[regext] Re: [Ext] AD Evaluation: draft-ietf-regext-epp-ttl-14
Hi Orie, comments below. > On 1 Jul 2024, at 23:30, Orie Steele wrote: > > # 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 > [author-tools.ietf.org] > > 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. I don't think it would be appropriate for this draft to recommend a default TTL value. The provisioning system should reflect the policy that's determined on the publication side, not impose a policy on it. > ### DELEG as example > > ``` > 298299 for="custom" > 300 custom="DELEG">3600 > ``` > > Consider a record that is already registered with IANA, TLSA for example. As I understand it, TLSA is not appropriate for publication at a delegation point, so using TLSA here would not make any more sense than DELEG. Perhaps this should just be some placeholder value, such as MYCUSTOMTYPE? > ### 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? No. The text extract only describes the permitted XML syntax of the extension elements. By default, an command just returns information about the specified object. The purpose of the Policy Mode is to allow the client to also determine the server policy, that is, the supported DNS record types and the corresponding min, default and max TTL values. > ### 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. No, only. In the document, Default Mode and Policy Mode are only specified in the context of the command. > ``` > 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? Yes, a SHOULD here makes sense. > ### 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? No - 2306 is appropriate for an unsupported DNS record type, but 2004 (Parameter value range error) is appropriate for "out of range" errors. There are a couple of usages of 2306 in Section 2.2 which should be 2004, so I will fix those. > ### 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? I didn't use MUST here because provisioning and publication systems are normally loosely coupled, so MUST seemed (in my view) to impose too strong an obligation on the server. There are scenarios where the TTLs might be ignored, such as those contemplated in Section 4. > ### 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? This is basically saying the same thing as the
[regext] Re: [Ext] AD Evaluation: draft-ietf-regext-epp-ttl-14
On 7/12/24 05:41, Gavin Brown wrote: ### DELEG as example ``` 298 3600 ``` Consider a record that is already registered with IANA, TLSA for example. As I understand it, TLSA is not appropriate for publication at a delegation point, so using TLSA here would not make any more sense than DELEG. Perhaps this should just be some placeholder value, such as MYCUSTOMTYPE? DS maybe? -andy___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] Re: [Ext] AD Evaluation: draft-ietf-regext-epp-ttl-14
The "custom" attribute is only needed for DNS record types which are not already permitted above a zone cut. DS is one of the permitted records, so the "custom" attribute would not be needed. G. > On 12 Jul 2024, at 12:41, Andrew Newton (andy) wrote: > > > On 7/12/24 05:41, Gavin Brown wrote: >>> ### DELEG as example >>> >>> ``` >>> 298 >> 299 for="custom" >>> 300 custom="DELEG">3600 >>> ``` >>> >>> Consider a record that is already registered with IANA, TLSA for example. >>> >> As I understand it, TLSA is not appropriate for publication at a delegation >> point, so using TLSA here would not make any more sense than DELEG. Perhaps >> this should just be some placeholder value, such as MYCUSTOMTYPE? >> > > DS maybe? > -andy -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.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
This WGLC is now closed. With 7 indications of support and no objections it can now be submitted to the IESG for consideration as a Best Current Practice. The Document Shepherd for this work is Andy Newton and the Chairs request that he confirm all WGLC comments have been addressed in the latest version of the document and prepare a Shepherd write-up. Upon receipt of the write-up the Chairs will review and submit the document appropriately. Thanks to all for you review and support! Jim and Antoin REGEXT co-Chairs On 24 Jun 2024, at 9: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] WGLC: draft-ietf-regext-rdap-geofeed-05
The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: An RDAP Extension for Geofeed Data https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-geofeed/ 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, Friday, 2 August 2024. This WGLC has been extended to 3 weeks because of the IETF120 meeting. If there are no objections the document will be submitted to the IESG. The Document Shepherd for this document is Gavin Brown. 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] WGLC: draft-ietf-regext-rdap-rir-search-09
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: RDAP RIR Search https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/09/ This document has been through WGLC previously. However, a number of questions arose and changes were made that are considered material and thus we are proceeding with this additional WGLC. 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, Friday, 2 August 2024. This WGLC has been extended to 3 weeks because of the IETF120 meeting. If there are no objections the document will be submitted to the IESG. The Document Shepherd for this document is Mario Loffredo. 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] Re: [Ext] AD Evaluation: draft-ietf-regext-epp-ttl-14
Gavin, thanks for your comments. Nothing major or blocking here, but still some clarifying questions on my side. Inline replies: On Fri, Jul 12, 2024 at 4:41 AM Gavin Brown wrote: > Hi Orie, comments below. > > > On 1 Jul 2024, at 23:30, Orie Steele wrote: > > > > # 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 > [author-tools.ietf.org] > > > > 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. > > I don't think it would be appropriate for this draft to recommend a > default TTL value. The provisioning system should reflect the policy that's > determined on the publication side, not impose a policy on it. > That makes sense. > > > ### DELEG as example > > > > ``` > > 298> 299 for="custom" > > 300 custom="DELEG">3600 > > ``` > > > > Consider a record that is already registered with IANA, TLSA for example. > > As I understand it, TLSA is not appropriate for publication at a > delegation point, so using TLSA here would not make any more sense than > DELEG. Perhaps this should just be some placeholder value, such as > MYCUSTOMTYPE? > Elsewhere in the document it states the record must be registered, so providing an example that is registered seems better than a placeholder value for an example. I don't have strong opinions on this, but I think DELEG is not a good choice, because it is a work in progress. > > > ### 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? > > No. The text extract only describes the permitted XML syntax of the > extension elements. > > By default, an command just returns information about the specified > object. The purpose of the Policy Mode is to allow the client to > also determine the server policy, that is, the supported DNS record types > and the corresponding min, default and max TTL values. > Is it the case that servers always have a policy, but that it is just not always requested? If servers don't have a policy but one is requested an error is produced? I'm imagining an implementer who might just prefer to implement one solution, and get back extra info which they ignore when they don't care. It feels like there could be a reduction in implementation burden here, am I wrong about that? > > > ### 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. > > No, only. In the document, Default Mode and Policy Mode are only > specified in the context of the command. > I see... mutations are only setting the ttl value, and the responses never include the policy information. > > > ``` > > 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? > > Yes, a SHOULD here makes sense. > > > ### 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? > > No - 2306 is appropriate for an unsupported DNS record type,
[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03
+1 On Mon, Jun 3, 2024, 7:56 AM 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
