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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 30 Apr 2019 12:49:38 -0700

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

----------------------------------------------------------------------
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”)?

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

(3) Section 2.5.6.  Typos

s/timegap/time gap/
s/successfully/successfully/

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 30 Apr 2019 21:29:44 +0000

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

> From: Roman Danyliw via Datatracker -- Tuesday, April 30, 2019 3:50 PM
> 
> 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.)
> 
> 
> 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

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

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

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

> s/successfully/successfully/

Fixed.

Thanks!
Eric