Two points in this email: * one related to the on a comment that I made at the mic during the 30 March meeting at IETF 116; and * one higher level issue that came up during Yet Another Read of the draft
Point One: Section 5: Not sure about whether paragraph 3 of section 5 should have a SHOULD about notifying the sponsoring client with a change poll. In my experience, change polls are processed inconsistently. Suggestion: change the SHOULD in Section 5 to a MAY. (Here is the text so one doesn’t need to go searching) If a TTL value is changed out-of-band, EPP server operators SHOULD notify the sponsoring client using the EPP Change Poll extension ([RFC8590]). Point Two: (Note that this next point is one that I would have discussed w/ Gavin in the hallway or over some ramen.) This is higher-level issue: Presently the EPP model is what I will term: Opaque Server Control: * server controls the RR TTL values * client has no EPP access to the TTL info (read or write) The extension described enables a model that looks like client control: Client Control Model: * client can control the RR TTL values * client has EPP access to the TTL info (read and write) It seems like the extension should also more clearly enable models of: Visible Server Control Model: * server controls the RR TTL values * client has EPP access to the TTL info (read but no write) Hybrid Control Model: * server mostly controls the RR TTL values * client has access to the TTL info (read and some write) (Note: I just made up these terms up to help be descriptive, I’m not necessarily proposing that they need to be part of the doc, but having terminology did help me to think about this.) To be fair, the doc does have text which allude to these models other than the current. For example, also in Section 5, we see an allusion to what might be the Hybrid Control Model: EPP server operators MAY, in order to address operational or security issues, make changes to TTL values out-of-band (that is, not in response to an <update> command received from the sponsoring client). Additionally, server operators MAY implement an automatic reset of TTL values, so that they may be changed for a finite period before and after a planned change, and then revert to a standard value. But the wording of this implies that it’s optional, and that the default state described by the doc is Client Control Model. That is, I couldn’t see text in the <update> command that enabled the Visible Server Control Model (e.g. rejected update commands based on access policy, even for a sponsored object). I think that including changes which explicitly enable these different models makes the extension “more mechanism, less policy” and could improve both adoption and transition. Hope that the above is clear… happy to discuss. Thanks, Rick From: regext <regext-boun...@ietf.org> on behalf of Gavin Brown <gavin.br...@centralnic.com> Date: Thursday, March 2, 2023 at 7:17 PM To: regext@ietf.org <regext@ietf.org> Subject: [EXTERNAL] [regext] FW: New Version Notification for draft-regext-brown-epp-ttl-04.txt CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting. ________________________________ Hi all, With thanks to Rick and Jim for their feedback, I’ve uploaded a new version of the TTL extension draft, which incorporates their suggestions. I’ve asked the WG chairs for a slot at IETF116 to present this draft and request WG adoption. Feedback and advice gratefully appreciated! G. (forgive HTML email, Outlook no longer provides a way to send in plain text) From: internet-dra...@ietf.org <internet-dra...@ietf.org> Date: Thursday, 23 February 2023 at 10:41 To: Gavin Brown <gavin.br...@centralnic.com> Subject: New Version Notification for draft-regext-brown-epp-ttl-04.txt A new version of I-D, draft-regext-brown-epp-ttl-04.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Name: draft-regext-brown-epp-ttl Revision: 04 Title: Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values Document date: 2023-02-22 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/archive/id/draft-regext-brown-epp-ttl-04.txt<https://protect-us.mimecast.com/s/BNXPCXD2y5HMMZrc6mJtI?domain=ietf.org> Status: https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/<https://protect-us.mimecast.com/s/5m8QCYENz5S66XBUGeW6D?domain=datatracker.ietf.org/> Htmlized: https://datatracker.ietf.org/doc/html/draft-regext-brown-epp-ttl<https://protect-us.mimecast.com/s/EkRtCZ6NA0iooYBTK1HA_?domain=datatracker.ietf.org> Diff: https://author-tools.ietf.org/iddiff?url2=draft-regext-brown-epp-ttl-04<https://protect-us.mimecast.com/s/9pM_C1wP04sEEXWTXneYn?domain=author-tools.ietf.org> 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. The IETF Secretariat
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
