Patrick,
I like how you have broken down the problem into discrete registry
implementation cases that can be applied to any EPP extension. To make the
core object-extension (draft-gould-carney-regext-registry) workable, we need to
target case 1 (fully RFC-compliant registry implementers) and case 3b
(implement base and standard policy extensions along with a server-specific
policy extension for unique policies), since the goal is to define policies
associated with the SHOULDs, MAYs, and options included in RFCs. Case 3b could
also be a sub-option for case 1 (1a), since a fully compliant registry
implementer may have unique RFC-compliant policies that they need to define.
Targeting case 2 does not make any sense, since those not implementing
draft-gould-carney-regext-registry will most likely not speak up. Targeting
case 3a is highly unlikely to be successful, since why would an implementer
change their policy to support defining their policy externally? Also, case 3a
is equivalent to case 1 from a draft-gould-carney-regext-registry perspective.
I also have a 3c case, where the implementer creates a Registry Mapping-like
implementation by not following the normative language or/and customizing the
XML schema. In the end, the best that we can do is to define a solid base
draft that covers the SHOULDs, MAYs, and options of the EPP RFCs, with the
ability to define system-level and zone-level policy extensions that cover the
policies of specific EPP extensions or a server-specific policy. I would
imagine that if there is a need for a server-specific policy extension, that
the implementer would define just one. For clarity, I include the revised
draft-gould-carney-regext-registry implementation cases below:
1. Fully RFC-compliant Registry Implementers - Implementation driven by
policy/business/marketing case.
* Optionally create Server Policy Extension for server-specific policies
2. Registry Non-Implementers - Registries not implementing for a variety of
reasons.
3. Non RFC-compliant Registry Implementers
* Change policies to be compliant with RFCs
* Define Server Policy Extension for server-specific policies (e.g., RFC
overrides)
* Create Registry Mapping-like implementation (e.g., not following
normative language and/or XML schema in draft-gould-carney-regext-registry)
—
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, 1:53 AM, "regext on behalf of Patrick Mevzek"
<regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote:
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
