Procedures for Modifying the Resource reSerVation Protocol (RSVP)
draft-kompella-rsvp-change-02

[Ballot discuss]
From: Thomas Narten
To: kireeti@juniper.net
cc: jplang@ieee.org, Allison Mankin ,
    Bert Wijnen
Date: Fri, 16 Apr 2004 14:35:11 -0400
Subject: draft-kompella-rsvp-change-01.txt

Hi Kireeti.

It seems that a ball got dropped on this document. The IESG discussed
this document a while back, but I had only entered a placeholder
discuss for some things we discussed during the telechat. I've
appended my full notes below. I think that once we resolve the issues
below, the document will be ready to be approved.  (I was reminded of
this document because I just got some mail indicating that the ATM
forum is apparently still interested in an RSVP code point, though
they now say they will go for a Vendor type).

Thomas

>    Note that this memo updates the IANA Considerations section (section
>    7) of [RSVP-TE].

updates "and replaces", or just updates?

>    processing of an RSVP entity that belongs to a range designated
>    "Expert Review" MUST be documented in an Experimental RFC.

what about info? (i.e, isn't the point here just not standards track?)

It would be good here to add some wording here that describes what the
general intent of this is. I.e., I gather the goal is to have stuff be
done in an experimental RFC first, get some experience and review, and
then (if appropriate) move to standards track. A big part of this is I
assume a "go slow" and be sure to review and revise, and not just do
one-shot things. If I've summarized the intent correctly, I think it
would be helpful to add a few sentences saying this is the
intention/motivation for saying experimental. It might even be good to
say exactly why information is not allowed (i.e., there is an
assumption that Informational are just published with minimal review
and little ability to influence, and this is precisely what is not
desired.)

> 6. IANA Considerations
>
>    For each of the RSVP name spaces identified by IANA, the space is
>    divided into assignment ranges; the following terms are used in
>    describing the procedures by which IANA allocates values: "Standards
>    Action" (as defined in [IANA]); "Expert Review" and "Vendor Private
>    Use".
>
>    Values from "Expert Review" ranges MUST be registered with IANA, and
>    MUST be accompanied by an Experimental RFC that describes the format
>    and procedures for using the code point.
>
>    Values from "Vendor Private" ranges MUST NOT be registered with IANA;
>    however, the first 4-octet word of the data field MUST be an
>    enterprise code as registered with the IANA SMI Network Management
>    Private Enterprise Codes, and the rest of the data thereafter is for
>    the private use of the registered enterprise.  (For each RSVP entity
>    that has a Vendor Private range, it must be specified where exactly
>    the data field starts; see below for examples.)  In this way, several
>    enterprises (vendors) can use the same code point without fear of
>    collision.

These definitions don't appear until the IANA considerations section,
half way through the document. Yet the terms are used earlier (and
partly defined). It might be good to move the defintions to the
beginning of the document, and also to make it more clear that only
the term "Standards Action" is the one from 2434. "expert review" is
defined differently here. I.e., Replace the text starting with:

  referred to as RSVP entities).  This memo specifies for each name
  space ranges that are "Vendor Private", "assigned by Expert Review",
  and "assigned by Standards Action" (these terms are defined in the
  IANA Considerations section).  New RSVP name spaces must be defined
  in a Standards Track RFC which include guidelines for IANA
  assignments within the new name spaces.
 
to something like (note I've taken text from various places to get
this):

    This memo divides each of the RSVP name spaces into assignment
    ranges; the following terms are used in describing the procedures
    by which IANA allocates values: "Standards Action" (as defined in
    [IANA]); "Expert Review" and "Vendor Private Use" (as defined
    below).

    "Expert Review" ranges refer to values that are to be reviewed by
    an Expert designated by the IESG.  The code points from these
    ranges are typically used for experimental extensions; such
    assignments MUST be accompanied by Experimental RFCs that document
    their use and processing.

    "Vendor Private" ranges refer to values that are
    enterprise-specific and are not registered with IANA.  For Vendor
    Private values, the first 4-octet word of the data field MUST be
    an enterprise code [ENT] as registered with the IANA SMI Network
    Management Private Enterprise Codes, and the rest of the data
    thereafter is for the private use of the registered enterprise.
    (For each RSVP entity that has a Vendor Private range, it must be
    specified where exactly the data field starts; see below for
    examples.)  In this way, different enterprises, vendors or
    Standards Development Organizations (SDOs) can use the same code
    point without fear of collision.

[note specific mention of SDO too.]

> 6.3. Class Types
>
>    Within each object class there is an 8-bit Class Type (also known as
>    a C-Type).  Class Types are scoped to a Class Number.  For each
>    object class, Class Types from 0 to 191 are to be assigned by
>    Standards Action.  Class Types from 192 through 223 are to be
>    assigned by Expert Review.  Class Types from 224 through 255 are
>    reserved for Vendor Private Use.

Since Class  Types are dependendent on the Class Number, it doesn't
seem right to automatically reserve a range of types for either Expert
Review of Vendor Private use. The appropriateness of such a policy
really depends on the Class Number. Seems like it would be better to
say something like:

    Within each object class there is an 8-bit Class Type (also known as
    a C-Type).  Class Types are scoped to a Class Number. In general,
    the appropriateness of allowing assignments of Class Types through
    Expert Review or Vendor Private depends on the semantics of the
    Class Number itself. Thus, any Class Number definition needs to
    specify an appropriate IANA Considerations policy for assigning
    additional Class Type values.

    For the purpose of the existing define Class Numbers (XXX list
    them here?), Class Types from 0 to 191 are to be assigned by
    Standards Action.  Class Types from 192 through 223 are to be
    assigned by Expert Review.  Class Types from 224 through 255 are
    reserved for Vendor Private Use. [XXX, this paragraph needed
    assuming it is correct for the existing class numbers.]

[Ballot discuss]
This seems to leave open the possibility that another SDO could request an Enterprise number
and populate the fields within it.  Is that an appropriate result?

[Ballot comment]
The way this document is structured, the references occur before
most of the document text (which is in the IANA Considerations
section).  There are also references used after the references
section.  This should really be cleaned up, but I think that
the RFC editor will probably do it.

[Ballot comment]
The way this document is structured, the references occur before
most of the document text (which is in the IANA Considerations
section).  There are also references used after the references
section.  This should probably be cleaned up, but I think that
the RFC editor will probably do it.

[Ballot comment]
Nits:

  No IPR boilerplate

  The ordering of the sections in the document ends up being screwy because
  effectively all of the content ended up in the IANA considerations section,
  which appears after the references and so forth.

  I suggest creating a section after the intro with the range information
  for each namespace in it and then have an IANA consideration section that
  refers to this new section.

Review of rsvp-change (Allison):

1. "intent in this document is that code points from these ranges are used for Experimental extensions; it is RECOMMENDED that such assignments be accompanied by Experimental RFCs.  If deployment suggests that these extensions are useful, then they should be described in Standards Track RFCs, and new code points from the Standards Action ranges be assigned. "

Hmm, some experiments are so experimental that they should definitely be in the Private Use space. 

In addition, this seems like a very subtle way of saying that no other SDOs will register RSVP values, if the main use for the Expert Review space is Experimentals.  Is this what is meant and if so, should it be more explicit?

2.

Is it a good idea to have 12 Private Use Class Types?  There may be an unintended effect that they are like FCFS for some time.  Would it be better to increase the number of Expert Review Types and decrease  Private Use, since those will be likely to collide if they are fewer, and therefore be less like the old FCFS?

3. 

6.3.1 Sub-objects

"Within a Class Type, sub-objects may be defined, generally as a Type-Length-Value triple.  These sub-objects are also registered with IANA, and appropriate ranges of values will be set aside for these."

This does not give a requirement to register sub-objects.  It needs to. "When new sub-objects are defined, it must be done in a standards track RFC" or something like this.