Subject: [ipfix-protocol] PROTO-26: IANA considerations

From: Benoit Claise <[email-masked]>
Date: Wed, 28 Jul 2004 17:57:51 +0200

Dear all,

A few thoughts on the IANA considerations. Think about it before next week meeting.

I went through RFC 2434, listed the paragraphs of interest, and commented on the applicability for IPFIX.
Please give me your feedback whether this is what you had in mind.
Note: all sentences and words between "" come from the RFC

RFC 2434

1.
"One way to insure community review of prospective assignments is to
have the requester submit a document for publication as an RFC. Such
an action insures that the IESG and relevant WGs review the
assignment. This is the preferred way of insuring review, and is
particularly important if any potential interoperability issues can
arise. For example, many assignments are not just assignments, but
also involve an element of protocol specification. A new option may
define fields that need to be parsed and acted on, which (if
specified poorly) may not fit cleanly with the architecture of other
options or the base protocols on which they are built.

In some cases, however, the burden of publishing an RFC in order to
get an assignment is excessive. However, it is generally still useful
(and sometimes necessary) to discuss proposed additions on a mailing
list dedicated to the purpose (e.g., the [email-masked] for
media types) or on a more general mailing list (e.g., that of a
current or former IETF WG).  Such a mailing list provides a way for
new registrations to be publicly reviewed prior to getting assigned,
or to give advice for persons who want help in understanding what a
proper registration should contain."

-> mailing the IPFIX, PSAMP lists.
-> requesting directly to IANA in case the first two 
   working group disappear

2.
"While discussion on a mailing list can provide valuable technical
expertise, opinions may vary and discussions may continue for some
time without resolution.  In addition, the IANA cannot participate in
all of these mailing lists and cannot determine if or when such
discussions reach consensus.  Therefore, the IANA cannot allow
general mailing lists to fill the role of providing definitive
recommendations regarding a registration question.  Instead, the IANA
will use a designated subject matter expert. That is, the
IANA forwards the requests it receives to a specific point-of-contact
(one or a small number of individuals) and acts upon the returned
recommendation from the designated expert. The designated expert can
initiate and coordinate as wide a review of an assignment request as
may be necessary to evaluate it properly.

-> the IPFIX and/or PSAMP WG chairs, or Area director should designate 
   a few matter experts, or potentially be the experts themselves

3.
For the new information model elements, I recommend a mixed solution of 
"First Come First Served" and "Expert Review".

  "First Come First Served - Anyone can obtain an assigned number, so
       long as they provide a point of contact and a brief
       description of what the value would be used for.  For
       numbers, the exact value is generally assigned by the IANA;
       with names, specific names are usually requested.

       Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP
       and UDP port numbers."

  "Expert Review - approval by a Designated Expert is required."

  -> Someone would request a number.
     The expert (discussed above) would then check the accuracy and 
     completeness of specification. 

4.
For new FlowSet, I recommend a "specification required" solution.

   "Specification Required - Values and their meaning must be
        documented in an RFC or other permanent and readily available
        reference, in sufficient detail so that interoperability
        between independent implementations is possible."

  -> this is typically the case for PSAMP, we need a new RFC.

5.
"It should be noted that it often makes sense to partition a name
space into several categories, with assignments out of each category
handled differently."

-> I don't think it applies in our case.
   Specifically if the scopes use the information element already defined 
   (see my previous email)

6.
"Registrations are a request for an assigned number, including the
related information needed to evaluate and document the request. Even
after a number has been assigned, some types of registrations contain
additional information that may need to be updated over time. For
example, mime types, character sets, language tags, etc. typically
include more information than just the registered value itself.
Example information can include point of contact information,
security issues, pointers to updates, literature references, etc.  In
such cases, the document must clearly state who is responsible for
maintaining and updating a registration.

-> The important job of the experts is to review the plain 
   English text specification ("literature reference" for accuracy 
   and completeness. So, yes, some extra text next to the information
   element number is compulsory.

7.
"An analysis of security issues is required for all parameters (data
types, operation codes, keywords, etc.) used in IETF protocols or
registered by the IANA. All descriptions of security issues must be
as accurate as possible regardless of level of registration. In
particular, a statement that there are "no security issues associated
with this type" must not given when it would be more accurate to
state that "the security issues associated with this type have not
been assessed".

-> "the security issues associated with this type have not been 
   assessed" is the appropriate sentence to be written note in the
   IANA section.

8. 
-> We should also note that WG will be assigning new informations
   elements up to the point IANA is ready to take over.

9. 
-> What is the best place for this IANA section?
   IPFIX Information Model and/or IPFIX Protocol Specifications.

Feedback? 
If you agree on this, the next step is try write down some text to reflect this...

Regards, Benoit.

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/