Registration Data Access Protocol (RDAP) Object Tagging
draft-ietf-regext-rdap-object-tag-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-11-13
|
05 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-11-12
|
05 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-11-05
|
05 | James Galvin | Added to session: IETF-103: regext Tue-1350 |
2018-11-01
|
05 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-11-01
|
05 | (System) | RFC Editor state changed to RFC-EDITOR from IANA |
2018-11-01
|
05 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2018-11-01
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-10-31
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-10-03
|
05 | Adam Roach | Sent query to IANA about status of IANA actions on October 3rd |
2018-09-18
|
05 | (System) | RFC Editor state changed to IANA from RFC-EDITOR |
2018-09-11
|
05 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-08-31
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-08-28
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-08-28
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-08-27
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-08-17
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-08-13
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-08-10
|
05 | (System) | RFC Editor state changed to EDIT |
2018-08-10
|
05 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-08-10
|
05 | (System) | Announcement was received by RFC Editor |
2018-08-10
|
05 | (System) | IANA Action state changed to In Progress |
2018-08-10
|
05 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-08-10
|
05 | Cindy Morgan | IESG has approved the document |
2018-08-10
|
05 | Cindy Morgan | Closed "Approve" ballot |
2018-08-10
|
05 | Cindy Morgan | Ballot approval text was generated |
2018-08-10
|
05 | Adam Roach | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-08-03
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-08-03
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-08-03
|
05 | Scott Hollenbeck | New version available: draft-ietf-regext-rdap-object-tag-05.txt |
2018-08-03
|
05 | (System) | New version approved |
2018-08-03
|
05 | (System) | Request for posting confirmation emailed to previous authors: Andrew Newton , Scott Hollenbeck |
2018-08-03
|
05 | Scott Hollenbeck | Uploaded new revision |
2018-08-02
|
04 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-08-02
|
04 | Alexey Melnikov | [Ballot comment] This is a fine document, but I have one possible issue that I would like to quickly discuss before recommending approval of this … [Ballot comment] This is a fine document, but I have one possible issue that I would like to quickly discuss before recommending approval of this document: Looking at the example in Section 3: { "version": "1.0", "publication": "YYYY-MM-DDTHH:MM:SSZ", "description": "RDAP service provider bootstrap values", "services": [ [ ["YYYY"], Values like YYYY are not distinguishable from TLD values registered in . All numeric values (ASNs or ranges of ASNs), as well as IPv4/IPv6 addresses are syntactically distinguishable from TLDs, but values registered in this document are not. Is this a problem? My concern is about fetching JSON from and misinterpreting it as valid data from the registry established in this document or vice versa. [ "https://example.com/rdap/" ] ], [ ["ZZ54"], [ "http://rdap.example.org/" ] ], [ ["1754"], [ "https://example.net/rdap/", "http://example.net/rdap/" ] ] ] } |
2018-08-02
|
04 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2018-08-02
|
04 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-08-01
|
04 | Taylor Yu | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Taylor Yu. |
2018-08-01
|
04 | Ben Campbell | [Ballot comment] I'm also a little surprised to see this as a BCP. It seems to define at least a bit of protocol as part … [Ballot comment] I'm also a little surprised to see this as a BCP. It seems to define at least a bit of protocol as part of the "practice". §3.1: Does the FCFS registration policy allow a potential for squatting or other malicious behavior? |
2018-08-01
|
04 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-08-01
|
04 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-07-31
|
04 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-07-31
|
04 | Alissa Cooper | [Ballot comment] I'm not sure why anyone would do this, but I'll ask anyway: is there no concern about someone maliciously registering an identifier against … [Ballot comment] I'm not sure why anyone would do this, but I'll ask anyway: is there no concern about someone maliciously registering an identifier against an existing RDAP URL, given that the registry is specified to be FCFS? Let's say I have a grudge against MyLocalRIR and I go register "fubar" as the service provider name together with an existing mylocalrir.org RDAP URL. This maybe has little practical effect but surely MyLocalRIR would not be too happy with it. |
2018-07-31
|
04 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-07-30
|
04 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-07-30
|
04 | Warren Kumari | [Ballot comment] Thank you for writing this - it solves a useful purpose, and is clear and easy to read. I had 2 comments / … [Ballot comment] Thank you for writing this - it solves a useful purpose, and is clear and easy to read. I had 2 comments / questions - please also see Tim Chown'sOpsDir review for a useful nit. Section 2. Object Naming Practice The entire 'HYPHEN-MINUS' selection makes me slightly twitchy - the argument that it was chosen because it is commonly already used as a separator feels like it cuts both ways - the fact that 'Handles can themselves contain HYPHEN-MINUS characters' already seems to argue that a different separator should have been chosen to minimize the chance of collisions / people getting this wrong. I get that the document says "the service provider identifier is found following the last HYPHEN-MINUS character in the tagged identifier", and would feel more comfortable if some of the examples contained more than one hyphen to make this clearer. Section 7. Security Considerations 'The transport used to access the IANA registries can be more secure by using TLS [RFC5246], which IANA supports.' I'm confused by this sentence in the Security Considerations section - more secure than what, not using TLS? Why isn't this something like "The transport used to access the IANA registries SHOULD (or MUST) be over TLS"? |
2018-07-30
|
04 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2018-07-30
|
04 | Warren Kumari | [Ballot comment] Thank you for writing this - it solves a useful purpose, and is clear and easy to read. I had 2 comments / … [Ballot comment] Thank you for writing this - it solves a useful purpose, and is clear and easy to read. I had 2 comments / questions. Section 2. Object Naming Practice The entire 'HYPHEN-MINUS' selection makes me slightly twitchy - the argument that it was chosen because it is commonly already used as a separator feels like it cuts both ways - the fact that 'Handles can themselves contain HYPHEN-MINUS characters' already seems to argue that a different separator should have been chosen to minimize the chance of collisions / people getting this wrong. I get that the document says "the service provider identifier is found following the last HYPHEN-MINUS character in the tagged identifier", and would feel more comfortable if some of the examples contained more than one hyphen to make this clearer. Section 7. Security Considerations 'The transport used to access the IANA registries can be more secure by using TLS [RFC5246], which IANA supports.' I'm confused by this sentence in the Security Considerations section - more secure than what, not using TLS? Why isn't this something like "The transport used to access the IANA registries SHOULD (or MUST) be over TLS"? |
2018-07-30
|
04 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-07-29
|
04 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-07-29
|
04 | Alexey Melnikov | [Ballot discuss] This is a fine document, but I have one possible issue that I would like to quickly discuss before recommending approval of this … [Ballot discuss] This is a fine document, but I have one possible issue that I would like to quickly discuss before recommending approval of this document: Looking at the example in Section 3: { "version": "1.0", "publication": "YYYY-MM-DDTHH:MM:SSZ", "description": "RDAP service provider bootstrap values", "services": [ [ ["YYYY"], Values like YYYY are not distinguishable from TLD values registered in . All numeric values (ASNs or ranges of ASNs), as well as IPv4/IPv6 addresses are syntactically distinguishable from TLDs, but values registered in this document are not. Is this a problem? My concern is about fetching JSON from and misinterpreting it as valid data from the registry established in this document or vice versa. [ "https://example.com/rdap/" ] ], [ ["ZZ54"], [ "http://rdap.example.org/" ] ], [ ["1754"], [ "https://example.net/rdap/", "http://example.net/rdap/" ] ] ] } |
2018-07-29
|
04 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov |
2018-07-27
|
04 | Benjamin Kaduk | [Ballot comment] I was a little surprised to see that this document targets BCP status, not Proposed Standard. Was there much discussion of this question … [Ballot comment] I was a little surprised to see that this document targets BCP status, not Proposed Standard. Was there much discussion of this question in the WG? Section 2 Service provider tags are concatenated to the end of RDAP query object identifiers to unambiguously identify the authoritative server It seems like it is the combination of concatenation of the service provider tag, and the use of the rdap_objectTag_level_0 rdapConformance attribute that provides the unambiguous property; I would like to see this caveat made more clear here. Also, per https://www.iab.org/2016/11/07/iab-statement-on-ipv6/, please consider using IPv6 addresses in the examples. Section 5.1 Are all provided URLs supposed to be functionally different? If not, how do we tell which ones do what? Section 7 Perhaps note that it is using IANA as a well-known central trusted authority in order to provide the property of allowing users to get RDAP data from an authoritative source? [...] The method has the same security properties as the RDAP protocols themselves. The transport used to access the IANA registries can be more secure by using TLS [RFC5246], which IANA supports. Well, I don't know that "the same as" is quite right, especially given the following sentence. The composed chain of "talk to iana, talk to referred RDAP server" depends both on the security of the connection to the RDAP server and that of the connection to IANA; it seems prudent to note that if TLS is used for the RDAP connection, TLS should also be used when talking to IANA, or even that TLS should always be used when talking to IANA. |
2018-07-27
|
04 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2018-07-24
|
04 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-07-17
|
04 | Adam Roach | IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup |
2018-07-17
|
04 | Adam Roach | IESG state changed to IESG Evaluation::AD Followup from Waiting for Writeup::AD Followup |
2018-07-16
|
04 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-07-15
|
04 | Cindy Morgan | Placed on agenda for telechat - 2018-08-02 |
2018-07-15
|
04 | Adam Roach | Ballot has been issued |
2018-07-15
|
04 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2018-07-15
|
04 | Adam Roach | Created "Approve" ballot |
2018-07-15
|
04 | Adam Roach | Ballot writeup was changed |
2018-07-15
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-07-15
|
04 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-07-15
|
04 | Scott Hollenbeck | New version available: draft-ietf-regext-rdap-object-tag-04.txt |
2018-07-15
|
04 | (System) | New version approved |
2018-07-15
|
04 | (System) | Request for posting confirmation emailed to previous authors: Andrew Newton , Scott Hollenbeck |
2018-07-15
|
04 | Scott Hollenbeck | Uploaded new revision |
2018-07-15
|
03 | Tim Chown | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Tim Chown. Sent review to list. |
2018-07-14
|
03 | Adam Roach | See https://mailarchive.ietf.org/arch/msg/regext/h0mtzkMtaBwK3PTzpB6yoboTHoM |
2018-07-14
|
03 | Adam Roach | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2018-06-28
|
03 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2018-06-19
|
03 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-06-19
|
03 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-regext-rdap-object-tag-03. 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-object-tag-03. If any part of this review is inaccurate, please let us know. The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, a new registry is to be created called the RDAP Bootstrap Services Registry. We understand that the new registry is to be managed via First Come, First Served as defined in RFC 8126. IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? IANA Question --> Section 3 of the current draft provides an example of the JSON output of the regsitry. However, there appear to be no initial values for the registry and the current draft appears to make no registrations. Is this correct? IANA Question --> Could Section 3 or Section 5.1 be updated with a description of the physical appearance of the registry? It would be useful to understand the link between the registrations and the JSON output. Second, in the RDAP Extensions located at: https://www.iana.org/assignments/rdap-extensions/ a single, new registration is to be made as follows: Extension identifier: rdap_objectTag Registry operator: Any Published specification: [ RFC-to-be ] Contact: IESG Intended usage: This extension describes a best practice for structuring entity identifiers to enable query bootstrapping. As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. The IANA Services Operator understands that these are the only actions 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 |
2018-06-19
|
03 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-06-12
|
03 | Roni Even | Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list. |
2018-06-12
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2018-06-12
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2018-06-07
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2018-06-07
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2018-06-07
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Taylor Yu |
2018-06-07
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Taylor Yu |
2018-06-05
|
03 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-06-05
|
03 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-06-19): From: The IESG To: IETF-Announce CC: adam@nostrum.com, jgould@verisign.com, regext-chairs@ietf.org, James Gould , … The following Last Call announcement was sent out (ends 2018-06-19): From: The IESG To: IETF-Announce CC: adam@nostrum.com, jgould@verisign.com, regext-chairs@ietf.org, James Gould , draft-ietf-regext-rdap-object-tag@ietf.org, regext@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Registration Data Access Protocol (RDAP) Object Tagging) to Best Current Practice The IESG has received a request from the Registration Protocols Extensions WG (regext) to consider the following document: - 'Registration Data Access Protocol (RDAP) Object Tagging' as Best Current Practice 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 ietf@ietf.org mailing lists by 2018-06-19. 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) includes a method that can be used to identify the authoritative server for processing domain name, IP address, and autonomous system number queries. The method does not describe how to identify the authoritative server for processing other RDAP query types, such as entity queries. This limitation exists because the identifiers associated with these query types are typically unstructured. This document updates RFC 7484 by describing an operational practice that can be used to add structure to RDAP identifiers that makes it possible to identify the authoritative server for additional RDAP queries. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7484: Finding the Authoritative Registration Data (RDAP) Service (Proposed Standard - IETF stream) |
2018-06-05
|
03 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-06-05
|
03 | Adam Roach | Last call announcement was generated |
2018-06-05
|
03 | Adam Roach | Last call was requested |
2018-06-05
|
03 | Adam Roach | Last call announcement was generated |
2018-06-05
|
03 | Adam Roach | Ballot approval text was generated |
2018-06-05
|
03 | Adam Roach | Ballot writeup was generated |
2018-06-05
|
03 | Adam Roach | IESG state changed to Last Call Requested from AD Evaluation |
2018-06-04
|
03 | Adam Roach | Sent AD review to WG and authors; see https://mailarchive.ietf.org/arch/msg/regext/VYbscA450lhXYxriVUXuyHHKe3g Pausing processing pending response by working group to issues raised in review. |
2018-06-04
|
03 | Adam Roach | IESG state changed to AD Evaluation from Publication Requested |
2018-06-01
|
03 | Antoin Verschuren | Technical Summary This document updates RFC 7484 by describing an operational practice that can be used to add structure to RDAP identifiers that makes it … Technical Summary This document updates RFC 7484 by describing an operational practice that can be used to add structure to RDAP identifiers that makes it possible to identify the authoritative server for additional RDAP queries. Working Group Summary draft-ietf-regext-rdap-object-tag is on best current practice track. The document defines an entity identifier structure in RFC 7484 to support identifying the authoritative server for additional RDAP queries. Document Quality This document has been discussed on the mailing lists of the regext working group. The authors have addressed all comments and changes have been incorporated in the document. Verisign Labs and OpenRDAP have working implementations of this specification. Personnel Document shepherd is James Gould, jgould@verisign.com Area Director is Adam Roach, adam@nostrum.com Shepherd Comments As document shepherd I have verified that all the JSON examples. The “…” convention used in the examples was removed to perform the verification. The rdapConformance structure example JSON snippet verified by adding the leading “{“ and the trailing “}” characters. The author has confirmed following BCP78 and BCP79 in the document header. No IPR disclosures have been submitted for this document. The IANA considerations follow the defined format for the submission of the RDAP Service Providers Registry and the RDAP Extensions Registry. All normative and informative references have been verified. After carefully reviewing the mailings lists of the regext working group I have found no objections to this document. From IETF meetings I recall broad consensus that this document is ready for publication. As document shepherd I believe this document is ready for publication. |
2018-06-01
|
03 | Antoin Verschuren | Responsible AD changed to Adam Roach |
2018-06-01
|
03 | Antoin Verschuren | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-06-01
|
03 | Antoin Verschuren | IESG state changed to Publication Requested |
2018-06-01
|
03 | Antoin Verschuren | IESG process started in state Publication Requested |
2018-05-25
|
03 | James Gould | Changed document writeup |
2018-05-22
|
03 | James Gould | Changed document writeup |
2018-05-21
|
03 | Scott Hollenbeck | New version available: draft-ietf-regext-rdap-object-tag-03.txt |
2018-05-21
|
03 | (System) | New version approved |
2018-05-21
|
03 | (System) | Request for posting confirmation emailed to previous authors: Andrew Newton , Scott Hollenbeck |
2018-05-21
|
03 | Scott Hollenbeck | Uploaded new revision |
2018-05-04
|
02 | Antoin Verschuren | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2018-04-27
|
02 | Scott Hollenbeck | New version available: draft-ietf-regext-rdap-object-tag-02.txt |
2018-04-27
|
02 | (System) | New version approved |
2018-04-27
|
02 | (System) | Request for posting confirmation emailed to previous authors: Andrew Newton , Scott Hollenbeck |
2018-04-27
|
02 | Scott Hollenbeck | Uploaded new revision |
2018-04-20
|
01 | Antoin Verschuren | Notification list changed to James Gould <jgould@verisign.com> |
2018-04-20
|
01 | Antoin Verschuren | Document shepherd changed to James Gould |
2018-04-06
|
01 | Antoin Verschuren | IETF WG state changed to In WG Last Call from WG Document |
2018-03-26
|
01 | Scott Hollenbeck | New version available: draft-ietf-regext-rdap-object-tag-01.txt |
2018-03-26
|
01 | (System) | New version approved |
2018-03-26
|
01 | (System) | Request for posting confirmation emailed to previous authors: Andrew Newton , Scott Hollenbeck |
2018-03-26
|
01 | Scott Hollenbeck | Uploaded new revision |
2018-01-19
|
00 | James Galvin | Changed consensus to Yes from Unknown |
2018-01-19
|
00 | James Galvin | Intended Status changed to Best Current Practice from None |
2018-01-19
|
00 | James Galvin | Adopted as REGEXT working group document |
2018-01-19
|
00 | James Galvin | This document now replaces draft-hollenbeck-regext-rdap-object-tag instead of None |
2018-01-16
|
00 | Scott Hollenbeck | New version available: draft-ietf-regext-rdap-object-tag-00.txt |
2018-01-16
|
00 | (System) | New version approved |
2018-01-16
|
00 | Scott Hollenbeck | Request for posting confirmation emailed to submitter and authors: Andrew Newton , Scott Hollenbeck |
2018-01-16
|
00 | Scott Hollenbeck | Uploaded new revision |