Peter, Thank you for the thorough review. We try to address these comments as soon as possible. - Jouni On Oct 2, 2014, at 4:22 AM, Peter Yee wrote: > 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-v6ops-ipv6-roaming-analysis-05 > Reviewer: Peter Yee > Review Date: September-30-2014 > IETF LC End Date: September-29-2014 > IESG Telechat date: TBD > > Apologies for the late review -- I've been on vacation and didn't quite get > everything keyed in before the deadline. I hope you still find the review > useful. > > Summary: This draft is ready with issues for publication as an Informational > RFC. [Ready with issues] > > This draft discusses some of the issues that may occur when a mobile device > roams on a visited network and attempts to use IPv6. The technical meat of > the draft is fine, but the language usage makes it difficult to read through > without extra effort and reflection. I'm not a 3GPP expert by any stretch > of the imagination, so I can't tell if the analysis made is sufficiently > comprehensive, but it appears to cover all of the IPv4/IPv6 combinations and > home/local breakout uses cases. > > Minor issues: > > General: > > There are a lot of definite (the) and indefinite articles (a/an) missing in > the draft. This makes it really difficult to read and interpret what is > meant. In some cases, the plural form would also make sense, so it's hard > to know how to interpret the sentence. I hate to say it, but please look > carefully at pretty much any acronym/initialism and the common nouns. Make > a determination if an article is appropriate. I started to mark these items > in the document while doing my review but became bogged down by the sheer > number of missing and in a few cases superfluous articles. I do understand > that English may not be a primary language for several of the authors and > appreciate your indulgence in trying to make the document more readable and > therefore more useful. > > > Nits: > > General: > > Ensure that the abbreviations i.e and e.g. are followed by a comma > consistently. > > Separate references from the preceding text with a space, again for > readability. > > I'll leave the Oxford/Harvard/serial comma alone for this review -- the > first general nit will take enough time to straighten out! > > Specific: > > Page 3, 4th bullet item, 2nd sentence: omit the commas. > > Page 4, Section 2.1.1, 2nd paragraph, 1st sentence: change "is" to "are". > > Page 6, 1st paragraph: replace the space after "breakout" with a hyphen. > > Page 6, 2nd bullet item: delete "a". > > Page 8, 1st partial paragraph, 3rd full sentence: append a comma after > "updated". Delete the "(" before "Section 6". > > Page 9, 1st bullet item, 2nd sentence: delete the 2nd appearance of "only". > > Page 9, 2nd bullet item, 3rd sentence: "lose" doesn't seem to be the right > word here. I would think that the subscriber simply would not be able to > obtain an IPv6 connection. > > Page 10, 1st partial paragraph: append "an error" after "not". > > Page 10, 1st paragraph after bullet items, 1st sentence: change "support" to > "supports". > > Page 10, Section 4.2, 2nd paragraph, 2nd sentence: I don't think the word > risky is what you mean. More like guaranteed, right? > > Page 10, Section 4.2, 2nd paragraph, 4th sentence: replace the space after > "roaming" with a hyphen. > > Page 11, Section 4.3, 2nd sentence: change "to support" to "of supporting". > Make the immediately following "type" plural. > > Page 11, Section 4.4, 2nd paragraph, 1st sentence: delete the first "the". > Replace the second "the" with "this". > > Page 11, Section 4.4, 2nd paragraph, last sentence: change "an" to "a". > > Page 11, Section 5.1, 1st paragraph, last sentence: insert "to" before > "failed". Change "failed" to "fail". And isn't the failure more than > likely, it is essentially guaranteed? > > Page 12, Section 5.2, 1st paragraph, 2nd sentence: append "used" after > "likely". > > Page 12, Section 5.2, 3rd paragraph, 1st sentence: change "to" to "on". > > Page 12, Section 5.2, 4th paragraph, 1st sentence: delete "the" before > "local". > > Page 13, 1st paragraph after Scenario 1, 1st sentence: replace "is" with > "are". > > Page 14, Section 7, 1st paragraph, 2nd sentence: change "testified" to > "illustrated". Change "issues" to "problems". Change "happened" to > "happen". > > Page 14, Section 7, 2nd paragraph, 1st sentence: change "stage of the > network attachment" to "network attachment stage". > > Page 14, Section 7, 2nd paragraph, 2nd sentence: change "early release" to > "earlier releases". > > Page 14, Section 7, 2nd paragraph, 3rd sentence: change "Such" to "That". > Change "didn't" to "isn't". Change "support" to "supported". > > Page 14, Section 7, 2nd paragraph, 4th sentence: I'm simply having troubles > parsing this sentence. Please rewrite for clarity. > > Page 14, Section 7, 2nd paragraph, 5th sentence: should "SSGN" really be > "SGSN"? If not, add a definition for "SSGN" in Section 1.1. > > Page 14, Section 7, 3rd paragraph, 1st sentence: change "stage of the > PDP/PDN creation" to "PDP/PDN creation stage". Change "type" to "types". > > Page 14, Section 7, 3rd paragraph, 3rd sentence: append "that" after > "desirable". > > Page 14, Section 7, 3rd paragraph, 4th sentence: append "support of" after > "For". Change "the DAF is suggested to be set" to "it is suggested to set > the DAF". > > Page 15, 1st full paragraph, 1st sentence: change "stage of service > requests" to "service requests stage". Delete "are". > > Page 15, 1st full paragraph, 3rd sentence: change "to use" to "using". > Append "mode" after "routed". Change "the" to "these". Change "risks" to > "problems". > > Page 15, 2nd bullet item, 2nd sentence: change "an" to "a" on the assumption > that "AAA" is typically pronounced "Triple A". Change "Radius" to > "RADIUS". > > Page 15, Section 9: change "it" to "the reader". > > >