Hi Andy,
On 13/08/2015 17:08, Andy Bierman wrote:
On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
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.
The concepts behind old-manager/new-agent protection mechanisms go back
a couple decades (with SNMP). There is no way that a vendor can
control all
the applications using a particular module, and therefore mandate a
flag-day
upgrade on all clients, in order to upgrade some servers.
Yes, I agree in principle, but I'm not sure whether the default set of
YANG modules has yet reaches the maturity that enforcing this rule truly
makes sense. It feels that many of the YANG modules (even those have
been standardized) are still some what at the experimental stage. This
is effectively the same point that you make below.
YANG is very limited wrt/ adding new functionality,
A designer must guess correctly on all mandatory nodes
on the first version. If this a bug, then it should be fixed
properly, instead of just pretending it's OK to break
existing client apps.
In Lada's case there is no base version, all of his modules are being
newly defined. So, in this scenario, ideally that RR-type specific
modules should be allowed to augment with mandatory nodes since this
must effectively be backwards compatible.
(YANG packages do not fix this problem BTW)
Perhaps we need a new module-level "release" statement.
release stable;
release unstable;
release experimental;
Then all the very strict YANG change control rules can be relaxed on
unstable and experimental modules.
Yes, this may make sense for other scenarios, but I don't see that it
helps with either of the problems that Lada or I have described.
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.
A P-container insulates the old client because it would not know to
create it, and the mandatory child nodes are only checked if
the P-container exists.
Yes, but in Lada's example, the P-container doesn't really help anyone,
since the server has to now handle the case that the RR-type has been
specified but the corresponding P-container isn't present. If it is
possible for the server to handle this scenario then the mandatory child
fields don't have to be mandatory either because some sensible default
must exist. This implies that all servers would likely reject the
configuration as being invalid if the P-container isn't also present.
As I see it, having a P-container here only protects a old client in the
scenario that it was mis-configured in the first place, i.e. using a
particular RR-type without the corresponding mandatory nodes being
specified ... which a sane server should have rejected the config for
previously.
I don't really want to flog a dead horse, but I do think that the
mandatory rule could be relaxed to state that it cannot be used to
introduce non backwards compatible nodes. The text could specify the
specific conditions where it is allowed to be used in a augmentation.
Or, alternatively, perhaps allow for a must statement to simulate a
mandatory keyword in these cases - although I don't think that this
solution is particularly clear or clean.
Thanks,
Rob
To me, in this scenario, it feels that you might as well forego
both the P-container and mandatory marking.
Thanks,
Rob
Andy
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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
