Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing)

From: "Bound, Jim" <[email-masked]>
Date: Fri, 2 May 2003 07:18:59 -0400

The entire working group did decide this is not going to be resolved and
we cannot agree hence they should be deprecated for now and that is the
consensus.  Your view is invalid here not the Chairs.
/jim

> -----Original Message-----
> From: Tony Hain [mailto:[email-masked]] 
> Sent: Monday, April 28, 2003 9:44 PM
> To: 'Thomas Narten'; 'Erik Nordmark'
> Cc: [email-masked]; 'Bob Hinden'; 'Margaret Wasserman'
> Subject: RE: Your Appeal Regarding Site-Local Deprecation 
> (Was: Consensus on Site-Local Addressing)
> 
> 
> Thomas & Erik,
> 
> I trust that you will take a more objective view of this, 
> because any outsider who needs to watch that video will be 
> rolling in the isles with laughter at the absurdity of the 
> process abuse in this case. At least 5 long-time IETF 
> participants (including yourself) felt the need to state what 
> they meant by 'deprecate SL'. One has to assume they bothered 
> to assert their interpretation because the YES/NO question 
> was unclear to them, or that their need to explain which 
> question they were answering is an implicit statement that 
> the original question was unclear. Even though the question 
> never changed, none of the (amazingly vague) clarifying 
> remarks in SF were sent to the list version of the consensus call.
> 
> If a legal professional were to watch the proceedings here, 
> they would comment that the WG gave the chairs the freedom to 
> interpret the meaning of the question any way they choose. In 
> fact we have examples of that already on the mail list and in 
> this response. 
> 3/30 chair email claimed
> > As part of deprecating site-local addressing, we
> > agreed in the meeting that, in addition to  deprecating 
> > site-local addressing in the addressing architecture 
> > and removing it from other  places (scoped addressing 
> > architecture, address selection rules, etc.), a document 
> > would be  written that would do two things:
> >
> >         - Explain why site-local addressing was deprecated
> >         - Outline alternative means to address some of the
> >                 problems that could have been solved by
> >                 site-local addressing.
> 
> That question was never asked of the room, and those 
> statements were not made by the chairs in SF. How could there 
> be an agreement?
> 
> > The decision to deprecate site-local addressing,
> > rather than simply removing it, was made to avoid 
> > harm to IPv6.
> 
> There was nothing more to this than vague conversations 
> between Margaret & Keith, and Margaret & Thomas. There was no 
> decision by the WG, just a chair proclamation that one had 
> occurred. We can't allow the WG process to degenerate to the 
> point that a chair can call an ambiguous YES/NO question, 
> then make up anything they choose to have it mean later. In 
> particular, when the chair explicitly states '... if we 
> eliminate it we will also have multiple choices about what 
> exactly that means ...', and '... may have to hand wave ...' 
> there is not a clear indication about what question is being asked. 
> 
> I put specific rebuttal comments to the chair's rejection in 
> a list response to the chairs. In summary I believe the 
> chairs have declared a consensus when there really wasn't one 
> due to the ambiguity of the question. Specifically the YES 
> votes for removing addresses with local scope from the 
> architecture or consideration by applications are void, as 
> that is not something the IETF gets to decide. Had the chairs 
> asked Keith's original question about finding an alternate 
> way forward through replacement technologies, we would not be 
> going through this process. 
> 
> As for a path forward, I would expect you to invalidate the 
> consensus, then have the WG stop the pronouncements that SL 
> is dead, and work on finding appropriate replacements. This 
> effort must begin with identification of the requirements for 
> addresses of local scope, and under local network manager 
> control. With requirements in hand, the scoped address 
> architecture document needs to specifically deal with 
> handling mixed scope addresses, both between and for 
> simultaneous use on a singe node. That document in particular 
> is hopelessly gutted and meaningless without such a 
> discussion. IF we get to the point were all requirements are 
> met by alternatives, the current SL definition should 
> appropriately be moved to historic. If not, it will likely 
> end up in the corner case use that Keith was trying to 
> achieve. Either way, the entire WG must decide exactly what 
> happens. We must not allow the 'ambiguous YES/NO question - 
> chairs subsequently decide what it means', process to set a precedent.
> 
> Tony
> 
> 
> 
> 
> Margaret Wasserman wrote:
> > Hi Tony,
> > 
> > We have considered your appeal regarding the IPv6 WG
> > consensus to deprecate site-locals.  Based on our analysis, 
> > we believe that your appeal makes the following points:
> > 
> >    (1) You believe that deprecating IPv6 site-local unicast
> >        addressing is an incorrect technical choice that places
> >        the work output of the IPv6 WG in jeopardy.
> > 
> >    (2) You believe that the question asked by the chairs
> >        was insufficiently clear to be understood properly
> >        by the WG.
> > 
> >    (3) You do not believe that there is rough consensus to
> >        deprecate IPv6 site-local addressing, because people
> >        provided different reasons for why they believe that
> >        IPv6 site-local addressing should be deprecated.  In
> >        particular, some people want to deprecate the particular
> >        model of site-local addressing defined in the scoped
> >        addressing architecture (ambiguous, scoped addresses),
> >        while others do not believe that we need a local
> >        addressing mechanism at all.
> > 
> >    (4) You believe that it is invalid for the IPv6 WG to
> >        deprecate site-local addressing without publishing an
> >        IPv6 WG document that analyzes the operational requirements
> >        for local addressing.  Without this analysis document, you
> >        believe that the IPv6 WG has made an uninformed choice.
> > 
> > We will now respond to each of your points.
> > 
> > --
> > 
> > Point (1):
> > 
> > The chairs do not believe that deprecating IPv6 site-local
> > addressing is an incorrect technical decision that will place 
> > the work output of the IPv6 WG in jeopardy.
> > 
> > The consensus was to "deprecate" the usage of site-local
> > addressing instead of simply removing it. This was done 
> > purposely to avoid interference with any current 
> > implementations or deployments that might use site-local 
> > addressing.  In addition to the time it will take to formally 
> > deprecate site-local addressing by publishing an RFC, the WG 
> > understands that it will take some time after the publication 
> > of an RFC for implementations to change.  The decision to 
> > deprecate site-local addressing, rather than simply removing 
> > it, was made to avoid harm to IPv6.
> > 
> > In fact, we believe that the previous disagreement over the
> > usage of IPv6 site-local addressing was damaging to the WG, 
> > and that our lack of consensus was delaying our work, 
> > particularly on the IPv6 scoped addressing architecture.  The 
> > consensus to deprecate site-local addressing will allow us to 
> > move forward and complete our work.
> > 
> > ---
> > Point (2):
> > 
> > The question was:
> > 
> >      "Should we deprecate IPv6 site-local unicast
> >      addressing?"  Possible answers were YES or NO.
> > 
> > The chairs believe that this question was sufficiently clear to be 
> > understood by the WG.  This is supported by the following
> > points:
> > 
> >      - Over 200 people responded to the question.
> > 
> >      - Many of the responses on the list (both YES and NO
> >        responses) included reasons or comments that
> >        followed from the question in a way that indicated
> >        that the responders understood the question.
> > 
> >      - There were only three requests for clarification of
> >        this consensus call on the mailing list, two of which
> >        were procedural.  All of these requests were answered
> >        promptly by the chairs.
> > 
> >      - The chairs sent the consensus results to the list
> >        over two weeks ago, including a course of action for
> >        the deprecation of site-local addressing.  There
> >        have been no objections from people who originally
> >        expressed YES opinions that the chairs' course of
> >        action fails to match their expectations.
> > 
> > ---
> > 
> > Point (3):
> > 
> > The chairs do not believe that consensus on an issue is
> > invalidated by the fact that people have multiple reasons for 
> > coming to the same conclusion.  We suspect that this happens 
> > in most WG consensus calls, and this is not a reason to 
> > invalidate the consensus.
> > 
> > All of the groups that you mentioned in your message agreed
> > that IPv6 site-local unicast addressing should be deprecated. 
> > They may disagree on what we should do after deprecating 
> > site- local addressing, but that does not invalidate the 
> > consensus on this point.
> > 
> > ---
> > 
> > Point (4):
> > 
> > It is true that the IPv6 WG has not produced a WG document
> > that analyzes the operational requirements for local 
> > addressing.  However, we do not believe that this is a reason 
> > to invalidate the IPv6 WG consensus to deprecate IPv6 
> > site-local unicast addressing.
> > 
> > There has been considerable discussion and analysis of site-
> > local addressing performed over the past year, including 
> > extensive discussions during three IETF sessions.  There have 
> > also been several drafts published on the subject, including 
> > one draft that attempts to analyze the cost/benefit 
> > trade-offs of site-local addressing.
> > 
> > This period of discussion has offered sufficient time for
> > anyone who has an operational need for any of the 
> > currently-defined usage models of site-local addressing to 
> > document those requirements in an Internet-Draft and/or to 
> > discuss those requirements on the IPv6 mailing list.
> > 
> > During our discussions, several operational benefits of
> > site-local addressing have been raised on the IPv6 WG mailing 
> > list, including benefits for disconnected sites, 
> > intermittently- connected sites, renumbered sites, etc.  We 
> > have also uncovered several issues and complexities caused by 
> > the current model of ambiguous, scoped site-local addressing, 
> > and we have determined that this particular model places 
> > burdens on other parts of the TCP/IP protocol suite, 
> > particularly routing protocols and applications.
> > 
> > In a recent phone discussion and in your appeal
> > clarification, you have indicated that the chairs should void 
> > responses from people who do not think that the IPv6 WG 
> > should specify any type of local addressing mechanism, 
> > because you believe that those responders are uninformed 
> > about the operational conditions that require the use of 
> > local addressing.
> > 
> > While operational necessity is certainly an appropriate
> > argument to raise in support of your position that the IPv6 
> > WG should specify some mechanism for local addressing, the 
> > fact that you disagree with the reasons that some people 
> > offered for why they want to deprecate the current IPv6 
> > site-local unicast addressing mechanism does not invalidate 
> > their contribution to this consensus call.
> > 
> > It is the opinion of the chairs that the IPv6 WG did have
> > sufficient information to make an informed decision regarding 
> > whether or not to deprecate IPv6 site-local unicast addressing.
> > 
> > ---
> > 
> > So, to summarize, the chairs do not agree with the points
> > that you have raised in your appeal, and we do not agree to 
> > overturn the consensus of the IPv6 WG based on the issues 
> > that you have raised.
> > 
> > Tony, while we disagree with your position on this particular
> > issue, we do respect your contributions to the IPv6 effort 
> > and we realize that your appeal is motivated by your desire 
> > to do the right thing for IPv6.  We hope that you will accept 
> > our response to your appeal and focus on working to define 
> > the local addressing problem and solutions as we outlined in 
> > our email to the list. We think it is important for the 
> > working group to move forward on this issue.
> > 
> > Best Regards,
> > 
> > Bob Hinden & Margaret Wasserman
> > IPv6 WG Chairs
> > 
> > 
> > --------------------------------------------------------------------
> > 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-masked]
> > --------------------------------------------------------------------
> > 
> 
> 
> --------------------------------------------------------------------
> 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-masked]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 2 May 2003 08:54:48 -0700

Bound, Jim wrote:
> The entire working group did decide this is not going to be 
> resolved and we cannot agree hence they should be deprecated 
> for now and that is the consensus.  Your view is invalid here 
> not the Chairs. /jim

I have a hard time believing that you of all people would have agreed
that 'somewhere to the left ...' and 'have to hand wave ...' were
adequate definitions of the question. Exactly what is the plan to
replace non-provider controlled address space, since the working group
has never been able to agree on any other approach? Forcing all sites
into provider-only space will guarantee that they deploy nat to isolate
themselves from the whims of the provider.

Tony

> > > We have considered your appeal regarding the IPv6 WG consensus to 
> > > deprecate site-locals.  Based on our analysis, we believe 
> that your 
> > > appeal makes the following points:
> > > 
> > > addressing is an incorrect technical decision that will place the 
> > > work output of the IPv6 WG in jeopardy.
> > > 
> addressing 
> > > instead of simply removing it. This was done purposely to avoid 
> > > interference with any current implementations or deployments that 
> > > might use site-local addressing.  In addition to the time it will 
> > > take to formally deprecate site-local addressing by publishing an 
> > > RFC, the WG understands that it will take some time after the 
> > > publication of an RFC for implementations to change.  The 
> decision 
> > > to deprecate site-local addressing, rather than simply removing
> > > In fact, we believe that the previous disagreement over 
> the usage of 
> > > IPv6 site-local addressing was damaging to the WG, and 
> that our lack 
> > > of consensus was delaying our work, particularly on the 
> IPv6 scoped 
> > > addressing architecture.  The consensus to deprecate site-local 
> > > addressing will allow us to move forward and complete our work.
> > > 
> > > ---
> > > Point (2):
> > > 
> > > The question was:
> > > 
> invalidated 
> > > by the fact that people have multiple reasons for coming 
> to the same 
> > > conclusion.  We suspect that this happens in most WG consensus 
> > > calls, and this is not a reason to invalidate the consensus.
> > > 
> > > All of the groups that you mentioned in your message agreed that 
> > > IPv6 site-local unicast addressing should be deprecated. They may 
> > > disagree on what we should do after deprecating
> > > It is true that the IPv6 WG has not produced a WG document that 
> > > analyzes the operational requirements for local addressing.  
> > > However, we do not believe that this is a reason to 
> invalidate the 
> > > IPv6 WG consensus to deprecate IPv6 site-local unicast addressing.
> > > 
> > > There has been considerable discussion and analysis of 
> site- local 
> > > addressing performed over the past year, including extensive 
> > > discussions during three IETF sessions.  There have also been 
> > > several drafts published on the subject, including one draft that 
> > > attempts to analyze the cost/benefit trade-offs of site-local 
> > > addressing.
> > > 
> anyone who 
> > > has an operational need for any of the currently-defined usage 
> > > models of site-local addressing to document those 
> requirements in an 
> > > Internet-Draft and/or to discuss those requirements on the IPv6 
> > > mailing list.
> > > 
> site-local 
> > > addressing have been raised on the IPv6 WG mailing list, 
> including 
> > > benefits for disconnected sites,
> clarification, you 
> > > have indicated that the chairs should void responses from 
> people who 
> > > do not think that the IPv6 WG should specify any type of local 
> > > addressing mechanism, because you believe that those 
> responders are 
> > > uninformed about the operational conditions that require 
> the use of
> > > local addressing.
> > > 
> argument to 
> > > raise in support of your position that the IPv6 WG should specify 
> > > some mechanism for local addressing, the fact that you 
> disagree with 
> > > the reasons that some people offered for why they want to 
> deprecate 
> > > the current IPv6 site-local unicast addressing mechanism does not 
> > > invalidate their contribution to this consensus call.
> > > 
> sufficient 
> > > information to make an informed decision regarding 
> whether or not to 
> > > deprecate IPv6 site-local unicast addressing.
> > > 
> > > ---
> > > 
> that you 
> > > have raised in your appeal, and we do not agree to overturn the 
> > > consensus of the IPv6 WG based on the issues that you have raised.
> > > 
> > > Tony, while we disagree with your position on this 
> particular issue, 
> > > we do respect your contributions to the IPv6 effort and 
> we realize 
> > > that your appeal is motivated by your desire to do the 
> right thing 
> > > for IPv6.  We hope that you will accept our response to 
> your appeal 
> > > and focus on working to define the local addressing problem and 
> > > solutions as we outlined in our email to the list. We think it is 
> > > important for the working group to move forward on this issue.
> > > 
> > > Best Regards,
> > >