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

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

I agree with adrian that it would be convenient for the reader if the document specified what it was updating in the abstract.

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.
"""

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.