[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03
+1 Kind Regards, Pawel On 24.06.24 15:26, James Galvin wrote: The Chairs have decided to extend this WGLC last call for two weeks, one more week from the date of this message. There has only been on indication of support and two different threads discussing some minor changes. We would like these discussion to resolve and for there to be more indications of support for this document. Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient). If any working group member has questions regarding the publication of this document please respond on the list with your concerns by close of business everywhere, Monday, 1 July 2024. Thanks, Antoin and Jim On 3 Jun 2024, at 10:56, James Galvin wrote: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Best Current Practice: Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-epp-delete-bcp/03/ Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient). If any working group member has questions regarding the publication of this document please respond on the list with your concerns by close of business everywhere, Monday, 17 June 2024. If there are no objections the document will be submitted to the IESG. The Document Shepherd for this document is Andy Newton. Thanks, Antoin and Jim REGEXT WG Co-Chairs ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org smime.p7s Description: S/MIME Cryptographic Signature ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03
+1. -andy On 6/24/24 09:26, James Galvin wrote: The Chairs have decided to extend this WGLC last call for two weeks, one more week from the date of this message. There has only been on indication of support and two different threads discussing some minor changes. We would like these discussion to resolve and for there to be more indications of support for this document. Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient). If any working group member has questions regarding the publication of this document please respond on the list with your concerns by close of business everywhere, Monday, 1 July 2024. Thanks, Antoin and Jim On 3 Jun 2024, at 10:56, James Galvin wrote: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Best Current Practice: Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-epp-delete-bcp/03/ Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient). If any working group member has questions regarding the publication of this document please respond on the list with your concerns by close of business everywhere, Monday, 17 June 2024. If there are no objections the document will be submitted to the IESG. The Document Shepherd for this document is Andy Newton. Thanks, Antoin and Jim REGEXT WG Co-Chairs ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03
+1. Thanks, Jody Kolker 319-329-9805 (mobile) Please contact my direct supervisor Scott Courtney (scourt...@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. -Original Message- From: Andrew Newton (andy) Sent: Monday, July 1, 2024 6:16 AM To: James Galvin ; REGEXT Working Group Subject: [regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03 Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@. +1. -andy On 6/24/24 09:26, James Galvin wrote: > The Chairs have decided to extend this WGLC last call for two weeks, one more > week from the date of this message. There has only been on indication of > support and two different threads discussing some minor changes. We would > like these discussion to resolve and for there to be more indications of > support for this document. > > Please indicate your support or no objection for the publication of this > document by replying to this message on list (a simple "+1" is sufficient). > > If any working group member has questions regarding the publication of this > document please respond on the list with your concerns by close of business > everywhere, Monday, 1 July 2024. > > Thanks, > > Antoin and Jim > > > On 3 Jun 2024, at 10:56, James Galvin wrote: > >> The document editors have indicated that the following document is ready for >> submission to the IESG to be considered for publication as a Best Current >> Practice: >> >> Best Practices for Deletion of Domain and Host Objects in the >> Extensible Provisioning Protocol (EPP) >> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat >> atracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-delete-bcp%2F03%2F&da >> ta=05%7C02%7Cjkolker%40godaddy.com%7C153f140d05e24759c8bf08dc99bf2d52 >> %7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C638554293590182064%7CUn >> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha >> WwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=mFNHwSZy7Rrw0wTt6iH6FeYq8%2B6hnr >> c1L2luxWiD%2F2o%3D&reserved=0 >> >> Please indicate your support or no objection for the publication of this >> document by replying to this message on list (a simple "+1" is sufficient). >> >> If any working group member has questions regarding the publication of this >> document please respond on the list with your concerns by close of business >> everywhere, Monday, 17 June 2024. >> >> If there are no objections the document will be submitted to the IESG. >> >> The Document Shepherd for this document is Andy Newton. >> >> Thanks, >> >> Antoin and Jim >> REGEXT WG Co-Chairs > ___ > regext mailing list -- regext@ietf.org To unsubscribe send an email to > regext-le...@ietf.org ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] AD Evaluation: draft-ietf-regext-epp-ttl-14
# Orie Steele, ART AD, comments for draft-ietf-regext-epp-ttl-14 CC @OR13 https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-regext-epp-ttl-14.txt&submitcheck=True Thanks to Anthony Somerset for the DNSDir early review. Thanks to Andy Newton for the shepherd writeup. Thanks to Gavin and the working group for this document. As you read my comments, please keep in mind that I am not a DNS expert. ## Comments I found the document easy to read, and most of my comments are minor. I do have a concern regarding the choice of enabling 2 modes "Default" and "Policy". Especially after reading SAC-025, I wonder why the "Default" mode is offered to implementations. If it is possible to make Policy Mode the only option, it seems like that might improve the ability to surface and address the security issues associated with short and long lived TTLs. ### Recommended default TTL? ``` 204 4. "default", which MUST NOT be present in command frames but MAY be 205 present in response frames (see Section 2.1.1), and which is used 206 by the server to indicate the default value; ``` ``` 224 2. empty, in which case the server's default TTL for the given 225 record type is to be applied. ``` Is there a recommended default TTL when EPP is used? See security considerations for why this might be a good idea. ### DELEG as example ``` 298 3600 ``` Consider a record that is already registered with IANA, TLSA for example. ### Are 2 modes really needed? ``` 308 It has a single OPTIONAL policy attribute, which takes a boolean 309 value with a default value of false. ``` Should this be interpreted as Default Mode is mandatory to support and Policy Mode is optional? ### Examples for Section 2.2.1 and 2.2.2 Examples in Section 2.2.1 and 2.2.2 both only include the Default Mode. Is Policy Mode supported by `` and `` ? I assume the answer is yes, but explicit examples might make this clearer. ``` 685 If an EPP server receives a command containing a TTL value 686 that is outside the server's permitted range, it MUST reject the 687 command with a 2306 "Parameter value policy error" response. ``` ``` 745 If an EPP server receives an command containing a TTL value 746 that is outside the server's permitted range, it MUST reject the 747 command with a 2306 "Parameter value policy error" response. ``` Consider providing a complete response for these rejected commands. ### Servers MAY have policies? ``` 753 Servers MAY restrict the supported DNS record types in accordance 754 with their own policy. For example, a server MAY allow clients to 755 specify TTL values for DS records only. ``` Can this be strengthened to a SHOULD or MUST? ### Range and Record Type Errors ``` 757 A server which receives a or command which includes 758 a restricted record type MUST respond with a 2306 "Parameter value 759 policy" error. ``` Is it correct to reply with 2306 for both out of range and restricted record type errors? ### Servers can ignore clients? ``` 767 EPP servers which implement this extension SHOULD use the values 768 provided by EPP clients for the TTL values records published in the 769 DNS for domain and (if supported) host objects. ``` This feels like a throwaway sentence, why not MUST? When can this SHOULD be ignored? ### When can servers ignore the host attribute? ``` 771 EPP servers that use the "host attribute" model SHOULD use any A and/ 772 or TTL values specified for the domain object when publishing 773 NS, A and records derived from host attributes. ``` When can this SHOULD be ignored? Why not MUST? ### Operational considerations ``` 796 Historically, registry operators have used a global TTL value for all 797 delegations within their zones, which could then be tuned to an 798 optimum value. ``` Is this a recommendation? Can it be turned into one or removed? ``` 800 Registry operators SHOULD implement limits on the maximum and minimum 801 accepted TTL values that are narrower than the values permitted in 802 the XML schema in the Formal syntax (which were chosen to allow any 803 TTL permitted in DNS records), in order to prevent scenarios where an 804 excessively high or low TTL causes operational issues on either side 805 of the zone cut. ``` This feels like it is in conflict with the Default Mode, which is mandatory to support? ### Should ensure user understands ``` 814 A common operational mistake is changing of DNS record TTLs during or 815 after the planned change to the records themselves. This arises due 816 to a misunderstanding about how TTLs work. 818 Implementations of this specification SHOULD ensure that the user 819 understands that changes to a TTL are only effective in shortening 820 transition periods if implemented a period of time — at least equal 821 to the current TTL — _before_ the planned change. The latency 822 between receipt
