Minutes for NETMOD at interim-2014-netmod-18
||Minutes for NETMOD at interim-2014-netmod-18
NETCONF Data Modeling Language WG (netmod)
9th YANG 1.1 Virtual Interim
Wednesday, December 03, 2014, 16:00-18:00 CET
Minutes Juergen Schoenwaelder
- 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
* 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
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
- 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
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
- AB: It may be OK to use anyxml within extensions (e.g. the mount
* 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.