Just going back through messages to check on things and noticed a question for me...
On Thu, Sep 29, 2016 at 1:39 AM, Jim Schaad <[email protected]> wrote: > 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? > Not a problem anymore as this one is ahead of COSE now in the RFC editor queue. I see it was moved and that's just fine. Thanks, Kathleen > > > > > 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 > -- Best regards, Kathleen
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
