Re: [netconf] mbj review of draft-ietf-netconf-notification-capabilities-01
Balázs Lengyel <balazs.lengyel@ericsson.com> Mon, 25 March 2019 23:41 UTC
Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7700F1201AA for <netconf@ietfa.amsl.com>; Mon, 25 Mar 2019 16:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.036
X-Spam-Level: ***
X-Spam-Status: No, score=3.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 E0I0u9duUOnE for <netconf@ietfa.amsl.com>; Mon, 25 Mar 2019 16:41:01 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70045.outbound.protection.outlook.com [40.107.7.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B048120194 for <netconf@ietf.org>; Mon, 25 Mar 2019 16:40:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qmAAW76dtsKeQT/Wys7l2hINOlL48Qv56eKAOb9foMg=; b=Un1F/24N0mTRvcx8Y6OffR2acklIX9FX529Y6MGAkgEJu5zT9X8KmyQYmqAROvHboVJo4rr/AsQwRKThS2vX9vJdBTU+/vZtlYWLALqtPtU7MPbYz/2zl765STgd/H9K0kUZZIKd+53nAoCPANN+8o7vzHlHroJpu+RqXeV3X3c=
Received: from DB7PR07MB3850.eurprd07.prod.outlook.com (52.134.99.143) by DB7PR07MB5260.eurprd07.prod.outlook.com (20.178.43.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.14; Mon, 25 Mar 2019 23:40:56 +0000
Received: from DB7PR07MB3850.eurprd07.prod.outlook.com ([fe80::6c96:5ffd:d461:9f5e]) by DB7PR07MB3850.eurprd07.prod.outlook.com ([fe80::6c96:5ffd:d461:9f5e%3]) with mapi id 15.20.1750.014; Mon, 25 Mar 2019 23:40:56 +0000
From: Balázs Lengyel <balazs.lengyel@ericsson.com>
To: Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] mbj review of draft-ietf-netconf-notification-capabilities-01
Thread-Index: AQHU42Qxrrq0rsMFj06W2FbjkiSDuQ==
Date: Mon, 25 Mar 2019 23:40:56 +0000
Message-ID: <e333e4e3-2c40-2f19-5035-d6d24a0adcab@ericsson.com>
References: <20190325.215637.1342845104682793774.mbj@tail-f.com>
In-Reply-To: <20190325.215637.1342845104682793774.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.176.1.93]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
x-clientproxiedby: HE1PR0902CA0017.eurprd09.prod.outlook.com (2603:10a6:3:e5::27) To DB7PR07MB3850.eurprd07.prod.outlook.com (2603:10a6:5:7::15)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f501b662-7e54-4d6b-fc3b-08d6b17b535a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB5260;
x-ms-traffictypediagnostic: DB7PR07MB5260:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com;
x-microsoft-antispam-prvs: <DB7PR07MB52608BB192AD0DB332F1DB83F05E0@DB7PR07MB5260.eurprd07.prod.outlook.com>
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(39860400002)(396003)(366004)(199004)(189003)(51914003)(99286004)(31696002)(2501003)(64126003)(486006)(85202003)(8936002)(446003)(102836004)(54896002)(65826007)(6486002)(36756003)(86362001)(476003)(8676002)(110136005)(71190400001)(81156014)(81166006)(2616005)(11346002)(14444005)(58126008)(5660300002)(85182001)(316002)(71200400001)(7736002)(6116002)(14454004)(65956001)(65806001)(66066001)(26005)(52116002)(606006)(6246003)(105586002)(478600001)(25786009)(2906002)(256004)(386003)(3846002)(76176011)(229853002)(31686004)(6506007)(6436002)(186003)(15650500001)(68736007)(53936002)(99936001)(966005)(106356001)(236005)(97736004)(6512007)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5260; H:DB7PR07MB3850.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: W3Bqul3PR5nsvEp/7ErryZ7zthfLKFmfQrQvK9CrfWd9BjWzV6Ea5qcDdj3z6FDjNGK1IqMqXGAKnZs/eF68hQ4D70Ql0bDC1koTW2PtkKuvYDnhGHoIdjOORHMViCBkY/7esZh/dP4rry4kUON9IgiHaFN42l9NcnLY+qmxSqkdDlfwhRQ3C8f+f20uXuagD3bTF41AwjZXf33kpDERNhAWk2+0lTT89nSbvmSYOrmGLKVTqNXKMLPNCGzY8pP5ON+M/YIPfQALodSuMXOFvG4gjlNcH7RQszpzpE6iAk7U2jLgQZVFW6u148Ok/daGuSL2k34XUzPsSVz6I0d9vd2qDLpagWz0tX8vG9oHq7Qzvm/Dl5D825fiZG5keA3nYPLjkgvkY5q1DO5yW3IFr683pNY1Z0F1LJ/+R1L0lag=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030106050200090904070900"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f501b662-7e54-4d6b-fc3b-08d6b17b535a
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 23:40:56.5195 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5260
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/yrBNkq7obie4geLw0eoVxzkoeog>
Subject: Re: [netconf] mbj review of draft-ietf-netconf-notification-capabilities-01
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2019 23:41:17 -0000
Thanks for the comments, See below. Balazs
BALAZS: OKHi, Here are my (mostly minor) comments on draft-ietf-netconf-notification-capabilities-01 o Terminology 1. The term that is used in th YP draft is "YANG-Push". Please import that and use it consistently. (I see at least "YangPush" and "Yang-Push").
BALAZS: OK2. This document uses the terms "YANG server" and "Yang server". I suggest you change this to "server", and import that from RFC 8342.
BALAZS: OKo Abstract The abstract mentions YANG Instance Data, but it doesn't mention run-time. I think it should.
BALAZS: OKo Section 1 s/Rutime/Runtime/
BALAZS: OKo Section 1 s/protocol/management protocol/ Should you really list HTTPS here? + add references to NETCONF and RESTCONF.
BALAZS: The defaults will also be per datastore. For datastores that do support them, they have no meaning. E.g. state data in intended. They could be removed formally with when statements in the YANG, but IMHO its enough to state it in text:o Section 3 Editorial: remove the text within the parentheses. o General We need to be able to specify on-change support per datastore. With support per datastore, it is not quite clear if notification-sent-for-config-default and notification-sent-for-state-default are needed, and/or how they should be interpreted.
- default for state is anyway false
- For new datastores we would not know how to set up the when condition
BALAZS: OK, but some other capacity related proerties are still valid.o General In YP, support for on-change is optional. There is a feature called "on-change". I think this document should state explicitly that this module is intended for servers that implement that feature.
BALAZS: OKo Section 3.2 Editorial: We no longer list the WG Chairs in the description. Since you use 2119 language in the model, please include the boilerplate in the module description. The module description doesn't contain the proper copyright text, The module should be formatted similar to the rest of the IETF-published modules. I suggest you run pyang -f yang --keep-comments --yang-line-length 69 <FILE> and then ensure that any additions are consistent with that.
BALAZS: OKo Section 3.2 The top-level container is currently called "yangpush-notification-capabilities". This doesn't really match the naming in the YP document. I suggest it is called "datastore-subscription-capabilities", so that we use a word that can be related to the the nodes YP defines, such as in "establish-subscription" ... "datastore" "datastore-subtree-filter"
BALAZS: OK, probably change all to centiseconds. Is there a general rule not to use the official abbreviations?o Section 3.2 You have: units msec; units centiseconds; I think you probably should do s/msec/milliseconds/
BALAZS: If not present it means that the system does not tell you what it is. No special meaning. I do not see a reasonable minimum value (eventhough 0 would look strange). IMHO it is the responsibility of the server to provide a meaningful value. If it says zero, that's obviously crazy, just ignore it. I don't thing we need to have rules, like: do not provide stupid state data.o Section 3.2 minimum-dampening-period is optional. It should be stated what it means if this leaf is not present. (or should the default be 0?)
BALAZS: If not present it means that the system does not tell you what it is. No special meaning.o Section 3.2 The choice update-period is not mandatory, and doesn't have a default. What does it mean if this is not reported?
BALAZS: If not present it means that the system does not tell you what it is. No special meaning. I do not see a reasonable minimum value (eventhough 0 would look strange). IMHO it is the responsibility of the server to provide a meaningful value. If it says zero, that's obviously crazy, just ignore it.o Section 3.2 The leaf max-objects-per-update is not mandatory. What does it mean if this is not reported? It can have the value 0. What does that mean?
BALAZS: IMHO infinite is unreasonable. If the server doesn't know the real limit, it should just not provide a value.Perhaps make a union of uint32 0..max and the enum "infinite" and make that the default? (of course "infinite" is not really correct...)
BALAZS: Will be provided.o General I missed some examples, perhaps in an Appendix.
_______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf" rel="nofollow">https://www.ietf.org/mailman/listinfo/netconf
-- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com
- [netconf] mbj review of draft-ietf-netconf-notifi… Martin Bjorklund
- Re: [netconf] mbj review of draft-ietf-netconf-no… Balázs Lengyel
- Re: [netconf] mbj review of draft-ietf-netconf-no… Martin Bjorklund
- Re: [netconf] mbj review of draft-ietf-netconf-no… Eric Voit (evoit)
- Re: [netconf] mbj review of draft-ietf-netconf-no… Martin Bjorklund