Tony –

I think Chris and I have expressed the same point.
I also think you seem to want to “pick a fight” – and I am not interested in 
that.

I will call your attention to the following from RFC 7120. Although RFC 7120 is 
not directly applicable in this case, it is related and the concern expressed 
there seems very relevant to this case.

From https://www.rfc-editor.org/rfc/rfc7120.html#section-5


“There is a significant concern that the procedures in this document
   could be used as an end-run on the IETF process to achieve code point
   allocation when an RFC will not be published.  For example, a WG or a
   WG chair might be pressured to obtain an early allocation for a
   protocol extension for a particular company or for another Standards
   Development Organization even though it might be predicted that an
   IETF LC or IESG Evaluation would reject the approach that is
   documented.”

Les


From: Tony Li <[email protected]>
Sent: Monday, July 20, 2026 1:05 PM
To: Christian Hopps <[email protected]>
Cc: Les Ginsberg (ginsberg) <[email protected]>; lsr-chairs 
<[email protected]>; lsr <[email protected]>
Subject: Re: [Lsr] Re: Adoption of draft-many-lsr-power-group

Chris, Les,

I wrote that code points "do not require adoption".  That is accurate.  A 
'SHOULD' is not a 'MUST'.  You don't get to change it into one.  What I wrote 
originally was correct.

I respect the 'SHOULD' and the work the experts do, but the fact of the matter 
is that we have code, and it is going to ship regardless of adoption.  At this 
point, I cannot stop it.

So, this is really up to you.  You can allocate, or we can squat.  Waiting is 
out of the question.  Your choice?

Regards,
Tony

On Mon, Jul 20, 2026 at 9:56 PM Christian Hopps 
<[email protected]<mailto:[email protected]>> wrote:
Expert hat on: I do not believe Les is raising the bar. We (reg experts) have 
followed the SHOULD advice rather consistently. We have always pushed for WG 
adoption first. It’s why I mentioned the order, adoption and then allocate, 
during the presentation. Yes, SHOULD is not MUST, but it’s also not MAY. :)

I think it’s worth giving the normal route a chance here before we look to the 
exceptional one.

Thanks,
Chris.


On Jul 20, 2026, at 20:12, Tony Li 
<[email protected]<mailto:[email protected]>> wrote:

Les,

What I wrote is correct.  Please read what you quoted.  That's a SHOULD, not a 
MUST.

You don't get to raise the bar on a whim.

Tony


On Mon, Jul 20, 2026 at 6:36 PM Les Ginsberg (ginsberg) - ginsberg at 
cisco.com<http://cisco.com> 
<[email protected]<mailto:[email protected]>> wrote:
Tony –

I don’t want to start an argument – just want to set the record straight.

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
states:

“Note
For IS-IS registries and value ranges maintained via the "Expert
Review" [RFC8126] registration procedure, guidance for IESG-designated
experts can be found in [RFC7370].”

https://www.rfc-editor.org/rfc/rfc7370.html#section-4 states:

“2.  The Designated Experts SHOULD only consider requests that arise
       from I-Ds that have already been accepted as Working Group
       documents or that are planned for progression as AD Sponsored
       documents in the absence of a suitably chartered Working Group.”

So what you say below is not correct.

   Les

From: Tony Li <[email protected]<mailto:[email protected]>>
Sent: Monday, July 20, 2026 8:50 AM
To: lsr-chairs <[email protected]<mailto:[email protected]>>
Cc: lsr <[email protected]<mailto:[email protected]>>
Subject: [Lsr] Adoption of draft-many-lsr-power-group

Hi,

I would like to formally request that we start an adoption poll of 
draft-many-lsr-power-group.

I would also like to formally request code point assignment for this document.  
The relevant code points are all under "Expert Review" and do not require 
formal adoption before code point allocation.  We would greatly prefer not to 
squat on code point values if we do not have to.

Regards,
Tony

_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to