Well, there are far more people saying yes than no, but let me respond to some of the comments made.
1. Process (Tony Hain). Of course. If we make a substantive change to a draft that's already passed the IESG, a last call is needed IMHO. It would still be cleaner than publishing the RFC and then publishing a change. 2. Rationale. (several people). Yes, it might be good to publish an informational document about this. That might well belong in v6ops. 3. Can't stop NAT's anyway. (several people). That may sadly be true, but we shouldn't publish specs that seem to encourage them. 4. Impact on existing implementations and ongoing work. (several people). I don't really understand what the implementation change would be - surely this is basically a configuration issue? Products will still have to support SL. If we are going to impact ongoing work, however, the sooner the better. 5. Why not just kill SL completely? (JINMEI) That would definitely annoy implementors, and close off our options. 6. We have to handle multiple scopes anyway (Brian Zill, Tony Hain). Right. And by retaining SL, we retain the option of reversing the "disconnected" decision if we ever do figure out how to handle them properly. 7. must not v. MUST NOT (Keith Moore). The document as a whole doesn't use upper case. 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 -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- 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] --------------------------------------------------------------------
