Subject: RE: padata-type ?

From: Tim Alsop <[email-masked]>
Date: Mon, 12 Apr 2004 18:15:23 +0100

Sam,

Thankyou.

The reason for asking is that I am working with another standard (not IETF controlled) that will make reference to the Kerberos standard, so I want to make sure if we mention rfc1510 that this rfc number is going to be the correct rfc in the future. If I understand you correctly, a new number will be allocated when clarifications is approved by IESG so we should make this clear in our documentation.

Regards, Tim.

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: 12 April 2004 18:23
To: Tim Alsop
Cc: [email-masked]
Subject: Re: padata-type ?

>>>>> "Tim" == Tim Alsop <[email-masked]> writes:

    Tim> Can you also give me an indication as to the future of
    Tim> rfc1510 ? Will it eventually be deprecated or superseded -
    Tim> effectively being replaced with a new rfc covering the
    Tim> Kerberos protocol when clarifications, extensions and other
    Tim> drafts are completed, or will each draft become its own rfc
    Tim> and we will continue to refer to Kerberos as rfc1510 ?

Clarifications obsoletes RFC 1510, so when it is approved by the IESG
RFC 1510 will be replaced.  Since the crypto framework has already
been approved, I have been acting as if the crypto related sections of
RFC 1510 are already replaced.  This is not quite true: the document
that will replace them is a (currently unpublished) proposed standard,
but the protocol action that updates the references to the new
document has not yet happened.

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 12 Apr 2004 15:28:01 -0400

On Monday, April 12, 2004 18:15:23 +0100 Tim Alsop 
<[email-masked]> wrote:

> The reason for asking is that I am working with another standard (not
> IETF controlled) that will make reference to the Kerberos standard, so I
> want to make sure if we mention rfc1510 that this rfc number is going to
> be the correct rfc in the future. If I understand you correctly, a new
> number will be allocated when clarifications is approved by IESG so we
> should make this clear in our documentation.

That is correct.  RFC's are immutable; once published, an RFC never changes 
(the rfc-editor does maintain a list of errata in published RFC's at 
http://www.rfc-editor.org/errata.html, but the originial documents are 
never modified).

RFC1510 describes Kerberos V, Specification 1.

Once approved, kerberos-clarifications will be published as a new RFC; this 
will obsolete RFC1510 and (in combination with the crypto and AES 
documents) will describe Kerberos V, Specification 2.

In most cases it is desirable in a standards context for normative 
references to be to a particular version of the specification.  For IETF 
standards, you can do this by referring to a particular RFC.  In a few 
cases, you actually want a reference to "the current version", whatever 
that happens to be.  The IETF way to do this is to refer to an STD number; 
however, these numbers are currently assigned only to full Internet 
standards.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Apr 2004 16:43:32 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> In most cases it is desirable in a standards context for
    Jeffrey> normative references to be to a particular version of the
    Jeffrey> specification.  For IETF standards, you can do this by
    Jeffrey> referring to a particular RFC.  In a few cases, you
    Jeffrey> actually want a reference to "the current version",
    Jeffrey> whatever that happens to be.  The IETF way to do this is
    Jeffrey> to refer to an STD number; however, these numbers are
    Jeffrey> currently assigned only to full Internet standards.

Interesting.  I get the impression but have not confirmed in ID Nits
or RFC editor policy that you need to include an RFC number when you
make a STD reference.

It seems that in practice, people use IANA registries to indirect to
current versions.  Stringprep is the obvious example of doing this.