Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-crypto-types-18

Kent Watsen <kent+ietf@watsen.net> Mon, 19 April 2021 23:34 UTC

Return-Path: <01000178ec7bfedf-5b8a2940-2fdd-42f5-ae43-27277d991769-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 AD4F63A4958; Mon, 19 Apr 2021 16:34:18 -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 qJWEwNQg4DaP; Mon, 19 Apr 2021 16:34:14 -0700 (PDT)
Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24AA3A4956; Mon, 19 Apr 2021 16:34:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618875252; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=pyc1GRNP7ZmFNO1wPgqEA6opmhvzNnnKO6FDhPQ/X4s=; b=LTe12lzuZQMh/0cm0lvVJ+kbohPwCa2gPZOnj1kDJWaFqgkAgwTJzlMCvQknQk+X Zv5EmuyOmcry77i2quUlY7T2jVEN+G2GUBOsqaOw4UrINm4fte7sSAt9i9FlFrs6bXh /4Ji3K+91WlbY9G9+jLojns+TysKxPCRM0h3Xs7w=
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: <20210416115004.fqhitq6jofc6vjih@anna.jacobs.jacobs-university.de>
Date: Mon, 19 Apr 2021 23:34:12 +0000
Cc: "netconf@ietf.org" <netconf@ietf.org>, YANG Doctors <yang-doctors@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000178ec7bfedf-5b8a2940-2fdd-42f5-ae43-27277d991769-000000@email.amazonses.com>
References: <161045360252.14510.16755799701987783827@ietfa.amsl.com> <010001778e67638b-53d8c33f-82f6-4bda-881a-3cf881c06c95-000000@email.amazonses.com> <20210416115004.fqhitq6jofc6vjih@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.19-54.240.48.95
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/sdf01Vgnmpt8AnaFAw0WlEWq5rI>
Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-crypto-types-18
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: Mon, 19 Apr 2021 23:34:19 -0000

Hi Juergen,

Whittling out things resolved...

K.

> 
>> - Does it make sense to have a new notation like
>>> 
>>>     |  The diagram above uses syntax that is similar to but not
>>>     |  defined in [RFC8340].
>>> 
>>> or shall this simply become regular text?
>> 
>> I find using tree-diagram like notation for features, identities, and typedefs helpful, especially in showing the “if-feature” constraints and hierarchical relationships between items.  I recommend adding these enhancements to RFC 8340.  It would be helpful if someone could whip up an I-D so these documents could reference the I-D instead of having the "The diagram above uses syntax that is similar to but not defined in [RFC8340]” language.
>> 
>> That said, I also used a "rfc8340-like" diagram to list all the groupings in a module.  It seems like the consistent thing to do, but I can’t imagine the RFC 8340 being updated to support that output, so I replaced that diagram, with a normal "xml2rfc" list, in the entire suite of drafts.
> 
> I am sorry, I should have been clearer. My comment did not concern the
> diagrams but the mere fact that you have
> 
>      |  The diagram above uses syntax that is similar to but not
>      |  defined in [RFC8340].
> 
> instead of simply
> 
>   The diagram above uses syntax that is similar to but not
>   defined in [RFC8340].
> 
> and this is really an editorial nit if at all. The diagram itself I
> like, it would be nice to have them in RFC 8340bis.

Ah, now I understand, you mean to remove the XML2RFC v3 “aside”?  I agree that it renders poorly in plain-text, but it renders inside a pretty-box for HTML and PDF.  Thoughts?

Yes, the diagrams would be a nice addition to an 8340bis.  Also, I don’t know if you noticed, but the “Data Model Overview” section I created in all these drafts is highly mechanical…something that could be mostly automated…perhaps a good student project?  ;)


>>> - I wonder why this is a SHOULD and not a MUST:
>>> 
>>>          "Identifies the symmetric key's format.  Implementations
>>>           SHOULD ensure that the incoming symmetric key value is
>>>           encoded in the specified format.";
>>> 
>>> This statement shows up several times when the key-format identities
>>> are used. I wonder what this means to an implementer. If I receive a
>>> key format (say one-symmetric-key-format) and a corresponding blob
>>> of data, do I have to decode this to see whether the format works
>>> out? If later the key-format is changed to something else (lets say
>>> octet-string-key-format), do I reject such a change or is it OK as
>>> long as the binary data I have would be a valid value given the new
>>> format? Perhaps this is implementation specific? Well, since we deal
>>> with keys, ...
>> 
>> It currently a "SHOULD” because some implementations may assume that clients always configure perfect values, and so it becomes squishy as to if they MUST.   If a server fails to validate the base64 contents (which are outside YANG validation) as they’re being applied, then the server may run into nasty exceptions when needing to use the value at runtime.  A nice system will decode the base64 values and verify that they contain valid values during the commit process.
>> 
>> Make sense?  - leave as SHOULD okay?
> 
> Thanks for the explanation. I am not religious about SHOULD vs MUST
> here.

I’ll leave as a SHOULD then.



> I have browsed through the diffs and they look good. I did not do
> another full review again.

Thanks and Ack.

K.