Subject: Re: RSVP Aggregation - cleanup of IANA considerations needed

From: Fred Baker <[email-masked]>
Date: Thu, 05 Apr 2001 08:44:29 -0700

At 08:15 AM 3/28/2001 -0500, Allison Mankin wrote:
>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.

OK, we'll get a new paragraph in there.

---

From: Fred Baker <[email-masked]>
Date: Thu, 05 Apr 2001 08:59:08 -0700

At 08:15 AM 3/28/2001 -0500, Allison Mankin wrote:
> > 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.

Bruce - I think you're the guy with the most up to date draft text. Here is 
some proposed text:

.nh 1 "IANA Considerations"
.lp
Section 1.2 proposes a new protocol type, RSVP-E2E-IGNORE, which is used to 
identify a message which routers in the network core will see and must 
evaluate the egress interface type to determine what they must do with.

Section 1.4.9 describes the manner in which the Router Alert is used in the 
context of this specification, which is essentially an algorithmic 
numeration of the number of aggregation nesting levels it is passed. RFC 
2113, the IPv4 Router Alert, has the option simply ask the router to look 
at the protocol type of the intercepted datagram and decide what to do with 
it; the parameter is additional information to that decision. RFC 2711, the 
IPv6 Router Alert, turns the parameter into an option sub-type. As a 
result, the IPv6 router alert option may not be used algorithmically in the 
context of the protocol in question. We therefore request IANA to assign a 
block of 32 values which we may map to nesting depths 0..31, hoping that 32 
levels is enough. Since RFC 2711 assigns the values 0, 1, and 2, we suggest 
that these values occupy the range 3..35.

Section 3.2 discusses a path error code NEW-AGGREGATE-NEEDED, to be assigned.

Sections 3.3, 3.4, and 35 describe extensions to three object classes: 
Session, Filter Specification, and Sender Template. These require two 
common C-Types to be specified for the aggregator's address, which we call 
the RSVP-AGGREGATE-IP4 and RSVP-AGGREGATE-IP6. The same number should be 
used for all three objects, as is done for IPv4 and IPv6 address tuples in 
RFC 2205.