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

[Roman Danyliw <[e-mail]>]

Hi!

> -----Original Message-----
> From: Eric Voit (evoit) [mailto:[e-mail]]
> Sent: Tuesday, April 30, 2019 5:30 PM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; Kent Watsen
> <[e-mail]>; [e-mail]; [e-mail]
> 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