Thanks Roni. On Jan 16, 2011, at 2:07 PM, rontlv wrote:
> Hi JP, > Thanks, I am OK with all your responses > Roni > > From: JP Vasseur [mailto:[email protected]] > Sent: Friday, January 14, 2011 8:44 AM > To: Roni Even > Cc: [email protected]; [email protected]; > IETF-Discussion list > Subject: Re: Gen-ART LC review of draft-ietf-roll-routing-metrics-14 > > 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 protected] > https://www.ietf.org/mailman/listinfo/ietf > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 5785 (20110113) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 5791 (20110116) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
