[yang-doctors] Yangdoctors early review of draft-ietf-teas-yang-rsvp-te-07
Ebben Aries via Datatracker <email@example.com> Tue, 14 January 2020 03:49 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C499D12001B; Mon, 13 Jan 2020 19:49:11 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: Ebben Aries via Datatracker <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org
Reply-To: Ebben Aries <email@example.com>
Date: Mon, 13 Jan 2020 19:49:11 -0800
Subject: [yang-doctors] Yangdoctors early review of draft-ietf-teas-yang-rsvp-te-07
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2020 03:49:12 -0000
Reviewer: Ebben Aries Review result: On the Right Track First, I'd like to apologize for the delay in getting this review out. Overall, the draft/modules are in fairly good shape but have some comments/clarifications below. 2 modules in this draft: - firstname.lastname@example.org - email@example.com YANG compiler errors or warnings (pyang 2.1.1, yanglint 1.5.5, confdc 7.2.1) - ietf-rsvp-te: Line 262 - when statement should have a description substatement per RFC6087, Section 4.12 - ietf-rsvp-te-mpls: Line 121 - when statement should have a description substatement per RFC6087, Section 4.12 Module firstname.lastname@example.org: - Remove WG Chairs from contact information per https://tools.ietf.org/html/rfc8407#appendix-B - There are 2 augments to rsvp-te-interface-attributes of an empty state container. What are the intentions behind this and is it meant for future proofing other modules? Module email@example.com: - Remove WG Chairs from contact information per https://tools.ietf.org/html/rfc8407#appendix-B - The leaf 'percent-value'. What is the intention of specifying a range here that covers the entire uint32 space? General comments on the draft/modules: - Consistent use of 'units' statement for various data nodes (soft-preemption-timeout is one such example) - When 'units' is in use, rather than define it as "Bytes per second", I suggest replacing w/ the common usage of "bps" - Various leaf descriptions have "XX" placeholders that need updating - In the IANA considerations, this appears possibly cut/pasted from another module set and needs to be corrected to reflect the actual 2 modules contained within this draft. - It seems these modules are agnostic of IPv4/IPv6 transport yet existing implementations are going to be geared towards IPv4. What if any considerations need to be called out or adjusted here as an implementation would either need to resolve this via deviations or backend validations. - Lack of defined RPCs. For all the cases around RSVP signalled LSPs, is there an intention to add relevant RPCs in this draft? (Same w/ notifications) - Am I missing any generic per-LSP counters defined throughout these models? - Are there any uses where features/if-feature could be used throughout these modules?
- [yang-doctors] Yangdoctors early review of draft-… Ebben Aries via Datatracker