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

[James Carlson <[e-mail]>]

On 08/16/10 01:42, Eswaran Srinivasan wrote:
> 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)?

It's RFC 1717 that deprecates Class 1 ... before even RFC 1990.  It was
born deprecated.

The proposed draft is not changing this, so I think this discussion
might be a bit off-topic for the draft itself.

> 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.

There's no specific time limit nor prohibition against using it.

I think the original fear with Class 1 was that since there's no defined
way to ensure uniqueness among bundle heads, there could possibly be
duplication of values -- which would cause (at least) link failures.

As I read it, and perhaps someone else here remembers more about it, the
force of the "deprecation" is that it's not the recommended practice for
new systems, because the other defined mechanisms are believed to be
better and just as easy to use, and that there's the possible threat
that it may be removed entirely from future specifications.

However, if it is indeed in common use, then that'd be a good reason to
document those usages and perhaps create a new document that removes the
"deprecated" status rather than removing the feature.  Do you have
pointers to any additional information?

-- 
James Carlson         42.703N 71.076W         <[e-mail]>