Reviewer: Joel Halpern Review result: Not Ready I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ippm-ioam-deployment-02 Reviewer: Joel M. Halpern Review Date: 2-Nov-2022 IETF LC End Date: N/A Intended Status: Informational Summary: This document is almost ready for publication as an Informational RFC, with one Major issue, one minor issue, and some nits. Comments: The document is well written, clear, and helpful. Major Issues: The framework described here seems to treat the notion of IOAM namespace as an important concept. However, none of the encapsulation drafts I checked have any representation for IOAM namespace. It does not seem possible for transit / decapsulation devices to infer the namespace from the packet. Is it assumed that for now there is a single default namespace, and the encapsulations will be enhanced? Or? This needs to be clarified. Minor Issues: I presume the list of data at the end of section 4.1 ("IOAM tracing can collect the following types of information") is intended to be exemplary and not complete? If so, would it be clearer to say "IOAM tracing can for example collect the following types of information"? (The inclusion of "generic data" in the list means I suppose you could treat it as complete, but it seems odd to do so, particularly in an Informational document.) Nits: The abstract refers to the content as including best current practices. This is an Informational draft, and not a BCP. How about replacing that with "recommended practices"? It would be good to have a better example in section 3 (IOAM Deployment: Domains And Nodes) of why IOAM namespaces are useful. Logical and physical interfaces already have distinct identifiers (since there are contexts which can refer to both), so that example does not help the reader understand what problem IOAM namespaces solves. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
