[ippm] Re: AD Review of draft-ietf-ippm-qoo

[Ike Kunze <[e-mail]>]

Hi Med,

Thank you very much for your feedback and suggestions!
We have gone through the annotated pdf and have addressed all your comments.

I will briefly comment on how we have addressed your major comments below inline, indicated with [IK].

Please let us know if you see the need for any additional changes or if you would like a detailed description of how we have addressed your comments from the annotated pdf.

Thanks again.

Cheers,
Ike


Friendly Note: I send emails at times that work best for me. Please don’t feel any pressure to reply outside your usual working hours.


[Background pattern  Description automatically generated]

Ike Kunze

Senior Researcher

Phone [phone]

CUJO AI<https://cujo.com/> | News <https://cujo.com/blog/> | LinkedIn<https://www.linkedin.com/company/cujoai>


From: [e-mail] <[e-mail]>
Date: Wednesday, 12 November 2025 at 14:44
To: [e-mail] <[e-mail]>, IETF IPPM WG <[e-mail]>
Subject: [ippm] AD Review of draft-ietf-ippm-qoo

Hi Bjørn, Magnus, and IPPM,

Many thanks for the effort put into this well-written document. Thanks for the insights and various practical advices in the document.

As a preparation to the IETF Last Call, I performed my AD review of the document. I have a set of comments, suggestions, and edits that you can find in the detailed review below. Most of the comments are easy to fix. Major comments are:


  *
Need to clarify early in the document that the framework is about network performance requirements, not **all** network requirements.

[IK] We now consistently use the term network performance requirements.


  *   Indicate early in the document that it is out of scope to cover the following
     *   How applications defines and share their network requirements.
     *   Which format is used to publish such information
     *
How operators retrieve such data

[IK] We have added a corresponding paragraph at the end of the Introduction.



  *
As communications are likely to span multiple administrative domains, I think that we need to clearly characterize what is meant by “network” in the doc. The current definition entry in Section 3 should be updated. As I’m there, that definition seems like it assume point to point communications, while other forms of communication can be supported by a network (multicast, etc.). Please fix that as well.

[IK] We have updated the network definition as follows:

The communication infrastructure that facilitates data transmission between endpoints, including all intermediate devices, links, and protocols that affect the transmission of data.  This encompasses both the physical infrastructure and the logical protocols that govern data transmission.  The network may support various communication patterns and may span multiple administrative domains.
Does this work for you?



  *
Also, connectivity issues may be encountered in the customer-facing network, in-between, or at the server/remote side. As such, the target perimeter of the framework should be made better early in the doc.

[IK] We added an additional paragraph in the introduction that makes it clear that the QoO framework can, in principle, used in all of these environments, depending on what measurements are performed.



  *
The use of “perfect” is a bit unfortunate IMO. Typically, a network may be designed to accommodate a variety of applications. The delivered connectivity service may be nominal for some applications, but not for all under some conditions. Not sure what “perfect” would mean in such cases. Some tweaking of the text may needed to convey the intent. BTW, “Optimal” or “Nominal” or “optimized Performance” would be more appropriate as I don’t think we can reason about “perfect” conditions, in general.

[IK] We switched to “optimal” throughout the document.



  *
The assumption in the document is that the measured perf will reflect the perf of actual connectivity service that will be provided to that application flows. However, there might be several connectivity service levels offered by a same network (e.g., VPN services, corporate customers, network slicing). There is a challenge about how to bind the measurement and the actual network configuration that will deliver related flows. I think these deployment assumptions should be called out.

[IK] You had several comments in this direction. To address them, we have added a corresponding subsection on deployment considerations. Does this work for you or would you rather have more explicit statements throughout the document?



  *
I tagged at least three references that need to be listed as normative. Please check and fix those.

[IK] Done.


  *
The QoO score definition does not cover the directionality. Should such aspect be reminded in Section 7?

[IK] Instead of defining the QoO score as a per-direction metric, we added the following paragraph after the the “Calculating QoO”-introduction and before the description of the calculation.

Note that the QoO score should reflect the directionality of the measurements
(one-way or round-trip) as specified in the network performance requirements. When comparing
measurements to requirements, both must use the same directionality and, for
one-way measurements, the same direction (uplink or downlink).
Does this work for you?


  *   Group Ops matters under an “Operational Considerations” Section per the guidance in draft-opsarea-rfc5706bis.

[IK] Added an “operational considerations” section and discussed several considerations. Please let us know if you see the need to cover additional aspects.


FWIW, the detailed review can be found at:


  *   pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-ippm-qoo-04-rev%20Med.pdf
  *   doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-ippm-qoo-04-rev%20Med.doc

Please let me know if any clarification is needed.

Thank you.

Cheers,
Med

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.