Well, that was fun: send one message and receive a few hundred. Peace.

I'm very sensitive to the argument about intermittently connected
networks needing a stable prefix. So I would finally prefer the 
addressing architecture to contain yet another version of the
text in question:

   Site-local addresses are designed to be used for addressing inside of
   a site which is not permanently connected to the Internet. Using 
   site-local addresses, a subnet ID may be up to 54-bits long, but it 
   is recommended to use at most 16-bit subnet IDs, for convenience of
   subnet management.

Why? Because we don't have consensus, and this text carries less baggage
than the others, which seems appropriate for an architecture document.

However, it may be that this change is not enough for the WG to recall
the draft from the RFC Editor. I think we should hum on that in Atlanta.

    Brian

Brian E Carpenter wrote:
> 
> Unfortunately it's too late to catch the addressing architecture
> document unless we recall it from the RFC Editor and cycle it
> through the IESG again. But I propose that we do exactly that,
> in order to change the following paragraph in section 2.5.6:
> 
> Current text:
> 
> >    Site-local addresses are designed to be used for addressing inside of
> >    a site without the need for a global prefix.  Although a subnet ID
> >    may be up to 54-bits long, it is expected that globally-connected
> >    sites will use the same subnet IDs for site-local and global
> >    prefixes.
> 
> Proposed new text:
> 
>    Site-local addresses are designed to be used for addressing inside of
>    a site which is not connected to the Internet and therefore does not
>    need a global prefix.  They must not be used for a site that is connected
>    to the Internet. Using site-local addresses, a subnet ID may be up to
>    54-bits long, but it is recommended to use at most 16-bit subnet IDs,
>    for convenience if the site is later connected to the Internet using a
>    global prefix.
> 
> Otherwise, we will need a whole new RFC just for this paragraph.
> 
> Alternatively, we could spend the next 5 years discussing the
> unnecessary complexities of using site-locals on connected sites.
> 
>   Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to