Skip to main content

Registration Data Access Protocol (RDAP) Reverse Search
draft-ietf-regext-rdap-reverse-search-26

Revision differences

Document history

Date Rev. By Action
2024-03-08
26 (System) RFC Editor state changed to AUTH48
2024-01-10
26 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2023-11-13
26 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-26.txt
2023-11-13
26 (System) New version approved
2023-11-13
26 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2023-11-13
26 Mario Loffredo Uploaded new revision
2023-10-04
25 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2023-10-04
25 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2023-10-04
25 (System) IANA Action state changed to In Progress from Waiting on Authors
2023-10-03
25 (System) IANA Action state changed to Waiting on Authors from In Progress
2023-10-03
25 (System) IANA Action state changed to In Progress from Waiting on Authors
2023-10-02
25 (System) IANA Action state changed to Waiting on Authors from In Progress
2023-09-28
25 (System) RFC Editor state changed to EDIT
2023-09-28
25 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2023-09-28
25 (System) Announcement was received by RFC Editor
2023-09-28
25 (System) IANA Action state changed to In Progress
2023-09-28
25 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2023-09-28
25 Cindy Morgan IESG has approved the document
2023-09-28
25 Cindy Morgan Closed "Approve" ballot
2023-09-28
25 Cindy Morgan Ballot approval text was generated
2023-09-27
25 (System) Removed all action holders (IESG state changed)
2023-09-27
25 Murray Kucherawy IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2023-09-08
25 Robert Wilton [Ballot comment]
Updated position - Thanks for addressing my discuss issue.
2023-09-08
25 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss
2023-09-07
25 John Scudder [Ballot comment]
Thanks for addressing my discuss!
2023-09-07
25 John Scudder [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss
2023-08-30
25 Roman Danyliw
[Ballot comment]
Thank you to Tero Kivinen for the SECDIR review.

Thanks for address my DISCUSS feedback.

I support Lars Eggert's DISCUSS position.

==

** …
[Ballot comment]
Thank you to Tero Kivinen for the SECDIR review.

Thanks for address my DISCUSS feedback.

I support Lars Eggert's DISCUSS position.

==

** Section 1.
  The first objection concerns the potential risks of privacy
  violation.

Where are these privacy concerns summarized?  Could a reference be provided?
2023-08-30
25 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2023-08-30
25 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2023-08-30
25 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-08-30
25 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2023-08-30
25 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-25.txt
2023-08-30
25 (System) New version approved
2023-08-30
25 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2023-08-30
25 Mario Loffredo Uploaded new revision
2023-08-24
24 (System) Changed action holders to Mario Loffredo, Maurizio Martinelli, Murray Kucherawy (IESG state changed)
2023-08-24
24 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2023-08-24
24 Lars Eggert
[Ballot comment]
# GEN AD review of draft-ietf-regext-rdap-reverse-search-24

CC @larseggert

Thanks to Susan Hares for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/Pb3ulFRTmqoQ5FOhkYGLHrZ1zVE). …
[Ballot comment]
# GEN AD review of draft-ietf-regext-rdap-reverse-search-24

CC @larseggert

Thanks to Susan Hares for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/Pb3ulFRTmqoQ5FOhkYGLHrZ1zVE).

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `natively`; alternatives might be `built-in`, `fundamental`,
  `ingrained`, `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-jsonpath-base-17`, but `-19` is the latest
available revision.

### Grammar/style

#### Section 12.2.3.1, paragraph 5
```
| entity search based on the full name (a.k.a | | | formatted name) of an as
                                        ^^^^^
```
The abbreviation/initialism is missing a period after the last letter.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2023-08-24
24 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2023-08-24
24 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2023-08-24
24 Andrew Alston [Ballot comment]
Supporting John's discuss on this one
2023-08-24
24 Andrew Alston [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston
2023-08-24
24 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2023-08-23
24 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

While my review did not identity any issues, I am supporting Lars' & John's …
[Ballot comment]
Thank you for the work put into this document.

While my review did not identity any issues, I am supporting Lars' & John's DISCUSS points.

Special thanks to Tom Harrison for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric
2023-08-23
24 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2023-08-23
24 Robert Wilton
[Ballot discuss]


Hi,

Flagging part of the IANA considerations as a DISCUSS, but I think that this should be easy to resolve:

(1) p 11, …
[Ballot discuss]


Hi,

Flagging part of the IANA considerations as a DISCUSS, but I think that this should be easy to resolve:

(1) p 11, sec 12.2.1.  Creation of the RDAP Reverse Search Registries

  These registries follow the Specification Required process as defined
  in Section 4.5 of [RFC8126].

  The designated expert should prevent collisions and confirm that
  suitable documentation, as described in Section 4.6 of [RFC8126], is
  available to ensure interoperability.  References are not limited
  only to RFCs and simple definitions could be described in the
  registries themselves.

I'm not sure that "simple definitions could be described in the registries themselves" is consistent with the "Specification Required" policy chosen above.
2023-08-23
24 Robert Wilton
[Ballot comment]
[I support John's discuss on normative references.]

I also have some other comments that you may wish to consider:

(2) p 14, sec …
[Ballot comment]
[I support John's discuss on normative references.]

I also have some other comments that you may wish to consider:

(2) p 14, sec 12.2.4.2.  Initial Content

      +==========+==================================================+
      | Property | Property Path                                    |
      +==========+==================================================+
      | fn      | $.entities[*].vcardArray[1][?(@[0]=='fn')][3]    |
      +----------+--------------------------------------------------+
      | handle  | $.entities[*].handle                            |
      +----------+--------------------------------------------------+
      | email    | $.entities[*].vcardArray[1][?(@[0]=='email')][3] |
      +----------+--------------------------------------------------+
      | role    | $.entities[*].roles                              |
      +----------+--------------------------------------------------+

Would it be helpful for this table to include the "Description" and "Reference" properties?



Minor level comments:

(3) p 3, sec 1.  Introduction

  The protocol described in this specification aims to extend the RDAP
  query capabilities and response to enable reverse search based on the
  relationships defined in RDAP between an object class for search and
  a related object class.  The reverse search based on the domain-
  entity relationship is treated as a particular case of such a generic
  model.

This introduction text seems to immediately jump into a defense as to why it is okay to standardize this functionality in an RDAP extension.  This is okay, but I wonder whether it wouldn't be better if the introduction only included the last paragraph (i.e., that is stating what extension is defined in this document), and the rest of the text was moved into a "Background" subsection of the introduction.


(4) p 7, sec 8.  Reverse Searches Based on Entity Details

  Reverse search property:  fn
  RDAP member path:  $.entities[*].vcardArray[1][?(@[0]=='fn')][3]
  Reference:  Section 6.2.1 of [RFC6350]

A minor issue, but it wasn't immediately obvious to me what 'fn' is - I initially presumed that it meant function, so I was wondering if some more text would be helpful here, and/or perhaps in the IANA registry that you are creating.

Regards,
Rob
2023-08-23
24 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2023-08-23
24 Zaheduzzaman Sarker [Ballot comment]
Supporting Lars's and John's Discuss.
2023-08-23
24 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2023-08-22
24 John Scudder
[Ballot discuss]
Thanks for this document. I have one concern, which should be easy to address.

It looks as though draft-ietf-jsonpath-base should be a Normative …
[Ballot discuss]
Thanks for this document. I have one concern, which should be easy to address.

It looks as though draft-ietf-jsonpath-base should be a Normative reference. In fact, this is explicitly mentioned in the shepherd writeup (thank you!):

> 15. Should any informative references be normative or vice-versa? See the
[IESG >    Statement on Normative and Informative References][16].

JSON Paths are depended on normatively in the document, but the
reference for them is to I-D.ietf-jsonpath-base, which is why that
reference is informative.  (This is in keeping with e.g. RFC 8977,
though in that case the reference was to the original description of
the JSON Path behaviour at https://goessner.net/articles/JsonPath/.)

However, that rationale doesn't make sense to me. If a normative reference is a downref, "just stick it in the informative references section instead" is not the appropriate fix, the usual thing is to keep it in the normative references and then the RFC Editor deals with the mismatch by holding off on publication of the dependent document, until the dependency is published (a so-called "cluster").  In this case, draft-ietf-jsonpath-base is on the same IESG agenda as draft-ietf-regext-rdap-reverse-search is, so there isn't even much reason to worry that draft-ietf-regext-rdap-reverse-search will be stalled for long if at all, the two will likely move together.

The easiest way to resolve this DISCUSS would be to change the reference to Normative. If for some reason that's considered unacceptable, I'd appreciate a discussion explaining why, and why "make it an informative reference" should be acceptable.
2023-08-22
24 John Scudder [Ballot Position Update] New position, Discuss, has been recorded for John Scudder
2023-08-22
24 Roman Danyliw
[Ballot discuss]
** Section 13
  In general, given the sensitivity of this functionality, it SHOULD be
  accessible to authorized users only, and for …
[Ballot discuss]
** Section 13
  In general, given the sensitivity of this functionality, it SHOULD be
  accessible to authorized users only, and for specific use cases only.

If this data is considered sensitive, why would unauthorized users be permitted to access it (as permitted by use of SHOULD and not a MUST).

** Section 13
  Providing reverse search in RDAP carries the following threats as
  described in [RFC6973]:

  *  Correlation
  *  Disclosure
  *  Misuse of information

  Therefore, RDAP providers need to mitigate the risk of those threats
  by implementing appropriate measures supported by security services
  (see Section 14).

Thank you for explicitly including a privacy considerations section to outline the associated risks.  Can the text please be more specific in linking these real threats with the proposed mitigations referenced in Section 14?

For example, if one is mitigating against “misuse of information” is that by an authenticated/authorized or authenticated user?  Is some kind of authentication/authorization required for this class of invocation of RDAP?  RFC7481 presents options but not much MTI. 

How is “correlation” being mitigated?

What is “disclosure” in this case?  How is it mitigated?
2023-08-22
24 Roman Danyliw
[Ballot comment]
Thank you to Tero Kivinen for the SECDIR review.

I support Lars Eggert's DISCUSS position.

** Section 1.
  The first objection concerns …
[Ballot comment]
Thank you to Tero Kivinen for the SECDIR review.

I support Lars Eggert's DISCUSS position.

** Section 1.
  The first objection concerns the potential risks of privacy
  violation.

Where are these privacy concerns summarized?  Could a reference be provided?
2023-08-22
24 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2023-08-22
24 Lars Eggert
[Ballot discuss]
# GEN AD review of draft-ietf-regext-rdap-reverse-search-24

CC @larseggert

Thanks to Susan Hares for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/Pb3ulFRTmqoQ5FOhkYGLHrZ1zVE). …
[Ballot discuss]
# GEN AD review of draft-ietf-regext-rdap-reverse-search-24

CC @larseggert

Thanks to Susan Hares for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/Pb3ulFRTmqoQ5FOhkYGLHrZ1zVE).

## Discuss

(For discussion in the IESG, i.e., no action required from the
authors.) This is likely me not understanding something, but I'd
appreciate if someone could explain where this document fits into the
current REGEXT charter scope?
2023-08-22
24 Lars Eggert
[Ballot comment]
## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `natively`; …
[Ballot comment]
## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `natively`; alternatives might be `built-in`, `fundamental`,
  `ingrained`, `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-jsonpath-base-17`, but `-19` is the latest
available revision.

### Grammar/style

#### Section 12.2.3.1, paragraph 5
```
| entity search based on the full name (a.k.a | | | formatted name) of an as
                                        ^^^^^
```
The abbreviation/initialism is missing a period after the last letter.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2023-08-22
24 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert
2023-08-21
24 Susan Hares Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Susan Hares. Sent review to list.
2023-08-21
24 Tim Chown Request for Last Call review by OPSDIR Completed: Not Ready. Reviewer: Tim Chown. Sent review to list.
2023-08-17
24 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2023-08-17
24 David Dong Expert has approved the RDAP Extensions registration.
2023-08-17
24 David Dong IANA Experts State changed to Expert Reviews OK from Issues identified
2023-08-17
24 Amy Vezza Placed on agenda for telechat - 2023-08-24
2023-08-17
24 Murray Kucherawy Ballot has been issued
2023-08-17
24 Murray Kucherawy [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy
2023-08-17
24 Murray Kucherawy Created "Approve" ballot
2023-08-17
24 Murray Kucherawy IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2023-08-17
24 Murray Kucherawy Ballot writeup was changed
2023-08-17
24 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2023-08-17
24 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-08-17
24 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2023-08-17
24 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-24.txt
2023-08-17
24 (System) New version approved
2023-08-17
24 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2023-08-17
24 Mario Loffredo Uploaded new revision
2023-08-16
23 David Dong
Thanks Mario. I understand the intent and had assumed that multiple
mappings were allowed.

While Scott and I understand, do we feel that future DE's …
Thanks Mario. I understand the intent and had assumed that multiple
mappings were allowed.

While Scott and I understand, do we feel that future DE's might need
better guidance? Is the term "collisions" clear enough for a future DE
that may not have the benefit of having read this email thread?

-andy
2023-08-12
23 Murray Kucherawy Changes planned after ARTART review.
2023-08-12
23 (System) Changed action holders to Murray Kucherawy, Mario Loffredo, Maurizio Martinelli (IESG state changed)
2023-08-12
23 Murray Kucherawy IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead::AD Followup
2023-08-12
23 Murray Kucherawy IESG state changed to Waiting for AD Go-Ahead::AD Followup from Waiting for AD Go-Ahead
2023-08-11
23 David Dong
I wish I had asked this during the WG discussion, but I do have a question.

Section 12.2.1 paragraph 3 states:

"The designated expert should …
I wish I had asked this during the WG discussion, but I do have a question.

Section 12.2.1 paragraph 3 states:

"The designated expert should prevent collisions and confirm that
suitable documentation, as described in Section 4.6 of [RFC8126], is
available to ensure interoperability. References are not limited only
to RFCs and simple definitions could be described in the registries
themselves."

Does this mean that no duplicates in the RDAP Reverse Search Mapping
(section 12.2.4) are allowed?

If this is the case, that means a reverse search of "fn" will only
apply to jCard and cannot be applied to JSContact or SimpleContact
since the registration for "fn" is jCard specific. Is this
intentional?

I see this in section 5:

"Documents that deprecate or restructure RDAP responses such that a
registered reverse search is no longer able to be used MUST either
note that the relevant reverse search is no longer available (in the
case of deprecation) or describe how to continue supporting the
relevant search by adding another mapping for the reverse search
property (in the case of restructuring)."

It implies that duplicates are allowed, at least to me.

-andy
2023-08-11
23 David Dong IANA Experts State changed to Issues identified from Reviews assigned
2023-08-11
23 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-08-10
23 David Dong IANA Experts State changed to Reviews assigned
2023-08-10
23 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2023-08-10
23 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-rdap-reverse-search-23. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-rdap-reverse-search-23. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about the first action requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the RDAP Extensions registry located at:

https://www.iana.org/assignments/rdap-extensions/

a single new registration will be made as follows:

Extension Identifier: reverse_search
Registry Operator: Any
Specification: [ RFC-to-be ]
Contact: IETF
Intended Usage: This extension identifier is used for both URI path segments and response extensions related to the reverse search in RDAP.


IANA QUESTION -> Would it be acceptable to list the IETF as the change controller for the RDAP Extensions registration, along with the other registrations in this document, instead of the IESG? There has been a preference for doing so, as described in the expired document at https://datatracker.ietf.org/doc/html/draft-leiba-ietf-iana-registrations-00, but it has not been recorded in a permanent document yet.


As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry is to be created called the RDAP Reverse Search registry. The new registry will be a new item in the Registration Data Access Protocol (RDAP) grouping of registries located at:

https://www.iana.org/assignments/

The new registry is to be managed via Specification Required as defined in RFC 8126 and new requests for registrations can be drafted via the template in [ RFC-to-be, Section 12.2.3.1 ] and sent to iana@iana.org.

There are four initial registrations in the new registry as follows:

Property: fn
Description: The server supports the domain/nameserver/entity search based on the full name (a.k.a formatted name) of an associated entity
Searchable Resource Type: domains, nameservers, entities
Related Resource Type: entity
Registrant Name: IETF
Registrant Contact Information: iesg@ietf.org
Reference: [ RFC-to-be, Section 8 ]

Property: handle
Description: The server supports the domain/nameserver/entity search based on the handle of an associated entity
Searchable Resource Type: domains, nameservers, entities
Related Resource Type: entity
Registrant Name: IETF
Registrant Contact Information: iesg@ietf.org
Reference: [ RFC-to-be, Section 8 ]

Property: email
Description: The server supports the domain/nameserver/entity search based on the email address of an associated entity
Searchable Resource Type: domains, nameservers, entities
Related Resource Type: entity
Registrant Name: IETF
Registrant Contact Information: iesg@ietf.org
Reference: [ RFC-to-be, Section 8 ]

Property: role
Description: The server supports the domain/nameserver/entity search based on the role of an associated entity
Searchable Resource Type: domains, nameservers, entities
Related Resource Type: entity
Registrant Name: IETF
Registrant Contact Information: iesg@ietf.org
Reference: [ RFC-to-be, Section 8 ]

Third, a new registry is to be created called the RDAP Reverse Search Mapping registry. The new registry will be a new item in the Registration Data Access Protocol (RDAP) grouping of registries located at:

https://www.iana.org/assignments/

The new registry is to be managed via Specification Required as defined in RFC 8126 and new requests for registrations can be drafted via the template in [ RFC-to-be, Section 12.2.4.1 ] and sent to iana@iana.org.

There are four initial registrations in the new registry as follows:

Property: fn
Property Path: $.entities[*].vcardArray[1][?(@[0]=='fn')][3]
Searchable Resource Type: domains, nameservers, entities
Related Resource Type: entity
Registrant Name: IETF
Registrant Contact Information: iesg@ietf.org
Reference: [ RFC-to-be, Section 8 ]

Property: handle
Property Path: $.entities[*].handle
Searchable Resource Type: domains, nameservers, entities
Related Resource Type: entity
Registrant Name: IETF
Registrant Contact Information: iesg@ietf.org
Reference: [ RFC-to-be, Section 8 ]

Property: email
Property Path: $.entities[*].vcardArray[1][?(@[0]=='email')][3]
Searchable Resource Type: domains, nameservers, entities
Related Resource Type: entity
Registrant Name: IETF
Registrant Contact Information: iesg@ietf.org
Reference: [ RFC-to-be, Section 8 ]

Property: role
Property Path: $.entities[*].roles
Searchable Resource Type: domains, nameservers, entities
Related Resource Type: entity
Registrant Name: IETF
Registrant Contact Information: iesg@ietf.org
Reference: [ RFC-to-be, Section 8 ]

The IANA Functions Operator understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2023-08-08
23 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Tero Kivinen. Sent review to list.
2023-08-07
23 James Galvin
> # Document Shepherd Write-Up for Group Documents                                    …
> # Document Shepherd Write-Up for Group Documents                                                                                                                   
>                                                                                                                                                                     
> *This version is dated 4 July 2022.*                                                                                                                               
>                                                                                                                                                                     
> Thank you for your service as a document shepherd. Among the responsibilities is                                                                                   
> answering the questions in this write-up to give helpful context to Last Call                                                                                       
> and Internet Engineering Steering Group ([IESG][1]) reviewers, and your                                                                                             
> diligence in completing it is appreciated. The full role of the shepherd is                                                                                         
> further described in [RFC 4858][2]. You will need the cooperation of the authors                                                                                   
> and editors to complete these checks.                                                                                                                               
>                                                                                                                                                                     
> Note that some numbered items contain multiple related questions; please be sure                                                                                   
> to answer all of them.                                                                                                                                             
>                                                                                                                                                                     
> ## Document History                                                                                                                                                 
>                                                                                                                                                                     
> 1. Does the working group (WG) consensus represent the strong concurrence of a                                                                                     
>    few individuals, with others being silent, or did it reach broad agreement?                                                                                     
                                                                                                                                                                     
It represents the strong concurrence of a few individuals.  However,                                                                                                 
the group within regext that's concerned with RDAP is fairly small,                                                                                                   
and most of them are in favour, so it might also be considered broad                                                                                                 
agreement when taking that into consideration.                                                                                                                       
                                                                                                                                                                     
> 2. Was there controversy about particular points, or were there decisions where                                                                                     
>    the consensus was particularly rough?                                                                                                                           
                                                                                                                                                                     
There is currently no controversy about any particular points, and there were                                                                                                 
no decisions where the consensus was particularly rough.  There has                                                                                                 
been a substantial amount of fairly contentious discussion over time                                                                                                 
concerning the privacy considerations section of the document, given                                                                                                 
e.g. laws like the GDPR, but all known issues in this respect have                                                                                                   
been resolved. There has been a substantial amount of fairly contentious
discussion over time concerning human rights issues that have been resolved
in the privacy considerations section of the document.

> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If                                                                                   
>    so, please summarize the areas of conflict in separate email messages to the                                                                                     
>    responsible Area Director. (It should be in a separate email because this                                                                                       
>    questionnaire is publicly available.)                                                                                                                           
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 4. For protocol documents, are there existing implementations of the contents of                                                                                   
>    the document? Have a significant number of potential implementers indicated                                                                                     
>    plans to implement? Are any existing implementations reported somewhere,                                                                                         
>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere                                                                                         
>    (where)?                                                                                                                                                         
                                                                                                                                                                     
There are existing implementations of the protocol:                                                                                                                   
                                                                                                                                                                     
- IIT-CNR/Registro.it RDAP Server (https://rdap.pubtest.nic.it/)                                                                                                     
- IIT-CNR/Registro.it RDAP Client (https://web-rdap.pubtest.nic.it/)                                                                                                 
- APNIC server (https://github.com/APNIC-net/rdap-rmp-demo/tree/reverse-search)                                                                                     
                                                                                                                                                                     
The document includes further details on the first two of these in                                                                                                   
section 11 (Implementation Status).                                                                                                                                   
                                                                                                                                                                     
There haven't been any express comments on the list from implementors                                                                                                 
about their plans to implement.  However, it is likely that each of                                                                                                   
the RIRs will implement this protocol at some point, at least.

> ## Additional Reviews                                                                                                                                               
>                                                                                                                                                                     
> 5. Do the contents of this document closely interact with technologies in other                                                                                     
>    IETF working groups or external organizations, and would it therefore benefit                                                                                   
>    from their review? Have those reviews occurred? If yes, describe which                                                                                           
>    reviews took place.                                                                                                                                             
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 6. Describe how the document meets any required formal expert review criteria,                                                                                     
>    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.                                                                                           
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 7. If the document contains a YANG module, has the final version of the module                                                                                     
>    been checked with any of the [recommended validation tools][4] for syntax and                                                                                   
>    formatting validation? If there are any resulting errors or warnings, what is                                                                                   
>    the justification for not fixing them at this time? Does the YANG module                                                                                         
>    comply with the Network Management Datastore Architecture (NMDA) as specified                                                                                   
>    in [RFC 8342][5]?                                                                                                                                               
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 8. Describe reviews and automated checks performed to validate sections of the                                                                                     
>    final version of the document written in a formal language, such as XML code,                                                                                   
>    BNF rules, MIB definitions, CBOR's CDDL, etc.                                                                                                                   
                                                                                                                                                                     
The document contains JSON documents and JSON Path strings.  The JSON                                                                                                 
documents were validated using Perl's JSON::XS.  The JSON Path strings                                                                                               
were validated using http://jsonpath.com, which relies on the JS                                                                                                     
JSONPath Plus library (https://github.com/JSONPath-Plus/JSONPath).

> ## Document Shepherd Checks                                                                                                                                         
>                                                                                                                                                                     
> 9. Based on the shepherd's review of the document, is it their opinion that this                                                                                   
>    document is needed, clearly written, complete, correctly designed, and ready                                                                                     
>    to be handed off to the responsible Area Director?                                                                                                               
                                                                                                                                                                     
Yes.                                                                                                                                                                 
                                                                                                                                                                     
> 10. Several IETF Areas have assembled [lists of common issues that their                                                                                           
>    reviewers encounter][6]. For which areas have such issues been identified                                                                                       
>    and addressed? For which does this still need to happen in subsequent                                                                                           
>    reviews?                                                                                                                                                       
                                                                                                                                                                     
The items mentioned on the ART list on the linked page are not                                                                                                       
relevant to this document.  (Most are relevant to the underlying RDAP                                                                                                 
protocol specifications, though, and are addressed in the appropriate                                                                                                 
core RDAP document as necessary.)                                                                                                                                     
                                                                                                                                                                     
> 11. What type of RFC publication is being requested on the IETF stream ([Best                                                                                       
>    Current Practice][12], [Proposed Standard, Internet Standard][13],                                                                                             
>    [Informational, Experimental or Historic][14])? Why is this the proper type                                                                                     
>    of RFC? Do all Datatracker state attributes correctly reflect this intent?                                                                                     
                                                                                                                                                                     
The type of RFC being requested is Proposed Standard, because the                                                                                                     
document defines extensions to the existing RDAP protocol.  All                                                                                                       
Datatracker state attributes correctly reflect this intent.                                                                                                           
                                                                                                                                                                     
> 12. Have reasonable efforts been made to remind all authors of the intellectual                                                                                     
>    property rights (IPR) disclosure obligations described in [BCP 79][7]? To                                                                                       
>    the best of your knowledge, have all required disclosures been filed? If                                                                                       
>    not, explain why. If yes, summarize any relevant discussion, including links                                                                                   
>    to publicly-available messages when applicable.                                                                                                                 
                                                                                                                                                                     
The document authors have all confirmed they know of no needed                                                                                                       
IPR disclosures.                                                                                                                                                     
                                                                                                                                                                     
> 13. Has each author, editor, and contributor shown their willingness to be                                                                                         
>    listed as such? If the total number of authors and editors on the front page                                                                                   
>    is greater than five, please provide a justification.                                                                                                           
                                                                                                                                                                     
Each author has shown their willingness to be listed as such.

> 14. Document any remaining I-D nits in this document. Simply running the [idnits                                                                                   
>    tool][8] is not enough; please review the ["Content Guidelines" on                                                                                             
>    authors.ietf.org][15]. (Also note that the current idnits tool generates                                                                                       
>    some incorrect warnings; a rewrite is underway.)                                                                                                               
                                                                                                                                                                     
The idnits page is available at                                                                                                                                       
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-22.txt&submissioncheck=True:                       
                                                                                                                                                                     
- "There is 1 instance of lines with non-ascii characters in the                                                                                                     
  document"                                                                                                                                                         
    - The non-ASCII character is in the name 'Gössner', so this is                                                                                                   
      fine.                                                                                                                                                           
                                                                                                                                                                     
- "Looks like a reference, but probably isn't: '1' on line 670"                                                                                                     
    - This comment is the result of the script misinterpreting a JSON                                                                                                 
      Path value.                                                                                                                                                     
                                                                                                                                                                     
The document appears to be fine as against the "Content Guidelines".                                                                                                 
                                                                                                                                                                     
> 15. Should any informative references be normative or vice-versa? See the [IESG                                                                                     
>    Statement on Normative and Informative References][16].

JSON Paths are depended on normatively in the document, but the                                                                                                       
reference for them is to I-D.ietf-jsonpath-base, which is why that                                                                                                   
reference is informative.  (This is in keeping with e.g. RFC 8977,                                                                                                   
though in that case the reference was to the original description of                                                                                                 
the JSON Path behaviour at https://goessner.net/articles/JsonPath/.)

> 16. List any normative references that are not freely available to anyone. Did                                                                                     
>    the community have sufficient access to review any such normative                                                                                               
>    references?                                                                                                                                                     
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 17. Are there any normative downward references (see [RFC 3967][9] and [BCP                                                                                         
>    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,                                                                                     
>    list them.                                                                                                                                                     
                                                                                                                                                                     
N/A (though see the earlier comment about the JSON Path reference in                                                                                                 
this respect).                                                                                                                                                       
                                                                                                                                                                     
> 18. Are there normative references to documents that are not ready to be                                                                                           
>    submitted to the IESG for publication or are otherwise in an unclear state?                                                                                     
>    If so, what is the plan for their completion?                                                                                                                   
                                                                                                                                                                     
N/A (though see the earlier comment about the JSON Path reference in                                                                                                 
this respect).

> 19. Will publication of this document change the status of any existing RFCs? If                                                                                   
>    so, does the Datatracker metadata correctly reflect this and are those RFCs                                                                                     
>    listed on the title page, in the abstract, and discussed in the                                                                                                 
>    introduction? If not, explain why and point to the part of the document                                                                                         
>    where the relationship of this document to these other RFCs is discussed.                                                                                       
                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 20. Describe the document shepherd's review of the IANA considerations section,                                                                                     
>    especially with regard to its consistency with the body of the document.                                                                                       
>    Confirm that all aspects of the document requiring IANA assignments are                                                                                         
>    associated with the appropriate reservations in IANA registries. Confirm                                                                                       
>    that any referenced IANA registries have been clearly identified. Confirm                                                                                       
>    that each newly created IANA registry specifies its initial contents,                                                                                           
>    allocations procedures, and a reasonable name (see [RFC 8126][11]).                                                                                             
                                                                                                                                                                     
The IANA considerations section includes registration of a new RDAP                                                                                                   
extension, as well as creation of two new registries for RDAP reverse                                                                                                 
searches.  Each of the above checks appears to be fine.                                                                                                               
                                                                                                                                                                     
> 21. List any new IANA registries that require Designated Expert Review for                                                                                         
>    future allocations. Are the instructions to the Designated Expert clear?                                                                                       
>    Please include suggestions of designated experts, if appropriate.                                                                                               
                                                                                                                                                                     
The two new registries are "RDAP Reverse Search" and "RDAP Reverse                                                                                                   
Search Mapping", in the "Registration Data Access Protocol (RDAP)"                                                                                                   
group.  The instructions to the designated expert are clear.                                                                                                         
                                                                                                                                                                     
Andy Newton (andy@hxr.us) and Scott Hollenbeck (shollenbeck@verisign.com)
are the designated experts for the existing RDAP IANA registries that
require designated expert review.  Each has agreed to be listed as one
of the designated experts for the new registries defined by this document.

> [1]: https://www.ietf.org/about/groups/iesg/
> [2]: https://www.rfc-editor.org/rfc/rfc4858.html
> [3]: https://www.rfc-editor.org/rfc/rfc7942.html
> [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
> [5]: https://www.rfc-editor.org/rfc/rfc8342.html
> [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
> [7]: https://www.rfc-editor.org/info/bcp79
> [8]: https://www.ietf.org/tools/idnits/
> [9]: https://www.rfc-editor.org/rfc/rfc3967.html
> [10]: https://www.rfc-editor.org/info/bcp97
> [11]: https://www.rfc-editor.org/rfc/rfc8126.html
> [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
> [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
> [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
> [15]: https://authors.ietf.org/en/content-guidelines-overview
> [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> [17]: https://datatracker.ietf.org/doc/downref/
2023-08-03
23 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2023-08-03
23 Jean Mahoney Request for Last Call review by GENART is assigned to Susan Hares
2023-08-03
23 Scott Hollenbeck Request for Last Call review by ARTART Completed: Ready. Reviewer: Scott Hollenbeck. Review has been revised by Scott Hollenbeck.
2023-08-02
23 Scott Hollenbeck Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Scott Hollenbeck. Sent review to list.
2023-08-02
23 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2023-07-31
23 Barry Leiba Request for Last Call review by ARTART is assigned to Scott Hollenbeck
2023-07-28
23 Cindy Morgan IANA Review state changed to IANA - Review Needed
2023-07-28
23 Cindy Morgan
The following Last Call announcement was sent out (ends 2023-08-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-regext-rdap-reverse-search@ietf.org, regext-chairs@ietf.org, regext@ietf.org, superuser@gmail.com, tomh@apnic.net …
The following Last Call announcement was sent out (ends 2023-08-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-regext-rdap-reverse-search@ietf.org, regext-chairs@ietf.org, regext@ietf.org, superuser@gmail.com, tomh@apnic.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Registration Data Access Protocol (RDAP) Reverse Search) to Proposed Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Registration Data Access
Protocol (RDAP) Reverse Search'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-08-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Registration Data Access Protocol (RDAP) does not include query
  capabilities for finding the list of domains related to a set of
  entities matching a given search pattern.  Considering that an RDAP
  entity can be associated with any defined object class and other
  relationships between RDAP object classes exist, a reverse search can
  be applied to other use cases besides the classic domain-entity
  scenario.  This document describes an RDAP extension that allows
  servers to provide a reverse search feature based on the relationship
  defined in RDAP between an object class for search and any related
  object class.  The reverse search based on the domain-entity
  relationship is treated as a particular case.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/



No IPR declarations have been submitted directly on this I-D.




2023-07-28
23 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2023-07-28
23 Murray Kucherawy Last call was requested
2023-07-28
23 Murray Kucherawy Ballot approval text was generated
2023-07-28
23 Murray Kucherawy Ballot writeup was generated
2023-07-28
23 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2023-07-28
23 Murray Kucherawy IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2023-07-28
23 Murray Kucherawy Last call announcement was generated
2023-07-28
23 (System) Changed action holders to Antoin Verschuren, Tom Harrison, James Galvin (IESG state changed)
2023-07-28
23 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-07-28
23 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-23.txt
2023-07-28
23 (System) New version approved
2023-07-28
23 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2023-07-28
23 Mario Loffredo Uploaded new revision
2023-07-09
22 Murray Kucherawy Changed action holders to Antoin Verschuren, Tom Harrison, James Galvin, Mario Loffredo, Maurizio Martinelli
2023-07-09
22 (System) Changed action holders to Mario Loffredo, Maurizio Martinelli, Murray Kucherawy (IESG state changed)
2023-07-09
22 Murray Kucherawy IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2023-05-19
22 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2023-05-19
22 Murray Kucherawy IESG state changed to AD Evaluation from Publication Requested
2023-05-15
22 Antoin Verschuren
> # Document Shepherd Write-Up for Group Documents                                    …
> # Document Shepherd Write-Up for Group Documents                                                                                                                   
>                                                                                                                                                                     
> *This version is dated 4 July 2022.*                                                                                                                               
>                                                                                                                                                                     
> Thank you for your service as a document shepherd. Among the responsibilities is                                                                                   
> answering the questions in this write-up to give helpful context to Last Call                                                                                       
> and Internet Engineering Steering Group ([IESG][1]) reviewers, and your                                                                                             
> diligence in completing it is appreciated. The full role of the shepherd is                                                                                         
> further described in [RFC 4858][2]. You will need the cooperation of the authors                                                                                   
> and editors to complete these checks.                                                                                                                               
>                                                                                                                                                                     
> Note that some numbered items contain multiple related questions; please be sure                                                                                   
> to answer all of them.                                                                                                                                             
>                                                                                                                                                                     
> ## Document History                                                                                                                                                 
>                                                                                                                                                                     
> 1. Does the working group (WG) consensus represent the strong concurrence of a                                                                                     
>    few individuals, with others being silent, or did it reach broad agreement?                                                                                     
                                                                                                                                                                     
It represents the strong concurrence of a few individuals.  However,                                                                                                 
the group within regext that's concerned with RDAP is fairly small,                                                                                                   
and most of them are in favour, so it might also be considered broad                                                                                                 
agreement when taking that into consideration.                                                                                                                       
                                                                                                                                                                     
> 2. Was there controversy about particular points, or were there decisions where                                                                                     
>    the consensus was particularly rough?                                                                                                                           
                                                                                                                                                                     
There was no controversy about any particular points, and there were                                                                                                 
no decisions where the consensus was particularly rough.  (There has                                                                                                 
been a substantial amount of fairly contentious discussion over time                                                                                                 
concerning the privacy considerations section of the document, given                                                                                                 
e.g. laws like the GDPR, but all known issues in this respect have                                                                                                   
been resolved.)

> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If                                                                                   
>    so, please summarize the areas of conflict in separate email messages to the                                                                                     
>    responsible Area Director. (It should be in a separate email because this                                                                                       
>    questionnaire is publicly available.)                                                                                                                           
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 4. For protocol documents, are there existing implementations of the contents of                                                                                   
>    the document? Have a significant number of potential implementers indicated                                                                                     
>    plans to implement? Are any existing implementations reported somewhere,                                                                                         
>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere                                                                                         
>    (where)?                                                                                                                                                         
                                                                                                                                                                     
There are existing implementations of the protocol:                                                                                                                   
                                                                                                                                                                     
- IIT-CNR/Registro.it RDAP Server (https://rdap.pubtest.nic.it/)                                                                                                     
- IIT-CNR/Registro.it RDAP Client (https://web-rdap.pubtest.nic.it/)                                                                                                 
- APNIC server (https://github.com/APNIC-net/rdap-rmp-demo/tree/reverse-search)                                                                                     
                                                                                                                                                                     
The document includes further details on the first two of these in                                                                                                   
section 11 (Implementation Status).                                                                                                                                   
                                                                                                                                                                     
There haven't been any express comments on the list from implementors                                                                                                 
about their plans to implement.  However, it is likely that each of                                                                                                   
the RIRs will implement this protocol at some point, at least.

> ## Additional Reviews                                                                                                                                               
>                                                                                                                                                                     
> 5. Do the contents of this document closely interact with technologies in other                                                                                     
>    IETF working groups or external organizations, and would it therefore benefit                                                                                   
>    from their review? Have those reviews occurred? If yes, describe which                                                                                           
>    reviews took place.                                                                                                                                             
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 6. Describe how the document meets any required formal expert review criteria,                                                                                     
>    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.                                                                                           
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 7. If the document contains a YANG module, has the final version of the module                                                                                     
>    been checked with any of the [recommended validation tools][4] for syntax and                                                                                   
>    formatting validation? If there are any resulting errors or warnings, what is                                                                                   
>    the justification for not fixing them at this time? Does the YANG module                                                                                         
>    comply with the Network Management Datastore Architecture (NMDA) as specified                                                                                   
>    in [RFC 8342][5]?                                                                                                                                               
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 8. Describe reviews and automated checks performed to validate sections of the                                                                                     
>    final version of the document written in a formal language, such as XML code,                                                                                   
>    BNF rules, MIB definitions, CBOR's CDDL, etc.                                                                                                                   
                                                                                                                                                                     
The document contains JSON documents and JSON Path strings.  The JSON                                                                                                 
documents were validated using Perl's JSON::XS.  The JSON Path strings                                                                                               
were validated using http://jsonpath.com, which relies on the JS                                                                                                     
JSONPath Plus library (https://github.com/JSONPath-Plus/JSONPath).

> ## Document Shepherd Checks                                                                                                                                         
>                                                                                                                                                                     
> 9. Based on the shepherd's review of the document, is it their opinion that this                                                                                   
>    document is needed, clearly written, complete, correctly designed, and ready                                                                                     
>    to be handed off to the responsible Area Director?                                                                                                               
                                                                                                                                                                     
Yes.                                                                                                                                                                 
                                                                                                                                                                     
> 10. Several IETF Areas have assembled [lists of common issues that their                                                                                           
>    reviewers encounter][6]. For which areas have such issues been identified                                                                                       
>    and addressed? For which does this still need to happen in subsequent                                                                                           
>    reviews?                                                                                                                                                       
                                                                                                                                                                     
The items mentioned on the ART list on the linked page are not                                                                                                       
relevant to this document.  (Most are relevant to the underlying RDAP                                                                                                 
protocol specifications, though, and are addressed in the appropriate                                                                                                 
core RDAP document as necessary.)                                                                                                                                     
                                                                                                                                                                     
> 11. What type of RFC publication is being requested on the IETF stream ([Best                                                                                       
>    Current Practice][12], [Proposed Standard, Internet Standard][13],                                                                                             
>    [Informational, Experimental or Historic][14])? Why is this the proper type                                                                                     
>    of RFC? Do all Datatracker state attributes correctly reflect this intent?                                                                                     
                                                                                                                                                                     
The type of RFC being requested is Proposed Standard, because the                                                                                                     
document defines extensions to the existing RDAP protocol.  All                                                                                                       
Datatracker state attributes correctly reflect this intent.                                                                                                           
                                                                                                                                                                     
> 12. Have reasonable efforts been made to remind all authors of the intellectual                                                                                     
>    property rights (IPR) disclosure obligations described in [BCP 79][7]? To                                                                                       
>    the best of your knowledge, have all required disclosures been filed? If                                                                                       
>    not, explain why. If yes, summarize any relevant discussion, including links                                                                                   
>    to publicly-available messages when applicable.                                                                                                                 
                                                                                                                                                                     
The document authors have all confirmed they know of no needed                                                                                                       
IPR disclosures.                                                                                                                                                     
                                                                                                                                                                     
> 13. Has each author, editor, and contributor shown their willingness to be                                                                                         
>    listed as such? If the total number of authors and editors on the front page                                                                                   
>    is greater than five, please provide a justification.                                                                                                           
                                                                                                                                                                     
Each author has shown their willingness to be listed as such.

> 14. Document any remaining I-D nits in this document. Simply running the [idnits                                                                                   
>    tool][8] is not enough; please review the ["Content Guidelines" on                                                                                             
>    authors.ietf.org][15]. (Also note that the current idnits tool generates                                                                                       
>    some incorrect warnings; a rewrite is underway.)                                                                                                               
                                                                                                                                                                     
The idnits page is available at                                                                                                                                       
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-22.txt&submissioncheck=True:                       
                                                                                                                                                                     
- "There is 1 instance of lines with non-ascii characters in the                                                                                                     
  document"                                                                                                                                                         
    - The non-ASCII character is in the name 'Gössner', so this is                                                                                                   
      fine.                                                                                                                                                           
                                                                                                                                                                     
- "Looks like a reference, but probably isn't: '1' on line 670"                                                                                                     
    - This comment is the result of the script misinterpreting a JSON                                                                                                 
      Path value.                                                                                                                                                     
                                                                                                                                                                     
The document appears to be fine as against the "Content Guidelines".                                                                                                 
                                                                                                                                                                     
> 15. Should any informative references be normative or vice-versa? See the [IESG                                                                                     
>    Statement on Normative and Informative References][16].

JSON Paths are depended on normatively in the document, but the                                                                                                       
reference for them is to I-D.ietf-jsonpath-base, which is why that                                                                                                   
reference is informative.  (This is in keeping with e.g. RFC 8977,                                                                                                   
though in that case the reference was to the original description of                                                                                                 
the JSON Path behaviour at https://goessner.net/articles/JsonPath/.)

> 16. List any normative references that are not freely available to anyone. Did                                                                                     
>    the community have sufficient access to review any such normative                                                                                               
>    references?                                                                                                                                                     
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 17. Are there any normative downward references (see [RFC 3967][9] and [BCP                                                                                         
>    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,                                                                                     
>    list them.                                                                                                                                                     
                                                                                                                                                                     
N/A (though see the earlier comment about the JSON Path reference in                                                                                                 
this respect).                                                                                                                                                       
                                                                                                                                                                     
> 18. Are there normative references to documents that are not ready to be                                                                                           
>    submitted to the IESG for publication or are otherwise in an unclear state?                                                                                     
>    If so, what is the plan for their completion?                                                                                                                   
                                                                                                                                                                     
N/A (though see the earlier comment about the JSON Path reference in                                                                                                 
this respect).

> 19. Will publication of this document change the status of any existing RFCs? If                                                                                   
>    so, does the Datatracker metadata correctly reflect this and are those RFCs                                                                                     
>    listed on the title page, in the abstract, and discussed in the                                                                                                 
>    introduction? If not, explain why and point to the part of the document                                                                                         
>    where the relationship of this document to these other RFCs is discussed.                                                                                       
                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 20. Describe the document shepherd's review of the IANA considerations section,                                                                                     
>    especially with regard to its consistency with the body of the document.                                                                                       
>    Confirm that all aspects of the document requiring IANA assignments are                                                                                         
>    associated with the appropriate reservations in IANA registries. Confirm                                                                                       
>    that any referenced IANA registries have been clearly identified. Confirm                                                                                       
>    that each newly created IANA registry specifies its initial contents,                                                                                           
>    allocations procedures, and a reasonable name (see [RFC 8126][11]).                                                                                             
                                                                                                                                                                     
The IANA considerations section includes registration of a new RDAP                                                                                                   
extension, as well as creation of two new registries for RDAP reverse                                                                                                 
searches.  Each of the above checks appears to be fine.                                                                                                               
                                                                                                                                                                     
> 21. List any new IANA registries that require Designated Expert Review for                                                                                         
>    future allocations. Are the instructions to the Designated Expert clear?                                                                                       
>    Please include suggestions of designated experts, if appropriate.                                                                                               
                                                                                                                                                                     
The two new registries are "RDAP Reverse Search" and "RDAP Reverse                                                                                                   
Search Mapping", in the "Registration Data Access Protocol (RDAP)"                                                                                                   
group.  The instructions to the designated expert are clear.                                                                                                         
                                                                                                                                                                     
Andy Newton (andy@hxr.us) and Scott Hollenbeck (shollenbeck@verisign.com)
are the designated experts for the existing RDAP IANA registries that
require designated expert review.  Each has agreed to be listed as one
of the designated experts for the new registries defined by this document.

> [1]: https://www.ietf.org/about/groups/iesg/
> [2]: https://www.rfc-editor.org/rfc/rfc4858.html
> [3]: https://www.rfc-editor.org/rfc/rfc7942.html
> [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
> [5]: https://www.rfc-editor.org/rfc/rfc8342.html
> [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
> [7]: https://www.rfc-editor.org/info/bcp79
> [8]: https://www.ietf.org/tools/idnits/
> [9]: https://www.rfc-editor.org/rfc/rfc3967.html
> [10]: https://www.rfc-editor.org/info/bcp97
> [11]: https://www.rfc-editor.org/rfc/rfc8126.html
> [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
> [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
> [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
> [15]: https://authors.ietf.org/en/content-guidelines-overview
> [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> [17]: https://datatracker.ietf.org/doc/downref/
2023-05-15
22 Antoin Verschuren Responsible AD changed to Murray Kucherawy
2023-05-15
22 Antoin Verschuren IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2023-05-15
22 Antoin Verschuren IESG state changed to Publication Requested from I-D Exists
2023-05-15
22 Antoin Verschuren Document is now in IESG state Publication Requested
2023-05-15
22 Antoin Verschuren Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway cleared.
2023-05-05
22 Tom Harrison
> # Document Shepherd Write-Up for Group Documents                                    …
> # Document Shepherd Write-Up for Group Documents                                                                                                                   
>                                                                                                                                                                     
> *This version is dated 4 July 2022.*                                                                                                                               
>                                                                                                                                                                     
> Thank you for your service as a document shepherd. Among the responsibilities is                                                                                   
> answering the questions in this write-up to give helpful context to Last Call                                                                                       
> and Internet Engineering Steering Group ([IESG][1]) reviewers, and your                                                                                             
> diligence in completing it is appreciated. The full role of the shepherd is                                                                                         
> further described in [RFC 4858][2]. You will need the cooperation of the authors                                                                                   
> and editors to complete these checks.                                                                                                                               
>                                                                                                                                                                     
> Note that some numbered items contain multiple related questions; please be sure                                                                                   
> to answer all of them.                                                                                                                                             
>                                                                                                                                                                     
> ## Document History                                                                                                                                                 
>                                                                                                                                                                     
> 1. Does the working group (WG) consensus represent the strong concurrence of a                                                                                     
>    few individuals, with others being silent, or did it reach broad agreement?                                                                                     
                                                                                                                                                                     
It represents the strong concurrence of a few individuals.  However,                                                                                                 
the group within regext that's concerned with RDAP is fairly small,                                                                                                   
and most of them are in favour, so it might also be considered broad                                                                                                 
agreement when taking that into consideration.                                                                                                                       
                                                                                                                                                                     
> 2. Was there controversy about particular points, or were there decisions where                                                                                     
>    the consensus was particularly rough?                                                                                                                           
                                                                                                                                                                     
There was no controversy about any particular points, and there were                                                                                                 
no decisions where the consensus was particularly rough.  (There has                                                                                                 
been a substantial amount of fairly contentious discussion over time                                                                                                 
concerning the privacy considerations section of the document, given                                                                                                 
e.g. laws like the GDPR, but all known issues in this respect have                                                                                                   
been resolved.)

> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If                                                                                   
>    so, please summarize the areas of conflict in separate email messages to the                                                                                     
>    responsible Area Director. (It should be in a separate email because this                                                                                       
>    questionnaire is publicly available.)                                                                                                                           
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 4. For protocol documents, are there existing implementations of the contents of                                                                                   
>    the document? Have a significant number of potential implementers indicated                                                                                     
>    plans to implement? Are any existing implementations reported somewhere,                                                                                         
>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere                                                                                         
>    (where)?                                                                                                                                                         
                                                                                                                                                                     
There are existing implementations of the protocol:                                                                                                                   
                                                                                                                                                                     
- IIT-CNR/Registro.it RDAP Server (https://rdap.pubtest.nic.it/)                                                                                                     
- IIT-CNR/Registro.it RDAP Client (https://web-rdap.pubtest.nic.it/)                                                                                                 
- APNIC server (https://github.com/APNIC-net/rdap-rmp-demo/tree/reverse-search)                                                                                     
                                                                                                                                                                     
The document includes further details on the first two of these in                                                                                                   
section 11 (Implementation Status).                                                                                                                                   
                                                                                                                                                                     
There haven't been any express comments on the list from implementors                                                                                                 
about their plans to implement.  However, it is likely that each of                                                                                                   
the RIRs will implement this protocol at some point, at least.

> ## Additional Reviews                                                                                                                                               
>                                                                                                                                                                     
> 5. Do the contents of this document closely interact with technologies in other                                                                                     
>    IETF working groups or external organizations, and would it therefore benefit                                                                                   
>    from their review? Have those reviews occurred? If yes, describe which                                                                                           
>    reviews took place.                                                                                                                                             
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 6. Describe how the document meets any required formal expert review criteria,                                                                                     
>    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.                                                                                           
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 7. If the document contains a YANG module, has the final version of the module                                                                                     
>    been checked with any of the [recommended validation tools][4] for syntax and                                                                                   
>    formatting validation? If there are any resulting errors or warnings, what is                                                                                   
>    the justification for not fixing them at this time? Does the YANG module                                                                                         
>    comply with the Network Management Datastore Architecture (NMDA) as specified                                                                                   
>    in [RFC 8342][5]?                                                                                                                                               
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 8. Describe reviews and automated checks performed to validate sections of the                                                                                     
>    final version of the document written in a formal language, such as XML code,                                                                                   
>    BNF rules, MIB definitions, CBOR's CDDL, etc.                                                                                                                   
                                                                                                                                                                     
The document contains JSON documents and JSON Path strings.  The JSON                                                                                                 
documents were validated using Perl's JSON::XS.  The JSON Path strings                                                                                               
were validated using http://jsonpath.com, which relies on the JS                                                                                                     
JSONPath Plus library (https://github.com/JSONPath-Plus/JSONPath).

> ## Document Shepherd Checks                                                                                                                                         
>                                                                                                                                                                     
> 9. Based on the shepherd's review of the document, is it their opinion that this                                                                                   
>    document is needed, clearly written, complete, correctly designed, and ready                                                                                     
>    to be handed off to the responsible Area Director?                                                                                                               
                                                                                                                                                                     
Yes.                                                                                                                                                                 
                                                                                                                                                                     
> 10. Several IETF Areas have assembled [lists of common issues that their                                                                                           
>    reviewers encounter][6]. For which areas have such issues been identified                                                                                       
>    and addressed? For which does this still need to happen in subsequent                                                                                           
>    reviews?                                                                                                                                                       
                                                                                                                                                                     
The items mentioned on the ART list on the linked page are not                                                                                                       
relevant to this document.  (Most are relevant to the underlying RDAP                                                                                                 
protocol specifications, though, and are addressed in the appropriate                                                                                                 
core RDAP document as necessary.)                                                                                                                                     
                                                                                                                                                                     
> 11. What type of RFC publication is being requested on the IETF stream ([Best                                                                                       
>    Current Practice][12], [Proposed Standard, Internet Standard][13],                                                                                             
>    [Informational, Experimental or Historic][14])? Why is this the proper type                                                                                     
>    of RFC? Do all Datatracker state attributes correctly reflect this intent?                                                                                     
                                                                                                                                                                     
The type of RFC being requested is Proposed Standard, because the                                                                                                     
document defines extensions to the existing RDAP protocol.  All                                                                                                       
Datatracker state attributes correctly reflect this intent.                                                                                                           
                                                                                                                                                                     
> 12. Have reasonable efforts been made to remind all authors of the intellectual                                                                                     
>    property rights (IPR) disclosure obligations described in [BCP 79][7]? To                                                                                       
>    the best of your knowledge, have all required disclosures been filed? If                                                                                       
>    not, explain why. If yes, summarize any relevant discussion, including links                                                                                   
>    to publicly-available messages when applicable.                                                                                                                 
                                                                                                                                                                     
The document authors have all confirmed they know of no needed                                                                                                       
IPR disclosures.                                                                                                                                                     
                                                                                                                                                                     
> 13. Has each author, editor, and contributor shown their willingness to be                                                                                         
>    listed as such? If the total number of authors and editors on the front page                                                                                   
>    is greater than five, please provide a justification.                                                                                                           
                                                                                                                                                                     
Each author has shown their willingness to be listed as such.

> 14. Document any remaining I-D nits in this document. Simply running the [idnits                                                                                   
>    tool][8] is not enough; please review the ["Content Guidelines" on                                                                                             
>    authors.ietf.org][15]. (Also note that the current idnits tool generates                                                                                       
>    some incorrect warnings; a rewrite is underway.)                                                                                                               
                                                                                                                                                                     
The idnits page is available at                                                                                                                                       
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-22.txt&submissioncheck=True:                       
                                                                                                                                                                     
- "There is 1 instance of lines with non-ascii characters in the                                                                                                     
  document"                                                                                                                                                         
    - The non-ASCII character is in the name 'Gössner', so this is                                                                                                   
      fine.                                                                                                                                                           
                                                                                                                                                                     
- "Looks like a reference, but probably isn't: '1' on line 670"                                                                                                     
    - This comment is the result of the script misinterpreting a JSON                                                                                                 
      Path value.                                                                                                                                                     
                                                                                                                                                                     
The document appears to be fine as against the "Content Guidelines".                                                                                                 
                                                                                                                                                                     
> 15. Should any informative references be normative or vice-versa? See the [IESG                                                                                     
>    Statement on Normative and Informative References][16].

JSON Paths are depended on normatively in the document, but the                                                                                                       
reference for them is to I-D.ietf-jsonpath-base, which is why that                                                                                                   
reference is informative.  (This is in keeping with e.g. RFC 8977,                                                                                                   
though in that case the reference was to the original description of                                                                                                 
the JSON Path behaviour at https://goessner.net/articles/JsonPath/.)

> 16. List any normative references that are not freely available to anyone. Did                                                                                     
>    the community have sufficient access to review any such normative                                                                                               
>    references?                                                                                                                                                     
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 17. Are there any normative downward references (see [RFC 3967][9] and [BCP                                                                                         
>    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,                                                                                     
>    list them.                                                                                                                                                     
                                                                                                                                                                     
N/A (though see the earlier comment about the JSON Path reference in                                                                                                 
this respect).                                                                                                                                                       
                                                                                                                                                                     
> 18. Are there normative references to documents that are not ready to be                                                                                           
>    submitted to the IESG for publication or are otherwise in an unclear state?                                                                                     
>    If so, what is the plan for their completion?                                                                                                                   
                                                                                                                                                                     
N/A (though see the earlier comment about the JSON Path reference in                                                                                                 
this respect).

> 19. Will publication of this document change the status of any existing RFCs? If                                                                                   
>    so, does the Datatracker metadata correctly reflect this and are those RFCs                                                                                     
>    listed on the title page, in the abstract, and discussed in the                                                                                                 
>    introduction? If not, explain why and point to the part of the document                                                                                         
>    where the relationship of this document to these other RFCs is discussed.                                                                                       
                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 20. Describe the document shepherd's review of the IANA considerations section,                                                                                     
>    especially with regard to its consistency with the body of the document.                                                                                       
>    Confirm that all aspects of the document requiring IANA assignments are                                                                                         
>    associated with the appropriate reservations in IANA registries. Confirm                                                                                       
>    that any referenced IANA registries have been clearly identified. Confirm                                                                                       
>    that each newly created IANA registry specifies its initial contents,                                                                                           
>    allocations procedures, and a reasonable name (see [RFC 8126][11]).                                                                                             
                                                                                                                                                                     
The IANA considerations section includes registration of a new RDAP                                                                                                   
extension, as well as creation of two new registries for RDAP reverse                                                                                                 
searches.  Each of the above checks appears to be fine.                                                                                                               
                                                                                                                                                                     
> 21. List any new IANA registries that require Designated Expert Review for                                                                                         
>    future allocations. Are the instructions to the Designated Expert clear?                                                                                       
>    Please include suggestions of designated experts, if appropriate.                                                                                               
                                                                                                                                                                     
The two new registries are "RDAP Reverse Search" and "RDAP Reverse                                                                                                   
Search Mapping", in the "Registration Data Access Protocol (RDAP)"                                                                                                   
group.  The instructions to the designated expert are clear.                                                                                                         
                                                                                                                                                                     
Andy Newton (andy@hxr.us) and Scott Hollenbeck (shollenbeck@verisign.com)
are the designated experts for the existing RDAP IANA registries that
require designated expert review.  Each has agreed to be listed as one
of the designated experts for the new registries defined by this document.

> [1]: https://www.ietf.org/about/groups/iesg/
> [2]: https://www.rfc-editor.org/rfc/rfc4858.html
> [3]: https://www.rfc-editor.org/rfc/rfc7942.html
> [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
> [5]: https://www.rfc-editor.org/rfc/rfc8342.html
> [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
> [7]: https://www.rfc-editor.org/info/bcp79
> [8]: https://www.ietf.org/tools/idnits/
> [9]: https://www.rfc-editor.org/rfc/rfc3967.html
> [10]: https://www.rfc-editor.org/info/bcp97
> [11]: https://www.rfc-editor.org/rfc/rfc8126.html
> [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
> [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
> [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
> [15]: https://authors.ietf.org/en/content-guidelines-overview
> [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> [17]: https://datatracker.ietf.org/doc/downref/
2023-05-02
22 Tom Harrison
> # Document Shepherd Write-Up for Group Documents                                    …
> # Document Shepherd Write-Up for Group Documents                                                                                                                   
>                                                                                                                                                                     
> *This version is dated 4 July 2022.*                                                                                                                               
>                                                                                                                                                                     
> Thank you for your service as a document shepherd. Among the responsibilities is                                                                                   
> answering the questions in this write-up to give helpful context to Last Call                                                                                       
> and Internet Engineering Steering Group ([IESG][1]) reviewers, and your                                                                                             
> diligence in completing it is appreciated. The full role of the shepherd is                                                                                         
> further described in [RFC 4858][2]. You will need the cooperation of the authors                                                                                   
> and editors to complete these checks.                                                                                                                               
>                                                                                                                                                                     
> Note that some numbered items contain multiple related questions; please be sure                                                                                   
> to answer all of them.                                                                                                                                             
>                                                                                                                                                                     
> ## Document History                                                                                                                                                 
>                                                                                                                                                                     
> 1. Does the working group (WG) consensus represent the strong concurrence of a                                                                                     
>    few individuals, with others being silent, or did it reach broad agreement?                                                                                     
                                                                                                                                                                     
It represents the strong concurrence of a few individuals.  However,                                                                                                 
the group within regext that's concerned with RDAP is fairly small,                                                                                                   
and most of them are in favour, so it might also be considered broad                                                                                                 
agreement when taking that into consideration.                                                                                                                       
                                                                                                                                                                     
> 2. Was there controversy about particular points, or were there decisions where                                                                                     
>    the consensus was particularly rough?                                                                                                                           
                                                                                                                                                                     
There was no controversy about any particular points, and there were                                                                                                 
no decisions where the consensus was particularly rough.  (There has                                                                                                 
been a substantial amount of fairly contentious discussion over time                                                                                                 
concerning the privacy considerations section of the document, given                                                                                                 
e.g. laws like the GDPR, but all known issues in this respect have                                                                                                   
been resolved.)

> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If                                                                                   
>    so, please summarize the areas of conflict in separate email messages to the                                                                                     
>    responsible Area Director. (It should be in a separate email because this                                                                                       
>    questionnaire is publicly available.)                                                                                                                           
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 4. For protocol documents, are there existing implementations of the contents of                                                                                   
>    the document? Have a significant number of potential implementers indicated                                                                                     
>    plans to implement? Are any existing implementations reported somewhere,                                                                                         
>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere                                                                                         
>    (where)?                                                                                                                                                         
                                                                                                                                                                     
There are existing implementations of the protocol:                                                                                                                   
                                                                                                                                                                     
- IIT-CNR/Registro.it RDAP Server (https://rdap.pubtest.nic.it/)                                                                                                     
- IIT-CNR/Registro.it RDAP Client (https://web-rdap.pubtest.nic.it/)                                                                                                 
- APNIC server (https://github.com/APNIC-net/rdap-rmp-demo/tree/reverse-search)                                                                                     
                                                                                                                                                                     
The document includes further details on the first two of these in                                                                                                   
section 11 (Implementation Status).                                                                                                                                   
                                                                                                                                                                     
There haven't been any express comments on the list from implementors                                                                                                 
about their plans to implement.  However, it is likely that each of                                                                                                   
the RIRs will implement this protocol at some point, at least.

> ## Additional Reviews                                                                                                                                               
>                                                                                                                                                                     
> 5. Do the contents of this document closely interact with technologies in other                                                                                     
>    IETF working groups or external organizations, and would it therefore benefit                                                                                   
>    from their review? Have those reviews occurred? If yes, describe which                                                                                           
>    reviews took place.                                                                                                                                             
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 6. Describe how the document meets any required formal expert review criteria,                                                                                     
>    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.                                                                                           
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 7. If the document contains a YANG module, has the final version of the module                                                                                     
>    been checked with any of the [recommended validation tools][4] for syntax and                                                                                   
>    formatting validation? If there are any resulting errors or warnings, what is                                                                                   
>    the justification for not fixing them at this time? Does the YANG module                                                                                         
>    comply with the Network Management Datastore Architecture (NMDA) as specified                                                                                   
>    in [RFC 8342][5]?                                                                                                                                               
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 8. Describe reviews and automated checks performed to validate sections of the                                                                                     
>    final version of the document written in a formal language, such as XML code,                                                                                   
>    BNF rules, MIB definitions, CBOR's CDDL, etc.                                                                                                                   
                                                                                                                                                                     
The document contains JSON documents and JSON Path strings.  The JSON                                                                                                 
documents were validated using Perl's JSON::XS.  The JSON Path strings                                                                                               
were validated using http://jsonpath.com, which relies on the JS                                                                                                     
JSONPath Plus library (https://github.com/JSONPath-Plus/JSONPath).

> ## Document Shepherd Checks                                                                                                                                         
>                                                                                                                                                                     
> 9. Based on the shepherd's review of the document, is it their opinion that this                                                                                   
>    document is needed, clearly written, complete, correctly designed, and ready                                                                                     
>    to be handed off to the responsible Area Director?                                                                                                               
                                                                                                                                                                     
Yes.                                                                                                                                                                 
                                                                                                                                                                     
> 10. Several IETF Areas have assembled [lists of common issues that their                                                                                           
>    reviewers encounter][6]. For which areas have such issues been identified                                                                                       
>    and addressed? For which does this still need to happen in subsequent                                                                                           
>    reviews?                                                                                                                                                       
                                                                                                                                                                     
The items mentioned on the ART list on the linked page are not                                                                                                       
relevant to this document.  (Most are relevant to the underlying RDAP                                                                                                 
protocol specifications, though, and are addressed in the appropriate                                                                                                 
core RDAP document as necessary.)                                                                                                                                     
                                                                                                                                                                     
> 11. What type of RFC publication is being requested on the IETF stream ([Best                                                                                       
>    Current Practice][12], [Proposed Standard, Internet Standard][13],                                                                                             
>    [Informational, Experimental or Historic][14])? Why is this the proper type                                                                                     
>    of RFC? Do all Datatracker state attributes correctly reflect this intent?                                                                                     
                                                                                                                                                                     
The type of RFC being requested is Proposed Standard, because the                                                                                                     
document defines extensions to the existing RDAP protocol.  All                                                                                                       
Datatracker state attributes correctly reflect this intent.                                                                                                           
                                                                                                                                                                     
> 12. Have reasonable efforts been made to remind all authors of the intellectual                                                                                     
>    property rights (IPR) disclosure obligations described in [BCP 79][7]? To                                                                                       
>    the best of your knowledge, have all required disclosures been filed? If                                                                                       
>    not, explain why. If yes, summarize any relevant discussion, including links                                                                                   
>    to publicly-available messages when applicable.                                                                                                                 
                                                                                                                                                                     
The document authors have all confirmed they know of no needed                                                                                                       
IPR disclosures.                                                                                                                                                     
                                                                                                                                                                     
> 13. Has each author, editor, and contributor shown their willingness to be                                                                                         
>    listed as such? If the total number of authors and editors on the front page                                                                                   
>    is greater than five, please provide a justification.                                                                                                           
                                                                                                                                                                     
Each author has shown their willingness to be listed as such.

> 14. Document any remaining I-D nits in this document. Simply running the [idnits                                                                                   
>    tool][8] is not enough; please review the ["Content Guidelines" on                                                                                             
>    authors.ietf.org][15]. (Also note that the current idnits tool generates                                                                                       
>    some incorrect warnings; a rewrite is underway.)                                                                                                               
                                                                                                                                                                     
The idnits page is available at                                                                                                                                       
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-22.txt&submissioncheck=True:                       
                                                                                                                                                                     
- "There is 1 instance of lines with non-ascii characters in the                                                                                                     
  document"                                                                                                                                                         
    - The non-ASCII character is in the name 'Gössner', so this is                                                                                                   
      fine.                                                                                                                                                           
                                                                                                                                                                     
- "Looks like a reference, but probably isn't: '1' on line 670"                                                                                                     
    - This comment is the result of the script misinterpreting a JSON                                                                                                 
      Path value.                                                                                                                                                     
                                                                                                                                                                     
The document appears to be fine as against the "Content Guidelines".                                                                                                 
                                                                                                                                                                     
> 15. Should any informative references be normative or vice-versa? See the [IESG                                                                                     
>    Statement on Normative and Informative References][16].

JSON Paths are depended on normatively in the document, but the                                                                                                       
reference for them is to I-D.ietf-jsonpath-base, which is why that                                                                                                   
reference is informative.  (This is in keeping with e.g. RFC 8977,                                                                                                   
though in that case the reference was to the original description of                                                                                                 
the JSON Path behaviour at https://goessner.net/articles/JsonPath/.)

> 16. List any normative references that are not freely available to anyone. Did                                                                                     
>    the community have sufficient access to review any such normative                                                                                               
>    references?                                                                                                                                                     
                                                                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 17. Are there any normative downward references (see [RFC 3967][9] and [BCP                                                                                         
>    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,                                                                                     
>    list them.                                                                                                                                                     
                                                                                                                                                                     
N/A (though see the earlier comment about the JSON Path reference in                                                                                                 
this respect).                                                                                                                                                       
                                                                                                                                                                     
> 18. Are there normative references to documents that are not ready to be                                                                                           
>    submitted to the IESG for publication or are otherwise in an unclear state?                                                                                     
>    If so, what is the plan for their completion?                                                                                                                   
                                                                                                                                                                     
N/A (though see the earlier comment about the JSON Path reference in                                                                                                 
this respect).

> 19. Will publication of this document change the status of any existing RFCs? If                                                                                   
>    so, does the Datatracker metadata correctly reflect this and are those RFCs                                                                                     
>    listed on the title page, in the abstract, and discussed in the                                                                                                 
>    introduction? If not, explain why and point to the part of the document                                                                                         
>    where the relationship of this document to these other RFCs is discussed.                                                                                       
                                                                                                                     
N/A                                                                                                                                                                   
                                                                                                                                                                     
> 20. Describe the document shepherd's review of the IANA considerations section,                                                                                     
>    especially with regard to its consistency with the body of the document.                                                                                       
>    Confirm that all aspects of the document requiring IANA assignments are                                                                                         
>    associated with the appropriate reservations in IANA registries. Confirm                                                                                       
>    that any referenced IANA registries have been clearly identified. Confirm                                                                                       
>    that each newly created IANA registry specifies its initial contents,                                                                                           
>    allocations procedures, and a reasonable name (see [RFC 8126][11]).                                                                                             
                                                                                                                                                                     
The IANA considerations section includes registration of a new RDAP                                                                                                   
extension, as well as creation of two new registries for RDAP reverse                                                                                                 
searches.  Each of the above checks appears to be fine.                                                                                                               
                                                                                                                                                                     
> 21. List any new IANA registries that require Designated Expert Review for                                                                                         
>    future allocations. Are the instructions to the Designated Expert clear?                                                                                       
>    Please include suggestions of designated experts, if appropriate.                                                                                               
                                                                                                                                                                     
The two new registries are "RDAP Reverse Search" and "RDAP Reverse                                                                                                   
Search Mapping", in the "Registration Data Access Protocol (RDAP)"                                                                                                   
group.  The instructions to the designated expert are clear.                                                                                                         
                                                                                                                                                                     
Andy Newton (andy@hxr.us) and Scott Hollenbeck are the designated experts
for the existing RDAP IANA registries that require designated expert review.
Each has agreed to be listed as one of the designated experts for the new
registries defined by this document.

> [1]: https://www.ietf.org/about/groups/iesg/
> [2]: https://www.rfc-editor.org/rfc/rfc4858.html
> [3]: https://www.rfc-editor.org/rfc/rfc7942.html
> [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
> [5]: https://www.rfc-editor.org/rfc/rfc8342.html
> [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
> [7]: https://www.rfc-editor.org/info/bcp79
> [8]: https://www.ietf.org/tools/idnits/
> [9]: https://www.rfc-editor.org/rfc/rfc3967.html
> [10]: https://www.rfc-editor.org/info/bcp97
> [11]: https://www.rfc-editor.org/rfc/rfc8126.html
> [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
> [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
> [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
> [15]: https://authors.ietf.org/en/content-guidelines-overview
> [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> [17]: https://datatracker.ietf.org/doc/downref/
2023-05-02
22 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-22.txt
2023-05-02
22 (System) New version approved
2023-05-02
22 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2023-05-02
22 Mario Loffredo Uploaded new revision
2023-04-17
21 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-21.txt
2023-04-17
21 (System) New version approved
2023-04-17
21 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2023-04-17
21 Mario Loffredo Uploaded new revision
2023-04-17
20 James Galvin Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway set.
2023-04-17
20 James Galvin IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2023-03-20
20 James Galvin Tag Other - see Comment Log cleared.
2023-03-20
20 James Galvin IETF WG state changed to In WG Last Call from WG Document
2023-03-10
20 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-20.txt
2023-03-10
20 (System) New version approved
2023-03-10
20 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2023-03-10
20 Mario Loffredo Uploaded new revision
2023-03-06
19 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-19.txt
2023-03-06
19 (System) New version approved
2023-03-06
19 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2023-03-06
19 Mario Loffredo Uploaded new revision
2023-02-23
18 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-18.txt
2023-02-23
18 (System) New version approved
2023-02-23
18 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2023-02-23
18 Mario Loffredo Uploaded new revision
2022-12-01
17 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-17.txt
2022-12-01
17 (System) New version approved
2022-12-01
17 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2022-12-01
17 Mario Loffredo Uploaded new revision
2022-11-21
16 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-16.txt
2022-11-21
16 (System) New version approved
2022-11-21
16 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2022-11-21
16 Mario Loffredo Uploaded new revision
2022-11-21
15 Antoin Verschuren This document is taken back by the WG because there were still discussions on desirable options after WGLC had formally closed.
2022-11-21
15 Antoin Verschuren IETF WG state changed to WG Document from In WG Last Call
2022-11-14
15 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-15.txt
2022-11-14
15 (System) New version approved
2022-11-14
15 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2022-11-14
15 Mario Loffredo Uploaded new revision
2022-10-03
14 James Galvin Extended WGLC to 3 October 2022
2022-10-03
14 James Galvin WGLC ends 26 September 2022
2022-10-03
14 James Galvin IETF WG state changed to In WG Last Call from WG Document
2022-10-03
14 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-14.txt
2022-10-03
14 (System) New version approved
2022-10-03
14 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2022-10-03
14 Mario Loffredo Uploaded new revision
2022-09-13
13 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-13.txt
2022-09-13
13 (System) New version approved
2022-09-13
13 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2022-09-13
13 Mario Loffredo Uploaded new revision
2022-08-18
12 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-12.txt
2022-08-18
12 (System) New version approved
2022-08-18
12 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2022-08-18
12 Mario Loffredo Uploaded new revision
2022-05-16
11 Antoin Verschuren AS result of WGLC feedback, the authors decided to do a new revision of the draft before issuing a new WGLC.
2022-05-16
11 Antoin Verschuren Tag Other - see Comment Log set.
2022-05-16
11 Antoin Verschuren IETF WG state changed to WG Document from In WG Last Call
2022-05-02
11 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-11.txt
2022-05-02
11 (System) New version approved
2022-05-02
11 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2022-05-02
11 Mario Loffredo Uploaded new revision
2022-04-11
10 James Galvin IETF WG state changed to In WG Last Call from WG Document
2022-04-08
10 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-10.txt
2022-04-08
10 (System) New version accepted (logged-in submitter: Mario Loffredo)
2022-04-08
10 Mario Loffredo Uploaded new revision
2022-02-10
09 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-09.txt
2022-02-10
09 (System) New version approved
2022-02-10
09 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2022-02-10
09 Mario Loffredo Uploaded new revision
2022-01-31
08 James Galvin Notification list changed to tomh@apnic.net because the document shepherd was set
2022-01-31
08 James Galvin Document shepherd changed to Tom Harrison
2021-11-27
08 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-08.txt
2021-11-27
08 (System) New version approved
2021-11-27
08 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2021-11-27
08 Mario Loffredo Uploaded new revision
2021-11-10
07 James Galvin Added to session: IETF-112: regext  Wed-1430
2021-11-05
07 James Galvin Added to session: interim-2021-regext-01
2021-10-05
07 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-07.txt
2021-10-05
07 (System) New version approved
2021-10-05
07 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2021-10-05
07 Mario Loffredo Uploaded new revision
2021-07-26
06 James Galvin Added to session: IETF-111: regext  Wed-1430
2021-04-09
06 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-06.txt
2021-04-09
06 (System) New version approved
2021-04-09
06 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2021-04-09
06 Mario Loffredo Uploaded new revision
2020-10-26
05 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-05.txt
2020-10-26
05 (System) New version approved
2020-10-26
05 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2020-10-26
05 Mario Loffredo Uploaded new revision
2020-07-24
04 James Galvin Added to session: IETF-108: regext  Fri-1100
2020-05-18
04 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-04.txt
2020-05-18
04 (System) New version approved
2020-05-18
04 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2020-05-18
04 Mario Loffredo Uploaded new revision
2020-05-07
03 (System) Document has expired
2019-11-04
03 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-03.txt
2019-11-04
03 (System) New version approved
2019-11-04
03 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2019-11-04
03 Mario Loffredo Uploaded new revision
2019-10-08
02 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-02.txt
2019-10-08
02 (System) New version approved
2019-10-08
02 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2019-10-08
02 Mario Loffredo Uploaded new revision
2019-07-21
01 James Galvin Added to session: IETF-105: regext  Thu-1000
2019-06-21
01 Antoin Verschuren Changed consensus to Yes from Unknown
2019-06-21
01 Antoin Verschuren Intended Status changed to Proposed Standard from None
2019-06-21
01 Antoin Verschuren Working Group adoption
2019-06-21
01 Antoin Verschuren This document now replaces draft-loffredo-regext-rdap-reverse-search instead of None
2019-04-11
01 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-01.txt
2019-04-11
01 (System) New version approved
2019-04-11
01 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2019-04-11
01 Mario Loffredo Uploaded new revision
2019-02-01
00 Mario Loffredo New version available: draft-ietf-regext-rdap-reverse-search-00.txt
2019-02-01
00 (System) New version approved
2019-02-01
00 Mario Loffredo Request for posting confirmation emailed  to submitter and authors: Maurizio Martinelli , Mario Loffredo
2019-02-01
00 Mario Loffredo Uploaded new revision