-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/20/2013 06:20 AM, Brian Rosen wrote: > I will contact Henning
I was in the process yesterday evening of doing a review according to the link Mary send when Roland's review arrived, which basically killed any chance of doing that. So either Henning send me today a list of things to fix, or I'll do the review later, but that probably be after the IESG telechat. > > Brian > > On Feb 19, 2013, at 7:16 PM, Marc Petit-Huguenin <[email protected]> > wrote: > > Thanks Mary. I start working on this immediately. > > On 02/19/2013 04:06 PM, Mary Barnes 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>. >>>> >>>> >>>> Document: draft-ietf-p2psip-base-24 Reviewer: Mary Barnes Review >>>> Date: 19 February 2013 Previous Review Date (-23): 14 December 2012 >>>> Original Review Date (-17): 6 August 2011 IETF LC End Date: 22 July >>>> 2011 IETF 2nd LC End Date: 19 February 2013 >>>> >>>> Summary: Almost Ready. This version is in significantly better shape >>>> than the previous versions. >>>> >>>> Comments: ========= I reviewed against my review of the -23 up >>>> through section 6. I reviewed beyond section 6 of this version >>>> (section 5 of -17, section 6 of -23) against my comments on the -17, >>>> since I had not re-reviewed those against the -23. >>>> >>>> >>>> General: -------- >>>> >>>> I still *strongly* recommend that you ensure Henning has reviewed >>>> this document *before* it gets into the RFC editor's queue. The last >>>> RFC I had published with Henning as a co-author had much more >>>> extensive changes suggested during AUTH 48 than I found acceptable. >>>> If all the co-authors have not reviewed and approved the draft before >>>> it goes into the RFC editor's queue, then the document should not go >>>> into the RFC editor's queue. He has fairly strict (and quite >>>> accurate) views on grammar and structure but it really isn't good to >>>> have so many changes go in at AUTH48 as there is a risk of >>>> introducing true technical bugs or changing something that was >>>> carefully crafted to achieve WG consensus: >>>> http://www.cs.columbia.edu/~hgs/etc/writing-bugs.html Note, that >>>> there some are cases of incorrect grammar that I have not identified >>>> because I think the RFC editor can fix, however, Henning may have >>>> different views on this. >>>> >>>> >>>> Major: ------ - [-17, section 10.5] Section 11.5, 3rd para: text >>>> uses the phrase "it can note the Node-ID in the response and use this >>>> Node-ID to start sending requests". It's not clear whether the use >>>> of the Node-ID is a MAY or a MUST. [Note: Marc's response to this >>>> was that it's an open issue, but this should be clarified prior to >>>> publication]. >>>> >>>> Minor: ------ - idnits identifies 5 errors (downrefs). I will note >>>> that in the PROTO write-up it was noted that those should likely be >>>> moved to Informative. >>>> >>>> - [-17] Section 1.2.1, 2nd paragraph: I don't understand the example >>>> as to why a single application requires multiple usages - i.e, why >>>> voicemail? Isn't the intent to say that an application might need to >>>> use both SIP and XMPP - i.e., you wouldn't define a "usage" for an >>>> application, would you? [While Cullen responded to this comment with >>>> an explanation, there was no change to clarify the text and Marc's >>>> response didn't help clarify my concern] >>>> >>>> - Section 3.3, 2nd paragraph after the capability bullet list, next >>>> to last sentence. There is at least an article missing from this >>>> sentence and it reads rather awkwardly. Perhaps changing to something >>>> like: OLD: If there is a failure on the reverse path caused by >>>> topology change since the request was sent, this will be handled by >>>> the end-to-end retransmission of the response as described in Section >>>> 6.2.1. NEW: Note that a failure on the reverse path caused by a >>>> topology change after the request was sent, will be handled by the >>>> end-to-end retransmission of the response as described in Section >>>> 6.2.1. >>>> >>>> - [-17] Section 3.3, last paragraph. Add a reference to 5.4.2.4 >>>> after "RouteQuery method" >>>> >>>> - Section 3.4, last paragraph, 3rd sentence: "that the specified by >>>> the algorithm" should be something like "than specified by the >>>> algorithm". >>>> >>>> - [-23] Section 6.6: All my previous concerns were addressed, >>>> except, the Note to implementors paragraph still seems out of context >>>> - it should be deleted or this section should be restructured so it >>>> is in context. >>>> >>>> - [-17, section 11] Section 12, Second paragraph, 3rd sentence says >>>> that "It gets routed to the admitting peer (AP), yet the flow shows >>>> that the message first gets routed to the PP and then onto AP. It >>>> would be helpful if that were clarified. [Note: Marc's response >>>> indicated that he thought this was fixed in the -23, however, the >>>> diff shows no changes to that specific text between the -17 and the >>>> -24 ] >>>> >>>> >>>> Nits: ----- >>>> >>>> - Section 1.2.5, 2nd para, last sentence: this sentence is a bit >>>> tough to interpret on a first read. I would suggest rewording >>>> something like the following: OLD: This layer is to the Message >>>> Transport Layer as link- level congestion control and retransmission >>>> in modern wireless networks is to Internet transport protocols. NEW: >>>> The relation of this layer to the Message Transport Layer "is similar >>>> to"|"can be likened to" the relation of the link- level congestion >>>> control and retransmission in modern wireless networks to Internet >>>> transport protocols. >>>> >>>> - Section 3.4, last paragraph, 4th sentence: "in accord" -> "in >>>> accordance" >>>> >>>> - Section 10.1, 2nd paragraph, 5th sentence: "can be thought of a >>>> doubly-linked list" -> "can be thought of as a doubly-linked list" >>>> >>>> - Section 15, last paragraph: "help resolve" -> "helped resolve" >>>> > > > - -- Marc Petit-Huguenin Email: [email protected] Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRJOg2AAoJECnERZXWan7EgygQAKZOFUs981xC3DO/0kNdqqxT JEdTbNsEmfPurt5HP4GyX1Xz1nXirbrItl4Cb5ss0r2CuBuCQHKZhT82yukNgaUE yVjVQSSuH+myWPTi+qxjpzrFIZRvYOZUQQrleMNeivVnCNEeIgxWcOq3UJVMrAEB 4dStv3fwA4a3yaRQT9EfPML23UUtnmXDNklwDx4Ih5AgDz8xQilxcl4IpSZwPXcm K4AUOmQJOL64KiWQCXEhXS6fen51azOlRgYRuUNoaz5K2GMSvhPFDLfmVdnjX4Vu QVK7PJgPjIi3bgSArQe99LbwuUpJWZOsihnFvjvP689FNdxOZ/7cu2lp9bmJmifR bJNmj/LDk+q4phlpYYkcPqSYLrAg1tbEbV3M6mJqCti3APF8ODXSfydsijdD1Lvx 8HRdUasaWfakQ3Jh3qADXJVfdRW7xM6CsrGusq/surgW/B3AlPAcwNkmsr4iZEAm ILTjHFkqWPmQDNs6UkPqVFnzH8LTAPsKmb7GHKJEKkVQfBe1BZ7MHFODkzFtp9wn drCg1cr+LUuiskPKhJqF7Jplb+kU+9wq1XlcNy3koSrljHF4TvDqrBOSIJnxqCyT cAU4iAL0rqw7BGtEutRHzJ8Tl4qgSebZeYO3RjCqAr3oACjtzUr8JFF2GEayWV/f 5nI2ugEK/+xxevxbyH0c =dbqe -----END PGP SIGNATURE----- _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
