Hi Lada,
I agree with you in that I don't really understand how having a
p-container solves the problem of a mandatory node, since as you say the
p-container could just be left out so to me it seems that any child node
marks as mandatory isn't truly mandatory anyway!
I have a similar issue in the YANG that I have defined in
draft-wilton-netmod-intf-ext-yang-00 (reproduced below) for defining the
nature of a sub-interface.
Basically, I would like the model to enforce the rule that every child
sub-interface must have a parent, but I can't currently really see a
satisfactory solution to this problem. My working assumption is that I
would end up describing the field as being mandatory, but not mark it as
mandatory in YANG (obviously), and assume that backend servers would
enforce that the leaf is present when the configuration is verified.
But I'm open to any better suggestions that folks may have on how to
model this :-)
<snip from draft-wilton-netmod-intf-ext-yang-00
/*
* Add generic support for sub-interfaces.
*
* This should be extended to cover all interface types that are
* child interfaces of other interfaces.
*/
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:l2vlan' or
if:type = 'ianaift:atmSubInterface' or
if:type = 'ianaift:frameRelay'" {
description
"Any ianaift :types that represent sub-interfaces";
}
if-feature "sub-interfaces";
description "Add a parent interface field to interfaces to model
sub-interfaces";
leaf parent-interface {
type if:interface-ref;
/*
* TODO - How to make this mandatory without using the
* mandatory keyword.
* - Current options appear to be:
* - Create a sub-interface container with presence.
* - Enforce the constraint with a must statement.
*/
//mandatory true;
description
"This is the mandatory reference to the parent interface of
this sub-interface.";
}
}
Thanks,
Rob
On 13/08/2015 15:07, Ladislav Lhotka wrote:
Hi,
although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted
solution Y26-02 is really horrible, so at least I want to make sure the
WG is aware of the consequences.
I am currently working on a data model for DNS zone data and the schema
is like this:
module: dns-zones
+--rw zones
+--rw zone* [name]
+--rw name inet:domain-name
+--rw description? string
+--rw class? ianadns:class
+--rw rrset* [owner type]
+--rw owner inet:domain-name
+--rw type identityref
+--rw description? string
+--rw ttl positive-int32
+--rw rdata* [id]
+--rw id string
+--rw description? string
The idea is that specific RDATA will be added for each RR type (with a
"when" condition based on "type"). Data for essential RR Types (SOA, NS,
A, AAAA, ...) can be defined in the same module but for some types they
need to be defined in other modules and added via augmenting the target
node "rdata". Typically, some (or all) of RDATA is mandatory, and this
is where Y26 comes into play. The solution recommended by Y26-02 would
look like this:
augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
+ "'TLSA')";
container rdata { // <=================
presence "TLSA data";
leaf certificate-usage {
mandatory true;
...
}
...
}
}
Note the superfluous presence container "rdata". It that just adds a
useless level of hierarchy and still doesn't enforce the correct
constraints: the data model allows the presence container to be missing
so that RDATA will be empty. Defining this extra container for all ~75
RR types is a nuisance and it certainly won't make the modules more
readable.
As this situation is likely to be very common, I wonder: do we really
want to do that?
[1] https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27
Thanks, Lada
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
