Skip to main content

Appeal to the IAB on the site-local issue (Tony Hain) - 2003-10-09
Response - 2003-11-12

IAB Response to IPv6 Site-Local Appea

Followup from Tony Hain

Report to the IETF

November 12, 2003

IAB Response to Appeal from Tony Hain

On October 9, 2003, the IAB received an appeal against the IESG decision regarding the IPv6 Working Group chairs’ declaration of consensus on the issue of site local addresses in the IPv6 address architecture (Attachment A).

  1. The Appeal Question

The IAB interpreted this appeal to be as follows:

The appeal is that the IESG, in upholding the IPv6 Working Group chairs’ and Internet Area ADs’ decisions relating to the declaration of consensus on the issue of deprecation of site local addresses in the IPv6 address architecture, made an incorrect decision.

  1. The Basis of the Appeal

The appeal is using the process described in Section 6.5.2 of the “Internet Standards Process” (RFC 2026), namely:

Should the complainant not be satisfied with the outcome of the IESG review, an appeal may be lodged to the IAB. The IAB shall then review the situation and attempt to resolve it in a manner of its own choosing and report to the IETF on the outcome of its review.

If circumstances warrant, the IAB may direct that an IESG decision be annulled, and the situation shall then be as it was before the IESG decision was taken. The IAB may also recommend an action to the IESG, or make such other recommendations as it deems fit. The IAB may not, however, pre-empt the role of the IESG by issuing a decision which only the IESG is empowered to make.

The IAB decision is final with respect to the question of whether or not the Internet standards procedures have been followed.

  1. The Process used by the IAB to Review the Situation

The question raised by the appeal from the perspective of the IAB is whether the Internet Standards Process been followed in the determination of Working Group consensus and the subsequent appeal- based reviews on the issue of deprecation of site local addresses in the IPv6 address architecture.

The procedure used by the IAB in responding to this appeal has included

•review of the documentation of the IETF’s standards procedures and a working group’s declaration of consensus, as described in RFC 2026 and RFC 2418,

•review of the history of this appeal, and the process used and evidence gathered by the IESG in responding to the appeal directed to the IESG,

•review of the video recording of the meeting of the IPv6 working group at the 56th IETF, where the original question concerning site local addresses was put to the working group, and

•review of the IPv6 Working Group mailing list following the 56th IETF to ascertain what followup actions were taken within the Working Group leading to the declaration of Working Group consensus on this topic, and

•review of email on the thread “Appeal to the IAB on the site-local issue” on the IETF mailing list.

  1. IAB Considerations

4.1 Review of Internet Standards Procedures

RFC 2026 notes “the importance of establishing widespread community consensus” within the operation of Internet Standards process. The document also notes that disputes may be related to technical disagreements or the process used by the Working Group to reach an outcome.

i) RFC 2026, Section 6.5.1, Working Group Disputes

“An individual (whether a participant in the relevant Working Group or not) may disagree with a Working Group recommendation based on his or her belief that either (a) his or her 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 first issue is a difficulty with Working Group process; the latter is an assertion of technical error. These two types of disagreement are quite different, but both are handled by the same process of review.”

The procedure for Working Group meetings is detailed section 3 of the “Working Group Guidelines” (RFC2418) document. Relevant excerpts from this section of RFC 2418, “IETF Working Group Guidelines and Procedures” are:

ii) RFC 2418, Section 3, Working Group Operation:

“The IETF has basic requirements for open and fair participation and for thorough consideration of technical alternatives. Within those constraints, working groups are autonomous and each determines most of the details of its own operation with respect to session participation, reaching closure, etc. The core rule for operation is that acceptance or agreement is achieved via working group “rough consensus”.

iii) RFC 2418, Section 3.1, Session Planning:

“the [Working Group] Chair(s) MUST publish a draft agenda well in advance of the actual session. The agenda should contain at least:

•The items for discussion;

•The estimated time necessary per item; and

•A clear indication of what documents the participants will need to read before the session in order to be well prepared.”

iv) RFC 2418, Section 3.2, Session venue:

“Decisions reached during a face-to-face meeting about topics or issues which have not been discussed on the mailing list, or are significantly different from previously arrived mailing list consensus MUST be reviewed on the mailing list.”

“While open discussion and contribution is essential to working group success, the Chair is responsible for ensuring forward progress.”

v) RFC2418, Section 3.3, Session management:

“Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as “rough consensus” and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached.”

“In the case where a consensus which has been reached during a face- to-face meeting is being verified on a mailing list the people who were in the meeting and expressed agreement must be taken into account. If there were 100 people in a meeting and only a few people on the mailing list disagree with the consensus of the meeting then the consensus should be seen as being verified. Note that enough time should be given to the verification process for the mailing list readers to understand and consider any objections that may be raised on the list. The normal two week last-call period should be sufficient for this.”

“The challenge to managing working group sessions is to balance the need for open and fair consideration of the issues against the need to make forward progress.”

“It is occasionally appropriate to revisit a topic, to re-evaluate alternatives or to improve the group’s understanding of a relevant decision. However, unnecessary repeated discussions on issues can be avoided if the Chair makes sure that the main arguments in the discussion (and the outcome) are summarized and archived after a discussion has come to conclusion.”

4.2 Review of the background of this appeal, and the process used and evidence gathered by the IESG

References to the material reviewed are listed in Attachment B.

The April 10 appeal to the Area Directors and the July 31 appeal to the IESG both claimed that the Working Group Chairs asked an ambiguous question of yes/no for deprecation, both at the meeting and subsequently on the list.

The IESG reply on September 30 was that the question asked by the chairs at the meeting and on the mailing list was clear and precise. The IESG reply on Sept. 30 also contends that the spectrum of choices, included the limited use model, had been adequately presented at the SF meeting.

The IAB noted that the IESG, in undertaking its review of the appeal had reviewed the text of the Area Director’s response to the appeal to the Area Director, the Area Director’s summary to the IESG of the issue, the videotape of the IETF 56 Working Group meeting, and the mailing list archives. It was noted that not all IESG members reviewed every item in this collection of material. The IESG noted to the IAB that it had unsuccessfully attempted to seek clarification of the appeal from the appellant.

The IESG chose to treat the appeal as an appeal about the declaration of consensus by the chairs at the IPv6 Working Group meeting during IETF 56, and noted that the IESG regarded the video of this meeting as the most central piece of evidence.

Since this was regarded as a process appeal, not an appeal on technical substance, the events that transpired in the meeting, and their relationship to the description about declaration of consensus within the Internet Standards Process, were reported by the IESG as the central points they considered in reaching their decision on the appeal.

4.3 Review of Video Recording

A review of the video recording of the IETF56 IPv6 Working Group meeting was undertaken by Scott Bradner and passed to the IAB on October 13 (Attachment C). IAB members reviewed the video recording and there is broad agreement that the report prepared by Scott Bradner is an accurate summary of the proceedings.

The questions put to the Working Group at the meeting were:

(1) “how many people want to deprecate the use of IPv6 SL addresses?”

and

(2) “how many people do not want to deprecate the use of IPv6 SL addresses?”

There was evidence of a consensus position within the meeting and the chairs then informed the meeting that this would be then be taken to the mailing list for verification.

4.4 Review of the IPv6 Working Group Mailing List

The Working Group Chairs took the declared consensus decision of the Working Group meeting to the IPv6 working group mailing list. The IAB has reviewed the mailing list traffic from the period between the consensus call on April 1, and the declaration of consensus on April 10.

The question asked on the mailing list was:

“The question is:

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

The mailing list message also included the following notice:

“NOTE: DO NOT reply if you already expressed an opinion during the IPv6 WG meeting in SF!”

People voting were required to vote either “Yes” or “No” unambiguously.

After reviewing the mails sent in response to this question, it is noted that people clearly did so.

There was some mailing list traffic indicating that not all members of the working group were entirely clear on the basis of the question and text describing deprecation of site local addresses was requested. The view was expressed that the question could imply that the working group should stop working on any address technology that had site-local scope, or that the question could imply that the working group should remove the specification of the site-local prefix FEC0::/10, leaving the potential for the working group to explore a similar approach at a later time.

Other working group members indicated that did not see the question as being unclear, and were comfortable that they were making an informed decision when voicing their views on what they felt was a clearly put question.

The declaration of consensus by the Working Group on the question was posted to the mailing as follows:

“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).”

4.5 Review of IETF email following the IAB Appeal

The IAB reviewed email on on the thread “Appeal to the IAB on the site- local issue” on the IETF mailing list, following the lodging of an appeal with the IAB. The email highlighted two main topics:

•Does the decision to remove a technology from a proposed standard require a stronger demonstration of consensus that the decision to adopt a technology? Various views were expressed on this question within the mail thread.

•Was the decision regarding site local addresses a decision related to the definition of the address prefix FEC0::/10, or was it a decision to remove site-scoped local addresses from the IPv6 address architecture altogether? Differing views were expressed regarding the scope of the outcome of the working group’s decision.

4.6 Further Remarks

The appeal notes that:

“Contrary to their claim, the full spectrum of choices was not presented at the SF meeting.”

The appeals process within the IETF is intended to ensure that differences of perspective in the manner of the conduct of the Internet Standards Process are handled at through a number of levels of escalation. It is assumed that when an appeal is passed to the IAB the matter under review is one that has some gravity and substance and is entirely germane to the proper operation of the Internet Standards Process. Appeals can be seen to serve a role as one means of feedback on the quality of the IETF’s work in terms of both our ability to adhere to our adopted process and the quality of the process itself. These remarks are addressed to this broader perspective of the role of appeals.

The technical topic upon which this appeal is based has been a topic that has engaged the IPv6 Working Group’s attention for a number of years, and behind it lie a number of considerations relating to the utility and role of scoped address prefixes within the protocol’s address architecture, and the associated issues of routing architectures and deployment considerations.

The original approach of the definition of a common site local prefix within the IPv6 address architecture, namely FEC0::/10, introduced the potential issue of addressing clashes in the deployment environment. Given the highly variable definitions of a “site” in the context of deployment environments, and the consequences of leakage of these site- local addresses beyond its intended scope of use, there was a body of opinion that saw this as a potential weak point in the overall protocol architecture.

Equally it is apparent that there is a body of opinion that recognizes that there are perceived to be considerable advantages in a structured approach to scoped architectures where local-use utilities could be appropriately supported using local scoped addresses. In this fashion it appeared to be the intention that local use contexts could be supported using automated forms of local use address assignments in a so-called ‘plug- and-play’ architecture.

It has been observed that the IPv6 working group has been grappling with these two perspectives for some time, and progress with respect to the standard forms of use of site-local addresses was not apparent within the IPv6 Working Group for some time due to failure to obtain a clear consensus, albeit rough consensus, over how to balance these two perspectives and complete this part of its chartered activity.

It is noted that the Chairs have been diligent in attempting to assist the working group to come to a consensus position on this topic, and the IETF 56 meeting was intended to proceed further on the positions that the Working Group had shown some level of preference at the IETF 55 meeting. The Chairs noted the emerging consensus position in the IETF 56 working group meeting, and elected to put the question to the working group that reflected this position.

The appeal to the IAB notes that within this course of events, there was no documentation at the IETF 56 meeting of the option of complete removal of the site-local prefix from the address architecture, nor was there a requirements draft for locally-scoped addresses, nor were there drafts that considered the implications of the elimination of this prefix, or its retention within the address architecture. As noted in the comments received by the IAB, and noted in a review of the mailing list archives, this did lead to the comment being made that the question was not sufficiently clear to all working group members.

This consideration highlights the question received by the IAB regarding the possible need for a stronger demonstration of consensus for a decision to deprecate a technology from a proposed standard than that required to adopt a technology. A possible rephrasing of this question is to what degree should the working group carefully consider the implications of deprecation in the form of preparation of working group drafts that attempt to clearly define the intended action and explore the consequences and potential alternative approaches prior to making a consensus decision. This consideration would need to be balanced against the need to ensure that IETF Working Groups can operate effectively and efficiently, and that each Working Group consensus decision does not get unduly enmeshed in an increasing level of process overheads that may ultimately cause a Working Group to cease to make any progress at all.

However, with regards to the protocol for IETF appeals, the appeal to the IAB is an appeal of the IESG’s ruling on the prior appeal to the IESG. Broadening the terms of the appeal at this point in time is not within the intended scope of the appeals process. For this reason the IAB feels that above question is not properly within the scope of the appeal of the IESG decision. If the IETF is of the view that this question is of sufficient validity to warrant further study, then it is appropriate that it should be considered within the existing process of chartering a IETF working group activity relating to a review of the Working Group Procedures and the Internet Standards Process, rather than as part of any formal outcome of this appeal to the IAB.

The appeal raises the question:

“was this a vote about removing ambiguity from the site-local prefix, or removing limited routing scope from the architecture?”

The appeal cites as evidence:

“Which returns us to the ambiguity of the original question, was this a vote about removing ambiguity from the site-local prefix, or removing limited routing scope from the architecture? People expressed opinions about each of those as the basis of their yes vote”

The questions posed to the working group by the chairs at the IETF 56 meeting were:

“how many people want to deprecate the use of IPv6 Site Local addresses?”

and

“how many people do not want to deprecate the use of IPv6 Site Local addresses?”

The question mailed to the ipv6 working group mailer was:

“Should we deprecate IPv6 site-local unicast addressing?”

It is observed that while a Working Group makes progress through rough consensus, this consensus refers to working group consensus questions, as distinct to a formation of a consensus among working group members as the basis for their reasons to support a particular response to the consensus question.

In terms of the question of the ambiguity of the question, this can be posed as whether the term “deprecate IPv6 Site Local Addresses” is inherently ambiguous to a IPv6 working group member.

It is noted that in the IPv6 address architecture the concept of a “Site-Local Address” is defined as a set of constraints on those addresses that use the prefix FEC0:/10. Within the mail archives of the working group, the Working Group’s use of the term “IPv6 site-local address” has been consistently used to mean the FEC0::/10 prefix together with the described set of constraints associated with this prefix in the address architecture specification.

In this light is it reasonable to conclude that “deprecate IPv6 Site Local Addresses” refers to the deprecation of the part of the IPv6 address architecture specification that describes the FEC0::/10 prefix and its associated constraints. In the view of the IAB, we believe that terminology used in the question was consistent with the working group’s normal usage of this terminology.

  1. IAB Consideration of the Appeal

The IAB finds that:

•While this was a topic with a considerable history of consideration within the Working Group’s activities, the Working Group adopted a direction within its IETF 56 meeting that wasn’t well signaled in advance in the meeting’s agenda material, in the documents prepared for consideration on the topic and in the conduct of this part of the meeting. However, the Chairs of the Working Group were acting within the parameters of conduct of Working Groups in calling the question at the meeting in response to evidence of a possible consensus on the question. The subsequent validation of this consensus decision on the WG mailing list was a necessary and useful adjunct to the WG meeting. The meeting poll was not a decision taken in isolation or taken without subsequent consideration.

•This decision was reflective of the consensus position of the Working Group and was not an instance of the use of incorrect or improper process. The Working Group Chairs declaration of Working Group rough consensus on the question was made in accordance with IETF process.

•There is no current documentation that requires any additional or altered procedure to that of rough consensus when deprecating a technology from an Internet standard, as compared to the adoption of a technology.

•The IESG undertook a diligent investigation into the declaration of consensus by the Working Group chairs, and had gathered all the relevant inputs. The IAB in their review found that there is nothing obvious that was omitted in the IESG investigation and the IESG interpretation of the appeal as a process appeal is consistent with the data the IESG gathered.

•that the IESG’s decision not to uphold the appeal was consistent with available evidence, and consistent with the IETF documented processes for working group conduct and consistent with the Internet Standards Process.

The IAB finds that the IESG decision, namely to uphold the IPv6 Working Group chairs’ and Internet Area ADs’ decisions relating to the declaration of consensus on the issue of deprecation of site local addresses in the IPv6 address architecture, was consistent with the available evidence and consistent with documented IETF process.

Accordingly, the IAB upholds the IESG decision in this matter.

——————————————————————————–

Attachment A

Text of the Appeal to the IAB

From: “Tony Hain”

To: “IAB”

Cc: “The IESG” , , “IETF”

Subject: Appeal to the IAB on the site-local issue

Date: Thu, 9 Oct 2003 16:59:38 -0700

I am saddened that it has come to this, but the IESG action has simply prolonged the process. The only clarity in their ‘…somewhere to the left…’ justification is their willingness to let personal technical biases blind them to the process failure. As such, please consider this note to be an appeal to the IAB against the IESG decision to reject my appeal.

Contrary to their claim, the full spectrum of choices was not presented at the SF meeting. Then, if it weren’t for the seriousness of the issue, their inability to do a quick check of the Atlanta minutes (which shows that 125 attendees were against complete removal, not the limited model) would be humorous. In response to the overwhelming rejection of her preferred path, in Atlanta the chair declared ‘The wg has agreed we don’t want to remove them completely …’ so there was no documentation developed discussing the impacts of complete removal. Therefore there could be no substantive presentation of that position. As noted in my original 4/10/2003 appeal to the chairs, the mail list claims that the RFC 3513 Site-Local addresses ‘have issues that outweigh the benefits’, or ‘does not meet the requirements’ are invalid because there was no document listing the requirements, therefore no way to conduct an evaluation which would justify those positions.

This lack of documentation became acute when the participants from the applications area were invited to join in the discussion. While I acknowledge that cross area participation helps refine the specifications (and had personally been lobbying the Apps Area to participate), that refinement only happens through extended discussion and informed debate. An hour and twenty minutes of inciting the mob does not constitute informed discussion. In fact 10 minutes before the question, Dave Thaler pointed out there was no draft about elimination, but that detail was ignored by the chair. Shortly after that, Brian Carpenter pointed out that he couldn’t vote for keeping SL unless he knew the details of that outcome, to which the chair eventually countered we don’t have any details about what it means to remove them either and ‘we may have to wave our hands around a little bit’. The chair chose to conduct the vote with no clear outcome for either position, leaving the result that the chair could later tell the working group what it had decided.

The further comment by the IESG that the action has resulted in working group activity to address the issues is equally flawed. There were attempts to disambiguate the FEC0 space prior to the SF fiasco, but those were consistently savaged by those who want nothing more than to declare the routing space to be globally flat by IETF fiat. Those same people are working to prevent a different form of local prefix from being defined, and now are feeling emboldened as it appears that this current work is an addition to the architecture rather than a refinement. Which returns us to the ambiguity of the original question, was this a vote about removing ambiguity from the site-local prefix, or removing limited routing scope from the architecture? People expressed opinions about each of those as the basis of their yes vote, but the scope of routing is an operational decision of network managers, therefore not something the IETF gets to decide. Since the votes were mixed as a common Yes, the vote must be invalidated.

At every step, this exercise has exposed failures in how the IETF conducts its business. It is now up to the IAB to recommend that the IESG go back, *seriously* set aside their technical biases, and reconsider the process breakdowns. Anything less and we set the precedent that it really doesn’t matter how badly a chair abuses the process as long as the IESG agrees with the outcome.

Tony

FYI: video of the SF session: ftp://limestone.uoregon.edu/pub/videolab/video/ietf56

The IESG has reviewed the appeal by Tony Hain of the IPv6 Working Group chairs’ declaration of consensus on the issue of site local addresses in the IPv6 address architecture.

Tony’s appeal requests that the declaration of consensus be overturned due to the ambiguity of the question asked.

As is to be expected of a technical discussion where there are many opinions, the discussion of the site-local issue at the San Francisco IETF meeting went all over the map, with many unanswered questions. However, the question asked by the chairs, with clarification from the AD, was clear. “Does the group want to go away from site-local addressing, deprecate it, work out how to get it out, [or] does the group want to keep it and figure out what the right usage model is for it?” The clarifying statement was “Deprecate […] means somewhere to the left of the ‘limited use’ model?” The spectrum of choices, including the ‘limited use’ model, had been presented during that same meeting. Although the group had decided to rule out the ‘limited use’ model (and presumably anything to the left of it as well) in Atlanta, nothing precludes new information from prompting a review of old decisions.

The question posed on the list was more concise, simply “Should we deprecate IPv6 site-local unicast addressing?” This question is not ambiguous.

The deprecation of site-local addresses in their current form has served a useful role in forcing the working group to recognize the problems that the original definition had and work to address them. The IESG finds nothing unusual about how the question was asked or how the working group has proceeded.

There is strong consensus in the IESG that deprecation is the correct technical decision, but we have done our best to separate our technical preferences from the process issue in considering this appeal.

In summary, the IESG upholds the chairs’ and INT ADs’ decisions.

The IESG

——————————————————————————–

Attachment B

References to documentation and related material reviewed by the IAB

November 2003, Atlanta IETF: Brian Haberman, “Routing and Forwarding of Site Local Addresses”, 55th IETF.

http://www.ietf.org/proceedings/02nov/slides/ipv6-5.pdf

Rob Austein, Connected Site-Local Considered Harmful, 55th IETF.

http://www.ietf.org/proceedings/02nov/slides/ipv6-6.pdf

Minutes from the IPv6 Working Group at the Atlanta IETF:

http://playground.sun.com/pub/ipng/html/minutes/ipv6-minutes-nov2002.txt

March 2003, M. Wasserman, The Impact of Site-Local Addressing in Internet Protocol, Version 6 (IPv6).

http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.txt

March 2003, San Francisco IETF meeting: Bob Hinden and Margaret Wasserman, IPv6 Site-Local Discussion, 56th IETF

http://www.ietf.cnri.reston.va.us/proceedings/03mar/slides/ipv6-3/index.html

Page 3 lists the range of use cases: No site-local; limited; exclusive; moderate; full-usage.

Minutes: http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt

April 1, Hinden and Wasserman, Consensus Call.

ftp://ftp.ietf.org/ietf-mail-archive/ipngwg/2003-04.mail Message-Id: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com>

•”The question is: Should we deprecate IPv6 site-local unicast addressing?”

April 9, Hinden and Wasserman, Declaration on Consensus.

ftp://ftp.ietf.org/ietf-mail-archive/ipngwg/2003-04.mail Message-Id: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com>

Declaration:

•This is the IPv6 Working Group chairs’ declaration of consensus on the issue of site local addresses in the IPv6 address architecture.

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

April 10, appeal to the ADs:

ftp://ftp.ietf.org/ietf-mail-archive/ipngwg/2003-04.mail Message-Id: <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings>

Appeal claims:

•”the chairs decided to call an ambiguous question of yes/no for deprecation”

•”the call ended up combining yes opinions for removing ambiguity with yes opinions for removing local scope addresses from the architecture.”

July 31, appeal to the IESG:

http://www.ietf.org/IESG/APPEALS/tony-hain-appeal.txt

Appeal claims:

•The chair asked an ambiguous question.

•The question asked to the list was no clearer.

August 26: draft-ietf-ipv6-deprecate-site-local-00.txt, by Huitema and Carpenter.

Now draft-ietf-ipv6-deprecate-site-local-01.txt

Sept. 16 email from Hinden and Haberman to ipv6@ietf.org on “Results of Poll”

Sept. 30, IESG reply to the appeal:

http://www.ietf.cnri.reston.va.us/IESG/APPEALS/iesg_tony_hain.txt

In the IESG reply to the appeal, the IESG found that:

•The question asked by the chair, with clarification from the AD, was clear;

•The question posed on the mailing list was clear and concise.

•The spectrum of choices, included the limited use model, had been presented at the meeting.

•Although the group had decided to rule out the limited use model in July, “nothing precludes new information from prompting a review of old decisions”.

October 9, Hain, appeal to the IAB.

http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg00239.html

Appeal claims:

•The full spectrum of choices was not presented at the SF meeting;

•The co-chairs didn’t check the Atlanta minutes showing 125 attendees against complete removal;

•There was no documentation at the meeting of the complete removal option.

•Claims on the mailing list that site-local addresses don’t meet the requirements are invalid because there is no requirements document.

•The chair conducted the vote with no clear drafts about the elimination or the keep-site-local options.

•It was not clear whether the vote was about removing ambiguity from the site-local prefix, or about removing limited routing scope from the architecture. “Since the votes were mixed as a common Yes, the vote must be invalidated.”

Email archives: ftp://ftp.ietf.org/ietf-mail-archive/ipngwg/

——————————————————————————–

Attachment C

Review of recording of the IPv6 Working Group Session

Excerpts from mail from Scott Bradner to the IAB describing a review of a video recording of the IPv6 Working Group meeting.

Date: Mon, 13 Oct 2003 12:28:49 -0400 (EDT)

From: Scott Bradner

To: iab@ietf.org

Subject: Re: Appeal to the IAB on the site-local issue

Cc: iesg@ietf.org, ietf@ietf.org

ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56%20-%2003202003%20-%20INT%20ipv6.rm

The SL discussion starts at 1:02 into the session.

The chairs first presented a set of slides talking about various SL related options. The presentation was interrupted with questions from the floor quite a few times during the discussion of the “exclusive” model (wherein a v6 node would be a SL node of a global addressing node) – it was clear to me that there was quite a bit of confusion about this model. There were few interruptions during the discussions about the other models.

The chairs opened the floor for general discussion at 1:39 into the session. The discussion was careful and extensive. After a while it became clear, as noted by Thomas [Narten], that more people were arguing for eliminating SL than had been the case in the past and few people were arguing for SL addressing. Those that were arguing in favor of SL mostly said that SL and v6 NATs were going to happen anyway but no one seemed all that concerned that the IETF define such addresses (e.g. Deno pointed out that people would just pick their own if the IETF did not.)

At 2:07 into the session the chairs conferred and said that they would ask a simple yes or no question (in reality they asked two questions) about deprecating IPv6 SL addresses. (Not eliminate them in that the sense that the prefix would not be reassigned for other uses.) Margaret noted that the simple questions covered a lot of details that were not called out.

After 10 minutes of discussion to clarify the intent of the questions Margaret asked for a show of hands for:

1.how many people want to deprecate the use of IPv6 SL addresses?

2.how many people do not want to deprecate the use of IPv6 SL addresses?

She asked the first question twice so they could get a count of hands the second time. The result was 102 hands in favor of deprecating and 20 opposed. The chairs declared that there was rough consensus in the session to deprecate the use of IPv6 SL addressing but that this consensus would now be taken to the list to verify.

Date: Tue, 14 Oct 2003 11:17:44 -0400 (EDT)

From: Scott Bradner

To: iab@ietf.org

Subject: RE: Appeal to the IAB on the site-local issue

Cc: iesg@ietf.org, ietf@ietf.org

Yesterday I posted a message that said that I agreed with the IPv6 working group chairs that rough consensus was reached to deprecate IPv6 site local addresses. That said, I do have an issue on the discussion that led up to that consensus decision. I do not think there was much of an actual discussion on the topic.

The working group chair’s presentation on the site local options listed five options for the working group moving forward in regards to the site local question. These options ranged from eliminating site local addresses to fully embracing the concept and working out all the details of how to use them. But they only discussed the middle three options. They reported that the consensus in the Atlanta meeting was to not support outright elimination or full embrace so those options were not included in the chair’s presentation of the advantages and disadvantages of the various options.

The discussion during the chair’s presentation basically did not touch on the pros and cons of having site local addresses per se – a few ‘they should just go away’ statements were made but no exploration of the issues.

The open discussion after the presentation also did not explore the issues but there were a greater number of people who felt that SL addresses should be eliminated from IPv6.

As I mentioned in yesterday’s note – Thomas and others noticed the sentiment against SL and the chairs wound up asking the question they did (about deprecating SL) as a result.

——————————————————————————–

Appeal to IAB concerning the IPv6 WG decision on site-local addresses. Date: Thu, 9 Oct 2003 16:59:38 -0700

From: “Tony Hain”

To: “IAB”

Cc: “The IESG” , , “IETF”

Subject: Appeal to the IAB on the site-local issue

I am saddened that it has come to this, but the IESG action has simply prolonged the process. The only clarity in their ‘…somewhere to the left…’ justification is their willingness to let personal technical biases blind them to the process failure. As such, please consider this note to be an appeal to the IAB against the IESG decision to reject my appeal.

Contrary to their claim, the full spectrum of choices was not presented at the SF meeting. Then, if it weren’t for the seriousness of the issue, their inability to do a quick check of the Atlanta minutes (which shows that 125 attendees were against complete removal, not the limited model) would be humorous. In response to the overwhelming rejection of her preferred path, in Atlanta the chair declared ‘The wg has agreed we don’t want to remove them completely …’ so there was no documentation developed discussing the impacts of complete removal. Therefore there could be no substantive presentation of that position. As noted in my original 4/10/2003 appeal to the chairs, the mail list claims that the RFC 3513 Site-Local addresses ‘have issues that outweigh the benefits’, or ‘does not meet the requirements’ are invalid because there was no document listing the requirements, therefore no way to conduct an evaluation which would justify those positions.

This lack of documentation became acute when the participants from the applications area were invited to join in the discussion. While I acknowledge that cross area participation helps refine the specifications (and had personally been lobbying the Apps Area to participate), that refinement only happens through extended discussion and informed debate. An hour and twenty minutes of inciting the mob does not constitute informed discussion. In fact 10 minutes before the question, Dave Thaler pointed out there was no draft about elimination, but that detail was ignored by the chair. Shortly after that, Brian Carpenter pointed out that he couldn’t vote for keeping SL unless he knew the details of that outcome, to which the chair eventually countered we don’t have any details about what it means to remove them either and ‘we may have to wave our hands around a little bit’. The chair chose to conduct the vote with no clear outcome for either position, leaving the result that the chair could later tell the working group what it had decided.

The further comment by the IESG that the action has resulted in working group activity to address the issues is equally flawed. There were attempts to disambiguate the FEC0 space prior to the SF fiasco, but those were consistently savaged by those who want nothing more than to declare the routing space to be globally flat by IETF fiat. Those same people are working to prevent a different form of local prefix from being defined, and now are feeling emboldened as it appears that this current work is an addition to the architecture rather than a refinement. Which returns us to the ambiguity of the original question, was this a vote about removing ambiguity from the site-local prefix, or removing limited routing scope from the architecture? People expressed opinions about each of those as the basis of their yes vote, but the scope of routing is an operational decision of network managers, therefore not something the IETF gets to decide. Since the votes were mixed as a common Yes, the vote must be invalidated.

At every step, this exercise has exposed failures in how the IETF conducts its business. It is now up to the IAB to recommend that the IESG go back, *seriously* set aside their technical biases, and reconsider the process breakdowns. Anything less and we set the precedent that it really doesn’t matter how badly a chair abuses the process as long as the IESG agrees with the outcome.

Tony

FYI: video of the SF session:

ftp://limestone.uoregon.edu/pub/videolab/video/ietf56

The IESG has reviewed the appeal by Tony Hain of the IPv6 Working Group chairs’ declaration of consensus on the issue of site local addresses in the IPv6 address architecture.

Tony’s appeal requests that the declaration of consensus be overturned due to the ambiguity of the question asked.

As is to be expected of a technical discussion where there are many opinions, the discussion of the site-local issue at the San Francisco IETF meeting went all over the map, with many unanswered questions. However, the question asked by the chairs, with clarification from the AD, was clear. “Does the group want to go away from site-local addressing, deprecate it, work out how to get it out, [or] does the group want to keep it and figure out what the right usage model is for it?” The clarifying statement was “Deprecate […] means somewhere to the left of the ‘limited use’ model?” The spectrum of choices, including the ‘limited use’ model, had been presented during that same meeting. Although the group had decided to rule out the ‘limited use’ model (and presumably anything to the left of it as well) in Atlanta, nothing precludes new information from prompting a review of old decisions.

The question posed on the list was more concise, simply “Should we deprecate IPv6 site-local unicast addressing?” This question is not ambiguous.

The deprecation of site-local addresses in their current form has served a useful role in forcing the working group to recognize the problems that the original definition had and work to address them. The IESG finds nothing unusual about how the question was asked or how the working group has proceeded.

There is strong consensus in the IESG that deprecation is the correct technical decision, but we have done our best to separate our technical preferences from the process issue in considering this appeal.

In summary, the IESG upholds the chairs’ and INT ADs’ decisions.

The IESG

——————————————————————————–