Patrick, I respond to your feedback below. — JG
James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 12/11/18, 2:14 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: Hello, Back in July I sent group of emails with details seen in the wild that may need to be in the extension, or not. I am only responding to this one about the form in fact and not the content, because I was kind of surprised by various points in the replies I got like: > How many registries do this (many, some, few, or just one)? This is the first time I see a count of registries being asked to finally decide how to implement something or not. JG - Identifying the breadth of a implementation choice helps to categorize where a policy should reside (in the base draft or optionally in a policy extension). If there are "many", then it is a great candidate for inclusion in the base draft, if it's just "one" then it is a great candidate for inclusion in a policy extension, and when it's "some" or "few" then it may require more discovery and discussion to determine the course of action. Not everything belongs in the base draft, since a policy can be described in an extension-specific policy extension (e.g., draft-gould-regext-launch-policy, draft-gould-regext-login-security-policy) or a server-specific policy extension (e.g, example-server-policy). In fact recent cases show that we did exactly the opposite: for the fee extension and the very late inclusion of the standard attribute, if we summarize things we had - one registrar asking for it but not really promoting it nor participating on discussions - 2 registries saying basically "it is optional, we will not use it, so we are neutral to it" - one client side implementor (me) and one registry saying: this lacks a true purpose and is dangerous for interoperability. Result: it passed, the attribute was added! JG - You are referring to the OPTIONAL "standard" attribute in the <fee:check> command. As the document shepherd for draft-ietf-regext-epp-fees, I raised the consensus issue on the list with the message https://mailarchive.ietf.org/arch/msg/regext/3v2sblGhLVvHvgFyBkjETPodGbw, which originated at IETF-100 with the mailing list thread https://mailarchive.ietf.org/arch/msg/regext/E_oE3luLvB6B2c082-0PHvYZP9o. There was a group that met on it at IETF-102 (minutes posted to list message https://mailarchive.ietf.org/arch/msg/regext/dykfIv-Edy5ZAdWd1cTnPPnifzc), which included you remotely, that agreed to include the "standard" attribute but to move it from the check command (commandType) to the check response (commandDataType). This was also discussed at the IETF-102 REGEXT meeting. I characterize the agreement for the inclusion of the "standard" attribute in draft-ietf-regext-epp-fees based on what was posted on the mailing list. Based on that, I do not see why now we should dictate what goes in or not based on how it is used in the wild. I think you have basically three options: - encode only exactly what core EPP documents allow - try to filter things and define those used often enough to warrant being included from those used by only "1" registry that are put aside and would need an extension - put everything in. We are not doing 1) because last time I read the specification there are things in it that are clearly not in EPP core documents (like "custom" contact types). We seem to be trying to do 2) which is very dangerous because it leads to questions like above and if you match that by the very low amount of exchanges on this list, I really fail to see how we can make sure to take the proper decisions as a group. And of course, by "extension" 3) would be as well difficult to reach. JG - We can remove the "custom" contact type if that makes sense. As stated many times before, the draft-gould-carney-regext-registry defines the framework for identifying the features and policies of a registry, that includes the MAYs, SHOULDs, and options include in the original EPP RFCs, and with a framework for the definition of policy extensions at the system-level and at the zone-level. As with any EPP extension, there can be standard policy extensions and proprietary policy extensions. But at least my position is basicall a 2) without treating some cases as second class citizen just because they are rare or further away from "pure" EPP. Of course it would help if each registry participated and were champions for their own cases but obviously we are not there nor will we be in a short future. Or otherwise we really do 1) but then multiple things will need to be removed (custome contact types, privacy/proxy, etc. I listed some in my previous emails). JG - If you have a list of non-RFC related items that should be removed, please provide that list again. I believe that I captured the items raised thus far in the GitHub project (https://github.com/james-f-gould/EPP-Registry-Mapping/issues), but there may be more that I didn't capture. So, I do not think it is useful for this working group that I reply extensively on each point, where I mostly detailed what is happening in the wild currently, that we may like or dislike on an engineer level, but then the question I think is really how much we want this "registry policy" extension to be implemented by many registries, and not by the ones closer to "standard" EPP. JG - I don't see this as being unimplementable by registries that don't closely follow the EPP RFCs, since they can provide their policy overrides in a server-specific policy extension. I don't believe that draft-gould-carney-regext-registry should attempt to capture non-RFC compliant policies. If draft-gould-carney-regext-registry became an RFC, what would stop registries from not following it as defined (similar to what has happened with some registries not implementing to the EPP RFCs)? Even if I may not have phrased things good enough, I hope the above will have succeeded in trying to raise awareness about the so many different cases in the wild and the need to try to "accomodate" if we want success both in term of numbers of implementations and avoiding fragmentations (where multiple extensions exist to do exactly the same thing in fact). -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
