Re: [netconf] RtgDir review: draft-ietf-netconf-yang-push-22

"Alexander Clemm" <ludwig@clemm.org> Wed, 15 May 2019 02:54 UTC

Return-Path: <ludwig@clemm.org>
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 A1189120127; Tue, 14 May 2019 19:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 4MuLi6bg37uJ; Tue, 14 May 2019 19:54:03 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28CB1201D0; Tue, 14 May 2019 19:54:02 -0700 (PDT)
Received: from LAPTOPR7T053C2 ([71.178.248.224]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1M6DvY-1hK7Hq1pUG-006dFd; Wed, 15 May 2019 04:53:58 +0200
From: "Alexander Clemm" <ludwig@clemm.org>
To: "'Daniele Ceccarelli'" <daniele.ceccarelli@ericsson.com>, <rtg-ads@ietf.org>
Cc: <rtg-dir@ietf.org>, <draft-ietf-netconf-yang-push.all@ietf.org>, <netconf@ietf.org>
References: <AM0PR07MB609874A375A159709AC41C3FF03A0@AM0PR07MB6098.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB609874A375A159709AC41C3FF03A0@AM0PR07MB6098.eurprd07.prod.outlook.com>
Date: Tue, 14 May 2019 19:53:52 -0700
Message-ID: <043d01d50ac9$710eb070$532c1150$@clemm.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_043E_01D50A8E.C4B27080"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIX4Hao3662Ojb5sUX1GhdIgG7VPqXlc/bA
Content-Language: en-us
X-Provags-ID: V03:K1:RHK5NVZ8+kA2vDXXzHhtRAoUUfKtHGu1xX+Sxbc0I68VMqkLBpD 0u9VFOD7deGgccsnwBH2BWyqlDRVnO6SiKxyOqy0PO6BdvKr6bNqzVfrChOicFjgEi0nwxg MUTAfcZ2negrOEHzEGATpdq58DIjCi9KwyBOIvAw7xevTwUFWjYq7wwsVoS72F8lx4OUeip SyHUsyOQYVOBtK5PW/3LA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Dz8gmBzMHj8=:fYALs2uD1Otzh/Gkkdppf8 0zApgCOi7M1qJm6GtgIhULanfSisk2am+4b5aP5NHzP2G5JTdV4A5pIxgdGsvUz3c0loIm4pC EBjKbK8Zg7gluID7retTuPUjEC2tWF1G4ctpIJTRStQ/XuzX1VFQqOXrp27P7Hw6lpk0FhQM6 1NJI1a6tnzRLRAkeGHWGPsUAh2BdEa6z/3Oy5UbnqFURNdVUX4PJC4YMEWcexTBtdmddhFNDh 2wyqF8aikkG6VKl7lOX0zfbHySVGNGhTSpm5eU61rCASSEjqc6JMsUDyaja9AjmJra09jWVYF gOpDzlwJs1qZGXcns/Z/d4/yuN446HHQvn7FWXu91JflFxh5h9+zY+VRpxZovtz8+YjLlI9ub zsf7sUv3yz/H0UDLzbzPx8hEwcPdI/RcJW4Y1E3yzVkzU4qddl5N/guVGW/vNSvm6J08dM+pO ks6p7ZF6RqvSasTsE756i8kv7XiZlwAUKDbBU4aJSxPgSvZFEycJJods9tJSQwQGeQhjX7+zN P1PUV8eEkOgiZ1RNwCfRelUHaCbhfFL9YFH0uO5pqY5hWihKPgcim1eYYgUz+B48iWTRQ6xPR ULIbZMLMukMTlWEWjXlQLR1CmHQ5Tp6I+va8bMBBbDMo+nlShj9c30ACfh8PvgPXoTPdSAMCG 7lMPTwrZP6GQaBmGPTFUvVy+OYiCjQt76EGksCW9l7ebhE7dH/V2xB5X4Fvn3XAY3oEAuTVVb RxMWc3yVyfwRYJXG9E+Vm0WVQI1Z/oNqG3ui2zBbPcymogPCL2mPvgXJcro=
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/VDj6EqCr24m9uOjubtCYdXqM7AQ>
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-yang-push-22
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: Wed, 15 May 2019 02:54:06 -0000

Hello Daniele,

 

Thank you for your review!  Responses inline, <ALEX>.  Updates will be reflected in -24, to be published shortly.  

 

Kind regards

--- Alex

 

From: netconf <netconf-bounces@ietf.org>; On Behalf Of Daniele Ceccarelli
Sent: Tuesday, April 30, 2019 12:24 PM
To: <rtg-ads@ietf.org>; (rtg-ads@ietf.org) <rtg-ads@ietf.org>;
Cc: rtg-dir@ietf.org; draft-ietf-netconf-yang-push.all@ietf.org; netconf@ietf.org
Subject: [netconf] RtgDir review: draft-ietf-netconf-yang-push-22

 

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see  <http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-netconf-yang-push-22
Reviewer: Daniele ceccarelli 
Review Date: 2019-04-30
IETF LC End Date: 
Intended Status: Standards Track

Summary: 

*	This document is basically ready for publication, but has nits that should be considered prior to publication.

Comments:

*	The draft is well structured and covers a lot of different aspects of the proposed method. I only have some concerns on readability and quality of English. A review from a mother tongue would improve it significantly. (maybe the RFC editor should be enough).

Major Issues:

*	No major issues found

Minor Issues:

*	Number of authors on the front page: shouldn’t it be 5 max?

<ALEX> Several of the authors have graciously agreed to step down and be listed as contributors. </ALEX>

*	Section 3: “This solution supports dynamic as well as configured subscriptions to updates of datastore node”. What does dynamic and configured mean? It’s probably defined in other documents? 

<ALEX> Yes, these are defined in the Subscribed Notifications draft which YANG-Push builds on, as explained in the Introduction.  </ALEX>

*	Section 3.2. “However, there are no guarantees that subsequent requests which consider these hints will be accepted.” What happens then? Undefined number of retries?

<ALEX> It is up to the client application.  When making a subsequent request, it should presumably “lower” its demands.  The idea of the hint is to provide an idea which request would result in a load that is still acceptable, a “poor man’s negotiation” if you will that will reduce the number of retries that might otherwise result.  </ALEX>

*	3.5.1.  Periodic Subscriptions:”In a periodic subscription, the data included as part of an update record corresponds to data that could have been read using a retrieval operation.”. Is it not possible to have periodic subscriptions with just the delta between the previous update and the last one? Everything needs to be sent at any time? 

<ALEX> In that case, you would request an on-change subscription.  In case of a high rate of changes, the dampening period will in effect result in periodic updates of changes only. </ALEX>  

Nits:

*	Abstract: suggest to change “continuous, customized” with “continuous and customized”.

<ALEX> see next bullet item </ALEX>

*	Maybe it’s better to change the first sentence entirely. How about: “  This document describes a mechanism that allows subscriber applications requesting a continuous and customized stream of updates from a YANG datastore.”

<ALEX> This sounds fine to me. Perhaps we have edited the sentence too much in the past.  I am making the change, but replacing “requesting” with “to request”, to read “This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore.” </ALEX>

*	“Traditional approaches to providing”, shouldn’t this be “to provide” or “of providing”?

<ALEX> OK, change made </ALEX>

*	Polling incurs significant latency. This latency prohibits many application types. – Also this sentence doesn’t look very correct. Actually the entire section can be improved from a language perspective. (e.g. “yet for which applications need to be quickly notified whenever a change does occur with minimal delay.”)

<ALEX> Prefer to keep as-is at this point.  Would leave copy edits to RFC-editor.  </ALEX>

*	[I-D.draft-ietf-netconf-subscribed-notifications] usually a more friendly reference is used, e.g. [SUB-NOT]

<ALEX> Keeping this as-is, as this will be replaced by the corresponding RFC reference anyhow.  </ALEX>

BR

Daniele