Section 1, Introduction: "The protocol described in this specification is intended to address deficiencies with the WHOIS protocol [RFC3912] that have been identified over time" "The intent of the patterns described here are to enable queries of: (...) reverse DNS metadata by domain, nameservers by name, registrars by name, and entities (such as contacts) by identifier." Possible requirement: An RDDS must include features that address the deficiencies of WHOIS, including lack of standardized command structures, lack of standardized output and error structures, lack of support for internationalization and localization, and lack of support for user identification, authentication, and access control. Possible requirement: An RDDS must be able to support queries for reverse DNS metadata by domain, name servers by name, registrars by name, and entities (such as contacts) by identifier. Associated charter question(s): System Model: What system requirements must be satisfied by any next-generation RDS implementation? Section 3, Path Segment Specification "The base URLs used to construct RDAP queries are maintained in an IANA registry described in [RFC7484]." Possible requirement: An RDDS must be able to form queries using provider-specific information maintained in an IANA registry. Associated charter question(s): System Model: What system requirements must be satisfied by any next-generation RDS implementation? Section 3.1.6, Help Path Segment Specification "The help path segment can be used to request helpful information (command syntax, terms of service, privacy policy, rate-limiting policy, supported authentication methods, supported extensions, technical support contact, etc.) from an RDAP server." Possible requirement: An RDDS must provide an online help facility that describes how to use the service. Associated charter question(s): System Model: What system requirements must be satisfied by any next-generation RDS implementation? Section 3.2, Search Path Segment Specification "The resource type path segments for search are..." Possible requirement: An RDDS must provide a search facility for domain names, name servers, and entities in addition to a basic lookup facility. Associated charter question(s): System Model: What system requirements must be satisfied by any next-generation RDS implementation? Section 5, Extensibility "This document describes path segment specifications for a limited number of objects commonly registered in both RIRs and DNRs. It does not attempt to describe path segments for all of the objects registered in all registries." Possible requirement: It must be possible to add new features to an RDDS. Associated charter question(s): System Model: What system requirements must be satisfied by any next-generation RDS implementation? Section 6, Internationalization Considerations: "There is value in supporting the ability to submit either a U-label (Unicode form of an IDN label) or an A-label (US-ASCII form of an IDN label) as a query argument to an RDAP service." Possible requirement: An RDDS must support queries using both the A-label and U-label forms of an Internationalized Domain Name label. Possible requirement: An RDDS must be able to return domain name and name server variants in response to IDN queries. Associated charter question(s): System Model: What system requirements must be satisfied by any next-generation RDS implementation? Section 7, Security Considerations "Search functionality typically requires more server resources (such as memory, CPU cycles, and network bandwidth) when compared to basic lookup functionality. This increases the risk of server resource exhaustion and subsequent denial of service due to abuse. This risk can be mitigated by developing and implementing controls to restrict search functionality to identified and authorized clients." Possible requirement: An RDDS must provide features to identify and authorize clients. Associated charter question(s): Gated Access: What steps should be taken to control data access for each user/purpose? "Search functionality also increases the privacy risk of disclosing object relationships that might not otherwise be obvious." Possible requirement: An RDDS must provide features to restrict information returned to clients on a "need to know" basis. Associated charter question(s): Gated Access: What steps should be taken to control data access for each user/purpose? Privacy: What steps are needed to protect data and privacy?