Re: [netconf] ietf crypto types - permanently hidden

Kent Watsen <kent+ietf@watsen.net> Thu, 04 April 2019 17:24 UTC

Return-Path: <01000169e9613a53-6b1ac2ef-810e-476b-84a5-0eb388e7af48-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 F092312008D for <netconf@ietfa.amsl.com>; Thu, 4 Apr 2019 10:24:19 -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 YiHS1LoLvCgS for <netconf@ietfa.amsl.com>; Thu, 4 Apr 2019 10:24:18 -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 7573D12000F for <netconf@ietf.org>; Thu, 4 Apr 2019 10:24:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1554398657; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=q+Omh3IK9V1x6QDFE00h5R6CkrFDk9nReheq1KdBGDo=; b=cc76ehCdkvprMQcpqukQTCP3L/dLq2zlhVfqGRgGwT4elnubbJHD6hdWlGTcDWPj PdBjr1px7LXRKkchqNiZI3V0iO33UJRx5Zu8IlrMBnvaVDD505Ltm52c10D1YJG6Umc 6C/Is5CtvtsCySWc7xgtBeMRpfj+1bRytAKpxLyQ=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000169e9613a53-6b1ac2ef-810e-476b-84a5-0eb388e7af48-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_42BBDE71-24DE-4B4B-AEA9-78100B02031F"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 04 Apr 2019 17:24:17 +0000
In-Reply-To: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de>
Cc: Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
References: <VI1PR07MB47351FF76BBF6C56AC6E64B5835E0@VI1PR07MB4735.eurprd07.prod.outlook.com> <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> <20190403.134424.1377386644961079970.mbj@tail-f.com> <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.04.04-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/vn_hiuYOGqiQDFmjS8wh6sLKfcM>
Subject: Re: [netconf] ietf crypto types - permanently hidden
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, 04 Apr 2019 17:24:20 -0000


>> We have always said no, but the reasoning is unclear.  What are the
>> specific objections and is there anyway to alleviate them?
>> 
> 
> If editing of all configuration can be done with a single edit-data
> (or edit-config) operation, you simplify the world and you enable
> generic implementations.
> 
> Once you build silos of data that can only be manipulated with special
> purpose operations, you say goodbye to the idea of generic client
> libraries.

Fair, so what can we do to ensure this doesn't spiral out of control?

Clearly there is some line being crossed here (a Security best practice)
that is driving this.   Could we add that such use MUST only be done in 
order to resolve a Security best practice?

That said, I think your fear is unwarranted.  I do not believe that folks
would rush to defined 1000s of RPCs.   It seems that such use would
be done only in extenuating circumstances.

And, besides, so what?  Why do we care if people do stupid things?
Do we feel that our obligation to prevent people from doing stupid
things is more important than enabling people to do smart things?

Kent