Hi Andy, Lada,
On 13/08/2015 15:46, Andy Bierman wrote:
Hi,
I'm not sure how many times we need to go over this issue...
YANG conformance is based on the YANG module.
YANG has no concept of conformance beyond this
simplistic approach, You cannot assume (ever, under any conditions)
that module foo AND bar will both be present on a server.
Therefore if a client is written to work with "foo", it has no
responsibility at all to know that "bar" adds a mandatory
node to a "foo" subtree.
The extra P-container is needed to make sure clients written
to work with module "foo" do not break when new nodes are
added via augments.
I still don't see how a P-container really solves the problem since any
child mandatory nodes aren't really mandatory, or at least not in the
way that is actually intended.
E.g. in Lada's example having the P-container implies that for a given
RR type it is acceptable to either not provide any extra RR specific
config (i.e. no P-container), or if RR specific config is provided then
some fields must always be provided, and others can be left out. I.e.
the P-container also needs to be mandatory for the configuration to be sane.
To me, in this scenario, it feels that you might as well forego both the
P-container and mandatory marking.
Thanks,
Rob
We already decided not to do anything useful wrt/ Y45,
so we are stuck with the YANG module as the unit of conformance.
Andy
On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka <[email protected]
<mailto:[email protected]>> 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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
