Hello,
thanks for reporting this. The original text was meant as some
possible guidance on what to do for the implementor. However, the use of
may and could in the text shows clearly that this is just one
possibility, leaving the implementor more complex implementation
algorithm. I’m not sure what is the best solution, one is what you
suggest (delete text), other is to leave it as is (given the may/could
usage), other is to make it more comprehensive. I’m pretty neutral to
any at this point.
Regards, Marc.
On 14 Aug 2018, at 8:09, RFC Errata System wrote:
The following errata report has been submitted for RFC7484,
"Finding the Authoritative Registration Data (RDAP) Service".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5460
--------------------------------------
Type: Technical
Reported by: Pieter Vandepitte <pieter.vandepi...@dnsbelgium.be>
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.
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.
--------------------------------------
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
