On Tue, Nov 27, 2018, at 11:28, Gould, James wrote: > > * Ensure that the hostAddr model of RFC 5731 is supported > > <https://github.com/james-f-gould/EPP-Registry-Mapping/issues/1> * > > *Discussion* > > * In the case of a zone that supports domain:hostAddr instead of > > domain:hostObj, > > No. It is not "instead". > Have a look at the example on page 19 of some registry documentation > at > https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf
[..] > The purpose of draft-gould-carney-regext-registry and the policy > extensions is to define the policies around the SHOULDs, MAYs, and > options included in extension RFCs, I-Ds, custom extensions, and to > define the server-specific policies. If a registry chooses not to > follow the MUSTs in the extensions, that is their choice. They can > define their custom, non-compliant policies in a server-specific policy > extension of draft-gould-carney-regext-registry. Custom policy > extensions can be created that define system-level and zone-level > policies that don't need to go through the IETF. There is no need to > attempt to address non-compliant policies in the standards track I-Ds. I think you are missing the point I try to raise here. It is of course very easy to dismiss this specific case (but there are tons of others) because the RFC says "MUST", and the case does not follow it, so it is deemed invalid per RFC specifications and can then be ignored. Technically, yes. But this has consequences for the future. First, let me reiterate how important I think this extension is, and I wished we had it many years ago already. With it, life of registrars would be tremendously easier. Which would then also make registries life easier. **IF** (and this is the big if and the core of my point) it gets implemented, and this is where I fear problems, even more so because there is basically no discussion on this list from other registries about it. For me the future can morph into the following cases: 1) a registry is fully conformant with all RFCs and hence could implement this extension as is without difficulties. It is just a policy/business/marketing case to decide to implement it or not, the specification is not a barrier 2) registries that decided not to implement it anyway, for whatever reasons and case they are in 3) registries that DO NOT respect all RFCs to the letter and/or are in cases not handled by this new extension and that are thinking about implementing it or not. If they want to implement it they have the choice: a) either to change their policies and business rules that either contradicts core EPP documents or are incompatible with the extension as written right now b) or to create **another** EPP extension just to code for the differences between the kind of policies that can be encoded in your extension and the registry policies that do not fit in The above are facts, the below are my assumptions. - case 1 will be mostly gTLDs or said differenly I doubt many ccTLDs will fall in this case - case 2 is irrelevant for this discussion as nothing we discuss can change that - case 3 is the interesting point, and my assumption is that this will group basically all ccTLDs, and my further assumptions are that of course registries will not change their policies just because this extension is not tailored to them (so 3a will mostly be empty) and I doubt many will go the length of writing a new extension just to codify their policies (so 3b will be negligible) [BTW 3b introduces again the exact same problem we had with EPP extensions since the beginning: fragmentation. Multiple registries have a "trade" operation for example. To encode that as policy, there is a risk each one drafting an extension for it, and then you come back to the case of multiple non-interoperable extensions that do the same things which is a nightmare] So I fear that at the end we will have something beautiful that caters for all the generic/simple cases, but that left out all complicated cases, and hence the implementation will not be widespread. The fact that no registry claimed to be willing to implement it or to write an extension for their own policy is very troublesome for me. But maybe it happened in private or will be announced in the future. -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
