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

[Dean Willis <[e-mail]>]

Mary's very right about the need to get Henning's further review
processed ahead of the RFC-Ed work, and I like Gonzalo's suggestion
for dealing with it.

On Thu, Feb 21, 2013 at 6:56 AM, Gonzalo Camarillo
<[e-mail]> wrote:
> Hi Mary,
>
> yes, as you know, I know Henning very well. I will talk with him about
> this. A potential outcome is that we get this document in the Approved
> Point Raised state and then we get him to review it. In any case, thanks
> for the advice!
>
> Cheers,
>
> Gonzalo
>
> On 21/02/2013 2:49 PM, Mary Barnes wrote:
>> 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:
>> 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"
>>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>