[yang-doctors] Yangdoctors early review of draft-ietf-mpls-msd-yang-02

Jan Lindblad via Datatracker <noreply@ietf.org> Tue, 19 December 2023 15:52 UTC

Return-Path: <noreply@ietf.org>
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 BDC02C0900A9; Tue, 19 Dec 2023 07:52:09 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Jan Lindblad via Datatracker <noreply@ietf.org>
To: yang-doctors@ietf.org
Cc: draft-ietf-mpls-msd-yang.all@ietf.org, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <170300112976.56537.3631529033903574839@ietfa.amsl.com>
Reply-To: Jan Lindblad <janl@tail-f.com>
Date: Tue, 19 Dec 2023 07:52:09 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/PUx5grv1ch3L93cBmwKS_iFB3_w>
Subject: [yang-doctors] Yangdoctors early review of draft-ietf-mpls-msd-yang-02
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 19 Dec 2023 15:52:09 -0000

Reviewer: Jan Lindblad
Review result: Ready with Issues

Hi all,

This is my YANG-Doctor Last-Call review of draft-ietf-mpls-msd-yang-02. This
draft contains two small and focused modules. They seem to be in pretty good
shape, but I do have a couple of issues and nits to discuss.

Issue #1: Keyless list

The list node-msds is keyless. This is legal for config false lists, but that
something is legal does not necessarily make it a good idea. Is there a strong
reason for not having a key here? Keyless lists are less efficient, as all
clients will have to read the entire list every time. Unless there is a strong
reason not to, I would suggest adding a key here.

Maybe the msd-type could function as a key for this list, or will there ever be
multiple msd entries of the same msd type? Multiple entries of the same
msd-type are currently allowed, but I'm not sure what the interpretation of
such a server response should be.

         list node-msds {
           leaf msd-type { ... }
           leaf msd-value { ... }
         }

Issue #2: Optional values

Both msd-type and msd-value are modeled as optional. They have no default and
there is no description text explaining what it means if either of them is
missing. Maybe they should be made mandatory, as I expect the list entry is
pretty uninformative unless both are present?

Nit #3: Repetition

The msd-type and msd-value leaf definitions are repeated twice in the module
(except for a one letter difference in one description that probably is not
intentional). I would suggest placing them in a grouping that is referenced in
each list to avoid the repetition.

           leaf msd-type {
             type identityref {
               base iana-msd-types:msd-base-mpls;
             }
             description
               "MSD type";
           }
           leaf msd-value {
             type uint8;
             description
               "MSD value, in the range of 0-255.";
           }

Nit #4: Indentation

The indentation is a bit off. I'd suggest running the module through a pretty
printer, like pyang -f yang.

Nit #5: Typo in reference

The revision statement reference has some typos.

     revision 2023-10-22 {
       description
         "Initial Version";
       reference
         "RFC XXXX: YA YANG Data Model for MPLS MSD..";
     }

Nit #6: Read only data and get-config

In section 5, security considerations, there is a paragraph:

   Some of the readable data nodes in the modules may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.

Since the data in these modules is read-only, it will never show up in
get-config, so listing that operation may be somewhat superfluous.

Best Regards,
/jan