Re: [Idr] draft-rosen-idr-extcomm-iana-00.txt

[Eric Rosen <[e-mail]>]

Thanks for taking the time to read through all the tedious details!

> Section 6 - should you just change title of Section 5 then?

Yes, that seems like a sensible idea.

> Considering this redefines every registry and has content
> in it, maybe a note to IANA/RFC Editor to hold publication until URL
> references to the actual re-organized IANA registries, which will be
> more useful to future readers than stale content in Section 5.

Generally an RFC is not published until the IANA actions are completed;
there's a "waiting for IANA" state as part of the RFC Editor's workflow, and
IANA always (at least in my experience) verifies with the authors that the
proper IANA actions are being taken.

> Section 5.2.2 - Section header says Transitive, Registry Name says
> Non-Transitive?

Did you mean section 5.2.10?  The registry name should say "transitive".

> Section 5.2.10 - this section nor anywhere else in document talks about
> Traffic Actions (for flow spec) which is currently referenced in BGP
> Extended Communities registry - will it be removed from the registry or
> should 0x07 just have a comment/reference to it's separate registry?

I overlooked this one.  I think the proper way to handle it is with the
following entry in the "BGP Generic Non-Transitive Experimental Use
Extended Community Sub-Types" registry:

    0x07         Flow spec traffic-action (Use of the Value field is defined
                 in the "Traffic Actions Field" registry.)

> Section 5.1.1 - first thought it was mistake that simpson draft had
> full type considering all other flowspec actions are sub-type of
> experimental, but guess this is a point to take up with those authors

Looking at draft-simpson-idr-flowspec-redirect, I see it defines a
transitive type (0x08), but it doesn't seem to define any sub-types, even
though it requests an "extended type".  Under the proposed reorganization,
the authors would have specify whether they want a Sub-Type registry for the
second octet, or whether they want to treat the second octet as part of the
value field. 

> 0x06 could use standard wording of "Sub-types are defined in..."

Yes, good point.

> Section 5.2 - it would be easier to understand I think if you split
> transitive and non-transitive sub-types into seperate sub-sections.

I don't think that would be right, because the transitive/intransitive
distinction is part of the Type field, not part of the Sub-Type field.  It
should be possible for a Sub-Type registry to be shared between a transitive
Type and an intransitive Type (although there are no current examples of
that).

> Section 4 - Can I suggest "Standards Action" for new Types, or at
> least something more specific than request to IANA.

Both Type registries (and the Sub-Type registries as well) have defined
registration policies for specific value ranges.