[yang-doctors] Yangdoctors last call review of draft-ietf-ospf-sr-yang-28
Reshad Rahman via Datatracker <noreply@ietf.org> Sat, 13 January 2024 20:30 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 466AEC14F6FF; Sat, 13 Jan 2024 12:30:55 -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-ospf-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: <170517785527.58459.14481518553879372449@ietfa.amsl.com>
Reply-To: Reshad Rahman <reshad@yahoo.com>
Date: Sat, 13 Jan 2024 12:30:55 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/sKKd2TPvgDzpS4-8lNHS-zucTuU>
Subject: [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-sr-yang-28
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: Sat, 13 Jan 2024 20:30:55 -0000
Reviewer: Reshad Rahman Review result: Ready with Issues Hi all, This is my YANG Doctor review of -28, I had previously reviewed -20. Thanks to the authors for addressing my previous comments. There is 1 comment in my initial review which concerns RFC9020, I am not convinced yet and may send another email (or errata). Comments ======== Should the title explicitly call out OSPFv2 and OSPFv3? The reason I’m asking is because OSPF may imply v2 only, e.g. RFC8665 says “OSPF Extensions for Segment Routing” but then the abstract says OSPFv2. Section 2. “OSPF base model[RFC9129]”, nit: add a space before the reference In the following, can there be overlaps? If not, this should be documented (ideally should have been documented in RFC9020) +--rw srgb | +--rw srgb* [lower-bound upper-bound] | +--rw lower-bound uint32 | +--rw upper-bound uint32 Section 2.1 (the YANG module) - In grouping ospfv2-prefix-sid-sub-tlvs, leaf-list flags should have a reference? Same for v3. - The grouping ospfv2-extended-prefix-range-tlvs has an ‘af’ address family leaf which is a uint8, why not use address-family from RFC8294 with the appropriate restrictions. But since this is OSPFv2 specific, is address family still needed? For v3, I believe the af leaf is needed, although I’d rename it to address-family and would use address-family enum from RFC8294. - The grouping ospfv2-extended-prefix-range-tlvs: should there be a range for prefix-length? Same question, but but different range needed, for OSPFv3. - In list local-block-tlv, description of leaf range-size has “…The return of a zero value”. Nit: change to “A value of zero…” - In container srms-preference-tlv, leaf preference. Nit: “with with 255”. - Should leaf neighbor-id be mandatory? If not, what happens when it’s not set, does it need a default value? I believe the description needs to indicate what happens when it is set or not set. - In ti-lfa container: the enable flag is not mandatory and does not have a default value, you should add a default value or make it mandatory. Other choice is a presence container. - In the selection-tie-breakers container, can both tie-breakers be enabled simultaneously? - For leaf use-segment-routing-path, the description has “…is in effect only when remote-lfa is enabled”. I did not see any remote-lfa leaf node, not sure if this is referring to a feature. I think the description needs to be modified and a reference would be very helpful here. Appendix A. There is only 1 (simple) example and it covers v2 only. Please add a v3 example also, ideally with more config data than the current example e.g. with the neighbor-id (since that augment is in this document). Having an operational state example for OSPFv2 and OSPFv3 would also really be helpful. I realize examples can be painful... Regards, Reshad.
- [yang-doctors] Yangdoctors last call review of dr… Reshad Rahman via Datatracker
- Re: [yang-doctors] Yangdoctors last call review o… Acee Lindem
- Re: [yang-doctors] Yangdoctors last call review o… Reshad Rahman