> On 08 Sep 2015, at 10:50, Martin Bjorklund <[email protected]> wrote:
>
> Ladislav Lhotka <[email protected]> wrote:
>> Robert Wilton <[email protected]> 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 <[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?
>>
>> It is allowed in YANG 1.0.
>>
>>>
>>> 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
>>
>> ietf-interfaces could also use the same mandatory choice pattern but
>> it seems too late now. This is an example why the strict module update rules
>> are counter-productive at this stage - instead if adopting the best current
>> practice we have to resort to kludges.
>
> Can you explain what you would like to do with ietf-interfaces, and
> why that is not allowed according to the upgrade rules?
list interface {
key name;
leaf name { … }
leaf type { … }
choice interface-parameters {
mandatory true;
}
}
Lada
>
>
> /martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
