[ippm] Re: [Tsv-art] Tsvart ietf last call review of draft-ietf-ippm-capacity-protocol-14

[[e-mail]]

Hi Lars,

As with any design, there might be alternative ways with each having pros/cons, including implications on the deployment model.

That’s said, and as you rightfully mentioned, this comment is not actionable at this stage especially that this work stared since 2021 and leverages effort/implementation work done in other SDOs (e.g., https://github.com/BroadbandForum/obudpst) The design is also aligned with how protocols in this field were designed (OWAMP, TWAMP, STAMP, etc.). 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : Lars Eggert <[e-mail]>
> Envoyé : mercredi 11 juin 2025 11:21
> À : [e-mail]
> Cc : Magnus Westerlund <[e-mail]>; tsv-
> [e-mail]; [e-mail]; draft-ietf-ippm-capacity-
> [e-mail]; [e-mail]; [e-mail]; BOUCADAIR
> Mohamed INNOV/NET <[e-mail]>
> Objet : Re: [Tsv-art] Tsvart ietf last call review of draft-ietf-
> ippm-capacity-protocol-14
> 
> 
> Hi,
> 
> On Jun 11, 2025, at 11:47, [e-mail] wrote:
> > Apart from these, Med and Lars had minor comments and nits, which
> should be addressed by this version too. Lars raised concerns with
> the term "traditional", which aren't addressed by this version.
> 
> I also said
> 
> > Major issues:
> >
> > I'm kinda sad to see it's 2025 and we still invent new control
> > protocols, especially over UDP. Most of the complexity in this doc
> is
> > due to that. I can't see a requirement here that the control
> protocol (also) needs to run over UDP.
> > Can we not simply exchange JSON blobs over HTTPS to configure the
> > subsequent UDP testing flows? That should eliminate much of the
> > complexity here, and would probably be more extensible as well.
> 
> I appreciate that this probably isn't actionable at this time, but I
> do strongly believe that building these sorts of protocols from
> scratch is not something we should do anymore in 2025.
> 
> Thanks,
> Lars
> 

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