Subject: [netconf] overview of updates and current issues

From: Kent Watsen <[email-masked]>
Date: Mon, 8 Apr 2019 00:07:59 +0000

For all drafts:

  - Collapsed all the inner groupings into the top-level grouping.
  - Added a top-level "demux container" inside the top-level grouping.
    By "demux", I'm referring to the namespace problem discussed @104.
  - Added NACM statements and updated the Security Considerations section.
  - Added "presence" statements on the "keepalive" containers, as was
    needed to address a validation error that appeared after adding the
    "must" statements into the NETCONF/RESTCONF client/server modules.
  - Updated the boilerplate text in module-level "description" statement
     to match copyeditor convention.

For the http draft:
  - removed "keepalive" node
  - added "proxy-server" node
  - added "protocol-version" node
  - added "server-name" node

For the netconf/restconf drafts:
  - Adjusted for the top-level "demux container" added by groupings
    imported from other modules.
  - Added "must" expressions to ensure that keepalives are not
    configured for "periodic" connections.
  - Moved "groupings-expanded" tree diagrams to the Appendix.

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?

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?

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?

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.

  Someone else can write it.

  Thoughts?

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Apr 2019 17:46:13 +0200

>         Pros: maximum flexibility

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.
 
>       maybe there's a better answer?

No idea.
 
>    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.
 
>    that could also contain a picture like this:

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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 15 Apr 2019 21:05:30 +0000

Hi Juergen,

Thanks for your response.

>>       - now the NC/RC models look better
> <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...?

>>      maybe there's a better answer?

This remains an open issue.

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

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

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Apr 2019 23:34:48 +0200

Inline...

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

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.
 
> 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 (d…

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?

> 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 m…

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

> 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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 16 Apr 2019 22:44:38 +0000

> On Apr 15, 2019, at 5:34 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Inline...
> 

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.

> called home - so how can we be sure that keep alives never make sense

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

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

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.

>> which might be right, but somehow it feels odd that the client wouldn't always close the connection...
>> 
> 

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:

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

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Apr 2019 09:52:21 +0200

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

I think we should discard the "demux containers" to give data model
writers the freedom to have them or not.

>                      establishing a new connection is NOT RECOMMENDED.

Sounds good, this provides a hint that implementers need to track and
limit call home connections.

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 23 Apr 2019 13:55:00 +0000

Hi Kent,

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

Hi Juergen,

Current Issues:

    Pros:

    Cons:

  Question:

about 10 lines above.

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

 What to do?

No idea.

                                       crypto-types
                                         ^      ^
                                        /        \
                                       /          \
                             trust-anchors       keystore
                                ^      ^------+    ^
                                |              \   |
                                |      +-----------+
                                |     /          \

Kent