Skip to main content

Last Call Review of draft-vinapamula-softwire-dslite-prefix-binding-07
review-vinapamula-softwire-dslite-prefix-binding-07-genart-lc-taylor-2015-07-15-00

Request Review of draft-vinapamula-softwire-dslite-prefix-binding
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-08-05
Requested 2015-07-09
Authors Suresh Vinapamula , Mohamed Boucadair
I-D last updated 2015-07-15
Completed reviews Genart Last Call review of -07 by Tom Taylor (diff)
Genart Last Call review of -09 by Tom Taylor (diff)
Secdir Last Call review of -07 by Dan Harkins (diff)
Assignment Reviewer Tom Taylor
State Completed
Request Last Call review on draft-vinapamula-softwire-dslite-prefix-binding by General Area Review Team (Gen-ART) Assigned
Reviewed revision 07 (document currently at 12)
Result Ready w/issues
Completed 2015-07-15
review-vinapamula-softwire-dslite-prefix-binding-07-genart-lc-taylor-2015-07-15-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: 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.




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/.






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?