Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06

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

Hi Kent,

> Hi Eric,
> 
> 
> 
> The intent of my comment was mainly to assist the understandability between
> drafts.   Subscription state change notifications are a part of RFC8639.
> 
> Assisting understandability is good!  :)
> 
> 
> 
> 
> This draft's Section 1.1 Applicability statement *totally appropriately* notes that
> only a subset of RFC8639 constructs are applicable.
> 
> The -06 "applicability statement” was removed in -07.

I still see "1.1.  Applicability Statement" in -v07 of
https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07
 
> -07 also has an “applicability” section (Section 3.1), but it regards an entirely
> different matter.  That said, this “applicability” section has also been removed
> (or will be, when -08 is posted), per comments from Martin.
> 
> 
> 
> As a result subscription state change notifications are not required when
> leveraging this specification.
> If there is a minimum set of subscription state change notifications required or
> desired, it would be good to list them.  I suspect there are not (as per the
> Applicability Statement).  Based on this, I believe it be worth listing some
> implications of not having the subscription state change notifications in the
> Security Considerations section.  E.g., not sending a <subscription-modified>
> might mean a receiver can't be sure that a compliant publisher is sending the full
> set of events expected.   Such a statement would make it easily apparent to an
> implementer of the differences in functionality delivered as they choose which
> RFCs to support.
> 
> RFC 8639 needs to state what notifications are required by valid
> implementations.  

RFC 8639 Section 2.7 "Subscription State Change Notifications" starts with "In addition to sending event records to receivers, a publisher MUST also send subscription state change notifications when events related to subscription management have occurred... The complete set of subscription state change notifications is described in the following subsections."   So the only optional ones are related to replay (if replay is supported) and suspension (if a publisher is capable of that.)  

> The notif drafts MUST NOT limit any notifications from being
> sent.  If there are Security Considerations related to certain notifications not
> being sent, they should be stated in RFC 8639.
> 
> Stated differently, the “notif” drafts define effectively *dumb* transport-level
> protocols.  If higher-level logic is layered on top of raw notifications,
> considerations for if certain notifications are *not* sent needs to be defined in
> the higher-level documents.

And the dumb transport is excellent.    All I was asking for is the differences in behavior between A.1 and A.2 to be noted somewhere.  The two are unlikely to be equivalent in functionality, however a reader new to the space could perceive equivalence. 

> Does this make sense, or do you mean something else?  Please provide specific
> text that you are hoping to see included.

Perhaps something like second paragraph in Section A.2 like:

Note that if the receiver requires:
* being fed metadata about the intended contents of the Event Stream,
* that changes to the publisher's configuration of Stream have occurred, or
* the publisher has temporarily suspended event transmission
then this application specific module should include functionality similar to that supported by the RFC-8639 Section 2.7 Subscription State Change Notifications. 


Eric 

> 
> K.
>