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

Roman Danyliw <rdd@cert.org> Wed, 01 May 2019 14:23 UTC

Return-Path: <rdd@cert.org>
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 ECA9F120122; Wed, 1 May 2019 07:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 Mf9P-HmcuErX; Wed, 1 May 2019 07:23:27 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 B4F761200CE; Wed, 1 May 2019 07:23:27 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x41ENJcn026216; Wed, 1 May 2019 10:23:19 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x41ENJcn026216
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1556720599; bh=k6oEP43zD4XJ2JoD5V2TFgMSSbwWpmMR0AMSnLgkyPA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=p1ArMVdhOfGxPfb3YOArExG7OjPpt0Yt/zVQgfVTG1+wPqDqqBMg0kADqJCXofLu8 yem3cbi7UcGcW5ddKehSxPzd9Lfl3/UTLkRLRvkYkJMszO+5I67OpdyfEyOtrO2ZS4 NjQc1BVNaHp1KAdVxfmDeJnIuq214dTaFLv6BXnw=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x41ENGb8003420; Wed, 1 May 2019 10:23:16 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Wed, 1 May 2019 10:23:16 -0400
From: Roman Danyliw <rdd@cert.org>
To: "Eric Voit (evoit)" <evoit@cisco.com>, 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/43bdZR/ina0AEW5K8wY2ATR0aZVe5oAgADXmyA=
Date: Wed, 1 May 2019 14:23:15 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33508ED@marathon>
References: <155665377891.7475.13101015755522983059.idtracker@ietfa.amsl.com> <257ba0408739443e8a1af9d3a888fa8b@XCH-RTP-013.cisco.com>
In-Reply-To: <257ba0408739443e8a1af9d3a888fa8b@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.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/YtDNMpp80gjgCQq5uZdF2Vxf8HU>
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: Wed, 01 May 2019 14:23:30 -0000

Hi!

> -----Original Message-----
> From: Eric Voit (evoit) [mailto:evoit@cisco.com]
> Sent: Tuesday, April 30, 2019 5:30 PM
> To: Roman Danyliw <rdd@cert.org>;; The IESG <iesg@ietf.org>;
> Cc: draft-ietf-netconf-subscribed-notifications@ietf.org; Kent Watsen
> <kent+ietf@watsen.net>;; netconf-chairs@ietf.org; netconf@ietf.org
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-netconf-subscribed-
> notifications-24: (with DISCUSS and COMMENT)
> 
> 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-notific
> > ations/
> >
> >
> >
> > ----------------------------------------------------------------------
> > 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.)

Thanks for the adding the text.

> > ----------------------------------------------------------------------
> > 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.

Understood.  Thanks for the clarity.

> > (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.)

I appreciate the clarifying pointer.  

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

Thanks.

Regards,
Roman

> Thanks!
> Eric