Re: [Netconf] configuration models status and timeline

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Jul 18, 2018 at 02:25:06PM +0000, Kent Watsen wrote:
> Hi Juergen,
> 
> Thanks for the analysis.  I was also thinking that it seems that just a couple issues were left, and then we could go to last call, potentially well within the timeframe needed for the YANG-push set of drafts.
> 
> Regarding #4: I met with two Security+YANG folks from Huawei yesterday, who have agreed to help me with this issue.  We also plan to try to loop back in Gary Wu, who created the identities in the ietf-ssh/tls-common modules in the first place.  Our tentative plan is a meet in a couple weeks.

Good. Sooner is better. ;-)
 
> Regarding #6: my understanding (from Tim C. and Balazs L.) is to use some combination of a notification and an RPC to stimulate traffic.  Presumably:
> 
>   For when the NC/RC-client is the transport-initiator (normal):
> 
>     - if there is a lull, the client could send a bogus RPC of 
>       some sort (e.g., an <edit-config> that selects nothing) 
>       and wait for the server sends an RPC-reply.

Ideally, the keep alive would just be handled at the session layer. I am
not sure where the NC spec allows

C: <rpc message-id="101"
C:      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
S: <rpc-reply message-id="101"
S:      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>

otherwise one could define a noop RPC (I am not sure invoking a fake
edit-config is necessarily a good idea).

>   For when the NC/RC-server is the transport-initiator (call-home):
> 
>     - if there is a lull, the server could send a notification
>       and wait for the client to send an RPC of some sort, which
>       the server would, presumably, send a reply for, to complete
>       the protocol transaction.  The downside to this approach
>       is that it is wholly dependent on the client processing the
>       notification correctly (i.e., it's not baked into the NC/RC
>       protocols themselves).

If you do call-home, there is still a client who could send keep alive
messages. But yes, if you only stream notifications, then the server
receives no feedback from the client in NETCONF (and I assume the same
it true for RESTCONF notification streams).  So here it is easier to
say "protocol keep alive" than it is to work out the details.

>   As for removing keepalives altogether, please note the SHOULD 
>   in RFC 8071, S7.

Yep, but this text is specific for TLS and SSH and it seems TLS
libraries practically have an issue here.

>   Another idea is to keep them, but add an 
>   enumeration called something like "protocol-layer" (which 
>   protocol layer should the keepalives occur) with a single 
>   built-in option ("crypto-layer"?) and then let some future 
>   module augment-in an additional enum like "app-layer".

My point is that working out protocol layer keep alives is not as easy
as it may sound (unless someone has a solution I can't think of) and
the question is whether we want to hold off the documents until
someone found a solution. It seems, we can define crypto layer
keep-alives with a feature and then implementations will have to deal
with this (for SSH this seems less an issue, so this affects NC over
TLS primarily and also RC) and perhaps we can also define TCP layer
keep-alives with a feature and with a warning attached to it (could be
that the security ADs are OK with that if the warning makes the issues
clear). For both keep-alives, we know how they would work.

Protocol layer keep-alives are something new to be invented and it is
somewhat unclear how they would work for the notification streaming
case. It seems protocol layer keep-alives can be developed separately
and then augmented in where the keep-alives are configured. A short
RFC that details how the keep-alive messages work plus an augmentation
of the configuration model (perhaps even just the definition of another
identity).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>