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:sob@harvard.edu] > Sent: Friday, October 10, 2003 10:17 AM > To: iab@iab.org > Cc: iesg@ietf.org; ietf@ietf.org; ipv6@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: Erik.Nordmark@Sun.COM > Subject: Re: state-of-art SLs > Cc: ipng@sunroof.eng.sun.com > In-Reply-To: <Roam.SIMC.2.0.6.1059396655.12753.nordmark@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 > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >