Re: [OPSAWG] Yangdoctors last call review of draft-ietf-opsawg-mud-tls-10

tirumal reddy <kondtir@gmail.com> Mon, 12 December 2022 08:00 UTC

Return-Path: <kondtir@gmail.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9079CC14CE3D; Mon, 12 Dec 2022 00:00:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PC7SnhAS8h2; Mon, 12 Dec 2022 00:00:22 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A723C14F743; Mon, 12 Dec 2022 00:00:19 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id g7so17216896lfv.5; Mon, 12 Dec 2022 00:00:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZoiT05AAd6gOFfESaqAYSbqi895EwjZQHmAZLC+JBqg=; b=CysBIrQE0GVzHnOMM9jqcXLznrBomvf5k1eAbzDi2HawSzKxbZjOPMKzCdDX922Mu7 ShgGFOQxV+1vFucwjhg9FlKLOrwAT6W4QUEB/mVnjgbF2lpi+dogff+rRQNqkkmetNTK OROgLUuDmsGuTC4/THrP88o6NnOLYQE7ICrgNSYs52THoJJ30OArMf36N3j+x8HcHRRp hZOC+hYy00mnjADJ2NRFI/Kthd4oAMpOaWXmxGyx2badrJlsuvxrtVHO5Nfyb1H9bKDE z3b5e0rftXnuC8bG53cNpP0oZtmpy6jC+lmliZbVzq6wVB6sjRJq8hSH5cAQTXl4Aqaz d18Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZoiT05AAd6gOFfESaqAYSbqi895EwjZQHmAZLC+JBqg=; b=69jYuuhHbCLID3XXFDiKebcKDck7q12k8OpPLwPkql5Y4A3bFchk3rGrpH4xSs42eV kUEw7B53NFYSsO3hZGXyR+KMOX7NMIP9kCUMadscwiWt09HcZ9WjBB8+i1rj/4i9myT8 fXKJMtTb2zONargpTWSwNP/oPQk7ggXOnasffmbl3TBE2MgliykRC7EIX45bSGf4JIYI RsdZzbOoJokqhki/QL0qf/8Bh3omvD4yNDtq2bzUKqOkTGxOIFYud5Rzd53BnbpgmrZN AaRd/9HH9KWja+aY/yJuJMnBJRUAOrxajDkF0MRxdL2hBG/Unk6bt36rhsH+jL6QGFNM hkhQ==
X-Gm-Message-State: ANoB5pl10DBDYueobkMHy8zsYmcNrR5NQUXMbNxNlA57FZFj845E144J REEnYFyGIGDdAdjv+zn0DNwcjr4Inn2qSvyAfXw=
X-Google-Smtp-Source: AA0mqf62bqPd0BkRNooDkg4LvJo7TKae2HaVUMCJFt6J4cadMmAhhgpu9RztuAElsvRUhAq118d6f7beA3LEm5updpI=
X-Received: by 2002:a05:6512:398c:b0:4b6:eb5a:66a4 with SMTP id j12-20020a056512398c00b004b6eb5a66a4mr283184lfu.482.1670832016384; Mon, 12 Dec 2022 00:00:16 -0800 (PST)
MIME-Version: 1.0
References: <167063197456.29432.6912041180293949341@ietfa.amsl.com>
In-Reply-To: <167063197456.29432.6912041180293949341@ietfa.amsl.com>
From: tirumal reddy <kondtir@gmail.com>
Date: Mon, 12 Dec 2022 13:30:05 +0530
Message-ID: <CAFpG3gcZXd+CNCo2sokWxC7LyGa-d4SOAsOi_gXah4ohnnV_qw@mail.gmail.com>
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Cc: yang-doctors@ietf.org, draft-ietf-opsawg-mud-tls.all@ietf.org, last-call@ietf.org, opsawg@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d0e64305ef9ce408"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/zD_R5I9mv45wVo_DC3Vcjjiffmg>
Subject: Re: [OPSAWG] Yangdoctors last call review of draft-ietf-opsawg-mud-tls-10
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2022 08:00:26 -0000

Thanks Xufeng for the detailed review. Please see inline

On Sat, 10 Dec 2022 at 05:56, Xufeng Liu via Datatracker <noreply@ietf.org>
wrote:

> Reviewer: Xufeng Liu
> Review result: Ready with Issues
>
> This is a review of the YANG module in draft-ietf-opsawg-mud-tls-10.
>
> Sec 5.1. and 5.2
>
> 1) The container “client-profile” is duplicated twice. Is there any reason
> for
> the duplication?
>

It was added by mistake, I will remove the duplication.


>
> 2) As a convention, in IETF YANG modules, the node name of a list is in the
> singular form. Above the list there can be a container with a name in the
> plural form. For example, in RFC8519, there are a container “acls” and a
> list
> “acl”. Using such a convention, the container “client-profile” would be
> better
> named as “client-profiles”, and the list “tls-dtls-profiles” would be
> better
> named as “tls-dtls-profile”. The same is applicable to other list names,
> such
> as “tls-dtls-profiles”, “cipher-suites”, “extension-types”,  and
> “signature-algorithms-cert”.
>

Thanks, I wil fix the above names accordingly.


>
> 3) The leaf-list “acceptlist-ta-certs” can be better named as
> “accept-list-ta-certs” per RFC8407.
>

Sure.


>
> 4) Default values should be specified or explained for optional leaves like
> “spki-hash-algorithm”.
>

Okay.


>
> 5) The leaf “profile-name” is suggested to be renamed to “name”. As
> described
> in Sec 4.3.1. of RFC8407, child nodes within a container or list SHOULD NOT
> replicate the parent identifier.
>

Done.


>
> Sec. 5.3. IANA (D)TLS profile YANG Module
>
> 1) This section indicates that there are no IANA-maintained values for
> spki-pin-set, and certificate-authority parameters. If so, what are the
> reasons
> to include these two types in this IANA YANG module? What do we expect
> IANA to
> maintain and update?
>

I see your point, I will remove these types from the IANA YANG module.


>
> Sec. 5.4. MUD (D)TLS Profile Extension
>
> 1) The file name of the YANG module is wrong. It seems to be a typo.
>

Yes, fixed.


>
> 2) The statement “import ietf-mud” needs to have a “reference”
> sub-statement.
>

Added.


>
> 3) The leaf “is-tls-dtls-profile-supported” should have a default value or
> a
> description of the default behavior.
>

Okay.


>
> Sec 7.
>
> 1) In the example, the leaf “profile-name” is needed as it is the key of
> the
> list.
>

Yes.


>
> Sec 10.1.
>
> 1) For iana module, iana-tls-profile, instead of “Registrant Contact:
> IESG”, we
> should have Registrant Contact: IANA
>

Fixed.


>
> [Nit]:
>
> 1) The following code contains a line longer than 69 characters:
>             leaf hash {
>               type ianatp:hash-algorithm;
>               description
>                 "Hash algorithm used with HKDF as defined in RFC5869.";
>             }
>

Done.

Cheers,
-Tiru


>
> Thanks,
> - Xufeng
>
>
>
>