# Orie Steele, ART AD, comments for draft-ietf-regext-epp-delete-bcp-08 CC @OR13
* line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-regext-epp-delete-bcp-08.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md I have only minor comments, and I believe this document is ready for IETF Last Call. ## Comments Thanks to Andy Newton for the shepherd writeup. Highlighting a comment from the writeup: ``` Additionally, there were discussion regarding the use of BCPs to suggest practices that are not know to be practiced. In other words, how can a BCP normatively require a practice that has not been observed because it is not a "current" practice. It was noted that RFC 2026 permits BCPs to describe what is believed to be the best way to perform some operations or IETF process functions. ``` Indeed the document highlights several patterns which would "not be best", and provides recommendations for what is believed to be best at this time. ### Why not MUST? ``` 414 The service SHOULD provide responses that indicate problems with a 415 domain's delegation, such as non-existence or include controlled 416 interruption IP addresses [RFC8023]. This practice has been observed 417 in use. ``` Under which circumstances can this should be safely ignored? ### Use of .invalid recommended? .alt is clearly forbidden: ``` 440 Clients may rename host objects to use ".alt" or another non-DNS 441 pseudo-TLD as suggested in [risky-bizness-irtf]. This practice has 442 not been observed in use. This practice MUST NOT be used. ``` So I wonder if there should be clear guidance on treatment of .invalid. ``` 471 Clients may rename host objects to use ".invalid" or another reserved 472 special-use ([RFC6761]) TLD as suggested in [risky-bizness]. ``` Because the comments on .alt come before the comments on .invalid, I get the feeling that use of .invalid is encouraged... even though there is no explicit guidance. Later: ``` 748 use domain issues described in [RFC8244]. Use of 749 "sacrificial.invalid" (see 5.1.4.3) as the parent domain for the 750 host objects is RECOMMENDED to avoid the overhead of creating a 751 new TLD using either IETF or ICANN processes that offers no 752 additional operational benefit. ``` Perhaps add a brief comment and a pointer to this recommendation when the concept is introduced. -- OS, ART AD
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
