Discussion:
Response to appeal by Tony Hain on site-local issue
The IESG
2003-09-30 18:44:30 UTC
Permalink
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
Tony Hain
2003-10-09 23:59:38 UTC
Permalink
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
>
Harald Tveit Alvestrand
2003-10-10 01:54:08 UTC
Permalink
Tony,

speaking only for myself:

I am saddened to see the length to which you are willing to go in
attempting to use process mechanisms to overturn a technical WG decision to
which you do not agree.

After reviewing the video, I personally concluded that *no matter what the
merits of the case*, the WG had clearly made a decision. My judgment of the
the form of the discussion was that it was an informed one; my judgment of
the arguments raised was that it was a correct one.

But there's absolutely no doubt in my mind that the WG made a decision, and
that the chairs were procedurally correct in recording that decision as the
outcome of the meeting.

That is, after all, what you claimed to be appealing.

Harald


--On 9. oktober 2003 16:59 -0700 Tony Hain <alh-***@tndh.net> wrote:

> 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.
Michel Py
2003-10-10 02:14:02 UTC
Permalink
Harald,

> Harald Tveit Alvestrand
> But there's absolutely no doubt in my mind that the WG made a
> decision, and that the chairs were procedurally correct in
> recording that decision as the outcome of the meeting.

There many people, including some that actually _wrote_ the procedures,
that disagree with you. As of myself, I am not completely happy with the
way Tony has worded his appeal (although I do agree with it), which is
why I will file one on different grounds as soon as this one as been
ruled. Since it appears that there is a waiting list to file an appeal
on this matter, I am sure that we will be entertained for the next two
or three years to come.

Michel.
Thomas Narten
2003-10-10 15:59:37 UTC
Permalink
Michel,

> There many people, including some that actually _wrote_ the procedures,
> that disagree with you.

This is FUD. If there are people that agree with Tony's appeal, let
them speak for themselves. In all the email on this thread (and the
many conversations I have had with folk), I have had a _very_ hard
time seeing anyone truly supporting Tony's appeal (with the exception
of kre, who posted specifically in support of it). Scott Bradner has
already posted separately clarifying his views.

And let's be very clear. Disagreeing with the decision to deprecate is
not the same thing as agreeing with Tony's appeal. His appeal is very
specific and focuses on a process question. One can disagree with the
the decision to deprecate and simultaneously disagree with the
appeal. Not to beat an obvious point, one can't just appeal a decision
because one doesn't like it, one has to have specific reasons (as
listed in 2026).

> As of myself, I am not completely happy with the
> way Tony has worded his appeal (although I do agree with it), which is
> why I will file one on different grounds as soon as this one as been
> ruled. Since it appears that there is a waiting list to file an appeal
> on this matter, I am sure that we will be entertained for the next two
> or three years to come.

You might want to consult RFC 2026. There is a statute of limitations
with regards to appeals:

> All appeals must be initiated within two months of the public
> knowledge of the action or decision to be challenged.

If you are waiting to see the results of the current appeal before
filing yet another one, you'd better have grounds other than issues
with the original actions some months ago. A statute of limitations is
apparently a necessary thing (unfortunately), precisely to prevent
issues from dragging out over "the next two or three years to come".

Popping up a level, there's a more basic thing that I fail to
understand about this appeal. If the decision to deprecate was so
wrong and flawed, how does one explain that the community seems to
support it? From some of Tony's notes, one would think that process
ran amok in this case with a horrible end result that goes against the
will of the WG. But I don't see the community agreeing with that view.
E.g., see a recent note from the IPv6 chairs on the subject
(appended). From it, it is clear that there is strong community
support to deprecate SLs. Thus, the idea that the consensus call was
fatally flawed, that the community doesn't support the decision and
that we consequently somehow need to reset the clock and pretend that
the last 6 months didn't happen and that we must start the entire
conversation over about what to do with SLs just doesn't make any
sense to me.

Thomas

From: Bob Hinden & Brian Haberman <***@iprg.nokia.com>
To: ***@ietf.org
Cc: ***@iprg.nokia.com, Brian Haberman <***@innovationslab.net>
Date: Tue, 16 Sep 2003 10:55:33 -0700
Subject: Results of Poll

The results of the poll (appended below) started by the chairs in early
August to get more feed back from the working about how to deprecate
site-local are as follows:

Preference A 32 45%
Preference B 31 44%
Preference C 8 11%
--------------------------
Total Votes 71 100%

The raw votes are available at:

http://people.nokia.net/~hinden/ipv6-choices.html

If we missed your preference or got it wrong, please let us know.

There are a few conclusions that can be seen in this poll.

Only 11% of the people responding wanted to defer the deprecation of
site-local until an alternative was deployed. 89% wanted to deprecate
prior to an alternative being standardized or at the same time an
alternative was standardized.

There was not a consensus about tieing the deprecation of site-local to
defining an alternative or do the deprecation before defining an
alternative. The working group is closely split on this. Even combing
preferences B & C (i.e., 55%) does not form a consensus.

Based on this, the chairs will plan to move the deprecation document and
the local addressing specification forward at approximately the same time,
but will not do anything to officially tie them together.

Bob Hinden / Brian Haberman
IPv6 w.g. chairs



>Date: Mon, 04 Aug 2003 11:06:55 -0700
>To: ***@sunroof.eng.sun.com
>From: Bob Hinden <***@IPRG.nokia.com>
>Subject: Moving forward on Site-Local and Local Addressing
>Cc: ***@iprg.nokia.com
>
>[IPv6 working group chair hat on]
>
>I think the working group has been making good progress on replacing
>site-local addresses and wanted to get feed back from the working group on
>how we should move forward. This is not intended to directly relate to
>the ongoing appeal of the working groups decision to deprecate the usage
>site-local addresses, but to get feedback on how to proceed. I think it
>is very important that we move forward on this issue and not rehash what
>has happened in the past.
>
>We now have a combined local addressing requirements document
><draft-hain-templin-ipv6-limitedrange-00.txt>, a specific alternative to
>site-local addresses draft <draft-hinden-ipv6-global-local-addr-02.txt>
>(accepted as a working group item at the Vienna IETF), and will soon have
>a draft describing why site-local addresses are being deprecated and doing
>the formal deprecation (authors identified and outline discussed at the
>Vienna IETF). Note that all of these documents will proceed through the
>normal working group and IETF processes of last calls and review.
>
>I think legitimate questions have been raised about how the working group
>should go about deprecating site-local addresses given their maturity in
>the current specifications and use in deployed products. Specifically
>should they be deprecated independently from having an alternative
>solution available, at the same time an alternative is available, or
>sometime after an alternative is available. A forth alternative is to not
>replace site-local addresses in any form, but I think the working group
>has made it clear that this is not a reasonable alternative.
>
>I would like to hear from the working group on how we should proceed. I
>think the choices are:
>
>A) Deprecate Site-Local addresses independently from having an alternative
>solution available. This would mean that the working group should treat
>the deprecation, and requirements and solution documents outlined above
>independently from each other. If there was no consensus on an
>alternative a replacement would not happen.
>
>B) Deprecate Site-Local addresses at the same time as a alternative
>solution is agreed to. This would mean advancing both documents at the
>same time and making them include normative references to each other to
>insure that they were published at the same time. This would result in
>the deprecation only happening if a consensus was reached on an alternative.
>
>C) Deprecate Site-Local addresses after an alternative is defined,
>standardized, and in operational practice. This would mean not advancing
>a deprecation document until there was operational evidence that the
>alternative was working and shown to be an improvement over Site-Local
>addresses.
>
>Note: In the above choices "Deprecate Site-Local addresses" means
>publishing an RFC that does the formal deprecation.
>
>Please respond to the list with your preference, or if there is an
>alternative approach that is an improvement from the ones I outlined. I
>hope that many of you will respond.
>
>Thanks,
>Bob




--------------------------------------------------------------------
IETF IPv6 working group mailing list
***@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Tony Hain
2003-10-10 18:04:50 UTC
Permalink
Thomas Narten wrote:
> ...
> Popping up a level, there's a more basic thing that I fail to
> understand about this appeal. If the decision to deprecate was so
> wrong and flawed, how does one explain that the community seems to
> support it?

You are listening to a very limited subset of the 'community'. I have had
several questions from fortune 500 network managers as to 'what now?' They
plan to roll out IPv6 with addresses that are in either the FEC0 range
anyway, or are trusting that the proposed replacement FC00 will be finalized
soon.

> From some of Tony's notes, one would think that process
> ran amok in this case with a horrible end result that goes against the
> will of the WG. But I don't see the community agreeing with that view.
> E.g., see a recent note from the IPv6 chairs on the subject
> (appended). From it, it is clear that there is strong community
> support to deprecate SLs.

Take the biased questions in context, all choices started with 'Deprecate
Site-Local ...' You can get any answer you want as long as you get to frame
the question and later define what the answer means.

Tony

> Thus, the idea that the consensus call was
> fatally flawed, that the community doesn't support the decision and
> that we consequently somehow need to reset the clock and pretend that
> the last 6 months didn't happen and that we must start the entire
> conversation over about what to do with SLs just doesn't make any
> sense to me.
>
> Thomas
>
> From: Bob Hinden & Brian Haberman <***@iprg.nokia.com>
> To: ***@ietf.org
> Cc: ***@iprg.nokia.com, Brian Haberman <***@innovationslab.net>
> Date: Tue, 16 Sep 2003 10:55:33 -0700
> Subject: Results of Poll
>
> The results of the poll (appended below) started by the chairs in early
> August to get more feed back from the working about how to deprecate
> site-local are as follows:
>
> Preference A 32 45%
> Preference B 31 44%
> Preference C 8 11%
> --------------------------
> Total Votes 71 100%
>
> The raw votes are available at:
>
> http://people.nokia.net/~hinden/ipv6-choices.html
>
> If we missed your preference or got it wrong, please let us know.
>
> There are a few conclusions that can be seen in this poll.
>
> Only 11% of the people responding wanted to defer the deprecation of
> site-local until an alternative was deployed. 89% wanted to deprecate
> prior to an alternative being standardized or at the same time an
> alternative was standardized.
>
> There was not a consensus about tieing the deprecation of site-local to
> defining an alternative or do the deprecation before defining an
> alternative. The working group is closely split on this. Even combing
> preferences B & C (i.e., 55%) does not form a consensus.
>
> Based on this, the chairs will plan to move the deprecation document and
> the local addressing specification forward at approximately the
> same time,
> but will not do anything to officially tie them together.
>
> Bob Hinden / Brian Haberman
> IPv6 w.g. chairs
>
>
>
> >Date: Mon, 04 Aug 2003 11:06:55 -0700
> >To: ***@sunroof.eng.sun.com
> >From: Bob Hinden <***@IPRG.nokia.com>
> >Subject: Moving forward on Site-Local and Local Addressing
> >Cc: ***@iprg.nokia.com
> >
> >[IPv6 working group chair hat on]
> >
> >I think the working group has been making good progress on replacing
> >site-local addresses and wanted to get feed back from the
> working group on
> >how we should move forward. This is not intended to directly relate to
> >the ongoing appeal of the working groups decision to deprecate the usage
> >site-local addresses, but to get feedback on how to proceed. I think it
> >is very important that we move forward on this issue and not rehash what
> >has happened in the past.
> >
> >We now have a combined local addressing requirements document
> ><draft-hain-templin-ipv6-limitedrange-00.txt>, a specific alternative to
> >site-local addresses draft <draft-hinden-ipv6-global-local-addr-02.txt>
> >(accepted as a working group item at the Vienna IETF), and will
> soon have
> >a draft describing why site-local addresses are being deprecated
> and doing
> >the formal deprecation (authors identified and outline discussed at the
> >Vienna IETF). Note that all of these documents will proceed through the
> >normal working group and IETF processes of last calls and review.
> >
> >I think legitimate questions have been raised about how the
> working group
> >should go about deprecating site-local addresses given their maturity in
> >the current specifications and use in deployed products. Specifically
> >should they be deprecated independently from having an alternative
> >solution available, at the same time an alternative is available, or
> >sometime after an alternative is available. A forth alternative
> is to not
> >replace site-local addresses in any form, but I think the working group
> >has made it clear that this is not a reasonable alternative.
> >
> >I would like to hear from the working group on how we should proceed. I
> >think the choices are:
> >
> >A) Deprecate Site-Local addresses independently from having an
> alternative
> >solution available. This would mean that the working group should treat
> >the deprecation, and requirements and solution documents outlined above
> >independently from each other. If there was no consensus on an
> >alternative a replacement would not happen.
> >
> >B) Deprecate Site-Local addresses at the same time as a alternative
> >solution is agreed to. This would mean advancing both documents at the
> >same time and making them include normative references to each other to
> >insure that they were published at the same time. This would result in
> >the deprecation only happening if a consensus was reached on an
> alternative.
> >
> >C) Deprecate Site-Local addresses after an alternative is defined,
> >standardized, and in operational practice. This would mean not
> advancing
> >a deprecation document until there was operational evidence that the
> >alternative was working and shown to be an improvement over Site-Local
> >addresses.
> >
> >Note: In the above choices "Deprecate Site-Local addresses" means
> >publishing an RFC that does the formal deprecation.
> >
> >Please respond to the list with your preference, or if there is an
> >alternative approach that is an improvement from the ones I outlined. I
> >hope that many of you will respond.
> >
> >Thanks,
> >Bob
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
Eugene M. Kim
2003-10-10 18:52:05 UTC
Permalink
Tony Hain wrote:

>You are listening to a very limited subset of the 'community'. I have had
>several questions from fortune 500 network managers as to 'what now?' They
>plan to roll out IPv6 with addresses that are in either the FEC0 range
>anyway, or are trusting that the proposed replacement FC00 will be finalized
>soon.
>
>

With all due respect, it seems that it would be beneficial for both
camps (for and against SL) to hear, even now, the real concerns directly
from the operation people and to let them participate in the decision
themselves. I'm afraid isn't particularly effective nor or appealing
just to claim `There are many people who are silent now but have their
stake in SL and would be jeopardized by this decision,' when the
discussion and decision processes have been open to the public. I'm
sure that the IAB and the IESG would also be happy to hear opinions
directly from them, because that will give a clearer and broader view.

It'd be a totally different story though, if you officially represented
a group of operation people when you opposed SL deprecation. I
apologize if this was indeed the case.

Regards,
Eugene
Leif Johansson
2003-10-10 21:30:55 UTC
Permalink
Eugene M. Kim wrote:


<snip>

|
| With all due respect, it seems that it would be beneficial for both
| camps (for and against SL) to hear, even now, the real concerns directly
| from the operation people and to let them participate in the decision
| themselves. ... <snip>

Been there. Done that. Didn't work. This vast Moral Majority of the
Site-Locals either don't exist or live entierly behind NATs or other
boxes which prevent them from receiving the call to arms to participate
in the debate. ;-)

Cheers Leif
Stephen Sprunk
2003-10-10 20:23:55 UTC
Permalink
Thus spake "Leif Johansson" <***@it.su.se>
> Been there. Done that. Didn't work. This vast Moral Majority of the
> Site-Locals either don't exist or live entierly behind NATs or other
> boxes which prevent them from receiving the call to arms to participate
> in the debate. ;-)

Or we all just got sick of the bickering and accepted defeat (unlike Tony).

For the record, I can't support deprecating site locals until we have
something else approved to replace them -- at which point I say good
riddance. There are several drafts in the WG to that end which haven't
gained any momentum thus far.

S

Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
Eliot Lear
2003-10-10 20:40:38 UTC
Permalink
Stephen Sprunk wrote:
> Or we all just got sick of the bickering and accepted defeat (unlike Tony).
>
> For the record, I can't support deprecating site locals until we have
> something else approved to replace them -- at which point I say good
> riddance. There are several drafts in the WG to that end which haven't
> gained any momentum thus far.

And this is why the appeal is in my opinion untimely. The working group
has not yet been given a chance to provide any documentation on that
"What next?" question Tony asked. For the IESG or the IAB to interfere
at this stage would be micromanagement.

But here we are. Tony has decided to push an appeal of a "vote", and
not even one that generated a document. That the appeal has even gotten
this far seems is a flaw in the process.

Had the IESG been able to disallow the appeal, simply on this basis,
then perhaps the working group could actually provide documents about
which we could argue over technical merit. As it stands, I predict yet
another round of appeals once IETF last call closes, and the document is
reviewed by the IESG.

Welcome to Court TV, IETF style.

Eliot
Brian E Carpenter
2003-10-13 10:24:19 UTC
Permalink
I believe that the best outcome for the IETF, and for its constituency,
including enterprise network operators, is for the IPv6 WG to get on with
what it's doing (documenting the deprecation of site-local, and developing
alternatives). I believe the worst outcome for the IETF would be to waste the
time of busy people (and I'm sadly aware that this message will go to several
thousand people) over a consensus call that was not even about a document
but just a decision in principle. Personally I see no abuse of process in
either the face to face consensus call or the subsequent email poll; the
fact that the questions asked had some degree of ambiguity is simply a result
of the complexity involved. I recommend that the IAB deals with this appeal
as quickly as possible, and avoids future time wasting by constructing a
response that makes further appeals on the same topic pointless.

Personally, this is my last message on this thread and I won't be reading
it again either. I have work to do.

Brian

Eliot Lear wrote:
>
> Stephen Sprunk wrote:
> > Or we all just got sick of the bickering and accepted defeat (unlike Tony).
> >
> > For the record, I can't support deprecating site locals until we have
> > something else approved to replace them -- at which point I say good
> > riddance. There are several drafts in the WG to that end which haven't
> > gained any momentum thus far.
>
> And this is why the appeal is in my opinion untimely. The working group
> has not yet been given a chance to provide any documentation on that
> "What next?" question Tony asked. For the IESG or the IAB to interfere
> at this stage would be micromanagement.
>
> But here we are. Tony has decided to push an appeal of a "vote", and
> not even one that generated a document. That the appeal has even gotten
> this far seems is a flaw in the process.
>
> Had the IESG been able to disallow the appeal, simply on this basis,
> then perhaps the working group could actually provide documents about
> which we could argue over technical merit. As it stands, I predict yet
> another round of appeals once IETF last call closes, and the document is
> reviewed by the IESG.
>
> Welcome to Court TV, IETF style.
>
> Eliot
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM

NEW ADDRESS <***@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK
Keith Moore
2003-10-10 21:20:25 UTC
Permalink
> For the record, I can't support deprecating site locals until we have
> something else approved to replace them

replace them for what purpose? different people wanted site locals for
different purposes. some of those purposes are dubious. others inherently
cause harm.

we're not going to find a single solution that satisfies all of the
purposes for which people thought site-locals were a good idea.
and that is a good thing.
Fred Baker
2003-10-10 21:55:04 UTC
Permalink
At 02:30 PM 10/10/2003, Leif Johansson wrote:
>>With all due respect, it seems that it would be beneficial for both camps
>>(for and against SL) to hear, even now, the real concerns directly from
>>the operation people and to let them participate in the decision
>>themselves. ... <snip>
>
>Been there. Done that. Didn't work. This vast Moral Majority of the
>Site-Locals either don't exist or live entierly behind NATs or other boxes
>which prevent them from receiving the call to arms to participate in the
>debate. ;-)

Let's at least try to be fair and realistic. There is a fairly large and
vocal camp from tier 1 and tier 2 operators in the IETF which presumes that
the needs of a backbone service provider are the only needs that are
relevant in any network and go around blasting anything they don't need as
"clueless". But not all tier 1/2 operators are represented or choose to
speak publicly, and not all networks are tier 1/2 networks. I have a fairly
long history of sitting in the room with people from certain tier 1/2
operators who will tell me at dinner or in the hallway what they think
about this or that, but are precluded from speaking for themselves publicly
by the policy or culture of their employers. I'm not naming names, because
that would be inappropriate (if they can't/won't speak for themselves
because their employer doesn't want to tip a business hand, who am I to tip
it for them?). But I guarantee you that they are present, and they don't
necessarily agree with the vocal operators.

When it comes to tertiary operators and enterprises, let's face it. They're
vastly under-represented, and perhaps not at all represented. If they were
represented as completely as the Tier 1/2 operators are, we would routinely
have meetings with multiples of 10K attendees. They don't come to IETF
meetings. They read about them in Network World and Computer Week, they
tell their vendors what they are willing to buy, and their vendors come
talk about the features smaller operators and enterprises are asking for.
The vendors take a beating from the operational elite, who tell us

- we have no clue how to run a network
- we have no idea what features a network needs
- there is no deployed (pick your protocol that is perhaps inappropriate in
a Tier 1 backbone) in the whole wide world
- Specifically, there is no operational deployment of the diffserv
architecture (having heard this extensively from the gentleman from
Telstra,
I wonder if he ever talks to the gentleman from Comindico that I spoke
with
last week; they seem to live on different planets)
- That everything we produce and talk about is what we want to sell, not
what the tier 1/2 operators or anybody else wants to buy.
- That whatever we say is inherently invalid because we are vendors.

Interesting. Do we do these things for our health? Do we go generate
features and then try to sell them to people? Do we keep beat our heads
against the wall for a decade or more while there is no market and all
problems are trivially solved using other technologies?

Are we that idiotic?

You know, I'd like to see a little more respect for people, and for the
reports they make. Yes, it would be much better if operational staff from
each of the Fortune 500 companies and larger tertiary operators came to the
IETF and spoke for themselves. They don't, and that doesn't make their
opinions or requirements irrelevant.
Leif Johansson
2003-10-11 06:12:37 UTC
Permalink
| You know, I'd like to see a little more respect for people, and for the
| reports they make. Yes, it would be much better if operational staff
| from each of the Fortune 500 companies and larger tertiary operators
| came to the IETF and spoke for themselves. They don't, and that doesn't
| make their opinions or requirements irrelevant.

I do (sort of) apologize for the tone of my email but I simply don't
understand how the debate in the IETF will survive the trend to replace
technical argument with "My Fortune 500 customers tell me foo and thus
foo it must be.". Please tell me how that is fundamentally different
from voting based on (in some way) market share.

Don't take me wrong, I am not an air-headed academic who fails to
understand the importance of beeing able to sell the solutions to
people who are willing to pay for them.

Cheers Leif
Leif Johansson
2003-10-11 06:43:57 UTC
Permalink
|
| Don't take me wrong, I am not an air-headed academic who fails to
| understand the importance of beeing able to sell the solutions to
| people who are willing to pay for them.

Just to be very clear on this: I don't believe I have seen anyone
in the SL debate who presented an 'academic' argument without insight
into the commercial realities facing vendors. Even the most die-hard
opponents of SL I believe understand this. The failure to accept the
Furtune-500 argument is not the same as not understanding it.

Cheers Leif
Keith Moore
2003-10-10 19:43:55 UTC
Permalink
> You are listening to a very limited subset of the 'community'. I have had
> several questions from fortune 500 network managers as to 'what now?' They
> plan to roll out IPv6 with addresses that are in either the FEC0 range
> anyway, or are trusting that the proposed replacement FC00 will be finalized
> soon.

maybe those people are being fed bad information. the question is, by whom?
Scott Bradner
2003-10-10 18:18:39 UTC
Permalink
note that this survey was done *after* the decision was announced
as a done deal - I, for one, took that into account when I responded

----
From: Bob Hinden & Brian Haberman <***@iprg.nokia.com>
To: ***@ietf.org
Cc: ***@iprg.nokia.com, Brian Haberman <***@innovationslab.net>
Date: Tue, 16 Sep 2003 10:55:33 -0700
Subject: Results of Poll

The results of the poll (appended below) started by the chairs in early
August to get more feed back from the working about how to deprecate
site-local are as follows:

Preference A 32 45%
Preference B 31 44%
Preference C 8 11%
--------------------------
Total Votes 71 100%

The raw votes are available at:

http://people.nokia.net/~hinden/ipv6-choices.html

If we missed your preference or got it wrong, please let us know.
Spencer Dawkins
2003-10-10 11:58:46 UTC
Permalink
Speaking as an outsider on this particular topic...

Is there any reason why these appeals should be single-threaded?

As much fun as it might be to continue to rotate this topic on a spit,
we've been discussing whether we actually made this decision or not
for six months. Continuing to discuss it for another two or three
years is just pathological. If it was the WRONG decision, deciding
that we made the decision, and letting the wrongness blossom/fester
and become evident to all, would be an improvement.

Spencer

----- Original Message -----
From: "Michel Py" <***@arneill-py.sacramento.ca.us>


> Harald,
>
> > Harald Tveit Alvestrand
> > But there's absolutely no doubt in my mind that the WG made a
> > decision, and that the chairs were procedurally correct in
> > recording that decision as the outcome of the meeting.
>
> There many people, including some that actually _wrote_ the
procedures,
> that disagree with you. As of myself, I am not completely happy with
the
> way Tony has worded his appeal (although I do agree with it), which
is
> why I will file one on different grounds as soon as this one as been
> ruled. Since it appears that there is a waiting list to file an
appeal
> on this matter, I am sure that we will be entertained for the next
two
> or three years to come.
>
> Michel.
>
>
>
> _______________________________________________
> This message was passed through ***@carmen.ipv6.cselt.it,
which is a sublist of ***@ietf.org. Not all messages are passed.
Decisions on what to pass are made solely by IETF_CENSORED ML
Administrator (***@ngnet.it).
Christian Huitema
2003-10-10 05:11:40 UTC
Permalink
> > Harald Tveit Alvestrand
> > But there's absolutely no doubt in my mind that the WG made a
> > decision, and that the chairs were procedurally correct in
> > recording that decision as the outcome of the meeting.
>
> There many people, including some that actually _wrote_ the
procedures,
> that disagree with you.

Please explain or retract. I was the note-taker during that particular
session, and I don't recall ever stating that the chair's decision did
not reflect the result of the meeting.

-- Christian Huitema
Michel Py
2003-10-10 05:22:24 UTC
Permalink
Christian,

>> Michel Py wrote:
>> There many people, including some that actually _wrote_
>> the procedures, that disagree with you.

> Christian Huitema wrote:
> Please explain or retract. I was the note-taker during that
> particular session, and I don't recall ever stating that the
> chair's decision did not reflect the result of the meeting.

Neither do I. I was not referring to you. By "_wrote_ the procedures", I
did not mean "wrote the proceedings".

As an example, I was referring to Scott Bradner's posts the; relation
with the procedure being that Scott is the editor of RFC2026; I do
acknowledge that Scott might not have been speaking as the editor of
RFC2026; nevertheless I consider (as many other people do) Scott as an
expert in terms of procedure.

Michel.
Keith Moore
2003-10-10 14:56:33 UTC
Permalink
- I don't see anything in our documented processes that requires a
greater degree of consensus to change an existing specification.
Rather I see an expectation built into our process that undesirable
or unworkable features will be removed as a standard progresses from
proposed to draft to full standard.

- I can understand a belief that 3/4 majority is on the rough edge of rough
consensus. But even assuming that rough consensus requires a greater
plurality, there was certainly a sufficient demonstration of opinion
that any revision to existing specifications that did include site local
was unlikely to gain consensus and that trying to fix site-local was
not a useful expenditure of the WG's energy. And there was also growing
evidence that we had not found a workable way to use site local, which would
by itself be sufficient to bar site-local from advancing in grade along
with the rest of IPv6. So even accepting that there was something less than
consensus in the WG's decision, in some sense it's a moot point. Site-local
was a dead end anyway, both politically and technically.
M***@nokia.com
2003-10-10 15:09:22 UTC
Permalink
Hi Scott,

Speaking only for myself, I would like to address a couple of the
points that you have made.

> It is my opinion that there is a difference between a working group
> deciding to adopt a technology and a working group deciding
> to delete a technology from an existing IETF specification. It is my
> opinion that the second case should require a stronger demonstration
> of consensus to change since the decision effects existing implementations,
> documentation, text books etc.

First, I disagree with your basic premise. We don't make any
distinction between these cases, but if we did, all other things
being equal, I think it should be harder to add a new feature to a
specification than to take one out. Removing a feature from a
specification doesn't even prevent people from using it, whereas
adding a feature requires people to implement new code to be compliant
with the specification.

But, regardless of our differing opinions on this theoretical point, I
am not sure how it applies to this situation. Although a prefix for
site-local addressing was set aside in the IPv6 Address Architecture
(a PS RFC), the entire specification for the concept of site-local
addressing, including how you would actually use these addresses, was
only ever documented in the IPv6 Scoped Addressing Architecture I-D. At
the time that this decision was made by the WG, the latest version of
that I-D had expired. Various versions of the I-D had been considered
by the WG for years, but we had never reached rough consensus to send
this I-D to the IESG for publication.

> The claim was made on the list that there was not consensus
> to keep site local addresses, I think that is the wrong question
> to ask - the proposal was to change a specification after its
> publication there should have been a rough consensus to remove the
> feature.

I'm not sure where this is coming from. You quoted the consensus
finding later in your message:

> > 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 other words, we found that there was consensus to deprecate AND
replace site-locals, not that there was a lack of consensus to keep
them.

In response to your appended letter:

> humm - it is not all that often that we have said that 2/3 is rough
> consensus in the IETF - in my exterience if 1/3 is not in support
> then I would not claim consensus (even 6 grit) - 3/4 would be very
> rough indeed, 5/6 would be the mininum I would say was "rough
> consensus"

The actual ratio of YES to NO responses to this poll was closer
to 3/4.

Also, the poll was not the only tool that the WG chairs (I was
one of them at the time) used to determine the consensus of the
WG. There was considerable discussion regarding this issue -- in
the WG meeting and on the list. This included a fairly large number
of people who gave conditional replies on the list, or who clarified
their meeting postion on the list along the lines of: (1) I do not
think we should deprecate site-local unless/until we replace them,
or (2) Although I think that we should deprecate site-locals, I also
think that we need a replacement. The chairs consensus call was
based on lengthy and careful consideration of all of the information
contributed by the WG, not just on the results of the opinion poll.

It is still my personal opinion that we correctly judged the
consensus of the WG regarding this matter.

Margaret
Tony Hain
2003-10-10 17:59:45 UTC
Permalink
Additional input for your consideration.

***@nokia.com wrote:
> ...
> In other words, we found that there was consensus to deprecate AND
> replace site-locals, ...
Witness the situation where the chair is after the fact defining what the
working group agreed to. There was nothing about 'replacement' in the
question that was asked.

Coupling this with her earlier comment:
> I think it should be harder to add a new feature to a specification
> than to take one out.
shows that, now as AD, the bar for a disambiguated local range will be
higher if the pronouncement is allowed to stand, than what is necessary to
fix the existing specification.

Tony
Fred Baker
2003-10-10 18:34:04 UTC
Permalink
At 08:09 AM 10/10/2003, ***@nokia.com wrote:
>Removing a feature from a specification doesn't even prevent people from
>using it

I'm changing the thread subject. While this is relevant to the subject of
Tony's appeal, it is also a general debate orthogonal to Tony's appeal. It
is a side note that may prove relevant. While your assertion may generally
be true, this particular change does prevent people from using it, and I'm
not sure the assertion is true as worded.

The site-local proposal says that there is an assurance that a particular
block of addresses is available to a network administration to use in
whatever way it chooses within the confines of its own network, on the
proviso that it neither advertise those addresses outside its network in
routing nor trust announcements of the block by others, and presumably also
ingress filters for the address prefix. Removing the concept removes that
capability. YMMV as to whether you want the capability, but you cannot
accurately say that the capability still exists once it has been removed.

Your assertion is also dangerous in protocols. If a capability is
deprecated (remains defined but its implementation/use is discouraged, as
for example true of TOS routing in OSPF, cf RFCs 1583, 2178, and 2328),
then an implementation that contains the capability can accurately say it
is using a superset of the specification. If the capability is simply
removed, one has to presume that at some time in the future the bits will
be reused with different semantics, making the implementation that
yesterday was using a superset of the specification an active hazard today,
and causing operational networks that were using the capability to have to
make some potentially hard choices.

So in the general case I don't see a problem with deprecating things under
the right circumstances, but I do have a problem with removing them
outright. Deprecation doesn't prevent people from using them, but outright
removal can be dangerous. And in this case, the assertion that one can
still use the address prefix in a local manner is simply incorrect; it can
be assigned at the whim of IANA, and network administrations need to plan
accordingly.
Keith Moore
2003-10-10 19:40:11 UTC
Permalink
> At 08:09 AM 10/10/2003, ***@nokia.com wrote:
> >Removing a feature from a specification doesn't even prevent people
> >from using it
>
> I'm changing the thread subject. While this is relevant to the subject
> of Tony's appeal, it is also a general debate orthogonal to Tony's
> appeal. It is a side note that may prove relevant. While your
> assertion may generally be true, this particular change does prevent
> people from using it, and I'm not sure the assertion is true as
> worded.

Given that the objections to site local were based on the realization
that using it actually causes harm to applications and to the network,
then I agree with you. Most of us realize that we cannot prevent
harmful behavior, especially on a private network. But the intent of
deprecating site-local was at the very minimum to strongly discourage
its use.

> The site-local proposal says that there is an assurance that a
> particular block of addresses is available to a network administration
> to use in whatever way it chooses within the confines of its own
> network, on the proviso that it neither advertise those addresses
> outside its network in routing nor trust announcements of the block by
> others, and presumably also ingress filters for the address prefix.

It turns out that those usage constraints are not sufficient to avoid
harm to the network as a whole, and after numerous attempts we have
not been able to define a set of constraints that still allow use of
site-local while avoiding that harm.

> Your assertion is also dangerous in protocols. If a capability is
> deprecated (remains defined but its implementation/use is discouraged,
> as for example true of TOS routing in OSPF, cf RFCs 1583, 2178, and
> 2328), then an implementation that contains the capability can
> accurately say it is using a superset of the specification.

The terms you are using are biased. A vendor could define a "superset"
of IP that had the "capability" of routing addresses to destinations
other than those intended by the source, or modifying the contents of
messages sent by the source, or masquerading as the destination and
issuing responses that appear to come from the destination. A DNS
server could add the "capability" of misrepresenting the status of a
name given in a query. Indeed, all of these "capabilities" exist in
some product or another. It also turns out that all of these
"capabilities" cause harm to applications.

It's a fallacy to believe, and disingeneous to pretend, that
providing new "capabilities" or a "superset" of a protocol is at worst
a benign activity. There exist "capabilities" that do harm. In the
case of site-locals, it happens that this "capability" was part of an
IETF specification. So once we realized that site-locals were harmful,
it became our responsibility to fix them. I agree, as do most of us,
that we should make considerable effort to avoid disruptive changes to
published specifications. However it was only after investigating
several proposals for less disruptive fixes, and finding all of them
insufficient, that there emerged a consensus to deprecate site-locals.

> If the
> capability is simply removed, one has to presume that at some time in
> the future the bits will be reused with different semantics, making
> the implementation that yesterday was using a superset of the
> specification an active hazard today, and causing operational networks
> that were using the capability to have to make some potentially hard
> choices.

We can promise to not re-assign them, and we can keep our promise.

But if site administrators decide to move away from site-locals, this is
a good thing, as it will minimize the harm done by having them in the wild.

Keith
V***@vt.edu
2003-10-10 19:55:06 UTC
Permalink
On Fri, 10 Oct 2003 11:34:04 PDT, Fred Baker said:

> The site-local proposal says that there is an assurance that a particular
> block of addresses is available to a network administration to use in
> whatever way it chooses within the confines of its own network, on the
> proviso that it neither advertise those addresses outside its network in
> routing nor trust announcements of the block by others, and presumably also
> ingress filters for the address prefix. Removing the concept removes that
> capability. YMMV as to whether you want the capability, but you cannot
> accurately say that the capability still exists once it has been removed.

On the flip side, the biggest basis for removing the feature is the fact that
RFC1918 contains essentially the same provision for IPv4, and 1918 addresses
are continually leaking like sieves, and nobody (to my knowledge) was able to
point at magic router filter dust that would prevent it from happening on IPv6.

So the basic concept is (in my opinion) broken and needs to be euthanized.

> outright. Deprecation doesn't prevent people from using them, but outright
> removal can be dangerous. And in this case, the assertion that one can
> still use the address prefix in a local manner is simply incorrect; it can
> be assigned at the whim of IANA, and network administrations need to plan
> accordingly.

And in fact, we've seen this effect in operation recently, when the 69/8 address
space was allocated but often unreachable due to bogon filters....

All in all, however, I think outright removal, although short-term more painful,
will be less troublesome than many years of debugging problems caused by
1918-style leakage of addresses for a "deprecated" feature.
Fred Baker
2003-10-10 21:29:24 UTC
Permalink
At 12:55 PM 10/10/2003, ***@vt.edu wrote:
>All in all, however, I think outright removal, although short-term more
>painful, will be less troublesome than many years of debugging problems
>caused by 1918-style leakage of addresses for a "deprecated" feature.

That may be so. It is a third discussion, and is appropriate to the IPv6 list.

The first discussion is Tony's appeal, which is a procedural discussion and
should not be debated on the basis of whether one agrees or disagrees with
the particular feature (site-local addresses) but on the basis of whether
the right consensus development and recognition procedures were followed.
The Author/Editor of the procedural description has commented that it
looked problematic to him.

The second is the side point I raised with Margaret: in the general case of
"things in specifications", removing something from a specification does
not mean that someone can still use it. Deprecation protects such a usage,
but removal does not.

The third point, the one you address, is where all this started out, which
is whether or not one should entertain site-local addresses at all. It is
relevant to neither the procedural discussion nor the general discussion
about removing features. But it is clearly something that the IPv6 working
group needs to have a consensus opinion on. That is actually not the
subject of either appeal, and should not enter into the discussion of
either appeal, as it has no bearing on the thing appealed - which is the
procedural issue. Using the wrong procedure to accomplish the right result
(if one assumes that this is what happened) is just as bad as using the
right procedure to produce the wrong result. One wants to use the right
procedure *and* produce the right result.

When I changed the topic, I changed the subject line... Let's not confuse
issues.
Iljitsch van Beijnum
2003-10-10 21:43:20 UTC
Permalink
On vrijdag, okt 10, 2003, at 21:55 Europe/Amsterdam,
***@vt.edu wrote:

> the biggest basis for removing the feature is the fact that
> RFC1918 contains essentially the same provision for IPv4, and 1918
> addresses
> are continually leaking like sieves, and nobody (to my knowledge) was
> able to
> point at magic router filter dust that would prevent it from happening
> on IPv6.

> So the basic concept is (in my opinion) broken and needs to be
> euthanized.

This is based on the assumption that leaking RFC 1918 routing
information or packets with RFC 1918 source or destination addresses is
actually harmful in and of itself. This is a broken assumption. If
people are going to send bogus routes or packets, then having RFC 1918
addresses in them is the least harmful way to do it. Now obviously
people shouldn't send out bogus routes or packets, but this is a
problem that is completely unrelated to private addressing issues. It's
just that private addresses make this problem much more visible.
Removing that which is clearly wrong only helps to make sure the
wrongness that remains is less visible.

And if you're unable to figure out how to filter private addresses in
routing updates or IP traffic, there are numerous non-magical books out
there that will tell you how to do this.

>> outright. Deprecation doesn't prevent people from using them, but
>> outright
>> removal can be dangerous. And in this case, the assertion that one can
>> still use the address prefix in a local manner is simply incorrect;
>> it can
>> be assigned at the whim of IANA, and network administrations need to
>> plan
>> accordingly.

> And in fact, we've seen this effect in operation recently, when the
> 69/8 address
> space was allocated but often unreachable due to bogon filters....

> All in all, however, I think outright removal, although short-term
> more painful,
> will be less troublesome than many years of debugging problems caused
> by
> 1918-style leakage of addresses for a "deprecated" feature.

Your argument is self-defeating. If we were to recycle FEC0::/10 this
would be the 69.0.0.0/8 but ten times worse. Everybody knew that
69.0.0.0/8 would be assigned at some point, so the people filtering
this range knew what they were doing (or at least, they should have).
FEC0::/10 on the other hand has been in the specification as a fixed
special purpose range for a lot of years, and presumably people have
implemented their networks accordingly. Pulling the rug from under them
by removing this address range from the spefication and (at least
theoretically) allowing it to be reassigned for a different purpose is
insane.

And that's not even considering the lack of alternatives at this point
in time. We may not be able to come up with a reasonable way for
networks that implement site local addressing and interconnect with
other networks that do the same, but there is still a very real need
for addresses that can be used in disconnected IPv6 networks. I believe
that forcing people who just want to interconnect a few boxes to do
some testing to obtain globally routable IPv6 unicast space is a very
bad idea. As long as there aren't any alternatives, FEC0::/10 should be
used for this. And even after we have alternatives, FEC0::/10 should
forever be set aside to avoid problems.

> <mime-attachment>

Huh?

Iljitsch van Beijnum
Keith Moore
2003-10-10 22:57:24 UTC
Permalink
> > So the basic concept is (in my opinion) broken and needs to be
> > euthanized.
>
> This is based on the assumption that leaking RFC 1918 routing
> information or packets with RFC 1918 source or destination addresses is
> actually harmful in and of itself.

no, it's based on (among other things) first-hand experience that applications
are expected to be able to use whatever addresses are given to them, regardless
of whether or not those applications employ hosts that are outside of site
boundaries.

> And if you're unable to figure out how to filter private addresses in
> routing updates or IP traffic, there are numerous non-magical books out
> there that will tell you how to do this.

attempts to filter such traffic just makes the breakage worse.
V***@vt.edu
2003-10-10 23:12:55 UTC
Permalink
On Fri, 10 Oct 2003 23:43:20 +0200, Iljitsch van Beijnum said:

> And if you're unable to figure out how to filter private addresses in
> routing updates or IP traffic, there are numerous non-magical books out
> there that will tell you how to do this.

The problem is that usually, the offending site isn't the one feeling the pain.

We've been doing bogon filtering of 1918 addresses for a LONG time.

The *real* fun is collateral damage - we filter inbound 1918 source
addresses. A certain clueless Tier-1 numbers their point-to-points
out of 1918 space. If one of those links tosses an ICMP error,
it gets dropped at our border router.

Does wonders for PMTU discovery when the frag-needed packet gets tossed.

How many sites have to Get It Wrong before 30% of all the packets seen
at the root nameservers are from 1918 space?

> Your argument is self-defeating. If we were to recycle FEC0::/10 this
> would be the 69.0.0.0/8 but ten times worse. Everybody knew that
> 69.0.0.0/8 would be assigned at some point, so the people filtering
> this range knew what they were doing (or at least, they should have).
> FEC0::/10 on the other hand has been in the specification as a fixed
> special purpose range for a lot of years, and presumably people have
> implemented their networks accordingly. Pulling the rug from under them
> by removing this address range from the spefication and (at least
> theoretically) allowing it to be reassigned for a different purpose is
> insane.

Agreed. On the other hand, if we don't, we're stuck looking at
having inbound FEC0::/10 packets for eternity.

> And that's not even considering the lack of alternatives at this point
> in time. We may not be able to come up with a reasonable way for
> networks that implement site local addressing and interconnect with
> other networks that do the same, but there is still a very real need
> for addresses that can be used in disconnected IPv6 networks. I believe
> that forcing people who just want to interconnect a few boxes to do
> some testing to obtain globally routable IPv6 unicast space is a very
> bad idea. As long as there aren't any alternatives, FEC0::/10 should be
> used for this. And even after we have alternatives, FEC0::/10 should
> forever be set aside to avoid problems.

Well.. OK... *disconnected* networks, I can see the point. Unfortunately,
unless you make a rule that an IPv6 host will categorically refuse to
accept traffic to/from a FEC0::/10 host if it knows *ANY* other non-link-local
prefixes, it will end up leaking. Yes, that means if you connect and learn
other prefixes, you need to renumber the site-locals. It also means that
if you have a router talking to the outside world, you aren't allowed to do
NAT-style games - the router has to pretend your FEC0:/10 hosts don't exist.

> > <mime-attachment>
>
> Huh?

RFC2440 - OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, R.
Thayer. November 1998. (Format: TXT=141371 bytes) (Status: PROPOSED
STANDARD)
Rob Austein
2003-10-11 00:06:17 UTC
Permalink
No offense, folks, but if you really must have yet another round of
this interminable discussion, could you please trim the cc: list?
Four copies of each message is a bit much. Thanks.
Iljitsch van Beijnum
2003-10-11 11:10:37 UTC
Permalink
On zaterdag, okt 11, 2003, at 01:12 Europe/Amsterdam,
***@vt.edu wrote:

> The problem is that usually, the offending site isn't the one feeling
> the pain.

> We've been doing bogon filtering of 1918 addresses for a LONG time.

> The *real* fun is collateral damage - we filter inbound 1918 source
> addresses. A certain clueless Tier-1 numbers their point-to-points
> out of 1918 space. If one of those links tosses an ICMP error,
> it gets dropped at our border router.

> Does wonders for PMTU discovery when the frag-needed packet gets
> tossed.

Wouldn't the people behind this setup feel the pain too?

I must say giving a router that handles links with different MTU sizes
RFC 1918 addresses is an interesting choice.

But then path MTU discovery has been broken (by assuming packet too big
messages would *always* be returned) for 10 years and only recently the
IETF and implementers have been starting to do something about that.

> How many sites have to Get It Wrong before 30% of all the packets seen
> at the root nameservers are from 1918 space?

Dunno. What kind of pathalogical setup makes this happen anyway?
Running a resolving nameserver behind a broken NAT? But only a few of
those will generate lots of queries as they never see any answers.

>> Your argument is self-defeating. If we were to recycle FEC0::/10 this
>> would be the 69.0.0.0/8 but ten times worse. Everybody knew that
>> 69.0.0.0/8 would be assigned at some point, so the people filtering
>> this range knew what they were doing (or at least, they should have).
>> FEC0::/10 on the other hand has been in the specification as a fixed
>> special purpose range for a lot of years, and presumably people have
>> implemented their networks accordingly. Pulling the rug from under
>> them
>> by removing this address range from the spefication and (at least
>> theoretically) allowing it to be reassigned for a different purpose is
>> insane.

> Agreed. On the other hand, if we don't, we're stuck looking at
> having inbound FEC0::/10 packets for eternity.

I doubt that FEC0::/10 will be as prevalent as RFC 1918. But if you
absolutely don't want to see them, you probably need to filter them for
eternity, yes.

> Well.. OK... *disconnected* networks, I can see the point.
> Unfortunately,
> unless you make a rule that an IPv6 host will categorically refuse to
> accept traffic to/from a FEC0::/10 host if it knows *ANY* other
> non-link-local
> prefixes, it will end up leaking. Yes, that means if you connect and
> learn
> other prefixes, you need to renumber the site-locals. It also means
> that
> if you have a router talking to the outside world, you aren't allowed
> to do
> NAT-style games - the router has to pretend your FEC0:/10 hosts don't
> exist.

Yes, all of this is very problematic. What we really need is provider
independent address space that is globally usable. If we can't make
this happen I'm sure IPv6 will end up with much of the IPv4
unpleasantness, such as two-faced DNS if not full-out NAT.

>>> <mime-attachment>

>> Huh?

> RFC2440 - OpenPGP Message Format. J. Callas, L. Donnerhacke, H.
> Finney, R.
> Thayer. November 1998. (Format: TXT=141371 bytes) (Status:
> PROPOSED
> STANDARD)

But why bother signing your messages? We're discussing based on
arguments here, it doesn't matter who makes them...
Leif Johansson
2003-10-11 06:46:04 UTC
Permalink
Iljitsch van Beijnum wrote:
<snip>

|
| This is based on the assumption that leaking RFC 1918 routing
| information or packets with RFC 1918 source or destination addresses is
| actually harmful in and of itself. This is a broken assumption. If

Tell that to the root zone operators and brace for the reaction.

Cheers Leif
Juan Rodriguez Hervella
2003-10-13 13:45:15 UTC
Permalink
On Saturday 11 October 2003 08:46, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Iljitsch van Beijnum wrote:
> <snip>
>
> | This is based on the assumption that leaking RFC 1918 routing
> | information or packets with RFC 1918 source or destination addresses is
> | actually harmful in and of itself. This is a broken assumption. If
>
> Tell that to the root zone operators and brace for the reaction.
>

Hello Leif,

Do you know what are the problems that *root zone operators* are
experiencing with RFC 1918 addresses ? It would be very interesting
if you could explain (to me) some of these issues... I don't see why
this kind of addresses could be a problem, as long as they
don't use them....


--
JFRH
Jeroen Massar
2003-10-13 14:01:41 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----

Juan Rodriguez Hervella wrote:

> On Saturday 11 October 2003 08:46, Leif Johansson wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Iljitsch van Beijnum wrote:
> > <snip>
> >
> > | This is based on the assumption that leaking RFC 1918 routing
> > | information or packets with RFC 1918 source or
> destination addresses is
> > | actually harmful in and of itself. This is a broken assumption. If
> >
> > Tell that to the root zone operators and brace for the reaction.
> >
>
> Hello Leif,
>
> Do you know what are the problems that *root zone operators* are
> experiencing with RFC 1918 addresses ? It would be very interesting
> if you could explain (to me) some of these issues... I don't see why
> this kind of addresses could be a problem, as long as they
> don't use them....

You might want to read http://www.as112.net/

Quote: "Because most answers generated by the Internet's root name server system are negative, and many of those negative answers are in response to PTR queries for RFC1918 and other ambiguous addresses"

And that is only queries, you don't want to know how many RFC1918
sourced addresses they are dropping, can't send an icmp back now can you :)

Greets,
Jeroen
Juan Rodriguez Hervella
2003-10-14 07:37:37 UTC
Permalink
On Monday 13 October 2003 16:01, Jeroen Massar wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Juan Rodriguez Hervella wrote:
> > On Saturday 11 October 2003 08:46, Leif Johansson wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Iljitsch van Beijnum wrote:
> > > <snip>
> > >
> > > | This is based on the assumption that leaking RFC 1918 routing
> > > | information or packets with RFC 1918 source or
> >
> > destination addresses is
> >
> > > | actually harmful in and of itself. This is a broken assumption. If
> > >
> > > Tell that to the root zone operators and brace for the reaction.
> >
> > Hello Leif,
> >
> > Do you know what are the problems that *root zone operators* are
> > experiencing with RFC 1918 addresses ? It would be very interesting
> > if you could explain (to me) some of these issues... I don't see why
> > this kind of addresses could be a problem, as long as they
> > don't use them....
>
> You might want to read http://www.as112.net/
>
> Quote: "Because most answers generated by the Internet's root name server
> system are negative, and many of those negative answers are in response to
> PTR queries for RFC1918 and other ambiguous addresses"
>
> And that is only queries, you don't want to know how many RFC1918
> sourced addresses they are dropping, can't send an icmp back now can you :)

I would have to read it again, but I think that ICMP error messages are
sent with the source address of the output interface, so IMO it would be able
to come back. Anyway, thank you very much for the info Jeroen ^--^

--
JFRH
Jeroen Massar
2003-10-14 09:36:49 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----

Juan Rodriguez Hervella wrote:

<SNIP>

> > > Do you know what are the problems that *root zone operators* are
> > > experiencing with RFC 1918 addresses ? It would be very interesting
> > > if you could explain (to me) some of these issues... I don't see why
> > > this kind of addresses could be a problem, as long as they
> > > don't use them....
> >
> > You might want to read http://www.as112.net/

<SNIP>

> I would have to read it again, but I think that ICMP error
> messages are sent with the source address of the output interface, so IMO
> it would be able to come back.

$stupiddevice --> non-filtering-ISP --> Transit --> Nameserver
192.168.0.1 x.x.x.x

To which IP should the Nameserver, or for that matter anything
filtering in between send the traffic? In the DFZ there is no
route to 192.168.0.0/16, if there was is it is a still a bogon.
AS112 concentrates on bogus queries from valid IP's though as
the rootservers get queries for things like: 1.0.168.192.in-addr.arpa. PTR.

Mind you if the ISP doesn't even filter RFC1918 space they are not
filtering based on source address also. Thus that complete ISP is
a perfect source for..... spoofed ddos'ses, now track those ;)

ISP's should filter *any* source addresses that are not delegated
to their clients, doing this more at the edge where the client
connects to their network is a good thing. They should for
stupidity's sake also only forward traffic that they know the
destination is only at that client. Yes this breaks 'multihoming',
but is that real multihoming? Not per my definition at least.
uRPF etc come to mind also ofcourse.

Greets,
Jeroen
Juan Rodriguez Hervella
2003-10-14 09:59:44 UTC
Permalink
On Tuesday 14 October 2003 11:36, Jeroen Massar wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Juan Rodriguez Hervella wrote:
>
> <SNIP>
>
> > > > Do you know what are the problems that *root zone operators* are
> > > > experiencing with RFC 1918 addresses ? It would be very interesting
> > > > if you could explain (to me) some of these issues... I don't see why
> > > > this kind of addresses could be a problem, as long as they
> > > > don't use them....
> > >
> > > You might want to read http://www.as112.net/
>
> <SNIP>
>
> > I would have to read it again, but I think that ICMP error
> > messages are sent with the source address of the output interface, so IMO
> > it would be able to come back.
>
> $stupiddevice --> non-filtering-ISP --> Transit --> Nameserver
> 192.168.0.1 x.x.x.x
>
> To which IP should the Nameserver, or for that matter anything
> filtering in between send the traffic? In the DFZ there is no
> route to 192.168.0.0/16, if there was is it is a still a bogon.
> AS112 concentrates on bogus queries from valid IP's though as
> the rootservers get queries for things like: 1.0.168.192.in-addr.arpa. PTR.
>
> Mind you if the ISP doesn't even filter RFC1918 space they are not
> filtering based on source address also. Thus that complete ISP is
> a perfect source for..... spoofed ddos'ses, now track those ;)
>
> ISP's should filter *any* source addresses that are not delegated
> to their clients, doing this more at the edge where the client
> connects to their network is a good thing. They should for
> stupidity's sake also only forward traffic that they know the
> destination is only at that client. Yes this breaks 'multihoming',
> but is that real multihoming? Not per my definition at least.
> uRPF etc come to mind also ofcourse.
>
> Greets,
> Jeroen
>
> -----BEGIN PGP SIGNATURE-----
> Version: Unfix PGP for Outlook Alpha 13 Int.
> Comment: Jeroen Massar / ***@unfix.org / http://unfix.org/~jeroen/
>
> iQA/AwUBP4vDpymqKFIzPnwjEQJ4+gCfav+ZRDKVvC75m21Y9ZUF+1YACbkAoJUI
> o7gclmYD8G7tWbqJ3n5mkm6O
> =gg+6
> -----END PGP SIGNATURE-----

I agree with you Jeroen, I misunderstood the following phrase:

> And that is only queries, you don't want to know how many RFC1918
> sourced addresses they are dropping, can't send an icmp back now can you :)

I was thinking that you were talking about packets with
"src=global dest=private", and I just wanted to note that ICMP error
packets are sent with "src=<output_iface>, dest=global".

I see private addressing is a really bad idea, and I quite agree with
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-01.txt

See you and thanks again !


--
JFRH
Kurt Erik Lindqvist
2003-10-14 15:44:50 UTC
Permalink
>> | This is based on the assumption that leaking RFC 1918 routing
>> | information or packets with RFC 1918 source or destination
>> addresses is
>> | actually harmful in and of itself. This is a broken assumption. If
>>
>> Tell that to the root zone operators and brace for the reaction.
>>
>
> Hello Leif,
>
> Do you know what are the problems that *root zone operators* are
> experiencing with RFC 1918 addresses ? It would be very interesting
> if you could explain (to me) some of these issues... I don't see why
> this kind of addresses could be a problem, as long as they
> don't use them....
>
Questions sourced from RFC1918 addresses and queries about RFC1918
in-addr.arpa (which should be handled by the AS112 servers) are the top
two garbage requests at i.root-servers.net.

- - kurtis -
Leif Johansson
2003-10-15 00:09:32 UTC
Permalink
<snip>

|>Hello Leif,
|>
|>Do you know what are the problems that *root zone operators* are
|>experiencing with RFC 1918 addresses ? It would be very interesting
|>if you could explain (to me) some of these issues... I don't see why
|>this kind of addresses could be a problem, as long as they
|>don't use them....
|>
|
| Questions sourced from RFC1918 addresses and queries about RFC1918
| in-addr.arpa (which should be handled by the AS112 servers) are the top
| two garbage requests at i.root-servers.net.
|
| - kurtis -
|

Sorry I missed your question. Anyway: Yeah, What Kurtis said. I sent a
reference to a presentation to the list a few days back. It contains
numbers.

leifj
Scott Bradner
2003-10-10 14:16:42 UTC
Permalink
IAB,

Please consider this input for the IAB discussion on Tony's appeal of the
site local decision. This should not be considered a separate appeal.
(Which I would think would have to start at the beginning with the working
group chairs.)

I do not have an opinion on the particulars of Tony's appeal since I was
not at the meeting in question and only followed the discussion on the
mailing list. Nor is this an opinion based on the technical question under
discussion. (Although I think some of the cures proposed to the site-local
disease are quite a bit worse than the disease itself.)

I would like to reiterate the concern I expressed on the mailing list back
in July - I think there may been a violation of the IETF consensus process
in this case.

It is my opinion that there is a difference between a working group
deciding to adopt a technology and a working group deciding to delete a
technology from an existing IETF specification. It is my opinion that the
second case should require a stronger demonstration of consensus to
change since the decision effects existing implementations, documentation,
text books etc.

But even without any need to show any extra level of consensus I did not
see that even a minimal level of rough consensus was demonstrated to remove
site local addresses.

The claim was made on the list that there was not consensus to keep site
local addresses, I think that is the wrong question to ask - the proposal
was to change a specification after its publication there should have been
a rough consensus to remove the feature.

I did not see rough consensus to do so based on my monitoring the list.

Scott

(this is the letter I sent back in July on the topic)

>From sob Mon Jul 28 15:11:01 2003
To: ***@Sun.COM
Subject: Re: state-of-art SLs
Cc: ***@sunroof.eng.sun.com
In-Reply-To: <***@bebop.france>


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

humm - it is not all that often that we have said that 2/3 is rough
consensus in the IETF - in my exterience if 1/3 is not in support
then I would not claim consensus (even 6 grit) - 3/4 would be very
rough indeed, 5/6 would be the mininum I would say was "rough consensus"


just when does "rough consensus" faid out in this model?

Scott
M***@nokia.com
2003-10-10 18:43:49 UTC
Permalink
Hi Fred,

> So in the general case I don't see a problem with deprecating
> things under the right circumstances, but I do have a problem with
> removing them outright. Deprecation doesn't prevent people from using
> them, but outright removal can be dangerous. And in this case, the
> assertion that one can still use the address prefix in a local manner
> is simply incorrect; it can be assigned at the whim of IANA, and
> network administrations need to plan accordingly.

Actually, we are being very careful about this in the deprecation
of IPv6 site-local addressing. Christian Huitema and Brian Carpenter
have co-authored a very carefully written deprecation document that
makes it clear how these addresses should be treated to avoid problems
with existing site-local implementations. And, we are planning to
instruct IANA not to return these addresses to the regular allocation
pool.

Margaret
Brian E Carpenter
2003-10-13 10:07:46 UTC
Permalink
The word "deprecating" has a quite precise meaning in standards writing,
which is not the same as "removing". Rather than debating this cross-posted
on several lists, why don't people watch out for
draft-ietf-ipv6-deprecate-site-local-01.txt which will appear in a few days,
and see if they agree with the way it's written? And then debate it on
the relevant list?

Brian

***@nokia.com wrote:
>
> Hi Fred,
>
> > So in the general case I don't see a problem with deprecating
> > things under the right circumstances, but I do have a problem with
> > removing them outright. Deprecation doesn't prevent people from using
> > them, but outright removal can be dangerous. And in this case, the
> > assertion that one can still use the address prefix in a local manner
> > is simply incorrect; it can be assigned at the whim of IANA, and
> > network administrations need to plan accordingly.
>
> Actually, we are being very careful about this in the deprecation
> of IPv6 site-local addressing. Christian Huitema and Brian Carpenter
> have co-authored a very carefully written deprecation document that
> makes it clear how these addresses should be treated to avoid problems
> with existing site-local implementations. And, we are planning to
> instruct IANA not to return these addresses to the regular allocation
> pool.
>
> Margaret
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM

NEW ADDRESS <***@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK
M***@nokia.com
2003-10-10 22:03:31 UTC
Permalink
> The second is the side point I raised with Margaret: in the
> general case of "things in specifications", removing something
> from a specification does not mean that someone can still use
> it. Deprecation protects such a usage, but removal does not.

Scott's posting made a distinction between adding and removing
features, lumping site-local deprecation into the "removing
features" category. I echoed his terminology.

I agree with you that there is a difference between simply
removing a feature (which might cause serious backwards
compatibility concerns, and could be quite irresponsible in
some cases) and carefully deprecating a feature (while considering
the affects on current implementations and preserving backwards
compatibility). In the IPv6 site-local case, the decision was made
to deprecate site-local addresses, and that is what we are working
to do. The proposals currently on the table reserve the current
site-local prefix, so that it will not be reallocated by IANA.

Fred, I hope that this resolves your technical concern about
this particular case, and I apologize for not making this
distinction clear in my response to Scott.

> That is actually not the
> subject of either appeal, and should not enter into the discussion of
> either appeal,...

As far as I know, there is only one appeal currently open
regarding this subject.

Margaret
Fred Baker
2003-10-10 22:50:47 UTC
Permalink
At 03:03 PM 10/10/2003, ***@nokia.com wrote:
>Fred, I hope that this resolves your technical concern about
>this particular case, and I apologize for not making this
>distinction clear in my response to Scott.

yes, it does.

In this case, I was responding to an increase in the complexity of the
debate. Whether or not you like site locals, the process of the decision
and such needs to be correct, so bringing up the technical merits or
demerits of site local actively doesn't help.
Michel Py
2003-10-11 06:59:24 UTC
Permalink
> Leif Johansson wrote:
> Tell that to the root zone operators and brace for the reaction.

Root zone operators, meaning like Verisign?

Michel.
Mans Nilsson
2003-10-13 16:07:08 UTC
Permalink
Subject: RE: Removing features Date: Fri, Oct 10, 2003 at 11:59:24PM -0700 Quoting Michel Py (***@arneill-py.sacramento.ca.us):
> Root zone operators, meaning like Verisign?

Yes. They, in the part of their operation that runs root servers,
feel the pain of leakage, as does USC-ISI, Cogent, UMD, NASA-ARC,
ISC, DOD-NIC, ARL, Autonomica, RIPE, ICANN and WIDE.

There is no reason to mix up the root server ops with the anycast debacle.

--
Måns Nilsson Systems Specialist
+46 70 681 7204 KTHNOC
MN1334-RIPE

Am I elected yet?
Mans Nilsson
2003-10-13 16:13:09 UTC
Permalink
Subject: Re: Removing features Date: Mon, Oct 13, 2003 at 06:07:08PM +0200 Quoting Mans Nilsson (***@sunet.se):
> There is no reason to mix up the root server ops with the anycast debacle.

I was not thinking! Substitute "anycast" with "wildcard" on the above line.

Sorry!
--
Måns Nilsson Systems Specialist
+46 70 681 7204 KTHNOC
MN1334-RIPE

Yow! I want my nose in lights!
Bound, Jim
2003-10-14 03:33:48 UTC
Permalink
Scott,

I agree with your caution about "removal" 100% and that it requires a
much stronger consenus and test to execute removal, and do not want it
done in anyway but from a serious analysis of those consequences. I also
agree the issue has nothing to do with which side of the fence one sits
on the issue. It is a process issue and removal is a very serious
decision.

But I read all the discussions that lead up to the March 2003 meeting,
and was in that March 2003 meeting. It was one of the strongest
consensus moments I have seen that happened that day in that room in
that working group and was IMO over 3/4 of the attendees. And then the
follow up email to the meeting did not overturn that consenus or the
view of the Chairs, ADs, and no one jumped over the fence, who supported
the decision to my knowledge.

Hence, I agree with the bar you articulate for this case, but I for one
truly believe the IETF process was met to proceed with the
recommendation of the Chairs on this issue and is supported by strong
cosensus of the IETF direct participants.

Also the draft below URL provides a good initial discussion and
framework of the issue and also a means to reduce any pain caused by
this removal. It is not my endorsement of the draft at this time as a
qualification.

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local
-01.txt

Other questions not related to this specific issue you articulated so
well are as follows for the future as input to you who knows far more
about this than I and I realize that completely:

1. Why did the WG agree to this consensus? An important question? I
will not comment on this in public.

2. Did the implementors who agreed understand the ramifications to code
base and were they participants? The answer is yes.

3. Were the needs of the market considered in the decision? I don't
think by all but do we ever use this bar? As I said to you once when
you were on the IESG consistency is imperative. The market is
reprsented by our participants. If participants are not here to support
the IETF they do not get heard. We have no way to trust one or a few to
represent an entire market other than present their individual view.
That may or may not influence the WG, it depends on the respect the
individual has with their peers I guess?

I will stop there.

Thanks for doing this and documenting the importance of "removal"
publicly it is a very important understanding we must know well before
we ever do removals. I do "feel" we had consenus as a note.
/jim

**************************************
"if it looks good, you'll see it;
if it sounds good, you'll hear it,
if it's marketed right, you'll buy it;
but...if it's real, you'll feel it."
Kid Rock
**************************************






> -----Original Message-----
> From: Scott Bradner [mailto:***@harvard.edu]
> Sent: Friday, October 10, 2003 10:17 AM
> To: ***@iab.org
> Cc: ***@ietf.org; ***@ietf.org; ***@ietf.org
> Subject: re: Appeal to the IAB on the site-local issue
>
>
> IAB,
>
> Please consider this input for the IAB discussion on Tony's
> appeal of the site local decision. This should not be
> considered a separate appeal. (Which I would think would have
> to start at the beginning with the working group chairs.)
>
> I do not have an opinion on the particulars of Tony's appeal
> since I was not at the meeting in question and only followed
> the discussion on the mailing list. Nor is this an opinion
> based on the technical question under discussion. (Although
> I think some of the cures proposed to the site-local disease
> are quite a bit worse than the disease itself.)
>
> I would like to reiterate the concern I expressed on the
> mailing list back in July - I think there may been a
> violation of the IETF consensus process
> in this case.
>
> It is my opinion that there is a difference between a working
> group deciding to adopt a technology and a working group
> deciding to delete a technology from an existing IETF
> specification. It is my opinion that the second case should
> require a stronger demonstration of consensus to change since
> the decision effects existing implementations, documentation,
> text books etc.
>
> But even without any need to show any extra level of
> consensus I did not see that even a minimal level of rough
> consensus was demonstrated to remove site local addresses.
>
> The claim was made on the list that there was not consensus
> to keep site local addresses, I think that is the wrong
> question to ask - the proposal was to change a specification
> after its publication there should have been a rough
> consensus to remove the feature.
>
> I did not see rough consensus to do so based on my monitoring
> the list.
>
> Scott
>
> (this is the letter I sent back in July on the topic)
>
> From sob Mon Jul 28 15:11:01 2003
> To: ***@Sun.COM
> Subject: Re: state-of-art SLs
> Cc: ***@sunroof.eng.sun.com
> In-Reply-To: <***@bebop.france>
>
>
> > 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.
>
> humm - it is not all that often that we have said that 2/3 is
> rough consensus in the IETF - in my exterience if 1/3 is not
> in support then I would not claim consensus (even 6 grit) -
> 3/4 would be very rough indeed, 5/6 would be the mininum I
> would say was "rough consensus"
>
>
> just when does "rough consensus" faid out in this model?
>
> Scott
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
EricLKlein
2003-10-20 17:28:47 UTC
Permalink
----- Original Message -----
From: "Bound, Jim" <***@hp.com>

One point I would like to make in regards to this item:

> 3. Were the needs of the market considered in the decision? I don't
> think by all but do we ever use this bar? As I said to you once when
> you were on the IESG consistency is imperative. The market is
> reprsented by our participants. If participants are not here to support
> the IETF they do not get heard. We have no way to trust one or a few to
> represent an entire market other than present their individual view.
> That may or may not influence the WG, it depends on the respect the
> individual has with their peers I guess?


Setting aside personal opinion on this topic, I think that the WG vote
process of the mailing list should have a much stronger deciding factor in
making this type of decisions than the meetings. Not to understate the value
of the meetings, but as they are spread over quite a geographic area, and
many of us are not funded to attend too many of this type of event
(especially those of us in industry).

I would like to suggest a more standard voting is worked out. Possibly using
a log of e-mail addresses (I know this does away with secret votes, but
keeps them honest) and check off buttons. There are many sites that offer
free voting (the ISOC uses them).

Just my opinion,
Eric
Loading...