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

Ladislav Lhotka <lhotka@nic.cz> Tue, 20 February 2018 14:44 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B31C1274D2 for <yang-doctors@ietfa.amsl.com>; Tue, 20 Feb 2018 06:44:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level:
X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL4zxJ-KRsm7 for <yang-doctors@ietfa.amsl.com>; Tue, 20 Feb 2018 06:44:00 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88310124B17 for <yang-doctors@ietf.org>; Tue, 20 Feb 2018 06:43:59 -0800 (PST)
Received: from birdie (37-48-39-170.tmcz.cz [37.48.39.170]) by mail.nic.cz (Postfix) with ESMTPSA id 948A7605C2 for <yang-doctors@ietf.org>; Tue, 20 Feb 2018 15:43:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1519137837; bh=R3zqCoEHY30o0rBrOaC2rHqlconfKiFggGR0lRBtwNs=; h=From:To:Date; b=S2xymMLIde5y6hYZ22EJq6mzdBHF3x6qLvcQ3CluL1pAxlmxdqF31aYy/KsLFUn84 mujTumblazFTCiagjnYCQZrJWjZrxvAbMuIlw9BsXETM1YddYGldinea8sVnLX5Z5f l/jE0axd5g7+7OhNCpnt6xjSJyFP51zmeY3Rut4w=
Message-ID: <1519137837.1496.5.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: yang-doctors@ietf.org
Date: Tue, 20 Feb 2018 15:43:57 +0100
In-Reply-To: <BN3PR0201MB0867C99BB3B3AB12346A664BF1CF0@BN3PR0201MB0867.namprd02.prod.outlook.com>
References: <BN3PR0201MB0867740F23053ADF02F39AD0F1F30@BN3PR0201MB0867.namprd02.prod.outlook.com> <22D8EED4-0A6C-4035-B01B-595CEEA9F2F1@cisco.com> <9AB8DC45-EFAE-462B-B291-B4432B49967F@cisco.com> <20180219.101346.2229730027340550251.mbj@tail-f.com> <874lmd47sc.fsf@chopps.org> <B4B94E93-48B4-4916-A0E7-3308775EF5AC@cisco.com> <BN3PR0201MB0867C99BB3B3AB12346A664BF1CF0@BN3PR0201MB0867.namprd02.prod.outlook.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.5
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/odK9gI3i0T67g7Ej7upVQKMXDBo>
Subject: Re: [yang-doctors] How to restrict to have single control-plane-protocol instance
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Feb 2018 14:44:05 -0000

On Tue, 2018-02-20 at 14:29 +0000, Xufeng Liu wrote:
> 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.

I agree with Chris, the empty string is preferable to inventing a magical name.
The ietf-routing module permits the "name" key to be empty, so implementations
should not choke on it.

Lada

> 
> 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>rg>; Martin Bjorklund <mbj@tail-f.com>
> > Cc: Xufeng Liu <Xufeng_Liu@jabil.com>om>; 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>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@ci
> > sco.com>
> >     >>         >     >
> >     >>         >     > >     > > Date: Monday, February 5, 2018 at 6:25 PM
> >     >>         >     >
> >     >>         >     > >     > > To: Xufeng Liu <Xufeng_Liu@jabil.com>om>,
> >     >>         > "zhang.zheng@zte.com.cn"
> >     >>         >     >
> >     >>         >     > >     > > <zhang.zheng@zte.com.cn>
> >     >>         >     >
> >     >>         >     > >     > > Cc: "anish.ietf@gmail.com" <anish.ietf@gmai
> > l.com>,
> > "Mahesh
> >     >>         > Sivakumar
> >     >>         >     >
> >     >>         >     > >     > > (masivaku)" <masivaku@cisco.com>om>,
> > "guofeng@huawei.com"
> >     >>         >     >
> >     >>         >     > >     > > <guofeng@huawei.com>om>,
> > "pete.mcallister@metaswitch.com"
> >     >>         >     >
> >     >>         >     > >     > > <pete.mcallister@metaswitch.com>om>,
> > "liuyisong@huawei.com"
> >     >>         >     >
> >     >>         >     > >     > > <liuyisong@huawei.com>om>, "xu.benchong@zte.co
> > m.cn"
> >     >>         >     >
> >     >>         >     > >     > > <xu.benchong@zte.com.cn>cn>, "tanmoy.kundu@alc
> > atel-
> >     >>         > lucent.com"
> >     >>         >     >
> >     >>         >     > >     > > <tanmoy.kundu@alcatel-lucent.com>om>,
> >     >>         > "zzhang_ietf@hotmail.com"
> >     >>         >     >
> >     >>         >     > >     > > <zzhang_ietf@hotmail.com>om>, "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@cisc
> > o.com>,
> >     >>         >     >
> >     >>         >     > >     > > "anish.ietf@gmail.com" <anish.ietf@gmail.co
> > m>,
> > "Mahesh
> >     >>         > Sivakumar
> >     >>         >     >
> >     >>         >     > >     > > (masivaku)" <masivaku@cisco.com>om>,
> > "guofeng@huawei.com"
> >     >>         >     >
> >     >>         >     > >     > > <guofeng@huawei.com>om>,
> > "pete.mcallister@metaswitch.com"
> >     >>         >     >
> >     >>         >     > >     > > <pete.mcallister@metaswitch.com>om>,
> > "liuyisong@huawei.com"
> >     >>         >     >
> >     >>         >     > >     > > <liuyisong@huawei.com>om>, "xu.benchong@zte.co
> > m.cn"
> >     >>         >     >
> >     >>         >     > >     > > <xu.benchong@zte.com.cn>cn>, "tanmoy.kundu@alc
> > atel-
> >     >>         > lucent.com"
> >     >>         >     >
> >     >>         >     > >     > > <tanmoy.kundu@alcatel-lucent.com>om>,
> >     >>         > "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.c
> > n;
> >     >>         >     >
> >     >>         >     > >     > > 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:rrahman@cisco.com>>;
> >     >>         > 张征00007940;
> >     >>         >     >
> >     >>         >     > >     > > <anish.ietf@gmail.com<mailto:anish.ietf@gma
> > il.com>>;
> >     >>         >     >
> >     >>         >     > >     > > <masivaku@cisco.com<mailto:masivaku@cisco.c
> > om>>;
> >     >>         >     >
> >     >>         >     > >     > >
> > <guofeng@huawei.com<mailto:guofeng@huawei.com>>;
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >
> > <pete.mcallister@metaswitch.com<mailto:pete.mcallister@metaswitch.co
> >     >>         >     > m>>;
> >     >>         >     >
> >     >>         >     > >     > >
> > <liuyisong@huawei.com<mailto:liuyisong@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:Xufeng_Liu@jab
> > il.com>>;
> >     >>         >     >
> >     >>         >     > >     > > anish.ietf@gmail.com<mailto:anish.ietf@gmai
> > l.com>;
> > Mahesh
> >     >>         > Sivakumar
> >     >>         >     >
> >     >>         >     > >     > > (masivaku)
> >     >>         > <masivaku@cisco.com<mailto:masivaku@cisco.com>>;
> >     >>         >     >
> >     >>         >     > >     > > guofeng@huawei.com<mailto:guofeng@huawei.co
> > m>;
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >
> > pete.mcallister@metaswitch.com<mailto:pete.mcallister@metaswitch.com
> >     >>         >     > >;
> >     >>         >     >
> >     >>         >     > >     > > liuyisong@huawei.com<mailto:liuyisong@huawe
> > i.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:xufeng_liu@jabil.com>"
> >     >>         >     >
> >     >>         >     > >     > > <xufeng_liu@jabil.com<mailto:xufeng_liu@jab
> > il.com>>,
> >     >>         >     >
> >     >>         >     > >     > > "anish.ietf@gmail.com<mailto:anish.ietf@gma
> > il.com>"
> >     >>         >     >
> >     >>         >     > >     > > <anish.ietf@gmail.com<mailto:anish.ietf@gma
> > il.com>>,
> > "Mahesh
> >     >>         >     > Sivakumar
> >     >>         >     >
> >     >>         >     > >     > > (masivaku)"
> >     >>         > <masivaku@cisco.com<mailto:masivaku@cisco.com>>,
> >     >>         >     >
> >     >>         >     > >     > > "guofeng@huawei.com<mailto:guofeng@huawei.c
> > om>"
> >     >>         >     >
> >     >>         >     > >     > >
> > <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:liuyisong@huawei.com>"
> >     >>         >     >
> >     >>         >     > >     > >
> > <liuyisong@huawei.com<mailto:liuyisong@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:xufeng_liu@jabil.com>>;
> >     >>         >     >
> >     >>         >     > >     > > <anish.ietf@gmail.com<mailto:anish.ietf@gma
> > il.com>>;
> >     >>         >     >
> >     >>         >     > >     > > <masivaku@cisco.com<mailto:masivaku@cisco.c
> > om>>;
> >     >>         >     >
> >     >>         >     > >     > >
> > <guofeng@huawei.com<mailto:guofeng@huawei.com>>;
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >
> > <pete.mcallister@metaswitch.com<mailto:pete.mcallister@metaswitch.co
> >     >>         >     > m>>;
> >     >>         >     >
> >     >>         >     > >     > >
> > <liuyisong@huawei.com<mailto:liuyisong@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:rrahman@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-do
> > ctors
> >     >>         >     >
> >     >>         >     > >     --
> >     >>         >     >
> >     >>         >     > >     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-doct
> > ors
> >     >>         >     >
> >     >>         >     > >
> >     >>         >     >
> >     >>         >     > >
> >     >>         >     >
> >     >>         >     --
> >     >>         >     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
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67