> -----Original Message----- > From: regext <[email protected]> On Behalf Of Marc Blanchet > Sent: Tuesday, August 14, 2018 8:38 AM > To: RFC Errata System <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected] > Subject: [EXTERNAL] Re: [regext] [Technical Errata Reported] RFC7484 > (5460) > > 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.
I think the guidance is useful. I'd suggest leaving it as-is unless "better" text is proposed. Scott > > 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 <[email protected]> > > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
