Minutes for NETMOD at interim-2014-netmod-9
minutes-interim-2014-netmod-9-1
| Meeting Minutes | Network Modeling (netmod) WG | |
|---|---|---|
| Title | Minutes for NETMOD at interim-2014-netmod-9 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2015-02-26 |
minutes-interim-2014-netmod-9-1
=============================================================
NETCONF Data Modeling Language WG (netmod)
4th YANG 1.1 Virtual Interim
Wednesday, September 3rd, 2014, 16:00-18:00 CEST
Minutes Juergen Schoenwaelder
=============================================================
* Participants
- JS = Juergen Schoenwaelder
- MB = Martin Bjorklund
- PO = Peyman Owladi
- DR = David Reid
- BC = Benoit Claise
- AB = Andy Bierman
- LL = Ladislav Lhotka
- MJ = Mahesh Jethanandani
* Y09 introduce optional keys
PO: Why is at least one key element required?
PO: What if in an xpath expression suddenly evaluates to a node set
rather than a single node?
MB: We need to extend the instance-identifier syntax to be able to
express that a certain key element is absent.
PO: Right now, an instance-identifier is valid xpath, we should
not diverge from it.
JS: If you allow to add an optional key while revising a YANG
module, does this not potentially affect other modules? Does
this at the end require import by revision everywhere?
JS: The concern is breaking the contract when adding an optional
key, but this is likely the most interesting use case.
MB: Yes, this may be problematic. Perhaps we should not allow to
change the key statement, i.e., optional keys can't be added
later on.
JS: You can have optional keys today by designing special 'null'
values for optional key elements.
MB: The primary use case is not necessarily YANG module updates.
The workarounds you mention as possible today but they are
clumsy.
AB: Does this proposal affect error-path?
MB: No, error-path is already an xpath expression. As long as
instance-identifier remain a subset of xpath, this will work.
Proposal: adopt Y09-02 but do not allow leafs to be added to a key
in a module update and the instance-identifier syntax needs to be
extended to express that certain key elements have no value.
* Y34 remove/deprecate/replace the 'anyxml' statement
LL: Why do we need anydata at all?
MB: There are use cases for anyxml although rare.
JS: Example: Kent's configlets.
MB: Example: Definition of edit-config.
AB: I have something we call a docroot, something that holds
a top-level YANG node.
JS: What is the difference between docroot and the proposed anydata?
AB: The docroot is anydata restricted to top-level YANG nodes.
MB: Since NETCONF is defined using anyxml, changing anyxml is
changing the protocol.
LL: Leave anyxml as it is.
LL: But this is hard for JSON.
MB: That is the reason why I propose to add anydata, which may be
easier to deal with.
AB: The reason implementations do not support mixed mode or PIs is
to avoid passing raw data to callbacks and hence everything is
restricted to a few types in the implementations I am familiar
with.
AB: I support anyxml but make it clear that it is non-interoperable.
LL: Yes, and I propose to leave it completely open how anyxml is
represented in JSON.
MB: If we keep anyxml and mark it as should not be used, do we even
have to translate anyxml into JSON?
MB: If we have anydata, why can't you follow the usual JSON rules?
AB: It seems to work for us, except every value is JSON encoded as a
string.
LL: You need to know the difference between a list and a container.
AB: My implementation hands the tree to the application.
AB: We only use docroot in RPC definitions and everything else is
theoretical and of no practical use.
MB: There is one other use case: A list say containing the last N
notifications. It is still not anyxml but anydata.
LL: We could have simpler rules for anydata that work like generic
XML to JSON translators.
MB: What about namespaces? I think we need them.
LL: I am not sure we need them.
AB: So how do the many online XML to JSON translators work?
LL: They use arbitrary solutions for things like namespaces.
MB: The translator needs all the data models. I personally think
this is fine.
JS: For ncclient, the interface to the lower layer is typeless and
it is a significant change to make it type aware etc.
AB: Our server will convert things as needed and basically ignore
the JSON type.
LL: I started with what is the most natural representation. Otherwise,
what is the value of JSON?
AB: For me, the value is that JSON is more compact data encoding. I
do not care about having type information in the encoding. Our
code has no interest to reject data just because the JSON type
was wrong. Making JSON types authoritative seems backwards.
LL: What about making it legal to allow sending integers as strings?
JS: If I am allowed to send strings, the world changes for me.
MB: This also solves the problem of dealing with numbers in unions.
MB: In edit-config, it is not just XML elements but also attributes.
JS: So we have to keep anyxml for these rare corner cases (typically
the definition of RPCs). But we should have big warnings about
the usage of anyxml in data models and instead introduce
anydata.
MB: Even if we allow encoding of values as strings and require that
the receiver be able to translate to the proper YANG type, we
still have the namespace problem.
LL: What is the problem with normal data?
MB: You need the mapping URI to YANG module name.
JS: A URI is not something ugly. In fact, you use the YANG namespace
statement to define the namespace.
LL: URIs tend to be longer than module names and they can contain
more 'interesting' characters.
JS: But the URI character set is restricted.
LL: A URI can contain colons so the separate colon cannot be
used.
JS: Yes, we need to pick a different delimiter. Some use
{<uri>}name. I do not care much which character is used.
JS: I am concerned that using two different identifiers to identify
what is essentially the same namespace adds complexity for no
real value. Even operationally, when people are confronted with
JSON and XML snippets, they are exposed to different identifiers
for the same thing. I do not see how that makes things simpler.
Proposal: Keep anyxml and add text that usage of anyxml in regular
data models is generally not interoperable and that anyxml should
only be used in certain special cases (e.g., the definition of
NETCONF RPCs). Add an anydata statement that is restricted to data
that can be defined using YANG. For the JSON mapping, allow string
encoding and require the receivers are expected to do type
conversions in case the JSON type does not match the YANG type
instead of treating a JSON type mismatch as an error. For anydata,
the JSON encoding should be well defined.
No agreement has been reached yet on the handling of namespaces,
that is whether module names or URIs should be used.