Hi,
Ladislav Lhotka <[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;
> ...
> }
Working with what we currently have, I think this would look a bit
better if you instead did:
augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
+ "'TLSA')";
container tlsa { // name change
presence "TLSA data";
leaf certificate-usage {
mandatory true;
...
I think the model itself is quite ok with this design, but the
instance data contains the type information encoded twice; once in the
the 'type' leaf and once in the container 'tlsa'. Since the 'type'
leaf is part of the key, it cannot easily be removed.
As for this issue in general, I think we all agreed that it would be
nice if we could allow such data to be mandatory, but noone came up
with any proposal for how to do this. The "safe" use case we
discussed was when the identity was defined in the same module as the
augment, but that is not the case in you module, where all identities
are defined in a central module.
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
