Re: [Last-Call] Secdir last call review of draft-ietf-ippm-ioam-conf-state-05 Sun, 09 October 2022 02:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA237C14F6EC; Sat, 8 Oct 2022 19:43:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f2U7B0LPGA7F; Sat, 8 Oct 2022 19:43:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EEF2C14F73D; Sat, 8 Oct 2022 19:43:25 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4MlRDq52cvz8R03x; Sun, 9 Oct 2022 10:43:23 +0800 (CST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4MlRDF3bVmz4y3Z8; Sun, 9 Oct 2022 10:42:53 +0800 (CST)
Received: from ([]) by with SMTP id 2992goW2088260; Sun, 9 Oct 2022 10:42:50 +0800 (GMT-8) (envelope-from
Received: from mapi (njxh01app02[null]) by mapi (Zmail) with MAPI id mid201; Sun, 9 Oct 2022 10:42:50 +0800 (CST)
Date: Sun, 09 Oct 2022 10:42:50 +0800
X-Zmail-TransId: 2afa6342352affffffffb7b49b32
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 2992goW2088260
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04- with ID 6342354B.001 by FangMail milter!
X-FangMail-Envelope: 1665283403/4MlRDq52cvz8R03x/6342354B.001/[]/<>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6342354B.001/4MlRDq52cvz8R03x
Archived-At: <>
Subject: Re: [Last-Call] Secdir last call review of draft-ietf-ippm-ioam-conf-state-05
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 09 Oct 2022 02:43:31 -0000

Hi Chris,

Thank you for the review and thoughtful comments.

I'v posted a new -06 revision, attempting to address your comments, as well as remaining comments from responsible AD Martin Duke.

Please see inline my responses...

Best Regards,

Xiao Min


From: ChrisLonvickviaDatatracker <>
To: <>;
Cc: <>; <>; <>;
Date: 2022年10月01日 09:38
Subject: Secdir last call review of draft-ietf-ippm-ioam-conf-state-05

Reviewer: Chris Lonvick
Review result: Has Issues
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.
The summary of the review is Ready with Issues.
The Security Considerations section doesn't give any guidance regarding errors,
boundaries, or limits. For example, the specification requires that certain
fields MUST be set to 0, but no guidance is given of what a receiver is to do
if it receives a packet with that field not set to 0. Similarly, the
specification requires that a list of IOAM Namespace-IDs be transmitted. What
should a receiver do if the list includes duplicate entries, or if it receives
a Namespace-ID that is not defined? Please add some bounds checking and limits
in the Security Considerations section.

[XM]>>> OK. A new paragraph is added to cover the sanity check.

The specification frequently references RFC 9197, which appears to have a
well-developed Security Considerations section. It would be appropriate if the
Security Considerations section of this ID were to reference that Security
Considerations section and require that implementations of this specification
follow the guidance given there.

[XM]>>> OK. A new paragraph is added as you suggested.

Other than those issues, I found the document to be understandable and well
written. I found no nits.