Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-keystore-20

Kent Watsen <kent+ietf@watsen.net> Tue, 20 April 2021 01:28 UTC

Return-Path: <01000178ece4d8fd-09010867-cbff-486e-b598-3653e944b833-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 602403A0D39; Mon, 19 Apr 2021 18:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 X5psgx2qtx6v; Mon, 19 Apr 2021 18:28:45 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682053A0D2D; Mon, 19 Apr 2021 18:28:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618882124; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=Bq8iYRT9gnc+njqhiTBSJyRd5QhZ6GdYCzaYc6icsnM=; b=gVqlzRK4YiLXWGA7u/XWqI268YJqGzkh4tTqXZfQ0m+ifDM2LkJP9bHbDVaWRKCq KPyK83fb5Kn+P8Uh/3uBC/MdulhlKAsj65N5w2qI2LeZWRNIVbcPGhWy7SfSqBSbeJl vR7szPOQGsSyoWI2hz8p974yfCa0z4TUu7K0Dil4=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <20210416123749.246d6irnd3oso3x4@anna.jacobs.jacobs-university.de>
Date: Tue, 20 Apr 2021 01:28:44 +0000
Cc: YANG Doctors <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000178ece4d8fd-09010867-cbff-486e-b598-3653e944b833-000000@email.amazonses.com>
References: <161064362767.26403.10249622617283363882@ietfa.amsl.com> <010001778e68398d-c2bff7b8-4c4e-4f30-a962-1ce39e2ece13-000000@email.amazonses.com> <20210416123749.246d6irnd3oso3x4@anna.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.04.20-54.240.8.33
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/WArTCQFTLG-fCWw4oKEXJhqekMk>
Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-keystore-20
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: Tue, 20 Apr 2021 01:28:50 -0000

Hi Juergen,

Likewise trimming to the essential parts.

K.


>>> - Is the feature keystore-supported really needed? Does the YANG
>>> library not already provide the information whether a module has
>>> been implemented or just imported to access type and grouping
>>> definitions? OK, I know see that this is used to make definitions
>>> conditional, hence it makes sense. This means that my comment on
>>> truststore-supported in the other review can be ignored, I found
>>> the answer.
>> 
>> Please see my response to your comment in that draftb
>> 
> 
> See also my comment on the other document. My question was whether
> this bit can already be picked up from the YANG library.

Right, and I did just reply that whilst the two point to the same same, only one can be used in “if-feature” statement expressions, which is what is needed.


> 
>> BTW, b
> 
> I think this is better.

It took me while to determine what text got clipped above which you this is better.  Let me clarify, you think that it would be better to both:

OLD; keystore-supported
NEW: central-keystore-supported

*and*

OLD:  … the keystore, when this module is implemented
NEW: … the central keystore, when this module is implemented

Correct?


>>> - Section 4.3 talks about _highly_ restricted access mechanisms and
>>> _highly_ authorized clients and I am usually a bit confused what
>>> _highly_ means. But I am YANG doctor, not a security reviewer. ;-)
>> 
>> Trying to say that, e.g., the NACM should only allow a "crypto officer" access to the MKb
> 
> So is NACM the 'highly restricted access mechanisms'? Should it be
> 
> OLD
>  highly restricted access mechanisms SHOULD
> 
> NEW
>  access control mechanisms like NACM SHOULD

Replaced.  Better, thanks!


> OLD
>  highly authorized clients
> 
> NEW
>  authorized clients

NEWEST:  ...only to the most trusted authorized clients

Ok?


> My point is that "highly" simply does not mean anything (to me).

Point taken, “highly” doesn’t mean much.




> I browsed the diff, the changes look good to me.


Thanks,


K.