Re: [COSE] Ben Campbell's No Objection on draft-ietf-cose-msg-18: (with COMMENT)

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 <ietf@augustcellars.com> wrote:

> Changes are in https://github.com/cose-wg/cose-spec/pull/181
>
>
>
> > -----Original Message-----
> > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Ben Campbell
> > Sent: Tuesday, September 27, 2016 8:40 PM
> > To: The IESG <iesg@ietf.org>
> > Cc: cose-chairs@ietf.org; goran.selander@ericsson.com; cose@ietf.org;
> draft-
> > ietf-cose-msg@ietf.org
> > 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
> > COSE@ietf.org
> > https://www.ietf.org/mailman/listinfo/cose
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>

-- 

Best regards,
Kathleen