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]<mailto:[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]<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]
