Hi Rick,
On Thu, 30 Mar 2023, at 22:55, Rick Wilhelm wrote:
> 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]).*
Agreed - I have updated the working document and this will be in the next
revision.
> 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 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 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.
There is a paragraph at the top of Section 4 of the current revision which says
that servers can reject TTLs that are outside of their policy. However the
response code it suggests is wrong - it should be 2306 - and would be more
impactful if placed within the and sections. I have made
these changes which will be in the next revision.
My intention has always been to aim for the extension to follow something like
the "hybrid control" model that you describe, with a wide range of possible
configurations, since the "client control" and "server control" models are
really just the degenerate cases of a hybrid model. I've added some wording to
the introduction and to Sections 5 and 6 to try to make this clearer.
G.
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
