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