Re: [netmod] Using augment to overwrite an existing definition?

Jan Lindblad <janl@tail-f.com> Tue, 10 April 2018 08:58 UTC

Return-Path: <janl@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC2F1273E2 for <netmod@ietfa.amsl.com>; Tue, 10 Apr 2018 01:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 8E1jPVwq7ZPc for <netmod@ietfa.amsl.com>; Tue, 10 Apr 2018 01:57:57 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E81F512420B for <netmod@ietf.org>; Tue, 10 Apr 2018 01:57:56 -0700 (PDT)
Received: from [10.147.40.111] (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id 2B65A1AE00A0; Tue, 10 Apr 2018 10:57:55 +0200 (CEST)
From: Jan Lindblad <janl@tail-f.com>
Message-Id: <F0213241-5915-43DC-A43D-3B5DAC1B6980@tail-f.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AAA4D06C-CCF5-4992-8613-0D6876603576"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Tue, 10 Apr 2018 10:57:53 +0200
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBE12@dggeml507-mbs.china.huawei.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
To: Jiangyuanlong <jiangyuanlong@huawei.com>
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBE12@dggeml507-mbs.china.huawei.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/61iR948Ceh6-qY7Fg_8woix7e_I>
Subject: Re: [netmod] Using augment to overwrite an existing definition?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2018 08:58:00 -0000

Yuanlong,

Both approaches you describe are technically valid, but I don't like either of them much.

When you augment another "leaf two-step-flag" (from a different module) into the same parent you will end up with *both* leafs. They will have the same local-name, but different namespaces. For the average user, this will likely be highly confusing.

I also don't like when standards bodies are playing with deviations. They are meant to be a last resort for implementors that are unable to follow a standard. If a standard requires the use of deviations, the value of the standard is diluted. And if an implementor would want to deviate from the standard, how would he deviate from the deviation?

Instead, I'd propose that you model this as two leafs with different names, one config false and one config true. The config true leaf may depend on a feature.

Btw, the current definition of the leaf two-step-flag defines no default value and does not declare the leaf mandatory. This opens up for an undefined case. If the two-step-flag is true, it's a two-step clock. If false, one-step. But what if an implementation doesn't return the two-step-leaf at all? There is no requirement per the YANG to return this leaf, and no language as to what that would mean.

/jan



> We are developing a YANG module for IEEE 1588, which is already a WG draft, please see https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-07 <https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-07>.
> The base module defines a leaf node ‘two-step-flag’ and tags it as read-write, but some applications may want to remodel it as read-only.
> The following is the codes I tried:
> module ptp-augment {
>     namespace "urn:example:ptp-augment";
>     prefix ptp-ag;
>  
>     import ietf-ptp {
>         prefix ptp;
>     }
>  
>     augment /ptp:ptp/ptp:instance-list/ptp:default-ds {
>            leaf two-step-flag {
>              config false;
>              type boolean;
>              description
>                "When set, the clock is a two-step clock; otherwise,
>                 the clock is a one-step clock.";
>            }
>  
> }
> }
> The codes are validated to be right by http://www..yangvalidator.com/validator <http://www.yangvalidator.com/validator>.
> My question is: By using ‘augment’, two leaf nodes are defined successfully with the same YANG identifier but with different behaviors (also applicable to different types), does the new definition take the precedence and overwrite its old definition?  
> If the answer is yes, I will be glad to use this YANG feature, but perhaps it makes sense that a YANG compiler emits a warning that a new definition overrides an existing one.
> Or, are two leaf nodes defined exactly? How do we distinguish them?
>  
> I also tried to use ‘deviation’ instead, the following is the codes:
>  
>      module ptp-deviations {
>        namespace "urn:example:ptp-deviations";
>        prefix ptpd;
>  
>        import ietf-ptp {
>          prefix ptp;
>        }
>  
>        deviation /ptp:ptp/ptp:instance-list/ptp:default-ds/ptp:two-step-flag {
>            deviate replace {
>              config false;
>            }
>        }
>  
>      }
> The codes are also validated to be right by http://www..yangvalidator.com/validator <http://www.yangvalidator.com/validator>.
> My concern is, it cannot add new leaf nodes, so inevitably, another augment will always be used.
>  
> Any thoughts?
>  
> Thanks,
> Yuanlong
> _______________________________________________
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>