Hi, Your proposed changes seem good to me, there have been other reviews that have landed on -08 since, please address them in -09 as well.
Regards, OS On Thu, Nov 14, 2024 at 9:47 AM Carroll, William <wicarr...@verisign.com> wrote: > 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 > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
