Hi Peter, thanks very much for the thorough review. Nearly all of your suggestions have been incorporated [1]. The only thing left is to address your first "minor issue". See below for some considerations. Let us know if there is anything specific you would like to see included in the document.
cheers! [1] https://github.com/ietf-rats-wg/draft-ietf-rats-msg-wrap/pull/256 On Thu, 30 Oct 2025 at 06:28, Peter Yee via Datatracker <[email protected]> wrote: > [...] > Minor issues: > > Page 10, 6th paragraph: Is there some expectation of what happens when > a sending implementation allows more nesting depth than a receiving > implementation? This should be treated as a decoding failure. From an operational perspective, this should probably be logged as it could represent a security-relevant event. If the CMW collection is used in a protocol that provides detailed error messages, such as a RESTful API that uses RFC 9457/RFC 9290, the receiver could use that to inform the sender of the specific details of the problem. > Page 26, section 10.5, 4th paragraph: do indicator values need to be > in monotonically ascending order or are gaps fine? Good catch. The allocations should be strictly monotonically increasing without gaps. Done. > Nits/editorial comments: > > Page 1, Abstract, 1st paragraph, 1st sentence: since the use of > “(RFC9334)” is not a reference (which are not allowed in abstracts in > any case), then it should be written as “(RFC 9334”. (See RFC 7322, > section 3.5.) Thanks for the pointer. Done. > Page 1, Abstract, 1st paragraph, last sentence. The same correction > applies here as well. Ditto. > Page 7, ind definition, 2nd sentence: change “included” to > “inclusive”. Done. > Page 7, ind definition, 3rd sentence: change “values” to “bits”. There > are many more values than bits, as the previous sentence shows. Append > a comma after “so”. Delete the comma after “ambiguous”. Done. > Page 11, section 4, 1st sentence: append a comma after “integrity”. Done. > Page 12, section 4.1, sentence after “signed-cbor-cmw” layout: append > a comma after “Record”. Done (also, similarly in §4.2) > Page 16, section 5.2, paragraph after the wire registration: change > “registrered” to “registered”. Done > Page 19, section 6: at least one sentence explaining what this section > is wouldn’t be a bad thing. Done. > Page 23, section 9.1, 1st paragraph, 1st sentence: append a comma > after “Tags”. Done. > Page 28, section 10.5.2, 2nd paragraph: append “prior to publication > of this specification as an RFC” after “regularly updated” to make it > clearer what’s going on here. The 3rd paragraph helps that > understanding, but reading the 2nd paragraph in order might leave the > reader confused as to what’s going on here. Done. > Another thought is to mark section 10.5.2 as to be deleted by the RFC > Editor on publication as it is almost completely irrelevant after > that. Good catch, thanks. Done. _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
