Subject: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ?

From: Toerless Eckert <[email-masked]>
Date: Fri, 25 Jun 2021 21:05:12 +0200

https://trac.ietf.org/trac/netmod/wiki/YANG_FAQ#when-use-empty

Is this the solution we are looking for ?

What would be JSON vs. CBOR encoding of such "empty" values ?

Cheers

    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Jun 2021 16:41:08 -0400

Toerless Eckert <[email-masked]> wrote:
    tte> https://trac.ietf.org/trac/netmod/wiki/YANG_FAQ#when-use-empty
    tte> Is this the solution we are looking for ?

here it the relevant text:

} The second situation is when you want to define an extensible enumeration,
} as an alternative to the type "enumeration", which is not extensible by other
} modules. For example if an enumeration is used:

} leaf protocol {
}   type enumeration {
}     enum smtp;
}     enum pop3;
}   }
} }
} and we want to add a new protocol 'imap4', it must be done by adding a new
} enum in the module. But if we use a choice of type empty instead:

} container protocol {
}   choice p {
}     case smtp { leaf smtp { type empty; } }
}     case pop3 { leaf pop3 { type empty; } }
}   }
} }
} then another module can augment the first:
}
} augment /foo:protocol/p {
}    case imap4 { leaf imap4 { type empty; } }
} }

Well, this seems to be exactly what we want.
Do we get to put a description in there?
can we put a value in so that our SID process works?
(I imagine we'll have to hack pyang to make it cope, but...)

proceedural options:

1) write this up as errata against 8366.  That seems a bit much for errata,
   but how much whisky does it cost to bribe an AD?

2) write a formal "Updates" RFC8366 that just does the NEW/OLD version of
   updates, and that's it.

3) do an entire RFC8366bis.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 26 Jun 2021 00:48:10 +0200

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 binary encoding ?

I am also not quite clear what difference it really makes to use empty instead
of just creating a new revision of the voucher, as shown for module b in

https://datatracker.ietf.org/doc/html/rfc7950#section-5.6.5

Need to learn more YANG ;-)

Wrt errata: I would bet that none of this will go through as errata to
RFC8366. In all the instances i remember erratas being accepted as such, 
they where all about what i'd call real textual bugs where it was obvious
that what was desired by the RFC is not what the text of the RFC says.
I think choosing a better/different extensible encoding is purely a feature.
Which is fine, it just means we need to find a different place to track
this, maybe the trac wiki. Errata are just a very limited editorial tool,
not really a generic help for an RFCbis ;-(

Lets hear from yang doctors or yang friends. Right now i bet that if
the only change for yang vouchers is this enum, then its probably easiest
to do b), e.g.: make AE be a formal update. I think c) is appropriate if
we have a larger critical mass of changes for rfc8366.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 27 Jun 2021 17:02:54 -0400

Toerless Eckert <[email-masked]> wrote:
    > the only change for yang vouchers is this enum, then its probably
    > easiest to do b), e.g.: make AE be a formal update. I think c) is
    > appropriate if we have a larger critical mass of changes for rfc8366.

I wasn't think that brski-async-enroll would be the RFC8366 Update document,
but I guess it could be.

I thought that it would be a new document.
I will prepare an RFC8366bis ID so that we have some complete YANG, and I'll
attempt to point constrained-voucher at it to see what happens to SID values, etc.

But, not before the hackathon, maybe during.

---

From: tom petch <[email-masked]>
Date: Mon, 28 Jun 2021 11:54:04 +0000

From: netmod <[email-masked]> on behalf of Toerless Eckert <[email-masked]>
Sent: 25 June 2021 23:48

<tp>
As you say, this is never going to be an Erratum.

A leaf of type empty is encoded as, well, empty.
<voucher-type/>
as per RFC 7950.

When this concept was first mentioned, my sense was that while it was technically possible, it would still add complexity for little gain.  As I see YANG Doctors for ever saying, identity can be augmented, enumeration can not so enumeration are used when you positively want to stop people augmenting, when the concept does not make sense so a revised enum may make sense or a change to something like identity which I see as as big a change as the use of 'empty' but the latter is not in current use and so may cause some uncertainty, some confusion.

Tom Petch

Cheers
    Toerless

--
---
[email-masked]

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Jun 2021 14:09:24 +0200

On Mon, Jun 28, 2021 at 11:54:04AM +0000, tom petch wrote:

[...]

> As you say, this is never going to be an Erratum.

Yep.
 
> When this concept was first mentioned, my sense was that while it was technically possible, it would still add complexity for little gain.  As I see YANG Doctors for ever saying, identity can be au…

Enumerations are centrally managed. Section 11 of RFC 7950 does allow
additions to enums but only where the enum itself is defined, i.e.,
you need to create a new revision of the YANG module to add an enum
value. An identity is more flexible as the value space is not
centrally managed.

Using leafs of type <empty/> as a way to define a non-centrally
managed enumerated set of values really is a hack. It may work if
people follow certain rules, but it is unlikely that tools will
understand the rules (i.e., which places of a data model were designed
to be used as a 'leafs of type <empty/> enumeration'). Hence, there is
nothing that will prevents people from augmenting in a leaf that is
not using the type empty or even an entire subtree of YANG definitions.

I do not know exactly what the issue with RFC 8366 is but it seems you
will have to revise the YANG module defined in RFC 8366 anyway.

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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Jun 2021 12:04:46 -0400

Juergen Schoenwaelder <[email-masked]> wrote:
    > 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?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Jun 2021 18:14:48 +0200

> That would suit me. How do we do that?

You revise RFC 8366 and do the following:

- You define an IANA maintained module defining the enumeration type.
- You write IANA considerations for the new module.
- You modify the existing module to import and use the enumeration type.
- You do not make any modifications to the existing enumerations.
- You republish the revised version of RFC 8366.

A couple of month later (and after surviving all the reviews), you
declare success. I fear there is nothing "cheaper".

/js

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Jun 2021 12:39:38 -0400

> - You define an IANA maintained module defining the enumeration type.

This is the part that I don't know to do.
  https://www.rfc-editor.org/rfc/rfc7950.html#section-9.6
says nothing about IANA.  Is RFC7224 the model for this?

What document am I missing here?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Jun 2021 20:20:43 +0200

> What document am I missing here?

Yes, RFC 7224 defining the iana-if-type module may serve as a
template. There are a couple of IANA maintained YANG modules, I am not
sure whether we have a good place listing them all. Well, you can
filter out the iana- modules from this list:

https://www.iana.org/assignments/yang-parameters/

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 28 Jun 2021 20:04:06 +0000

Hi Michael,

> -----Original Message-----
> From: Anima <[email-masked]> On Behalf Of Michael Richardson
> Sent: 25 June 2021 21:41
> To: Toerless Eckert <[email-masked]>; Fries, Steffen
> <[email-masked]>; [email-masked]; [email-masked]; Kent
> Watsen <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>
> Subject: [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but
> what's he encoding ?
> 
> 

Depends how expensive the whisky is ;-)

More seriously though, this can't be done as an errata.

An RFC8366bis is the right option.  If the changes are minor then I may be able to ease the passage through the IESG, but I can't do much to affect the elapsed time.

Regards,
Rob

---

From: tom petch <[email-masked]>
Date: Tue, 29 Jun 2021 08:48:10 +0000

From: netmod <[email-masked]> on behalf of Juergen Schoenwaelder <[email-masked]>
Sent: 28 June 2021 19:20

>     >> Juergen Schoenwaelder <[email-masked]> wrote:
<snip>

<tp>

There is what would be a good place but it is on the IANA website and that is never a good place:-(  AFAICT there is no URI for it but if you go to IANA Parameters, click on the letter 'Y', it takes me to 
YANG Module Tags (no URI)
below which is 
YANG Modules (no URI)
which is not YANG Modules in any expected sense but IANA-Maintained YANG Modules.  (But if the title was sensible, then it would collate under the letter 'I' and I would never find it again:-(.

Anyhow, cynicism aside, there is a list of eight IANA-maintained modules to use as exemplars.

Tom Petch

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 29 Jun 2021 19:49:41 +0000

> Anyhow, cynicism aside, there is a list of eight IANA-maintained modules to use as exemplars.

And five more IANA-maintained modules to-be with "draft-ietf-netconf-ssh-client-server" and "draft-ietf-netconf-ssh-client-server".

K.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Jun 2021 18:36:20 -0400

<#secure method=pgpmime mode=sign>

    > filter out the iana- modules from this list:

Okay, I understand now.
RFC7224 is an *IANA* maintained YANG module.  When new allocations are made,
then IANA rewrites the YANG module to include the new items.
It's not a YANG module that imports from a IANA registry, which I think we
have no YANG way to do that.

RFC7224 seems to use identity to create new subclasses.
RFC7217 seems to use typedef and feature.

Based upon my understanding, perhaps we don't need to revise RFC8366 completely,
it might be that we can just update it to include IANA Considerations and
turn the ietf-voucher YANG module into an IANA maintained YANG module?

That just avoids opportunity for more text churn.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Jun 2021 20:36:51 -0400

Rob Wilton (rwilton) <[email-masked]> wrote:
    > An RFC8366bis is the right option.  If the changes are minor then I may
    > be able to ease the passage through the IESG, but I can't do much to
    > affect the elapsed time.

I will prepare a draft for this week.

I thought I wrote a really nice ASCII art version of what documents inherit
from RFC8366.  I can't find it in my outbox... I wonder if I nuked the draft
by mistake.

The short of it:
RFC8366 -> RFC8995 (voucher-request)
        -> constrained-voucher (voucher-request, voucher)
        -> brski-async-enroll (voucher-request)
        -> jose-voucher (voucher, voucher-request)

and my question was a bit about how we manage all their things inherited.
It's really the classic CS multiple inheritance problem.

{A Cat is an Mammal
 A Cat is an Four-legged creature
 A Cat is Nocturnal.}

---

From: Kent Watsen <[email-masked]>
Date: Wed, 30 Jun 2021 00:56:24 +0000

> On Jun 29, 2021, at 8:36 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

If considering a bis, can we consider changing the "pinned-domain-cert” node from a X.509v3 cert to a “choice” between that and a chain of certs?   

In particular, from:

   +---- pinned-domain-cert               binary

To:

   +---- (domain-cert-format)
      +---- pinned-domain-cert               binary
      +---- pinned-domain-certs              binary

Or, better, using ietf-crypto-types:

   +---- (domain-cert-format)
      +---- pinned-domain-cert               ct:end-entity-cert-x509
      +---- pinned-domain-certs              ct:end-entity-cert-cms

> from RFC8366.  I can't find it in my outbox... I wonder if I nuked the draft

Check this:

https://yangcatalog.org/yang-search/impact_analysis/?modtags=ietf-voucher%402017-10-25.yang&orgtags=&recursion=0&show_rfcs=1&show_subm=1&show_dir=dependents <https://yangcatalog.org/yang-search/impact_analysis/?modtags=[email-masked]&orgtags=&recursion=0&show_rfcs=1&show_subm=1&show_dir=dependents>

K.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Jun 2021 21:23:04 -0400

> If considering a bis, can we consider changing the "pinned-domain-cert”
    > node from a X.509v3 cert to a “choice” between that and a chain of
    > certs?

Yeah, I think it's a good idea.
Could we also have the choice be a RPK?

    > Or, better, using ietf-crypto-types:

:-)

    > https://yangcatalog.org/yang-search/impact_analysis/?modtags=ietf-voucher%402017-10-25.yang&orgtags=&recursion=0&show_rfcs=1&show_subm=1&show_dir=dependents
    > <https://yangcatalog.org/yang-search/impact_analysis/?modtags=[email-masked]&orgtags=&recursion=0&show_rfcs=1&show_subm=1&show_dir=dependents>

Yeah, I knew about that, but others might not.
I was basically trying to distill it down into a few words.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 30 Jun 2021 12:38:20 +0000

Hi Michael, 

> From: Michael Richardson <[email-masked]>
> Sent: Mittwoch, 30. Juni 2021 02:37

> I thought I wrote a really nice ASCII art version of what documents inherit from
> RFC8366.  I can't find it in my outbox... I wonder if I nuked the draft by mistake.
> 
> The short of it:
Would it make sense to also state the voucher for BRSKI-AE as it also uses the voucher and tries to argue for a new assertion type (agent-proximity)?

>         -> jose-voucher (voucher, voucher-request)

Regards
Steffen