Re: [netconf] overview of updates and current issues

[Kent Watsen <[e-mail]>]

Hi Juergen,

Thanks for your response.


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


>> 2. Only in the RESTCONF draft, http proxy-server weirdness
>> 
>>   a) in the "ietf-restconf-client", there's an unwanted "proxy-server"
>>      definition  (middle of page 43):
>> 
>>      /restconf-client/listen/endpoint/https/http-client-parameters/proxy-server
>> 
>>      An HTTP client that receives a call-home connection does NOT need
>>      to initiate a connection and therefore there never is a desire to
>>      configure a proxy server, but here it is!
>> 
>>      It's here because the "ieft-http-client" grouping defines it, but
>>      when that grouping is used, neither "refine" nor "augment" can
>>      remove the definition.
>> 
>>      Sure, a "must" could disable it, but it still shows in the tree
>>      diagram, which is undesirable...
>> 
>> 
>>  b)in the "ietf-restconf-server", there's a missing "proxy-server"
>>      definition  (bottom of page 48 ):
>> 
>>      /restconf-server/call-home/restconf-client/endpoints/endpoint/\
>>      https/http-client-parameters/<missing:proxy-server/>
>> 
>>      An HTTP server that establishes a call-home connection needs
>>      to initiate a connection and therefore there is a desire to
>>      configure a proxy server, but the config node is missing!
>> 
>>      This is because the "ieft-http-server" grouping doesn't
>>      defines a proxy-server node (because servers typically
>>      never need to go through a proxy so, when that grouping
>>      is used, the definition is missing.
>> 
>>      Sure, we could augment it in, but coupled with the above,
>>      maybe there's a better answer?
>> 
>>  What to do?
> 
> No idea.

This remains an open issue.


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


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




>> 4) Only in the NETCONF draft, Section 5 contains the old  "Design
>>   Considerations" text from ~5 years ago.
>> 
>>   The idea of removing is was discussed a while back, and someone
>>   said it was worth keeping...
>> 
>>   I'm thinking again to remove it, but rather to deleting it, I'm
>>   now thinking maybe we could *move* it to an Informational draft:
>> 
>>     "Architecture for the Collection of Client and Server Models"
>> 
>>   that could also contain a picture like this:
>> 
>>                                        crypto-types
>>                                          ^      ^
>>                                         /        \
>>                                        /          \
>>                              trust-anchors       keystore
>>                                 ^      ^------+    ^
>>                                 |              \   |
>>                                 |      +-----------+
>>                                 |     /          \
>> tcp-client-server     ssh-client-server      tls-client-server     http-client-server
>>       ^      ^              ^                  ^           ^               ^
>>       |      |              |                  |           |               |
>>       |      |              |       +----------+           |               |
>>       |      |              |       |                      |               |
>>       |      |              |       |                      |               |
>>       |      +--------------|-------|------------+         |               |
>>       |                     |       |            |         |               |
>>       |                     |       |            |         |               |
>>       +--------------+      |       |            |         |      +--------+
>>                      |      |       |            |         |      |
>>                      |      |       |            |         |      |
>>                   netconf-client-server        restconf-client-server
>> 
>> 
>> 
>> 
>>  If there is desire, it would be best to do it now so that all of
>>  the client/server drafts could reference it.  Thus, whichever draft
>>  a reader begins with, their attention is drawn to the collection and
>>  thus they can see how the part fits into the whole.
> 
> I like the modularization you are doing but perhaps the problem is
> that the packaging of this stuff into documents makes things hard to
> follow. For example, why not define crypto-types, trust-anchors, and
> keystore into one document? Then this document could explain the top
> part of your figure. One could perhaps also put tcp-client-server,
> tls-client-server, and http-client-server together, perhaps even
> adding ssh-client-server to it. Note that you always revise the
> modules are different speeds later on since you can have future RFCs
> take over control over a specific module.

I'm not interested in doing this work, especially given where we are now.   If there is consensus in the WG, I request someone take over being Editor for awhile.


> That said, I believe we need to document the design of this somewhere
> so that others use it instead of rolling their own solutions. So my
> preference likely is to do both, merge some closely related modules
> into single documents and have a document that explains the overall
> design and how it is to be used by others.


I support "have a document that explains the overall design and how it is to be used by others", but I would like someone else to pick up the pen.  In the meanwhile, I think that it is safe to delete Section 5 (Design Considerations) from the netconf-client-server draft.   Someone can grab it from the archives when needed.


Kent