Subject: [Rtg-yang-coord] container with presence

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 May 2015 11:28:44 +0200

Hi,

I have a suggestion for the authors of all routing protocol modules: the container that encapsulates all configuration data for a given protocol should be a container with presence (see sec. 7.5.1 in RFC 6020) because then the configuration data may include mandatory items that are otherwise forbidden at the top level of an augment.

See also YANG 1.1 issue Y26:

https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27

For example, in the the ietf-isis it should look like this:

     augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
         +"rt:routing-protocol" {
       when "rt:type = 'isis:isis'" {
         description
          "This augment is only valid when routing protocol
           instance type is isis.";
       }
       presence "IS-IS routing protocol”;
       ...
     }

I am also including this recommendation in the routing-cfg draft.

Lada
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 May 2015 11:33:10 +0200

Sorry, the example is wrong, the presence statement should of course be inside the container:

     augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
         +"rt:routing-protocol" {
       when "rt:type = 'isis:isis'" {
         description
          "This augment is only valid when routing protocol
           instance type is isis.";
       }
       description
        "This augments a routing protocol instance with ISIS
         specific parameters.";
       container isis {
         presence "IS-IS routing protocol";
         ...
       }
     }

Lada

> On 28 May 2015, at 11:28, Ladislav Lhotka <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 28 May 2015 07:18:06 -0400

Lada: 

Thank you for this suggestion. How would you suggest the I2RS yang models for I2RS RIB, I2RS Topology, and I2RS FB-RIB use the 

     augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
         +"rt:routing-protocol" {
       when "rt:type = 'i2rs:i2rs'" {
         description
          "This augment is only valid when routing protocol
           instance type is i2rs.";
       }
       presence "I2RS routing protocol”;
       ...
     }

 If a modules depends on L1 TEAS model or l2  how should this be tested? 

Sue 

-----Original Message-----
From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Thursday, May 28, 2015 5:29 AM
To: [email-masked]
Subject: [Rtg-yang-coord] container with presence

Hi,

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 May 2015 13:42:41 +0200

Hi Sue,

> On 28 May 2015, at 13:18, Susan Hares <[email-masked]> wrote:
> 
> Lada: 
> 

These models don’t define routing protocols, so why should they augment "rt:routing-protocol”?

However, the use of presence containers is a common workaround for all situation where mandatory data are needed inside an augment. Another example is the if:interface list in the ietf-interfaces module, where config data for a specific interface type (augmented into the list from another module) might include mandatory items.

Another solution that doesn’t need an extra presence container is to use a “must” statement. 

> If a modules depends on L1 TEAS model or l2  how should this be tested?

Sorry, I don’t understand, what exactly do you want to test?

Lada

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 28 May 2015 13:38:24 -0700

And the error that will pop up as result will be something like this:

Warning: top-level NP container ‘twamp-client' is mandatory
ietf-twamp.yang:59.9: warning(1048): top-level object is mandatory

> On May 28, 2015, at 2:28 AM, Ladislav Lhotka <[email-masked]> wrote:
> 
> Hi,
> 

Mahesh Jethanandani
[email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 May 2015 18:28:29 +0200

> ietf-twamp.yang:59.9: warning(1048): top-level object is mandatory

This is actually something else, the case I am writing about leads to
this error message in pyang:

knot-dns.yang:322 (at knot-dns.yang:169): error: cannot augment mandatory node record-type

(and it is a hard error rather than warning).

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 29 May 2015 09:50:03 -0700

> (and it is a hard error rather than warning).

It is not an error to augment a mandatory node.
It is an error to augment any node with mandatory nodes.
Big difference.

> Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 May 2015 19:38:11 +0200

> On 29 May 2015, at 18:50, Andy Bierman <[email-masked]> wrote:
> 

Right, but it is a linguistic problem, ‘record-type’ is a mandatory node inside the augment statement, not the target node.
The error message should thus read "cannot augment with mandatory node record-type”.

Thanks for catching it, I’ve corrected it in the source.

Lada

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 29 May 2015 16:13:43 -0400

Lada:

A clearer example, is the I2RS BGP modules is dependent on the BGP protocol.   How would you use a "must" to require the BGP protocol exist.  The L1 portion of the I2RS topology model may be dependent on the L1 TEAS definitions.   How would you write that dependency in the yang module? 

If there is an RFC or draft I should read, just point it out. 

Sue 

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Thursday, May 28, 2015 7:43 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Rtg-yang-coord] container with presence

Hi Sue,

Lada