[regext] Re: [Ext] AD Evaluation: draft-ietf-regext-epp-ttl-14
Hi Orie, comments below. I will shortly publish a new version with the amendments discussed in this thread. > On 12 Jul 2024, at 22:50, Orie Steele wrote: > > Gavin, thanks for your comments. > > Nothing major or blocking here, but still some clarifying questions on my > side. > > Inline replies: [snip] > > > 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. OK, I have settled on "NEWRRTYPE" and will use that. > > ### 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? Yes, servers will always have a policy. Or rather, they will need to decide what the values of the "min" and "max" attributes should be as part of the implementation of this extension (the "default" TTL is whatever value is already used for a given record type). > 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? Client implementers may well implement a "policy mode by default" approach, that's their choice. A previous version of this document included policy information in all responses, but feedback from the WG was that it should only be included when specifically requested. > > 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. Correct. > > > ### 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 preceding paragraph, just in > > the scenario where an EPP server uses host attributes rather than host > > objects. See Section 1.1 of RFC 5731 for an explanation of the difference. > > Thanks, this took a few readings for me to understand, the reason this is not > a MUST is the same. > > You may consider adding a sentence at the end to tie both of these SHOULDs to > section 4, like: > > Regardless of if "host attributes" or "host objects" are in use, Section 4 > explains that TTL values can change out of band. > > This is probably obvious to people with more experience with EPP though. These paragraphs appear immediately before Section 4, so I am not sure adding something is needed. > > ### 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? > > It's not a recommendation, just a description of historical practice. It > could be removed. > > This reads to me as a recommendation, if you are not trying to recommend > implementers continue this trend, I suggest removing it. Will do (or rather, have done). > > > ``` > > 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 op
[regext] Re: [Ext] AD Evaluation: draft-ietf-regext-epp-ttl-14
Actually the submission window is now closed so I won't be able to submit until Saturday. G. > On 15 Jul 2024, at 13:08, Gavin Brown wrote: > > Hi Orie, comments below. > > I will shortly publish a new version with the amendments discussed in this > thread. > >> On 12 Jul 2024, at 22:50, Orie Steele wrote: >> >> Gavin, thanks for your comments. >> >> Nothing major or blocking here, but still some clarifying questions on my >> side. >> >> Inline replies: > > [snip] > 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. > > OK, I have settled on "NEWRRTYPE" and will use that. > >>> ### 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? > > Yes, servers will always have a policy. Or rather, they will need to decide > what the values of the "min" and "max" attributes should be as part of the > implementation of this extension (the "default" TTL is whatever value is > already used for a given record type). > >> 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? > > Client implementers may well implement a "policy mode by default" approach, > that's their choice. > > A previous version of this document included policy information in all > responses, but feedback from the WG was that it should only be included when > specifically requested. > >>> 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. > > Correct. > ### 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 preceding paragraph, just in >>> the scenario where an EPP server uses host attributes rather than host >>> objects. See Section 1.1 of RFC 5731 for an explanation of the difference. >> >> Thanks, this took a few readings for me to understand, the reason this is >> not a MUST is the same. >> >> You may consider adding a sentence at the end to tie both of these SHOULDs >> to section 4, like: >> >> Regardless of if "host attributes" or "host objects" are in use, Section 4 >> explains that TTL values can change out of band. >> >> This is probably obvious to people with more experience with EPP though. > > These paragraphs appear immediately before Section 4, so I am not sure adding > something is needed. > >>> ### 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? >> >> It's not a recommendation, just a description of historical practice. It >> could be removed. >> >> This reads to me as a recommendation, if you are not trying to recommend >> implementers continue this trend, I suggest removing it. > > Will do (or rather, have done). > >> >>> ``` >>> 800 Registry operators SHOULD implement limits on the maximum and minimum >>> 801 accepted TTL values t
[regext] ICANN gTLD Profile
Hi all, If you are attending IETF 120 in Vancouver and work for a gTLD registry operator or registrar or current or potential Registry Service Provider and have questions about the ICANN gTLD Profile (https://www.icann.org/gtld-rdap-profile), including the new version of the profile, send me a private message and I will arrange a meeting time to help answer any questions you might have. If there is enough interest, I can also look into getting one of the rooms the IETF has for side meetings. Also to help with common issues, we have been adding to the wiki for the RDAP Conformance Tool which includes explanations and examples. You can find that wiki here: https://github.com/icann/rdap-conformance-tool/wiki -andy ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] Re: WGLC: draft-ietf-regext-rdap-rir-search-09
A few small things: The last call notice refers to the draft as "considered for publication as a Best Current Practice". The draft describes itself as a Standards Track candidate. I believe that's just an error in the last call notice. [I-D.ietf-regext-rdap-reverse-search] is now RFC 9536. I'd like to see something more in the Security Considerations section that specifically notes how search functionality increases the risk of disclosing information that wasn't explicitly requested. We have this text in RFC 9082: "Search functionality also increases the privacy risk of disclosing object relationships that might not otherwise be obvious. For example, a search that returns IDN variants [RFC6927] that do not explicitly match a client-provided search pattern can disclose information about registered domain names that might not be otherwise available. Implementers need to consider the policy and privacy implications of returning information that was not explicitly requested." Maybe just note that the Security Considerations described in RFC 9082 also apply here. Scott > -Original Message- > From: James Galvin > Sent: Friday, July 12, 2024 5:18 PM > To: REGEXT Working Group > Subject: [EXTERNAL] [regext] WGLC: draft-ietf-regext-rdap-rir-search-09 > > 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. > > 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://secure-web.cisco.com/1bZSsnQGQmxhBWWisxpA-e7EjLi- > FF0G4N3sfIfipgTWVCmeXwOierTpwOew31D7g3qSZRMxhe_HESJdmm6NBVfl > 9-PQKs8ZX0Z1XihN4BcG-4k6wgMbq05HaLTiUO47a- > ylj0vgXs1JhxgJle21VH7uz0egkUqSAS4RzRaLe7Ebvb8pRM1knYxxX24lySavXliF > ANQlXRmnyX0R5sZhzAQ8a49IDSS2prEKgZcI8RtJ5NJl_5GvZU1G0rmok_UFyg > g8JJMOxd5Aq8_5I4kB6G9TYndwZtR5U8XXJTUGsreM/https%3A%2F%2Fdat > atracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-rir-search%2F09%2F > > 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 mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
