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