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
