Subject: Editorial snafus in RFC 2751 and RFC 2752

From: Andrew Smith <[email-masked]>
Date: Thu, 1 Jun 2000 11:33:20 -0700

It has come to our attention that there was an editorial snafu that occurred
sometime last summer during the various edits of the Internet Drafts from
the RAP WG that became RFC 2751 and RFC 2752. At that time, we had an
informal co-ordination of the P-Type assignments within the POLICY_DATA RSVP
object and we messed up and these got switched around before WG and IETF
approval and RFC publication.
 
Unfortunately, people have been implementing these drafts for a while now
and, in fact, there have been significant numbers of copies of
implementation shipped to customers using the original assignments which are
incompatible with the assignments in the RFCs. This leads to headaches.

The assignments in question are as follows:
================================================================
RFC 2752            Identity Representation for RSVP        January 2000

  P-Type (Identity Type)
       Type of identity information contained in this Policy Element
       supplied as the Policy element type (P-type). The Internet
       Assigned Numbers Authority (IANA) acts as a registry for policy
       element types for identity as described in the [POL-EXT].
       Initially, the registry contains the following P-Types for
       identity:

       1   AUTH_USER       Authentication scheme to identify users

       2   AUTH_APP        Authentication scheme to identify
                           applications
=================================================================

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

   P-Type: 16 bits
      PREEMPTION_PRI  = 3

=================================================================

The original assignments, prior to last summer, were as follows:

1  PREEMPTION_PRI
2  AUTH_USER
3  AUTH_APP

===============================================================

So, what to do about this? The "correct" answer is to say that people were
stupid to ship product before the RFCs were out and that they should fix
things themselves. However, this would cause serious deployment headaches
that could easily affect the larger choice of whether or not to deploy
RSVP-based products in a customers network. And it is a bad way to reward
the implementers whose early experiences led to *significantly* better
protocol-definition documents.

It is up to the RAP WG, as the sponsor of these RFCs, to determine what the
best course of action is, in consultation with the RSVP WG of course. If we,
the WG, were to recommend to change the RFCs back to the original P-Type
values (and re-issue these 2 RFCs) then I hope that the IESG would be
sympathetic (I guess we should ask them first really ... I did ask Scott
Bradner and he suggested that the WG should first come to a decision as to
what it wants to do).

So, please express your opinions ASAP to the RAP mailing list on this
potential change. We will try to gauge the consensus to determine our next
steps, if any.

Thank you,

Andrew Smith
RAP WG co-chair

---

From: "Nitsan Elfassy" <[email-masked]>
Date: Wed, 7 Jun 2000 11:41:19 +0200

Andrew,

We support changing the PE types back to the original assignment.
Cisco is among those vendors that worked together to gain field experience,
which contributes so much to the standard success.
Since some of our colleague vendors, as you have noted, already shipped a
product that supports the original assignment, I second helping everybody
avoid those "headaches" you described.

As for the IETF procedures to support such a change, I guess the co-authors
will not have to cross the Rubickon, will they ?

Nitsan

Nitsan Elfassy - QPM-COPS PDP - Dev Mgr.
mailto://[email-masked]
Direct Line: 972-9-9700066
Cisco Israel
Herziliya Business Park,
4 Maskit St., P.O.B 12497,Herziliya
46766, ISRAEL