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

[Fabrice Theoleyre <[e-mail]>]

Dear Megan, 

Thank you very much. The current version seems valid to me.

For the keywords, I suggest to add:
Metrics
Tracing

Best regards,
Fabrice


> Le 5 mars 2024 à 01:56, Megan Ferguson <[e-mail]> a écrit :
> 
> Greg, Fabrice, Georgios, and Carlos,
> 
> Thank you for your replies.  We have updated accordingly.
> 
> Please review the files carefully as we do not make changes after publication.  
> 
> Note: we did not see anyone reply to the keywords request.  
> We will assume the words in the title are sufficient unless we hear otherwise.
> 
> The files have been posted here (please refresh):
>   https://www.rfc-editor.org/authors/rfc9551.txt
>   https://www.rfc-editor.org/authors/rfc9551.pdf
>   https://www.rfc-editor.org/authors/rfc9551.html
>   https://www.rfc-editor.org/authors/rfc9551.xml
> 
> The relevant diff files have been posted here (please refresh):
>   https://www.rfc-editor.org/authors/rfc9551-diff.html (comprehensive diff)
>   https://www.rfc-editor.org/authors/rfc9551-auth48diff.html (AUTH48 changes only)
>   https://www.rfc-editor.org/authors/rfc9551-lastdiff.html (last to current version only)
> 
> Please contact us with any further updates/questions/comments you may have.  
> 
> We will await approvals from each of the parties listed on the AUTH48 status page prior to moving forward to publication.  
> 
> The AUTH48 status page for this document is available here:
> 
> https://www.rfc-editor.org/auth48/rfc9551
> 
> Thank you.
> 
> RFC Editor/mf
> 
>> On Mar 4, 2024, at 6:50 AM, CARLOS JESUS BERNARDOS CANO <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Thanks. I don't have anything to add and I agree with the proposed changes and replies by the co-authors.
>> 
>> Carlos
>> 
>> On Mon, Mar 4, 2024 at 10:38 AM Georgios Z. Papadopoulos <[e-mail] <mailto:[e-mail]>> wrote:
>> Dear RFC editor,
>> 
>> Thank you for your work and comments.
>> 
>>> On 1 Mar 2024, at 20:08, [e-mail] wrote:
>>> 
>>> 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?-->
>>> 
>>> 
>>> 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.  -->
>> 
>> [GP] Many thanks. No 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.
>>> -->
>> 
>> [GP] +1
>> Thanks for the reformulation.
>> 
>>> 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.
>>> -->
>> 
>> [GP] +1
>> Thanks for the 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.
>>> 
>>> -->
>> 
>> [GP] +1
>> Thanks for the reformulation.
>> 
>>> 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? -->
>> 
>> [GP] +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.
>>> -->
>> 
>> [GP] +1
>> Thanks for the reformulation.
>> 
>>> 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.
>>> -->
>> 
>> [GP] +1
>> Thanks for the reformulation.
>> It makes more sense now indeed.
>> 
>>> 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
>>> 
>>> 
>>> -->
>>> 
>>> 
>>> Thank you.
>>> 
>>> RFC Editor/mf
>> 
>> 
>> Many thanks,
>> Georgios
>> 
>> 
>>> *****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