Patrick, Thank you for your detailed feedback. We'll take a look at your following messages. I believe the goal of the Registry Mapping is to hit on the most common use cases and leave exceptional cases up to extensions (the 80/20 or 90/10 rule). If there is a crosscutting policy being applied across many registries then it is a good candidate for inclusion directly within the Registry Mapping.
Thanks, — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/17/18, 3:33 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: https://datatracker.ietf.org/doc/html/draft-gould-carney-regext-registry Multiple subjects were covered and I had to input some data, so I will be doing different topics by replying to this email so that they are threaded together. You may wish to read all of them for context before replying to any. I only took a quick read of some documentation I currently have on hand for some registries, and this is far from exhaustive. I am not putting the registry names as I do not think that changes anything, but you will have to trust my word that I am not making up cases. Otherwise, the registry that recognize themselves could also speak up and say if they would deploy this extension. Like I said, to be a success, this extension needs to be widespread. It needs to be made in such a way that it can encompass very different cases. And for the one point specifically raised (control over the contact IDs, while the RFC may say there are completely under control of registrar, in practice for many ccTLDs registries it is the registry that choose the ID at creation, irrespective to what the registrar asks for), it needs to be easy to derive it separately in an extension for deviations from base. In fact, here is a generic comment: I think there is already things belonging in an extension that are indeed in the base document, so that should be split. For example, about contact types, while it is obvious that there are other ones on the wild, RFC5731 defines only 3, and not "custom". So custom should be dropped from core document. Same for privacy/proxy these concepts are not in RFC5733, and should be handled in extensions. -- 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
