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

"Susan Hares" <shares@ndzh.com> Fri, 29 May 2015 20:13 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8191E1A872E for <rtg-yang-coord@ietfa.amsl.com>; Fri, 29 May 2015 13:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.455
X-Spam-Level:
X-Spam-Status: No, score=-98.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_29=0.6, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRrDxtAnQ2Fn for <rtg-yang-coord@ietfa.amsl.com>; Fri, 29 May 2015 13:13:46 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id F092A1A871B for <Rtg-yang-coord@ietf.org>; Fri, 29 May 2015 13:13:45 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112;
From: "Susan Hares" <shares@ndzh.com>
To: "'Ladislav Lhotka'" <lhotka@nic.cz>
References: <331A2562-6D35-4D49-911E-9881CCE5D6A1@nic.cz> <00a701d09937$f8edf620$eac9e260$@ndzh.com> <07EA8763-056F-4BD3-B7F1-8B6647B486A6@nic.cz>
In-Reply-To: <07EA8763-056F-4BD3-B7F1-8B6647B486A6@nic.cz>
Date: Fri, 29 May 2015 16:13:43 -0400
Message-ID: <002201d09a4b$f657ac70$e3070550$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGMdBhPp/EGgcFyBhqWIKEwxi/HrQLvNFuFAh9TqYGd8zp2AA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/B0fy-REbusbUaeBtCX488ZWaIuk>
Cc: Rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] container with presence
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" <rtg-yang-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-yang-coord/>
List-Post: <mailto:rtg-yang-coord@ietf.org>
List-Help: <mailto:rtg-yang-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2015 20:13:47 -0000

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:lhotka@nic.cz] 
Sent: Thursday, May 28, 2015 7:43 AM
To: Susan Hares
Cc: Rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] container with presence

Hi Sue,

> On 28 May 2015, at 13:18, Susan Hares <shares@ndzh.com> wrote:
> 
> 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 

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. 
 

> 
> 
>     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?

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

Lada

>  
> 
> 
> Sue 
> 
> -----Original Message-----
> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Ladislav Lhotka
> Sent: Thursday, May 28, 2015 5:29 AM
> To: Rtg-yang-coord@ietf.org
> Subject: [Rtg-yang-coord] container with presence
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> 

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