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

Jan Lindblad <janl@tail-f.com> Wed, 20 December 2023 17:23 UTC

Return-Path: <janl@tail-f.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 2A0A6C14CE2E; Wed, 20 Dec 2023 09:23:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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] 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 VdBUdZtqdidz; Wed, 20 Dec 2023 09:23:52 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 215FDC14F61C; Wed, 20 Dec 2023 09:23:51 -0800 (PST)
Received: from smtpclient.apple (unknown [64.103.40.21]) by mail.tail-f.com (Postfix) with ESMTPSA id 39B1E1AE02AB; Wed, 20 Dec 2023 18:23:50 +0100 (CET)
From: Jan Lindblad <janl@tail-f.com>
Message-Id: <01DCF5C3-2E5C-4AC2-B6D8-8386C82ADBF3@tail-f.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_93CE4B7E-C16A-4D42-9D24-C4B2A290BD9E"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Date: Wed, 20 Dec 2023 18:23:39 +0100
In-Reply-To: <CABY-gOMv7YZhAxqcRqZqo9rK5GvVhhKiXAup2=t_HunwPY+J=Q@mail.gmail.com>
Cc: YANG Doctors <yang-doctors@ietf.org>, draft-ietf-mpls-msd-yang.all@ietf.org, mpls@ietf.org
To: Yingzhen Qu <yingzhen.ietf@gmail.com>
References: <170300112976.56537.3631529033903574839@ietfa.amsl.com> <CABY-gOMdJvT10EHUkMKEvhveUekLt47cRVkaCKXRQxO+cxtYsQ@mail.gmail.com> <BCB7AB6A-C457-4DAC-B559-D623B07522F7@tail-f.com> <CABY-gOMv7YZhAxqcRqZqo9rK5GvVhhKiXAup2=t_HunwPY+J=Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/44yrUVb4WDHmLpH4pqccYKq9Y2Q>
Subject: Re: [yang-doctors] Yangdoctors early review of draft-ietf-mpls-msd-yang-02
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Wed, 20 Dec 2023 17:23:57 -0000

Yingzhen,

> Please see my questions below inline about the "mandatory" statement.

Certainly.

>>>> 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?
>>>  
>>> [Yingzhen]: It's meaningless if there is a msd-value without a msd-type. Theoretically
>>> they should always show up as a pair. These are read-only data, so I don't think any
>>> control is needed.
>> 
>> Since you confirm my understanding that both values are needed for an entry to make sense, I would actually suggest that you mark both as   mandatory true;   The mandatory concept is also useful for config false data. In this case it means the server MUST return these values for each entry. This will make it abundantly clear to all that every entry needs to have both. Users that are using this model can file a bug report to their vendors etc if they see something else, rather than a drawn out conversation about what is allowed in this list.
> 
> [Yingzhen]: although both the msd-type and msd-value are needed for an entry to make sense, it's possible for a router to not return any entry. My understanding of a leaf to be mandatory means the leaf has to exist with a value. Please correct me if I'm wrong.

No, not exactly. If you make msd-type and msd-value mandatory, that means that each entry (if any) in the list must have both. Which is, I believe, what everyone expects. So it would be nice to write this down in the model.

// I think you want:

  grouping msd-type-value {
    description
      "Grouping for MSD type and value.";
    leaf msd-type {
      mandatory true;
      type identityref {
        base iana-msd-types:msd-base-mpls;
      }
      description
        "MSD types. The MSD type is defined in IANA IGP
         MSD-Types registry.";
    }
    leaf msd-value {
      mandatory true;
      type uint8;
      description
        "MSD value, in the range of 0-255.";
    }
  }

If you don't have the mandatory true statements, it would, for example, be considered valid from a YANG perspective for an implementation to return all possible msd-type-values but leave some of them without an msd-value. If someone complained, the implementor could claim to implement RFC xxxx (this document). So if you mean that both msd-type and msd-value have to be returned for each entry in the list (if any), I think marking them mandatory is a good thing.

If you wanted to say something about how many entries there must be in the list, you would use min-elements and/or max-elements. E.g. you could say min-elements 1; on the list to require at least one entry. But this is not what you want in this case.

// I think you don't want:

      list node-msds {
        key "msd-type";
        uses msd-type-value;
        // To require at least one entry
        min-entries 1;
        description
          "List of different types of MSDs of the node. A type of
           Node MSD is the smallest same type link MSD supported by
           the node.";
      }


I hope this makes sense. Happy to clarify/discuss.

Best Regards,
/jan