Re: [Idr] The IDR WG has placed draft-spaghetti-idr-deprecate-8-9-10 in state "Candidate for WG Adoption"

[[e-mail]]

Hi Susan,

Please see inline



Orange Restricted
From: Idr <[e-mail]> On Behalf Of Susan Hares
Sent: Tuesday, July 5, 2022 2:45 PM
To: Job Snijders <[e-mail]>; DECRAENE Bruno INNOV/NET <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] The IDR WG has placed draft-spaghetti-idr-deprecate-8-9-10 in state "Candidate for WG Adoption"

Job, Bruno, Nick and Jeff:

As Jeff mentions, you have raised points we've talked about before.
His presentation is useful for companies.

Here's a few questions I've gathered from the discussion:

Due to our last discussion, we added new procedures to
streamline registries  (see RFC9029 and RFC9184).
Do we need any more?
I think we would need to collect the answer from the people squatting the codepoints. Which would call for identifying those people, and hopefully finding someone to explain what's missing.

IDR urges early allocation.  If a draft has been adopted,
Interestingly, RFC7120 seems to have slightly different view on early allocation:

"At most, one renewal request may be made; thus, authors
   should choose carefully when the original request is to be made."

IDR chairs grant requests for early allocation (if needed with new registry
policies).    Are the chairs too slow in getting early adoption code points?


Are companies squatting before a draft is adopted or
after the IDR draft is adopted?

Do companies lack information on the process of early
Allocation?

IDR  has found that established companies make mistakes
Is this omission due to lack of knowledge, or deliberate choice because they feel important enough to be (above) the law, or lack of tool/ IANA API to check the validity of a code point in a CI/CD tool chain?
Without knowing the reason, it may be hard for IDR/IETF to improve/correct.

(now and in the past).   What do we do about past errors?
It may depend on the allocation policy.
FCFS? allocate the codepoint to the feature
STD with a big enough pool: may be doing an "early" allocation? (better allocating than wasting??)
STD with a small pool: we need an incentive not to squat. E.g. deprecate, name and shame.

Like Job, my concern is running code in networks.
+1. My concern is interoperability in networks.

Regards,
--Bruno

Cheers,
Sue

From: Job Snijders <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 30, 2022 12:01 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Nick Hilliard <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] The IDR WG has placed draft-spaghetti-idr-deprecate-8-9-10 in state "Candidate for WG Adoption"


Hi Bruno, others,

I'm not seeing "shame and name" in the draft. I think this should be reflected both in the draft and in the IANA registry. E.g. "squatted by XXXX"
Could the draft be updated with this information before the call for adoption?

Correct. I do not intend to name and shame (unless the chairs ask me to do so).

The (perceived) punitive action doesn't really further the challenge I'd like to address: helping IANA assign usable code points.

Another consideration: listing the squatter(s), to some degree validates the squatting.

Kind regards,

Job

_________________________________________________________________________________________________________________________

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.