Re: Path to move forward with 4rd…

<div>
<br><div>
<div>Le 2012-03-25 &agrave; 14:08, Maoke a &eacute;crit :</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<br><br><div class="gmail_quote">2012/3/25 R&eacute;mi Despr&eacute;s <span dir="ltr">&lt;<a href="mailto:despres.remi@...">despres.remi@...</a>&gt;</span><br><blockquote class="gmail_quote">
<div>
<br><div>
<div>Le 2012-03-25 &agrave; 05:34, Maoke a &eacute;crit :</div>
<div class="im">
<br><blockquote type="cite">dear Remi,<br><div class="gmail_quote">2012/3/24 R&eacute;mi Despr&eacute;s <span dir="ltr">&lt;<a href="mailto:despres.remi@..." target="_blank">despres.remi@...</a>&gt;</span><br><blockquote class="gmail_quote">
<div>
<br><div>
<div>Le 2012-03-22 &agrave; 15:40, Maoke a &eacute;crit :</div>
<div>
<br><blockquote type="cite">dear Alain, Yong, Ralph and all,<div><br></div>
<div>in program, the effort of the MAP team should be respected. The formation of the MAP team was also the consensus of our meeting in beijing and we have seen the the team is working with clear progress. I don't think it is correct now to insert 4rd-u into a sort of exclusive decision of choice. And 4rd-u also has the address format elements abondoned by the MAP design team. I believe the MAP format reflects that the common understanding concludes the insignificance of those features. Sorry but the chair's questions &nbsp;a little confused me: if we need to go back to the stage before the works of the MAP design team? &nbsp;</div>

<div><br></div>
<div>The MAP series have reached running codes </div>
</blockquote>
<br><blockquote type="cite"><div>and the collective understanding of the community.</div></blockquote>
<div><br></div>
</div>
<div>Here are some issues among those remaining before reaching "collective understanding":</div>

<div>&nbsp;</div>
</div>
</div>
</blockquote>
<div>&nbsp;</div>
<div>some issues remaining not yet reaching collective undertanding is not a reason of making things over. the collective understanding has been reached for the major part of the </div>

<div>1) MAP address format and the corresponding algorithms</div>
<div>2) encapsulation and translation modes being&nbsp;supported by MAP format and the existing header processing&nbsp;standards&nbsp;</div>
<div>3) DHCP extensions as a way of distributing rules. </div>

<div>&nbsp;</div>
<div>the above big picture&nbsp;are what i call "collective understanding". the correct way is:&nbsp;making&nbsp;these already gained approaches as bases, continuing discussion&nbsp;or even dabate on the details. i don't think it is a correct way of action to disrespect a team's work. 4rd-u's&nbsp;problem is even its big picture is still fuzzy. </div>
</div>
</blockquote>
<div><br></div>
</div>
<div>Not more fuzzy than MAP (actually less fuzzy IMHO).</div>
<div>Debate on details is possible for U as wall as for T+E.</div>
<div>&nbsp;</div>
</div>
</div>
</blockquote>
<div>&nbsp;</div>
<div>
you may argue that MAP is much more fuzzy. but as i said, nobody knows exactly what the "4rd-u tunnel" is. </div>
</div>
</blockquote>
<br><blockquote type="cite"><div class="gmail_quote"><div>you said it is just a reversible header mapping that is not tunnel </div></div></blockquote>
<div><br></div>I rather say that reversible header mapping implements a "tunnel" variant.</div>
<div>&nbsp;</div>
<div>
<blockquote type="cite"><div class="gmail_quote"><div>nor translation path section. </div></div></blockquote>
<br><blockquote type="cite"><div class="gmail_quote"><div>then what does the "reversible header mapping" provides to the architecture of transition? you never clearly state this. </div></div></blockquote>
<div><br></div>The draft is AFAIK not ambiguous.</div>
<div>I tried to answer all your questions on this point I barely understand (neither an implementation nor an operation issue)</div>
<div><br></div>
<div>End of this point for me, if there is nothing significantly new.</div>
<div><br></div>
<div>
<br><blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote"><div>
<div>
<div class="im">
<blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote"><div><div>
<div>a) T operation in hub&amp;spoke (hasn't been so far answered in an understandable way).</div>
</div></div></blockquote>
<div>&nbsp;</div>
<div>i doubt i understand what you mean. may you please specify the question in details? </div>
</div></blockquote>
<div><br></div>
</div>Is a DHCPv6 parameter needed, yes or no?</div>
<div>&nbsp;</div>
</div></blockquote>
<div>&nbsp;</div>
<div>i am not sure i know&nbsp;about the details of what you mean. </div>
</div></blockquote>
<div><br></div>
<div>Today, there is no DHCPv6 parameter to require H&amp;S, right?</div>
<div>My question is then: "is it sufficient to have none, or is it needed to add a new parameter".</div>
<div>Looking at more details would be premature for me until you have answered this question.</div>
<div><br></div>
<br><blockquote type="cite"><div class="gmail_quote">
<div>do you mean the feature of R-2.C? if so, i happen to have following questions:</div>
<div>1) why hub&amp;spoke topology should be announced to the CE? (IMHO, if a&nbsp; CE is informed with the FMR involving other CEs, it works as mesh; if only BMR and DMR is informed, surely it is hub&amp;spoke. i think this has been clarified in MAP Section 5.)</div>
<div>2) to this parameter issue, what is the difference between T and E? </div>
</div></blockquote>
<div><br></div>None AFAIK.<br><div><br></div>
<br><blockquote type="cite"><div class="gmail_quote">
<div>look forward to your further clarification/discussions! if you mean not the hub&amp;spoke mode indicator, please specify your question further. </div>
<div>&nbsp;</div>
<blockquote class="gmail_quote"><div>
<div>&nbsp;</div>
<div>
<div class="im">
<blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote"><div><div>
<div>b) IDs from shared-address CEs.&nbsp;&nbsp;T currently has&nbsp;so far no solution while both U and E include one.&nbsp;</div>
<div>&nbsp;</div>
</div></div></blockquote>
<div>&nbsp;</div>
<div>what do you mean with the IDs? or&nbsp;do you mean interface IDs?&nbsp;i don't see "IDs&nbsp;from shared-address&nbsp;CEs" in U too. please teach!</div>
</div></blockquote>
<div><br></div>
</div>
<div>Sec 4.5.3. is "Packet Identifications from Shared-Address CEs".</div>
<div>Did you read the complete draft?</div>
<div>&nbsp;</div>
</div>
</div></blockquote>
<div>&nbsp;</div>
<div>
execuse me. it is my fault. i read it but i didn't realize you mean the datagram identification here. it is a good point, and not only this but also the issue of how BR deals with fragments of the same datagram where only the first fragment has the port number.&nbsp;for this point,&nbsp;i think MAP-T also needs to consider this problem described in the MAP-E Section 7, last 2 paragraphs. thanks a lot!</div>
</div></blockquote>
<div><br></div>
<div>(*)</div>
<div>End of this subject.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote"><div>
<div>
<div class="im">
<blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote"><div><div>
<div>c) MAP-A+P says "Each MAP node in the domain has the same set of rules" while MAP-T says "if a CE knows only a subset of the mapping rules ..." &nbsp;</div>
<div>&nbsp;</div>
</div></div></blockquote>
<div>&nbsp;</div>

<div>first of all, they are not conflicting logically.</div>
</div></blockquote>
<div><br></div>
</div>???</div>
<div>
<div class="im">
<br><blockquote type="cite"><div class="gmail_quote">
<div> second, if you mean one doc is superior than multiple with better consistency in writing, i could agree. </div>
</div></blockquote>
<div><br></div>
</div>This is not the point.</div>
<div>Separate documents can be consistent, but they aren't on this point.</div>
<div><br></div>
<div>One of the two assertions must be changed.&nbsp;</div>
<div>
Remaining question: which one?</div>
<div>&nbsp;</div>
</div></blockquote>
<div>&nbsp;</div>
<div>well. this is why i said they are not conflict in logic. as a definition of the MAP rule, right, each MAP node in the domain SHOULD have the same set of rules. however, in practice of operation, it is possible that this MAY not strictly achieved due to some information losses (which is often happens in the Internet environment), MAP-T defines the CE working as it were in&nbsp;hub&amp;spokes mode for an unknown destination CE.</div>
</div></blockquote>
<div><br></div>I am not aware that a CE might receive some of the MAP DHCPv6 parameters but not all due to lost packets.</div>
<div>Clarification on this will be welcome.</div>
<div><br></div>
<div>
<br><blockquote type="cite"><div class="gmail_quote">
<div> the text of Sec 8.2 of MAP-T and that of Sec 8.2 of&nbsp;MAP-E are clear enough to me. no one among MAP/MAP-T/MAP-E&nbsp;here needs to be changed. (i may partly agree with you that one could be further clarified). </div>
<div>&nbsp;</div>
<blockquote class="gmail_quote"><div>
<div>
<br>&nbsp;</div>
<div>
<div class="im">
<blockquote type="cite"><div class="gmail_quote">
<div>but it doesn't mean one doc is definitely reflecting "collective understanding" better than multiple. </div>
<div>&nbsp;</div>
<blockquote class="gmail_quote"><div><div>
<div>&nbsp;</div>

<div>d) Whether T can work with a single mapping rule (as was, I think, the case for IVI). So far DMR and BMR seem exclusive, and there is no way to distinguish them in MAP-dhcp.</div>
<div>&nbsp;</div>
</div></div></blockquote>

<div>&nbsp;</div>
<div>single mapping rule for a domain != single mapping rule for the IPv4 world. </div>
</div></blockquote>
<div><br></div>
</div>???</div>
<div>
<div class="im">
<br><blockquote type="cite"><div class="gmail_quote">
<div>the IVI (RFC6052/6145/6219) practice does the latter. the latter doesn't need DHCP to distribute the mapping rule. in the MAP, i don't think DMR and BMR being exclusive is a problem. </div>
</div></blockquote>
<div><br></div>
</div>How many MAP mapping rules do you see for the equivalent of the IVI use case in a MAP domain?&nbsp;</div>
<div>&nbsp;</div>
</div></blockquote>
<div>&nbsp;</div>
</div></blockquote>
<br><blockquote type="cite"><div class="gmail_quote"><div>if you mean the single mapping rule in IVI case, the answer is NONE, surely. IVI uses RFC6052 address format rather than the MAP, without the business of MAP. </div></div></blockquote>
<div><br></div>
<div>OK</div>
<div>(In this respect at least, IVI significantly differs from a running version of MAP-T).</div>
<br><blockquote type="cite"><div class="gmail_quote">
<div>&nbsp;</div>
<div>if you mean using the MAP for the single translation as we did in IVI (though actually we have IVI working for both single and double translations simultaneously),&nbsp;MAP-T Sec 8.3 has answered your question. </div>
</div></blockquote>
<div><br></div>Saying that there is no mapping rule in IVI is sufficient an answer.</div>
<div><br></div>
<div>
<br><blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote"><div>
<div>None?&nbsp;</div>
<div>If one, is it a DMR or a BMR?</div>
<div>If two, what are they?</div>
<div>
<div class="im">
<div><br></div>
<div><br></div>
<blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote"><div>
<div>The fact that no-one involved in the MAP design raised any of these issues is AFAIK sign that MAP has NOT reached "collective understanding of the community".</div>
<div>(Note that, concerning stateless v4/v6 solutions, I think I should be considered&nbsp;part of this community. Right? ).</div>
<div>&nbsp;</div>
</div></blockquote>
<div>&nbsp;</div>
<div>well, "collective understanding" was mentioned by Sally Floyd to the community of Internet researchers,&nbsp;and i borrowed her term. but i understand: no matter it is research or engineering, collective understanding is the understanding on the problems and the&nbsp;architecture rather than the detailed technical solutions. the MAP architecture has been reflected in the works of the draft suite. on the other hand, the community is not the softwires wg but the whole Internet engineering circle. </div>

<div>&nbsp;</div>
<blockquote class="gmail_quote"><div>
<div>&nbsp;</div>

<div><br></div>
<div>Maoke, clarifications on these points will be welcome.</div>
<div><br></div>
<div><br></div>
<div>
<div>
<blockquote type="cite">
<div>From a view of a middle-sized ISP and cloud service provider, we do support to accept MAP series into standard track in order we can utilize it into business as soon as possible.&nbsp;</div>

<div><br></div>
<div>in technology, first of all, MAP now has approached address mapping algorithm and that enough to make the series a unified solution. In our practice, we need to use either encapsulation or translation according to the actual needs and environment. </div>

</blockquote>
<div><br></div>
</div>Note: This excludes&nbsp;ISPs that would like to offer full IPv4 transparency with some IPv6-only middles boxes.</div>
<div>Right?</div>
<div>&nbsp;</div>
</div></blockquote>
<div>&nbsp;</div>
<div>i cannot follow your "full IPv4 transparency" with "some" IPv6-only middle boxes. what does the "transparency" mean for the middle boxes? i understand, when we talk about the Internet transparency, we refer to the "end-to-end transparency". please specify your question concretely. </div>
</div></blockquote>
<div><br></div>
</div>
<div>OK, could have been clearer.</div>
<div>Yet, I think you understand that with U, one&nbsp;has&nbsp;SIMULTANEOUSLY, transparency to DF=MF=1 and applicability of IPv6-only middle boxes that look at TCP ports.</div>
<div>&nbsp;</div>
</div>
</div></blockquote>
<div>&nbsp;</div>
<div>ok. then may i conclude, for the major part of U,&nbsp;that 1) U, as a stated&nbsp;enhancement for&nbsp;double translation,&nbsp;gain the transparency for DF=MF=1 (the 10^-6 minor cases, commonly thought abnormal);</div>
</div></blockquote>
<div><br></div>1) A statistic at a given time, and in a given place, isn't a proof that the same ratio will be found later and somewhere else.</div>
<div>2) Those that happen to be in the sacrificed minority, be it small, may not like their situation. Solving the problem, be it only for them, is progress.</div>
<div><br></div>
<div>
<blockquote type="cite"><div class="gmail_quote"><div> 2) with introducing #1. weird definition of the fragment header of IPv6; #2 weird packet of IPv6 carrying ICMPv4 messages? </div></div></blockquote>
<div><br></div>AFAIK, not weird to those who are open to accept that it is very simple.</div>
<div><br></div>
<div>
<br><blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote"><div><div>
<div class="im">
<blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote"><div><div>
<div>
<blockquote type="cite">
<div>The most important is, both the building blocks of transition architecture: virtual link (supported by encapsulation/tunneling) and participant of the delivery path (supported by translation), have their suitable use cases. And their advantages and limitations have been well investigated and understood by the community.&nbsp;</div>

<div><br></div>
<div>second, i deeply discussed and explored 4rd-u, but i found its attempting of mixing the tunneling and translation, if accepted as standard, may trap the operators into a harsh situation of being unable to define what building block it really is. </div>

</blockquote>
<div><br></div>
</div>
<div>Such an operator would know it uses 4rd-U.&nbsp;</div>
<div>&nbsp;</div>
</div></div></blockquote>
<div>&nbsp;</div>
<div>well, this is&nbsp;what i&nbsp;mean the uncertainty of 4rd-U in the architecture to the common understanding. as a analogy, one of Mr.&nbsp;E and Mr. T said, "i give you a horse", while&nbsp;the other&nbsp;said "i give you a donkey". then people well understand when they need a horse when they need a donkey. now Mr. U said "wow, i give you a fantastic donkorse!". there would be&nbsp;2 possible results, not certain right now: </div>

<div>A. donkorse is just another sort of donkey, somehow good but somehow flawed. </div>
<div>B. donkorse is just donkorse, and people, taking a long time to understand it, and finally find it either a flawed or a quite good hybrid, like mule, useful in some cases. </div>

<div>&nbsp;</div>
<div>no matter if the future result is A or B, now Mr. O understand what he needs for his business is either a horse and a donkey, with their well-known characteristics. Mr. MAP provides a wheeled car as&nbsp;the common instrument, while Mr. O needs a standard suite for the wheeled-car, the horse-driving and donkey-driving methods and the way of feeding the horse and donkey.&nbsp;this is the&nbsp;task of our wg, right now. &nbsp;</div>

<div>&nbsp;</div>
<div>Mr. U said you must have another type of wheel and drive it with my donkorse --- and when Mr. O asked him, what your donkorse is, he answered: you will know it is donkorse, having both the advantages of the horse and the advantages of the donkey. however, Mr. O doubts donkorse hasn't also the disadvantages of horse and the disadvantages of donkey and some flaws not yet documented. why not? </div>

<div>&nbsp;</div>
<blockquote class="gmail_quote">
<div><div>
<div>&nbsp;</div>

<div>This doesn't seem to justify any FUD&nbsp;from co-authors from broadband and mobile operators (or from product vendors).</div>
<div>
<br><blockquote type="cite">
<div>It is stated as tunneling but actually behaves like tunnel in some aspects while like translation in some other aspects.</div>

</blockquote>
<div><br></div>
</div>
<div>Yes indeed, thus achieving the best of both worlds without making it more complex. Actually making it clearly less complex than supporting both T and E.</div>
<div>&nbsp;</div>
</div></div>

</blockquote>
<div>&nbsp;</div>
<div>i don't think those who made out mule expected the mule could replace horse and donkey and achieving a better world without horse and donkey but only mule. surely mule-only world is simpler. </div>
</div></blockquote>
<div><br></div>
</div>
<div>Comparison is not reason (French proverb).</div>
<div>&nbsp;</div>
</div></div></blockquote>
<div>&nbsp;</div>
<div>i just try to understand what the 4rd-u reversible header mapping really&nbsp;is, in the term of architecture. this analogy is written&nbsp;as problem understanding rather than a&nbsp;reason&nbsp;of anything. &nbsp;</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote"><div><div>
<div>&nbsp;</div>
<div class="im">
<br><blockquote type="cite"><div class="gmail_quote">
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<div>
<div><div>
<blockquote type="cite"><div> (I have pointed out in the 4rd-u discussion thread).</div></blockquote>
</div></div>
<div>
<div>
<blockquote type="cite">
<div> We see it only a yet-another-translation that try to solve some corner problems but introduces new, possibly major flaws (also pointed out in the technical threads on 4rd.) </div>

</blockquote>
<div><br></div>
</div>
<div>"Possibly major flaws" isn't an identified point on which U would do less than what it has been designed to do (unified replacement of T + E).</div>
<div>&nbsp;</div>
</div>
</div>

</blockquote>
<div>&nbsp;</div>
<div>i believe they are major flaws but i was gently argued with the "possibly" because i respected that maybe others didn't think so critically like me. </div>
</div></blockquote>
<div>
<br>
</div>
</div>
<div>I have still to understand where you see "major flaws".</div>
<div>Just asserting they exist, without explanation although others who read the specification don't see them isn't enough.</div>
<div>&nbsp;</div>
</div></div></blockquote>
<div>&nbsp;</div>
<div>well, i mostly argue that&nbsp;the ICMPv4 being carried by IPv6 and CNP are major flaws (as we discussed so much, i was not convinced at all). i don't think others who read the specification don't see them and other issues. </div>
</div></blockquote>
<div><br></div>
<div>ICMPv4 payloads in IPv6 packets appear only during domain traversal, where they don't hurt anyone.</div>
<div><br></div>
<div>If a host is IPv6 only, it isn't a 4rd-U host.&nbsp;</div>
<div>For communication between IPv4-only applications of DS hosts and IPv6-only hosts,&nbsp;there are already workable RFCs.&nbsp;</div>
<div>BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient.&nbsp;</div>
<div>A new solution for this isn't needed.&nbsp;</div>
<div><br></div>
<br><blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote"><div><div>
<div>Saying that E+T is better because its current inconsistencies are "details" isn't enough either (IMHO).</div>
<div class="im">&nbsp;</div>
</div></div></blockquote>
<div>&nbsp;</div>
<div>different problems. E + T is actually not only the MAP-E and MAP-T, but the utilization of existing, already mature E and T with the new&nbsp;MAP format.&nbsp;&nbsp;</div>
<blockquote class="gmail_quote"><div><div>
<div class="im">
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"><div>
<div>
<div>IMPORTANT: &nbsp;</div>
<div>- The essential characterization of U (vs T and E) is its Reversible header mapping (as replacement of both Double RFC6145 translation and Encapsulation).</div>
<div>&nbsp;</div>
</div>
</div></blockquote>
<div>&nbsp;</div>
<div>yet-another-translation, with some issues still in debates. </div>
</div>
</blockquote>
<div>&nbsp;</div>
</div>
<div>You can call it as you wish, but the point remains that, with U, one doesn't need both E and T.</div>
<div>&nbsp;</div>
</div></div></blockquote>
<div>&nbsp;</div>
<div>no. U has changed the layered model of Internet protocol stack. </div>
</div></blockquote>
<br><blockquote type="cite"><div class="gmail_quote"><div>an operator definitely needs the encapsulation as a fully featured virtual link (underlay infrastructure)&nbsp;in real O&amp;A for IPv4 communications over IPv6 infrastructure. U cannot replace E at all. </div></div></blockquote>
<div><br></div>Different understanding.</div>
<div>An detailed E use case that cannot be supported by U&nbsp;(if it exists)&nbsp;would give substance to this claim.</div>
<div>Open to look at it. &nbsp;</div>
<div>
<br><blockquote type="cite"><div class="gmail_quote"><div>on the other hand, an operator needs the translation to encourage transition and mutual communications between IPv4 and IPv6 and double translation is included in such an environment. T has specifications for this working</div></div></blockquote>
<div><br></div>BIH does the job with single translation.</div>
<div>Where U applies, both ends are IPv4, T has&nbsp;AFAIK&nbsp;no operational superiority while U is more transparent.</div>
<div><br></div>
<div>
<br><blockquote type="cite"><div class="gmail_quote"><div> but U needs still discussion </div></div></blockquote>
<br><div>
<div>T too.</div>
<div>See, for example, (*) above.</div>
</div>
<br><blockquote type="cite"><div class="gmail_quote"><div>and running code approval. it cannot replace T at least this moment. </div></div></blockquote>
<div><br></div>
<div>Understanding how U's header mapping works doesn't need great expertise.</div>
<div>Co-autors readily understood it, with origins as varied as router-and-host vendor, software vendor, broadband operator, mobile operator.</div>
<div><br></div>
<div>Running code as soon couldn't be done yet, but isn't a big deal at all (see (**) below)</div>
<div><br></div>
<div><br></div>
<blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote"><div><div>
<div class="im">
<blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote"><div>
<div>
<div>- Other features of U that differ from MAP&nbsp;(V-octet, CNP), or are complementary to it (Rule&nbsp;IPv6 suffix, NAT64+), are secondary in this respect. Each of these features&nbsp;could be abandoned in U, or, if the WG appreciates what they offer, added to MAP.</div>

<div>&nbsp;</div>
</div>
</div></blockquote>
<div>&nbsp;</div>
<div>MAP team has concluded V-octet and CNP are not necessary. do we need to debate again? i doubt people have unlimited time. </div>
</div></blockquote>
<div><br></div>
</div>
<div>I made the point many times that the right to analyze problems didn't stop after a majority decision obtained during an improvised meeting.</div>
<div>Many MAP contributors were absents, and no time was given to correct invalid objections that had been made just before during a WG meeting.</div>
<div><br></div>
</div></div></blockquote>
<div>&nbsp;</div>
<div>the reason is simple, </div>
</div></blockquote>
<br><blockquote type="cite"><div class="gmail_quote"><div>MAP can work even without the V-octet and CNP, at least in significant cases.</div></div></blockquote>
<div><br></div>Not a valid reason to stop progress, especially if easy to understand.</div>
<div>At least Med suggested to look at V octet even in the context of MAP (if chosen for standard track).</div>
<div>
<br><blockquote type="cite"><div class="gmail_quote"><div>&nbsp;if we have the standard of MAP, we&nbsp;can immediately&nbsp;deploy it into practice through applying MAP rules into the&nbsp;already well understood, well approved, well standardized&nbsp;encapsulation and translation modules, &nbsp;without&nbsp;waiting for the approval of the new features in the address format, and the approval of the reversible header mapping tightly coupled with the address format. </div></div></blockquote>
<div><br></div>
<div>(**)</div>
<div>When we discussed in Taipei, you first said you might code 4rd-U so that it could be tested for real. You didn't do it for reasons that I perfectly respect.</div>
<div>Yet, modifying T code to support header mapping remains quite simple (you even call it a translation variant). Starting from E code, it's simple too.</div>
<div>When this is done, all verifications can be easily done that what analysis says is right is also right with running code.</div>
<div><br></div>
<div><br></div>
<div>Regards,</div>
<div>RD</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div>&nbsp;</div>
<br><blockquote type="cite">
<div class="gmail_quote">
<div>&nbsp;</div>
<div>- maoke</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote"><div>
<div>
<div></div>
<div>Note that several co-authors of the U proposal have been MAP contributors. &nbsp;</div>
<div>&nbsp;</div>
</div>
</div></blockquote>
<blockquote class="gmail_quote">
<div>
<div>
<div>&nbsp;</div>
<div class="im">
<div><br></div>
<br><blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote">
<div><div>
<div>- For this, community acceptance to listen to explanations, would be the normal process. I&nbsp;will be available this week for this.</div>
<div>&nbsp;</div>
</div></div>
</blockquote>
<div>&nbsp;</div>
<div>i think we are all open to listen to and to discuss on any explorations but it doesn't mean we should stop standardization of our wheeled-car/horse-driving/donkey-driving/feeding suite with an expectation of a "better world" with only donkorse and the donkorse-specific wheeled car.</div>
</div></blockquote>
<div><br></div>
</div>
<div>Your stand is clear, but comparison isn't reason.</div>
<div><br></div>
<div>RD</div>
<div>
<div></div>
<div class="h5">
<div><br></div>
<div><br></div>
<div><br></div>
<br><blockquote type="cite">
<div class="gmail_quote">
<div>regards,</div>
<div>maoke</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">

<div>
<div>
<div>&nbsp;</div>
<div><br></div>
<div>Cheers,</div>
<div>RD</div>
<div>
<div></div>
<div>
<div><br></div>
<br><blockquote type="cite">
<div>In either the term of architectural philosophy or technical details, introducing 4rd-u into standards would be harmful.&nbsp;</div>

<div><br></div>
<div>personally, i respect the exploration of the author(s), and the discussion between me and the author encouraged me to comprehensively review E and T, and the result is: i bacame much more confident of the correctness of the MAP track. We should move forward.&nbsp;</div>

<div><br></div>
<div>regarding the chair's questions, my answer is:&nbsp;<span>MAP, MAP-E/T, MAP-DHCP are of a whole suite needing to be put into standard track. Question is not about T, E or U.&nbsp;</span>
</div>
<div><br></div>
<div>best regards,</div>
<div>Maoke</div>
<div>
<br>&#22312; 2012&#24180;3&#26376;20&#26085;&#26143;&#26399;&#20108;&#65292;Alain Durand  &#20889;&#36947;&#65306;<br><blockquote class="gmail_quote">

Dear wg,<br><br>
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.<br><br>
1) There &nbsp;is an observation that all the solutions on the table E, T &amp; U actually solve the stateless &nbsp;problem we started with.<br>
 &nbsp; &nbsp;There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation<br>
 &nbsp; &nbsp;proposals, U is an hybrid unifying solution.<br><br>
2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those<br>
 &nbsp; &nbsp;documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track.<br><br>
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 &amp; U).<br>
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.<br><br>
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<br>
and their sequence.<br><br>
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?<br><br>
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.<br>
If the answer is YES, we move to the next question.<br><br><br>
Q2: Do you believe that the WG should publish U as the one Standards Track document?<br><br>
If the answer is YES, the process stop, we put U on the Standard Track and publish E &amp; T as Informational.<br>
If the answer is NO, we are left with E &amp; T (U then might be abandoned or published as Historical/Informational)<br><br><br>
Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)?<br><br>
If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational.<br>
If there is no clear consensus on this question, we will publish both E &amp; T as Experimental.<br><br>
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.<br><br>
 &nbsp;Alain &amp; Yong, wg co-chairs.<br>
_______________________________________________<br>
Softwires mailing list<br><a>Softwires@...</a><br><a href="https://www.ietf.org/mailman/listinfo/softwires" target="_blank">https://www.ietf.org/mailman/listinfo/softwires</a><br>
</blockquote>
</div>
_______________________________________________<br>Softwires mailing list<br><a href="mailto:Softwires@..." target="_blank">Softwires@...</a><br><a href="https://www.ietf.org/mailman/listinfo/softwires" target="_blank">https://www.ietf.org/mailman/listinfo/softwires</a><br>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
<br>
</div>