Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?

[Rob Wilton (rwilton)]

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 -> empty, but
> what's he encoding ?
> 
> 
> Toerless Eckert  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?

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


> 
> 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. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ?

[Juergen Schoenwaelder]

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 
> easier
> >> > to extend - should extensions be needed more regularly.
> >>
> >> 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.
> 
> 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?

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ?

[Michael Richardson]

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.
>>
>> 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.

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?

> - 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".

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ?

[Juergen Schoenwaelder]

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 be needed more regularly.
> 
> 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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ?

[Michael Richardson]

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 Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ?

[Juergen Schoenwaelder]

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 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.
>

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  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  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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ?

[tom petch]

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 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.


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

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 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

On Fri, Jun 25, 2021 at 04:41:08PM -0400, Michael Richardson wrote:
>
> Toerless Eckert  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. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>



--
---
t...@cs.fau.de

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod