2012-06-26 à 10:50, Wojciech Dec: > > On 26 June 2012 10:37, Rémi Després <[email protected]> wrote: > > 2012-06-26 à 09:37, Wojciech Dec: > >> On 26 June 2012 09:13, Rémi Després <[email protected]> wrote: >> >> Le 2012-06-26 à 08:04, Wojciech Dec a écrit : >>> >>> On 25 June 2012 17:28, Rémi Després <[email protected]> wrote: > ... > >>> Having asked several times for a list of substantial evolutions from >>> previous MAP drafts, with their justifications, and having received no >>> answer, I see this statement as an indirect but first answer. >>> >>> Woj> You were provided with an answer (pls see Ole's mail). >> >> Could you please indicate which one? > > Since you claim there has been an answer, and suggest I find it, I suppose > you can find it yourself. > => Please answer (or implicitly acknowledge that the list of MAP substantial > evolutions is still awaited). > > http://www.ietf.org/mail-archive/web/softwires/current/msg04358.html
Sorry, but I am lost! This reference is that of my query, not that of an answer by Ole. > It's a short list : > - MAP-E and MAP-T drafts have been merged. > - Handling of the corner cases regarding DMR but no BMR added An explanation on this point would be appreciated. Which sentences of the draft deal with this? > - Non normative text regarding use (eg backwards compatibility) added. A less "short" list has yet to be made. It should include AFAIK: - 5th DMR parameter addition (as long as the deletion you suggest below hasn't been discussed an approved in the WG) - ability to disable NAT functionality (which has a normative MUST in the draft) >>> But it doesn't seem acceptable (*): >>> - AFAIK, the added 5th parameter of basic mapping rules is more than >>> editorial >>> >>> Woj> Please indicate what the new parameter in your opinion is. >> >> In Section 5, "Forwarding mode" has become a BMR 5th parameter. >> In Section 5 of the mdt draft of january 30, there were only 4 BMR parameter. >> >> Anything missed? >> >> Ok, so fair point. MAP-E and -T have been merged in the draft, based on >> previous feedback from the WG incl discussions at the last meeting. We >> thought having less drafts is more as was discussed at the last meeting. The >> updated draft also highlights how much commonality there is. > > - A parameter PER DOMAIN was an obvious result of a merger. > - But a parameter PER RULE is a significant novelty. > OK? > > That was not intended, and appears to be a genuine mistake in draft-00. > Thanks for spotting. > It is a parameter per domain, as discussed on the design team alias. The specification is AFAIK viable with this 5th parameter, and some may find it useful. Since it is now a WG matter, individuals who would like to delete it from the specification should propose it on the mailing list. (FWIW, I have personally no objection to its deletion). RD > > -Woj. > >> We're welcome to suggestions on how to provide information on which >> transport mode to use, or if the merger is no desired. >> >>> - I didn't find the equivalent of the following sentence in previous >>> drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in the >>> 1:1 case, and with no IPv4 address and port range configured by other >>> means, MUST disable its NAT44 functionality." >> >> Is there such an equivalent? >> Please answer (not answering the question isn't a way to eliminate it). >> >> Equivalent of what? > > Is there in previous drafts the sentence above (or an equivalent) "A MAP-E > CE... MUST disable its NAT44 functionality."? > - If yes, please indicate where. > - If not, IT IS an evolution, to be identified as such. > > >> Note: I asked you how you would propose dealing with the DMR but no BMR >> corner case, and await your proposal.. > > - In the 4rd draft, appendix D, there is a deployment example with only on > mapping rule (the BR mapping rule, AKA the DMR in your MAP draft). > - If this isn't sufficient to answer your concern, please point to the mail > in which you asked the unanswered question. Subject closed, I suppose. > > Thanks, > RD > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
