Hi again Shuping, On Fri, 3 Jan 2025 at 11:13, Thomas Fossati <thomas.fossati@xxxxxxxxxx> wrote: > > Hi Shuping, > > Thanks very much for the review. > > On Sat, 28 Dec 2024 at 10:03, Shuping Peng via Datatracker > <noreply@xxxxxxxx> wrote: > > > > Reviewer: Shuping Peng > > Review result: Ready with Issues > > > > I am the assigned ART-ART reviewer for this draft. > > > > Summary: > > > > I have some minor concerns about this document that I think should be resolved > > before publication. > > > > Comments: > > > > The 03 version has resolved the comments posted in the mailing list so far. The > > IANA description is much more clear, two use cases are added, and the Security > > considerations is significantly extended. > > > > Major Issues: > > > > "No major issues found." > > > > Minor Issues: > > > > 1. A COSE header parameter with two modes or two COSE header parameters for two > > modes? > > > > In the Abstract, it says "This document defines a CBOR Signing And Encrypted > > (COSE) header parameter for ...". In Section 1, it says "This document defines > > two new CBOR Object Signing and Encryption (COSE) [STD96] header parameters > > that ..." In Section 3, it says "The two modes described in ... To clearly > > separate their semantics two different COSE header parameters are defined as > > described in the following subsections." > > > > So is it about two COSE header parameters for two modes? Maybe simply changing > > the wording in the Abstract? > > > > 2. Section 2.1 > > To compare through 2.1, 2.2, 3.1, and 3.2, would it be more clear to move this > > following sentence to Section 3.1? "The message imprint sent to the TSA > > (Section 2.4 of [RFC3161]) MUST be the hash of the payload field of the COSE > > signed object." > > > > 3. Section 2.1, 3.2 > > To compare against RFC 3161 and the Figures, should "message imprint" be > > "messageImprint"? s/message imprint/messageImprint > > > > 4. Section 3.1 > > This following sentence could be moved to the end of this sub-section, to > > better align with the similar information in Section 3.2. "The 3161-ttc > > protected header parameter contains a DER-encoded RFC3161 TimeStampToken > > wrapped in a CBOR byte string (Major type 2)." > > > > Nits: > > 6. IANA Considerations > > In Table 1. > > s/"3161-tcc"/"3161-ttc" > > We have filed issues for your suggestions [1] and will work on them in > the next few days. We think all your comments have been addressed in the editor's copy [EC]. Please have a look and let us know if you are OK with the changes. cheers, thanks! [EC] https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-cose-tsa-tst-header-parameter&url_2=https://ietf-scitt.github.io/draft-birkholz-cose-tsa-tst-header-parameter/draft-ietf-cose-tsa-tst-header-parameter.txt -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
