Hi Marc,
Thanks for your review. I will spare Brian the responsibility of replying on my
behalf :) My comments are inline below.
> in the EPP command mapping there is a mention on a registry policy regarding
> TTL values which must/should be within server’s permitted range. And the
> subject returns in the Security considerations chapter. Is it an idea to
> mention this already in the general part of this document?
I believe this topic is addressed with sufficient detail and prominence in the
draft. Sections 6 and 7 provide guidance to implementers on what should be
taken into consideration when defining server policy: beyond this and we enter
the realm of *specifying* policy which I don't believe is appropriate for this
document.
> Question on 2.2 <ttl:NS> element. Why is this element not OPTIONAL? What am
> I overseeing by thinking it should be optional, as is with the other elements
> within de domain object?
Because a delegation doesn't exist if no NS records are present. If no NS
records are present then no other record types will be present. Therefore, the
NS element is mandatory.
> Remark 1 on 3.1.1. In the example of the domain:info command the server
> responds with ttl:DS while there is no DS record within the domain object. I
> think it should mention a DS record, otherwise you’re working against (in
> part) the remark you shouldn’t use ttl elements for which there are no
> objects.
Thanks, that'll be fixed in the next version.
> Remark 2 on 3.1.1. In the example <ttl:A> and <ttl:AAAA> are returned while
> the domain object uses hostObjs. Should these values not be part of the
> hostObjs?
The specification allows for TTLs for A and AAAA records to be set on a domain,
that propagate down to subordinate hosts (if those hosts don't have explicit
TTLs).
The extension also needs to allow for the host attribute model, however this is
not explicitly stated in the current text (something I will fix).
> Remark on 3.2.1: for the host create command example I see the use of
> <ttl:ttl> instead of the <ttl:A> and <ttl:AAAA> elements which I suspected to
> be used. What will the <ttl:ttl> achieve when used within the host object
> creation?
<ttl:ttl> is used when the same value is used for all record types. You would
only use <ttl:A> and <ttl:AAAA> if you wanted a different TTL for A and AAA
records, respectively.
Perhaps this approach is confusing? Should we drop <ttl:ttl> and use
<ttl:$RRTYPE> exclusively?
> Typo in chapter 5 last paragraph: EPP servrers -> EPP servers.
> That’s for now. Still looking into another scheme to make this to succeed…
Thanks again for your feedback.
G.
> Best regards,
> Marc Groeneweg
> From: Brian Dickson <brian.peter.dick...@gmail.com>
> Date: Thursday, 14 September 2023 at 20:22
> To: Marc Groeneweg <marc.groene...@sidn.nl>
> Cc: Gavin Brown <gavin.br...@icann.org>, regext@ietf.org <regext@ietf.org>
> Subject: Re: [regext] [Ext] New Version Notification for
> draft-ietf-regext-epp-ttl-02.txt
> On Tue, Sep 12, 2023 at 6:34 AM Marc Groeneweg
> <marc.groeneweg=40sidn...@dmarc.ietf.org> wrote:
> Hi Gavin,
> I am going to review your draft. I see you’re using a ttl object for adding,
> updating and removing ttls on a role type. Is it also an idea to extend
> existing objects (domain and host) with a ttl field? I know this is a
> different approach and perhaps more complex. But when I look at an example on
> changing a hostObj with 2 IPv4 addresses the ttl for “A” will apply for both
> IPv4 addresses I guess. When extending on separate fields it should be
> possible to get a ttl for each address right? And then there’s no need to
> give a ttl a role like “A” or “AAAA”.
> Speaking as a DNS person ("expert" might be overstating things): the TTL of
> any set of records with the same owner name (i.e. FQDN) and type (RRTYPE,
> such as A or AAAA) absolutely MUST be identical. This is part of the core DNS
> specification, and set in stone for all DNS implementations. It carries over
> to DNSSEC as well.
> So, please ensure the EPP specifications related to TTL adequately prevent
> any deviation from this requirement.
> Brian
> Really, it’s just a blunt idea from my side, and not thought through yet 😊.
> Forgot to mention thank you for taking the lead in this draft, as it’s
> mentioned a lot in OARC meetings that this would help in the daily DNS
> operations…
> Best regards,
> Marc Groeneweg
> From: regext <regext-boun...@ietf.org> on behalf of Gavin Brown
> <gavin.br...@icann.org>
> Date: Monday, 11 September 2023 at 14:28
> To: regext@ietf.org <regext@ietf.org>
> Subject: Re: [regext] [Ext] New Version Notification for
> draft-ietf-regext-epp-ttl-02.txt
> [Some people who received this message don't often get email from
> gavin.br...@icann.org. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi all,
>
> Please look at this document. It contains a "straw man" implementation of a
> syntax for supporting TTLs for different record types.
>
> I do not personally like this syntax but have struggled to find one that both
> (a) seems intuitive and (b) can be fully validated using only the XML schema:
> the *easy* approach would be to have looser XML schema and then use MUSTs and
> MUST NOTs in the text, but I'd like to avoid that if I can.
>
> So, I am asking for suggestions on how to do it better. I would be very sad
> if the current model ended up being the final one!
>
> G.
>
> On 10/09/2023, 14:00, internet-dra...@ietf.org
> <mailto:internet-dra...@ietf.org wrote:
>
> A new version of Internet-Draft draft-ietf-regext-epp-ttl-02.txt has been
> successfully submitted by Gavin Brown and posted to the
> IETF repository.
>
> Name: draft-ietf-regext-epp-ttl
> Revision: 02
> Title: Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live
> (TTL) values
> Date: 2023-09-05
> Group: regext
> Pages: 18
> URL: https://www.ietf.org/archive/id/draft-ietf-regext-epp-ttl-02.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-02
>
> Abstract:
>
> This document describes an extension to the Extensible Provisioning
> Protocol (EPP) that allows EPP clients to manage the Time-To-Live
> (TTL) value for domain name delegation records.
>
> About this draft
>
> This note is to be removed before publishing as an RFC.
>
> The source for this draft, and an issue tracker, may can be found at
> https://github.com/gbxyz/epp-ttl-extension.
>
>
> The IETF Secretariat
>
> --
> Gavin Brown
> Principal Engineer, GDS Technical Services
> Internet Corporation for Assigned Names and Numbers (ICANN)
>
> https://www.icann.org
>
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
--
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
https://www.ietf.org/mailman/listinfo/regext
