Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 04 May 2017 01:15 UTC

Return-Path: <evoit@cisco.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 B52B6127058 for <netconf@ietfa.amsl.com>; Wed, 3 May 2017 18:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 bjEkkVnLCyXa for <netconf@ietfa.amsl.com>; Wed, 3 May 2017 18:15:39 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871CA12954C for <netconf@ietf.org>; Wed, 3 May 2017 18:15:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12473; q=dns/txt; s=iport; t=1493860528; x=1495070128; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5W4KXuUGsxQXRi39KBkpyJ/PAdZZF2hF7DSwmvUkCCk=; b=eeiLXfKHMH/dW7lcCgQvqpQkpGD0wb9WNDOnGj+OkXXA/b4KSswdgv1q le70FDpdZCyXjlbpBaaAoXYZw5HLmQWhW86LVANtcAr4XKyJDhHMqxYeK +GDy/rvhHs8zVD6fBgh/c1/RgT+oY6+Yl4a0ZGJVeiKnFIN1m2kWX3YRh M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DPAACkfwpZ/4gNJK1cGQEBAQEBAQEBAQEBBwEBAQEBgm48K2KBDAeNeZFTiCKIFYU3gg8shXgChEA/GAECAQEBAQEBAWsohRUBAQEBAx0QQQsQAgEIFRAaByERFBECBAENBQiKAQMVDrJ8hy4Ngy4BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZfgV6DG4JUgkWFLwWJNog2hG+GRjsBhxqHKYRHgguFOYNlhQOBPYshiRIBHziBCm8VRYZwdodqgQ0BAQE
X-IronPort-AV: E=Sophos;i="5.38,286,1491264000"; d="scan'208,217";a="421564325"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2017 01:15:27 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v441FRN7030313 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2017 01:15:27 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 3 May 2017 21:15:26 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Wed, 3 May 2017 21:15:26 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "Andy Bierman (andy@yumaworks.com)" <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>
CC: Netconf <netconf@ietf.org>, Mahesh Jethanandani <mjethanandani@gmail.com>
Thread-Topic: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis
Thread-Index: AQHSxFM7evplkJhlYEmuOHGXG3Fp5KHjJrQw
Date: Thu, 04 May 2017 01:15:26 +0000
Message-ID: <f2106a6c538a4b9e96ba490b867bd40d@XCH-RTP-013.cisco.com>
References: <A13E62FA-AB96-4164-98D5-3CC1D04A78E8@gmail.com> <E236AC6C-4B6D-43B1-8092-0B8AA3F4D6AA@gmail.com>
In-Reply-To: <E236AC6C-4B6D-43B1-8092-0B8AA3F4D6AA@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: multipart/alternative; boundary="_000_f2106a6c538a4b9e96ba490b867bd40dXCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/32mjeTjwl0zUKpj9dKf6VLZd2Mo>
Subject: Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 04 May 2017 01:15:43 -0000

Hi Andy,
Hi Martin,

This is an excellent document.  I  have a few questions:

#1 Section 3.1.3
If a data node identified in a request has no read access allowed (i.e., data node rule violation), isn't it better to treat the response like the node didn't exist, i.e. a "data-missing" error code?   You highlight this as an issue in 3.7.2, but I don't see a reason why "data missing" isn't preferable to "access denied" (other than ease of debug.)

#2  Section 3.1.3
On the sentence: "If the user is not authorized to read all the specified data nodes and the notification node, then the notification is dropped for that subscription."    There is a difference between events (where the whole event should be discarded), and YANG object selections (where it is preferable to just discard those node for which a receiver has no access).   What are your thoughts based on the type of notification of allowing the simple dropping any nodes where read access is not available if the notification includes some extract of a yang datastore?

#3 Section 3.4.6
Outgoing <notification> Authorization in 3.4.6 say descendent nodes are out of scope.  But as some notifications can contain datastore extracts, it would seem useful allow NACM to act similarly to the processing of a response to a get.  Also is there an intersection of this point with #2 above?

Thanks,
Eric

From: Mahesh Jethanandani, May 3, 2017 5:18 PM

Folks,

There has been literally no feedback on this document, either to say they have read the document and support it, or to express concerns about the document. Silence, unfortunately is not a good guide for us. To move the document forward, we need to hear from folks, including those who were in IETF 98.

Thanks.

On Apr 18, 2017, at 5:34 PM, Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote:

NETCONF WG,

In IETF 98, the authors indicated that the above draft was ready for Last Call, and the consensus in the room indicated as much.

This is a start of a 2 week WG Last Call for draft-ietf-netconf-rfc6536bis. After two weeks, the document will be assigned a shepherd, and the document will be prepared for IESG.

The latest version of the draft can be found at:
https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-01

Please review and send any comments to the WG mailing list or by responding to this e-mail. Comments can be statements such as, I read/reviewed the document and believe it is ready for publication, or I have concerns about the document. For the latter, please indicate what your concerns are.

Any reports on implementation status or plans to implement are also very useful.

Authors, please indicate if you are aware of any IPRs related to the draft.

Thanks.

Mahesh and Mehmet



Mahesh & Mehmet