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

[Gonzalo Camarillo <[e-mail]>]

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

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