Hi Michael,
> -Original Message-
> From: Anima On Behalf Of Michael Richardson
> Sent: 25 June 2021 21:41
> To: Toerless Eckert ; Fries, Steffen
> ; an...@ietf.org; netmod@ietf.org; Kent
> Watsen ; Rob Wilton (rwilton)
> Subject: [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue ->
On Mon, Jun 28, 2021 at 12:39:38PM -0400, Michael Richardson wrote:
>
> Juergen Schoenwaelder wrote:
> >> Juergen Schoenwaelder wrote:
> >> > Note that there is also a middle ground, namely an enumeration type
> >> > factored out into an IANA maintained module that is process wise
Juergen Schoenwaelder wrote:
>> Juergen Schoenwaelder wrote:
>> > Note that there is also a middle ground, namely an enumeration type
>> > factored out into an IANA maintained module that is process wise easier
>> > to extend - should extensions be needed more regularly.
>>
On Mon, Jun 28, 2021 at 12:04:46PM -0400, Michael Richardson wrote:
>
> Juergen Schoenwaelder wrote:
> > Note that there is also a middle ground, namely an enumeration type
> > factored out into an IANA maintained module that is process wise easier
> > to extend - should extensions
Juergen Schoenwaelder wrote:
> Note that there is also a middle ground, namely an enumeration type
> factored out into an IANA maintained module that is process wise easier
> to extend - should extensions be needed more regularly.
That would suit me. How do we do that?
--
Michael
On Mon, Jun 28, 2021 at 11:54:04AM +, tom petch wrote:
[...]
> As you say, this is never going to be an Erratum.
Yep.
> A leaf of type empty is encoded as, well, empty.
>
> as per RFC 7950.
>
> When this concept was first mentioned, my sense was that while it was
> technically
From: netmod on behalf of Toerless Eckert
Sent: 25 June 2021 23:48
I was first asking about the encoding ;-)
Would be good to understand if this "empty" encoding would result in a
- same of different degree of "backward compatibility" as an extended enum
- same or different size of ascii and
