[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Current Results from Poll



Hi.

I vote B with C as a second preference.

Ending up with no site locals for any period of time will just result in
people inventing them in an ad-hoc fashion.

Regards,
Elwyn Davies

> -----Original Message-----
> From: Bob Hinden [mailto:hinden@iprg.nokia.com] 
> Sent: 27 August 2003 23:27
> To: ipng@sunroof.eng.sun.com
> Cc: hinden@iprg.nokia.com; Margaret Wasserman
> Subject: Current Results from Poll
> 
> 
> The current results of the poll (appended below) started 
> early in August are:
> 
>      Preference A       21
>      Preference B       13
>      Preference C        7
>                      ------
>      Total              41
> 
> If you missed this and want to express a preference, please 
> do so.  41 
> isn't a large number given the size of the working group.  The chairs 
> wanted to give folks who might have missed this due to being 
> on vacation or 
> who were overwhelmed by the amount of email a chance to 
> respond.  You can 
> send your responses directly to the chairs or to the list. We 
> plan to send 
> a final summary (including the actual results to make sure we 
> got them 
> correctly) in a few weeks.
> 
> Thanks,
> Bob
> 
> >Date: Mon, 04 Aug 2003 11:06:55 -0700
> >To: ipng@sunroof.eng.sun.com
> >From: Bob Hinden <hinden@IPRG.nokia.com>
> >Subject: Moving forward on Site-Local and Local Addressing
> >Cc: hinden@iprg.nokia.com
> >
> >[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
--------------------------------------------------------------------