[Idr] Re: draft-ietf-idr-sr-te-policy-attr - code point squatting

[Susan Hares <[e-mail]>]

Robert:

The most important thing is to lower the barrier to entropy to the registration.

In reality, the text in an Internet-draft is very little for a registry point.  The boiler plate is large.  And, given the experience with links to non-IETF documents disappearing, the Internet Draft repository is actually better.

If a hackathon could create tools to put a form for querying registry information into an Internet draft, then the Internet Draft would be a stable, low-cost library.   Perhaps, that’s the better direction.

As for experimental numbers, if they (the numbers) go outside the test lab, there is always a chance of a major problem.   It is better to streamline the process for “temporary” assignment.  Temporary assignment can be FCFS, expert review, or IETF standard.   The creation of registries for BGP numbers with limited number space size – falls into IETF or Expert review so we can correctly utilize the space.

So, that has always led me back to revising the process:

1) Revise the early allocation process and “text” for draft,
2) Figure out how to handle temporary new registries.
3) Keep emphasizing that only IANA assigned values get deployed.

I hope my ideas are clearer.  I got a short nap over lunch here.

Sue





From: Robert Raszuk <[e-mail]>
Sent: Thursday, March 19, 2026 7:36 AM
To: [e-mail]
Cc: Susan Hares <[e-mail]>; [e-mail]; idr@ietf. org <[e-mail]>; idr-chairs <[e-mail]>
Subject: Re: [Idr] Re: draft-ietf-idr-sr-te-policy-attr - code point squatting

> we should define experimental code points. For all our registries.

Yes ! That would not be a bad idea. However ...

There is one problem with this approach. See vendor X based on the customer requirement comes up with an extension. He codes it up, gives to the customer and the customer deploys it. In parallel someone (vendor or customer or both) writes a draft, maybe a patent too.

The time it takes to write a draft then go through the process is way too long to wait to get some codepoints allocated officially by IANA.

If an experimental code point is used then the customer needs to upgrade the network when a proper code point is allocated at some point. Sure this is the price to pay when running a pre-standard feature or protocol extension. But this causes a service disruption as it may not be easy to flip a switch and upgrade entire network in one click.

So I guess there are two options ...

Option 1)

Get any IANA code point for your experiment from regular pool via an online form in 24h bypassing all WGs business - valid for 6 months. If there is no accepted draft in any WG - code point automatically expires - experiment is over. Chairs and AD could extend it as an exception. Would we likely end up with having a swiss cheese effect in registries - yes - so what ?

Option 2)

As you say add experimental code points to all registries ... does not need to be large - just few code points as by design there should not be a vendor collistions. Do not ask anyone when developing protocol extension just take it from this pool. And make it clear to anyone who would deploy it outside of lab that this is trial only code and that upgrade to proper code point will be a MUST.

Cheers,
R.



On Thu, Mar 19, 2026 at 11:45 AM <[e-mail]<mailto:[e-mail]>> wrote:
Sue,

Thanks for your email.

The codepoints I was referring to have a registration procedure of “Specification Required”, with a registry defined in 2022. So not dependent on RFC9830.

>   The authors had numbers for testing only.  It was not to be deployed.
>     But the temptation to use it always great.

Absolutely.
So to avoid temptation, authors should just not pick value that IANA has not allocated. Ever. Simple & effective.

If there is a need of a codepoint for testing, we should define experimental code points. For all our registries.

Anyhow, “Note that Internet-Drafts should not include a specific value of a
   code point until IANA has completed the early allocation for this
   value. »
https://datatracker.ietf.org/doc/html/rfc7120#section-3.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc7120-23section-2D3.1&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=jnr3LUueJkuvG3z7FLQ0ZJFuV4YsBEaDAzXzq3qcgiJ-XQHZOBANo-WAlZqEBfY_&s=R1fydN8E2qgMYgX-aon_WIhESuzJ9HjFh_Ahcjb46eA&e=>


  *   2) This draft waited on -04 (published last November) for WG LC for early allocation.

This draft was squatting on the codepoint since individual version 00 and it was squatting on code points at WG adoption time. https://datatracker.ietf.org/doc/html/draft-peng-idr-segment-routing-te-policy-attr-11#name-segment-types<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dpeng-2Didr-2Dsegment-2Drouting-2Dte-2Dpolicy-2Dattr-2D11-23name-2Dsegment-2Dtypes&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=jnr3LUueJkuvG3z7FLQ0ZJFuV4YsBEaDAzXzq3qcgiJ-XQHZOBANo-WAlZqEBfY_&s=N2v-TWprewv-6GtYeUY_FscleJ1k-IT8vmFQObqqjQM&e=>

Thank you for working on fixing things.
--Bruno

From: Susan Hares <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, March 19, 2026 5:11 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: idr@ietf. org <[e-mail]<mailto:[e-mail]>>; idr-chairs <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-ietf-idr-sr-te-policy-attr - code point squatting


https://wiki.ietf.org/group/idr/Early-Allocation-Status<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ietf.org_group_idr_Early-2DAllocation-2DStatus&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=jnr3LUueJkuvG3z7FLQ0ZJFuV4YsBEaDAzXzq3qcgiJ-XQHZOBANo-WAlZqEBfY_&s=UOPLw2HCJwIGg_b2XeSW2mjRQtGkZr8tp5-nHotIC64&e=>

Bruno –

Part of this is my problem, I’ve been quietly trying to fix it.

1) All these allocations waited for the publication of RFC9830
     We thought RFC9830 would be published sooner, and the registry would be available for Early allocation.
     So, I made a bad decision. I put the assignments on the IDR wiki. Adrian told me we would have problems.
     We do.  And it is my fault.

Wiki: https://wiki.ietf.org/group/idr/Early-Allocation-Status<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ietf.org_group_idr_Early-2DAllocation-2DStatus&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=jnr3LUueJkuvG3z7FLQ0ZJFuV4YsBEaDAzXzq3qcgiJ-XQHZOBANo-WAlZqEBfY_&s=UOPLw2HCJwIGg_b2XeSW2mjRQtGkZr8tp5-nHotIC64&e=>

     The authors had numbers for testing only.  It was not to be deployed.
     But the temptation to use it always great.

2) This draft waited on -04 (published last November) for WG LC for early allocation.
So, the best thing for this draft is for me to start an Early Allocation WG LC for this draft.
I will do that tonight before I sleep.

It is also a good time to remind the authors of the following drafts
1) draft-ietf-idr-sr-policy-path-segment
2) draft-ietf-idr-sr-policy-metric
3) draft-ietf-idr-sr-policy-path-mtu
4) draft-ietf-idr-sr-te-policy-attr

That you should not use the values on the following page in products:
https://wiki.ietf.org/e/en/group/idr/Early-Allocation-Status<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ietf.org_e_en_group_idr_Early-2DAllocation-2DStatus&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=jnr3LUueJkuvG3z7FLQ0ZJFuV4YsBEaDAzXzq3qcgiJ-XQHZOBANo-WAlZqEBfY_&s=TtGXHQ8iGm2O9wDvsBLX95XnteWjwpZkcjhzZv1fTEY&e=>

Instead, you should work with me to get an official “Early Allocation” number from IANA.

Sorry for the mess,
Sue Hares



Sue


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, March 19, 2026 12:49 AM
To: [e-mail]<mailto:[e-mail]>
Cc: idr@ietf. org <[e-mail]<mailto:[e-mail]>>; idr-chairs <[e-mail]<mailto:[e-mail]>>
Subject: draft-ietf-idr-sr-te-policy-attr - code point squatting

Hi authors,

This WG document seems to squat on code points.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-te-policy-attr#section-4.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Didr-2Dsr-2Dte-2Dpolicy-2Dattr-23section-2D4.1&d=DwMFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=rEoy_H4r-c4UNUr3jSF-7Q&m=wpt9j5EQ5pjYr4SYvCLahLYdfruxflN85CaUxgcH1qniSziSvMlBmQkxSFAIAMum&s=MgPwyoPRrI9MopztCrUORD4aBrvnNN9oPycAk08i5yk&e=>
https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#segment-types<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_segment-2Drouting_segment-2Drouting.xhtml-23segment-2Dtypes&d=DwMFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=rEoy_H4r-c4UNUr3jSF-7Q&m=wpt9j5EQ5pjYr4SYvCLahLYdfruxflN85CaUxgcH1qniSziSvMlBmQkxSFAIAMum&s=JLZHbqqP5Qm2Vmoarxiwr9NF3B-9vZ-PaEuaVemST18&e=>

If so, in order for us to improve,

-            Could you elaborate on the reason for squatting?

-            Could you suggest incentive for authors not to squat on code points ?

Thank you
--Bruno



____________________________________________________________________________________________________________

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.
_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>