Subject: RE: Editorial snafus in RFC 2751 and RFC 2752

From: "Yoram Bernet" <[email-masked]>
Date: Thu, 1 Jun 2000 14:15:13 -0700

Thanks Andrew...

Not surprisingly, I vote to change the RFCs. Isn't proposed standard
status supposed to be ammenable to changes?

Y

> -----Original Message-----
> From: Andrew Smith [mailto:[email-masked]]
> Sent: Thursday, June 01, 2000 11:33 AM
> To: rap (E-mail); rsvp@isi. edu (E-mail)
> Cc: 'Scott Bradner'; 'Bert Wijnen'; Randy Bush (E-mail);
> [email-masked]'
> Subject: Editorial snafus in RFC 2751 and RFC 2752
> 
> 
> 
> 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: Shai Herzog <[email-masked]>
Date: Fri, 02 Jun 2000 14:59:47 -0400

On second thought, I question the procedure where a draft with an IANA
clause (with number registration) can become RFC before its values are
actually recorded with IANA. Since the motivation for using IANA is to
prevent numbering blunders, allowing RFCs to be published pre-IANA registration
is crippling the mechanism.

In fact, I've just visited http://www.iana.org/numbers.htm#C only to
find out that COPS client numbers have yet to be registered with IANA, even
though the RFCs have been around for quite some time.

So, my suggestion is to have a pre-RFC registry with IANA, that follows
an I-D since creation (if it has an IANA clause). When the draft goes
to last call, its IANA registry goes with it. When the draft is approved,
the registry is moved to the "production" IANA registry.

2c (+2c) = my 4c ;-)

Shai

-----
Date: Fri, 02 Jun 2000 14:43:51 -0400
To: Bob Braden <[email-masked]>, [email-masked], 
[email-masked], [email-masked], [email-masked]
From: Shai Herzog <[email-masked]>
Subject: RE: Editorial snafus in RFC 2751 and RFC 2752
Cc: [email-masked], [email-masked], [email-masked], [email-masked], 
[email-masked]

I agree.

Seems that having two copies of RFCs 2751 floating around with different
values would be very confusing (even if it was permitted since RFCs don't
have version numbers like IDs).

If we decide to change the values to reflect actual deployed implementations
I think we should re-issue these RFCs with new numbers and obsolete the old
ones.

my 2c

Shai

At 04:37 PM 6/2/2000, Bob Braden wrote:
   *>
   *> Thanks Andrew...
   *>
   *> Not surprisingly, I vote to change the RFCs. Isn't proposed standard
   *> status supposed to be ammenable to changes?
   *>
   *> Y

Yoram,

Surely you realize, RFCs DO NOT CHANGE, ever, once they are published.
What you *can* do is to publish a new RFC that obsoletes the bad one.

Such a procedure is hardly unknown in the history of the
Internet ;-)

Bob Braden (wearing his RFC Editor)

__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Fax : (914) 654-0209
Framingham, MA 01701                          Main: (508) 620-1141

---

From: "Ralph Santitoro" <[email-masked]>
Date: Thu, 8 Jun 2000 17:48:55 -0400

Andrew,

Given the nature of this assignment change in the RFC (an editorial
mistake), we support changing the P-Types back to their original assignment
as defined in the Internet draft, namely:

1 = PREEMPTION_PRI
2 = AUTH_USER
3 = AUTH_APP

Ralph Santitoro
QoS and Policy Architecture
Nortel Networks
Tel: 805-527-3024
[email-masked]

-----Original Message-----
From: Andrew Smith [mailto:[email-masked]]
Sent: Thursday, June 01, 2000 11:33 AM
To: rap (E-mail); rsvp@isi. edu (E-mail)
Cc: 'Scott Bradner'; 'Bert Wijnen'; Randy Bush (E-mail);
[email-masked]'

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)

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

   P-Type: 16 bits
      PREEMPTION_PRI  = 3

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: Andrew Smith <[email-masked]>
Date: Fri, 16 Jun 2000 11:14:41 -0700

Well, I've seen several messages in suport of this change and none against
it: would the authors of RFC 2751 and 2752 please submit some revised drafts
that incorporate these 3 changes? Hopefully this can be done before the next
Internet-Draft deadline (July 14th) - we can then issue WG last calls.

Thanks,

Andrew Smith
RAP WG co-chair