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

"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Wed, 04 January 2023 10:28 UTC

IronPort-PHdr: A9a23:ums17xexd9ipAWqiznpQoYvzlGM/tYqcDmcuAtIPh7FPd/Gl+JLvd Aza6O52hVDEFYPc97pfiuXQvqyhPA5I4ZuIvH0YNpAZURgDhJYamgU6C5uDDkv2ZPfhcy09G pFEU1lot3G2OERYAoDwfVrX93az9jUVXB74MFkdGw==
IronPort-Data: A9a23:ymtrvKtEbp80iOMZ3TyAHZb+/ufnVJZeMUV32f8akzHdYApBsoF/q tZmKTzXPPfZYGb1eo8nO9nloEgC6MDcn4c3SQFqriA2Q3gTgMeUXt7xwmUckM+xwmwvaGo9s q3yv/GZdJhcokf0/0vrav67xZVF/fngqoDUUIYoAQgsA146IMsdoUg7wbVh29Y02YHR7z6l4 LseneWOYDdJ5BYsWo4kw/rrRMRH5amaVJsw5zTSVNgT1LPsvyB94KE3ecldG0DFrrx8RYZWc QpsIIaRpQs19z91Yj+sfy2SnkciGtY+NiDW4pZatjTLbhVq/kQPPqgH2PU0NQAJjh+qgOBIk PJJqoWoFQQvOIDzobFIO/VYO3kW0axu4rTLJz20ttaeihSfNXDt2P5pSkoxOOX0+M4uXjoIr qNeeWtLN0zc7w616OrTpu1EiM45K8LoOo43sXB7xjafBvEjKXzGa/6Rv4QHhmxo7ixINa70Q 5A2VBF3VTbvQyZqE0xKBLwVwOj90xETdBUB+A7K+sLb+VP70BR4zbz8GNPNYtiHA85Smy6wp 3re+kz4Dw0UctuFxlKt82q0g6rEnSr6Qpk6FbCk+LhtmlL77mAJARMKEFq2vff8i1amXpdeL EURvyYjtaw15UmmSMXVXhCkrjiDpBF0c9tdCOIS6QyRxOzT+QnxLmwNVCVpZdMpudUqAzsw2 Te0c8jBHzdjtvieTmiQs+7N6zizIiMSa2QFYEfoUDfp/fG/5982pDHQfu87N6qql8WpGjf27 g+z+X1Wa6ooseYH0KCy/Fbiij2qp4TUQgNd2jg7Tl5J/SsiO9H4P93ABUzzqKcffNzAHzFtq VBdw5DGhN3iG61hg8BkfQngNKui6/DAOzrGjBs2Rt8q9i+m/DioeoU4DNBCyKVBb5dsldzBO R+7VeZtCHl7ZyXCgUhfONjZNijS5fK8fekJr9iNBja0XrB/dRWc4AZlblOK0mbmnSAEyP9gY 8jEKZj3VS9LUcyLKQZaoc9AjtfHIQhjmwvuqWzTlHxLLJLHPifOEOdZWLdwRrlisfvsTPrpH yZ3bpvWlEo3vBzWaSjM+olbNkERMXU+HvjLRz9/KIa+zv5dMDh5UZf5mOp5E6Q8xvg9vrmTp BmVBBQHoGcTcFWac21mnFg5NuO2NXu+xFpmVRER0aGAgCN7Pdf3tPhGKvPav9APrYRe8BK9d NFdE+3oPxiFYm2vF+g1BXUlkLFfSQ==
IronPort-HdrOrdr: A9a23:c4n3i6G/W540kR2NpLqFXJHXdLJyesId70hD6qkvc3Jom52j+P xGws526fatskdsZJkh8erwXJVoMkmsiqKdhrNhcYtKPTOW9VdASbsC0WKM+UyZJ8STzJ8+6U 4kSdkCNDSSNyk0sS+Z2njCLz9I+rDum8rE5Za8854ud3ARV0gK1XYfNu/vKDwOeOAwP+teKH Pz3LsjmxOQPVAsKuirDHgMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlal9yZbdwkK7aYp8G DDnQC8zL6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+4kow3TX+0aVjbZaKv+/VQMO0aSSAZER4Z 3xSiIbTodOArXqDyaISFXWqk/dOX0VmgHfIBej8AreSIrCNWsH4w4rv/MDTvMfgHBQ5O2UmZ g7r16xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOLFuIIO5gLZvin+9Kq1wVR7S+cQiCq 1jHcvc7PFZfReTaG3YpHBmxJipUm4oFhmLT0AesojNugIm1kxR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY+8C3DLQxjLLGWOSG6XX50vKjbIsdr68b817OaldNgBy4Yzgo 3IVBdCuWs7ayvVeLqzNV1wg2TwqUmGLEHQI5tllutEU5XHNcjWDRE=
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+C66NJkVAgAELHHA=
Date: Wed, 04 Jan 2023 10:28:37 +0000
Message-ID: <MWHPR11MB1311520847F66668FD2CAFB1DAF59@MWHPR11MB1311.namprd11.prod.outlook.com>
References: <167084561141.46389.6261114964304426173@ietfa.amsl.com> <MWHPR11MB13115676FA84C5E316DBE9FBDAF49@MWHPR11MB1311.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR11MB13115676FA84C5E316DBE9FBDAF49@MWHPR11MB1311.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: lYZDFDGCS/d08dSFLwNkZdhjIIEGZJJ8WGtli+BrDD551W2YLNHnFZXGPXui1XxWUWkjkN2y22TLm/mNcWqs4Eu+DYcixfgie0UWTxIWUC8Nf3z4mykpLa15JvTJld0OnvcEH022H0e30JhIiLVh83g3DF9YM3p7QK7OkDtZ8bEgqBvqzBNIbWWEmHpOva0bwbHibWnlhnlJdJJKEO/jpZGjbNHZXoUgzrIVOHUF5EuUKZ06zcr/cMzNEFWkLUX9phxmiTr0+j8wT6PsZW1HqECmDU3p2rJSUVuFuS8vXpEzM95gI5xHje1/fZyPk+dBzrL/bQoX0L/3PXgXPEBMgB+Rm4iKHsd3WUmwDsrCx43RjY55/90Xzjw3FDiHUWXT1qLhnSINhKyYH+529n2n/xP4fiKIwPnkyWxQ9dLbOWl2G3FHftDZldocSAbfeMF82iloo4zEi5uaoDMp23qrWQNzIf37eGPHrV6RuyfXbxIeVNIPu+NHAIi9AgoCo3KWZ8cNBfPP7vgAGrI7GaxMWYTcAQEV9mllL7mcopmue2EP7FiEDcuI8TzeOea/3OgVcj0qpnt4Ss22yGcT1vlYDDVebjrhFC0RBNZPbVwP4f0jat30dRKUundGw6cLvAbqwi7CsoKA9C/Kt9JMCzW6dd8FoLE7i2b8TPtpK8POgsC30JREgs0NEUqclwCN+uXnkbDOQhVXD7HLK//FBUK4cLTN+VwoNY7syzfLuSiTSEfqRNgrB1CfYFXsUjHBCcWGQt7UdmzWPHrh/f4vcXbrxFRHx6vMMTnAZKHVXo15hM3mHxa4Akk9aBEhZnc5aPWKvHdeuRhcMHMhQmoAwG47a2+gLqCQXqG0FBbDKlN64FEWyLCEIQvLIJCne9bgr5LDmKpxsVpG/531REoV2R4H7oHXIsQ846oxw6doLrbP0IBFP076KyGfQkSHEBq0doAj7Hna+Jrzs6+smID8jUP6rLsI3NtemL9GkR/8pjl+Kz6fhkcPmiVpoCvIlss+PV7N/38yEsvDoF4k4PNlGj2NxbKeqLXmwf4WkP8VQRSvi8/MhTsFHGm3SLIzspxjtc523IYDgVhAbGa11AISaEoQcMweb8Y6r4bCFacPhJr9Tp+hO0d9DTvBts11ENbqGREKkZ1sBWnwvTLBMAaWaxiQEexpKMf+qvaHLwIciaMx6VUcCR8SNt0mHdxInhQWRpv9/yfmBjjeDuABAxR6MHQL7KACFgzrUY2taquc59IJ2jGbSP3ZwLn7XdareNKn0qTfWTJtr7igN7U0PoBKtnaye/TAIGklDG7ZtziFyYpEJOkvIfogMEdmX0k4Kz4ZbYzCKPHwYC/0EWtoiyk+0q6la2WbP9WvZNNM7/vqalFFoJllpm7kBhET26EZ1ueki/dum81xWvv0JA7UY0EMUYrFpNEnvKHuFLP7ojUC1MxFT5NvUljf5yNi2oi7RnCG9dviLWidI3Nn+uNpX2oXgYVgrzwjvUjoaJn8cg42E1MvjYIMsvhNl0I3KLEwigBSOhFZ6k/tQAdnBevbOgznP1Wg2HoyUiXYKFPvabk7WsDLB212Iv7ZTaX9E1yK4pZTeOAT
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: 8e8052a4-1d78-4c18-d253-08daee3e70b1
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2023 10:28:37.2118 (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: RM0h+/8QVp0yzp47VtVTkfKGLREFGu3hxmPn19M800IavRbQpvVE2lKdN0H0CqStc0sc5rlQ5aJnjjEMevMhjg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR11MB7553
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.227.250, xfe-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/6h7Wkl5mmrCGuGTg3tRl6mNFnAo>
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: Wed, 04 Jan 2023 10:28:54 -0000

Hi Lars, team,

FYI - I've just posted yet another revision (https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-deployment-05.txt) which now also includes the most recent boilerplate for the Copyright Notice section (updating xml2rfc to the latest version fixed the issue for me) - and fixes a few minor typos.

Cheers, Frank

> -----Original Message-----
> From: Frank Brockners (fbrockne)
> Sent: Tuesday, 3 January 2023 19:38
> To: Lars Eggert <lars@eggert.org>; The IESG <iesg@ietf.org>
> Cc: draft-ietf-ippm-ioam-deployment@ietf.org; ippm-chairs@ietf.org;
> ippm@ietf.org; tpauly@apple.com
> Subject: RE: Lars Eggert's No Objection on draft-ietf-ippm-ioam-deployment-02:
> (with COMMENT)
> 
> 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)