[Last-Call] Yangdoctors last call review of draft-ietf-opsawg-collected-data-manifest-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Qiufang Ma
Review result: On the Right Track

Hi, authors, WG,

This is my YANG Doctor review of draft-ietf-opsawg-collected-data-manifest-05.

The document defines three YANG modules (though only two of them are mentioned
in the introduction section), two modules leverage the schema mount mechanism
defined in RFC 8528, and the other augments the ietf-subscribed-notifications
defined in RFC 8639.

Moderate Comments:
1. The mounted schema cannot be determined at design time.
The schema mount mechanism defined in RFC 8528 doesn’t provide support for the
design time, it might be confusing for the document to provide a normative tree
diagram with the mounted schema specified in the draft. I understand the
document implies it relies on some run time instance configuration to
determine, but it is weird to see some instance data after the YANG module that
is not specified as an example. I would suggest the authors to follow the
instruction from sec.4 in RFC 8340 and give a schema mount tree diagram with
only the mount point being specified and another tree diagram as an example
combined with the instance data to show your intended use, maybe also refer to
some RFCs that uses the schema mount mechanism, e.g., RFC 8529, RFC 8530.

2. The yang module  "ietf-data-collection-manifest-statistics" doesn’t seem to
fit in the scope of this draft. I am a little surprised to see a YANG-push
extension module defined in this document (I think the intent is to define
current-period node as ro, rather than rw?), as I understand it is targeting to
define network modules for telemetry context information. And I am also
wondering whether the current-period could be available by reading the exact
node in <operational>, i.e., <running> contains what is configured, but
<operational> holds what is actually applied by the system as per RFC 8342.

3. Lack of IANA consideration
Please complete the IANA consideration for the newly defined YANG modules, the
document needs to register in the "IETF XML Registry" and "YANG Module Names"
registry.

Minor comments:
1. Section 3.1: "As an example, the identifier could be the 'sysname' from the
ietf-notification module presented in [I-D.tgraf-netconf-notif-sequencing]."
Note that the referenced document has been replaced, it would be good it would
be updated accordingly.

2. Section 3.2 and Section 4.3, please add description statement for the
yangmnt:mount-point in YANG modules to clarify the intended use, e.g., mounted
schema type, which YANG module is supposed to be mounted, etc.

3. Section 3.2, I am unsure I fully understand the definition of
software-version, software-flavor, and os-version and their differences. E.g.,
if the software-version refers to the operating system version, does this node
has the same value as os-version? How is the software-flavor node related to
the version information and how to parse "A variation of a specific version
where YANG model support may be different"? Maybe some more clarification would
help.

4. Section 4.2, I was expecting the yang code for the
ietf-data-collection-manifest module. But another module comes first, without
the tree diagram being specified first. Perhaps some structure refinement is
needed.

Nits:
1.organization
   "IETF OPSAWG (Network Configuration) Working Group";
wrong expansion for OPSAWG.

2.reference
    "RFC xxxx: Title to be completed";
Please complete it.

3. s/ Copyright (c) 2022  /  Copyright (c) 2024/


-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux