> On 08 Sep 2015, at 17:48, Robert Wilton <[email protected]> wrote:
>
>
>
> On 08/09/2015 14:25, Ladislav Lhotka wrote:
>>> 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;
>> }
>> }
>
> I'm not sure that it helps for my sub-interface parent leaf problem, since I
> would ideally like the same parent-if-ref leaf to exist for multiple if:types
> (e.g. Frame, ATM, VLANs) with the same namespace. But unless VLANs + ATM +
> Frame Relay are all defined in the same module (which wouldn't seem a very
> natural thing to do) then they would end up in different namespaces, and
> hence not be so usable.
This could probably be done by defining an interface type as kind of superclass
for all interface types that need parent-if-ref and then derive all concrete
interface types (Frame Relay, ATM, VLANs) from it. A corresponding augment then
would be, e.g.,
augment “/if:interfaces/if:interface/if:interface-parameters/“ {
when “derived-from(../if:type, ‘mymod’, ‘child-interface’)”;
container child-interface {
leaf parent-if-ref {…}
}
}
Concrete interface types could then add specific nodes by augmenting the
child-interface container.
Lada
>
> Thanks,
> Rob
>
>
>>
>> Lada
>>
>>>
>>> /martin
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> .
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
