[netconf] kw review of draft-wu-netconf-nmda-compatibility-01
Kent Watsen <kent@watsen.net> Mon, 25 March 2019 05:29 UTC
Return-Path: <01000169b352ec89-29aef326-0d11-4cf2-af02-c7ecd64aa4ef-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 8714612034F for <netconf@ietfa.amsl.com>; Sun, 24 Mar 2019 22:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 W3Myb91OHccn for <netconf@ietfa.amsl.com>; Sun, 24 Mar 2019 22:29:11 -0700 (PDT)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63EAD12034E for <netconf@ietf.org>; Sun, 24 Mar 2019 22:29:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553491750; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:To:Feedback-ID; bh=bhBi1oyTgoUySVMiMg6S45mOwG33kptPxnZ69v8IxEs=; b=diI2tKiZXA4PQz/i/RElktsslh30hqgeJb3VOdHrKpJ2XY+9h00uN74I86NGnWvX 0fy446acbO8kElf/Ccb6p0dfUFaAaM8W4E6qdLygJ/kjMGx735TQ5l5JtqPFgzFX5sk R2Jf7iVK1xTQOmMh4mKVIyTWd5wIck/QnyFzH1gA=
From: Kent Watsen <kent@watsen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail-D39BE5B3-0A2D-469D-84D8-BEB5C1ACE441"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Mon, 25 Mar 2019 05:29:10 +0000
Message-ID: <01000169b352ec89-29aef326-0d11-4cf2-af02-c7ecd64aa4ef-000000@email.amazonses.com>
To: netconf@ietf.org
X-Mailer: iPhone Mail (16D57)
X-SES-Outgoing: 2019.03.25-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/IbJ6gGAeqE0jfIw8xwGONKmN3dI>
Subject: [netconf] kw review of draft-wu-netconf-nmda-compatibility-01
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, 25 Mar 2019 05:29:13 -0000
I started reading this document, but struggled with this sentence in the Introduction: “NMDA Transition Guidelines in section 4.23.3 of [RFC8407] <snip/> doesn't provide guidelines on whether existing NETCONF protocol operations such as get/get-config/edit-config change semantics when they are exchanged between the non NMDA client and the NMDA aware server.” Correct, no statements are made (here or in RFC 8526), because no changes exist. RFC 6241 is unchanged by RFC 8526. The draft also has this statement in the Problems section: “When a server is upgraded to NMDA aware server and needs to support both NMDA client and non-NMDA clients, there is no standards-based way for the server to know whether the client supports NMDA.” True, but it doesn’t matter, as the server only cares if the client uses the RPC from RFC 6241 or RFC 8526. In order to maintain backwards compatibility, there are *no* changes to RFC 6241. It is an implementation issue for the NMDA-aware server to maintain support for the non-NMDA aware RPCs. FWIW, the draft also has suggestions for clarifying NMDA behavior (e.g., with-defaults), which may be needed, but I didn’t dig into these suggestions as I want to first ensure my understanding of the problem statement. Thanks, Kent // contributor