Subject: Re: [Cbor] 🔔 WGLC on draft-ietf-cbor-tags-oid-02

From: Henk Birkholz <[email-masked]>
Date: Fri, 15 Jan 2021 13:40:20 +0100

Hi chairs,
hi CBOR WG,

I am so sorry that I missed to reply to this call. In fact, it is 
essential to improve existing work on large component manifests 
represented in CBOR.

I've read the I-D and am in strong favor of progressing of progressing 
this work.

Viele Grüße,

Henk

On 15.12.20 23:37, Francesca Palombini wrote:
> Hi all,
> 
> The WGLC has officially ended, but I'd appreciate a couple more eyes on this, so if you have the time, please take a look. Also, here is my shepherd review. There is one point where I'd like to get the authors and the WG's opinion, see the first point below.
> 
> * I am not sure (and please correct me if I am wrong!) there ever was a conclusion to Jim's comment about not seeing the necessity of going below one layer for maps and arrays: https://mailarchive.ietf.org/arch/msg/cbor/5lj35zvO85Yu2tVO_Fw__KWLadc/  - this was discussed at an interim: https://datatracker.ietf.org/meeting/interim-2020-cbor-14/materials/minutes-interim-2020-cbor-14-202009021700-00.txt  And I see the text Jim referred to was clarified, but as shepherd I'd like to see more opinions on this point: anybody else seeing a problem with Carsten's point of "if you don't need all bstr tagged, don't use the tag on the map/array" ? Anybody agrees with Jim and would rather this being a 1-level tag?
> 
> * Update references to RFC 8949
> 
> * normative references X.660, X.680 and X.690 are missing links
> 
> * add a reference to IANA PEN registry
> 
> "the first byte of each SDNV cannot be 0x80 (which would be a
>     leading zero in SDNV's base-128 arithmetic)."
> 
> "this requirement requires
>        expressing the integer values in their shortest form, with no
>        leading zeroes"
> 
> * I would suggest reversing this sentence: "the first byte cannot be a leading zero in SDNV's base-128 arithmetic, so it cannot take value 0x80", possibly mentioning the requirement on the integer values being expressed in their shortest form. By the way, does this requirement comes from BER OID rules? Can you add some reference to where this is specified?
> 
> "except for the last byte, where it must be
>     unset"
> 
> * either replace "must" with "is" or with "MUST" (I would suggest is, because the normative MUST before covers the requirement already)
> 
> "its first byte" and "its last byte"
> 
> * I would replace "its" by "the tag's" for clarity.
> 
> * It seems to me that this document could benefit from a more expanded terminology section. In particular, I would quickly summarize the terms used from X.690 - e.g. arc - and SDNV.
> 
> * Some introductory text for the examples in Section 3 would have been good.
> 
> * I am a bit unsure about the reasoning behind section 4 "Discussion". Is this not background? Then in my opinion it would fit better in section 2.
> 
> * I would have merged section 3 and 6 in one section "Examples"
> 
> 
> Francesca
> 
> On 29/10/2020, 10:57, "CBOR on behalf of Francesca Palombini" <[email-masked] on behalf of francesca.palombini=[email-masked]> wrote:
> 
>      CBOR wg,
> 
>      This starts a two weeks WG last call on https://tools.ietf.org/html/draft-ietf-cbor-tags-oid-02 , ending on *Thursday, 12th November*.
> 
>      Please send inputs to the mailing list that you have read the document and do or do not feel it is ready to progress, along with any issues that you believe need to be dealt with.
> 
>      We will discuss any open issues we’ve gotten during our WG meeting at IETF109 scheduled for Thursday, 19 November.
> 
>      CBOR Chair
>      Francesca
> 
>      On 28/10/2020, 18:44, "CBOR on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:
> 
> 
>          A New Internet-Draft is available from the on-line Internet-Drafts directories.
>          This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF.
> 
>                  Title           : Concise Binary Object Representation (CBOR) Tags for Object Identifiers
>                  Authors         : Carsten Bormann
>                                    Sean Leonard
>          	Filename        : draft-ietf-cbor-tags-oid-02.txt
>          	Pages           : 14
>          	Date            : 2020-10-28
> 
>          Abstract:
>             The Concise Binary Object Representation (CBOR, draft-ietf-cbor-
>             7049bis) is a data format whose design goals include the possibility
>             of extremely small code size, fairly small message size, and
>             extensibility without the need for version negotiation.
> 
>             The present document defines CBOR tags for object identifiers (OIDs).
>             It is intended as the reference document for the IANA registration of
>             the CBOR tags so defined.
> 
> 
>          The IETF datatracker status page for this draft is:
>          https://datatracker.ietf.org/doc/draft-ietf-cbor-tags-oid/
> 
>          There is also an HTML version available at:
>          https://www.ietf.org/archive/id/draft-ietf-cbor-tags-oid-02.html
> 
>          A diff from the previous version is available at:
>          https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-tags-oid-02
> 
> 
>          Please note that it may take a couple of minutes from the time of submission
>          until the htmlized version and diff are available at tools.ietf.org.
> 
>          Internet-Drafts are also available by anonymous FTP at:
>          ftp://ftp.ietf.org/internet-drafts/
> 
> 
>          _______________________________________________
>          CBOR mailing list
>          [email-masked]
>          https://www.ietf.org/mailman/listinfo/cbor
> 
>      _______________________________________________
>      CBOR mailing list
>      [email-masked]
>      https://www.ietf.org/mailman/listinfo/cbor
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 15 Jan 2021 08:50:29 -0500

Hi,

Like Henk, I've been overwhelmed in the last month and missed this one.

I strongly agree that this document is ready to send for IETF Last Call.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Fri, Jan 15, 2021 at 7:40 AM Henk Birkholz <
[email-masked]> wrote:

> > The WGLC has officially ended, but I'd appreciate a couple more eyes on
> this, so if you have the time, please take a look. Also, here is my
> shepherd review. There is one point where I'd like to get the authors and
> the WG's opinion, see the first point below.
> >
> > * I am not sure (and please correct me if I am wrong!) there ever was a
> conclusion to Jim's comment about not seeing the necessity of going below
> one layer for maps and arrays:
> https://mailarchive.ietf.org/arch/msg/cbor/5lj35zvO85Yu2tVO_Fw__KWLadc/
> - this was discussed at an interim:
> https://datatracker.ietf.org/meeting/interim-2020-cbor-14/materials/minutes-interim-2020-cbor-14-202009021700-00.txt
> And I see the text Jim referred to was clarified, but as shepherd I'd like
> to see more opinions on this point: anybody else seeing a problem with
> Carsten's point of "if you don't need all bstr tagged, don't use the tag on
> the map/array" ? Anybody agrees with Jim and would rather this being a
> 1-level tag?
> >
> > * I would suggest reversing this sentence: "the first byte cannot be a
> leading zero in SDNV's base-128 arithmetic, so it cannot take value 0x80",
> possibly mentioning the requirement on the integer values being expressed
> in their shortest form. By the way, does this requirement comes from BER
> OID rules? Can you add some reference to where this is specified?
> >
> > * either replace "must" with "is" or with "MUST" (I would suggest is,
> because the normative MUST before covers the requirement already)
> >
> > * It seems to me that this document could benefit from a more expanded
> terminology section. In particular, I would quickly summarize the terms
> used from X.690 - e.g. arc - and SDNV.
> >
> > * I am a bit unsure about the reasoning behind section 4 "Discussion".
> Is this not background? Then in my opinion it would fit better in section 2.
> >
> > On 29/10/2020, 10:57, "CBOR on behalf of Francesca Palombini" <
> [email-masked] on behalf of francesca.palombini=
> [email-masked]> wrote:
> >
> >      CBOR wg,
> >
> >      This starts a two weeks WG last call on
> https://tools.ietf.org/html/draft-ietf-cbor-tags-oid-02 , ending on
> *Thursday, 12th November*.
> >
> >      Please send inputs to the mailing list that you have read the
> document and do or do not feel it is ready to progress, along with any
> issues that you believe need to be dealt with.
> >
> >      We will discuss any open issues we’ve gotten during our WG meeting
> at IETF109 scheduled for Thursday, 19 November.
> >
> >      CBOR Chair
> >      Francesca
> >
> >      On 28/10/2020, 18:44, "CBOR on behalf of [email-masked]"
> <[email-masked] on behalf of [email-masked]> wrote:
> >
> >
> >          This draft is a work item of the Concise Binary Object
> Representation Maintenance and Extensions WG of the IETF.
> >

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 15 Jan 2021 19:22:11 +0100

Hello tags-oid authors, hello CBOR group,

with the recently arrived positive feedback from Henk and Ira, this WGLC
can be concluded positively.

Authors, we wait for your submission to move forward; as soon as that's
in, the document can continue through the shepherd write-up and out of
the working group.

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 15 Jan 2021 22:07:02 +0100

Hi Francesca,

thank you for this review. 

> * I am not sure (and please correct me if I am wrong!) there ever was a conclusion to Jim's comment about not seeing the necessity of going below one layer for maps and arrays: https://mailarchive.…

I haven’t seen support for this, so I consider this a wontfix.

> * Update references to RFC 8949

Done.

(Note that we have a downref to RFC 6256 SDNV; I wonder why that isn’t in the downref list https://datatracker.ietf.org/doc/downref/ .)

> * normative references X.660, X.680 and X.690 are missing links

Ugh.  
I didn’t want to innovate here, but RFC 8951 has (inconsistent) ones to X.68x (why is the X.680 one different from the others?).

I went with:
https://www.itu.int/rec/T-REC-X.660
https://www.itu.int/rec/T-REC-X.680
https://www.itu.int/rec/T-REC-X.690

(Wow, the last bib entry for X.660 was in RFC 5280!)

> * add a reference to IANA PEN registry

Done.

> * I would suggest reversing this sentence: "the first byte cannot be a leading zero in SDNV's base-128 arithmetic, so it cannot take value 0x80", possibly mentioning the requirement on the integer…

RFC 6256 says “Section 8.1.2.4.2 of X.690”, which contains the bullet:

c) bits 7 to 1 of the first subsequent octet shall not all be zero.

Reference added.

> * either replace "must" with "is" or with "MUST" (I would suggest is, because the normative MUST before covers the requirement already)

“is” it is.

> * I would replace "its" by "the tag's" for clarity.

“the byte string’s", actually.  Done.

> * It seems to me that this document could benefit from a more expanded terminology section. In particular, I would quickly summarize the terms used from X.690 - e.g. arc - and SDNV.

Well, I put this in the “Object Identifier” section:

We also use the term "arc" when the focus is on the edge of the tree
labeled by such an integer value, as well as in the sense of a "long
arc", i.e. a (sub)sequence of such integer values.)

The terminology of X.660 is really confused (they try to maintain the illusion the edges are labeled by Unicode strings), so this is probably the best we can do.

I also added a pointer to RFC 6256 in the terminology section.

> * Some introductory text for the examples in Section 3 would have been good.

I added a sentence.

> * I am a bit unsure about the reasoning behind section 4 "Discussion". Is this not background? Then in my opinion it would fit better in section 2.

I moved it so it is now section 2.2 (initiating some renumbering of sections).

> * I would have merged section 3 and 6 in one section “Examples”

I moved what was Section 6 to a Section 4.1, titled:

4.1.  Tag factoring example: X.500 Distinguished Name

Separating the basic usage examples (now Section 2.2) and the tag factoring usage example (now Section 4.1) probably helps the user.  If you insist, we can of course reorder and merge back.

			.oOo.

Thank you again, I think the document is better now…

I have made the updated version available at https://github.com/cbor-wg/cbor-oid (pregenerated HTML at https://raw.githack.com/cbor-wg/cbor-oid/master/draft-ietf-cbor-tags-oid.html as indicated in the README; diff at https://tools.ietf.org/rfcdiff?url1=draft-ietf-cbor-tags-oid&url2=https://raw.githack.com/cbor-wg/cbor-oid/master/draft-ietf-cbor-tags-oid.txt in rfcdiff format).

The plan is to submit -04 after a quick re-check of these updates.

Grüße, Carsten

---

From: Francesca Palombini <[email-masked]>
Date: Tue, 26 Jan 2021 20:23:27 +0000

Thanks Carsten, it looks good! Please upload v-04 with these changes.

Francesca

On 15/01/2021, 22:07, "Carsten Bormann" <[email-masked]> wrote:

    Hi Francesca,

    Done.

    Ugh.  

    I went with:

    Done.

    Reference added.

    “is” it is.

    I added a sentence.

    			.oOo.

    I have made the updated version available at https://protect2.fireeye.com/v1/url?k=ec06175c-b39d2e5e-ec0657c7-869a14f4b08c-beba7de442b69289&q=1&e=77373f56-00e1-459f-99c9-b4227b5b0846&u=https%3A%2F%2Fgithub.com%2Fcbor-wg%2Fcbor-oid (pregenerated HTML at https://raw.githack.com/cbor-wg/cbor-oid/master/draft-ietf-cbor-tags-oid.html as indicated in the README; diff at https://tools.ietf.org/rfcdiff?url1=draft-ietf-cbor-tags-oid&url2=https://raw.githack.com/cbor-wg/cbor-oid/master/draft-ietf-cbor-tags-oid.txt in rfcdiff format).

    Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Jan 2021 02:20:51 +0100

On 2021-01-26, at 21:23, Francesca Palombini <[email-masked]> wrote:
> 
> Thanks Carsten, it looks good!

Thank you!
I do like the cleaner structure we have now.

> Please upload v-04 with these changes.

Done.  The changes section says:

> A.1.  Changes from -03 to -04
> 
>    Process WGLC and shepherd comments:
> 
>    *  Update references (RFC 8949, URIs for ITU-T)
> 
>    *  Define arc for this document, reference SDN definition
> 
>    *  Restructure, small editorial clarifications

Detailed changes as always at

https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-tags-oid-04

Grüße, Carsten