Skip to main content

Minutes for NETMOD at interim-2015-netmod-5
minutes-interim-2015-netmod-5-1

Meeting Minutes Network Modeling (netmod) WG
Title Minutes for NETMOD at interim-2015-netmod-5
State Active
Other versions plain text
Last updated 2015-03-05

minutes-interim-2015-netmod-5-1
=============================================================
NETCONF Data Modeling Language WG (netmod)
14th YANG 1.1 Virtual Interim
Wednesday, March 4th, 2015, 16:00-18:00 CET
Minutes Juergen Schoenwaelder
=============================================================

* Participants:

  JS = Juergen Schoenwaelder
  MB = Martin Bjorklund
  KW = Kent Watsen
  AB = Andy Bierman
  DR = Dan Romascanu
  LL = Lada Lhotka

* Y45 better conformance mechanism

  JS provided a solution proposal that was discussed and a bit fine
  tuned during the discussion. This will be added to the issue list
  as solution Y45-02.
  
    Scope of the work:

    - A conformance framework for defining conformance that can cut
      through sets of modules (and their features) may be needed at
      some point in time but it seems that this can be done later once
      there is more experience and such a conformance framework is not
      required to solve in YANG 1.1.

    Simple solution:

    - Typedefs must not change their value space or semantics. If this
      is needed, a new typedef needs to be created. This does not
      affect the ability to make bug fixes.

    - Groupings must not change their structure or semantics. If this
      is needed, a new grouping needs to be created. This does not
      affect the ability to make bug fixes.

    - Leafs can have their value space extended but this is not
      automatic.

    - The definition of 'deprecated' and 'obsolete' may need some
      clarification, the wording borrowed from SMIv2 may not be
      precise enough for configuration management.

    - We can consider to define RPCs that allow to retrieve possible
      value sets for certain types (or leafs?). But this does not have
      to be part of the YANG 1.1 specification; this could also be
      part of the YANG library (and such RPCs might even be an
      optional feature).

  Discussion
	
  AB: This could lead to corner cases for enums that get updated
      regularly.
  MB: But in such cases, identities might be a better option.
  MB: Can we allow to add enums if they are scoped by a new feature?
  KW: This seems to be OK.
  AB: But the client has no control if the feature is enabled, so this
      can't be done.
	 
  MB: Does this imply that import-by-revision is not needed anymore?
  JS: Probably simplest to leave import-by-revision as is. It likely
      won't be used anymore since importing a specific revision does
      not add value (the latest revision always works). It merely
      documents which revision was used when a module was published.
	 
  AB: What about include-by-revision?
  MB: This may still be useful. I usually use include-by-revision but
      never import-by-revision.
	 
  AB: What about augment drift?
  MB: I believe an import-by-revision in this case means
      import-by-min-revision.
  AB: I may have must statements in my augmenting module that make
      assumptions about the value space of the leafs being augmented.
  AB: There probably should be guidelines how to write must statements
      that are update friendly.
	 
  MB: Instead "if module implemented it needs to be advertised" write
      "if module advertised it has been implemented" to allow in the
      future to add other ways to define and communicate conformance.

  MB: If I have a new conformance mechanism and I only implement a
      module partially, do I still advertise the module?
  JS: No, you do not implement the module so you do not advertise
      it. You likely advertise the new future conformance statement
      instead.

  MB: Any NETCONF specific text needs to be clearly marked since protocols
      may differ how announcements are implemented.
 
  AB: On constrained devices, the YANG library may not be local to the
      device.

  Everybody seemed to be OK with Y45-02. JS to add it to the issues list
  and to start a verification on the list.

* Y34 remove/deprecate/replace the 'anyxml' statement

  AB: anyxml is terminal, there is no schema data within anyxml,
      except when we use it that way since we have no other choice.
  AB: I think my current thinking aligns with what the proposal is.
  
  KW: The logical extension of anyxml would be anyblob.
  JS: But this should be avoided since the goal is interoperability.
  LL: I like anyblob, anyxml was just a misnomer.
  MB: But in YANG patch, we do not want anyblob - we want YANG data.
  AB: I need the server to be encoding independent and I do not want
      encoding specific information in the schema.
  AB: Inside the server, there is no encoding. Encoding is something
      that happens when data is serialized.
  MB: LL, can you live with the current proposal?
  LL: Yes. But even with anydata we might not have a complete solution.
  MB: It is important to define how anydata is encoded in the various
      encodings, it is not an issue if the encoding of anyxml is not
      well defined in all encodings.
  
  Everybody seemed to be OK with Y34-05. JS to try another consensus
  call on the mailing list.

* Y18 fix "when" expression context problem

  MB: Shall we verify Y18-01 on the mailing list?
  LL: I think I made some comments on the mailing list. I think your
      proposal is to introduce a temporary context node.
  MB: When would there be multiple instances? I guess leaf-lists. This
      may be a corner case.
  LL: I think the text should deal with the situation if there are
      multiple context nodes.
  MB: Your proposed text says if there is one, use it. If not, create
      a temporary one. Does it matter if there are multiple candidates?
  LL: I think we should say something, even if it is pick one of the many.
  MB: I will update the issue with this input.
  AB: If the particular node has instances, then the instances are evaluated.
  
  Like last time, we tasked MB and LL to work out a new proposal that
  covers the corner cases.

* Y25 make enum numbering purely informative and optional

  LL: OK with declaring this dead if protocols start using the numeric
      value. MB should update the text that other encodings may use
      the numeric values.
  MB: Perhaps remove all encoding specific discussion and statements
      that the numeric value is not used.
	
  Everybody seems to be happy with Y25-02.