Re: [Softwires] map-t to proposed standard rather than experimental

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

13 nov. 2014  21:00, Ted Lemon <[e-mail]>  :

> On Nov 13, 2014, at 6:29 AM, Rémi Després <[e-mail]> wrote:
>> If the IESG, now proposes 2 standards instead of 1, that’s a choice I view as based on a misunderstanding.
> 
> The IESG proposes one standard with three profiles or, if you prefer, three standards instead of two.
> 
>> I therefore vote against a WG support of this proposal.
> 
> You were not asked for a vote.

Wasn’t so clear, but OK.

> You were asked if you had any technical objection: some reason why MAP-T might have interop problems or operational problems and thus ought to be only an experiment and not a standard.

(a) Incompatibility with path MTU discovery  (standard-track RFC4821) is, in my understanding, sufficient a reason to keep MAP-T experimental.  

(b) I understand that the MAP-DHCP draft includes specifications for both MAP-E and MAP-T, and that an RFC cannot be both standard and experimental track.
Isn’t it possible, in the MAP-DHCPv6 RFC to have:
- for stateful operation, a MUST for lw4over6
- for stateless, a MUST for MAP-E, and, for MAP-T, a "MAY as long as it remains experimental, to become a MUST if and when "

If (a) is deemed insignificant, and (b) is found impossible, I guess  there is no more useful contribution I can hope to make for IPv4 across IPv6. 

Regards,
RD


 

>  A process objection would also be viable, but as I've explained, I don't think there _is_ a process objection you could raise here.
>