On Fri, Jun 1, 2018, at 17:16, Roger D Carney wrote: > We have been talking about Registry Mapping for over a year now and here > is the official first > draft<https://datatracker.ietf.org/doc/draft-gould-carney-regext-registry/ > >. > > > > Please take a read and let the discussions flow!
Some quick remarks before trying to implement it and hence reviewing it more in depth later. First I think it is an important concept (auto-discovery), whatever the implementation is. It would be most useful if deployed by multiple registries, also outside of gTLDs, so even if not technical some outreach should be done to try finding registries willing to participate and/or deploy it later. So that during desigining no spots are missed. Also I think this is an extension that needs itself to be extended. I have seen the other document about the launchphase policies but I think the model should be different, so that extension data is still inside the <registry:infData> node. Here is an outline of what I thought, so names are just examples: among the nodes there would be a <policy> one with a "for" attribute whose value would be the XML namespace of the extension concerned by the policies that will be described inside this policy node. So infData will be mostly a list of <policy> nodes. The core document would define the blocks for RFC 5730 to 5733 (and maybe also RGP and DNSSEC) and then each other extension would define their own block content. Also, using the XML namespace as identifier may not be always possible: all policies regarding transport are in RFC5734 which has no XML namespace per se. So maybe instead of the XML namespace you could use the RFC number or the interne-draft name. In the long run if all of this work (independ of the specific implementation details) I would think at least an update to RFC3735 would be welcome that could add: * IANA registration in the EPP registry is mandatory * and description of the policy of the extension described must exist and conform to this document standard. More specifically now, about "2.3. Schedule" I am *strongly* against using the format proposed for at least 2 reasons: - crontab format is not a standard, and is ambiguous for various points - it encodes a format as a string which is itself in a formatted structure since it is XML. "Hijacking" some free form space when you are in formatted structure seems wrong to me and shows that the structure is not correctly formatted because if it were you would not have to inject a new format in a free text. Why not use ISO8601 Repeated Time Interval format? We are then still gulty of the previous point but at least it is a standard. Otherwise please amend the XML structure to break the content currently in the crontab format. As for timezones, all EPP standards always used UTC for all timestamps (and even if some registries on the field do not respect that), and I think it would be best to stick to that, so that removes the "tz" attribute. I find this unfortunate: <registry:name>: The zone name that can be at any level When you parse it, you read it as "a registry name", but then it is a zone. So while it could probably not be <zone:name> it should at least be <registry:zoneName>. You are speaking about "regex" in various places without referencing how is this formatted. There are multiple de facto regex "standards" so care must be taken there to reference precisely what kind of regex are manipulated. Also, for example for passwords, some registries policies are not possible to express (only) in regex I think, so there might be a blind spot here. alphaNumStart/alphaNumEnd/aLabelSupported/uLabelSupported and maybe others (all the IDNs ones) should be removed and instead LGRs (RFC7940) should be used/referenced: far more complicated but at least you cater for all cases. For IP addresses (min/max) you may need to separate between IPv4 and IPv6 as some registries may impose different constraints to each (including: IPv4 allowed but not IPv6) For contacts: - I think the design around int/loc policy does not capture all cases. Some registries allow int only; some loc; some int only or int+loc, some loc only or int+loc, some int only or loc only or int+loc, etc. (I am not saying all combinations exist, but there are at least more than one of them so we need to be able to handle that) - for the contact ID some registries let the registrars choose it (per the RFC5733 spirit) but some do not and just choose instead of them; it should be possible to encode this in the policy; there may also be the need to encode that in some cases the prefix of contact ids is not free, but fixed per registrar; maybe a need too to define what happens when 2 registrars try to create the same contact ID, depending on if they are global to the system or local to each registrar (the ROID would be different of course). Other things that would be useful to include (and could be done "easily" if you take my ideas on top to have blocks identified by the underlying XML namespace or RFC number): - data related to transport: number of connections, timeouts (soft and hard), recommended frequency of keepalive, etc. - data related to sessions: password policies (maybe both for registrar login and for domain authInfo) which go further than just regex you may want to code about lifetime of a password, and the sets/classes of characters allowed and their use (like mandatory one uppercase character, one lowercase, one "special", etc.), etc. For domain passwords, is <domain:null> allowed? (an arcane part of the standard that I know one registry does) Also/maybe: - various rate limiting (per command or not, etc.) - various hitpoints mechanism (ex: 1 hitpoint per EPP error, cut of all write operations after X hitpoints, for X days or token bucket like operations) - data about notification messages: how long are they kept in the queue? What happens at end of lifetime? - "extended" error codes used Finally, as bikeshedding as it may seem, I am not convinced that "Registry Mapping" is the correct naming here. The abstract talks about zones, features and policies. All other EPP standards talks about server and client, not about registry and registrar. I would favor changing the name of the extension and removing Registry from it. I lack good suggestions for now, maybe later. Policy Mapping? Metadata? Zone Metadata? -- Patrick Mevzek _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
