[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.)