[yang-doctors] Re: Yangdoctors early review of draft-ietf-bfd-optimizing-authentication-18

"maqiufang (A)" <maqiufang1@huawei.com> Mon, 23 September 2024 08:05 UTC

Return-Path: <maqiufang1@huawei.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB26C1CAF32; Mon, 23 Sep 2024 01:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 Tqn8o4pEhtog; Mon, 23 Sep 2024 01:05:04 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC99C14CF09; Mon, 23 Sep 2024 01:05:03 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XBwQj59XKz6K9LJ; Mon, 23 Sep 2024 16:00:29 +0800 (CST)
Received: from lhrpeml100002.china.huawei.com (unknown [7.191.160.241]) by mail.maildlp.com (Postfix) with ESMTPS id 84370140452; Mon, 23 Sep 2024 16:05:00 +0800 (CST)
Received: from kwepemm600018.china.huawei.com (7.193.23.140) by lhrpeml100002.china.huawei.com (7.191.160.241) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 23 Sep 2024 09:04:59 +0100
Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemm600018.china.huawei.com (7.193.23.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 23 Sep 2024 16:04:58 +0800
Received: from kwepemm600017.china.huawei.com ([7.193.23.234]) by kwepemm600017.china.huawei.com ([7.193.23.234]) with mapi id 15.01.2507.039; Mon, 23 Sep 2024 16:04:58 +0800
From: "maqiufang (A)" <maqiufang1@huawei.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Thread-Topic: Yangdoctors early review of draft-ietf-bfd-optimizing-authentication-18
Thread-Index: AQHbDIHQnVDyeDXM7EK9N1lAhm9aSLJk+KZw
Date: Mon, 23 Sep 2024 08:04:58 +0000
Message-ID: <94c5fd847a2d410093558243aebdb1d4@huawei.com>
References: <172258141852.225.6083275970110603688@dt-datatracker-6dd76c4557-2mkrj> <A9096D23-B3CB-40FD-8C9E-4F779B89F1D5@gmail.com>
In-Reply-To: <A9096D23-B3CB-40FD-8C9E-4F779B89F1D5@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.118.147]
Content-Type: multipart/alternative; boundary="_000_94c5fd847a2d410093558243aebdb1d4huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: JJLCMMU4LXDOCWVRGY3D4DBIQAAKXY33
X-Message-ID-Hash: JJLCMMU4LXDOCWVRGY3D4DBIQAAKXY33
X-MailFrom: maqiufang1@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-yang-doctors.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: YANG Doctors <yang-doctors@ietf.org>, "draft-ietf-bfd-optimizing-authentication.all@ietf.org" <draft-ietf-bfd-optimizing-authentication.all@ietf.org>, "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [yang-doctors] Re: Yangdoctors early review of draft-ietf-bfd-optimizing-authentication-18
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/Cx9T1IUdP6gqdZW_Y8oCzBprkFc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Owner: <mailto:yang-doctors-owner@ietf.org>
List-Post: <mailto:yang-doctors@ietf.org>
List-Subscribe: <mailto:yang-doctors-join@ietf.org>
List-Unsubscribe: <mailto:yang-doctors-leave@ietf.org>

Hi, Mahesh,

Thank you for addressing my comments. It appears that the PR link you provided below is not accessible to me. Please feel free to submit a new revision when you believe it is ready and I will review then. Please also see some of my responses below. Thanks.


Best Regards,
Qiufang
From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]
Sent: Sunday, September 22, 2024 7:56 AM
To: maqiufang (A) <maqiufang1@huawei.com>
Cc: YANG Doctors <yang-doctors@ietf.org>; draft-ietf-bfd-optimizing-authentication.all@ietf.org; rtg-bfd@ietf. org <rtg-bfd@ietf.org>
Subject: Re: Yangdoctors early review of draft-ietf-bfd-optimizing-authentication-18

Hi Qiufang,

Thanks for your thorough review. Here are some comments. The changes are being tracked as part of the PR  here<https://github.com/bfd-wg/optimized-auth/pull/50>.


On Aug 1, 2024, at 11:50 PM, Qiufang Ma via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:

Reviewer: Qiufang Ma
Review result: Ready with Nits

Hi, this is my YANG Doctor review of draft-ietf-bfd-optimizing-authentication,
the requested revision is 16, but it is currently at version 18, so my review
is based on the latest.

This draft defines a YANG module which augments the base BFD YANG model in RFC
9314, and also has an IANA-maintained module in Appendix which updates the
initial one in RFC 9127. Both YANG modules have been parsed by yanglint and
pyang, which didn’t generate any warnings and errors.

Some nits that need to be fixed:
1.      Sec.5.1 states “Finally, it adds a flag to enable optimized
authentication, an interval value that specifies how often the BFD session
should be re-authenticated once it is in the Up state, and the key chain that
should be used in the Up state.” But I think the YANG module only defines the
reauth-interval, which is inconsistent with the narrative description.

Fixed.



2.      The YANG module in sec.5.3 imports a set of modules from RFC 9314, but
the reference statement to RFC 9314 should be: OLD:
   reference
     "RFC 9314: YANG Data Model for Bidirectional
      Forwarding Detection.";
NEW:
   reference
     "RFC 9314: YANG Data Model for Bidirectional
      Forwarding Detection (BFD)”;

Fixed.



3.      The YANG module in sec.5.3, reference statement to RFC 8177 should be:
OLD:
   reference
     "RFC 8177: YANG Key Chain.";
NEW:
   reference
     " RFC 8177: YANG Data Model for Key Chains";

Fixed.



4.      The YANG module in sec.5.3, please update the reference for identity
definitions optimized-md5-meticulous-keyed-isaac and
optimized-sha1-meticulous-keyed-isaac as follows: OLD:
   reference
     "I-D.ietf-bfd-optimizing-authentication:
        Meticulous Keyed ISAAC for BFD Authentication.
      I-D.ietf-bfd-secure-sequence-numbers:
        Meticulous Keyed ISAAC for BFD Authentication.";
NEW:
    reference
       "RFC XXXX: Optimizing BFD Authentication
        RFC YYYY: Meticulous Keyed ISAAC for BFD Authentication";
And also add a note to RFC editor that YYYY is the number assigned to
I-D.ietf-bfd-secure-sequence-numbers at the time of publication.

I agree with the change for draft-ietf-bfd-optimizing authentication, but the other draft is a separate draft (even though it is part of the same cluster of documents). I would therefore keep the reference as is.
While personally I prefer the suggested approach for a cluster of documents, I’ll leave this to you to decide.


5.      The YANG module in sec.5.3, the description for all the augment
substatements are identical, distinction should be made here between the
descriptions of different modules being augmented.

Fixed.



6.      Sec.6.4 requests an update to the IANA-maintained YANG module
“iana-bfd-types.yang”, maybe it should also mention the revision of this YANG
module is to mirror the update to the registry “BFD Authentication Types” as
requested in sec.6.1.

I am not sure. The IANA maintained YANG module in Appendix already carries the updates the registry “BFD Authentication Types”. Also, the “Note to RFC Editor” in Section 2.1, already carries instructions on how to update the revision of the YANG module.
What I am suggesting is to be consistent with what is defined in sec.5.1 of RFC 9127. Feel free to accept or reject.


7.      Appendix A, the description:
OLD:
 This version of this YANG module is part of RFC 9127; see the
 RFC itself for full legal notices.
NEW:
 The initial version of this YANG module is part of RFC 9127; see the
 RFC itself for full legal notices.
 (and I think the reference below should be RFC XXXX instead of RFC 9127)

The initial version of the YANG module is the one in RFC 9127, so I would agree to add the word ‘initial’. The module in Appendix A is updating that module.



8.      Appendix A, the reference:
OLD:
   reference
     "I-D.ietf-bfd-optimizing-authentication:
          Optimizing BFD Authentication,
      I-D.ietf-bfd-stability: BFD Stability.";
NEW:
   reference
     "RFC XXXX: Optimizing BFD Authentication
      RFC ZZZZ: BFD Stability";
And also add a note to RFC editor that ZZZZ is the number assigned to
I-D.ietf-bfd-stability at the time of publication.

Agree to change the reference for the first item. For the second reference see response above.



9.      RFC 8340 should be informative reference rather than normative one.
See section 3.4 in
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/: “If YANG tree
diagrams are used, then an informative reference to the YANG tree diagrams
specification MUST be included in the document."

Done.