Last Call Review of draft-ietf-softwire-map-t-05
review-ietf-softwire-map-t-05-genart-lc-romascanu-2014-10-06-00

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