Subject: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Wed, 10 Jun 2020 11:05:25 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-cose-rfc8152bis-struct-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-cose-rfc8152bis-struct/

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

I've only reviewed the diffs, not the historical approved text.  Everything
looks okay to me.  A few minor comments/nits:

Comment:

1.4.  CBOR Grammar

  The CDDL grammar is informational; the prose description is normative.

I'm not familiar with the CDDL grammar, and specifically whether there is any
tooling that can use the grammar to generate structures/etc.  If there is, then
I think that it would be helpful if the CDDL grammar was also normative, in the
sense that readers of the spec should be able to assume that the CDDL is
correct.  I would still be okay with a statement that says that if there is any
ambiguity between the two then the prose description should be taken as being
definitive.

Nits:

1.5.  CBOR-Related Terminology

  The presence in a CBOR map of a label that is not a text string or an integer
  is an error.

This sentence was changed from the original formulation, but I find it slightly
clunky.  Perhaps:

The presence of a label, that is neither a text string nor an integer, in a
CBOR map, is an error.

9.  Taxonomy of Algorithms used by COSE

   In this section, a taxonomy of the different algorithm types that can
   be used in COSE is laid out.  This taxonomy should not be considered
   to be exhaustive.  New algorithms will be created which will not fit
   into this taxonomy.  If this occurs, then new documents addressing
   this new algorithms are going to be needed.

Nit, this -> these

Regards,
Rob

---

From: Jim Schaad <[email-masked]>
Date: Sun, 14 Jun 2020 15:09:49 -0700

-----Original Message-----
From: Robert Wilton via Datatracker <[email-masked]> 
Sent: Wednesday, June 10, 2020 11:05 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Matthew Miller <[email-masked]>; [email-masked]
Subject: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT)

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.)

I've only reviewed the diffs, not the historical approved text.  Everything looks okay to me.  A few minor comments/nits:

Comment:

1.4.  CBOR Grammar

I'm not familiar with the CDDL grammar, and specifically whether there is any tooling that can use the grammar to generate structures/etc.  If there is, then I think that it would be helpful if the CDDL grammar was also normative, in the sense that readers of the spec should be able to assume that the CDDL is correct.  I would still be okay with a statement that says that if there is any ambiguity between the two then the prose description should be taken as being definitive.
[JLS] I am not aware of any tools today that can be used to generate code form CDDL although I believe it is only a matter of time until they exist.  The current tools allow one to validate that a CBOR encoded object does or does not match the CDDL.  I have used these tools to do validation, but since I have not used tools for generation I am not sure what to do.  It is my firm belief that the text and the CDDL are both the same.  The reason that the CDDL is not normative is not because of this, but because I am not willing yet to have a normative dependency on the CDDL document.

Nits:

This sentence was changed from the original formulation, but I find it slightly clunky.  Perhaps:

The presence of a label, that is neither a text string nor an integer, in a CBOR map, is an error.
[JLS] done

Nit, this -> these
[JLS] I just deleted the sentence for Ben so this is moot.

Regards,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 15 Jun 2020 09:11:00 +0000

Hi Jim,

Please see inline ...

> From: Jim Schaad <[email-masked]>
> Sent: 14 June 2020 23:10
> To: Rob Wilton (rwilton) <[email-masked]>; 'The IESG' <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; 'Matthew Miller' <[email-masked]>
> Subject: RE: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-
> struct-10: (with COMMENT)
> 
> 
> 
> Cc: [email-masked]; [email-masked];
> [email-masked]; Matthew Miller <[email-masked]>;
> [email-masked]
> I've only reviewed the diffs, not the historical approved text.
> Everything looks okay to me.  A few minor comments/nits:
> 
> Comment:
> 
> 1.4.  CBOR Grammar
> 
> I'm not familiar with the CDDL grammar, and specifically whether there is
> any tooling that can use the grammar to generate structures/etc.  If there
> is, then I think that it would be helpful if the CDDL grammar was also
> normative, in the sense that readers of the spec should be able to assume
> that the CDDL is correct.  I would still be okay with a statement that
> says that if there is any ambiguity between the two then the prose
> description should be taken as being definitive.
> [JLS] I am not aware of any tools today that can be used to generate code
> form CDDL although I believe it is only a matter of time until they exist.
> The current tools allow one to validate that a CBOR encoded object does or
> does not match the CDDL.  I have used these tools to do validation, but
> since I have not used tools for generation I am not sure what to do.  It
> is my firm belief that the text and the CDDL are both the same.  The
> reason that the CDDL is not normative is not because of this, but because
> I am not willing yet to have a normative dependency on the CDDL document.
[RW] 

You need a normative reference on the CDDL document regardless, given that it is not possible to understand the entirety of draft-ietf-cose-rfc8152bis-struct without reading the CDDL draft, hence it is a normative reference.  The only alternative would be to strip all the CDDL text out of the document, and I really doubt that you would want to do that.

Even if tools are just being used for validation then you still require the CDDL to be right or otherwise the validation could give an incorrect response.

Hence, I would recommend that you bite the bullet, add the normative reference, and make the CDDL text normative.  Given that CDDL has already been published as an RFC, I'm unsure why having a normative reference to it would be a problem.

Regards,
Rob

---

From: Jim Schaad <[email-masked]>
Date: Mon, 15 Jun 2020 09:47:02 -0700

-----Original Message-----
From: Rob Wilton (rwilton) <[email-masked]> 
Sent: Monday, June 15, 2020 2:11 AM
To: Jim Schaad <[email-masked]>; 'The IESG' <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; 'Matthew Miller' <[email-masked]>; Benjamin Kaduk <[email-masked]>
Subject: RE: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT)

Hi Jim,

Please see inline ...

> 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
> I'm not familiar with the CDDL grammar, and specifically whether there 
> is any tooling that can use the grammar to generate structures/etc.  
> If there is, then I think that it would be helpful if the CDDL grammar 
> was also normative, in the sense that readers of the spec should be 
> able to assume that the CDDL is correct.  I would still be okay with a 
> statement that says that if there is any ambiguity between the two 
> then the prose description should be taken as being definitive.
> [JLS] I am not aware of any tools today that can be used to generate 
> code form CDDL although I believe it is only a matter of time until they exist.
> The current tools allow one to validate that a CBOR encoded object 
> does or does not match the CDDL.  I have used these tools to do 
> validation, but since I have not used tools for generation I am not 
> sure what to do.  It is my firm belief that the text and the CDDL are 
> both the same.  The reason that the CDDL is not normative is not 
> because of this, but because I am not willing yet to have a normative dependency on the CDDL document.
[RW] 

[JLS] Section 1.4 is designed to avoid the need for CDDL to be normative.  Also since the CDDL is explicitly normative I do not believe that it needs to be normative.

I am still under the impression that one needs to look very closely at STD downrefs as well as Standards Track downrefs is that not true?

Jim

Regards,
Rob

---

From: Barry Leiba <[email-masked]>
Date: Mon, 15 Jun 2020 13:11:08 -0400

>> You need a normative reference on the CDDL document regardless, given
>> that it is not possible to understand the entirety of
>> draft-ietf-cose-rfc8152bis-struct without reading the CDDL draft,
>> hence it is a normative reference.  The only alternative would be to
>> strip all the CDDL text out of the document, and I really doubt that
>> you would want to do that.
>>
>> Even if tools are just being used for validation then you still
>> require the CDDL to be right or otherwise the validation could give an
>> incorrect response.
>>
>> Hence, I would recommend that you bite the bullet, add the normative
>> reference, and make the CDDL text normative.  Given that CDDL has
>> already been published as an RFC, I'm unsure why having a normative
>> reference to it would be a problem.
>
> [JLS] Section 1.4 is designed to avoid the need for CDDL to be
> normative.  Also since the CDDL is explicitly normative I do not
> believe that it needs to be normative.

I can't figure this out, Jim.  Is there a "not" missing, or some such?

In any case, I agree that the CDDL reference can be informative.  8152
predated the CDDL spec and was understandable with only an informative
reference to it, and I don't think 8152bis has changed in that regard.

> I am still under the impression that one needs to look very closely at
> STD downrefs as well as Standards Track downrefs is that not true?

An Internet Standard that cites a Proposed Standard normatively is
making a downref, if that's what you're asking.  That said, it's not a
big problem to accept that -- we would just have to run another
two-week last call to approve the downref.  But, as I said above, I
don't think that's necessary.

Rob, can you give specific examples of things in 8152bis that can't be
properly understood without normative reference to RFC 8610?

Barry

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 15 Jun 2020 19:22:13 +0000

> From: Barry Leiba <[email-masked]>
> Sent: 15 June 2020 18:11
> To: Jim Schaad <[email-masked]>
> Cc: Rob Wilton (rwilton) <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked]; Matthew
> Miller <[email-masked]>; Benjamin Kaduk <[email-masked]>;
> [email-masked]
> Subject: Re: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-
[RW] 

I suspect that Jim probably meant "CDDL is explicitly informative ...", but that doesn’t matter.  I.e. just because the text is informative doesn’t make references to explain it informative (if required).

Barry, we should try and complete the updated text for explaining normative vs informative references ...

[RW] 

Actually, having looked at the draft again, I agree.  I hadn't realized that this document aims to describe/document enough of the CDDL syntax that it doesn't require a normative reference.

[RW] 

I've checked again, no I can't.  Informative is fine.

Regards,
Rob