Subject: [Gen-art] Last Call review of draft-vinapamula-softwire-dslite-prefix-binding-07

From: Tom Taylor <[email-masked]>
Date: Wed, 15 Jul 2015 10:58:34 -0400

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?

---

From: Terry Manderson <[email-masked]>
Date: Wed, 15 Jul 2015 15:23:35 +0000

Thank you for your detailed review Tom!

Cheers
T. 

Sent from my iPhone

> On 15 Jul 2015, at 07:59, Tom Taylor <[email-masked]> wrote:
> 
> 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:
> 
> 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. 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?

---

From: <[email-masked]>
Date: Thu, 16 Jul 2015 08:13:37 +0000

Hi Tom,

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Tom Taylor [mailto:[email-masked]]
> 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
> 

[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).
 
> redirect", or alternatively, s/to redirect/redirecting/.

[Med] Fixed. Thank you.

> of applying the space fixing program available on the Tools page?

[Med] The extra spaces is generated automatically by xml2rfc.