Le 2012-04-06 à 17:36, Ralph Droms a écrit : > > On Apr 6, 2012, at 11:04 AM 4/6/12, Rémi Després wrote: > >> >> Le 2012-04-06 à 16:35, Brian Haberman a écrit : >> >>> On 4/6/12 3:42 AM, Rémi Després wrote: >>>> Hi, Brian, >>>> >>>> First, welcome as new Internet-area AD. Also, thanks for the >>>> reference and the quote. >>> >>> Thanks. >>> >>>> >>>> Note however that, in this particular instance, this quote will not >>>> be of any help because it concerns "issues which have not been >>>> discussed on the mailing list". >>>> >>>> On the contrary, RFC 2418 says: >> >> (*) >>>> "There are two different cases where >>>> a working group may be trying to understand the level of consensus >>>> via a mailing list ... - In the case where a consensus which HAS BEEN >>>> REACHED during a face-to-face meeting is being verified on a mailing >>>> list ... - The other case is where the discussion has been held >>>> ENTIRELY over the mailing list" (upper cases added). >>>> >>>> Facts are that: - No consensus has been reached during the >>>> face-to-face meeting. - There has been extensive discussion on the >>>> mailing list. - The only action that has been announced in absence of >>>> consensus was publication of all specifications as experimental. >>> >>> Would you agree that the outcome of the WG session in Paris is that there >>> was not a clear consensus to choose either one of the options? >> >> Yes. >>> I have not seen anyone dispute that there was not a clear consensus to >>> choose one option over the other. >> >> I haven't either. >> >>> Hence, everyone agrees there was not a consensus in the face-to-face >>> meeting. In that situation, does it make sense to ask a broader audience >>> (the entire mailing list) the same set of questions? >> >> Sorry to answer it is inappropriate: >> - The case isn't,in RFC2418, one of the two, "where a working group may be >> trying to understand the level of consensus via a mailing list" (see (*) >> above) > > We may have to agree to disagree here.
> It is always the IETF practice to hold the binding consensus call on the > mailing list. Yes, this is the first case mentioned in RFC 2418 and copied above: "case where a consensus HAS BEEN REACHED". But lack of consensus isn't a REACHED consensus. > That consensus call is being conducted now. Any determination of WG > consensus is premature until the results of the consensus call are complete. > >> - To make it worse, the chair, during the meeting itself, already tried to >> change the result >> by asking a second time, after some had already left, the same question >> about a preference between MAP and 4rd. > > > This statement is wrong and makes an inappropriate implication about the > chairs' motives. The chairs asked for a second assessment of consensus after > asking those in the room to reconsider their position to see if some > consensus could be reached. Yet there were less people in the room, which makes it special. >> The same ratio between the two answers happens to have been obtained, but >> who knows what would have been concluded otherwise? >> - Publishing all drafts on experimental track had been previously announced >> as the (logical) result in case no single solution for standard track would >> be agreed on. > > I will repeat myself: until the consensus call on the WG mailing list is > complete, there is no determination of consensus or lack of consensus. May I repeat myself too: that lack of consensus isn't a reached consensus that, according to the rules, needs to be verified. > The correct action is to wait until the mailing list consensus is assessed > before making a determination about how to publish the various documents. > >>>> There is therefore no justification I know to further delay >>>> publication of ALL specifications as WG drafts, on experimental >>>> track. - As I already said to the chairs, I am ready to do it as soon >>>> as authorized. - I understand that MAP-E+T drafts will also be >>>> treated the same, and that's obviously fair. >>>> >>>> As already said too said, if procedures continue to be distorted, I >>>> will have no other choice than referring to RFC 2026 section 6.5.1, >>>> and signal, on behalf of co-authors of the 4rd-U proposal, "a >>>> difficulty with Working Group process", with an "appeal to the IESG >>>> as a whole". >>> >>> That is your prerogative. >> >> Yes, but, please be sure that we have a clear preference for not having to >> use it. >> Trying by all means, including with a self-authorized procedure, to prevent >> market-based decision should be avoided. > > I object here as well to your implication that there is an effort "to prevent > market-based decision". Suspicion is at least justified, by the chair being listed as member of the MAP team (Ole's slide). > The chairs are working hard to do their due diligence in assessing and > determining WG consensus about how to proceed. > You have one point of view, but that point of view does not constitute WG > consensus. Well aware of that. Yet, both MAP-T+E and 4rd-U on experimental track is the less criticizable approach at this point, and permits "market-based decision". RD > > - Ralph > >> >> Thanks, >> RD >> >> >> >> >>> >>> Regards, >>> Brian >>> >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
