Subject: [Cbor] Roman Danyliw's No Objection on draft-ietf-cbor-7049bis-14: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 08 Sep 2020 14:55:24 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-cbor-7049bis-14: 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-cbor-7049bis/

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

I support Ben Kaduk’s DISCUSS position.

** Section 1.0. Is it possible to enumerate the fixed errata?

** Section 3.4.5.3.  For Tag 35, how does one know if the syntax is a PCRE or
ECMA regular expression?

** Section 3.4.5.3.  PCRE is the only informative reference of all of the tags
defined in this section (even ECMA is normative).  Please make it normative.

** Section 4.1.  As an implementer of an application, what is the take away
from this section?  I’m not following on the definition of “preferred”.

** Section 10.  Per “The input check itself may consume resources.  This is
usually linear in the size of the input, which means that an attacker has to
spend resources that are commensurate to the resources spent by the defender on
input validation.”  I’m not sure this is true for all types of resources.  For
example, with compute resources, as an attacker I can craft an input that will
take longer for the target to process then for me to produce.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Sep 2020 19:30:16 +0000

Thanks for your comments. Our notes are below.

--Paul Hoffman

We have dealt with that in a different thread.

> ** Section 1.0. Is it possible to enumerate the fixed errata?

It is possible, but does not seem important. They were issues in some examples.

> ** Section 3.4.5.3.  For Tag 35, how does one know if the syntax is a PCRE or

Fixed earlier in response to Ben.

> defined in this section (even ECMA is normative).  Please make it normative.

Fixed earlier in response to Ben.

> from this section?  I’m not following on the definition of “preferred”.

This section is signifying is that each application needs to specify which
serialization is being used for values with multiple serializations (such as
integer and bigint for the number "forty two"). It is not talking about a
universal preference, but one that each implementer needs to specify for their
particular application.

> take longer for the target to process then for me to produce.

Good catch. We added text covering that.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Sep 2020 15:26:18 +0200

> It is possible, but does not seem important. They were issues in some examples.

Rereading this comment, it now appears to me that it is asking for what is Appendix G.1:

https://www.ietf.org/id/draft-ietf-cbor-7049bis-15.html#name-errata-processing-clerical-

(I don’t think there is a need to reference that from Section 1 — anyone searching for “errata” will find Appendix G.1.)

Grüße, Carsten

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 30 Sep 2020 13:49:11 +0000

Hi Carsten!

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Carsten Bormann
> Sent: Wednesday, September 30, 2020 9:26 AM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]; The IESG <[email-masked]>
> Subject: Re: [Cbor] [Ext] Roman Danyliw's No Objection on draft-ietf-cbor-
> 7049bis-14: (with COMMENT)
> 
> (I don’t think there is a need to reference that from Section 1 — anyone
> searching for “errata” will find Appendix G.1.)

When I wrote that comment I hadn't read Appendix G (70-something pages later) yet.  When deduplicating my comments for my final ballot text, I didn't notice the discrepancy.  The intent of my feedback was to signal the utility of having the addressed errata enumerated somewhere.  Appendix G works for me as much as Section 1.  I concur with you.  Nothing needs to be done.

Regards,
Roman