Hi Acee, Hmm. I won't clear now, Acee. There are other pending points in this DICUSS other than registry policy.
Please poke me when a new version with a concrete proposal addressing those is available for review. Thank you. Cheers, Med > -----Message d'origine----- > De : Acee Lindem <acee.i...@gmail.com> > Envoyé : vendredi 11 juillet 2025 02:07 > À : Ketan Talaulikar <ketant.i...@gmail.com> > Cc : Les Ginsberg (ginsberg) <ginsb...@cisco.com>; BOUCADAIR Mohamed > INNOV/NET <mohamed.boucad...@orange.com>; Peter Psenak > <ppse...@cisco.com>; The IESG <i...@ietf.org>; draft-ietf-lsr-igp- > flex-algo-reverse-affin...@ietf.org; lsr-cha...@ietf.org; lsr > <lsr@ietf.org> > 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 > <ketant.i...@gmail.com> 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) > <ginsb...@cisco.com> 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 <ketant.i...@gmail.com> > > Sent: Thursday, July 10, 2025 5:41 AM > > To: mohamed.boucad...@orange.com > > Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Peter Psenak > > (ppsenak) <ppse...@cisco.com>; The IESG <i...@ietf.org>; > > draft-ietf-lsr-igp-flex-algo-reverse-affin...@ietf.org; > > lsr-cha...@ietf.org; lsr@ietf.org; acee.i...@gmail.com > > 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 <mohamed.boucad...@orange.com> > 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) <ginsb...@cisco.com> Envoyé : > mercredi > > 9 juillet 2025 17:59 À : BOUCADAIR Mohamed INNOV/NET > > <mohamed.boucad...@orange.com>; Peter Psenak (ppsenak) > > <ppse...@cisco.com>; The IESG <i...@ietf.org> Cc : > > draft-ietf-lsr-igp-flex-algo-reverse-affin...@ietf.org; lsr- > cha...@ietf.org; lsr@ietf.org; acee.i...@gmail.com 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: mohamed.boucad...@orange.com > <mohamed.boucad...@orange.com> > > Sent: Wednesday, July 9, 2025 1:15 AM > > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Peter Psenak > > (ppsenak) <ppse...@cisco.com>; The IESG <i...@ietf.org> > > Cc: draft-ietf-lsr-igp-flex-algo-reverse-affin...@ietf.org; > > lsr-cha...@ietf.org; lsr@ietf.org; acee.i...@gmail.com > > 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) > <ginsberg=40cisco....@dmarc.ietf.org> > > Envoyé : mardi 8 juillet 2025 22:31 > > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > Peter > > Psenak <ppsenak=40cisco....@dmarc.ietf.org>; The IESG > <i...@ietf.org> > > Cc : draft-ietf-lsr-igp-flex-algo-reverse-affin...@ietf.org; lsr- > cha...@ietf.org; lsr@ietf.org; acee.i...@gmail.com 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 -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
