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 <jgo...@verisign.com> 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 <create> and <update> commands, that the client > wishes to remove a previously set value, in favour of the default value.". I > would revise this to "(b) in <create> and <update> 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 <info> command" > • The assumption is that the server will only include the > <ttl:infData> element if the "urn:ietf:params:xml:ns:ttl-1.0" is included in > the login services. The sentence "The <info> response MAY contain an > <extension> element, which MAY contain a <ttl:infoData> 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 <ttl:infoData> 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., <ttl:info/> 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 > > <image001.png> > > 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
