> >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?
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.
> >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.
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.
> 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).
Erik
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
