Re: [netconf] Virtual hum for the question on "https-notif" draft

Kent Watsen <kent+ietf@watsen.net> Wed, 29 April 2020 23:50 UTC

Return-Path: <01000171c8592477-936cf5b6-e4fa-4426-80e9-9ba560c4bd51-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 AC0C43A0A66 for <netconf@ietfa.amsl.com>; Wed, 29 Apr 2020 16:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 YKTuYpjltHhe for <netconf@ietfa.amsl.com>; Wed, 29 Apr 2020 16:50:19 -0700 (PDT)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97733A0A58 for <netconf@ietf.org>; Wed, 29 Apr 2020 16:50:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1588204217; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=QSUbtgI4dEjXS0jk/mGIZnhkT5pay2qKk2K/wzwJAAA=; b=cDlYi3S/tRao4yILUwUAUcbxaSHI3IsAMK8ewkvCgqqij4Kz75X+dqmlnDVctrNN b00ZXN4A0nATsePFH6xzvzsFPIW+zjeN1fh5TLO/tBkCKqhvwgDKDpODbK+moRDHvNW edXNuA1O9quDNxlSM3cYCkpSql5c8cz3LCqYmUfc=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000171c8592477-936cf5b6-e4fa-4426-80e9-9ba560c4bd51-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_75803C75-1F8D-4DA5-BCC1-53FA9B557083"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 29 Apr 2020 23:50:17 +0000
In-Reply-To: <BL0PR11MB312212D6F955DF26188D0901A1AD0@BL0PR11MB3122.namprd11.prod.outlook.com>
Cc: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>, "netconf@ietf.org" <netconf@ietf.org>, Martin Bjorklund <mbj@tail-f.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
References: <5CE2095E-7117-4092-B356-A5C4FF490D10@gmail.com> <MN2PR11MB4366FC94F18140F1BB153A1FB5AF0@MN2PR11MB4366.namprd11.prod.outlook.com> <01000171bc405640-6e173d84-f921-4f6f-929a-6431410051c8-000000@email.amazonses.com> <BL0PR11MB312212D6F955DF26188D0901A1AD0@BL0PR11MB3122.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.04.29-54.240.48.90
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/6UJ5uxaONIugfx_mQJDvS3UwkA4>
Subject: Re: [netconf] Virtual hum for the question on "https-notif" draft
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: Wed, 29 Apr 2020 23:50:22 -0000

Eric,

> In light of the RFC 8639 text quoted above, we might question the validity of the hum…or, given the strong preference from the hum, we might question the validity of that constraint in RFC 8639.  If questioning RFC 8639, a better question to ask might be why the configurable “encoding” leaf isn’t mandatory (also eliminating this issue and seemingly cleaner)?
>  
> <eric> The WG feedback during RFC-8639 development was that encoding was often implied from transport.  Therefore mandating exposure of this information in the model was overly verbose, and could result in misconfiguration.  

Okay, but now our first configurable transport can support multiple encodings and 70% of the WG wants to “let the market decide” (i.e., no required, or default, encoding), it seems almost like we’re contradicting ourselves here...  

You mention the rational making the ”encoding” leaf optional, which seems reasonable to me, but what about mandating a default, do you have a sense for how many people weighed-in on that decision?  

PS: separately, can you look into configuring your mail agent to indent quotes in responses?

Kent // contributor