Re: [auth48] AUTH48: RFC-to-be 9551 <draft-ietf-detnet-oam-framework-11> for your review

[Fabrice Theoleyre <[e-mail]>]

Dear RFC editor,

Thank you for your proofreading and comments. 

Please find inline my comments.

> Le 1 mars 2024 à 20:08, [e-mail] a écrit :
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> 
> 1) <!--[rfced] Fabrice: we see a slightly different address in RFC 9450.
>     Please let us know if ICube Lab, Pole API should be added to this
>     document as well?-->

[FT] Yes, we could add "ICube Lab, Pole API", so that the addresses are consistent. 


> 2) <!--[rfced] Please note that the XML submitted had some author
>     comments that have since been deleted.  We assume all had been
>     reviewed.  Please let us know if this is in error. -->
> 
> 
> 3) <!--[rfced] Georgios: please note that we have updated the header to
>     use your single first initial as was done in RFC 9450.  Please
>     let us know any objections.  -->
> 
> 
> 4) <!-- [rfced] Please insert any keywords (beyond those that appear in
>     the title) for use on https://www.rfc-editor.org/search. -->
> 
> 
> 5) <!--[rfced] Is the following text equivalent to the original?  If so,
>     the "Perhaps" text may be clearer/easier for the reader.  If not,
>     please let us know how to rephrase.
> 
> Original:
> Specifically, it investigates the requirements for a deterministic
> network, supporting critical flows.
> 
> Perhaps:
> Specifically, it investigates the requirements for a deterministic
> network that supports critical flows.
> -->

[FT] It sounds perfect.


> 6) <!--[rfced] Please confirm that our updated text maintains your
>     intended meaning.
> 
> Original:
> DetNet expects to implement an OAM framework to maintain a real-time
> view of the network infrastructure, and its ability to respect the
> Service Level Objectives (SLOs), such as in-order packet delivery,
> packet delay, delay variation, and packet loss ratio, assigned to each
> DetNet flow.
> 
> Current:
> DetNet is expected to implement an OAM framework to maintain a
> real-time view of the network infrastructure, and its ability to
> respect the Service Level Objectives (SLOs), such as in-order packet
> delivery, packet delay, delay variation, and packet loss ratio,
> assigned to each DetNet flow.
> -->

[FT] thank you for this reformulation.

> 
> 7) <!--[rfced] Please review our updates to this paragraph to ensure we
>     have maintained your intended meaning.  Note that a similar
>     change was made in Section 2.
> 
> Original:
> 
>   This document lists the functional requirements toward OAM for a
>   DetNet domain.  The list can further be used for gap analysis of
>   available OAM tools to identify possible enhancements of existing
>   or whether new OAM tools are required to support proactive and
>   on-demand path monitoring and service validation.
> 
> Current:
> 
>   This document lists the OAM functional requirements for a DetNet
>   domain.  The list can further be used for gap analysis of available
>   OAM tools to identify:
> 
>   *  possible enhancements of existing tools, or
> 
>   *  whether new OAM tools are required to support proactive and on-
>      demand path monitoring and service validation.
> 
> -->

[FT] The new formulation improves the readability, thank you.

> 
> 8) <!--[rfced] As our policy is to expand abbreviations on first use, all
>     of the abbreviations in the "Abbreviations" sections have already
>     been introduced.  Additionally, there are a number of
>     abbreviations in the "Definitions" section.  Might it be better/
>     more consistent to cut the "Abbreviations" section? -->
> 
[FT] +1

> 9) <!--[rfced] Please review the use of "it" in the following sentence.
>     Does it refer to "set" (i.e., a set of SLOs is required for the
>     flows that the set generates)?  If not, please see the possible
>     rephrase below or let us know how we may clarify.
> 
> Original:
> Most critical applications will define a set of SLOs to be required
> for the DetNet flows it generates.
> 
> Perhaps:
> Most critical applications will define a set of SLOs to be required
> for the DetNet flows they generate.
> -->

[FT] Yes, you're right. Thank you for the correction.


> 10) <!--[rfced] In the following, may we cut "criteria" from this sentence
>     (as it seems to be the quality that degrades, not the criteria)?
> 
> Original:
>   Because the quality of service criteria associated with a path may
>   degrade, the network has to provision additional resources along
>   the path.
> 
> Perhaps:
>   Because the quality of service associated with a path may degrade,
>   the network has to provision additional resources along the path.
> -->
> 

[FT] Yes, the term "criterion" is here improperly used.

> 
> 11) <!--[rfced] We note that draft-mirsky-ippm-hybrid-two-step-15 is
>     listed in the datatracker as replaced by
>     draft-ietf-ippm-hybrid-two-step.  Please confirm that we may
>     update the reference to point to the latter. -->
> 
> 
> 12) <!-- [rfced] Please review the "Inclusive Language" portion of the
>     online Style Guide
>     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>     and let us know if any changes are needed.
> 
> 
> For example, please consider whether the following use of "natively"
> should be updated:
> 
> Original:
> ...IP data plane is natively in-band with respect to the monitored
> 
> 
> -->


[FT] "IP data plane is by design in-band with respect to the monitored"


Thank you for all your comments.

Best regards,
Fabrice 

> 
> 
> Thank you.
> 
> RFC Editor/mf
> 
> *****IMPORTANT*****
> 
> Updated 2024/03/01
> 
> RFC Author(s):
> --------------
> 
> Instructions for Completing AUTH48
> 
> Your document has now entered AUTH48.  Once it has been reviewed and 
> approved by you and all coauthors, it will be published as an RFC.  
> If an author is no longer available, there are several remedies 
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> 
> You and you coauthors are responsible for engaging other parties 
> (e.g., Contributors or Working Group) as necessary before providing 
> your approval.
> 
> Planning your review 
> ---------------------
> 
> Please review the following aspects of your document:
> 
> *  RFC Editor questions
> 
>   Please review and resolve any questions raised by the RFC Editor 
>   that have been included in the XML file as comments marked as 
>   follows:
> 
>   <!-- [rfced] ... -->
> 
>   These questions will also be sent in a subsequent email.
> 
> *  Changes submitted by coauthors 
> 
>   Please ensure that you review any changes submitted by your 
>   coauthors.  We assume that if you do not speak up that you 
>   agree to changes submitted by your coauthors.
> 
> *  Content 
> 
>   Please review the full content of the document, as this cannot 
>   change once the RFC is published.  Please pay particular attention to:
>   - IANA considerations updates (if applicable)
>   - contact information
>   - references
> 
> *  Copyright notices and legends
> 
>   Please review the copyright notice and legends as defined in
>   RFC 5378 and the Trust Legal Provisions 
>   (TLP – https://trustee.ietf.org/license-info/).
> 
> *  Semantic markup
> 
>   Please review the markup in the XML file to ensure that elements of  
>   content are correctly tagged.  For example, ensure that <sourcecode> 
>   and <artwork> are set correctly.  See details at 
>   <https://authors.ietf.org/rfcxml-vocabulary>.
> 
> *  Formatted output
> 
>   Please review the PDF, HTML, and TXT files to ensure that the 
>   formatted output, as generated from the markup in the XML file, is 
>   reasonable.  Please note that the TXT will have formatting 
>   limitations compared to the PDF and HTML.
> 
> 
> Submitting changes
> ------------------
> 
> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
> the parties CCed on this message need to see your changes. The parties 
> include:
> 
>   *  your coauthors
> 
>   *  [e-mail] (the RPC team)
> 
>   *  other document participants, depending on the stream (e.g., 
>      IETF Stream participants are your working group chairs, the 
>      responsible ADs, and the document shepherd).
> 
>   *  [e-mail], which is a new archival mailing list 
>      to preserve AUTH48 conversations; it is not an active discussion 
>      list:
> 
>     *  More info:
>        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> 
>     *  The archive itself:
>        https://mailarchive.ietf.org/arch/browse/auth48archive/
> 
>     *  Note: If only absolutely necessary, you may temporarily opt out 
>        of the archiving of messages (e.g., to discuss a sensitive matter).
>        If needed, please add a note at the top of the message that you 
>        have dropped the address. When the discussion is concluded, 
>        [e-mail] will be re-added to the CC list and 
>        its addition will be noted at the top of the message. 
> 
> You may submit your changes in one of two ways:
> 
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
> 
> Section # (or indicate Global)
> 
> OLD:
> old text
> 
> NEW:
> new text
> 
> You do not need to reply with both an updated XML file and an explicit 
> list of changes, as either form is sufficient.
> 
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text, 
> and technical changes.  Information about stream managers can be found in 
> the FAQ.  Editorial changes do not require approval from a stream manager.
> 
> 
> Approving for publication
> --------------------------
> 
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
> 
> 
> Files 
> -----
> 
> The files are available here:
>   https://www.rfc-editor.org/authors/rfc9551.xml
>   https://www.rfc-editor.org/authors/rfc9551.html
>   https://www.rfc-editor.org/authors/rfc9551.pdf
>   https://www.rfc-editor.org/authors/rfc9551.txt
> 
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9551-diff.html
>   https://www.rfc-editor.org/authors/rfc9551-rfcdiff.html (side by side)
> 
> Diff of the XML: 
>   https://www.rfc-editor.org/authors/rfc9551-xmldiff1.html
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>   https://www.rfc-editor.org/auth48/rfc9551
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9551 (draft-ietf-detnet-oam-framework-11)
> 
> Title            : Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet)
> Author(s)        : G. Mirsky, F. Theoleyre, G. Papadopoulos, C. Bernardos, B. Varga, J. Farkas
> WG Chair(s)      : Lou Berger, János Farkas
> 
> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> 
>