Re: [Netconf] Anyone want just Configured Subscriptions?

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

From: Andy Bierman, July 9, 2018 11:07 PM
...

On Sun, Jul 8, 2018 at 8:05 PM, Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Andy,

From: Andy Bierman, July 8, 2018 12:26 PM
On Sun, Jul 8, 2018 at 9:05 AM, Martin Bjorklund <[e-mail]<mailto:[e-mail]>> wrote:
Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>> wrote:
> On Sun, Jul 08, 2018 at 09:58:07AM +0200, Martin Bjorklund wrote:
> > Andy Bierman <[e-mail]<mailto:[e-mail]>> wrote:
> > >
> > > You mean <start-all-configured-subscriptions> I think.
> >
> > Yes.
> >
>
> If you do this, why does the client, after receiving a call home, not
> simply create dynamic subscriptions? ;-)

Well, the configured subscription is needed anyway in order for the
device to call home, so having the client create all configured
subscriptions as dynamic subscriptions as well doesn't seem quite
right.

It is quite possible that multiple RPC operations are needed to get the session
started, such as reading the YANG library, and that the client
is not ready to receive notifications as soon as the session is started.
So an <activate-configured-sessions> operation may help.


But if the WG agrees that it is ok to send <notification> directly,
this issue goes away.

Sitting idle is definitely OK.
Accepting notifications right away is OK as an implementation feature
outside the standard.

<Eric> If the NETCONF-Notif says that the NETCONF client for a configured subscription must be able to handle accepting notifications right away, do you see any standardization issue with this behavior in this context?


Actually, I think there are issues with configured subscriptions wrt/ CallHome because
of the text in RFC 8071, 1.3:

https://tools.ietf.org/html/rfc8071#section-1.3

The transport and encoding leafs are identityrefs, which means the possible values
are unknown and unbounded.

Do all possible values (including vendor values, which are valid for the YANG leaf)
change the protocol enough so separate security analysis are required?
I think a SecDir review may raise concerns wrt/ this issue.

<Eric> For any IETF defined transport, a “Transport-Notif” draft definitely needs to address any issues with Call Home or other such mechanism.  At next IETF, perhaps we will see if this can await concurrent resolution with the NETCONF client/server work.

For configured subscriptions with a vendor specified transport identity, it would be great to see SecDir sees any issues.  I don’t see anything off hand (as it is a vendor transport), but I certainly don’t claim all their perspectives.

Eric

Eric

/martin

Andy


Andy