Subject: [yang-doctors] YANG module statement

From: Benoit Claise <[email-masked]>
Date: Tue, 26 Jul 2016 17:53:57 +0200

Dear YANG doctors,

The RTG and OPS ADs came up with this guidance:

    YANG modules SHOULD NOT be structured to include nodes/leaves to
    indicate applied configuration
    If the YANG module is sufficently advanced, it MAY be structured to
    include nodes/leaves to indicate applied configuration.
    If you do so, you SHOULD place nodes/leaves that are specific to the
    applied configuration in a model augmentation

    We would like to thank the RT design team for the excellent suggestion.

Note: Lou being THE person making this statement happen, and checking 
with TEAS, PCE, MPLS (and CCAMP)

We would like to validate this sentence with you: "you SHOULD place 
nodes/leaves that are specific to the applied configuration in an model 
augmentation". Lou can explain the details, if necessary.

So any strong objection to this guidance? The end goal is to have an 
email sent on behalf of the RTG and OPS ADs, posted soon, ideally 
tomorrow evening.

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jul 2016 18:16:19 +0200

On Tue, Jul 26, 2016 at 05:53:57PM +0200, Benoit Claise wrote:
> Note: Lou being THE person making this statement happen, and checking with
> TEAS, PCE, MPLS (and CCAMP)
> 
> So any strong objection to this guidance? The end goal is to have an email
> sent on behalf of the RTG and OPS ADs, posted soon, ideally tomorrow
> evening.

Yes, I have a strong objection since terms are undefined (i.e.,
'applied configuration', 'sufficiently advanced'). A policy using
undefined terms is for me useless. So who is going to decide whether a
leaf is 'applied configuration' or not? Who is going to decided
whether a model is 'sufficiently advanced'?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 26 Jul 2016 18:29:19 +0200

On 7/26/2016 6:16 PM, Juergen Schoenwaelder wrote:
> leaf is 'applied configuration' or not?
basically, we don't want to duplicate all the leafs, like openconfig did.
> Who is going to decided
The ADs. Example: IDR BGP has got multiple implementations already. What 
do we do with this?
The SHOULDs are there to leave the door open for very particular cases.

Regards, B.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Jul 2016 09:37:29 -0700

On Tue, Jul 26, 2016 at 9:29 AM, Benoit Claise <[email-masked]> wrote:

>>> email

IMO this is a good solution approach.
We know the "official solution" is not done yet, so the details
are not resolved yet.  That does not matter.
Using augment makes it possible to undo the mirror-solution
and also allow vendors to decide if/when to do that. Very clever.

Regards, B.
>> /js

Andy

> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jul 2016 19:22:18 +0200

> basically, we don't want to duplicate all the leafs, like openconfig did.

We have duplicated several leafs in ietf-interfaces. Please clarify
whether your policy targets duplication (i) inside a single tree or
(ii) at the leaves of a tree or (iii) at two different roots (i.e.,
the /foo and /foo-state model) or a certain combination of the three
or all of them. I just can't tell from the way the policy is worded.

> The ADs. Example: IDR BGP has got multiple implementations
> already. What do we do with this?  The SHOULDs are there to leave
> the door open for very particular cases.

You mean draft-ietf-idr-bgp-model-02.txt? This document needs updates
anyway to turn it from openconfig models into IETF models and that
likely will require implementations to change; perhaps the early
implementors are better off publishing the openconfig models they
implement as Informational or Experimental documents.

But back to the topic, perhaps clarify in the policy that the ADs
(that is the respective area ADs and the OPS AD together) decide what
is 'sufficently advanced'.

/js