Re: [ippm] Rtgdir last call review of draft-ietf-ippm-ioam-deployment-02

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Joel,

Happy New Year!  Thanks a lot for your review - and sorry for the delay.
We've just posted a new revision https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-deployment-04.txt which is to address your comments. 
Please see inline.


> -----Original Message-----
> From: Joel Halpern via Datatracker <[e-mail]>
> Sent: Wednesday, 2 November 2022 18:35
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; last-
> [e-mail]
> Subject: Rtgdir last call review of draft-ietf-ippm-ioam-deployment-02
> 
> 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.

...FB: There seems to be a bit of a misunderstanding here. The Namespace-ID is part of the IOAM Option-Type definition. As such, it is part of the IOAM data fields and defined in RFC 9197, rather than in the specifications that define how the IOAM data fields are encapsulated into a specific protocol. To avoid that confusion with other readers, I've expanded Section 7.1 to include the appropriate reference:

   IOAM-Namespaces add further context to IOAM-Option-Types and
   associated IOAM-Data-Fields.  IOAM-Namespaces are defined in
   Section 4.3 of [RFC9197].  The Namespace-ID is part of the IOAM
   Option-Type definition, see e.g., Section 4.4 of [RFC9197] for IOAM
   Trace Option-Types or Section 4.6 of [RFC9197] for the IOAM Edge-to-
   Edge Option-Type.

> 
> 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.)

...FB: Thanks! Good catch. The sentence in section 4.1 now reads:

   IOAM tracing can for example collect the following types of
   information:

> 
> 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.

...FB: The fact that the abstract should not sounds like a BCP has been mentioned by several reviewers.
The abstract now reads:

" This document
   provides a framework for IOAM deployment and provides IOAM deployment
   considerations and guidance."

Section 3 also now only makes reference to section 7.1 which discusses Namespaces in more detail.
Having an example in section 3 and then a larger set of examples in section 7.1 was indeed confusing.
Thanks for pointing this out.

Thanks again for your review.

Cheers, Frank

> 
>