Le 16 nov. 2014 à 04:54, Ted Lemon <[email protected]> a écrit :
> On Nov 15, 2014, at 10:24 AM, Rémi Després <[email protected]> wrote: >> This seems to suggest that someone viewed this issue had been "a factor in >> the coin toss". >> No one did AFAIK, and certainly not me. >> But this isn’t the point. > > If it wasn't a factor in the coin toss, it doesn't have anything to do with > the working group's decision to choose Experimental vs. Proposed status. This was exactly my point. End of this subject fro me. >> Even in its experimental status, I do think MAP-T's specification should >> have included a warning that it is incompatible with Path MTU Discovery of >> RFC4821, and that MAP-E should be used if such compatibility is desired. > > I would not object to such a statement if the authors and the working group > agree to add it, Yes, beyond authors themselves, the WG is concerned in what the RFC will say. Avoiding such clarification in the RFC after this discussion would amount, IMHO, to consciously withholding useful information. > but that's not the question we're asking at the moment. If the current question is whether an operational limitation exists in MAP-T, which would justify to keep it experimental, the answer is: Incompatibility with the only ICMP-independent PMTU discovery in IPv4 (as specified in standard-track RFC 4821). Regards, RD PS: Ole Troan just mentioned, rightly, that the 464XLAT of RFC6877 (specified by Behave) had the same limitation. To be noted: - RFC6877 explicitly concerns a "technique to quickly deploy limited IPv4 access service" (underline added). Even if what its operational limitations aren’t explained, this is an warning that that some limitation exists. - Explaining in the RFC what was the known IPv4 service limitation was IMHO a must, and I made the point in Behave. A text proposal for it was proposed by Gang Chen (as referenced by Ole). - Yet, the WG had a majority vote against such clarification. What influenced decision to withhold relevant information is still unclear to me, and IMHO unfortunate. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
