Subject: Re: [Cbor] Mirja Kühlewind's Block on charter-ietf-cbor-01-01: (with BLOCK)

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 02 Jul 2019 15:44:45 +0100

Hi Mirja,

On Wed, Jun 26, 2019, at 5:46 PM, Carsten Bormann wrote:
> Hi Mirja,
> 
> good points.  Details below.
> 
> > On Jun 26, 2019, at 17:27, Mirja Kühlewind via Datatracker <[email-masked]> wrote:

> > ----------------------------------------------------------------------
> > BLOCK:
> > ----------------------------------------------------------------------
> > 
> > Not sure if my two points justify a block, so I'm happy to change my position
> > if other ADs tell me to, but I'm also not certain if I want to go for "No
> > Objection".
> > 
> > Here are my points:
> > 
> > 1) First on this:
> > "After that, the CBOR working group will monitor issues found with the CBOR
> > specification and, if needed, will produce an updated document." This intention
> > seems to contradict the idea of an Internet Standard in RFC2026 a bit:
> >   "A specification for which significant implementation and successful
> >   operational experience has been obtained may be elevated to the
> >   Internet Standard level.  An Internet Standard (which may simply be
> >   referred to as a Standard) is characterized by a high degree of
> >   technical maturity and by a generally held belief that the specified
> >   protocol or service provides significant benefit to the Internet
> >   community."
> > Maybe this is nit-picking but if the group is not sure if there are further
> > issue, one should probably simply not push for Internet Standard…
> 
> Of course the group is sure about that!!!1one
> 
> Some STD documents do have updates (say, RFC 791 is updated by RFC1349, 
> RFC2474,     RFC6864), but I would actually also feel better without 
> this apparent escape hatch.  We do want to get this right!

Ok, I suggest we remove "After that, the CBOR working group will monitor issues found with the CBOR specification
and, if needed, will produce an updated document." This would always remain a future possibility, even if the document is an Internet Standard.

> > 2) I find the later part of the charter rather generic (starting which "There
> > are a number of additional CBOR tagged types..."). I also don't really
> > understand the difference of "General purpose" and "Internet-wide". These are
> > two different aspects for me that don't exclude each other. I would rather like
> > to see a charter that actually limits the technical scope rather than talking
> > about a generic process (that may or could be or is applied in other groups as
> > well).

Are you suggesting that the Charter should just list specific documents and require rechartering once the work is done?

> My fault.  This was specifically about CBOR Tag definitions, until we 
> noticed that we might be having some glue/housekeeping like the CBOR 
> sequence document.  But really, this is almost all about CBOR Tag 
> definitions.
> 
> General purpose vs. Internet-wide: Not all usage of CBOR occurs on the 
> Internet, so there is a difference, but yes, these generally will 
> overlap.  (Example for non-Internet usage: CBOR can be a great log file 
> format.)
> 
> So when is a Tag spec in scope:  When we expect a general purpose 
> and/or Internet-wide usage of the Tag (or other CBOR specific 
> housekeeping document like a media type definition).

Is any clarification needed on this point?

Best Regards,
Alexey

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 2 Jul 2019 17:52:51 +0200

Hi Carsten,

See inline.

> On 2. Jul 2019, at 16:44, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Mirja,
> 

I think that makes sense. Thanks!

> Are you suggesting that the Charter should just list specific documents and require rechartering once the work is done?

Yes, I think that would actually be the better approach, where document should not be specific drafts but specific work items.
> Is any clarification needed on this point?

I think my confusion is about listing hem as separate items on the implication on the decision. However, if the group decided to rather list specific items instead, I guess this part is not needed anymore.

Mirja

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Jul 2019 19:44:59 +0200

Hi Mirja,

> Yes, I think that would actually be the better approach, where document should not be specific drafts but specific work items.

We did that in the previous (current) charter, and it was a mistake.

Tags are the most prominent defined extension point for CBOR, defined so there is a low threshold to actually making an “extension” (defining a tag), mostly done by third parties via IANA registrations.  It does make sense to coordinate some of this from the WG and pick some strategic tags for WG attention.  It makes more sense when this can be done flexibly and quickly.

The current charter from 2.5 years ago lists a couple of tag documents, one of which we chose not to progress right now after all and one that did move forward (WGLC completed).  There are a couple other documents that are de facto WG documents but can’t be officially.  That just serves to slow down work.  It’s a bit as if the DHC working group needed to be rechartered for each new DHCP option.

Grüße, Carsten

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 3 Jul 2019 15:23:12 +0200

Hi Carsten,

Having a more open charter is fine as well, if you see this as going into maintenance mode. However, I don’t really see the value in defining this additional process with these three categories (which are also not completely clear to everybody and therefore probably not always straight forward to map). I would recommend to discuss every proposed tag separately and have a wg call to add a milestone for a tag if accepted in the group. I’d otherwise even be afraid that having these categories might focus any adoption discussion too much on the scope only and may end up not being very unconstructive. Therefore I still recommend to remove that part from the charter. Maybe say something other like:

"The working group will evaluate such proposal individually and decide about addition of a respective milestone. Proposals that are deemed to be out of scope for the working group, e.g. because they are too narrow purpose specifications, may still be published as individual submission or in another groups if there is a specific need. The cbor group will review these proposals on request.”

Or something similar…

Mirja

> On 2. Jul 2019, at 19:44, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Mirja,
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 3 Jul 2019 16:28:37 +0200

Hi Mirja,

these are good points.

> On Jul 3, 2019, at 15:23, Mirja Kuehlewind <[email-masked]> wrote:
> 
> Hi Carsten,
> 
> Having a more open charter is fine as well, if you see this as going into maintenance mode. However, I don’t really see the value in defining this additional process with these three categories (which are also not completely clear to everybody and therefore probably not always straight forward to map). I would recommend to discuss every proposed tag separately and have a wg call to add a milestone for a tag if accepted in the group. I’d otherwise even be afraid that having these categories might focus any adoption discussion too much on the scope only and may end up not being very unconstructive.

I can imagine that, too (even if I think that the composition of the WG so far wouldn’t fall for that, the composition can of course change).

> Therefore I still recommend to remove that part from the charter. Maybe say something other like:
> 

Works for me.

I could imagine that the WG will get used over time to an evaluation process that does make use of the two dimensions, broad vs. narrow, and application development vs. Internet usage.  But we can let the WG evolve that process (e.g., in an informal way) on its own, without having to touch the charter again on every step of that evolution.

> Or something similar…

I think we can discuss the details further in 35 minutes in our virtual WG interim…

Thank you!

Grüße, Carsten