Hi, Ralph, More comments in line.
2012-04-05 15:02, Ralph Droms: > > On Apr 5, 2012, at 4:07 AM 4/5/12, Rémi Després wrote: > >> Hi, Alain, Yiong, Ralph, Brian, >> >> 1. >> In view of the lack of sufficient consensus at the Softwire meeting for a >> choice between MAP-T+E and 4rd-U, several suggested, at the end of the >> meeting and after on the ML, to publish MAP-T+E and 4rd-U as experimental, >> with the expectation to select one later on. > > Assessment of the consensus in the WG meeting is informative but not final. > As is usual IETF practice, the chairs are now assessing WG consensus on the > mailing list. Therefore, it is too early to make a decision to publish both > specifications as Experimental. > >> As a matter of fact, this is in substance what Alain had proposed before >> IETF 83 if, during the meeting, there would be no consensus for one standard >> track and the other(s) informational. No such consensus having emerged, that >> would be the natural outcome. >> >> In the mean time, a vendor having announced on the ML its intention to >> "implement 4rd-u and do operational tests", it is clear that better >> understanding of issues will be possible to enlighten the WG before a final >> decision on what deserves standard track. > > You raise an issue that, to my memory, has not been explored in any great > detail. > The MAP specification documents have been published and stable (with, I > think, one minor exception) since January, (*) No revision has been seen since January for 3 of them, yes, but this is despite the need to correct them, AT LEAST concerning the following acknowledged points: - MAP-A+P says "Each MAP node in the domain has the same set of rules", in contradiction with MAP-T - MAP-T doesn't deal yet with the need of different packet IDs from shared-address CEs - MAP-E needs a correction for BR hairpinning - MAP-DHCP needs to be updated, at least to add a topology parameter to request hub and spoke In other words, stable yes, but because bugs remained uncorrected. > while 4 revisions of the 4rd-u document have been published, with what appear > to be major revisions, in that same time period. After January, the first revision included 3 co-authors including one ISP, another included one more co-author from a mobile operator, the latter was to deal with two valid remarks made on the mailing list. Anything wrong with that? On the opposite, concerning MAP team operation: a) There is no visibility on how the MAP team worked (no archives). b) The presented list of team members included names of some individuals who clearly don't agree with what was presented on their behalf. c) One wonders why such an efficient team hasn't corrected identified bugs (is it to pretend work was completed?) d) The "MAP team report" presented in Paris included a grossly erroneous list of 4rd-U features while, by the chair's decision, discussion on 4rd-U was to take place in the WG itself. This was NOT a work item to be discussed internal to the MAP team. > My understanding is that there is running code for the MAP specification > (both transport variants). Partial running code and partial test, sure, but the fact is that repeated requests that tested scenarios be documented with their mapping rules remained unanswered. > We've already delayed progress on the "stateless" specification since you > announced the first versions of 4rd-u. Now you are asking us to wait to make > a decision for a vendor who has "announced on the ML its intention to > "implement 4rd-u and do operational tests"". The present state of the > maturity and experience with MAP and 4rd-u should be considered at this point > in time as the WG expresses its preference for a way forward. > >> 2. >> Question 1 below (*) formally excludes, independently from received >> responses, any possibility that both solutions be published as experimental >> (Yes => One on standard track; No => both on standard track.) > > This question about "both Experimental" only needs to be asked if there is no > clear consensus to support publication of one specification. Absence of clear consensus was clear in Paris. Mailing list is AFAIK appropriate to confirm a consensus, not to quickly mask a lack of consensus by means of a weird voting procedure. >> I therefore note that this procedure, in addition to be confused (who may >> answer, with which conclusion process), is illegitimate. >> Taking this procedure as conclusive would therefore lead to an application >> of RFC2026 sec 6.5.1 (Working Group Disputes). >> >> OTOH, publishing now MAP-T+E and 4rd-U as WG documents on the experimental >> track would be indisputable. > > I disagree. > > That decision would be premature prior to assessment of WG consensus to > publish one or the other. Trying now to turn around the lack of consensus in IETF 83, using for this a highly criticizable procedure, remains unacceptable, sorry for that. If nothing else, your current ignorance of the real state of MAP documents (see (*) above) would justify to let passion to settle down. To conclude, I like agreements and consensus, and do regret to have to make the above points. Yet, too much would be too much, and would justify to apply 6.5.1 of RFC 2026, with whoever will join. Regards, RD > > - Ralph > >> >> Regards, >> RD >> >> >> Le 2012-04-04 à 23:14, Alain Durand a écrit : >> >>> Dear Softwire wg members: >>> >>> At the Paris IETF Softwire meeting, we had presentations on MAP (taken as a >>> whole) and >>> 4rd-U. We got very strong feedback that we needed to select one >>> solution to cover that full stateless case, not two, and that we should >>> make this >>> decision relatively quickly. >>> >>> During Paris meeting, we asked the following additional question: >>> Do you prefer MAP or 4rd-U? >>> We got about 1/3 support for 4rd-U and 2/3 for MAP. >>> >>> The real gauge of consensus is the mailing list, so we would like >>> to ask the same questions to the list. >>> >> >> (*) >>> ===================================================================== >>> Question 1: Do you agree that the wg should put EITHER 4rd-U OR MAP (as a >>> whole) on the standard track, >>> the other being published as experimental or informational. >>> Answering YES to this question means you agree we cannot publish both as >>> standard track. >>> Answering NO to this question means you want to see both advance on the >>> standard track. >> >> >> >>> ---------------------------------------------------------------------------- >>> Your full name, your affiliation, your choice: YES or NO >>> ---------------------------------------------------------------------------- >>> >>> >>> ===================================================================== >>> >>> Questions 2: Which one do you want to see placed on the Standards Track: >>> 4rd-U or MAP? >>> >>> ------------------------------------------------------------------------------ >>> Your full name, your affiliation, your choice: 4rd-U or MAP >>> ------------------------------------------------------------------------------ >>> >>> ===================================================================== >>> >>> >>> >>> >>> Please fill out the following form and reply to the list >>> by Wednesday 4/10 5pm EDT. >>> >>> Note: Use this thread ONLY for expressing your support to >>> one OR the other, and redirect any discussions to other threads. >>> That would help up gauge consensus. >>> >>> Alain & Yong. >>> _______________________________________________ >>> Softwires mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
