[netmod] Yangdoctors last call review of draft-ietf-netmod-rfc8407bis-11

Xufeng Liu via Datatracker <noreply@ietf.org> Tue, 18 June 2024 03:33 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DECC09E1C1; Mon, 17 Jun 2024 20:33:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Xufeng Liu via Datatracker <noreply@ietf.org>
To: yang-doctors@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.15.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171868159806.800.9211559974125341765@ietfa.amsl.com>
Date: Mon, 17 Jun 2024 20:33:18 -0700
Message-ID-Hash: XXVUDKISCSITNC6CF6ZUEUK5DFSGHGWR
X-Message-ID-Hash: XXVUDKISCSITNC6CF6ZUEUK5DFSGHGWR
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-netmod-rfc8407bis.all@ietf.org, last-call@ietf.org, netmod@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Subject: [netmod] Yangdoctors last call review of draft-ietf-netmod-rfc8407bis-11
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Lto49pXDCpKdUdR-ISUrRFVWhBw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>

Reviewer: Xufeng Liu
Review result: Ready with Nits

3.2. Code Components
The “file name” after the "<CODE BEGINS>" tag is something described as
“SHOULD” be included. If there is no such a “file name”, the tool “rfcstrip”
will not extract the correct file. Should we consider making this “file name” a
“MUST”?

3.5.1. YANG Module Classification
In the section “Network model”, the term "Network model” is described as
“relevant protocols operating at the link and network layers”. Can a network
model be designed for other layers, such as OTN or MPLS? If so, such a
description seems to be too narrow.  RFC 8309 clarifies the “Service Model”,
which is the section before this one. Is there a definition of the “network
model” in RFC 8309?

3.8. IANA Considerations Section
The “YANG Module Names” registry is defined in RFC 6020, but not RFC 7950. Many
YANG module writers mistakenly used RFC 7950. Should we consider bringing this
up with special attention?

4.5. Conditional Statements
An example not preferred is given, but there is no preferred fix. Would it be
better to provide the proffered solution?