[Gen-art] Assignments for the 2013-02-28 telechat

[A. Jean Mahoney]

Hi all,

The following reviewers have assignments:

Reviewer LC end  Draft

Ben Campbell 2013-02-28  
draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04

Dan Romascanu2013-02-24  draft-cardenas-dff-09 **

Francis Dupont   2013-02-25  draft-ietf-dhc-secure-dhcpv6-07

Joel Halpern 2013-02-26  draft-ietf-tcpm-proportional-rate-reduction-04 
**

Kathleen Moriarty2013-02-27  draft-ietf-geopriv-flow-identity-01

Mary Barnes  2013-01-16  draft-ietf-6man-ipv6-atomic-fragments-03

Roni Even2013-02-28  draft-harkins-brainpool-ike-groups-04 **

Suresh Krishnan  2013-02-28  draft-eastlake-additional-xmlsec-uris-09


* Earlier draft reviewed
** Already reviewed



I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

For your convenience, the review boilerplate template is included below.

Note that reviews should ideally be posted to the gen-art mailing list
by COB on Tuesday:
http://wiki.tools.ietf.org/area/gen/trac/wiki/

Jean

---

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

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] A *new* batch of IETF LC reviews - 2013-02-21

[A. Jean Mahoney]

Hi all,

The following reviewers have assignments:

Reviewer  LC end   Draft
-
Alexey Melnikov   2013-03-07   draft-ietf-idr-deprecate-dpa-etal-00 **
 
Martin Thomson2013-03-19   draft-schaad-pkix-rfc2875-bis-07 *


Meral Shirazipour 2013-03-06   draft-ietf-appsawg-acct-uri-03

Peter McCann  2013-03-07   draft-ietf-tsvwg-byte-pkt-congest-09


* 2nd LC due to downrefs
** 2nd LC due to change from Informational to Proposed Standard



I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html


The standard template is included below.

Thanks,

Jean

---

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Cullen Jennings (fluffy)]

On Feb 21, 2013, at 9:57 AM, Dean Willis  wrote:

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

+1

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dean Willis]

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

Re: [Gen-art] Gen-art last call review of draft-ietf-idr-as-private-reservation-03

[Susan Hares]

Jon and Elwyn:

These drafts are working toward a larger goal - the eventual update of the
RFC 4271 with current practices.   Getting consensus on these items except
in very small pieces have been extremely difficult. 

Eventually, these will be all rolled up into larger documents that refer to
these smaller documents. 

The reason behind this is tactical. The smaller drafts allow people to stop
doing bad things to BGP immediately.  We have new implementation coming due
to the explosion in the Data center market.  Therefore, vague pieces in
RFC4271 must be plugged now. 

It seems that I really should get around to writing up the process on the
IDR web page and an internet draft. 

Thanks for your hard work, 

Sue 

-Original Message-
From: Jon Mitchell (GNS) [mailto:jon.mitch...@microsoft.com] 
Sent: Tuesday, February 19, 2013 3:27 PM
To: Elwyn Davies
Cc: General Area Review Team;
draft-ietf-idr-as-private-reservation@tools.ietf.org
Subject: RE: Gen-art last call review of
draft-ietf-idr-as-private-reservation-03


Elwyn -

Yes, I agree this is a reasonable change to remove all of the "suggestion"
text in the IANA considerations area and will make sure it is in the next
draft if one is required, either way all of that text will be removed by
IANA, who has also just sent back their review of the actions required.

On your second comment, currently being published as an RFC is a draft
reserving as0 in a similar fashion, so I do think it's most appropriate as a
second doc.. and I really have trouble tying these reservations to a RFC
about Private ASN's.   If no doc is published, the good news is that IANA
has already reserved the last number (with no justification).  Again, if
IESG or others feel strongly it should be in this draft, I will try to work
out some text to justify their reservations...

Thanks!

Jon

-Original Message-
From: Elwyn Davies [mailto:elw...@dial.pipex.com]
Sent: Monday, February 18, 2013 8:12 PM
To: Jon Mitchell (GNS)
Cc: General Area Review Team;
draft-ietf-idr-as-private-reservation@tools.ietf.org
Subject: RE: Gen-art last call review of
draft-ietf-idr-as-private-reservation-03

On Mon, 2013-02-18 at 15:26 +, Jon Mitchell (GNS) wrote:
> Elwyn -
> 
> Thanks for your review. 
:-)

>  The suggestion is being made to IANA who owns the assignment and was 
> discussed at length in the working group with rough consensus.
As specified in the registry, allocations in this registry are either by
IETF Concensus (i.e. a suitable RFC such as this draft is intended to
be) or request from a RIR. Thus it isn't a matter of suggesting to IANA but
telling them what the IETF want done - so this draft should be definitive -
and what you said about WG concensus constitutes the values to be used
unless somebody else in the IETF manages to alter the concensus which seems
unlikely.
  
> IANA will replace the suggested values into TBDX values below that 
> text if IESG approves.  This text will not be in the RFC, it's to be 
> stricken from the final document by RFC Editor (I was attempting to 
> write this text in alignment with Section 5.1 of RFC 5226) .
Yes, that's fine and as expected.
> 
> On the final ASN in the range, this is in accordance with like 
> reservation of the existing 2 byte Private ASN reservations, where the 
> final ASN in that space is not utilized either (except for well-known 
> community values).  Also, a case was made that code implementations 
> tend to have issues with final number usage if using incorrect 
> variable types for storage.  That said, the small discussion on and 
> off list about this resolved that if we wanted to formalize the 
> reservation of the last ASN of both the 2 byte space 65535 and the 4 
> byte space 4294967295, probably a separate draft should be constructed 
> detailing the logic behind these as they have nothing to do with 
> Private ASN's per se and have already been marked as Reserved by IANA 
> as you noted.  I'm open to IESG direction if we want to take a 
> different approach on this...
Publishing a separate draft seems a bit overkill but clearly that's not my
decision. ;-)

Regards,
Elwyn
> 
> Cheers,
> 
> Jon
> 
> -Original Message-
> From: Elwyn Davies [mailto:elw...@dial.pipex.com]
> Sent: Friday, February 15, 2013 4:15 AM
> To: General Area Review Team
> Cc: draft-ietf-idr-as-private-reservation@tools.ietf.org
> Subject: Gen-art last call review of
> draft-ietf-idr-as-private-reservation-03
> 
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at
> 
> .
> 
> Please resolve these comments along with any other Last Call comments you
may receive.
> 
> Document: draft-ietf-idr-as-private-reservation-03.txt
> Reviewer: Elwyn Davies
> Review Date: 15 February 2013
> IETF LC End Date: 22 February 2013
> IESG Telechat date: (if known) -
> 
> Summary: Ready for the IESG.
> 
> Nits/editorial comments:  The 

Re: [Gen-art] Gen-art last call review of draft-ietf-idr-as-private-reservation-03

[Susan Hares]

Elwyn and Jon:

This is an IETF consensus about the draft range.  As such, it should be put
in the draft as Jon indicated.  As a shepherd and a co-chair, my comment to
the IANA team is that perhaps they should consider handling out a portion of
the whole space. 

Once it is out, no one ever says "less" but someone always says "more".   I
will try to respond to the IANA or have a conversation about this draft with
them if possible.  I will note this in my status to Stewart Bryant (AD)
today. 

Sue 

-Original Message-
From: Elwyn Davies [mailto:elw...@dial.pipex.com] 
Sent: Monday, February 18, 2013 8:12 PM
To: Jon Mitchell (GNS)
Cc: General Area Review Team;
draft-ietf-idr-as-private-reservation@tools.ietf.org
Subject: RE: Gen-art last call review of
draft-ietf-idr-as-private-reservation-03

On Mon, 2013-02-18 at 15:26 +, Jon Mitchell (GNS) wrote:
> Elwyn -
> 
> Thanks for your review. 
:-)

>  The suggestion is being made to IANA who owns the assignment and was 
> discussed at length in the working group with rough consensus.
As specified in the registry, allocations in this registry are either by
IETF Concensus (i.e. a suitable RFC such as this draft is intended to
be) or request from a RIR. Thus it isn't a matter of suggesting to IANA but
telling them what the IETF want done - so this draft should be definitive -
and what you said about WG concensus constitutes the values to be used
unless somebody else in the IETF manages to alter the concensus which seems
unlikely.
  
> IANA will replace the suggested values into TBDX values below that 
> text if IESG approves.  This text will not be in the RFC, it's to be 
> stricken from the final document by RFC Editor (I was attempting to 
> write this text in alignment with Section 5.1 of RFC 5226) .
Yes, that's fine and as expected.
> 
> On the final ASN in the range, this is in accordance with like 
> reservation of the existing 2 byte Private ASN reservations, where the 
> final ASN in that space is not utilized either (except for well-known 
> community values).  Also, a case was made that code implementations 
> tend to have issues with final number usage if using incorrect 
> variable types for storage.  That said, the small discussion on and 
> off list about this resolved that if we wanted to formalize the 
> reservation of the last ASN of both the 2 byte space 65535 and the 4 
> byte space 4294967295, probably a separate draft should be constructed 
> detailing the logic behind these as they have nothing to do with 
> Private ASN's per se and have already been marked as Reserved by IANA 
> as you noted.  I'm open to IESG direction if we want to take a 
> different approach on this...
Publishing a separate draft seems a bit overkill but clearly that's not my
decision. ;-)

Regards,
Elwyn
> 
> Cheers,
> 
> Jon
> 
> -Original Message-
> From: Elwyn Davies [mailto:elw...@dial.pipex.com]
> Sent: Friday, February 15, 2013 4:15 AM
> To: General Area Review Team
> Cc: draft-ietf-idr-as-private-reservation@tools.ietf.org
> Subject: Gen-art last call review of 
> draft-ietf-idr-as-private-reservation-03
> 
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at
> 
> .
> 
> Please resolve these comments along with any other Last Call comments you
may receive.
> 
> Document: draft-ietf-idr-as-private-reservation-03.txt
> Reviewer: Elwyn Davies
> Review Date: 15 February 2013
> IETF LC End Date: 22 February 2013
> IESG Telechat date: (if known) -
> 
> Summary: Ready for the IESG.
> 
> Nits/editorial comments:  The draft is not actually definitive about range
of values to be allocated - the range in s10 is just a 'suggestion'.  Who is
actually making the decision about the range?
> 
> Aside: I noted that the highest possible 32 bit number (4294967295 =
> 0x) is excluded from the proposed range.  This is marked as 
> reserved in the IANA table but AFAICS this reserved item does not have 
> a specification associated with the reservation.  This document would 
> be an opportunity to explicitly mention that the topmost value is 
> reserved (for future expansion? :-) )
> 
> 


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-art last call review of draft-ietf-idr-as-private-reservation-03

[Susan Hares]

Jon and Elwyn:

I would like to make a correction here. The WG as a body of experts
suggested to the author via the Author to IANA.  Perhaps as a body of
experts, this WG is sufficient to begin this range.  Second, the suggestion
from the chairs is that IANA might want to allocate a portion of this total
range for initial usage. 

Finally, the Private Address space in the IPV4 space and this IPv6 range are
logically connected, but the numbers are not connected.

Please let me know if this challenges any of your review. 

Sue Hares
(Shepherd and co-chair) 

-Original Message-
From: Jon Mitchell (GNS) [mailto:jon.mitch...@microsoft.com] 
Sent: Monday, February 18, 2013 10:26 AM
To: Elwyn Davies; General Area Review Team
Cc: draft-ietf-idr-as-private-reservation@tools.ietf.org
Subject: RE: Gen-art last call review of
draft-ietf-idr-as-private-reservation-03


Elwyn -

Thanks for your review.  The suggestion is being made to IANA who owns the
assignment and was discussed at length in the working group with rough
consensus.  IANA will replace the suggested values into TBDX values below
that text if IESG approves.  This text will not be in the RFC, it's to be
stricken from the final document by RFC Editor (I was attempting to write
this text in alignment with Section 5.1 of RFC 5226) .

On the final ASN in the range, this is in accordance with like reservation
of the existing 2 byte Private ASN reservations, where the final ASN in that
space is not utilized either (except for well-known community values).
Also, a case was made that code implementations tend to have issues with
final number usage if using incorrect variable types for storage.  That
said, the small discussion on and off list about this resolved that if we
wanted to formalize the reservation of the last ASN of both the 2 byte space
65535 and the 4 byte space 4294967295, probably a separate draft should be
constructed detailing the logic behind these as they have nothing to do with
Private ASN's per se and have already been marked as Reserved by IANA as you
noted.  I'm open to IESG direction if we want to take a different approach
on this...

Cheers,

Jon

-Original Message-
From: Elwyn Davies [mailto:elw...@dial.pipex.com] 
Sent: Friday, February 15, 2013 4:15 AM
To: General Area Review Team
Cc: draft-ietf-idr-as-private-reservation@tools.ietf.org
Subject: Gen-art last call review of
draft-ietf-idr-as-private-reservation-03

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-idr-as-private-reservation-03.txt
Reviewer: Elwyn Davies
Review Date: 15 February 2013
IETF LC End Date: 22 February 2013
IESG Telechat date: (if known) -

Summary: Ready for the IESG.

Nits/editorial comments:  The draft is not actually definitive about range
of values to be allocated - the range in s10 is just a 'suggestion'.  Who is
actually making the decision about the range?

Aside: I noted that the highest possible 32 bit number (4294967295 =
0x) is excluded from the proposed range.  This is marked as reserved
in the IANA table but AFAICS this reserved item does not have a
specification associated with the reservation.  This document would be an
opportunity to explicitly mention that the topmost value is reserved (for
future expansion? :-) )



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Gonzalo Camarillo]

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


 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
>

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

[Mary Barnes]

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