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

> 
> 
> On 25 June 2012 17:28, Rémi Després <[email protected]> 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
> 
> 

_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to