Subject: [Gen-art] Gen-ART Telechat review of draft-ietf-softwire-map-t-05.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 13 Oct 2014 14:14:08 +0000

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: http://www.ietf.org/id/draft-ietf-softwire-map-t-05.txt

Reviewer: Dan Romascanu

Review Date: 10/6/2014

IETF LC End Date: 10/10/2014

IESG Telechat date: 10/16/2014

Summary:

Almost Ready.

There was no updated version of this document since I sent the original review. My previous comments still stand.

The document is well written and the technical content is clear. There are however a number of issues which I recommend to be clarified before the document is approved.

Major issues:

1.       It is unclear to me how this document fits into the charter of the softwire WG. The MAP-T solution defined in this document is described in the Introduction as:

Ø  The MAP-T solution differs from MAP-E in
the use of IPv4-IPv6 translation, rather than encapsulation, as the form of IPv6 domain transport.

                However, the WG charter says:

> IPv4/IPv6 translation mechanisms, new addressing schemes, and block address assignments are out of scope.

Is this a different type of IPv4-IPv6 translation than the one considered by the original charter out-of-scope? Did the scope of the WG change in time, but the charter was not updated? Some clarification is needed.

2.       The status of this document is Experimental. It is not clear why. There are no experimental documents in the softwire WG charter, and the status of the 'sister' document draft-ietf-softwire-map is Standards Track. Why the difference?

3.       The document uses the term MAP without expanding it. It is probably supposed to be 'Mapping of Address and Port'. However, the title of draft-ietf-softwire-map identifies MAP as the expansion of 'Mapping of Address and Port with Encapsulation' and never uses the MAP-E expansion used here. The terminology and abbreviations in the two documents must be aligned.

4.        Section 5 says:

Ø     The MAP-T algorithmic mapping rules are identical to those in
   Section 5 of the MAP-E specification [I-D.ietf-softwire-map], with
   the exception of Section 5.4 concerning the forwarding of traffic to/
   from IPv4 nodes outside the MAP-T.

If such is the case draft-ietf-softwire-map needs to be a Normative Reference. This Section cannot be fully understood and implemented without draft-ietf-softwire-map.

Minor issues:

1.       The 2119 keywords are used in an inconsistent manner in some places. Take as an example Section 10. The subsections describe three mechanism that deal with fragmentation and path MTU discovery. Section 10.3 uses SHOULD language while section 10.1 and 10.2 uses 'recommended' or 'has to'.

2.       Appendix A uses the IPv4 address 1.2.3.4 as an example address which is against the guidance in RFC 5735.

Nits/editorial comments:

1.       BMR and FMR occur in the text a few times before they are expanded in section 8.1 - please expand at first occurrence

2.       In the Introduction s/end-end/end-to-end/ and s/optimalise/optimize/

3.       3. Section 7.1 - the first sentence has no verb in it

4.       Also in in Section 7.1 - the last paragraph can be dropped - this was already said in the section

5.       In Section 9 I cannot make sense of the sentence that starts with 'In the return ...'

Regards,

Dan

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 13 Oct 2014 14:46:20 +0000

Hello Dan,

Thank you for you comments. I’m reading an updated draft, however there is one point that I am unable to address fully:

“2."2.       The status of this document is Experimental. It is not clear why. There are no experimental documents in the softwire WG charter, and the status of the ‘sister’ document draft-ietf-softwire-map is Standards Track. Why the difference?”

Together with the other authors, we fully agree that the draft does not fit the “experimental” status, as in it actually uses standards track technology (NAT64) as well as the sister (standard track) MAP. There also are a number of reports about MAP-T testing (http://tools.ietf.org/html/draft-cordeiro-experience-mapt-01 ), and a handful of commercial implementations. As Xing commented earlier on, the decision on the track was made by the WG by means of a coin toss, which in our opinion wasn’t based on technical merits.

Regards,
W. Dec

From: <Romascanu>, "Dan (Dan)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, 13 October 2014 16:14
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Gen-ART Telechat review of draft-ietf-softwire-map-t-05.txt
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Wojciech Dec <[email-masked]<mailto:[email-masked]>>, Xing Li <[email-masked]<mailto:[email-masked]>>
Resent-Date: Monday, 13 October 2014 16:14

Reviewer: Dan Romascanu

Review Date: 10/6/2014

Summary:

Almost Ready.

Major issues:

2.       The status of this document is Experimental. It is not clear why. There are no experimental documents in the softwire WG charter, and the status of the ‘sister’ document draft-ietf-softwire-map is Standards Track. Why the difference?

3.       The document uses the term MAP without expanding it. It is probably supposed to be ‘Mapping of Address and Port’. However, the title of draft-ietf-softwire-map identifies MAP as the expansion of ‘Mapping of Address and Port with Encapsulation’ and never uses the MAP-E expansion used here. The terminology and abbreviations in the two documents must be aligned.

4.        Section 5 says:

Minor issues:

1.       The 2119 keywords are used in an inconsistent manner in some places. Take as an example Section 10. The subsections describe three mechanism that deal with fragmentation and path MTU discovery. Section 10.3 uses SHOULD language while section 10.1 and 10.2 uses ‘recommended’ or ‘has to’.

Nits/editorial comments:

1.       BMR and FMR occur in the text a few times before they are expanded in section 8.1 – please expand at first occurrence

3.       3. Section 7.1 – the first sentence has no verb in it

4.       Also in in Section 7.1 – the last paragraph can be dropped – this was already said in the section

5.       In Section 9 I cannot make sense of the sentence that starts with ‘In the return …’

Regards,

Dan

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Oct 2014 11:28:24 -0400

Hi Dan,

On 10/13/2014 10:46 AM, Wojciech Dec (wdec) wrote:
> Hello Dan,
>
> Thank you for you comments. I’m reading an updated draft, however there
> is one point that I am unable to address fully:
>
> “2."2.The status of this document is Experimental. It is not clear why.
> There are no experimental documents in the softwire WG charter, and the
> status of the ‘sister’ document draft-ietf-softwire-map is Standards
> Track. Why the difference?”
>
> Together with the other authors, we fully agree that the draft does not
> fit the “experimental” status, as in it actually uses standards track
> technology (NAT64) as well as the sister (standard track) MAP. There
> also are a number of reports about MAP-T testing
> (http://tools.ietf.org/html/draft-cordeiro-experience-mapt-01 ), and a
> handful of commercial implementations. As Xing commented earlier on, the
> decision on the track was made by the WG by means of a coin toss, which
> in our opinion wasn’t based on technical merits.

Just so that nobody misunderstands what happened with the coin toss, I 
will explain what the coin toss was about. First off, I want to state 
that MAP-T's experimental status **WAS NOT** determined by a coin toss.

The coin toss only determined whether MAP-E and MAP-T were to be treated 
as one solution or two. The WG was split on this question and I opted to 
ask the ADs for a coin toss to resolve this deadlock. Period. The coin 
toss was not used for anything else.

The questions I used can be found in the proceedings at

http://www.ietf.org/proceedings/84/slides/slides-84-softwire-15.pdf

MAP-E was confirmed as the Standards track solution starting with this 
thread that I initiated.

http://www.ietf.org/mail-archive/web/softwires/current/msg04719.html

The WG opted to publish MAP-T as an experimental document as a result of 
*another* consensus call. Thread at

http://www.ietf.org/mail-archive/web/softwires/current/msg04817.html

Hope this clarifies things a bit.

Thanks
Suresh

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 14 Oct 2014 15:41:34 +0000

Hi Suresh,

your description, which I don¹t dispute, does not convey the importance of
Q5, which ultimately was the question the chairs verified via the call on
the WG mailer. I.e. The choices for progressing the MAP-T draft, post
split from MAP-E, were:
- ³Experimental from the WG²
- ³Don¹t work on them in the WG²

Given that there were numerous parties that wanted it to remain a WG
document, the net effect of the coin-toss was thus, indeed to split from
MAP-E standards track, and to put MAP-T on the ³experimental track².

Historical clarifications aside thought, and perhaps more relevantly, the
MAP-T authors do not think that the draft¹s designation as ³Experimental²
is technically objectively justified.

Regards,
Wojciech.

On 14/10/2014 17:28, "Suresh Krishnan" <[email-masked]>
wrote:

>> Thank you for you comments. I¹m reading an updated draft, however there
>> ³2."2.The status of this document is Experimental. It is not clear why.
>> status of the Œsister¹ document draft-ietf-softwire-map is Standards
>> Track. Why the difference?²
>>
>> fit the ³experimental² status, as in it actually uses standards track
>> in our opinion wasn¹t based on technical merits.
>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Oct 2014 11:50:15 -0400

Hi Woj,

> is technically objectively justified.

Noted. Unfortunately, the Gen-ART list is not the right forum for this 
discussion. If you feel strongly about this, we can discuss alternatives 
on the softwire working group mailing list.

Thanks
Suresh

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 14 Oct 2014 16:00:24 +0000

Clearly the last sentence below should have ended in *unjustified*. Sorry
for the typo.
 
Last post from me on this topic, as I'll leave this to the IESG.