Re: [Netconf] Anyone want just Configured Subscriptions? (was RE: LC on subscribed-notifications-10)

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

> From: Kent Watsen, July 5, 2018 4:19 PM
> 
> 
> > My undefined point was that leaving NETCONF-Notif open means that  we
> > don't progress sections 3, 4, 5.1, 6, 7 , & 10 of
> > draft-ietf-netconf-netconf-event-notifications towards RFC.
> > These sections contain the needed requirements for dynamic
> > subscriptions.
> 
> I see, that's too bad, as I was hoping that we could just not progress the "notif"
> documents at all.  Let's review these sections to see what's possible:
> 
>   Section 3: yes, it seems like this needs to be said.  Though I
>   think a case is missing: establish-subscription RPC cannot be
>   sent on a session on which create-subscription is active, right?

To make it perfectly clear, I updated bullet #2 to:

It is a prohibited to accept an establish-subscription request, or send either updates or state change notifications for a configured subscription on a NETCONF session where the create-subscription RPC has successfully [RFC5277] created subscription.

>   Section 4: the first paragraph would now no longer be needed.

Yes

>   The 2nd paragraph seems like it should be moved to SN Section
>   2.1.  

No, the NETCONF stream is not a MUST for non-NETCONF or non-RESTCONF publishers.  E.g.: draft-birkholz-yang-core-telemetry

>  Is the 3rd paragraph needed? - YP already requires
>   ietf-datastore to be implemented, and the nmda-netconf draft
>   requires that <operational> be supported...

It could be removed as the requirement is inherited through the YANG models.  As drafts over in core are looking at YANG push for CoMI defined datastores (i.e., draft-birkholz-yang-core-telemetry), I thought it couldn't hurt to make it clear.

>   Section 5.1: the first paragraph seems obvious, 

For HTTP transport, it can be ok to lose the transport session and leave up the subscription.  (This can improve scale)   So better to make it explicit.

>   but also I think
>   the word "deleted" is wrong, since there is nothing to delete,
>   should this be rephrased?

There is a delete-subscription RPC.  Why is it wrong?

>   Section 6: the 1st paragraph seems okay.  The 2nd paragraph
>   seems okay for dynamic subscriptions, but this section applies
>   to configured subscriptions too, from which there isn't an
>   "establish-subscription" - right?

True.  To clarify the 2nd paragraph, tweaked the words to:

"For dynamic subscriptions, all notification messages MUST use the NETCONF transport session used by the "establish-subscription" RPC."

>   Section 7: First, it seems like much of this section (and s3.3
>   in restconf-notif) could be moved to the SN draft.

This is not the case, as the mapping is NETCONF specific.  Non NETCONF/RESTCONF transports will not necessarily use this mapping.

>   That said,
>   I think that the 1st paragraph should remove the reference to YP
>   draft, since YP just augments the SN draft. 

There is an additional non-augmented RPC in YANG-Push:  resynch-subscription.

>  Regarding the 4th
>   bullet point following the first paragraph, I think that it is
>   sufficient to just identify that a suitable base identity must
>   be returned (i.e., lose the refs to Sections 2.4.6 and A.1).

That is the way I initially had it.  Martin requested that these be made explicit during his review.

>   The 2nd paragraph seems to be defining a non-standard way to
>   encode identities (red flag).

This also was at Martin's request.  It is not non-standard as it simply describes the encoding of an error string.

>   Section 10: the 1st paragraph is not a security consideration
>   (move to Section 5?).  

Moved into 5.2.

>  The 2nd paragraph articulates a valid
>   concern, but it seems to apply to all transports (although
>   missing in the restconf-notif draft) and so should be moved
>   to the SN draft? 

As the mechanism for mitigating certain DDoS vectors is transport specific, the transport drafts seemed a better place.  

If you are good with it staying as a transport mechanism, I will add corresponding text to RESTCONF-Notif.

>   The 3rd paragraph could be removed, since it
>   isn't for dynamic subscriptions.

Yes.

Eric

> Thoughts?
> 
> Kent // contributor