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

Xufeng Liu <Xufeng_Liu@jabil.com> Mon, 19 February 2018 14:36 UTC

Return-Path: <Xufeng_Liu@jabil.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF261276AF for <yang-doctors@ietfa.amsl.com>; Mon, 19 Feb 2018 06:36:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.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 PwtseYMcH-XC for <yang-doctors@ietfa.amsl.com>; Mon, 19 Feb 2018 06:36:12 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0114.outbound.protection.outlook.com [104.47.33.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE1912762F for <yang-doctors@ietf.org>; Mon, 19 Feb 2018 06:36:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XvxeHfG5MP0lGjeSNtox0Soganp7FS8AnQivMnO1pTc=; b=BQtMYNo0ZFgTRgTcOKA893LucJZA0IdW3dl5WXQvhl0ruNGOhHGhjBMW0nJZAhX0Y87Q90wYlWO1rFP5g0zuYoYPE50RuMa1ZthBxSxOXvHZSr0xhA1UlA3SqxKWi+sBmvZypodVDotxxEc0pUEproauOYi7KcGyT7Nc6RF9lwM=
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB1025.namprd02.prod.outlook.com (10.161.207.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 14:36:04 +0000
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([fe80::99f9:82ca:f5f2:2f8b]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([fe80::99f9:82ca:f5f2:2f8b%13]) with mapi id 15.20.0506.023; Mon, 19 Feb 2018 14:36:04 +0000
From: Xufeng Liu <Xufeng_Liu@jabil.com>
To: Martin Bjorklund <mbj@tail-f.com>, "acee@cisco.com" <acee@cisco.com>
CC: "rrahman@cisco.com" <rrahman@cisco.com>, "lhotka@nic.cz" <lhotka@nic.cz>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>
Thread-Topic: [yang-doctors] How to restrict to have single control-plane-protocol instance
Thread-Index: AQHToHz+iqb8zCrKLke5wcDQ+oqkJqOaKkyAgAAW6YCAABg5gIAACJ8AgAAGQYCAACxmAIAAAFBwgAru0wCAAjGkgIADzW4AgABOjcA=
Date: Mon, 19 Feb 2018 14:36:04 +0000
Message-ID: <BN3PR0201MB0867DF2125F37887776326E5F1C80@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>
In-Reply-To: <20180219.101346.2229730027340550251.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTdmMTZhZDM0LTE1ODEtMTFlOC05YzQ0LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFw3ZjE2YWQzNS0xNTgxLTExZTgtOWM0NC0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjYwNDI3IiB0PSIxMzE2MzUyNDI1NzI4NDc3OTciIGg9Ii9xbkFBZHFmNmFwZFFqOWpKL01CVSt4amRlVT0iIGlkPSIiIGJsPSIwIiBibz0iMSIvPjwvbWV0YT4=
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com;
x-originating-ip: [98.191.72.170]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0201MB1025; 20:FPJ4JNXHjgjbekrPg73hTQnzXXCi7byI/GgXEuyLsdEVr6EMw2enXGMhH7fNvJDRaAhOzgW/URY0tj70OFnpRKeRBAn+wPhuhLImXl6Q5iJr0E1J3P/kN6ZWejocG/uuXZtYBnZBENJgsYWXui0XqeMwQZfMvAY8PVnSO3FZ3i0=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 746f026b-608a-4c7f-9f87-08d577a61b2d
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN3PR0201MB1025;
x-ms-traffictypediagnostic: BN3PR0201MB1025:
x-microsoft-antispam-prvs: <BN3PR0201MB10251086E6F8B7B71E123F93F1C80@BN3PR0201MB1025.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(50582790962513)(85827821059158)(95692535739014)(130873036417446)(194151415913766)(21534305686606);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231101)(944501161)(3002001)(6055026)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:BN3PR0201MB1025; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB1025;
x-forefront-prvs: 0588B2BD96
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(39860400002)(396003)(39380400002)(53754006)(51914003)(377424004)(13464003)(199004)(189003)(2900100001)(54906003)(6246003)(3846002)(6116002)(110136005)(33656002)(561944003)(53936002)(106356001)(9686003)(55016002)(6306002)(53946003)(16200700003)(5660300001)(74316002)(305945005)(25786009)(551544002)(3280700002)(316002)(93886005)(4326008)(8676002)(2906002)(97736004)(80792005)(7736002)(81156014)(45080400002)(478600001)(81166006)(8936002)(72206003)(966005)(229853002)(2950100002)(105586002)(186003)(26005)(14454004)(3660700001)(66066001)(7696005)(6436002)(99286004)(76176011)(114624004)(53546011)(6506007)(102836004)(59450400001)(2501003)(5250100002)(68736007)(86362001)(559001)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB1025; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: xAvvfuwsl2baELaY6AruudcZz63loMAtWiT5FBJKVXmvNwPUBs1sHWoGPT6o7AKWDpkgz86fPZ85T/HSOaf67N044TcQ2GzlyLo7UfLghGPDc46fl70H8nl3/XZIGdYZ40LtW7YQpvJB0Ng6nJKKMgMpUZDuStbcABmxbaaTzTM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: jabil.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 746f026b-608a-4c7f-9f87-08d577a61b2d
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 14:36:04.5794 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB1025
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/EZ8KqR3HmBvAbx6a_Uxf29JNLxk>
Subject: Re: [yang-doctors] How to restrict to have single control-plane-protocol instance
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Feb 2018 14:36:17 -0000


> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Monday, February 19, 2018 4:14 AM
> To: acee@cisco.com
> Cc: rrahman@cisco.com; Xufeng Liu <Xufeng_Liu@jabil.com>om>; lhotka@nic.cz;
> yang-doctors@ietf.org; zhang.zheng@zte.com.cn
> Subject: Re: [yang-doctors] How to restrict to have single control-plane-
> protocol instance
> 
> 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).
> 
> With options #1 and #2, if you need a reference to a control plane
> protocol, you can always have a leafref to the well-known single list
> of protocols.  With option #3, you need a leafref to either a protocol
> in this list, or some of the singletons (if you know where to find
> them).
> 
> There's a similiar issue with augments; if you want to augment some
> generic additional data to all control-plane protocols, you can
> augment a single list with option #1 and #2.  With option #3 you'd
> have to explicitly augment all singletons as well.  This is not very
> scalable.

[Xufeng] Such a common augmentation and reference are not anticipated. Is there such a use case? Each protocol is designed and structured too differently to require or fit a common augmentation. Such "singleton" protocols are designed to be managed by simple "enable" or "disable" operations, without using the concept of instantiation. The instance name does not exist in the implementation. An analogy is to "enable IPv4 or IPv6 on an interface", which we do not model as "create an IPv6 instance with a well-known instance name, on an interface.".

Thanks,
- Xufeng

> 
> > Other than the simplicity of option #1, I'm not sure I fully
> > appreciate the pros and cons of #2
> 
> #2 is really just a more formal version of #1.  There is a constraint
> and it is either formally defined with XPath, or just defined in text.
> 
> 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.
> 
> 
> /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@cisco.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@gmail.com>om>,
> "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.com.cn"
> >         >     >
> >         >     > >     > > <xu.benchong@zte.com.cn>cn>, "tanmoy.kundu@alcatel-
> >         > 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@cisco.com>om>,
> >         >     >
> >         >     > >     > > "anish.ietf@gmail.com" <anish.ietf@gmail.com>om>,
> "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.com.cn"
> >         >     >
> >         >     > >     > > <xu.benchong@zte.com.cn>cn>, "tanmoy.kundu@alcatel-
> >         > 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.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:rrahman@cisco.com>>;
> >         > 张征00007940;
> >         >     >
> >         >     > >     > > <anish.ietf@gmail.com<mailto:anish.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: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@jabil.com>>;
> >         >     >
> >         >     > >     > > anish.ietf@gmail.com<mailto:anish.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:liuyisong@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:xufeng_liu@jabil.com>"
> >         >     >
> >         >     > >     > > <xufeng_liu@jabil.com<mailto:xufeng_liu@jabil.com>>,
> >         >     >
> >         >     > >     > > "anish.ietf@gmail.com<mailto:anish.ietf@gmail.com>"
> >         >     >
> >         >     > >     > > <anish.ietf@gmail.com<mailto:anish.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: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@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: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-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
> >         >
> >
> >
> >
> >
> >