-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
there is no way Henning is going to review this document in the next 24 hours. So, do whatever you need to do and I will talk with Henning later. Thanks, Gonzalo On 20/02/2013 5:14 PM, Marc Petit-Huguenin wrote: > 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" >>>>> > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRJO/pAAoJENEzUJhwP4c2+5IIAMGKYdj0TF71N03TyOe406EJ A0WZKPEQwFHIJcly0weIHTorjjd48ukC369W1/VokffSuV4tFdRgYGFVZMiGRSE5 Jl6f9DCZJclCp26c5hSgb54IpiIIaps8Yk3Jy3J+wW81l+l3jUClM4pJNJyh6oxi jNNjJX67ATsqsN3D0Il7/6a0K90d0zUHL9tqIbHFIz5ls7UISQem4jsL2SJPJr6B 8I1R/TSXgf00huLx8EhEV44hPhMkSc7DNtEutY1a7jQ2D6Q+55mXABveY05GmI4y 1eq2u8WZzoBvA1mWOcvpa4ICwYr4pYG8bCD0EiHqSyXEE7icirjH8OyUDx3uza0= =9jzo -----END PGP SIGNATURE----- _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
