[ippm] Re: Review of draft-ietf-ippm-capacity-protocol-12 / part 4 [76]-[102]

[[e-mail]]

Hi Ruediger,

We should definitely leave 20- in the IETF range. That value will be allocated for this doc.

The bit boundaries do not matter much here as we always use the same nb of bits to encode the version (Figure 2). That's said, my brain would be more comfortable with 20-40599.

Cheers,
Med

De : [e-mail] <[e-mail]>
Envoyé : mardi 6 mai 2025 16:16
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]; [e-mail]
Objet : AW: Review of draft-ietf-ippm-capacity-protocol-12 / part 4 [76]-[102]


Hi Med,

Thanks and great. Your suggested change will be implemented into the next version.

Magnus still has an open change request related to the registry:

protocolVer: rules for values that is assigned by table 4 is strange: To my understanding the first entry in table 3 should be 21-40960, or shouldn't this be 21-40599 to find the bit boundaries?

Regards,

Ruediger

Von: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Gesendet: Montag, 5. Mai 2025 10:54
An: Geib, Rüdiger <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Betreff: RE: Review of draft-ietf-ippm-capacity-protocol-12 / part 4 [76]-[102]

Hi Ruediger,

Thank you.

The IANA section is much more better. We don't need to have "Experts: Performance Metrics Experts" as this will be set the to-be-appointed DEs once the document is published as RFC. Also, note sure we need "Note: TBD"

That's said, I think this can be passed to IANA for review. Thanks.

Cheers,
Med

De : [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Envoyé : mercredi 30 avril 2025 08:50
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : AW: Review of draft-ietf-ippm-capacity-protocol-12 / part 4 [76]-[102]

Hi Med,

Len and I worked on the registry, which we hopefully were able to improve.

Apart from your useful hints and comments, some more changes apply

  *   We look for a single assigned port in the user range
  *   Which we deem useful to simplify passing NATs and firewalls before using dynamic ports
  *   We replaced the term "well-known" port by "standard UDP/UDPSTP" port to avoid text which may hint to a privileged port

Some more statements related to your open registry related comments below, marked [Authors2].

I'll try to post a version -15 later today addressing changes on the registry and some of Benson's comments.

Please note, 1. May is a bank holiday over here and I'll be off on Friday. I'll pick up work Monday again. Please let me know if the re-edited registry is in a state to be forwarded to IANA / David Dong for his review (once, I published).

Regards,

Ruediger


#################



11.1.  New System Port Number Assignment

Commenté [MB83]: I guess that you checked rfc6335 for the guidance for when it makes sense to request one.

Authors: We think, Al Morton took all steps required when he edited this section.



[Med] OK. Let's see what we will get in the service request review. I strongly suggest the authors get familiar with BCP 165<https://datatracker.ietf.org/doc/bcp165/>, by then.



[Authors2]: We've read into BCP 165 and other docs, hopefully better text now.



An editorial following:

"IANA will allocate the following..."

Authors: terminology is conforming to https://www.iana.org/help/protocol-registration#verbiage, no change (valid for other proposed editorial changes too, in some cases limited changes)

[Med] Let's keep it, but I personally prefer to formulate this as a request to IANA.



#################



Experts: Performance Metrics Experts

Commenté [MB84]: Do you mean Performance Metrics Directorate (perfmetrdir) or something else?

Authors: Al wrote that. I think he addressed IPPM WG experts by that. That doesn't exclude the PM Directorate (largely identical people), but I don't think, it was exclusively the PM Directorate (Al would have been writing so, if he had that in mind, I think)

ADD: (e.g. IPPM WG or Performance Metrics Directorate)



[Med] Having both is better. I already approached Mahesh so that the perfdir is "refreshed".



[Authors2]: That has been resolved, I think. Thanks for organizing.



#################



PDU Identifier Registry

0x8000-0xFFFE          IETF Review

Commenté [MB85]: Is Expert Review needed here?

Ok, text changed.



[Med] OK thanks. Please consider adding some text for Design Expert Guidance. This is a recurrent DISCUSS point by the IESG, so let's address that in the next version.

You may refer as an example to https://www.rfc-editor.org/rfc/rfc9606.html#name-guidelines-for-the-designat



[Authors2]: Thanks for the link, included text.





##################



11.2.1. PDU Identifier Registry

Identifier Name (e.g. controlId)

Commenté [MB86]: The guidance should describe whether the identifier is unique or not

Authors: Any uniqueness is to this protocol only, and doesn't need to have a scope beyond the draft. This field, along with the protocol version, is used to determine how the PDU should be processed, what fields to expect, and where exactly they should be expected in the packet buffer.

Are we missing the intent of the question?



[Med] Actually, my comment is that we are mixing a set of ids (grabbed from the header) and a set of values. It is not clear if the index of the table should be the identifier name or the value. Also, not clear if the same value can be used for different names, etc. After re-reading this, I think that it would be better to split your current table to specific sub-registries; each for a given identifier.



CURRENT:

   Identifier  Value    Description           Reference

   Name

   ===============================================================

   controlId   0xACE1   Test Setup PDU        <this RFC>



   controlId   0xACE2   Test Activation PDU   <this RFC>



   controlId   0xDEAD   Null PDU              <this RFC>



   loadId      0xBEEF   Load PDU              <this RFC>



   statusId    0xFEED   Status Feedback PDU   <this RFC>



Also, please make sure the registry is referenced in the main specification body.



[Authors2]: removed all names of fields, added references to registry (sub-)chapters in the main text , replaced all IDs in the above table by "pduId" in the figures and text and did so for all registry tables.





##################



Protocol Number Registry

Protocol version 8-10

Commenté [MB91]: Are there references for these ones?

Authors: NEW: 0-19   Experimental protocol versions  <Prior IDs>
Authors: two of them were published in drafts. Probably guidance on an acceptable expression would help.

[Med] OK



[Authors2]: agreed to have 0-19 listed as reserved with David Dong.





#################



modifierBitmap

Commenté [MB93]: I guess this should be the name of the bit, not the field

Authors: it's the field name, see Figure 2.



[Med] Yes, but you don't need to repat the name of the field in a registry that is dedicated to that specific field! Please use the name of the bit, rather than the field for each entry in the table.



[Authors2]: removed all names of fields, added references to registry (sub-)chapters in the main text and did so for all registry tables.





#################



modifierBitmap   0x00   <this RFC>  IETF      ****OLD: No modifications*****

Commenté [MB93]: That is?

NEW: No modification as compared to Setup Request



[Med] My comment is that I failed to see where this is mentioned in the main body of the specification. We need to link the dots :-)



[Authors2]: removed all names of fields, added references to registry (sub-)chapters in the main text and did so for all registry tables.



#################



Field        Value  Reference   Change     Description

Name                                       Controller

Commenté [MB98]: Why the same name is used? Guidance is needed to help IANA

Authors (RG at least): Med, please clarify your comment. We are not sure, how to address it.

[Med] This is similar to a previous comment. I was expecting the see the mnemonic of each registered mode, not repeating authMode for each entry does not add value given that this registry is about authMode. Please update accordingly.



CURRENT:



   Field     Value   Description                    Reference

   Name

   ===============================================================



   authMode  0       Optional Unauthenticated mode  <this RFC>



   authMode  1       Required authentication        <this RFC>

                     for the Control phase



   authMode  2       Optional authentication for    <this RFC>

                     the Data phase, in addition

                     to the Control phase



   authMode  3       Optional partial encrypted     <this RFC>

                     mode



Same comment for other registries.



[Authors2]: removed all names of fields, added references to registry (sub-)chapters in the main text and did so for all registry tables.



Thank you.

Cheers,

Med





#### End of final set of version-12 comments ####



Von: mailto:[e-mail] <mailto:[e-mail]>

Gesendet: Donnerstag, 6. Februar 2025 16:59

An: mailto:[e-mail]

Cc: mailto:[e-mail]

Betreff: Review of draft-ietf-ippm-capacity-protocol-12



Hi Ruediger, Len,



Many thanks for the effort put into this document. Great work!



As an incoming AD, I thought that it would be useful to proceed in steps and share with you a first review (read, the review is partial).



The full detailed review can be found at:



* pdf: https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fblob%2Fmaster%2F2025%2Fdraft-ietf-ippm-capacity-protocol-11-rev%2520Med.pdf&data=05%7C02%7CRuediger.Geib%40telekom.de%7C381cac0b70f34b471dfc08dd57e32637%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C638763356615097348%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bgQZwKZ1%2F0HjNKyOP79YGLEs%2Fj4vF8cox9l7LsDDGSk%3D&reserved=0<https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-ippm-capacity-protocol-11-rev%20Med.pdf>

* doc: https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fblob%2Fmaster%2F2025%2Fdraft-ietf-ippm-capacity-protocol-11-rev%2520Med.doc&data=05%7C02%7CRuediger.Geib%40telekom.de%7C381cac0b70f34b471dfc08dd57e32637%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C638763356615114809%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vLIKZL073%2B%2Fz3R4asGE2qcUvLk07A%2BP9DO4sZnnqSVY%3D&reserved=0<https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-ippm-capacity-protocol-11-rev%20Med.doc>



Cheers,

Med



Orange Restricted





Orange Restricted

____________________________________________________________________________________________________________

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.

____________________________________________________________________________________________________________

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.

____________________________________________________________________________________________________________

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.

____________________________________________________________________________________________________________

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