Delivery-Date: Wed Jul  9 09:05:08 2003
Message-Id: <200307091300.h69D0Zq10846@cichlid.adsl.duke.edu>
To: "Tony Hain" <alh-ietf@tndh.net>
cc: ipng@sunroof.eng.sun.com
Subject: AD response to Site-Local Appeal
Date: Wed, 09 Jul 2003 09:00:35 -0400
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

[Note that this message is very long because it includes the cited
email messages verbatim; we are not aware of an IPv6 WG mailing list
archive that provide URL references for individual emails.]

Tony,

We have reviewed your appeal of the IPv6 WG chairs calling of
consensus to deprecate site-local addresses from the IPv6
architecture. We believe they have acted properly, and indeed, have
done an admirable job of moving the WG forward on a complex, subtle
and divisive topic that has troubled the WG and the IETF as a whole
for a long time. We find that the chairs have responded reasonably and
appropriately to your appeal and agree with their response. Based on
our review, we reject your appeal in its entirety.

Some specifics:

Your appeal seems to center around the point that different people had
different reasons for responding to the question of whether or not to
deprecate SLs and that those reasons were different enough that it
isn't appropriate to use those differing reasons to conclude a single
outcome, namely to deprecate SLs.

We disagree. The question asked by the chairs was not about the
differing reasons, the question was specifically about SLs, and
whether the WG wanted to deprecate them. That the question referred
specifically to deprecating site locals (and not the reasons why one
might do so) is obvious.  It is common in the IETF when deciding
technical issues for different people to have different reasons for
coming to a particular conclusion, or to weigh tradeoffs
differently. In the end, if there is consensus on the answer to a
specific question, we have consensus, even if the reasons for reaching
a particular outcome are not shared.

In your response to the chairs [8],

"Tony Hain" <alh-ietf@tndh.net> writes:

> Margaret Wasserman wrote:
> >    (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.

> I was not objecting to 'different reasons'. The specific complaint is
> that many of YES votes were for removing the architectural construct, or
> need for applications to deal with addresses that are only accessable
> over a limited scope. That is not in the purview of the IETF to decide,
> it is an operational decision of the network manager. Those votes are
> not valid as a result.

It is certainly within the purview of a WG (and/or IETF) to decide
what it wants to work on.  Given that the IETF defined a designated
site-local prefix in RFC 1884 it can also choose to undo that
definition.  This doesn't remove the ability for network managers to
do filtering, or remove their ability to allocate address ranges for
any particular purpose including "local use".  Moreover, if the WG
does not want to work on defining a model that requires applications
to deal with "addresses that are only accessible over a limited
scope", it can certainly make such a choice.

We also note that you seem to have a broader definition of "scoping"
(and the requirements that must be met by the architecture to support
such scoping) than many, and you appear to be choosing to view the
decision to deprecate SLs as an attempt to outlaw (or eliminate) all
forms of such scoping, including the ability of site operators to
filter on arbitrary addresses (which you seem to include in your
definition). This view is incorrect. The decision to deprecate SLs is
just that. It is not a decision to outlaw all forms of scoping or to
forbid operators from (say) filtering packets based on addresses.

> > 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.

> You said it multiple times in SF yourself, the WG needs complete
> documentation to do an appropriate analysis. You appear to be letting
> your desire to 'be right' get in the way of your ability to analyze your
> own responses. I don't understand how can you objectively say 'we don't
> need a document describing the need for X to decide that we don't need
> X'?

The key issue is whether the community believes it has enough
information to make a decision and is ready to make a decision. When
complex issues are being discussed it is important that sufficient
information is available and that the issue has been thought
through. In such cases it makes sense to try to get detailed
documentation listing the pros and cons of the choices, e.g., as
internet-drafts, or as part of email discussions. So while the advance
availability of an internet-draft on deprecation would have been good,
what matters in the end is whether the community believes it has
enough information to make a decision.

During the meeting (early on) one person suggested that there wasn't
enough information on which to base a decision. But this claim didn't
appear to resonate with others, either in the meeting or on the
mailing list.  If a large number of WG participants had agreed with
the claim, one would have expected them to speak up. Hence one can
infer that the WG felt that there was sufficient information to make a
decision.

In [6] you say:

> 	>>> There is a vast difference between identifying direction of
> the group and the actual yes/no to deprecate SL question that was asked.
> In fact all other indications from the chairs were that the question was
> NOT about measuring direction of the WG, but actually about their intent
> to have local scoped addresses removed from the scoped address
> architecture and other documents.

The question asked was about a general direction for the WG to go
in. The alternative to "direction" would have been a question about an
existing document (such as an update to the addressing architecture
doc to deprecate SLs) which was clearly not what was being asked.

In summary, the INT ADs 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. We would also
like to point out that while we disagree with your position on this
particular issue, we do recognize the contributions you have made to
the IPv6 effort and we realize that your appeal is motivated by your
desire to do what you believe is the right thing for IPv6.  We hope
that you will accept our response and focus on working to define the
local addressing problem and solutions in the IPv6 WG.  It is
important for the working group to move forward on this issue.

Thomas Narten & Erik Nordmark
Internet Area ADs


References:

[1] Message from chairs to list, announcing results of consensus call.

Return-Path: owner-ipng@sunroof.eng.sun.com
Message-Id: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com>
Date: Wed, 09 Apr 2003 15:11:04 -0700
To: ipng@sunroof.eng.sun.com
From: Bob Hinden & Margaret Wasserman <hinden@iprg.nokia.com>
Subject: Consensus on Site-Local Addressing

Hi All,

Well, that was fun!  :-)

All told, there were over 200 responses to the consensus call on IPv6 
site-local addressing, approximately 3-to-1 in favor of deprecating IPv6 
site-local unicast addressing.  The final count (including the room and the 
mailing list) was:  155 YES, 56 NO (211 Total).

There were also a significant number of the people on both sides of this 
issue that voiced (in their original responses, or in subsequent messages) 
a strong belief that we should investigate alternative mechanisms for local 
addressing and local access control.

The chairs have read all of the messages on the list, and based on your 
considerable input, we have determined that the IPv6 WG does have rough 
consensus to deprecate the usage of IPv6 site-local unicast addressing AND 
to investigate alternative mechanisms for local addressing and local access 
control.

In particular, the IPv6 WG will work to accomplish the following things in 
parallel:

   (1) Publish an informational document that explains the issues
       encountered with site-local addressing and our reasons
       for deprecating IPv6 site-local unicast addresses.  This
       document will officially deprecate site-local addressing.

   (2) Remove site-local unicast addressing from the IPv6
       scoped addressing architecture I-D, and publish the
       parts of the document on which we do have consensus
       (i.e., link local addresses, multicast, etc.).  This
       will include a note that the IPv6 working group is
       investigating other forms of local IPv6 addressing and
       that the usage of any new forms of local addresses will be
       documented elsewhere.

   (3) Update the IPv6 addressing architecture to indicate that the
       usage of the FECO::/10 prefix for site-local addressing is
       deprecated.  To maintain backward compatibility with existing
       implementations the prefix should be reserved and should not
       be allocated for other purposes.

   (4) Define and publish the requirements for a local addressing
       mechanism to provide:
         - Addresses for disconnected networks.
         - Addresses for intermittently connected networks.
         - Addresses that support merging of sites.
         - Stable local addresses for changing ISPs without
           disrupting local communication.
       Once we have consensus on the requirements, the IPv6
       WG will work on solutions for local addressing that
       meet those requirements.

   (5) Define and publish the requirements for a local access
       control mechanism, then work on a solution that meets
       those requirements.

Each of these new work items will need to be added to the IPv6 WG charter 
and will go through the normal IETF document processes.  For (4) and (5) it 
is important to make the rest of the IETF community aware that the IPv6 WG 
is undertaking these tasks, so we will consider methods to invite wider 
review and discussion of these problems.

IPv6 site-local addressing has been a contentious issue in the IPv6 WG for 
some time, and we are both glad to see the WG reach consensus on this 
issue.  This will allow us to complete and publish the IPv6 scoped 
addressing architecture document, an important part of the IPv6 specification.

We hope that people on all sides of this issue will respect the rough 
consensus of the WG, and will work with us to achieve the goals outlined above.

Thanks to everyone who expressed an opinion during this discussion.

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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

[2] First message from Tony Hain appealing decision.

Return-Path: owner-ipng@sunroof.eng.sun.com
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Thomas Narten'" <narten@us.ibm.com>,
   "'Erik Nordmark'" <erik.nordmark@Sun.COM>
Cc: <ipng@sunroof.eng.sun.com>
Subject: FW: Consensus on Site-Local Addressing
Date: Wed, 9 Apr 2003 17:41:32 -0700
Message-Id: <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings>

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


> -----Original Message-----
> From: owner-ipng@sunroof.eng.sun.com 
> [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Bob 
> Hinden & Margaret Wasserman
> Sent: Wednesday, April 09, 2003 3:11 PM
> To: ipng@sunroof.eng.sun.com
> Subject: Consensus on Site-Local Addressing
> 
> 
> Hi All,
> 
> Well, that was fun!  :-)
> 
> All told, there were over 200 responses to the consensus call on IPv6 
> site-local addressing, approximately 3-to-1 in favor of 
> deprecating IPv6 
> site-local unicast addressing.  The final count (including 
> the room and the 
> mailing list) was:  155 YES, 56 NO (211 Total).
> 
> There were also a significant number of the people on both 
> sides of this 
> issue that voiced (in their original responses, or in 
> subsequent messages) 
> a strong belief that we should investigate alternative 
> mechanisms for local 
> addressing and local access control.
> 
> The chairs have read all of the messages on the list, and 
> based on your 
> considerable input, we have determined that the IPv6 WG does 
> have rough 
> consensus to deprecate the usage of IPv6 site-local unicast 
> addressing AND 
> to investigate alternative mechanisms for local addressing 
> and local access 
> control.
> 
> In particular, the IPv6 WG will work to accomplish the 
> following things in 
> parallel:
> 
>    (1) Publish an informational document that explains the issues
>        encountered with site-local addressing and our reasons
>        for deprecating IPv6 site-local unicast addresses.  This
>        document will officially deprecate site-local addressing.
> 
>    (2) Remove site-local unicast addressing from the IPv6
>        scoped addressing architecture I-D, and publish the
>        parts of the document on which we do have consensus
>        (i.e., link local addresses, multicast, etc.).  This
>        will include a note that the IPv6 working group is
>        investigating other forms of local IPv6 addressing and
>        that the usage of any new forms of local addresses will be
>        documented elsewhere.
> 
>    (3) Update the IPv6 addressing architecture to indicate that the
>        usage of the FECO::/10 prefix for site-local addressing is
>        deprecated.  To maintain backward compatibility with existing
>        implementations the prefix should be reserved and should not
>        be allocated for other purposes.
> 
>    (4) Define and publish the requirements for a local addressing
>        mechanism to provide:
>          - Addresses for disconnected networks.
>          - Addresses for intermittently connected networks.
>          - Addresses that support merging of sites.
>          - Stable local addresses for changing ISPs without
>            disrupting local communication.
>        Once we have consensus on the requirements, the IPv6
>        WG will work on solutions for local addressing that
>        meet those requirements.
> 
>    (5) Define and publish the requirements for a local access
>        control mechanism, then work on a solution that meets
>        those requirements.
> 
> Each of these new work items will need to be added to the 
> IPv6 WG charter 
> and will go through the normal IETF document processes.  For 
> (4) and (5) it 
> is important to make the rest of the IETF community aware 
> that the IPv6 WG 
> is undertaking these tasks, so we will consider methods to 
> invite wider 
> review and discussion of these problems.
> 
> IPv6 site-local addressing has been a contentious issue in 
> the IPv6 WG for 
> some time, and we are both glad to see the WG reach consensus on this 
> issue.  This will allow us to complete and publish the IPv6 scoped 
> addressing architecture document, an important part of the 
> IPv6 specification.
> 
> We hope that people on all sides of this issue will respect the rough 
> consensus of the WG, and will work with us to achieve the 
> goals outlined above.
> 
> Thanks to everyone who expressed an opinion during this discussion.
> 
> 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 majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
> 


--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------


[3] Note from Tony Hain indicating he will followup with chairs first.


Return-Path: owner-ipng@sunroof.eng.sun.com
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Thomas Narten'" <narten@us.ibm.com>
Cc: "'Erik Nordmark'" <erik.nordmark@Sun.COM>, <ipng@sunroof.eng.sun.com>
Subject: RE: FW: Consensus on Site-Local Addressing 
Date: Thu, 10 Apr 2003 10:04:41 -0700
Message-Id: <0f9101c2ff83$46f11ac0$ee1a4104@eagleswings>

Thomas Narten wrote:
> 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.
> 
> Discussing general issues with the chairs is not the same as 
> finding disagreement with a specific action that the chairs 
> have taken. I suspect you have done the former, but not the 
> latter. If you feel that the chairs have erred, and that they 
> have taken an action that isn't supported by the processes as 
> outlined in RFC 2026 (and RFC 2418), an appeal might be 
> warranted. To file an appeal, the process is outlined in RFC 
> 2026. Start with the chairs, use RFC 2026/2418 as a guide for 
> what are appropriate grounds for an appeal, and be clear 
> about what action (or inaction) you specifically have issue 
> with and want reconsidered. Suggesting what remedy you 
> believe is appropriate would also be useful.

Well I did specifically discuss a disagreement with the action of the
chairs in calling the ambiguous question, but I will accept this
deferral and redirect the current appeal comment to the chairs. 

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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------


[4] Note from chairs to Tony Hain requesting clarification

Message-Id: <5.1.0.14.2.20030411094553.040e3040@mail.windriver.com>
Date: Fri, 11 Apr 2003 10:16:09 -0400
To: Tony Hain <tony@tndh.net>
From: Margaret Wasserman <mrw@windriver.com>
Subject: Your Appeal Regarding Site-Local Deprecation (Was: Consensus
  on Site-Local Addressing)
Cc: Bob Hinden <hinden@iprg.nokia.com>, Thomas Narten <narten@us.ibm.com>,
   Erik Nordmark <Erik.Nordmark@Sun.COM>, ipng@sunroof.eng.sun.com


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: <alh-ietf@tndh.net>
>From: "Tony Hain" <alh-ietf@tndh.net>
>To: "'Bob Hinden'" <hinden@iprg.nokia.com>,
>         "'Margaret Wasserman'" <mrw@windriver.com>
>Cc: <ipng@sunroof.eng.sun.com>
>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: owner-ipng@sunroof.eng.sun.com
>
>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: owner-ipng@sunroof.eng.sun.com
> > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tony Hain
> > Sent: Wednesday, April 09, 2003 5:42 PM
> > To: 'Thomas Narten'; 'Erik Nordmark'
> > Cc: ipng@sunroof.eng.sun.com
> > 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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

[5] Note from Tony Hain clarifying his appeal.

From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Margaret Wasserman'" <mrw@windriver.com>, "'Tony Hain'" <tony@tndh.net>
Cc: "'Bob Hinden'" <hinden@iprg.nokia.com>,
   "'Thomas Narten'" <narten@us.ibm.com>,
   "'Erik Nordmark'" <Erik.Nordmark@Sun.COM>, <ipng@sunroof.eng.sun.com>
Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus  on Site-Local Addressing)
Date: Fri, 11 Apr 2003 10:07:44 -0700
Message-Id: <106f01c3004c$deceb8b0$ee1a4104@eagleswings>

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:
> 
>         (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.

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

> 
> Bob Hinden & Margaret Wasserman
> IPv6 WG Chairs
> 
> 
> >Reply-To: <alh-ietf@tndh.net>
> >From: "Tony Hain" <alh-ietf@tndh.net>
> >To: "'Bob Hinden'" <hinden@iprg.nokia.com>,
> >         "'Margaret Wasserman'" <mrw@windriver.com>
> >Cc: <ipng@sunroof.eng.sun.com>
> >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: owner-ipng@sunroof.eng.sun.com
> >
> >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: owner-ipng@sunroof.eng.sun.com 
> > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tony Hain
> > > Sent: Wednesday, April 09, 2003 5:42 PM
> > > To: 'Thomas Narten'; 'Erik Nordmark'
> > > Cc: ipng@sunroof.eng.sun.com
> > > 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 majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
> 


--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

[6] More followup/clarification from Tony Hain 

From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Bob Hinden'" <hinden@iprg.nokia.com>,
   "'Margaret Wasserman'" <mrw@windriver.com>
Cc: <ipng@sunroof.eng.sun.com>
Subject: Appeal clarification ...
Date: Thu, 24 Apr 2003 22:45:30 -0700
Message-Id: <047f01c30aed$e1f8ed20$261e4104@eagleswings>

Everyone should check out the video at:
ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56 - 03202003
- INT ipv6.mpg  ... Starting at 1:02:05. It is very instructional about
how not to call a question. The claimed consensus was over (and I quote
from the AD & chair 2:18:20) 'just to be clear, deprecate I assume means
...' ... '...we may have to handwave - wave our hands around that a
little bit...'. 

In further discussion with the chairs, the appeal issue is still not
clear. This note attempts to make it clearer, and adds documentation
from the video of the SF session. 

Appeal:
The chairs have asserted an incorrect technical choice which places the
quality and/or integrity of the Working Group's products in significant
jeopardy.

The working group did not make a decision as some of the YES votes were
for removal of local scopes from the architecture, some for removal of
the need for apps to recognize that local scopes exist, others were for
removing ambiguous addresses as SL is currently defined, and others were
for removing the threat of NAT. Those are technically different
architectural concepts requiring different questions. In particular,
local scope addresses are the result of an operational choice, and not
in the purview of the IETF to decide. The IETF can decide to set aside a
well known prefix for that use or not, but removing the well-known
prefix does not mean local scope addresses go away, or that applications
are exempted from handling them correctly. It only means that there is
no consistent way to identify which addresses are local use. 

There is no document identifying the requirements and needs of the
network operators, therefore no reasonable and complete evaluation could
result in the conclusion that deprecation is an appropriate action. The
chairs chose to ask an ambiguous question that the group clearly had
different opinions about the meaning of, and shortly before the initial
question was called there was an explicit statement about lack of
clarity in the consequences of the alternatives. Forcing a YES/NO
question for an end state rather than a process, without a widespread
understanding of the consequences and trade-offs, was an inappropriate
action by the chairs. 

The working group was mislead by an ambiguous question from the chairs.
The asserted conclusion is invalid as the WG has not reached consensus
on anything other than more work needs to be done. 


Background:
The entire open discussion in SF started off misled by a bogus technical
assertion by the chair: 
1:42:04 ... it is always going to be possible to implement wrong unless
we get rid of whole concept of private addresses ... you will always
have the possibility ... for leaking addresses if they exist in the
architecture
	>>> Existence in the address architecture is not what creates
the possibility for limited scope addresses to be leaked, that only
allows identification of them. The thing the creates the possibility for
leaking limited scope addresses outside their realm of applicability is
the ignorance by the applications that the real network has limited
scope addresses and they require appropriate handling. Removing any tag
for the application to identify which addresses have limited scope only
ensures that they will be leaked.


There was no enumeration of the requirements for any solution, therefore
no reasonable and complete evaluation that the current SL is inadequate.

1:06:49 MW - you can only document the cost/benefit analysis of a point
that's understood

1:36:30 - 'Do we have enough information to decide' 
	>>> on slide but not discussed
	>>> discussion about overriding need to reach consensus

1:39:00 - Pekka - Exclusive is just broken ... if we want ...  
	>>> indicates need to understand requirements

	without further analysis, that requirement is met by access
prefix thing
	access prefix is less intrusive and easier to implement
	>>> where is the analysis that backs that up?

1:41:42 - Alain -  ... if we want to avoid leaking  ...
	>>> indicates need to understand requirements

1:50:05 - Erik - we don't have enough information to decide yet, and
part of what I am looking for is so what are the benefits of these
things anyhow
	>>> indicates need to understand requirements

1:52:33 - look at benefits before we try to decide something 
	- MW 'anything we are doing here should be a cost/benefit
tradeoff ... maybe we'll decide we need more information ... we need to
do an intelligent cost/benefit analysis and have a supportable reason
for our choice

1:58:00 Leif - Erik's comments were first time I heard purported
benefits - applications shouldn't have to worry about topology that's a
fundamental comparing the benefits with breaking fundamental assumption
that apps shouldn't care about topology - its clear that you should
eliminate SL
	>>> an informed conclusion after 5 1/2 minutes evaluation of a
partial verbal list of requirements ??? How many others were in the same
place?

2:11:39 Dave - I agree with Keith's attempt to clarify the wording of
the question people are arguing for the eliminate proposal which there
isn't any draft about ...


In fact over the meeting it was clear that there was no common
understanding about what 'deprecate' means even by the chairs, and this
carried onto the list discussion: 

2:09:24 MW - that would be eliminating it, you can always bring
something back later someone can have a research group, but if take it
out of the specs, ** that is what eliminating it means **
2:09:35 Keith - alternate proposal for a way forward - I don't believe
the bit patterns that are defined for SL will be allocated for some
other use so I don't think we are eliminating them entirely, but I want
to know if we can get a sense of the group that discouraging use of SL
is the appropriate way to move forward - part 1   part 2 - identify the
things that SL was supposed to solve and work out alternate solutions
for those 
2:10:20 MW - instead of eliminate I think the right word would be
deprecate because I agree that we are not going to suddenly decide to
use those bits for something else - I agree with you on that but
discouraging  ** is that deprecating? ** 
2:10:35 Keith - deprecating in a sense, it also leaves the idea that
until we find something else, you might have some usage of SL but the
plan is in the future to deprecate it

2:11:39 Dave - I agree with Keith's attempt to clarify the wording of
the question people are arguing for the eliminate proposal which there
isn't any draft about - this is a question to you to clarify the
question - Erik made and Dino added - zero conf asked what do routers do
- do we want to enable a zero config thing - if so do you want to enable
SL in a deprecated sense as Keith put it, for that or is the proposal to
eliminate them and force zero config guys to not work because we don't
care about that, or to force them to use some other well known prefix
clarify which one of those is actually the proposal ?
	>>> questions never answered or even discussed

2:12:51 Christian - if we say that we are going to eliminate SL we have
to actually eliminate it and ** that means ** that we have to make it
explicit that at some point in the future all implementations are
supposed to discard any packets sent to the specific prefix 

2:13:19 MW - I'll resay what I said earlier which is I had said we would
say eliminate it or keep it and then we'd have multiple choices if we
kept it but apparently ** if we eliminate it we will also have multiple
choices about what exactly that means **
	>>> 'multiple choices' how does that indicate a clear meaning
???

2:13:31 Erik - I think there area some details about what it means if we
actually choose to eliminate ** I think that means ** that people at
their leisure can go ahead and delete whatever code they have that
currently recognizes FEC0 but they don't have to do it tomorrow, because
we are not going to allocate this for any other purpose in the near
future, but it means that you don't have to add any more code, but you
can at your leisure delete what you have

2:14:05 Brian - I got up to say that the question that you were going to
ask is one that ** I would have difficulty answering because I wouldn't
vote for keeping SL unless I knew which of the options we were going to
go for **
	>>> though voting against without understanding the consequences
didn't appear to be a problem

2:16:09 Bound - IPv4 NAT is a national security problem, at least in the
US so ** what I am hearing to day is we should stop it and not give any
credence to help proliferate them ** 
	>>> a belief that removing SL removes the threat of NAT ???

2:16:45 Keith - ... ** the real trick is ** that applications shouldn't
have to special case these things, Dns shouldn't have to special case
them, routing shouldn't; have to special case these things 
	>>> in other words applications continue to ignore the reality
of limited scope addresses, because without a well-known tag it is
impossible to special case them

2:18:20 Thomas, just to be clear, ** deprecate I assume means **
somewhere to the left of the limited use model 
	- MW Yes, somewhere to the left of limited, the bits would
somehow become deprecated but probably you wouldn't get to reuse them
and we would not want to invalidate existing implementations so we may
have to wave our hands around that a little bit to make sure we do it
right - Bob, Christian just added - and probably needed to be blackholed
	>>> 'somewhere to the left'; 'somehow be deprecated'; & '...may
have to hand wave...' those are not clear indications of the meaning of
the question or consequences of this action.

4/2 JB - Ambiguous addresses are a nightmare...
	>>> a common theme

4/5 MW - The proposal is to deprecate a prefix in the addressing
architecture for which we have found no suitable use.
	>>> Translation - we refuse to acknowledge the uses in shipping
code, though we do acknowledge that there is shipping code which uses
them.

4/5 DL - I thought we were voting on something more meaningful, i.e.,
site-locals  themselves.  Now I understand that site-locals do not exist
as such and we were just voting on the deprecation of the prefix itself.

4/7 AW - I have come to the conclusion that the consensus call email on
the list failed to adequately  describe what a YES for deprecation
actually entailed, and has pretty effectively shot itself in the foot.

4/4 HA - Note: By "Deprecate Site-Local", ** I mean ** "Do not require
any application, host, router, protocol or IETF practice to have to make
special 
consideration for the idea that an IPv6 unicast address outside of the 
link-local range can refer to two different hosts".

4/4 PF - So, when I say I want Site Local deprecated ** I mean ** I want
routing and addressing separated, and given that separation, we have to
work on 
solving the real problems we have with Internet today


While there was no single clear statement about what deprecate means
(though many architecturally different assertions), there was a clear
overriding concern by the chairs that some conclusion be reached, even a
bad one:
2:07:43 Erik - call for comments for SL     Bob - give us a second here
MW - if we are going reach any conclusion we can't accept a sudden
influx at mic 
2:08:45 Bob - if you want to support SL independent of usage model come
to the mic 2:15:22 Bob by the way... MW cut off> we have to cut off
discussion with the people who are at the mic because we have to try to
have some conclusion
	>>> where was the fire? If the question had not been called in
SF, would the world have ended? Allowing 7 1/2 minutes for rebuttal
comments to a discussion that was not on the agenda, there were no
documents published, and people did not come to the meeting prepared to
discuss is inappropriate in any case. Cutting off discussion just as
people were getting their thoughts together to form reasonable
statements about requirements is improper meeting management and biases
any attempt to measure consensus.


Despite the lack of agreement about exactly what deprecate means, there
was a comment: 
2:17:19 MW - lets see, just a sec ... we are going to call a question
and the question is going to be a yes no question do we want to
deprecate SL addresses or do we not want to deprecate SL addresses - we
realize that both of those answers no matter which answer you give there
is more details that need to be worked out, but we are trying to get
what is the direction, does the group want to go away from SL
addressing, deprecate it work out how to get it out, does the group want
to keep it and figure out what the right usage model is for it OK, this
is a usage model issue. its is like do we want to support usage of SL
and come up with a usage model for it, or do we want to deprecate it

which was not made to the mail list consensus call. 

	>>> There is a vast difference between identifying direction of
the group and the actual yes/no to deprecate SL question that was asked.
In fact all other indications from the chairs were that the question was
NOT about measuring direction of the WG, but actually about their intent
to have local scoped addresses removed from the scoped address
architecture and other documents.

	>>> This drive for a decision despite multiple statements (by
the chairs no less), that a cost/benefit analysis can only be done with
a complete set of requirements. Where is the supportable reason for the
asserted choice to change the architecture? For that matter, where is
the requirements document that a supportable reason would be built from?


In preparing the question, it should have been clear that the chairs
were not thinking this though clearly: 
2:18:57 Perry when you say it is a yes or no question, therefore it must
be phrased differently than do we wish to deprecate them or do we not
wish to deprecate them 
- MW I am tired, did I actually say that?

Yet seconds later:
2:19:20 MW Question - show of hands, how many people think that we
should deprecate SL addressing?


Keith's wording at 2:09:35 would have been an appropriate pair of
questions for the chairs to ask (I acutally support part 2), but the
chairs chose to ask an ambiguous question that the group (and even the
chairs) clearly had different and inconsistent opinions about the
meaning of. Shortly before the question was called there was an explicit
statement about lack of clarity about the consequences of the
alternatives. The fact that many of the YES responses were about removal
of local scope addresses invalidates the asserted conclusion. The
existence of limited scope addresses are an architectural consequence of
operational choices, and not in the purview of the IETF to decide. 

Tony


PS: 2:14:05 Brian ... I also a comment that RFC 1597 is one of the worst
end runs in the history of the IETF. 
	>>> I am arguing that through an ambiguous question this
desperate drive for a conclusion which intends to remove local scope
addresses from the architecture superseded it.


--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

[7] Chairs formal response to Tony Hain's appeal

Message-Id: <5.1.0.14.2.20030428165715.046a3888@mail.windriver.com>
Date: Mon, 28 Apr 2003 17:02:02 -0400
To: Tony Hain <tony@tndh.net>
From: Margaret Wasserman <mrw@windriver.com>
Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was:
  Consensus  on Site-Local Addressing)
Cc: ipng@sunroof.eng.sun.com, Thomas Narten <narten@us.ibm.com>,
   Erik Nordmark <Erik.Nordmark@Sun.COM>, Bob Hinden <hinden@iprg.nokia.com>

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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

[8] Tony Hain's reaction to the response from chairs.

From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Margaret Wasserman'" <mrw@windriver.com>,
   "'Bob Hinden'" <hinden@iprg.nokia.com>
Cc: <ipng@sunroof.eng.sun.com>, "'Thomas Narten'" <narten@us.ibm.com>,
   "'Erik Nordmark'" <Erik.Nordmark@Sun.COM>
Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was:  Consensus  on Site-Local Addressing)
Date: Mon, 28 Apr 2003 18:38:26 -0700
Message-ID: <066f01c30df0$07ae4740$261e4104@eagleswings>

Margaret Wasserman wrote:
>    (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.

I was not objecting to 'different reasons'. The specific complaint is
that many of YES votes were for removing the architectural construct, or
need for applications to deal with addresses that are only accessable
over a limited scope. That is not in the purview of the IETF to decide,
it is an operational decision of the network manager. Those votes are
not valid as a result. 


> 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. 

By asking an ambiguous question, it is easy to insert your
interpretation as the collective consensus. How convenient. 
SF question --
... how many people think that we should deprecate SL addressing? 
Mail list question --
Should we deprecate IPv6 site-local unicast addressing? 

Neither of those mention 'usage'. In fact if you watch the video of SF,
you will find that you spent much more time talking about elimination
than anything else.

> 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.

There was no decision. You had an inconclusive discussion with Keith,
then later a vague discussion with Thomas about a 'hand wave'. Neither
of those even come close to a decision, let alone a WG decision. Are we
supposed to just say YES to any ambiguous question you ask, so you can
make up the content of the consensus later?

> 
> 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.  

While you may believe that the disagreement over SL was delaying the
work, most of those disagreements stemmed from a lack of agreement over
the fundamental requirements. Removing SL does not solve the basic
problems that need to be addressed in the scoped addressing
architecture.

> The 
> consensus to deprecate site-local addressing will allow us to 
> move forward and complete our work.

No it won't. A scoped address architecture document that ignores the
reality of addresses that are only reachable within a limited part of
the network is incomplete on its major point. It is absolutely useless
to pretend that we have a document that discusses a scoped architecture
when the case for the majority of nodes in the Internet is missing.

> 
> ---
> 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.  

Clearly you didn't watch the video of the SF meeting. Why would Thomas,
Keith, Dave, and Christian make a specific point of trying to clarify
the question if it was clear to begin with? Since the question didn't
change, it remained just as unclear as it started, and none of the
'somewhere to the left' & 'hand wave' comments were sent to the list.

> 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.

I disagree. Many of the responses indicated what they meant by saying
yes, which is not the same as understanding the question. In fact, their
need to explain what question they were answering is an implicit
statement of lack of clarity in 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.

Why would there be? They all have their own interpretations, so there
won't be objections until the actual next steps begin. 

> 
> ---
> 
> 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.

You missed the point that many of those responses are for an
architectural change that is not in the IETF's purview to decide. See
above.

> 
> All of the groups that you mentioned in your message agreed 
> that IPv6 site-local unicast addressing should be deprecated. 

No, some of them believed this is about removing local scoped addresses
from the architecture, or consideration by applications. That is not the
same as 'usage' of a defined prefix.

> They may disagree on what we should do after deprecating 
> site- local addressing, but that does not invalidate the 
> consensus on this point.

There is a vast and architectural difference between removing addresses
which are only reachable over a limited part of the network, and usage
of a specific prefix to identify those.  You keep claiming there is a
consensus, but any objective observer of the SF video would disagree.

> 
> ---
> 
> 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.

You said it multiple times in SF yourself, the WG needs complete
documentation to do an appropriate analysis. You appear to be letting
your desire to 'be right' get in the way of your ability to analyze your
own responses. I don't understand how can you objectively say 'we don't
need a document describing the need for X to decide that we don't need
X'?

> 
> 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.

There have been personal drafts. The WG has not taken this on as a
specific work item. 

> 
> 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.

They have been discussed on the mail list to the point that people stop
paying attention. This argument is disingenuous because there has never
been a WG item about creating this document. In addition, I have offered
a draft on the subject multiple times in the last month, yet have not
even received as much as a simple 'no thanks' from the chairs.

> 
> 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.

Most of those difficulties will persist, because they are the result of
inconsistent views of the network topology. There is nothing about
deprecating SL that will change this. The only affect will be to make it
harder to figure out when the burdens exist.

> 
> 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.

I am pointing out that their 'reason' is not in the purview of the IETF
to decide, so their YES votes are not informed or valid. I am not
objecting to their opinion, just the chair's interpretation of consensus
is in error because it fails to discount the votes for an architectural
point that is out of the IETF's control. 

> 
> 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.

Even though a long-term member of the WG said right before the question
that he did not have enough information to vote NO ...  and another
participant stated he had never heard the requirements before Erik gave
a verbal partial list. How do these create 'an informed decision'?

> 
> ---
> 
> 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.

I am not surprised. 

> 
> 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.

I will be escalating to Erik & Thomas, because I do believe that is the
right and expeditious thing to do in this case. 

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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

[9] Tony Hain's appeal to the INT ADs.

From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Thomas Narten'" <narten@us.ibm.com>,
   "'Erik Nordmark'" <Erik.Nordmark@Sun.COM>
Cc: <ipng@sunroof.eng.sun.com>, "'Bob Hinden'" <hinden@iprg.nokia.com>,
   "'Margaret Wasserman'" <mrw@windriver.com>
Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was:  Consensus  on Site-Local Addressing)
Date: Mon, 28 Apr 2003 18:43:47 -0700
Message-ID: <067001c30df0$c7ae0ad0$261e4104@eagleswings>

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 majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
> 


--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------