Re: [Gen-art] Gen-ART LC Review: draft-ietf-p2psip-base-24

[Brian Rosen <[e-mail]>]

I will contact Henning

Brian

On Feb 19, 2013, at 7:16 PM, Marc Petit-Huguenin <[e-mail]> wrote:

> -----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: [e-mail]
> 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-----