Subject: [Supa] DM Enumerations

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Nov 2016 10:54:12 -0500

As discussed in Korea, there is one aspect of the YANG usage in the data 
model that concerns me.

There are a number of enumerations in the model that represent a range 
of choices (encodings, information location representations, constraint 
languages, ...).  These are current represented as YANG enums.

YANG enums can be revised when a document is reved, but can not be 
extended by an augmentation.  So new models, based on this work, can not 
add new values to the enumerations.

If we stick with enumerations, this means that we frequently end up with 
catch-all "other" entries (or worse, undefined1, undefined2, undefined3).

As an alternative, we can switch to identities.  For each enumeration, 
the model can define a base identity (the type as it were), and then a 
derived identity for each value in the enumeration.  Then, new models 
building on that work can define additional identities on the same base.

Does the working group want the authors to make this change?

Yours,
Joel

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Nov 2016 18:01:55 +0100

On the abstract level, it seems that identities are fine. That said, I
wonder how you plan to arrive at interoperable implementations if
everything is flexible. Are there any mandatory to implement
identities?

/js

On Mon, Nov 21, 2016 at 10:54:12AM -0500, Joel M. Halpern wrote:
> There are a number of enumerations in the model that represent a range of
> choices (encodings, information location representations, constraint
> YANG enums can be revised when a document is reved, but can not be extended
> by an augmentation.  So new models, based on this work, can not add new
> values to the enumerations.
> 
> As an alternative, we can switch to identities.  For each enumeration, the
> model can define a base identity (the type as it were), and then a derived
> identity for each value in the enumeration.  Then, new models building on
> that work can define additional identities on the same base.
> 
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Nov 2016 12:22:09 -0500

Sorry Juergen, I am not following your question.

There are enumerations in the current model.  In terms of model support, 
all the current models will become base identities.

If the quesiton is about what values an implementation will support, it 
is already the case that different implementations will use different 
values.  Not all policy systems will support OCL for constraints.  Not 
all policy systems will support URLs for external references.  It may 
well be that we should pick some things as mandatory to implement.  Most 
of the enumerations are tied to optional capabilities anyway.

Yours,
Joel

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Nov 2016 18:43:59 +0100

On Mon, Nov 21, 2016 at 12:22:09PM -0500, Joel M. Halpern wrote:
> There are enumerations in the current model.  In terms of model support, all
> the current models will become base identities.

As I said, on the abstract level, it seems that identities are fine.
 
> If the quesiton is about what values an implementation will support, it is
> already the case that different implementations will use different values.
> Not all policy systems will support OCL for constraints.  Not all policy
> systems will support URLs for external references.  It may well be that we
> should pick some things as mandatory to implement.  Most of the enumerations
> are tied to optional capabilities anyway.

Unless there is a common baseline of mandatory to implement 'features',
my expectations that you will end up with interoperable policy systems
is small.

/js