[DNSOP] URI RR labels derived from Enumservices (was: [Editorial Errata Reported] RFC8552 (7064))

[[e-mail]]

Hi Dave

Not sure there is yet another issue around the Enumservices derived URI 
label registrations.

As I understand this document (RFC 8552) is based on RFC 7553 regarding 
Enumservices, which states:

    The Enumservice Registration [RFC6117] parameters are
    reversed (i.e., subtype(s) before type), prepended with an underscore
    (_), and prepended to the owner name in separate labels.
    [...]
    For example, suppose we are looking for the URI for a service with
    ENUM Service Parameter "A:B:C" for host example.com.  Then we would
    query for (QNAME,QTYPE)=("_C._B._A.example.com","URI").


However, RFC 8552 only lists the Enumservices labels for Types, but not 
for Subtypes: 
https://www.iana.org/assignments/enum-services/enum-services.xhtml

Shouldn't the labels for Subtypes also go to this (initial) URI Registry?

cheers,
  Bernie (Designated Expert for Enum)


--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology


On Wed, 3 Aug 2022, Dave Crocker wrote:

> On 8/2/2022 8:04 AM, RFC Errata System wrote:
> 
> Type: Editorial
> Reported by: Bernie Hoeneisen <[e-mail]>
> 
> Section: 4.1.2.
> 
> Original Text
> -------------
>  | URI        | _acct                 | [RFC6118]     |
> 
> Corrected Text
> --------------
>  | URI        | _acct                 | [RFC7566]     |
> 
> Notes
> -----
> Wrong reference. Note that is also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-pa
> rameters.xhtml#underscored-globally-scoped-dns-node-names
> 
> 
> Folks,
>
>  1. Bernie, thanks for bringing this up
>  2. Using this case as an example, the history in the attrleaf development seems concerning.  The RFC cited for this entry
>     changes, over the course of a number of I-D versions.  So, in -13 is was RFC 7553, -14 is was RFC 7566, and in -15 it
>     went to RFC 6118.
>  3. That the published version landed on the wrong choice should raise a question possibly about process but especially about
>     understanding.
> 
> In Spring, 2018 and again in Fall, 2018, there was some focused discussion (see:  dnsop) about _acct, and related strings,
> and which citation to use for the enum-related values.  The choice bounced around, as I've cited.  This includes having what
> is now being deemed the 'correct' choice in -14...
> 
> Note that none of the cited documents refers to the exact string "_acct".  So there is a derivation process that seems to be
> unclear. I believe the attrleaf RFC contains no pedagogy about this, but it probably should.
> 
> Before doing the simple -- but possibly wrong -- thing of agreeing on a new -- or, rather, returning to an old -- better RFC
> citation, I suggest there be some community discussion about the why of the right choice and consideration of how to document
> that, this time, this latest choice is the truly correct one.
> 
> 
> d/
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> 
>