Re: [Cbor] Reminder and call for agenda: CBOR WG Virtual Meeting on 2023-03-08

[Carsten Bormann <[e-mail]>]

On 2023-03-06, at 22:13, Christopher Allen <[e-mail]> wrote:
> 
> On Mon, Mar 6, 2023 at 3:02 AM Carsten Bormann <[e-mail]> wrote:
>> I can’t speak for the whole community, but I am sure interested in any implications your implementation might have on standardization.
>> I think the CBOR meeting at IETF 116 will be a bit cramped for the discussion content we should be having, so doing this at an interim probably works better.
> 
> We'd be glad to do so when you are ready (and somewhat relieved not to
> have to be in best form at 11pm PDT).

OK, so I have mentioned dCBOR on https://notes.ietf.org/notes-ietf-interim-2023-cbor-05-cbor?both, which we are using as a community input page to the meeting agenda which will be set up Tuesday evening-ish.

[…]

> I was not aware of a separate SecDispatch. I had presumed bringing it
> up in SAAG was too broad for us until we could demonstrate more IETF
> membership support.

SAAG probably indeed is too early.  As may be SecDispatch at this point.  Doing that side meeting is probably the best way to get forward progress.
> 
> Yes, a side meeting would be great if a BOF is too challenging. Any
> advice on how to proceed is appreciated.

You should probably have a look at 

https://wiki.ietf.org/meeting/116/sidemeetings

and put up some information there.

You probably want to look at the meeting agenda as well and avoid conflicts that would keep people from coming.  (I sent an abridged agenda to this list, but that may not be perfect as your approach is probably not constrained-environment only.)

>> Leafing through the draft, there are a lot of things that might require rethinking in the IETF (say, BLAKE3???).
> 
> Thank you for taking a look!
> 
> We will have an updated draft -01 this week, based on feedback from
> many parties, including one of the co-authors of BLAKE, and have
> decided we can't fully take advantage of its capabilities, and thus
> will be using SHA-256.

Makes this much more interesting to me (but don’t forget putting in some crypto agility!).
(Generally, we try to get analysis from CFRG before we employ new crypto components; I am not aware of any attention that has been paid there to BLAKE3.)

>> (At some point we should be talking about assigning the tags that are squatted on by this draft, but maybe talking about the content is first.)
> 
> As we understand it, the range of numbers that we've suggested
> ("squatted on" ;-] ) in our draft only has a "specification required"
> requirement, which our I-D offers.

I haven’t checked the spec enough, but yes, it does seem you would qualify for these registrations.  A registration is not a registration until it has been registered…

> There are certainly examples of
> others in this range that are not even I-D.

Correct, the stability of the specification has been more important to us than the specific venue that it has been made available under.
I should mention that we have slightly tightened the reins in the transition from RFC 7049 (2013) to RFC 8949 (2020), so we will look more closely on the space you want to register in.

Here is today’s tag report:

$ tag-report.rb
range  used     %                 free                total
0 1+0    13 54.17                   11                   24
1 1+1    70 30.17                  162                  232
2 1+2   437  0.67                64843                65280
3 1+4 65284  0.00           4294836476           4294901760
4 1+8     2  0.00 18446744069414584318 18446744069414584320

Note that these spaces need to supply fresh numbers for a few more decades, so those percentages are a bit more dramatic than they may seem.

> We decided not to apply quite yet in case there were questions. Should
> we go ahead and apply now? If there is something missing from the
> official docs about the requirements for the assignment of CBOR
> numbers in this range by IANA, please let us know.

If you think there will be deployment soon, that is the time for registering.
As long as the protocol is still very malleable, registering is counterproductive.  You should indicate that the numbers you use for experiments are not final.  I recently wrote up a possible way to handle this in draft-bormann-cbor-draft-numbers-00 [1] — you don’t have to do exactly this, but it should give you an idea of what we are trying to achieve.

> Of course, what I'd really like is for the CBOR community to fall in
> love with Gordian Envelope and let us have one of the precious
> remaining 1-byte tags (6–15 and 20 are currently unassigned) as
> Gordian Envelope is being used in constrained environments (even
> possibly as silicon logic), every byte counts, and this specific tag
> (currently requesting 200) is used a lot as the structure is very
> recursive.

That would indeed require a rather significant love affair.
11 “1+0” tags left for, say, at least the next 30 years...

Please do continue to use the mailing list for discussing your work and how it might fit into the IETF.
(I have removed a number of names from the CC that I expect are on the mailing list; they don’t need two copies.)

Grüße, Carsten