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 |