Re: [netconf] overview of updates and current issues

[Juergen Schoenwaelder <[e-mail]>]

Inline...

On Mon, Apr 15, 2019 at 09:05:30PM +0000, Kent Watsen wrote:
> 
> >> Current Issues:
> >> 
> >> 1. Regarding the "demux containers":
> >> 
> >>     Pros:
> >>       - now the NC/RC models look better
> >>       - a convenient place to have a nacm:default-deny-write
> >> 
> >>     Cons:
> >>       - seems overbearing for general use
> >> 
> >>   Question:
> >> 
> >>     Would it be better to revert and instead wrap each "uses"
> >>     statement in the NC/RC models with a container?
> >> 
> >>        Pros: maximum flexibility
> >>        Cons: less consistency?
> > 
> > What exactly are the demux containers? You mean the
> > <tcp-client-parameters> and <tls-client-parameters> containers?
> 
> Yes.  This is what what meant by:
> 
>    "Added a top-level "demux container" inside the top-level grouping.
>     By "demux", I'm referring to the namespace problem discussed @104."
> 
> about 10 lines above.
> 
> 
> 
> > I have no strong opinion, they may be ok although things get a bit more verbose.
> 
> On the "Cons" side, I'm calling the containers "<protocol>-<client/server>-parameters".  I question is if this is a good name in all contexts.  By removing the "demux container",  it lets the consumer decide what to call it.  This brings us to the "less consistency?" comment;  of course there would be little consistency but, do we care?
> 
> Regarding "a convenient place to have a nacm:default-deny-write", I don't see anywhere in RFC 8341 that nacm:default-deny-write can't be used in a grouping, but it will impact the parent...  If the parent has other descendents besides from the grouping, those descendents would likely be impacted too, right?   Do we care?  If we put nacm:default-deny-write under the grouping statement, then I think that it subtly enforces consumers to create their own wrapper containers (as opposed to mixing the descendents in with other nodes).   Alternately, we could float the "if-feature" statement down to each descendent of the grouping.  Not ideal, but works...?
>

Perhaps instead of being tricky (subtly enforcing consumers to create
their own wrapper), why not move the nacm:default-deny-write to the
leafs? This seems less subtle and more robust.
 
> >> 3. In either the NETCONF and RESTCONF drafts, does it matter at all
> >>   where a 'must' statement is located, especially if they refer to
> >>   nodes that are conditional by "if-feature" statements?
> >> 
> >>      i.e., search for "case periodic-connection"
> >> 
> >>   Should the "must" statements be located somewhere else?
> > 
> > I actually wonder whether this must is really desirable. What breaks
> > if I have TCP keep-alives turned on for a periodic call-home connection?
> > Perhaps I want to enable keep-alives to work around a broken firewall.
> 
> The point of the periodic connection, from which it gets its name, is that it "frequently" sets-up and tears-down.  Thus is self-healing in the case of a network drop.
> 
> Our WG's primary use-case for keepalives is a device that has been configured to periodically call-home (perhaps every midnight), in case its controller application has any config pending for it (depositing logs is assumed to be out-of-band).    One can imagine the controller performing a number of steps, potentially with delays between the steps.

The point is that we do not know what will happen once the server has
called home - so how can we be sure that keep alives never make sense
with call-home?

> The ietf-[net/rest]conf-server-grouping groupings say this about the "periodic-connection" presence container (under "call-home"):
> 
>                      "Periodically connect to the NETCONF client.  The
>                       NETCONF client should close the underlying TCP
>                       connection upon completing planned activities.
> 
> So, if the connection is dropped (do to a lack a keepalives), should the server interpret that as "the client completed planned activities", and therefore doesn't need to connect again until next midnight?

The server likely does not care, at least likely not more than without
call-home. I assume that keep alives are more interesting for a client
that is not constantly talking to the server but likes to keep the
session open (for whatever reason).

> Separately (not related to the above), the ietf-[net/rest]conf-client-grouping groupings say (under "initiate"):
> 
>                      "Periodically connect to the NETCONF server.  The
>                       NETCONF server should close the underlying TCP
>                       connection upon completing planned activities.
> 
> which might be right, but somehow it feels odd that the client wouldn't always do close the connection...
>

For the use cases I have in mind for this, the server would not really
know when to close the connection since the client would take control
over what is going on. This may, however, be different from a
call-home to stream notifications. Perhaps we should say less.

One thing that comes to mind is whether a new callhome attempt should
be made in situations where the previous callhome is still alive. Do
we want to say something about this or not?

/js

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