Dear all,
I posted revision -04 of draft-bertoldi-regext-rdap-reliability-scoring today: https://datatracker.ietf.org/doc/draft-bertoldi-regext-rdap-reliability-scoring/ The -02, announced here on 6 September, asked two questions: whether anything in RDAP assumes that a server answering /domain/<ldhName> is authoritative for that domain, and whether object tagging under RFC 8521 can be used by a server that is not authoritative for the registration data. Neither drew a reply, so I put the question of use directly to registry operators, on the view that a statement that a party would not use the extension, with the reason, is worth more than silence. One of them explained why it could not implement the extension and, when asked, confirmed that object tagging is not available to a service that is not authoritative for the registration data: the practice exists to bootstrap entity queries and nothing else. Section 10 records the exchange. The operator asked not to be named and is not, and its observations are recorded as neither an endorsement nor an intention to implement. That answer removes the ground under the model of the -02 and the -03. An assessment service that is not authoritative is outside the RFC 9224 bootstrap for domain objects and, without object tagging, unreachable through the RFC 8521 registry for entity objects: a client that has not been configured in advance cannot find it. The -04 therefore no longer presents a third-party assessment service as the primary configuration. For both object classes the authoritative server is the starting point, and Section 5.4 describes two arrangements: the server carries the result in its own response, or it publishes a link to a resource from which the result may be retrieved. A third, suggested by the same operator, is a dedicated path segment at the authoritative server that either returns the result or redirects to a service that does; it would make this a query extension as well as a response extension, so the -04 records it as a candidate for a later revision rather than defining it. In every arrangement the decision belongs to the server: nothing in the document requires an authoritative server to support the extension, to publish a result, or to refer to one. On endorsement the -04 takes a narrower view than the -03 did: a response carrying a result attributed to the issuer named in scoreIssuer conveys that attribution and nothing further about the publisher, and neither this extension nor core RDAP assigns the carriage of a result a standardized semantic of agreement. The narrow claim is stated because it is the only one that holds; the choice a publisher makes in carrying one result rather than another remains the publisher's, and the document does not pretend otherwise. This is the question I would like to put to the group. Are these arrangements for publication by an authoritative server, the result in the response and a link to a resource, with a dedicated path as a candidate, the right ones, and do you see others? I have asked the chairs for a short slot at IETF 127 and would use it for this; answers here are just as welcome. Two further changes. A result may now carry no score and be complete: the extension is then a way of attesting that the properties defined by a scheme were examined, as much as a way of scoring, and Appendix C.3 shows one; the only new normative requirement there is that a consumer MUST NOT infer a numeric judgement from the absence of a score. And Section 8 now requires a scheme specification to state the basis on which the publishing party relies in publishing a result, and how the exposure arising from publication is allocated between issuer and publisher; the same operator identified that as a condition of deployability, and I agree. The identifier, the JSON member, the fields and their types are unchanged: a client written for the -03 reads a -04 response without change. Separately, and I would rather you heard it from me than came across it in the registry: the -02 stated that registration of the "reliabilityAssessment" identifier would be requested only on publication as an RFC. An Internet-Draft is not a stable reference, so I published a stable specification outside the IETF and requested the registration against it; IANA has opened ticket #1459780 and the request is with the designated experts. To be explicit about what that document is and is not: it is not offered as IETF work, it asserts no consensus of any kind, and it states that it is not intended to foreclose any decision this working group may take. Should the draft be published as an RFC, I will ask IANA to point the registry entry at the RFC in place of it. The -04 contains normative language that the registered specification does not; Section 13.1 lists it, the wire representation is unaffected, and I have informed the experts. This remains an individual, Experimental draft, and I am not requesting adoption. What I am still looking for is operators who would publish or consume this kind of data. A statement that someone would not use it, with the reason, has already shaped this revision and is as welcome as the opposite. Best regards, Alessandro Bertoldi Bertoldi Cybersecurity "Empowering your business with cutting-edge cybersecurity solutions, safeguarding your digital assets and ensuring a seamless, secure experience for your customers." BertoldiCybersecurity GCVE Numbering Authority (GNA 128) Alessandro Bertoldi Owner T. +39 0185 799079 M. +39 348 5130136 E-Mail [email protected] www.bertoldicybersecurity.comhttps://bcsec.io
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
