Re: [Gen-art] Gen-ART LC Review of draft-ietf-ospf-ospfv3-iid-registry-update-00

[Stewart Bryant <[e-mail]>]

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" <[e-mail]> 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" <[e-mail]> 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