Subject: Appeal clarification ...

From: "Tony Hain" <[email-masked]>
Date: Thu, 24 Apr 2003 22:45:30 -0700

Everyone should check out the video at:
ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56 - 03202003
- INT ipv6.mpg  ... Starting at 1:02:05. It is very instructional about
how not to call a question. The claimed consensus was over (and I quote
from the AD & chair 2:18:20) 'just to be clear, deprecate I assume means
...' ... '...we may have to handwave - wave our hands around that a
little bit...'. 

In further discussion with the chairs, the appeal issue is still not
clear. This note attempts to make it clearer, and adds documentation
from the video of the SF session. 

Appeal:
The chairs have asserted an incorrect technical choice which places the
quality and/or integrity of the Working Group's products in significant
jeopardy.

The working group did not make a decision as some of the YES votes were
for removal of local scopes from the architecture, some for removal of
the need for apps to recognize that local scopes exist, others were for
removing ambiguous addresses as SL is currently defined, and others were
for removing the threat of NAT. Those are technically different
architectural concepts requiring different questions. In particular,
local scope addresses are the result of an operational choice, and not
in the purview of the IETF to decide. The IETF can decide to set aside a
well known prefix for that use or not, but removing the well-known
prefix does not mean local scope addresses go away, or that applications
are exempted from handling them correctly. It only means that there is
no consistent way to identify which addresses are local use. 

There is no document identifying the requirements and needs of the
network operators, therefore no reasonable and complete evaluation could
result in the conclusion that deprecation is an appropriate action. The
chairs chose to ask an ambiguous question that the group clearly had
different opinions about the meaning of, and shortly before the initial
question was called there was an explicit statement about lack of
clarity in the consequences of the alternatives. Forcing a YES/NO
question for an end state rather than a process, without a widespread
understanding of the consequences and trade-offs, was an inappropriate
action by the chairs. 

The working group was mislead by an ambiguous question from the chairs.
The asserted conclusion is invalid as the WG has not reached consensus
on anything other than more work needs to be done. 

Background:
The entire open discussion in SF started off misled by a bogus technical
assertion by the chair: 
1:42:04 ... it is always going to be possible to implement wrong unless
we get rid of whole concept of private addresses ... you will always
have the possibility ... for leaking addresses if they exist in the
architecture
	>>> Existence in the address architecture is not what creates
the possibility for limited scope addresses to be leaked, that only
allows identification of them. The thing the creates the possibility for
leaking limited scope addresses outside their realm of applicability is
the ignorance by the applications that the real network has limited
scope addresses and they require appropriate handling. Removing any tag
for the application to identify which addresses have limited scope only
ensures that they will be leaked.

There was no enumeration of the requirements for any solution, therefore
no reasonable and complete evaluation that the current SL is inadequate.

1:06:49 MW - you can only document the cost/benefit analysis of a point
that's understood

1:36:30 - 'Do we have enough information to decide' 
	>>> on slide but not discussed
	>>> discussion about overriding need to reach consensus

1:39:00 - Pekka - Exclusive is just broken ... if we want ...  
	>>> indicates need to understand requirements

	without further analysis, that requirement is met by access
prefix thing
	access prefix is less intrusive and easier to implement
	>>> where is the analysis that backs that up?

1:41:42 - Alain -  ... if we want to avoid leaking  ...
	>>> indicates need to understand requirements

1:50:05 - Erik - we don't have enough information to decide yet, and
part of what I am looking for is so what are the benefits of these
things anyhow
	>>> indicates need to understand requirements

1:52:33 - look at benefits before we try to decide something 
	- MW 'anything we are doing here should be a cost/benefit
tradeoff ... maybe we'll decide we need more information ... we need to
do an intelligent cost/benefit analysis and have a supportable reason
for our choice

1:58:00 Leif - Erik's comments were first time I heard purported
benefits - applications shouldn't have to worry about topology that's a
fundamental comparing the benefits with breaking fundamental assumption
that apps shouldn't care about topology - its clear that you should
eliminate SL
	>>> an informed conclusion after 5 1/2 minutes evaluation of a
partial verbal list of requirements ??? How many others were in the same
place?

2:11:39 Dave - I agree with Keith's attempt to clarify the wording of
the question people are arguing for the eliminate proposal which there
isn't any draft about ...

In fact over the meeting it was clear that there was no common
understanding about what 'deprecate' means even by the chairs, and this
carried onto the list discussion: 

2:09:24 MW - that would be eliminating it, you can always bring
something back later someone can have a research group, but if take it
out of the specs, ** that is what eliminating it means **
2:09:35 Keith - alternate proposal for a way forward - I don't believe
the bit patterns that are defined for SL will be allocated for some
other use so I don't think we are eliminating them entirely, but I want
to know if we can get a sense of the group that discouraging use of SL
is the appropriate way to move forward - part 1   part 2 - identify the
things that SL was supposed to solve and work out alternate solutions
for those 
2:10:20 MW - instead of eliminate I think the right word would be
deprecate because I agree that we are not going to suddenly decide to
use those bits for something else - I agree with you on that but
discouraging  ** is that deprecating? ** 
2:10:35 Keith - deprecating in a sense, it also leaves the idea that
until we find something else, you might have some usage of SL but the
plan is in the future to deprecate it

2:11:39 Dave - I agree with Keith's attempt to clarify the wording of
the question people are arguing for the eliminate proposal which there
isn't any draft about - this is a question to you to clarify the
question - Erik made and Dino added - zero conf asked what do routers do
- do we want to enable a zero config thing - if so do you want to enable
SL in a deprecated sense as Keith put it, for that or is the proposal to
eliminate them and force zero config guys to not work because we don't
care about that, or to force them to use some other well known prefix
clarify which one of those is actually the proposal ?
	>>> questions never answered or even discussed

2:12:51 Christian - if we say that we are going to eliminate SL we have
to actually eliminate it and ** that means ** that we have to make it
explicit that at some point in the future all implementations are
supposed to discard any packets sent to the specific prefix 

2:13:19 MW - I'll resay what I said earlier which is I had said we would
say eliminate it or keep it and then we'd have multiple choices if we
kept it but apparently ** if we eliminate it we will also have multiple
choices about what exactly that means **
	>>> 'multiple choices' how does that indicate a clear meaning
???

2:13:31 Erik - I think there area some details about what it means if we
actually choose to eliminate ** I think that means ** that people at
their leisure can go ahead and delete whatever code they have that
currently recognizes FEC0 but they don't have to do it tomorrow, because
we are not going to allocate this for any other purpose in the near
future, but it means that you don't have to add any more code, but you
can at your leisure delete what you have

2:14:05 Brian - I got up to say that the question that you were going to
ask is one that ** I would have difficulty answering because I wouldn't
vote for keeping SL unless I knew which of the options we were going to
go for **
	>>> though voting against without understanding the consequences
didn't appear to be a problem

2:16:09 Bound - IPv4 NAT is a national security problem, at least in the
US so ** what I am hearing to day is we should stop it and not give any
credence to help proliferate them ** 
	>>> a belief that removing SL removes the threat of NAT ???

2:16:45 Keith - ... ** the real trick is ** that applications shouldn't
have to special case these things, Dns shouldn't have to special case
them, routing shouldn't; have to special case these things 
	>>> in other words applications continue to ignore the reality
of limited scope addresses, because without a well-known tag it is
impossible to special case them

2:18:20 Thomas, just to be clear, ** deprecate I assume means **
somewhere to the left of the limited use model 
	- MW Yes, somewhere to the left of limited, the bits would
somehow become deprecated but probably you wouldn't get to reuse them
and we would not want to invalidate existing implementations so we may
have to wave our hands around that a little bit to make sure we do it
right - Bob, Christian just added - and probably needed to be blackholed
	>>> 'somewhere to the left'; 'somehow be deprecated'; & '...may
have to hand wave...' those are not clear indications of the meaning of
the question or consequences of this action.

4/2 JB - Ambiguous addresses are a nightmare...
	>>> a common theme

4/5 MW - The proposal is to deprecate a prefix in the addressing
architecture for which we have found no suitable use.
	>>> Translation - we refuse to acknowledge the uses in shipping
code, though we do acknowledge that there is shipping code which uses
them.

4/5 DL - I thought we were voting on something more meaningful, i.e.,
site-locals  themselves.  Now I understand that site-locals do not exist
as such and we were just voting on the deprecation of the prefix itself.

4/7 AW - I have come to the conclusion that the consensus call email on
the list failed to adequately  describe what a YES for deprecation
actually entailed, and has pretty effectively shot itself in the foot.

4/4 HA - Note: By "Deprecate Site-Local", ** I mean ** "Do not require
any application, host, router, protocol or IETF practice to have to make
special 
consideration for the idea that an IPv6 unicast address outside of the 
link-local range can refer to two different hosts".

4/4 PF - So, when I say I want Site Local deprecated ** I mean ** I want
routing and addressing separated, and given that separation, we have to
work on 
solving the real problems we have with Internet today

While there was no single clear statement about what deprecate means
(though many architecturally different assertions), there was a clear
overriding concern by the chairs that some conclusion be reached, even a
bad one:
2:07:43 Erik - call for comments for SL     Bob - give us a second here
MW - if we are going reach any conclusion we can't accept a sudden
influx at mic 
2:08:45 Bob - if you want to support SL independent of usage model come
to the mic 2:15:22 Bob by the way... MW cut off> we have to cut off
discussion with the people who are at the mic because we have to try to
have some conclusion
	>>> where was the fire? If the question had not been called in
SF, would the world have ended? Allowing 7 1/2 minutes for rebuttal
comments to a discussion that was not on the agenda, there were no
documents published, and people did not come to the meeting prepared to
discuss is inappropriate in any case. Cutting off discussion just as
people were getting their thoughts together to form reasonable
statements about requirements is improper meeting management and biases
any attempt to measure consensus.

Despite the lack of agreement about exactly what deprecate means, there
was a comment: 
2:17:19 MW - lets see, just a sec ... we are going to call a question
and the question is going to be a yes no question do we want to
deprecate SL addresses or do we not want to deprecate SL addresses - we
realize that both of those answers no matter which answer you give there
is more details that need to be worked out, but we are trying to get
what is the direction, does the group want to go away from SL
addressing, deprecate it work out how to get it out, does the group want
to keep it and figure out what the right usage model is for it OK, this
is a usage model issue. its is like do we want to support usage of SL
and come up with a usage model for it, or do we want to deprecate it

which was not made to the mail list consensus call. 

	>>> There is a vast difference between identifying direction of
the group and the actual yes/no to deprecate SL question that was asked.
In fact all other indications from the chairs were that the question was
NOT about measuring direction of the WG, but actually about their intent
to have local scoped addresses removed from the scoped address
architecture and other documents.

	>>> This drive for a decision despite multiple statements (by
the chairs no less), that a cost/benefit analysis can only be done with
a complete set of requirements. Where is the supportable reason for the
asserted choice to change the architecture? For that matter, where is
the requirements document that a supportable reason would be built from?

In preparing the question, it should have been clear that the chairs
were not thinking this though clearly: 
2:18:57 Perry when you say it is a yes or no question, therefore it must
be phrased differently than do we wish to deprecate them or do we not
wish to deprecate them 
- MW I am tired, did I actually say that?

Yet seconds later:
2:19:20 MW Question - show of hands, how many people think that we
should deprecate SL addressing?

Keith's wording at 2:09:35 would have been an appropriate pair of
questions for the chairs to ask (I acutally support part 2), but the
chairs chose to ask an ambiguous question that the group (and even the
chairs) clearly had different and inconsistent opinions about the
meaning of. Shortly before the question was called there was an explicit
statement about lack of clarity about the consequences of the
alternatives. The fact that many of the YES responses were about removal
of local scope addresses invalidates the asserted conclusion. The
existence of limited scope addresses are an architectural consequence of
operational choices, and not in the purview of the IETF to decide. 

Tony

PS: 2:14:05 Brian ... I also a comment that RFC 1597 is one of the worst
end runs in the history of the IETF. 
	>>> I am arguing that through an ambiguous question this
desperate drive for a conclusion which intends to remove local scope
addresses from the architecture superseded it.

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