Erik, At 09:05 AM 2/12/2003, Erik Nordmark wrote:
I too agree with this view. I tried to write this draft to be as uncontroversial as possible so it could proceed quickly and accomplish the goal of replacing RFC2374.> I agree with Michel. Although Thomas is logically correct, > I think that including section 2.0 and putting this on > standards track is a necessary signal to ensure that TLAs > are really understood to be dead.
If you want to be explicit about TLA/NLA being dead why not have a section 2.0 titled "TLA and NLA are dead" with a shortish explanation of why and with an informational reference to the registries document?
Care to suggest some text?
I don't see how one could come to this conclusion.> I also think the explicit reference to 2000::/3 is useful. > It's the only space currently being allocated. Because this might confuse people that they should only code for 2000::/3 in their implementation?
The draft was written to only cover the 2000::/3 prefix because the document it is obsoleting also only covers that prefix. For example from section 2.0 of RFC2374:
This document defines an address format for the 001 (binary) Format
Prefix for Aggregatable Global Unicast addresses. The same address
format could be used for other Format Prefixes, as long as these
Format Prefixes also identify IPv6 unicast addresses. Only the "001"
Format Prefix is defined here.
Making it apply to other prefixes seemed out of scope to me.
We tried to make this clear in addr-arch-v3 (hopefully clear enough) but this document is not clear enough on that issue.
What did you have in mind that might further clarify this issue?
While I don't feel too strongly about that status of the document, I share the belief that is important to send a "strong" message. Perhaps classifying it as a BCP might be a good middle ground.Since RFCs live forever the "currently being allocated" argument might not be a good argument. Finally, assuming that this document isn't going standardize anything (now that the documentation prefix is removed) I think it makes sense having be an informational document that is part of a protocol action which moves RFC 2374 to historic. Only if this document standardizes some replacement to 2374 would it make sense for it to be proposed standard. Examples of "move to historic" documents are RFC 3197 and RFC 3167. They tend to explain why and what is being made historic with varying levels of detail.
Bob
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
