[netmod] Yangdoctors last call review of draft-ietf-netmod-node-tags-04

Mahesh Jethanandani via Datatracker <noreply@ietf.org> Tue, 01 February 2022 05:24 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 734E03A1462; Mon, 31 Jan 2022 21:24:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mahesh Jethanandani via Datatracker <noreply@ietf.org>
To: yang-doctors@ietf.org
Cc: draft-ietf-netmod-node-tags.all@ietf.org, last-call@ietf.org, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164369307541.25061.16067998788319986829@ietfa.amsl.com>
Reply-To: Mahesh Jethanandani <mjethanandani@gmail.com>
Date: Mon, 31 Jan 2022 21:24:35 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/zOZ6_gZrXaNQW0e0GDW9oV-lHjw>
Subject: [netmod] Yangdoctors last call review of draft-ietf-netmod-node-tags-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2022 05:24:36 -0000

Reviewer: Mahesh Jethanandani
Review result: On the Right Track

Summary:

This document defines a method to tag data objects associated with operation
and management data in YANG Modules.  This YANG data object tagging method can
be used to classify data objects from different YANG modules and identify
characteristics data.

Nits

/subobjects/sub-objects/g

Comments:

If the document updates RFC 8407, it needs to mention that in the Abstract.
Also the abstract can be shortened to what the document defines, and move
everything else into the introduction.

The document says "This document defines an extension statement ...". Is only
extension statement defined?

Text like "data object tags may be registered as well as assigned during module
definition" follow the pattern of RFC 8819 and should be referred to rather
than duplicated. If assigned during implementation, is there a possibility that
the same tag is assigned by two different implementations? What is the scope of
a given data object tag?

Similarly, the draft says "objects can be one of container, leaf-list and
list". Did you mean to say "objects can be one of type container, leaf-list and
list"?

The example in Figure 2 can be improved. For example, if all the data objects
are for the module name "tunnel-pm", do you need the last column. More
importantly, it is not clear why tunnel-src/max-latency (why a gap between /
and max-latency), is not an object tag? Can a sub-object tag exist if the node
is not an object tag?

In Section 4, Data Object Tag Values, it says tags can be any value except
carriage-returns, newlines and tabs. Does it mean spaces are allowed? Can a
data object have multiple tags? What does it mean "No further structure is
imposed ..."?

Section 4.2 introduces the concept of vendor prefix for tags. It says vendors
include extra identification in the tag to avoid collision. But what is to say
that two organizations may not use the same identification? And is this
identifier part of the tag or is separated from the tag with a :.

Similarly, it says that user prefix is RECOMMENDED. If not using it can cause
collision, why is use prefix RECOMMENDED and not a MUST?

The draft has just one example. And it shows mostly ietf prefixed tags. More
examples showing use of different types of tags are needed. It would be helpful
to know how tags can be removed.

Section 5 - YANG Module.

The section does not reference the RFCs that it imports modules from, e.g.
ietf-netcom-acm.

Inside the YANG model, import statements need to carry reference statement.

The WG link needs to refer to datatracker.ietf.org and not tools.ietf.org

The Copyright statement has 2021 as the year.

Line length should be limited to 72 columns.

No need to repeat parent name in child node, e.g. object-name -> name.

Indentation is off in places, specially in the example.

A pyang compilation of the model with —ietf and —lint option was clean.

A idnits run of the draft reveals a few issues. Please address them.

draft-ietf-netmod-node-tags-04.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  -------------------------------------------------------------------

     No issues found here.

  Checking nits according to
  https://www.ietf.org/id-info/1id-guidelines.txt:
  -------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  -------------------------------------------------------------------

  ** There are 70 instances of too long lines in the document, the
     longest one being 15 characters in excess of 72.

  -- The draft header indicates that this document updates RFC8407,
     but the abstract doesn't seem to mention this, which it should.

  Miscellaneous warnings:
  -------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line
     does not match the current year

  == Line 404 has weird spacing: '...ct-name    nac...'

  == Line 493 has weird spacing: '...dentify  multi...'

  == Line 656 has weird spacing: '...resents  a pro...'

  == Line 999 has weird spacing: '...dentify  multi...'

  -- The document date (November 2021) is 77 days in the past.  Is
     this intentional?

  Checking references for intended status: Proposed Standard
  -------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative
     references to lower-maturity documents in RFCs)

  == Missing Reference: 'I-D.netconf-notification-capabilities' is
     mentioned on line 139, but not defined

  == Missing Reference: 'I-D.ietf-netmod-yang-instance-file-format'
     is mentioned on line 1106, but not defined

     Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2
     comments (--).

     Run idnits with the --verbose option for more detailed
     information about the items above.