Minutes for NETMOD at interim-2014-netmod-19
||Minutes for NETMOD at interim-2014-netmod-19
NETCONF Data Modeling Language WG (netmod)
10th YANG 1.1 Virtual Interim
Wednesday, December 17, 2014, 16:00-18:00 CET
Minutes Juergen Schoenwaelder
JS = Juergen Schoenwaelder
LL = Lada Lhotka
MB = Martin Bjorklund
AB = Andy Bierman
DR = David Reid
JT = Jason Sterne
BC = Benoit Clais
BL = Balazs Lengyel
KW = Kent Watsen
DR = Dan Romascanu
* Status Check
- Y09 introduce optional keys
Need to validate adoption of Y09-03 on the mailing list.
- Y16 module advertisement optimization
Need to validate adoption of Y16-03 on the mailing list.
- Y18 fix "when" expression context problem
Pending action MB => action to be completed
- Y59 restrict use of 64-bit numbers in XPath expressions
Moved to open, perhaps discuss resolution?
- Y25 make enum numbering purely informative and optional
JS to start a thread on the mailing list. There once was rough
consensus for Y25-01 - we need to check what happens on the list.
- Y26 allow mandatory nodes in augment
Pending action LL => action done
- Y58 associate an actions with a data node
Pending action JS (check with NETCONF chairs concerning NACM update).
- Y34 remove/deprecate/replace the 'anyxml' statement
Need to verify Y34-04 on the mailing list and that it can handle
all existing meaningful uses of anyxml.
- Y49 clarify nested submodule behavior
Need to validate adoption of Y49-04 on the mailing list.
- Y57 non-unique leaf-list
There was an action item for BL on 2014-10-15 => action to be completed
- Y45 better conformance mechanism
How to resolve this? Do we need to collect the requirements a
solution must satisfy? It sometimes feels like going in circles on
* Y45 better conformance mechanism
JS: We seem to go in circles, can we collect use cases to verify
solution proposals against?
MB: Yes, we seem to go in circles.
AB: Using import-by-revision everywhere is one solution, but it has a cost.
AB: I wanted to move conformance out of the YANG module, conformance
is specified separate from the objects.
BL: Simplifying assumptions may be needed (only one version per module)
AB: Do we agree on one module per server?
MB: Only one module where you implement data nodes.
KW: Import by revision resolves which version of a type has been used.
MB: This may lead to massive updates if a type module changes.
JS: Lets distinguish between (a) a modular server implementing multiple
versions within a module and (b) different modules importing from
different versions of some other module.
MB: Import by revision does not solve the problem.
MB: The problem is two augmenting modules importing the augmented
module at different revision numbers.
KW: RFC6020 says must statement can be relaxed, it is silent about
when statements, perhaps an errata?
AB: Phil said that if B augments A, then a server needs to implement A
KW: If you have a module A that imports only groupings from B, then the
server does not need to claim implementing B
BL: We use a lot of imports without import-by-revision.
MB: This may be a maintenance issue.
AB: There is already some confusion about what needs to be announced.
KW: You can add a must statement to a new node, but you can't add a
stricter statement to an existing node.
BL: But you can break the rules by side effects.
BL: I like to know which version of a typedef module is actually
MB: The requirement is that the client can understand which version
of a typedef module is actually used by a module.
AB: Perhaps keep it simple - if you change a grouping, you have to
give it a new name.
KW: Lets collect statements (axioms) we agree on (or not).
A0. Claiming conformance means that the server implements all
protocol-accessible nodes, rpcs, notifications (modulo supported
features). It does not include aspects that are not directly
accessible, including typedefs, identities, and groupings.
A1. A server can only claim conformance (i.e., implement the
data-nodes, rpcs, notifications) to one revision of a specific
module at a time.
A2. A server does not need to claim conformance to a module that was
only imported by other modules for purposes other than augment.
A3. A server must claim conformance to a module if it is imported by
another module for the purpose of an augment statement by
another module the server claims conformance to.
A4. The version of all imported items including typedefs, groupings,
etc. must be visible to the client.
BL: We need to maintain backwards compatibility since management
systems are very hard to update.
LL: But backwards compatibility rules hard coded in the language
limit flexibility where needed.
AB: I agree with BL, we need to be most concerned about software updates.
AB: The cost of being wrong can be high, so try to check the modules
well before publishing them.
KW: I believe vendors will implement functionally overlapping modules.
MB: What is in that case the response to a get-config?
KW: Without a namespace, you get the default module set, otherwise
the namespace defines what is returned to a client.
KW: The developers of submodules may use imports at different revision
BL: This may be fine for the developers, but how does an operator deal
KW: I assume the operator's code is data model driven. The
import-by-revision will tell them which imported definition was used.
AB: In a module, you can't import a module multiple times. But this
happens with submodules if they import at different revisions.
BL: I do not like to allow importing different revisions of A in
MB: But it depends on the solution. We need to work out the use cases
and evaluate the solution against use cases.
BL: RFC 6020 says multiple revisions imported in a module is not
supported. It is not clear whether this applies to modules and/or
AB: You can only have conformance to things that are protocol
LL: A server advertises the identities it implements by advertising
the module where the identity is defined.
JS: I do not think this is valid for say iana-interface-types.
AB: The set of identity values that can be used is a runtime issue.
KW: Is this not similar to groupings?
MB: No, because the value is used (or not) at runtime.
MB: Use an RPC to discover possible values at runtime.
LL: The problem is the IANA interface type list, the identities should
be defined in type specific modules.
BL: Even with specialized modules, we will see the problem again. At
the end, every identity ends up in a separate module.
AB: Line cards often have specific constraints and we need to be
able to deal with this.
BL: There are also license restrictions that apply.
AB: The problem is when import-by-revision is mixed with import
KW: We need to distinguish the different types of imports (import
for just groupings/typdefs/etc vs import for augment).
- MB volunteers to kick of the process of collecting use-cases and