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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 6 Oct 2014 13:01:50 +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>.

Please resolve these comments along with any other Last Call comments you may receive.

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.

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: Ted Lemon <[email-masked]>
Date: Mon, 6 Oct 2014 15:52:45 -0400

> 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 clarifi…

The translation mechanism used is just NAT64.

---

From: Xing Li <[email-masked]>
Date: Tue, 07 Oct 2014 08:09:47 +0800

Hi, Dan,

Thanks for your review and the comments.

Romascanu, Dan (Dan) 写道:
> 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:
>
> 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.
>

This is the decision of the WG and moves forward in Softwire Interim 
Meeting in Beijing, Sept, 2011. 
http://www.ietf.org/mail-archive/web/softwires/current/msg02631.html We 
may add some historical background in the next version.

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

Unfortunately, this is the decision made by coin toss 
http://en.wikipedia.org/wiki/Mapping_of_Address_and_Port
Thanks to point out. We think MAP-T should also be in the Standards 
Track, same as MAP-E.

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

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

Agree to cite draft-ietf-softwire-map as a Normative Reference.

> 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
>
> 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 …’
>

Thanks. We will fix above issues during the RFC editor phase.
> Dan
Best regards,

xing

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Oct 2014 22:03:13 -0400

On Oct 6, 2014, at 8:09 PM, Xing Li <[email-masked]> wrote:
> This is the decision of the WG and moves forward in Softwire Interim Meeting in Beijing, Sept, 2011. http://www.ietf.org/mail-archive/web/softwires/current/msg02631.html We may add some historical background in the next version.

I don't think this is necessary.   I believe this document is in charter because it is just using NAT64 in a new way, not defining a new translation mechanism.   The message you quoted doesn't really address the issue; I suspect this was discussed with Ralph back then, but I think we are okay.   However, it's possible that the IESG will want to explore the issue further; worst case, we recharter.   I don't think this needs to be addressed in the document.

---

From: Xing Li <[email-masked]>
Date: Tue, 07 Oct 2014 10:33:08 +0800

> I don't think this is necessary.   I believe this document is in charter because it is just using NAT64 in a new way, not defining a new translation mechanism.   The message you quoted doesn't real…
I agree, thanks! xing