RFC Errata
Found 3 records.
Status: Verified (1)
RFC 9537, "Redacted Fields in the Registration Data Access Protocol (RDAP) Response", March 2024
Source of RFC: regext (art)
Errata ID: 7876
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jasdip Singh
Date Reported: 2024-03-30
Verifier Name: Orie Steele
Date Verified: 2024-04-12
Section 4.2 says:
Figure 13:
{
"rdapConformance": [
"rdap_level_0"
],
"domainSearchResults":[
{
"objectClassName": "domain",
"handle": "ABC121",
"ldhName": "example1.com",
"links":[
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example1.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"related",
"href":"https://example.com/rdap/domain/example1.com",
"type":"application/rdap+json"
}
]
},
{
"objectClassName": "domain",
"handle": "ABC122",
"ldhName": "example2.com",
"links":[
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example2.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"related",
"href":"https://example.com/rdap/domain/example2.com",
"type":"application/rdap+json"
}
]
}
]
}
Figure 14:
{
"rdapConformance": [
"rdap_level_0",
"redacted"
],
"domainSearchResults":[
{
"objectClassName": "domain",
"ldhName": "example1.com",
"links":[
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example1.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"related",
"href":"https://example.com/rdap/domain/example1.com",
"type":"application/rdap+json"
}
],
"redacted": [
{
"name": {
"type": "Registry Domain ID"
},
"prePath": "$.domainSearchResults[0].handle",
"pathLang": "jsonpath",
"method": "removal",
"reason": {
"type": "Server policy"
}
}
]
},
{
"objectClassName": "domain",
"ldhName": "example2.com",
"links":[
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example2.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"related",
"href":"https://example.com/rdap/domain/example2.com",
"type":"application/rdap+json"
}
],
"redacted": [
{
"name": {
"description": "Registry Domain ID"
},
"prePath": "$.domainSearchResults[1].handle",
"pathLang": "jsonpath",
"method": "removal",
"reason": {
"description": "Server policy"
}
}
]
}
]
}
It should say:
Figure 13:
{
"rdapConformance": [
"rdap_level_0"
],
"domainSearchResults":[
{
"objectClassName": "domain",
"handle": "ABC121",
"ldhName": "example1.com",
"links":[
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example1.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"related",
"href":"https://example.net/rdap/v1/domain/example1.com",
"type":"application/rdap+json"
}
]
},
{
"objectClassName": "domain",
"handle": "ABC122",
"ldhName": "example2.com",
"links":[
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example2.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"related",
"href":"https://example.net/rdap/v1/domain/example2.com",
"type":"application/rdap+json"
}
]
}
]
}
Figure 14:
{
"rdapConformance": [
"rdap_level_0",
"redacted"
],
"domainSearchResults":[
{
"objectClassName": "domain",
"ldhName": "example1.com",
"links":[
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example1.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"related",
"href":"https://example.net/rdap/v1/domain/example1.com",
"type":"application/rdap+json"
}
],
"redacted": [
{
"name": {
"type": "Registry Domain ID"
},
"prePath": "$.domainSearchResults[0].handle",
"pathLang": "jsonpath",
"method": "removal",
"reason": {
"type": "Server policy"
}
}
]
},
{
"objectClassName": "domain",
"ldhName": "example2.com",
"links":[
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example2.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"related",
"href":"https://example.net/rdap/v1/domain/example2.com",
"type":"application/rdap+json"
}
],
"redacted": [
{
"name": {
"description": "Registry Domain ID"
},
"prePath": "$.domainSearchResults[1].handle",
"pathLang": "jsonpath",
"method": "removal",
"reason": {
"description": "Server policy"
}
}
]
}
]
}
Notes:
Noticed that the "self" and "related" links in Figure 13 and Figure 14 examples have the same "href" value. From RFC 9083: A "related" link relation MUST NOT include an "href" URI that is the same as the "self" link relation "href" URI to reduce the risk of infinite client processing loops. (The new "href" values for the "related" links are per James Gould's earlier suggestion.)
Status: Rejected (2)
RFC 9537, "Redacted Fields in the Registration Data Access Protocol (RDAP) Response", March 2024
Source of RFC: regext (art)
Errata ID: 8004
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: James Gould
Date Reported: 2024-06-26
Rejected by: Orie Steele
Date Rejected: 2024-08-12
Throughout the document, when it says:
This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language.
It should say:
This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields.
Notes:
The Abstract and the first sentence of the Introduction is "This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language.". This sentence is combining two aspects into a single sentence ("explicitly identifying redacted RDAP response fields" and "using JSONPath as the default expression language") incorrectly. It is true that the extension is "explicitly identifying redacted RDAP response fields" and it's true that extension is "using JSONPath as the default expression language", but the expression languages are optional and the use of JSONPath as the default expression language is not relevant for the Abstract and first sentence of the Introduction. The recommended change is to remove the ", using JSONPath as the default expression language" from the sentences to correct it, resulting in:
"This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields."
--VERIFIER NOTES--
Per https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/
I considered HFDU based on:
>Technical items that have a clear resolution in line with the original intent should be classified as Verified. If the resolution is not clear or requires further discussion, the report should be classified as Hold for Document Update. In both cases, only items that are clearly wrong should be considered.
However, it is not obvious to me that this is "clearly wrong".
>The erratum is invalid or proposes a significant change to the RFC that should be done by publishing a new RFC that replaces or updates the current one. In the latter case, if the change is to be considered for future updates of the document, it should be proposed using channels other than the errata process, such as a WG mailing list.
It seems to me that the correct solution is a -bis document, especially if the intention is to clarify mandatory or optional implementation details that impact interoperability.
Errata ID: 8006
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: James Gould
Date Reported: 2024-06-27
Rejected by: Orie Steele
Date Rejected: 2024-08-12
Section 4.2 says:
The "postPath" member MUST be set when the redacted field does exist in the redacted response for the Redaction by Empty Value Method (Section 3.2), the Redaction by Partial Value Method (Section 3.3), and the Redaction by Replacement Value Method (Section 3.4).
It should say:
The "postPath" member MAY be set when the redacted field does exist in the redacted response for the Redaction by Empty Value Method (Section 3.2), the Redaction by Partial Value Method (Section 3.3), and the Redaction by Replacement Value Method (Section 3.4).
Notes:
The “postPath” member is an OPTIONAL member and this MUST can provide confusion. The intent of this sentence was to outline which of the path members (“prePath”, “postPath”, and “replacementPath”) to use when using path expressions and not to conflict with the OPTIONAL definition. All of the path expression members are defined as OPTIONAL in the RFC, so this MUST needs be changed to a MAY to correct the confusion.
--VERIFIER NOTES--
Per https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/
> The erratum is invalid or proposes a significant change to the RFC that should be done by publishing a new RFC that replaces or updates the current one.
I believe it would be harmful to mark this as HFDU, because the normative requirements for implementations would be less clear, and the document might never be updated.