|
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
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, 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> [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:mohamed.boucadair@xxxxxxxxxx <mailto:mohamed.boucadair@xxxxxxxxxx>
Gesendet: Donnerstag, 6. Februar 2025 16:59 An:
mailto:draft-ietf-ippm-capacity-protocol@xxxxxxxx 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=""> • doc:
https://deu01.safelinks.protection.outlook.com/?url=""> 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.
|
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
