-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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: m...@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRJBXhAAoJECnERZXWan7EArsP/1Jwo7XD8sRHgFFNyw6hCLZB c7ovMWrpJgM+EENmFq9pkTIQLLE/E3BAGzCsXZ3xoSPkemhUmxWFkGheuWQowzeP ShoE8OcB6C/RIgqpkNuZfCnmvhBv5he1nsDj8RJ3e7YDkjpBixLK+x0EFncJVaWs PF77UIEOaddq4R5WYtfovxOeRYS8z00JQfM8JBOHdSHKkNr1IvlJMVKgmtO3gQHH 1JS+O44pljkXrB8okLoEhDPjYaDMM08PE2HIbOyu6aaFPgBe7E1cNeniyoG0w0Sf hMkpJiAxLoLuEWMfkpWrHXNGK76EDDnCbGK5Xpi9EpsPHHCjVgZxB6AfuunRB+we RA2PPqTV1Fa9ZkSSO+wbm3n2dUALp1bOq4LGgL3vjsWg+ePiTIynHaemHFTgOEMU xnQdA3At/Du+GkRqatuKn7dTegNw+tvXS2WAytscHvJ2X4pj8yOl6c/NNtDeEduN jfB8RclXB5srMALfmHFr6I8CsfGRpuRTES1DkaNaiWJRhqI7G8QYhJitpJwwneKd PQI2pnNYBpY+4sVjl6xJb9ynBlmaDOTdnfhmWj2QeRxnqZQxGTdnoBOHolfKYIV6 R8BjiEoJKPSLwuxpWBxDvIJUoxMPNkndSAbkpqawsMQvIptmlG5R4vL92ljTthhH OTgyQ3TUjCf9D/4FO5AQ =UxzS -----END PGP SIGNATURE----- _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
