ietf
[Top] [All Lists]

RE: IAB Response to Tony Hain's appeal of October 9, 2003

2003-11-20 16:15:41
I appreciate the prompt response. A few points of clarification: 

The contention was that there was no WG decision, because there was no
consistent technical basis for the question. It is impossible to judge
'correctness' without some defining scope. When the responsible AD & Chair
use clarifications of 'somewhere to the left' and 'handwave', it should be
obvious that someone needs to go back and write a concrete definition for
what is being discussed before any conclusions can be drawn.

I was only aware of one question from the IESG on 8/1, which I responded to
that day. I have no idea why the IESG would claim they were unsuccessful in
their attempt to seek clarification.

The IAB's role here (and IESG for that matter) is to ensure that the
leadership has not endorsed or participated in an edict of 'the correct
technical decision' outside of the proper process. My understanding of the
IESG response was that it didn't matter how the WG got here, they were happy
with the result.

If the IAB's interpretation of the language and question scope (sec 4.6) had
been the clear interpretation from the participants in the SF meeting & mail
list, I would not have bothered with the appeal process. Given the context
of the interpretation as specific to the prefix FEC0::, I consider the
matter closed.

Tony


-----Original Message-----
From: owner-ietf-announce(_at_)ietf(_dot_)org 
[mailto:owner-ietf-announce(_at_)ietf(_dot_)org]
On Behalf Of Leslie Daigle
Sent: Monday, November 17, 2003 12:55 PM
To: IETF-Announce:
Subject: IAB Response to Tony Hain's appeal of October 9, 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.


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


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


 4. 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 April 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 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 that are
of
       potential relevance:


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

 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.



 5. 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" <alh-ietf(_at_)tndh(_dot_)net>
       To: "IAB" <iab(_at_)iab(_dot_)org>
       Cc: "The IESG" <iesg(_at_)ietf(_dot_)org>, <ipv6(_at_)ietf(_dot_)org>, 
"IETF"
<ietf(_at_)ietf(_dot_)org>
       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/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://playground.sun.com/pub/ipng/mail-archive/,
       ipng.200304, Message-Id:
 
<5(_dot_)1(_dot_)0(_dot_)14(_dot_)2(_dot_)20030401143711(_dot_)04a0f848(_at_)mail(_dot_)windriver(_dot_)com>
       * "The question is: Should we deprecate IPv6 site-local unicast
addressing?"

       April 9, Hinden and Wasserman, Declaration on Consensus.
       ftp://playground.sun.com/pub/ipng/mail-archive/,
       ipng.200304, Message-Id:
 
<4(_dot_)3(_dot_)2(_dot_)7(_dot_)2(_dot_)20030409150734(_dot_)02f0ad58(_at_)mailhost(_dot_)iprg(_dot_)nokia(_dot_)com>
       * 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."
       * "The IPv6 WG will work to accomplish the following things in
parallel:"

       April 10, appeal to the ADs:
       ftp://playground.sun.com/pub/ipng/mail-archive/,
       ipng.200304, Message-Id:
<0f4201c2fef9$ef22eaf0$ee1a4104(_at_)eagleswings>
       * "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(_at_)ietf(_dot_)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://playground.sun.com/pub/ipng, then
       http://www1.ietf.org/mail-archive/working-
groups/ipv6/current/maillist.html

 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 <sob(_at_)harvard(_dot_)edu>
       To: iab(_at_)ietf(_dot_)org
       Subject: Re: Appeal to the IAB on the site-local issue
       Cc: iesg(_at_)ietf(_dot_)org, ietf(_at_)ietf(_dot_)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 <sob(_at_)harvard(_dot_)edu>
       To: iab(_at_)ietf(_dot_)org
       Subject: RE: Appeal to the IAB on the site-local issue
       Cc: iesg(_at_)ietf(_dot_)org, ietf(_at_)ietf(_dot_)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.






<Prev in Thread] Current Thread [Next in Thread>
  • RE: IAB Response to Tony Hain's appeal of October 9, 2003, Tony Hain <=