Re: [netconf] overview of updates and current issues

[Kent Watsen <[e-mail]>]

> On Apr 15, 2019, at 5:34 PM, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> 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.

Right, this was my last sentence: "Alternately, we could float the "if-feature" statement down to each descendent of the grouping.".

Okay, so it's technically possible (the nacm extension), but I feel that we're still open on if the "demux containers" should be kept or discarded.  

I'm personally leaning towards "discard", but I don't want to make the change until we have a solid decision.



>>>> 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?

I'm okay with removing these "must" statements"  They can be added in again later, potentially through an "augment" statement, if need be.



>> 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 (due 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).

Unsure.  It seems that a packer could drop the TCP connection immediately after NC/RC starts up.   The client would be unable to send any data to the server.  The server MAY think that it was a successful "no-op" call-home.  With NETCONF, the client could send <close-session>, but still there is a need to support dropped connections and, besides, there is no RESTCONF equivalent.


>> 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 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.

I think that you're right.  This is NOT for the call-home case (that is the "listen" subtree, not the "initiate" subtree).  I think that the comment is wrong and should say:

                    "Periodically connect to the NETCONF server.  The
                     NETCONF client should close the underlying TCP
                     connection upon completing planned activities.

or (since it's not special, as in the matching call-home statement):

                    "Periodically connect to the NETCONF server."

    To your point: "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?



If that happens, then something is wrong.  Either the previous attempt is "hung" (but I think there is an "idle-timeout" to catch such cases, maybe only for NC though), or it is legitimately still busy (in which case it MAY be an indication that the frequency is set too high but, in either case, it seems that a second connection wouldn't be desired).   There is currently no text stating what to do in this case.  It seems like such text might go into the same description statements discussed above:


                    "Periodically connect to the <protocol> <peer>.  The
                     <protocol> client SHOULD close the underlying TCP
                     connection upon completing planned activities.

                     In the case that the pervious connection is still active,
                     establishing a new connection is NOT RECOMMENDED.


Thoughts?


Kent // contributor