[regext] Re: ccTLDs using EPP

[Thomas Corte (TANGO support)]

Hello Tobias,

On 22.08.24 08:37, 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 


You can add "EPP" to the row for .ad (Andorra), they switched to EPP in May 
2024.
I added a respective comment to the sheet.

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
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: ccTLDs using EPP

[Thomas Corte (TANGO support)]

Hello,

On 22.08.24 08:37, 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 


Given that e.g. .pl and .cz are on this list, it should be pointed out that the list is based on a 
very lax interpretation of "using EPP". Among other things, these two registries (these are just 
examples I'm aware of, I'm sure there are other offenders) are using heavily modified versions of 
the EPP XML schema files, with a custom target namespace, so that's not really EPP at all; 
registrars thinking they can just use their off-the-shelf EPP client to connect to them are in for a 
rude awakening.


So "using EPP" here really means something like "XML-based provisioning protocol, roughly resembling 
EPP".


Best regards,

Thomas

--
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Does section 3.7 of RFC 8748 forbid standard fees for non-standard (aka premium) domains?

[Thomas Corte (TANGO support)]

Hello Ryan,

On 20.06.24 00:59, Ryan Jaeb wrote:


Hi,

The end of section 3.7 says:

"
Servers that make use of this element MUST use a  element
with the value "standard" for all objects that are subject to the
standard or default fee.
"

Does that forbid a response to a "check' command where
fee:class=standard alongside a fee:fee that is equal to the standard
fee for the TLD?  For example, if the standard renewal fee for a
domain is $22 USD, is a "check" command allowed to respond with
something like:



   USD
   
  example.com
  premium
  ...
  
 1
 22.00
  
   



I have a domain where the "fee:class" has been changed from "standard"
to "premium" and I'm trying to understand what impact that has on me
and if it violates any applicable standards.  Any input would be
greatly appreciated.


In our own implementation of fee-1.0 (for TANGO), we interpreted the  element as being 
the overall premium tier for the domain name, which may affect the fees for *some* operations (like 
create) but not others (like renew). Hence, it possible in our system to receive responses like


  
 
USD

   example.tld
   premium-1000
   
  1
  grace-period="P5D" refundable="true">1000

   
   
  1
  refundable="true">9

   

 
  

Where the class for the domain "example.tld" is "premium-1000" because its creation price is 
"premium" (1000 USD) while the renewal price is standard (9 USD). Registrars can still use the 
different "standard" boolean attributes in the  response elements to determine the 
individual "premium situation" for each command.


It doesn't seem right to return a different  for the same domain depending on the command for 
which fees are inquired.


Best regards,

Thomas Corte

--
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
To unsubscribe send an email to regext-le...@ietf.org

Re: [regext] New Version Notification for draft-regext-brown-epp-related-objects-00.txt

[Thomas Corte (TANGO support)]

Hello,

On 13.04.23 15:28, Gavin Brown wrote:


Yes, that's the point. It's not atypical for a registrar to have to
perform 6 or more  commands in order to retrieve all the
relevant information about a domain name
(registrant/admin/tech/billing contact objects, 2 or more
nameservers). This extension allows all that information to be
retrieved in a single command/response transaction. Obviously this is
less of an issue for a thin registry.

I may be barking up the wrong tree here, so would appreciate feedback
from registrars as to whether this extension would be helpful (if
sufficiently deployed by registries).


TBH, it's very unlikely that we would implement this extension in our
registrar software.

The major reason is that our code is written to work as generic as
possible, i.e. the goal is to use the generalized code base for as
many EPP registries as possible, and only implement registry-specific
exceptions where absolutely necessary.

This means that, if there is a way to achieve a goal with "generic"
means (like, in this case, simply inquiring the objects separately),
we would not use an extension for it, especially if that extension
is only going to be available for a handful of registries.

Another reason is that our systems all carry copies of all
domain/contact/host data of our sponsored objects in the local
database, meaning that the inquiry of all data (as facilitated by
this extension) is usually not necessary.
For non-sponsored objects, querying of such data does become
necessary here and there, but there are usually strong restrictions
involved (due to GDPR etc.), which again favors an individual inquiry.

I'd assume that most registrars would take the same position,
but I'm curious to hear other opinions.

Best regards,

Thomas Corte


--
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

Re: [regext] [EPP] Several commands under the same

[Thomas Corte (TANGO support)]

Hello,

On 10/20/22 12:06, Stephane Bortzmeyer wrote:


...
and that "it works with all the other registries".


I'd be curious to know which registries are actually supporting this, and 
how they deal with issues such as


* what response to generate if the various commands demand different 
responses (e.g., when an  is sent along with a  or a )


* what response to generate in case of partial success (e.g. if the 
 succeeds but the  does not)


* how to decide which of the commands the  elements below them 
should apply to


Best regards,

Thomas

--
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [EPP] Several commands under the same

[Thomas Corte (TANGO support)]

Hello,

On 10/20/22 12:06, Stephane Bortzmeyer wrote:


We got a message from a registrar saying that having several commands
under an  element is legal:


   
 
...
 
 
...

and that "it works with all the other registries".

XML schema is difficult to read but RFC 5730, section 2.5 uses the
singular to talk about the command. So, my opinoion is that the
registrar is wrong. Advices?


The sequence in "commandType" contains

 
   
   
   
   
   
   
   
   
   
   
 

As minOccurs and maxOccurs on  both default to 1, exactly one of 
these elements must occur. So the wording is backed by the formal syntax.


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

Re: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-01.txt

[Thomas Corte (TANGO support)]

Hello Gavin,

On 9/14/22 13:35, Gavin Brown wrote:


Greetings all,

Many years ago CentralNic had a proprietary EPP extension for managing
 the TTL values of domain names. ...

However I've had a bit of feedback about the draft since then, so I've
 just published a new version and am now sharing it with the WG for
feedback.


I have two comments:

1) The specification should probably address the effect of the TTLs on 
IDN variants. If a registry supports IDN variants as attributes of a 
domain name (either automatically added or via an extension), they will 
usually add some DNS records dedicated to these variants to the TLD zone, 
so the spec should specify that the same TTL is applied to these 
dedicated records as well. If IDN variants are managed as their own 
objects, they can receive their own specific TTL values.


2) I'd suggest to add this boilerplate text (or something similar) to the 
draft:


  "EPP uses XML namespaces to provide an extensible object management
   framework and to identify schemas required for XML instance parsing
   and validation.  These namespaces and schema definitions are used to
   identify both the base protocol schema and the schemas for managed
   objects.  The XML namespace prefixes used in examples (such as the
   string "ttl" in "xmlns:ttl") are solely for illustrative purposes.  A
   conforming implementation MUST NOT require the use of these or any
   other specific namespace prefixes."

This is a pet peeve of mine, as some registries still haven't managed to 
implement this correctly.



In our implementation, glue records are only published if the
superordinate domain is delegated to them, and the current
specification assumes the same design choice. However this is
obviously not true for other registries, so being able to change the
TTL on a host object independently of the superordinate domain may be
needed to account for scenarios where the client wishes to change the
TTL of all NS records *except* those of the superordinate domain.
However I am not sure if this is a scenario that justifies the
additional complexity entailed - but I'd appreciate the list's input
on that point.


Our own TANGO system's zone generation also suppresses glue records if 
they're unnecessary, so I'd agree that the extra complexity shouldn't be 
required.


Best regards,

Thomas

--
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Comments to the feedback about epp-over-http

[Thomas Corte (TANGO support)]

Hello Scott,

On 3/31/22 19:58, Hollenbeck, Scott wrote:


[SAH] Client certificates ARE required for TCP transport with TLS. See here:

https://datatracker.ietf.org/doc/html/rfc5734#section-9

They're not specifically a requirement for EPP, but they are for that 
particular transport protocol (which just happens to be the only standard 
transport protocol).


Interesting, it seems that we overlooked that in our own (TANGO) 
implementation. There, we're currently allowing clients to connect 
without presenting a client certificate, but they *may* send one (which 
isn't checked beyond the CA's trustworthiness).


The thing is that many registries' client certificate checks end with 
doing just that, i.e. clients may present ANY certificate, as long as 
it's not expired and issued by a CA trusted by the registry's server. In 
particular, the common name is usually *not* checked, as no properties of 
the client certificates are "negotiated out of band", as RFC 5734 suggests.
To us, this common practice seemed silly, as anybody can easily get a 
trusted certificate like that, but all that does is adding costs and 
effort for the client, while not adding any security. This is why we made 
the client certificate optional, but as it's obviously an RFC violation, 
we'll need to change that.


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

Re: [regext] Comments to the feedback about epp-over-http

[Thomas Corte (TANGO support)]

Hello Mario,

On 3/31/22 17:36, Mario Loffredo wrote:

Starting an HTTP session when receiving an EPP command other than the 
Login command is in .it experience (but I can speak on behalf of .pl too) 
very inefficient because you can't immediately lock the HTTP session to 
the Registrar.


Ok, but plain TCP implementations have the same problem. Unless the 
registry requires that no two registrars have the same IP address 
whitelisted, the server always has to wait for the  until it knows 
which registrar has connected. That is, unless client certificates are 
also in play, as suggested by Patrick, but that's not a requirement in 
EPP, even if many registries are now requiring them.


In addition, while TCP client needs to establish a connection before 
sending the EPP Login command since the transport protocol is 
connection-oriented, an HTTP client doesn't need to do because the 
protocol is not connection-oriented (even if it uses connections). So why 
should an HTTP client be required to send a useless HTTP request? Just to 
operate in the same way of EPP over TCP? It's a nonsense.


With regard to the compliance with RFC5730, the only difference with the 
proposed approach is that a client MAY send an Hello via POST before 
sending a Login. Anyway, the EPP session starts after a successful Login 
as defined in RFC5730 itself.


Obtaining the  (which, in case of connection-less operation, is 
actually supposed to be triggered by the client's ) before  
isn't useless – the greeting contains information like object/extension 
URIs that can be used by the client to select a proper supported 
object/extension implementation before sending the  (in which that 
support is declared). So, for HTTP, it makes sense to require the 
client's  so that the server's  can be sent as the 
response to a proper initial request (rather than, say, an awkward empty 
POST, or a GET request).


In fact, it memory serves, ITNIC's *current* EPP-over-HTTP implementation 
*requires* a  as the start of any EPP session.


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

Re: [regext] Comments to the feedback about epp-over-http

[Thomas Corte (TANGO support)]

Hello Mario,

On 3/31/22 13:52, Mario Loffredo wrote:


Hi James,

For what I have understood, your implementation is based on the 
assumption that once the HTTP Connection is established, it is used for 
the transit of all the HTTP requests of an EPP session, starting from the 
Login and ending with the Logout.


Consequently, you rely on keeping the HTTP connection alive as long as 
the EPP session works. Correct?


If so, in my opinion, that is a wrong assumption.

Clients should not be forced to keep alive the HTTP connections if HTTP 
allows to maintain HTTP sessions alive across a sequence of HTTP  
connections.

...


I might be wrong (it was hard to follow the entire discussion, mostly due 
to the lack of consistent e-mail quoting in the thread), but I don't 
think there really any disagreement here between James and you.


As James speaks of HTTP Session Cookies in many places, I don't think 
he's suggesting that the connection management should be required to make 
use of any HTTP keepalive features. Instead, I think that you're both 
agreeing that the EPP "session" over HTTP is simply managed by an initial 
cookie given to the client, which he'll need to send along with any 
subsequent request to indicate that it belong to the same session. This 
also means that, unlike with TCP, an EPP session over HTTP can indeed 
survice a server restart, as long as the server can retrieve sessions 
from permanent storage after its restart.


I think the only point of contention here is when exactly the cookie is 
supposed to be returned by the server, namely


a) at the time the very first request without a session cookie is 
received (i.e., when the EPP client sends a ?) OR

b) only after the first  command is received with correct credentials

My preference would be a) as it more closely resembles the TCP transport 
(where the connection itself is established before the first valid ).


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

Re: [regext] Comments to the feedback about epp-over-http

[Thomas Corte (TANGO support)]

Hello Mario,

On 3/29/22 17:07, Mario Loffredo wrote:

That's exactly my main concern about such an idea that was the same 
supporting last proposal about EPP-over-HTTP submitted to this WG.


Making EPP completely stateful appeared,and still apeears, to me 
inefficient and in contrast with the trend in the design of REST services.


EPP *is* stateful by definition (see "Protocol Description" in RFC 5730), 
and that has implications beyond the fact that credentials are only 
presented to the server in the . The  also contains 
"handshake" information that tells the server which object and extension 
URIs the client understands, and that information governs the content of 
server responses during the session (e.g., which version of fee extension 
data is returned in the response to a billable operation).


Consequently, EPP would need to be completely revamped in order to 
facilitate stateless operation. All extensions relying on the  
handshake would need to be rewritten. The use of cookies (a 
well-established method to maintain server state over HTTP) seems like 
the lesser evil here.


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

Re: [regext] Comments to the feedback about epp-over-http

[Thomas Corte (TANGO support)]

Hello,

On 3/25/22 15:58, Mario Loffredo wrote:


Hi folks,

here are in the following some comments grouped by subject to last 
meeting's feedback about EPP-over-HTTP:

...
*2)  Cookies*

Jim (Reed) asked why cookies should be used in this case.
...
Which method other than session cookie shoud be used instead ?


In terms of EPP-over-HTTP implementations in the wild, RED.ES's abysmal 
implementation for .es comes to mind, which uses a proprietary EPP 
extension for the submission of the EPP client's credentials along with 
each and every command. But such a move away from a stateful EPP session 
is surely not desirable, leaving cookies (or some other way to maintain 
state over multiple HTTP requests) as the only sensible choice.


Best regards,

Thomas Corte

--
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

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04

[Thomas Corte (TANGO support)]

Hello,

On 12/20/21 14:55, Antoin Verschuren wrote:


Dear WG,

This WGLC will end tonight, and so far we only have 2 explicit voices of 
support.
This is a bit low to declare consensus. Could more people voice their 
support?


+1

--
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Extension Object Search

[Thomas Corte (TANGO support)]

Hello,

On 12/14/21 19:17, Patrick Mevzek wrote:


Also the exact same EPP security mechanisms (as laid out by RFC5734), namely
1) IP access lists 2) clients X509 certificates 3) login+password, can be done 
exactly
as is with RDAP, if so wished.

EPP is Extensible *Provisioning* Protocol (yes, I know not fully true already).
I am into the personal position that a lot of stuff added lately/being added to 
EPP would in fact have been better through RDAP, because it also for some opens 
the use by other
entities than registrars.


All of this is correct; however, for registrars seeking to keep their 
inventory up-to-date with such a feature, it seems rather awkward having 
to implement *two* instead of one real-time connection to the registry.


Right now, registrars have little to no reason to include an RDAP client 
implementation in their software at all, as everything they need to do in 
terms of domain/contact/host inventory management can/must be done via 
EPP, and EPP provides more information about sponsored objects than RDAP 
anyway.


As such, IF e.g. a "list my domains" feature shall be made available in a 
real-time interface, IMHO it would make more sense to add it to EPP, as 
registrars can then handle all of their business with the registry over 
their existing EPP connection, rather than having to add one for RDAP.
Given that maintaining a registry connection involves more and more 
effort these days (thanks to short-lived client certificates, frequent 
registry migrations etc.), adding yet another one to maintain should 
better be avoided.


Best regards,

Thomas

--
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Extension Object Search

[Thomas Corte (TANGO support)]

Hello,

On 12/14/21 15:29, Tobias Sattler wrote:


Dear Working Group,

Jody and I wrote a draft on EPP Extension called Object Search.

We want to spin this idea with this group because using EPP for searching 
is more secure than RDAP by reducing a threat vector.


https://github.com/seitsu/epp-object-search/blob/main/draft-sattler-epp-object-search.txt 



Please note that this is an early draft that is not submitted yet. 
Therefore, the approach used in this document is only to illustrate the 
idea, not necessarily the final approach.


We are looking forward to hearing your feedback.


As a (registrar) EPP client developer, I'd surely actually welcome a way 
to obtain ad-hoc lists of sponsored objects via EPP (rather than having 
to rely on out-of-band reports, which aren't really standardized yet, see 
below).



However, as a (registry) EPP server developer, I'm wary of the extra 
stress that could be caused by excessive list queries (with search 
filters) hitting the main SRS database, especially if registrars took the 
availability of this feature as an incentive to neglect their local 
inventory management.


This is one of the reasons why our own TANGO registry system is using a 
dedicated reporting server that offers daily inventory reports, 
pre-generated from a local, partial copy of the registry's data.



The registration reporting draft at

https://datatracker.ietf.org/doc/draft-ietf-regext-simple-registration-reporting/

seems to be aiming at standardizing such registry reports, which at this 
point seems to be the preferable option to get inventory information IMHO 
- registrars could use them to easily get full inventory data, allowing 
them to filter them offline in any way they see fit (compared to the 
simple filtering options the object search branch offers right now). 
Also, the standardized reports are supposed to also include data about 
transactions, RGP, reserved names, premium names etc.; the EPP object 
search would really only offer a small subset of this data.


By the way, the text and examples don't seem to be aligned with the XSD 
in the draft; for example, "type" and "filter" are defined as XML 
elements, while they occur as XML attributes in the examples.


Best regards,

Thomas

--
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [check] always prohibited when avail="1" ?

[Thomas Corte (TANGO support)]

Hello,

On 9/29/21 13:01, Stephane Bortzmeyer wrote:

> RFC 5731 3.1.1 seems to clearly prevent a  to be sent when
> avail="1".
> 
> But RFC 9095 6.1.1 has an example with a  for avail="1".
> 
> So, is it really forbidden to send a  to the client when the
> domain is available but you want to send some extra conditions?

Technically, it seems to me that the check response in RFC 9095 violates
RFC 5731 anyway, because it asks for returning check results in the check
response for domain names which were not present in the check command,
while RFC 5731 clearly requires the check response to contain "A
 element that contains the fully qualified name of the
queried domain object."

Semantically, including a reason for a domain name's availability feels
pointless, and the authors of RFC 5731 seemingly thought so, too.
Most EPP clients won't expect a reason to be present for avail=1 and will
simply ignore it.

To me, using the  element to add *conditions* that must be met
for the name to be available feels like a misuse of that element.

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

Re: [regext] pass on the lower fee

[Thomas Corte (TANGO support)]

Hello,

On 8/18/21 14:57, Gould, James wrote:

> Martin,
> 
> If you do return the extension in a poll response it should be included in 
> the greeting services.  My recommendation is to fully implement the registry 
> fee extension along with this so not to cause client confusion.

Agreed, adding it to the greeting and then only implement it where it
isn't really expected (as per this version of the RFC) sounds like bad
practice.
Though I wonder which price the implementation of  would even
return for the "renew" command if its price is dependent on a property of
the domain (signed/unsigned) that isn't known at the time of the check...

I'm usually not a fan of proprietary extensions, but this sounds like a
case where it seems prudent to introduce one.

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

Re: [regext] pass on the lower fee

[Thomas Corte (TANGO support)]

Hello,

On 8/17/21 16:30, Mario Loffredo wrote:

> Hi Martin,
> 
> at .it we renew every domain automatically but the fee is always the same.
> 
> However, if I understood well, it seems to me that a possible solution
> might be a combination of the extensions defined in the two RFCs.
> 
> After all, RFC5730 allows to include more elements in the extension
> section of an EPP response.

I'd agree that a combination of the changePoll and fee response
extensions could be used here, but there are minor problems (see below).

> You can use a poll message including as extensions the
> changePoll:changeData element, to convey that the operation child is
> "autoRenew", plus the fee:renew element, to convey the applied fee.

In RFC 8748,  is defined for commands, while  is
defined for (transform) responses, so  seems more appropriate.

One problem here is that the poll response in this case isn't strictly
the response to any (client) transform command.

Actually, RFC 8748 explicitly states

  "This extension does not add any elements to the EPP  or 
   commands or responses."

which indicates that this use case (delivering fees for unsolicited,
server-initiated actions in poll messages) isn't really covered by the
EPP fee extension yet, even if including them in poll responses is
syntactically allowed as far as the XSD is concerned. However, registrars
supporting the fee extension are unlikely to expect fee information in
this place.

But I think support for this use case should be added to a revised
version of RFC 8748.

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

Re: [regext] [Ext] Re: I-D Action: draft-ietf-regext-epp-eai-02.txt

[Thomas Corte (TANGO support)]

Hello,

On 8/10/21 02:34, Gustavo Lozano wrote:

> I have a comment regarding the following scenario:
> 
> The EAI supporting server MUST satisfy the following obligations when the
> client does not support the EAI extension:
> 
> [...]
> 
> When the email property is optional in the EPP response, the server MUST
> validate whether the email property is an EAI address and if so don't
> return the email property in the response and otherwise return the email
> property that has been set based on server policy.
> 
> I think that omitting the email property for this case is overloading the
> meaning of an optional field. How does a client know if the email
> property was omitted because there is no data or an EAI?. A client may
> implement different actions for each semantic (i.e., no data or EAI).
> 
> I think that the action for this case (EAI persisted for an optional
> field) should be as in the case where the email property is required, in
> other words, to return the error code 2308.
> 
> Thoughts?

I agree, simply omitting an optional e-mail field if the client didn't
signal EAI support creates uncertainty that must be avoided, so the 2308
error we discussed for mandatory e-mail fields should be used here, too.

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

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

[Thomas Corte (TANGO support)]

Hello,

On 8/2/21 20:08, Gould, James wrote:

> Thomas,
> 
> For use case #2 (info response of EAI address with non-EAI supporting
> client), your preference is to return a failure.  Is 2308 “data
> management policy violation” the best error code in your opinion?

While not ideal, it seems to be the most suitable one among the codes in
RFC 5730, yes. Semantically, 2305 "Object association prohibits
operation" seems even better, but it's clearly supposed to be used for
responses to transform commands only.

> For use case #1, what is your proposal for the value that the sponsoring
> registrar should provide with the create command to a non-EAI supporting
> server?  I see the following options:
> 
>  1. ASCII placeholder value – The current proposal is the use of
> e...@empty.as112.arpa .  The assumption
> is that using a placeholder value is not the preferred option based
> on your feedback on use case 2.
>  2. Collect ASCII value from registrant – This is counter to the goal of
> supporting EAI, so it would only be done to pass a compliant value to
> a non-EAI supporting server.
>  3. Use proxy ASCII value – The EAI registrar would need to be able to
> support EAI registrants and mix for EAI-supporting registries by
> providing a ASCII proxy value to a non-EAI-supporting registry.  The
> proxy value to use would be up to registrar policy. 
>  4. A mix of the above options.

2. and 3. would be my preferred options.

2. seems OK as it's not unusual for registrars to collect different data
for different registries to represent the same contact due to the varying
data requirements, e.g. for widely differing authinfo string rules.


Also, while I understand the hesitation, I'm inclined to agree with other
participants in this discussion in that, going forward, a new
"contact-2.0" schema version for EPP contacts may be the best option here.
While we're at it, we could also use the opportunity to eliminate some of
the confusion that arose from unclear update semantics for address data,
or to make the contact authinfo optional (as many registries don't
support it anyway), among other things.

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

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

[Thomas Corte (TANGO support)]

Hello,

On 8/2/21 15:50, Gould, James wrote:

>  2. EPP Contact  Response
> (https://datatracker.ietf.org/doc/html/rfc5733#section-3.1.2
> ) - The
>  element is required, which poses an issue when the
> registry supports EAI and the querying registrar does not support
> EAI.  The querying registrar could be any registrar and not just the
> sponsoring registrar, where there is only a single email value in the
> registry that is an EAI address for this use case.  What should the
> registry return to the non-EAI supporting registrar?  This case is
> even more challenging then case #1 since registry has a single value
> and there can be a mix of EAI supporting querying registrars.  One
> alternative is to return an error response (e.g., 2308 “data
> management policy violation”) instead of a successful response with a
> predefined placeholder value,  but that seems harsh to me.

It does seem harsh, but it's (in my opinion) the better option than to
return a syntactically valid placeholder value for the e-mail, as that
placeholder value will - for registrars not supporting EAI - most likely
end up being used as the "real" e-mail address for the contact, causing
problems down the line, for example when the registrar tries to send
verification e-mails to the contact for ICANN WAP compliance. These mails
will bounce, which very often goes unnoticed, and domains may be
suspended as a result. In this scenario, it's better to "fail fast", i.e.
let the inquiry of the contact's data fail with the 2308 error, which
will immediately point the registrar to a systemic problem that needs to
be addressed.

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

Re: [regext] 2nd WG LAST CALL: draft-ietf-regext-epp-registry-maintenance

[Thomas Corte (TANGO support)]

Hello,

On 3/29/21 14:49, Antoin Verschuren wrote:

> 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!

I reviewed the document and have one comment/question in addition to what
Michael mentioned in his previous e-mail:

Section 4.1.4.  EPP  Command, says:

  "For the Registry Maintenance Notification, there are three types of
   poll messages, defined by the  element in Section
   3.3. A poll message applies when a maintenance is created, updated,
   or deleted."

This may be an intentional omission, but in my opinion this should read
"five types of poll messages", and the message type list should include
the "courtesy" and "end" message types, as it doesn't make sense to
define courtesy and end messages while not including them in poll messages.

Otherwise the document seems fine to me, and I support its publication.

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

Re: [regext] Contact Postal Info Elements Proposal

[Thomas Corte (TANGO support)]

Hello,

On 3/31/17 17:24, Gould, James wrote:

> ...
> 
> Thanks for the response.  My feedback is embedded below.  I’ve updated
> the proposal based on your feedback:
> 
> 1.  The  sub-elements do have replace semantics 
> 
> a.    Existing sub-element data deleted first and then set with
> updated data.
> 
> b.    This includes the , ,
> , , , and the
>  elements.
> 
> c.    Servers with special policies regarding contact data
> modifications should check the new data for any actual changes in
> relevant fields.
> 
> 2.  The typed  elements (“int” or “loc”) are
> treated independently
> 
> a.    Exclusion of a  type (“int” or “loc”)
> does not implicitly delete it
> 
> 3.  The typed  element (“int” or “loc”) is
> deleted explicitly via an empty element
> 
> a.     or  type=”loc”/>
> 
> b.    The same applies to deleting the voice or the fax via an
> empty element ( or )

Sorry to pick up this discussion from three years ago, but I was
wondering: has this language ever made it into an "official" IETF
publication? It's not in RFC 5733, and there's no successor for RFC 5733
either. Currently, the only way to find this online is via this mailing
list's archive.

I'm asking because, as a registrar, we're still seeing lots of different
contact update implementations in the wild, and even larger registries
seem to be struggling with getting this right.

Best regards,

Thomas Corte

-- 
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

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

[Thomas Corte (TANGO support)]

Hello,

On 10/11/20 13:39, Dmitry Belyavsky wrote:

> Dear colleagues,
> 
> Here is the updated version of the draft describing the usage of the
> Internationalized Email Addresses (EAI) in the EPP protocol.
> This version provides a specification to submit EAI to the registries via
> the EPP protocol extension.
> 
> Any feedback is welcomed!

As James already pointed out, I'm not sure why the extension is even
necessary to accomplish this on a purely technical (protocol) level.

eppcom:minTokenType is based on xsd:token, which is based on
xsd:normalizedString and adds whitespace collapsing. Unless that
introduces a problem I'm not a aware of, none of this prevents the
specification of internationalized e-mail addresses for contacts in EPP;
in particular, it doesn't limit the available characters to ASCII.

Many registries (like e.g. Neustar for .biz, or the TLDs run by our own
TANGO system) already accept them right now. It would be silly to require
them to use an extension to do the same in the future.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

[Thomas Corte (TANGO support)]

Hello,

On 10/7/20 03:17, Tom Harrison wrote:

>>> The question is whether the RDAP protocol should provide guidance with
>>> how to handle overlapping non-unique handles.
>>
>> I don't think it should. A Jasdip pointed out, the definition of a
>> handle notes that they're supposed to be registry-unique.
> 
> I agree with Scott and Jasdip on this point.

I think it's problematic to have a standard like this (which will
eventually have to be implemented by all ICANN-regulated registries)
impose such a requirement (unique handles across all object types) out of
the blue when there are already hundreds of databases out there that were
not build with this assumption in mind.

Sure, a migration of non-unique handles is possible, and we did that when
ICANN demanded a specific ROID prefix per TLD, but that was a minor
change as the ROID isn't really used for operationally addressing
anything. Renaming contact IDs and/or registrar IDs would have more of an
impact, as it would also require all registrars to update their own
databases/configurations as well to reflect the new handles.

If "using a  precedence order" means that a server can choose to
e.h. just deliver the contact when there's a registrar with the same
handle, that's an acceptably lenient interpretation. Otherwise, no
assumption about the uniqueness of entity handles should be made long
after the fact.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Thomas Corte (TANGO support)]

Hello,

On 7/14/20 17:21, Patrick Mevzek wrote:

> It is a classical chicken and egg problem based on the fact that registries, 
> once they got one version working have no or very little incentive to change 
> (being similar as other registries is not a strong force for them) and for 
> registrars as long as not all registries do the same thing they have anyway 
> to code for the extra case and then once they done it for one registry they 
> could as well use that for others. So for registries they have only one case 
> to handle, where registrars have many but for registries each registrar is 
> like any other, besides its market position eventually.
> 
> However, for a non trivial number of players in this game they are bound by 
> contracts that
> can basically force them to implement new standards after some given delay.
> But that wouldn't apply for ccTLDs where each registry is king in its kingdom.

True, and even for gTLDs, there is no real pressure here since ICANN
doesn't seem to be particularly aware of the EPP fee extension (or care
about interoperability with regard to domain price tiers for that
matter). But that may (and should) change, of course.
> Besides market pressure, that has its limits here, I see only contractual 
> forces able to move things around.

It could go a long way if some of the larger registries (Verisign,
Afilias, Neustar, CentralNic, Donuts) would care to implement the RFC
version *and* start to phase out the older versions with clear deadlines.

As long as they keep supporting ancient versions of the extension (or, in
the case of Donuts, use their own proprietary one), the larger registrars
will see no incentive to implement newer versions, and will in turn
pressure smaller registries into adding support for these ancient
versions (e.g. by threatening to otherwise not include their premium
domains in their portfolios).

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
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?

[Thomas Corte (TANGO support)]

Hello James,

On 7/14/20 14:01, Gould, James wrote:

> Thomas,
> 
> The versions of the fee extension that you reference have similar language 
> associated with returning avail="0" for premium domains:
> 
> 1. fee-0.23 - 
> https://tools.ietf.org/html/draft-ietf-regext-epp-fees-08#section-4
> 2. fee-0.21 - 
> https://tools.ietf.org/html/draft-ietf-regext-epp-fees-05#section-4
>  
> In both cases it reads:
> 
>The server MUST return avail="0" in its response to a  command
>for any domain name in the  command that does not include the
> extension for which the server would likewise fail a
>domain  command when no  extension is provided for that
>same domain name.

Ok, thanks for pointing this out - looks as if we missed this addition
when we upgraded our system from the older versions we had supported
previously.

> The very old fee-0.8 version specifies in 
> https://tools.ietf.org/html/draft-brown-epp-fees-05#section-4 "Servers MUST 
> provide clear documentation to clients about the circumstances in which this 
> extension must be used.", which provides flexibility for the server to 
> normalize the behavior as defined in draft-ietf-regext-epp-fees-05, 
> draft-ietf-regext-epp-fees-08, and RFC 8748.  

Sure, it provides flexibility, but a registry must still be wary about
the implications of any change in server behavior, even if the previous
behavior resulted from a wrong implementation. We'll need to take this
into consideration when altering the check results of our system where
legacy versions of the extension are used. Our fee-1.0 implementation
will for sure adhere to the language in the RFC.

By the way, you're right that fee-0.8 is very old, however you'd be
surprised that, for many registries, it is still the latest version they
will support, with some only supporting even *older* versions (like
fee-0.5 in the case of CentralNic).
This has led to the unpleasant situation that some bigger registrars who
want to avoid the effort of implementing newer versions even put pressure
on registries to introduce support for these older versions, as they
regard them as the established "de-facto" standard.

Based on this experience, I'm afraid it will take a long time until
fee-1.0 will be widely adopted by registries or registrars, if ever.

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

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

[Thomas Corte (TANGO support)]

James,

On 7/13/20 21:46, Gould, James wrote:

> Thomas, 
> 
> Signaling support for fee-1.0 in the login services is not material for this 
> use case.  The key element is whether the create of the premium domain name 
> will fail if the client does not know the correct fee and the fee extension 
> is required to be passed on create.  I don't see a code breakage scenario 
> here, but I don't know what mix of extensions you're dealing with.  

So, case in point: once we roll out support for fee-1.0, TANGO will also
keep supporting the older fee extension versions fee-0.8, fee-0.21 and
fee-0.23 (the RFC recommends to allow older versions to facilitate
migration to new versions).

Now, none of these old versions had the requirement to report "domain not
available" if no fee extension is included in a premium domain check.

So, registrars currently using fee-0.21 for example will expect
availability checks to truthfully report avail=1 for premium domains in
such a scenario. Just the fact that the registry system was updated to
also support fee-1.0 should not change the system's behavior from their
point of view, should it? Otherwise, they would be forced to change their
 clients to include the fee extension to get the previous
availability results - to accommodate a change caused by a fee extension
version they don't even use.

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

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

[Thomas Corte (TANGO support)]

Hello,

On 6/26/20 16:18, Gould, James wrote:

> The goal is to cover the case of a client not passing the fee extension at 
> all, with the assumption that the fee extension would reference the create 
> command.  It's simpler to make the case based on the existence or 
> non-existence of the fee extension in the check command, but there may be 
> cases were the renew fee matches the create fee.  It's up to the server to 
> determine whether a particular domain will fail on create without the client 
> having the correct non-standard fee.  I realize that there are corner cases 
> where the client may know the fee, based on assuming that the create fee 
> matches the renew fee, or the fees are provided out-of-band to EPP, 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.
> 
> The server MUST return avail="0" in its response to a  command
> for any object in the  command that does not include the
>  extension for which the server would likewise fail a
> domain  command when no  extension is provided for that
> same object. 

Another clarifying question: the above only needs to happen if the client
at least signaled its general understanding of the fee-1.0 extension in
the EPP  command, correct?

Otherwise (i.e., if the server needs to report premiums as unavailable
even to clients who are not aware of fee-1.0), this RFC would be asking
for a change in a server's behavior just by virtue of introducing support
for fee-1.0, which would mean that clients not using any fee extension
(or an older version which didn't yet have this requirement) would see an
unexpected code-breaking change, no?

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
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?

[Thomas Corte (TANGO support)]

Hello Jothan,

On 6/26/20 17:15, Jothan Frakes wrote:

> @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,   

Sure, the subsequent domain create attempt would still fail if the wrong
command was sent in the extension, even if the availability check was
"tricked" into confirming availability.

> 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. 

Agreed, it's more work to get this wrong than right. We'll go with the
John's lax interpretation in our implementation and will report avail="1"
for premium names as long as the check command contains *any* fee
extension whatsoever.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
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?

[Thomas Corte (TANGO support)]

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

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

[Thomas Corte (TANGO support)]

Hello James,

thanks for your reply, I'll go back to check out the respective thread.

On 6/25/20 21:40, Gould, James wrote:

> JG - The RFC only specifies that the fee extension needs to be provided to 
> support the create command, so checking the renewal fee is not applicable.   

So, just to be sure, to the following check for a *renew* fee of a
premium domain, the server should respond with avail="0" (as the check
merely asks for a renewal price, not a creation price)?

http://www.w3.org/2001/XMLSchema-instance";>
  

  
premium-a1.tango
  


  

  1

  

e1f8b4cd61f84469436bf16585f976b3
  


While the following check asking for a creation price should be responded
with avail="1"?

http://www.w3.org/2001/XMLSchema-instance";>
  

  
premium-a1.tango
  


  

  1

  

e1f8b4cd61f84469436bf16585f976b3
  


Just trying to clarify this, as the RFC isn't all that clear about which
exact conditions the fee check extension must meet in order to qualify
for a positive availability check of free premium domains.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Thomas Corte (TANGO support)]

Hello,

we're currently working on implementing RFC 8748 (EPP Registry Fee
Extension) in our registry system, and I just stumbled upon this
paragraph in section 4 (Server Handling of Fee Information):

   "The server MUST return avail="0" in its response to a  command
   for any object in the  command that does not include the
extension where the server would fail a domain 
   command when no  extension is provided for that same object."

If my interpretation of this is correct, this means that the server is
supposed to reply avail="0" in a  response for all
available domains which do not have a standard price, i.e. which require
the acceptance of special fees via the fee extension on ,
unless the client supplies (any?) fee extension in with the
 command.

I admit that I missed this part even in older versions of the draft, so I
may be late to the party.
Anyhow, I wonder:

* Is it a good idea to simply claim that a name is not available,
  even though it actually *is* available (if the client is ready to pay
  the special price)?

* Which kind of fee check extension is sufficient to report the name
  as "available"? What if the registrar merely checks for a renewal
  price, but not for a create price?
  Should he still get avail="1", even though he may still be oblivious to
  the higher registration price?

I understand that this is maybe another attempt to protect registrars
from offering / registering premium names inadvertently, but is it the
right way to do this?

Fee-unaware registrars may lose business by reporting names as taken,
even though they may be able to register them manually for their
customers (without EPP) after determining the price out-of-band.
And requiring the fee extension in the transform commands for
non-standard prices should be protection enough against inadvertent
premium registrations.

Also, it seems somewhat questionable to affect the outcome of the plain
availability check depending on the presence of the fee extension.

Thoughts?

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP and rate-limiting

[Thomas Corte (TANGO support)]

Hello,

On 1/17/20 15:49, bortzme...@nic.fr wrote:

> On Fri, Jan 17, 2020 at 02:43:02PM +,
>  Hollenbeck, Scott  wrote 
>  a message of 21 lines which said:
> 
>> Perhaps 2002 ("Command use error")?
> 
> May be but the text in RFC 5730 limits it to "the command cannot
> be executed due to a sequencing or context error".

Admittedly, looking at this, our 2502 doesn't seem to be overly suitable
either:

  2502"Session limit exceeded; server closing connection"

  This response code MUST be returned when a server receives
  a  command and the command cannot be completed
  because the client has exceeded a system-defined limit on
  the number of sessions that the client can establish.  It
  might be possible to establish a session by ending
  existing unused sessions and closing inactive connections.

(as this clearly refers to the number of open registry connections only).

I guess we interpreted "Session limit exceeded" in a liberal fashion, in
the sense that exceeding a rate limit means exceeding a limit *of* this
session, not the limit to the number of sessions.

Anyway, as the goal is to stop the client from further hitting the
server, closing the session (as opposed to let subsequent commands fail,
allowing the load on the server to continue) is IMHO a good way to react,
and in that case this seems to be the most suitable response code.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP and rate-limiting

[Thomas Corte (TANGO support)]

Hello Stephane,

On 1/17/20 15:30, Stephane Bortzmeyer wrote:

> Sometimes, some clients are too talkative and, for instance, try
>  too often to grab a domain. I'm not sure of the best error
> code to return when such behaviour is detected. HTTP has 429 "Too Many
> Requests" (RFC 6585) but I don't find a proper code in EPP. Any idea?

We're using 2502 ("Session limit exceeded; server closing connection") in
similar cases. And we're closing the connection, of course.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] draft-ietf-regext-epp-fees: add feature to inquire balance and credit limit?

[Thomas Corte (TANGO support)]

Hello,

some of our registrars keep asking for a feature to simply inquire their
current account balance and credit limit via EPP.

As far as I can tell, even the latest fee extension draft
("draft-ietf-regext-epp-fees-16") only supports the retrieval of this
information in the response to a *transform* command, but not e.g. in a
check response.

This isn't ideal since the registrar should not be forced to send a
"dummy" sequence of billable commands (e.g., a domain create/delete or
transfer request/cancel sequence) only to get this information.
Also, even if the registrar would store the values from the most recent
"non-dummy" transform response, they could become obsolete quickly due to
intermittent automatic renewals, or account top-up deposits.

What's the opinion in this group regarding the addition of an inquiry
feature, e.g. by adding a flag to the  command fee
extension, which could trigger the inclusion of the balance/limit in the
 fee response extension?

Best regards,

Thomas Corte

-- 
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

Re: [regext] Unhandled namespaces IETF 102 flashback

[Thomas Corte (TANGO support)]

Hello Martin,

On 10/17/18 17:50, Martin Casanova wrote:

> I would like to comment 4 statements(analogous) that were made in this
> session:

Overall, I agree that all four statements are problematic at best
(details inline below).

> 1. To make sure the server remains RFC compliant when sending poll
> messages with extensions it should not accept sessions where the client
> did not specify all server supported extensions. (Server supported
> language: ABC, Client only A and B)
>     - This is a rather strict interpretation.  Of what I heard, some
> registries allow the session anyway

This is what we're doing in our TANGO system. In today's environment with
thousands of TLDs, it's unrealistic to demand that every registrar keeps
track of every single new extension (or version thereof) introduced by a
registry, which they would have to do (just to enable their client to log
in) if the above was implemented.

> but use only extensions of the common
> subset of client login and greeting in their reposes. Other extensions
> are omitted in responses. Commands of other extensions that the server
> does not support are answered with 2307 "Unimplemented object service"
> but for that to happen the session must have been established. Who is
> handling it this way, lets say for the DNSSec extension? 

In an ideal world, this would be the case across the board. TANGO does
that for the supported fee extension (responses won't contain it unless
the registrar specified in in the EPP login), but e.g. never omits DNSSEC
data from  responses, even if the registrar didn't announce
support for it.

> 2. Poll Messages are informational. Nothing important should be sent over
> this channel.
> - I think this could hinder the further development of all poll message
> related extensions. The importance of the whole poll mechanism is
> undermined by saying that the information in poll messages is anyway only
> optional to process and not so "important". Maybe we will have even more
> important stuff to communicate in the future via this channel. (low
> balance etc.)

Transfer-out messages are important; not only do they enable registrars
to maintain a proper inventory, they also allow registrants to react in
time should a domain be transferred away illegitimately. Transfer-in
messages are maybe slightly less important, since a client can always
check for the outcome of a transfer after a timeout, but this kind of
busy waiting isn't exactly state-of-the-art.

Since there is no other way in EPP to get that kind of information, poll
messages are essential and hardly just informational.

> 3. Poll messages could be purged if they were not delivered after a
> certain time.

While this could be seen as a solution for getting rid of unparseable
messages left in the queue by the registrar (blocking the reception of
others), I'm against the concept in general. The queue should always be
emptied at the discretion of the registrar.

> 4. The problem of breaking clients should never occur in production
> because clients can prepare them selfs in OT&E

Again, with thousands of TLDs, it's ridiculous to assume that registrars
can constantly test and re-test their client systems in time for
production updates in all cases. Extensions, especially non-mandatory
ones, should therefore be rolled out in a fashion that ideally doesn't
affect the functionality of legacy clients not seeking the use any of the
new features, even if they don't retest in OT&E.

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