Skip to main content

Minutes for NETMOD at interim-2014-netmod-18

Meeting Minutes Network Modeling (netmod) WG Snapshot
Title Minutes for NETMOD at interim-2014-netmod-18
State Active
Other versions plain text
Last updated 2015-02-26

NETCONF Data Modeling Language WG (netmod)
9th YANG 1.1 Virtual Interim
Wednesday, December 03, 2014, 16:00-18:00 CET
Minutes Juergen Schoenwaelder

* Participants

  - AB = Andy Bierman
  - BL = Balazs Lengyel
  - DR = David Reid
  - IB = Ignas Bagdonas
  - JS = Juergen Schoenwaelder
  - LL = Lada Lhotka
  - RP = Reinaldo Penno

* Y09 introduce optional keys

  Martin did writeup Y09-03. On 2014-11-19, we agreed to Y09-03. This
  should be a quick check that we are still in sync on this. There was
  quite some mailing list discussion as well. It seems this boils down
  to the question whether expanding the syntax of instance identifiers
  falls into the scope of YANG 1.1.
  - LL: The not() assumption was false.
  - BL: I prefer the solution which requires default values.
  - JS: I have concerns about solutions that require to change the
        instance identifier syntax - this may be outside the scope
        of YANG 1.1.
  Proposal: Adopt Y09-03 and we will see whether this validates on the
  mailing list.

* Y16 module advertisement optimization

  Martin has done his action item and we should try to decide between
  Y16-01, Y16-02, and Y16-03.
  - BL: I am happy with Y16-03.
  - LL: A YANG 1.0 implementation won't understand this advertisement.
  - AB: A YANG 1.1 client won't look at a YANG 1.1 module.
  - JS: The "MUST either advertise them as before, or advertise something
        like" text is confusing, it seems the advertisement should be
        mandatory for 1.1.
  - AB: YANG 1.0 modules will continue to be advertised as before.
  - BL: Does this require an update of RFC 6244?
  - JS: The sentence in section 2.1 of RFC 6244 should be OK.

  Proposal: Adopt Y16-03 (replace the word 'hash' with module set
  identifier) and move this issue to VRFY.

* Y18 fix "when" expression context problem

  Did Martin complete the action item? If so, can we wrap this up?
  - JS: Pending action, skipped discussion of this issue.

* Y59 restrict use of 64-bit numbers in XPath expressions

  New issue, no reaction on the mailing list so far. Should we propose
  adoption as a bug fix / clarification issue?
  - JS: Is the proposal to declare expressions with these types illegal?
  - LL: Not, it should be more a warning about possible consequences.
  - LL: May even belong to the security considerations section.
  - AB: My code does not always convert to doubles but I need to check.
  - AB: It is hard to make this an error.
  - JS: Probably we need to warn that in general numbers are converted
        to doubles and thus rounding errors may also cause issues in 
        other contexts.
  Proposal: Move this to open. LL to propose new text.

* Y25 make enum numbering purely informative and optional

  Last time we discussed this we reached rough consensus for
  Y25-01. Shall we try to resolve this on the list? If so, JS to
  create a thread, e.g., to VRFY adoption of and then we will see.
  - AB: There is a new xpath function proposed to return the number.
  - AB: I am not happy with this auto-numbering feature, we need to
        support it but it is not used in NETCONF or RESTCONF.
  - AB: However, one use case may be the COMI draft.
  Action: JS to start a thread on the mailing list and then we will
  see whether there is consensus.

* Y26 allow mandatory nodes in augment

  Discussion on the list went into philosophical aspects. The question
  is whether someone can write down rules in which conditions adding
  mandatory nodes in an augment is OK. Volunteers for a homework?
  - LL: I think it is difficult to write this text.
  - LL: An indentityref may point to an for the client unknown
  - BL: This is similar to expanding value ranges.
  - LL: I suggest to simple remove this constraint and to trust module
        authors that they are not going to break things.
  - LL: I propose to add text to the usage guidelines to tell people
        to not break modules.
  - AB: We need to maintain contract rules.
  - AB: Mandatory nodes can not be required for anything an old client
        is doing.
  - AB: The template with the client provided discriminator works, not
        sure how to put this into text.
  - LL: But I can also break rules with must statements.
  - AB: Yes, there are other ways to break things. That is why this
        needs to be conditional.
  - JS: Having tools to flag things that potentially break things is a
        good thing.
  Action: LL to draft some text and then we can work on it.

* Y58 associate an actions with a data node

  Verification failed since there is no NACM support for actions nor
  are actions part of the NETCONF architecture (Andy).  Phil questions
  the need for actions since everything can be done with RPCs. Changed
  back to OPEN. Need to decide how to proceed with this one.
  - LL: Is this possible to do in RESTCONF?
  - AB: We would use a RESTCONF post to an /operations resource.
  Action: JS to talk to the NETCONF chairs whether such a NACM update
  can be chartered if NETMOD has otherwise agreement to support actions.

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

  Quite some debate on the mailing list. Apparently some think anydata
  means 'any data in the encoding used' while others think 'anydata is
  data that can be modeled in YANG'. Andy suggested to restrict what
  can be in anyxml. We also see differences in opinion what the
  function of an encoding really is. Another obstacle are the lexical
  representation rules for instance-identifier (9.13.3 of RFC 6020).
  - LL: I think anydata is any data conforming to the underlying
  - JS: I think this is interesting but problematic. What is the value
        of an object that contains XML or JSON or CBOR or ...?
  - BL: Back in a day, we wanted to allow config modeled in XML.
  - AB: In YANG 1.0, we tried to treat anyxml as if it would be a
        leaf. I do not think tail-f supports it at all.
  - JS: MB proposed to have anydata that is always bound to the rules
        of things expressable in YANG.
  - AB: We produce a hierarchy of nodes in JSON for anyxml, everything
        is a container or a string and we have no problem with round trip
  - LL: In XML you can have attributes, PIs etc.
  - AB: I believe the useful uses of anyxml are actually not a type
        but a statement to declare a root of a subtree.
  Proposal: Go with Y34-04, need to check whether this causes issues
  to any of the current usages of anyxml.
  - AB: We only allow usage of root only in notifications / RPCs, not
        in datastores.
  - AB: It may be OK to use anyxml within extensions (e.g. the mount
        use case).

* Y49 clarify nested submodule behavior

  Need to discuss Martin's solution proposal Y49-03.
  - LL: I added Y49-04.
  - AB: MB said that submodules can be compiled on their own.
  - AB: I prefer to make things simpler.
  - BL: I believe with LL and data hiding between submodules is
        something we do not need.
  - AB: There should only be a single namespace.
  Adopt solution proposal Y49-04? Need to check with MB.