Subject: Re: Last Call: <draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard

From: Yaron Sheffer <[email-masked]>
Date: Sat, 10 Aug 2013 09:46:51 +0300

Hi Dave,

I agree with you about the counter-marketing text that will only turn 
off potential implementers.

However I think this would be more appropriate as Experimental. Yes, we 
give PS to specs that may not ever be implemented. But at least working 
groups are (usually) good at avoiding publishing multiple specs to solve 
the same problem. Here we do not have that gating function. If we 
foresee multiple solutions being published for this problem space, which 
is what I'm hearing, then Experimental is the better choice.

Thanks,
	Yaron

> Date: Fri, 09 Aug 2013 19:33:49 -0700
> From: Dave Crocker<[email-masked]>
> To: Stephen Farrell<[email-masked]>
> Cc: Carsten Bormann<[email-masked]>,	IETF Discussion Mailing List
> 	<[email-masked]>
> Subject: Re: Last Call: <draft-bormann-cbor-04.txt> (Concise Binary
> 	Object	Representation (CBOR)) to Proposed Standard
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 8/9/2013 6:09 PM, Stephen Farrell wrote:
>> >So some kind of statement that CBOR is one point in a design
>> >space (as opposed to an optimal solution for some set of
>> >design objectives) would be worthwhile.
>
> huh?  a statement beyond the opening sentence of the introduction and
> its third paragraph?
>
> worthwhile to whom and for what?  it's a spec (or perhaps a meta-spec.)
>    it provides a capability.  it needs to specify the what and how well
> enough to be usable.
>
> while ietf culture permits specifications to have quite a variety of
> commentary, historical or contextual discussion is not an essential part
> of the document, and certainly not discussion cast in a manner to
> denigrate the current spec.
>
> Counter-marketing that has the current spec self-deprecatingly casting
> itself as  only one of many seems mostly worthwhile to get people to
> avoid using it.
>
> exp makes sense if there is doubt that it is technically workable, not
> because its success in the market is questionable.  we give ps all the
> time to specs that have little clear market and go on gain small market use.
>
> from what i've seen, this is a carefully researched and crafted
> mechanism and i haven't noted anyone challenging it on basic technical
> grounds.
>
> d/
>
> -- Dave Crocker Brandenburg InternetWorking bbiw.net

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 10 Aug 2013 09:07:04 +0200

On Aug 10, 2013, at 08:46, Yaron Sheffer <[email-masked]> wrote:

> If we foresee multiple solutions being published for this problem space, which is what I'm hearing, then Experimental is the better choice.

By that argument, TCP and UDP should be Experimental, too -- they are both in the transport protocol problem space.

There is nothing Experimental about CBOR.

Grüße, Carsten

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Aug 2013 08:00:18 -0700

> There is nothing Experimental about CBOR.

One of the reasons we find groups choosing to avoid the IETF's standards 
process is its unpredictability.  Folks here -- both on open discussion 
lists and often in the IESG -- think it's acceptable to invoke 
spontaneous, personal criteria, rather than pay attention to the rules 
we've put into place.  We have criteria for the standards labels. 
They've gone through IETF consensus and they are supposed to have 
something akin to the force of (IETF) law.

If someone feels that this specification does not qualify for Proposed 
Standard, they ought to feel obligated to begin with a citation of the 
portion of RFC 2026, Section 4.1.1 -- specifying the criteria for 
Proposed Standard -- that this specification fails to satisfy.

In particular, they should draw carefully from the second paragraph of 
that section.,

By my own reading, this specification looks to be a pretty classic 
example of what we say we want for Proposed Standard.

Most of this thread has ignored the IETF's own rules and criteria.  As 
such, it's wasteful, at best, though I think it's actually destructive, 
since it provides fuel to the view that the IETF is a questionable venue 
for standards work.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Aug 2013 11:14:31 -0400

On Aug 10, 2013, at 11:00 AM, Dave Crocker <[email-masked]> wrote:
> Most of this thread has ignored the IETF's own rules and criteria.  As such, it's wasteful, at best, though I think it's actually destructive, since it provides fuel to the view that the IETF is a questionable venue for standards work.

+1

---

From: John C Klensin <[email-masked]>
Date: Sat, 10 Aug 2013 11:33:24 -0400

--On Saturday, August 10, 2013 11:14 -0400 Ted Lemon
<[email-masked]> wrote:

>> Most of this thread has ignored the IETF's own rules and
>> criteria.  As such, it's wasteful, at best, though I think
>> it's actually destructive, since it provides fuel to the view
>> that the IETF is a questionable venue for standards work.
> 
> +1

+1 more.  Not doing this sort of thing to ourselves is probably
far more important, in the long run, than trying to slightly
re-tune the language of 2026 in that hope that will impress
someone.  The latter might still be worthwhile, but it is, IMO,
far more important to stop shooting ourselves in the foot.

   john

---

From: Eliot Lear <[email-masked]>
Date: Sat, 10 Aug 2013 20:46:29 +0200

On 8/10/13 5:00 PM, Dave Crocker wrote:
>
> One of the reasons we find groups choosing to avoid the IETF's
> standards process is its unpredictability.

Our processes must be stable, but people have different reasons for
articulating concern.  2026 is not meant to be the singular criteria. 
In fact we have for a long time accepted the additional questions that
form a working group, as well.  And unpredictability is part and parcel
of standards activity: you can't buy a standard at the IETF, which is
what predictability implies, if taken to extremes.  And people not
familiar with the IETF often take it to extremes.  A perfect example was
Tim Berners-Lee who wanted to standardize HTML, but didn't want to give
up control of the specification.  It just doesn't work that way.

Now that we're done with generalities, I'll just chime in and say that
the spec in question seems perfectly fine to advance as a Proposed
Standard.  I do wonder whether CBOR is better than compressed JSON, but
I understand that in this context CPU may be a limiting factor.

There is an architectural question hiding here: when we use CBOR in
various protocols, we may be optimizing for the wrong set of devices
overall.  Conversely, we may be optimizing for just the right devices
since the so-called Internet of Things that are low end devices will
outnumber other devices.  Which is it?  Either way, it seems to me we
can't answer without CBOR or something like it, so...  let's have it, then.

Eliot