Thanks, Mahesh We did discuss your input in our weekly BRSKI meeting. The authors did submit an update to github, which i think resolves all your concerns below, see
https://raw.githubusercontent.com/anima-wg/anima-jws-voucher/main/anima-jws-voucher.txt Thst version should IMHO simply be pushed to datatracker as revision -10 and then hopefvully be able to pass your official AD review (see other email) quickly. Aka: as WG chair, i would like to see this pushed to datatracker. For detail answers, see below. Cheers Toerless On Tue, Feb 13, 2024 at 03:43:12PM -0500, Mahesh Jethanandani wrote: > Here are my comments on draft-ietf-anima-jws-voucher-09 draft. > > Overall the draft is short, and easy to understand. There are a few issues > categorized under Overall, Major, Minor, and Nits, in order of importance. > > Overall: > > Please resolve all the TODOs in the document. Done. > Major: > > None. > > Minor: > > - The document makes the following statement, but it is not clear the purpose > of the paragraph. Neither voucher data for CBOR or its signature format, COSE > is referenced or discussed in the document. The paragraph should be removed. > > [I-D.ietf-anima-constrained-voucher] provides a serialization of the voucher > data to CBOR [RFC8949] with the signature format of COSE [RFC8812] and the > media type "application/voucher-cose+cbor”. This explanatory text was improved and moved and hopefully meets your approval now. This is all explanatory text and does not impact the functionality/interoperability described basically the editorial challenge we have and solution we choose was how we should define our voucher wrt. to RFC8366/RFC8366bis. a "JWS Voucher" uses a different encoding than an RFC8366(bis) "CMS" Voucher and is hence incompatible with it in the sense of interoperability on the wire. But given how it is carrying the same "payload" (voucher) data, it is a voucher in the sense of the concept "voucher" introduced in RFC8366. Alas, i am drawing a blank right now for a good example of a prior IETF digital artefact technology that exists in different variations with these properties. So we did choose to call JWS voucher an "extension" of RFC8366bis and marked it as an update RFC8366 so that readers of RFC8366bis will be able to easily find JWS voucher - and pick it for their deployments if it fits better than a CMS voucher. But whether or not the terms "extension of RFC8366bis" and "update to RFC8366bis" are perfect matches with how others interpret extension/update - i don't know. And i guess the authors neither. Which is why we started putting "TODO" into the text for this type of editorial naming question. Which we now removed on your request. Just to make it easier: We put a stake in the ground, choose "extension" and "upgrade to" and let IESG/IETF review chime in if they don't like it. > - The term “Voucher Artifact” is referenced multiple times in the document, > sometimes with mixed capitalization. The terminology section has definition > for other terms, but not for "Voucher Artifact”. draft-ietf-anima-rfc8366bis, > which defines the term does not use any capitalization. Fixed. > - draft-kuehlewind-update-tag-04 has expired and archived. Do you want to > continue referencing it? Referring to that draft was just a ?feeble? attempt to find further evidence that "extension" and "upgrade to" are the appropriate editorial word choices to describe the situation. If i remember correctly, the draft also expired because Mirja could't figure out how to get a sufficient agreement in the community about the vocabulary, so thats why we're here - to make up the best wording as we go along ;-) Aka: reference removed. > Nit: > > Section 3.3 > > - Am I missing a “\” in backslashes(“). Looks like the backslash got eaten by > whatever was rendering the HTML. You might want to escape the backslash. > > - This sentence did not parse for me. > > "Note, a trust anchor SHOULD be provided differently to be trusted. This is > consistent with Section 5.5.2 of [BRSKI].” > > Did you mean to say “SHOULD be provided separately, for it to be trusted”? Fixed. Thanks a lot for the review. > > Thanks > > > Mahesh Jethanandani > [email protected] > > > > > > -- --- [email protected] _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
