[OPSAWG] Yangdoctors last call review of draft-ietf-opsawg-l2nm-07

Ladislav Lhotka via Datatracker <noreply@ietf.org> Tue, 05 October 2021 08:03 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42ABF3A088C; Tue, 5 Oct 2021 01:03:58 -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-opsawg-l2nm.all@ietf.org, last-call@ietf.org, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.38.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <163342103815.25660.17600005180075521549@ietfa.amsl.com>
Reply-To: Ladislav Lhotka <ladislav.lhotka@nic.cz>
Date: Tue, 05 Oct 2021 01:03:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/yUZexW2PI3a2BwtDdUdqLtCH-f8>
Subject: [OPSAWG] Yangdoctors last call review of draft-ietf-opsawg-l2nm-07
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Oct 2021 08:03:59 -0000

Reviewer: Ladislav Lhotka
Review result: Ready with Issues

**** General comments

The ietf-l2vpn-ntw module with about 400 data nodes represents an impressive
amount of work. Its size, however, raises some concerns in terms of
manageability. For example, if the ITU-T Y-1731 recommendation ever gets
updated (I don't know how likely this is), the module will have to be updated.
I would therefore suggest to consider factoring out such parts into separate
modules.

Apart from that, the YANG modules are in a good shape.

**** Specific comments

***** Instance data examples

The appendices A.1--A.6 contain examples of instance data for six different use
cases. This would be laudable, but only if the examples were valid according to
the data model schema. It seems that the examples were not updated during the
data model development. It is necessary to validate the examples using the
available tools such as yanglint or Yangson, and correct all errors. Here is a
non-exhaustive list of problems in the example of appendix A.1: - The top-level
container "ietf-l2vpn-ntw:l2vpn-ntw" is missing, which complicates the use of
validation tools. - "vpn-service" list contains "vpn-description" leaf, not
"description". - "global-parameters-profile" list contains "svc-mtu" leaf, not
"mtu". - The value of "global-parameters-profile/rd-suffix" should be uint16,
not string (e.g. 1 rather than "1"). Similarly, "vpn-target/id" is uint8, not
string. - Container "vpn-targets" encapsulating "vpn-target" list doesn't exist
in the schema. - "vpn-target/route-targets" is defined as a list, but its
instance value is given as ["0:65550:1"] (it probably used to be a leaf-list).
- Inside "vpn-service" list, the schema defines "vpn-nodes" container
encapsulating "vpn-node" list. This container is missing in the example.

***** RFC 8792 line folding

My reading of sec. 7.1.1 in RFC 8792 is that each text chunk that uses the
single backslash strategy should be preceded with the header

NOTE: '\' line wrapping per RFC 8792

**** Nits

- The naming of groupings is inconsistent: "cfm-802-grouping" versus e.g.
"y-1731". I'd suggest to remove the "-grouping" suffix in the former.