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 <https://www.rfc-editor.org/rfc/rfc7120>]. *However, the procedures in [RFC7120 <https://www.rfc-editor.org/rfc/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 > <https://www.rfc-editor.org/rfc/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]
