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 <[email protected]
<mailto:[email protected]>> wrote:
Hi Randy,
On 24/08/2015 20:20, Randy Presuhn wrote:
Hi -
From: Ladislav Lhotka <[email protected] <mailto:[email protected]>>
Sent: Aug 24, 2015 11:44 AM
To: Andy Bierman <[email protected]
<mailto:[email protected]>>
Cc: "[email protected] <mailto:[email protected]>"
<[email protected] <mailto:[email protected]>>
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?
Unfortunately (2) won't work for my model augmentation issue, of wanting
to enforce that a sub-interface has to have a parent interface-ref. As
a recap, the yang from my interfaces-common draft is:
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:l2vlan' or
if:type = 'ianaift:atmSubInterface' or
if:type = 'ianaift:frameRelay'" {
description
"Any ianaift :types that represent sub-interfaces";
}
if-feature "sub-interfaces";
description "Add a parent interface field to interfaces to model
sub-interfaces";
leaf parent-interface {
type if:interface-ref;
/*
* TODO - How to make this mandatory without using the
* mandatory keyword.
* - Current options appear to be:
* - Create a sub-interface container with presence.
* - Enforce the constraint with a must statement.
*/
//mandatory true;
description
"This is the mandatory reference to the parent interface of
this sub-interface.";
}
}
One suggestion that I've heard is based on a specific instance of your
first condition above, where the when statement only uses identities
defined by the same augmenting module:
I.e. don't use the existing "ianaift:l2vlan" for a VLAN sub-interface,
but define a new interface type identity "vlan-sub" in my interface
extensions module which would inherit from "iftype:l2vlan". Similarly
for atmSubInterface and frameRelay. Obviously, at the moment, this is
not allowed, but potentially it could be, and it is still safe to
existing clients (since they can't be using the new type).
However, I'm not really sure whether fragmenting the list of iftypes
into separate modules would be a good idea ...
Thanks,
Rob
I can point you to a concrete example if it helps.
Thanks,
Rob
Andy
Randy
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
