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 |
---|---|---|---|
2019-03-20
|
16 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-03-01
|
16 | (System) | RFC Editor state changed to AUTH48 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 |
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 |
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 |
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): From: The IESG To: IETF-Announce CC: draft-ietf-dnsop-attrleaf@ietf.org, dnsop-chairs@ietf.org, Benno Overeinder , dnsop@ietf.org, … The following Last Call announcement was sent out (ends 2018-09-25): From: The IESG To: IETF-Announce CC: draft-ietf-dnsop-attrleaf@ietf.org, dnsop-chairs@ietf.org, Benno Overeinder , dnsop@ietf.org, Tim Wicinski , benno@NLnetLabs.nl, warren@kumari.net Reply-To: ietf@ietf.org Sender: Subject: Last Call: (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' 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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |