Subject: Re: [pkix] FW: An errata of RFC 3161 (RE: [ESI] Update of RFC 316 1 - Time St amping)

From: "Pope, Nick" <[email-masked]>
Date: Tue, 15 Sep 2009 12:33:15 +0100

Stefan and all,

I have submitted an errata on RFC 3161 through the errata web site regarding
use of application/timestamp-response instead of application/timestamp-reply
in section 3.4.

I understand that the procedures for obsolescing RFCs implies that
references to RFC 2459 are replaced by RFC 5280.  However, I have yet to
find something that explicitly says this.

Nick

> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: 07 September 2009 09:13
> To: Pope, Nick; Peter Sylvester
> Cc: [email-masked]'; [email-masked]'
> Subject: Re: [pkix] FW: An errata of RFC 3161 (RE: [ESI] Update of RFC 316
> 1 - Time St amping)
> 
> Nick,
> 
> On 09-09-06 12:19 PM, "Pope, Nick" <[email-masked]> wrote:
> 
> > What are the rules regarding what is an update which requires a new RFC
> > number and what is a new issue of an existing standard?  Is there a
> document
> > which describes the IETF practices in this respect?
> 
> For error handling there is the following document:
> http://www.rfc-editor.org/draft-rfc-editor-errata-process-02.txt
> 
> I don't know explicitly where it is stated that IETF does not make new RFC
> documents to update references in existing RFCs. It is just something I
> have
> noticed over the years, and something that would create a complete mess if
> we did.
> 
> Maybe Tim or Pasi could help out with a ref to the precise rules.
> 
> /Stefan

Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [email-masked].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited".

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 15 Sep 2009 14:34:06 +0200

Nick,

This were the comments by Pasi regarding this issue.

On 09-09-07 1:51 PM, "[email-masked]" <[email-masked]> wrote:

> About references pointing to obsoleted RFCs, I don't think there
> are definite rules here either -- we trust the reader to make
> a sensible choice. In some cases, that is to read the newer
> RFC (which might e.g. clarify some corner cases and do some
> minor fixes to the old RFC), in some cases it's not (e.g. the
> IKEv2 RFC obsoletes the IKEv1 RFCs, but they're totally different
> protocols -- if some old RFC required using IKEv1, that continues
> to require IKEv1).
> 
> Best regards, 
> Pasi

/Stefan