Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT)

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 30 April 2019 21:29 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 7D83A120147; Tue, 30 Apr 2019 14:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 Yff_8jHUmIMV; Tue, 30 Apr 2019 14:29:48 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F96120154; Tue, 30 Apr 2019 14:29:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4258; q=dns/txt; s=iport; t=1556659788; x=1557869388; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JUGt4tUlmLAyJhq9s6rmIgyJQOGYlN/47xbEp5LfGek=; b=am9AB/Llxvkqck1rDcYm2thK/XhMmoAghOXXbyh85X33NAeF8o8QfwzI HdR4HStvKLjzZNamnce3UmW4EsWDl+ZWpUglrIj2+j0zF5Dgg5g0lSYZT nIPL2fBqloQO8NACPbqhzasRVpIp0oQynss16a0IbrFYDlCMYf5682Srn g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAACKvchc/5NdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGBZippgQQoCoQGlTCYZIFnDgEBJYRIAheGGiM?= =?us-ascii?q?3Bg4BAwEBBAEBAgECbRwMhUoBAQEDASMEDUMCBQsCAQgOBwUCCRYHAgICMBU?= =?us-ascii?q?QAgQBDQ2CT0yBew8Pr098M4RGQYUpBoELJwGLSheBQD+EIz6CYQIBAgGBKgE?= =?us-ascii?q?SAYMpglgEiwiCN4w+jQcJAoIJhhWELYdwI4INhjeMa4wOhkOODgIRFYEwNSJ?= =?us-ascii?q?lWBEIcBWDJ4JGiEyFP0ExAZF1gSKBIQEB?=
X-IronPort-AV: E=Sophos;i="5.60,414,1549929600"; d="scan'208";a="556754014"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2019 21:29:45 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x3ULTjwd013541 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Apr 2019 21:29:45 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.1473.3; Tue, 30 Apr 2019 17:29:44 -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.1473.003; Tue, 30 Apr 2019 17:29:44 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" <draft-ietf-netconf-subscribed-notifications@ietf.org>, Kent Watsen <kent+ietf@watsen.net>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT)
Thread-Index: AQHU/43eaU0mVheLMEKEty0C2KlleqZVLZdA
Date: Tue, 30 Apr 2019 21:29:44 +0000
Message-ID: <257ba0408739443e8a1af9d3a888fa8b@XCH-RTP-013.cisco.com>
References: <155665377891.7475.13101015755522983059.idtracker@ietfa.amsl.com>
In-Reply-To: <155665377891.7475.13101015755522983059.idtracker@ietfa.amsl.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.233]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/WHXDXJPX1x2ZX4K58Qer9VcSoEU>
Subject: Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT)
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: Tue, 30 Apr 2019 21:29:50 -0000

Thanks very much for the comments Roman.    Some thoughts in-line...

> From: Roman Danyliw via Datatracker -- Tuesday, April 30, 2019 3:50 PM
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-netconf-subscribed-notifications-24: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Sections 2.4.2.1 and 2.5.6 seems to describe a mechanism (replay) to access
> historical data that was potentially collected prior to a given subscriber having
> access to it.  This appears to be an explicitly designed feature.  No push back on
> that.  However, I believe that explicitly stating this arrangement is warranted.
> Perhaps something on the order of the following could be added to the Security
> Considerations -- “The replay mechanisms described in Sections
> 2.4.2.1 and 2.5.6 provides access to historical event records.  By design, the
> access control model that protects these records could enable subscribers to
> view data to which they were not authorized at the time of collection.”

I have no problems at all with this exact statement being placed into the Security Considerations section.   So I just added it verbatim.   (I don't expect this to be controversial as this is the same behavior which is available from RFC-5277 implementations.)

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (1) Section 2.5.1.  Per Figure 8, if a modify operation fails re-evaluation (the “no
> (2)” branch) wouldn’t it go directly to “invalid” (instead of through
> “unsupportable->invalid”)?

Effectively it does go right to invalid, as 'unsupportable' isn't a state.  The merge was a something in the diagram which was intended to save some space.  Basically both (2) and (3) go through "unsupportable" to explicitly show that a "subscription terminated" message needs to be sent to any currently active but soon disconnected receivers.  

> (2) Section 2.5.2, what are “transport specific call-home operations”?

A transport specific document needs to define how to establish a transport connection from a configured publisher to an intended receiver.    An example of the operations would be in sections 3 & 4 of  RFC 8071 (NETCONF Call Home and RESTCONF Call Home.)

> (3) Section 2.5.6.  Typos
> 
> s/timegap/time gap/
> s/successfully/successfully/

Fixed.

Thanks!
Eric