Why is the type editorial? According to [1], an editorial errata is "a spelling, grammar, punctuation, or syntax error that does not affect the technical meaning". Although the mistake in RFC4492 is clearly a typo, I think it does affect the technical meaning. So I would prefer to leave the type as technical.
[1] https://www.rfc-editor.org/errata-definitions/ Best, Xiaoyin ________________________________ From: TLS <tls-boun...@ietf.org> on behalf of Sean Turner <s...@sn3rd.com> Sent: Tuesday, August 23, 2016 9:19 PM To: <tls@ietf.org> Cc: he...@florent-tatard.fr; sean+i...@sn3rd.com; b...@openssl.org; Kathleen Moriarty; ch...@corriente.net; nel...@bolyard.com; vipul.gu...@sun.com Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) This looks correct, but I'd change the "type" to editorial. Unless anybody disagrees with by next Monday, I'll ask Stephen to accept this. I've also submitted an issue in the 4492bis github repo to get this fixed in the new draft. I'd submit a PR, but I'm still digging out from being absent last week. spt > On Aug 19, 2016, at 13:13, RFC Errata System <rfc-edi...@rfc-editor.org> > wrote: > > The following errata report has been submitted for RFC4492, > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security > (TLS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4492&eid=4783 > > -------------------------------------- > Type: Technical > Reported by: Florent Tatard <he...@florent-tatard.fr> > > Section: 5.7 > > Original Text > ------------- > Actions of the sender: > > The client selects an ephemeral ECDH public key corresponding to the > parameters it received from the server according to the ECKAS-DH1 > scheme from IEEE 1363 [6]. It conveys this information to the client > in the ClientKeyExchange message using the format defined above. > > Corrected Text > -------------- > Actions of the sender: > > The client selects an ephemeral ECDH public key corresponding to the > parameters it received from the server according to the ECKAS-DH1 > scheme from IEEE 1363 [6]. It conveys this information to the server > in the ClientKeyExchange message using the format defined above. > > Notes > ----- > The client conveys data to the server, not itself. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4492 (draft-ietf-tls-ecc-12) > -------------------------------------- > Title : Elliptic Curve Cryptography (ECC) Cipher Suites for > Transport Layer Security (TLS) > Publication Date : May 2006 > Author(s) : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. > Moeller > Category : INFORMATIONAL > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls