OSPFv3 Instance ID Registry Update
draft-ietf-ospf-ospfv3-iid-registry-update-04

Note: This ballot was opened for revision 02 and is now closed.

(Jari Arkko) Yes

Comment (2013-04-23 for -03)
No email
send info
I'd like to thank Ben Campbell for the Gen-ART review.

(Stewart Bryant) Yes

(Adrian Farrel) Yes

Comment (2013-04-22 for -03)
No email
send info
Thanks for this document.

It would be nice if the Abstract included a second paragraph...

   This document updates RFC 5838 that includes the base definintion for
   the modified registry.

---

Section 1

As this document will (presumably) be published as an RFC and cause the
registry to be updated, the text in Section 1 will become confusing:
                       
   The following table lists the value ranges as
   currently allocated.

How about...

   The following table lists the value ranges as
   allocated for RFC 5838.

---

You could either delete the change log, or add a note to the RFC editor
that they can remove it upon publication.

(Richard Barnes) No Objection

Comment (2013-04-24 for -03)
No email
send info
The abstract is completely unhelpful.  It should say what sort of modification is being made.  Suggested:
"""
This document modifies the "Unassigned" number space in the IANA "OSPFv3 Instance ID Address Family Values" registry.  The current "Unassigned" space is divided into two halves, one half "Unassigned" but managed via Standards Action, and one half reserved for private use.
"""

(Benoit Claise) No Objection

Comment (2013-04-23 for -03)
No email
send info
No objection to the publication of this document, but please improve the following, which confused me.

   For example,
   [I-D.ietf-ospf-ipv4-embedded-ipv6-routing] describes an application
   in which IPv4-embedded IPv6 addresses are used to transport IPv4
   packets over an IPv6 network.  While the IPv4-embedded IPv6 addresses
   do in fact represent IPv6 destinations, it would be operationally
   benefitial to be able to easily identify the the specific application
   by having a separate space to do so.

My first impression was: it doesn't make sense to embed a protocol hierarchy (as we call it in the DPI world) into an OSPF instance, so you surely want the "private use" range. On top of that "unassigned - Standard Action" was already available in the registry.
After thinking so more about it, I'm not sure any longer that you intend "private use", and http://tools.ietf.org/html/draft-ietf-ospf-ipv4-embedded-ipv6-routing-11#section-13 doesn't help. 
Regardless of whether it's right or wrong to embed a protocol hierarchy into the OSPF instance (this will be a discussion for raft-ietf-ospf-ipv4-embedded-ipv6-routing), since you use this example as a justification for this document, express if the example is supposed to use "private use" or "reserved". In other words, why "unassigned" doesn't work

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2013-04-22 for -03)
No email
send info
I agree with adrian that it would be convenient for the reader if the document specified what it was updating in the abstract.

(Barry Leiba) No Objection

(Ted Lemon) (was Discuss) No Objection

Comment (2013-04-25 for -03)
No email
send info
The introduction doesn't really lead into Section 2 with any explanation. We just have a statement of a problem that exists in the introduction, and then a statement about a change to the registry in section 2, with no text at all stating how this solves the problem.

What I was no doubt naively wondering was why this wasn't being handled through more specific allocations, rather than a private allocation with no rules.   I assume it's because you don't want to reserve iids for all time for transition technology, but it would be good if that were stated explicitly.

I don't have a strong objection to this document, but it would be awfully nice if there were an additional glue paragraph in there somewhere explaining the leap from problem to registry update.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection