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 <hinden(_at_)iprg(_dot_)nokia(_dot_)com>
To: ipv6(_at_)ietf(_dot_)org
Cc: hinden(_at_)iprg(_dot_)nokia(_dot_)com, Brian Haberman
<brian(_at_)innovationslab(_dot_)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: ipng(_at_)sunroof(_dot_)eng(_dot_)sun(_dot_)com
From: Bob Hinden <hinden(_at_)IPRG(_dot_)nokia(_dot_)com>
Subject: Moving forward on Site-Local and Local Addressing
Cc: hinden(_at_)iprg(_dot_)nokia(_dot_)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
ipv6(_at_)ietf(_dot_)org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------