Erik,
> Care to suggest some text?This is OK for me. I will plan add it to the next version of the draft. Would you like to be listed as an author?
RFC 2374 contained an IPv6 allocation structure that included
TLA (Top Level Aggregator) and NLA (Next Level Aggregator) which
is formally made historic by this document.
The TLA/NLA scheme has been replaced by an coordinated allocation policy
defined by the Regional Internet Registries [REF].
Part of the motivations for obsoleting the TLA/NLA structure
were technical, for instance there was concerns that it was not
the technically best approach at this point in time on IPv6 deployment.
Another part of the motivation was that the issues of how the
IPv6 address space is managed is much more related to policy and
to the the stewardship of the IP address space and routing table
size that the RIRs have been managing for IPv4. It is likely that
the RIRs policy will evolve as IPv6 deployment proceeds.
The IETF has provided technical input to the RIRs
(for example [RFC 3177]) that has been taken into account
when defining the policy.
Any one else have comments on this change?
OK, that is clearer. It wouldn't be too hard to make this change, but there doesn't seem to be complete agreement on the list for this change.> >Because this might confuse people that they should only code for 2000::/3 > >in their implementation? > > I don't see how one could come to this conclusion. > > 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:I agree that RFC 2374 only covers that prefix. But that doesn't mean that the docment which makes 2374 historic needs to have the same limitation. > What did you have in mind that might further clarify this issue? Remove "for the 2000::/3 Prefix" from the title and remove the mention of the specific prefix from the text.
I think it provides a summary of what the resulting address format for this prefix (and other prefixes if the above change is made). Since we now seem to heading toward a non-standards track document, what is the harm?Apart from the restriction to 2000::/3 I don't see how section 2.0 adds anything beyond what is in addr-arch. Perhaps I'm missing something.
The RIPv1/v2 case seems fairly different to me, because the RIPv2 existed for a long time before RIPv1 was made historic.> 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. But the strong message would be that there would be an IETF last call saying that RFC 2374 is moving to historic and this doc informational. Then this will be permanently recorded in rfc-index with 2374 being marked as historic. This seems to be strong enough for other protocols/documents we've made historic such as RIPv1 (with RFC 1923 being the info doc that explains why).
I now agree that it can be non-standards track. What was your objection to making it a BCP? In some ways this is the best current practice.
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]
--------------------------------------------------------------------
