I agree: move on, and make this discussion a new work item for the group.
It was an interesting discussion by the way...
My opinion:
First of all, I don't know about real world examples of issues concerning
unsupported extensions by one of our registrars. When we introduce new
extensions,
Hi Linlin,
I did a review with a magnifying glass. Some things should really be fixed (or
rather MUST be fixed), some others are opinionated.
I'm preparing a review of the draft-ietf-regext-org-ext-06 too, but that's for
tomorrow
===
> 3.1
Hi Patrick,
>
>> Registry Mapping, Roger Carney
>> Open question on boot strap for registry mapping
>> Discussion about how to distribute the data and if it is public at all.
>> Question if this data should be in EPP, RDAP or something else.
>> Next step: make a draft, adaption
>
> Why is this
eview. I am preparing the update.
>
> Regards,
> Linlin
> zhoulin...@cnnic.cn <mailto:zhoulin...@cnnic.cn>
>
> From: Pieter Vandepitte <mailto:pieter.vandepi...@dnsbelgium.be>
> Date: 2018-05-20 04:29
> To: regext <mailto:regext@ietf.org>
> Subject: [regext
Hi Anthony,
Exactly the same question as Patrick. As I'm not in the registrar world, but
the registry world, I'm very interested in the use cases (or why) of EPP over
HTTP instead of EPP over TCP. But very willing to collaborate if there's a case
(not just because it is technically more fun to
gt; wrote:
>
> On Wed, May 23, 2018, at 13:36, Pieter Vandepitte wrote:
>> @Patrick, did you have time in mean time to catch up? How would you like
>> the draft to be changed in order to support it?
>
> I unfortunately think that I am not convinced by the use case, and I b
Hi all,
The registry I work for, developed a custom extension to manage "nameserver"
groups and "keygroups". When a registrar links a group to a domain, all member
nameservers/keys of that group are automatically linked to that domain. This
way, it is very convenient for DNS operators to
Hi all,
Other thoughts? I think it's important as document shepherd to know whether we
should move on or not.
Kind regards
Pieter
> On 21 May 2018, at 05:19, Patrick Mevzek wrote:
>
> On Fri, May 11, 2018, at 15:32, James Galvin wrote:
>> With that, version 06 of this
for better, more structured and machine interpretable
responses, but I don’t think the extra check step is the way to go. Just my 2
cents…
Kind regards
--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be
On 06/06/18 14:22, "regext on behalf of Gould, James&qu
"pendingCreate". The server operator reviews the request
offline, and informs the client of the outcome of the review either
by queuing a service message for retrieval via the command or
by using an out-of-band mechanism to inform the client of the
request.
Kind regards
Thanks, Roger,
It now makes much more sense to me.
Kind regards
Pieter
--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be<http://www.dnsbelgium.be>
[DNS_PUNT_Belgium_RGB]
From: regext on behalf of Roger D Carney
Date: Monday 11 June 2018 at 17:44
To: "rege
I have nothing to add. Just letting know I share the same opinion.
--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be <http://www.dnsbelgium.be>
On 14/06/18 00:45, "regext on behalf of Patrick Mevzek"
wrote:
On Mon, Jun 11, 2018,
Hi,
As I see discussions popping up now and then of 3rd party organisations having
to modify registry objects, wouldn't it be an idea to design something like
delegated EPP instead of implementing new protocols? Something like: a
registrar assigns a group to an object, then generates a token
ot a list of command to the EPP server.
Kind regards
Pieter
> On 26 May 2018, at 04:48, Patrick Mevzek wrote:
>
> Pieter,
>
> On Fri, May 25, 2018, at 21:37, Pieter Vandepitte wrote:
>> The registry I work for, developed a custom extension to manage
>> "namese
> delegation of epp to 3rd parties that are unknown to the registry does have
> some operational implications that need to be thought through. Although I
> suppose this group isnt regops.
>
>
> On 29/5/18 6:13 am, Pieter Vandepitte wrote:
>> Hi,
>>
>>
I follow the concerns of Patrick,
I'm neither a fan of the [LOGIN-SECURITY]. Isn't it enough to specify that a
server MUST ignore the value of if the loginSec extension is used?
I don't know if I overlooked it, but it seems that there's only support for
password based login and provisioning.
Just a small note... Shouldn't section 3.1.2 be renamed to EPP Command?
I think the purpose of the extension is to extend poll messages, no?
Moreover, the draft talks about
Example poll response
I think that's an error. Poll info does not exist. It should be poll req
Pieter
On 05 Jan
n.com<http://verisigninc.com/>
From: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on
behalf of Pieter Vandepitte
<pieter.vandepi...@dnsbelgium.be<mailto:pieter.vandepi...@dnsbelgium.be>>
Date: Monday, January 8, 2018 at 3:11 AM
To: "rege
name a few of them.
Isn’t this useful content for some kind of Best Practices document?
Kind regards
Pieter
--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be<http://www.dnsbelgium.be>
[DNS_PUNT_Belgium_RGB]
From: regext on behalf of Linlin Zhou
Date: Thur
Did anyone consider RFC 6321 (xcal)? It has features like recurrences too. A
maintenance event is basically just a calendar event + some data about the
scope/context...
Kind regards
--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be <http://www.dnsbelgium.be>
and other extensions.
Thoughts?
Pieter
--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be<http://www.dnsbelgium.be>
[DNS_PUNT_Belgium_RGB]
From: regext on behalf of Roger D Carney
Date: Tuesday 3 July 2018 at 20:04
To: Registration Protocols Extensions
Subject: [
I don't want to delay the publication, and I support it, but there are still
some issues/concerns
Typos/errors
> EPP provides two commands to retrieve domain information
Should be: "EPP provides two commands to retrieve organization information".
>This document does not define a mapping
>
> (1) I think the solution is just not right. It's a quick and dirty way of
> doing these things. The right way imo is defining a new RDAP extension (with
> a dedicated attribute to identify the authoritative source)
> (2) In my opinion there are other, existing, mechanisms for discovering
e:
>
> Dear Pieter,
> Thanks for your support. I'll update the text according to your comments.
> Please see some my feedbacks inline.
>
> Regards,
> Linlin
> zhoulin...@cnnic.cn <mailto:zhoulin...@cnnic.cn>
>
> From: Pieter Vandepitte <mailto:pieter
Hi, my 2 cents:
(1) I think the solution is just not right. It's a quick and dirty way of doing
these things. The right way imo is defining a new RDAP extension (with a
dedicated attribute to identify the authoritative source)
(2) In my opinion there are other, existing, mechanisms for
Thanks for the minutes. This also triggered me to re-read the DSF draft :)
Regarding reporting,
I don’t know the details of the conversations in that meeting, but keep in mind
that we are not the first ones to invent the wheel...
There are initiatives like CSV on the web
26 matches
Mail list logo