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

["Alvaro Retana (aretana)" <[e-mail]>]

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.