Re: [pim] [yang-doctors] Optional key support?

Andy Bierman <andy@yumaworks.com> Tue, 23 October 2018 21:36 UTC

Return-Path: <andy@yumaworks.com>
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 8F744130E63 for <pim@ietfa.amsl.com>; Tue, 23 Oct 2018 14:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 BGqus79N6b5u for <pim@ietfa.amsl.com>; Tue, 23 Oct 2018 14:36:09 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5EA5130DEC for <pim@ietf.org>; Tue, 23 Oct 2018 14:36:07 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id p11-v6so2331062lfc.6 for <pim@ietf.org>; Tue, 23 Oct 2018 14:36:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HXrOENsgLBQSzFDKJKR5yWv/54cMZTcWUbMbFjAFWoM=; b=lFHU4TN77ayAkQy4r1a9iu5TNwQN/qPeRqWzcSbuBLjW2gA2kK83CAFXIv2D7zmrep 6sdikEY2lzZwmYjG+/KEzzt0ojBdjiXEnEiqlw73zx/gq1EIm8b4dyk8AP3PDhUnAikN ufC5ZJvDq5jT3688psdNIQhoDAVKQ2JYcbqK4BBgfEZG04xlZoFmGOSX5Wh0JfK2X8Wi 0jmurASi6LmCyCpk8R+ZssUgrBzRD+WXm++FtLD3cCKmVGahBn6/9lJeLaiAgPzhjO/U QRb/wrz/Lb2XMFXoluyzrQVrROojqvYme03dpexrdiGNT2gJ6hXYKIfCDw17/+GOqOeF 10kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HXrOENsgLBQSzFDKJKR5yWv/54cMZTcWUbMbFjAFWoM=; b=EvYnBcnc7Hm6FWYG/uFyJV9AoqYKwDwx9tB4ToD3gCwuozIeC/pWyfCVCgIgHUTyLz ZIFBONdYJgGhKENFdYqZKFqk9k1IgZSXQlLVIGE4Fby96qw3mz6GS6LxDEHYM9HlIIxM PIKCE8dthK6YDMruiZvUsbHd+sPb26TRrV9Fv/KnTJVc2GZbVcaUup2c4Ofpb9RkwWsb R4OteiKNioyTQhYMykVt0oCEwJDyJfkdznzdZS+c//ZM2XVp/DbYPviNE3cHtn5VzK37 jh7FeJexKgxkEhIFIcWwCyIvgotjDxRREUHMPNZNwxeNIKc3eyKUM9xZveSpis7lCKsw p18w==
X-Gm-Message-State: ABuFfohWLnDC9hZZVfLCBUTiavxx8pB57Ec4dJ2Y6BNgsAmdCUn+W8Ru 0t8fg8exa5gvYI+jyHNglORhPaWcw8Y7Kfq+vZx0LA==
X-Google-Smtp-Source: ACcGV6306yCNyaC0lXg8vUpN/aJVwbPNGTrpF/5h8pJQ4VqLnRViGyFr6XY3HjUrAMkd2E9e693BagwKtWrK55ELQyo=
X-Received: by 2002:a19:690d:: with SMTP id e13mr9046175lfc.84.1540330565407; Tue, 23 Oct 2018 14:36:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Tue, 23 Oct 2018 14:36:04 -0700 (PDT)
In-Reply-To: <8AC97776-E280-45D0-86AC-08BF3F13A60B@cisco.com>
References: <8AC97776-E280-45D0-86AC-08BF3F13A60B@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 23 Oct 2018 14:36:04 -0700
Message-ID: <CABCOCHTSiW8y46SMvXcyW0rTZmNDfHPUka_Y35gW8v5M8yC--Q@mail.gmail.com>
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: Xufeng Liu <xufeng.liu.ietf@gmail.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>
Content-Type: multipart/alternative; boundary="000000000000303d730578ec288a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/XQEkRpzDVqREoW0U9QnCBrpVLfY>
X-Mailman-Approved-At: Thu, 25 Oct 2018 16:20:05 -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: Tue, 23 Oct 2018 21:36:23 -0000

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?

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 =
> 'bfd-types:bfdv1'"  {
> >     >>         >     >
> >     >>         >     > >     > >       description
> >     >>         >     >
> >     >>         >     > >     > >         "This augmentation is only
> valid for a control-plane
> >     >>         >     > protocol
> >     >>         >     >
> >     >>         >     > >     > >          instance of BFD (type
> 'bfdv1').";
> >     >>         >     >
> >     >>         >     > >     > >     }
> >     >>         >     >
> >     >>         >     > >     > >     description "BFD augmentation.";
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >     container bfd {
> >     >>         >     >
> >     >>         >     > >     > >       when "../rt:name = 'bfdv1'"  {
> >     >>         >     >
> >     >>         >     > >     > >         description
> >     >>         >     >
> >     >>         >     > >     > >           "This augmentation is only
> valid for a control-plane
> >     >>         >     > protocol
> >     >>         >     >
> >
>
>
>
>
> ---------- Forwarded message ----------
> From: Christian Hopps <chopps@chopps.org>
> To: Martin Bjorklund <mbj@tail-f.com>
> Cc: <Xufeng_Liu@jabil.com>, <zhang.zheng@zte.com.cn>, <
> yang-doctors@ietf.org>
> Bcc:
> Date: Mon, 19 Feb 2018 05:01:55 -0500
> Subject: Re: [yang-doctors] How to restrict to have single
> control-plane-protocol instance
> 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 {
>
> 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 = 'bfd-types:bfdv1'"  {
> >>         >     >
> >>         >     > >     > >       description
> >>         >     >
> >>         >     > >     > >         "This augmentation is only valid for
> a control-plane
> >>         >     > protocol
> >>         >     >
> >>         >     > >     > >          instance of BFD (type 'bfdv1').";
> >>         >     >
> >>         >     > >     > >     }
> >>         >     >
> >>         >     > >     > >     description "BFD augmentation.";
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >     container bfd {
> >>         >     >
> >>         >     > >     > >       when "../rt:name = 'bfdv1'"  {
> >>         >     >
> >>         >     > >     > >         description
> >>         >     >
> >>         >     > >     > >           "This augmentation is only valid
> for a control-plane
> >>         >     > protocol
> >>         >     >
> >>         >     > >     > >            instance of BFD (type 'bfdv1').";
> >>         >     >
> >>         >     > >     > >       }
> >>         >     >
> >>         >     > >     > >       description "BFD top level container.";
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > From: Xufeng Liu <Xufeng_Liu@jabil.com>
> >>         >     >
> >>         >     > >     > > Date: Monday, February 5, 2018 at 9:38 AM
> >>         >     >
> >>         >     > >     > > To: "zhang.zheng@zte.com.cn" <
> zhang.zheng@zte.com.cn>
> >>         >     >
> >>         >     > >     > > Cc: "Reshad Rahman (rrahman)" <
> rrahman@cisco.com>,
> >>         >     >
> >>         >     > >     > > "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>
> >>         >     >
> >>         >     > >     > > Subject: RE: Hi all, about the modification
> of MSDP YANG
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Hi Sandy,
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Thanks for the updates.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > In RFC8022bis, the rt:type is defined under
> >>         >     >
> >>         >     > >     > > /rt:routing/rt:control-plane-
> protocols/rt:control-plane-protocol.
> >>         > If
> >>         >     >
> >>         >     > >     > > we augment /rt:routing/rt:control-plane-protocols,
> the “when”
> >>         >     >
> >>         >     > >     > > statement will not be valid, because it
> cannot find the rt:type. I
> >>         >     >
> >>         >     > >     > > don’t think that we need the “when”
> statement. The container
> >>         > with
> >>         >     >
> >>         >     > >     > > “presence” will serve the purpose of the
> identity. We can simply
> >>         >     > take
> >>         >     >
> >>         >     > >     > > out the “when” statement and the definition
> of the MSDP identity.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Thanks,
> >>         >     >
> >>         >     > >     > > - Xufeng
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > From: zhang.zheng@zte.com.cn [mailto:
> zhang.zheng@zte.com.cn]
> >>         >     >
> >>         >     > >     > > Sent: Monday, February 5, 2018 3:36 AM
> >>         >     >
> >>         >     > >     > > To: Xufeng Liu <Xufeng_Liu@jabil.com>
> >>         >     >
> >>         >     > >     > > Cc: rrahman@cisco.com; anish.ietf@gmail.com;
> >>         > masivaku@cisco.com;
> >>         >     >
> >>         >     > >     > > guofeng@huawei.com;
> pete.mcallister@metaswitch.com;
> >>         >     >
> >>         >     > >     > > liuyisong@huawei.com; xu.benchong@zte.com.cn;
> >>         >     >
> >>         >     > >     > > tanmoy.kundu@alcatel-lucent.com;
> zzhang_ietf@hotmail.com
> >>         >     >
> >>         >     > >     > > Subject: RE: Hi all, about the modification
> of MSDP YANG
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Hi Xufeng and Reshad,
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > I am sorry for forgetting the point. I
> updated the YANG model.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > If no one has comments on it I'd like to
> submit the new version. :-)
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Thanks,
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Sandy
> >>         >     >
> >>         >     > >     > > 原始邮件
> >>         >     >
> >>         >     > >     > > 发件人:
> >>         > <Xufeng_Liu@jabil.com<mailto:Xufeng_Liu@jabil.com>>;
> >>         >     >
> >>         >     > >     > > 收件人: <rrahman@cisco.com<mailto:rrah
> man@cisco.com>>;
> >>         > 张征00007940;
> >>         >     >
> >>         >     > >     > > <anish.ietf@gmail.com<mailto:a
> nish.ietf@gmail.com>>;
> >>         >     >
> >>         >     > >     > > <masivaku@cisco.com<mailto:masivaku@cisco.com
> >>;
> >>         >     >
> >>         >     > >     > > <guofeng@huawei.com<mailto:guofeng@huawei.com
> >>;
> >>         >     >
> >>         >     > >     > >
> >>         > <pete.mcallister@metaswitch.com<mailto:pete.mcallister@
> metaswitch.co
> >>         >     > m>>;
> >>         >     >
> >>         >     > >     > > <liuyisong@huawei.com<mailto:l
> iuyisong@huawei.com>>;徐本
> >>         > 崇10065053;
> >>         >     >
> >>         >     > >     > > <tanmoy.kundu@alcatel-
> >>         > lucent.com<mailto:tanmoy.kundu@alcatel-lucent.
> >>         >     > com>>;
> >>         >     >
> >>         >     > >     > > <zzhang_ietf@hotmail.com<mailto:
> zzhang_ietf@hotmail.com>>;
> >>         >     >
> >>         >     > >     > > 日 期 :2018年02月03日 01:21
> >>         >     >
> >>         >     > >     > > 主 题 :RE: Hi all, about the modification of
> MSDP YANG
> >>         >     >
> >>         >     > >     > > Hi Sandy and Reshad,
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > The reason that we used to augment
> >>         >     >
> >>         >     > >     > > /rt:routing/rt:control-plane-protocols,
> instead of
> >>         >     >
> >>         >     > >     > > /rt:routing/rt:control-plane-
> protocols/rt:control-plane-protocol,
> >>         > is
> >>         >     >
> >>         >     > >     > > that we do not allow multiple instances of
> MSDP.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Thanks,
> >>         >     >
> >>         >     > >     > > - Xufeng
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > From: Reshad Rahman (rrahman) [mailto:
> rrahman@cisco.com]
> >>         >     >
> >>         >     > >     > > Sent: Friday, February 2, 2018 12:08 PM
> >>         >     >
> >>         >     > >     > > To: zhang.zheng@zte.com.cn<mailto:
> zhang.zheng@zte.com.cn>;
> >>         > Xufeng
> >>         >     > Liu
> >>         >     >
> >>         >     > >     > > <Xufeng_Liu@jabil.com<mailto:X
> ufeng_Liu@jabil.com>>;
> >>         >     >
> >>         >     > >     > > anish.ietf@gmail.com<mailto:an
> ish.ietf@gmail.com>; Mahesh
> >>         > Sivakumar
> >>         >     >
> >>         >     > >     > > (masivaku)
> >>         > <masivaku@cisco.com<mailto:masivaku@cisco.com>>;
> >>         >     >
> >>         >     > >     > > guofeng@huawei.com<mailto:guofeng@huawei.com
> >;
> >>         >     >
> >>         >     > >     > >
> >>         > pete.mcallister@metaswitch.com<mailto:pete.mcallister@
> metaswitch.com
> >>         >     > >;
> >>         >     >
> >>         >     > >     > > liuyisong@huawei.com<mailto:li
> uyisong@huawei.com>;
> >>         >     >
> >>         >     > >     > > xu.benchong@zte.com.cn<mailto:
> xu.benchong@zte.com.cn>;
> >>         >     >
> >>         >     > >     > > tanmoy.kundu@alcatel-
> >>         > lucent.com<mailto:tanmoy.kundu@alcatel-lucent.c
> >>         >     > om>;
> >>         >     >
> >>         >     > >     > > zzhang_ietf@hotmail.com<mailto:
> zzhang_ietf@hotmail.com>
> >>         >     >
> >>         >     > >     > > Subject: Re: Hi all, about the modification
> of MSDP YANG
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Hi Sandy,
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > I don’t know what warning you are getting now
> but from a quick
> >>         > look
> >>         >     > at
> >>         >     >
> >>         >     > >     > > the revision you sent I see couple of issues.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >      identity msdp {
> >>         >     >
> >>         >     > >     > >        base "rt:routing-protocol";  <==
> should be rt:control-plane-
> >>         >     > protocol
> >>         >     >
> >>         >     > >     > >        description "MSDP";
> >>         >     >
> >>         >     > >     > >      }
> >>         >     >
> >>         >     > >     > > <snip>
> >>         >     >
> >>         >     > >     > >      /*
> >>         >     >
> >>         >     > >     > >       * Data nodes
> >>         >     >
> >>         >     > >     > >       */
> >>         >     >
> >>         >     > >     > >      augment
> >>         >     >
> >>         >     > >     > >      "/rt:routing/rt:control-plane-
> protocols/rt:control-plane-
> >>         >     > protocol" {
> >>         >     >
> >>         >     > >     > >         when "rt:type = 'MSDP'" { <== should
> be "rt:type =
> >>         >     > 'msdp:msdp'"
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > HTH,
> >>         >     >
> >>         >     > >     > > Reshad.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > From:
> >>         > "zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>"
> >>         >     >
> >>         >     > >     > > <zhang.zheng@zte.com.cn<mailto:
> zhang.zheng@zte.com.cn>>
> >>         >     >
> >>         >     > >     > > Date: Friday, February 2, 2018 at 4:37 AM
> >>         >     >
> >>         >     > >     > > To: "xufeng_liu@jabil.com<mailto:x
> ufeng_liu@jabil.com>"
> >>         >     >
> >>         >     > >     > > <xufeng_liu@jabil.com<mailto:x
> ufeng_liu@jabil.com>>,
> >>         >     >
> >>         >     > >     > > "anish.ietf@gmail.com<mailto:a
> nish.ietf@gmail.com>"
> >>         >     >
> >>         >     > >     > > <anish.ietf@gmail.com<mailto:a
> nish.ietf@gmail.com>>, "Mahesh
> >>         >     > Sivakumar
> >>         >     >
> >>         >     > >     > > (masivaku)"
> >>         > <masivaku@cisco.com<mailto:masivaku@cisco.com>>,
> >>         >     >
> >>         >     > >     > > "guofeng@huawei.com<mailto:guofeng@huawei.com
> >"
> >>         >     >
> >>         >     > >     > > <guofeng@huawei.com<mailto:guofeng@huawei.com
> >>,
> >>         >     >
> >>         >     > >     > >
> >>         > "pete.mcallister@metaswitch.com<mailto:pete.mcallister@
> metaswitch.co
> >>         >     > m>"
> >>         >     >
> >>         >     > >     > >
> >>         > <pete.mcallister@metaswitch.com<mailto:pete.mcallister@
> metaswitch.co
> >>         >     > m>>,
> >>         >     >
> >>         >     > >     > > "liuyisong@huawei.com<mailto:l
> iuyisong@huawei.com>"
> >>         >     >
> >>         >     > >     > > <liuyisong@huawei.com<mailto:l
> iuyisong@huawei.com>>,
> >>         >     >
> >>         >     > >     > > "xu.benchong@zte.com.cn<mailto:
> xu.benchong@zte.com.cn>"
> >>         >     >
> >>         >     > >     > > <xu.benchong@zte.com.cn<mailto:
> xu.benchong@zte.com.cn>>,
> >>         >     >
> >>         >     > >     > > "tanmoy.kundu@alcatel-
> >>         > lucent.com<mailto:tanmoy.kundu@alcatel-lucent.
> >>         >     > com>"
> >>         >     >
> >>         >     > >     > > <tanmoy.kundu@alcatel-
> >>         > lucent.com<mailto:tanmoy.kundu@alcatel-lucent.
> >>         >     > com>>,
> >>         >     >
> >>         >     > >     > > "zzhang_ietf@hotmail.com<mailto:
> zzhang_ietf@hotmail.com>"
> >>         >     >
> >>         >     > >     > > <zzhang_ietf@hotmail.com<mailto:
> zzhang_ietf@hotmail.com>>
> >>         >     >
> >>         >     > >     > > Cc: "Reshad Rahman (rrahman)"
> >>         >     >
> >>         >     > >     > > <rrahman@cisco.com<mailto:rrahman@cisco.com>>
> >>         >     >
> >>         >     > >     > > Subject: FW: Hi all, about the modification
> of MSDP YANG
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Hi all,
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > I deleted some groupings and make the model
> more clear.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > And I updated the decription of (peer-as,
> up-time, expire).  Please
> >>         >     >
> >>         >     > >     > > review it.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > A warning is still existing about rt:type:
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > 5, - augment of control-plane-protocols is
> incorrect. There should
> >>         >     > be
> >>         >     >
> >>         >     > >     > > an identity msdp with
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > base "rt:routing-protocol" and then augment
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > "/rt:routing/rt:control-plane-
> protocols/rt:control-plane-protocol"
> >>         >     >
> >>         >     > >     > > with a when
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > statement. Take a look at OSPF YANG for an
> example.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Added the identity and modify the
> augmentation, but it
> >>         >     > seems
> >>         >     >
> >>         >     > >     > > like there is no MSDP register in rt:type.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > How can we register it?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Thanks,
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Sandy
> >>         >     >
> >>         >     > >     > > 原始邮件
> >>         >     >
> >>         >     > >     > > 发件人:张征00007940
> >>         >     >
> >>         >     > >     > > 收件人: <xufeng_liu@jabil.com<mailto:x
> ufeng_liu@jabil.com>>;
> >>         >     >
> >>         >     > >     > > <anish.ietf@gmail.com<mailto:a
> nish.ietf@gmail.com>>;
> >>         >     >
> >>         >     > >     > > <masivaku@cisco.com<mailto:masivaku@cisco.com
> >>;
> >>         >     >
> >>         >     > >     > > <guofeng@huawei.com<mailto:guofeng@huawei.com
> >>;
> >>         >     >
> >>         >     > >     > >
> >>         > <pete.mcallister@metaswitch.com<mailto:pete.mcallister@
> metaswitch.co
> >>         >     > m>>;
> >>         >     >
> >>         >     > >     > > <liuyisong@huawei.com<mailto:l
> iuyisong@huawei.com>>;徐本
> >>         > 崇10065053;
> >>         >     >
> >>         >     > >     > > <tanmoy.kundu@alcatel-
> >>         > lucent.com<mailto:tanmoy.kundu@alcatel-lucent.
> >>         >     > com>>;
> >>         >     >
> >>         >     > >     > > <zzhang_ietf@hotmail.com<mailto:
> zzhang_ietf@hotmail.com>>;
> >>         >     >
> >>         >     > >     > > 抄送人: <rrahman@cisco.com<mailto:rrah
> man@cisco.com>>;
> >>         >     >
> >>         >     > >     > > 日 期 :2018年01月29日  17:04
> >>         >     >
> >>         >     > >     > > 主 题 :Hi all, about the modification of MSDP
> YANG
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Hi all,
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > YANG doctor Reshad had finished the early
> review about MSDP
> >>         > YANG.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > I finished the preliminary modification
> version, please review it.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > I think some advices from Reshad should be
> discussed:
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > 1, - Not sure why peer-as is needed. Don't
> see it in RFC3618.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > 2, - leaf up-time, what's meant by "up time"
> in the description? Is
> >>         >     > it
> >>         >     >
> >>         >     > >     > > time it's
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > been created?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > 3, - description for leaf expire seems wrong.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: These items (peer-as, up-time,
> expire) doesn't existed in
> >>         >     >
> >>         >     > >     > > RFC3618, are these unnecessary? Please write
> down your
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > description if you insist on it. If nobody
> insist on it, should we
> >>         >     >
> >>         >     > >     > > delete them?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > 4, - Groupings are used for data which is
> used only once. Is this
> >>         >     > done
> >>         >     >
> >>         >     > >     > > on purpose or
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > was the intention to use those groupings more
> than once?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: These eight groupings are used only
> once, should we
> >>         > change
> >>         >     >
> >>         >     > >     > > them to container?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > authentication-container;
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > global-config-attributes;
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > peer-config-attributes;
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > peer-state-attributes;
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > sa-cache-state-attributes;
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > statistics-container
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > statistics-error
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > statistics-queue
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > 5, - augment of control-plane-protocols is
> incorrect. There should
> >>         >     > be
> >>         >     >
> >>         >     > >     > > an identity msdp with
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > base "rt:routing-protocol" and then augment
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > "/rt:routing/rt:control-plane-
> protocols/rt:control-plane-protocol"
> >>         >     >
> >>         >     > >     > > with a when
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > statement. Take a look at OSPF YANG for an
> example.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Added the identity and modify the
> augmentation, but it
> >>         >     > seems
> >>         >     >
> >>         >     > >     > > like there is no MSDP register in rt:type.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > How can we register it?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Most of the suggestion is adopted. The
> modification detail pls see
> >>         >     >
> >>         >     > >     > > below:
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - Too many features (17)! Every piece of
> config has an if-feature
> >>         >     >
> >>         >     > >     > > - statement.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Some of the configs (timers?) should be part
> of most/basic
> >>         >     >
> >>         >     > >     > > implementations, for
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > other config (e.g. authentication) I can see
> why a feature would
> >>         > be
> >>         >     >
> >>         >     > >     > > used.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Modified the three timers
> (connect-retry, hold, keepalive)
> >>         >     > to
> >>         >     >
> >>         >     > >     > > fixed format.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > -“import ietf-yang-types” should have a
> reference to RFC6991
> >>         > (see
> >>         >     >
> >>         >     > >     > > -section 4.7 of
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > rfc6087bis-15)
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - “import ietf-inet-types” should have a
> reference to RFC6991
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - “import ietf-routing” should have a
> reference to RFC8022
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - “import ietf-interfaces” should have a
> reference to RFC7223
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - "import ietf-ip" should have a reference to
> RFC7277
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - "import ietf-key-chain" should have a
> reference to RFC8177
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Added all the references above.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - organization s/"...PIM( Protocols for IP
> Multicast ) Working
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Group"/"...PIM (Protocols for IP Multicast)
> Working Group"?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - Remove WG Chairs from contact information
> as per Appendix C
> >>         > of
> >>         >     >
> >>         >     > >     > > - rfc6087bis-15
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - No copyright in the module description, see
> Appendix of
> >>         > 6087bis-15
> >>         >     > for
> >>         >     >
> >>         >     > >     > > - a module description
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > example
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - Module description must contain reference
> to RFC, see
> >>         > Appendix C
> >>         >     > of
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > rfc6087bis-15
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Removed WG chairs and add copyright
> from Appendix of
> >>         >     >
> >>         >     > >     > > rfc6087bis. Added reference to RFC3618.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - grouping authentication-container.
> key-chain and password
> >>         > both
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > use if-feature peer-key-chain.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Removed the if-feature
> peer-key-chain from password.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - grouping connect-source. The name is not
> very
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > descriptive. Should this be something along
> the lines of
> >>         >     >
> >>         >     > >     > > tcp-connection-source?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Changed the name "connect-source" to
> "tcp-connection-
> >>         >     > source".
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - grouping global-state-attributes has nothing
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Deleted the grouping.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - Some of the descriptions are
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > pretty terse. e.g. for rpf-peer it says "RPF
> peer.". In a case like
> >>         >     >
> >>         >     > >     > > this
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > consider adding more descriptive text or a
> reference to the
> >>         > proper
> >>         >     >
> >>         >     > >     > > section in
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > RFC3618
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Added more description.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - peer-as (Autonomous System Number) is
> defined as type string,
> >>         >     > should
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > be of type as-number in ietf-inet-types?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Modified to inet types.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - keepalive-interval depends on
> holdtime-interval.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > There should be "if-feature
> peer-timer-holdtime" under leaf
> >>         >     >
> >>         >     > >     > > keepalive-interval
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > or change the must statement to (assuming we
> keep the 2
> >>         > features):
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >   must "(not ../holdtime-interval) or (. > 1
> and . <
> >>         >     >
> >>         >     > >     > >   ../holdtime-interval)".
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Modified the features to fixed
> format.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - leaf up-time: s/sa cache/SA cache/
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - leaf peer-learned-from, change description
> from "The address
> >>         > of
> >>         >     > peer
> >>         >     >
> >>         >     > >     > > - that we learned
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > this SA from ." to "The address of the peer
> that we learned this SA
> >>         >     >
> >>         >     > >     > > from."
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Modified.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - RPC leaf group, I thought we had a type for
> IP multicast address?
> >>         >     > If
> >>         >     >
> >>         >     > >     > > - not, it should be done?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Yes. Added the rt-type reference to
> RFC8294.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - s/msdp/MSDP/
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - In rpc msdp-clear-peer, s/Clears the
> session to the peer./Clears
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > the TCP connection to the peer./
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - In rpc msdp-clear-sa-cache, why have the
> enum '*' for
> >>         >     >
> >>         >     > >     > > - source-addr. Can't the same technique as
> for peer-address be
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > used?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - msdp prefix not needed in rpc names
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Done.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - MSDP peers are configured in a mesh-group,
> did the authors
> >>         >     > consider
> >>         >     >
> >>         >     > >     > > - adding state per mesh-group, e.g. all the
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > peers in a particular mesh-group?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: IMO it is unnecessary because the
> states of peers is not
> >>         >     >
> >>         >     > >     > > unified in a mesh-group.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > General:
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - Per Appendix B of rfc6087bis-15: "that all
> YANG modules
> >>         > containing
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > imported items are cited as normative
> reference". So RFCs 6991,
> >>         >     > 7223,
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > 7277, 8022 and 8177 should be included in the
> normative
> >>         > reference
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > section.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Added.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - Section 3 "the irrelevant information", add
> a
> >>         >     > reference/explanation
> >>         >     >
> >>         >     > >     > > - for what
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > the irrelevant information is. s/the
> irrelevant
> >>         >     > information/irrelevant
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > information/?
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Changed the description.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - Section 5 should give a brief description
> of what the RPCs do.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Added some description.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - Section 6 any plans for notifications? If
> not, just say so.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Done.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - Need Security
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Considerations, see sections 3.7 and 6 of
> rfc6087bis-15
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Added security consideration section.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - Need IANA Considerations, see section 3.8
> of rfc6087bis-15
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Added IANA considerations.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > - Need license in YANG module,
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > see appendix B of rfc6087bis-15
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > [Sandy]: Added the YANG module description.
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Thanks,
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > > Sandy
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     > >
> >>         >     >
> >>         >     > >     >
> >>         >     >
> >>         >     > >     > _______________________________________________
> >>         >     >
> >>         >     > >     > 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
> >>         >     >
> >>         >     > >
> >>         >     >
> >>         >     > >     _______________________________________________
> >>         >     >
> >>         >     > >     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
> >>         >
> >>
> >>
> >>
> >>
> >>
> > _______________________________________________
> > yang-doctors mailing list
> > yang-doctors@ietf.org
> > https://www.ietf.org/mailman/listinfo/yang-doctors
>
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors
>
>
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors
>
>