A new batch of IETF LC reviews - 2012-05-01

Hi all,

The following reviewers have assignments:

Reviewer               LC end       Draft

Allyn Romanow        2012-05-28     draft-polk-ipr-disclosure-03

Ben Campbell         2012-05-14     draft-ietf-ccamp-assoc-info-03

David Black          2012-05-10     draft-ietf-codec-opus-12

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

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

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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Assignments for the 2012-05-10 telechat

Hi all,

The following reviewers have assignments:

Reviewer:              LC end:      Draft:

Brian Carpenter        2011-11-03   
draft-sprecher-mpls-tp-oam-considerations-03

Christer Holmberg      2012-03-21   draft-betts-itu-oam-ach-code-point-04

Miguel Garcia          2012-04-06   
draft-ietf-roll-minrank-hysteresis-of-10

Roni Even              2012-05-02   draft-ietf-mboned-mcaddrdoc-03 *

Vijay Gurbani          2012-04-11   draft-ietf-ippm-reporting-metrics-08
Vijay Gurbani          2012-05-07   
draft-ietf-appsawg-mime-default-charset-03
Vijay Gurbani          2012-04-03   draft-ietf-avtext-rams-scenarios-04 *

Wassim Haddad          2012-03-23   draft-ietf-mpls-tp-oam-analysis-09
Wassim Haddad          2012-04-03   draft-ietf-avtext-splicing-for-rtp-07
Wassim Haddad          2012-03-23   draft-ietf-mpls-tp-oam-analysis-09

* Draft already reviewed

Spreadsheets have been updated:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

Gen-ART telechat review of draft-sprecher-mpls-tp-oam-considerations-03.txt

Please see attached review.

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: draft-sprecher-mpls-tp-oam-considerations-03.txt
Reviewer: Brian Carpenter
Review Date: 2012-05-04
IETF LC End Date: 2011-10-24
IESG Telechat date: 2012-05-10

Summary:  Ready
--------

Comments:
---------

My Last Call comments have been addressed, and the document now reads
more logically, due to material being moved to the appendices.

Nit:
----

There is duplicated text in section 1.2:

Gen-Art review of draft-ietf-netext-access-network-option-10.txt

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: Gen-Art review of draft-ietf-netext-access-network-option-10.txt

Alexey,

Thanks for the review. See some initial comments inline.

On May 5, 2012, at 8:58 PM, Alexey Melnikov 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>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-netext-access-network-option-10.txt
> Reviewer: Alexey Melnikov
> Review Date: 5 May 2012
> IETF LC End Date: 9 May 2012
> IESG Telechat date: Unknown
> 
> Summary: This draft is ready as a Proposed Standard
> 
> Major issues: none
> 
> Minor issues:
> 
> Minor: [ANI] and [TS23003] seem to be Normative (as per their use in 3.1.1)

If it is OK from the RFC process point of view, we can put these
non-IETF references into the normative section.

> 
> Nits/editorials:
> 
> 1.  Introduction
> 
>    This document defines a new mobility option, the Access Network
>    Identifier (ANI) option and its sub-options for Proxy Mobile IPv6,
>    that can be used by the mobile access gateway to signal the access
>    network information to the local mobility anchor.  The specific
>    details on how the local mobility anchor uses this information are
>    out-of-scope for this document.  These mobility options are optional
>    and are not mandatory for the Proxy Mobile IPv6 protocol.
> 
> Nit: Last sentence: "optional" and "not mandatory" are the same thing on my book.

Proposal for new text:

   "These mobility options are optional for the Proxy Mobile IPv6 protocol."

> 
> Strictly speaking PEN numbers are not limited to 4 bytes. However you have a registry for types of
identifiers, so a new value can be allocated for bigger-than-4-bytes PENs.

Right. So we could just remove the 4 octet length requirement and use a 
"natural" length indicated octet coding for the PENs. For example

ANI Length = 1 -> PENs 0-255
ANI Length = 2 -> PENs 0-65535
ANI Length = 3 -> PENs 0-16777216
...

That would be ok?

- Jouni

Re: Gen-Art review of draft-ietf-netext-access-network-option-10.txt

On 06/05/2012 20:58, jouni korhonen wrote:
> Alexey,
Hi Jouni,
> Thanks for the review. See some initial comments inline.
>
>
> On May 5, 2012, at 8:58 PM, Alexey Melnikov 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>.
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Document: draft-ietf-netext-access-network-option-10.txt
>> Reviewer: Alexey Melnikov
>> Review Date: 5 May 2012
>> IETF LC End Date: 9 May 2012
>> IESG Telechat date: Unknown
>>
>> Summary: This draft is ready as a Proposed Standard
>>
>> Major issues: none
>>
>> Minor issues:
>>
>> Minor: [ANI] and [TS23003] seem to be Normative (as per their use in 3.1.1)
> If it is OK from the RFC process point of view, we can put these
> non-IETF references into the normative section.
I think that is fine in general. You should double check with the 
responsible AD whether the references are stable (as otherwise they 
might not be suitable for referencing normatively).
>> Nits/editorials:
>>
>> 1.  Introduction
>>
>>     This document defines a new mobility option, the Access Network
>>     Identifier (ANI) option and its sub-options for Proxy Mobile IPv6,
>>     that can be used by the mobile access gateway to signal the access
>>     network information to the local mobility anchor.  The specific
>>     details on how the local mobility anchor uses this information are
>>     out-of-scope for this document.  These mobility options are optional
>>     and are not mandatory for the Proxy Mobile IPv6 protocol.
>>
>> Nit: Last sentence: "optional" and "not mandatory" are the same thing on my book.
> Proposal for new text:
>
>     "These mobility options are optional for the Proxy Mobile IPv6 protocol."
Perfect .
>> Strictly speaking PEN numbers are not limited to 4 bytes. However you have a registry for types of
identifiers, so a new value can be allocated for bigger-than-4-bytes PENs.
> Right. So we could just remove the 4 octet length requirement and use a
> "natural" length indicated octet coding for the PENs. For example
>
> ANI Length = 1 ->  PENs 0-255
> ANI Length = 2 ->  PENs 0-65535
> ANI Length = 3 ->  PENs 0-16777216
> ...
>
> That would be ok?
That would work, as long as the extra complexity (which is marginal in 
this case) is Ok with the WG.

Gen-ART review of draft-betts-itu-oam-ach-code-point-04

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: Gen-ART review of draft-betts-itu-oam-ach-code-point-04

All (copying the IESG),

I do sincerely welcome all reviews of all I-Ds that I sponsor or where I am the
responsible AD. I even mainly welcome them when I am an author.

However, when Directorate or Review Team reviews come in so long after the end
of IETF Last Call, and especially when they arrive after the I-D has been
updated to address last call comments, I do grind my teeth a bit.

Additionally, when Directorate or Review Team reviews are repeated and bring up
new issues (even minor ones) that were in the document at the time of the first
review but didn't warrant a comment at that time, I feel like I am being asked
for a rock.

Anyway, thanks Chris for caring enough to read the document for a second time,
and see in line for answers.

> Summary: The draft is ready for publication, with a couple of editorial nits.
>
> Major issues: -
>
> Minor issues: -
> 
> Nits/editorial comments:
>
> (The comments also applied to the -03 version, and I apologize for
> not bringing them up when I reviewed that version.)
>
> - General: G-ACh is mentioned throughout the document, but only in 
> section 4 is there a reference to RFC 5586. I suggest to add a reference
> on first occurrence at least to section 1. It would probably be good also
> in section 3.

Added RFC Editor note

Section1 para 2

s/Generic Associated Channel (G-ACh) Type/Generic Associated Channel (G-ACh)
Type [RFC5586]

> - Section 1: What is the purpose of the last paragraph, talking about IETF
>  Experts not agreeing? For someone who has not followed the work, it
>  seems as little strange.

I am not sure how to answer you without giving a long and detailed history of
this work covering the last four years. Such a history is without doubt
contentious.

You might read the referenced I-D for an alternate viewpoint. Or you might speak
privately with any number of people involved with this work.

In summary, this text is necessary to obtain consensus on the publication of
this document, and is agreed by the document author.

> - Section 3: The text says "The G-ACh Type assigned by this document". I guess
> it would be better to say e.g. "based on this document".

Well, of course, "based on" is also not right 

One might say, "...assigned by the IANA as a result of the request contained in
this document."
To me that is over-baked. What is more, during late-stage IANA processing, the
"request" text in I-Ds is replaced with "action" text that describes what action
IANA has taken.

Common usage is that a document that is approved for publication and that makes
an IANA request is the document that made the assignment or created the
registry.

So we won't make any change for that.

Cheers,
Adrian

Re: Gen-ART review of draft-betts-itu-oam-ach-code-point-04

Hi Adrian,

I will not go more into the comment regarding IETF Experts not agreeing. If the paragraph was needed in order
to move the work forward, I don't want to mess that up :)

I am happy if the 5586 reference is fixed, which you have requested the RFC editor to do.

Once again, I appologize for not giving these comments earlier.

Regards,

Christer

________________________________________
From: Adrian Farrel [adrian <at> olddog.co.uk]
Sent: Monday, May 07, 2012 4:49 PM
To: Christer Holmberg; gen-art <at> ietf.org
Cc: draft-betts-itu-oam-ach-code-point.all <at> tools.ietf.org; iesg <at> ietf.org
Subject: RE: Gen-ART review of draft-betts-itu-oam-ach-code-point-04

All (copying the IESG),

I do sincerely welcome all reviews of all I-Ds that I sponsor or where I am the
responsible AD. I even mainly welcome them when I am an author.

However, when Directorate or Review Team reviews come in so long after the end
of IETF Last Call, and especially when they arrive after the I-D has been
updated to address last call comments, I do grind my teeth a bit.

Additionally, when Directorate or Review Team reviews are repeated and bring up
new issues (even minor ones) that were in the document at the time of the first
review but didn't warrant a comment at that time, I feel like I am being asked
for a rock.

Anyway, thanks Chris for caring enough to read the document for a second time,
and see in line for answers.

> Summary: The draft is ready for publication, with a couple of editorial nits.
>
> Major issues: -
>
> Minor issues: -
>
> Nits/editorial comments:
>
> (The comments also applied to the -03 version, and I apologize for
> not bringing them up when I reviewed that version.)
>
> - General: G-ACh is mentioned throughout the document, but only in
> section 4 is there a reference to RFC 5586. I suggest to add a reference
> on first occurrence at least to section 1. It would probably be good also
> in section 3.

Added RFC Editor note

Section1 para 2

s/Generic Associated Channel (G-ACh) Type/Generic Associated Channel (G-ACh)
Type [RFC5586]

> - Section 1: What is the purpose of the last paragraph, talking about IETF
>  Experts not agreeing? For someone who has not followed the work, it
>  seems as little strange.

I am not sure how to answer you without giving a long and detailed history of
this work covering the last four years. Such a history is without doubt
contentious.

You might read the referenced I-D for an alternate viewpoint. Or you might speak
privately with any number of people involved with this work.

In summary, this text is necessary to obtain consensus on the publication of
this document, and is agreed by the document author.

> - Section 3: The text says "The G-ACh Type assigned by this document". I guess
> it would be better to say e.g. "based on this document".

Well, of course, "based on" is also not right 

One might say, "...assigned by the IANA as a result of the request contained in
this document."
To me that is over-baked. What is more, during late-stage IANA processing, the
"request" text in I-Ds is replaced with "action" text that describes what action
IANA has taken.

Common usage is that a document that is approved for publication and that makes
an IANA request is the document that made the assignment or created the
registry.

So we won't make any change for that.

Cheers,
Adrian

Gen-ART review of draft-ietf-roll-minrank-hysteresis-of-10.txt

I have been selected as the General Area Review Team (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 resolve these comments along with any other comments you may receive.

Document: draft-ietf-roll-minrank-hysteresis-of-10.txt
Reviewer: Miguel Garcia <Miguel.A.Garcia <at> ericsson.com>
Review Date: 2012-05-08
IESG Telechat date: 2012-05-10

Summary: The document is ready for publication as a standards track RFC

Major issues: none

Minor issues: none

Nits/editorial comments:

I reviewed version -07 of this document. At that time, I had a few 
editorial comments, and all of them but one have been addressed in 
version -10. The comment that has not been address is included here again 
for your consideration:

- Section 3.1. Towards the end of the section, the sentence reads:

    The path cost corresponding to a neighbor SHOULD be re-computed each
    time:

and then there are 3 conditions numbered from 1 to 3. It is not clear if 
the path cost should be recomputed when all of the 3 conditions are met, 
or when any of the 3 conditions are met. In other words, it is not clear 
if the 3 bullet points are an "AND" or an "OR" operation among then. 
Presumably they are an "OR". If this is the case, perhaps the sentence 
should be rephrased as:

    The path cost corresponding to a neighbor SHOULD be re-computed each
    time any of the following conditions are met:

/Miguel
--

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain