Hi Lada,
On 08/09/2015 09:16, Ladislav Lhotka wrote:
Robert Wilton <rwil...@cisco.com> writes:
Hi Andy,
Picking up a slightly old thread after PTO ...
On 24/08/2015 22:50, Andy Bierman wrote:
On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>> wrote:
Hi Randy,
On 24/08/2015 20:20, Randy Presuhn wrote:
Hi -
From: Ladislav Lhotka <lho...@nic.cz <mailto:lho...@nic.cz>>
Sent: Aug 24, 2015 11:44 AM
To: Andy Bierman <a...@yumaworks.com
<mailto:a...@yumaworks.com>>
Cc: "netmod@ietf.org <mailto:netmod@ietf.org>"
<netmod@ietf.org <mailto:netmod@ietf.org>>
Subject: Re: [netmod] Y26 again, sorry
...
YANG does not provide any mechanism to REQUIRE modules
A and B
to both be implemented on a server. You may think it
should, but
currently the YANG conformance is for an individual
module.
There are sections on conformance and conformance
announcement,
and they say nothing like this. In my view, the data model
comprises
*all* modules advertised by the server. I think your
interpretation
of conformance might be an extrapolation from SNMP/SMI
times, but,
for better or worse, it really has no support in the YANG
spec.
It sounds as though you might be talking past each other.
I believe part of Andy's point is that clients will need to deal
with servers that do not implement (and thus do not advertise)
the augmenting module. But there's (I think) a more interesting
issue beneath this.
Let's start with module M. Let's say M is for "modem" (to pick
an obsolete but widely understood resource).
Two different augmenting modules, F (for FSK - frequency
shift keying) and Q (for QAM - quadrature amplitude modulation)
are developed. Let us say that F and Q are mutually incompatible.
A system with multiple Ms could well have both M+F and M+Q modems,
but (if we claim F & Q are incompatible) could not have M+F+Q.
If naked M is to be prohibited in systems (also) supporting F or Q
or both, we don't currently have a mechanism to do so.
Could this be achieved by augmenting from a choice statement?
M defines the choice statement but with no case statements.
F and Q both implement separate case statements that augment the
choice statement in M. The case statements have containers which
hold the parameters related to F or Q.
M without F or Q is meaningless.
M+F or M+Q works, but the choice statement means that you cannot
have M+F+Q.
nice solution
This is perhaps the cleanest way to add mandatory nodes to a module.
The old client will not attempt to create the new case.
As I said before, I am OK with changing MUST NOT to SHOULD NOT
add mandatory nodes, and then add MAY when X, Y, Z conditions are met.
Two conditions so far:
(1) augment + when <new flag set that old client will not set>
(2) augment choice with a new case-stmt
(1) is hard to define, but not (2)
So, Lada is using (2) for DNS zones which works. Does the Y26 text need
to be updated to explicitly allow this, or is this implicitly allowed
anyway?
It is allowed in YANG 1.0.
I was thinking that this would still fall foul of the RFC 6020 section
7.15 rule:
If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes (seeSection 3.1 <#section-3.1>).
But presumably, this statement is only intended to refer to the top
level nodes that are by added by the augmentation statement rather than
all nodes that are being added (which the current wording seems to imply
to me).
Thanks,
Rob
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
