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

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

Le 2012-06-26 à 08:04, Wojciech Dec a écrit :

> 
> 
> On 25 June 2012 17:28, Rémi Després <[e-mail]> wrote:
> 
> 2012-06-25 à 16:24, Wojciech Dec:
> ...
> > The updated MAP draft does not change the MAP architecture nor its technical underpinnings. In fact there are no changes, bar editorial to the normative parts of MAP,
> 
> 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?

> 
> 
> 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?


> - 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).

> Woj> Well, perhaps you would like to suggest what the CPE should do in the case the CPE is issued with a default mapping rule, ie a default route in map terms, and the absence of an assigned IPv4 address or other parameters (BMR). The above appears to be reasonable behaviour.
> 
> => A carefully studied list of substantial changes MAP supporters have found appropriate after the Paris meeting remains to be due.
> 
> Woj> Take it from the other people who have done implementations, technically there are no changes.

In their implementation, maybe, but we talk about the specification.

RD


> 
> -Woj.
> 
> 
> 
> > something that is proven by existing implementations prior to this draft supporting the current draft.
> 
> Please understand that your stating that some tests (for which we don't have detailed reports) should be considered a proof that what you say is true, is difficult to accept.
> Especially if what you say seems contradicted by a verifiable fact (see (*) above).
> 
> RD
> 
>