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

[Marc Petit-Huguenin <[e-mail]>]

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

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-----