Re: [Idr] draft-decraene-idr-reserved-extended-communities-00

[Eric Rosen <[e-mail]>]

John> although draft-decraene-idr-reserved-extended-communities-00 makes its
John> request from the Standards Action portion of the two registries, it
John> need not -- the authors could have requested an FCFS code point
John> instead in which case this discussion would have been moot.  They
John> could still do this.

The discussion about the allocation of the codepoint would be moot, but I
don't think there's a FCFS procedure for the creation of IANA registries.
So I don't really think this draft could go forward without WG discussion
even if FCFS codepoints were requested.

I think it's a valid question to ask why this new registry is actually
needed.  The draft offers two justifications:

   "one needing to reserve a single non-transitive extended community
   would need to reserve an extended subtype which represents 2^48
   communities.  This would both waste the resources"

I don't really see what the resource is that's being wasted.  Are we worried
about running out of extended type codepoints?

   "and disable the ability to define global policies on reserved
   communities, such as to filter them out."

The proposal is to have a big chunk of FCFS space in the new registry.  This
means that anyone can use it for anything.  That makes it hard to see how
there could be a useful global policy to filter them all out.

I'm having trouble seeing what value is provided by this new registry.

Bruno> if people can't get a community, they will get a full type
Bruno> instead. This seems much more suboptimal to me.

I'm not sure what "much more suboptimal" means in this context.  

I also think it's confusing to call these extended communities "reserved",
as RFC 5226 ("Guidelines for Writing IANA Considerations") defines the term
"reserved" as meaning "not to be assigned".