Re: [yang-doctors] How to restrict to have single control-plane-protocol instance

Martin Bjorklund <mbj@tail-f.com> Mon, 19 February 2018 19:02 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC841243F6 for <yang-doctors@ietfa.amsl.com>; Mon, 19 Feb 2018 11:02:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 6lCAgpwwEQlh for <yang-doctors@ietfa.amsl.com>; Mon, 19 Feb 2018 11:02:06 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E1F1412420B for <yang-doctors@ietf.org>; Mon, 19 Feb 2018 11:02:05 -0800 (PST)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 7C2D31AE018B; Mon, 19 Feb 2018 20:02:04 +0100 (CET)
Date: Mon, 19 Feb 2018 20:02:04 +0100 (CET)
Message-Id: <20180219.200204.2260953014464778228.mbj@tail-f.com>
To: acee@cisco.com
Cc: chopps@chopps.org, Xufeng_Liu@jabil.com, zhang.zheng@zte.com.cn, yang-doctors@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <B4B94E93-48B4-4916-A0E7-3308775EF5AC@cisco.com>
References: <20180219.101346.2229730027340550251.mbj@tail-f.com> <874lmd47sc.fsf@chopps.org> <B4B94E93-48B4-4916-A0E7-3308775EF5AC@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/PUoe81FT-GipCHyI0NpCHJDPlU4>
Subject: Re: [yang-doctors] How to restrict to have single control-plane-protocol instance
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Feb 2018 19:02:07 -0000

"Acee Lindem (acee)" <acee@cisco.com> wrote:
> 
> 
> On 2/19/18, 5:02 AM, "Christian Hopps" <chopps@chopps.org> wrote:
> 
>     
>     Martin Bjorklund <mbj@tail-f.com> writes:
>     
>     > Hi,
>     >
>     > "Acee Lindem (acee)" <acee@cisco.com> wrote:
>     >> All,
>     >>
>     >> As seems to be the modus operandi for YANG issues, we have 3 separate
>     >> opinions as to how a protocol only supporting a single instance should
>     >> be realized.
>     >>
>     >>   1. Augment the existing control plane protocols list (RFC 8022BIS)
>     >>   and specify in the description text that only a single instance is
>     >>   supported.
>     >>   2. Augment the existing control plane protocols list (RFC 8022BIS)
>     >>   and use a YANG 1.1 must() restriction as discussed by Martin and
>     >>   Lada.
>     >>   3. Augment the container one level up from the list for singleton
>     >>   protocols (suggested by Xufeng).
>     
>     > But I think there was also a proposal to require the single instance
>     > to have a well-known name - but maybe this proposal is no longer on
>     > the table.
>     
>     I actually liked this solution; however, instead of picking an
>     arbitrary "well-known" value for name, I would specify the 0 length
>     string instead. I think that reinforces the idea that this isn't
>     actually a named instance. :)
>     
>        augment "/rt:routing/rt:control-plane-protocols/"
>              + "rt:control-plane-protocol" {
>           when "derived-from-or-self(rt:type, 'msdp:msdp') and rt:name = ''"  {
>           container msdp {
> 
> One benefit of this solution is that it solves Xufeng's issue of what
> the client uses as the instance name.

Note that with options #1 and #2, the client is of course free to send
the name "".  But the client isn't *restricted* to "" - it can use
whatever meaningful name it wants.



/martin