Re: [auth48] AUTH48: RFC-to-be 9550 <draft-ietf-detnet-pof-11> for your review

[Balázs Varga A <[e-mail]>]

Hi RFC Editor/rv,
Many thanks for your detailed review and proposed changes.
My replies inline marked with <BalazsV>. Please, let us know if further clarification needed.
I will reach out to co-authors regarding your first comment.
Again, many thanks for your efforts
Bala'zs

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Saturday, March 2, 2024 2:40 AM
To: Balázs Varga A <[e-mail]>; Janos Farkas <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: AUTH48: RFC-to-be 9550 <draft-ietf-detnet-pof-11> for your review

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.


1) <!-- [rfced] This is a question for Stephan and Tobias. Would you like to use a shortened form of your affiliation in the first-page header and then the full name in the Authors' Addresses section? Please review the first-page header in each of the output formats (txt, html, and pdf), and let us know your thoughts.
-->


2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. -->
<BalazsV> I think no further keywords needed.

3) <!-- [rfced] Would it be helpful to revise this sentence to state that "[RFC8655] defines" rather than "The DetNet Working Group has defined"?
In addition, please clarify "but without any implementation details" in the second sentence below.

Original:
   The DetNet Working Group has defined packet replication (PRF) and
   packet elimination (PEF) functions for achieving extremely low packet
   loss.  PRF and PEF are described in [RFC8655] and provide service
   protection for DetNet flows.  
   ...
   The IETF DetNet WG has defined
   in [RFC8655] the external observable result of a POF function, i.e.,
   that packets are reordered, but without any implementation details.   

Perhaps: 
   [RFC8655] defines the Packet Replication Function
   (PRF) and Packet Elimination Function (PEF) in DetNet for achieving extremely
   low packet loss. PRF and PEF provide service protection for DetNet flows.
   ...   
   [RFC8655] defines the external observable result of a POF
   function (i.e., that packets are reordered) but does not specify any implementation
   details.
-->

<BalazsV> Your proposal is perfect.
OLD TEXT:
   The DetNet Working Group has defined packet replication (PRF) and
   packet elimination (PEF) functions for achieving extremely low packet
   loss.  PRF and PEF are described in [RFC8655] and provide service
   protection for DetNet flows.  
   ...
   The IETF DetNet WG has defined
   in [RFC8655] the external observable result of a POF function, i.e.,
   that packets are reordered, but without any implementation details.   

NEW TEXT: 
   [RFC8655] defines the Packet Replication Function
   (PRF) and Packet Elimination Function (PEF) in DetNet for achieving extremely
   low packet loss. PRF and PEF provide service protection for DetNet flows.
   ...   
   [RFC8655] defines the external observable result of a POF
   function (i.e., that packets are reordered) but does not specify any implementation
   details.
END


4) <!-- [rfced] Please confirm that [RFC8655] is correct here. We believe it is correct, but we want to make sure. We see "sequence number" and "encapsulation" in RFC 8655 but not used together.

Original:
   This can be
   done by adding a sequence number as part of DetNet encapsulation
   [RFC8655].  
-->
<BalazsV> Yes confirmed. [RFC8655] is correct here.

5) <!-- [rfced] Are the parentheses needed here with "DetNet"?

Original:
   POF ensures in-order delivery for packets being within the latency bound of
   the (DetNet) flow. 

Perhaps: 
   POF ensures in-order delivery for packets within the latency bound of
   the DetNet flow. 
-->
<BalazsV> No parentheses needed here. Your proposed change is perfect.
OLD TEXT:
   POF ensures in-order delivery for packets being within the latency bound of
   the (DetNet) flow. 
NEW TEXT: 
   POF ensures in-order delivery for packets within the latency bound of
   the DetNet flow.
END

6) <!-- [rfced] The title of Section 3 uses "POF Implementations", but the first sentence in the section uses "POF function". Should these be consistent?

Original:
   3.  Requirements on POF Implementations

      The requirements on a POF function are:

Perhaps: 
   3.  Requirements for POF Implementations

      The requirements for POF implementations are:
-->
<BalazsV> Consistency is important. Your proposed change is perfect.
OLD TEXT:
   3.  Requirements on POF Implementations
      The requirements on a POF function are:
NEW TEXT: 
   3.  Requirements for POF Implementations
      The requirements for POF implementations are:
END

7) <!-- [rfced] Would moving "in network nodes" to the end of the sentence improve readability? Also, please review "states/configuration parameters and resources". Specifically, is "states" separate from "configuration parameters", or does "states/configuration" describe the type of parameters?

Original:
   *  to be simple and to require in network nodes only a minimum set of
      states/configuration parameters and resources per DetNet Flow.

Perhaps:
   *  To be simple and to require only a minimum set of
      states, configuration parameters, and resources per DetNet flow in network nodes.

Or ("states" to "state"):
   *  To be simple and to require only a minimum set of
      state/configuration parameters and resources per DetNet flow in network nodes.
-->
<BalazsV> Your proposed change reads better. Yes, "states" are separate from "configuration parameters".
OLD TEXT:
   *  to be simple and to require in network nodes only a minimum set of
      states/configuration parameters and resources per DetNet Flow.
NEW TEXT:
   *  To be simple and to require only a minimum set of
      states, configuration parameters, and resources per DetNet flow in network nodes.
END

8) <!-- [rfced] The text above Figure 2 uses "Conditional buffer", but Figure 2 uses "Conditional Delay Buffer". Should the figure be updated for consistency with the text or vice versa?
-->
<BalazsV> Right. Please, change text to use "Conditional Delay Buffer".

9) <!-- [rfced] Please review "the difference of sequence number" in these sentences. Is the intended meaning "the difference between sequence numbers"?
     
Original:
   Note: the difference of sequence number in consecutive packets is
   bounded due to the history window of the Elimination function before
   the POF.  
   ...
   For example, under normal
   circumstances the difference of sequence number in consecutive
   packets is bounded due to the history window of PEF.    

Perhaps:
   The difference between sequence numbers in consecutive packets is
   bounded due to the history window of the elimination function
   before the POF.  
   ...
   For example, under normal
   circumstances, the difference between sequence numbers in consecutive
   packets is bounded due to the history window of PEF. 
-->
<BalazsV> Right. Confirmed, that it means "the difference between sequence numbers".
Your proposal is OK.
OLD TEXT:
   Note: the difference of sequence number in consecutive packets is
   bounded due to the history window of the Elimination function before
   the POF.  
   ...
   For example, under normal
   circumstances the difference of sequence number in consecutive
   packets is bounded due to the history window of PEF.    
NEW TEXT:
   The difference between sequence numbers in consecutive packets is
   bounded due to the history window of the elimination function
   before the POF.  
   ...
   For example, under normal
   circumstances, the difference between sequence numbers in consecutive
   packets is bounded due to the history window of PEF.
END


10) <!-- [rfced] We updated "Packets being in order" as shown below. Please review.

Original:
   Packets being in order are not delayed. 

Updated:
   In-order packets are not delayed.
-->
<BalazsV> Right. Your proposal is OK.
OLD TEXT:
   Packets being in order are not delayed. 
NEW TEXT:
   In-order packets are not delayed.
END

11) <!-- [rfced] Please confirm that "relations" is the correct word choice here. 

Original:
   Figure 3 shows the delay budget relations at the POF point.
   ...
   Figure 3: Delay Budget Relations at the POF Point

Perhaps:
   Figure 3 shows the relationship between delay budgets at the POF point.
   ...
   Figure 3: Relationship between Delay Budgets at the POF Point
-->
<BalazsV> Right. "relations" is not the correct word here. Using "situation" would be better.
OLD TEXT:
   Figure 3 shows the delay budget relations at the POF point.
   ...
   Figure 3: Delay Budget Relations at the POF Point
NEW TEXT:
   Figure 3 shows the delay budget situation at the POF point.
   ...
   Figure 3: Delay Budget Situation at the POF Point
END

12) <!-- [rfced] In the text introducing the list, may we update "needs two extensions of" in one of the following ways to improve clarity?

Original:
   The advanced POF algorithm needs two extensions of the basic POF
   algorithm:

   *  to identify the received packet's path at the POF location and

   *  to make the value of "POFMaxDelay" for buffered packets path
      dependent ("POFMaxDelay_i", where "i" notes the path the packet
      has used).
   
Perhaps: 
   The advanced POF algorithm extends the basic POF
   algorithm:

   *  to identify the received packet's path at the POF location and

   *  to make the value of "POFMaxDelay" for buffered packets path
      dependent ("POFMaxDelay_i", where "i" notes the path the packet
      has used).

Or:
   The advanced POF algorithm requires extensions of the basic POF
   algorithm:

   *  to identify the received packet's path at the POF location and

   *  to make the value of "POFMaxDelay" for buffered packets path
      dependent ("POFMaxDelay_i", where "i" notes the path the packet
      has used).
-->
<BalazsV> Right. Your second proposal is OK.
OLD TEXT:
   The advanced POF algorithm needs two extensions of the basic POF
   algorithm:
   *  to identify the received packet's path at the POF location and
   *  to make the value of "POFMaxDelay" for buffered packets path
      dependent ("POFMaxDelay_i", where "i" notes the path the packet
      has used).
NEW TEXT:
   The advanced POF algorithm requires extensions of the basic POF
   algorithm:
   *  to identify the received packet's path at the POF location and
   *  to make the value of "POFMaxDelay" for buffered packets path
      dependent ("POFMaxDelay_i", where "i" notes the path the packet
      has used).
END

13) <!-- [rfced] How may we clarify the beginning of this sentence (i.e., "By....information")? Also, should "POFMaxDelay_i" appear in parentheses?

Original:
   By identifying the path of a given packet, the POF algorithm can use
   this information to select what predefined time "POFMaxDelay_i" to
   apply for the buffered packet.  

Perhaps: 
   The POF algorithm identifies the path of a given packet and uses
   this information to select the predefined time ("POFMaxDelay_i") to
   apply for the buffered packet.  
-->
<BalazsV> Right. Your proposal is OK.
OLD TEXT:
   By identifying the path of a given packet, the POF algorithm can use
   this information to select what predefined time "POFMaxDelay_i" to
   apply for the buffered packet.  
NEW TEXT: 
   The POF algorithm identifies the path of a given packet and uses
   this information to select the predefined time ("POFMaxDelay_i") to
   apply for the buffered packet.  
END

14) <!-- [rfced] We are having trouble understanding the text in the parenthetical (i.e., "e.g., replication...PathID"). Please clarify.

Original:
   It can be implemented via
   various techniques, for example using ingress interface information,
   encoding the path in the packet itself (e.g., replication functions
   can set different FlowID per egress what can be used as a PathID), or
   in other means.  

Perhaps: 
   It can be implemented via
   various techniques, for example, using ingress interface information,
   encoding the path in the packet itself (e.g., replication functions
   can set a different FlowID per egress, which can be used as a PathID), or
   other means.  
-->
<BalazsV> Right. Your proposal is somewhat finetuned. Please, let us know if further clarification needed.
OLD TEXT:
   It can be implemented via
   various techniques, for example using ingress interface information,
   encoding the path in the packet itself (e.g., replication functions
   can set different FlowID per egress what can be used as a PathID), or
   in other means.  
NEW TEXT: 
   It can be implemented via
   various techniques, for example, using ingress interface information,
   encoding the path in the packet itself (e.g., replication functions
   set a different FlowID per member flows at their egress and such 
   a FlowID is used to identify the path of a packet at the POF), or
   other means.  
END

15) <!-- [rfced] Please review "for example" here. Is it needed, or would it be more clear if placed elsewhere in the sentence?

Original:
   The challenge for POF initialization is that for example after a
   reset it is not known whether the first received packet is in-order
   or out-of-order.  

Perhaps:
   The challenge for POF initialization is that it is not known whether the
   first received packet is in order or out of order (for example, after a
   reset).

Or:
   The challenge for POF initialization is that after a
   reset, it is not known whether the first received packet is in-order
   or out-of-order.  
-->
<BalazsV> Right. Your first proposal is OK. 
OLD TEXT:
   The challenge for POF initialization is that for example after a
   reset it is not known whether the first received packet is in-order
   or out-of-order.  
NEW TEXT:
   The challenge for POF initialization is that it is not known whether the
   first received packet is in order or out of order (for example, after a
   reset).
END


16) <!-- [rfced] Should "(see before)" be updated to a specific section? If not, we will update to "(see above)".
Original:
   The original initialization (see before) considers
   the first packet as in-order, so out-of-order packet(s) during
   "POFMaxTime"/"POFMaxTime_path_i" time - after the first packet was
   received - cannot be corrected.  
-->
<BalazsV> Right. Better to add an explicit reference to Section 4.3. Please change as follow:
OLD TEXT:
   The original initialization (see before) considers
   the first packet as in-order, so out-of-order packet(s) during
   "POFMaxTime"/"POFMaxTime_path_i" time - after the first packet was
   received - cannot be corrected.  
NEW TEXT:
   The original initialization (see Section 4.3) considers
   the first packet as in-order, so out-of-order packet(s) during
   "POFMaxTime"/"POFMaxTime_path_i" time - after the first packet was
   received - cannot be corrected.  
END

17) <!-- [rfced] Will "basic/advanced" be clear to readers? 

Original:
   *  No basic/advanced POF rules are applied until the first timer
      expires.
      ...
   *  The basic/advanced POF rules are applied for the packet(s) in the
      buffer and the subsequently received packets.

Perhaps: 
   *  No basic or advanced POF rules are applied until the first timer
      expires.
      ...
   *  The basic or advanced POF rules are applied for the packet(s) in the
      buffer and the subsequently received packets.
-->
<BalazsV> Right. No strong preference here. Your change is OK.
OLD TEXT:
   *  No basic/advanced POF rules are applied until the first timer
      expires.
      ...
   *  The basic/advanced POF rules are applied for the packet(s) in the
      buffer and the subsequently received packets.
NEW TEXT: 
   *  No basic or advanced POF rules are applied until the first timer
      expires.
      ...
   *  The basic or advanced POF rules are applied for the packet(s) in the
      buffer and the subsequently received packets.
END

18) <!-- [rfced] How may we update "needs setting of" in this sentence?
	   
Original:
   POF algorithms needs setting of the following parameters:

Perhaps: 
   The following parameters should be set for POF algorithms:

Or:
   POF algorithms require the following parameters to be set:
-->
<BalazsV> Right. No strong preference here. Slightly prefer Your second version.
OLD TEXT:
   POF algorithms needs setting of the following parameters:
NEW TEXT:
   POF algorithms require the following parameters to be set:
END

19) <!-- [rfced] We tried to access the URL in this reference entry, but it is behind a sign-in wall. Also, it looks like this reference entry points to a draft that has now been published. May use one of the following URLs and update the rest of the entry accordingly (e.g., title, DOI, and date)?

Possible URLs:
https://standards.ieee.org/ieee/802.1CBcv/7285/
https://ieeexplore.ieee.org/document/9715061

Original:
   [IEEEP8021CBcv]
              Kehrer, S., "FRER YANG Data Model and Management
              Information Base Module", IEEE P802.1CBcv
              /D1.2 P802.1CBcv, March 2021,
              <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-3e5e7c6dcc50f3ea&q=1&e=f2d48fdf-37cd-4595-a8fa-4cf3226814ef&u=https%3A%2F%2Fwww.ieee802.org%2F1%2Ffiles%2Fprivate%2Fcv-drafts%2Fd1%2F802-
              1CBcv-d1-2.pdf>.

Perhaps:
   [IEEEP8021CBcv]
             IEEE, "IEEE Standard for Local and metropolitan area networks - Frame
             Replication and Elimination for Reliability - Amendment 1: Information
	     Model, YANG Data Model, and Management Information Base Module,
             IEEE Std 802.1CBcv-2001, DOI 10.1109/IEEESTD.2022.9715061, February 2022,
             <https://standards.ieee.org/ieee/802.1CBcv/7285/>.
-->
<BalazsV> Thanks. Your change is correct.
OLD TEXT:
   [IEEEP8021CBcv]
              Kehrer, S., "FRER YANG Data Model and Management
              Information Base Module", IEEE P802.1CBcv
              /D1.2 P802.1CBcv, March 2021,
              <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-3e5e7c6dcc50f3ea&q=1&e=f2d48fdf-37cd-4595-a8fa-4cf3226814ef&u=https%3A%2F%2Fwww.ieee802.org%2F1%2Ffiles%2Fprivate%2Fcv-drafts%2Fd1%2F802-
              1CBcv-d1-2.pdf>.
NEW TEXT:
   [IEEEP8021CBcv]
             IEEE, "IEEE Standard for Local and metropolitan area networks - Frame
             Replication and Elimination for Reliability - Amendment 1: Information
	     Model, YANG Data Model, and Management Information Base Module,
             IEEE Std 802.1CBcv-2001, DOI 10.1109/IEEESTD.2022.9715061, February 2022,
             <https://standards.ieee.org/ieee/802.1CBcv/7285/>.
END

20) <!-- [rfced] We updated these names in the Acknowledgements section. Please review and let us know any concerns.

a) Per https://datatracker.ietf.org/person/[e-mail]:

Original:
  Mohammadpour Ehsan

Updated:
  Ehsan Mohammadpour 


b) Per https://datatracker.ietf.org/person/[e-mail]:

Original:
  Shirley Yangfan

Updated:
  Fan Yang
-->
<BalazsV> Thanks. Your change is correct.


21) <!-- [rfced] Should "algorithm" be updated to "algorithms" (plural) in the following sentences as both a basic and advanced POF algorithm are defined in Section 4? Or in some of these instances (perhaps the last two below), is the intent to say "the basic POF algorithm" or "the advanced POF algorithm"?

Original:
   The Packet Ordering Function (POF)
   algorithm described herein enables to restore the correct packet
   order when replication and elimination functions are used in DetNet
   networks.  
   ...
   4.6.  Selecting and using the POF algorithm
   ...
   The POF Algorithm discussed in this document makes some assumptions
   and tradeoffs regarding the characteristics of the sequence of
   received packets.
   ...
   In particular, the algorithm assumes that a Packet
   Elimination Function (PEF) is performed on the incoming packets
   before they are handed to the POF function.
   ...
   The algorithm further requires that the delay difference between two
   replicated packets that arrive at the PEF before the POF is bounded
   and known.
   ...
   The algorithm also makes some tradeoffs.
   ...
   Note2: The algorithm can be extended to cope with multiple failure
   scenarios (i.e., simultaneous packet loss and out-of-order packets), ...
   ...
   By identifying the path of a given packet, the POF algorithm can use
   this information to select what predefined time "POFMaxDelay_i" to
   apply for the buffered packet.  
-->
<BalazsV> Thanks. Using plural is better in this text, except the last two places, where explicit reference is OK.
OLD TEXT:
   The Packet Ordering Function (POF)
   algorithm described herein enable to restore the correct packet
   order when replication and elimination functions are used in DetNet
   networks.  
   ...
   4.6.  Selecting and using the POF algorithm
   ...
   The POF Algorithms discussed in this document makes some assumptions
   and tradeoffs regarding the characteristics of the sequence of
   received packets.
   ...
   In particular, the algorithm assumes that a Packet
   Elimination Function (PEF) is performed on the incoming packets
   before they are handed to the POF function.
   ...
   The algorithm further requires that the delay difference between two
   replicated packets that arrive at the PEF before the POF is bounded
   and known.
   ...
   The algorithm also makes some tradeoffs.
   ...
   Note2: The algorithm can be extended to cope with multiple failure
   scenarios (i.e., simultaneous packet loss and out-of-order packets), ...
   ...
   By identifying the path of a given packet, the POF algorithm can use
   this information to select what predefined time "POFMaxDelay_i" to
   apply for the buffered packet.  
NEW TEXT:
   The Packet Ordering Function (POF)
   algorithms described herein enables to restore the correct packet
   order when replication and elimination functions are used in DetNet
   networks.  
   ...
   4.1.  Prerequisites and Assumptions
   ...
   The POF Algorithms discussed in this document makes some assumptions
   and tradeoffs regarding the characteristics of the sequence of
   received packets.
   ...
   In particular, the algorithms assume that a Packet
   Elimination Function (PEF) is performed on the incoming packets
   before they are handed to the POF function.
   ...
   The algorithms further require that the delay difference between two
   replicated packets that arrive at the PEF before the POF is bounded
   and known.
   ...
   The algorithms also make some tradeoffs.
   ...
   4.3.  The Basic POF Algorithm
   ...
   Note2: The basic POF algorithm can be extended to cope with multiple failure
   scenarios (i.e., simultaneous packet loss and out-of-order packets), ...
   ...
   4.4.  The Advanced POF Algorithm
   ...
   By identifying the path of a given packet, the advanced POF algorithm can use
   this information to select what predefined time "POFMaxDelay_i" to
   apply for the buffered packet.  
END

22) <!-- [rfced] Terminology

a) We see inconsistency in the capitalization of the following. We updated to use the lowercase form. Please let us know any objections.

Replication and Elimination function
replication and elimination functions
replication function
Elimination function

<BalazsV> OK to use lowercase, except in Section "2.2.  Abbreviations".

b) Should "function" be removed in these instances because the expansion of the acronym already includes the word "Function"? For example, if expanded, "POF function" would read "Packet Ordering Function function".

PEF function
POF function
PREOF functions

<BalazsV> Yes, please remove "function".

c) Use of quotation marks for the following terms is inconsistent. Please review and let us know how to update for consistency.

"POFLastSent" vs. POFLastSent

"POFMaxDelay" vs. POFMaxDelay

"POFMaxDelay_i"

"POFMaxTime"/"POFMaxTime_path_i"

"POFTakeAnyTime"

<BalazsV> Hhmmm. Right. The intention was to use "POFLastSent" in descriptive text and use POFLastSent in mathematical formulas.
Would that make sense for You?
One good example is in Section 4.3.  The Basic POF Algorithm, where "" used as per our intention:
   ...
   *  If (seq_num <= POFLastSent + 1)
      -  Then the packet is forwarded without buffering and
         "POFLastSent" is updated (POFLastSent = seq_num).

Unfortunately bad examples also in the same section, which needs correction:
OLD TEXT
   *  The sequence number of the last forwarded packet (POFLastSent) is
      stored for each DetNet Flow.
   *  The sequence number (seq_num) of a received packet is compared to
      that of the last forwarded one (POFLastSent).
NEW TEXT
   *  The sequence number of the last forwarded packet ("POFLastSent") is
      stored for each DetNet Flow.
   *  The sequence number ("seq_num") of a received packet is compared to
      that of the last forwarded one ("POFLastSent").
END
Could You make the changes accordingly?

d) Please review the usage of the articles "a" or "the" with PEF, PRF, and POF when used as a noun. An article is used in some instances but not others. Are any updates needed, or is the current usage acceptable? This may be on a case-by-case basis. A few examples with and without the article are listed below.

Some examples with article (the POF, the POF, the PEF):

   Note: the difference of sequence number in consecutive packets is
   bounded due to the history window of the Elimination function before
   the POF.  

   Error cases in which duplicate packets are
   presented to the POF can lead to out of order delivery of duplicate
   packets as well as to increased delays.

   The algorithm further requires that the delay difference between two
   replicated packets that arrive at the PEF before the POF is bounded
   and known. 

Some examples with no article (PEF, POF, POF):

   For example, under normal
   circumstances the difference of sequence number in consecutive
   packets is bounded due to the history window of PEF.  

   POF only provides ordering within the latency bound of a
   DetNet flow, and does not provide any additional reliability.

   POF ensures in-order delivery for packets being within the latency
   bound of the (DetNet) flow.  POF does not correct errors in the
   packet flow e.g., duplicate packets, too late packets.
-->
<BalazsV> Right. As a non-native speaker, I have to admit having issues with articles. Sorry for that. I would trust your suggestions.


23) <!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
<BalazsV> Notes are important and related to the content that surrounds it. No need to use <aside> in our understanding.

24) <!-- [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. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice.
-->
<BalazsV> Review done. No changes needed.


Thank you.

RFC Editor/rv



On Mar 1, 2024, at 5:32 PM, [e-mail] wrote:

*****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/rfc9550.xml
  https://www.rfc-editor.org/authors/rfc9550.html
  https://www.rfc-editor.org/authors/rfc9550.pdf
  https://www.rfc-editor.org/authors/rfc9550.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9550-diff.html
  https://www.rfc-editor.org/authors/rfc9550-rfcdiff.html (side by side)

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9550-xmldiff1.html

Alt-diff of the text (allows you to more easily view changes where text has been deleted or moved): 
  https://www.rfc-editor.org/authors/rfc9550-alt-diff.html

The following files are provided to facilitate creation of your own diff files of the XML.  

Initial XMLv3 created using XMLv2 as input:
  https://www.rfc-editor.org/authors/rfc9550.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates
only: 
  https://www.rfc-editor.org/authors/rfc9550.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9550

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9550 (draft-ietf-detnet-pof-11)

Title            : Deterministic Networking (DetNet): Packet Ordering Function
Author(s)        : B. Varga, J. Farkas, S. Kehrer, T. Heer
WG Chair(s)      : Lou Berger, János Farkas

Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston