Randy Presuhn <[email protected]> writes:
> 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.
As I understand it, the restriction on mandatory nodes in augments
addresses the opposite situation where the server addresses both the
original and augmenting module, whereas the client supports only the
original one.
>
> 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.
A solution could be similar to what "ietf-interfaces" does:
list modem {
key name;
leaf name { ... }
leaf type { ... }
...
}
F and G would then augment the "modem" list, for example:
augment "/.../M:modem" {
when "M:type = 'FSK'";
...
}
Module M can also implement the concept of system-controlled modem
entries.
The server then may advertise M+F or M+Q or M+F+Q depending on the
supported technologies.
Of course, the author of module M has to anticipate that there may be
multiple modems of different types. If M only has
container modem { ... }
then we are stuck.
The problem with the above approach is that either F or Q may need some
mandatory parameters to be configured for which no (static) defaults
exist - but this condition cannot be properly specified in the data
model. That's what this thread is about.
> 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.
I don't know whether naked M exactly needs to be prohibited (as an
"abstract class"). It causes no harm, as naked "ietf-interfaces", only
it is of limited use because there isn't much to be configured. A server
implementor should have an idea about what needs to be configured, and
will therefore add one or more augmenting modules that will be
advertised along with M.
Lada
>
> Randy
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
