Re: [netmod] Y26 again, sorry

[Andy Bierman <[e-mail]>]

On Mon, Sep 7, 2015 at 10:13 AM, Robert Wilton <[e-mail]> wrote:

> 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 <[e-mail]> wrote:
>
>> Hi Randy,
>>
>> On 24/08/2015 20:20, Randy Presuhn wrote:
>>
>>> Hi -
>>>
>>> From: Ladislav Lhotka <[e-mail]>
>>>> Sent: Aug 24, 2015 11:44 AM
>>>> To: Andy Bierman <[e-mail]>
>>>> Cc: "[e-mail]" <[e-mail]>
>>>> 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?
>
> 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 a
> recap, the yang from my interfaces-common draft is:
>



Your example shows the YANG conformance problems fairly well.
Clearly the IETF (and others) want to use advanced design patterns
in which conformance to the base module (M) is insufficient to describe
the actual API requirements.

YANG uses revision dates to identify versions.
There is no such thing as a major vs. minor revision.
I agree with Lada that it is possible to have major revision update
where the old clients should not be used anymore.

I already suggested relaxing the MUST NOT to a SHOULD NOT,
wrt/ adding mandatory nodes.


 Andy


>   augment "/if:interfaces/if:interface" {
>     when "if:type = 'ianaift:l2vlan' or
>           if:type = 'ianaift:atmSubInterface' or
>           if:type = 'ianaift:frameRelay'"  {
>       description
>         "Any ianaift :types that represent sub-interfaces";
>     }
>     if-feature "sub-interfaces";
>     description "Add a parent interface field to interfaces to model
>                  sub-interfaces";
>     leaf parent-interface {
>       type if:interface-ref;
>       /*
>        * TODO - How to make this mandatory without using the
>        * mandatory keyword.
>        * - Current options appear to be:
>        *   - Create a sub-interface container with presence.
>        *   - Enforce the constraint with a must statement.
>        */
>       //mandatory true;
>       description
>         "This is the mandatory reference to the parent interface of
>          this sub-interface.";
>     }
>   }
>
>
> One suggestion that I've heard is based on a specific instance of your
> first condition above, where the when statement only uses identities
> defined by the same augmenting module:
> I.e. don't use the existing "ianaift:l2vlan" for a VLAN sub-interface, but
> define a new interface type identity "vlan-sub" in my interface extensions
> module which would inherit from "iftype:l2vlan".   Similarly for
> atmSubInterface and frameRelay.  Obviously, at the moment, this is not
> allowed, but potentially it could be, and it is still safe to existing
> clients (since they can't be using the new type).
>
> However, I'm not really sure whether fragmenting the list of iftypes into
> separate modules would be a good idea ...
>
> Thanks,
> Rob
>
>
>
> I can point you to a concrete example if it helps.
>>
>> Thanks,
>> Rob
>>
>>
>>
>>>
>
> Andy
>
>
>
>> Randy
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>