Subject: Re: [Netmod-ver-dt] Today's meeting

From: "Wubo (lana)" <[email-masked]>
Date: Thu, 20 Feb 2020 08:30:51 +0000

Hi Rob,

For the package draft, section 1 Terminology:

o  YANG schema: A datastore schema, not bound to any particular datastore.

There is a different definition in the version selection draft:
   o  YANG schema: The combined set of schema nodes for a set of YANG
      module revisions, taking into consideration any deviations and
      enabled features.

The package draft also says:  a top level package schema represents a datastore schema, so the latter definition  should be used?

Thanks,
Bo
发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Rob Wilton (rwilton)
发送时间: 2020年2月19日 23:24
收件人: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; Joe Clarke (jclarke) <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; [email-masked]
主题: Re: [Netmod-ver-dt] Today's meeting

Hi Jason,

I think that we have converged.  Thanks for the review and comments.

Please see inline for confirmation …

Updated doc is attached.

Last chance for any objections before I post the updated draft version!

Thanks,
Rob

From: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Sent: 19 February 2020 15:10
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; Joe Clarke (jclarke) <[email-masked]<mailto:[email-masked]>>; Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Netmod-ver-dt] Today's meeting

Thx. Pls see below.
Jason

From: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 19, 2020 8:44 AM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Joe Clarke (jclarke) <[email-masked]<mailto:[email-masked]>>; Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Netmod-ver-dt] Today's meeting

Hi Jason,

I’ve changed the first block of text (that is summarizing from the NMDA) to use not RFC 2119 language.

I’ve given [RW2] comments inline below, but also this is the updated text that should take into account all of your comments (some of them I have reworded slightly):

5.3.3.  The relationship between packages and datastores

   As defined by NMDA [RFC8342], each datastore has an associated
   datastore schema.  Sections 5.1 and 5.3 of NMDA defines further
   constraints on the schema associated with datastores.  These
  constraints can be summarized thus:

      The schema for all conventional datastores is the same.

      The schema for non conventional configuration datastores (e.g.,
      dynamic datastores) may completely differ (i.e. no overlap at all)
      from the schema associated with the conventional configuration
      datastores, or may partially or fully overlap with the schema of
      the conventional configuration datastores.  A dynamic datastore,
      for example, may support different modules than conventional
      datastores, or may support a subset or superset of modules,
      features, or data nodes supported in the conventional
      configuration datastores.  Where a data node exists in multiple
      datastore schema it has the same type, properties and semantics.

Wilton                   Expires August 22, 2020               [Page 11]

Internet-Draft                YANG Packages                February 2020

      The schema for the operational datastore is intended to be a
      superset of all the configuration datastores (i.e. includes all
      the schema nodes from the conventional configuration datastores),
      but data nodes can be omitted if they cannot be accurately
      reported.  The operational datastore schema can include additional
      modules containing only config false data nodes, but there is no
      harm in including those modules in the configuration datastore
      schema as well.[>>JTS: ] I'm OK if you want to leave the "can be omitted" part.
[RW]
I think that makes sense to include it because of the NMDA doc.

   Given that YANG packages represent a YANG schema, it follows that
   each datastore schema can be represented using packages.  In
   addition, the schema for most datastores on a server are often
   closely related.  Given that there are many ways that a datastore
   schema could be represented using packages, the following guidance
   provides a consistent approach to help clients understand the
   relationship between the different datastore schema supported by a
   device (e.g., which parts of the schema are common and which parts
   have differences):

      Any datastores (e.g., conventional configuration datastores) that
      have exactly the same datastore schema MUST use the same package
      definitions.  This is to avoid, for example, the creation of a
      'running-cfg' package and a separate 'intended-cfg' package that
      have identical schema.

      Any datastores (e.g., conventional configuration datastores) that
      have the same datastore schema MUST use the same package
      definitions.[>>JTS: ] Remove this paragraph?
[RW] Oops, yes.

      Common package definitions SHOULD be used for those parts of the
      datastore schema that are common between datastores, when those
      datastores do not share exactly the same datastore schema.  E.g.,
      if a substantial part of the schema is common between the
      conventional, dynamic, and operational datastores then a single
      common package can be used to describe the common parts, along
      with other packages to describe the unique parts of the
      datastore schema.[>>JTS: ] Maybe replace "the datastore schema" with "each datastore schema" ?
[RW] Yes, that is better.

      Common package definitions SHOULD be used for the parts of the
      schema that are common between datastores.[>>JTS: ] Remove this paragraph?
[RW] Yes, sorry, poor editing!

Thanks,
Rob

      YANG modules that do not contain any configuration data nodes
      SHOULD be included in the package for configuration datastores if
      that helps unify the package definitions.

      The packages for the operational datastore schema MUST include all
      packages for all configuration datastores, along with any required
      modules defining deviations to mark unsupported data nodes.  The

Wilton                   Expires August 22, 2020               [Page 12]

Internet-Draft                YANG Packages                February 2020

      deviations MAY be defined directly in the packages defining the
      operational datastore schema, or in separate non referentially
      complete packages.

      The schema for a datastore MAY be represented using a single
      package or as the union of a set of compatible packages, i.e.,
      equivalently to a set of non-conflicting packages being included
      together in an overarching package definition.

From: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Sent: 18 February 2020 18:54
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; Joe Clarke (jclarke) <[email-masked]<mailto:[email-masked]>>; Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Netmod-ver-dt] Today's meeting

Please see below.
Jason

From: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 18, 2020 11:36 AM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Joe Clarke (jclarke) <[email-masked]<mailto:[email-masked]>>; Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Netmod-ver-dt] Today's meeting

Hi Jason,

Please see [RW] inline …

From: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Sent: 18 February 2020 15:51
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; Joe Clarke (jclarke) <[email-masked]<mailto:[email-masked]>>; Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Netmod-ver-dt] Today's meeting

A few comments and suggestions.

(A)
Dynamic datastores may (often?) be comprised of completely separate models than the conventional datastores (i.e. no overlap at all). Also - I'm not sure the formal "MAY" gives the right impression (implies it should normally be the same as conventional). So instead of this:

The schema for non conventional configuration datastores (e.g., dynamic datastores) MAY differ from the schema associated with the conventional configuration datastores, but where a data node exists in multiple datastore schema it MUST have the same type, properties and semantics.  E.g., a dynamic datastore may not support all modules, features, or data nodes supported in the conventional configuration datastores; and it could support additional modules, features, or data nodes that are not supported in the conventional configuration datastores.

how about this:

The schema for non conventional configuration datastores (e.g., dynamic datastores) may completely differ (i.e. no overlap at all) from the schema associated with the conventional configuration datastores, or may partially or fully overlap with the schema of the conventional configuration datastores. A dynamic datastore, for example, may support different modules than conventional datastores, or may support a subset or superset of modules, features or data nodes supported in the conventional configuration datastores. Where a data node exists in multiple datastore schema it MUST have the same type, properties and semantics.
[RW]
Yes, okay.

(B)
I'm a bit unclear from the descriptions below if it is illegal to include any packages in <operational> that aren't also included in the conventional DSes. I *think* NMDA allows the operational DS to be a superset of the config schema (with some deviations) PLUS additional (operational-only) modules right?

[RW]
Yes, NMDA allows operational-only modules to be only be included in the datastore schema for operational.  However, I also think that there is no harm in having the operational-only modules in the configuration datastores as well – they just have no configuration nodes.

So, if the only difference between the datastore schema for running and operation was the addition of extra operational-only modules then I would recommend using the same schema and hence same package for both.

[>>JTS: ] Sure - that helps simplify packages and their associations with datastores.  But then this I'm trying to figure out what we're really trying to say with this statement:

The schema for the operational datastore MUST be a superset of all the configuration datastores, except that some data nodes MAY not be supported.
[RW2]
This was intended to be a rewording/simplification of this paragraph from NDMA, RFC 8342, section 5.3:

   The datastore schema for <operational> MUST be a superset of the
   combined datastore schema used in all configuration datastores,
   except that configuration data nodes supported in a configuration
   datastore MAY be omitted from <operational> if a server is not able
   to accurately report them.

At the limit, the operational DS is allowed to support *none* of the data nodes from the config datastores, but could contain some operational-only nodes. So that means it could be completely different (no overlap) with the config datastores.

  I'd suggest we ignore the subtlety that operational can *not* support some config nodes for the purposes of our packages draft, and just say this for operational:

The schema for the operational datastore is intended to be a superset of all the configuration datastores (i.e. includes all the schema nodes from the conventional configuration datastores).  Additional operational-only modules are allowed to be included in the schema for the operational datastore, but there is no harm in having those in the configuration datastores as well. it is recommended to simply use the same package(s) definitions for both the conventional configuration datastores and the operational datastore.

[RW2]
Okay, I’ve included everything but the last sentence, which really belongs to the second block of statements about how packages should be used.

(C)
These two sentence almost seem to contradict each other:

      Any datastores (e.g., conventional configuration datastores) that
      have the same datastore schema MUST use the same package
      definitions.
[RW]
This says if the schema is *exactly* the same then it MUST be the same package.  This is to avoid someone creating an running-cfg package and an intended-cfg package that have exactly the same schema (which is mandated by NMDA) but different package names or definitions.

[>>JTS: ] OK then let's add that clarification:

Any datastores (e.g., conventional configuration datastores) that have exactly the same datastore schema MUST use the same package definitions. This is to avoid, for example, the creation of a 'running-cfg' package and a separate 'intended-cfg' package that have the same schema.

[RW2]
Okay.

      Common package definitions SHOULD be used for the parts of the
      schema that are common between datastores.
[RW]
This is trying to say, that if say 70% of your schema is common between running, dynamic, and operational, then you SHOULD use common package definitions for those common parts, that would then either be (i) included in datastore specific packages, or (ii) used in conjunction with datastore specific packages to describe the unique parts of the datastore schema.

[>>JTS: ] OK - let's clarify again then:

If datastores don't have exactly the same schema, but have some common overlap with other datastores, then common package definitions SHOULD be used for the parts of the schema that are common between datastores.  i.e. if 70% of the schema is the same between running, dynamic and operational, then use a single common package to describe that 70%, and then other packages to describe the remaining unique parts of the schemas.

[RW2]
I’ve tweaked this to the following:

          <t>Common package definitions SHOULD be used for those parts of the
          datastore schema that are common between datastores, when those
          datastores do not share exactly the same datastore schema.  E.g., if a
          substantial part of the schema is common between the conventional,
          dynamic, and operational datastores then a single common package can
          be used to describe the common parts, along with other packages to
          describe the individual parts of the datastore schema.</t>

Thanks,
Rob

How is the 2nd part different from the first?
[RW]
Does that clarify, do I need to expand this text at all?

Thanks,
Rob

Jason

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Rob Wilton (rwilton)
Sent: Wednesday, February 12, 2020 9:41 AM
To: Joe Clarke (jclarke) <[email-masked]<mailto:[email-masked]>>; Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Netmod-ver-dt] Today's meeting

From: Joe Clarke (jclarke) <[email-masked]<mailto:[email-masked]>>
Sent: 12 February 2020 14:38
To: Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>
Cc: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netmod-ver-dt] Today's meeting

On Feb 12, 2020, at 09:10, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:

Rob, LGTM.

Agreed.  The modified text is clearer.  The bit at the very end still reads oddly to me:

 The schema for a datastore MAY be represented using a single

      package or as the union of a set of compatible packages, i.e.,

      equivalently to the packages being included in a package

      definition together with no conflicts.

“the packages being included in a package” definition.  The word “package” is used a lot in that sentence, and I wonder if it could be tightened.  Maybe, “equivalently to a set of non-conflicting packages being included together in an overarching package definition.”

[RW]
Yes, that is better.  I will pull that in.

Thanks,
Rob

Joe

Regards,
Reshad.

From: "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 12, 2020 at 5:32 AM
To: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Netmod-ver-dt] Today's meeting

Hi Reshad,

Thanks for the review.  A couple of comments inline below [RW}.

From: Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>
Sent: 11 February 2020 21:01
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netmod-ver-dt] Today's meeting

Hi Rob,

  1.  Yes it’d be good to have this change now
[RW]
Okay, I will update that.

  1.  I agree that text for the relationship between packages and datastores would be better placed in the packages draft. Inline.
[RW]
Okay.

From: "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 10, 2020 at 10:38 AM
To: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Netmod-ver-dt] Today's meeting

Having said that, two issues have occurred to me:

  1.  The version selection draft allows a datastore schema to be defined using a set of packages, but the equivalent definition in YANG library only allows the schema to be referenced by a single package.  I think that this needs to be unified, but this could be tracked with an issue and deferred for now.  My hunch is that YANG library reference should also allow for the datastore schema to be defined by a union of compatible packages rather than only a single package.  Perhaps I should just change this now?

  1.  I’ve been thinking a bit more about the relationship between packages and datastores and where that text should live.  I’ve written up some potential text for this, which I think would probably better exist in the packages draft than the version selection draft.  Do you think that it would be reasonable to add the following text to the end of section 5.3?  E.g. a new section 5.3.3 with the following text:

5.3.3.  The relationship between packages and datastores

   As defined by NMDA [RFC8342], each datastore has an associated

   datastore schema.  Sections 5.1 and 5.3 of NMDA defines further

   constraints on the schema associated with datastores.  These

   constraints can be summarized thus:

      The schema for all conventional datastores MUST be the same.

      The schema for non conventional configuration datastores (e.g.,

      dynamic datastores) MAY differ from the schema associated with the

      conventional configuration datastores, but where a data node

      exists in multiple datastore schema it MUST have the same type,

      properties and semantics.  E.g., a dynamic datastore may not

      support all modules, features, or data nodes supported in the

      conventional configuration datastores; and it could support

      additional modules, features, or data nodes that are not supported

      in the conventional configuration datastores.

      The schema for the operational datastore MUST be a superset of all

      the configuration datastores, except that some data nodes MAY not

      be supported.

   Given that YANG packages represent schema, it follows that each

   datastore schema can be represented by a package.  However, there are

   multiple ways that a package representing a datastore can be

   constructed.  The following guidance is provided to make it easier

   for clients to understand the schema relationship between datastores:

 <RR> I don’t understand the last part, do you mean relationship between datastores and schemas?

[RW]

Yes, perhaps something like the following expanded wording would be more clear:

   Given that YANG packages represent a YANG schema, it follows that each

   datastore schema can be represented using packages.  In addition, the schema for most datastores on a server are often closely related.  Given that there are many ways that a datastore schema could be represented using packages, the following guidance provides a consistent approach to help clients understand the relationship between the different datastore schema supported by a device (e.g., which parts of the schema are common and which parts have differences):

Regards,

Reshad.

[RW]

Thanks,

Rob

      Any datastores (e.g., conventional configuration datastores) that

      have the same datastore schema MUST use the same package

      definitions.

      Common package definitions SHOULD be used for the parts of the

      schema that are common between datastores.

      YANG modules that do not contain any configuration data nodes

      SHOULD be included in the package for configuration datastores if

      that helps unify the package definitions.

      The packages for the operational datastore schema MUST include all

      packages for all configuration datastores, along with any required

      modules defining deviations to mark unsupported data nodes.  The

      deviations MAY be defined directly in the packages defining the

      operational datastore schema, or in separate non referentially

      complete packages.

      The schema for a datastore MAY be represented using a single

      package or as the union of a set of compatible packages, i.e.,

      equivalently to the packages being included in a package

      definition together with no conflicts.

Thanks,
Rob

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Reshad Rahman (rrahman)
Sent: 07 February 2020 23:32
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netmod-ver-dt] Today's meeting

Only managed to skim through the draft, ship it. IMO definitely good enough for GW adoption.

Thanks,
Reshad.

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> on behalf of "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 4, 2020 at 12:33 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netmod-ver-dt] Today's meeting

I would like to post the updated YANG packages draft as soon as possible so that folks in the WG have time to read this before we manage to publish the updated version select draft.

I think that the draft is probably good enough to go as is, but if you would like to review it then please can you do so and provide comments by Friday, or otherwise let me know if you need more time.

Thanks,
Rob

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Rob Wilton (rwilton)
Sent: 30 January 2020 11:12
To: [email-masked]<mailto:[email-masked]>
Subject: [Netmod-ver-dt] Today's meeting

Proposed agenda for today’s meeting:

(1)    Discuss timing of publishing the YANG packages draft.  I would like to publish this sooner rather than later, so that folks have an opportunity to digest it before the WG adoption call.
(2)    Continue the discussion on YANG versioning:
a.       We should try and decide whether we want to proceed with the model that I posted this week, or go back to the previous version..
(3)    Discuss next steps to getting an updated version of the document before the WG and request adoption.

Thanks,
Rob

_______________________________________________
Netmod-ver-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod-ver-dt

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 20 Feb 2020 14:20:26 +0000

Hi Bo,

Good catch.

I think that both definitions really amount to the same thing, noting the RFC 8342 defines datastore schema as:

   o  datastore schema: The combined set of schema nodes for all modules
      supported by a particular datastore, taking into consideration any
      deviations and enabled features for that datastore.

But I think that the second definition is potentially better.  I think that we should get an agreed definition into the packages draft, and then reference that from the version selection draft.  Would you be happy to raise a github issue to track this please?

Basically, every package represents a schema (that might be incomplete).  In some cases that schema may also represent a datastore schema, or potentially a union of compatible packages represents a datastore schema.

Thanks,
Rob

From: Wubo (lana) <[email-masked]>
Sent: 20 February 2020 08:31
To: Rob Wilton (rwilton) <[email-masked]>; Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; Joe Clarke (jclarke) <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] Today's meeting

Hi Rob,

Thanks,
Bo
发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Rob Wilton (rwilton)
发送时间: 2020年2月19日 23:24
收件人: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Joe Clarke (jclarke) <[email-masked]<mailto:[email-masked]>>; Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
主题: Re: [Netmod-ver-dt] Today's meeting

Hi Jason,

Updated doc is attached.

Thanks,
Rob

Thx. Pls see below.
Jason

Hi Jason,

Thanks,
Rob

Please see below.
Jason

Hi Jason,

Please see [RW] inline …

(A)

how about this:

(B)

[RW]

[RW2]

(C)

[RW2]
Okay.

[RW2]

Thanks,
Rob

Thanks,
Rob

Jason

Rob, LGTM.

[RW]

Thanks,
Rob

Joe

Regards,
Reshad.

Hi Reshad,

Hi Rob,

      be supported.

[RW]

Regards,

Reshad.

[RW]

Thanks,

Rob

      definitions.

      complete packages.

Thanks,
Rob

Thanks,
Reshad.

Thanks,
Rob

Thanks,
Rob