Subject: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-rfc7030est-clarify-10: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 12 Aug 2020 16:10:16 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-lamps-rfc7030est-clarify-10: 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-lamps-rfc7030est-clarify/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I, too, wonder why there’s a need to still cite RFC 2616 here.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Aug 2020 14:21:57 -0400

> I, too, wonder why there’s a need to still cite RFC 2616 here.

Yes, I agree it is weird.
Section 3.1 is why.

This is because the text in RFC7230/31 is much less clear about whether
CR/LF/spaces are allowed in base64.
My recollection was that the base64 text from 2616 is appropriately, just gone.

In order to avoid changes to bits on the wire, we need decoders to
be tolerant of whitespace in base64 blocks.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-