Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 29 August 2019 09:29 UTC
Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E93E120103 for <netmod@ietfa.amsl.com>; Thu, 29 Aug 2019 02:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Cip4GsVZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=czolgNpQ
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 XkxDmn2A8jZL for <netmod@ietfa.amsl.com>; Thu, 29 Aug 2019 02:29:47 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BA31200A4 for <netmod@ietf.org>; Thu, 29 Aug 2019 02:29:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8189; q=dns/txt; s=iport; t=1567070987; x=1568280587; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kSYp7jEQSwfrv+dQgLfmr7JHdyC0+24NNhTo+2Eu0+g=; b=Cip4GsVZZkoFkiXHliYo79YXzTuqmtJEkcQXkclGdGueEg5NTDpGxyoY zjarlrH84ziYH5+XiPYZDxkRbIxKwMVLLpW7poyUJYR/rMSJXJMP4XmX4 qO4S7SYipKMAhOlqjxUKLHnk9FdE4clD8x+hF33Jn222X24ByesVyCTZZ o=;
IronPort-PHdr: 9a23:S65EWx8QBz2/9v9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUERoMiMEYhQslVdSaCEnnK/jCZC0hF8MEX1hgrDm2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAgB8mmdd/5NdJa1cCRsBAQEBAwEBAQcDAQEBgWeBRSQsA21WIAQLKgqHXgOKcE2CD36WbIFCgRADVAkBAQEMAQEYCwoCAQGDekUCglgjOBMCAwgBAQQBAQECAQYEbYUuDIVKAQEBAQIBAQEQKAYBASwEAgYEBwQCAQgOAwEDAQEfECcLFwYIAgQBEggTB4MBgWoDDg8BAgyeewKBOIhhgiWCfAEBBYUOGIIWAwaBNIt3GIFAP4ERRoIXNT6CYQEBgSYREhqDO4ImlGKIao1QbQkCgh6Gbo1+gjKWK41tgTaGOZBIAgQCBAUCDgEBBYFnIYFYcBUaIYJsgkIJAxeDT4UUhT9ygSmNEQGBIgEB
X-IronPort-AV: E=Sophos;i="5.64,442,1559520000"; d="scan'208";a="320883195"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Aug 2019 09:29:46 +0000
Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x7T9Tkjx007094 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Aug 2019 09:29:46 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 04:29:45 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 05:29:45 -0400
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 29 Aug 2019 05:29:45 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TipjkQ1ZGPqyWhmqXOFEYFvdGr/rY2edTAszAOENs5lYTMLHsx5fH3E59YbP/tFcsaphtAXgyO+6qY++aHxt/BzWNeOaH4GKtNSHSxWc1N8mTQPFPZvpE9lsUMohh5bGJgwajp/0u0ONEOFi4FXImHHAQNOa4Ww3rHwGm2iHvzxPnsMm33wZrvLNaXirKH9S5w/7tAbhX9VGc6MKlC/olebHMzEdSquGBf1EEYWvhQBPUxfUaiNyDrc/aB1tnfaokfE2H6yRzgBgknIWqnmNKsIuAGzOI3N0SGYuha0IpRG4O2xsqmEJKqk2tsaf1t/1dkPdHNKnIAvoixRmHNQdIg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WhrxnGyJWqE5XKfaYyN0gK63180fUrEdFvVjObJFLlw=; b=T8t2RU4qmTBIIm1mmFz0v4nUR/SpiOYHc0ZTIXFHfnpC1Uto7dg7Hz5MWfw3Hi19Mpt7GvmvspVvjTtvB6WZxo1Bjnn8AOgUUO+md9URkzy6WomYWiBtWg9CFs/o1l7gQgvV6wf14AxhQxqNKTz8Dr2EL8dZSESEUdVtX6NKmP0MjKxR1etjggX9rH5/FNusIX8pikbO/UxwBAVue0LRe15pf+xFkwlyehM4bbw0Dw1zdDnyyQ0wGUKbefkrLqD2ZNGwfzSVP8pX25J9V8fjt92BFB6gkplqENt3ydexzsfyYxGHTxljsyoQxMVa1qK85Hg/GKya3azoOPkBb8M+AA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WhrxnGyJWqE5XKfaYyN0gK63180fUrEdFvVjObJFLlw=; b=czolgNpQ0lF1zTLV+pn+b/Cdscj7lJj2e7b1w74MtLoJ6uQhkAv3KqVuVNEB+h4mq9oNI5qAkfyPjSE7zCTI12N0WRmL8y0hokguS+mEplmOP7JSTrpj0nm/9DQGAaod2blMVdQhGhQsy4mIkEYnpeuZrpu0xsF9/6OTepfFuPQ=
Received: from BY5PR11MB4355.namprd11.prod.outlook.com (52.132.254.141) by BY5PR11MB3991.namprd11.prod.outlook.com (10.255.160.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.18; Thu, 29 Aug 2019 09:29:43 +0000
Received: from BY5PR11MB4355.namprd11.prod.outlook.com ([fe80::4590:1fad:4b16:7abd]) by BY5PR11MB4355.namprd11.prod.outlook.com ([fe80::4590:1fad:4b16:7abd%3]) with mapi id 15.20.2199.021; Thu, 29 Aug 2019 09:29:43 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
Thread-Index: AQHVNrSsI3r62XsUgUy/9VeuuC2cP6cF4/wAgAFWQZA=
Date: Thu, 29 Aug 2019 09:29:43 +0000
Message-ID: <BY5PR11MB4355684E068D399D3BF2B4ADB5A20@BY5PR11MB4355.namprd11.prod.outlook.com>
References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> <20190821.155950.1596034237173159188.mbj@tail-f.com>
In-Reply-To: <20190821.155950.1596034237173159188.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [173.38.220.59]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 50accbb3-c8c0-48be-242c-08d72c636cfa
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BY5PR11MB3991;
x-ms-traffictypediagnostic: BY5PR11MB3991:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BY5PR11MB3991FDD8E64CC184E14D1148B5A20@BY5PR11MB3991.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0144B30E41
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(396003)(39860400002)(136003)(366004)(199004)(189003)(51444003)(13464003)(51914003)(11346002)(486006)(476003)(446003)(14444005)(71190400001)(71200400001)(256004)(478600001)(6116002)(3846002)(26005)(102836004)(6506007)(53546011)(186003)(7696005)(76176011)(74316002)(305945005)(7736002)(8936002)(8676002)(81166006)(81156014)(14454004)(99286004)(966005)(2501003)(110136005)(316002)(229853002)(86362001)(76116006)(33656002)(66946007)(66476007)(66446008)(64756008)(66556008)(53936002)(9686003)(55016002)(6306002)(25786009)(6246003)(5660300002)(52536014)(66574012)(66066001)(2906002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR11MB3991; H:BY5PR11MB4355.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: JOyAqn2Xhf7uPUR+mpY3bnVhEOHN6hijzg9TC6yb/Iwq4DVIvr/emolEUKnEhJCwhUQIuToNVe4wLlNt3RLhbM83sHNAQLLknXsEzC5Kz77LNo1vg2ZkRHZYLT+myh/1fLDaWFjgqJ57Ks3A/pH9ng1s3C51ryQeI6mBBFG4l4nw543NoE4U0i62UxK8AgSYwRq3479kLDTGNWznlNz6q9ZYvYM7EdDfe2D5vRaCD/CBH/8bsfaRgqNq9L/L1UssVTwntIgA7lPjcoQbov0fdmuYR3sJBWVy40xQl234LjDuA8S2MNasTSbrR4/8cCAvFcKWfGEEAMtP+eBo0LT3J0zO0UBpzK5ydSRv9fuD0rzz5BEX6xHYUOi0xqhqf3ILvEEdKpH1iQyMR4vjBoCYlIBt0D+LreilniZtrdiZxWo=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 50accbb3-c8c0-48be-242c-08d72c636cfa
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 09:29:43.5932 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: a5G2O0k/0MrbmJnkEXvsZztO2cpGlzOdnLKnlsJRA2Nv5591CbZaHRJeZIusf9F9GjquVKVW8ra0TA7px6oXkQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3991
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/o7LVTVggTAy8aI2t39r_TwYi1-Q>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2019 09:29:50 -0000
Hi Martin, Thanks for the review. Mostly just updated, a couple of comments/questions inline below. Latest source XML and txt are at: https://github.com/netmod-wg/interface-extensions-yang/tree/wglc > -----Original Message----- > From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Bjorklund > Sent: 21 August 2019 15:00 > To: netmod@ietf.org > Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 > > Hi, > > Here is my (late) review of draft-ietf-netmod-intf-ext-yang-07. It is a > well-written document and my comments are mostly minor. > > > o Abstract > > OLD: > > The YANG data model in this document conforms to the Network > Management Datastore Architecture (NMDA) defined in RFC 8342. > > NEW: > > The YANG modules in this document conform to the Network > Management Datastore Architecture (NMDA) defined in RFC 8342. > OK. > > o Section 1 > > One of the aims of this draft is to provide a standard namespace and > path for these configuration items regardless of the underlying > interface type. For example a standard namespace and path for > > "standard namespace and path" sounds a bit clumsy. In section 2 you > use "standard definition", perhaps that can be use here. > OK. > > o General > > s/this internet draft/this document/g > s/this draft/this document/g > OK. > > o Section 2 > > It seems this short section mostly says what is already said in > section 1. Remove? > At this stage yes, I think that this can be removed. > > o 3 > > The text says: > > o A parent interface leaf useable for all types of sub-interface > that are children of parent interfaces. > > I suggest you add before that bullet: > > o A generic "sub-interface" identity that an interface identity > defintion can derive from if it defines a sub-interface. > OK. > > o 3.1 > > The text says: > > E.g. in the > case that the link state transition is suppressed then there is no > change of the /if:interfaces-state/if:interface/oper-status or > /if:interfaces-state/if:interfaces/last-change leaves for the > interface that the feature is operating on. > > This should be: > > no change of the /if:interfaces/if:interface/oper-status or > /if:interfaces/if:interfaces/last-change leaves for the > interface that the feature is operating on. > OK. > > o 3.2 > > It took me some time to understand the dampening algorithm. Why is > it important to talk about nominal values and that a device doesn't > have to use 1000 as the penalty, as long as they scale the given > values? Wouldn't it be easier to describe the algorithm w/o any > nominal values, and then explain that an implementation is free to > implement this algorithm in any way it wants (which of course is > true for everything we do...) That makes sense. I have tweaked the description. > > Otherwise, the text currently says: > > Implementations are not required to use a penalty of 1000 units in > their dampening algorithm, but should ensure that the Suppress > Threshold and Reuse Threshold values are scaled relative to the > nominal 1000 unit penalty to ensure that the same configuration > values provide consistent behaviour. > > Should "should" in this text be "SHOULD"? Or perhaps "MUST"? > I've just removed this text. As you say above, this is just a definition of an API, and vendors are free to implement however they wish as long as they are consistent with the API. > > o 3.2.1 > > The text says: > > When the accumulated penalty reaches the default or > configured suppress threshold, the interface is placed in a dampened > state. > > The term "dampended state" occurs twice, in 3.2.1 and 3.2.3. It is > not used in the YANG model. I suspect the leaf "suppressed" > reflects this. Perhaps align naming. > I've changed this to suppressed. > > o 4 > > It would be useful with a sentence that describes the relationship > to /if:interfaces/if:interface/if:phys-address. > > It seems that the mac-address leaf is useful when the mac address > can be configured; otherwise if:phys-address should be sufficient, > right? Yes, if not configured, it returns the same value as if:phys-address (but constrained to being exactly 6 bytes long). Perhaps a better long term solution here would be to allow if:phys-address to be configurable, and add a hw-phys-address config false leaf to indicate the default hardware value? Should the mac-address leaf have a feature, or can we expect > all implementations to support configurable mac addresses? No, I don't think that all Ethernet interfaces will necessarily support configurable MAC addresses, e.g. I suspect that a lightbulb or simple home router probably does not allow it to be configured. But I would expect Linux and more sophisticated network devices to allow MAC addresses to be configured. Hence making this conditional on a feature makes sense. leaf mac-address { type yang:mac-address; description "The MAC address of the interface."; } In terms of the relationship to phy-address, I would suggest the following update: leaf mac-address { if-feature "configurable-mac-address"; type yang:mac-address; description "The MAC address of the interface. The operational value matches the if:phys-address leaf defined in ietf-interface.yang"; } > > > o 4 > > You add a container 'statistics' under 'ethernet-like', so we have: > > +--rw interfaces > +--rw interface* [name] > ... > +--ro statistics > ... > +--rw ethlike:ethernet-like > +--ro ethlike:statistics > ... > > Did you consider augmenting the container if:statistics instead? I > think it can be useful to have all statistics in the same container > in this case. I think that given that we are only adding one counters and they are probably widely useful for Ethernet interfaces then I think that augmenting the existing statistics container makes sense. I will change this. If we end up defining Ethernet histogram counters (which we are not doing now, and would be a separate draft), then we might want to think carefully whether or not to put those counters under the main interface statistics container, because I suspect that most of the time clients probably won't be interested in those values. > > > o 7.2 > > Perhaps show the (related) 'if:oper-status' leaf as well. > Yes. > > o 7.3 > > Perhaps show the (related) if:phys-address' leaf as well in the > first and third examples. OK. > > Before the second example, perhaps change: > > The following example shows an explicit MAC address being configured > on interface eth0. > > to: > > The following example shows the intended configuration for > interface eth0 with an explicit MAC address being configured. > Fixed. > > o YANG nits > > Both YANG modules list the WG chairs; we don't do that anymore. Fixed. > > Both YANG modules have the IETF Trust Copyright statement, but not > exactly as it should be (try: pyang --ietf and/or pyang --ietf-help) > > Many descriptions are full sentences w/o the ending ".". > Fixed, I think. > The reference in the revision statement should be changed to "RFC > XXXX: <title>" > Fixed. Thanks, Rob > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
- [netmod] WG Last Call: draft-ietf-netmod-intf-ext… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Acee Lindem (acee)
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Rob Wilton (rwilton)
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Acee Lindem (acee)
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Rob Wilton (rwilton)
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Vladimir Vassilev
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Rob Wilton (rwilton)
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Vladimir Vassilev
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Balázs Lengyel
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Vladimir Vassilev
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Qin Wu
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Martin Bjorklund
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Rob Wilton (rwilton)
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Martin Bjorklund
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Martin Bjorklund
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Rob Wilton (rwilton)
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Martin Bjorklund
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Vladimir Vassilev
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Rob Wilton (rwilton)
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Rob Wilton (rwilton)
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Rob Wilton (rwilton)
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Rob Wilton (rwilton)
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Qin Wu
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Qin Wu
- Re: [netmod] WG Last Call: draft-ietf-netmod-intf… Rob Wilton (rwilton)