Subject: Document Action: IPv6 Global Unicast Address Format to Informational

From: The IESG <[email-masked]>
Date: Wed, 18 Jun 2003 18:00:41 -0400

The IESG has approved the Internet-Draft 'IPv6 Global Unicast 
 Address Format' <draft-ietf-ipv6-unicast-aggr-v2-02.txt> as an 
 Informational RFC. This document will replace RFC2374 and 
 reclassify RFC 2374 (and the TLA/NLA structure described there) 
 as historic.

 This document is the product of the IP Version 6 Working Group.
 The IESG contact persons are Thomas Narten and Erik Nordmark.

 Technical Summary
   
 RFC2374 "An IPv6 Aggregatable Global Unicast Address Format" 
 defined an IPv6 address allocation structure that includes TLA 
 (Top Level Aggregator) and NLA (Next Level Aggregator). This 
 document replaces RFC2374, and makes RFC 2374 and the TLA/NLA 
 structure historic.
   
 Working Group Summary
   
 There was support for this in the WG; this document documents 
 what the WG decided quite some time ago.
   
 Protocol Quality
   
   This document has been reviewed for the IESG by Thomas Narten.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Thu, 19 Jun 2003 12:46:10 -0400

>  reclassify RFC 2374 (and the TLA/NLA structure described there) 

This announcement was premature; there are still ongoing discussions on
some wording.

To cut to the chase, one of the IESG comments (which actually came
from one of Randy's OPS reviewers) was:

    >***** o IPv6 Global Unicast Address Format (Informational)
    > <draft-ietf-ipv6-unicast-aggr-v2-02.txt>
    > Token: Narten, Thomas
    > Note: An IETF LC call is needed, as this reclassifies RFC 2374 
    > historic.; last call expires 2003-04-08.

    my concern with this note is that at the top of page 3
    the diagram implies that there is a single global
    routing prefix, followed by a subnet id.
    the text says that the global-routing-prefix is 
    typically hierarchically structured, which implies
    that it is not a single global routing prefix but
    has some internal structure, with higher and lower
    levels of prefix and so on and so forth. it _might_
    be nice if the authors were to do a bit of text editing
    and try and get the diagram to say the same thing (eliminating
    the implication in the diagram that there is exactly 1 prefix).

    also, the text and diagram sort of imply that there is one level
    of 'subnet id' that would be available to a 'site'. this is
    not completely true. my isp may allocate me a /32, leaving
    me 32 bits to play with which i may in turn make hierarchical
    allocations out of. again, some text twiddling might be nice
    here.

There was further discussion, which eventually led to a proposal from
Bob:

Bob Hinden <[email-masked]> writes:

> >Okay, it sounds like we're in agreement here.  Bob, does this
> >work for you?  Any remaining questions?

> Works for me.  How about if I change the text:

>     where the global routing prefix is a (typically hierarchically-
>     structured) value assigned to a site (a cluster of subnets/links),
>     the subnet ID is an identifier of a subnet within the site, and the
>     interface ID is as defined in section 2.5.1 of [ARCH].

> to:

>     where the global routing prefix is a (typically hierarchically-
>     structured) value assigned to a site (a cluster of subnets/links),
>     the subnet ID is an identifier of a subnet within the site, and the
>     interface ID is as defined in section 2.5.1 of [ARCH].  The global
>     routing prefix is designed to be hierarchically structured by
>     the RIRs and ISPs, and the subnet field is designed to be hierarchically
>     structured by site administrators.

With this change, the IESG is expected to approve the document.

Is this OK with everyone?

If so, we either need to reissue the document or ask for an RFC editor
note. I can go either way.

Thomas

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 19 Jun 2003 12:52:19 -0400

>note. I can go either way.

If it is okay with everyone, let's just re-issue the document.
I think that would be cleaner.

Margaret

---

From: Bob Hinden <[email-masked]>
Date: Thu, 19 Jun 2003 14:45:42 -0700

Margaret,

I just submitted it.

Bob