IETF Logo Mail Archive

Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types

Kent Watsen <kent@watsen.net> Thu, 25 April 2019 17:51 UTC

Return-Path: <0100016a559fd6c6-0deaad17-593f-434c-94b6-111ac0619a3c-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 A18F41201C7 for <netconf@ietfa.amsl.com>; Thu, 25 Apr 2019 10:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 5h1sS8MEdR2C for <netconf@ietfa.amsl.com>; Thu, 25 Apr 2019 10:51:48 -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 4B1691202E6 for <netconf@ietf.org>; Thu, 25 Apr 2019 10:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556214700; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=hKfQf6cxtmHG32qsvA4eHRIHyUHCz7dYa3FWlzjxCcs=; b=NRNEvGZzOLPz9Y0F3+dB50x/gQNXksg0LuTMDa6+4igYMmqvqmuS+yPAPVtdjsNk TOB61FBocQ9s7DaMQw4z5m2mTsSYtK1TsU8lz3QCqFlbDbr7hq9aIjnBXRs9HK4ceJx tGQms8crAQHzzODd6kODH5Fjpb5V3RSOHw1yKof4=
From: Kent Watsen <kent@watsen.net>
Message-ID: <0100016a559fd6c6-0deaad17-593f-434c-94b6-111ac0619a3c-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CF90D05C-DB7F-4372-992D-E37A270C8671"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 25 Apr 2019 17:51:39 +0000
In-Reply-To: <20190425.185116.1747028954255365462.mbj@tail-f.com>
Cc: Wang Haiguang <wang.haiguang.shieldlab@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>
To: Martin Bjorklund <mbj@tail-f.com>
References: <0AE05CBFB1A6A0468C8581DAE58A31309E3CB0F5@SINEML521-MBX.china.huawei.com> <20190425064201.lfuwspbkkwatbg6h@anna.jacobs.jacobs-university.de> <0100016a554785f6-a0f918fc-5396-4410-8320-701f65abf6c0-000000@email.amazonses.com> <20190425.185116.1747028954255365462.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.04.25-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/IZEiEx3O4Xkw3pcAHL6rPmgoF5A>
Subject: Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types
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: Thu, 25 Apr 2019 17:51:51 -0000


> On Apr 25, 2019, at 12:51 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> Kent Watsen <kent@watsen.net> wrote:
>> 
>> 
>>> This issue touches on an open issue that we never managed to solve:
>>> Given an arbitrarily extensible set of identifiers, how does an
>>> implementation announce the subset actually supported? And related to
>>> that, can a YANG module define a subset that is expected to be
>>> supported (i.e., a conformance requirement)? I am not sure we have
>>> a YANG next issue for this, but we should.
>> 
>> Just submitted https://github.com/netmod-wg/yang-next/issues/80
>> <https://github.com/netmod-wg/yang-next/issues/80>.
>> 
>> Perhaps YANG Library can be used for this?
> 
> This requirement is already captured in #40.

The issues are related, but seem like two sides of a coin:

   #40 regards deviating away what is not supported
   #80 regards expressing what is supported

Of course, what is supported could be form of implementing the module and then deviating away what's not used, but is it ideal?   

For instance, a server may implement different modules that use different sets of identities (e.g., because they use different libraries in the backend), such that what is not supported in one module (and hence the deviated away) is supported in the other (and hence shouldn't be deviated away).


Kent // contributor

v2.23.0 | Report a Bug | By Email