Hi -
> From: Andy Bierman
> Sent: Sep 9, 2015 12:10 PM
> To: Ladislav Lhotka
> Cc: Robert Wilton , Randy Presuhn , "[email protected]"
> Subject: Re: [netmod] Y26 again, sorry
...
> I don't think it really addresses the design pattern very well.
> You want to claim that M and Q are both being developed at the
> same time,so it's OK that Q adds mandatory nodes to M. YANG
> has no such rule.YANG says a server can implement M and never
> implement Q.YANG says a server may implement M and then add Q
> in a future release.These conformance mechanisms do not align
> with your expectationsof how YANG can/should be used.
I agree with Andy that there seems to be a mismatch in expectations.
Let's look at a slightly more complex hypothetical case to tease
out how folks *want* things to work. Assume the following have
been defined:
- base module M
- augmentation Q
- augmentation R
On a server claiming to supporting the modules containing M, Q,
and R, respectively, which of the following might one encounter
concurrently?
- plain M
- M+Q
- M+R
- M+Q+R
If the answer is "any of the them" (which is what I'd expect)
how can the modeler exclude specific combinations, and would
these exclusions be testable as part of a conformance check?
If the answer is anything other than "any of them", how does
the modeler go about making it possible to handle equivalents
to the excluded cases, in the event that someone actually does
need to support functionality equivalent to the excluded cases?
I think this matters because the question of mandatory stuff
within an augmentation appears to really be a stand-in for
making an augmentation (at least conditionally) mandatory,
as well as naturally leading to questions about "non-instantiable"
stuff done for modeling convenience.
I think Andy is very right to be concerned about this, because
this is another aspect of the old question of deciding just how
different two things can be before we give up on trying to claim
that they are two instances of the same class or in some weaker
sense "compatible".
Randy
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
