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: =?us-ascii?q?9a23=3AS65EWx8QBz2/9v9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdSaCEnnK/jCZC0hF8MEX1hgrDm2?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAgB8mmdd/5NdJa1cCRsBAQEBAwE?= =?us-ascii?q?BAQcDAQEBgWeBRSQsA21WIAQLKgqHXgOKcE2CD36WbIFCgRADVAkBAQEMAQE?= =?us-ascii?q?YCwoCAQGDekUCglgjOBMCAwgBAQQBAQECAQYEbYUuDIVKAQEBAQIBAQEQKAY?= =?us-ascii?q?BASwEAgYEBwQCAQgOAwEDAQEfECcLFwYIAgQBEggTB4MBgWoDDg8BAgyeewK?= =?us-ascii?q?BOIhhgiWCfAEBBYUOGIIWAwaBNIt3GIFAP4ERRoIXNT6CYQEBgSYREhqDO4I?= =?us-ascii?q?mlGKIao1QbQkCgh6Gbo1+gjKWK41tgTaGOZBIAgQCBAUCDgEBBYFnIYFYcBU?= =?us-ascii?q?aIYJsgkIJAxeDT4UUhT9ygSmNEQGBIgEB?=
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