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

[Mary Barnes <[e-mail]>]

Certainly - but it's a pay now or a pay later unless you can convince
Henning that he doesn't need to do his usual careful review of a
document with his name.  This suggestion is based on my experience
with the XCON protocol document. The level of complexity and density
of this specification is significantly higher than the XCON document.
It will be a huge challenge for the RFC editor - I think even Alice
would find it so.  Having to deal with a potential large number of
edits at that stage has the potential to break or changes things that
were so carefully fixed.

Regards,
Mary.

On Wed, Feb 20, 2013 at 9:46 AM, Gonzalo Camarillo
<[e-mail]> wrote:
> -----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-----