> 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. > > 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. 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
