Hi, Dan,
Thanks for your review and the comments.
Romascanu, Dan (Dan) 写道:
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.
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.
.
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.
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
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 …’
Thanks. We will fix above issues during the RFC editor phase.
Regards,
Dan
Best regards,
xing
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art