Re: [regext] draft-ietf-regext-epp-ttl Feedback
Thanks for the feedback Jim. I agree with all your points and have incorporated them into the draft. Now that the datatracker is open again I am going to submit a new version of the draft. The version after that will allow TTLs to be specified for different RR types, which is (IIRC) the only outstanding item for this document. I also need a document shepherd. Any volunteers? Thanks, > On 25 Jul 2023, at 17:05, Gould, James wrote: > > Gavin, > Ahead of the REGEXT meeting, I did a fresh review of > draft-ietf-regext-epp-ttl and below is my feedback: > > • Section 2 "Extension elements" > • Nit - "(b) in and commands, that the client > wishes to remove a previously set value, in favour of the default value.". I > would revise this to "(b) in and commands, that the client > wishes to use the server default value.". > • Nit – “Note that this does no mean…” needs to be “Note that this > does not mean…" > • Section 3.1.1 "EPP command" > • The assumption is that the server will only include the > element if the "urn:ietf:params:xml:ns:ttl-1.0" is included in > the login services. The sentence "The response MAY contain an > element, which MAY contain a element based on > server policy and based on inclusion of "urn:ietf:params:xml:ns:ttl-1.0" in > the login service extensions." Should this be a MUST for the server to > always include the element in the info response based on > inclusion of "urn:ietf:params:xml:ns:ttl-1.0" in the login service extensions > or does the info command need to be extended to allow the client to > explicitly request the ttl extension (e.g., element)? > • Section 4.2 "Relationship between host object and domain object TTL > values" > • I believe the following sentence "However, if no TTL value is > specified for a subordinate host object, but a TTL value is specified for the > superordinate domain object, then the domain object's TTL value SHOULD be > used for the host object instead of the default TTL value." should be a MAY. > I'm concerned about the cascading relationship issue of the parent domain and > its child hosts. I don't want a domain update to result in a cascade update > to all child hosts or cascading it from the parent domain in the DNS > propagating or DNS resolution. > • Section 4.3 "Use of TTL values for IDN variants" > • I believe the following sentence "If a domain name has variants > ([RFC6927]) that are linked to that domain, then any NS or DNAME records > published for those variants SHOULD use the same TTL as that used for the > primary domain." should be a MAY. The concept of a primary and variant > domain names and the inheritance of related domain attributes is heavily > dependent on the relationship model (associated, aggregated, and composite). > I would not have the TTL extension imply a certain kind of relationship > model, so this should be a MAY and not a SHOULD. > • Section 6.2 "When the TTL should be changed" > • Nit – The “Client implementations of this specification…” sentence > could be changed to "Client implementations of this specification SHOULD > ensure that the user understands that changes to a TTL are only effective in > shortening transition periods if implemented in a period of time — at least > equal to the current TTL — before the planned change." > • Section 8.2 "EPP extension registry" > • Nit - Change Document Status from "Experimental" to "Standards > Track" > Thanks, > -- > JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com -- Gavin Brown CentralNic Group plc (LSE:CNIC) https://centralnicregistry.com CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6BR. https://www.centralnic.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] I-D Action: draft-ietf-regext-epp-ttl-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Registration Protocols Extensions (REGEXT) WG of the IETF. Title : Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values Author : Gavin Brown Filename: draft-ietf-regext-epp-ttl-01.txt Pages : 16 Date: 2023-08-01 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 datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-01 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: New Version Notification for draft-ietf-regext-epp-ttl-01.txt
FYI Begin forwarded message: From: internet-dra...@ietf.org Subject: New Version Notification for draft-ietf-regext-epp-ttl-01.txt Date: 1 August 2023 at 12:58:25 BST To: "Gavin Brown" [You don't often get email from internet-dra...@ietf.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] A new version of I-D, draft-ietf-regext-epp-ttl-01.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Name: draft-ietf-regext-epp-ttl Revision: 01 Title: Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values Document date: 2023-08-01 Group: regext Pages: 16 URL:https://www.ietf.org/archive/id/draft-ietf-regext-epp-ttl-01.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-01 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 CentralNic Group plc (LSE:CNIC) https://centralnicregistry.com CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6BR. https://www.centralnic.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-epp-ttl Feedback
On Tue, Aug 1, 2023 at 7:49 AM Gavin Brown wrote: > I also need a document shepherd. Any volunteers? I can do it. -andy ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-epp-ttl Feedback
Thanks Andy! WG chairs, please note. G. > On 1 Aug 2023, at 13:41, Andrew Newton wrote: > > [You don't often get email from a...@hxr.us. Learn why this is important at > https://aka.ms/LearnAboutSenderIdentification ] > > On Tue, Aug 1, 2023 at 7:49 AM Gavin Brown wrote: >> I also need a document shepherd. Any volunteers? > > I can do it. > > -andy -- Gavin Brown CentralNic Group plc (LSE:CNIC) https://centralnicregistry.com CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6BR. https://www.centralnic.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-x-media-type-00.txt
On Tue, Jul 25, 2023 at 9:01 AM Gould, James wrote: > > JG - I'm not sure where the "search all RDAP servers" use case is coming > from. The RDAP RFCs and extensions provide bootstrapping and query features > (lookup and search) that clients can use to query individual RDAP servers. Let me try to restate this. The use case of search and authnz do not lend themselves to either bootstrapping or redirection to authoritative servers by their very nature. But finding authoritative servers via bootstrapping and redirects is integral to the operations of RDAP lookups which makeup the vast majority of RDAP queries. Any feature that intends to be used in lookups needs to be compatible with finding authoritative servers in RDAP. Tom Harrison gives an excellent example of this in his recent talk at ROW 12: https://regiops.net/sites/default/files/documents/2-ROW12-Tom%20Harrison-RIR%20RDAP%20profile%20and%20related%20standardisation%20work_0.pdf > The query parameters of an RDAP extension are additive to the queries and > don't change the bootstrapping, query, and response model. No they are not. See Section 4.3 of RFC 7480. Additionally, see Appendix A.2.2 of the RDAP-X draft which demonstrates how this is not true with currently deployed RDAP servers. > Maybe you should define a draft associated with RDAP redirection and > aggregation services that leverages the REST interface defined by RDAP and > the RDAP extensions. No need. Please see Section 5.2 and Appendix C of RFC 7480. > JG - The draft defines an alternative mechanism for a client to specify the > extensions that are desired in the RDAP response, which is in direct conflict > with the use of the "versioning" query parameter in > draft-gould-regext-rdap-versioning. The use of a media type could be > leveraged in place of the query parameter or in addition to the query > parameter in draft-gould-regext-rdap-versioning, but as defined > draft-newton-regext-rdap-x-media-type does not define a generic feature that > can be used by draft-gould-regext-rdap-versioning but instead defines a > conflicting approach for signaling desired extensions by the client. Correct. The intent is to define a generic mechanism that can be used by both your semantic versioning scheme and other versioning schemes including the current opaque versioning in RDAP. I'd be happy to work with you on incorporating the use of RDAP-X with your semantic versioning idea. > > I don’t believe that the RDAP application protocol concerns should move > > into the transport layer with the use of a new HTTP header. The use of > > query parameters is appropriate and as shown in #2 above is being used in > > many places. > > > This draft does not create a new HTTP header. And query parameters are > part of the identifier system (URIs) which are intrinsic to HTTP, so > both are aspects of HTTP as an application transport. > > JG - Correct, you are defining a new media type to use with the Accept > header, which I believe moves the application signaling down to the transport > layer. I prefer keeping the query information in the URI with the use of > query parameters. The only problem is that RDAP is specifically intended to use the features of HTTP. See Section 3 of RFC 7480. RDAP also currently defines the use of HTTP headers, as do many REST protocols. In fact, the idea behind RDAP-X is not novel as it was inspired by the W3C's ActivityPub protocol which uses multiple media types, one of which can have parameters. RDAP does not have the mental model of EPP when it comes to application vs transport. -andy ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
