Appeal to the IAB on the site-local issue

["Tony Hain" <alh-ietf@tndh.net>]

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
>