Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

[Rémi Després <[e-mail]>]

2012-06-26 à 10:50, Wojciech Dec:

> 
> On 26 June 2012 10:37, Rémi Després <[e-mail]> wrote:
> 
> 2012-06-26 à 09:37, Wojciech Dec:
> 
>> On 26 June 2012 09:13, Rémi Després <[e-mail]> wrote:
>> 
>> Le 2012-06-26 à 08:04, Wojciech Dec a écrit :
>>> 
>>> On 25 June 2012 17:28, Rémi Després <[e-mail]> 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
> 
>