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

From: Mary Barnes <[email-masked]>
Date: Tue, 19 Feb 2013 18:06:34 -0600

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"

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 19 Feb 2013 16:16:37 -0800

Thanks Mary.  I start working on this immediately.

On 02/19/2013 04:06 PM, Mary Barnes wrote:
> 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: --------
> 
> 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 
> 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 

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Brian Rosen <[email-masked]>
Date: Wed, 20 Feb 2013 09:20:40 -0500

I will contact Henning

Brian

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> -----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-----

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 20 Feb 2013 07:14:10 -0800

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

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

- -- 
Marc Petit-Huguenin

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 20 Feb 2013 17:46:50 +0200

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:
> 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
> 
>>>>> I am the assigned Gen-ART reviewer for this draft. For
>>>>> background on Gen-ART, please see the FAQ at 
>>>>> 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
>>>>> - [-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 10.1, 2nd paragraph, 5th sentence: "can be
>>>>> thought of a doubly-linked list" -> "can be thought of as a
>>>>> doubly-linked list"
>>>>>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 21 Feb 2013 06:49:51 -0600

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
<[email-masked]> wrote:
> Hash: SHA1
> 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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 21 Feb 2013 14:56:19 +0200

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

---

From: Dean Willis <[email-masked]>
Date: Thu, 21 Feb 2013 10:57:51 -0600

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.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 21 Feb 2013 20:36:03 +0000

On Feb 21, 2013, at 9:57 AM, Dean Willis <[email-masked]> wrote:

> I like Gonzalo's suggestion
> for dealing with it.

+1