[alto] Éric Vyncke's No Objection on draft-ietf-alto-oam-yang-15: (with COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Wed, 25 October 2023 09:49 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: alto@ietf.org
Delivered-To: alto@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8BCC14E515; Wed, 25 Oct 2023 02:49:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-alto-oam-yang@ietf.org, alto-chairs@ietf.org, alto@ietf.org, mohamed.boucadair@orange.com, mohamed.boucadair@orange.com, jim@rfc1035.com, mellon@fugue.com, scott.rose@nist.gov
X-Test-IDTracker: no
X-IETF-IDTracker: 11.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <169822738618.22438.195848943330081124@ietfa.amsl.com>
Date: Wed, 25 Oct 2023 02:49:46 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/mV5QajdoR-N4rTJOJyWHV4mN04Y>
Subject: [alto] Éric Vyncke's No Objection on draft-ietf-alto-oam-yang-15: (with COMMENT)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Oct 2023 09:49:46 -0000
Éric Vyncke has entered the following ballot position for draft-ietf-alto-oam-yang-15: 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-alto-oam-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-alto-oam-yang-15 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Mohamed Boucadair for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. Other thanks to Ted Lemon and Scott Rose, the DNS directorate reviewers, please consider this dns-dir review: https://datatracker.ietf.org/doc/review-ietf-alto-oam-yang-15-dnsdir-telechat-lemon-2023-10-23/ (authors should probably reply on the email thread) https://datatracker.ietf.org/doc/review-ietf-alto-oam-yang-14-dnsdir-telechat-rose-2023-10-19/ (and I have seen authors' reply) I hope that this review helps to improve the document, Regards, -éric # COMMENTS ## NMDA support I often see YANG RFC stating their support (or lack of) NMDA (RFC 8342), is there any reason why NMDA support is not stated in the text ? ## Section 3 (comments can be ignored) While it does not hurt, several acronyms are really well-known, hence no need to expand them. Is "O&M" really used in other documents ? First time that I see this acronym. ## Section 5.1 As the module is prefixed by the ietf-alto namespace, strongly suggest to use another term than "alto" at the root and even more s/alto-client/client/ s/alto-server/server/ ## Section 5.3.1.1 As I am trusting the SEC ADs' reviews, I will not ballot a blocking DISCUSS, please remove all HTTP (as opposed to HTTPS) in the text and in the data model itself. Or is "http" used instead of "https" ? But, then why is there a "tls" Later in the YANG module itself, it seems that the TLS termination would be done in a different node, then how can this TLS termination be configured ? If confirmed, then adding some text in this section would make the reader's task easier. ## Section 5.3.2 I am sorry, but relying on SYSLOG in 2023 seems really legacy... ## Section 7.1 Some identities would benefit if the units where mentioned in the description instead of providing a pointer to another RFC (e.g., for delay-rt), adding a meaningful description (such as "round-trip delay") would also be benefitial for the reader. ## Section A.5 The example should also have a listen to "::/0" for IPv6 # NITS ## Section 4.2 and other places s/the data models/the data model/ or /the data modules/ as this I-D defines a single data model consisting of several data modules.
- [alto] Éric Vyncke's No Objection on draft-ietf-a… Éric Vyncke via Datatracker
- Re: [alto] Éric Vyncke's No Objection on draft-ie… mohamed.boucadair
- Re: [alto] Éric Vyncke's No Objection on draft-ie… Eric Vyncke (evyncke)
- Re: [alto] Éric Vyncke's No Objection on draft-ie… mohamed.boucadair