Subject: RSVP Aggregation - cleanup of IANA considerations needed

From: Allison Mankin <[email-masked]>
Date: Wed, 28 Mar 2001 08:15:52 -0500

Hi folks,

I thought I'd send this to the mailing list as well as principal
authors and chair.

We ADs accepted the RSVP Aggregation draft once it had very strong security
considerations about the function that rewrites the protocol number,
and just before IETF, the IESG supported advancement of the draft to PS.

But the draft needs one further rev because the IANA has asked us to have
the IANA considerations written out explicitly.  By this mail, I ask the
document's editor to do so and submit a new i-d.  Both IESG and author/editors
are having to learn recently how to write very clear instructions to IANA
in the IANA Considerations.  I will be glad to help with this one, if needed.

What's currently there states four registration needs, but very passingly
and telegraphically.

For each of the four, the revised IANA considerations should include a reference
to where in the early text it is discussed, and should state explicitly
what should be registered as soon as the RFC is published.

Here's what's in the draft now:

> 6.  IANA Considerations
> 
>	  Beyond allocating an IP Protocol, a PathErr code, a set of
>	  values for the IPv6 router alert option, and an RSVP
>	  Addressing object "type", there are no IANA issues in	this
>	  document. We do not define an	object that will itself	require
>	  assignment by	IANA.
> 

Are the values for the IPv6 router alert option to be a one-time registration
of N of them (should also state what N is) or something that might need to be 
expanded later?  The IANA needs a decision procedure for such a registry, see
BCP 26 (RFC 2434), section 2.

Allison