Robert Wilton <rwil...@cisco.com> 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 <rwil...@cisco.com
>> <mailto:rwil...@cisco.com>> wrote:
>>
>> Hi Randy,
>>
>> On 24/08/2015 20:20, Randy Presuhn wrote:
>>
>> Hi -
>>
>> From: Ladislav Lhotka <lho...@nic.cz <mailto:lho...@nic.cz>>
>> Sent: Aug 24, 2015 11:44 AM
>> To: Andy Bierman <a...@yumaworks.com
>> <mailto:a...@yumaworks.com>>
>> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>"
>> <netmod@ietf.org <mailto:netmod@ietf.org>>
>> 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.
> a recap, the yang from my interfaces-common draft is:
>
> 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.
... which doesn't make the parent-interface mandatory anyway.
> * - Enforce the constraint with a must statement.
Yes, but this design offers no good place for it, you'd need to use an
extra np-container and attach the must statement to it.
> */
> //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).
I think it would be best to make backward old-client compatibility a
general guideline rather than a hard language rule. Currently it is
enforced in some cases (augments, module update rules) but a mere
guideline in other cases (must statements, extensions, defaults).
Lada
>
> 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
>> netmod@ietf.org <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
