Re: [Netconf] Last Call on yang-push-17
Alexander Clemm <alexander.clemm@huawei.com> Tue, 28 August 2018 18:45 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 2DC17127148 for <netconf@ietfa.amsl.com>; Tue, 28 Aug 2018 11:45:03 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 NyvrTM0SxKOq for <netconf@ietfa.amsl.com>; Tue, 28 Aug 2018 11:45:00 -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 E6516129C6A for <netconf@ietf.org>; Tue, 28 Aug 2018 11:44:59 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 19BF176B74032 for <netconf@ietf.org>; Tue, 28 Aug 2018 19:44:54 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 28 Aug 2018 19:44:56 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.188]) by SJCEML701-CHM.china.huawei.com ([169.254.3.173]) with mapi id 14.03.0415.000; Tue, 28 Aug 2018 11:44:52 -0700
From: Alexander Clemm <alexander.clemm@huawei.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>, "Tim Jenkins (timjenki)" <timjenki=40cisco.com@dmarc.ietf.org>
CC: "alex@clemm.org" <alex@clemm.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] Last Call on yang-push-17
Thread-Index: AQHUPhaKcQxQfuHY+Uq6v1G3YGy+OqTV7yqA//+S8KA=
Date: Tue, 28 Aug 2018 18:44:51 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB5A202@sjceml521-mbs.china.huawei.com>
References: <D6033FA2-D168-44E6-BB3C-BDE168165606@cisco.com> <e1553e32631443328bb807b9ad9c95c4@XCH-RTP-013.cisco.com>
In-Reply-To: <e1553e32631443328bb807b9ad9c95c4@XCH-RTP-013.cisco.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: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB5A202sjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/dqHWYC8_bd0lHb97ZcX5R1t5Qt4>
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 18:45:03 -0000
Incorporated the suggested changes into the text. --- Alex From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Tuesday, August 28, 2018 11:15 AM To: Tim Jenkins (timjenki) <timjenki=40cisco.com@dmarc.ietf.org> Cc: alex@clemm.org; Alexander Clemm <alexander.clemm@huawei.com>; netconf@ietf.org Subject: RE: [Netconf] Last Call on yang-push-17 Hi Tim, From: Tim Jenkins, August 27, 2018 10:59 AM <snip> 13. Section 4.4.4, paragraph 1: The resynch cannot apply to configured subscriptions? I would think the logic to apply its use would be independent of how the subscription is created. However, with multiple receivers, there may be issues with the use of this. <Eric> Allowing configured subscriptions to optionally support resynch RPC is possible, but it makes at least two things more complex: (1) Right now the publisher doesn’t need to support any dynamic signaling interactions with a configured receiver. (2) You are correct that the RPC would only be relevant per-receiver, rather than per subscription. So the publisher will actually perform a slightly different behavior with a resynch request. My suggestion therefore would be to tweak the text in 4.4.4 to “this RPC is supported for on-change subscriptions previously established using an "establish-subscription" RPC.” And the definition in the YANG model would be tweaked: OLD: This RPC can only be invoked on the same session on which the subscription was established (using an establish-subscription RPC). NEW: This RPC can only be invoked on the same transport session on which a subscription is currently active. This would allow future support of the resynch-subscription RPC for configured subscriptions if turns out people want that in the future. Eric
- [Netconf] Last Call on yang-push-17 Tim Jenkins (timjenki)
- Re: [Netconf] Last Call on yang-push-17 Alexander Clemm
- Re: [Netconf] Last Call on yang-push-17 Eric Voit (evoit)
- Re: [Netconf] Last Call on yang-push-17 Alexander Clemm