Changes are in https://github.com/cose-wg/cose-spec/pull/181
> -----Original Message----- > From: COSE [mailto:[email protected]] On Behalf Of Ben Campbell > Sent: Tuesday, September 27, 2016 8:40 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; draft- > [email protected] > Subject: [COSE] Ben Campbell's No Objection on draft-ietf-cose-msg-18: (with > COMMENT) > > Ben Campbell has entered the following ballot position for > draft-ietf-cose-msg-18: 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-msg/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A few minor comments: > > Substantive: > > -1.3, definition of "int": Is that really _unsigned_ or negative? Or is it a signed > integer than can be negative or non-negative? (contrasting with uint?) (Or is int > merely a parent of nint and uint?) Using the terminology of CDDL, this is really unsigned or negative. Specifically, it would be the union of uint (unsigned - 0 and above) and nint (negative integer strictly less than 0). Both of these types have different major types so they are coded differently. > > -3: What is the scope of uniqueness for map labels? I expected it to be the map, > but the text immediately aftewards suggests the scope may be the whole > message. Whatever the answer, it would help to be explicit. I kind of thought that it was sufficiently explicit. Does it work better for you if the first sentence reads: If a label is used in one of the maps, it MUST appear only once in that map and it MUST NOT appear in the other map. Then leave the rest of the text in the paragraph alone. > > - Informative References: [I-D.irtf-cfrg-eddsa]: Other algorithm references are > normative. Why not this one? I plead the 5th. It would be because I pasted it in the wrong place and missed the fact. I have been acting as if this was a normative reference. Kathleen, is there a problem if I just move this reference? > > Editorial: > > "Contributing to this Memo" section: Is this intended to stay in the final RFC? If > not, it might be worth a note to the RFC editor. The not already exists in the XML. > > -1, first paragraph, last sentence: Comma splice. Changed in response to the Gen-Art review already. > > -1, 2nd paragraph: MAC usually expands to Message Authentication _Code_. Yeah, Changed in response to the Gen-Art review already > > -2, 6th paragraph, last sentence: s/method/methods (assuming the following > list is a list of methods, and not steps in a method. Should be plural - changed > > -3, definition of protected: Did you lose some text at this point? > > -4.1, "COSE_Sign_Tagged = #6.991(COSE_Sign) ; Replace 991 with TBD1": Is the > comment intended as a note to the RFC editor? If so, it might be helpful to label > it as such. Added as a note to the XML > > -4.3, first bullet: "If multiple items are included, care needs to be taken that data > cannot bleed between the items." > Is this talking about data framing, or something else? That is probably not the term that I would use for this, but it is similar. The requirement is to make sure that data from one item is separated from another item so that when the hash string is constructed the same hash string cannot be constructed for two different pairs of items. Jim > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
