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
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
