ore and more gTLDs will get thin.
>
> Ciao
> Marco
>
>
> On 31 January 2025 00:31:45 CET, Rubens Kuhl
> wrote:
>>
>> Don’t the remaining thin registries allow for thin to thick migration on a
>> granular basis ?
>>
>>
>> Rubens
&
Don’t the remaining thin registries allow for thin to thick migration on a
granular basis ?
Rubens
> Em 30 de jan. de 2025, à(s) 18:24, Marco Schrieck
> escreveu:
>
> Hi
>
> Yes the registry should generate them, but what with thin Registries.
>
> Only we as registrar have the contact d
the RIRs side. :)
>
> Thanks for pointing to the NIC BR’s EPP extensions.
>
> Jasdip
>
> From: Rubens Kuhl
> Date: Friday, December 13, 2024 at 2:29 PM
> To: Jasdip Singh
> Cc: Rubens Kuhl , Gould, James
> , regext@ietf.org ,
> r...@ietf.org
> Subject
ngh escreveu:
>
> Hi Rubens,
>
> Since couple of these involve number resource provisioning, curious if it is
> desired from the NIC BR perspective that these use cases be considered
> upfront for RPP?
>
> Thanks,
> Jasdip
>
> From: Rubens Kuhl
> Date: Fr
James,
Follows links to extensions in active use although not in the IANA registry,
from use cases in the RIR/NIR system and ccTLDs:
https://ftp.registro.br/pub/libepp-nicbr/draft-neves-epp-asn-02.txt
https://ftp.registro.br/pub/libepp-nicbr/draft-neves-epp-brdomain-05.txt
https://ftp.registro
Not following the same semantics of an specific gTLD registry that was the
first to adopt Thick WHOIS is different from not following the EPP standard.
I agree with Thomas that those specific examples are not EPP, but all gTLDs and
most ccTLDs follow EPP to the letter.
Rubens
> Em 22 de
if possible and palatable, recharting RegExt still looks better to me.
And this is orthogonal to the ICANN risk that has been mentioned, which can be
addressed by not obsoleting or updating EPP RFCs, as they are the ones
mentioned in the gTLD agreements.
Rubens
> Em 24 de jul. de 202
I believe option 1 with the re-charter option is better.
It’s not an extension.
Compatibility with existing object mapping and extensions should be
best-effort, and new extensions should specify whether it applies only to EPP,
only to REPP or to both(supporting both is preferred but not mandat
REPPP is not a transport, it’s much more than that. And changing RFC 5730 has a
trickle-down effect to some of the EPP users that might be unwanted, like the
gTLD space.
But rechartering this WG seems the most logical course of action, since this
audience is likely the one for discussing REPP
Some comments:
- I believe an idempotency considerations section is in order and its writing
will allow confirmation of idempotency throughout the spec
- For instance, it would have indicated the renewal section to have a MUST
instead of a MAY for the current expiration date. Without that there
I was reviewing a documentation that mentioned RDAP over DTLS… was that ever
defined ? I always thought of RDAP thru TCP-based TLS and remember ideas of
using RDAP over QUIC, but DTLS was not a transport I’ve heard of being used
with RDAP.
If defined, is it a SHOULD or a MUST ?
Rubens
si
> On 11 Aug 2020, at 16:27, Patrick Mevzek wrote:
>
> Hello Marc,
>
> On Tue, Aug 11, 2020, at 13:55, Marc Blanchet wrote:
>> On 4 Aug 2020, at 15:47, Patrick Mevzek wrote:
>>>
>>> PS: related but not directly, at least for domain registries, it would
>>> be
>>> nice to have an `SRV` record o
> On 23 Apr 2019, at 05:12, Michael Bauland wrote:
>
> Hi Rubens, Jim (btw is it now Jim or James?), and Quoc,
>
> thanks for you responses.
>
> On 19.04.2019 15:55, Gould, James wrote:
>> I mirror Rubens response, that there exists system-to-system multi-factor
>> authentication for EPP wit
Do you mean 3rd or 4th, since most EPP systems already have two factors
(password and certificate), and some of those also require IP whitelisting.
I believe we already have the tools for the job in this area. And if a registry
wants to add some extra layer, the password field could be password
> On 26 Feb 2019, at 14:46, Tony Finch wrote:
>
> Rubens Kuhl wrote:
>>
>> I imagine that DNS as a communication channel to assure registrant
>> willingness to change something, similar to CDNS/CDNSKEY, could be quite
>> useful. For instance, if the name
I imagine that DNS as a communication channel to assure registrant willingness
to change something, similar to CDNS/CDNSKEY, could be quite useful. For
instance, if the name servers that are delegated on the registry are now
pointing to new name servers, and this response is signed by the curre
While my experience is more with host attributes registries, I wonder if
removing the single address of a host object would be forbidden because that is
actually leaving the object with no content at all.
Does the same happen if the object already had a v4 and a v6 address, and you
then remove
I believe there is either a minor omission or punctuation error at Page 17:
6.3. Neustar gTLD SRS
Organisation: Neustar Inc.
Gould & Feher Expires July 6, 2018 [Page 17]
Internet-Draft allocationTokenJanuary 2018
Name: Neustar gen
Isn't the sponsoring registrar already available in the clID field of the
object ?
Rubens
> On Sep 18, 2017, at 9:08 AM, Gould, James wrote:
>
> Jody,
>
> You don’t have any use for retrieving the sponsoring registrar information
> via EPP in the support of transfers? A registrar could c
Jody,
Would that also apply to the use of the extension to signal the DNS operator ?
Rubens
> Em 15 de set de 2017, à(s) 18:05:000, Jody Kolker
> escreveu:
>
> Hi Jim,
>
> We do not have any intention at this time of implementing this draft. We
> have no desire to send reseller informa
> Em 17 de jul de 2017, à(s) 19:42:000, Jody Kolker
> escreveu:
>
> Active to me means a phase where the start date is in the past and the end
> date is in the future.
>
> This interpretation would cause an issue when a check is performed if a
> registry was in a quiet period between phase
James,
I understand your concern with option #1, but I think option #3 goes into a
different set of issues where we mix the domain sales pipeline with domain
management activities, for which domain:info is commonly used.
I'm neutral between option #1 and option #2, but while both work me, I w
> Em 3 de abr de 2017, à(s) 10:43:000, Alexander Mayrhofer
> escreveu:
>
> Rubens Kuhl wrote:
>> .br has run such an UDP-based protocol for almost 10 years... it's called
>> isavail, uses UDP port 43 and implements a session cookie mechanism in
>> ord
> Em 3 de abr de 2017, à(s) 10:26:000, Alexander Mayrhofer
> escreveu:
>
Better would be something akin to Nominet's DAC protocol:
http://registrars.nominet.uk/namespace/uk/registration-and-domain-
>> management/query-tools/dac/instructions
>>>
>
> For what it's worth, we (.at
>
> I'm not saying there aren't tonnes of potential issues with Nominet's
> DAC protocol, but it's a closer match to the needs of registrars than
> RDAP is.
I will add that I see the same from a registry view.
Rubens
___
regext mailing list
rege
Besides the concerns already mentioned by Michele, I add that using a TCP+TLS
based mechanism adds latency that is not the best friend of a sales pipeline.
When this topic last appeared I suggested considering DTLS transport and I
repeat that suggestion, adding that an availability protocol s
> Em 7 de dez de 2016, à(s) 20:13:000, Andrew Sullivan
> escreveu:
>
> On Wed, Dec 07, 2016 at 03:16:01PM -0200, Rubens Kuhl wrote:
>>
>> Unintuitive as it is, that was exactly the output of the ICANN EWG on RDDS.
>
> Perhaps fortunately, the EWG's output
> Em 7 de dez de 2016, à(s) 15:12:000, Gould, James
> escreveu:
>
> Andrew,
>
> Yes, RDDS is aware of the data but not of all the business rules that is
> needed to support the SRS. RDDS is a lookup protocol and just because there
> is one or some implementations out there that have include
> Em 7 de dez de 2016, à(s) 15:04:000, Andrew Sullivan
> escreveu:
>
> On Wed, Dec 07, 2016 at 03:30:24PM +, Gould, James wrote:
>> It sounds like you’re attempting to morph RDDS into the SRS.
>
> Nope.
>
>> RDDS is a lookup service and the SRS is an OLTP system. A lookup
>> service eith
> On Dec 7, 2016, at 5:48 AM, Mario Loffredo wrote:
>
> Hi all,
>
> I have a question about how to deal with RDAP lookup queries for reserved or
> unassignable domains.
>
> If a client submits a query about a reserved or unassignable domain, which
> response code should the server return?
>
> Em 22 de set de 2016, à(s) 17:55:000, Dave Piscitello
> escreveu:
>
> I can't process this without understanding what deficiencies are known, not
> addressed by RDAP or provably uncommercial.
>
> Assistance or speculation invited.
The RDS PDP WG has a gigantic laundry list of what deficie
> Em 22 de set de 2016, à(s) 17:39:000, Andrew Newton escreveu:
>
> On Thu, Sep 22, 2016 at 3:52 PM, John Levine wrote:
>> In article <83c4fe76-52e8-48ed-b6c2-0691555d3...@icann.org> you write:
>>> I think there are two parts to your question. First, the Registry
>>> Stakeholder Group (RySG) r
> Em 22 de set de 2016, à(s) 15:46:000, Francisco Arias
> escreveu:
>
> I think there are two parts to your question. First, the Registry Stakeholder
> Group (RySG) request for reconsideration that triggered this proposal;
> perhaps someone else in this list (from the RySG) can speak to that.
> Em 22 de set de 2016, à(s) 15:56:000, Hollenbeck, Scott
> escreveu:
>
>> -Original Message-
>> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Francisco
>> Arias
>> Sent: Thursday, September 22, 2016 2:46 PM
>> To: Andrew Newton
>> Cc: regext@ietf.org
>> Subject: Re: [regex
34 matches
Mail list logo
