Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> > Perhaps declaring 6to4 deprecated rather than historic would have a
>> > better chance of consensus.
>>
>> Pardon my ignorance, but where is the document describing the
>> implications of historic{,al} vs deprecated?
>>
>> This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:
>>
>> """
>>    A specification that has been superseded by a more recent
>>    specification or is for any other reason considered to be obsolete is
>>    assigned to the "Historic" level.  (Purists have suggested that the
>>    word should be "Historical"; however, at this point the use of
>>    "Historic" is historical.)
>>
>>    Note: Standards track specifications normally must not depend on
>>    other standards track specifications which are at a lower maturity
>>    level or on non standards track specifications other than referenced
>>    specifications from other standards bodies.  (See Section 7.)
>> """
>>
>> I don't know where similar explanatory language about "Deprecated"
>> might be (I'm sure I just didn't search correctly or long enough).
>
> Since 6rd depends on 6to4, as it is a variant of it, would 6to4 being
> declared historic also mean that 6rd needs to become historic as well?

http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05
Section 1, in which the draft clarifies that 6rd supersedes 6to4,
which meets the qualification in the first paragraph of the "Historic"
term.  With 6rd we clearly don't need to have anything built on top of
6to4 in the future, addressing the 2nd paragraph.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]