Hi Med, > On Jul 10, 2025, at 11:54 PM, [email protected] wrote: > > Hi Acee, > > Hmm. I won't clear now, Acee. There are other pending points in this DICUSS > other than registry policy.
Ok - I was going to reply more on the registration policy but Les's response captures what I was going to say. > > Please poke me when a new version with a concrete proposal addressing those > is available for review. Thank you. Peter will be back from PTO on Monday and I'm sure he'll address then. Thanks, Acee > > Cheers, > Med > >> -----Message d'origine----- >> De : Acee Lindem <[email protected]> >> Envoyé : vendredi 11 juillet 2025 02:07 >> À : Ketan Talaulikar <[email protected]> >> Cc : Les Ginsberg (ginsberg) <[email protected]>; BOUCADAIR Mohamed >> INNOV/NET <[email protected]>; Peter Psenak >> <[email protected]>; The IESG <[email protected]>; draft-ietf-lsr-igp- >> [email protected]; [email protected]; lsr >> <[email protected]> >> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-lsr-igp-flex- >> algo-reverse-affinity-07: (with DISCUSS and COMMENT) >> >> >> Med, >> So can you clear your discuss without further delay? We really want >> to keep this new registry "Expert Review" like the other IS-IS >> registries and I don't think you've provided a good reason not to. >> I believe you understand this is not a registry that defines code >> points but the order of application of the Flex Algo constraints. >> Hence, it is not going to have specific ranges. >> Thanks, >> Acee >> >>> On Jul 10, 2025, at 10:45 AM, Ketan Talaulikar >> <[email protected]> wrote: >>> >>> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww >> w. >>> rfc-editor.org%2Frfc%2Frfc7370.html%23section- >> 4&data=05%7C02%7Cmohamed >>> >> .boucadair%40orange.com%7Ce7a53a1ea1d44aba3b2a08ddc00eea77%7C90c7a20 >> af >>> >> 34b40bfbc48b9253b6f5d20%7C0%7C0%7C638877892487416196%7CUnknown%7CTWF >> pb >>> >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI >> kF >>> >> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fC%2FxQkw2NfJMjA5Sg >> 1j >>> O62wLgR%2F0Hibvupf69FACijw%3D&reserved=0 >>> >>> When new I-Ds are introduced requiring new codepoints, it is >>> advantageous to be able to allocate codepoints without waiting for >>> them to progress to RFC. The reasons this is advantageous are >>> described in [RFC7120]. However, the procedures in [RFC7120] for >> early >>> allocation do not apply to registries, such as the "IS-IS TLV >>> Codepoints" registry, that utilize the "Expert Review" allocation >>> policy. In such cases, what is required is that a request be made >> to >>> the Designated Experts who MAY approve the assignments according >> to >>> the guidance that has been established for the registry concerned. >>> >>> >>> >>> On Thu, Jul 10, 2025 at 8:11 PM Les Ginsberg (ginsberg) >> <[email protected]> wrote: >>> Ketan – >>> Please read RFC 7370 more closely. >>> Early allocation is supported – but it is NOT made permanent until >> RFC status is achieved. >>> <snip> >>> 6. In the event that the document fails to progress to RFC, the >>> Expiry and deallocation process defined in [RFC7120] MUST >> be >>> followed for the relevant codepoints -- noting that the >>> Designated Experts perform the role assigned to Working >> Group >>> chairs. >>> <end snip> >>> As I have indicated in my response to Med, the important issue >> here is the clear guidance associated with the registry. We should >> focus on that. >>> Les >>> From: Ketan Talaulikar <[email protected]> >>> Sent: Thursday, July 10, 2025 5:41 AM >>> To: [email protected] >>> Cc: Les Ginsberg (ginsberg) <[email protected]>; Peter Psenak >>> (ppsenak) <[email protected]>; The IESG <[email protected]>; >>> [email protected]; >>> [email protected]; [email protected]; [email protected] >>> Subject: Re: Mohamed Boucadair's Discuss on draft-ietf-lsr-igp- >> flex-algo-reverse-affinity-07: (with DISCUSS and COMMENT) >>> Hi Les, >>> It was not clear to me that the WG wanted to allow for Flex-Algo >> documents with experimental status to introduce rules in this >> registry. If that is indeed the case, then Standards Action is not >> appropriate. >>> Picking the Expert Review policy (with the appropriate guidance >> to DEs) will enable allocation to be made permanently while the >> document is still in the WG phase but considered stable. Picking >> IETF Review will require the Early Allocation procedures (and >> renewals) [RFC7120] to be performed if the allocation is needed >> before publication - here the WG/IETF is the "expert". >>> The choice is for the WG to make. >>> Thanks, >>> Ketan >>> On Thu, Jul 10, 2025 at 10:07 AM <[email protected]> >> wrote: >>> 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]> Envoyé : >> mercredi >>> 9 juillet 2025 17:59 À : BOUCADAIR Mohamed INNOV/NET >>> <[email protected]>; Peter Psenak (ppsenak) >>> <[email protected]>; The IESG <[email protected]> Cc : >>> [email protected]; lsr- >> [email protected]; [email protected]; [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] >> <[email protected]> >>> Sent: Wednesday, July 9, 2025 1:15 AM >>> To: Les Ginsberg (ginsberg) <[email protected]>; Peter Psenak >>> (ppsenak) <[email protected]>; The IESG <[email protected]> >>> Cc: [email protected]; >>> [email protected]; [email protected]; [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]> >>> Envoyé : mardi 8 juillet 2025 22:31 >>> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; >> Peter >>> Psenak <[email protected]>; The IESG >> <[email protected]> >>> Cc : [email protected]; lsr- >> [email protected]; [email protected]; [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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww >> w. >>> rfc-editor.org%2Frfc%2Frfc7370.html%23section- >> 4&data=05%7C02%7Cmohamed >>> >> .boucadair%40orange.com%7Ce7a53a1ea1d44aba3b2a08ddc00eea77%7C90c7a20 >> af >>> >> 34b40bfbc48b9253b6f5d20%7C0%7C0%7C638877892487435770%7CUnknown%7CTWF >> pb >>> >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI >> kF >>> >> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tOmlOs3N6VN0FryN%2B >> pN >>> oHxPMYS3SE%2Fh%2BYTmJ8NKBdkg%3D&reserved=0 >>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww >> w.rfc-editor.org%2Frfc%2Frfc8126%23section- >> 4.9&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce7a53a1ea1d44aba >> 3b2a08ddc00eea77%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638877 >> 892487450204%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI >> wLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C >> %7C%7C&sdata=01t3hsNMQ4gAUCc53NMFETO68%2FBJjG4q6ryHLwgFdIY%3D&reserv >> ed=0 ). >>> 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. > > ____________________________________________________________________________________________________________ > 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]
