Re: FW: AD response to Site-Local Appeal

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Sun, 03 Aug 2003 12:33:08 -0400
    From:        Margaret Wasserman <mrw@windriver.com>
    Message-ID:  <5.1.0.14.2.20030803114743.066ddbf8@mail.windriver.com>

I am not planning on debating these issues here, again, so just this
one message...

  | An initial draft agenda, which did list the local addressing
  | topic, was sent to the mailing list on March 3rd.  The final
  | agenda was posted on March 14th.

The March 3 message you refer to was, I assume, the "Draft Agenda
Announcement", which I would interpret as a call for agenda items.
It certainly was nothing even close to meeting the requirements for
an agenda in rfc2418.   So while I appreciate the lengths to which
you're willing to go to have it appear that the "well in advance"
rule was met, I don't think that message is going to help you.

Even if it did, I doubt that even Mar 3 could be considered as "well
in advance" - that was just 2 weeks before the IETF - the same day
as (final) I-D submissions ended (-00 submissions had already been
closed for a week).   The idea of posting the agenda in advance is
to give people a chance to decide whether or not they need to attend
the meeting.

And of course, this assumes that the topics that are to be decided are
announced in the agenda.   The Mar 3 message just said ...

   - Site-Local Usage
      o Impact of Site-Local draft
      o Moderate Use Case draft

which doesn't mention that a question to deprecate site local addresses
would be even considered possible.


  | 
  | RFC2418 also says:
  | 
  |      In the case where a consensus which has been reached during a
  |      face-to-face meeting is being verified on a mailing list the

Yes.   There are two aspects to this.   First, there are two different
types of face to face meeting discussion.   One is where an issue has
been debated on the list, with no consensus being reached, so the WG
decides to discuss this more at an IETF, and try and work out the
differences (announcing that this is to happen in the agenda, with
plenty of time for everyone who cares to decide to attend).  If after
that the meeting finds a solution to the problem, all that requires is
verification on the list - to make sure that those who weren't able to
attend don't have any particular problems.

The other case is where something new (unforeseen) appears at a face
to face meeting - there 2418 says "review" on the list.   "review"
and "verify" aren't the same thing.

But, even if the section you quoted were relevant to the issue
under discussion, note that ...

  |      If there were 100 people in a meeting and
  |      only a few people on the mailing list disagree with the consensus

"only a few".   There were way more than "a few" on the list who disagreed.

IETF "rough consensus" has always been this way, a few objectors don't
necessarily matter (though everyone's objection should be at least
examined, even a single objector can find a fatal flaw sometimes), but
lots of objections means there is no consensus.

Further, while quoting 2418 back and forward, you might also want to
look at ...

   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.

That is, two weeks is probably long enough (but it is hinted that it
might sometimes not be).   One week?


  | The concept of deprecating site-local addressing had been under
  | discussion for some time.  In particular, removing site-local
  | addresses from the architecture was discussed as an option at the
  | IPv6 WG meeting in Atlanta in November 2002,

Hmm, in the minutes of that meeting, I see that mentioned as an option
in what appears like a question, or an answer to a question (those minutes
are very confusing).

I also see ...

	Margaret - The wg has agreed we don't want to remove them
                   completely and that we don't want to document
		   them completely

So, it appears, in Nov 2002, at least, the WG hade decided not to
remove site locals (if those minutes are to be believed anyway).

Also ...

	Moore - [...] it appears to me that we have near consensus that
		it is OK  to use site-local in disconnected networks.
		We also have near-consensus that it may be OK to use
		site-locals in restricted other uses.

What's more, the results of the "vote" taken there, as it appears
in the minutes was ...

No consensus:  ~30 Remove, ~51 Limited, ~57 Moderate, ~17 Full

which as "no consensus" I certainly agree with (no surprise, as there
were no real concrete proposals, just hand waving, as I understand it)
but from that, only a very small fraction of the audience looked to
support removing SL.

  | and proposed as an alternative in an I-D that I published in December
  | 2002. 

Yes, and in the 3rd version of that I-D (the -02 version) which was current
as of the 56th IETF, that suggestion (which never actually went as far as
to delete SL completely, it was the "limited use" proposal) had been moved
from the body of the document to an appendix - in all respects appearing to
be just stating your private opinion, which was apparently not gaining a
lot of WG support.

  | So, this was certainly not a new topic of discussion for anyone who had
  | been following the IPv6 WG since November 2002.

That people wanted to talk about how to handle SL addresses was
abundantly clear.   That there would be a serious proposal to remove
them completely wasn't apparent in advance at all.

You agree...

  | To our surprise, however, the consensus of those attending
  | the meeting in San Francisco was that all of the proposals to
  | limit the use of site-locals still had substantial problems.

This was clearly something new.   And that is exactly what 2418
says needs to be reviewed on the list.   That is, face to face
meetings cannot...

  | So, we reached consensus to move in the direction of deprecating
  | site-local unicast addressing, and that is the course that we
  | are pursuing now.

The list needs to do that.

  | This is incorrect.  One person did publicly change his mind (David
  | Borman, in a message sent to the list on April 4th), and this
  | was publicly acknowledged and supported in mail sent by me on
  | April 5th.  No one else indicated a desire to change his/her mind.

Yes, one was willing to violate the original stated rules, which
were quite explicit that no-one who had expressed an opinion in the
face to face meeting was allowed to talk again.   Dave made it quite
clear in his message that he wasn't sure that what he wanted to do
was allowed.

I can't even imagine just why the "don't send a message again" nonsense
was in the original "consensus call" at all.

  | It is strange that you argue both that:
  | 
  |          (1) Consensus is not determined by voting or numbers.
  | 
  |          -AND-
  | 
  |          (2) These numbers aren't good enough to constitute
  |                  consensus.

Not at all.    We don't determine consensus by counting votes.   However
it is quite reasonable to ask for a straw poll to see just how many
objections are really out there (as, as 2418 quite correctly points out,
it is possible, sometimes, for just a small number of people to make lots
of noise for or against something).

What we don't do is decide "10 for, 6 against, carried"....

  | All documents produced as part of this course of action will
  | be subject to discussion by the WG, and they will go through
  | WG last call, etc.  In keeping with normal IETF processes,
  | these documents won't be sent to the IESG unless they
  | represent the consensus of the WG at that time.

Fine.   In that case, why not just tell everyone that the SF+list
"vote" is irrelevant for all purposes.   Anyone can submit a new
document any time, and have it considered by the WG.   If there
are new versions of any of these documents being written, they can
be studied when they appear to see if they meet the overall demands
of this group (and then eventually, of the IETF as a whole).

Doing that would certainly end my (current) objections, and while I
can't speak for Tony, it might well end his appeal as well.

The only think I am currently concerned about is that the WG seems
to be being pushed into making decisions that look as if they're
binding, without having any concrete proposals to consider.

That's a horrible way to attempt to make progress, and rarely gets
anywhere.   If the WG gets to make a reasoned decision based upon
a fully constructed document, that's fine - but emotive "this is
hard, lets get rid of it" type arguments, do no-one any good.


  | >The WG chairs did not bother to reply to any of the issues raised in
  | >that message.  Or at least, they have not so far.
  | 
  | I did reply to this message, also on April 10th, just a few hours
  | after you sent it.

Yes, that indicates that you received and read the message.   If that
reply was meant to be a reply from the WG chairs (or a WG chair) rather
than from a WG member (the people who are WG chairs get to be members
of the WG as well of course), then it certainly didn't come across that
way.

In particular, neither that response, nor any of the following discussion,
addressed any of the process issues at all, it was all technical (as in
what should we actually do).   That was fine as a discussion, but it
certainly wasn't a (chair's) reply to my message.

  | It is my hope that we can re-focus this discussion on making the
  | right technical decisions within the IPv6 WG moving forward.

That would be nice.   One easy way to do that would be to simply
tell the WG to act as if this "consensus" never happened, and to
go back to writing drafts that actually solve problems, which can
be considered on their individual or collective merits.

Personally, I find it amusing, at least, that anyone can possibly
have decided that SL addresses aren't the answer to any problems,
when the problems haven't even been specified and agreed yet.

It is true that if we didn't have SL addresses in the architecture,
we wouldn't be adding them based upon current discussions - but we
do, they're in use, they're documented in text books, and the RFCs.

  | I would encourage you to read the current documents, which include:

Believe it or not, I have.

  | Your technical input on these documents would be very welcome.

And on some of those I have made comments.   No doubt in the future
I may make more.

kre