Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-roll-routing-metrics-14

From: JP Vasseur <[email-masked]>
Date: Fri, 14 Jan 2011 07:43:44 +0100

Hi Roni,

Thanks for your thorough review - please see in line JP>

On Dec 20, 2010, at 7:14 PM, Roni Even 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-roll-routing-metrics-14
> Reviewer: Roni Even
> Review Date:2010–12–20
> IETF LC End Date: 2011–1–5
> IESG Telechat date:
>  
> Summary: This draft is almost ready for publication as an Standard track RFC.
>  
> Major issues:
> No Major issues
>  
> Minor issues:
>  
> 1.  In section 2.1 after figure 1 you specify the different fields. Please specify the size in bits of the flags field the A-field and the prec field.

JP> Done.

> 2.  In section 2.1 in example 1 how is it known that all nodes MUST be main powered.

JP> In this example, we first explain how the headers flags are determined. To help clarify I modified the text:

OLD:

As far as the constraint is concerned, if the constraint signalled in the DIO message is not satisfied, the advertising node is just not selected as a parent by the node that processes the DIO message.

NEW:

As far as the constraint is concerned, the object body will carry a node energy constraint object defined in Section 3.1 indicating that nodes must be mains-powered: if the constraint signalled in the DIO message is not satisfied, the advertising node is just not selected as a parent by the node that processes the DIO message.

> Do you need to provide a value to prec field?

JP> As indicated earlier, the Prec field is only useful when a DAG Metric Container contains several Routing Metric objects. In this example, there is just one metric (the node energy is a constraint).

> 3.  In section 3.1 and throughout the document when you define the different object you have “recommended value=xx”. I think that since this draft defines the table and create the initial table in the IANA consideration section these are the actual values. So maybe say that these are the actual values as specified in section 6 (6.1)

JP> We added "recommended values" until IANA confirms.

> 4.  In section 3.1 the flag field – how many bits, specify.

JP> Done.

> 5.  In section 3.2 figure 4 shows a flag field, how many bits, what is the value.

JP> Done.

> 6.  In section 6 according to rfc5226 “IETF consensus” is now “IETF review”.

JP> Fixed.

> 7.  In section 6.1 you should say that the table has the initial values and add which numbers are available for allocation.

JP> Done.

> 8.  In section 6.2 what values are available for allocation.  Also say that currently the table is empty.

JP> Done.

> 9.  In section 6.2 is there a reason to create an empty table. Why not do it when there is a request to define a TLV

JP> Just to have the registry already in place. There is more than likely be TLVs defined in a very near future. This also allows to make sure that all TLVs have the same structure.

> 10.In section 6.3, are there more values allowed, can they be allocated. If not why have it managed by IANA.

JP> The A field is a 3-bit field and there are currently 4 defined values.

> 11.After the table in section in section 6.3 there is a request to create another table. Maybe it should be in a separate section.

JP> This is just because we put all registries belonging to the Routing Metric/Constraint Common Header in the same section.

> 12.In section 6.3 “New bit numbers may be allocated”, how many bits are available.

JP> The text was misplaced, thanks.

> 13.The same paragraph in section 6.3 also talks about the registration policy, is it different from the one that is common in section 6, why specify it again. Also look at comment 6

JP> This was a duplicate. Fixed.

> 14.Comment 12 and 13 are also true for section 6.4 and 6.5.
>  

JP> Fixed too.

>  
>  
> Nits/editorial comments:
>  
> 1.  In section first paragraph “object” should be “object”
> 2.  In section 4.3.2 first paragraph “wich” should be “which”
>  

JP> Fixed.

Many Thanks. These changes are all incorporated in revision 15.

JP.

>  
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "rontlv" <[email-masked]>
Date: Sun, 16 Jan 2011 15:07:59 +0200

Hi JP,

Thanks, I am OK with all your responses

Roni

From: JP Vasseur [mailto:[email-masked]] 
Sent: Friday, January 14, 2011 8:44 AM
To: Roni Even
Cc: [email-masked]; [email-masked];
IETF-Discussion list
Subject: Re: Gen-ART LC review of draft-ietf-roll-routing-metrics-14

Hi Roni,

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.

Reviewer: Roni Even

Review Date:2010-12-20

IETF LC End Date: 2011-1-5

IESG Telechat date:

Summary: This draft is almost ready for publication as an Standard track
RFC.

Major issues:

No Major issues

Minor issues:

1.  In section 2.1 after figure 1 you specify the different fields. Please
specify the size in bits of the flags field the A-field and the prec field.

JP> Done.

2.  In section 2.1 in example 1 how is it known that all nodes MUST be main
powered. 

JP> In this example, we first explain how the headers flags are determined.
To help clarify I modified the text:

OLD:

As far as the constraint is concerned, if the constraint signalled in the
DIO message is not satisfied, the advertising node is just not selected as a
parent by the node that processes the DIO message.

NEW:

As far as the constraint is concerned, the object body will carry a node
energy constraint object defined in Section 3.1 indicating that nodes must
be mains-powered: if the constraint signalled in the DIO message is not
satisfied, the advertising node is just not selected as a parent by the node
that processes the DIO message.

JP> As indicated earlier, the Prec field is only useful when a DAG Metric
Container contains several Routing Metric objects. In this example, there is
just one metric (the node energy is a constraint).

3.  In section 3.1 and throughout the document when you define the different
object you have "recommended value=xx". I think that since this draft
defines the table and create the initial table in the IANA consideration
section these are the actual values. So maybe say that these are the actual
values as specified in section 6 (6.1)

4.  In section 3.1 the flag field - how many bits, specify.

JP> Done.

5.  In section 3.2 figure 4 shows a flag field, how many bits, what is the
value.

JP> Done.

6.  In section 6 according to rfc5226 "IETF consensus" is now "IETF review".

JP> Fixed.

7.  In section 6.1 you should say that the table has the initial values and
add which numbers are available for allocation.

JP> Done.

8.  In section 6.2 what values are available for allocation.  Also say that
currently the table is empty.

JP> Done.

9.  In section 6.2 is there a reason to create an empty table. Why not do it
when there is a request to define a TLV

JP> Just to have the registry already in place. There is more than likely be
TLVs defined in a very near future. This also allows to make sure that all
TLVs have the same structure.

10.In section 6.3, are there more values allowed, can they be allocated. If
not why have it managed by IANA.

11.After the table in section in section 6.3 there is a request to create
another table. Maybe it should be in a separate section.

JP> This is just because we put all registries belonging to the Routing
Metric/Constraint Common Header in the same section.

12.In section 6.3 "New bit numbers may be allocated", how many bits are
available.

13.The same paragraph in section 6.3 also talks about the registration
policy, is it different from the one that is common in section 6, why
specify it again. Also look at comment 6

 

JP> Fixed too.

Nits/editorial comments:

1.  In section first paragraph "object" should be "object"

2.  In section 4.3.2 first paragraph "wich" should be "which"

JP> Fixed.

JP.

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 5785 (20110113) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

From: JP Vasseur <[email-masked]>
Date: Sun, 16 Jan 2011 17:07:37 +0100

Thanks Roni.

On Jan 16, 2011, at 2:07 PM, rontlv wrote:

> Cc: [email-masked]; [email-masked]; IETF-Discussion list
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5785 (20110113) __________
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5791 (20110116) __________
>