Hi,
I vote for B, as it seems to be the most reasonable way forward.
However, C sound tempting too.
Br,
Teemu
> -----Original Message-----
> From: ext Bob Hinden [mailto:[EMAIL PROTECTED]
> Sent: 28 August, 2003 01:27
> To: [EMAIL PROTECTED]
> Cc: Hinden Bob (IPRG); 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: [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]
--------------------------------------------------------------------
