Re: [yang-doctors] How to restrict to have single control-plane-protocol instance
Xufeng Liu <Xufeng_Liu@jabil.com> Tue, 20 February 2018 14:29 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 8F8FB127010 for <yang-doctors@ietfa.amsl.com>; Tue, 20 Feb 2018 06:29:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 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, URIBL_BLOCKED=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 37BYyZKytu5P for <yang-doctors@ietfa.amsl.com>; Tue, 20 Feb 2018 06:29:07 -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 48FBB124B17 for <yang-doctors@ietf.org>; Tue, 20 Feb 2018 06:29:07 -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=5HpehwO7ViN+Y+sHo/3g6SglEv+KazEIkTvCdZ6fado=; b=R+S9lNpU/2c9KRFiIaKgaCkRgpVwEPwJkp9dqfyYCKQv0JlnuSUsyY7eoiGJO+FqyIgERXfRuFUJi7V0hKmEjeb9p+eCFfW3nOGoYVuYJc1CFPK3KmmH0Up4oqLYli36ouv/owDyd7dCBz3NR8+fASJxyDPJr0CdbkvAGIJM3BE=
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0865.namprd02.prod.outlook.com (10.160.154.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Tue, 20 Feb 2018 14:29:02 +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; Tue, 20 Feb 2018 14:29:02 +0000
From: Xufeng Liu <Xufeng_Liu@jabil.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, Christian Hopps <chopps@chopps.org>, Martin Bjorklund <mbj@tail-f.com>
CC: "zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
Thread-Topic: [yang-doctors] How to restrict to have single control-plane-protocol instance
Thread-Index: AQHToHz+iqb8zCrKLke5wcDQ+oqkJqOaKkyAgAAW6YCAABg5gIAACJ8AgAAGQYCAACxmAIAAAFBwgAru0wCAAjGkgIADzW4AgAANdICAAI92gIABR0Aw
Date: Tue, 20 Feb 2018 14:29:02 +0000
Message-ID: <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>
In-Reply-To: <B4B94E93-48B4-4916-A0E7-3308775EF5AC@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWEzNmQwN2Y5LTE2NDktMTFlOC05YzQ1LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFxhMzZkMDdmYS0xNjQ5LTExZTgtOWM0NS0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjY4NDM2IiB0PSIxMzE2MzYxMDIxODczODQ0NDkiIGg9InQ2cTVnangzTG5lUFZZRTlzQUdrcitVY1ZUND0iIGlkPSIiIGJsPSIwIiBibz0iMSIvPjwvbWV0YT4=
x-originating-ip: [98.191.72.170]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0865; 7:oeuFgdrKmbEOAsfO7cVcUwfXijaGcx+nr6MueDp6e7TKO5SZ4fz26CPA1qyR6d5A+NlCPVj+f8oyQWQOVRkXGEAb1hNsZ/HshmsYW0OjDg2fMQI64g9VkkBrRxlp9eStKEZ0fkuzr2P2vNUTngaWw8GzziNbtQB7BsY2MGcEn47J79jyyYmIaJ6dpmLJEOlDF5rH9X0W11XdVFgs1Brbb1cpWBNhhrbFYf8AKzOvyZxZqwFeTcUBKVWMQO66fkuR; 20:m22nJoeh0lXjk2vmoJPvzvalQfeATth7Rc2tmKlUtwwseZQeHYFCpQPPyerlLOL+Oh6LUfFj/0Lpb7BCEDfBIgFd7gf6pSbyXeP4TgyRUeDnBeE2M4NqdXcl1Gzf/uQkavYmQFOQy+xowsIUfQJInviWejkeRgKncw5gVWYj6lc=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 9ba094f5-53be-4a46-ca91-08d5786e49e9
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:BN3PR0201MB0865;
x-ms-traffictypediagnostic: BN3PR0201MB0865:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com;
x-microsoft-antispam-prvs: <BN3PR0201MB0865A12F63DF2D0591EC94AAF1CF0@BN3PR0201MB0865.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)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BN3PR0201MB0865; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB0865;
x-forefront-prvs: 05891FB07F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(376002)(366004)(346002)(396003)(51444003)(377424004)(53754006)(189003)(199004)(51914003)(13464003)(7696005)(26005)(97736004)(54906003)(68736007)(6506007)(80792005)(186003)(551544002)(53546011)(76176011)(110136005)(2906002)(3660700001)(45080400002)(229853002)(4326008)(102836004)(6246003)(5660300001)(106356001)(14454004)(53946003)(3280700002)(7736002)(305945005)(99286004)(53936002)(114624004)(5250100002)(74316002)(6436002)(478600001)(105586002)(8676002)(81166006)(81156014)(316002)(16200700003)(66066001)(9686003)(2900100001)(72206003)(6116002)(86362001)(3846002)(59450400001)(93886005)(561944003)(6306002)(8936002)(966005)(2950100002)(25786009)(33656002)(55016002)(502464002)(579004)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0865; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: z4nuxmuZYiL/pZ9trqrZWktDF6bL4iljZw5cUAX2NqGLUYT5SHOSFPu1hW+wPyX7ujaw8YFgP8eK+hRSIQj8pO2fo9VnFRgHiG5COUKQd0FJ+Nq+XX2EZxgmTkPoYSgrh81lqYPwSTt6paVxTU1YMaM4NvfIGQvzkgXB9Q1PZm0=
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: 9ba094f5-53be-4a46-ca91-08d5786e49e9
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2018 14:29:02.0993 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0865
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/ozIZH6FklThXIMZ20XmyrzZQCxY>
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:29:13 -0000
Using "" as the name is better, but I am not sure that it is good enough. When we use ConfD to translate the model to a command line, if the option "tailf:cli-expose-key-name" is not used, we will have: edit routing control-plane-protocols control-plane-protocol type msdp name ''" If the option "tailf:cli-expose-key-name" is used, we will have: edit routing control-plane-protocols control-plane-protocol msdp ''" I am pretty sure that we would get a bug report on this, asking what is the purpose to have: name ''", and requesting a suppression on the term, but we do not have a good way to achieve. As a comparison, the option #3 will give: edit routing control-plane-protocols msdp This is the only acceptable solution so far. When a model is not usable by the end-user, other considerations (such as augmentation convenience) will not matter. Thanks, - Xufeng > -----Original Message----- > From: Acee Lindem (acee) [mailto:acee@cisco.com] > Sent: Monday, February 19, 2018 1:35 PM > To: Christian Hopps <chopps@chopps.org>; Martin Bjorklund <mbj@tail-f.com> > Cc: Xufeng Liu <Xufeng_Liu@jabil.com>; zhang.zheng@zte.com.cn; yang- > doctors@ietf.org > Subject: Re: [yang-doctors] How to restrict to have single control-plane- > protocol instance > > > > On 2/19/18, 5:02 AM, "Christian Hopps" <chopps@chopps.org> wrote: > > > Martin Bjorklund <mbj@tail-f.com> writes: > > > Hi, > > > > "Acee Lindem (acee)" <acee@cisco.com> wrote: > >> All, > >> > >> As seems to be the modus operandi for YANG issues, we have 3 separate > opinions as to how a protocol only supporting a single instance should be > realized. > >> > >> 1. Augment the existing control plane protocols list (RFC 8022BIS) > >> and specify in the description text that only a single instance is > >> supported. > >> 2. Augment the existing control plane protocols list (RFC 8022BIS) > >> and use a YANG 1.1 must() restriction as discussed by Martin and > >> Lada. > >> 3. Augment the container one level up from the list for singleton > >> protocols (suggested by Xufeng). > > > But I think there was also a proposal to require the single instance > > to have a well-known name - but maybe this proposal is no longer on > > the table. > > I actually liked this solution; however, instead of picking an arbitrary "well- > known" value for name, I would specify the 0 length string instead. I think that > reinforces the idea that this isn't actually a named instance. :) > > augment "/rt:routing/rt:control-plane-protocols/" > + "rt:control-plane-protocol" { > when "derived-from-or-self(rt:type, 'msdp:msdp') and rt:name = ''" { > container msdp { > > One benefit of this solution is that it solves Xufeng's issue of what the client uses > as the instance name. > > > Thanks, > Chris. > > > > > > > /martin > > > > > >> and #3. For #3, one determent would be that the control plane protocols > are in a location other than where they were originally envisioned and I don't > relish pulling RFC8022BIS off the RFC queue to document. > >> > >> Thanks, > >> Acee > >> > >> On 2/15/18, 8:39 AM, "Reshad Rahman (rrahman)" <rrahman@cisco.com> > wrote: > >> > >> Hi Xufeng, > >> > >> I think the intent of 8022bis was to have all protocols under > /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol. I agree that > forcing a name for a single-instance is cumbersome, but I think it is too late to > change tree hierachy organization at this point. > >> > >> I will defer to other YDs and 8022bis authors on this. > >> > >> Regards, > >> Reshad. > >> > >> On 2018-02-08, 9:48 AM, "Xufeng Liu" <Xufeng_Liu@jabil.com> wrote: > >> > >> Hi All, > >> > >> I feel that such a solution is still not clean enough to outweigh the > simple augmentation to "/rt:routing/rt:control-plane-protocols/". > >> > >> Some considerations are: > >> > >> - Name management: Neither the operator nor the implementation > wants to deal with the artificial name, whether it is hardcoded, user-configured, > or system-generated. When we implement such singleton protocol, we don't > save a name anywhere. > >> - The complexity of validation: The "when" statement is an > unnecessary expense to the user and to the implementation, especially if we > need to check all instances. > >> - Data tree query: If the singleton "MSDP" is mixed with other protocol > instances, it is less obvious or harder to search for. Depending on the > implementation, it would be worse if the entire list needs to be iterated. > >> - Tree hierarchy organization: I don't see too big a problem with "all > single-instance protocols under /rt:routing/rt:control-plane-protocols and all > the multi-instance ones under /rt:routing/rt:control-plane-protocols/rt:control- > plane-protocol". If necessary, some of the names can be adjusted. > >> > >> Thanks, > >> - Xufeng > >> > >> > >> > -----Original Message----- > >> > From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] > >> > Sent: Thursday, February 8, 2018 9:41 AM > >> > To: Ladislav Lhotka <lhotka@nic.cz>; Martin Bjorklund <mbj@tail- > f.com>; > >> > Acee Lindem (acee) <acee@cisco.com> > >> > Cc: yang-doctors@ietf.org; zhang.zheng@zte.com.cn; Xufeng Liu > >> > <Xufeng_Liu@jabil.com> > >> > Subject: Re: [yang-doctors] How to restrict to have single control- > plane- > >> > protocol instance > >> > > >> > Thanks for the suggestions. I agree that hard-coding the name is a > bad idea, > >> > glad that a cleaner way of doing this is possible. > >> > - We can move the must statement up to restrict max of 1 control- > plane- > >> > protocol instance of type msdp? > >> > - Acee/Lada, should a note be added to section 5.3 of 8022bis > regarding how > >> > to enforce single instance? How much of a concern is the > performance > >> > impact in this specific case? > >> > > >> > Regards, > >> > Reshad. > >> > > >> > On 2018-02-08, 7:02 AM, "Ladislav Lhotka" <lhotka@nic.cz> wrote: > >> > > >> > On Thu, 2018-02-08 at 12:39 +0100, Martin Bjorklund wrote: > >> > > "Acee Lindem (acee)" <acee@cisco.com> wrote: > >> > > > Hi Lada, > >> > > > >> > > > > >> > > > >> > > > On 2/8/18, 4:42 AM, "yang-doctors on behalf of Ladislav > Lhotka" > >> > <yang-docto > >> > > rs-bounces@ietf.org on behalf of lhotka@nic.cz> wrote: > >> > > > >> > > > > >> > > > >> > > > On Thu, 2018-02-08 at 09:20 +0100, Martin Bjorklund wrote: > >> > > > >> > > > > Hi, > >> > > > >> > > > > > >> > > > >> > > > > "Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote: > >> > > > >> > > > > > Hi YDs, > >> > > > >> > > > > > > >> > > > >> > > > > > MSDP YANG authors want to enforce single-instance of > MSDP > >> > > > >> > > > > > control-plane protocol. The when “rt:type = > ‘msdp’“ allows > >> > multiple > >> > > > >> > > > > > control-pane-protocol instances as long as they have > different > >> > > > >> > > > > > rt:name. The only workaround I thought of is to have a > when > >> > > statement > >> > > > >> > > > > > on the name in the top level container. This would still > multiple > >> > > > >> > > > > > control-plane-protocol instance of type msdp but > restricts the > >> > name > >> > > to > >> > > > >> > > > > > a fixed name (msdp-protocol in this case) for the top level > msdp > >> > > > >> > > > > > container to exist. Any suggestions on how to do this > better? > >> > > > >> > > > > > >> > > > >> > > > > Hard-coding a name like this is IMO a bad idea. > >> > > > >> > > > > > >> > > > >> > > > > Better would be to simply state in text that there MUST > only be one > >> > > > >> > > > > instance of this type. > >> > > > >> > > > > > >> > > > >> > > > > But you can also add a must statement that enforces this: > >> > > > >> > > > > > >> > > > >> > > > > augment "/rt:routing/rt:control-plane-protocols/" > >> > > > >> > > > > + "rt:control-plane-protocol" { > >> > > > >> > > > > when 'derived-from-or-self(rt:type, "msdp:msdp"' { > >> > > > >> > > > > container msdp { > >> > > > >> > > > > must 'count(/rt:routing/rt:control-plane-protocols/' > >> > > > >> > > > > + ' rt:control-plane-protocol[' > >> > > > >> > > > > + ' derived-from-or-sel(../rt:type, "msdp:msdp")]) > <= > >> > > 1'"; > >> > > > >> > > > > > >> > > > >> > > > > > >> > > > >> > > > > In general, you should be careful with the usage of "count", > since it > >> > > > >> > > > > will loop through *all* instances in the list every time. If > the list > >> > > > >> > > > > is big, this can have a performance impact. > >> > > > >> > > > > >> > > > >> > > > Instead of count(), it is possible to use the so-called > Muenchian > >> > > method: > >> > > > >> > > > > >> > > > >> > > > container msdp { > >> > > > >> > > > must "not(../preceding-sibling::rt:control-plane- > protocol[" > >> > > > >> > > > + "derived-from-or-self(rt:type, 'msdp:msdp')])"; > >> > > > >> > > > .. > >> > > > >> > > > } > >> > > > >> > > > > >> > > > >> > > > It basically states that the control-plane-protocol containing > the > >> > > "msdp" > >> > > > >> > > > container must not be preceded with a control-plane- > protocol entry > >> > of > >> > > the > >> > > > >> > > > msdp:msdp type (or derived). > >> > > > >> > > > > >> > > > >> > > > This looks like an elegant solution. > >> > > > >> > > > >> > > "elegant" as in "less obvious" ;) It has the same time complexity > as > >> > > the count() solution. > >> > > >> > It should be faster on the average - it has to scan only preceding > siblings of > >> > the MSDP protocol instance whereas count() always has to check > *all* > >> > protocol > >> > instances. > >> > > >> > It is true though that in XSLT this technique can be made > considerably > >> > more > >> > efficient by using indexed keys. > >> > > >> > Lada > >> > > >> > > > >> > > > >> > > However, since the key for the control-plane-protocol list is > "type > >> > > name", won't it only work if the previous sibling has a "name" > that > >> > > is precedes the one being added? > >> > > > >> > > For each list entry that has this container, the expression is > >> > > evaluated. It will scan all preceding entries and ensure that there > >> > > are none with this type. So the order of the entries doesn't > matter; > >> > > if there are two with the same type, one of them has to be > before the > >> > > other. > >> > > > >> > > > >> > > /martin > >> > > > >> > > > >> > > > > >> > > > >> > > > Thanks, > >> > > > >> > > > Acee > >> > > > >> > > > > >> > > > >> > > > > >> > > > >> > > > Lada > >> > > > >> > > > > >> > > > >> > > > > > >> > > > >> > > > > Also note that I use derived-from-or-self instead of equality > for the > >> > > > >> > > > > identity. > >> > > > >> > > > > > >> > > > >> > > > > > >> > > > >> > > > > /martin > >> > > > >> > > > > > >> > > > >> > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > Regards, > >> > > > >> > > > > > Reshad. > >> > > > >> > > > > > > >> > > > >> > > > > > augment "/rt:routing/rt:control-plane-protocols/" > >> > > > >> > > > > > + "rt:control-plane-protocol" { > >> > > > >> > > > > > when "rt:type = ‘msdp’" { > >> > > > >> > > > > > description > >> > > > >> > > > > > "….”; > >> > > > >> > > > > > } > >> > > > >> > > > > > description "…."; > >> > > > >> > > > > > > >> > > > >> > > > > > container msdp { > >> > > > >> > > > > > when "../rt:name = ‘msdp-protocol’" { > >> > > > >> > > > > > description > >> > > > >> > > > > > "…."; > >> > > > >> > > > > > } > >> > > > >> > > > > > description "MSDP top level container."; > >> > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > From: "Reshad Rahman (rrahman)" <rrahman@cisco.com> > >> > > > >> > > > > > Date: Monday, February 5, 2018 at 6:25 PM > >> > > > >> > > > > > To: Xufeng Liu <Xufeng_Liu@jabil.com>, > >> > "zhang.zheng@zte.com.cn" > >> > > > >> > > > > > <zhang.zheng@zte.com.cn> > >> > > > >> > > > > > Cc: "anish.ietf@gmail.com" <anish.ietf@gmail.com>, > "Mahesh > >> > Sivakumar > >> > > > >> > > > > > (masivaku)" <masivaku@cisco.com>, > "guofeng@huawei.com" > >> > > > >> > > > > > <guofeng@huawei.com>, > "pete.mcallister@metaswitch.com" > >> > > > >> > > > > > <pete.mcallister@metaswitch.com>, > "liuyisong@huawei.com" > >> > > > >> > > > > > <liuyisong@huawei.com>, "xu.benchong@zte.com.cn" > >> > > > >> > > > > > <xu.benchong@zte.com.cn>, "tanmoy.kundu@alcatel- > >> > lucent.com" > >> > > > >> > > > > > <tanmoy.kundu@alcatel-lucent.com>, > >> > "zzhang_ietf@hotmail.com" > >> > > > >> > > > > > <zzhang_ietf@hotmail.com>, "Acee Lindem (acee)" > >> > <acee@cisco.com> > >> > > > >> > > > > > Subject: Re: Hi all, about the modification of MSDP YANG > >> > > > >> > > > > > > >> > > > >> > > > > > Hi Sandy and Xufeng, > >> > > > >> > > > > > > >> > > > >> > > > > > I understand that you want only 1 MSDP instance but I > don’t think > >> > > that > >> > > > >> > > > > > justifies /rt:routing/rt:control-plane-protocols. If we do > that we > >> > > > >> > > > > > will end up with all single-instance protocols under > >> > > > >> > > > > > /rt:routing/rt:control-plane-protocols and all the multi- > instance > >> > > ones > >> > > > >> > > > > > under > >> > > > >> > > > > > /rt:routing/rt:control-plane-protocols/rt:control-plane- > protocol. > >> > > > >> > > > > > > >> > > > >> > > > > > I am not sure what’s the best way to enforce single- > instance, I can > >> > > > >> > > > > > check with the other YDs on this topic. One way it can be > done is > >> > as > >> > > > >> > > > > > follows (I’ve added the when statement in bold to > existing BFD > >> > > model), > >> > > > >> > > > > > it enforces that the protocol name is ‘bfdv1’. So multiple > >> > instances > >> > > > >> > > > > > with rt:type=bfd-types:bfdv1 could be created, but only > one of > >> > these > >> > > > >> > > > > > instances can have the bfd container. This is probably not > the > >> > best > >> > > > >> > > > > > way but the point is that IMO protocols have to go under > >> > > > >> > > > > > /rt:routing/rt:control-plane-protocols/rt:control-plane- > protocol. > >> > > > >> > > > > > > >> > > > >> > > > > > Regards, > >> > > > >> > > > > > Reshad. > >> > > > >> > > > > > > >> > > > >> > > > > > augment "/rt:routing/rt:control-plane-protocols/" > >> > > > >> > > > > > + "rt:control-plane-protocol" { > >> > > > >> > > > > > when "rt:type = 'bfd-types:bfdv1'" { > >> > > > >> > > > > > description > >> > > > >> > > > > > "This augmentation is only valid for a control-plane > >> > > protocol > >> > > > >> > > > > > instance of BFD (type 'bfdv1')."; > >> > > > >> > > > > > } > >> > > > >> > > > > > description "BFD augmentation."; > >> > > > >> > > > > > > >> > > > >> > > > > > container bfd { > >> > > > >> > > > > > when "../rt:name = 'bfdv1'" { > >> > > > >> > > > > > description > >> > > > >> > > > > > "This augmentation is only valid for a control-plane > >> > > protocol > >> > > > >> > > > > > instance of BFD (type 'bfdv1')."; > >> > > > >> > > > > > } > >> > > > >> > > > > > description "BFD top level container."; > >> > > > >> > > > > > > >> > > > >> > > > > > From: Xufeng Liu <Xufeng_Liu@jabil.com> > >> > > > >> > > > > > Date: Monday, February 5, 2018 at 9:38 AM > >> > > > >> > > > > > To: "zhang.zheng@zte.com.cn" > <zhang.zheng@zte.com.cn> > >> > > > >> > > > > > Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, > >> > > > >> > > > > > "anish.ietf@gmail.com" <anish.ietf@gmail.com>, > "Mahesh > >> > Sivakumar > >> > > > >> > > > > > (masivaku)" <masivaku@cisco.com>, > "guofeng@huawei.com" > >> > > > >> > > > > > <guofeng@huawei.com>, > "pete.mcallister@metaswitch.com" > >> > > > >> > > > > > <pete.mcallister@metaswitch.com>, > "liuyisong@huawei.com" > >> > > > >> > > > > > <liuyisong@huawei.com>, "xu.benchong@zte.com.cn" > >> > > > >> > > > > > <xu.benchong@zte.com.cn>, "tanmoy.kundu@alcatel- > >> > lucent.com" > >> > > > >> > > > > > <tanmoy.kundu@alcatel-lucent.com>, > >> > "zzhang_ietf@hotmail.com" > >> > > > >> > > > > > <zzhang_ietf@hotmail.com> > >> > > > >> > > > > > Subject: RE: Hi all, about the modification of MSDP YANG > >> > > > >> > > > > > > >> > > > >> > > > > > Hi Sandy, > >> > > > >> > > > > > > >> > > > >> > > > > > Thanks for the updates. > >> > > > >> > > > > > > >> > > > >> > > > > > In RFC8022bis, the rt:type is defined under > >> > > > >> > > > > > /rt:routing/rt:control-plane-protocols/rt:control-plane- > protocol. > >> > If > >> > > > >> > > > > > we augment /rt:routing/rt:control-plane-protocols, the > “when” > >> > > > >> > > > > > statement will not be valid, because it cannot find the > rt:type. I > >> > > > >> > > > > > don’t think that we need the “when” statement. The > container > >> > with > >> > > > >> > > > > > “presence” will serve the purpose of the identity. We can > simply > >> > > take > >> > > > >> > > > > > out the “when” statement and the definition of the MSDP > identity. > >> > > > >> > > > > > > >> > > > >> > > > > > Thanks, > >> > > > >> > > > > > - Xufeng > >> > > > >> > > > > > > >> > > > >> > > > > > From: zhang.zheng@zte.com.cn > [mailto:zhang.zheng@zte.com.cn] > >> > > > >> > > > > > Sent: Monday, February 5, 2018 3:36 AM > >> > > > >> > > > > > To: Xufeng Liu <Xufeng_Liu@jabil.com> > >> > > > >> > > > > > Cc: rrahman@cisco.com; anish.ietf@gmail.com; > >> > masivaku@cisco.com; > >> > > > >> > > > > > guofeng@huawei.com; > pete.mcallister@metaswitch.com; > >> > > > >> > > > > > liuyisong@huawei.com; xu.benchong@zte.com.cn; > >> > > > >> > > > > > tanmoy.kundu@alcatel-lucent.com; > zzhang_ietf@hotmail.com > >> > > > >> > > > > > Subject: RE: Hi all, about the modification of MSDP YANG > >> > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > Hi Xufeng and Reshad, > >> > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > I am sorry for forgetting the point. I updated the YANG > model. > >> > > > >> > > > > > > >> > > > >> > > > > > If no one has comments on it I'd like to submit the new > version. :-) > >> > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > Thanks, > >> > > > >> > > > > > > >> > > > >> > > > > > Sandy > >> > > > >> > > > > > 原始邮件 > >> > > > >> > > > > > 发件人： > >> > <Xufeng_Liu@jabil.com<mailto:Xufeng_Liu@jabil.com>>; > >> > > > >> > > > > > 收件人： > <rrahman@cisco.com<mailto: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 > >> > > >> > >> > >> > >> > >> > > _______________________________________________ > > yang-doctors mailing list > > yang-doctors@ietf.org > > https://www.ietf.org/mailman/listinfo/yang-doctors > >
- [yang-doctors] How to restrict to have single con… Reshad Rahman (rrahman)
- Re: [yang-doctors] How to restrict to have single… Martin Bjorklund
- Re: [yang-doctors] How to restrict to have single… Ladislav Lhotka
- Re: [yang-doctors] How to restrict to have single… Acee Lindem (acee)
- Re: [yang-doctors] How to restrict to have single… Ladislav Lhotka
- Re: [yang-doctors] How to restrict to have single… Martin Bjorklund
- Re: [yang-doctors] How to restrict to have single… Ladislav Lhotka
- Re: [yang-doctors] How to restrict to have single… Reshad Rahman (rrahman)
- Re: [yang-doctors] How to restrict to have single… Martin Bjorklund
- Re: [yang-doctors] How to restrict to have single… Xufeng Liu
- Re: [yang-doctors] How to restrict to have single… Reshad Rahman (rrahman)
- Re: [yang-doctors] How to restrict to have single… Acee Lindem (acee)
- Re: [yang-doctors] How to restrict to have single… Martin Bjorklund
- Re: [yang-doctors] How to restrict to have single… Christian Hopps
- Re: [yang-doctors] How to restrict to have single… Xufeng Liu
- Re: [yang-doctors] How to restrict to have single… Acee Lindem (acee)
- Re: [yang-doctors] How to restrict to have single… Acee Lindem (acee)
- Re: [yang-doctors] How to restrict to have single… Reshad Rahman (rrahman)
- Re: [yang-doctors] How to restrict to have single… Martin Bjorklund
- Re: [yang-doctors] How to restrict to have single… Reshad Rahman (rrahman)
- Re: [yang-doctors] How to restrict to have single… Xufeng Liu
- Re: [yang-doctors] How to restrict to have single… Ladislav Lhotka