Re: [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl

[Jothan Frakes]

+1 to adopt

Jothan Frakes
Tel: +1.206-355-0230



On Wed, Apr 26, 2023 at 8:25 AM Hollenbeck, Scott  wrote:

> > -Original Message-
> > From: regext  On Behalf Of Antoin Verschuren
> > Sent: Tuesday, April 25, 2023 4:54 PM
> > To: regext 
> > Subject: [EXTERNAL] [regext] CALL FOR ADOPTION:
> draft-regext-brown-epp-ttl
> >
> > Caution: This email originated from outside the organization. Do not
> click links
> > or open attachments unless you recognize the sender and know the content
> is
> > safe.
> >
> > This is a formal adoption request for Extensible Provisioning Protocol
> (EPP)
> > mapping for DNS Time-To-Live (TTL) values:
> >
> >   https://secure-
> > web.cisco.com/1vtHPNRjRoP018Btc9HtpkrlEP8X4IRXSodTHdma89uV-
> > 59o3wBXYUKsuEJOIDko-dUIR-
> > fujfpHzenyYS1YNt2Ml2Siv917k4vaR1en_cDLK8eopYMt4g7eplcfjaVmqC7kWm6b
> > N8AbjmViEiqfzC1u8H5i4qRqbFx_stlr9G8_tPX0uZP5-yZGRc7SHrC_f9IpS-
> > zeJb3S1mFPFaDaM92LPOOzro93GndI8mSrj5EpW-
> > A5yMkrOVgDGQ9VewJqC6_b0UZnFgZ0z_2G-
> > G8Y1088XlYiMifLDbaoAdSt9VLI/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2
> > Fdraft-regext-brown-epp-ttl%2F
> >
> > Please review this draft to see if you think it is suitable for adoption
> by REGEXT
> > and comment to this message on the list, clearly stating your view.
> > Optionally indicate if you are willing to contribute text, review text,
> or be a
> > document shepherd.
>
> [SAH] I support adoption and am willing to review and contribute text as
> needed.
>
> Scott
>
> ___
> 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

[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

[Jothan Frakes]

+1

On Mon, Jun 3, 2024, 7:56 AM James Galvin  wrote:

> The document editors have indicated that the following document is ready
> for submission to the IESG to be considered for publication as a Best
> Current Practice:
>
> Best Practices for Deletion of Domain and Host Objects in the Extensible
> Provisioning Protocol (EPP)
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-delete-bcp/03/
>
> Please indicate your support or no objection for the publication of this
> document by replying to this message on list (a simple “+1” is sufficient).
>
> If any working group member has questions regarding the publication of
> this document please respond on the list with your concerns by close of
> business everywhere, Monday, 17 June 2024.
>
> If there are no objections the document will be submitted to the IESG.
>
> The Document Shepherd for this document is Andy Newton.
>
> Thanks,
>
> Antoin and Jim
> REGEXT WG Co-Chairs
>
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org
>
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: ccTLDs using EPP

[Jothan Frakes]

Pretty much all the TLDs on the patrons list of this site use EPP
https://cocca.org.nz/ which should add about 50 or so


On Wed, Aug 21, 2024 at 11:37 PM Tobias Sattler  wrote:

> I investigated which ccTLD might run EPP a while ago based on publicly
> available information.
>
> I don’t know if those ccTLDs are following this list, and I cannot
> guarantee its 100% correctness, but maybe it helps you.
>
>
> https://docs.google.com/spreadsheets/d/1IMk5TBzeoJTOwDJfQ-I50Kztwr3bipdjcLKy1etG3cg/edit?usp=sharing
>
> On 22. Aug 2024, at 00:40, George Michaelson  wrote:
>
> please post back, or write it up online somewhere and point us at it!
>
> _G
>
> On Thu, Aug 22, 2024 at 8:08 AM Orie Steele 
> wrote:
>
>
> Hi,
>
> I was chatting with Paul Hoffman, about Restful EPP, and we were wondering
> how many ccTLDs using EPP are following this list.
>
> If you don't mind messaging me offlist, sharing a bit about yourself and
> your thoughts on EPP / Restful EPP, I would appreciate it.
>
> Regards,
>
> OS, ART AD
>
>
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org
>
>
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org
>
>
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org
>
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

Re: [regext] Using RDAP as a Domain Availability Service

[Jothan Frakes]

While I would push people towards epp check, having domain availability in
an anycasted zone for DNS queries is so much more lightweight.

We did this in .cc back in 1998

The registry loses the ability to measure which domains are getting looked
up or measure volumes accurately, but registrars already use zonefiles or
cached results and look to alternatives to epp check to speed the process
of responding to customers in order to not lose sales, so that data on
checks is not 100% no matter what.

Check commands are read-only, so this increases resilience and speed.

Smart move, Chris!

-jothan

On Apr 3, 2017 8:09 AM, "Chris Cowherd"  wrote:

> Have you seen this: https://gist.github.com/case/b979575e2feb1c3810d1
>
> Donuts is considering implementing it
> On Mon, Apr 3, 2017 at 6:47 AM Rubens Kuhl  wrote:
>
>>
>> Em 3 de abr de 2017, à(s) 10:43:000, Alexander Mayrhofer <
>> alexander.mayrho...@nic.at> 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
>> order to enforce rate limits.
>>
>>
>> [OT] Interesting! Do you have a protocol specification available
>> somewhere? I can see there is some code in various languages  at
>> ftp://ftp.registro.br/pub/isavail/ , but it doesn't seem to include a
>> formal spec?
>>
>>
>>
>> It's described here in an alien language known as Portuguese. ;-)
>> https://registro.br/tecnologia/Protocolo-ISAVAILv1.txt
>>
>> I don't think it has been described as an I-D.
>>
>>
>> Rubens
>>
>> ___
>> regext mailing list
>> regext@ietf.org
>> https://www.ietf.org/mailman/listinfo/regext
>>
> --
> Chris Cowherd, CTO Donuts Inc.
>
> ___
> 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

Re: [regext] WG LAST CALL: draft-ietf-regext-data-escrow-01 draft-ietf-regext-dnrd-objects-mapping-01

[Jothan Frakes]

+1

On Fri, Oct 4, 2019, 2:21 PM Owen Smigelski 
wrote:

> +1
>
> > On Sep 27, 2019, at 6:40 AM, James Galvin  wrote:
> >
> > This is a reminder to please indicate your support or comments regarding
> these drafts.
> >
> > Thanks!
> >
> > Antoin and Jim
> >
> >
> >
> > On 20 Sep 2019, at 9:31, James Galvin wrote:
> >
> >> The following working group documents are believed to be ready for
> submission to the IESG for publication as a Proposed Standard:
> >>
> >> https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/
> >>
> https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/
> >>
> >> These documents are a set and will be processed together.
> >>
> >> The WG LAST CALL will end in two weeks at close of business, Friday, 4
> October 2019.
> >>
> >> Please review these documents and indicate your support (a simple “+1”
> is sufficient) or concerns with the publication of these documents by
> replying to this message on the list.
> >>
> >> Finally, we need a document shepherd for these documents.  If you are
> interested in being the document shepherd please let the Chairs know by
> sending a message to the list or to regext-cha...@ietf.org.
> >>
> >> Thanks!
> >>
> >> Antoin and Jim
> >
> > ___
> > 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
>
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

[Jothan Frakes]

@Tomas  I could see someone submitting a non-conforming fee extension in
the check command to trick the registry into providing basic availability
or taken of a name.

Possible: perhaps
Probable: unlikely

You make a good point that the respective command, especially billable
events, should perhaps check that the appropriate fee extension was sent.
Depending upon the registry implementation, this could theoretically work,
but a registrar would still have to pay the respective registry designated
fee for a create/renew/transfer,

I am working very hard to imagine why someone would go to the trouble of
sending the wrong fee extension with a command if they were going to be
sending one at all.

Jothan Frakes



On Fri, Jun 26, 2020 at 7:47 AM Gould, James  wrote:

> Thomas,
>
> Yes, to cover the corner case, avail="0" is the best response when the
> client does not include "create" in the fee extension of the check command
> of a premium domain name.  Without knowing the create fee of the premium,
> the create will likely fail, thus avail="0" is the correct answer.  The
> intent of the language in the RFC was to cover the broader case of a client
> that doesn't pass the fee extension at all in the check command, but your
> corner case is applicable.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com
> 
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 6/26/20, 10:41 AM, "Thomas Corte (TANGO support)" <
> thomas.co...@knipp.de> wrote:
>
> Hello James,
>
> On 6/26/20 16:18, Gould, James wrote:
>
> > but to cover the intent of the RFC the safest approach is to return
> avail="0" for a premium domain if the fee extension is not passed in the
> check command.
>
> In my example, the fee extension was passed, but only asking for the
> *renew* fee (which may be standard), not for the *create* fee (which
> may
> be non-standard). Based on your answer above, the server would have to
> return avail=1" then (because *some* fee extension was passed), however
> the client would still be unaware that the create fee is non-standard..
>
> If the "safest approach" is the goal here, it would probably be better
> (albeit indeed more implementation effort) to not only require the fee
> extension, but to specifically require the fee extension checking the
> "create" price, no?
>
> In this case, the RFC text may need a clarification, as it currently
> doesn't reflect such a specific requirement. I'm aware this is a rare
> corner case, but still one that should be covered.
>
> Best regards,
>
> Thomas
>
>
> --
> TANGO REGISTRY SERVICES® is a product of:
> Knipp Medien und Kommunikation GmbH
> Technologiepark Phone: +49 231 9703-222
> Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
> D-44227 Dortmund   E-Mail: supp...@tango-rs.com
> Germany
>
>
>
> ___
> 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

Re: [regext] New Version Notification for draft-ietf-regext-rfc7484bis-02.txt

[Jothan Frakes]

+1draft-ietf-regext-epp-registry-maintenance looks good to me

Just to be clear, since this is a 2nd WGLC, the new WGLC is for
> draft-ietf-regext-epp-registry-maintenance-12



> > Op 29 mrt. 2021, om 14:49 heeft Antoin Verschuren 
> <> het volgende geschreven:
> >
> > The following working group document is believed to be ready for
> submission to the IESG for publication as a standards track document:
> >
> >
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/
> >
> > EXTRA ATTENTION: This is the second WGLC for this document. During the
> first WGLC, there were still some substantial comments to be addressed, and
> there was not enough positive feedback to declare consensus on this
> document. Let’s do better this time and please take the time to review this
> document and indicate your support (a simple “+1” is sufficient) or
> concerns with the publication of this document by replying to this message
> on the list. Since we have 3 authors, we need more reviewers to state
> support!
> >
> > This WG last call will end at close of business, Monday, 12 April 2021.
> >
> >
> > The document shepherd for this document is James Galvin.
> >
> > Regards,
> >
> > Antoin and Jim
> >
> >
> >
> > ___
> > 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

Re: [regext] New Version Notification for draft-ietf-regext-rfc7484bis-02.txt

[Jothan Frakes]

Hi Jim-

I support both but the focus on my email was to provide a +1 support for
registry-maintenance

-Jothan



On Mon, May 3, 2021 at 5:59 AM James Galvin  wrote:

> Jothan,
>
> Your message is confusing.
>
> The subject of the message suggests you’re supporting rfc7484bis, but the
> content of the message is all about registry-maintenance.
>
> Would you please clarify your support?
>
> Thanks,
>
> Jim
>
>
> On 15 Apr 2021, at 12:50, Jothan Frakes wrote:
>
> +1draft-ietf-regext-epp-registry-maintenance looks good to me
>
> Just to be clear, since this is a 2nd WGLC, the new WGLC is for
>> draft-ietf-regext-epp-registry-maintenance-12
>
>
>
>> > Op 29 mrt. 2021, om 14:49 heeft Antoin Verschuren 
>> <<i...@antoin.nl>> het volgende geschreven:
>> >
>> > The following working group document is believed to be ready for
>> submission to the IESG for publication as a standards track document:
>> >
>> >
>> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/
>> >
>> > EXTRA ATTENTION: This is the second WGLC for this document. During the
>> first WGLC, there were still some substantial comments to be addressed, and
>> there was not enough positive feedback to declare consensus on this
>> document. Let’s do better this time and please take the time to review this
>> document and indicate your support (a simple “+1” is sufficient) or
>> concerns with the publication of this document by replying to this message
>> on the list. Since we have 3 authors, we need more reviewers to state
>> support!
>> >
>> > This WG last call will end at close of business, Monday, 12 April 2021.
>> >
>> >
>> > The document shepherd for this document is James Galvin.
>> >
>> > Regards,
>> >
>> > Antoin and Jim
>> >
>> >
>> >
>> > ___
>> > 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
>
>
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] A Radical Idea for draft-ietf-regext-rdap-openid

[Jothan Frakes]

Great Idea, Scott.

Let's call those Path A and Path B

Were you envisioning that A or B were ok, or are you suggesting Path B only?

I recommend that either should be possible in order to let this grow faster
in adoption.

If what you described in Path B could be presented as an option, leaving
room for those for whom Path A would be preferred to still use Path A, it
might be best.

I look at the n+1 on integrations that of BERO and registrar systems in the
wild, and then consider there are 5-6 or more OID providers out there.

That is a bit of a matrix.  Also consider all the various topologies of
architecture where systems are isolated for security, there might be a lot
of work forced on Ry/Rr if they have to operate some form of shim to
support Path B automation.

Path B integrations vs just receiving a couple fields on an administrative
panel in Path A also could represent more engineering costs and perhaps in
some cases contractual or financial relationships for use of those systems.

Among the benefits from DNSSEC has been good user journey data on how
additional integration work can hobble adoption, despite all the added
elegance or increased benefits.

-Jothan


On Sun, Jan 30, 2022, 6:24 AM Hollenbeck, Scott  wrote:

> I've been writing my own RDAP server code to test the concepts described
> in the latest version of draft-ietf-regext-rdap-openid. That's given me
> some real insight into what works, what doesn't, and how easy or hard it is
> to use.
>
> An RDAP server that supports OpenID Connect MUST implement basic session
> management to associate an RDAP query with the redirect that comes back
> from an OpenID Provider after an end-user is identified and authenticated.
> That got me thinking: if the server must do session management, how can I
> make this easier for the client/end-user so that they don't have to deal
> with the tokens?
>
> Here's my radical idea: change the draft such that it includes login and
> logout functions and eliminate the externally visible token management
> functions. Instead of a flow that looks like this:
>
> Client sends RDAP "tokens" query to RDAP server
> RDAP server redirects client to OpenID Provider for identification and
> authentication
> OpenID Provider does its thing
> OpenID Provider redirects client back to RDAP server with identification
> and authentication result
> RDAP server displays result (including token info if successful) to client
> Client sends other RDAP queries to server with ID and token info to
> authorize each query
> Client refreshes or revokes tokens to continue to end token validity
>
> We could do something that looks like this:
>
> Client sends RDAP "login" query to RDAP server
> RDAP server redirects client to OpenID Provider for identification and
> authentication
> OpenID Provider does its thing
> OpenID Provider redirects client back to RDAP server with identification
> and authentication result
> RDAP server displays result (storing token info in the session) to client
> Client sends other RDAP queries to server, server accesses stored info to
> confirm authorization
> Client sends RDAP "logout" query to end a session
>
> This seems easier to me, and it looks more like what people are used to
> when working with a web service. The login function could return an
> indication of success or failure, and the set of claims (end-user
> identification information) that will be used for subsequent commands that
> require identification, authentication, and authorization. The logout
> command can return an indication of success or failure.
>
> What do you think?
>
> Scott
>
> ___
> 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