[yang-doctors] Yangdoctors last call review of draft-ietf-isis-sr-yang-19

Reshad Rahman via Datatracker <noreply@ietf.org> Sun, 14 January 2024 00:24 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 0B233C14F70B; Sat, 13 Jan 2024 16:24:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Reshad Rahman via Datatracker <noreply@ietf.org>
To: yang-doctors@ietf.org
Cc: draft-ietf-isis-sr-yang.all@ietf.org, last-call@ietf.org, lsr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <170519187203.2829.6087985821024655929@ietfa.amsl.com>
Reply-To: Reshad Rahman <reshad@yahoo.com>
Date: Sat, 13 Jan 2024 16:24:32 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/FWbc3qZD4R7aIE-zr3P0_xojr3U>
Subject: [yang-doctors] Yangdoctors last call review of draft-ietf-isis-sr-yang-19
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: Sun, 14 Jan 2024 00:24:32 -0000

Reviewer: Reshad Rahman
Review result: Ready with Issues

Hi all,

This is my YANG Doctor review of -19. Thanks to the authors for making the
effort to align with draft-ietf-ospf-yang (as previously requested).

Comments
========

Section 3 (YANG Tree)

- There are a few instances of perfix-sid-flags, should bd prefix-sid-flags

- For the list below, can there be overlaps between different entries? If not,
this should be documented (ideally should have been documented in RFC9020)

       +--rw protocol-srgb {sr-mpls:protocol-srgb}?
          +--rw srgb* [lower-bound upper-bound]
             +--rw lower-bound    uint32
             +--rw upper-bound    uint32

YANG Model

- The identities such as r-bit, n-bit etc should all have a reference (not just
the document but also the section)

- All those identities are called x-bit but the description says flag. Which
terminology is typically used in IS-IS?

- Leaf Sid, how do we know whether it’s a 32-bit SID or a 20-bit label (not
sure if we need to know)?

- For global-blocks and local-blocks, a reference would help.

- In grouping sid-sub-tlv, is the container sid-sub-tlv needed?

- In grouping srlb , can there be an overlap of the advertised local blocks?
Need some enhanced description here iMO.  Same question for sr-capability and
global blocks.

- In list global-block, why not add a key? I’m assuming the sid would be
unique? Same comment for local-block.

- In grouping srms-preference, leaf preference, no need for the range 0..255
since it is a uint8.

- Nit: a few instances of “This group …”, it should be “This grouping …”

- Leaf ‘af’, nit/suggestion: I would rename to address-family.

- In grouping segment-routing-binding-tlv, leaf range, is that description
accurate?

- Augment with neighbor-system-id, should the leaf node be mandatory?

- Container selection-tie-breakers, can both protection types be enabled
simultaneously?

There should be an appendix with a fairly complete config example and also an
operational state example.

Regards,
Reshad.