[netconf] overview of updates and current issues

Kent Watsen <kent+ietf@watsen.net> Mon, 08 April 2019 00:08 UTC

Return-Path: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@amazonses.watsen.net>
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 32F2F120267 for <netconf@ietfa.amsl.com>; Sun, 7 Apr 2019 17:08:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 5OxnvvhxgTtT for <netconf@ietfa.amsl.com>; Sun, 7 Apr 2019 17:08:02 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96C9120248 for <netconf@ietf.org>; Sun, 7 Apr 2019 17:08:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554682080; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=23vlV1lkmEAaWl1ox/nfqnyvv/wekIZfO9j1WRTbt/4=; b=VfY8h6AQBI6rRXNrG6pwJc7MDtVRMNWIKk2nyGs8B7vuda634+xZGp5FadXZPHYn xZfHlN+SIEy2ptb8kGKwnWTFatmLnn2QPQFjUEafVp6HGyD07XfAFNUlXBYSY+xCTQb bI+UeeC6kHLsijB9RD/O8LMBk6m6k5E99ygDf9FI=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-ID: <01000169fa45ea88-505cd325-94b7-4d48-a529-448a9905f534-000000@email.amazonses.com>
Date: Mon, 8 Apr 2019 00:07:59 +0000
To: "netconf@ietf.org" <netconf@ietf.org>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.04.08-54.240.8.83
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/n3YlHhGpDnAxMveF5VkFJHZw8GI>
Subject: [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 00:08:04 -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