Re: [ippm] Lars Eggert's No Objection on draft-ietf-ippm-ioam-deployment-02: (with COMMENT)

"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Tue, 03 January 2023 18:38 UTC

IronPort-PHdr: A9a23:k3vOAxIaX/u1bGBHF9mcuWEyDhhOgF28FgIW659yjbVIf+zj+pn5J 0XQ6L1ri0OBRoTU7f9Iyo+0+6DtUGAN+9CN5XYFdpEfWxoMk85DmQsmDYaMAlH6K/i/aSs8E YxCWVZp8mv9P1JSHZP1ZkbZpTu56jtBcig=
IronPort-Data: A9a23:3hfh7qqB55fk3cKDQP9Gbj+Wt71eBmL0ZRIvgKrLsJaIsI4StFCzt garIBnXbvzfZWbxLYwjaoWy9hkFvJbcnIdjTAY/qithQS5E9uPIVI+TRqvS04x+DSFioGZPt Zh2hgzodZhsJpPkjk7xdOCn9xGQ7InQLlbGILas1htZGEk1Fk/NtTo5w7Ri2tcw2oDla++wk YqaT/P3aQfNNwFcagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDf3Zw0/Df2VhNrXSq 9AvY12O1jixEx8FUrtJm1tgG6EAaua60QOm0hK6V0U+6/RPjnRa70o1CBYTQWlnmTuAmYl78 opAu4GMUCELL5DAxftIBnG0EwkmVUFH0LbDJX76usuJwgifKj3nwu5lCwc9OohwFuRfWD4Vs 6dGbmlWKEnY3Ipaw5rjIgVorsopNs7gP4USknph1jreS/0hRPgvRo2TtIIAhG1r2aiiG97nf sY0cSd2ZS+afjJQGE9MI7YAweS30yyXnzpw8QLJ+vVfD3Lo5BBp2aXpIfLcYsSOSINemUPwj mPe52HRAxwGOpqY0zXt2nO0nuqKliPyWZgJPLy16vAsh0ecrkQfEhQYSR66rOW3z0+mQ9caK ksd/28ioLA2812uQ9/hdxy1vHDCuQQTM/JRHvY1wACA1qSS5ByWbkAARyRaQNEpu8IsWXotz FDhoj/yLTVrtLvQQnWH+/LN9HW5ODMeKikJYipsoRY5D8fLjrEhgBvJF9xZT6O7k+HsPxPh/ jzXs31r71kMtvIj26K+9FHBpjujoJnVUwI4jjk7uEr4tmuVg6b4POSVBUjnAeVod9zGEAjY1 JQQs43Psr5WUMrleDmlHb1lIV2/2xqS3NQwa3ZKEoI46jWx9hZPlqgPvWgidS+F3iv4EAIFj WfavQdXoZRUJnbvNPYxaIOqAMNsxq/lfTgEahw2RoQWCnSSXFbYlM2LWaJ29zu0+KTLufpmU ap3ie72UR4n5V1PlVJavds1374x3TwZzmjOX539xBnP+ePAOyTLGetfagvePr1RAEa4TOP9r os32yyilks3bQECSnK/HXM7dApTdiFrWfgaVeQOLbfZSuaZJI3RI6aBnex+E2CUt69UjezPt mqsQVNVzUGXuJE0AVviV5yXU5u2BcwXhStiZUQEZA/0s1B9OtzHxPlEKPMKkUwPqbYLIQhcF adVIq1tw51nF1z6xtjqRcWl8dYyKU7y2l/m0ujMSGFXQqOMjjfhorfMFjYDPgFXZsZrnaPSe 4Gd6z4=
IronPort-HdrOrdr: A9a23:rRFsTq25bbudEuLdHq324QqjBQZyeYIsimQD101hICG9Lfb3qy n+ppsmPEHP5Ar5AEtQ5expOMG7MBfhHO1OkPYs1NCZLUXbUQqTXcxfBO7ZogEIdBeOjtK1uZ 0QEZSWTeeAcGSS7vyKrzVQcexQu+VvmZrA7Yy1ohcdLj2CKZsQlTuRYTzrdXGeMTM2fKbRY6 DsgPavyQDQHEg/X4CePD0oTuLDr9rEmNbNehgdHSMq7wGIkHeB9KP6OwLw5GZRbxp/hZMZtU TVmQ3w4auu99uhzAXH6mPV55NK3PP819p4AtCWgMR9EESstu/oXvUgZ1SxhkF2nAid0idurD AKmWZlAy1H0QKTQohym2qr5+Cv6kdp15ao8y7nvZKqm72JeNt9MbsZuWqcGSGpsHbJe7pHof p2NiuixupqJAKFkyLn69fSURZ20kKyvHo5iOYWy2dSSI0EddZq3MQiFW5uYeE99RjBmckaOf grCNuZ6OddcFucYXyctm5zwMa0VnB2GhudWEANtsGczjATxRlCvgEl7d1amm1F+IM2SpFC6e iBOqN0lKtWRstTaa5mHu8OTca+F2SISxPRN2CZJ0jhCcg8Sjnwgo+y5K9w6PCheZQOwpd3kJ PdUElAvWp3YE7qAd3m5uw9zvkMehTIYd3A8LAq23EigMyOeFPCC1zwdGwT
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: Lars Eggert <lars@eggert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ippm-ioam-deployment@ietf.org" <draft-ietf-ippm-ioam-deployment@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "tpauly@apple.com" <tpauly@apple.com>
Thread-Topic: Lars Eggert's No Objection on draft-ietf-ippm-ioam-deployment-02: (with COMMENT)
Thread-Index: AQHZDh9xoGl4EXYUL0qEICKy4wF+C66NJkVA
Date: Tue, 03 Jan 2023 18:38:28 +0000
Message-ID: <MWHPR11MB13115676FA84C5E316DBE9FBDAF49@MWHPR11MB1311.namprd11.prod.outlook.com>
References: <167084561141.46389.6261114964304426173@ietfa.amsl.com>
In-Reply-To: <167084561141.46389.6261114964304426173@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Gi7VAW3lgiIUgUZ63qg2yFIr16HIECglQcXAaKRBwqH+AeERlOtvGYL/lPZUZ4uTjMOa8zIiStbEVJQTkOfv5P7wU2luXgIs1F1aBBhkidhjc+1Fx0VVIMRPVWIaQ51r3aa9qVSndR9SOvWt0akU0wouIg32qOdbm19XektPn1BJdu+kLevRDiS/0+wnoHeZ8qmobZVEldopxRcQjm+38v/whiRSYC88vHmX8QV+mKGGa+4JryMglrFZ8EnQopaJWOSCQuS75kAFL5o9zU9KfvpIcc9njlQmvgP0u406yZM0XkLCQVGXJyzXVJ1QGDqiLUrJwPNMBWn/zqZoEFezFu3PUKEHn9ANXWTKKtFBpPT45yuYPNXtcfUaMbt9BTyGAcpVFdVXfIX6mM3z9SrpSy9yusotI4GJp8LueLZNs0vwBA5+Gzu6EBYNIvq2n65wdv9gzornhO/wW+gOjkUllNzvlY86UdC4WFWHCRHID3JsklTBnSW7AAH7rXZfZlia8VQ2Hl8oGG0cQhg/fSrm/ddUNeqsNJt7pYmnQS2Vj5TwskNBHXqIX/n1JS4CHf62kx8wECDHdSMq7ly+pCQfm0FqOpPsCH/IXWvTi0tm+o9uM6s8sVvR7Pb3wmMGGuDBaII9UcirJX54wJ23QGnlpuK/FjcQ7eO4bKyL6uSK5ysW/D0ojTHv5g8ZR3GQMAzcCgAtabSZso7bz871tsMG4cNNSWsSBgdzIOhiRzMjS80xhw/iv18a/Mq6OXbn9r/W67GQOf7ADxou2jD2q/UXhyH/tjMEKn0+UiYOd+xEsLY6jODJOWyAoETUBgKVpWZ38xBBaHigvGHczKF7BwfnQ4qb4FN7xFjHBDB8qECH7VmMTLNdOHMZOuqcsvzdXKpO0S496r032lbvyjxvm6Z9q6uXpu5Bq1iAPNwgq/Jxen1ub4AK9+aZ9qPzLal17i4u/8t6EW1YZB6/S275ttLrb9pFLz4ndXFBclFx4m6ZUkNnLk/Cn2F+VFQIUaVCY1dbB5Opa03e0P7I3B4T2O1NhoTh0LBCKFo9uWsZyUJHaJefDHpdjCOSY3unk4yPOhKlYmfcimiGrTNJd6L+ujKbFXpztUYMuCu5XdWoF2v52eGiJuqyr77dGpLET1YBE0pFnnkeUMulhf6LBYAJXznqEdH+Lu0ZfwtljCEPTCHe6zEPXI/7s5oLBFTFHPj0n4KQw78At9jTyvIeFw1yyePjfUyEL+lKgqIQ1XONeHdAGkeHXDq0QqweqFN+SxuAwUaGSe0BIiyuRbrbtSV0sHB4XDvOA9VTULpcc12GpSBl8/9vG6tErA7GCohOyp150qg+1EtVSEw7JN5WFTlMDrf8BhFtgrkUTLTHeD9wNjsGY4UJ8f0t5hrOtDC7neZc1ME24XWP/s9Xbp7xqVDDNrIpdrFNVzdaLuyvQ+bx8Q5QUVRxpiP4xzDDVu+5cxWanWEM+6KA0yj7LBjVikVARv27BqZXdNxOeTMlJJbKMxxypsqlnfsWysR0xav6TDcVTdHUkAwDosUDwgUe3zWA/K1Hyh5lX3Qm8sAVmLAwGt7EuXQJ/lJIsR1C0bYilNpnRok+
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1311.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0798dd01-e8d6-4ad1-0e80-08daedb9b4fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2023 18:38:28.7315 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cDm3sLaOeYK8x1h1pglvL00sz5b13xB/eP7kCXzUe8Q5JGUbq8cT28DiwKGfKAMfZ3anV7PIRgqBg6GngjGivg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR11MB5251
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 64.101.210.235, xfe-rtp-005.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/VCoxkn00m_39fVcUwJQfAwVnr4A>
Subject: Re: [ippm] Lars Eggert's No Objection on draft-ietf-ippm-ioam-deployment-02: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2023 18:38:40 -0000

Hi Lars,

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. 

Special thanks for running the draft via your nits tool. All the suggestions were really helpful. 
There is one that I'd need a bit of help with: The boilerplate code included is driven by
<rfc category="info" docName="draft-ietf-ippm-ioam-deployment-04" ipr="trust200902">
In order to get the "Revised BSD License" boilerplate text - which ipr reference am I supposed to use?

Please see inline.

> -----Original Message-----
> From: Lars Eggert via Datatracker <noreply@ietf.org>
> Sent: Monday, 12 December 2022 12:47
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-ippm-ioam-deployment@ietf.org; ippm-chairs@ietf.org;
> ippm@ietf.org; tpauly@apple.com; tpauly@apple.com
> Subject: Lars Eggert's No Objection on draft-ietf-ippm-ioam-deployment-02:
> (with COMMENT)
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-ippm-ioam-deployment-02: 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-ippm-ioam-deployment/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # GEN AD review of draft-ietf-ippm-ioam-deployment-02
> 
> CC @larseggert
> 
> Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART)
> review
> (https://mailarchive.ietf.org/arch/msg/gen-art/A39Rwii1B-f8X3VfnjmdQ2Iz_6k).

...FB: Thanks - Ines' comments are reflected in revision -04.

> 
> ## Comments
> 
> ### "Abstract", paragraph 1
> ```
>      In-situ Operations, Administration, and Maintenance (IOAM) collects
>      operational and telemetry information in the packet while the packet
>      traverses a path between two points in the network.  This document
>      provides a framework for IOAM deployment and discusses best current
>      practices.
> ```
> Since this document is not a BCP, it might be better to
> rephrase "discusses best current practices" as "gives deployment
> guidance" or something like that.

...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, paragraph 4
> ```
>      An "IOAM transit node" updates one or more of the IOAM-Data-Fields.
>      If both the Pre-allocated and the Incremental Trace Option-Types are
>      present in the packet, each IOAM transit node will update at most one
>      of these Option-Types.  A transit node does not add new IOAM-Option-
>      Types to a packet, and does not change the IOAM-Data-Fields of an
>      IOAM Edge-to-Edge Option-Type.
> ```
> If each node can unilaterally determine which of the two option types
> to update, how will the eventual receiver of this information be able
> to come to a consistent view of he signaled information, if two
> different values are present in a packet?

...FB: It isn't really the job of the receiver (the decapsulating node) to make sense of the information in the packet. It would be up to a network management station, or similar which would need to fit the different pieces of data into an overall view. The section has been updated to clarify that fact:

   An "IOAM transit node" updates one or more of the IOAM-Data-Fields.
   If both the Pre-allocated and the Incremental Trace Option-Types are
   present in the packet, each IOAM transit node will update at most one
   of these Option-Types.  Note that in case both Trace Option-Types are
   present in a packet, it is up to the IOAM data processing systems
   (see Section 6) to integrate the data from the two Trace Option-Types
   to form a view of the entire journey of the packet.  A transit node
   does not add new IOAM-Option-Types to a packet, and does not change
   the IOAM-Data-Fields of an IOAM Edge-to-Edge Option-Type.


> 
> ## Nits
> 
> All comments below are about very minor potential issues that you may choose
> to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
> 
> ### Typos
> 
> #### Section 1, paragraph 1
> ```
> -    leveraged where mechanisms using e.g.  ICMP do not apply or do not
> -                                         ^
> +    leveraged where mechanisms using, e.g., ICMP, do not apply or do not
> +                                    +     ^     +
> ```

...FB: Corrected.

> 
> #### Section 3, paragraph 1
> ```
> -    an IOAM domain, e.g. using for example packet filtering methods.  The
> -                              ------------
> +    an IOAM domain, e.g., using packet filtering methods.  The
> +                        +
> ```
...FB: Corrected.
> 
> #### Section 7.2, paragraph 1
> ```
> -    encapsulation mechanisms.  Similarly, the sematics of the IOAM-Data-
> +    encapsulation mechanisms.  Similarly, the semantics of the IOAM-Data-
> +                                                  +
> ```
...FB: Corrected.
> 
> #### Section 7.3, paragraph 1
> ```
> -    is expanded at every IOAM node that addes IOAM-Data-Fields.  "Pre-
> -                                           -
> ```
...FB: Corrected.
> 
> #### Section 10, paragraph 5
> ```
> -    are subject to IOAM encpasulation and the rate of exported traffic,
> -                            -
> -    it is possible to cofine the impact of such attacks.
> +    are subject to IOAM encapsulation and the rate of exported traffic,
> +                           +
> +    it is possible to confine the impact of such attacks.
> +                        +
> ```
...FB: Corrected.

> 
> ### Boilerplate
> 
> Document still refers to the "Simplified BSD License", which was corrected in
> the TLP on September 21, 2021. It should instead refer to the "Revised BSD
> License".

...FB: See above. Which ipr reference am I supposed to use?

> 
> ### Outdated references
> 
> Document references `draft-ietf-ippm-ioam-flags`, but that has been published
> as `RFC9322`.
> 
> Document references `draft-ietf-ippm-ioam-conf-state-07`, but `-10` is the
> latest available revision.
> 
> Document references `draft-gandhi-spring-ioam-sr-mpls-02`, but `-08` is the
> latest available revision.
> 
> Document references `draft-ietf-ippm-ioam-direct-export`, but that has been
> published as `RFC9326`.

...FB: Corrected.

> 
> ### Grammar/style
> 
> #### Section 4.1, paragraph 2
> ```
> s for generic IOAM data include geo-location information (location of the no
>                                 ^^^^^^^^^^^^
> ```
> This word is normally spelled as one.
...FB: Corrected.
> 
> #### Section 6, paragraph 2
> ```
> elds. IOAM-Namespaces support several different uses: o IOAM-Namespaces
> can
>                               ^^^^^^^^^^^^^^^^^
> ```
> Consider using "several".
...FB: Corrected.
> 
> #### Section 7.1, paragraph 3
> ```
> -Data-Fields in one layer are independent from IOAM-Data-Fields in another l
>                               ^^^^^^^^^^^^^^^^
> ```
> The usual collocation for "independent" is "of", not "from". Did you mean
> "independent of"?
...FB: Corrected.
> 
> #### Section 7.1, paragraph 3
> ```
> tionship, in IOAM, layers are independent from each other and don't assume a
>                               ^^^^^^^^^^^^^^^^
> ```
> The usual collocation for "independent" is "of", not "from". Did you mean
> "independent of"?
...FB: Corrected.
> 
> #### Section 7.2, paragraph 3
> ```
> ta-Fields does not exceed the MTU of any of the links in the IOAM domain. In
>                                   ^^^^^^^^^
> ```
> Consider simply using "of" instead.
...FB: Corrected.
> 
> #### Section 7.3, paragraph 1
> ```
> tays within the bounds of the MTU of any of the links in the IOAM domain. Th
>                                   ^^^^^^^^^
> ```
> Consider simply using "of" instead.
...FB: Corrected.
> 
> #### Section 7.3, paragraph 1
> ```
> as to ensure that the minimum MTU of any of the links in the IOAM domain is k
>                                   ^^^^^^^^^
> ```
> Consider simply using "of" instead.
...FB: Corrected.
> 
> #### Section 7.6, paragraph 3
> ```
> Proof of Transit Option-Type (Section Section 4.2) is used for verifying the
>                               ^^^^^^^^^^^^^^^
> ```
> Possible typo: you repeated a word.
...FB: Corrected.
> 
> #### Section 7.6, paragraph 5
> ```
>  single LAN, but span multiple inter-connected sites (for example, using an o
>                                ^^^^^^^^^^^^^^^
> ```
> This word is normally spelled as one.
...FB: Corrected.
> 
> #### Section 8, paragraph 2
> ```
> revent IOAM traffic from leaking outside of the IOAM domain, and prevent IOA
>                                  ^^^^^^^^^^
> ```
> This phrase is redundant. Consider using "outside".
> 
> ## Notes
> 
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].
> 
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> [IRT]: https://github.com/larseggert/ietf-reviewtool
> 
> 

Thanks again for your review.

Cheers, Frank

[ippm] Lars Eggert's No Objection on draft-ietf-i… Lars Eggert via Datatracker
Re: [ippm] Lars Eggert's No Objection on draft-ie… Frank Brockners (fbrockne)
Re: [ippm] Lars Eggert's No Objection on draft-ie… Frank Brockners (fbrockne)