Speaking as co-chair:
Hold on a minute. As a point of order, our process with the Yang 1.1
issue processing has been very clear: we debate/discuss the issues on the
interim calls in order, then propose the outcome that the design team came up
with to the list each time. There is a “last call” period when
debate/discussion with the NETMOD WG can take place after which the issue is
closed and will
not be debated again.
Looking at this issue, it was discussed/debated and is now closed as of
2015-04-17.
http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27
Let us please stop debating this issue as it is closed.
—Tom
> On Aug 13, 2015:3:43 PM, at 3:43 PM, Ladislav Lhotka <[email protected]> wrote:
>
>
>> On 13 Aug 2015, at 21:31, Andy Bierman <[email protected]> wrote:
>>
>> Hi,
>>
>> IMO this is issue is closed.
>> I see no reason to re-open it.
>> YANG does not allow augments to add mandatory nodes.
>
> I strongly disagree with this attitude, this is a normal IETF procedure.
> Things can be changed even during WGLC.
>
> Virtual interims aren’t good for discussing non-trivial technical issues.
>
> Lada
>
>>
>>
>> Andy
>>
>>
>> On Thu, Aug 13, 2015 at 12:22 PM, Ladislav Lhotka <[email protected]> wrote:
>>
>>> On 13 Aug 2015, at 19:44, Robert Wilton <[email protected]> wrote:
>>>
>>> Hi Andy,
>>>
>>> On 13/08/2015 17:08, Andy Bierman wrote:
>>>>
>>>>
>>>> On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton <[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.
>>
>> Right. Another thing is that augment was IMO originally intended to allow
>> for adding optional or vendor-specific parameters to a base data model.
>> However, as it turned out, it is in fact used as an essential tool for
>> developing *base* data models in a modular fashion.
>>
>> I have also argued several times that a client cherry-picking modules
>> advertised by the server is fundamentally unsafe - it may work but may also
>> break things.
>>
>>>
>>>>
>>>> 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.
>>
>> It doesn’t, it is just hand-waving.
>>
>>>
>>>>
>>>>
>>>>
>>>> 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.
>>
>> We tried to identify such situations but it is not that easy. I think the
>> restriction should be removed and explain backward compatibility issues in
>> 6087bis. Module authors then have to decide whether a certain node needs to
>> be defined as mandatory.
>>
>> If we clutter new modules with unnecessary p-containers, there will be no
>> way back.
>>
>>>
>>> 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.
>>
>> Exactly, it is an ugly hack to the same effect.
>>
>> Lada
>>
>>>
>>> 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]> 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]
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>>
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>>
>>>
>>
>> --
>> 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
