Francis, thank you very much for the thorough review! comments inline.
> 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: draft-ietf-softwire-map-10.txt > Reviewer: Francis Dupont > Review Date: 20141009 > IETF LC End Date: 20141010 > IESG Telechat date: 20141016 > > Summary: Ready > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > First please note I participated to Softwire WG work so it is possible > the document is not understantable by someone who has no knowledge > about the topic. I'll ask another member of the gen-art team to look > at it to check this particular point. > Other comments: > - there are more than 5 authors. RFC 7322 (the new RFC Style Guide) > provides an accurate (i.e., more than previously) indication > about this problem. we are aware of that, a complicated pre-history here. the softwire chairs are taking that directly with the IESG. > - ToC page 2 and 13 page 20: Acknowledgements -> Acknowledgments my quest for British English in RFCs is failing I see. the other English spellings you identify have been changed to American as well. > - 1 page 3: (FYI comment): RFC 1933 automatic tunneling was > historically the first way to run IPv6 (end of March 1995 > when IPv6 over Ethernet ran only at the July IETF meeting > the same year). So in fact the RFC was published in 1996 > but the mechanism itself was implemented a year before... thank you, interesting to know. changed reference to 1995. > - 1 page 4: IMHO there is no need to expand the MAP abbrev > at its first use because it is in the title (note this would > not apply if it was in the Abstract). couldn't find this one? > - 1 page 4: provider's(SP) -> provider's (SP) fixed. > - 3 page 5: NAPT should be in the terminology, in particular > because the standard abbrev is more NAT-PT we're referring to RFC2663. NAT44 with port translation. I've moved the reference to the first place in the text that NAPT is mentioned. > > - 3 page 5 and many other places: e.g. -> e.g., and i.e. -> i.e., thanks fixed. > > - 4 page 6: encapsulation/ -> encapsulation / ack. > - 4 page 7: figure 1 should be in one page (the RFC Editor should > take care of this in his final editing). > > - 5 page 8: a missing closing parenthesis in "MAP BR (see Section 5.4." fixed. > > - 5.1 page 8: minimise -> minimize ack. > - 5.2 page 10: /prefix -> / prefix fixed > > - 6 page 13: figure 8 in one page (cf figure 1) > > - 11 page 19: glitch in the text version: > "Attacks facilitated by restricted port set:" changed. > > - 12 page 19 and 20, and Authors' Addresses page 32: > CN is not a valid Country in a postal address, I suggest China > or better P.R. China ack. wonder if we could skip the addresses in the contributors section. any precedence here? > > - A Example 3 page 25: please expand FMR in the example title. ack. > > - A Example 5 page 26: avoid page break after a title > > - A Example 5 page 27 (twice): DHCP. -> DHCP ack. > > - A Example 5 page 27: please expand BMR abbrev (i.e., make the text > easier and more pleasant to read). done. thank you again. I'll integrate these changes in revision -11 that'll be posted today ready for the IESG telechat on the 16th. Best regards, Ole _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
