Hi Randy,

On 24/08/2015 20:20, Randy Presuhn wrote:
Hi -

From: Ladislav Lhotka <[email protected]>
Sent: Aug 24, 2015 11:44 AM
To: Andy Bierman <[email protected]>
Cc: "[email protected]" <[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.

I can point you to a concrete example if it helps.

Thanks,
Rob



Randy

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod


_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to