Just on this one topic.

On 31.07.24 19:30, Andrew Newton (andy) wrote:
Would you be satisfied if the first recommendation was labeled with "This practice has been observed in use." and the other two recommendations are labeled with "This practice has not been observed in use."?

This is already stated with each single practice and it would be logically inconsistent the way Section 6 is written now ("MUST implement one of the following practices...").

For me the BCP shall tell like "SHOULD implement practice 1 if existing and operationally proved practices are preferred or MAY consider experimenting with practice 2 or 3 in the future".

I don't understand this. A SHOULD and MAY means a practitioner can say they adhere to the BCP without doing anything. Also "the future" is subjective.

Yes, "the future" is subjective. That's right. However touches on one important point.

If the goal is to eliminate those bad existing practices in a foreseeable near future, then practice 1 is the only that is practicable and can be implemented by only one party - the clients. This is by the way also an inconsistency in the current text - it tells now that EPP MUST servers implement practices, which is not right for this one. At least the description does not mention any of server changes needed. For others both servers and clients must implement collectively.

Practice 2 has a lot of moving parts that needs to change both by servers and the clients, so nothing one party can implement on the spot to improve the situation in any way. It maybe recommended as a target picture, but will take loads of time to implement. Is it then an equal recommendation referring to the goal?

Practice 3 also require both servers and clients to change, but likely is easier to implement. Easier does not mean easy, as clients tend to be reluctant to solutions that work only with selection of registries, so servers would have to move first and allow for sacrificial.invalid or alike. I'm not an expert in ICANN policies, but maybe it's even needed to change those. Also quite broad tests are likely required if with all those conditions mentioned in 5.1.4.3 are indeed fulfilled in the wild.

So I don't feel right to put an equal mark within Best Current Practice document for those three. Whatever "current" means.

Kind Regards,

Pawel Kowalik

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

Reply via email to