Re: [netconf] overview of updates and current issues

[Juergen Schoenwaelder <[e-mail]>]

On Mon, Apr 08, 2019 at 12:07:59AM +0000, Kent Watsen wrote:
> 
> Current Issues:
> 
> 1. Regarding the "demux containers":
> 
>      Pros:
>        - now 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? I have
no strong opinion, they may be ok although things get a bit more
verbose.
 
> 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.
 
> 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.
 
> 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.

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.

/js

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