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

[Rebecca VanRheenen <[e-mail]>]

Hi Bala’zs,

Thank you for responding to our questions! We have updated the document per your responses and have a few followup questions/comments:


1) This question for Stephan and Tobias is still open:

> 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) Please review “POF functionality” here. Should this be updated to “POF”, or is the current okay?

Original:
   *  to eliminate the delay variation caused by the packet ordering.
      Dealing with delay variation is a DetNet forwarding sub-layer
      target and it can be achieved for example by placing a de-jitter
      buffer or flow regulator (e.g., shaping) function after the POF
      functionality.


3) Should “POF” in this sentence be updated to “POF algorithms”? We ask because the title of the section is “Selecting and Using the POF Algorithms”.

Current:
   Using the POF and
   calculating its parameters require proper design.  

Perhaps:
   Using the POF algorithms and
   calculating their parameters require proper design.  


4) Regarding this question:

>> 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.

We updated to use articles in several instances as we see that usage in RFC 8655 (normatively referenced by this document). Please review.

_______________

Updated XML file:
   https://www.rfc-editor.org/authors/rfc9550.xml

Updated output files:
   https://www.rfc-editor.org/authors/rfc9550.txt
   https://www.rfc-editor.org/authors/rfc9550.pdf
   https://www.rfc-editor.org/authors/rfc9550.html

Diff file showing all changes made during AUTH48:
   https://www.rfc-editor.org/authors/rfc9550-auth48diff.html

Diff files showing all changes:
   https://www.rfc-editor.org/authors/rfc9550-diff.html
   https://www.rfc-editor.org/authors/rfc9550-rfcdiff.html (side-by-side diff)
   https://www.rfc-editor.org/authors/rfc9550-alt-diff.html (diff showing changes where text is moved or deleted)

Note that it may be necessary for you to refresh your browser to view the most recent version. 

For the AUTH48 status of this document, please see:
   https://www.rfc-editor.org/auth48/rfc9550

Thank you,
RFC Editor/rv




> On Mar 5, 2024, at 1:36 AM, Balázs Varga A <balazs.a.varga=[e-mail]> wrote:
> 
> 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