[netconf] John Scudder's Discuss on draft-ietf-netconf-https-notif-14: (with DISCUSS)
John Scudder via Datatracker <noreply@ietf.org> Mon, 29 January 2024 20:00 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5ADC151064; Mon, 29 Jan 2024 12:00:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-netconf-https-notif@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, maqiufang1@huawei.com, maqiufang1@huawei.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <170655843581.28855.6523055059007714274@ietfa.amsl.com>
Date: Mon, 29 Jan 2024 12:00:35 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/m2nRsxEeXnt-2tn6Zyr9oO-hs0Y>
Subject: [netconf] John Scudder's Discuss on draft-ietf-netconf-https-notif-14: (with DISCUSS)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
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, 29 Jan 2024 20:00:35 -0000
John Scudder has entered the following ballot position for draft-ietf-netconf-https-notif-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this update. Since I already balloted No Objection on version 13, I’ve only reviewed the changes. They look fine, except one, on which I’m balloting DISCUSS. Be not afraid, this is the world’s easiest DISCUSS, and it comes packaged with a fix I think you will like. Version 14 says: “The update policy is “Specification Required”. Updates do not require an expert review by a Designated Expert.” This was changed from version 13, which said, “The update policy is “RFC Required”. Updates do not require an expert review by a Designated Expert.” I presume it was changed as a result of Murray’s DISCUSS questioning the “do not require an expert review” sentence and suggesting the use of Specification Required. I agree with Murray’s questioning of that sentence, but I’m afraid his fix has made things worse, not better. That’s the bad news, the good news is the correct fix is trivially easy. In my view, the correct fix is to revert to the version 13 policy, but completely delete the “do not require” sentence. That is, OLD (version 14): The update policy is “Specification Required”. Updates do not require an expert review by a Designated Expert. NEW: The registration policy is “RFC Required”. I’ve discussed this with Murray and he agrees in broad strokes. A little more background: the problem with shifting to Specification Required is that it definitionally requires use of an expert, you can’t disclaim it per my reading of RFC 8126 Section 4.6: For the Specification Required policy, review and approval by a designated expert (see Section 5) is required [...] There is no “unless” clause. No DE, no SR. Besides that, it’s not what you want! (I think. More below.) On the other hand, “RFC Required” (Section 4.7) doesn’t require expert review to begin with, so it’s redundant to say one isn’t required. Ergo, since this seems to be the policy you really want (demonstrated by the “reference” field definition in your template), simplify and stick with it! Do note that “RFC Required” is a more stringent policy than some, since as you know, it isn’t trivial to publish an RFC. But I’m assuming you knew that and chose your words deliberately. (In my NEW text I also changed “update policy” to “registration policy” since that’s the RFC 8126 lingo.)
- [netconf] John Scudder's Discuss on draft-ietf-ne… John Scudder via Datatracker
- Re: [netconf] John Scudder's Discuss on draft-iet… Mahesh Jethanandani
- Re: [netconf] John Scudder's Discuss on draft-iet… John Scudder
- Re: [netconf] John Scudder's Discuss on draft-iet… Mahesh Jethanandani