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" <stbryant@xxxxxxxxx> 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" <ben@xxxxxxxxxxx> 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 >