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

From: Margaret Wasserman <[email-masked]>
Date: Fri, 11 Apr 2003 10:16:09 -0400

Hi Tony,

Based on your messages below, we understand that you are attempting
to start an appeal regarding the IPv6 WG's decision to deprecate IPv6
site-local unicast addressing.  However, it is not entirely clear to
us what action (or inaction) you are appealing and on what grounds.  We
understand that you disagree with the WGs decision to deprecate IPv6
site-local unicast addressing without first defining an alternative
local addressing mechanism, but that is not, in itself, grounds for
an appeal.

In order for us to consider this appeal, you should follow the
appeals process outlined in section 6.5.4 of RFC 2026.  Your appeal
should include a "detailed and specific description of the facts
of the dispute".  In particular, you should make it clear exactly
what action (or inaction) you are appealing.

You must also indicate what grounds you have for appealing that
action (or inaction).  There are two possible grounds for appeal of
a WG action, listed in RFC 2026, section 6.5.1:

        (a) [your] own views have not been adequately considered
            by the Working Group, or
        (b) the Working Group has made an incorrect technical choice
            which places the quality and/or integrity of the Working
            Group's product(s) in significant jeopardy.

It might also be possible to raise a process appeal if you believe
that the chairs violated the process for session management described
in section 3.3 of RFC 2418.

Please explicitly state what you are appealing and explain your grounds
for appeal.  You should also supply any information necessary to explain
and support your position.  Once we have this information, we will
carefully consider your appeal and provide a written reply.

We understand that your appeal is motivated by your desire to do the
right thing for IPv6, and we will make every attempt to deal with it
fairly and promptly.

Bob Hinden & Margaret Wasserman
IPv6 WG Chairs

>Reply-To: <[email-masked]>
>From: "Tony Hain" <[email-masked]>
>To: "'Bob Hinden'" <[email-masked]>,
>         "'Margaret Wasserman'" <[email-masked]>
>Cc: <[email-masked]>
>Subject: FW: Consensus on Site-Local Addressing
>Date: Thu, 10 Apr 2003 10:31:47 -0700
>X-Mailer: Microsoft Outlook, Build 10.0.4510
>Importance: Normal
>X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com 
>id h3AHY8mh023731
>Sender: [email-masked]
>
>Bob &  Margaret,
>
>As I noted to Thomas a few moments ago, I have already raised concerns
>about the initial action of calling the ambiguous question. I believe
>his response indicates I also need to raise a concern with you about
>this specific action of declaring consensus. As the content of the note
>below indicates, there can be no consensus because the question was not
>clear. At best, this activity shows a desire to change the status quo,
>but it does not and can not indicate anything else. The consensus
>declaration must be voided.
>
>As I note below, steps 4) & 5) indicate work that the group believes we
>should take on. *If* the result of that work leaves us with no further
>use for the current definition for an ambiguous address space, then in
>that context I believe steps 1) & 3) are appropriate. Until then they
>are not, and are very likely to create chaos, particularly if done
>before 4) delivers complete alternatives.
>
>You must void the declaration of consensus, and should recognize that
>the original question was not clear.
>
>Tony
>
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Tony Hain
> > Sent: Wednesday, April 09, 2003 5:42 PM
> > To: 'Thomas Narten'; 'Erik Nordmark'
> > Cc: [email-masked]
> > Subject: FW: Consensus on Site-Local Addressing
> >
> >
> > Thomas & Erik,
> >
> > Please consider this the second step in the appeal process,
> > as I have already discussed these issues with the chairs on
> > more than one occasion.
> >
> > 'we reject kings, presidents and voting...'
> > The consensus measurement on the mail list was much more
> > indicative of the real lack of it (60/40%), than what was
> > effectively ballot stuffing by WG visitors without a complete
> > context. There was a very short presentation in the apps open
> > area, intended to raise concerns and incite involvement, were
> > those in the apps area were agitated, then invited to the
> > IPv6 WG session in SF to discuss the potential issues. The
> > subsequent short discussion in the IPv6 WG showed there were
> > issues to work through, and at least one question voiced
> > about understanding the requirements. Rather than deal with
> > the issues raised, the chairs decided to call an ambiguous
> > question of yes/no for deprecation.
> >
> > While the chairs do in 2) recognize their interpretation of
> > the consensus that the WG will investigate other forms of
> > local addressing, there is no mention of ambiguity and the
> > rest of the wording of 1) & 2) can be interpreted as local
> > scope addressing is deprecated. The concern is that we will
> > end up with a document lacking local scope addressing, and
> > claims that we had consensus to remove local scope from the
> > architecture. Many of those who bothered to state why they
> > were expressing a yes opinion claimed ambiguity was the
> > reason, while others were only interested in removing special
> > handling for local scope addresses. Those are technically
> > different issues, so they need different questions. What we
> > have is an indication that many are unhappy with the status
> > quo, but a lack of recognition that the call ended up
> > combining yes opinions for removing ambiguity with yes
> > opinions for removing local scope addresses from the
> > architecture. From subsequent discussions with the chairs, it
> > is clear that was not their intent, but never the less that
> > is the result of the lack of clarity in this consensus call.
> >
> > '... we believe in rough consensus & running code' & from the
> > Tao : 'running code wins' On several related mail threads
> > there were many comments about running code, and at least
> > Brian Zill & Brian Haberman said they collectively had host,
> > application, and router implementations of the current SL
> > running. Point 3) even acknowledges there are existing
> > implementations. This consensus call intends to invalidate
> > the running code, and all we have to replace it is a promise
> > in 4) that if the group can ever agree that operational
> > requirements of the site network manager are worth solving,
> > we might start to work on solutions, subject to appropriate
> > charter updates. This whole discussion is based on the
> > argument that some developers couldn't create running code
> > for an arguably bogus scenario where topology locators are
> > blindly passed outside their scope of relevance. Bias was
> > given to the opinions of those with a lack of running code,
> > at the expense of, and with the specific intent of
> > invalidating the code that exists.
> >
> > There were also claims in the meeting and mail threads that
> > we have analyzed site local as currently defined, and it
> > doesn't meet the requirements. At the same time, there is a
> > recognition by many of the same people that we need to
> > develop a complete set of requirements. It should be obvious
> > that the analysis is flawed if the complete set of
> > requirements are not understood first. To that end, and in
> > the spirit of making progress,
> > draft-hain-ipv6-sitelocal-00.txt was processed by the I-D
> > editor on 4/8, and is offered as an attempt to document the
> > requirements for address space with a local scope of
> > relevance. It is clearly incomplete, and largely based on my
> > previous email on the subject.
> >
> > While I contest the claim that the Yes/No opinions expressed
> > measured consensus for a consistent interpretation of what
> > 'deprecate site local addresses' means, I do believe that a
> > set of work items for the group were identified. It is also
> > clear that we can add new work to a group at any time,
> > without the need to remove existing items first. I agree with
> > the chairs that items 4) & 5) are valid outcomes of the
> > subsequent discussion, though one thing that their
> > interpretation of the result does not make clear is the
> > meaning of 'accomplish the following things in parallel:'. In
> > talking to the chairs it appears the intent is to start the
> > work at the same time, but we need to avoid invalid
> > transition states, so parallel needs to mean that all 5 are
> > to be forwarded to the IESG at one time. In particular,
> > without solutions to the requirements in hand, any documents
> > for 1) & 3) that intend to deprecate the only local use
> > address space will simply create chaos, and might need to be
> > rescinded if the complete set of requirements shows a need
> > with no other technical approach.
> >
> > In short, I do not believe the consensus call measured the
> > opinions that were consistent the chairs interpretation of
> > the question, so the claimed results are invalid. I do
> > believe that the effort identified work items 4) & 5), with
> > the potential that 1) & 3) might follow if there are no
> > outstanding requirements for ambiguous address space. I
> > question the wisdom of 2), but will reserve judgment until
> > the complete text identifying further work is spelled out. In
> > any case, I hope this appeal can be dealt with at this level,
> > and that the overall effort results in an expedited charter
> > update. It is imperative that new approaches exist prior to
> > removal of the current, and there is a very real danger that
> > the current destructive energy will dissipate in the face of
> > the hard work of creating replacements.
> >
> > Tony
> >

--------------------------------------------------------------------
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: Quality Quorum <[email-masked]>
Date: Fri, 11 Apr 2003 10:41:19 -0400

On Fri, 11 Apr 2003, Margaret Wasserman wrote:

> site-local unicast addressing.

Huh? You saw a consensus in this flurry of e-mail, unbelievable.

Just to be counted, my vote is 'no', all previous fights between IETF
and the market forces were easily won by the market forces. It is going
to happen again.

There is some undoubtful reason in the proposal - if you allow for PI
NAT6 will be unstoppable. The problem with the proposal is that it
unstoppable regardless of decision by WG/IESG/IETF.

Thanks,

Aleksey

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 11 Apr 2003 10:07:44 -0700

Margaret Wasserman wrote:
> Hi Tony,
> 
> Based on your messages below, we understand that you are 
> attempting to start an appeal regarding the IPv6 WG's 
> decision to deprecate IPv6 site-local unicast addressing.  
> However, it is not entirely clear to us what action (or 
> inaction) you are appealing and on what grounds. 

What is not clear about?
>> As the content of the note below indicates, there can 
>> be no consensus because the question was not clear. 

>>> Many of those who bothered to state why they were 
>>> expressing a yes opinion claimed ambiguity was the 
>>> reason, while others were only interested in removing 
>>> special handling for local scope addresses. Those are 
>>> technically different issues, so they need different 
>>> questions. 

>>> In short, I do not believe the consensus call measured 
>>> the opinions that were consistent the chairs 
>>> interpretation of the question, so the claimed results 
>>> are invalid. 

>  We 
> understand that you disagree with the WGs decision to 
> deprecate IPv6 site-local unicast addressing without first 
> defining an alternative local addressing mechanism, but that 
> is not, in itself, grounds for an appeal.

I can't disagree because the WG did not reach a decision, the chairs
declared one. There were different interpretations of what people were
voting YES for, therefore there was no decision. The chairs combined YES
get rid of scoping, with YES get rid of ambiguity responses to arrive at
a count. That does not constitute a WG decision.

> 
> In order for us to consider this appeal, you should follow 
> the appeals process outlined in section 6.5.4 of RFC 2026.  
> Your appeal should include a "detailed and specific 
> description of the facts of the dispute".  In particular, you 
> should make it clear exactly what action (or inaction) you 
> are appealing.

>> You must void the declaration of consensus, and should 
>> recognize that the original question was not clear.

The question asked was:
Should we deprecate IPv6 site-local unicast addressing?

The answers indicated that some interpreted that as deprecation of
address scoping, while others interpreted it as remove the ambiguity
associated with the current definition of the FEC0::/10 prefix. Those
are technically different issues and require separate questions, yet the
chairs combined the disparate YES votes for each perspective into their
own interpretation of what the original question meant. This is not WG
consensus.

> 
> You must also indicate what grounds you have for appealing 
> that action (or inaction).  There are two possible grounds 
> for appeal of a WG action, listed in RFC 2026, section 6.5.1:
> 

The working group was mislead by an ambiguous question from the chairs,
and has not reached a consensus on anything other than more work needs
to be done. Some of the YES votes were for removal of scopes from the
architecture, and others were for removing ambiguous addresses as SL is
currently defined. Those are technically different concepts requiring
different questions. The declaration of consensus by the chairs
indicates an incorrect technical choice which places the integrity of
the WG product in significant jeopardy.

> 
> It might also be possible to raise a process appeal if you 
> believe that the chairs violated the process for session 
> management described in section 3.3 of RFC 2418.

Well since you brought it up, the agenda listed Limited Usage, and
Moderate Usage as the topics of discussion. Then (someone that was there
should verify this, but I have been told that) your presentation listed:
Full
Moderate
Exclusive
Limited
No SLs
and you started the presentation by saying that the first one and the
last one were not under consideration. Later you call an ambiguous
question attempting to accomplish the last one. Is that proper session
management? If people are led to believe a topic will not be discussed,
they are less likely to come prepared to discuss it, or stick around to
make sure their views are heard during a discussion. I can only
question, maybe others that were there will appeal based on
mismanagement.

> 
> Please explicitly state what you are appealing and explain 
> your grounds for appeal.  You should also supply any 
> information necessary to explain and support your position.  
> Once we have this information, we will carefully consider 
> your appeal and provide a written reply.

I believe I did this in the original note to Thomas & Erik, which was
included in the subsequent note of appeal to the chairs. I am appealing
the declaration of consensus based on an ambiguous question, where some
responses indicate remove addresses with local scope while others
indicate remove ambiguity of the address range. 

> 
> We understand that your appeal is motivated by your desire to 
> do the right thing for IPv6, and we will make every attempt 
> to deal with it fairly and promptly.

From my reading, this response does not indicate a desire for
promptness. 

Tony

> > > Please consider this the second step in the appeal process, as I 
> > > have already discussed these issues with the chairs on 
> more than one 
> > > occasion.
> > >
> indicative 
> > > of the real lack of it (60/40%), than what was effectively ballot 
> > > stuffing by WG visitors without a complete context. There 
> was a very 
> > > short presentation in the apps open area, intended to 
> raise concerns 
> > > and incite involvement, were those in the apps area were 
> agitated, 
> > > then invited to the IPv6 WG session in SF to discuss the 
> potential 
> > > issues. The subsequent short discussion in the IPv6 WG 
> showed there 
> > > were issues to work through, and at least one question voiced
> > > While the chairs do in 2) recognize their interpretation of the 
> > > consensus that the WG will investigate other forms of local 
> > > addressing, there is no mention of ambiguity and the rest of the 
> > > wording of 1) & 2) can be interpreted as local scope 
> addressing is 
> > > deprecated. The concern is that we will end up with a document 
> > > lacking local scope addressing, and claims that we had 
> consensus to 
> > > remove local scope from the architecture. Many of those 
> who bothered 
> > > to state why they were expressing a yes opinion claimed ambiguity 
> > > was the reason, while others were only interested in removing 
> > > special handling for local scope addresses. Those are technically
> > > '... we believe in rough consensus & running code' & from 
> the Tao : 
> > > 'running code wins' On several related mail threads there 
> were many 
> > > comments about running code, and at least Brian Zill & Brian 
> > > Haberman said they collectively had host, application, and router 
> > > implementations of the current SL running. Point 3) even 
> > > acknowledges there are existing implementations. This 
> consensus call 
> > > intends to invalidate the running code, and all we have 
> to replace 
> > > it is a promise in 4) that if the group can ever agree that 
> > > operational requirements of the site network manager are worth 
> > > solving, we might start to work on solutions, subject to 
> appropriate
> > > There were also claims in the meeting and mail threads 
> that we have 
> > > analyzed site local as currently defined, and it doesn't meet the 
> > > requirements. At the same time, there is a recognition by many of 
> > > the same people that we need to develop a complete set of 
> > > requirements. It should be obvious that the analysis is flawed if 
> > > the complete set of requirements are not understood 
> first. To that 
> > > end, and in the spirit of making progress,
> > > 'deprecate site local addresses' means, I do believe that 
> a set of 
> > > work items for the group were identified. It is also 
> clear that we 
> > > can add new work to a group at any time, without the need 
> to remove 
> > > existing items first. I agree with the chairs that items 
> 4) & 5) are 
> > > valid outcomes of the subsequent discussion, though one 
> thing that 
> > > their interpretation of the result does not make clear is the
> > > In short, I do not believe the consensus call measured 
> the opinions 
> > > that were consistent the chairs interpretation of the 
> question, so 
> > > the claimed results are invalid. I do believe that the effort 
> > > identified work items 4) & 5), with the potential that 1) 
> & 3) might 
> > > follow if there are no outstanding requirements for ambiguous 
> > > address space. I question the wisdom of 2), but will reserve 
> > > judgment until the complete text identifying further work 
> is spelled 
> > > out. In any case, I hope this appeal can be dealt with at this 
> > > level, and that the overall effort results in an expedited charter