[Teas] Yangdoctors early review of draft-ietf-teas-yang-sr-te-topo-04

Ladislav Lhotka via Datatracker <noreply@ietf.org> Mon, 10 June 2019 13:02 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C3112018F; Mon, 10 Jun 2019 06:02:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ladislav Lhotka via Datatracker <noreply@ietf.org>
To: <yang-doctors@ietf.org>
Cc: draft-ietf-teas-yang-sr-te-topo.all@ietf.org, ietf@ietf.org, teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.97.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <156017177005.10755.7672289550345761824@ietfa.amsl.com>
Date: Mon, 10 Jun 2019 06:02:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Ov0I7RLREPvq49iE2A52IyNfvCU>
Subject: [Teas] Yangdoctors early review of draft-ietf-teas-yang-sr-te-topo-04
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2019 13:02:50 -0000

Reviewer: Ladislav Lhotka
Review result: Ready with Issues

This document and YANG module "ietf-sr-topology" contained therein
contribute two new types to the family of network topology data
models: segment routing and segment routing traffic engineering
topologies. The document also provides a companion module
"ietf-sr-topology-state" intended for non-NMDA implementations.

>From the YANG point of view, both modules are in a relatively good
shape. Also, as far as I can tell, they satisfy the requirements
specified in RFC 8345.

The example instance data contained in Appendix B successfully passes
formal validation against the date model, which is far from
commonplace for early versions of documents. See however comment #1
below.

**** Comments

1. I have argued several times that using URIs as identifiers of all
   network topology objects in RFC 8345 is an overkill. Now, the
   present draft demonstrates the consequences: id values used in
   many places of the example data (Appendix B) are not valid URIs!
   For example, "link-id" leaves have values like
   "D1,1-2-1,D2,2-1-1", which is not a URI.

   This type violation isn't caught by validating tools because the
   "ietf-inet-types:uri" type doesn't specify a regular expession
   pattern. However, its description states clearly that the type
   represents URI as defined by STD 66.

2. The module uses (indirectly) the grouping "srlr" from the
   "ietf-segment-routing-common" module. This grouping defines two
   leaves, "lower-bound" and "upper-bound". I assume it is expected
   that the former must not be greater than the latter. This is
   however not enforced by the data model. My suggestion is to add a
   "must" statement to the "srlr" grouping corresponding to this
   constraint.

3. Typos in the module text:

   - description of grouping "sr-topology-type":
     s/toplogies/topologies/

   - description of container "sr-mpls":
     s/Indiates/Indicates/