Re: [Netconf] Last Call on yang-push-17
Alexander Clemm <alexander.clemm@huawei.com> Tue, 28 August 2018 17:47 UTC
Return-Path: <alexander.clemm@huawei.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 B1563128CB7 for <netconf@ietfa.amsl.com>; Tue, 28 Aug 2018 10:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 1Ib7qrlClNON for <netconf@ietfa.amsl.com>; Tue, 28 Aug 2018 10:46:58 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C789126BED for <netconf@ietf.org>; Tue, 28 Aug 2018 10:46:58 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CE06BAA348099 for <netconf@ietf.org>; Tue, 28 Aug 2018 18:46:51 +0100 (IST)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 28 Aug 2018 18:46:53 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.188]) by SJCEML702-CHM.china.huawei.com ([169.254.4.168]) with mapi id 14.03.0415.000; Tue, 28 Aug 2018 10:46:45 -0700
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Qin Wu <bill.wu@huawei.com>, Kent Watsen <kwatsen@juniper.net>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] Last Call on yang-push-17
Thread-Index: AQHUM/QwQhG4fwKiUkSHvZFCs3Awe6TUk3QA///7D4CAAPeoQA==
Date: Tue, 28 Aug 2018 17:46:44 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5A145@sjceml521-mbs.china.huawei.com>
References: <BC944567-EC5F-42DA-983E-95493635B461@juniper.net> <645E45E1-EE1F-4E06-9B38-DE457003AC4C@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AFDB3A0@nkgeml513-mbx.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9AFDB3A0@nkgeml513-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.35.68]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/T7WlG7d3nx3OVJ7OsDelDH8khc0>
Subject: Re: [Netconf] Last Call on yang-push-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing 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: Tue, 28 Aug 2018 17:47:01 -0000
Hi Qin, thank you for your comments! Replies inline, <ALEX> --- Alex > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Qin Wu > Sent: Monday, August 27, 2018 8:24 PM > To: Kent Watsen <kwatsen@juniper.net>; netconf@ietf.org > Subject: Re: [Netconf] Last Call on yang-push-17 > > A few comments on yang-push-17: > I have difficult to understand section 3.2 of yang-push-17: > Section 3.2 of yang-push-17 said: > " > To accomplish this, implementations > SHOULD support the conceptual authorization model of [RFC8342], > specifically section 3.2.4. > > +-----------------+ +--------------------+ > push-update or --> | datastore node | yes | add datastore node | > push-change-update | access allowed? | ---> | to update message | > +-----------------+ +--------------------+ > > Figure 5: Updated [rfc6536bis] access control for push updates > > " > Do we have authorization model in NMDA specification [RFC8342], should we > reference to RFC8341? > Section 3.2.4 of RFC8341 is about get and get-config operation which seems > not relevant to this section. > Push-update or push-change-update are notification, so we should > reference notification access control? > What is the update to RFC6536bis or RFC8341? > If there is update to RFC8341, I think it should be reflected in the front page, > right? > <ALEX> We should reference 8341, not 8342, as also Martin has pointed out. It is true that this is about get and get-config operation, but the relevance is explained here: " Each "push-update" and "push-change-update" MUST have access control applied. This includes validating that read access is permitted for any new objects". In other words, for a push update the same checks apply as for a get - the only difference really is that the get is on-demand whereas the push is subscribed. </ALEX> > Also I think remote mirroring appears only once in the abstract, it will be > great to add definition of remote mirroring, it is hard to understand at the > first place. <ALEX> Hmm. It is true that mirroring is only mentioned once, in the abstract. However, I am not sure this needs to explained further - the sentence clearly explains what this is about: "remote mirroring of configuration and operational state". We could add "... in a datastore to a client application" at the end, however, I am not sure this makes it really better (only longer)? </ALEX> > > Section 3.11.1 said: > " > Or in case the loss of an update is > unavoidable, it is critical that the receiver is notified > accordingly. > " > I am wondering how does the publisher knows the loss of an update? > Do we have mechanism specified for this? <ALEX> Yes, and we have provided some updates to this section also per earlier comments by Tim to explain those mechanisms briefly. It is also explained in the bulleted list below. </ALEX> > > -Qin > On 2018-08-14, 1:28 PM, "Netconf on behalf of Kent Watsen" <netconf- > bounces@ietf.org on behalf of kwatsen@juniper.net> wrote: > > This message starts a Last Call on draft-ietf-netconf-yang-push-17: > > https://tools.ietf.org/html/draft-ietf-netconf-yang-push-17 > > > This marks the beginning of the last calls on the yang push suite of drafts. > Given the size and number of documents, the chairs decided to break the > reviews up into pieces so as to get focus on each in turn. We are choosing > to go top-down, starting with yang-push and ending with the "notif" drafts. > We plan to submit the drafts for publication when they are ready as a > collective. The goal is to do all this prior to IETF 103. > > We understand that, in reviewing yang-push, there is a need to consider > the > subscribed-notifications draft. We will not be surprised if, in the course > of things, both drafts are updated, even though the review is primarily on > the yang-push draft. > > While it's always nice to receive messages of support, at this time, the > question isn't so much if the working group supports the work, than if > the document is ready to progress. The chairs need to see reviews that > indicate thorough end-to-end reading of the text. Of course, if there > are any objections, these should be brought forward now as well. > > The current version (-17) of this draft was published on July 1st, just > before the IETF 102 meeting. The datatracker page for the draft is here: > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push. > > > Thanks, > Kent (and Mahesh) > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf
- [Netconf] Last Call on yang-push-17 Kent Watsen
- Re: [Netconf] Last Call on yang-push-17 Banghart, Stephen A. (Fed)
- Re: [Netconf] Last Call on yang-push-17 Reshad Rahman (rrahman)
- Re: [Netconf] Last Call on yang-push-17 Mahesh Jethanandani
- Re: [Netconf] Last Call on yang-push-17 Alexander Clemm
- Re: [Netconf] Last Call on yang-push-17 Qin Wu
- Re: [Netconf] Last Call on yang-push-17 Henk Birkholz
- Re: [Netconf] Last Call on yang-push-17 Alexander Clemm
- Re: [Netconf] Last Call on yang-push-17 Alexander Clemm
- Re: [Netconf] Last Call on yang-push-17 Alexander Clemm
- Re: [Netconf] Last Call on yang-push-17 Alexander Clemm
- Re: [Netconf] Last Call on yang-push-17 Reshad Rahman (rrahman)
- Re: [Netconf] Last Call on yang-push-17 Kent Watsen
- Re: [Netconf] Last Call on yang-push-17 Alexander Clemm