The deprecation text in draft-ietf-ipv6-deprecate-site-local-00.txt
was very carefully drafted after observing the mailing list debate,
including the earlier poll reponses. While I don't want to complicate
the discussion further, I would like to suggest that people read
Section 4 of the draft very closely, before making their choice.
To save you some bother, here is that section in its entirety,
with a silly typo corrected:
4 Deprecation
This document formally deprecates the IPv6 site-local unicast prefix
defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The
special behavior of this prefix MUST no longer be supported in new
implementations. The prefix MUST NOT be reassigned for other use
except by a future IETF standards action. Future versions of the
addressing architecture [RFC3513] will include this information.
However, router implementations SHOULD be configured to prevent
routing of this prefix by default.
Existing implementations and deployments MAY continue to use this
prefix.
Brian
Greg Daley wrote:
>
> Hi Bob,
>
> I know I'm late, but I vote for B.
>
> Greg Daley
>
> 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]
> --------------------------------------------------------------------
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM
NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
