Re: [Lwip] Magnus Westerlund's Discuss on draft-ietf-lwig-curve-representations-19: (with DISCUSS)

[Carsten Bormann <[e-mail]>]

(Please see previous discussion at
<https://mailarchive.ietf.org/arch/msg/lwip/eTH8zXdP0xASswZnl9u6rKp75ms>)

On 2021-02-17, at 12:43, John Mattsson <john.mattsson=[e-mail]> wrote:
> 
> I personally see no need to change the status of this document to standards track. If a 3 byte COSE identifiers are unacceptable it seems better to write a short standards track COSE draft for that part and publish the rest as informational.

None of this is a hard show-stopper, but I fear that we are setting ourselves up for the wrong signaling here.

By limiting 1 to 255 (1+0 and 1+1-byte) to “Standards Action”, we made it hard for Informational Documents to allocate these code points.  Security Area specifications are often Informational though.  

We don’t want to create “second class” specifications by giving them 1+2-byte identifiers only, just because the habit in the Security area is to mark certain specifications as informational.  

We also don’t want to insert the thought into the heads of protocol designers that they need to avoid sending these identifiers at all because some important specifications only got 1+2-byte identifiers.

Hmm, how do we fix this.  

(1) We could ask IESG to do a variance here.  We could support that with a formal consensus call in COSE.

(2) We could write a short WG document changing this into a “IETF Review” with some admonition that the DE should be consulted.

Section 4.8 of RFC 8126 says:

   Examples:

      IPSECKEY Algorithm Types [RFC4025]
      TLS Extension Types [RFC5246]

So we are in good companionship with this.

But I don’t want to create another obstacle for lwig-curve-representations now, so maybe we could do 1 *and* 2.

Let’s decide this later today.

Grüße, Carsten