Subject: Re: FW: AD response to Site-Local Appeal

From: Margaret Wasserman <[email-masked]>
Date: Sun, 03 Aug 2003 12:33:08 -0400

[Note:  This message is being sent in my role as an IPv6 WG chair.
I have already recused myself from IESG consideration of Tony
Hain's appeal and will not participate in this discussion as an
Internet AD.]

Hi Robert,

I'd like to respond to a few of the things that you mentioned in
your message:

At 09:23 PM 8/1/2003 +0700, Robert Elz wrote:
>First, RFC2418 (aka BCP 25) (WG procedures) requires...
>
>    For coordinated, structured WG interactions, the Chair(s) MUST
>    publish a draft agenda well in advance of the actual session.
>
>The agenda of the March 2003 ipv6 WG meeting was sent to the mailing
>list on March 14.   The WG meetings were on March 17 & 20.   "Well
>in advance".   Hmmm...

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.

>Then
>
>    The minutes shall
>    be submitted in printable ASCII text for publication in the IETF
>    Proceedings, and for posting in the IETF Directories and are to be
>    sent to: [email-masked]
>
>As best I can tell, no minutes have been submitted for that meeting
>(even though the next meeting has already been completed).   Draft
>minutes were sent to the mailing list (March 28), but nothing further
>seems to have been done.  They certainly don't appear in the normal
>IETF places for WG meeting minutes (as for example, the November 2002
>minutes do).

Due to a clerical error on our part, the minutes were not submitted
to the secretariat on time.  However, they were sent to the mailing
list (on March 28th, as you indicate) and there were no comments
indicating errors or omissions.

So, everyone on the mailing list has had access to the minutes since
March 28th (less than two weeks after the meeting).

Although the minutes were submitted to the secretariat late, they
were submitted.  We are not sure why they have not been posted to
the proceedings web page.  This is currently being investigated.

>Then, again from rfc2418:
>
>    In determining the balance, the WG must ensure that
>    its process does not serve to exclude contribution by email-only
>    participants.  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.
>
>First from that note, "reviewed" on the mailing list, not "continued
>there".

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

So, RFC 2418 does not indicate that the entire consensus call should
be re-done on the mailing list.  In fact, it explicitly states that
the number of people involved in the face-to-face consensus "must be
taken into account" in the final determination.

>Before we get to that though, there's the issue of whether the "deprecate
>site local" was a new issue, or one that had been dragging along forever.

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, and proposed as an
alternative in an I-D that I published in December 2002.  So, this
was certainly not a new topic of discussion for anyone who had
been following the IPv6 WG since November 2002.

In Atlanta, there was consensus in the WG to pursue a course
of action that involved limiting the use of site-local
addressing in some way.  This course was pursued for a few
months, with a few different proposals circulated for how to
limit the use of site-local addressing.  Bob and I presented
a summary/comparison of these proposals in SF, and we honestly
believed that the WG would choose between those proposals.

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

>         This email asks those that were NOT present at the Thursday IPv6
>         meeting in SF to express their opinions on a question that was
>         asked of the room.   If you expressed an opinion on this issue in
>         SF you can skip this message; in any case you MUST NOT respond to
>         this query.
>
>That is, no-one was permitted to have had a change of mind.

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.

>One may
>speculate as to why this "unusual" approach was taken, and perhaps
>reach the conclusion that having achieved a large majority (reported in
>the draft minutes as 102 to 20) in favour of the "deprecate site local"
>decision, they didn't want to risk any of that majority being dropped
>away, or any of the people who supported it, not really being on the
>ipv6 list, and so not normally a part of the working group or its
>decision making process (which isn't to say anyone should be excluded,
>anyone can join the list, and if, knowing the issue was to be discussed
>there, they had a strong opinion upon it, anyone could have joined the
>list to express that opinion).

Please see the RFC 2418 text quoted above.  RFC 2418 _requires_ that
the number of people who reached consensus in the meeting room must
be taken into account when the consensus is reviewed on the list.

>Further, even that assumes that taking votes is the way the IETF
>operates.   That would not often be regarded as a normal way to do
>things.   Normally, WGs take "straw polls" to determine whether
>just about everyone agrees with a point, or disagrees, or whether
>there's a serious split.    Here, had this been regarded as a straw
>poll, then even with 155 to 56 numbers, "serious split" and "no consensus"
>would have been the only reasonable result.

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.

The straw poll results were not the only thing that the WG
chairs considered in determining WG consensus on this issue,
We considered the hundreds of e-mail messages that had been
generated on the IPv6 mailing list regarding this subject over
several months, we considered the comments and discussion on
this topic from the face-to-face IPv6 WG meeting, and we also
considered the comments that people made regarding why they
indicated YES or NO in response to our straw poll.

Based on all of this input, we determined that (in our best
judgement) there was a consensus of the IPv6 WG to pursue a
specific course of action.  This course of action involves
doing multiple things in parallel that will eventually result
in deprecating site-local unicast addressing and replacing it
with a non-ambiguous local addressing scheme (not necessarily
in that order).  We believe that we correctly determined the
consensus of the WG, because very few people have objected to
our consensus statement since it was published on April 9th.
Furthermore, the WG seems to be productively engaged in carrying
out the action plan that we indicated in our consensus e-mail.

I won't argue that we followed every process in RFC 2418 to
perfection, and we should strive to do better in the future,
especially regarding the timeliness of our agenda and minutes.

But, I do not believe that our minor process violations materially
affected the ability of anyone who was involved in the IPv6 WG in
March and April of 2003 (via email and/or in-person) to participate
in this discussion, understand what was going on, or voice his/her
opinion on this issue.  And, I believe that we took all of those
opinions, regardless of how they were voiced, into consideration
as part of our consensus determination.

>This may not seem very important, as there is no apparent outcome from
>this decision.

The outcome from this decision is that our editors are currently
updating WG documents in accordance with the direction that
was agreed upon by the WG.  In my opinion, it does require
WG consensus to make a major change to a WG work item, such as
the scoped address architecture.

>What is important though is that the WG not be railroaded
>into agreeing to a later document (which is rumoured to be going to be
>written one day) with the argument that the WG already reached consensus
>that this be done, and that no re-opening of that issue will be permitted
>(which is what I anticipate may happen).   That is, if this planned
>document ever appears, the only discussion allowed may be whether or
>not it says the right things to implement the supposed consensus, and not
>whether or not the document itself is a good thing to publish.   That
>cannot be allowed to happen, and certainly not based upon the flawed
>processes in this particular instance.

I agree.  This cannot be allowed to happen, and there is no
intention of handling the situation this way.  We have
_repeatedly_ indicated that the March/April decision was
only about the general course of action that the we would
pursue.

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.

>Finally, while not strictly relevant to the current question, you may
>also wish to know that on April 10 (the day after the decision was
>announced), I sent a message to each of the WG chairs (and copied to the
>WG mailing list - Message-id: <[email-masked]>) in which
>I asked ...
>
>         You can expect an appeal against the decision that there is rough
>         consensus here.   What there is, is a debate.    You can treat this
>         message as an official request to the WG chairs that they reconsider
>         the stated position.   That's the first step ...
>
>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.  A multi-person discussion ensued, and I tried to
be responsive to the points raised in that discussion.  It wasn't
my intention to be non-responsive, and I am sorry if you found my
response inadequate.

It is my hope that we can re-focus this discussion on making the
right technical decisions within the IPv6 WG moving forward.  I
would encourage you to read the current documents, which include:

         - The latest scoped address architecture (currently
                 a WG I-D)
         - Bob Hinden's local addressing proposal (accepted as
                 a WG I-D, but not republished yet)
         - The upcoming updates to the local addressing
                 requirements, authored by Fred Templin and
                 Tony Hain (should be available very soon).

Your technical input on these documents would be very welcome.

Margaret

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Mon, 04 Aug 2003 19:02:02 +0700

Date:        Sun, 03 Aug 2003 12:33:08 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

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

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 4 Aug 2003 11:33:13 -0700

kre wrote:
> ....
> 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.

I am looking to have the declaration of consensus repealed. It doesn't
matter if that is done voluntarily by the chair's, or external directive. We
can't allow chairs to be declaring consensus when no one, including the
chair, knows the meaning of the question. Explicitly acknowledging that
there would be multiple meanings for yes as well as no, is not the way to
ask a valid question. Allowing the declaration to stand is handing the chair
a blank-check to tell the WG what it agreed to.

Tony

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Aug 2003 15:40:49 -0400

Tony,

there was strong concensus in the WG to deprecate SL.  by asking for
this declaration to be repealed you are asking for your own will and the
will of a small minority to override the consensus of this WG and the
extended IETF community.  not only would this be a grave technical
error, it would be a gross violation of IETF process.

in short, your request is ridiculous and out-of-order.  and for this WG
to even discuss it is a waste of this group's energy.

we have wasted enough time with this already; we need to stop this
nonsense now.  if there are real problems that we need to solve, let's
solve them, but propagating SL is not part of the solution space.

Keith

> matter if that is done voluntarily by the chair's, or external
> directive. We can't allow chairs to be declaring consensus when no
> one, including the chair, knows the meaning of the question.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 5 Aug 2003 17:33:50 -0700

Keith Moore wrote:
> Tony,
> 
> there was strong concensus in the WG to deprecate SL. 

No, there was a question asked where there would be multiple undefined
meanings for a Yes vote, and multiple undefined meanings for a No vote.
Basically a blank check for the chair to tell the WG what it had decided.

Tony

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Aug 2003 20:44:13 -0400

> meanings for a Yes vote, and multiple undefined meanings for a No vote.

nope.  the question asked was whether we should deprecate SL, and there 
was strong consensus to deprecate SL.  the precise meaning of 
"deprecate" was not nailed down, but Inobody who was there thought that 
"deprecate" meant "it's okay to keep promoting the use of these things".

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Aug 2003 08:44:19 +0300 (EEST)

> Basically a blank check for the chair to tell the WG what it had decided.

That's why we pay the chairs the big bucks. :-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Leif Johansson <[email-masked]>
Date: Wed, 06 Aug 2003 09:10:21 +0200

>Basically a blank check for the chair to tell the WG what it had decided.
On the contrary, I believe that there was strong consensus about the 
nature of
the question. In fact (as I recall) at the meeting in SF there was 
signifficant
discussion about the question posed - there was ample opportunity to 
clear up
any remaining confusion about the question posed.

       MVH leifj

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 Aug 2003 11:31:35 +0100

It's all on video.  Memories and recollections are not required :)

Tim

---

From: Leif Johansson <[email-masked]>
Date: Thu, 07 Aug 2003 13:27:52 +0200

>It's all on video.  Memories and recollections are not required :)

Are you saying that my recollectons are wrong?