Hi Bill and Patrik,
I made a start with implementing the types in NSD but failed, because of
the use of (unquoted and unescaped) parentheses in the Value RDATA
fields for both types. The zone parser for NSD uses (unquoted and
unescaped ) parentheses to group data, potentially across lines (see
Section 5.1 of RFC1035:
https://www.rfc-editor.org/info/rfc1035/#section-5.1 ). At least for NSD
it would be quite cumbersome to implement the exception for this RDATA
field type. Unbound and ldns also treat parentheses this way and will
have the same issue.
Could you consider another way to indicate the precision? Perhaps square
brackets instead of parentheses?
-- Willem
On 9/9/26 18:57, Bill Woodcock wrote:
Esteemed DNSOP folks:
Patrik and I have posted a new individual draft, and welcome your review:
https://datatracker.ietf.org/doc/draft-woodcock-faltstrom-external-registry-rrtypes/
Abstract:
This document defines two DNS resource record types, UNECE and ISO,
which convey numeric values paired with codes drawn from registries
maintained by external standards organizations: the United Nations
Economic Commission for Europe (UNECE) and the International
Organization for Standardization. Neither proposed RRTYPE duplicates
the external registries into IANA registries; each carries codes
verbatim and uses the semantics defined by the external maintainer.
The document specifies presentation and wire formats for both types,
requests the assignment of two decimal RRTYPE identifiers under the
Expert Review process of BCP 42, and suggests a common design pattern
that may serve as a model for future RRTYPEs seeking to make external
registries usable from the DNS without duplication.
These RRtypes are needed to support ongoing work in the DIEM working
group.
One question on which we think input might be particularly useful: We
defined these with one RRTYPE per maintainer organization, where the
alternative would have been a single generic external-registry type
discriminated by organization _within_ the data. We chose the former;
we assume that the argument against would be that additinal RRTYPEs
would be needed if the pattern gets reused.
RFC 6895 templates for both types were submitted to
[email protected] on 14 August, and the two RRTYPEs are
assigned... This draft is about standardizing their use so that they
can be referenced within the DIEM RFCs and elsewhere.
Thanks in advance for your thoughts and feedback,
-Bill
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
