[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, 08 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
- [netconf] overview of updates and current issues Kent Watsen
- Re: [netconf] overview of updates and current iss… Juergen Schoenwaelder
- Re: [netconf] overview of updates and current iss… Kent Watsen
- Re: [netconf] overview of updates and current iss… Juergen Schoenwaelder
- Re: [netconf] overview of updates and current iss… Kent Watsen
- Re: [netconf] overview of updates and current iss… Juergen Schoenwaelder
- Re: [netconf] overview of updates and current iss… Rob Wilton (rwilton)