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 15:29:52 +0100

If no one feels the same, and changing the RFC number used in time-stamp
server products has a cost, I accept to go the existing (untidy) route
unless others feel strongly otherwise.

Nick

> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: 15 September 2009 14:46
> To: Pope, Nick; Peter Sylvester
> Cc: [email-masked]'; [email-masked]'; [email-masked]
> Subject: Re: [pkix] FW: An errata of RFC 3161 (RE: [ESI] Update of RFC 316
> 1 - Time St amping)
> 
> Nick,
> 
> The main question is whether this is known to cause issues and problems
> for
> implementers. It is not a custom in the IETF to make an update just to
> incorporate erratas or to update references unless the present errors are
> severe, causing real problems.
> 
> I would suggest that you post a message to the PKIX list proposing to do a
> 3161bis update and your rationales for doing it. We can then have the
> discussion on the list prior to making a decision. Perhaps there are other
> things to fix as well.
> 
> /Stefan
> 
> 
> On 09-09-15 3:32 PM, "Pope, Nick" <[email-masked]> wrote:
> 
> > Stefan,
> >
> > Not exactly very easy for implementers to follow, especially with two
> > versions of RFC 3161 about (one with ESSCertV2) as well.
> >
> > I would suggest that we follow up with a Son of RFC 3161 that limits
> itself
> > with including errata and referencing latest RFCs.  NOT changing any of
> the
> > architectural concepts or the protocol.  How are similar changes handled
> > with keeping other RFCs up to date.
> >
> > Nick
> >
> >
> >> -----Original Message-----
> >> From: Stefan Santesson [mailto:[email-masked]]
> >> Sent: 15 September 2009 13:34
> >> To: Pope, Nick; Peter Sylvester
> >> Cc: [email-masked]'; [email-masked]';
> [email-masked]
> >> Subject: Re: [pkix] FW: An errata of RFC 3161 (RE: [ESI] Update of RFC
> 316
> >> 1 - Time St amping)
> >>
> >> 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
> >>
> >> On 09-09-15 1:33 PM, "Pope, Nick" <[email-masked]>
> wrote:
> >>
> >>> 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 postmaster@thales-
> >> esecurity.com.
> >>> 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".
> >

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".