Draftietfsupagenericpolicydatamodel02 Joel Halpern jmhjoelhalpern com joel halpernericsson com

  • Slides: 5
Download presentation
Draft-ietf-supa-genericpolicy-data-model-02 Joel Halpern jmh@joelhalpern. com, joel. halpern@ericsson. com

Draft-ietf-supa-genericpolicy-data-model-02 Joel Halpern jmh@joelhalpern. com, joel. halpern@ericsson. com

Draft state • Revision submitted 13 -October-2016 • All YANG passes available tests •

Draft state • Revision submitted 13 -October-2016 • All YANG passes available tests • After the buggy tests were repaired • Has a YANG data tree • Covers all of the Generic Policy from the Information model • Reflects the generic information model • With some refinements for YANG specifics

Structural overview - reminder • IM classes are represented as YANG groupings • Inheritance

Structural overview - reminder • IM classes are represented as YANG groupings • Inheritance is represented using • “using” clauses to use the parent grouping in the child • Class identities “based” on the parent identity. • With a dummy root because YANG “identityref” can not have a value equal to the base, the value must be derived from the base • Associations are represented as instance-identifiers • With “must” clauses using the identity that the target must have or be derived from • With association classes represented as their own groupings for the association properties • Classes which can be concrete have their own container, with a list, with elements that “use” the class grouping

Pending actions • We will add the ECA models • Using the same transforms

Pending actions • We will add the ECA models • Using the same transforms we used for the Generic Policy • We will add examples • Probably a subset of the examples we will add to the IM • Do we need to add more descriptive introductory material in section 5. • Some drafts describe the YANG objects carefully before the YANG • This draft, we are currently reliant on the extensive IM descriptions and the description clauses in the YANG

Open question - enumerations • The model includes many enumerations • These are used

Open question - enumerations • The model includes many enumerations • These are used for classic listings of “possible values for this thing” • YANG enumerations are not extensible in submodels • We could use a base identity for the field • with a derived identity for each currently defined meaning • Thus allowing new values to be added in models which build on this • Should we do so?