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

["Eric Voit (evoit)" <[e-mail]>]

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