Re: new draft published: draft-vautrin-6man-ipv6-mlppp-id-00.txt

Thanks Eswaran for your comment, I will rephrase the sentence about Class 1.

/Olivier

> -----Original Message-----
> From: Eswaran Srinivasan [mailto:[email protected]]
> Sent: Sunday, August 15, 2010 10:42 PM
> To: James Carlson
> Cc: [email protected]; [email protected]; [email protected]
> Subject: Re: [Pppext] new draft published: draft-vautrin-6man-ipv6-
> mlppp-id-00.txt
> 
> Hi Olivier,
> 
> The draft looks great to me in general.  However, I have a question to
> you.
> 
>     The section 1 says that the IPv6 class is introduced since the
>     class 1 (Locally Assigned Address) is deprecated.  I am thinking
>     that having a IPv6 class is useful even if class 1 is not
> deprecated.
> 
>     Should we rephrase the sentence (if you agree)?
> 
> Hi Jim,
> 
> I can still see the usefulness of class 1 and I have heard about a lot
> of deployment scenarios with this.  So, what does 'deprecated' mean
> here?
> Is there any time limit?
> 
> Basically, I am inclined towards making it 'non-deprecated' and I am
> trying to understand the logistics behind doing it.
> 
> Thanks
> -Eswaran
> 
> On Fri Aug 13, 2010 at 12:36:25PM -0700, James Carlson wrote:
> > >     Title           : Multi link PPP Support for an ipv6 address
> class
> > > identifier
> > >     Author(s)       : O. Vautrin, B. Lourdelet
> > >     Filename        : draft-vautrin-6man-ipv6-mlppp-id-00.txt
> >
> > In general, I like the idea, but I'd like to suggest a few amendments
> > (or at least points for consideration):
> >
> > - Some IPv6 addresses are probably not as suitable for use as others.
> > In particular, using a link local is unlikely to be a good idea
> because
> > of the greater risk of duplication.  We glossed over this issue with
> > IPv4 in RFC 1990, mostly because link-locals are so 'rare' there, but
> it
> > seems more important to call out in the context of IPv6.
> >
> > - A "privacy" address, or any other "changes frequently" address, may
> be
> > a problem operationally.  If a PPP system establishes one link, and
> then
> > later (perhaps on demand) establishes another link that's intended as
> > part of a bundle, that second link will need to use the same endpoint
> > discriminator.  If the address has changed, the bundle will fail.
> > Implementations likely need to "sample" a locally-available IPv6
> > address, and then keep using that address for all future links until
> the
> > bundle itself is terminated -- regardless of the current status of
> that
> > address on the system.
> >
> > That is, I believe the document should explicitly _encourage_ the use
> of
> > IPv6 addresses in this one context past the point where the system is
> > otherwise still "allowed" to use the address.  If that can't be done
> > (e.g., if the IPv6 folks believe that this usage is somehow a
> problem),
> > then addresses that are expected to change need to be avoided.
> > (Personally, I don't see how it could be a problem, unless you're
> > prepared to tear down the whole bundle when the address becomes
> invalid,
> > but I guess I'm unsure here.)
> >
> > - As a nit, I don't think it's wise to duplicate the existing RFC
> 1990
> > values for Class in this document.  Instead, just the new value and
> > semantics should be included.
> >
> > - I think this ought to be a standards-track document that updates
> RFC
> > 1990, and (with your agreement, of course) should be a wg document.
> > (See RFC 3818; the Class numbers are "IETF Consensus.")
> >
> > - Wow.  The new boilerplate makes a visual mess of otherwise nice,
> > simple proposals like this.  :-<
> >
> > --
> > James Carlson         42.703N 71.076W
> <[email protected]>
> > _______________________________________________
> > Pppext mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/pppext
_______________________________________________
Pppext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pppext