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://www.rfc-editor.org/rfc/rfc7370.html#section-4 > > 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]; > [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]; > [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://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]
