Hi Tom, Thank you for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Tom Taylor [mailto:[email protected]] > Envoyé : mercredi 15 juillet 2015 16:59 > À : Gen Art; BOUCADAIR Mohamed IMT/OLN; Suresh Vinapamula; Terry Manderson > Objet : Last Call review of draft-vinapamula-softwire-dslite-prefix- > binding-07 > > 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-vinapamula-softwire-dslite-prefix-binding-07 > Reviewer: Tom Taylor > Review Date: 2015-07-15 > IETF LC End Date: 2015-08-05 > IESG Telechat date: 2015-08-20 > > Summary: technically straightforward and well written with nits and a > minor issue. Most of the nits are to make the text sound better to an > anglophone ear. > > Major issues: > > Minor issues: > > In the Security Considerations section, it might be appropriate to > discuss the security (privacy?) consequences of misdirected traffic due > to address change (if the recommendations are not implemented), and to > prefix change in any event. [Med] Makes sense. I added this NEW text: Also, the recommendations in Section 4 ensure the traffic is forwarded to a legitimate CPE. If those recommendations are not implemented, privacy concerns may arise (e.g., If an IPv6 prefix is reassigned while mapping entries associated with that prefix are still active in the AFTR, sensitive data that belong to a previous prefix owner may be disclosed to the new prefix owner). > > Nits/editorial comments: > > Sec. 1, para 1, fourth line: s/that is/which is/ > > Sec. 1, next-to-last para: > OLD > to avoid the same prefix be assigned to the same customer > NEW > to avoid assigning the same prefix to the same customer > > Sec. 2, second para, second line: s/may be/maybe/ > " " , fifth line: s/no more/no longer/ > > Sec. 2, fourth para, second line: missing "of" after "fairness" > " " , eighth line, missing "changes" after "IPv6 address" > > Sec. 2, fourth para: the sentence > "To that aim, a subscriber should be identified by the > AFTR based upon the IPv6 prefix assigned to the corresponding CPE, > and not according to the derived B4's IPv6 address." > introduces a solution to the problem (redundantly, since that solution > is stated at the end of the section) rather than simply identifying the > problem. May I suggest replacing it with: > "If the derived B4's IPv6 address can change, resource tracking using > that address will give incomplete results." > > Sec. 3, second para, third line: s/to configure/configuring/ > > Sec. 4, bullet 1, indented para, first line: s/to mount/from mounting/ > " " " fourth line: s/quota was/quota were/ > Subjunctive voice is grammatically correct here, but less commonly > used these days, so the suggestion is totally optional. > > Sec. 4, bullet 2, fourth line: missing "a" in front of "configured". > > Sec. 4, bullet 3, sixth line: missing "the" in front of "B4's". > > Sec. 4, bullet 6, sixth line: missing "having" in front of "to > redirect", or alternatively, s/to redirect/redirecting/. [Med] Fixed. Thank you. > > In the Acknowledgements section there is an XML2RFC issue with extra > spaces after the periods delimiting the initials. Or is this the result > of applying the space fixing program available on the Tools page? [Med] The extra spaces is generated automatically by xml2rfc. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
