Le 2012-03-23 à 11:13, <mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com> a écrit :
> Dear WG members, > > I didn't had time to read the last version of 4rd-U but I read carefully -03 > when it was published. Note that -04 and -05 are significantly improved. Expertise of its now co-authors include broadband and mobile services as ell as product vendors. AFAIK, no reason why it wouldn't work, or do less than claimed, remained unanswered. If later on a flaw or uncertainty is identified, and confirmed after discussion, this will be fairly acknowledged. > I really appreciated the work done by Rémi to write down -03. The document is > well written, easy to read and the requirements are clearly sketched. I > really think this spirit should be adopted by MAP documents. > > As I already told Rémi, I would like if all proponents of stateless A+P > converge and avoid wasting energies in comparing individual proposals. I > thought this is what has been agreed during the softwire interim meeting: > IMO, MAP effort meets the objective of group work. > > Some of the points raised by Rémi can be easily considered in the context of > MAP; except the idea of unified header which is a step forward. Adopt a > unified approach is exclusive to encapsulation and/or translation. > > The question now is: Does the unified approach bring new features + > simplification compared to the normal IPv4-in-IPv6 encapsulation scheme > (which I'm mainly interested in)? The answer is: No. > > Perhaps this is selfish but given what I mentioned above, I vote for the > following: > * Adopt the work of the MAP design team as the base specification for > stateless A+P effort. > > * Make sure proposals from Rémi (except U) are discussed: This may be taken as "I don't care how many designs are standardized... provided my use case is covered by one of them". This is not AFAIK the best approach to simplify standards we make for the future. The chair encouraged further work on U after IETF 82 after arguments used to exclude it in Taipei were acknowledged to be invalid. Excluding to discuss U although it provides a unified design, with more operational features than either T or E, seems to me difficult to justify. Regards, RD > e.g., Checksum neutrality > (1) Share the archives of MAP Design Team discussion > (2) Use IETF Issue Tracker to record the issues and the consensus/conclusion > (3) Adopt a clear procedure within the Design Team to make decisions when > there are conflicts > > * Reduce the amount of MAP documents: IMHO, three documents are needed > (1) MAP Address Format > (2) MAP Overall Architecture and Design Recommendations > (3) MAP DHCPv6 Options > > Cheers, > Med > >> -----Message d'origine----- >> De : softwires-boun...@ietf.org >> [mailto:softwires-boun...@ietf.org] De la part de Alain Durand >> Envoyé : mardi 20 mars 2012 00:39 >> À : Softwires WG >> Cc : Yong Cui; Ralph Droms >> Objet : [Softwires] Path to move forward with 4rd. >> >> Dear wg, >> >> After a number of discussions with my co-chair, our AD and >> various authors, here is how we would like to move forward wrt 4rd. >> >> 1) There is an observation that all the solutions on the >> table E, T & U actually solve the stateless problem we started with. >> There are differences, but it is unclear if those >> differences are really significant. E and T are the original >> Encapsulation and Translation >> proposals, U is an hybrid unifying solution. >> >> 2) We have already agreed back in Beijing that we would >> publish all necessary documents. The issue here is the 'label' >> or 'status' those >> documents have at IETF. In particular, do we want to >> publish them as Experimental, Informational or Standard Track. >> >> We are at the point now where we need to make progress. In >> Paris, we would like to ask for presentations from the >> proponents of each candidate solution (E, T & U). >> Each presentation should cover an overview of the proposed >> solution, explain how it compares to the others and make a >> case as why it should be the one on the Standard Track. We >> will allocate 20 minutes for each presentation. >> >> Then, we, chairs, would like to ask a series of questions to >> the working group. In order to make this process transparent, >> here is the list of questions we want to ask >> and their sequence. >> >> Q1: Without pre-supposing which one will be selected, do you >> agree to publish 1 of the 3 proposals on the Standard Track >> and publish the other(s) as Informational if still asked to? >> >> If the answer is NO, then the process stops and we will >> publish everything as Experimental and come back in 12-24 >> months to see what gets adopted by the market. >> If the answer is YES, we move to the next question. >> >> >> Q2: Do you believe that the WG should publish U as the one >> Standards Track document? >> >> If the answer is YES, the process stop, we put U on the >> Standard Track and publish E & T as Informational. >> If the answer is NO, we are left with E & T (U then might be >> abandoned or published as Historical/Informational) >> >> >> Q3: Which of E and T do you want to see moving on the standard >> track (you can only express support for one)? >> >> If there is a clear outcome from this question, we would >> publish that proposal on the Standard Track and the other one >> as Informational. >> If there is no clear consensus on this question, we will >> publish both E & T as Experimental. >> >> In the meantime, we would like to encourage discussion on the >> mailing list to foster our common understanding of the various >> technologies and how they relate to each other. >> >> Alain & Yong, wg co-chairs. >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
