Summary

  • Revision 03 of the individual RDAP reliability-assessment draft was published on 13 September 2026; it is not an adopted REGEXT document or an RFC.
  • The registration request now cites a separately published, fixed specification instead of waiting for an RFC. The draft says the data model and wire format are unchanged.
  • IANA's checked RDAP Extensions list does not yet contain reliabilityAssessment. A published request is not evidence of expert approval or assignment.
  • A precise extension name must not become a substitute for standards consensus, assessor authority or an operator's deployment decision.

The change is in the reference column

A developer implementing an extension needs to know what the extension name means. That is a narrower question than whether a standards community endorses the design. Revision 03 of RDAP Extension for Structured Reliability Assessment Metadata puts the distinction into an unusually concrete publication arrangement.

The proposal carries assessments of registrars and domain names in RDAP responses. Its new revision, dated 13 September, does not change the data model, identifier, JSON member name or wire format. Instead, Section 13 changes the specification cited for the requested reliabilityAssessment registration.

Revision 02 expected registration only when an RFC existed. The authors now say the obstacle was the absence of a stable reference, not an absolute RFC prerequisite. They have published bcsec-RDAP-RA Version 1 separately and request registration against that text. The previous waiting statement is superseded because the reference has been supplied, not because its stability requirement has been waived.

This is not a completed registration. The IANA list inspected for this report still has no reliabilityAssessment entry. Nor does a registration request written into a specification prove that an application has been received, reviewed or accepted. The Datatracker records active individual work, with I-D Exists standing.

A specification need not be an RFC

The existing registry uses Specification Required. RFC 8126 defines that policy as designated-expert review and approval plus a permanent, publicly available specification detailed enough for independent interoperable implementations. The expert assesses stability, clarity and technical soundness. An RFC is an ideal publication route, but the policy expressly accommodates documents published outside it.

RFC 7480 supplies the RDAP registry and registration template. The parallel WG draft on RDAP Extensions proposes more explicit stable-reference and review guidance. That draft should not be promoted into a final replacement rule merely because the individual proposal cites it.

Expert review is consequently not clerical name reservation. Equally, meeting registration criteria would not turn individual work into IETF consensus. The fixed specification explicitly preserves REGEXT's freedom not to adopt the extension. It is published by Bertoldi Cybersecurity alone while crediting the joint technical design with Simon Pietro Romano through the individual draft.

Fixed bytes create a separate change path

The independent document promises that its canonical bytes will not be edited, even for an editorial correction. Errors are to be listed in a separate errata document with no normative weight. A correction affecting interoperability requires a new specification at a different URL; the old one remains available. A mirror is provided, with the canonical URL governing any discrepancy.

Those are the publisher's maintenance commitments. A successful retrieval proves present availability; it cannot prove future permanence. They nevertheless define a useful distinction between learning that a text contains an error and silently changing the text an implementation follows.

Appendix C declares the same data model as the individual draft but lists publication differences. Work-in-progress references become informative or have relevant requirements restated. Review invitations and open-question wording are removed or recast. The fixed document makes no independent RDAP JSON Values registration request; the draft pursues that separately. “Technically aligned” therefore does not mean the documents are interchangeable in every procedural respect.

If an RFC eventually appears, the registrant says it will ask to replace the registry's reference with it. That would be another observable decision, not an automatic rewrite of deployed implementations. The envelope still transports assessment results rather than selecting scoring methodology, thresholds or enforcement. Naming the interface settles none of those downstream choices.

Sources