[regext] [Errata Verified] RFC7484 (5460)
The following errata report has been verified for RFC7484, "Finding the Authoritative Registration Data (RDAP) Service". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid5460 -- Status: Verified Type: Technical Reported by: Pieter Vandepitte Date Reported: 2018-08-14 Verified by: Murray Kucherawy (IESG) Section: 8 Original Text - In the case of a domain object, the client may first query the DNS to see if the respective entry has been delegated or if it is mistyped information by the user. The DNS query could be to fetch the NS records for the TLD domain. If the DNS answer is negative, then there is no need to fetch the new version of the registry. However, if the DNS answer is positive, this may mean that the currently cached registry is no longer current. The client could then fetch the registry, parse, and then do the normal matching as specified above. This method may not work for all types of RDAP objects. Corrected Text -- Notes - I would remove the whole section. The point is: if the DNS answer is positive, then you need to fetch the registry. But if the answer is negative, this does not mean anything because it it possible that a registered domain is not delegated. -- RFC7484 (draft-ietf-weirds-bootstrap-11) -- Title : Finding the Authoritative Registration Data (RDAP) Service Publication Date: March 2015 Author(s) : M. Blanchet Category: PROPOSED STANDARD Source : Web Extensible Internet Registration Data Service Area: Applications Stream : IETF Verifying Party : IESG ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] [Errata Verified] RFC7484 (5461)
The following errata report has been verified for RFC7484,
"Finding the Authoritative Registration Data (RDAP) Service".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5461
--
Status: Verified
Type: Editorial
Reported by: Pieter Vandepitte
Date Reported: 2018-08-14
Verified by: Murray Kucherawy (IESG)
Section: 4
Original Text
-
{
"version": "1.0",
"publication": "-MM-DDTHH:MM:SSZ",
"description": "Some text",
"services": [
[
["net", "com"],
[
"https://registry.example.com/myrdap/";
]
],
[
["org", "mytld"],
[
"http://example.org/";
]
],
[
["xn--zckzah"],
[
"https://example.net/rdapxn--zckzah/";,
"http://example.net/rdapxn--zckzah/";
]
]
]
}
Corrected Text
--
{
"version": "1.0",
"publication": "-MM-DDTHH:MM:SSZ",
"description": "Some text",
"services": [
[
["net", "com"],
[
"https://registry.example.com/myrdap/";
]
],
[
["org", "mytld"],
[
"http://example.org/";
]
],
[
["xn--zckzah"],
[
"https://example.net/rdap/xn--zckzah/";,
"http://example.net/rdap/xn--zckzah/";
]
]
]
}
Notes
-
Include a slash between rdap and xn--zckzah. rdapxn--zckzah is not a valid
a-label
--
RFC7484 (draft-ietf-weirds-bootstrap-11)
--
Title : Finding the Authoritative Registration Data (RDAP) Service
Publication Date: March 2015
Author(s) : M. Blanchet
Category: PROPOSED STANDARD
Source : Web Extensible Internet Registration Data Service
Area: Applications
Stream : IETF
Verifying Party : IESG
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-rfc7484bis-04: (with DISCUSS and COMMENT)
On Mon, Nov 29, 2021 at 1:37 PM Benjamin Kaduk via Datatracker < nore...@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-regext-rfc7484bis-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/ > > > > -- > DISCUSS: > -- > > There are two errata reports against RFC 7484, both in status > "reported" > (https://www.rfc-editor.org/errata_search.php?rfc=7484&rec_status=15). > Part of the requirements for advancing a document to Internet Standard > is to address all errata reports against the original document. On a > superficial reading of the diff from RFC 7484 to this document it does > appear that changes are included that would address these two errata > reports, but that should probably be acknowledged in the text, and the > responsible AD should use the RFC Editor's errata tool to process the > reports accordingly. > The errata have been marked as "Verified". -MSK ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-rfc7484bis-04: (with DISCUSS and COMMENT)
On Thu, Dec 02, 2021 at 08:10:02AM -0800, Murray S. Kucherawy wrote: > On Mon, Nov 29, 2021 at 1:37 PM Benjamin Kaduk via Datatracker < > nore...@ietf.org> wrote: > > > -- > > DISCUSS: > > -- > > > > There are two errata reports against RFC 7484, both in status > > "reported" > > (https://www.rfc-editor.org/errata_search.php?rfc=7484&rec_status=15). > > Part of the requirements for advancing a document to Internet Standard > > is to address all errata reports against the original document. On a > > superficial reading of the diff from RFC 7484 to this document it does > > appear that changes are included that would address these two errata > > reports, but that should probably be acknowledged in the text, and the > > responsible AD should use the RFC Editor's errata tool to process the > > reports accordingly. > > > > The errata have been marked as "Verified". Thanks! I saw the email for that and updated my ballot position during the telechat. -Ben ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
