Re: Gen-ART LC Review of draft-ietf-ospf-ospfv3-iid-registry-update-00
Alvaro Please can you add a line or two of motivation to the draft. I don't think it needs to be major text, but it will be useful to record the reason for the update to the registry. Thanks Stewart On 06/03/2013 15:05, Acee Lindem wrote: I think the draft can talk to the motivation in general terms with the embedded routing draft cited as an example. Thanks, Acee On 3/6/13 7:01 AM, Stewart Bryant stbry...@cisco.com wrote: Chairs Please can you re on the question posed by Alvaro below. Do you have any objection to adding motivation text to the draft? Certainly I think it would be useful in IESG review. Stewart On 11/02/2013 21:15, Alvaro Retana (aretana) wrote: On 1/16/13 5:17 PM, Ben Campbell b...@nostrum.com wrote: Ben: Hi! Sorry for the delay, my filters put this in a different place.. I'm explicitly adding the OSPF chairs. Comments below. 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-ospf-ospfv3-iid-registry-update-00 Reviewer: Ben Campbell Review Date: 2013-01-16 IETF LC End Date: 2013-01-24 Summary: This draft is not ready for publication as a proposed standard. There is a significant IANA registration issue described in the review body. Major issues: This draft carves out a significant part of a registry with an assignment policy of standards action for private use. It offers very little motivation for the change. In my opinion, this sort of change should come with a clear justification. Specifically, the draft modifies the OSPFv3 Address Family Instance ID registry to carve out half of the unassigned space for private use. The justification for this is a single sentence saying that some networks need to use IIDs to identify specific applications. I think that needs significant elaboration in order to motivate the change in a way that the reader can evaluate. My understanding from the OFPS list is that this is in support of draft-ietf-ospf-ipv4-embedded-ipv6-routing, which is an informational draft. I have to wonder why the draft under review was not simply the IANA considerations for that draft. I suggest one of two paths forward: 1) If this change is in support of that draft in particular, then this draft should say that, and include a _normative_ reference. I recognize the normative downref would complicate things--but I think that complication is reasonable under the circumstances. 2) If this change is to support a general need that goes beyond draft-ietf-ospf-ipv4-embedded-ipv6-routing, then this draft should describe that need in enough detail for people to think about it, perhaps with an informative reference to draft-ietf-ospf-ipv4-embedded-ipv6-routing as an _example_. In short (from the shepherd write-up): The new range is for applications that do not justify a standards track OSPFv3 Instance ID allocation. An example would be Routing for IPv4-embedded IPv6 Packets. During pre-publication review, the WG chairs asked us to not include explicit references to draft-ietf-ospf-ipv4-embedded-ipv6-routing as that is just an example and not the only potential user/driver. I don't have a problem adding an example, but I want to get agreement/comments/guidance from the chairs before adding the text. Acee/Abhay?? Minor issues: -- section 3: I don't think it's appropriate to use normative language for IANA requests. Especially not MUST. (I think the strongest thing we can do here is a polite request :-) ) I suggest recasting that to descriptive language, and removing section 2 and the RFC 2119 reference. Yes, we already removed that in the -01 version. Thanks!! Alvaro. . -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html . -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: Gen-ART LC Review of draft-ietf-ospf-ospfv3-iid-registry-update-00
I think the draft can talk to the motivation in general terms with the embedded routing draft cited as an example. Thanks, Acee On 3/6/13 7:01 AM, Stewart Bryant stbry...@cisco.com wrote: Chairs Please can you re on the question posed by Alvaro below. Do you have any objection to adding motivation text to the draft? Certainly I think it would be useful in IESG review. Stewart On 11/02/2013 21:15, Alvaro Retana (aretana) wrote: On 1/16/13 5:17 PM, Ben Campbell b...@nostrum.com wrote: Ben: Hi! Sorry for the delay, my filters put this in a different place.. I'm explicitly adding the OSPF chairs. Comments below. 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-ospf-ospfv3-iid-registry-update-00 Reviewer: Ben Campbell Review Date: 2013-01-16 IETF LC End Date: 2013-01-24 Summary: This draft is not ready for publication as a proposed standard. There is a significant IANA registration issue described in the review body. Major issues: This draft carves out a significant part of a registry with an assignment policy of standards action for private use. It offers very little motivation for the change. In my opinion, this sort of change should come with a clear justification. Specifically, the draft modifies the OSPFv3 Address Family Instance ID registry to carve out half of the unassigned space for private use. The justification for this is a single sentence saying that some networks need to use IIDs to identify specific applications. I think that needs significant elaboration in order to motivate the change in a way that the reader can evaluate. My understanding from the OFPS list is that this is in support of draft-ietf-ospf-ipv4-embedded-ipv6-routing, which is an informational draft. I have to wonder why the draft under review was not simply the IANA considerations for that draft. I suggest one of two paths forward: 1) If this change is in support of that draft in particular, then this draft should say that, and include a _normative_ reference. I recognize the normative downref would complicate things--but I think that complication is reasonable under the circumstances. 2) If this change is to support a general need that goes beyond draft-ietf-ospf-ipv4-embedded-ipv6-routing, then this draft should describe that need in enough detail for people to think about it, perhaps with an informative reference to draft-ietf-ospf-ipv4-embedded-ipv6-routing as an _example_. In short (from the shepherd write-up): The new range is for applications that do not justify a standards track OSPFv3 Instance ID allocation. An example would be Routing for IPv4-embedded IPv6 Packets. During pre-publication review, the WG chairs asked us to not include explicit references to draft-ietf-ospf-ipv4-embedded-ipv6-routing as that is just an example and not the only potential user/driver. I don't have a problem adding an example, but I want to get agreement/comments/guidance from the chairs before adding the text. Acee/Abhay?? Minor issues: -- section 3: I don't think it's appropriate to use normative language for IANA requests. Especially not MUST. (I think the strongest thing we can do here is a polite request :-) ) I suggest recasting that to descriptive language, and removing section 2 and the RFC 2119 reference. Yes, we already removed that in the -01 version. Thanks!! Alvaro. . -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: Gen-ART LC Review of draft-ietf-ospf-ospfv3-iid-registry-update-00
Chairs Please can you re on the question posed by Alvaro below. Do you have any objection to adding motivation text to the draft? Certainly I think it would be useful in IESG review. Stewart On 11/02/2013 21:15, Alvaro Retana (aretana) wrote: On 1/16/13 5:17 PM, Ben Campbell b...@nostrum.com wrote: Ben: Hi! Sorry for the delay, my filters put this in a different place.. I'm explicitly adding the OSPF chairs. Comments below. 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-ospf-ospfv3-iid-registry-update-00 Reviewer: Ben Campbell Review Date: 2013-01-16 IETF LC End Date: 2013-01-24 Summary: This draft is not ready for publication as a proposed standard. There is a significant IANA registration issue described in the review body. Major issues: This draft carves out a significant part of a registry with an assignment policy of standards action for private use. It offers very little motivation for the change. In my opinion, this sort of change should come with a clear justification. Specifically, the draft modifies the OSPFv3 Address Family Instance ID registry to carve out half of the unassigned space for private use. The justification for this is a single sentence saying that some networks need to use IIDs to identify specific applications. I think that needs significant elaboration in order to motivate the change in a way that the reader can evaluate. My understanding from the OFPS list is that this is in support of draft-ietf-ospf-ipv4-embedded-ipv6-routing, which is an informational draft. I have to wonder why the draft under review was not simply the IANA considerations for that draft. I suggest one of two paths forward: 1) If this change is in support of that draft in particular, then this draft should say that, and include a _normative_ reference. I recognize the normative downref would complicate things--but I think that complication is reasonable under the circumstances. 2) If this change is to support a general need that goes beyond draft-ietf-ospf-ipv4-embedded-ipv6-routing, then this draft should describe that need in enough detail for people to think about it, perhaps with an informative reference to draft-ietf-ospf-ipv4-embedded-ipv6-routing as an _example_. In short (from the shepherd write-up): The new range is for applications that do not justify a standards track OSPFv3 Instance ID allocation. An example would be Routing for IPv4-embedded IPv6 Packets. During pre-publication review, the WG chairs asked us to not include explicit references to draft-ietf-ospf-ipv4-embedded-ipv6-routing as that is just an example and not the only potential user/driver. I don't have a problem adding an example, but I want to get agreement/comments/guidance from the chairs before adding the text. Acee/Abhay?? Minor issues: -- section 3: I don't think it's appropriate to use normative language for IANA requests. Especially not MUST. (I think the strongest thing we can do here is a polite request :-) ) I suggest recasting that to descriptive language, and removing section 2 and the RFC 2119 reference. Yes, we already removed that in the -01 version. Thanks!! Alvaro. . -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: Gen-ART LC Review of draft-ietf-ospf-ospfv3-iid-registry-update-00
On 1/16/13 5:17 PM, Ben Campbell b...@nostrum.com wrote: Ben: Hi! Sorry for the delay, my filters put this in a different place.. I'm explicitly adding the OSPF chairs. Comments below. 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-ospf-ospfv3-iid-registry-update-00 Reviewer: Ben Campbell Review Date: 2013-01-16 IETF LC End Date: 2013-01-24 Summary: This draft is not ready for publication as a proposed standard. There is a significant IANA registration issue described in the review body. Major issues: This draft carves out a significant part of a registry with an assignment policy of standards action for private use. It offers very little motivation for the change. In my opinion, this sort of change should come with a clear justification. Specifically, the draft modifies the OSPFv3 Address Family Instance ID registry to carve out half of the unassigned space for private use. The justification for this is a single sentence saying that some networks need to use IIDs to identify specific applications. I think that needs significant elaboration in order to motivate the change in a way that the reader can evaluate. My understanding from the OFPS list is that this is in support of draft-ietf-ospf-ipv4-embedded-ipv6-routing, which is an informational draft. I have to wonder why the draft under review was not simply the IANA considerations for that draft. I suggest one of two paths forward: 1) If this change is in support of that draft in particular, then this draft should say that, and include a _normative_ reference. I recognize the normative downref would complicate things--but I think that complication is reasonable under the circumstances. 2) If this change is to support a general need that goes beyond draft-ietf-ospf-ipv4-embedded-ipv6-routing, then this draft should describe that need in enough detail for people to think about it, perhaps with an informative reference to draft-ietf-ospf-ipv4-embedded-ipv6-routing as an _example_. In short (from the shepherd write-up): The new range is for applications that do not justify a standards track OSPFv3 Instance ID allocation. An example would be Routing for IPv4-embedded IPv6 Packets. During pre-publication review, the WG chairs asked us to not include explicit references to draft-ietf-ospf-ipv4-embedded-ipv6-routing as that is just an example and not the only potential user/driver. I don't have a problem adding an example, but I want to get agreement/comments/guidance from the chairs before adding the text. Acee/Abhay?? Minor issues: -- section 3: I don't think it's appropriate to use normative language for IANA requests. Especially not MUST. (I think the strongest thing we can do here is a polite request :-) ) I suggest recasting that to descriptive language, and removing section 2 and the RFC 2119 reference. Yes, we already removed that in the -01 version. Thanks!! Alvaro.
Gen-ART LC Review of draft-ietf-ospf-ospfv3-iid-registry-update-00
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-ospf-ospfv3-iid-registry-update-00 Reviewer: Ben Campbell Review Date: 2013-01-16 IETF LC End Date: 2013-01-24 Summary: This draft is not ready for publication as a proposed standard. There is a significant IANA registration issue described in the review body. Major issues: This draft carves out a significant part of a registry with an assignment policy of standards action for private use. It offers very little motivation for the change. In my opinion, this sort of change should come with a clear justification. Specifically, the draft modifies the OSPFv3 Address Family Instance ID registry to carve out half of the unassigned space for private use. The justification for this is a single sentence saying that some networks need to use IIDs to identify specific applications. I think that needs significant elaboration in order to motivate the change in a way that the reader can evaluate. My understanding from the OFPS list is that this is in support of draft-ietf-ospf-ipv4-embedded-ipv6-routing, which is an informational draft. I have to wonder why the draft under review was not simply the IANA considerations for that draft. I suggest one of two paths forward: 1) If this change is in support of that draft in particular, then this draft should say that, and include a _normative_ reference. I recognize the normative downref would complicate things--but I think that complication is reasonable under the circumstances. 2) If this change is to support a general need that goes beyond draft-ietf-ospf-ipv4-embedded-ipv6-routing, then this draft should describe that need in enough detail for people to think about it, perhaps with an informative reference to draft-ietf-ospf-ipv4-embedded-ipv6-routing as an _example_. Minor issues: -- section 3: I don't think it's appropriate to use normative language for IANA requests. Especially not MUST. (I think the strongest thing we can do here is a polite request :-) ) I suggest recasting that to descriptive language, and removing section 2 and the RFC 2119 reference. Nits/editorial comments: None.
