Subject: Re: [regext] DOODLE: select your documents

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 2 Jan 2019 14:55:03 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of James Galvin
> Sent: Friday, December 21, 2018 11:13 AM
> To: Registration Protocols Extensions <[email-masked]>
> Subject: [EXTERNAL] [regext] DOODLE: select your documents
>
> Please take the time to select the documents you support for advancement
> in this working group.
>
> https://doodle.com/poll/6nyguby3yr8dx9cp
>
> Please select from 1-5 documents.

Jim, how do you propose to address submissions that contain more than five "green checkmark" selections?

Scott

---

From: "James Galvin" <[email-masked]>
Date: Wed, 02 Jan 2019 13:48:02 -0500

Thanks Scott, for your question.  I have also gotten a few private 
questions about details of how “selections” will be interpreted and 
acted upon.  Rather than respond to your specific question let me make a 
general statement that I have made privately to a few folks.

Antoin and I are not trying to make this a particularly formal process.  
The IETF generally and certainly this working group specifically are 
guided by consensus.  It is our intention to interpret any results as 
broadly as possible.  We will certainly explain our decision process 
with any announcement of results.  If there are questions or concerns 
then we’ll address them, including the possibility of trying something 
different if this path doesn’t yield a consensus.

Of course, any decision we propose will be subject to approval by the 
working group.

We’re all working together to progress the work that is most 
interesting to the most people.

Hopefully no one will create entries that are problematic, hint hint!  
Note that folks can choose to edit their entry, until the Doodle is 
closed, or even add a second entry with a comment at the moment 
explaining which is preferred.

Of course anonymous entries will be problematic.  Please don’t do 
that.  If you do we’ll probably look at results both with and without 
your entries.  If that creates a problem then we’ll have to ask the 
working group to help us resolve the issue.

To everyone, please be fair and reasonable.  Antoin and I will do our 
best to do the same.

Thanks,

Jim

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 3 Jan 2019 08:25:17 +0000

Jim, 

thanks for posting that - i've made my choices. 

<rant>

Sigh.

As i have voiced in the past, I see greatest value when the IETF standardizes widely used protocols, *OR* important extensions to standards track protocols. Those are the documents that directly or indirectly affect billions of internet internet users, and that's where the IETF should focus their energy on. I do believe the standardization of industry-specific file formats with a very narrow (temporal and spatial) application window, affecting only 1k-2k organizations (and ~10k individual, at most - about 6 magnitudes less!) is an extremely inefficient use of the scarce resources of the IETF, and should pursued somewhere else. Particularly since most of the regext regulars congregate at various other venues anyways.

Slapping an RFC number onto a document just so that an ecstatic crowd can commence their chant "it's an RFC!! An RFC! Arrr Efff Zeee!! You MUST implement!!" doesn't make it a "better" or  "more important" specification. 

I do believe in the value of standardization, but we should carefully select the right venues.

</rant>

Best,
Alex

> -----Ursprüngliche Nachricht-----
> Von: regext <[email-masked]> Im Auftrag von James Galvin
> Gesendet: Freitag, 21. Dezember 2018 17:13
> An: Registration Protocols Extensions <[email-masked]>
> Betreff: [regext] DOODLE: select your documents
> 
> Please take the time to select the documents you support for advancement in
> this working group.
> 
> If you click once in the box a green check mark will appear.  Use this to
> indicate support for a document.  If you click twice in the box a yellow check
> mark in parentheses will appear.  You may use the yellow check mark to
> indicate support that is a lower priority than a green check mark.
> 
> For your convenience I have included the list of documents and their links
> below.
> 
> This selection process will remain open for 3 weeks, until 11 January 2019.
> 
> Enjoy your holiday season!  See you all next year!
> 
> Jim
> 
> 
> DOCUMENTS TO CONSIDER
> 
> Registry Reporting Repository
> https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-
> repo/
> 
> Registry Reporting Structure
> https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-report-
> structure/
> 
> Domain Fee Report
> https://datatracker.ietf.org/doc/draft-sattler-registry-domain-fee-report/
> 
> Registry Transaction Report
> https://datatracker.ietf.org/doc/draft-mcpherson-sattler-ry-transaction-
> report/
> 
> Registry Domain Inventory Report
> https://datatracker.ietf.org/doc/draft-sattler-registry-domain-inventory-
> report/
> 
> Registry Domain Drop Report
> https://datatracker.ietf.org/doc/draft-sattler-registry-domain-drop-report
> 
> Registry Unavailable Domain Report
> https://datatracker.ietf.org/doc/draft-sattler-registry-unavailable-domain-
> report/
> 
> Registry Maintenance Notifications
> https://datatracker.ietf.org/doc/draft-sattler-epp-registry-maintenance/
> 
> Unhandled Namespaces
> https://tools.ietf.org/html/draft-gould-casanova-regext-unhandled-
> namespaces
> 
> Data Set File Format
> https://datatracker.ietf.org/doc/draft-gould-regext-dataset/
> 
> Login Security
> https://datatracker.ietf.org/doc/draft-gould-regext-login-security/
> 
> Federated Authentication for RDAP
> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/
> 
> RDAP Partial Response
> https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-partial-response/
> 
> RDAP Search
> https://datatracker.ietf.org/doc/draft-fregly-regext-rdap-search-regex/
> 
> RDAP Reverse Search
> https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/
> 
> RDAP Sorting and Paging
> https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-
> paging/
> 
> Registry Data Escrow Specification
> https://datatracker.ietf.org/doc/draft-arias-noguchi-registry-data-escrow/
> 
> Domain Name Registration Data (DNRD) Objects Mapping
> https://datatracker.ietf.org/doc/draft-arias-noguchi-dnrd-objects-mapping/
> 
> Third Party DNS Operator to Registrar/Registry
> https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-
> protocol/
> 
> Validate
> https://datatracker.ietf.org/doc/draft-ietf-regext-validate/
> 
> Verification Code
> https://datatracker.ietf.org/doc/draft-ietf-regext-verificationcode/
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Tobias Sattler <[email-masked]>
Date: Thu, 3 Jan 2019 10:02:40 +0100

Hi Alex,

Thank you very much for your email.

I do understand your point. The original idea behind RFCs is, of course, for the benefit of the Internet community. What you can question about certain available drafts - and I'm not just referring to my own.

However, nowadays most domain registries have withdrawn to the point of implementing only their own ideas or approved RFCs. This inevitably leads to the situation that proposals for improvement - whoever they come from - either have to be solved via approved RFCs, in lengthy bilateral talks / negotiations or through policy development.

The goal of the ICANN CPH TechOps Group was and is to address technical and operational challenges and as there seems to be no other way we decided to go for the standardized way. If the REGEXT Group thinks that an individual submission with the status informational is sufficient and this is fully supported by the domain registries, then I see no problem doing it this way and we can save time and effort here.

Just let me know how you want to do it.

Best,
Tobias

> On 3. Jan 2019, at 09:25, Alexander Mayrhofer <[email-masked]> wrote:
> 
> Jim, 
>

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 3 Jan 2019 09:49:58 +0000

Tobias,

Thanks for coming back to my "rant". A few observations inline: 

> However, nowadays most domain registries have withdrawn to the point of
> implementing only their own ideas or approved RFCs. This inevitably leads to
> the situation that proposals for improvement - whoever they come from -
> either have to be solved via approved RFCs, in lengthy bilateral talks /
> negotiations or through policy development.

[AM] You're unwittingly strengthening my arguments here. You're saying "we don't bother about what Standards Track implies. We just need that RFC number so that we can force the industry into doing what we want". Not because of the higher quality reviews involved in IETF work, the well established and accepted process to progress an Internet Standard, etc. It's just to "gold plate" a spec with a "label" that tricks people into believing it's actually important. 

And secondly, you're actually saying "we're doing this so that we can evade the policy development  and discussions around it". Wow. 

> The goal of the ICANN CPH TechOps Group was and is to address technical
> and operational challenges and as there seems to be no other way we
> decided to go for the standardized way. If the REGEXT Group thinks that an
> individual submission with the status informational is sufficient and this is
> fully supported by the domain registries, then I see no problem doing it this
> way and we can save time and effort here.

[AM] I don't know what the group thinks, i'm speaking as an individual here, obviously. Escrow has been implemented widely, and never made it beyond an individual draft. So, it's possible without an RFC number. Yes, there was some force involved into that, obviously, but - on the contrary 
 
> Just let me know how you want to do it.

[AM] First, I'm not disregarding your (or someone else's) work. I have written enough specifications to understand the amount of work that goes into those documents. Ironing out the details once the first implementation is done, fixing contradictions with other specifications, ironing out late corner cases.. Tons of very very useful work.

[AM] Practically, CPH techops could perfectly publish all those file format specifications as their own documents (CPHT-001... CPHT-002... etc..).  If they are good and beneficial for both registrars and registries, implementation will follow. I'm the last one to oppose standardization in that area - quite the contrary, I can think of  (and I'm working on) standardization of more items (Registry Registrar Data Group, Registry Data Nerds, etc...) - but I wouldn't think of submitting the work there to the IETF. That's my only point.

Best,
Alex

---

From: Tobias Sattler <[email-masked]>
Date: Thu, 3 Jan 2019 11:27:44 +0100

Hi Alex,

I think we're more or less on the same page.

Just so we don't misunderstand each other: It's not that we or I don't appreciate the work on policies or even want to deliberately avoid them.  However, they essentially refer to framework conditions only and not to explicit technical implementations. Btw. I don’t think it would be a great idea to create ICANN policies on how things have to be technical implemented in every detail. But you never know what's to come.

Of course, as a registrar you could also take the view that you are king as a customer. However, it is far from my intention to make demands based on a possible market position. That's not a good style. This is why the way via standardisation should be in the common interest, especially since all parties can participate in it.

Be that as it may, I think we could live without IETF standardization, but conversely it would not be fair if this were interpreted against us and an implementation will only rejected by registries because our proposals are not RFC’s. Funny enough that some registries are working with us on these drafts and are not implementing them yet due to the non-standardization.

For me, this is a bit like a vicious circle.

My two cents

Best,
Tobias

> On 3. Jan 2019, at 10:49, Alexander Mayrhofer <[email-masked]> wrote:
> 
> Tobias,
>

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 3 Jan 2019 10:39:41 +0000

Hello Tobias,

> I think we're more or less on the same page.

[AM] Good to hear. I do agree that we have the same goal, only our paths differ :)
 
> Just so we don't misunderstand each other: It's not that we or I don't
> appreciate the work on policies or even want to deliberately avoid them.

[AM] I'm with you that some things (such as file formats) are not (much) related to policy, and can be agreed on the "more practical" layers.

> However, they essentially refer to framework conditions only and not to
> explicit technical implementations. Btw. I don’t think it would be a great idea
> to create ICANN policies on how things have to be technical implemented in
> every detail. But you never know what's to come.

[AM] I do definitely agree. Policies should cover the high level requirements. Implementations are a different story, and happen on a different "layer".

> Of course, as a registrar you could also take the view that you are king as a
> customer. However, it is far from my intention to make demands based on a
> possible market position. That's not a good style. This is why the way via
> standardisation should be in the common interest, especially since all parties
> can participate in it.

[AM] As i said, i do believe that if something is good, it will succeed naturally. Technical specifications can, of course, never overcome market considerations or practical considerations (such as available resources, or cost vs. effort considerations). No matter if they're an RFC or any other kind of specification. But that goes beyond the discussion on here.
 
> Be that as it may, I think we could live without IETF standardization, but
> conversely it would not be fair if this were interpreted against us and an
> implementation will only rejected by registries because our proposals are not
> RFC’s. Funny enough that some registries are working with us on these drafts
> and are not implementing them yet due to the non-standardization.

[AM] Maybe that's because now that's an internet draft (rather than an specification from somewhere else) the following text from RFC2026, page 7 applies?

      ********************************************************
      *                                                      *
      *   Under no circumstances should an Internet-Draft    *
      *   be referenced by any paper, report, or Request-    *
      *   for-Proposal, nor should a vendor claim compliance *
      *   with an Internet-Draft.                            *
      *                                                      *
      ********************************************************

> For me, this is a bit like a vicious circle.

[AM] Aiming at an RFC does not replace buy-in by the involved parties, i think that's what it boils down to... 

Best,
Alex

---

From: Tobias Sattler <[email-masked]>
Date: Thu, 3 Jan 2019 12:00:49 +0100

Just to round things up ;-)

We had talked to the registries about our proposals from the beginning. It quickly became clear that they would never implement anything that was not RFC. Which is why we had to make these submissions at all. It would be a real feat to say now that these are still drafts that are not being implemented and, on the other hand, to reject standardization.

Anyway, we will see. Just drop a note if we should pursue another way - I am okay with that, too.

Cheers,
Tobias

> On 3. Jan 2019, at 11:39, Alexander Mayrhofer <[email-masked]> wrote:
> 
> Hello Tobias,
>

---

From: "Gould, James" <[email-masked]>
Date: Mon, 7 Jan 2019 12:53:12 +0000

I don't view the need for the concrete report formats to be defined as standards track RFCs, but instead define an IANA registry for the report formats (e.g., common and optionally proprietary) based on a set of underlying RFCs (format and report interfaces(s)).  This is similar to what has been done with the EPP Extensions registry.  

I'm looking to make the Data Set File Format draft (draft-gould-regext-dataset) more generic to support the definition of an extensible set of CSV files, including initially bulk operations (current format supported) and reports.  The goal for reports is to have a separate definition file (.dsf file based on draft-gould-regext-dataset) per CSV report that provides the meta-data about the report (type, sub-type, date or date-range, duration, data scope, client / registrar, etc.), the report file name, report file checksum, and a formal definition of the fields and separator(s).  In this case, we leave the meta-data out of the file names, we can support the definition of the existing reports, and define an IANA registry for the registration of the report formats (common and proprietary).  A report consumer can look for all .dsf files for processing and leverage the meta-data and the format definition in the .dsf files to automate the consumption of the reports.  With the large number and variety of registrar reports, I believe the best strategy is to come up with an approach that helps define what exists today, that can be leveraged for consumption automation, and that supports a lighter-weight mechanism for defining and registering the reports formats (common and optionally proprietary).                       

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 1/3/19, 6:01 AM, "regext on behalf of Tobias Sattler" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Cheers,
    Tobias

---

From: "James Galvin" <[email-masked]>
Date: Thu, 10 Jan 2019 07:37:51 -0500

Thanks to all those who have indicated their document preferences.

This is a reminder we will close the poll tomorrow, so if you haven’t 
indicated your preferences please do so.

Currently, there is a small set at the top of the list.  More than 5, 
although there is a pretty clear top two.

Thanks again,

Jim

On 21 Dec 2018, at 11:13, James Galvin wrote:

> Please take the time to select the documents you support for 
> advancement in this working group.
>
> If you click once in the box a green check mark will appear.  Use this 
> to indicate support for a document.  If you click twice in the box a 
> yellow check mark in parentheses will appear.  You may use the yellow 
> check mark to indicate support that is a lower priority than a green 
> check mark.
>
> For your convenience I have included the list of documents and their 
> links below.
>
> https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/
>
> https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-report-structure/
>
> Domain Fee Report
> https://datatracker.ietf.org/doc/draft-mcpherson-sattler-ry-transaction-report/
>
> https://datatracker.ietf.org/doc/draft-sattler-registry-domain-inventory-report/
>
> https://datatracker.ietf.org/doc/draft-sattler-registry-unavailable-domain-report/
>
> https://tools.ietf.org/html/draft-gould-casanova-regext-unhandled-namespaces
>
> Data Set File Format
> https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/
>
> Validate

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 11 Jan 2019 03:04:09 -0500

Hello Alexander,

> thanks for posting that - i've made my choices. 

For the record, I share most if not all of your rant Alexander.

1) I am sad to see this working group and the IETF being a rubberstamp for documents discussed elsewhere and coming here explicitely as stated just to get an RFC number.
This is wrong on so many levels and could even be seen as an abuse of IETF.
I do not think the working group should put time and energy on those documents. In most cases they can as well be an individual submission or just stay as a specification added
to the EPP Extension registry.
If people decided to work on them in other venues, then they should just finish "standardization" of them in those other venues, switching to the IETF at the last minute just for an RFC number is certainly not the expected way to work.

The aim of the working group in my mind is to try defining extension that works for
the widest use cases possible accross many registrars and registries. The community is not so big so splitting work in many venues even lowers the chance the results will have enough reviews to make them as generic and globally useful as possible.

Like Alexander stated, the impact of each specification (does it concern one specific case or is it useful for all EPP servers in the world) could or should be taken into account when deciding to work on X instead of Y.

Otherwise we get only a very thin short time frame gain of having RFC for numerous "standardized" extensions where no real consensus will exist on them, some will overlap or even contradict themselves which will in the long term make the current situation regarding deployed extensions on servers even more complex that it is nowadays (and it is complex enough), hence making registrars even more complicated which in turn constrains registries to not be able to easily run new services because registrars will not implement them, etc.

2) I would have much prefered seeing people coming on this exact mailing-list and stating that they will support such and such documents by promising to work on them (reviewing, implementing, etc.) instead of an anonymous poll done on a remote site, whose results are difficult to interpret (is it interest in something being done? willingness to work on it? just showing that is seems to be important without any real interest in it? etc.). That would have shown real community support for some documents and provide a clear proof of interests later on for shepherd reviews and IETF-wide LC.

For all these reasons I voluntarily did not participate in this polling, even if I clearly have my opinion on which documents are most useful to work on than others and which should get the WG attention or not.

That is the end of my rant.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "James Galvin" <[email-masked]>
Date: Fri, 11 Jan 2019 09:08:59 -0500

This is the final reminder.  The poll will close today.

With 20 participants indicating preferences, I can say that RDAP is the 
clear winner.  More folks care about RDAP options than about 
registry-registrar options.

Here are the top 5 so far (highest to lowest) based on raw numbers:

The first choice is clear.  There is not much difference in the numbers 
past that point.

Working group members are invited to look at the raw entries and offer 
commentary about what it shows.

The co-Chairs will make a proposal for consideration early next week.

Jim

On 10 Jan 2019, at 7:37, James Galvin wrote:

> This is a reminder we will close the poll tomorrow, so if you 
> haven’t indicated your preferences please do so.
>
>> If you click once in the box a green check mark will appear.  Use 
>> this to indicate support for a document.  If you click twice in the 
>> box a yellow check mark in parentheses will appear.  You may use the 
>> yellow check mark to indicate support that is a lower priority than a 
>> green check mark.
>>

---

From: "James Galvin" <[email-masked]>
Date: Fri, 18 Jan 2019 11:00:21 -0500

The DOODLE was officially closed Friday.  There was additional person 
who selected documents bringing the total number of contributors to 21.  
The additional selections did not material change the ranking of the 
choices.

Based on raw numbers, the following 5 documents are preferred:

14 Federated Authentication for RDAP
  9 RDAP Partial Response
  8 RDAP Reverse Search
  8 RDAP Sorting and Paging
  8 Login Security

For completeness, I will also observe that if you take out the 
“maybe” votes, the ranking does not change.

The chairs are making the following assumption at this point: if you 
selected a document then you will work on the document.  This assumption 
should be addressed when you vote to adopt a document, where we will ask 
you to make it explicit.

The next thing that is needed is to formally adopt these documents and 
to set milestones for them.  In addition, recall that we agreed with our 
area director to have only 5 milestones open at a time.  Here is the 
process we will use to achieve these two goals.

1. The chairs will send out a call for adoption for each of the 
documents.  Folks MUST respond and either agree or disagree with the 
adoption of each document.  Instructions will be in each message.

2. There are two milestones on our list that do not match these 5 
documents.  The chairs will send out a call for objections to removing 
those two milestones from our list.

3. After we have adopted our documents we will start a discussion of 
setting the milestones for the adopted documents.

Thanks to those who participated in the Doodle poll.

Antoin and Jim

---

From: Tobias Sattler <[email-masked]>
Date: Fri, 25 Jan 2019 23:05:12 +0100

Hi everyone,

After seeing the result of the vote, I, as a representative of a domain registrar, must express my serious concern about the RDAP Reverse Search document.

A reverse search enables third parties to query RDAP, among other things, so that all associated domains can be queried using an email address. I consider this to be very questionable for data protection reasons.

In addition, such queries can lead to a very high load and strongly influence other systems - depending on the implementation of the service.

Furthermore, as far as I know, there is currently no requirement for such functionality - neither from ICANN nor from other registries / registrars. Which is why I want to suggest that this document should not be adopted for now.

Best regards,
Tobias

> On 18. Jan 2019, at 17:00, James Galvin <[email-masked]> wrote:
> 
> The DOODLE was officially closed Friday.  There was additional person who selected documents bringing the total number of contributors to 21.  The additional selections did not material change the ranking of the choices.
> 
> For completeness, I will also observe that if you take out the “maybe” votes, the ranking does not change.
> 
> The chairs are making the following assumption at this point: if you selected a document then you will work on the document.  This assumption should be addressed when you vote to adopt a document, where we will ask you to make it explicit.
> 
> The next thing that is needed is to formally adopt these documents and to set milestones for them.  In addition, recall that we agreed with our area director to have only 5 milestones open at a time.  Here is the process we will use to achieve these two goals.
> 
> 1. The chairs will send out a call for adoption for each of the documents.  Folks MUST respond and either agree or disagree with the adoption of each document.  Instructions will be in each message.
> 
> 2. There are two milestones on our list that do not match these 5 documents.  The chairs will send out a call for objections to removing those two milestones from our list.
> 
> 3. After we have adopted our documents we will start a discussion of setting the milestones for the adopted documents.
> 
>> Please take the time to select the documents you support for advancement in this working group.
>> 
>> If you click once in the box a green check mark will appear.  Use this to indicate support for a document.  If you click twice in the box a yellow check mark in parentheses will appear.  You may use the yellow check mark to indicate support that is a lower priority than a green check mark.
>> 
>> For your convenience I have included the list of documents and their links below.
>>

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 28 Jan 2019 10:47:13 +0100

Hi Tobias,

let me disagree with you about some conclusions. My comments are inline.

> A reverse search enables third parties to query RDAP, among other things, so that all associated domains can be queried using an email address. I consider this to be very questionable for data prot…

I would agree with you if that capability was available to any user and 
if there were no operators entitled to use it. But this is not the case. 
Reverse search is an example of a capability which should be provided to 
legitimated users according to the policies described in RFC7481. The 
current implementation of reverse search by .it public test server is 
fully GDPR compliant. Currently, it is allowed only to .it registrars 
searching for their own domains. They can submit a reverse search 
because they can rely on the "contract" lawful basis.  In the next 
future, we plan to extend its availability to other legitimated users 
(e.g. authorities, police).

The conclusion is: the specification is neutral, the implementations are 
subject to laws about privacy, but this occurs exactly in the same way 
as other internet protocols.

> In addition, such queries can lead to a very high load and strongly influence other systems - depending on the implementation of the service.
This capability has the same impact on servers of standard search 
queries and RDAP providers can  implement additional features to make 
search queries as sustainable as possible (see partial response and 
pagination).
> Furthermore, as far as I know, there is currently no requirement for such functionality - neither from ICANN nor from other registries / registrars. Which is why I want to suggest that this documen…

This is the crucial issue. Do most of the WG members agree that this 
capability is really helpful ? According to the doodle results, it seems so.

As far as I know, the reverse search concept has been around in TLDs 
community since time. However, the implementation in EPP of the so 
called "non provisioning operations" have been considered unpractical. 
Therefore some registries (including .it) have implemented custom 
solutions based on out-of-band mechanisms. Now, I think that the 
interest in reverse search still exists and RDAP seems suitable enough 
to enable a standardised approach.

Regards,

mario

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email-masked]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo