Re: [netconf] overview of updates and current issues

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Kent,

From: netconf <[e-mail]> On Behalf Of Kent Watsen
Sent: 15 April 2019 22:06
To: Juergen Schoenwaelder <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] overview of updates and current issues


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...?
[RW]
It's not obvious to me what a nacm:default-deny-write means when applied to a grouping, noting that RFC 7950 section 7.12 indicates that the extension statement applies to the grouping statement itself, not the data node under which the grouping is used.

I wouldn't be surprised if quite a few YANG compilers would just regard this as a bug, or at least they wouldn't all behave in a consistent way.

Thanks,
Rob



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