[yang-doctors] Review of draft-ietf-rtgwg-yang-key-chain-13
"Ladislav Lhotka" <lhotka@nic.cz> Mon, 20 February 2017 11:49 UTC
Return-Path: <lhotka@nic.cz>
X-Original-To: yang-doctors@ietf.org
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EEA1299B9; Mon, 20 Feb 2017 03:49:56 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ladislav Lhotka <lhotka@nic.cz>
To: yang-doctors@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148759139687.25976.6374643432126541498.idtracker@ietfa.amsl.com>
Date: Mon, 20 Feb 2017 03:49:56 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/6U_YGi5c7U2JqxjEwvhKGdiS6wU>
Cc: draft-ietf-rtgwg-yang-key-chain.all@ietf.org, ietf@ietf.org, rtgwg@ietf.org
Subject: [yang-doctors] Review of draft-ietf-rtgwg-yang-key-chain-13
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.17
List-Id: email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2017 11:49:57 -0000
Reviewer: Ladislav Lhotka Review result: Almost Ready # General Comments ## Cryptographic algorithm types What is the reason for representing these as a YANG choice with empty leaves? I think it would be more natural to use a single leaf, either an enumeration or (if extensibility is important) identityref. ## Reusability The module defines key-chain as a grouping with the aim of making it reusable in other modules. However, this approach has known problems that are discussed in draft-ietf-netmod-schema-mount. I am not sure how relevant they are in this case but, for one, the "key-chain-ref" type is not applicable if the "key-chain" grouping is used in another module. An alternative is not to use the grouping and rely on schema mount. ## Key string style The difference between ASCII and hexadecimal formats of key strings should be explained. I understand that the latter is a hash of the key and, if so, I'd suggest to include "hexadecimal-string" also in state data. Also, I believe that storing clear-text key in configuration is insecure and Security Considerations should warn against it. ## Example It might be useful to include an appendix with example instance data. # Specific comments ## Sec. 2 - paragraph 2: s/where ever/wherever/ ## Sec. 3 - paragraph 1: replace both Key-Id a Key-ID with Key ID (the latter is used in other places of the text). - paragraph 2: the suggested way of supporting asymmetric keys looks like a hack, I would suggest a more explicit representation, e.g. using a choice. ## Sec. 4 - The module has inconsistent indentation: up to "grouping crypto-algorithm-types", top-level statements are indented with four spaces, the subsequent ones with five spaces. ## Sec. 6 - The statement "Given that the key chains themselves are sensitive data, it is RECOMMENDED that the NETCONF communication channel be encrypted." is misleading because RFC 6241 requires that transport protocols for NETCONF guarantee confidentiality (and RFC 8040 does the same for RESTCONF).
- [yang-doctors] Review of draft-ietf-rtgwg-yang-ke… Ladislav Lhotka
- Re: [yang-doctors] Review of draft-ietf-rtgwg-yan… Ladislav Lhotka
- Re: [yang-doctors] Review of draft-ietf-rtgwg-yan… Acee Lindem (acee)
- Re: [yang-doctors] Review of draft-ietf-rtgwg-yan… Ladislav Lhotka