A. Jean Mahoney | 2 May 00:40 2012

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>.
(Continue reading)

A. Jean Mahoney | 4 May 01:52 2012

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
(Continue reading)

Brian E Carpenter | 4 May 09:47 2012
Picon

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:

(Continue reading)

Alexey Melnikov | 5 May 19:58 2012

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

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)

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.

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.
_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Robert G Cole | 6 May 16:41 2012
Picon
Picon

Re: Fwd: [Gen-art] review: draft-ietf-manet-nhdp-mib-12

Joel,

Ulrich and I have updated the NHDP-MIB module to address your questions
and suggestions.  We hope these changes are satisfactory?

Thanks,

Bob and Ulrich

----- Original Message -----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
Sent: Sunday, May 06, 2012 02:29 PM
To: manet-chairs <at> tools.ietf.org <manet-chairs <at> tools.ietf.org>;
draft-ietf-manet-nhdp-mib <at> tools.ietf.org <draft-ietf-manet-nhdp-mib <at> tools.ietf.org>;
adrian <at> olddog.co.uk <adrian <at> olddog.co.uk>
Subject: New Version Notification - draft-ietf-manet-nhdp-mib-13.txt

New version (-13) has been submitted for
draft-ietf-manet-nhdp-mib-13.txt:
http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-13.txt

Sub state has been changed to AD Followup from Revised ID Needed

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/

Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-mib-13

IETF Secretariat.

On Mon, 2012-04-23 at 11:14 -0700, Ulrich Herberg wrote:

> Dear Joel,
> 
> thank you very much for your review. Find our answers below, and
> please tell us if they address your comments.
> 
> ---------- Forwarded message ----------
> From: Joel M. Halpern <jmh <at> joelhalpern.com>
> Date: Fri, Apr 6, 2012 at 8:59 AM
> Subject: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12
> To: gen-art <at> ietf.org
> Cc: manet <at> ietf.org, "A. Jean Mahoney" <mahoney <at> nostrum.com>,
> sratliff <at> cisco.com
> 
> 
> 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-manet-nhdp-mib-12
>    Definition of Managed Objects for the
>        Neighborhood Discovery Protocol
> Reviewer: Joel M. Halpern
> Review Date: 6-April-2012
> IETF LC End Date: 16-April-2012
> IESG Telechat date: (if known)
> 
> Summary: This document is almost ready for publication as a Proposed
> Standard.
> 
> <nhdp-mib-authors>
> That's good :-)
> </nhdp-mib-authors>
> 
> Major issues:
>    Section 5.1.3.1 on Ignoring Initial Activity is trying to do a very
> reasonable thing, namely suppress notifications for activity which is
> expected.  The text references RFC 4750 as precedent.  RFC 4750 is
> clear that the suppress window is tied to specific events (interface
> up and election as a DR.)  Section 5.1.3.1 does not specify which
> condition(s) start(s) the suppress window.  If, as seems likely, it is
> Interface Up which starts the window, please state that explicitly in
> the text.
> 
> 
> <nhdp-mib-authors>
> [To Bob: I am not so sure if the below is correct. Can you check?]
> Yes, we agree. How about adding the following sentence at the end of
> the paragraph of 5.1.3.1:
> "The suppression window for notifications is started by Interface Up."
> </nhdp-mib-authors>
> 
>    In section 5.4, in addition to describing objects which are defined
> in the MIB, the text describes, under the heading "The following
> objects return statistics related to HELLO messages:", a number of
> what it refers to as "Derived Objects".  These do not appear to be
> actual elements of the MIB.  They appear rather to be descriptions of
> calculations which the manager can perform using the information from
> the MIB.  It is not at all clear why they are here.  If I am
> understanding their role properly, and if they belong in this
> document, they belong in some other section, as they are NOT objects
> which return statistics related to HELLO messages.  They appear not to
> be returned by the managed device at all.
> 
> <nhdp-mib-authors>
> [To Bob: It is true that we actually don't use the derived objects. I
> am not quite sure what to do about it. Shall we remove the derived
> objects?
> </nhdp-mib-authors>
> 
> 
> Minor issues:
>    I can not find the object that corresponds to the setting for
> Ignoring the Initial Activity.  I presume this is my error.  The
> document would be helped if the object were named in section 5.1.3.1.
> 
> <nhdp-mib-authors>
> [To Bob: Do we have such object? I am not sure... does OSPF-MIB have
> one?]
> </nhdp-mib-authors>
> 
>    I believe section 5.1.3.2 on Throttling Traps is intended to refer
> to the StateChange Threshold and StateChangeWindow objects.  It would
> be very helpful if these were actually named in section 5.1.3.2.
> 
> <nhdp-mib-authors>
> How about adding the following sentence to 5.1.3.2:
> The following objects are used to define the thresholds and time
> windows: nhdpNbrStateChangeThreshold,
> nhdpNbrStateChangeWindow, nhdp2HopNbrStateChangeThreshold,
> nhdp2HopNbrStateChangeWindow,         nhdpIfRxBadPacketThreshold,
> nhdpIfRxBadPacketWindow.
> </nhdp-mib-authors>
> 
> 
>    Most MIBs I review have a description of the tables they contain,
> how the tables relate to each other, and how they are indexed, in the
> front matter that is roughly equivalent to section 5.2, 5.3, and 5.4.
> As I am not a MIB Doctor, I do not know if that is formally required,
> but I find it very helpful, and am surprised not to see it here.
> 
> <nhdp-mib-authors>
> [To Bob: I am not sure if we need this. I suggest to refer to the MIB
> Doctor review; if they request it, it should be easy to copy the text]
> </nhdp-mib-authors>
> 
>    In looking at the fields in the NhdpInterfaceEntry, some of the
> field definitions include some of the constraints from RFC 6130
> section 5 in their DESCRIPTION clauses.  Some do not.  (For exampple,
> REFRESH_INTERVAL >= HELLO_INTERVAL is captured in
> nhdbpRefreshInterval, but not in nhdpHelloInterval.  The requirement
> that nhdpHelloInterval be greater than 0 is not captured anywhere.
>  Neither is H_HOLD_TIME >= REFRESH_INTERVAL captured.)  Some elements
> have a statement that the object is persistent, while others do not,
> but these do not seem to correspond to a difference in RFC 6130.  It
> is possible that there is a good reason for this apparent variation.
>  Is there?
> 
> <nhdp-mib-authors>
> [To Bob: That's true. I can go through all constraints from NHDP and
> add them to the MIB.]
> </nhdp-mib-authors>
> 
>    Particularly for top-level objects such as nhdpNHoldTime and
> NhdpIHoldTime I would really like to see a better description than
> just this is <named> object from section 5 of RFC 6130.  Someone who
> is using the MIB, who is looking at the description clause for
> assistance, really needs something more than the name of the field in
> the MIB.  (I think better descriptions would be a good idea through
> much of the MIB.)
> 
> <nhdp-mib-authors>
> [To Bob: I can look at the descriptions and copy some more text from
> NHDP. However, I would like to avoid copying all NHDP into the MIB.]
> </nhdp-mib-authors>
> 
> Nits/editorial comments:
>    The tracker claims this is "In WG Last Call (manet), but also seems
> to indicate that it is in IETF Last Call.  Are the two happening at
> the same time?
> 
> <nhdp-mib-authors>
> We actually don't know, and will ask the chairs about that.
> </nhdp-mib-authors>
> 
> _______________________________________________
> manet mailing list
> manet <at> ietf.org
> https://www.ietf.org/mailman/listinfo/manet
> 
> 
> 
jouni korhonen | 6 May 21:58 2012
Picon

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
Alexey Melnikov | 7 May 11:41 2012

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.
Christer Holmberg | 7 May 12:25 2012
Picon

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

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-betts-itu-oam-ach-code-point-04

Reviewer: Christer Holmberg

Review Date: 7 May 2012

IETF LC End Date: 21 March 2012

IESG Telechat date: 10 May 2012

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.

 

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

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

Regards,

Christer

 

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Adrian Farrel | 7 May 15:49 2012
Picon

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
Christer Holmberg | 7 May 19:51 2012
Picon

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

Gmane