As document shepherd, I agree. A small addon: I think that the suggested text for -10 sent around as response to Barry Leiba's review would be OK.
I have just compared it to the GenArt review. At first sight, the following nit is not addressed: [Page 7], 'Fast Open Cookie Option', it would be more familiar to IETF community to call "Kind" field "Type", unless there was a reason for this differentiation However, not changing the text in this case seems fine to me, given that the term "kind" is used on http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml. In addition, some acronyms may indeed not be expanded on first use, but I think the RFC editor will fix this anyway. Michael > -----Original Message----- > From: Martin Stiemerling [mailto:[email protected]] > Sent: Wednesday, August 20, 2014 7:14 PM > To: Jari Arkko; Yuchung Cheng > Cc: [email protected]; [email protected]; draft-ietf-tcpm- > [email protected] > Subject: Re: [Gen-art] Gen-ART Last Call review draft-ietf-tcpm- > fastopen-09 > > I would suggest to wait with any updated version until Friday, 8/22. > Many IESG members are still reading the -09 version and it is usually > confusing, if there is an updated draft in the meantime. > > Thanks, > > Martin > > Am 20.08.14 um 13:12 schrieb Jari Arkko: > > Thanks for the review & suggested edits. Is there a new draft version > forthcoming? > > > > Jari > > > > On 29 Jul 2014, at 20:22, Yuchung Cheng <[email protected]> wrote: > > > >> > >> > >> > >> On Wed, Jul 23, 2014 at 9:06 AM, Meral Shirazipour > <[email protected]> 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-tcpm-fastopen-09 > >>> > >>> Reviewer: Meral Shirazipour > >>> > >>> Review Date: 2014-07-23 > >>> > >>> IETF LC End Date: 2014-07-23 > >>> > >>> IESG Telechat date: NA > >>> > >>> > >>> > >>> > >>> > >>> Summary: > >>> > >>> This draft is ready to be published as Experimental RFC, but I have > some comments. > >>> > >>> > >>> > >>> Nits/editorial comments: > >>> > >>> -Abstract says "thus saving up to one full round trip time (RTT)": > by just reading the abstract one would think 1.5 RTT since initial 3WHS > is avoided. > >>> > >>> Reading the rest of the draft clarifies this though. Suggestion : > >>> > >>> > >>> > >>> " > >>> > >>> TFO allows data to be carried in the SYN and SYN-ACK packets > >>> > >>> and consumed by the receiving end during 'an' initial > connection > >>> > >>> handshake, 'and' saves up to one full round trip time (RTT) > compared > >>> > >>> to the standard TCP, ...... > >>> > >>> " > >> > >> Sounds good except it's "the" initial connection. > >> > >>> > >>> > >>> > >>> -[page 4] "MSL", to spell out at first use "maximum segment > lifetime" (or please consider mentioning reference to key TCP RFCs in > Terminology section). > >> ok > >>> > >>> > >>> > >>> -General: Also few other acronyms used without spelling out at > first use, please consider those as well. > >>> > >>> > >>> > >>> -[Page 7], 'Fast Open Cookie Option', it would be more familiar to > IETF community to call "Kind" field "Type", unless there was a reason > for this differentiation. > >> > >> OK > >> > >>> > >>> -[Page 10] please remove extra space (page break) if not needed. > >>> > >>> > >>> > >>> -[Page 12], typo "connection-sharding"--->"connection-sharing" > >>> > >>> > >>> > >>> -[page 14] "as a application"--->"as an application" > >>> > >>> > >>> > >>> -[Page 17], typo "Neverthless"--->"Nevertheless" > >>> > >>> > >>> > >>> -[Page 18], typo "meet the the"---->"meet the" > >>> > >>> > >>> > >>> -[Page 21], typo "in Section Section 4.1.1"---->"in Section 4.1.1" > >>> > >>> > >>> > >>> -[Page 21] please remove extra space (page break) if not needed. > >>> > >>> > >> OK except it is the connection-sharding, not connection sharing. The > two are opposite. To avoid confusion, I would rephrase to "If > experiments with TFO find that it encourages applications to use more > parallel connections, cookie-in-FIN may prove to be a useful > alternative"? > >> > >> I'd upload a new version soon. Thanks for the review. > >> > >>> > >>> Best Regards, > >>> > >>> Meral > >>> > >>> > >>> > >>> > >>> > >>> --- > >>> > >>> Meral Shirazipour > >>> > >>> Ericsson > >>> > >>> Research > >>> > >>> www.ericsson.com > >> _______________________________________________ > >> Gen-art mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
