Re: [yang-doctors] Ensuring top/base models are designed as augmentable

Including Joe Clarke in the loop.
As OPSAWG chair, Joe took the AI to follow up with the YANG doctors in 
order to find the best solution for the TACACS+ YANG model.

Regards, Benoit
> On Nov 18 08:52 AM, Martin Bjorklund wrote:
>> Ebben Aries <exa@arrcus.com> wrote:
>>> I was looking for any such possible wording in 8407 but could not find
>>> anything around this design consideration.
>>>
>>> Case in point, there are many modules that may be defined with top-level
>>> nodes where the intention is that other domains add/augment in either at
>>> a later date or at a bare minimum via another set of
>>> definitions/modules in related domains.  When this occurs, it seems
>>> important that the top level modules are designed in such a way to
>>> account for such augmentation and to pick on one case, is the use of
>>> 'must' statements in top-level modules.
>>>
>>> If we look at ietf-system below, for authentication, there are 2
>>> definitions carried in the top-level module (local-users/radius) with a
>>> must restriction being placed at a node which is a target candidate for
>>> augmentation.
>>>
>>> # ietf-system@2014-08-06.yang
>>>
>>>      container authentication {
>>>        nacm:default-deny-write;
>>>        if-feature authentication;
>>>
>>>         description
>>>           "The authentication configuration subtree.";
>>>
>>>         leaf-list user-authentication-order {
>>>           type identityref {
>>>             base authentication-method;
>>>           }
>>>           must '(. != "sys:radius" or ../../radius/server)' {
>>>             error-message
>>>               "When 'radius' is used, a RADIUS server"
>>>             + " must be configured.";
>>>             description
>>>               "When 'radius' is used as an authentication method,
>>>                a RADIUS server must be configured.";
>>>           }
>>>           ordered-by user;
>>>
>>> Now if one were to augment in with say 'tacacs' which would define an
>>> identity that would base off sys:authentication-method, this would
>>> either mean
>>>
>>> - Any augmented identities cannot follow the same design pattern as
>>>    those in the base module
>> Can you provide an example of what you want to do and show what
>> doesn't work?  From what I understand, it seems you can add the nodes
>> you want, but you can't just augment a must expression:
>>
>>            must '(. != "x:tacacs" or ../../x:tacacs/server)'
> The question is more generic wrt. ensuring nodes are augmentable or some
> verbiage around such otherwise there could very well be cases that a
> base restriction prevents and/or makes this difficult either for other
> future SDO modules or other implementation augments.
>
> For this specific case - that is precisely it as you have above.  The
> augmented module cannot enforce similar restrictions for design
> consistency sake
>
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors
> .
>