Re: [pim] [yang-doctors] Optional key support?
Ladislav Lhotka <lhotka@nic.cz> Wed, 24 October 2018 18:37 UTC
Return-Path: <lhotka@nic.cz>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB34130DF0; Wed, 24 Oct 2018 11:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 MAW2uJ8Mx0zK; Wed, 24 Oct 2018 11:37:38 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1335127B92; Wed, 24 Oct 2018 11:37:37 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 869B76059E; Wed, 24 Oct 2018 20:37:35 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1540406255; bh=Ltnfqv49OxqZ9uAcHB+YvCeOGmtg/1KA2OXM6DFhFck=; h=From:To:Date; b=ae1VbLbdQdwNnPctmyRQa/jwSFCzyo5mduoW0T61crt3GWHI9awb5w7ACu9Mcp8hz LtISZAZbUvZzZ8sULmn+mSWHsSpyBKeSWGACvvy+9XpMSNDLif8+hc6KFtvo8e4vgw uDjqSJB271hz3JymbDUjAnCJ+FuogqxFEYWHWYp0=
Message-ID: <41803cce2677cf6dc8f63c1d3b5dfa929876037f.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: "Acee Lindem (acee)" <acee@cisco.com>, Andy Bierman <andy@yumaworks.com>, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>
Cc: "xufeng.liu.ietf@gmail.com" <xufeng.liu.ietf@gmail.com>, "sivakumar.mahesh@gmail.com" <sivakumar.mahesh@gmail.com>, "stig@venaas.com" <stig@venaas.com>, "guofeng@huawei.com" <guofeng@huawei.com>, "anish.ietf@gmail.com" <anish.ietf@gmail.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "liuyisong@huawei.com" <liuyisong@huawei.com>, "pete.mcallister@metaswitch.com" <pete.mcallister@metaswitch.com>, "pim@ietf.org" <pim@ietf.org>
Date: Wed, 24 Oct 2018 20:37:35 +0200
In-Reply-To: <EA97F402-A8A9-4248-A19F-5EED6A424770@cisco.com>
References: <8AC97776-E280-45D0-86AC-08BF3F13A60B@cisco.com> <CABCOCHTSiW8y46SMvXcyW0rTZmNDfHPUka_Y35gW8v5M8yC--Q@mail.gmail.com> <20181024.074744.771331979340686070.mbj@tail-f.com> <870A0CEB-1E21-4451-80FD-2D1DE605A8C7@cisco.com> <991ade50-85d3-c907-0fb2-3d777ae49e09@cisco.com> <CABCOCHSc0NM=suTkVd5DBt_cst9GWAEx=Rh6Z+Jkpc+PdVHXnA@mail.gmail.com> <EA97F402-A8A9-4248-A19F-5EED6A424770@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/o363QRNy3q2_w4fRgbOnVA7Rmrs>
X-Mailman-Approved-At: Thu, 25 Oct 2018 16:21:35 -0700
Subject: Re: [pim] [yang-doctors] Optional key support?
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2018 18:37:44 -0000
On Wed, 2018-10-24 at 18:18 +0000, Acee Lindem (acee) wrote: > Lada, Andy, > > I guess I’m missing something in this discussion. Why is a key leaf with a > defaulted value any more complex to deal with than a leaf with an explicitly > specified value? I just don’t get it… Neither do I. FWIW, I think I was in favor of implementing Y09-02 in YANG 1.1. Lada > > Thanks, > Acee > > From: Andy Bierman <andy@yumaworks.com> > Date: Wednesday, October 24, 2018 at 1:31 PM > To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com> > Cc: Acee Lindem <acee@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, Xufeng > Liu <xufeng.liu.ietf@gmail.com>, "sivakumar.mahesh@gmail.com" < > sivakumar.mahesh@gmail.com>, "stig@venaas.com" <stig@venaas.com>, " > guofeng@huawei.com" <guofeng@huawei.com>, "anish.ietf@gmail.com" < > anish.ietf@gmail.com>, YANG Doctors <yang-doctors@ietf.org>, " > liuyisong@huawei.com" <liuyisong@huawei.com>, "pete.mcallister@metaswitch.com" > <pete.mcallister@metaswitch.com>, "pim@ietf.org" <pim@ietf.org> > Subject: Re: [yang-doctors] Optional key support? > > > > On Wed, Oct 24, 2018 at 8:56 AM, Robert Wilton <rwilton@cisco.com> wrote: > > It looks like the final reason that it was not accepted was because the > > change was regarded as being too big for YANG 1.1. As such, it seems > > reasonable for this issue to be on Yang.next and considered again. > > > > > My objection to it was that it had a huge impact on the protocols and the > implementations. > The added complexity is not worth it. > > It is not that hard to define a value that indicates "not really used". > That is not the same as "use the default". Doing this in an elegant way > instead of ad-hoc requires coordinated solutions in YANG, protocols, and > servers. > > There are probably lots of complex YANG text changes because the concept of an > instance (and an instance-identifier) is so different. Also augment, leafref, > and other cross-model dependencies are impacted. > > > > Thanks, > > Rob > > > > > Andy > > > On 24/10/2018 15:53, Acee Lindem (acee) wrote: > > > Read through the discussion and it is a shame we can't converge on a > > > solution. Is YANG 1.0 compatibility the major issue? > > > Thanks, > > > Acee > > > > > > On 10/24/18, 1:48 AM, "yang-doctors on behalf of Martin Bjorklund" < > > > yang-doctors-bounces@ietf.org on behalf of mbj@tail-f.com> wrote: > > > > > > Andy Bierman <andy@yumaworks.com> wrote: > > > > Hi, > > > > > > > > It has been discussed before. > > > > It is already allowed for config=false nodes so the change would be > > > to > > > > allow config=true nodes > > > > to have no keys. > > > > > > > > Each time it comes up, somebody mentions that > > > > (a) NETCONF/RESTCONF has no mechanism to delete all list entries > > > > (b) The client cannot create more than 1 entry. How does the server > > > know > > > > the next entry is a different instance or replacing the first > > > instance? > > > I don't think these were the reasons. See the proposal that was > > > on > > > the table for 1.1: > > > > > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-10 > > > and the discussion: > > > > > > https://mailarchive.ietf.org/arch/browse/netmod/?gbt=1&index=bwacmVipuJMakMFjDXXCZMXCTAA > > > /martin > > > > What is the use-case for a config list without keys? > > > > > > > > > > > > Andy > > > > > > > > > > > > On Tue, Oct 23, 2018 at 2:16 PM, Reshad Rahman (rrahman) < > > > rrahman@cisco.com> > > > > wrote: > > > > > > > > > <Changed subject> > > > > > > > > > > > > > > > > > > > > Hi Xufeng, > > > > > > > > > > > > > > > > > > > > I don’t know if this has been discussed for yang-next but it > > > doesn’t seem > > > > > to be in the yang-next list. I believe optional keys were > > > discussed for > > > > > YANG1.1, maybe others on the YD list remember… > > > > > > > > > > https://github.com/netmod-wg/yang-next/issues > > > > > > > > > > > > > > > > > > > > In this case, I believe it would have been useful to have that > > > > > functionality. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Reshad. > > > > > > > > > > > > > > > > > > > > *From: *Xufeng Liu <xufeng.liu.ietf@gmail.com> > > > > > *Date: *Tuesday, October 23, 2018 at 4:39 PM > > > > > *To: *"Reshad Rahman (rrahman)" <rrahman@cisco.com> > > > > > *Cc: *"janl@tail-f.com" <janl@tail-f.com>, Mahesh Sivakumar < > > > > > sivakumar.mahesh@gmail.com>, Stig Venaas <stig@venaas.com>, > > > Guofeng < > > > > > guofeng@huawei.com>, Anish Peter <anish.ietf@gmail.com>, " > > > > > yang-doctors@ietf.org" <yang-doctors@ietf.org>, Liuyisong < > > > > > liuyisong@huawei.com>, Pete McAllister < > > > pete.mcallister@metaswitch.com>, " > > > > > pim@ietf.org" <pim@ietf.org> > > > > > *Subject: *Re: [yang-doctors] [pim] Yangdoctors last call review > > > of > > > > > draft-ietf-pim-igmp-mld-yang-07 > > > > > > > > > > > > > > > > > > > > Hi Reshad and All, > > > > > > > > > > > > > > > > > > > > Do you think that it would be useful to eventually extend YANG > > > spec to > > > > > allow an optional key with a default value? That would allow the > > > user not > > > > > to enter the extra empty string, and make the model more user > > > friendly. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > - Xufeng > > > > > > > > > > > > > > > > > > > > On Fri, Oct 19, 2018 at 11:02 AM Reshad Rahman (rrahman) < > > > > > rrahman@cisco.com> wrote: > > > > > > > > > > Hi Xufeng, > > > > > > > > > > > > > > > > > > > > I think we should go with the solution proposed by Chris > > > (attached) when > > > > > we last discussed this. I realize it’s not ideal but IMO it’s > > > better than > > > > > other proposals. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Reshad. > > > > > > > > > > > > > > > > > > > > *From: *yang-doctors <yang-doctors-bounces@ietf.org> on behalf of > > > Xufeng > > > > > Liu <xufeng.liu.ietf@gmail.com> > > > > > *Date: *Friday, October 19, 2018 at 9:21 AM > > > > > *To: *"janl@tail-f.com" <janl@tail-f.com> > > > > > *Cc: *Mahesh Sivakumar <sivakumar.mahesh@gmail.com>, Stig Venaas > > > < > > > > > stig@venaas.com>, Guofeng <guofeng@huawei.com>, Anish Peter < > > > > > anish.ietf@gmail.com>, "yang-doctors@ietf.org" < > > > yang-doctors@ietf.org>, > > > > > Liuyisong <liuyisong@huawei.com>, Pete McAllister < > > > > > pete.mcallister@metaswitch.com>, "pim@ietf.org" <pim@ietf.org> > > > > > *Subject: *Re: [yang-doctors] [pim] Yangdoctors last call review > > > of > > > > > draft-ietf-pim-igmp-mld-yang-07 > > > > > > > > > > > > > > > > > > > > Hi Jan, > > > > > > > > > > > > > > > > > > > > Thanks for reviewing. > > > > > > > > > > For #1, as discussed, there is no other better solution at the > > > moment. > > > > > What would you suggest? > > > > > > > > > > Thanks. > > > > > > > > > > - Xufeng > > > > > > > > > > > > > > > > > > > > On Fri, Oct 19, 2018 at 4:25 AM Jan Lindblad <janl@tail-f.com> > > > wrote: > > > > > > > > > > Feng, > > > > > > > > > > > > > > > > > > > > Hi Jan, > > > > > > > > > > > > > > > > > > > > We updated draft-ietf-pim-igmp-mld-yang according to the > > > comments #2 ~ > > > > > #7, while Xufeng and you had discussed about comment #1. > > > > > > > > > > Please review the draft, thanks a lot. > > > > > > > > > > https://www.ietf.org/id/draft-ietf-pim-igmp-mld-yang-08.txt > > > > > > > > > > > > > > > > > > > > Good. I looked through the points #2-#7 and find that the work > > > group have > > > > > understood and fixed those issues. #1 still remains to be > > > resolved. I can > > > > > do a full re-review of the module once that one has been resolved > > > as well.. > > > > > Are there any outstanding questions on how to fix #1? > > > > > > > > > > > > > > > > > > > > Best Regards, > > > > > > > > > > /jan > > > > > > > > > > -- > > > > > > > > > > *Jan Lindblad*, janl@tail-f.com, +46 702855728 > > > > > > > > > > Solutions Architect, Business Development, Tail-f > > > > > > > > > > Tail-f is now a part of Cisco > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Feng > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Jan Lindblad [mailto:janl@tail-f.com <janl@tail-f.com>] > > > > > > > > > > Sent: Monday, August 13, 2018 10:35 PM > > > > > > > > > > To: yang-doctors@ietf.org > > > > > > > > > > Cc: ietf@ietf.org; pim@ietf.org; > > > draft-ietf-pim-igmp-mld-yang.all@ietf.org > > > > > > > > > > Subject: Yangdoctors last call review of draft-ietf-pim-igmp-mld- > > > yang-07 > > > > > > > > > > > > > > > > > > > > Reviewer: Jan Lindblad > > > > > > > > > > Review result: On the Right Track > > > > > > > > > > > > > > > > > > > > This is my YANG-doctor review of draft-ietf-pim-igmp-mld-yang-07. > > > In the > > > > > spring, I did an early review of the -02 version. > > > > > > > > > > > > > > > > > > > > Most of the comments from the earlier review are still valid. In > > > some ways > > > > > the document has progressed since -02, in many it has not, and in > > > a few it > > > > > has deteriorated. In my judgement, the document is not ready for > > > last call. > > > > > Many fundamentally important questions are still unresolved. Here > > > are my > > > > > review comments in rough falling order of importance. > > > > > > > > > > > > > > > > > > > > #1 Improper augment of /rt:routing/rt:control-plane-protocols > > > > > > > > > > > > > > > > > > > > Quoted from section 3.1: > > > > > > > > > > This model augments the core routing data model "ietf-routing" > > > > > > > > > > specified in [RFC8349]. The IGMP model augments "/rt:routing/ > > > > > > > > > > rt:control-plane-protocols" as opposed to augmenting > > > "/rt:routing/ > > > > > > > > > > rt:control-plane-protocols/rt:control-plane-protocol", as the > > > latter > > > > > > > > > > would allow multiple protocol instances, while the IGMP > > > protocol is > > > > > > > > > > designed to be enabled or disabled as a single protocol > > > instance on > > > > > > > > > > a network instance or a logical network element. > > > > > > > > > > > > > > > > > > > > The description above, and the actual augment statements in the > > > YANG > > > > > module violate the principles described in RFC 8349, the ietf- > > > routing.yang > > > > > module it augments. In RFC 8349, section 5.3. Control-Plane > > > Protocol, the > > > > > proper way of augmenting the routing module is described. The > > > fact that > > > > > this is a singleton protocol instance doesn't change this. > > > Section 5.3 > > > > > describes singleton cases as well. > > > > > > > > > > > > > > > > > > > > Guofeng: Xufeng has discussed with Jan about the comment, and it > > > is closed. > > > > > > > > > > > > > > > > > > > > #2 Incorrect vendor refinement model > > > > > > > > > > > > > > > > > > > > Quoted from section 2.2: > > > > > > > > > > For the same reason, wide constant ranges (for example, timer > > > > > > > > > > maximum and minimum) will be used in the model. It is > > > expected that > > > > > > > > > > vendors will augment the model with any specific restrictions > > > that > > > > > > > > > > might be required. Vendors may also extend the features list > > > with > > > > > > > > > > proprietary extensions. > > > > > > > > > > > > > > > > > > > > This is not acceptable. The principle suggested does not foster > > > > > interoperability and useful standards. It is also not possible to > > > do what > > > > > the paragraph suggests in YANG. This was pointed out in the -02 > > > review, and > > > > > a suggestion was given there on how to address the problem. > > > > > > > > > > > > > > > > > > > > Guofeng: We removed the paragraph above, and put the values > > > discussed by > > > > > Mcast Design Team. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #3 Top level structures not optional > > > > > > > > > > > > > > > > > > > > Quoted from section 2.3: > > > > > > > > > > The current document contains IGMP and MLD as separate schema > > > > > > > > > > branches in the structure. The reason for this is to make it > > > easier > > > > > > > > > > for implementations which may optionally choose to support > > > specific > > > > > > > > > > address families. And the names of objects may be different > > > between > > > > > > > > > > the IPv4 (IGMP) and IPv6 (MLD) address families. > > > > > > > > > > > > > > > > > > > > This problem was also pointed out in the -02 review. The author > > > suggests > > > > > that implementing igmp and/or mld is optional. This is not > > > reflected in the > > > > > YANG module, however. As currently modeled, both are currently > > > mandatory to > > > > > implement. If-feature is used liberally in the module, and could > > > be used > > > > > here as well. > > > > > > > > > > > > > > > > > > > > #4 Unclear meaning of optional leaves > > > > > > > > > > > > > > > > > > > > Quoted from section 3.1: > > > > > > > > > > Where fields are not genuinely essential to protocol > > > operation, they > > > > > > > > > > are marked as optional. Some fields will be essential but have > > > a > > > > > > > > > > default specified, so that they need not be configured > > > explicitly. > > > > > > > > > > > > > > > > > > > > In fact, in the current version of the module, every leaf is > > > optional > > > > > (except keys, which cannot be optional). It is good to see the > > > addition of > > > > > defaults in many cases, but many unclear cases remain. E.g. leaf > > > > > /igmp/global/enable is of type boolean. I understand what true > > > and false > > > > > implies for this leaf. But what does it mean if it is not set at > > > all? > > > > > Either add a default or describe the meaning in the description. > > > Similarly, > > > > > if the leaf version is not set on an igmp or mld interface, or on > > > the > > > > > interface-global level, what does that mean? > > > > > > > > > > Add default. require-router-alert? explicit-tracking? exclude- > > > lite? Many > > > > > of these are used in NP-containers inheriting all the from the > > > root, which > > > > > makes the use of mandatory highly discouraged in the current > > > form. If the > > > > > RFC 8349 augmentation principles are followed, the concern around > > > mandatory > > > > > falls, and some leafs with no sensible default could be marked > > > mandatory > > > > > instead. > > > > > > > > > > > > > > > > > > > > #5 All optional state > > > > > > > > > > > > > > > > > > > > All state data is optional, which means a conforming server could > > > very > > > > > well decide not to implement it. E.g. discontinuity-time is > > > optional. > > > > > Should a manager count on this being available? A situation where > > > every > > > > > leaf is optional is as nice and flexible for server implementors > > > as it is > > > > > frustrating and complicated for manager implementors to consume. > > > A YANG > > > > > model is an API contract and should consider the needs of both > > > sides. The > > > > > way this has been designed reveals that no representation for the > > > consumer > > > > > side of this model has been involved in the design. I would > > > suggest > > > > > thinking through what is the most essential state data for a > > > manager, and > > > > > make some leafs mandatory. > > > > > > > > > > > > > > > > > > > > #6 Abundant copy-paste > > > > > > > > > > > > > > > > > > > > There is abundant repetition in the YANG module. leaf version is > > > defined 2 > > > > > times for igmp with identical definitions, and two more for mld > > > with > > > > > identical definitions. leaf enable is defined once for the > > > interface > > > > > global-level, and with identical definition on the interface > > > local level. > > > > > leaf last-member-query-interval, query-interval and half a dozen > > > other > > > > > leaves are defined twice with identical definitions. > > > > > > > > > > > > > > > > > > > > #7 Leaf interface in the rpc clear*groups on line 1124, 1094 has > > > type > > > > > string. > > > > > > > > > > Should be a leafref? Describe what values are valid. #8 Leaf > > > group-policy, > > > > > source-policy on line 486, 527, 624, 689: type string. Should be > > > leafref? > > > > > > > > > > Describe what values are valid. #9 Leaf group on line 705, 1101, > > > 1131: Is > > > > > any > > > > > > > > > > ipv4/6 address ok, or only a multicast address? Model > > > accordingly. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *From:* pim [mailto:pim-bounces@ietf.org <pim-bounces@ietf.org>] > > > *On > > > > > Behalf Of *Jan Lindblad > > > > > *Sent:* Tuesday, September 11, 2018 9:52 PM > > > > > *To:* Xufeng Liu <xufeng.liu.ietf@gmail.com> > > > > > *Cc:* yang-doctors@ietf.org; ietf <ietf@ietf.org>; pim@ietf.org; > > > > > draft-ietf-pim-igmp-mld-yang.all@ietf.org > > > > > *Subject:* Re: [pim] Yangdoctors last call review of > > > > > draft-ietf-pim-igmp-mld-yang-07 > > > > > > > > > > > > > > > > > > > > Xufeng, > > > > > > > > > > > > > > > > > > > > Thanks for the review and valuable comments. > > > > > > > > > > > > > > > > > > > > In regard to item #1, there was a discussion thread among the > > > Yang > > > > > Doctors, authors of RFC 8349, and Routing Area Yang Architecture > > > Design > > > > > Team, as attached below. The discussion occurred during the > > > review of a > > > > > draft with the same issue as this one. > > > > > > > > > > > > > > > > > > > > I see, didn't know. Good. If this has been discussed to > > > conclusion, then > > > > > you should of course go with that decision. > > > > > > > > > > > > > > > > > > > > As mentioned earlier, there are a few other singleton protocols > > > mapped > > > > > into this structure, e.g. static. I think it would make sense to > > > treat this > > > > > the same. Principle of least astonishment. > > > > > > > > > > > > > > > > > > > > Best Regards, > > > > > > > > > > /jan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================ > > > > > > > > > > 原始邮件 > > > > > 发件人:XufengLiu <Xufeng_Liu@jabil.com> > > > > > 收件人:Acee Lindem (acee) <acee@cisco.com>Christian Hopps < > > > chopps@chopps.org>Martin > > > > > Bjorklund <mbj@tail-f.com> > > > > > 抄送人:张征00007940;yang-doctors@ietf.org <yang-doctors@ietf.org> > > > > > 日 期 :2018年02月20日 22:30 > > > > > 主 题 :RE: [yang-doctors] How to restrict to have > > > > > singlecontrol-plane-protocol instance > > > > > Using "" as the name is better, but I am not sure that it is good > > > enough. > > > > > When we use ConfD to translate the model to a command line, if > > > the option > > > > > "tailf:cli-expose-key-name" is not used, we will have: > > > > > > > > > > edit routing control-plane-protocols control-plane-protocol type > > > msdp name > > > > > ''" > > > > > > > > > > If the option "tailf:cli-expose-key-name" is used, we will have: > > > > > > > > > > edit routing control-plane-protocols control-plane-protocol msdp > > > ''" > > > > > > > > > > I am pretty sure that we would get a bug report on this, asking > > > what is > > > > > the purpose to have: name ''", and requesting a suppression on > > > the term, > > > > > but we do not have a good way to achieve. > > > > > > > > > > As a comparison, the option #3 will give: > > > > > > > > > > edit routing control-plane-protocols msdp > > > > > > > > > > This is the only acceptable solution so far. When a model is not > > > usable by > > > > > the end-user, other considerations (such as augmentation > > > convenience) will > > > > > not matter. > > > > > > > > > > Thanks, > > > > > - Xufeng > > > > > > > > > > > -----Original Message----- > > > > > > From: Acee Lindem (acee) [mailto:acee@cisco.com] > > > > > > Sent: Monday, February 19, 2018 1:35 PM > > > > > > To: Christian Hopps <chopps@chopps.org>; Martin Bjorklund < > > > > > mbj@tail-f.com> > > > > > > Cc: Xufeng Liu <Xufeng_Liu@jabil.com>; zhang.zheng@zte.com.cn; > > > yang- > > > > > > doctors@ietf.org > > > > > > Subject: Re: [yang-doctors] How to restrict to have single > > > control-plane- > > > > > > protocol instance > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Chris. > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > >> and #3. For #3, one determent would be that the control > > > plane > > > > > protocols > > > > > > are in a location other than where they were originally > > > envisioned and I > > > > > don't > > > > > > relish pulling RFC8022BIS off the RFC queue to document. > > > > > > >> > > > > > > >> Thanks, > > > > > > >> Acee > > > > > > >> > > > > > > >> On 2/15/18, 8:39 AM, "Reshad Rahman (rrahman)" < > > > rrahman@cisco.com > > > > > > > > > > > > wrote: > > > > > > >> > > > > > > >> Hi Xufeng, > > > > > > >> > > > > > > >> I think the intent of 8022bis was to have all > > > protocols under > > > > > > /rt:routing/rt:control-plane-protocols/rt:control-plane- > > > protocol. I > > > > > agree that > > > > > > forcing a name for a single-instance is cumbersome, but I think > > > it is > > > > > too late to > > > > > > change tree hierachy organization at this point. > > > > > > >> > > > > > > >> I will defer to other YDs and 8022bis authors on > > > this. > > > > > > >> > > > > > > >> Regards, > > > > > > >> Reshad. > > > > > > >> > > > > > > >> On 2018-02-08, 9:48 AM, "Xufeng Liu" < > > > Xufeng_Liu@jabil.com> > > > > > wrote: > > > > > > >> > > > > > > >> Hi All, > > > > > > >> > > > > > > >> I feel that such a solution is still not clean > > > enough to > > > > > outweigh the > > > > > > simple augmentation to "/rt:routing/rt:control-plane- > > > protocols/". > > > > > > >> > > > > > > >> Some considerations are: > > > > > > >> > > > > > > >> - Name management: Neither the operator nor the > > > > > implementation > > > > > > wants to deal with the artificial name, whether it is > > > hardcoded, > > > > > user-configured, > > > > > > or system-generated. When we implement such singleton protocol, > > > we don't > > > > > > save a name anywhere. > > > > > > >> - The complexity of validation: The "when" > > > statement is an > > > > > > unnecessary expense to the user and to the implementation, > > > especially if > > > > > we > > > > > > need to check all instances. > > > > > > >> - Data tree query: If the singleton "MSDP" is > > > mixed with > > > > > other protocol > > > > > > instances, it is less obvious or harder to search for. > > > Depending on the > > > > > > implementation, it would be worse if the entire list needs to > > > be > > > > > iterated. > > > > > > >> - Tree hierarchy organization: I don't see too > > > big a > > > > > problem with "all > > > > > > single-instance protocols under /rt:routing/rt:control-plane- > > > protocols > > > > > and all > > > > > > the multi-instance ones under /rt:routing/rt:control-plane- > > > > > protocols/rt:control- > > > > > > plane-protocol". If necessary, some of the names can be > > > adjusted. > > > > > > >> > > > > > > >> Thanks, > > > > > > >> - Xufeng > > > > > > >> > > > > > > >> > > > > > > >> > -----Original Message----- > > > > > > >> > From: Reshad Rahman (rrahman) [mailto: > > > rrahman@cisco.com > > > > > ] > > > > > > >> > Sent: Thursday, February 8, 2018 9:41 AM > > > > > > >> > To: Ladislav Lhotka <lhotka@nic.cz>; Martin > > > Bjorklund > > > > > <mbj@tail- > > > > > > f.com>; > > > > > > >> > Acee Lindem (acee) <acee@cisco.com> > > > > > > >> > Cc: yang-doctors@ietf.org; > > > zhang.zheng@zte.com.cn; > > > > > Xufeng Liu > > > > > > >> > <Xufeng_Liu@jabil.com> > > > > > > >> > Subject: Re: [yang-doctors] How to restrict to > > > have > > > > > single control- > > > > > > plane- > > > > > > >> > protocol instance > > > > > > >> > > > > > > > >> > Thanks for the suggestions. I agree that hard- > > > coding > > > > > the name is a > > > > > > bad idea, > > > > > > >> > glad that a cleaner way of doing this is > > > possible. > > > > > > >> > - We can move the must statement up to > > > restrict max of > > > > > 1 control- > > > > > > plane- > > > > > > >> > protocol instance of type msdp? > > > > > > >> > - Acee/Lada, should a note be added to section > > > 5.3 of > > > > > 8022bis > > > > > > regarding how > > > > > > >> > to enforce single instance? How much of a > > > concern is the > > > > > > performance > > > > > > >> > impact in this specific case? > > > > > > >> > > > > > > > >> > Regards, > > > > > > >> > Reshad. > > > > > > >> > > > > > > > >> > On 2018-02-08, 7:02 AM, "Ladislav Lhotka" < > > > > > lhotka@nic.cz> wrote: > > > > > > >> > > > > > > > >> > On Thu, 2018-02-08 at 12:39 +0100, Martin > > > Bjorklund > > > > > wrote: > > > > > > >> > > "Acee Lindem (acee)" <acee@cisco.com> > > > wrote: > > > > > > >> > > > Hi Lada, > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > On 2/8/18, 4:42 AM, "yang-doctors on > > > behalf of > > > > > Ladislav > > > > > > Lhotka" > > > > > > >> > <yang-docto > > > > > > >> > > rs-bounces@ietf.org on behalf of > > > lhotka@nic.cz> > > > > > wrote: > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > On Thu, 2018-02-08 at 09:20 +0100, > > > Martin > > > > > Bjorklund wrote: > > > > > > >> > > > > > > > > >> > > > > Hi, > > > > > > >> > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > "Reshad Rahman (rrahman)" < > > > > > rrahman@cisco.com> wrote: > > > > > > >> > > > > > > > > >> > > > > > Hi YDs, > > > > > > >> > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > >> > > > > > MSDP YANG authors want to > > > enforce > > > > > single-instance of > > > > > > MSDP > > > > > > >> > > > > > > > > >> > > > > > control-plane protocol. The > > > when > > > > > “rt:type = > > > > > > ‘msdp’“ allows > > > > > > >> > multiple > > > > > > >> > > > > > > > > >> > > > > > control-pane-protocol > > > instances as long > > > > > as they have > > > > > > different > > > > > > >> > > > > > > > > >> > > > > > rt:name. The only workaround I > > > thought > > > > > of is to have a > > > > > > when > > > > > > >> > > statement > > > > > > >> > > > > > > > > >> > > > > > on the name in the top level > > > container.. > > > > > This would still > > > > > > multiple > > > > > > >> > > > > > > > > >> > > > > > control-plane-protocol > > > instance of type > > > > > msdp but > > > > > > restricts the > > > > > > >> > name > > > > > > >> > > to > > > > > > >> > > > > > > > > >> > > > > > a fixed name (msdp-protocol in > > > this > > > > > case) for the top level > > > > > > msdp > > > > > > >> > > > > > > > > >> > > > > > container to exist. Any > > > suggestions on > > > > > how to do this > > > > > > better? > > > > > > >> > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > Hard-coding a name like this is > > > IMO a bad > > > > > idea. > > > > > > >> > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > Better would be to simply state > > > in text > > > > > that there MUST > > > > > > only be one > > > > > > >> > > > > > > > > >> > > > > instance of this type. > > > > > > >> > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > But you can also add a must > > > statement > > > > > that enforces this: > > > > > > >> > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > augment > > > "/rt:routing/rt:control-plane- > > > > > protocols/" > > > > > > >> > > > > > > > > >> > > > > + "rt:control-plane- > > > protocol" { > > > > > > >> > > > > > > > > >> > > > > when 'derived-from-or- > > > self(rt:type, > > > > > "msdp:msdp"' { > > > > > > >> > > > > > > > > >> > > > > container msdp { > > > > > > >> > > > > > > > > >> > > > > must > > > 'count(/rt:routing/rt:control- > > > > > plane-protocols/' > > > > > > >> > > > > > > > > >> > > > > + ' > > > > > rt:control-plane-protocol[' > > > > > > >> > > > > > > > > >> > > > > + ' > > > > > derived-from-or-sel(../rt:type, "msdp:msdp")]) > > > > > > <= > > > > > > >> > > 1'"; > > > > > > >> > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > In general, you should be > > > careful with > > > > > the usage of "count", > > > > > > since it > > > > > > >> > > > > > > > > >> > > > > will loop through *all* > > > instances in the > > > > > list every time. If > > > > > > the list > > > > > > >> > > > > > > > > >> > > > > is big, this can have a > > > performance > > > > > impact. > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > Instead of count(), it is possible > > > to use > > > > > the so-called > > > > > > Muenchian > > > > > > >> > > method: > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > container msdp { > > > > > > >> > > > > > > > > >> > > > must "not(../preceding- > > > sibling::rt: > > > > > control-plane- > > > > > > protocol[" > > > > > > >> > > > > > > > > >> > > > + "derived-from-or- > > > self(rt:type, > > > > > 'msdp:msdp')])"; > > > > > > >> > > > > > > > > >> > > > .. > > > > > > >> > > > > > > > > >> > > > } > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > It basically states that the > > > > > control-plane-protocol containing > > > > > > the > > > > > > >> > > "msdp" > > > > > > >> > > > > > > > > >> > > > container must not be preceded > > > with a > > > > > control-plane- > > > > > > protocol entry > > > > > > >> > of > > > > > > >> > > the > > > > > > >> > > > > > > > > >> > > > msdp:msdp type (or derived). > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > This looks like an elegant solution. > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > "elegant" as in "less obvious" ;) It > > > has the > > > > > same time complexity > > > > > > as > > > > > > >> > > the count() solution. > > > > > > >> > > > > > > > >> > It should be faster on the average - it > > > has to scan > > > > > only preceding > > > > > > siblings of > > > > > > >> > the MSDP protocol instance whereas count() > > > always > > > > > has to check > > > > > > *all* > > > > > > >> > protocol > > > > > > >> > instances. > > > > > > >> > > > > > > > >> > It is true though that in XSLT this > > > technique can > > > > > be made > > > > > > considerably > > > > > > >> > more > > > > > > >> > efficient by using indexed keys. > > > > > > >> > > > > > > > >> > Lada > > > > > > >> > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > However, since the key for the > > > > > control-plane-protocol list is > > > > > > "type > > > > > > >> > > name", won't it only work if the > > > previous sibling > > > > > has a "name" > > > > > > that > > > > > > >> > > is precedes the one being added? > > > > > > >> > > > > > > > > >> > > For each list entry that has this > > > container, the > > > > > expression is > > > > > > >> > > evaluated. It will scan all preceding > > > entries > > > > > and ensure that there > > > > > > >> > > are none with this type. So the order > > > of the > > > > > entries doesn't > > > > > > matter; > > > > > > >> > > if there are two with the same type, one > > > of them > > > > > has to be > > > > > > before the > > > > > > >> > > other. > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > /martin > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > Thanks, > > > > > > >> > > > > > > > > >> > > > Acee > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > Lada > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > Also note that I use derived- > > > from-or-self > > > > > instead of equality > > > > > > for the > > > > > > >> > > > > > > > > >> > > > > identity. > > > > > > >> > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > /martin > > > > > > >> > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > >> > > > > > Regards, > > > > > > >> > > > > > > > > >> > > > > > Reshad. > > > > > > >> > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > >> > > > > > augment > > > "/rt:routing/rt:control-plane- > > > > > protocols/" > > > > > > >> > > > > > > > > >> > > > > > + "rt:control-plane- > > > protocol" { > > > > > > >> > > > > > > > > >> > > > > > when "rt:type = ‘msdp’" > > > { > > > > > > >> > > > > > > > > >> > > > > > description > > > > > > >> > > > > > > > > >> > > > > > "….”; > > > > > > >> > > > > > > > > >> > > > > > } > > > > > > >> > > > > > > > > >> > > > > > description "…."; > > > > > > >> > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > >> > > > > > container msdp { > > > > > > >> > > > > > > > > >> > > > > > when "../rt:name = > > > > > ‘msdp-protocol’" { > > > > > > >> > > > > > > > > >> > > > > > description > > > > > > >> > > > > > > > > >> > > > > > "…."; > > > > > > >> > > > > > > > > >> > > > > > } > > > > > > >> > > > > > > > > >> > > > > > description "MSDP top > > > level > > > > > container."; > > > > > > >> > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > >> > > > > > From: "Reshad Rahman > > > (rrahman)" < > > > > > rrahman@cisco.com> > > > > > > >> > > > > > > > > >> > > > > > Date: Monday, February 5, 2018 > > > at 6:25 > > > > > PM > > > > > > >> > > > > > > > > >> > > > > > To: Xufeng Liu < > > > Xufeng_Liu@jabil.com>, > > > > > > >> > "zhang.zheng@zte.com.cn" > > > > > > >> > > > > > > > > >> > > > > > <zhang.zheng@zte.com.cn> > > > > > > >> > > > > > > > > >> > > > > > Cc: "anish.ietf@gmail.com" < > > > > > anish.ietf@gmail.com>, > > > > > > "Mahesh > > > > > > >> > Sivakumar > > > > > > >> > > > > > > > > >> > > > > > (masivaku)" < > > > masivaku@cisco.com>, > > > > > > "guofeng@huawei.com" > > > > > > >> > > > > > > > > >> > > > > > <guofeng@huawei.com>, > > > > > > "pete.mcallister@metaswitch.com" > > > > > > >> > > > > > > > > >> > > > > > < > > > pete.mcallister@metaswitch.com>, > > > > > > "liuyisong@huawei.com" > > > > > > >> > > > > > > > > >> > > > > > <liuyisong@huawei.com>, " > > > > > xu.benchong@zte.com.cn" > > > > > > >> > > > > > > > > >> > > > > > <xu.benchong@zte.com.cn>, > > > > > "tanmoy.kundu@alcatel- > > > > > > >> > lucent.com" > > > > > > >> > > > > > > > > >> > > > > > < > > > tanmoy.kundu@alcatel-lucent.com>, > > > > > > >> > "zzhang_ietf@hotmail.com" > > > > > > >> > > > > > > > > >> > > > > > <zzhang_ietf@hotmail.com>, > > > "Acee > > > > > Lindem (acee)" > > > > > > >> > <acee@cisco.com> > > > > > > >> > > > > > > > > >> > > > > > Subject: Re: Hi all, about the > > > > > modification of MSDP YANG > > > > > > >> > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > >> > > > > > Hi Sandy and Xufeng, > > > > > > >> > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > >> > > > > > I understand that you want > > > only 1 MSDP > > > > > instance but I > > > > > > don’t think > > > > > > >> > > that > > > > > > >> > > > > > > > > >> > > > > > justifies > > > /rt:routing/rt:control-plane-protocols. > > > > > If we do > > > > > > that we > > > > > > >> > > > > > > > > >> > > > > > will end up with all single- > > > instance > > > > > protocols under > > > > > > >> > > > > > > > > >> > > > > > /rt:routing/rt:control-plane- > > > protocols > > > > > and all the multi- > > > > > > instance > > > > > > >> > > ones > > > > > > >> > > > > > > > > >> > > > > > under > > > > > > >> > > > > > > > > >> > > > > > /rt:routing/rt:control-plane- > > > > > protocols/rt:control-plane- > > > > > > protocol. > > > > > > >> > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > >> > > > > > I am not sure what’s the best > > > way to > > > > > enforce single- > > > > > > instance, I can > > > > > > >> > > > > > > > > >> > > > > > check with the other YDs on > > > this topic.. > > > > > One way it can be > > > > > > done is > > > > > > >> > as > > > > > > >> > > > > > > > > >> > > > > > follows (I’ve added the when > > > statement > > > > > in bold to > > > > > > existing BFD > > > > > > >> > > model), > > > > > > >> > > > > > > > > >> > > > > > it enforces that the protocol > > > name is > > > > > ‘bfdv1’. So multiple > > > > > > >> > instances > > > > > > >> > > > > > > > > >> > > > > > with rt:type=bfd-types:bfdv1 > > > could be > > > > > created, but only > > > > > > one of > > > > > > >> > these > > > > > > >> > > > > > > > > >> > > > > > instances can have the bfd > > > container. > > > > > This is probably not > > > > > > the > > > > > > >> > best > > > > > > >> > > > > > > > > >> > > > > > way but the point is that IMO > > > protocols > > > > > have to go under > > > > > > >> > > > > > > > > >> > > > > > /rt:routing/rt:control-plane- > > > > > protocols/rt:control-plane- > > > > > > protocol. > > > > > > >> > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > >> > > > > > Regards, > > > > > > >> > > > > > > > > >> > > > > > Reshad. > > > > > > >> > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > >> > > > > > augment > > > "/rt:routing/rt:control-plane- > > > > > protocols/" > > > > > > >> > > > > > > > > >> > > > > > + "rt:control-plane- > > > protocol" { > > > > > > >> > > > > > > > > >> > > > > > when "rt:type = > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
- Re: [pim] [yang-doctors] Optional key support? Andy Bierman
- Re: [pim] [yang-doctors] Optional key support? Andy Bierman
- Re: [pim] [yang-doctors] Optional key support? Andy Bierman
- Re: [pim] [yang-doctors] Optional key support? Andy Bierman
- Re: [pim] [yang-doctors] Optional key support? Ladislav Lhotka
- Re: [pim] [yang-doctors] Optional key support? Martin Bjorklund