RE: Gen-ART LC review of draft-faltstrom-5892bis-04
Hi Paul, The IANA registry is in http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml#idnabis-ta bles-properties I saw that in the beginning it has as reference RFC 5892 for the whole table. Will it stay this way after the change proposed in this draft and just the three individual values will change based on 1.1, 1.2 and 1.3? or are there no changes in the IANA registry at all. This is unclear to me according to the section 3 of your draft. Section 5.1 of RFC5892 says If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. . My question was if the change is backward compatible. The 5892bis draft does not say it. Thanks Roni -Original Message- From: Paul Hoffman [mailto:paul.hoff...@vpnc.org] Sent: Tuesday, June 07, 2011 1:13 AM To: Roni Even Cc: draft-faltstrom-5892bis@tools.ietf.org; gen-...@ietf.org; 'IETF-Discussion list' Subject: Re: Gen-ART LC review of draft-faltstrom-5892bis-04 On May 29, 2011, at 4:13 AM, Roni Even wrote: Major issues: 1. I am not sure how the IANA consideration section is in-line with the IANA consideration section of RFC5892. Maybe some clarification text would be helpful. We think that the IANA considerations here are, in fact, what RFC 5892 was designed for. That is, RFC 5892 says that the registry will be updated (IANA has created a registry with the derived properties for the versions of Unicode released after (and including) version 5.2), and this is such an update. Please let me know if that doesn't match your understanding. 2. The IANA registry for derived property value has RFC 5892, does this draft want to change the reference, how will it be done. Section 2 of the draft is pretty clear here: No change to RFC 5892 is needed based on the changes made in Unicode 6.0. I think that it relates also to the issue of whether this draft updates RFC 5892. And here too. --Paul Hoffman __ Information from ESET NOD32 Antivirus, version of virus signature database 6185 (20110606) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6186 (20110607) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-faltstrom-5892bis-04
Hi Paul, My understanding that the new value does not replace the current one since 5892bis is not updating rfc5892. So should the IANA registry reflect that you are not replacing the current value or is my understanding wrong Roni Even -Original Message- From: Paul Hoffman [mailto:paul.hoff...@vpnc.org] Sent: Tuesday, June 07, 2011 7:39 PM To: rontlv Cc: draft-faltstrom-5892bis@tools.ietf.org; gen-...@ietf.org; 'IETF-Discussion list' Subject: Re: Gen-ART LC review of draft-faltstrom-5892bis-04 On Jun 7, 2011, at 3:56 AM, rontlv wrote: The IANA registry is in http://www.iana.org/assignments/idnabis-tables/idnabis- tables.xml#idnabis-ta bles-properties I saw that in the beginning it has as reference RFC 5892 for the whole table. Will it stay this way after the change proposed in this draft and just the three individual values will change based on 1.1, 1.2 and 1.3? or are there no changes in the IANA registry at all. This is unclear to me according to the section 3 of your draft. The table will likely change, based on the input of the expert reviewer. I assume that a reference to this RFC-to-be would be added to the top of the table, next to [RFC5892]. That is, this would be an additional reference, not a replacement. But that's up to IANA. Section 5.1 of RFC5892 says If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. . My question was if the change is backward compatible. The 5892bis draft does not say it. The draft says: This imply the derived property value differs depending on whether the property definitions used are from Unicode 5.2 or 6.0. We intended that as non-backwards-compatible; we can change the wording to make that explicit. --Paul Hoffman __ Information from ESET NOD32 Antivirus, version of virus signature database 6186 (20110607) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6188 (20110607) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-ietf-roll-routing-metrics-14
Hi JP, Thanks, I am OK with all your responses Roni From: JP Vasseur [mailto:j...@cisco.com] Sent: Friday, January 14, 2011 8:44 AM To: Roni Even Cc: gen-...@ietf.org; draft-ietf-roll-routing-metrics@tools.ietf.org; 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 Ietf@ietf.org 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
