Re: [netconf] overview of updates and current issues

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 08 April 2019 15:46 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2531120310 for <netconf@ietfa.amsl.com>; Mon, 8 Apr 2019 08:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF1beoggiqBj for <netconf@ietfa.amsl.com>; Mon, 8 Apr 2019 08:46:33 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CABCA120307 for <netconf@ietf.org>; Mon, 8 Apr 2019 08:46:25 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 08A10E03; Mon, 8 Apr 2019 17:46:24 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id UgD85MhsNiCP; Mon, 8 Apr 2019 17:46:23 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 8 Apr 2019 17:46:23 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5231200C2; Mon, 8 Apr 2019 17:46:23 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id TVkksb88lw6p; Mon, 8 Apr 2019 17:46:23 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 10871200C1; Mon, 8 Apr 2019 17:46:22 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Mon, 8 Apr 2019 17:46:14 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 42D793007BA85C; Mon, 8 Apr 2019 17:46:13 +0200 (CEST)
Date: Mon, 8 Apr 2019 17:46:13 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20190408154613.ytibxwvjurfcwinp@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Kent Watsen <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
References: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@email.amazonses.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@email.amazonses.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/0rhQ2O-snnQT7VctHH6lYHi1uog>
Subject: Re: [netconf] overview of updates and current issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2019 15:46:44 -0000

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