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
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
