I vote for B or C.
MikaL
On Thu, 2003-08-28 at 01:26, Bob Hinden wrote:
> 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: [EMAIL PROTECTED]
> >From: Bob Hinden <[EMAIL PROTECTED]>
> >Subject: Moving forward on Site-Local and Local Addressing
> >Cc: [EMAIL PROTECTED]
> >
> >[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 [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]
--------------------------------------------------------------------
