Re: [netmod] Y34 - root node
I like the idea of relocatable modules. It is almost to say everything defined by the IETF should be a grouping, allowing others to assemble the pieces as they see fit. I do not think it makes sense for IETF to define an uber structure, especially using a language mandating forever backwards compatibility... How to support logical/virtual systems is a bigger discussion. Certainly there is a huge data model overlap between the host system and the logical systems, but some data may only exist in the host system and some data may only exist in a logical system. Making things more interesting, some data in the host system (e.g., an interface) can be exported to a logical system as a read-only value. The way I solved this in another life was using conditional enablement [1] on a shared data model to indicate the applicability of nodes in a context. [1] https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 Kent, as a contributor ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y26 again, sorry
Ladislav Lhotka lho...@nic.cz wrote:
On 25 Aug 2015, at 14:48, Martin Bjorklund m...@tail-f.com wrote:
Ladislav Lhotka lho...@nic.cz wrote:
On 25 Aug 2015, at 14:01, Martin Bjorklund m...@tail-f.com wrote:
Hi,
I think this could work (thanks Robert; maybe this is what you
meant!):
container zones {
list zone {
...
list rrset {
...
leaf type {
type identityref { ... }
}
list rdata {
key id;
...
choice type-specific-params {
mandatory true;
// to be augmented with type-specific nodes
}
}
}
}
}
And then in another module:
augment /dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata
+ /type-specific-parameters {
when derived-from-or-self(../dnsz:type,'iana-dns-parameters',
+ 'TLSA');
leaf certificate-usage {
mandatory true;
...
}
}
The empty mandatory choice formally tells the client that additional
cases are expected.
(If the empty choice looks fishy, it is probably often possible to
define at least one case inline...)
This pattern is nice to the client, since there is no way an
additional augmenting module can break a working client.
Yes, I just tried very similar test modules with pyang, and DSDL seems
to validate instance data as expected: at least one case has to be
present, so no valid instance exists for the “abstract” module alone.
I think it is a better approach to subclassing than augment+when.
It is augemnt-choice+when.
when isn’t strictly necessary here because different cases cannot
appear together.
Well, the when statement is needed to make sure that you configure
nodes from a case that matches the specified type.
/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y26 again, sorry
Hi,
I think this could work (thanks Robert; maybe this is what you
meant!):
container zones {
list zone {
...
list rrset {
...
leaf type {
type identityref { ... }
}
list rdata {
key id;
...
choice type-specific-params {
mandatory true;
// to be augmented with type-specific nodes
}
}
}
}
}
And then in another module:
augment /dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata
+ /type-specific-parameters {
when derived-from-or-self(../dnsz:type,'iana-dns-parameters',
+ 'TLSA');
leaf certificate-usage {
mandatory true;
...
}
}
The empty mandatory choice formally tells the client that additional
cases are expected.
(If the empty choice looks fishy, it is probably often possible to
define at least one case inline...)
This pattern is nice to the client, since there is no way an
additional augmenting module can break a working client.
/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] LL review of 6020bis-06
Hi Lada, Thank you for this extensive review! Comments inline. Ladislav Lhotka lho...@nic.cz wrote: Hi, this time I reviewed the complete text so my comments aren't limited to YANG 1.1 stuff. Lada General comments 1. Would it make sense to at least mention that YANG is being used not only for NETCONF and with other encodings? I think so (and I think that was the general consensus in Prague) Details TBD. 2. I think it would be useful to include text (perhaps in sec. 4.2.2) describing the schema tree and data tree, and introducing appropriate terms so that, e.g., nodes in either tree can be clearly distinguished in the subsequent text. In my experience, this causes a lot of confusion. For example, sec. 4.2.2.1 says: ' A leaf node contains simple data like an integer or a string.' And then sec. 7.6: ' The leaf statement is used to define a leaf node in the schema tree.' If the leaf node is in the schema tree, then it cannot contain any value. The leaf statement defines a node in the schema tree. This can be instantiated in a data tree. A leaf node in the data tree contains a simple value. Since section 4.2 is really just intended as an overview, maybe we can s/A leaf node contains/A leaf contains/ (and similar for container)? 3. It's necessary to clearly separate properties of the data tree from properties of XML encoding. For instance, it is an inherent property of a container instance in the data tree that its children are unordered, or ordered in RPC input/output. Yet this is only specified in sec. 7.5.7 (XML Mapping Rules). I think this is a property of the XML encoding, not an inherent property of the container. In JSON, all children are always unordered. Similarly, the namespace of a module and XML namespace that's used in XML encoding are IMO two different things (cf. sec 5.3). Yes. Do you have any specific edits in mind? 4. Terms instance/instantiate/instatiation are used in a loose way without being properly defined, probably as SNMP legacy. The XML term instance document adds yet another meaning. I'm not sure these are SNMP specific terms. I thought they were more generic. Do you have any proposed edits? 5. A term is needed for describing a data model of a particular server, i.e. a collection of modules + supported features (+ deviations). I've used data model, see https://github.com/mbj4668/pyang/wiki/Tutorial#yang-data-model The term data model is already used in a much more generic way in 6020. server YANG data model maybe. 6. As Jürgen suggested, sections XML Mapping Rules should be more appropriately called XML Encoding Rules. Fixed. 7. I'd remove all mentions of submodules including other submodules, circular includes etc. because it is now confusing. If include is ignored in submodules, there is no need to bother with any rules. This sentence in sec. 7.1.6 should be enough: 'For backward compatibility with YANG version 1, the include statement is permitted in a submodule but has no effect there.' I found only this sentence: Submodules are only allowed to include other submodules belonging to the same module. which I have now removed. Sec. 3 - Shouldn't the term data tree also cover the contents of RPC input/output, actions and notifications? Yes, probably. But then we need to have a term for some of the current usages of data tree. Maybe datastore works (this term is already used). Sec. 4.2.2.3 OLD A container may contain any number of child nodes of any type (including leafs, lists, containers, and leaf-lists). NEW A container may contain any number of child nodes of any type (leafs, lists, containers, leaf-lists, and actions). Fixed. Sec. 4.2.9 - Include an example of action? Fixed. Sec. 5.2 - The last paragraph about separate compilation of submodules looks like an implementation detail and could perhaps be removed. Fixed. Sec. 5.5 s/closest matching/matching/ (because definitions of groupings/typedefs cannot shadow an equally named grouping/typedef in an outer scope) Fixed. Sec. 5.6.4 - OLD A server implements a module if it implements the module's data nodes, rpcs, notifications, and deviations. NEW A server implements a module if it implements the module's data nodes, rpcs, actions, notifications, and deviations. - s/augement/augment/ - spurious string '#}}' at the end. Fixed. Sec. 6.1.3 I think the rules for whitespace trimming are confusing and have very little practical
Re: [netmod] Y26 again, sorry
Randy Presuhn randy_pres...@mindspring.com writes:
Hi -
From: Ladislav Lhotka lho...@nic.cz
Sent: Aug 24, 2015 11:44 AM
To: Andy Bierman a...@yumaworks.com
Cc: netmod@ietf.org netmod@ietf.org
Subject: Re: [netmod] Y26 again, sorry
...
YANG does not provide any mechanism to REQUIRE modules A and B
to both be implemented on a server. You may think it should, but
currently the YANG conformance is for an individual module.
There are sections on conformance and conformance announcement,
and they say nothing like this. In my view, the data model comprises
*all* modules advertised by the server. I think your interpretation
of conformance might be an extrapolation from SNMP/SMI times, but,
for better or worse, it really has no support in the YANG spec.
It sounds as though you might be talking past each other.
I believe part of Andy's point is that clients will need to deal
with servers that do not implement (and thus do not advertise)
the augmenting module. But there's (I think) a more interesting
issue beneath this.
As I understand it, the restriction on mandatory nodes in augments
addresses the opposite situation where the server addresses both the
original and augmenting module, whereas the client supports only the
original one.
Let's start with module M. Let's say M is for modem (to pick
an obsolete but widely understood resource).
Two different augmenting modules, F (for FSK - frequency
shift keying) and Q (for QAM - quadrature amplitude modulation)
are developed. Let us say that F and Q are mutually incompatible.
A system with multiple Ms could well have both M+F and M+Q modems,
but (if we claim F Q are incompatible) could not have M+F+Q.
A solution could be similar to what ietf-interfaces does:
list modem {
key name;
leaf name { ... }
leaf type { ... }
...
}
F and G would then augment the modem list, for example:
augment /.../M:modem {
when M:type = 'FSK';
...
}
Module M can also implement the concept of system-controlled modem
entries.
The server then may advertise M+F or M+Q or M+F+Q depending on the
supported technologies.
Of course, the author of module M has to anticipate that there may be
multiple modems of different types. If M only has
container modem { ... }
then we are stuck.
The problem with the above approach is that either F or Q may need some
mandatory parameters to be configured for which no (static) defaults
exist - but this condition cannot be properly specified in the data
model. That's what this thread is about.
If naked M is to be prohibited in systems (also) supporting F or Q
or both, we don't currently have a mechanism to do so.
I don't know whether naked M exactly needs to be prohibited (as an
abstract class). It causes no harm, as naked ietf-interfaces, only
it is of limited use because there isn't much to be configured. A server
implementor should have an idea about what needs to be configured, and
will therefore add one or more augmenting modules that will be
advertised along with M.
Lada
Randy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] issue and question: YANG short-case-stmt in augment-stmt or uses-augment-stmt
Hi Martin,
as far as I can tell, these groupings are OK, and pyang also doesn't
complain.
Ahoj, Láďa
Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)
mcig...@cisco.com writes:
Hello
I've come across a yang module which defines a short-case-stmt in
augment-stmt or uses-augment-stmt
Something like this:
grouping grp1 {
uses grp2 {
augment mychoice {
leaf myleaf1 {
type string;
}
}
}
}
grouping grp2 {
choice mychoice {
leaf myleaf2 {
type string;
}
}
}
Based on my findings in RFC6020 and errata, this is invalid and there should
be only full case-stmt in augment/uses-augment.
Can you confirm please? Many thanks in advance.
Best Regards
Martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y34 - root node
From: Andy Bierman, Friday, August 21, 2015 10:28 AM snip Currently we have a proprietary way of relocating YANG modules, and ODL has its mount, and I think Andy has some other mechanism. Maybe the time has come to standardize how mount works, and maybe then also standardize the list of devices in a controller model. It seems there are many places where mount is being used effectively. I am all for some standard syntax. +1 We just need to standardize a docroot within a docroot. This is not relocation of subtrees within the datastore, this is just mounting a datastore somewhere within a parent datastore. In YANG validation terms, you simply adjust the docroot to the nested mount point, and the replicated datastore can be used as if it were stand-alone. This would allow any sort of encapsulation of datastores and not add any data model complexity to devices which do not have virtual servers (most of them). Compared to the mount draft, I would like to decouple the schema information from the instance population mechanism. I.e., I'd like a mechanism that simply defines the schema, not necessarily how the data is populated (in the mount draft data was fetched from a remote server, but IMO that is just one of several use cases). Yes, I agree that these could/should be decoupled. Although I note that the mount draft does also allow for local mounts, although this does not seem to be intended to be the mainline case. The mount draft was indeed driven by OpenDaylight's use cases. In ODL, mount is used for local YANG representation of remote device information. Based on this I believe a generalized mount syntax should not mandate that the target must be local and cannot be remote. Nor should a generalized mount syntax itself restrict whether the target node contain schema or instance info. There are many ways beyond the syntax if an implementation has no desire for this. Eric ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] issue and question: YANG short-case-stmt in augment-stmt or uses-augment-stmt
Hello
I've come across a yang module which defines a short-case-stmt in augment-stmt
or uses-augment-stmt
Something like this:
grouping grp1 {
uses grp2 {
augment mychoice {
leaf myleaf1 {
type string;
}
}
}
}
grouping grp2 {
choice mychoice {
leaf myleaf2 {
type string;
}
}
}
Based on my findings in RFC6020 and errata, this is invalid and there should be
only full case-stmt in augment/uses-augment.
Can you confirm please? Many thanks in advance.
Best Regards
Martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y26 again, sorry
On 25 Aug 2015, at 14:48, Martin Bjorklund m...@tail-f.com wrote:
Ladislav Lhotka lho...@nic.cz wrote:
On 25 Aug 2015, at 14:01, Martin Bjorklund m...@tail-f.com wrote:
Hi,
I think this could work (thanks Robert; maybe this is what you
meant!):
container zones {
list zone {
...
list rrset {
...
leaf type {
type identityref { ... }
}
list rdata {
key id;
...
choice type-specific-params {
mandatory true;
// to be augmented with type-specific nodes
}
}
}
}
}
And then in another module:
augment /dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata
+ /type-specific-parameters {
when derived-from-or-self(../dnsz:type,'iana-dns-parameters',
+ 'TLSA');
leaf certificate-usage {
mandatory true;
...
}
}
The empty mandatory choice formally tells the client that additional
cases are expected.
(If the empty choice looks fishy, it is probably often possible to
define at least one case inline...)
This pattern is nice to the client, since there is no way an
additional augmenting module can break a working client.
Yes, I just tried very similar test modules with pyang, and DSDL seems
to validate instance data as expected: at least one case has to be
present, so no valid instance exists for the “abstract” module alone.
I think it is a better approach to subclassing than augment+when.
It is augemnt-choice+when.
when isn’t strictly necessary here because different cases cannot appear
together. The schema is much cleaner, which is also immediately visible on the
tree output.
I agree it solves the subclassing use case, but it has its
limitations. For example, you cannot have two separate modules
augment with the same type. But then, in such a case you can
still to the old augment-p-container+when.
I am not sure I understand exactly what you mean but perhaps the second
augmenting module could then augment the case node in the first augment.
Lada
/martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y26 again, sorry
On 25 Aug 2015, at 14:01, Martin Bjorklund m...@tail-f.com wrote:
Hi,
I think this could work (thanks Robert; maybe this is what you
meant!):
container zones {
list zone {
...
list rrset {
...
leaf type {
type identityref { ... }
}
list rdata {
key id;
...
choice type-specific-params {
mandatory true;
// to be augmented with type-specific nodes
}
}
}
}
}
And then in another module:
augment /dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata
+ /type-specific-parameters {
when derived-from-or-self(../dnsz:type,'iana-dns-parameters',
+ 'TLSA');
leaf certificate-usage {
mandatory true;
...
}
}
The empty mandatory choice formally tells the client that additional
cases are expected.
(If the empty choice looks fishy, it is probably often possible to
define at least one case inline...)
This pattern is nice to the client, since there is no way an
additional augmenting module can break a working client.
Yes, I just tried very similar test modules with pyang, and DSDL seems to
validate instance data as expected: at least one case has to be present, so no
valid instance exists for the “abstract” module alone.
I think it is a better approach to subclassing than augment+when.
Lada
/martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y26 again, sorry
Ladislav Lhotka lho...@nic.cz wrote:
On 25 Aug 2015, at 14:01, Martin Bjorklund m...@tail-f.com wrote:
Hi,
I think this could work (thanks Robert; maybe this is what you
meant!):
container zones {
list zone {
...
list rrset {
...
leaf type {
type identityref { ... }
}
list rdata {
key id;
...
choice type-specific-params {
mandatory true;
// to be augmented with type-specific nodes
}
}
}
}
}
And then in another module:
augment /dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata
+ /type-specific-parameters {
when derived-from-or-self(../dnsz:type,'iana-dns-parameters',
+ 'TLSA');
leaf certificate-usage {
mandatory true;
...
}
}
The empty mandatory choice formally tells the client that additional
cases are expected.
(If the empty choice looks fishy, it is probably often possible to
define at least one case inline...)
This pattern is nice to the client, since there is no way an
additional augmenting module can break a working client.
Yes, I just tried very similar test modules with pyang, and DSDL seems
to validate instance data as expected: at least one case has to be
present, so no valid instance exists for the “abstract” module alone.
I think it is a better approach to subclassing than augment+when.
It is augemnt-choice+when.
I agree it solves the subclassing use case, but it has its
limitations. For example, you cannot have two separate modules
augment with the same type. But then, in such a case you can
still to the old augment-p-container+when.
/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
