Skip to main content

Registration Data Access Protocol (RDAP) Partial Response
draft-ietf-regext-rdap-partial-response-16

Revision differences

Document history

Date Rev. By Action
2021-02-03
16 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-02-01
16 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2021-01-07
16 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-01-04
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-01-04
16 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-01-04
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-01-01
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-12-31
16 (System) IANA Action state changed to In Progress from On Hold
2020-12-22
16 (System) RFC Editor state changed to EDIT
2020-12-22
16 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-12-22
16 (System) Announcement was received by RFC Editor
2020-12-21
16 (System) IANA Action state changed to On Hold from In Progress
2020-12-21
16 (System) IANA Action state changed to In Progress
2020-12-21
16 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-12-21
16 Amy Vezza IESG has approved the document
2020-12-21
16 Amy Vezza Closed "Approve" ballot
2020-12-21
16 Amy Vezza Ballot approval text was generated
2020-12-20
16 Barry Leiba IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-09-23
16 (System) New version available: draft-ietf-regext-rdap-partial-response-16.txt
2020-09-23
16 (System) Posted submission manually
2020-09-23
16 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2020-09-23
16 Mario Loffredo Uploaded new revision
2020-09-17
15 Benjamin Kaduk [Ballot comment]
Thanks for addressing my Discuss and Comment points!
2020-09-17
15 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-09-13
15 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-15.txt
2020-09-13
15 (System) New version approved
2020-09-13
15 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2020-09-13
15 Mario Loffredo Uploaded new revision
2020-09-13
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-09-13
14 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-14.txt
2020-09-13
14 (System) New version approved
2020-09-13
14 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2020-09-13
14 Mario Loffredo Uploaded new revision
2020-09-10
13 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2020-09-10
13 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-09-10
13 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-09-10
13 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-09-09
13 Benjamin Kaduk
[Ballot discuss]
As was the case for Murray, I'm unconvinced that I have understood what
Section 3 intended to convey.  However, I am balloting Discuss …
[Ballot discuss]
As was the case for Murray, I'm unconvinced that I have understood what
Section 3 intended to convey.  However, I am balloting Discuss because
my current best understanding is for a statement that seems inconsistent
with my understanding of how the partial response mechanism works.  In
particular, how would the topmost objects be returned according to
different field sets, if there's only a single query parameter and (I
assume) all topmost objects are the results of the same single query?
2020-09-09
13 Benjamin Kaduk
[Ballot comment]
Thanks to the shepherd for noting that the examples have been through
JSONLint!

Abstract

  The Registration Data Access Protocol (RDAP) does not …
[Ballot comment]
Thanks to the shepherd for noting that the examples have been through
JSONLint!

Abstract

  The Registration Data Access Protocol (RDAP) does not include
  capabilities to request partial responses.  Servers will only return
  full responses that include all of the information that a client is
  authorized to receive.  A partial response capability that limits the

[There is perhaps some stylistic question of whether to describe the
present state in the present tense vs. saying something like "prior to
the mechanism defined in this document" or "as specified in [RFC7483".]

Section 1

  Currently, RDAP does not provide a client with any way to request a
  partial response.  Servers can only provide the client with a full

nit: will this age well?

Section 2

  The path segment defined in this section is an OPTIONAL extension of
  search path segments defined in [RFC7482].  This document defines an

It's not entirely clear to me in what sense it's accurate to say that
this section "defines" a path segment.  (Perhaps RDAP path segments
diverge from normal HTTP and generic URI path segments in this sense?)
My current understanding is that we are defining an optional query
parameter in the purest URI sense, which does not require a new path
segment in the URI sense.

  full response (Figure 1).  The field sets supported by a server are
  usually described in out-of-band documents (e.g.  RDAP profile)

nit: comma (and only one space) after "e.g.".

Section 2.1

  responses about the available field sets.  Such information is
  collected in a new data structure named "subsetting_metadata"
  containing the following properties:

I assume this is a JSON datastructure, specifically?

  o  "availableFieldSets": "AvailableFieldSet[]" (OPTIONAL) an array of
      objects, with each element describing an available field set.
      Members are:

      *  "name": "String" (REQUIRED) the field set name;
      *  "default": "Boolean" (REQUIRED) whether the field set is
        applied by default;

Is it allowed to have more than one entry in the array set
"default":true?

      *  "links": "Link[]" (OPTIONAL) an array of links as described in
        [RFC8288] containing the query string that applies the field
        set.

I suggest giving an example or a bit more detail as to exactly what
structure/format is expected here; 8288 has a fair bit of meat to it.
Ah, but this is covered in Section 2.1.2, so maybe just a
forward-reference is enough.  It would be good (either here or there) to
give some indication as to which of "value"/"rel"/"href"/"title"/"type"
are required/optional, though.

Section 4

  o  "id": the server provides only the key field: "handle" for
      entities, "ldhName" for domains and nameservers.  If a returned
      domain or nameserver is an Internationalized Domain Name (IDN)
      [RFC5890], then the "unicodeName" field MUST be included in the

nit: I suggest "also" or "additionally be included".

  The "objectClassName" field is implicitly included in each of the
  above field sets.  RDAP providers SHOULD include a "self" link in
  each field set.  RDAP providers MAY also add any property providing
  service information.

Just to check my understanding: the "property" that might also be added
here is a "field" that would be included in a given field set and
corresponding query response?  (I don't know if "property" has
RDAP-specific connotations that make it a better word to use here.)

(nit?) I'm also not entirely sure that 'include a "self" link in each
field set' is pedantically correct, as opposed to 'include a "links"
field indicating the "self" link relationship'.

Section 8

I suppose it's always possible that by using a narrow field set a client
would not get back some important piece of information, e.g., a modifier
that restricts the scope of applicability of some information.  It seems
fairly obvious that the onus for knowing what fields are possible and
avoiding this scenario falls on the client, though perhaps it is worth
also giving some guidance to the server to take this into consideration
while defining field sets.

  Servers can also define different result limits according to the
  available field sets, so a more flexible truncation strategy can be

I'm not entirely sure I am understanding this correctly -- is it just
saying (roughly) "when using the 'id' field set it's safe to use much
larger page size than for the 'full' field set"?  (I didn't find a
specific definition of "result limits" in RFCs 7482 or 7483.)

  implemented.  The new query parameter presented in this document
  provides RDAP operators with a way to implement a server that reduces
  inefficiency risks.

Perhaps it's worth mentioning that in the face of unupdated clients
these potential gains are not actually realized.

Section 9.1

The one place we cite RFC 7481 does not seem to itself be a normative
usage (though I can imagine that one does need to read it in order to
build a complete system).

Appendix A

  Looking at the implementation experiences of partial response, two
  approaches are observed:

Looking at context from later in the suggestion suggests that this
survey was not restricted to RDAP partial response, which might be worth
mentioning.

  o  The request of some fields might not match the client's access and
      authorization levels.  Clients might request unauthorized fields
      and servers should define a strategy for responding, such as
      always returning an error response or returning a response that

nit: I think this is more of "servers have to" than "servers should"
(even though this strategy might just be "do whatever the existing code
happens to do").

Appendix A.1

  o  Relevant entity object information is included in a jCard, but
      such information cannot be easily selected because it is split
      into the items of a jagged array;

nit: I didn't find "jagged array" used in either RFC 7483 or RFC 7095;
is is relationship to jCard specified somewhere else?

  The latter approach seems to facilitate RDAP interoperability.
  Servers can define basic field sets which, if known to clients, can
  increase the probability of obtaining a valid response.  The usage of

nit: the "latter approach" seems to be an artifact of some text moves,
as there isn't a recent comparison of two approaches in this section.
("Latter approach" also appears in the following paragraph.)
2020-09-09
13 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-09-09
13 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-09-07
13 Murray Kucherawy
[Ballot comment]
Where is "AvailableFieldSet[]" defined?

I get a Permission Denied error when I click on the link for [REST].  Should it be updated?

I …
[Ballot comment]
Where is "AvailableFieldSet[]" defined?

I get a Permission Denied error when I click on the link for [REST].  Should it be updated?

I have the same question Roman does about Section 2.1.

I've tried several times, but I can't understand what Section 3 is trying to tell me.
2020-09-07
13 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-09-07
13 Robert Wilton
[Ballot comment]
Hi,

Thank you for this document.  I have two minor comments:

2.1.2.  Representing Subsetting Links

          "value": "https://example.com/rdap/domains?name=*nr.com …
[Ballot comment]
Hi,

Thank you for this document.  I have two minor comments:

2.1.2.  Representing Subsetting Links

          "value": "https://example.com/rdap/domains?name=*nr.com
                    &fieldSet=afieldset",

Should "afieldset" be "anotherfieldset"?


5.  Negative Answers

  Each request including an empty or unsupported "fieldSet" value MUST
  produce an HTTP 400 (Bad Request) response code.  Optionally, the
  response MAY include additional information regarding the negative
  answer in the HTTP entity body.

Given the solution suggests that subsetting metadata may be included in positive responses, it might be helpful to also include similar metadata in negative responses.  I.e. rather than just stating that a fieldSet is invalid, perhaps there should be a recommendation that the response include the list of possible valid values that fieldSet may take?

Regards,
Rob
2020-09-07
13 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-09-06
13 Erik Kline [Ballot Position Update] Position for Erik Kline has been changed to No Objection from Discuss
2020-09-05
13 Erik Kline
[Ballot discuss]
Probably I'm just not properly aware of details in the referenced RFCs, but
I had a few questions that came to mind.

[ …
[Ballot discuss]
Probably I'm just not properly aware of details in the referenced RFCs, but
I had a few questions that came to mind.

[ section 2 ]

* How are multiple keys encoded in a fieldSet parameter value?  An example
  would be welcome.

* What should be done with a query containing an empty fieldSet?
  E.g. ...?...&foo=bar&fieldSet=&baaz=quux

[ section 2.1 ]

* How much data transfer is actually saved if servers are supposed to send
  these subsetting_metadata structures in every response?  Are we just
  swapping data bytes transferred for meta-data bytes transfered?
2020-09-05
13 Erik Kline [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline
2020-09-04
13 Roman Danyliw
[Ballot comment]
** Section 2.1.  Can a server return multiple entries in the availableFieldSets area with default=TRUE?  Probably not.  Should something be said to that …
[Ballot comment]
** Section 2.1.  Can a server return multiple entries in the availableFieldSets area with default=TRUE?  Probably not.  Should something be said to that effect?

** Section 4.  Per ‘Fields included in the "brief" and "full" field set responses MUST take into account the user's access and authorization levels’, would there be circumstances where the “id” field set should also take into account the user’s access and authorization level?  Section 8 noted that “RDAP operators can vary the information returned in RDAP responses based on a client's access and authorization levels.”  My thinking is that if a given client’s access level would result in particular fields being removed, then perhaps they shouldn’t have been listed in the with the “id” field list to begin with.

** Section 8.

A search query typically requires more server resources (such as
  memory, CPU cycles, and network bandwidth) when compared to a lookup
  query.  This increases the risk of server resource exhaustion and
  subsequent denial of service due to abuse.  This risk can be
  mitigated by supporting the return of partial responses combined with
  other strategies ...

I do not follow how partial responses provide denial of service mitigation when the attack is intentional.  Wouldn’t the attacker continue to request full queries given the choice between loading the server with a subset vs. full query?  Or is this text saying that because of the use of partial responses the server would have more capacity and this would enable it to better result a denial service?

** Editorial:
-- Section 1.  Editorial.  s/fewer data/less data/
2020-09-04
13 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-09-04
13 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. It is simple to read and appears to address an important problem.

I have …
[Ballot comment]
Thank you for the work put into this document. It is simple to read and appears to address an important problem.

I have only one non blocking comment about section 4, is a "short" response specified in other documents or should it be better described in this document ?

Regards

-éric
2020-09-04
13 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-09-03
13 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-09-01
13 Cindy Morgan Placed on agenda for telechat - 2020-09-10
2020-09-01
13 Barry Leiba Ballot has been issued
2020-09-01
13 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2020-09-01
13 Barry Leiba Created "Approve" ballot
2020-09-01
13 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2020-08-22
13 Joseph Salowey Request for Last Call review by SECDIR Completed: Ready. Reviewer: Joseph Salowey. Sent review to list.
2020-08-15
13 Joel Jaeggli Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Joel Jaeggli. Sent review to list.
2020-08-14
13 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2020-08-13
13 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2020-08-13
13 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-rdap-partial-response-12. 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-partial-response-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the RDAP Extensions registry located at:

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

a single new registration is to be made as follows:

Extension identifier: subsetting
Registry operator: Any
Published specification: [ RFC-to-be ]
Contact: IETF
Intended usage: This extension describes best practice for partial response provisioning.

We understand that the expert review for this registration has been completed.

The IANA Functions Operator understands that this is the only action 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.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-08-06
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Joseph Salowey
2020-08-06
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Joseph Salowey
2020-08-04
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2020-08-04
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2020-07-29
13 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-13.txt
2020-07-29
13 (System) New version approved
2020-07-29
13 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2020-07-29
13 Mario Loffredo Uploaded new revision
2020-07-24
12 David Schinazi Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: David Schinazi. Sent review to list.
2020-07-24
12 Jean Mahoney Request for Last Call review by GENART is assigned to David Schinazi
2020-07-24
12 Jean Mahoney Request for Last Call review by GENART is assigned to David Schinazi
2020-07-24
12 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-07-24
12 Amy Vezza
The following Last Call announcement was sent out (ends 2020-08-14):

From: The IESG
To: IETF-Announce
CC: Jasdip Singh , jasdips@arin.net, regext@ietf.org, draft-ietf-regext-rdap-partial-response@ietf.org, …
The following Last Call announcement was sent out (ends 2020-08-14):

From: The IESG
To: IETF-Announce
CC: Jasdip Singh , jasdips@arin.net, regext@ietf.org, draft-ietf-regext-rdap-partial-response@ietf.org, regext-chairs@ietf.org, barryleiba@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Registration Data Access Protocol (RDAP) Partial Response) 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) Partial Response'
  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 2020-08-14. 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
  capabilities to request partial responses.  Servers will only return
  full responses that include all of the information that a client is
  authorized to receive.  A partial response capability that limits the
  amount of information returned, especially in the case of search
  queries, could bring benefits to both clients and servers.  This
  document describes an RDAP query extension that allows clients to
  specify their preference for obtaining a partial response.




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



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




2020-07-24
12 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-07-24
12 Amy Vezza Last call announcement was changed
2020-07-24
12 Barry Leiba Last call was requested
2020-07-24
12 Barry Leiba Last call announcement was generated
2020-07-24
12 Barry Leiba Ballot approval text was generated
2020-07-24
12 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation
2020-07-24
12 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2020-06-26
12 James Galvin
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standards Track since it will eventually become part of a Standards Track set of RDAP RFCs. Yes, the draft has “Intended status: Standards Track” in its header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The Registration Data Access Protocol (RDAP) does not include capabilities to request partial responses.  In fact, according to the user authorization, the server can only return full responses.  A partial response capability, especially in the case of search queries, could bring benefits to both clients and servers.  This document describes an RDAP query extension that allows clients to specify their preference for obtaining a partial response.

Working Group Summary:

There was some constructive feedback but nothing controversial. The authors have addressed the feedback in the latest draft.

Document Quality:

The document quality is high. Both IIT-CNR/Registro.it and APNIC have implemented this draft.

Personnel:

Document Shepherd: Jasdip Singh (jasdips@arin.net)
Area Director: Barry Leiba (barryleiba@gmail.com)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document explains well the problem it is trying to solve. It then refers to the current state-of-the-art for partial responses and proceeds to map a well-reasoned partial response solution for RDAP search query results. The normative and informative references in the end are helpful.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. The document already accounts for internationalized domain names in partial responses.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

N/A

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Sufficient consensus. The latter. There was constructive feedback but no disagreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document leverages web links (RFC 8288).

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requests that an entry be added to the IANA RDAP Extensions Registry for the new 'subsetting' extension identifier. The request is consistent with the use of this value in the document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The truncated examples in Figures 2 and 3 are written in JSON. They were verified using JSONLint (jsonlint.com).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

N/A
2020-06-26
12 James Galvin IETF WG state changed to Submitted to IESG for Publication from WG Document
2020-06-26
12 James Galvin IESG state changed to Publication Requested from AD is watching
2020-06-17
12 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-12.txt
2020-06-17
12 (System) New version approved
2020-06-17
12 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2020-06-17
12 Mario Loffredo Uploaded new revision
2020-05-29
11 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-11.txt
2020-05-29
11 (System) New version approved
2020-05-29
11 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2020-05-29
11 Mario Loffredo Uploaded new revision
2020-05-25
10 Barry Leiba IETF WG state changed to WG Document from Submitted to IESG for Publication
2020-05-25
10 Barry Leiba IESG state changed to AD is watching from AD Evaluation
2020-05-15
10 Barry Leiba Ballot writeup was changed
2020-05-15
10 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2020-05-15
10 James Galvin
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standards Track since it will eventually become part of a Standards Track set of RDAP RFCs. Yes, the draft has “Intended status: Standards Track” in its header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The Registration Data Access Protocol (RDAP) does not include capabilities to request partial responses.  In fact, according to the user authorization, the server can only return full responses.  A partial response capability, especially in the case of search queries, could bring benefits to both clients and servers.  This document describes an RDAP query extension that allows clients to specify their preference for obtaining a partial response.

Working Group Summary:

There was some constructive feedback but nothing controversial. The authors have addressed the feedback in the latest draft.

Document Quality:

The document quality is high. Both IIT-CNR/Registro.it and APNIC have implemented this draft.

Personnel:

Document Shepherd: Jasdip Singh (jasdips@arin.net)
Area Director: Barry Leiba (barryleiba@gmail.com)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document explains well the problem it is trying to solve. It then refers to the current state-of-the-art for partial responses and proceeds to map a well-reasoned partial response solution for RDAP search query results. The normative and informative references in the end are helpful.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. The document already accounts for internationalized domain names in partial responses.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

N/A

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Sufficient consensus. The latter. There was constructive feedback but no disagreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document leverages web links (RFC 8288).

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requests that an entry be added to the IANA RDAP Extensions Registry for the new 'subsetting' extension identifier. The request is consistent with the use of this value in the document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The truncated examples in Figures 2 and 3 are written in JSON. They were verified using JSONLint (jsonlint.com).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

N/A
2020-05-15
10 James Galvin Responsible AD changed to Barry Leiba
2020-05-15
10 James Galvin IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-05-15
10 James Galvin IESG state changed to Publication Requested from I-D Exists
2020-05-15
10 James Galvin IESG process started in state Publication Requested
2020-05-08
10 Jasdip Singh
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standards Track since it will eventually become part of a Standards Track set of RDAP RFCs. Yes, the draft has “Intended status: Standards Track” in its header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The Registration Data Access Protocol (RDAP) does not include capabilities to request partial responses.  In fact, according to the user authorization, the server can only return full responses.  A partial response capability, especially in the case of search queries, could bring benefits to both clients and servers.  This document describes an RDAP query extension that allows clients to specify their preference for obtaining a partial response.

Working Group Summary:

There was some constructive feedback but nothing controversial. The authors have addressed the feedback in the latest draft.

Document Quality:

The document quality is high. Both IIT-CNR/Registro.it and APNIC have implemented this draft.

Personnel:

Document Shepherd: Jasdip Singh (jasdips@arin.net)
Area Director: Barry Leiba (barryleiba@gmail.com)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document explains well the problem it is trying to solve. It then refers to the current state-of-the-art for partial responses and proceeds to map a well-reasoned partial response solution for RDAP search query results. The normative and informative references in the end are helpful.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. The document already accounts for internationalized domain names in partial responses.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

N/A

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Sufficient consensus. The latter. There was constructive feedback but no disagreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document leverages web links (RFC 8288).

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requests that an entry be added to the IANA RDAP Extensions Registry for the new 'subsetting' extension identifier. The request is consistent with the use of this value in the document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The truncated examples in Figures 2 and 3 are written in JSON. They were verified using JSONLint (jsonlint.com).

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

N/A
2020-04-28
10 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-10.txt
2020-04-28
10 (System) New version approved
2020-04-28
10 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2020-04-28
10 Mario Loffredo Uploaded new revision
2020-04-17
09 James Galvin IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2020-04-14
09 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-09.txt
2020-04-14
09 (System) New version approved
2020-04-14
09 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2020-04-14
09 Mario Loffredo Uploaded new revision
2020-04-14
08 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-08.txt
2020-04-14
08 (System) New version approved
2020-04-14
08 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2020-04-14
08 Mario Loffredo Uploaded new revision
2020-04-10
07 Jasdip Singh
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standards Track since it will eventually become part of a Standards Track set of RDAP RFCs. Yes, the draft has “Intended status: Standards Track” in its header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The Registration Data Access Protocol (RDAP) does not include capabilities to request partial responses.  In fact, according to the user authorization, the server can only return full responses.  A partial response capability, especially in the case of search queries, could bring benefits to both clients and servers.  This document describes an RDAP query extension that allows clients to specify their preference for obtaining a partial response.

Working Group Summary:

There was some constructive feedback but nothing controversial. The authors have addressed the feedback in the latest draft.

Document Quality:

The document quality is high. Both IIT-CNR/Registro.it and APNIC have implemented this draft.

Personnel:

Document Shepherd: Jasdip Singh (jasdips@arin.net)
Area Director: Barry Leiba (barryleiba@gmail.com)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document explains well the problem it is trying to solve. It then refers to the current state-of-the-art for partial responses and proceeds to map a well-reasoned partial response solution for RDAP search query results. The normative and informative references in the end are helpful.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. The document already accounts for internationalized domain names in partial responses.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

N/A

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Sufficient consensus. The latter. There was constructive feedback but no disagreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document leverages web links (RFC 8288).

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document intends to register with IANA a new RDAP extension called subsetting.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The new subsetting RDAP extension should be reviewed by the experts listed in https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The truncated examples employ correct JSON.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

N/A
2020-04-10
07 Jasdip Singh
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standards Track since it will eventually become part of a Standards Track set of RDAP RFCs. Yes, the draft has “Intended status: Standards Track” in its header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The Registration Data Access Protocol (RDAP) does not include capabilities to request partial responses.  In fact, according to the user authorization, the server can only return full responses.  A partial response capability, especially in the case of search queries, could bring benefits to both clients and servers.  This document describes an RDAP query extension that allows clients to specify their preference for obtaining a partial response.

Working Group Summary:

There was some constructive feedback but nothing controversial. The authors have addressed the feedback in the latest draft.

Document Quality:

The document quality is high. Both IIT-CNR/Registro.it and APNIC have implemented this draft.

Personnel:

Document Shepherd: Jasdip Singh (jasdips@arin.net)
Area Director: Barry Leiba (barryleiba@gmail.com)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document explains well the problem it is trying to solve. It then refers to the current state-of-the-art for partial responses and proceeds to map a well-reasoned partial response solution for RDAP search query results. The normative and informative references in the end are helpful.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. The document already accounts for internationalized domain names in partial responses.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

N/A

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was constructive feedback but no disagreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document leverages web links (RFC 8288).

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document intends to register with IANA a new RDAP extension called subsetting.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The new subsetting RDAP extension should be reviewed by the experts listed in https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The truncated examples employ correct JSON.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

N/A
2020-04-10
07 Jasdip Singh
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standards Track since it will eventually become part of a Standards Track set of RDAP RFCs. Yes, the draft has “Intended status: Standards Track” in its header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The Registration Data Access Protocol (RDAP) does not include capabilities to request partial responses.  In fact, according to the user authorization, the server can only return full responses.  A partial response capability, especially in the case of search queries, could bring benefits to both clients and servers.  This document describes an RDAP query extension that allows clients to specify their preference for obtaining a partial response.

Working Group Summary:

There was some constructive feedback but nothing controversial. The authors have addressed the feedback in the latest draft.

Document Quality:

The document quality is high. Both IIT-CNR/Registro.it and APNIC have implemented this draft.

Personnel:

Document Shepherd: Jasdip Singh (jasdips@arin.net)
Area Director: Barry Leiba (barryleiba@gmail.com)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document explains well the problem it is trying to solve. It then refers to the current state-of-the-art for partial responses and proceeds to map a well-reasoned partial response solution for RDAP search query results. The normative and informative references in the end are helpful.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. The document already accounts for internationalized domain names in partial responses.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

N/A

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was minimal feedback but no disagreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document leverages web links (RFC 8288).

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document intends to register with IANA a new RDAP extension called subsetting.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The new subsetting RDAP extension should be reviewed by the experts listed in https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The truncated examples employ correct JSON.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

N/A
2020-04-03
07 Antoin Verschuren Notification list changed to Jasdip Singh <jasdips@arin.net> from Tom Harrison <tomh@apnic.net>, Jasdip Singh <jasdips@arin.net>
2020-04-03
07 Antoin Verschuren Notification list changed to Tom Harrison <tomh@apnic.net>, Jasdip Singh <jasdips@arin.net> from Tom Harrison <tomh@apnic.net>
2020-04-03
07 Antoin Verschuren Document shepherd changed to Jasdip Singh
2020-03-27
07 James Galvin Document shepherd changed to (None)
2020-03-13
07 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-07.txt
2020-03-13
07 (System) New version approved
2020-03-13
07 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2020-03-13
07 Mario Loffredo Uploaded new revision
2020-03-13
06 Antoin Verschuren Notification list changed to Tom Harrison <tomh@apnic.net>
2020-03-13
06 Antoin Verschuren Document shepherd changed to Tom Harrison
2020-03-06
06 James Galvin IETF WG state changed to In WG Last Call from WG Document
2020-03-03
06 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-06.txt
2020-03-03
06 (System) New version approved
2020-03-03
06 (System) Request for posting confirmation emailed to previous authors: Mario Loffredo , Maurizio Martinelli
2020-03-03
06 Mario Loffredo Uploaded new revision
2020-02-11
05 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-05.txt
2020-02-11
05 (System) New version approved
2020-02-11
05 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2020-02-11
05 Mario Loffredo Uploaded new revision
2019-09-02
04 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-04.txt
2019-09-02
04 (System) New version approved
2019-09-02
04 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2019-09-02
04 Mario Loffredo Uploaded new revision
2019-07-31
03 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-03.txt
2019-07-31
03 (System) New version approved
2019-07-31
03 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2019-07-31
03 Mario Loffredo Uploaded new revision
2019-07-21
02 James Galvin Added to session: IETF-105: regext  Thu-1000
2019-06-21
02 Antoin Verschuren Changed consensus to Yes from Unknown
2019-06-21
02 Antoin Verschuren Intended Status changed to Proposed Standard from None
2019-06-21
02 Antoin Verschuren Working Group adoption
2019-06-21
02 Antoin Verschuren This document now replaces draft-loffredo-regext-rdap-partial-response instead of None
2019-05-27
02 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-02.txt
2019-05-27
02 (System) New version approved
2019-05-27
02 (System) Request for posting confirmation emailed to previous authors: Maurizio Martinelli , Mario Loffredo
2019-05-27
02 Mario Loffredo Uploaded new revision
2019-04-11
01 Mario Loffredo New version available: draft-ietf-regext-rdap-partial-response-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-partial-response-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