Skip to main content

Last Call Review of draft-ietf-ospf-ospfv3-iid-registry-update-00

Request Review of draft-ietf-ospf-ospfv3-iid-registry-update
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-01-24
Requested 2013-01-10
Authors Alvaro Retana , Dean Cheng
I-D last updated 2013-01-16
Completed reviews Genart Last Call review of -00 by Ben Campbell (diff)
Genart Telechat review of -03 by Ben Campbell (diff)
Assignment Reviewer Ben Campbell
State Completed
Request Last Call review on draft-ietf-ospf-ospfv3-iid-registry-update by General Area Review Team (Gen-ART) Assigned
Reviewed revision 00 (document currently at 04)
Result Not ready
Completed 2013-01-16
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


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

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: