[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ITU related IANA assignments for RSVP
Inline
> -----Original Message-----
> From: IANA [mailto:iana@iana.org]
> Sent: vrijdag 17 januari 2003 2:28
> To: Wijnen, Bert (Bert)
> Cc: Iesg (E-mail); Bob Braden
> Subject: RE: ITU related IANA assignments for RSVP
>
>
> Bert,
>
> -For the RSVP Assignments-
>
> Please see the attached proposed RSVP registry.
> These are only suggested values and these are not public.
>
> I have copied Bob Braden as the "RSVP Expert" (I have
> to keep his hats straight). Bob, please take a look
> at these proposed assignments and let me know if you see
> any issues.
>
Thanks... Pls note that changes are coming, cause based
on your questions below I have checked with Zhi and Bala
and I did not understand the I-Ds correctly.
I have a separate email to Bala/Zhi with copy to IANA
(not whole IESG) to verify that I have now understood
it correctly, and if so then we need to make a few more
changes.
> Tomorrow (since I'm completely cross-eyed looking at this
> stuff now) I will send the same suggested registry and
> comments for LDP since 2 of the 3 documents also contain
> LDP registrations.
>
OK, I am going to go over these myself, right after this email
> See below for areas are where I have comments/questions.
>
> Thanks! I'm looking forward to getting this done as
> quickly as possible. :)
>
Great. Hope we can get them (provisionally) assigned early
next week, and then if IESG indeed approves bala and Osama
documents, then we can announce (or inform ITU) friday
next week.
See detailed answers below
> Michelle
> IANA
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: Thursday, January 16, 2003 3:49 PM
> > To: IANA (E-mail)
> > Cc: Iesg (E-mail)
> > Subject: ITU related IANA assignments for RSVP
> >
> >
> > This is what I think I understand is being requested by ITU/OIF
> > with the 3 documents w.r.t. RSVP. Maybe based on this you can
> > get closer to proposed assignments in the RSVP space?
> >
> > >From http://www.iana.org/assignments/rsvp-parameters I find:
> >
> > - RSVP has classes of data objects that are Identified by
> > a Class Name and a Class Number.
> > Within a class, there are Class Types, also named C-types.
> > I believe some people also use the term sub-objects for C-types.
> >
> > There is a range of Class Numbers (224-255) that is
> > assigned on FCFS basis
> >
> > Within a Class, I think the assignment of C-types is under
> > guidance of the specific Class.
> >
> > - Error Codes and Globally-Defined Error Value Sub-Codes
> >
> > An Error Code is an 8-bit quantity that appears in an ERROR_SPEC
> > object to broadly define an error condition. With each Error Code
> > there may be a 16-bit Error Value that further specifies the cause
> > of the error. Error Values may be globally defined, in which case
> > the sub-code component is assigned by IANA [RFC2205].
> >
> >
> > Now the documents:
> >
> > draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
> >
> > - This document is asking for the assignment of 2
> > Class Names/Class Numbers in the FCFS space (224-255)
> > Formally no documentation needed (I think), but IANA asked
> > for supporting documentations and so they provided that.
> >
> > They ask for this in sect 12.2 and they want:
> >
> > CALL_ID and CALL_OPS
>
>
> I used suggested values where I could. The only one
> that I had to change was CALL_ID to 230 instead of 227.
> Both CALL_ID and CALL-OPS are in the temporary registry.
>
Yep, that looks good, and Zhi had actually agreed to change the
227 into 230 in an earlier email.
> >
> > Within each of these classes they want a few C-types, which
> > I think can be done under their own guidance (if any is needed)
> >
> > the two C-types within the CALL_ID class both have another
> > type field (under their control of course) and they provide
> > IANA guidelines as to how to assign values for that field.
> > They also have 5 values that they want to assign immediately
> > as part of this document. This sounds to me as if they are
> > asking IANA to keep a new registry (or sub-registry) for
> > values in this type field in these C-types in this Class.
>
> I have added the 2 C-types and an additional sub-registry.
> However, I'm not sure if I have set-up the sub-registry
> of type fields correctly. I will need guidance.
>
What you did looks correct.
> >
> > - They also ask for another assignment in a field of a new
> > C-type (EGRESS_LABEL) in the GENERALIZED_UNI class.
> > They ask for this in sect 12.2.
> >
> > This Class and C-type do not yet exist, they are part of the
> > Bala document But I think the Bala document controls if/how
> > C-types within that GENERALIZED_UNI class and field within
> > C-types can be assigned. Since they are supporting/referencing
> > each other, I think that this is OK (once the GENERALIZED_UNI
> > class has been assigned of course).
> >
> > See below under bala document though, it is kind of strange
> > that the bala doc states in sect 4.2 that IANA does not
> > need to administer C-types underneath GENERALIZED_UNI.
> >
>
> I have added the C-type to GENERALIZED_UNI but I'm not sure
> if I have done this correctly as they mention sub-ojects of
> EGRESS_LABEL. I will need guidance. Also the question about
> what is mentioned in the bala document needs to be addressed.
>
The above I understoiod incorrectly. I have spoken with Zhi
and Bala, I have send another email with explanation.
>
> > - They also ask for 3 new C-types in the SESSION class (Class
> > Number 1). They ask for this in sect 12.3.
> >
> > This is under control/guidance of RFC2205 I think. But
> > unfortunately, RFC2205 does not have an IANA considerations
> > section. Appendix A seems to suggest they can just be added.
> > I also see that various other RFCs have claimed allocations
> > here (RFC2207, 3209, 3175)... so it seems it is OK to
> > assign the requested values.
>
> I have added these.
>
Looks good to me
> >
> > - Then, in sect 12.4 they ask for 4 new error-code values.
> > These are value sub-codes within an existing error-code
> > (namely within error code 24 as defined by RFC3209)
> > RFC3209 does assign a initial set of sub-codes but as far
> > as I can tell it is silent on how to decide if new values
> > can be assigned. So... since RSVP expert and IESG approved,
> > I think this is OK.
> >
> > The suggested values I think are just the next set of
> > values after those asked by the bala document below.
>
> I have added these.
>
looks good to me
> ***********************************************************
>
> > draft-bala-uni-ldp-rsvp-extensions-01.txt
> >
> > - This document asks for a single new Class Name and Class
> > number (sect 4.2) namely GENERALIZED_UNI although they use
> > mixed case, while a class name must be all uppercase.
> > This is in the FCFS space, so I think it is OK to assign.
> >
> > - This doc also states (in sect 4.2) that IANA does not need to
> > administer the C-types withing GENERALIZED_UNI. So it is kind
> > of strange that Zhi Lin is asking IANA to make assignments
> > within this space underneath GENERALIZED_UNI.
> >
> > But I do wonder if it is wise that IANA lists this new
> > GENERALIZED_UNI code point without at least pointing to the
> > authority that then does administer sub-assugnments.
>
> In the temp registry I have added values for GENERALIZED_UNI.
> However, I do not think the way I have added them are correct
> and therefore need assistance. Also the overall question of
> whether or not these should even be added due to the statement
> made by this document should be addreseed as well as if a pointer
> is needed.
>
This also is being clarified in my other email to Zhi and Bala
and you.
> >
> > - The doc also asks (sect 4.2) for a C-type under the SESSION
> > (class-num 1) class.
> >
> > This is under control/guidance of RFC2205 I think. But
> > unfortunately, RFC2205 does not have an IANA considerations
> > section. Appendix A seems to suggest they can just be added.
> > I also see that various other RFCs have claimed allocations
> > here (RFC2207, 3209, 3175)... so it seems it is OK to
> > assign the requested values.
>
> I have added the C-Type.
>
Looks correct to me
> >
> > - Then, in sect 4.2 they ask for 5 new error-code values.
> > These are value sub-codes within an two existing error-codes
> > (namely within error code 24 as defined by RFC3209, and
> > within error-code 2 as defined by RFC2205)
> > RFC3209 does assign a initial set of sub-codes but as far
> > as I can tell it is silent on how to decide if new values
> > can be assigned. So... I think this is OK.
> > RFC2205 says about error code 2:
> > Contents of the Error Value field are to be determined
> > in the future.
> > which seems to say it is OK to assugn values.
>
> I did add error code 02 from RFC2205 and the erro code values.
>
Good... it kind of looks incomplete now, cause it does not
list the original RFC2205 value sub-codes. See below.
> >
> > If the requested/suggested values make sense I do not know,
> > I guess the RSVP-Expert should tell us, but I I would not
> > be surprised if OIF members have probably already
> > implemented the suggested codes.
>
> I was under the impression that they are already using them so
> where I could I used their suggested values.
>
I think so too, so your approach seems good to me.
> >
> > This reveals to me that the error codes and values from
> > RFC2205 seem to not be included in the online IANA registry
> > at http://www.iana.org/assignments/rsvp-parameters
> >
>
> I will look at 2205 and add these codes and values. I'll have Bob
> verify that I have added them all correctly and that I did not
> miss anything.
>
>
Yes... to make the registry complete you would have to add all of
those too.
Bert