[ippm] Robert Wilton's No Objection on draft-ietf-ippm-ioam-yang-12: (with COMMENT)
Robert Wilton via Datatracker <noreply@ietf.org> Thu, 29 February 2024 16:47 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ippm@ietf.org
Delivered-To: ippm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 817E8C151989; Thu, 29 Feb 2024 08:47:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-ioam-yang@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com, marcus.ihlar@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.6.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <170922526652.22965.16312237465257202789@ietfa.amsl.com>
Date: Thu, 29 Feb 2024 08:47:46 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/1gyKIC_o2-FFaHGZRJd2uMnf1Tc>
Subject: [ippm] Robert Wilton's No Objection on draft-ietf-ippm-ioam-yang-12: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Feb 2024 16:47:46 -0000
Robert Wilton has entered the following ballot position for draft-ietf-ippm-ioam-yang-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document, I noted that this document hadn't had a recent YANG doctor review. I have a few suggestions for you to consider that may improve the YANG. Minor level comments: (1) p 3, sec 3.1. Overview The "ioam-info" is a container for all the read-only information that assists monitoring systems in the interpretation of the IOAM data. module: ietf-ioam +--rw ioam +--ro ioam-info | +--ro timestamp-type? identityref | +--ro available-interface* [if-name] | +--ro if-name if:interface-ref +--rw ioam-profiles Please rename the 'ioam-info' container to 'info' and 'ioam-profiles' to 'profiles', and 'ioam-profile' to 'profile'. This will make the paths shorter and reduce duplicate semantic information on the path. (2) p 3, sec 3.1. Overview +--rw admin-config | +--rw enabled? boolean Please move 'admin-config' outside of the ioam-profiles container, so that the container is only wrapping the list entry. (3) p 17, sec 4. IOAM YANG Module description "This boolean value indicates whether the sequence number is used in the direct export option 32-bit flow identifier. If this value is true, the sequence number is used. By default, it's turned off."; } } Are you allowed to set both enable-sequence-number and a flow-id? If not, then it might be worth adding text to this effect. (4) p 20, sec 4. IOAM YANG Module leaf enabled { type boolean; default false; description "When true, apply incremental tracing option to the specified flow identified by the filter."; } You have several similar containers that all an "enabled" leaf, which defaults to false. Did you consider setting these containers as presence containers instead? Which would remove the need for the enable leaf, since the existence of the container in the config would indicate that it is enabled. Nit level comments: (5) p 17, sec 4. IOAM YANG Module leaf node-action { type ioam-node-action; default action-transit; description "This indicates what action the node will take, e.g. encapsulation."; Description isn't properly formatted (although the RFC editor should also fix this). (6) p 17, sec 4. IOAM YANG Module description "A 32-bit flow identifier. The field is set at the encapsulating node. The Flow ID can be uniformly assigned by a central controller or algorithmically generated by the encapsulating node. The latter approach cannot guarantee the uniqueness of Flow ID, yet the conflict probability is small due to the large Flow ID space.flow-id is used to correlate the exported data of the same flow from multiple nodes and from multiple packets."; } ".flow-id" => ". flow-id" (7) p 23, sec 5. Security Considerations * /ioam/ioam-profiles/ioam-profile: The entries in the list above include the whole IOAM profile configurations. Unexpected changes to these entries could lead to the mistake of the IOAM behavior for the corresponding flows. Consequently, it will impact the performance monitoring, data analytics, and the assciated reaction to network services. assciated => associated Regards, Rob
- [ippm] Robert Wilton's No Objection on draft-ietf… Robert Wilton via Datatracker
- Re: [ippm] Robert Wilton's No Objection on draft-… Tianran Zhou