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

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

Return-Path: <01000171c838d773-fd48e2c5-2902-4244-b039-98cf5866b6a8-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 3CFD43A099D for <netconf@ietfa.amsl.com>; Wed, 29 Apr 2020 16:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 mbsoPkNv7Q1m for <netconf@ietfa.amsl.com>; Wed, 29 Apr 2020 16:15:02 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1BD43A03EA for <netconf@ietf.org>; Wed, 29 Apr 2020 16:15:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1588202100; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=ZHiyCoHQdwcRTwFjLHTDpr2Na22yIn022vaKShz+d7w=; b=Alp2+At7U2Q43knJAfJRY47WuqW2L9xEQ4IaTxWzjcLs/HQ4lW8QRjqfqwY/Nbrd AuU5yogDCXN+gtMcQL/8c5xY4G2wvb2wAa/efLtm49EhliAOFst93NrLFtXny5jNgRS /ucmCxKZfGN5dSCHftH90dJinBdPA0CkbxGAGtcY=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <20200429.203838.1829077676409702830.id@4668.se>
Date: Wed, 29 Apr 2020 23:15:00 +0000
Cc: evoit=40cisco.com@dmarc.ietf.org, rwilton=40cisco.com@dmarc.ietf.org, "netconf@ietf.org" <netconf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000171c838d773-fd48e2c5-2902-4244-b039-98cf5866b6a8-000000@email.amazonses.com>
References: <MN2PR11MB4366FC94F18140F1BB153A1FB5AF0@MN2PR11MB4366.namprd11.prod.outlook.com> <01000171bc405640-6e173d84-f921-4f6f-929a-6431410051c8-000000@email.amazonses.com> <BL0PR11MB312212D6F955DF26188D0901A1AD0@BL0PR11MB3122.namprd11.prod.outlook.com> <20200429.203838.1829077676409702830.id@4668.se>
To: Martin Björklund <mbj+ietf@4668.se>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.04.29-54.240.8.88
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/l_co-25ptPxNFOBofrFAdJ7EkvI>
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:15:05 -0000

>> 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)?
> 
> RFC 8639 explains that if the "encoding" leaf isn't configured, the
> transport-default is used.  RFC 8639 also says that a transport must
> have a transport-default.
> 
> That's the answer to the question: "why is 'encoding' optional?”.


No, that’s just paraphrasing what the RFC says.   Eric’s answer below provides a “why”.

Kent // contributor


> /martin
> 
> 
>> 
>> <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.
>> 
>> Adding Martin to the thread as he was previosuly involved with this discussion.
>> 
>> Eric