Ladislav Lhotka <lho...@nic.cz> wrote:
>
> > On 18 Aug 2015, at 13:09, Martin Bjorklund <m...@tail-f.com> wrote:
> >
> > Hi,
> >
> > Ladislav Lhotka <lho...@nic.cz> 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;
> > …
>
> Right, using the same name for the presence container won’t work if
> rdata for multiple rr types are defined in the same module.
>
> But the main problem still remains: container “tlsa” needn’t be
> present, which leads to an invalid resource record. The server would
> have no choice but reject such configuration. I don’t get how this
> helps old clients.
Well, if it doesn't make any sense to configure an rrset of e.g. type
'TLSA' without the 'tlsa' container, I don't expect such clients to be
deployed in the network.
The rule about not augmenting mandatory nodes is there to protect
properly functioning clients. For example, suppose you have your tlsa
module and a client that knows this and works well. Then some vendor
writes a new module that also augments some mandatory nodes when the
type is 'TLSA'. Then the client that used to work doesn't work
anymore.
/martin
>
> >
> > 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.
>
> … as it is with interface types.
>
> I think it would be better to remove the restriction altogether. If a
> parameter is mandatory by its substance, it should be defined as
> mandatory in the data model. And if somebody wants to break old (or
> someone else’s) clients, there are other ways for achieving it.
>
> Lada
>
> >
> >
> > /martin
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
