[mpls] Mohamed Boucadair's Yes on draft-ietf-mpls-stamp-pw-10: (with COMMENT)

Mohamed Boucadair via Datatracker <noreply@ietf.org> Thu, 27 August 2026 11:01 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@mail2.ietf.org
Received: from [10.244.8.242] (gaia.k8s.ietf.org [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id DC02A13048742; Thu, 27 Aug 2026 04:01:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787828469; bh=9vV3BUcuZ2VmqE3orT/t9K1ShKeoTwH5GWwglDi92Sc=; h=From:To:Cc:Subject:Reply-To:Date; b=eo/w6kVVExIyQHZDzpHS5wTgqI7aOZ17cwUWgFJopUzMwDfTtiyJVMMo2ayOFlmcR bYo4rRY6LyauitiTgpaYK5/GGF+ucKrPyEMYnlKY9kk//g1zaNcjkW0rpQfqz4DQtC cIHJ5Wt6nK65SgD29wXSn1+mVc1pTMgHkaM7Ep4Q=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Mohamed Boucadair via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.72.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <178782846982.915465.7279761939667105560@dt-datatracker-786f84c586-97d96>
Date: Thu, 27 Aug 2026 04:01:09 -0700
Message-ID-Hash: WVW2QGQOJ2ODG4N4WPDVPKZOX7VDMNKN
X-Message-ID-Hash: WVW2QGQOJ2ODG4N4WPDVPKZOX7VDMNKN
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-mpls-stamp-pw@ietf.org, mpls-chairs@ietf.org, mpls@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Mohamed Boucadair <mohamed.boucadair@orange.com>
Subject: [mpls] Mohamed Boucadair's Yes on draft-ietf-mpls-stamp-pw-10: (with COMMENT)
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/tOTKzz31_BuoJ9CQwfIntHNFTw0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

Mohamed Boucadair has entered the following ballot position for
draft-ietf-mpls-stamp-pw-10: Yes

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-mpls-stamp-pw/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi Rakesh, Patrice, Eddie, and Xiao Min,

Thank you for the effort put into this well-written specification. I appreciate
in particular the good OPS cons section.

Thanks to Giuseppe Fioccola for the OSPDIR review, Carlos Pignataro for
PERFMETRDIR, and the authors for engaging and addressing the various comments.

I only have nits:

# Consider clarifying the update to 8972

OLD:
   This document updates RFC 8972: STAMP Test Session Identifier.

NEW:
   This document updates RFC 8972 by updating the STAMP Test Session Identifier
   for LSPs and PWs.

# Please s/port/port number through the document.

# Help readers by adding a forward reference that points to the section where
this is specified:

CURRENT:
      -  For encapsulating the STAMP test packet payloads over a G-ACh
         without adding IP/UDP headers, two new channel types are
         defined in this document: one for the Session-Sender test
         packets and one for the Session-Reflector test packets.

# Section 3

CURRENT:
   When using a destination
   UDP port number other than the default port number 862, the possible impact
   on the network MUST be carefully studied and agreed on by all users of the
   network domain where the test has been planned, as described in Section 4.1
   of [RFC8762].

I know this mirrors what is in 8762, but I think this text is better positioned
in the OPS considerations section.

Cheers,
Med