[TLS] Re: [TLS]Re: [Editorial Errata Reported] RFC6347 (8089)

[Eric Rescorla <[e-mail]>]

Sure, that's fine

On Wed, Sep 4, 2024 at 8:07 AM Sean Turner <[e-mail]> wrote:

> Since this is correctly marked as “Editorial” are there any objections to
> changing the state to “Hold For Document Update”?
>
> spt
>
> > On Aug 23, 2024, at 18:18, Eric Rescorla <[e-mail]> wrote:
> >
> > I don't think this is an erratum. I agree it would be better, but I
> don't think that rises to "error".
> >
> > -Ekr
> >
> >
> > On Fri, Aug 23, 2024 at 11:17 AM Rebecca VanRheenen <
> [e-mail]> wrote:
> > Hi Paul,
> >
> > We are unable to verify this erratum that the submitter marked as
> editorial, so we changed the Type to “Technical”. As Stream Approver,
> please review and set the Status and Type accordingly (see the definitions
> at https://www.rfc-editor.org/errata-definitions/)
> >
> > Notes:
> > * RFC 6347 has been obsoleted by RFC 9147. We see similar blocks of code
> in Section 5.2 and Appendix A.2 of RFC 9147.
> > * For information about errata on obsolete RFCs, see #7 in the IESG
> Statement on "IESG Processing of RFC Errata for the IETF Stream” (
> https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/
> ).
> >
> > You may review the report at:
> > https://www.rfc-editor.org/errata/eid8089
> >
> > Information on how to verify errata reports can be found at:
> > https://www.rfc-editor.org/how-to-verify/
> >
> > Further information on errata can be found at:
> > https://www.rfc-editor.org/errata.php
> >
> > Best regards,
> > RFC Editor/rv
> >
> >
> > > On Aug 23, 2024, at 6:26 AM, RFC Errata System <
> [e-mail]> wrote:
> > >
> > > The following errata report has been submitted for RFC6347,
> > > "Datagram Transport Layer Security Version 1.2".
> > >
> > > --------------------------------------
> > > You may review the report below and at:
> > > https://www.rfc-editor.org/errata/eid8089
> > >
> > > --------------------------------------
> > > Type: Editorial
> > > Reported by: Kamil Milewski <[e-mail]>
> > >
> > > Section: 4.2.2
> > >
> > > Original Text
> > > -------------
> > >   struct {
> > >     HandshakeType msg_type;
> > >     uint24 length;
> > >     uint16 message_seq;                               // New field
> > >     uint24 fragment_offset;                           // New field
> > >     uint24 fragment_length;                           // New field
> > >     select (HandshakeType) {
> > >       case hello_request: HelloRequest;
> > >       case client_hello:  ClientHello;
> > >       case hello_verify_request: HelloVerifyRequest;  // New type
> > >       case server_hello:  ServerHello;
> > >       case certificate:Certificate;
> > >       case server_key_exchange: ServerKeyExchange;
> > >       case certificate_request: CertificateRequest;
> > >       case server_hello_done:ServerHelloDone;
> > >       case certificate_verify:  CertificateVerify;
> > >       case client_key_exchange: ClientKeyExchange;
> > >       case finished: Finished;
> > >     } body;
> > >   } Handshake;
> > >
> > > Corrected Text
> > > --------------
> > >   struct {
> > >     HandshakeType msg_type;
> > >     uint24 length;
> > >     uint16 message_seq;                               // New field
> > >     uint24 fragment_offset;                           // New field
> > >     uint24 fragment_length;                           // New field
> > >     select (HandshakeType) {
> > >       case hello_request: HelloRequest;
> > >       case client_hello:  ClientHello;
> > >       case server_hello:  ServerHello;
> > >       case hello_verify_request: HelloVerifyRequest;  // New field
> > >       case certificate:Certificate;
> > >       case server_key_exchange: ServerKeyExchange;
> > >       case certificate_request: CertificateRequest;
> > >       case server_hello_done:ServerHelloDone;
> > >       case certificate_verify:  CertificateVerify;
> > >       case client_key_exchange: ClientKeyExchange;
> > >       case finished: Finished;
> > >     } body; } Handshake;
> > >
> > > Notes
> > > -----
> > > Change the order of cases inside select field to keep it:
> > > 1. In ascending order
> > > 2. Consistent with the structure in 4.3.2
> > >
> > > Instructions:
> > > -------------
> > > This erratum is currently posted as "Reported". (If it is spam, it
> > > will be removed shortly by the RFC Production Center.) Please
> > > use "Reply All" to discuss whether it should be verified or
> > > rejected. When a decision is reached, the verifying party
> > > will log in to change the status and edit the report, if necessary.
> > >
> > > --------------------------------------
> > > RFC6347 (draft-ietf-tls-rfc4347-bis-06)
> > > --------------------------------------
> > > Title               : Datagram Transport Layer Security Version 1.2
> > > Publication Date    : January 2012
> > > Author(s)           : E. Rescorla, N. Modadugu
> > > Category            : PROPOSED STANDARD
> > > Source              : Transport Layer Security
> > > Stream              : IETF
> > > Verifying Party     : IESG
> > >
> >
> > _______________________________________________
> > TLS mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
>