As a member of the MAT DT, I am naturally biased in favor of what Xing, Maoke and Ole said.
I also think that the chair's questions are not adequate. I don't think that the questions should be which of document the wg choose, make documents to be unified or not. I think that it should be what 'solution space' has been clarified beyond the MAP suite. Let me try to figure these out. 1. Reduce the number of parameters for MAP configuration The MAP currently needs bunch of parameters such as 'Rule IPv6 prefix', 'Rule IPv4 prefix' and 'EA-bits length' for each of BMR, FMR and DMR. It would be more convenient when one or some of them can be reduced or omitted. 2. Trying to keep more header transparency When operators think that it would be nice if the MAP-T can keep header transparency, which includes checksum neutrality, beyond the current header translation specification, the wg should be work on that, or ask other wg to do that. 3. Truly 'Unified' operation Since encapsulation and translation are completely separated operation in operator's network (I mean 'polarized' on Jan's comment) but the implementation of both is possible into one box. Beyond just 'unified document', does operators think it would be more attractive with 'unified' operation for which both encapsulation and translation co-exist in same time, on same network, for same service. Above three are my thought of what 4rd-u proposed to the wg. Discussions and more suggestions are welcome. Best regards, --satoru On 2012/03/23, at 10:46, Ole Trøan wrote: > Alain, et al, > > we have been at an impasse, so thank you very much for proposing a path > forward. > >> 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. > > I do agree with that. the Venn diagram for the three solutions would look > awfully similar to a single circle. ;-) > there are some use cases though, that can only be fulfilled with one mode of > transport versus the other. > I left the interim meeting in Beijing having been convinced that there are > use cases requiring both encapsulation and requiring translation. if we for a > moment accept that, I would suggest that we treat MAP as one single solution. > it will have two options/flavours of transport. > >> 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. > > with the above proposal, we can drop question 3. > >> 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. > > can ask the chairs to take a hum of how many would want t-shirts for the > meeting with: "Just pick one for F's sake and stop arguing". ;-) > > cheers, > Ole > _______________________________________________ > 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
