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

["Mallette, Edwin J." <[e-mail]>]

Hi Remi,

Thanks for your comments.  My added comments are below...

On 11/11/14, 11:46 PM, "Rémi Després" <[e-mail]> wrote:

>Hi Ted,
>
>You are right in that an old decision may always be revisited before
>casting it in concrete.
>Yet, changing an old decision has to be done carefully, especially if
>consequences of the change haven¹t been documented.
>Comments below suggest that wisdom is rather to maintain the old decision
>as it is: only one standard for stateless IPv4 connectivity across
>IPv6-only domains.
>
>Le 11 nov. 2014 à 22:11, Ted Lemon <[e-mail]> a écrit :
>
>> Dear softwire participants,
>>
>> As we've gotten closer to finally finishing the stateless
>>address-sharing suite of softwire specifications, I've had to explain
>>what happened to a number of different people, both in the directorates
>>and on the IESG, and even to nomcom.  As a consequence I've had to do a
>>lot of thinking about why things wound up the way they did, and whether
>>what happened was the right outcome.
>>
>> As a result of the directorate reviews and the IESG review, it became
>>clear that the plan to advance MAP-T as experimental didn't make sense.
>AFAIK, not at all as clear as you say:
>- If  both MAP-E and MAP-T would become standard, CPE providers would
>need to support (and maintain) both.

[EJM] it has never been the case that just because a standard exists that
can be used on an element, that said suppliers of that element have to
implement the standard. They implement standards on their devices based on
their customer demand. I fully expect that MAP-T will be implemented in
production networks and having broad deployments of a protocol documented
in an experimental-track RFC seems to be in poor judgement.

>
>- If both would become standard, full transparency to IPv4 fragmentation,
>which is guaranteed with MAP-E but not with MAP-T, would no longer be
>guaranteed to any customer, due to multiple standards.

[EJM] This is not something I care about operationally. It seems like an
academic argument, not a practical one.


>- If an ISP domain would activate both, CPEs would have to select one of
>the two standards for their transmissions, with AFAIK no advice on how to
>do it.

[EJM] Necessity is the mother of invention; given this turns out to be a
problem, I¹m unconcerned.  I¹m sure the smart people this impacts can get
together and document such advice.


>
>
>> The three solutions, MAP-E, MAP-T and Lightweight 4over6 actually make
>>a lot of sense when presented together.
>
>MAP-E and lw4over6 make a lot of sense, yes, but not with MAP-T in
>addition:
>- MAP-E is and lw4over6 have well separated uses ( stateless and static,
>stateful and dynamic)
>- MAP-E and MAP-T are two different solutions for essentially the same
>use. (Their DHCPv6 commonality is not an operational consideration.)
>
>>   Because of this there is no reason that one should be experimental
>>and the other two standards track.
>
>The above shows that there are such reasons.
>Deciding such a change without re-visiting technical arguments would
>depart from customary IETF practice.
>While the consensus on making MAP-E the only standard has held for long,
>re-visiting technical arguments would lead to an undesirable extra delay
>before the already-over-awaited MAP finalization.

[EJM] My view is that this is a mischaracterization. The decision from my
POV was to move these drafts forward in light of a clear understanding
that there would be no converging around the religious debates. Remember
the coin flip ?  That¹s not exactly a technical decision.


>
>> I would therefore like the working group to consider changing the
>>proposed status of MAP-T to Proposed Standard.
>
>> I think this would be a less confusing outcome.
>
>Completely opposite view, based on the above.
>
>> If the working group agrees, we would go through a second IETF last
>>call and then advance the document.
>>
>> I have not made the same suggestion with respect to 4RD because it
>>actually is quite different from the other three documents.
>
>Wise decision, in line with the current WG consensus.
>
>>   This is not intended as an editorial comment about 4RD: rather, it's
>>simply that I think the three documents together offer a good suite of
>>solutions that can be understood and implemented together, whereas 4RD
>>is essentially its own solution.   I think the working group has already
>>chosen to advance the MAP-style lightweight solutions, and it would
>>actually be confusing to advance 4RD as a separate standard solution.
>
>> Suresh and Cui Yong will be asking the working group to weigh in on
>>this issue, and then assuming no blocking objections are raised we will
>>re-do the IETF last call for map-t as a proposed standard.
>
>What makes objections to become blocking may be unclear, but I hope that
>the above will be enough for the WG to maintain its old and wise
>consensus.
>
>Best regards,
>RD
>
>
>>
>> Thanks!
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>
>_______________________________________________
>Softwires mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/softwires


________________________________

CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. **If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.