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

[Jon Mitchell <[e-mail]>]

On 17/06/13 09:11 -0400, Eric Rosen wrote:
> > 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.
> 

Eric - this is understood - what I meant to ask is explicitly put a
normative reference to the existing URL (assuming it will be rebuilt
in same place), and reference that in section 5.  Also, putting a note
in the draft with instructions to RFC Editor (for removal upon
publication), to ensure that the proper final URL reference is
included in the RFC.  By the current reading of the draft, this could
be published as an RFC and all the IANA actions to re-organize the
registries coudld be done and this RFC would not have a URL reference
to the registry.

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

Yes, sorry.

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

Sounds good.

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

OK - I thought a sub-type registry would be required to be defined for
each seperately (even if the values matched).  Thanks for clarifying.

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

Yes, I see it more clearly on second pass it's mentioned in Section 5
and Section 2.