RE: Moving forward on Site-Local and Local Addressing

[Soliman Hesham <H.Soliman@xxxxxxxxxxx>]

C makes sense to me. 

Hesham

 > ----- Original Message -----
 > From: "Bob Hinden" <hinden@iprg.nokia.com>
 > To: <ipng@sunroof.eng.sun.com>
 > Cc: <hinden@iprg.nokia.com>
 > Sent: Monday, August 04, 2003 9:06 PM
 > Subject: Moving forward on Site-Local and Local Addressing
 > 
 > 
 > > [IPv6 working group chair hat on]
 > >
 > > I think the working group has been making good progress on 
 > replacing
 > > site-local addresses and wanted to get feed back from the 
 > working group on
 > > how we should move forward.  This is not intended to 
 > directly relate to
 > the
 > > ongoing appeal of the working groups decision to deprecate 
 > the usage
 > > site-local addresses, but to get feedback on how to 
 > proceed.  I think it
 > is
 > > very important that we move forward on this issue and not 
 > rehash what has
 > > happened in the past.
 > >
 > > We now have a combined local addressing requirements document
 > > <draft-hain-templin-ipv6-limitedrange-00.txt>, a specific 
 > alternative to
 > > site-local addresses draft 
 > <draft-hinden-ipv6-global-local-addr-02.txt>
 > > (accepted as a working group item at the Vienna IETF), and 
 > will soon have
 > a
 > > draft describing why site-local addresses are being 
 > deprecated and doing
 > > the formal deprecation (authors identified and outline 
 > discussed at the
 > > Vienna IETF).  Note that all of these documents will 
 > proceed through the
 > > normal working group and IETF processes of last calls and review.
 > >
 > > I think legitimate questions have been raised about how 
 > the working group
 > > should go about deprecating site-local addresses given 
 > their maturity in
 > > the current specifications and use in deployed products.  
 > Specifically
 > > should they be deprecated independently from having an alternative
 > solution
 > > available, at the same time an alternative is available, 
 > or sometime after
 > > an alternative is available.  A forth alternative is to not replace
 > > site-local addresses in any form, but I think the working 
 > group has made
 > it
 > > clear that this is not a reasonable alternative.
 > >
 > > I would like to hear from the working group on how we 
 > should proceed.  I
 > > think the choices are:
 > >
 > > A) Deprecate Site-Local addresses independently from 
 > having an alternative
 > > solution available.  This would mean that the working 
 > group should treat
 > > the deprecation, and requirements and solution documents 
 > outlined above
 > > independently from each other.  If there was no consensus on an
 > alternative
 > > a replacement would not happen.
 > >
 > > B) Deprecate Site-Local addresses at the same time as a alternative
 > > solution is agreed to.  This would mean advancing both 
 > documents at the
 > > same time and making them include normative references to 
 > each other to
 > > insure that they were published at the same time.  This 
 > would result in
 > the
 > > deprecation only happening if a consensus was reached on 
 > an alternative.
 > >
 > > C) Deprecate Site-Local addresses after an alternative is defined,
 > > standardized, and in operational practice.  This would 
 > mean not advancing
 > a
 > > deprecation document until there was operational evidence that the
 > > alternative was working and shown to be an improvement 
 > over Site-Local
 > > addresses.
 > >
 > > Note:  In the above choices "Deprecate Site-Local addresses" means
 > > publishing an RFC that does the formal deprecation.
 > >
 > > Please respond to the list with your preference, or if there is an
 > > alternative approach that is an improvement from the ones 
 > I outlined.  I
 > > hope that many of you will respond.
 > >
 > > Thanks,
 > > Bob
 > >
 > > 
 > --------------------------------------------------------------------
 > > 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 majordomo@sunroof.eng.sun.com
 > > 
 > --------------------------------------------------------------------
 > 
 > --------------------------------------------------------------------
 > 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 majordomo@sunroof.eng.sun.com
 > --------------------------------------------------------------------
 > 
--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------