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"