Ladislav Lhotka <[email protected]> wrote: > > > On 18 Aug 2015, at 15:42, Martin Bjorklund <[email protected]> wrote: > > > > Ladislav Lhotka <[email protected]> wrote: > >> > >>> On 18 Aug 2015, at 13:09, Martin Bjorklund <[email protected]> wrote: > >>> > >>> 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; > >>> … > >> > >> 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. > > Then it would be better at least to define TLSA identity together with > rdata for TLSA rr, rather than having all identities defined in one > place.
Yes, and *maybe* it would be possible to come up with either text that allows such an augmentation, or a new YANG statement to handle this situation. /martin > > 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. > > It seems we all agree that, using Randy’s terminology, subclassing > augments are OK. We only can’t reliably identify such augments because > YANG uses “poor man’s” subclassing. > > You are arguing against mandatory extension augments but then: > > 1. A standard module might need to be patched by adding a mandatory > parameter, which is currently impossible via both augment and module > update, > > 2. The rogue vendor can use a must statement to achieve the same > effect (or perhaps just state it in a description?). What’s important > is whether the server that advertises such an extension rejects a > configuration where the new parameter is missing or not. > > Lada > > > > > > > /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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
