Martin,
if I understand you right, the problem is ignorant registrars. And the
solution is to make it easier for them to stay ignorant.
I am convinced that this is not the best way to go.
Clear communication with registrars and all internal departments sounds
more feasible.
We deploy these
> -Original Message-
> From: regext On Behalf Of Patrick Mevzek
> Sent: Tuesday, July 17, 2018 3:37 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Tidbits after monday meeting, related to
> registry mapping extension => IPR
>
> I discovered this myself just before the meeting
Changed milestone "Submit for publication "Registration Data Access Protocol
(RDAP) Object Tagging"", resolved as "Done".
URL: https://datatracker.ietf.org/wg/regext/about/
___
regext mailing list
regext@ietf.org
Ulrich
I am impressed by your process of checking who tested and who did not and
actively contact those who did not test. We did something like that as well
when we turned off TLS1.0 so I agree to this procedure for some cases.
It kind of confirms my statement that a technical change needs
Good Morning,
Thanks Pieter. I think the real goal of Validate is improved customer
experience.
I don’t think wrapping this in a transaction helps as the error identification
is still occurring to late in the process.
There are quite a few steps in the registration process but today one of
Hi Ulrich
We do have contracts yes. However experience shows us that some registrars just
don't have the necessary technical skills or means to react on any changes we
ask them to implement. To pull a change through, long dead lines must be
granted and even after that, only a part of them
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
Specific points related to RFC5730:
* clTRID is optional; but some registries make it mandatory
* some registries do not allow some commands, like contact:transfer being not
implemented (this is very frequent)
or even sometimes contact:check (especially if registrars do not control their
IDs),
* some registries allow, in domain:create, either attributes or objects for
host.
One might say this is against the core EPP specification, so do we want to
treat it?
* some registries do not allow all possible values for IP addresses. For
example one is saying that it will
refuse any IP
I discovered this myself just before the meeting when preparing it but Scott
also clearly mentioned it during the meeting (thanks for that): there is
currently an IPR on this extension, with the case of "details will be provided
later".
You may recall that we were in a similar case for the
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
11 matches
Mail list logo
