For the transport ADs, who both noticed the same typo: https://github.com/tlswg/tls-record-limit/commit/e36a69777ee5661c33a421d64bb48bb68c7680b9 (I think that it might have been "any", but "a" is equally good and also fewer characters)
On Tue, Apr 3, 2018 at 12:52 PM, Spencer Dawkins <spencerdawkins.i...@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-tls-record-limit-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This is a nit, but just to make sure … > > The "record_size_limit" extension replaces the "max_fragment_length" > extension [RFC6066]. A server that supports the "record_size_limit" > extension MUST ignore and "max_fragment_length" that appears in a > ^^^ > the "and" should be "any", shouldn't it? > > ClientHello if both extensions appear. A client MUST treat receipt > of both "max_fragment_length" and "record_size_limit" as a fatal > error, and SHOULD generate an "illegal_parameter" alert. > > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
