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

[Andy Bierman <[e-mail]>]

On Thu, Jul 5, 2018 at 1:03 PM, Eric Voit (evoit) <[e-mail]> wrote:

> *From:* Andy Bierman, July 5, 2018 3:17 PM
>
> On Thu, Jul 5, 2018 at 11:41 AM, Kent Watsen <[e-mail]> wrote:
>
>
> >>> Why does there need to be a dependency on the client-server module?
> >>> The only things missing from the "receiver" list are 2 leafs (host,
> port).
> >>
> >> <Eric>  This is what was there initially.   But several people have
> >> asserted that host and port interacts poorly with call-home.
>
> The issue isn't call-home, per se, the issue is that a
> transport-independent
> draft should leave all transport-specific details to the transport drafts.
>
>
>
>
>
> The current "receiver" list is not usable as a standard.
>
> IMO the need for a (host, port) tuple is not enough to require new modules,
>
> but I do not object to removing the configured subscriptions because
>
> they have to wait for other YANG modules.
>
>
>
>
> > Of course it interacts poorly with CallHome, because the receiver list is
> > used INSTEAD of CallHome, not with CallHome. CH is for initiating a new
> NC
> > or RC session, so a "special" version of it that doesn't initiate a
> session
> > would be a misuse.
>
> I don't follow this comment.  For configured subscriptions, the device is
> definitely initiating the underlying transport connection and, in the case
> of NC/RC, we've determined that the ietf-*conf-server's call-home mechanism
> is appropriate.
>
>
>
>
>
> CallHome is for initiating the NETCONF or RESTCONF protocol.
>
> It applies to dynamic subscriptions. E.g., our server initiates a CH
> session
>
> and the controller starts the session and decides what operations to send
>
> (such as establish-subscription).
>
>
>
> CH does not allow the client to use the TCP connection for any other
> purpose.
>
>
>
> <Eric> Initiating a Call Home before a dynamic subscription is absolutely
> fine.  Luckily this step is out of scope for the subscription drafts, as
> the transport session is already available when the establish-subscription
> comes in.
>
>
>
It is not fine according to RFC 8071.

   The techniques described in this document are suitable for network
   management scenarios such as the ones described in Section 1.1.
   However, these techniques are only defined for NETCONF Call Home and
   RESTCONF Call Home, as described in this document.

      ...Any use of call home with SSH/TLS for purposes other than NETCONF
or RESTCONF will need a thorough contextual risk assessment. ...

If your server opens a TCP connection to the client and does anything other
than
the procedures in RFC 8071, then it isn't CallHome. It is something new
that should be specified in an RFC and approved by the IETF.



> Eric
>
>
>

Andy


>
>
> Kent // contributor
>
>
>
>
> Andy
>
>
>
>
>