[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: AD response to Site-Local Appeal
IESG,
Unfortunately it is necessary to bring this appeal to the IESG as the chairs
& chartering AD's have not taken the ample opportunity to recognize the
seriousness of the problem of allowing a chair to ask an ambiguous question,
then decide what it means after the fact.
As the video of the SF meeting
ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56 - 03202003 -
INT ipv6.mpg (989MB)
clearly shows, the overriding goal was declaring consensus, not on actually
recognizing or achieving it. From comments on the mail list, the chair
appears to have had a personal mission of getting SL removed from the scoped
architecture document and progressing it without discussion of the one scope
most widely deployed in the IPv4 network. This oversight will result in a
serious degradation of the quality of the WG output. There was and still is
no consensus in the WG about what 'deprecate site-local' means, just a
declaration by the chair that consensus occurred.
During the SF meeting multiple current & former IESG & IAB members felt the
need to get clarity about the question being asked, and there was an
explicit unanswered request by Dave Thaler asking for an indication what
action implementations should take if elimination was selected. The best the
chair offered was the response at 2:13:19 "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". In other words,
the chair acknowledged the ambiguity of the question, but persisted in
calling it despite the lack of anyone in the room to make an informed
decision about the outcome of their choice. The question asked to the list
was no clearer.
The declaration of consensus must be overturned as an abuse of the process.
This should be done soon as the whole event has created a state of confusion
where network managers are questioning how they are supposed to deploy IPv6
without locally controlled address space. The subsequent discussion on the
mail list identified multiple work items, which the WG should or is already
undertaking, and those can be accomplished without the chairs calling
further questions on the topic. In particular, a document identifying the
requirements for local use address space is underway. Until the WG agrees on
the requirements, there is no possibility for the group to evaluate the
utility of the current SL or other approaches.
Tony Hain
----
While waiting for the 989MB to download, jump to 24 Apr message below which
contains excerpts from the SF video which highlight the confusion over the
meaning of the question being asked.
> -----Original Message-----
> From: Tony Hain [mailto:alh-ietf@tndh.net]
> Sent: Wednesday, July 16, 2003 8:07 AM
> To: 'Thomas Narten'
> Cc: 'ipng@sunroof.eng.sun.com'
> Subject: RE: AD response to Site-Local Appeal
>
>
> inline -
>
> > -----Original Message-----
> > From: owner-ipng@sunroof.eng.sun.com
> > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Thomas Narten
> > Sent: Wednesday, July 09, 2003 6:01 AM
> > To: Tony Hain
> > Cc: ipng@sunroof.eng.sun.com
> > Subject: AD response to Site-Local Appeal
> >
> >
> > [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.
>
> As I expected. I agree the chairs have moved the WG, but
> 'forward' is not the direction.
>
> >
> > 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.
>
> Unfortunately this is a misinterpretation of my point. It is
> not focused on 'different people had different reasons',
> because we agree there will always be different perspectives
> and opinions. The focus was that a significant number of
> participants had the specific reason 'remove limited
> scoping', and this is not something the IETF gets to decide.
> It is an operational issue, and network managers will build
> networks where addresses have limited routing scope.
>
> >
> > 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.
>
> This response highlights the point that not even you know
> what the meaning of the question was. If the group had been
> asked explicitly about removing limited scope, I agree the
> group gets to decide that. If the group had been explicitly
> asked about removing ambiguity from the addresses used for
> local scope, I agree the group gets to decide that. What the
> group was asked was;
> - Should we deprecate IPv6 site-local unicast addressing?
> -
> - Valid responses are:
> -
> - "YES -- Deprecate site-local unicast addressing".
> - "NO -- Do not deprecate site-local unicast addressing".
> with the additional 'guidance' from the chair for those in
> the room in San Francisco that '... if we eliminate it we
> will also have multiple choices about what exactly that means
> ...' & '... may have to handwave ...'. It was only after the
> fact that the chairs started providing interpretations as to
> what the question might mean.
>
> >
> > 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.
>
> I am only reflecting the viewpoints of some votes for
> deprecation. Those votes are the invalid ones, and must be removed.
>
> >
> > > > 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.
>
> The key issue is the claim that we know that SL does not meet
> the requirements, yet there is no document identifying the
> requirements. The community could not make a collective
> informed decision since there was no common understanding of
> the requirements, or understanding of the outcome of the 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.
>
> Or that since the question was ambiguous, they had
> independent expectations of the outcome.
>
> >
> > 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.
>
> You are correct that the ambiguous question did not ask about
> updates to specific documents. On the otherhand the chairs
> summary outcome to the mail list (your reference [1])
> explicitly lists documents to be modified.
>
>
> >
> > 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.
>
> It is important to move forward, but throwing something out
> without understanding the real requirements for its
> existence, or having a replacement is a step backward.
> Although that is not the point here. The point is that the
> chairs asked an ambiguous question, a significant number of
> yes voters expressed opinions to remove limited scoping from
> the architecture, and that opinion is not something the IETF
> gets to decide. This invalidates the call for concensus.
>
> It is unfortunate but not surprising that this could not be
> resolved at this level.
>
> Tony
>
> >
> > 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
> > --------------------------------------------------------------------
> >
>