Skip to main content

Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves
draft-ietf-dnsop-attrleaf-16

Revision differences

Document history

Date Rev. By Action
2021-04-20
16 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2019-08-19
16 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2019-08-19
16 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Fred Baker was marked no-response
2019-03-22
16 (System) IANA registries were updated to include RFC8552
2019-03-22
16 (System) Received changes through RFC Editor sync (added Errata tag)
2019-03-20
16 (System)
Received changes through RFC Editor sync (created alias RFC 8552, changed title to 'Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute …
Received changes through RFC Editor sync (created alias RFC 8552, changed title to 'Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves', changed abstract to 'Formally, any DNS Resource Record (RR) may occur under any domain name.  However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies.  The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name").  The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch.  This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA.  The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services.', changed standardization level to Best Current Practice, changed state to RFC, added RFC published event at 2019-03-20, changed IESG state to RFC Published, created alias BCP 222)
2019-03-20
16 (System) RFC published
2019-03-20
16 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8552">AUTH48-DONE</a> from AUTH48
2019-03-01
16 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8552">AUTH48</a> from RFC-EDITOR
2019-02-25
16 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-01-15
16 (System) RFC Editor state changed to EDIT from IESG
2019-01-10
16 (System) RFC Editor state changed to IESG from EDIT
2018-12-20
16 (System) RFC Editor state changed to EDIT from MISSREF
2018-12-11
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-12-11
16 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-12-11
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-12-11
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-12-11
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-12-10
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-11-29
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-11-26
16 (System) RFC Editor state changed to MISSREF
2018-11-26
16 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-11-26
16 (System) Announcement was received by RFC Editor
2018-11-26
16 (System) IANA Action state changed to In Progress
2018-11-26
16 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2018-11-26
16 Amy Vezza IESG has approved the document
2018-11-26
16 Amy Vezza Closed "Approve" ballot
2018-11-26
16 Amy Vezza Ballot approval text was generated
2018-11-26
16 Amy Vezza Ballot writeup was changed
2018-11-16
16 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-16.txt
2018-11-16
16 (System) New version approved
2018-11-16
16 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-11-16
16 Dave Crocker Uploaded new revision
2018-11-03
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-11-03
15 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-15.txt
2018-11-03
15 (System) New version approved
2018-11-03
15 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-11-03
15 Dave Crocker Uploaded new revision
2018-10-16
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Fred Baker
2018-10-16
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Fred Baker
2018-10-16
14 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Mahesh Jethanandani was rejected
2018-10-11
14 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2018-10-11
14 Michelle Cotton IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-10-11
14 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-10-10
14 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-10-10
14 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-10-10
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-10-10
14 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-14.txt
2018-10-10
14 (System) New version approved
2018-10-10
14 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-10-10
14 Dave Crocker Uploaded new revision
2018-10-10
13 Ben Campbell
[Ballot comment]
Adam captured all of my comments in considerably more detail than in my notes, so I will follow the discussion resulting from his …
[Ballot comment]
Adam captured all of my comments in considerably more detail than in my notes, so I will follow the discussion resulting from his ballot.
2018-10-10
13 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-10-10
13 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-10-10
13 Spencer Dawkins
[Ballot comment]
This is a DNS specification that is fairly clear to people who know a little about DNS, but not a lot. You win. …
[Ballot comment]
This is a DNS specification that is fairly clear to people who know a little about DNS, but not a lot. You win.

This text

  DNS data semantics have been
  limited to the specification of particular resource record types, on
  the expectation that new ones would be added as needed.

would have been clearer for me, if it said "new resource record types would be added as needed".  "new ones" was vague enough to break my train of thought.
2018-10-10
13 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-10-10
13 Benjamin Kaduk
[Ballot comment]
I'm happy to see this registry created and populated; I would be balloting
YES except that I do not think I have time …
[Ballot comment]
I'm happy to see this registry created and populated; I would be balloting
YES except that I do not think I have time to follow all the references
for the initial registry contents.

That said, I do share Adam's concern about IANA being more reliable than
authors of future enum-services documents at remembering to (check whether
to) update a second table, but the subsequent discussion about not all
enum-services necessarily being used in URI records seems to support the
current scheme.

I also have some section-by-section comments.

Abstract

  Formally, any DNS resource record may occur under any domain name.
  However some services have defined an operational convention, which
  applies to DNS leaf nodes that are under a DNS branch having one or
  more reserved node names, each beginning with an _underscore.  [...]

nit: just "underscore" or "_", I think -- "_underscore" is not a well
recognized character.

Section 1.4
 
  Conversely, a wildcard such as *.example.com can match any name
  including an underscored name.  So, a wildcard might match an
  underscored name, returning a record that is the type controlled by
  the underscored name but is not intended to be used in the
  underscored context and does not conform to its rules.

This could perhaps benefit from greater clarity on which entity's
perspective the "not intended" applies to.  I assume the entity making the
wild query does not intend to interpret the response in an underscore
context, but the language is a bit hard to follow.

Section 3

  This section provides a basic template that can be used to register
  new entries in the IANA DNS Underscore Global Scoped Entry Registry,
  if the global underscored name above the RRTYPE is not already
  registered. [...]

I'm not sure how to parse "name above the RRTYPE", since (1) the RRTYPE
record can have the owner name that is the global underscored name, and (2)
the RRTYPE is, well, a record type and not a name.

Section 4.1

I would consider adding another 8126 citation for "Expert Review"
procedures.

Section 4.3

There are some URI usages with node names _kerberos, _kpasswd, and
_kerberos-adm listed in draft-ietf-kitten-krb-service-discovery (and
implemented, per
http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html#kdc-discovery).
It's unclear whether they meet the WG's criteria for inclusion in the
initial registry contents, especially at such a late stage of the document's lifecycle.

Section 5

  For the purposes of this Expert Review, other matters of the
  specification's technical quality, adequacy or the like are outside
  of scope.

I have mixed feelings about wanting to keep registration open to avoid
squatting, but also about wanting to allow the experts to reject requests
that do not provide a clear and interoperable description of what the
RRTYPE+name is used for.  I do think that the first bullet point
("sufficeintly clear, precise and complete") allows the experts some leeway
in this regard, but when limited by this statement I'm not sure it provides
the experts enough leeway.

Section 6

One could perhaps argue that by creating a global registry this document
reduces the likelihood of inadvertent collision, and that such collision
could have security consequences.  But it would be a bit of a stretch.
2018-10-10
13 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-10-10
13 Alissa Cooper
[Ballot comment]
I agree with Alexey. It seems like the expert is being asked to do the review that IANA would typically do itself.

Please …
[Ballot comment]
I agree with Alexey. It seems like the expert is being asked to do the review that IANA would typically do itself.

Please address  the Gen-ART review nits.
2018-10-10
13 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-10-10
13 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-10-09
13 Eric Rescorla
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5596



COMMENTS

>      However some services have defined an operational convention, which
>      …
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5596



COMMENTS

>      However some services have defined an operational convention, which
>      applies to DNS leaf nodes that are under a DNS branch having one or
>      more reserved node names, each beginning with an _underscore.  The
>      underscored naming construct defines a semantic scope for DNS record
>      types that are associated with the parent domain, above the
>      underscored branch.  This specification explores the nature of this

This text is a bit hard to parse for the layman. Here's my attempted
rewrite, which captures what I think this means.

Conventionally, this construct associates data with the parent domain,
with the underscored label instead denoting the type of the data.

I'm not sure if that helps, but perhaps something along these lines?


S 1.1.

>  1.1.  Underscore Scoping

>      As an alternative to defining a new RR type, some DNS service
>      enhancements call for using an existing resource record type, but
>      specify a restricted scope for its occurrence.  Scope is meant as a

I think I get why you are saying "scope" here, but it's kind of not
that good fit with the programming concepts of scope as I am familiar
with.

It seems like there are two benefits to this convention (1) indicating
the type of the data (2) the ability to do a selective query.

Perhaps it would be clearer to introduce the convention first with the
typing benefit and then explain that this also gives you the ability
to do a selective query.




S 2.
>                        +----------------------------+

>                          Examples of Underscored Names

>      Only global underscored names are registered in the IANA Underscore
>      Global table.

so just for clarify, in the examples above, only _service[1-4] and
_authority would need to be registered?
2018-10-09
13 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-10-09
13 Adam Roach
[Ballot comment]
[Note that my initial issue below was originally a DISCUSS. I am leaving it
in as a comment, as I believe it remains …
[Ballot comment]
[Note that my initial issue below was originally a DISCUSS. I am leaving it
in as a comment, as I believe it remains a significant problem with the
registry established by this document; but given that it was explicitly
discussed by the Working Group and that reasonable people can disagree
on the degree of harm here, I'm not going to stand in the way of
publication.]

I'm glad to see this registry finally being set up, and want to thank everyone
who helped get the document ready. I understand that this has been a large
archaeological undertaking, and that the relatively small size of the document
belies the large amount of actual work that went into it.

I have one top-level concern about the registry, a handful of proposed
corrections to the initial table, and some very minor editorial nits. I present
the following feedback in that order.

---------------------------------------------------------------------------

I have some very strong concerns about the handling for the "URI" RRTYPE.
As far as I can tell, the entries in the initial table were formed by starting
with the entries in
https://www.iana.org/assignments/enum-services/enum-services.xhtml, adding the
most popular entries from
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml,
("dccp", "sctp", "tcp", and "udp") and removing "web".

Please note that it is entirely possible that I've missed an important detail
here, and am merely confused.

My top-line concern is that, while the table established by this document
appears to intend to be a strict superset of the Enumservices table, there are
no instructions of any kind to the IANA that would result in these tables
remaining in sync -- that is, when a new service is added to the "Enumservice
Registrations" table, one might presume that it needs to also appear in the
new registry established by this document.

I would imagine this could be handled either by asking the IANA to add
instructions to the "Enumservice Registrations" table indicating that a
corresponding entry must be added to this one; or simply by including the
contents of that table by reference rather than by value into this one. I'm
pretty agnostic about which approach is taken.

---------------------------------------------------------------------------

Related to the topic above, I have three very closely related comments:

Comment 1: Was the removal of "web" intentional?

Comment 2: These initial entries misspell "xmpp" as "xmp"

Comment 3: Is it envisioned that all future URI entries in this table will
reference RFC 7533? That doesn't quite seem right. My instinct is that it would
serve the users of this registry better if:

- _iax refers to RFC 6315
- _acct refers to RFC 7566
- All other enumservice-based URI entries in the current table refer to
  RFC 6118
- RFC 7533 is mentioned elsewhere in the document as the reason enumservices
  appear in the table.

---------------------------------------------------------------------------

RFC 6763 §6 says:

  Every DNS-SD service MUST have a TXT record in addition to its SRV
  record, with the same name, even if the service has no additional
  data to store and the TXT record contains no more than a single zero
  byte.

It's worth noting that RFC 6763 limits its use strictly to the use of "_tcp" and
"_udp" -- all non-TCP transports are coded as "_udp". So I believe the following
entries need to be added:

              | TXT        | _tcp            | [RFC6763]  |
              | TXT        | _udp            | [RFC6763]  |

---------------------------------------------------------------------------

RFC 4386 §2 defines Global SRV records for _ldap, _http, and _ocsp. So:

              | SRV        | _ldap            | [RFC4386]  |
              | SRV        | _http            | [RFC4386]  |
              | SRV        | _ocsp            | [RFC4386]  |

---------------------------------------------------------------------------

Regarding the existing entry:

              | SRV        | _tls            | [RFC6733]  |

RFC 6733 uses this name non-normatively in an example, as an intermediate
target while resolving an NAPTR record, and it is clearly a site-local
decision rather than a protocol element. I do not believe this should be
construed as reserving the name; its use in this context is clearly, in the
words of this document's introduction, "a matter of operational convention,
rather than defined protocol semantics."

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Minor nit: please consider using the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§4.1:

>  o  The table is to be maintained with entries sorted by the first
>    column (RR Type) and, within that, the second column (_Node Name).

Minor nit: I suggest that this document would be improved by sorting the table
in §4.3 in this order as well.
2018-10-09
13 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2018-10-09
13 Alvaro Retana
[Ballot comment]
Just a nit:

This document creates the new registry, but draft-ietf-dnsop-attrleaf-fix updates the existing specifications.  It would be nice to add an Informative …
[Ballot comment]
Just a nit:

This document creates the new registry, but draft-ietf-dnsop-attrleaf-fix updates the existing specifications.  It would be nice to add an Informative reference (to draft-ietf-dnsop-attrleaf-fix) in order to make the connection clear from both sides.
2018-10-09
13 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-10-08
13 Adam Roach
[Ballot comment]
Related to the topic in my DISCUSS, I have three very closely related comments:

Comment 1: Was the removal of "web" intentional?

Comment …
[Ballot comment]
Related to the topic in my DISCUSS, I have three very closely related comments:

Comment 1: Was the removal of "web" intentional?

Comment 2: These initial entries misspell "xmpp" as "xmp"

Comment 3: Is it envisioned that all future URI entries in this table will
reference RFC 7533? That doesn't quite seem right. My instinct is that it would
serve the users of this registry better if:

- _iax refers to RFC 6315
- _acct refers to RFC 7566
- All other enumservice-based URI entries in the current table refer to
  RFC 6118
- RFC 7533 is mentioned elsewhere in the document as the reason enumservices
  appear in the table.

---------------------------------------------------------------------------

RFC 6763 §6 says:

  Every DNS-SD service MUST have a TXT record in addition to its SRV
  record, with the same name, even if the service has no additional
  data to store and the TXT record contains no more than a single zero
  byte.

It's worth noting that RFC 6763 limits its use strictly to the use of "_tcp" and
"_udp" -- all non-TCP transports are coded as "_udp". So I believe the following
entries need to be added:

              | TXT        | _tcp            | [RFC6763]  |
              | TXT        | _udp            | [RFC6763]  |

---------------------------------------------------------------------------

RFC 4386 §2 defines Global SRV records for _ldap, _http, and _ocsp. So:

              | SRV        | _ldap            | [RFC4386]  |
              | SRV        | _http            | [RFC4386]  |
              | SRV        | _ocsp            | [RFC4386]  |

---------------------------------------------------------------------------

Regarding the existing entry:

              | SRV        | _tls            | [RFC6733]  |

RFC 6733 uses this name non-normatively in an example, as an intermediate
target while resolving an NAPTR record, and it is clearly a site-local
decision rather than a protocol element. I do not believe this should be
construed as reserving the name; its use in this context is clearly, in the
words of this document's introduction, "a matter of operational convention,
rather than defined protocol semantics."

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Minor nit: please consider using the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§4.1:

>  o  The table is to be maintained with entries sorted by the first
>    column (RR Type) and, within that, the second column (_Node Name).

Minor nit: I suggest that this document would be improved by sorting the table
in §4.3 in this order as well.
2018-10-08
13 Adam Roach Ballot comment text updated for Adam Roach
2018-10-08
13 Adam Roach
[Ballot discuss]
I'm glad to see this registry finally being set up, and want to thank everyone
who helped get the document ready. I understand …
[Ballot discuss]
I'm glad to see this registry finally being set up, and want to thank everyone
who helped get the document ready. I understand that this has been a large
archaeological undertaking, and that the relatively small size of the document
belies the large amount of actual work that went into it.

I have one top-level concern about the registry, a handful of proposed
corrections to the initial table, and some very minor editorial nits. I present
the following feedback in that order.

---------------------------------------------------------------------------

I have some very strong concerns about the handling for the "URI" RRTYPE.
As far as I can tell, the entries in the initial table were formed by starting
with the entries in
https://www.iana.org/assignments/enum-services/enum-services.xhtml, adding the
most popular entries from
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml,
("dccp", "sctp", "tcp", and "udp") and removing "web".

Please note that it is entirely possible that I've missed an important detail
here, and am merely confused.

My top-line concern is that, while the table established by this document
appears to intend to be a strict superset of the Enumservices table, there are
no instructions of any kind to the IANA that would result in these tables
remaining in sync -- that is, when a new service is added to the "Enumservice
Registrations" table, one might presume that it needs to also appear in the
new registry established by this document.

I would imagine this could be handled either by asking the IANA to add
instructions to the "Enumservice Registrations" table indicating that a
corresponding entry must be added to this one; or simply by including the
contents of that table by reference rather than by value into this one. I'm
pretty agnostic about which approach is taken.
2018-10-08
13 Adam Roach
[Ballot comment]
Related to the topic in my DISCUSS, I have three very closely related comments:

Comment 1: Was the removal of "web" intentional?

Comment …
[Ballot comment]
Related to the topic in my DISCUSS, I have three very closely related comments:

Comment 1: Was the removal of "web" intentional?

Comment 2: These initial entries misspell "xmpp" as "xmp"

Comment 3: Is it envisioned that all future URI entries in this table will
reference RFC 7533? That doesn't quite seem right. My instinct is that it would
serve the users of this registry better if:

- _iax refers to RFC 6315
- _acct refers to RFC 7566
- All other enumservice-based URI entries in the current table refer to
  RFC 6118
- RFC 7533 is mentioned elsewhere in the document as the reason enumservices
  appear in the table.

RFC 6763 §6 says:

  Every DNS-SD service MUST have a TXT record in addition to its SRV
  record, with the same name, even if the service has no additional
  data to store and the TXT record contains no more than a single zero
  byte.

It's worth noting that RFC 6763 limits its use strictly to the use of "_tcp" and
"_udp" -- all non-TCP transports are coded as "_udp". So I believe the following
entries need to be added:

              | TXT        | _tcp            | [RFC6763]  |
              | TXT        | _udp            | [RFC6763]  |

---------------------------------------------------------------------------

RFC 4386 §2 defines Global SRV records for _ldap, _http, and _ocsp. So:

              | SRV        | _ldap            | [RFC4386]  |
              | SRV        | _http            | [RFC4386]  |
              | SRV        | _ocsp            | [RFC4386]  |

---------------------------------------------------------------------------

Regarding the existing entry:

              | SRV        | _tls            | [RFC6733]  |

RFC 6733 uses this name non-normatively in an example, as an intermediate
target while resolving an NAPTR record, and it is clearly a site-local
decision rather than a protocol element. I do not believe this should be
construed as reserving the name; its use in this context is clearly, in the
words of this document's introduction, "a matter of operational convention,
rather than defined protocol semantics."

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Minor nit: please consider using the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§4.1:

>  o  The table is to be maintained with entries sorted by the first
>    column (RR Type) and, within that, the second column (_Node Name).

Minor nit: I suggest that this document would be improved by sorting the table
in §4.3 in this order as well.
2018-10-08
13 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2018-10-08
13 Warren Kumari Doh. I started the ballot, but forgot change the datatracker state.
2018-10-08
13 Warren Kumari IESG state changed to IESG Evaluation from Waiting for Writeup
2018-10-08
13 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2018-10-08
13 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-10-08
13 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-10-08
13 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-10-08
13 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-10-08
13 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-10-08
13 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-10-08
13 Alexey Melnikov [Ballot comment]
I am not sure how much value is there in the expert review part, as requirements on experts make their job pretty light.
2018-10-08
13 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2018-10-02
13 Cindy Morgan Placed on agenda for telechat - 2018-10-11
2018-10-02
13 Warren Kumari Ballot has been issued
2018-10-02
13 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2018-10-02
13 Warren Kumari Created "Approve" ballot
2018-10-02
13 Warren Kumari Ballot writeup was changed
2018-09-26
13 Erik Kline Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Erik Kline. Sent review to list.
2018-09-25
13 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-09-21
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani
2018-09-21
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani
2018-09-21
13 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-09-21
13 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dnsop-attrleaf-13. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dnsop-attrleaf-13. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

A new registry is to be created called the DNS Underscore Global Scoped Entry Registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry will be maintained via Expert Review as defined in RFC 8126. The new registry will include the following note:

NOTE: Under the NULL RR, the entry "_ta-*" is meant to denote all node names beginning with the string "_ta-". It does NOT refer to a DNS wildcard specification.

There are initial registrations in the new registry as follows:


+------------+------------------+------------+
| RR Type | _NODE NAME | REFERENCE |
+------------+------------------+------------+
| NULL | _ta-* {see note} | [RFC8145] |
| OPENPGPKEY | _openpgpkey | [RFC7929] |
| SMIMEA | _smimecert | [RFC8162] |
| SRV | _dccp | [RFC2782] |
| SRV | _ipv6 | [RFC5026] |
| SRV | _sip | [RFC5509] |
| SRV | _sctp | [RFC2782] |
| SRV | _tcp | [RFC2782] |
| SRV | _tls | [RFC6733] |
| SRV | _udp | [RFC2782] |
| SRV | _xmpp | [RFC3921] |
| TLSA | _dane | [RFC7671] |
| TLSA | _sctp | [RFC6698] |
| TLSA | _tcp | [RFC6698] |
| TLSA | _udp | [RFC6698] |
| TXT | _mta-sts | [MTA-STS] |
| TXT | _acme-challenge | [ACME] |
| TXT | _dmarc | [RFC7489] |
| TXT | _domainkey | [RFC6376] |
| TXT | _spf | [RFC7208] |
| TXT | _vouch | [RFC5518] |
| URI | _iax | [RFC7553] |
| URI | _acct | [RFC7553] |
| URI | _dccp | [RFC7553] |
| URI | _email | [RFC7553] |
| URI | _ems | [RFC7553] |
| URI | _fax | [RFC7553] |
| URI | _ft | [RFC7553] |
| URI | _h323 | [RFC7553] |
| URI | _ical-sched | [RFC7553] |
| URI | _ical-access | [RFC7553] |
| URI | _ifax | [RFC7553] |
| URI | _im | [RFC7553] |
| URI | _mms | [RFC7553] |
| URI | _pres | [RFC7553] |
| URI | _pstn | [RFC7553] |
| URI | _sctp | [RFC7553] |
| URI | _sip | [RFC7553] |
| URI | _sms | [RFC7553] |
| URI | _tcp | [RFC7553] |
| URI | _udp | [RFC7553] |
| URI | _unifmsg | [RFC7553] |
| URI | _vcard | [RFC7553] |
| URI | _videomsg | [RFC7553] |
| URI | _voice | [RFC7553] |
| URI | _voicemsg | [RFC7553] |
| URI | _vpim | [RFC7553] |
| URI | _xmp | [RFC7553] |
+------------+------------------+------------+

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-09-17
13 Roman Danyliw Request for Last Call review by SECDIR Completed: Ready. Reviewer: Roman Danyliw.
2018-09-13
13 Jean Mahoney Request for Last Call review by GENART is assigned to Erik Kline
2018-09-13
13 Jean Mahoney Request for Last Call review by GENART is assigned to Erik Kline
2018-09-12
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Roman Danyliw
2018-09-12
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Roman Danyliw
2018-09-11
13 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-09-11
13 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-09-25):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-ietf-dnsop-attrleaf@ietf.org, dnsop-chairs@ietf.org, …
The following Last Call announcement was sent out (ends 2018-09-25):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-ietf-dnsop-attrleaf@ietf.org, dnsop-chairs@ietf.org, Benno Overeinder <benno@NLnetLabs.nl>, dnsop@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, benno@NLnetLabs.nl, warren@kumari.net
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-dnsop-attrleaf-13.txt> (DNS Scoped Data Through "Underscore" Naming of Attribute Leaves) to Best Current Practice


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Scoped Data Through
"Underscore" Naming of Attribute Leaves'
  <draft-ietf-dnsop-attrleaf-13.txt> as Best Current Practice

PLEASE NOTE: The draft-ietf-dnsop-attrleaf-fix and
draft-ietf-dnsop-attrleaf documents are very closely related. Please
read **both** of them when commenting.


The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-09-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Formally, any DNS resource record may occur under any domain name.
  However some services have defined an operational convention, which
  applies to DNS leaf nodes that are under a DNS branch having one or
  more reserved node names, each beginning with an _underscore.  The
  underscored naming construct defines a semantic scope for DNS record
  types that are associated with the parent domain, above the
  underscored branch.  This specification explores the nature of this
  DNS usage and defines the "DNS Global Underscore Scoped Entry
  Registry" with IANA.  The purpose of the Underscore registry is to
  avoid collisions resulting from the use of the same underscore-based
  name, for different services.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc2181: Clarifications to the DNS Specification (Proposed Standard - IETF stream)
    rfc2782: A DNS RR for specifying the location of services (DNS SRV) (Proposed Standard - IETF stream)
    rfc5518: Vouch By Reference (Proposed Standard - IETF stream)
    rfc6698: The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA (Proposed Standard - IETF stream)
    rfc8145: Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) (Proposed Standard - IETF stream)
    rfc8162: Using Secure DNS to Associate Certificates with Domain Names for S/MIME (Experimental - IETF stream)
    rfc5026: Mobile IPv6 Bootstrapping in Split Scenario (Proposed Standard - IETF stream)
    rfc7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Informational - Independent Submission Editor stream)
    rfc7929: DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP (Experimental - IETF stream)
    rfc5509: Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream)
    draft-ietf-acme-acme: Automatic Certificate Management Environment (ACME) (None - IETF stream)
    rfc3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence (Proposed Standard - IETF stream)
    rfc6733: Diameter Base Protocol (Proposed Standard - IETF stream)
    draft-ietf-uta-mta-sts: SMTP MTA Strict Transport Security (MTA-STS) (None - IETF stream)
    rfc7553: The Uniform Resource Identifier (URI) DNS Resource Record (Informational - IETF stream)
    rfc7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (Proposed Standard - IETF stream)
    rfc7671: The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance (Proposed Standard - IETF stream)



2018-09-11
13 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-09-11
13 Warren Kumari Last call was requested
2018-09-11
13 Warren Kumari Ballot approval text was generated
2018-09-11
13 Warren Kumari Ballot writeup was generated
2018-09-11
13 Warren Kumari IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2018-09-11
13 Warren Kumari Last call announcement was changed
2018-08-23
13 Warren Kumari IESG state changed to AD Evaluation::AD Followup from AD is watching::AD Followup
2018-08-21
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-08-21
13 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-13.txt
2018-08-21
13 (System) New version approved
2018-08-21
13 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-08-21
13 Dave Crocker Uploaded new revision
2018-08-13
12 Warren Kumari As discussed (Mon, Aug 6) -- revised ID needed for the _ta-XXXX case, author is busy at the moment, will resubmit once done.
2018-08-13
12 Warren Kumari IESG state changed to AD is watching::Revised I-D Needed from Publication Requested
2018-07-21
12 Benno Overeinder
Summary

Review of draft-ietf-dnsop-attrleaf, combined with
draft-ietf-dnsop-attrleaf-fix.


1)
Document Type:
  BCP


2)
Technical Summary:

  Original uses of an underscore character as a …
Summary

Review of draft-ietf-dnsop-attrleaf, combined with
draft-ietf-dnsop-attrleaf-fix.


1)
Document Type:
  BCP


2)
Technical Summary:

  Original uses of an underscore character as a domain node name
  prefix, which creates a space for constrained interpretation of
  resource records, were specified without the benefit of an IANA
  registry.  This produced an entirely uncoordinated set of name-
  creation activities, all drawing from the same namespace.  A registry
  now has been defined.  However the existing specifications that use
  underscore naming need to be modified, to be in line with the new
  registry.  This document specifies those changes.  The changes
  preserve existing software and operational practice, while adapting
  the specifications for those practices to the newer underscore
  registry model.

Working Group Summary:

  This document has a very long history, with multiple, extended
  periods of hiatus.  It's recent activity received substantial
  working group participant commentary that produced substantial
  changes to the design of the proposed registry.  The latest rounds
  comments were primarily about minor editorial points or
  clarification of implications, rather than changes to the design.
  Multiple participants have commented on the work, over time and
  recently.  They are cited in the document Acknowledgements
  section.

  Was there anything in WG process that is worth noting? For example,
  was there controversy about particular points or were there
  decisions where the consensus was particularly rough?

  WG criticism of the design approach produced at least two major
  revisions to the design.

Document Quality:

  This work is explicitly designed to require no software or
  operational changes.  Changes is necessiates are restricted to the
  relevant IETF documents, to use standard registry processes.

  There are no other reviewers that merit special mentioning.

Personnel:

  Document shepherd: Benno Overeinder
  Area Director:    Warren Kumari


3)

The shepherd was involved at the final stages of the draft and its
Working Group Last Call.  Tim Wicinski (DNSNOP chair) was involved in
the earlier version of the document, and advised on the split-up of
the original draft-ietf-dnsop-attrleaf into two documents
draft-ietf-dnsop-attrleaf and draft-ietf-dnsop-attrleaf-fix for scope
and clarity.

We did talk with application area to have good reviews from them.


4)
The document shepherd has no any concerns about the depth or breadt of
the reviews.


5)
The companion document, draft-ietf-dnsop-attrleaf-fix, updates a large
number of existing RFCs.  This document and the companion should be
published simultaneously.  The specified updates will need review for
adequacy and could cause significant delay in publication. It will be
useful to find a way to expedite and coordinate these additional
reviews.


6)
There are not other specific concerns or issues.


7)
The author has confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79
have already been filed.


8)
There has no IPR disclosure been filed that references this document.


9)
There is a solid WG consensus behind the document. The document has
been reviewed by a fair group of individuals (almost twenty) over the
past period.  Constructive comments were made on the mailing list and
feedback was incorporated in the document or comments were settled on
the mailing list.


10)
There has been no indications of discontent with respect to the document.


11)
No nits.


12)
For the documnet no formal review criteria are needed.  One concern
might be conformance to IANA requirements for creating a registry.
IANA's documented guidance for this has been followed.


13)
All references within this document been identified as either normative or informative.


14)
The accompanying document draft-ietf-dnsop-attrleaf-fix depends this
draft-ietf-dnsop-attrleaf.  Both documents are send together in a
bundle to the AD.


15)
There or no downward normative references references (see RFC 3967).


16)
draft-ietf-dnsop-attrleaf does not alter any existing documents.

draft-ietf-dnsop-attrleaf-fix updates a large number of existing RFCs;
they are listed in the Updates document header.


17)
The IANA considerations section is adequate; it is consistent withthe
body of the document.


18)
DNS Underscore Global Scoped Entry Registry

  Guidance for expert review is in Section 5 of
  draft-ietf-dnsop-attrleaf.  Expert review concerns basic matters of
  form and small amounts of registry detail.  It does not require
  deep knowledge of technical aspects of what the larger topic for
  which a registry entry is needed, not deep knowledge of DNS
  technology.


19)
The documents were produced with an XML editor and were processed
through the IETF's ID Nits engine, and txt files were produced from
the XML by the IETF's Internet Drafts submission process.
2018-07-21
12 Benno Overeinder Responsible AD changed to Warren Kumari
2018-07-21
12 Benno Overeinder IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-07-21
12 Benno Overeinder IESG state changed to Publication Requested
2018-07-21
12 Benno Overeinder IESG process started in state Publication Requested
2018-07-21
12 Benno Overeinder Changed document writeup
2018-07-21
12 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-12.txt
2018-07-21
12 (System) New version approved
2018-07-21
12 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-07-21
12 Dave Crocker Uploaded new revision
2018-07-17
11 Benno Overeinder IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-07-15
11 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-11.txt
2018-07-15
11 (System) New version approved
2018-07-15
11 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-07-15
11 Dave Crocker Uploaded new revision
2018-06-25
10 Benno Overeinder IETF WG state changed to In WG Last Call from WG Document
2018-06-22
10 Tim Wicinski Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl> from "Tim Wicinski" <tjw.ietf@gmail.com>
2018-06-22
10 Tim Wicinski Document shepherd changed to Benno Overeinder
2018-06-05
10 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-10.txt
2018-06-05
10 (System) New version approved
2018-06-05
10 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-06-05
10 Dave Crocker Uploaded new revision
2018-05-22
09 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-09.txt
2018-05-22
09 (System) New version approved
2018-05-22
09 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-05-22
09 Dave Crocker Uploaded new revision
2018-05-22
08 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-08.txt
2018-05-22
08 (System) New version approved
2018-05-22
08 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-05-22
08 Dave Crocker Uploaded new revision
2018-03-31
07 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-07.txt
2018-03-31
07 (System) New version approved
2018-03-31
07 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-03-31
07 Dave Crocker Uploaded new revision
2018-03-28
06 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-06.txt
2018-03-28
06 (System) New version approved
2018-03-28
06 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-03-28
06 Dave Crocker Uploaded new revision
2018-03-25
05 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-05.txt
2018-03-25
05 (System) New version approved
2018-03-25
05 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-03-25
05 Dave Crocker Uploaded new revision
2018-03-22
04 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-04.txt
2018-03-22
04 (System) New version approved
2018-03-22
04 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-03-22
04 Dave Crocker Uploaded new revision
2018-03-19
03 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-03.txt
2018-03-19
03 (System) New version approved
2018-03-19
03 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2018-03-19
03 Dave Crocker Uploaded new revision
2017-09-30
02 (System) Document has expired
2017-03-29
02 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-02.txt
2017-03-29
02 (System) New version approved
2017-03-29
02 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2017-03-29
02 Dave Crocker Uploaded new revision
2017-03-05
01 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-01.txt
2017-03-05
01 (System) New version approved
2017-03-05
01 (System) Request for posting confirmation emailed to previous authors: Dave Crocker <dcrocker@bbiw.net>
2017-03-05
01 Dave Crocker Uploaded new revision
2016-09-16
00 (System) Document has expired
2016-03-15
00 Tim Wicinski Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com>
2016-03-15
00 Tim Wicinski Document shepherd changed to Tim Wicinski
2016-03-15
00 Tim Wicinski Changed consensus to Yes from Unknown
2016-03-15
00 Tim Wicinski Intended Status changed to Best Current Practice from None
2016-03-15
00 Tim Wicinski This document now replaces draft-crocker-dns-attrleaf instead of None
2016-03-15
00 Dave Crocker New version available: draft-ietf-dnsop-attrleaf-00.txt