Thanks! My comments are inline with [WC]. Please let us know if the proposed changes are adequate.
From: Orie Steele <orie@transmute.industries> Date: Thursday, November 14, 2024 at 9:37 AM To: Registration Protocols Extensions <regext@ietf.org> Subject: [EXTERNAL] [regext] AD Evaluation: draft-ietf-regext-epp-delete-bcp-08 Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. # 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<https://secure-web.cisco.com/1R_6_89KYCAnxiz6pusSz7suaygiczIEJYwa2Zqq4w4ewuq2n-ay-Dg1CC6BizdimI2c8ZVlmieSRqXaUFVffRd4w__JcQ-Y7aWcR9er4Y8T7UFs8zoOZTkPA_tJk3PmJwEp8mPCnujTnc-V0o7P7qp33LMrv8bpkq0Cb-SkQHSjYZi9xnmVV8If05QXHtbAT3TaW4jyp9lcg3qEfbot4PsTxZlVn4c-IU68N-WVG0wSyBzIPfVsjseSkfs1ySlPwHHEROMtjXc6hHR3pmm630NCPkwCQNr0yoBkrWUkejNw/https%3A%2F%2Fauthor-tools.ietf.org%2Fapi%2Fidnits%3Furl%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-epp-delete-bcp-08.txt%26submitcheck%3DTrue> * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md<https://secure-web.cisco.com/1sfJ1rAn7_ktXUlcBGBr_Lx6xUDSAwpq5_iuzp7KHdNl6YLEngWjfvBfi12j8V1ZnxPBVfsYB2W2pDCtV5nwhlWFZzeYzRCGxUdC0_HP4_TMxp_zD3nDkcv7Q-kI1DIb7E34kQETH8ciLkedSgbmijAyy7OHHz9E-snu_9Yj7eWdgOw1k0oDGpsQPuYC4A-_jmOBWjLDyXMTZdRYPSloRVxpV67C2s9AK-WRFWJ7ICIlqKlLRrbO1-dxnNJiCnaGvb7jUEvaNQQU42CZzwWKti9CXCUY3pTLzxowwwoF-P8E/https%3A%2F%2Fgithub.com%2Fmnot%2Fietf-comments%2Fblob%2Fmain%2Fformat.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? [WC]: Good point. We will change the “SHOULD” to a “MUST.” We had some concerns that our examples of potential responses was not comprehensive (e.g., use of extended RFC 8914 errors are not mentioned). However, as the “responses that indicate problems” language is generic enough, those concerns should be covered. ### 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. [WC]: We agree; the 5.1.4.2 special-use section should have a normative reference to match the 5.1.4.1 pseudo-TLD section’s MUST NOT (line 442). We will add a sentence and reference to line 467 like, “This practice is RECOMMENDED (see 6).” -- OS, ART AD
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
