I think Brian's proposal, if adopted, makes my worry about site-locals inducing complexity in naming lookup mechanisms go away (naming mechanisms for disconnected networks have to be different from those for connected networks anyway).

So you can count me as supporting the proposal.

That said, I also think that writing down (some of) the arguments on the issue in permanent form would be a good idea...... and there are a few devils-in-the-details having to do with the transition between connectedness and disconnectedness, which also could use some words-on-electrons.

But this resolution seems basically right to me.

Harald

--On tirsdag, november 12, 2002 13:53:00 +0100 Brian E Carpenter <[EMAIL PROTECTED]> 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]
--------------------------------------------------------------------


--------------------------------------------------------------------
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