Subject: FW: Consensus on Site-Local Addressing

From: "Tony Hain" <[email-masked]>
Date: Wed, 9 Apr 2003 17:41:32 -0700

Thomas & Erik,

Please consider this the second step in the appeal process, as I have
already discussed these issues with the chairs on more than one
occasion. 

'we reject kings, presidents and voting...'
The consensus measurement on the mail list was much more indicative of
the real lack of it (60/40%), than what was effectively ballot stuffing
by WG visitors without a complete context. There was a very short
presentation in the apps open area, intended to raise concerns and
incite involvement, were those in the apps area were agitated, then
invited to the IPv6 WG session in SF to discuss the potential issues.
The subsequent short discussion in the IPv6 WG showed there were issues
to work through, and at least one question voiced about understanding
the requirements. Rather than deal with the issues raised, the chairs
decided to call an ambiguous question of yes/no for deprecation. 

While the chairs do in 2) recognize their interpretation of the
consensus that the WG will investigate other forms of local addressing,
there is no mention of ambiguity and the rest of the wording of 1) & 2)
can be interpreted as local scope addressing is deprecated. The concern
is that we will end up with a document lacking local scope addressing,
and claims that we had consensus to remove local scope from the
architecture. Many of those who bothered to state why they were
expressing a yes opinion claimed ambiguity was the reason, while others
were only interested in removing special handling for local scope
addresses. Those are technically different issues, so they need
different questions. What we have is an indication that many are unhappy
with the status quo, but a lack of recognition that the call ended up
combining yes opinions for removing ambiguity with yes opinions for
removing local scope addresses from the architecture. From subsequent
discussions with the chairs, it is clear that was not their intent, but
never the less that is the result of the lack of clarity in this
consensus call.

'... we believe in rough consensus & running code' & from the Tao :
'running code wins'
On several related mail threads there were many comments about running
code, and at least Brian Zill & Brian Haberman said they collectively
had host, application, and router implementations of the current SL
running. Point 3) even acknowledges there are existing implementations.
This consensus call intends to invalidate the running code, and all we
have to replace it is a promise in 4) that if the group can ever agree
that operational requirements of the site network manager are worth
solving, we might start to work on solutions, subject to appropriate
charter updates. This whole discussion is based on the argument that
some developers couldn't create running code for an arguably bogus
scenario where topology locators are blindly passed outside their scope
of relevance. Bias was given to the opinions of those with a lack of
running code, at the expense of, and with the specific intent of
invalidating the code that exists.

There were also claims in the meeting and mail threads that we have
analyzed site local as currently defined, and it doesn't meet the
requirements. At the same time, there is a recognition by many of the
same people that we need to develop a complete set of requirements. It
should be obvious that the analysis is flawed if the complete set of
requirements are not understood first. To that end, and in the spirit of
making progress, draft-hain-ipv6-sitelocal-00.txt was processed by the
I-D editor on 4/8, and is offered as an attempt to document the
requirements for address space with a local scope of relevance. It is
clearly incomplete, and largely based on my previous email on the
subject. 

While I contest the claim that the Yes/No opinions expressed measured
consensus for a consistent interpretation of what 'deprecate site local
addresses' means, I do believe that a set of work items for the group
were identified. It is also clear that we can add new work to a group at
any time, without the need to remove existing items first. I agree with
the chairs that items 4) & 5) are valid outcomes of the subsequent
discussion, though one thing that their interpretation of the result
does not make clear is the meaning of 'accomplish the following things
in parallel:'. In talking to the chairs it appears the intent is to
start the work at the same time, but we need to avoid invalid transition
states, so parallel needs to mean that all 5 are to be forwarded to the
IESG at one time. In particular, without solutions to the requirements
in hand, any documents for 1) & 3) that intend to deprecate the only
local use address space will simply create chaos, and might need to be
rescinded if the complete set of requirements shows a need with no other
technical approach.

In short, I do not believe the consensus call measured the opinions that
were consistent the chairs interpretation of the question, so the
claimed results are invalid. I do believe that the effort identified
work items 4) & 5), with the potential that 1) & 3) might follow if
there are no outstanding requirements for ambiguous address space. I
question the wisdom of 2), but will reserve judgment until the complete
text identifying further work is spelled out. In any case, I hope this
appeal can be dealt with at this level, and that the overall effort
results in an expedited charter update. It is imperative that new
approaches exist prior to removal of the current, and there is a very
real danger that the current destructive energy will dissipate in the
face of the hard work of creating replacements.

Tony

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bob 
> Hinden & Margaret Wasserman
> Sent: Wednesday, April 09, 2003 3:11 PM
> To: [email-masked]
> Subject: Consensus on Site-Local Addressing
> 
> 
> Hi All,
> 
> Well, that was fun!  :-)
> 
> 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).
> 
> There were also a significant number of the people on both 
> sides of this 
> issue that voiced (in their original responses, or in 
> subsequent messages) 
> a strong belief that we should investigate alternative 
> mechanisms for local 
> addressing and local access control.
> 
> The chairs have read all of the messages on the list, and 
> based on your 
> considerable input, we have determined that the IPv6 WG does 
> have rough 
> consensus to deprecate the usage of IPv6 site-local unicast 
> addressing AND 
> to investigate alternative mechanisms for local addressing 
> and local access 
> control.
> 
> In particular, the IPv6 WG will work to accomplish the 
> following things in 
> parallel:
> 
>    (1) Publish an informational document that explains the issues
>        encountered with site-local addressing and our reasons
>        for deprecating IPv6 site-local unicast addresses.  This
>        document will officially deprecate site-local addressing.
> 
>    (2) Remove site-local unicast addressing from the IPv6
>        scoped addressing architecture I-D, and publish the
>        parts of the document on which we do have consensus
>        (i.e., link local addresses, multicast, etc.).  This
>        will include a note that the IPv6 working group is
>        investigating other forms of local IPv6 addressing and
>        that the usage of any new forms of local addresses will be
>        documented elsewhere.
> 
>    (3) Update the IPv6 addressing architecture to indicate that the
>        usage of the FECO::/10 prefix for site-local addressing is
>        deprecated.  To maintain backward compatibility with existing
>        implementations the prefix should be reserved and should not
>        be allocated for other purposes.
> 
>    (4) Define and publish the requirements for a local addressing
>        mechanism to provide:
>          - Addresses for disconnected networks.
>          - Addresses for intermittently connected networks.
>          - Addresses that support merging of sites.
>          - Stable local addresses for changing ISPs without
>            disrupting local communication.
>        Once we have consensus on the requirements, the IPv6
>        WG will work on solutions for local addressing that
>        meet those requirements.
> 
>    (5) Define and publish the requirements for a local access
>        control mechanism, then work on a solution that meets
>        those requirements.
> 
> Each of these new work items will need to be added to the 
> IPv6 WG charter 
> and will go through the normal IETF document processes.  For 
> (4) and (5) it 
> is important to make the rest of the IETF community aware 
> that the IPv6 WG 
> is undertaking these tasks, so we will consider methods to 
> invite wider 
> review and discussion of these problems.
> 
> IPv6 site-local addressing has been a contentious issue in 
> the IPv6 WG for 
> some time, and we are both glad to see the WG reach consensus on this 
> issue.  This will allow us to complete and publish the IPv6 scoped 
> addressing architecture document, an important part of the 
> IPv6 specification.
> 
> We hope that people on all sides of this issue will respect the rough 
> consensus of the WG, and will work with us to achieve the 
> goals outlined above.
> 
> Thanks to everyone who expressed an opinion during this discussion.
> 
> Bob Hinden & Margaret Wasserman
> IPv6 WG Chairs
> 	
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: Leif Johansson <[email-masked]>
Date: Thu, 10 Apr 2003 07:08:31 +0200

>the real lack of it (60/40%), than what was effectively ballot stuffing
Please note that the consensus call on the mailinglist explicitly called 
for those that
expressed their opinion during the show of hands at the meeting _not_ to 
vote. The
figures you quote doesn't take this into account. But even so the 
numbers you quote
clearly does not constitute rough consensus for *keeping* site-locals, 
or as Kurt
Zeilenga put it "contention is out of scope".

       leifj

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 10 Apr 2003 18:29:40 +1000

On Wed, Apr 09, 2003 at 05:41:32PM -0700, Tony Hain wrote:
> were identified.

I reckon that's not such a bad conclusion really:  I would
have preferred "choose replacement X; deprecate SLA in 
favour of X", but I'm happy enough with "Deprecate SLA;
choose replacement X" so long as the latter actually gets
supported.

I think there's been some really constructive work towards
various candidate Xs in the many side-threads too.

-----Nick

---

From: Scott Bradner <[email-masked]>
Date: Thu, 10 Apr 2003 08:10:57 -0400 (EDT)

> But even so the numbers you quote

I would think that the issue is 'is there consensus to remove something
that is currently in the spec'  - i.e., the removal of an established 
feature needs strong support, the default is to keep it.

(note that the above observation is not a comment on the specific 
question, it is comment on proper process in the IETF)

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Apr 2003 15:15:13 +0200

See my comments on the list in response to Robert Elz for
why I think this appeal is misguided. I think we should just get
on with the work at this point. Anything else is a distraction
and ultimately harmful to IPv6.

   Brian

---

From: Thomas Narten <[email-masked]>
Date: Thu, 10 Apr 2003 11:56:22 -0400

Tony,

> already discussed these issues with the chairs on more than one

Discussing general issues with the chairs is not the same as finding
disagreement with a specific action that the chairs have taken. I
suspect you have done the former, but not the latter. If you feel that
the chairs have erred, and that they have taken an action that isn't
supported by the processes as outlined in RFC 2026 (and RFC 2418), an
appeal might be warranted. To file an appeal, the process is outlined
in RFC 2026. Start with the chairs, use RFC 2026/2418 as a guide for
what are appropriate grounds for an appeal, and be clear about what
action (or inaction) you specifically have issue with and want
reconsidered. Suggesting what remedy you believe is appropriate would
also be useful.

Thomas

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 10 Apr 2003 10:04:41 -0700

Thomas Narten wrote:
> Discussing general issues with the chairs is not the same as 
> finding disagreement with a specific action that the chairs 
> have taken. I suspect you have done the former, but not the 
> latter. If you feel that the chairs have erred, and that they 
> have taken an action that isn't supported by the processes as 
> outlined in RFC 2026 (and RFC 2418), an appeal might be 
> warranted. To file an appeal, the process is outlined in RFC 
> 2026. Start with the chairs, use RFC 2026/2418 as a guide for 
> what are appropriate grounds for an appeal, and be clear 
> about what action (or inaction) you specifically have issue 
> with and want reconsidered. Suggesting what remedy you 
> believe is appropriate would also be useful.

Well I did specifically discuss a disagreement with the action of the
chairs in calling the ambiguous question, but I will accept this
deferral and redirect the current appeal comment to the chairs. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 10 Apr 2003 11:16:38 -0700

Brian E Carpenter wrote:
> ...
> why I think this appeal is misguided. I think we should just 
> get on with the work at this point. Anything else is a 
> distraction and ultimately harmful to IPv6.

While I agree we should get on with the work, confusing the network
managers of the world is the act that will be harmful to IPv6. We have
been claiming for some time now that the specs are stable and people
should be planning their deployments. An arbitrary act by the IPv6 WG to
declare site controlled address space as 'not to be used' is
significantly more damaging because it invalidates the plans of those
who bothered to start. This will only lead to bad press about IPv6 not
being ready for prime-time since the WG is not providing a viable
alternative. 

We do not need to call another question, because the discussion has
identified work to be done in the chair's items 4) & 5). If that work
provides appropriate alternatives, and there is no further need for the
current SL, then it is appropriate to deprecate it. Until then, actions
that remove a tool from a network managers hand without an acceptable
replacement, will only serve to delay IPv6 deployments.

We agree on the goal, but the specific course of action by the chairs
was inappropriate in this case.

Tony

---

From: Tim Chown <[email-masked]>
Date: Thu, 10 Apr 2003 20:01:50 +0100

On Thu, Apr 10, 2003 at 11:16:38AM -0700, Tony Hain wrote:
> should be planning their deployments. 

So who has actually deployed site-local addressing/routing on their sites?  

Tim

---

From: Ralph Droms <[email-masked]>
Date: Thu, 10 Apr 2003 15:09:12 -0400

>So who has actually deployed site-local addressing/routing on their sites?  

And what were the operational experiences?  What worked, what broke, etc.

It would be good to get some input based on experience as a counterweight
to speculation...

- Ralph

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 10 Apr 2003 12:24:40 -0700

> So who has actually deployed site-local addressing/routing on 

It is not my place to announce deployments, but at least Microsoft & kre
have said on this list they have deployed and use SL. My point was
targeted at those who are planning deployments. I have talked to
customers who consider a stable address block, independent of their
provider(s) to be a top priority. Yanking the defined non-PA space will
only cause them to pick random numbers, or turn the documentation space
into a different instance of ambiguous space. 

Tony

---

From: Robert Elz <[email-masked]>
Date: Fri, 11 Apr 2003 03:02:08 +0700

Date:        Thu, 10 Apr 2003 15:09:12 -0400
    From:        Ralph Droms <[email-masked]>
    Message-ID:  <[email-masked]>

  | At 08:01 PM 4/10/2003 +0100, Tim Chown wrote:
  | >So who has actually deployed site-local addressing/routing on their sites?

I have.
 
  | And what were the operational experiences?  What worked, what broke, etc.

A few implementation bugs (NetBSD (KAME) doesn't (didn't) send an ICMP
when packets attempted to leave the site, they were dropped silently)
but aside from that, nothing broke that I use - everything worked / works.

I am not trying to run a site containing nodes that are also in other
sites though, I don't have a topology that requires that.

I am however not using SLs in the way that many people imagine them, there
are no SL addresses in the DNS (well, none aside from a few for explicit
testing with names line foo-sl where there are only SL addresses).

  | It would be good to get some input based on experience as a counterweight
  | to speculation...

Yes.  It would.

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Apr 2003 21:21:27 -0400

Hi Robert,

>If one really wanted a vote (which I don't think is the correct answer
>anyway, for anything) the right way to do it on the list would be to
>ask everyone with an opinion to express it on the list.   Then there
>would be a simple record, and everyone could add up the numbers and
>verify them.

Actually, RFC 2418, section 3.3 explicitly 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."

Margaret

---

From: Robert Elz <[email-masked]>
Date: Thu, 10 Apr 2003 16:56:07 +0700

Date:        Thu, 10 Apr 2003 07:08:31 +0200
    From:        Leif Johansson <[email-masked]>
    Message-ID:  <[email-masked]>

  | Please note that the consensus call on the mailinglist explicitly called 
  | for those that expressed their opinion during the show of hands at
  | the meeting _not_ to vote.

That was a plain silly decision, if that's how it was done.   No-one knows
just who raised their hands in a WG meeting (I assume) - I doubt that there
was even a very accurate count done.  I wasn't at that meeting, but I've
been at many others where similar things have been done - it is almost
impossible to count raised hands, and I've never seen anyone attempt to
make a list of who held up hands on each side of a debate.

  | But even so the  numbers you quote
  | clearly does not constitute rough consensus for *keeping* site-locals, 

It has been previously ruled (and correctly I believe, though it was
on a proposal I was making for a change) that a consensus is needed to
change the architecture, not to retain it.   in the absence of a consensus
things should stay as they are.

That's what seems to have happened here (even assuming the published
numbers, that's not rough consensus).

kre

ps:  Thomas, Eirk, I support Tony's appeal, I'll be making a similar
one, assuming the chairs reject the request I have just made that they
undo this bogus decision.