Carl's in depth review

[thomas-fossati]

See https://mailarchive.ietf.org/arch/msg/rats/Bmlxnu0GmnRMsP6WEq3CBjLVm0k/

[thomas-fossati]

Below are some suggestions/questions regarding the RATS Conceptual Messages Wrapper draft (draft-ftbs-rats-msg-wrap-00).

Abstract

• Should the spec have a broader title/focus since there appears to be nothing to limit usage to RATS conceptual messages?

While the mechanism is generic -- at least in part, now that we added the CM indicator to the array serialisation -- we want to keep the scope limited to RATS messages.

• How does this draft relate to the EAT Media Types draft? That draft states that is "defines media types to be used for Entity Attestation Token (EAT) payloads independently of the RATS Conceptual Message in which they manifest themselves." Does this mean a separate media-type would be used with the encapsulation mechanisms defined in this draft?

This encap is intended for tunnelling RATS messages in protocols that don't use media types as first class type identifiers themselves. The relation of this spec with the EAT media type I-D is one of "consumer": if EAT MT has a type that is good for the message, we can use it.

Section 1

• In the first sentence of the second paragraph, what is being registered or used interoperably? This would clarify what "their" means in the second sentence. I think the media type notion might need to be introduced before this paragraph.

In #22, I hope I have explained a bit better the basic reason for providing a single encap, and what registrations we are amortising.

Section 3.1

• Is there any reason to not use .det with indentation of the RFC6838 definition? I think that'd be easier to read.

To improve readability this has now been separated into its own section.

Section 3.2

• What if a CoAP Content Format does not exist for the media type? I am assuming a media-type value is used, but it may be worth stating that.

Done in #23

• Are tag definitions intended to adhere to the same limitations defined for the value field in the array, i.e., cbor-bytes / base64-string serialized per the tag number? If not, what would govern the type?

This is stated in §3.2: "[...] encoded as a CBOR byte string, to which the tag is prepended."

Section 4

• I think it would be helpful to include ASCII hex of the CBOR encodings in addition to the diagnostic (i.e., 8219753144ABCDABCD and DA6374763244ABCDABCD).

Agreed; we have added the CBOR "pretty" output to the examples.

• It may be worth including a CBOR example with a media-type value. This could possibly be as a second hypothetical for which no CoAP content format has been defined or as an example with parameters of the same type as current example.

Done in #23

• It may be worth showing the CDDL definition of the resulting tag as it may appear in some protocol definition, i.e.. example_tag = #6.1668576818(bstr).

We have now used a brand new CDDL feature ("non-literal CBOR tag numbers") in §3.2 to do that in a generic way.

[thomas-fossati]

hi Carl, we think we addressed all your points. See https://thomas-fossati.github.io/draft-ftbs-rats-msg-wrap/draft-ftbs-rats-msg-wrap.html

Could you please check when you have some spare time?

/cc @carl-wallace

[carl-wallace]

Yep. Thanks. A few nits/comments: - In third sentence of first paragraph in section 1, “RATS conceptual message” should be plural. - In the cm-type definition, attestation-result should probably be plural. - In the first sentence of section 3.2, "may be derived from CoAP Content-Format numbers" may be more accurate given section 3.2.1's allowance for other registered tags. - I wonder if including <coap-cf-tag-number> in the definition of cmw-cbor-tag<bytes> is right given other values can be used. Maybe #6.<uint>(bytes) for the definition with coap-cf-tag-number defining the range where a registered tag is not in use? I'm not sure if it's better to have a definition like #6.<cmw-cbor-tag> that does not cover the range of what is acceptable or something overly broad like #6.<uint> (or if I am just missing something here). - Should the lookahead for CBORTag be bounded on 0xdb instead of 0xdf? The jump table in RFC 8949 has 0xdb as highest value.

[thomas-fossati]

Yep. Thanks.

Cool, thanks for checking (and for the further comments).

A few nits/comments: [...]

done in #30

[thomas-fossati]

Carl's original review was addressed in #22 and #23.

The follow-up re-review (#15 (comment)) has been addressed in #30