Med (and everyone) - I think I likely have abused the concern about Experimental track. Let me try to be more precise.
IS-IS registries (and some IGP registries) use Expert Review policy. As per https://www.rfc-editor.org/rfc/rfc7120.html#section-2 , early allocation of codepoints is only permitted when: "The code points must be from a space designated as "RFC Required", "IETF Review", or "Standards Action". Additionally, requests for early assignment of code points from a "Specification Required" registry are allowed if the specification will be published as an RFC." In the case of the new registry being created here, we aren't actually allocating "codepoints" - rather we are defining an ordered set of rules - but that set of rules is referencing various sub-TLVs whose codepoints are allocated using Expert Review policy. It would not be unexpected to find that in the future an addition to this ordered set of rules involves the case of a new sub-TLV which has used the early allocation procedures defined in RFC 7370 to obtain a codepoint while the defining document is still a WG document. Addition to the registry defining the ordered set of rules would be necessary to ensure interoperability and - for the same reasons as with early allocation of codepoints - being able to do so BEFORE the defining document has become an RFC is useful. If we use the same policy (Expert Review) for the new registry then I think there is no question that an "early allocation" approved following the procedures defined in RFC 7370 would be considered valid. If, however, we use a different policy (you and others have proposed Standards Action) then I things get unnecessarily murky in regards to early allocation. I am not a lawyer - don't want to be a lawyer - and don't want to have to consult a lawyer to determine what is valid. Hence, I advocate for the consistent use of Expert Review policy. None of this affects the writing of the appropriate guidance - which we all seem to agree is the most important thing. If you agree to this - please indicate that you no longer object to use of Expert Review policy for the new registry - and we can get on with agreeing on the text for the guidelines to the experts. I think the draft authors should take the lead in proposing that text (Peter will be back from vacation next week) - but I am happy to help if needed. Les From: Les Ginsberg (ginsberg) <[email protected]> Sent: Thursday, July 10, 2025 7:34 AM To: [email protected]; Peter Psenak (ppsenak) <[email protected]>; The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [Lsr] Re: Mohamed Boucadair's Discuss on draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: (with DISCUSS and COMMENT) Med - What we agree on is the need for more explicit guidance. I don't know why it makes sense to use Expert Review for the registries which define the codepoints used in the FAD but use a different policy for the registry which define the order in which the codepoints are utilized. Perhaps you are simply not familiar with the long history of Expert Review based on RFC 7370. I really do not want to move this to a separate document. IETF process moves at glacial speed - it would be a year at least before this is resolved. I don't think it should be that difficult to reach consensus on appropriate guidance - which is the important issue here. Les From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Wednesday, July 9, 2025 9:37 PM To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>; Peter Psenak (ppsenak) <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: (with DISCUSS and COMMENT) Hi Les, Glad to hear that we agree on having guidance. Will look into those when a concrete proposal is made by the WG. Another pending item is to check whether we declare the registry authoritative and thus tag RFC9350 and RFC-to-be-draft-ietf-lsr-flex-algo-bw-con as updated by this one. You raised an interesting point about experimental. An option for consideration to cover that case in addition to what was already discussed is "IETF Review". Unless the WG have done that, but which I fail to see in the draft and searching on the archives, I think we need to walkthrough the experimental path as I don't think we have the pieces in place. For example: * There is currently no provision of experimental use in the spec * There is no explanation of what experimental use means in this case * There is no visible/field to help users of the registry that a part of the algo is experimental (whatsoever that means) * There is an apparent disconnect with the spirit of RFC9350 which says the following for FAD, for example: The values 6-32767 are unassigned, and values 32768-33023 are for Experimental Use; these will not be registered with IANA. * .. * Of course, we need to supply some operational guidance if we are mixing std/exp components. I'm more and more convinced that this part of the draft is better handed in a separated document and keep this one focused on reverse-affinity. Cheers, Med De : Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> Envoyé : mercredi 9 juillet 2025 17:59 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; Peter Psenak (ppsenak) <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>> Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : RE: Mohamed Boucadair's Discuss on draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: (with DISCUSS and COMMENT) Med - Thanx for the constructive response. NOTE: I am not a draft author and am not speaking on behalf of the draft authors. Please see inline. From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Wednesday, July 9, 2025 1:15 AM To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>; Peter Psenak (ppsenak) <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: (with DISCUSS and COMMENT) Hi Les, Thank you for this input. The guidance in 7370 is not sufficient here, IMO. The new registry is special in the sense that it is not about assigning a codepoint, but about maintaining an algorithm. As with any algorithm, and as we gain deployment experience and new needs are defined, steps may need some tweaking. We need to set the expectation on the maintenance of such an algorithm when offloaded to a registry, especially with a DE policy. As already indicated in my ballot, I'd expect at least we have guidance whether we allow reorder steps, merge steps, insert a step between existing ones, update an existing one, etc. These are of course examples, but the point is to exemplify my purpose. [LES:] I agree with the points you have made. Additional guidelines would be helpful. In the meantime, I also don't want us to set rules that may not be flexile enough to accommodate specific needs in the future. This is why I favor for now to change the policy to Standard Action. [LES:] I do not see that Standard Action policy has any advantage - or in any way addresses your concerns. And, as I have pointed out, it has limits that seem unnecessary/undesirable in this case. For example, it is at least conceivable that an experimental use of flex-algo may be defined in the future and it would be useful to be able to incorporate any new rules in a way that avoids interoperability issues. My interpretation of Standards Action policy is that it provides no support for that. In summary, I support your desire to see more complete guidelines for the new registry - but I don't support the use of Standards Action policy for the registry. Les Cheers, Med De : Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> Envoyé : mardi 8 juillet 2025 22:31 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; Peter Psenak <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>> Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : RE: Mohamed Boucadair's Discuss on draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: (with DISCUSS and COMMENT) In regards to the registration policy for the new registry introduced by this draft - about which at least three IESG reviewers have commented (Ketan, Mohammed, and Roman) - all suggesting "Standards Action" rather than "Expert Review" as the policy... As the author of RFC 7370 - on which all of the IS-IS Registries (and some of the IGP Parameter registries) policies are based - I would like to comment. RFC 7370 was written precisely to address the use of Expert Review for registries. This was done in part because we wanted a policy that supports all RFC Tracks - including experimental. We also provided detailed instructions to the Designated Experts - see https://www.rfc-editor.org/rfc/rfc7370.html#section-4 I do not see that Standards Action policy is more robust - and it has the decided disadvantage that it only allows for "Standards Track or Best Current Practice RFCs" (as per https://www.rfc-editor.org/rfc/rfc8126#section-4.9 ). I would ask the IESG reviewers to consider the above. If you still feel that RFC 7370 based Expert Review policy is lacking, please be more specific in your reasons as to why. Thanx. Les ____________________________________________________________________________________________________________ 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.
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
