Re: [Netconf] netconf call home connection type

[Kent Watsen <[e-mail]>]

> Hi,
>
> In draft-ietf-netconf-netconf-client-server-06, each "netconf-client"
> in the "call-home" list has a list of endpoints and a
> "connection-type".  The connection type defaults to "persistent".

> I suggest we add a new connection type case "on-demand" or something
> similar, which can be used e.g. when there is something external to
> trigger the call home.  

"periodic" is meant to cover on-demand also.   Very early slides on all
this used to call it "periodic + on-demand".  The "reconnect-timeout" 
description statement says: 
 
  In ietf-netconf-client:
    The NETCONF client may initiate a
    connection before this time if desired
    (e.g., to set configuration).";

  In ietf-netconf-server:
    The NETCONF server may initiate a connection before
    this time if desired (e.g., to deliver an event
    notification message).";


> An example would be a periodic yang push subscription.

Right, "to deliver an event notification message".


> I also suggest that the default connection strategy either is 
> dropped, or changed to "on-demand".

This was discussed at the IETF 102 meeting (see attached slide and
lines 329-335 in the minutes).  Essentially, folks want to add a
"periodic" feature enabling the initiating peer to optionally
support periodic connections.  As such, I don't think it should
be the default.


> Also, looking at the "periodic" case, when have in ietf-netconf-server:
>
>           |        +--rw periodic!
>           |           +--rw idle-timeout?        uint16
>           |           +--rw reconnect-timeout?   uint16
>
> In YANG Push, we have:
>
>           |  +--rw yp:periodic!
>           |     +--rw yp:period         yang:timeticks
>           |     +--rw yp:anchor-time?   yang:date-and-time
>
>
> does it make sense to use similar parameters in these two cases?

The YANG Push parameters have no equivalent to "idle-timeout".  This
is what is sometimes called a "linger-timeout".  The connection stays
open a little while longer in case the remote peer has a follow-up,
as they often do.  There would be no need for YANG-push to have this
concept, being primarily a one-way flow.

The client-server drafts have no equivalent to "anchor-time", some
point in the future after which connections begin.  This looks
complex with questionable value, worth keeping?


Kent // contributor