Gavin,
Ahead of the REGEXT meeting, I did a fresh review of draft-ietf-regext-epp-ttl
and below is my feedback:
1. 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…"
2. 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)?
3. 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.
4. Section 4.3 "Use of TTL values for IDN variants"
* I believe the following sentence "If a domain name has variants
([RFC6927<https://www.rfc-editor.org/info/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.
5. 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."
6. Section 8.2 "EPP extension registry"
* Nit - Change Document Status from "Experimental" to "Standards Track"
Thanks,
--
JG
[cid87442*[email protected]]
James Gould
Fellow Engineer
[email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
