Sure, that's fine On Wed, Sep 4, 2024 at 8:07 AM Sean Turner <s...@sn3rd.com> 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...@rtfm.com> 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 < > rvanrhee...@amsl.com> 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 < > rfc-edi...@rfc-editor.org> 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 <kamil.milew...@plum.pl> > > > > > > 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 -- tls@ietf.org > > To unsubscribe send an email to tls-le...@ietf.org > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
