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 <gavin.br...@icann.org> 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 <orie@transmute.industries> 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 <info> command just returns information about the specified >> object. The purpose of the <info> 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 <info> > responses, but feedback from the WG was that it should only be included when > specifically requested. > >>> Is Policy Mode supported by `<create>` and `<update>` ? >>> >>> I assume the answer is yes, but explicit examples might make this clearer. >> >> No, <info> only. In the document, Default Mode and Policy Mode are only >> specified in the context of the <info> 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 AAAA TTL values specified for the domain object when publishing >>>> 773 NS, A and AAAA 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 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? >> >> This is not correct. "Default Mode" provides clients with a way to discover >> the current TTL settings for an object (as opposed to "Policy Mode" which >> also returns the server policy, see above). These two modes, which only >> apply to the <info> command, are not intended to, and indeed cannot, effect >> the server's ability to implement its own policy in relation to TTL values. >> >> Does this sentence imply then that there always exists a server policy, even >> if it's not requested in the info command? > > 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). > >>>> ### additional security considerations for ttl >>>> >>>> Consider commenting on the impact of TTL on DDoS. >>>> Consider commenting on the impact of TTL on DNS Spoofing. >>>> Consider commenting on the impact of TTL on DNS Cache Poisoning. >> >>> I don't believe this draft has any implications on these topics. If you >>> think it might, then I think I would want to get input from DNSOP and/or >>> the DNS Directorate. >> >> I see your point. The draft simply describes an extension to EPP which >> enables clients to manage TTL. >> >> Since you comment on the impact of choice of TTL value in security >> considerations in relation to fast flux, I wondered if you should comment on >> the choice of TTL and its impact on these topics. >> >> Seems fine to leave off these considerations since they are not specific to >> this EPP extension, but TTL in general. > > Noted. > > G. > > -- > Gavin Brown > Principal Engineer, Global Domains & Strategy > Internet Corporation for Assigned Names and Numbers (ICANN) > > https://www.icann.org > -- 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
