Subject: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Mar 2018 17:35:29 -0700

Folks,

I'll limit what should be an extensive and elaborate apology to just 
this: I'm sorry for the year of inactivity.

The -03 version should provide some useful substance of progress.

I've gone over last summer's comments and the -03 version should reflect 
what the wg agreed to.  Basically, it has been significantly 
streamlined, essentially to reflect a clean-sheet model of the world. 
That is, it doesn't deal with the ugliness that SRV, et al, created.  It 
merely establishes the two registries we need, long term, and populates 
them.  This document should have continuing utility.

-03 defines two registries, 'global' and 'second-level'.  I'm suspicious 
of how short the global one is, though it does make sense.

As noted in the document, absent major concerns with the substance of 
the document, please send me or the list s/old/new/ types of change 
suggestions, and if the change is for a reference, I'd love the 
suggestion to be <reference> xml...

A second document will attempt to fix up the uglinesses in some existing 
documents, to get them to align with a world that has these registries. 
It should be viewed as a transitional document, though we all know how 
glacial 'transitions' are in the Internet...

Deciding how to pursue that reasonably has been the effort.  The changes 
this 'fixes' document defines will be to documentation, but not to 
existing operation.  Existing uses in the field will be preserved.

Here's the approach I'm taking:

1. Simple underscore usage

    For many/most specifications that use underscore naming, the text 
merely says to use it.  They are straightforward.

    These specifications need to be listed in this document, explicitly, 
so that later updates to them will know to deal with the revisions 
called for by this document.

    But this document doesn't really need s/old/new kinds of precise 
detail for them. Rather than provide precise language for changing each 
of these, I propose to provide some generic text, and generic IANA 
Considerations.  This will permit this Fixes document to be cited as 
Updating those RFCs.

2. SRV and URI

    These need more detailed text, very much in the s/old/new style.

    The current text in them does a use-by-reference of existing tables 
defined for other purposes.  The Update text will, instead, specify a 
requirement for adding entries in the Global or Common Second-Level 
registries.

d/

-------- Forwarded Message --------

Name:		draft-ietf-dnsop-attrleaf
Revision:	03
Title:		DNS Scoped Data Through '_Underscore' Naming of Attribute Leaves
Document date:	2018-03-19
Group:		dnsop
Pages:		14
URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-03.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-03
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-03

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: tjw ietf <[email-masked]>
Date: Tue, 20 Mar 2018 07:41:20 +0000

Dave

First, thanks for resurrecting this for us.   I think splitting draft into
two parts probably makes sense after that last round of comments.

However, we need to go find those App Area folks (hence cc'ing Murray here)
and run this past them.

If the group likes this split, we can progress attrleaf first and give you
time to work on the second document.

Tim

On Tue, Mar 20, 2018 at 12:35 AM, Dave Crocker <[email-masked]> wrote:

> Folks,
>
> I'll limit what should be an extensive and elaborate apology to just this:
> I'm sorry for the year of inactivity.
>
> what the wg agreed to.  Basically, it has been significantly streamlined,
> essentially to reflect a clean-sheet model of the world. That is, it
> doesn't deal with the ugliness that SRV, et al, created.  It merely
> establishes the two registries we need, long term, and populates them.
> This document should have continuing utility.
>
> As noted in the document, absent major concerns with the substance of the
> document, please send me or the list s/old/new/ types of change
> suggestions, and if the change is for a reference, I'd love the suggestion
> to be <reference> xml...
>
>
> documents, to get them to align with a world that has these registries. It
> should be viewed as a transitional document, though we all know how glacial
> 'transitions' are in the Internet...
>
> this 'fixes' document defines will be to documentation, but not to existing
> operation.  Existing uses in the field will be preserved.
>
>
>    These specifications need to be listed in this document, explicitly, so
> that later updates to them will know to deal with the revisions called for
> by this document.
>
>    But this document doesn't really need s/old/new kinds of precise detail
> for them. Rather than provide precise language for changing each of these,
> I propose to provide some generic text, and generic IANA Considerations.
> This will permit this Fixes document to be cited as Updating those RFCs.
>
>
> 2. SRV and URI
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Mar 2018 06:39:03 -0700

> However, we need to go find those App Area folks (hence cc'ing Murray here)

tim, good idea.  query has been sent to the art mailing list.

('app' area, per se, was retired, and folded with rai.)

d/

---

From: "John R. Levine" <[email-masked]>
Date: 20 Mar 2018 16:31:36 +0000

> -03 defines two registries, 'global' and 'second-level'.  I'm suspicious of 
> how short the global one is, though it does make sense.

It's missing _dmarc, and the type names from the Enumservice registry 
which are used to name URI records.

> requirement for adding entries in the Global or Common Second-Level 

The second level registry, though, is a problem, because it tries to 
redefine the naming rules for SRV records.  RFC 2782 said that SRV second 
level names are from the services in Assiged Numbers STD 2.  RFC 3400 
abolished STD 2 in favor of an IANA registry.  That registry, the Service 
Name and Transport Protocol Port Number Registry, was cleaned up by RFC 
6335 which reiterates the fact that the service names in that registry are 
the services used to name SRV records.  RFC 7335 states that URI records 
are named the same as SRV, and also says you can use enumservice 
_subtype._type.

We need to change the description of the second level name registry to say 
that SRV and URI are special, they use names from Ports and Services at 
the second level and URI uses enumservice subtypes, and take out all of 
the SRV entries.  What's left is the grabbag of second level names 
used for other stuff like NAPTR and _adsp._domainkey.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Mar 2018 09:49:26 -0700

On 3/20/2018 9:31 AM, John R. Levine wrote:
>> -03 defines two registries, 'global' and 'second-level'.  I'm 
>> suspicious of how short the global one is, though it does make sense.
> 

_dmarc.  thanks.

as for enumservice, see below.

>> 2. SRV and URI
...
> We need to change the description of the second level name registry to 
> say that SRV and URI are special, they use names from Ports and Services 
> at the second level and URI uses enumservice subtypes, and take out all 
> of the SRV entries.  What's left is the grabbag of second level names 

No.  "Special" invites "errors", for on-going administration and 
operations.  I'm trying to make things simpler and less tangled.

We need to move away from the complexity created by having special rules 
for some entries in the registry.

Rather, we need to change the documents that are trying to be special 
to, instead, make them be mundane.  Hence the need for detailed text 
changes in the proposed, second draft.

d/

ps.  I thought the URI RR had no current actual use (or at least very 
little.)

---

From: "John R. Levine" <[email-masked]>
Date: 20 Mar 2018 18:11:08 +0000

After some back and forth with Dave, I realized I missed what seems to be 
to be a large change: this draft redefines the naming rules for SRV and 
URI.

The current rule is that SRV is _service._protocol where the protocol is 
from a short list including _tcp and _udp and the service is from the IANA 
Service Name and Transport Protocol Port Number Registry most recently 
defined by RFC 6335.  This draft proposes that the service names now come 
from a newly defined second-level name registry in the draft. The URI 
record uses the same namespace, but nobody believes it's widely used so 
it's less of an issue.

This seems to be a large change for very little benefit, and 
unlikely to be backward compatible unless we can identify every service 
name now in use with SRV which seems unlikely.

R's,
John

> G'day. This concerns an activity in dnsop, but the wg chair has quite 
> reasonably suggested running a significant, proposed change past apps folk, 
> since the work affects a number of existing and future apps efforts.   (In 
> fact, the effort was first triggered by the DKIM work, more than 12 years 
> ago...)
>
> The domain of discourse is _underscore domain names, used for defining a 
> special place to use some DNS resource records, such as TXT and SRV.
>
> There are quite a few, existing documents that define such use, all without 
> the benefit of a common registry.  Hence the danger of name collision.  The 
> attrleaf effort is seeking to define a registry for holding existing 
> _underscore names and defining new ones.
>
> Besides defining the registry, the task requires updating existing 
> specifications to use it.  The attrleaf draft has attempted to perform both 
> tasks in a single document, but this has made for a confused and confusing 
> document. (There's a larger lesson here, in spec writing...)
>
> More recent discussions (well, actually, last August) in dnsop, pointed 
> toward splitting registry definition from existing document updating, and the 
> note below points to a new draft that does the first.  The note also charts 
> out the plan for the updating document.
>
> Comments?
>
> d/
>
> Subject: [DNSOP] Fwd: New Version Notification for 
> draft-ietf-dnsop-attrleaf-03.txt
> Date: Mon, 19 Mar 2018 17:35:29 -0700
> From: Dave Crocker <[email-masked]>
> Reply-To: [email-masked]
> Organization: Brandenburg InternetWorking
> To: dnsop <[email-masked]>
>
> Folks,
>
> I've gone over last summer's comments and the -03 version should reflect what 
> the wg agreed to.  Basically, it has been significantly streamlined, 
> essentially to reflect a clean-sheet model of the world. That is, it doesn't 
> deal with the ugliness that SRV, et al, created.  It merely establishes the 
> two registries we need, long term, and populates them.  This document should 
> have continuing utility.
>
> document, please send me or the list s/old/new/ types of change suggestions, 
> and if the change is for a reference, I'd love the suggestion to be 
> <reference> xml...
>
>
> Deciding how to pursue that reasonably has been the effort.  The changes this 
> 'fixes' document defines will be to documentation, but not to existing 
>   For many/most specifications that use underscore naming, the text merely 
> says to use it.  They are straightforward.
>
> that later updates to them will know to deal with the revisions called for by 
> this document.
>
> for them. Rather than provide precise language for changing each of these, I 
> propose to provide some generic text, and generic IANA Considerations.  This 
> will permit this Fixes document to be cited as Updating those RFCs.
>
>
> 2. SRV and URI
>

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: P Vix <[email-masked]>
Date: Tue, 20 Mar 2018 18:32:51 +0000

Harmonization for the sake of harmonization is bad, and very little Internet System technology gets it. Just do new stuff better.

On March 20, 2018 6:11:08 PM UTC, "John R. Levine" <[email-masked]> wrote:
>doesn't 
>suspicious of 
>the 
>suggestions, 
>merely 
>detail 
>> URL:
>https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-03.txt
>> Status:        
>https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
>> Htmlized:       
>https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-03
>> Htmlized: 
>https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Mar 2018 19:30:44 -0700

On 3/20/2018 11:32 AM, P Vix wrote:
> Harmonization for the sake of harmonization is bad, and very little 
> Internet System technology gets it. Just do new stuff better.

I agree completely. So please forgive my not understanding how your 
first and third comments are relevant to the current topic, which 
pertains to ensuring that new behaviors use the new model.

d/

---

From: "John R. Levine" <[email-masked]>
Date: 21 Mar 2018 11:05:45 +0000

> I agree completely. So please forgive my not understanding how your first and 
> third comments are relevant to the current topic, which pertains to ensuring 
> that new behaviors use the new model.

I'm not Paul, but I'm guessing that he is referring to retroactively 
changing the naming rules for SRV and other RRs, rather than documenting 
existing practice.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Mar 2018 06:05:22 -0700

> changing the naming rules for SRV and other RRs, rather than documenting 

John,

Your attempt at clarification is equally confusing to me, since it, too, 
seems to have nothing to do with the current effort.

The effort is to create a registry -- which obviously differs from 
existing practice -- and to have that registry be used, going forward. 
Both the creation and the future use deviate fundamentally from 
'existing practice'.

d/

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Mar 2018 10:30:51 -0400

--On Wednesday, March 21, 2018 06:05 -0700 Dave Crocker
<[email-masked]> wrote:

>>>>  Harmonization for the sake of harmonization is bad, and
>>>> very little Internet System technology gets it. Just do
>>>> new stuff better.
>> 
>>> I agree completely. So please forgive my not understanding
>>> how your first and third comments are relevant to the
>>> current topic, which pertains to ensuring that new
>>> behaviors use the new model.
>  
>> I'm not Paul, but I'm guessing that he is referring to
>> retroactively changing the naming rules for SRV and other RRs,
>> rather than documenting existing practice.

> Your attempt at clarification is equally confusing to me,
> since it, too, seems to have nothing to do with the current
> effort.
> 
> The effort is to create a registry -- which obviously differs
> from existing practice -- and to have that registry be used,
> going forward. Both the creation and the future use deviate
> fundamentally from 'existing practice'.

I have to agree with Dave.

There is a strong case to be made that the introduction of the
underscore convention was a kludge that violated fundamental
design assumptions of the DNS and that it was added without
considering, much less acting on, what other changes would be
needed to support it smoothly.  One can imagine other, better,
ways to do the same thing.   I did consider including it as
another example in RFC 8324 but decided against it, which may
not have been the right decision.   While I think I understand
at least some of the reasons why alternatives to the underscore
convention were not considered seriously, much less adopted, it
is much too late now to change things and this proposal, AFAICT,
has absolutely nothing to do with that or any other change to
existing protocol or operational practices anyway.

Given that one is going to have a list of keywords that are
expected to expand over time (or demonstrated to do so whether
it was initially expected or not), the absolutely minimal thing
that can be done in the interest of _future_ damage is to create
a registry of the keywords that are being used in the hope of
minimizing the risk of inadvertent use of the same string for
different purposes.  As Graham points out, we recognized that
problem with mail header field names, but there are many other
examples as well and I note that we've been gradually altering
existing registry definitions to move toward "let's at least
prevent conflicts" rather than "registration indicates the IETF
needs has blessed this use" (media type and URN namespace
registries come immediately to mind).

AFAICT, the only change that is being made to existing specs is
to provide that, if new keywords are used/added, they should
probably be registered too.   That is not either harmonization
for its own sake or a protocol change; it is just an
administrative adjustment in how new keywords or actions are
documented.

I think the observation that we are needing to do this again
suggests something else that I hope the IESG can consider and
adopt as part of its review procedures (e.g., maybe in the
shepherd template questions).  We probably need to be much more
aggressive about asking whether new protocols or specs include,
or are creating, lists of things that might be expanded in the
future, identifying them, and just create the registries the
first time around.  If FCSF is the default (as Dave suggests
here), such a requirement does not imply significant new work or
long-term commitments or, e.g., designated experts.   It seems
to me that would be far preferable to having to go through these
later exercises of registry creation (including gathering old
data to seed them) that seem to almost always stir up
controversies that have little or nothing to do with the
registries themselves.   

However, that suggestion, which I trust the ART ADs are reading
and able to share with their colleagues, is very much about
doing things right in the future rather than about Dave's modest
and focused proposal to, as far as I'm concerned, is just fixing
an earlier omission and thereby lowering risk of name conflicts
going forward.

best,
    john

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Mar 2018 08:03:21 -0700

dave, i wasn't going to reply at all, since your snark is a turn-off. 
however, john decided to make this thing real, so now i'm stuck with it.

srv has a registry. that's working. that need not change.

adding another registry for other rr types who want to have well known 
underscored names will harm nobody and i'm unopposed.

paul

re:

Dave Crocker wrote:
>> changing the naming rules for SRV and other RRs, rather than
>> documenting existing practice.
>
>
> John,
>

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Mar 2018 08:13:53 -0700

John C Klensin wrote:
> needed to support it smoothly.  ...

jon postel raised the same point (as the rfc editor when SRV was 
published.) i'll tell you what i told him: we needed only one thing, 
which was an identifier that could never conflict with a "host name". to 
do that, we added a character (_) to the front of these service and 
transport names which was not in the syntax of the old HOSTS.TXT definition.

it was minimal, and not intended to be generalizable, but it violated 
_no_ design assumption, fundamental or otherwise, of the DNS.

where SRV was a process violation is that it tried to cover existing 
systems like the then-young "world wide web" with some load balancing 
logic but without any geo-ip logic which has since been shown to be 
widely desired.

however, SRV works for the people and protocols who use it, and the 
experience we gained from "names that pass in the night" underscoring 
has informed the community's long term understanding of what we need.

jon didn't love it but he understood it and he withdrew his objection.

i support creating a real registry for future reserved-word DNS labels.

i just don't want to apply it to SRV.

-- 
P Vixie

---

From: "John R. Levine" <[email-masked]>
Date: 21 Mar 2018 15:14:47 +0000

> AFAICT, the only change that is being made to existing specs is to 
> provide that, if new keywords are used/added, they should probably be 
> registered too.

The proposal changes the spec for naming SRV records, by replacing the 
existing service name registry with a new, different one, and vastly 
shrinking the list of known names.  To me, that is nuts.  It will 
retroactively make an unknown set of existing SRV records non-standard.

The part about adding new names as they are defined is fine.  Rewriting 
history is not.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 21 Mar 2018 16:26:11 +0000

Since there seems to be some question about what I'm concerned about, 
here's a hacked up version of the draft that establishes the same 
registries, but documents existing practice and does not change the 
meaning or validity of any existing DNS names.

https://www.taugh.com/draft-levine-dnsop-attrleaf-00.html

It needs a few more entries but the structure should be OK.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Mar 2018 11:17:24 -0700

> dave, i wasn't going to reply at all, since your snark is a turn-off. 

Snark?  You think my note was "crotchety, snappish; sarcastic, 
impertinent, or irreverent"?  It wasn't any of those things, though 
perhaps it's interesting you thought it was.  But only perhaps.

Your note made no obvious sense to me, since it began with what is 
really a platitude (that I really do agree with) and ended with a 
generality that had no obvious linkage to the current work.

> underscored names will harm nobody and i'm unopposed.

Much of the discussion of the current topic -- previously and now -- has 
tended to stray from the pragmatics, whereas that is the only thinking 
driving my concerns and suggestions.  In particular, some people seem to 
have a mystical -- or equally impractical -- view of how name collisions 
will be avoided between independent registries making assignments out of 
the same name space.

I prefer to take as simple an approach as possible: have a single 
registry control all allocations out of a name space.

So if you will please explain:

   1.  How the SRV underscore registration process and the new 
registration process will avoid collisions

   2.  How people revising existing specs that use _underscore naming 
will know that their document needs to use the new registry

it would be helpful.

d/

---

From: "John R. Levine" <[email-masked]>
Date: 21 Mar 2018 18:36:13 +0000

On Wed, 21 Mar 2018, Dave Crocker wrote:
> I prefer to take as simple an approach as possible: have a single registry 
> control all allocations out of a name space.

It's a little late for that.  The SRV RFC was published 18 years ago.

How exactly do you plan to grandfather all of the existing SRV records if 
you don't use the existing registry that existing records use to select 
their existing names?

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Mar 2018 11:43:34 -0700

> registry control all allocations out of a name space.

It occurs to me that some folk might not have a perfect memory of a 
dnsop working group agreement from Aug, 2017.  So here's a tag into it:

    https://www.ietf.org/mail-archive/web/dnsop/current/msg20708.html

d/

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Mar 2018 19:08:47 +0000

Dave,

> On 21 Mar 2018, at 18:36, John R. Levine <[email-masked]> wrote:
> 
>> I prefer to take as simple an approach as possible: have a single registry control all allocations out of a name space.
> 
> How exactly do you plan to grandfather all of the existing SRV records if you don't use the existing registry that existing records use to select their existing names?

Possibly related to this question: what is the relationship of this draft to RFC 6335?

Thank you,
Alexey

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Mar 2018 14:15:38 -0700

> Possibly related to this question: what is the relationship of this draft to RFC 6335?

Can separate registries be 'related'?  Anyhow, I think these aren't.

Perhaps you could ask a more detailed question?

d/

---

From: Ray Bellis <[email-masked]>
Date: Wed, 21 Mar 2018 21:57:04 +0000

> retroactively make an unknown set of existing SRV records non-standard.

I'm with John on this one.

I recall discussing attrlea fwith Dave way back at the Orlando IETF.

I argued then that we need a top level registry for the likes of _tcp,
_udp, _dmarc, etc, but I see absolutely no need for a new shrunken
registry to replace the port and services registry already used for SRV.

By all means define a second level registry for those two-level
underscore labels that aren't used for SRV, though.

Ray

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Mar 2018 08:12:43 -0700

On 3/20/2018 9:31 AM, John R. Levine wrote:
> redefine the naming rules for SRV records.  RFC 2782 said that SRV 
> second level names are from the services in Assiged Numbers STD 2.  RFC 
> 3400 abolished STD 2 in favor of an IANA registry.  That registry, the 
> Service Name and Transport Protocol Port Number Registry, was cleaned up 
> by RFC 6335 which reiterates the fact that the service names in that 
> registry are the services used to name SRV records.  RFC 7335 states 
> that URI records are named the same as SRV, and also says you can use 
> enumservice _subtype._type.
> 

Folks,

Level set:

      *****
      I think what hung me up was mostly missing the reference to
      'second-level' while focusing too much on the presence of
      the word 'special'.
      *****

For any use of an underscore first-level name, that also uses a 
second-level name, the authority over that second-level belongs entirely 
and solely to that first-level name.

    ..._my-second._firsta.example

and

    ..._my-second._firstb.example

have no conflict.

So here's what needs to be clearer in the main attrleaf document and the 
fixup document:

      All /first-level/ uses of underscore names MUST be registered in
      the single, /global/ registry, for in order to avoid collisions.

      For second-level names, any name assignment scheme can be used, as
      long as it prevents collisions /within the scope of its own
      first-level name/.

In the case of SRV, for example, that means that for the core SRV 
template specification document:

      1. The first-level, _Proto name assignment text has to be updated 
to use the new, Attrleaf global table.

      2. The second-level _Service name assignment text can remain 
unchanged, per RFC 6335.

Point #2 is actually not 'special' at all.  I'd entirely missed that the 
very strong need to do the first-level fixup did not also require 
messing with the existing second-level.

As for the proposed 'common, second-level' table...

Given that this seems to reduce the Attrleaf 'common second-level' table 
to only _adsp, I think it best to remove that table entirely from the 
main attrleaf document, and instead have the separate fixup document 
contain some text specific to the DKIM document's domain naming scheme, 
to indicate how future second-level names should be assigned.  Since 
ADSP is historic, specifying modification to it doesn't make sense to 
modify it.

Thoughts?

d/

---

From: Ray Bellis <[email-masked]>
Date: Thu, 22 Mar 2018 16:55:16 +0000

> messing with the existing second-level.

That's the conversation I thought we'd had in Orlando :p

Ray

---

From: "John Levine" <[email-masked]>
Date: 23 Mar 2018 18:02:47 +0000

>    https://www.ietf.org/mail-archive/web/dnsop/current/msg20708.html

I see a message on dnsop from you proposing a bunch of things
including "rationalizing" names, and comments from Andrew and Peter
saying they like that approach.

Maybe I'm odd, but I wouldn't call a change to SRV that retroactively
breaks some unknown and probably large number of existing SRV records
"rationalizing".

I agree that a registry of top level underscore names would be a good
idea.  I completely disagree with the assertion that we need to make
any significant change to the way the second level names are managed.

A good way to rationalize them would be to document the the rules in
one place with pointers to the relevant registries.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Mar 2018 14:28:47 -0400

> saying they like that approach.

I think, to be clear, what I was saying I liked was the document
splitting.  This is because I sent Dave feedback on his original
approach back a decade or so ago, worried about how the registry won't
really be possible because of the multiple levels and so on.

The basic problem is that underscore labels are a mess and needed a
registry to begin with.  

> one place with pointers to the relevant registries.

I would be willing to review additional proposals (including that one)
for how to make this whole thing less of a disaster, yes.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 23 Mar 2018 15:35:45 -0700

> saying they like that approach.

I am not finding any message from me with that word in it, so I've no 
idea what you are referring to.  Better still, my guess is that you are 
reacting to one or more messages from me before the one I sent that said 
'Level set'.

Take a look, at the latest draft.  If you have concerns with it, please 
point to specific text in it.

d/

---

From: "John R Levine" <[email-masked]>
Date: 24 Mar 2018 09:15:59 +0000

> I am not finding any message from me with that word in it, so I've no idea 
> what you are referring to.

>    https://www.ietf.org/mail-archive/web/dnsop/current/msg20708.html

It says:

  2. Create a separate document that specifies modifications to the SRV and
  URI documents, rationalizing the use of underscore names, through the
  mechanism defined in -attrleaf-.

> Take a look, at the latest draft.  If you have concerns with it, please point 
> to specific text in it.

Same problems that Vixie, Andrei, and I have been pointing to all along. 
It retroactively redefines SRV and contradicts RFC 6335.

See the link I sent yesterday to a version I wrote that sets up a registry 
that documents existing practice without trying to change history.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John Levine" <[email-masked]>
Date: 24 Mar 2018 14:25:14 +0000

Finally catching up.

>    ..._my-second._firstb.example

Aha.  That's somewhat different from what I gathered you were saying before.

>      2. The second-level _Service name assignment text can remain 

Seems right.  If we want to deal with URI names it needs a similar
update to RFC 6117 to put the enumservice type names into the
attrleaf table with a pointer back to the enumservice registry
for the second level subtypes.

>ADSP is historic, specifying modification to it doesn't make sense to 

Agree, no need to set up a registry for one dusty name.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Mar 2018 02:36:53 -0400

Taking another look at this now that the IETF dust has settled.

First, when I wrote my earlier note on the 21st, I had just
glanced through the spec, not studied it, and was under the
impression that either the SRV entries and registry would not be
affected or that all entries in the SRV registry would be folded
into the new one.  The former would be fine, the latter
plausible if it could be done smoothly but I gather there are
reasons why it cannot.

Two additional, possibly more important, thoughts after reading
-05 more closely...

(1) The introductory material in the I-D seems to imply that use
of labels styled with "_" is a reasonable alternative to
creating a new label type.  My impression has been that, while
there is nothing we can change about what is done and deployed,
there has been community consensus that it is a bad idea and
that changes have been made to the procedures for defining and
registering new RRTYPEs to reinforce the principle that new
RRTYPEs should be used and to make their use easier.
"Significantly challenging over the life of the DNS" is
undoubtedly correct, but that should not be, and presumably is
not, the situation today or in recent years.   I believe this
document should not be advanced until that material is changed
to be clear that use of underscore or similar conventions may be
a reality but is not a desirable substitute for separate RRTYPEs
(with or without that convention as appropriate).

(2) I'd encourage people to think through another possibility.
I'm not sure it is the right answer, but it is worth more
consideration than this draft (at least at -05) appears to be
giving it.  The issues associated with QTYPE=ANY
notwithstanding, it is not clear to me that the set of labels
starting with "_" constitute a namespace, any more than the set
of labels starting with "xn--" do.  It is just a naming
convention that identifies the labels as keywords with defined
meaning.   From that point of view, namespaces are actually
per-RRTYPE and the right way to design this document would be as
a registry of "_"-introduced keywords, with subregistries for
each RRTYPE with which those keywords can be used.  Given the
way the DNS works, at least as I understand it, there is no DNS
protocol conflict between
     _foo IN XYZ Data1
and
     _foo IN ABC Data2

Using the same keyword in both cases may be a bad idea but the
zone files don't care and, given that queries are typically made
for QNAME and QTYPE (etc.) and not the name alone (i.e., with
QTYPE=ANY) except for other purposes, I see some advantages of
[sub]registry-per-RRTYPE rather than pretending that every label
starting with "_" is the same namespace.  Of course, one of them
is that there is no need to treat SRV as a special, legacy, case
or even debate that.   The coverage of the current document
would be simply a subregistry for SRV (reorganized from the
current registry, but that is simply an IANA organizational
matter, not a change to what is registered, protocols, etc.,
plus a subregistry for RRTYPE=TXT and provisions for other
subregistries as might be needed in the future.

Organizing things that way would have at least one additional
advantage: while FCFS may be appropriate for some RRTYPEs, other
procedures may be appropriate for others.  In a way, SRV is a
good example of that distinction.

Again, that might not be the right thing to do on balance, but I
think it should be examined carefully as an alternative to
trying to treat "everything starting with '_' as long as it
occupies a particular place in the tree" as a namespace.

best,
    john

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Mar 2018 00:07:56 -0700

John C Klensin wrote:
> creating a new label type.  ...

i think you mean "RRTYPE" as used below, and not "label type". we 
flirted with extended label types in the original EDNS0, but found them 
to require end-to-end scale (forklift) DNS protocol evolution which is 
impossible, rather than hop-by-hop scale (incremental) evolution which 
is all we've got left given the installed base.

> ...  My impression has been that, while there is nothing we can
> change about what is done and deployed, there has been community
> consensus that it is a bad idea and that changes have been made to
> the procedures for defining and registering new RRTYPEs to reinforce
> the principle that new RRTYPEs should be used and to make their use
> easier. "Significantly challenging over the life of the DNS" is
> undoubtedly correct, but that should not be, and presumably is not,
> the situation today or in recent years.   I believe this document
> should not be advanced until that material is changed to be clear
> that use of underscore or similar conventions may be a reality but is
> not a desirable substitute for separate RRTYPEs (with or without that
> convention as appropriate).

while i am sympathetic to this point of view, and even share it, i know 
that developers of new apps learned from the SPF RR example "never 
again" and that they can and have and will continue to create new apps 
based on TXT with or without the IETF's blessing. so i'm expecting your 
call for the stated clarification to not reach consensus in this WG.

> (2) I'd encourage people to think through another possibility. I'm
> not sure it is the right answer, but it is worth more consideration
> than this draft (at least at -05) appears to be giving it. The issues
> associated with QTYPE=ANY notwithstanding, it is not clear to me that
> the set of labels starting with "_" constitute a namespace, any more
> than the set of labels starting with "xn--" do. It is just a naming
> meaning. From that point of view, namespaces are actually per-RRTYPE
> and the right way to design this document would be as a registry of
> "_"-introduced keywords, with subregistries for each RRTYPE with
> which those keywords can be used. Given the way the DNS works, at
> least as I understand it, there is no DNS protocol conflict between
>       _foo IN XYZ Data1
> and
>       _foo IN ABC Data2
>
> Using the same keyword in both cases may be a bad idea but the zone
> files don't care and, given that queries are typically made for QNAME
> and QTYPE (etc.) and not the name alone (i.e., with QTYPE=ANY) except
> for other purposes, I see some advantages of [sub]registry-per-RRTYPE
> rather than pretending that every label starting with "_" is the same
> namespace. Of course, one of them is that there is no need to treat
> SRV as a special, legacy, case or even debate that. The coverage of
> the current document would be simply a subregistry for SRV
> (reorganized from the current registry, but that is simply an IANA
> organizational matter, not a change to what is registered, protocols,
> etc., plus a subregistry for RRTYPE=TXT and provisions for other
> procedures may be appropriate for others. In a way, SRV is a good
> example of that distinction.
>
> think it should be examined carefully as an alternative to trying to
> treat "everything starting with '_' as long as it occupies a
> particular place in the tree" as a namespace.

i have reproduced your entire second suggestion here, because i think 
it's solid. rrset atomicity means you're right, and that underbar'ed 
labels need only be unique within an RRTYPE, and any registry of such 
labels can and therefore should be per-RRTYPE.

good catch.

-- 
P Vixie

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Mar 2018 04:14:38 -0400

--On Monday, March 26, 2018 00:07 -0700 Paul Vixie
<[email-masked]> wrote:

> 
> 
> John C Klensin wrote:
>> ...
>> 
>> Two additional, possibly more important, thoughts after
>> reading -05 more closely...
>> 
>> (1) The introductory material in the I-D seems to imply that
>> use of labels styled with "_" is a reasonable alternative to
> i think you mean "RRTYPE" as used below, and not "label type".
> we flirted with extended label types in the original EDNS0,
> but found them to require end-to-end scale (forklift) DNS
> protocol evolution which is impossible, rather than hop-by-hop
> scale (incremental) evolution which is all we've got left
> given the installed base.

Yes, sorry.  Late at night.

>> ...  My impression has been that, while there is nothing we
>> can change about what is done and deployed, there has been
>> community consensus that it is a bad idea and that changes
>> have been made to the procedures for defining and registering
>> new RRTYPEs to reinforce the principle that new RRTYPEs
>> should be used and to make their use easier. "Significantly
>> challenging over the life of the DNS" is undoubtedly correct,
>> but that should not be, and presumably is not, the situation
>> today or in recent years.   I believe this document should
>> not be advanced until that material is changed to be clear
>> that use of underscore or similar conventions may be a
>> reality but is not a desirable substitute for separate
>> RRTYPEs (with or without that convention as appropriate).
> 
> while i am sympathetic to this point of view, and even share
> it, i know that developers of new apps learned from the SPF RR
> example "never again" and that they can and have and will
> continue to create new apps based on TXT with or without the
> IETF's blessing. so i'm expecting your call for the stated
> clarification to not reach consensus in this WG.

If you are telling me I've fighting a losing battle, I
understand that.  At the same time, as I trust people have
figured out from RFC 8324 and/or Bert's presentation in DNSOP
last week, I think there is reason for concern that continuing
to add features, especially features with either high intrinsic
complexity or significant kludge properties, may eventually push
things over some virtual cliff.   That makes the fight worth
fighting even if most of the battles are lost.
 
>> (2) I'd encourage people to think through another
>> possibility. I'm not sure it is the right answer, but it is
>> worth more consideration than this draft (at least at -05)
>> appears to be giving it. The issues associated with QTYPE=ANY
>> starting with "_" constitute a namespace, any more than the
>> set of labels starting with "xn--" do. It is just a naming
>> per-RRTYPE and the right way to design this document would be
>> as a registry of "_"-introduced keywords, with subregistries
>> for each RRTYPE with which those keywords can be used. Given
>> the way the DNS works, at least as I understand it, there is
>> no DNS protocol conflict between _foo IN XYZ Data1
>> and
>>       _foo IN ABC Data2
>> 
>> Using the same keyword in both cases may be a bad idea but
>> the zone files don't care and, given that queries are
>> typically made for QNAME and QTYPE (etc.) and not the name
>> alone (i.e., with QTYPE=ANY) except for other purposes, I see
>> some advantages of [sub]registry-per-RRTYPE rather than
>> pretending that every label starting with "_" is the same
>> namespace. Of course, one of them is that there is no need to
>> treat SRV as a special, legacy, case or even debate that. The
>> coverage of the current document would be simply a
>> subregistry for SRV (reorganized from the current registry,
>> but that is simply an IANA organizational matter, not a
>> change to what is registered, protocols, etc., plus a
>> subregistry for RRTYPE=TXT and provisions for other
>> advantage: while FCFS may be appropriate for some RRTYPEs,
>> other procedures may be appropriate for others. In a way, SRV
>> is a good example of that distinction.
>> 
>> Again, that might not be the right thing to do on balance,
>> but I think it should be examined carefully as an alternative
>> to trying to treat "everything starting with '_' as long as
>> it occupies a particular place in the tree" as a namespace.
> 
> i have reproduced your entire second suggestion here, because
> i think it's solid. rrset atomicity means you're right, and
> that underbar'ed labels need only be unique within an RRTYPE,
> and any registry of such labels can and therefore should be
> per-RRTYPE.
> 
> good catch.

Thanks.

best,
    john

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Mar 2018 01:20:52 -0700

John C Klensin wrote:
>>> consensus that it is a bad idea and that changes have been made
>>> to the procedures for defining and registering new RRTYPEs to
>>> reinforce the principle that new RRTYPEs should be used and to
>>> make their use easier. "Significantly challenging over the life
>>> of the DNS" is undoubtedly correct, but that should not be, and
>>> presumably is not, the situation today or in recent years. I
>>> believe this document should not be advanced until that material
>>> is changed to be clear that use of underscore or similar
>>> conventions may be a reality but is not a desirable substitute
>>> for separate RRTYPEs (with or without that convention as
>>> appropriate).

>> while i am sympathetic to this point of view, and even share it, i
>> know that developers of new apps learned from the SPF RR example
>> "never again" and that they can and have and will continue to
>> create new apps based on TXT with or without the IETF's blessing.
>> so i'm expecting your call for the stated clarification to not
>> reach consensus in this WG.
>
> If you are telling me I've fighting a losing battle, I understand
> that. At the same time, as I trust people have figured out from RFC
> 8324 and/or Bert's presentation in DNSOP last week, I think there is
> reason for concern that continuing to add features, especially
> features with either high intrinsic complexity or significant kludge
> properties, may eventually push things over some virtual cliff. That
> makes the fight worth fighting even if most of the battles are lost.

i wish that reality as we will experience it was even halfway as cut or 
dried as you describe here. however, just as the worst abuser of "fake 
news" later became the most common accuser of that abuse in others, 
especially where the news _wasn't_ fake, so it is that your desire to 
create new RRTYPEs in preference to "just use TXT and allocate a new 
underbar'd name" will be called, wrongly and unfairly as i see it, but 
that won't matter, will be called, "unnec'y increase in system 
complexity." therefore, the battle you'll lose will be around who gets 
to call which thing by what name, and not around what problems should be 
avoided. the shape of this conference table has been decided -- your 
remaining decision is where you will allow yourself to be seated.

-- 
P Vixie

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Mar 2018 04:30:12 -0400

--On Monday, March 26, 2018 01:20 -0700 Paul Vixie
<[email-masked]> wrote:

>>>> have been made to the procedures for defining and
>>>> undoubtedly correct, but that should not be, and presumably
>>>> is not, the situation today or in recent years. I believe
>>>> this document should not be advanced until that material is
>>>> changed to be clear that use of underscore or similar
>>>> conventions may be a reality but is not a desirable
>>>> substitute for separate RRTYPEs (with or without that
>>> it, i know that developers of new apps learned from the SPF
>>> RR example "never again" and that they can and have and will
>> last week, I think there is reason for concern that
>> continuing to add features, especially features with either
>> high intrinsic complexity or significant kludge properties,
>> may eventually push things over some virtual cliff. That
> i wish that reality as we will experience it was even halfway
> as cut or dried as you describe here. however, just as the
> worst abuser of "fake news" later became the most common
> accuser of that abuse in others, especially where the news
> _wasn't_ fake, so it is that your desire to create new RRTYPEs
> in preference to "just use TXT and allocate a new underbar'd
> name" will be called, wrongly and unfairly as i see it, but
> complexity." therefore, the battle you'll lose will be around
> who gets to call which thing by what name, and not around what
> problems should be avoided. the shape of this conference table
> has been decided -- your remaining decision is where you will
> allow yourself to be seated.

Again, Paul, I fear you are right, but that does not eliminate
my sense that trying to sound the alarm is worthwhile.

    best,
      john

---

From: "John R. Levine" <[email-masked]>
Date: 26 Mar 2018 09:44:41 +0100

On Mon, 26 Mar 2018, John C Klensin wrote:
> If you are telling me I've fighting a losing battle, I understand that. 
> At the same time, as I trust people have figured out from RFC 8324 
> and/or Bert's presentation in DNSOP last week, ...

This is our history coming back to bite us.  Two decades of DNS WG people 
insisting that adding new RRTYPEs is easy and anyone who thinks otherwise 
is a moron has blown our credibility even though we mostly don't say that 
any more.  I also note the underwhelming IETF interest in my extension 
language proposal, while at the same time people who use the DNS have paid 
me to implement it.

I think we could put in a sentence or two pointing out that new RRTYPEs 
are often a better option, particularly if you might want to use 
wildcards.

>> labels can and therefore should be per-RRTYPE.

Technically, you are completely correct.  But since the namespace is in 
effect infinite I would just as soon not have to explain to anyone why 
_foo for SRV means the same thing as _foo for URI but different from _foo 
for TXT.  As we've seen it's hard enough to understand the separate second 
level underscore namespaces and we're stuck with them.

Regards,

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Mar 2018 10:38:11 -0400

--On Monday, March 26, 2018 09:44 +0100 "John R. Levine"
<[email-masked]> wrote:

>...
>>> i have reproduced your entire second suggestion here,
>>> because i think  it's solid. rrset atomicity means you're
>>> right, and that underbar'ed  labels need only be unique
>>> within an RRTYPE, and any registry of such  labels can and
>>> therefore should be per-RRTYPE.
> 
> Technically, you are completely correct.  But since the
> namespace is in effect infinite I would just as soon not have
> to explain to anyone why _foo for SRV means the same thing as
> _foo for URI but different from _foo for TXT.  As we've seen
> it's hard enough to understand the separate second level
> underscore namespaces and we're stuck with them.

Ah, but pulling them together into one registry is our old
problem, in disguise, of trying to control behavior by what we
allow to be registered.   If, for example, I'm stupid enough to
use "_tcp" as the label of a TXT RR, a single registration tree
won't stop me or cause any DNS problems, it will just help me
add to the confusion.   If they are separated, I'm at least
marginally encouraged to document what I'd doing. 

At least as I see it, the purpose of a registry like this is to
help non-stupid people avoid conflicts and to provide
documentation pointers for information about the keywords.
Especially if the registry is not expected to grow to a huge
number of entries, asking IANA to create an alphabetical index
of all label keywords (I'm resisting "_Node Name" because I
don't believe this is really a namespace) that could link names
to particular subregistries (possibly more than one) would not
be a big deal.  

By contrast, Table 1 of the I-D is 

                    +-------------+-----+------------+
                    | _NODE NAME  | RR  | REFERENCE  |
                    +-------------+-----+------------+
                    | _tcp        | SRV | [RFC2782]  |
                    | _udp        | SRV | [RFC2782]  |
                    | _sctp       | SRV | [RFC2782]  |
                    | _dccp       | SRV | [RFC2782]  |
                    | _domainkey  | TXT | [RFC6376]  |
                    | _spf        | TXT | [RFC7208]  |
                    | _dmarc      | TXT | [RFC7489]  |
                    | _vouch      | TXT | [RFC5518]  |
                    +-------------+-----+------------+ 

While not very large, it is sorted by RRTYPE and then not sorted
in any obvious way.  Were it to grow significantly, one would
either want the same sort of index or would want to sort it by
label string ("_Node name") and then create an index by RRTYPE. 

If we are going to separate "SRV" out, as you and several other
have argued is necessary, we've got two separate registries
already -- SRV and "everything else", with the latter consisting
exclusively of TXT.  So, again, going to two subregistries and
provision for expansion from a table that is halfway there
anyway does not seem to me to be a big deal while being closer
to the reality of the DNS (as Paul explained better than I
could).

best,
   john

---

From: Martin Hoffmann <[email-masked]>
Date: Mon, 26 Mar 2018 17:18:42 +0200

John C Klensin wrote:
>
> From that point of view, namespaces are actually
> Using the same keyword in both cases may be a bad idea [...]

This sort of thing already happens: Both SRV and TLSA use the
_tcp and _udp labels. Perhaps the difference is subtle since in
both cases the label denotes the transport protocol. But names
do represent different things -- a service provided for a
logical entity v. a port of a physical host.

Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and
OPENPGPKEY all use underscore labels and are currently missing
from the initial table in section 3.1.

Kind regards,
Martin

---

From: Dave Crocker <[email-masked]>
Date: Mon, 26 Mar 2018 08:26:48 -0700

> from the initial table in section 3.1.

The table there is for the right-most underscore name, which RFC 6698 
seems to constrain to choices that are already list.

The left-most underscore name appears to use a rule that differs from 
the rule used by SRV, etc.  As such, these are second-level names being 
drawn from the same namespace but without coordination.  So it looks 
like there's a problem, but not with the proposed global registry (for now.)

Yes?

d/

---

From: Martin Hoffmann <[email-masked]>
Date: Mon, 26 Mar 2018 17:56:09 +0200

> seems to constrain to choices that are already list.

TLSA needs to be added to the RR column for _tcp, _udp, and _sctp.

RFC 7929 defines _openpgpkey for use with the OPENPGPKEY record type.

RFC 8162 defines _smimecert for use with the SMIME record type.

> the rule used by SRV, etc.  As such, these are second-level names
> being drawn from the same namespace but without coordination.  So it
> looks like there's a problem, but not with the proposed global
> registry (for now.)
> 
> Yes?

Agreed. Currently however, the text in section 2 does sound as if this
sort of collision doesn't happen:

| that is, a subordinate name is meaningful only within the scope of
| the first (top-level) underscore name.

It should probably call out either here or elsewhere that there may
be different hierarchies for different record types.

Kind regards,
Martin

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Mar 2018 12:14:02 -0400

> logical entity v. a port of a physical host.

The current text of the I-D, as I read it, is intended to bind
the use of a given string to a given RRTYPE.  From the abstract:

	"The purpose of the Underscore registry is to avoid
	collisions resulting from the use of the same
	underscore-based name, for different services."

Subtle or not, that is a collision.   I would much prefer to see:

  SRV [sub]registry
     ...
     _tcp  [RFC2782]
     ...

  TLSA subregistry
     ...
     _tcp  [RFCnnnn]
     ...

rather than
      _tcp SRV  [RFC2782][RFCnnnn]

the former would also make it easy to say whatever needs to be
said about second-level strings.

> from the initial table in section 3.1.

Sigh.

   best,
    john

p.s. Some nit-picking in the hope of general improvements to the
document.  At least for me, the terminology and background
explanation needs careful review.  In particular 

(1) The text in Section 1.1 says

	'the DNS rules for a "host" (host name) are not allowed
	to use the underscore character... legal host names
	[RFC1035]'

1035 does not say that.  Its section 2.3.1 is about what is
preferred, not what is required (or "legal").  It says "should"
and "preferred", but there is no requirement.  As far as I know,
there has never been a serious attempt to turn that preference
into a requirement.  Indeed, RFC 8121 says exactly the opposite
and, if there were a prohibition, RFC 6055 would have been
largely unnecessary.

(2) While, AFAICT, it is correct or close to it, the terminology
describing the DNS tree structure is awkward.  For example, in
"_foo._tcp.example.com", it is probably incorrect to refer to
"_tcp" as a leaf node because it has substructure.  The
statement 

	"Each globally-registered underscore name owns a
	distinct, subordinate name space"

does not work if _foo._bar.examplle.com is valid for one RRTYPE
but not for a different one (this is another argument for both
associating "namespace" terminology with a keyword-RRTYPE pair
and a subregistry approach, but the current language is
problematic even if we stick with the current model.   And,
because a casual reader might associate "global" and
"right-most" with TLDs and get confused about whether the DNS
tree is considered "root up", "root down", or "root right",
those terms would probably benefit from an explicit terminology
section that describes this documents view of the tree.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 26 Mar 2018 09:54:56 -0700

> preferred, not what is required (or "legal").  It says "should"

Note that when that spec was written, we didn't have such precise and 
rigid vocabulary rules.

But RFC 1123 should be cited, especially since it has more forceful 
language: "The syntax of a legal Internet host name". (RFC6055 seems to 
have missed the import of 'legal'.)

> into a requirement.  Indeed, RFC 8121 says exactly the opposite

Please cite the specific text in that RFC you are referencing.

> and, if there were a prohibition, RFC 6055 would have been

Overall, it appears that your claim is that the underscore naming 
convention is predicated on an erroneous interpretation of 'hostname' 
restrictions.  As such, the entire activity is broken.

d/

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 26 Mar 2018 11:44:01 -0700

On Mon, Mar 26, 2018 at 7:38 AM, John C Klensin <[email-masked]> wrote:

>
> . . .Table 1 of the I-D is
>
>       | _spf        | TXT | [RFC7208]  | <-----
> The inclusion of "_spf" in this table is worrisome. RFC7208 uses it as an
example only, not as a defined item. If one were to take all such sample
usages, we would also have to define _foo and _bar. I'm sure that some of
the passive DNS folks could provide a lot more "_" terms that are currently
in use.

--Kurt

---

From: "John R. Levine" <[email-masked]>
Date: 26 Mar 2018 20:49:36 +0100

>>       | _spf        | TXT | [RFC7208]  | <-----

That's just a mistake.  Take it out.

Apropos of John K's comment about per-type names, he's right.  Given that 
people can do whatever they want I have to agree that if people want to 
define names that way, we can't prohibit them.

Assuming we agree that the table also says where to find the registry for 
second level names, this removes and need for special cases.  The top 
level names _tcp _udp _sctp _dccp all work for SRV and URI and take 
service names on the second level.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Mar 2018 16:21:33 -0400

(top post) 

Dave,

I identified that issue as a nit deliberately.  This is a WG
document and I believe the document would be improved if a less
strong assertion were made, just because the issues of what,
exactly, a "host" is for DNS purposes and what it can be called
has been a source of controversy among those who seem to enjoy
such discussions for about as long as I can remember. Trying to
address that issue through this document is unnecessary and has
a bit of a "side effect" feel to it -- it would be sufficient to
say that there is a convention about using leading underscore
followed by a keyword with some RRTYPEs and then move on.

To answer your specific question, RFC 2181, Section 11, says
"...any binary string whatever can be used as the label of any
resource record."  I have not checked as to whether one of the
many updates to that document modifies that statement, but the
point is that 
   _tcp IN A 10.0.0.1
is a perfectly valid record, whether it identifies a "host" or
not.  It just doesn't have any special interpretation there
because there is no special namespace for "_" keywords
associated with the "A" RRTYPE.

Yes, that means that the use of leading underscores as a
contention is a risk, just as the use of "xn--" to identify the
need for IDNA processing is a risk.  In practice, the risks have
proven to be low for both.  Maybe they are lower for "_" because
the label strings are interpreted only in the context of
specific label types, but that is just one more argument for
binding the concept of a namespace for these names to the
RRTYPE, not global, RRTYPE-independent, use of the DNS.

However, I certainly don't have the time or energy to turn the
validity of hostnames into a long, drawn-0ut, debate.    It is
not, IMO, a really serious error in the context of this
document, at least unless a explanatory statement made here is
cited later as an authoritative definition.   If no one else in
the WG cares about it, so be it.

    john

--On Monday, March 26, 2018 09:54 -0700 Dave Crocker
<[email-masked]> wrote:

> Note that when that spec was written, we didn't have such
> precise and rigid vocabulary rules.
> 
> But RFC 1123 should be cited, especially since it has more
> forceful language: "The syntax of a legal Internet host name".
> (RFC6055 seems to have missed the import of 'legal'.)
> 
> 
>> and "preferred", but there is no requirement.  As far as I
>> know, there has never been a serious attempt to turn that
>> preference into a requirement.  Indeed, RFC 8121 says exactly
>> the opposite
> 
> Overall, it appears that your claim is that the underscore
> naming convention is predicated on an erroneous interpretation
> of 'hostname' restrictions.  As such, the entire activity is
> broken.
> 
> d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 26 Mar 2018 14:03:09 -0700

> RFC 8162 defines _smimecert for use with the SMIME record type.

Confirming addition of these to the /global/ underscore registry table 
for the next version of the draft.

Thanks!

d/

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Mar 2018 14:30:17 -0700

John R. Levine wrote:
> ...
>
> Assuming we agree that the table also says where to find the registry
> for second level names, this removes and need for special cases. The top

if you view the use of _tcp by more than one rrtype as a coincidence 
rather than as evidence for the need for a registry, then we can simply 
define the global registry out of existence (where it has been until 
now) and ensure that every rrtype's registry of "_" names is public and 
easily found on the IANA web site.

-- 
P Vixie

---

From: Dave Crocker <[email-masked]>
Date: Mon, 26 Mar 2018 14:47:01 -0700

On 3/26/2018 12:07 AM, Paul Vixie wrote:
> 
> 
> John C Klensin wrote:
>>    it is not clear to me that
>> meaning.

1. This seems to require a very precise definition of the term 
namespace, but doesn't cite it.  Here's mine -- although it's different 
from Wikipedia's:

    An integrated (probably contiguous) range of values from which names 
can be chosen.

And elaborated:

      A set of rules for assigning names out of a common space of values.

2. If "_" at the beginning of a DNS label does not define a namespace in 
the current DNS, then it can't be subject to any distinct set of rules. 
In actual practice, the use of "_" as the first character is now fully 
entrenched.  Debating what to call the space it controls doesn't change 
established practice.

3. I don't understand how xn-- can be any less reserved for exclusive 
use. That is, I believe the convention of using xn-- has reserved that 
string for only that use and that the document choosing that string has 
formally made that restriction.

The goal of the current draft is to bring the space of names starting 
with underscore under unified control.  With the publication of a draft 
like this, the use of underscore as the first character makes its use 
reserved.

All of this has to do with name /assignment/, but makes no changes on 
name /resolution/.  Name resolution remains blissfully unaware of any 
rules about name assignment or 'meaning'.

d/

---

From: Ray Bellis <[email-masked]>
Date: Tue, 27 Mar 2018 09:30:36 +0100

On 26/03/2018 20:49, John R. Levine wrote:

> for second level names, this removes and need for special cases.  The
> top level names _tcp _udp _sctp _dccp all work for SRV and URI and take

Except when it doesn't.

_tcp is used for TLSA with (underscore prefixed) service _numbers_.

Ray

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 Mar 2018 06:26:51 -0700

> from the initial table in section 3.1.

Added TLSA to the next version of the draft.

d/

---

From: Martin Hoffmann <[email-masked]>
Date: Wed, 28 Mar 2018 14:49:02 +0200

Hi,

should probably do this more systematically, but I just
stumbled over another underscore label in the ACME draft:

draft-ietf-acme-acme defines _acme-challenge for TXT records.

The draft seems to be in Last Call right now, so it might
be an RFC before the registry is established.

Kind regards,
Martin
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 28 Mar 2018 06:49:27 -0700

> draft-ietf-acme-acme defines _acme-challenge for TXT records.

Thanks.  Added to the next version.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 28 Mar 2018 08:29:51 -0700

Folks,

(long note. couldn't make it shorter...)

This has been an unusually challenging journey.  None of the recent 
comments in support of a 'simplifying' view for this registry resonated. 
  Quite the opposite. In effect, it seemed to me as if RR type would be 
a lookup key, which frankly sounds a bit nuts.  OK in theoretical terms, 
perhaps, but problematic in practical terms, especially since -- given 
my understanding of what people were saying -- the use of the RR 
apparently would need to come into the lookup process just below the 
first underscore name...

On the other hand, when a variety of serious, knowledgeable folk support 
a view, there's an obligation to put serious effort into finding their 
f'ing pony...

It finally occurred to me that the current draft already has language 
that hints at the essential point that is probably what is actually 
being made, although it wasn't put there for that purpose or with that 
intended meaning:

     A given name defines a specific, constrained context for one or
     more RR records, in which use of such records MUST conform to the
     defined constraints.  Within this scope, other resource records that
     are not specified MAY be used.

The second sentence is the one with the larger meaning than I'd 
intended.  But the first one sets the larger point, though again, I 
wasn't seeing it.

One purpose of a registry to is prevent or resolve contention between 
publishers, for whatever is being listed.  The other is so that 
producers and consumers can rendezvous. The current draft's approach to 
doing the underscore work has focused on regulating domain name labels 
because, well, that's where the underscore is and it's been the obvious 
place where there has been no coordination.  The draft has been driven 
by a classic view of registration for a domain name.  Domain name 
registries concern possible contention between different organizations 
or people wanting a name.  So obviously that's what an underscore 
registry should worry about...

The essential point that I was missing was that the domain name is /not/ 
the contention to worry about, or at least, not much.  It's still 
essential that producers and consumers use the same rules for 
formulating the names, but that's about documentation and not 
contention.  The potential contention is in use of the RRs under a given 
name. (That is, after all, the point of the first sentence, quoted 
above.)  Having two different uses of the same RR in the same leaf is 
explicitly problematic.

So in end-to-end terms, the issue is the RR and not the path (name) to 
it.  As long as there is no contention in the production or use of a 
given RR appearing in a given leaf, then it doesn't matter if there are 
other actors using the same DNS node names (path) to get to their 
/other/ RRs.

Stated that way, this seems to me pretty obvious, but I really hadn't 
been seeing it.

The 'this' is:

      The DNS Global Underscore Registry MUST have entries that are 
unique with respect to the combination of the listed resource record and 
the listed, global underscore node name (RR, _Node Name).

Alas, seeing this doesn't resolve all the issues....

While (typeA, _label1) does not collide with (typeA, _label2), it 
obviously does collide with some other specification's use of (typeA, 
_label1).  Since permitting multiple services to use the same RR type is 
the explicit goal, we need procedures that ensure that these independent 
generators don't generate the same global underscore name.

The classic, boring approach to the underscore naming registry that I 
was taking fixes this problem, by ensuring there is only one controller 
of a given leaf, even with the simplest name registration FCFS approach.

The alternative being proposed does not accomplish this in an obvious 
way, since the requirement for uniqueness does not hinge on a single 
table entry value.

I think the best way to handle that issue is to make the global 
underscore registry subject to expert review, with very careful 
consensus language directing the expert on what to look for/ensure.

So...

1. Please comment on the above

2. I've submitted a new draft version based on this highly revised view

3. Besides changes to reflect the above, it also eliminates concern for 
any lower-level underscore usage:  uniqueness is only in terms of the RR 
and the global (first) underscore node name use. This is a simplifying 
point that could be argued, to have uniqueness depend on the full 
sequence of underscore lables, but I think it does not impose a 
significant burden.

3. The Expert Review is only for this registry entry.  Any other issues 
with the document specifying that entry would be outside of the scope of 
this review, but might be covered by some other process, such as the 
existing DNS RR review requirement.

4. I've punted on the details for the URI RR, given some complexities in 
RFC 6117.  If anyone wants to suggest specific text for this, it would 
be greatly appreciated.

5. There is still a second document needed, to fix the various documents 
that specify global underscore names, so that these documents are 
updated to cite the registry. Once things settle down for this main 
draft, I'll work on that one.

Thoughts?

d/

ps. Another round of hearty thanks to Ray Bellis for his offlist 
interactions with me on this, though of course he gets none of the blame 
for my getting any of this wrong...

---

From: Warren Kumari <[email-masked]>
Date: Thu, 29 Mar 2018 21:45:23 +0100

> associated with the "A" RRTYPE.

Actually, I'm not sure that that *is* a perfectly valid record, but
for a completely different reason to your statement / argument.

Many implementations simply will not resolve an underscore name to an
A or AAAA, and at least one implementation (BIND) won't load a
zonefile with them without bludgining:

foo                       IN 600 A 192.0.2.1
_foo                      IN 600 A 192.0.2.2
_bar                      IN 600 CNAME foo.example.com.
_txt                      IN 600 TXT "I'm a lumberjack..."

gets you:
$ named-checkzone  example.com example.com
example.com:11: _foo.example.com: bad owner name (check-names)
zone example.com/IN: not loaded due to errors.

I don't want to get into if this is the *right* behavior or not, but
it seems like worth mentioning in the draft as it has much background
already...
I can find nothing which states that A / AAAA cannot be associated
with underscore names, but they sure don't seem to work in practice.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Dave Crocker <[email-masked]>
Date: Thu, 29 Mar 2018 13:52:44 -0700

On 3/29/2018 1:45 PM, Warren Kumari wrote:
> I don't want to get into if this is the*right*  behavior or not, but

The current version is:

Please suggest specific text to use and where to put it.

d/

---

From: Warren Kumari <[email-masked]>
Date: Thu, 29 Mar 2018 22:00:49 +0100

> Please suggest specific text to use and where to put it.

I'm hoping someone will pipe up with "Gee, RFCfoo, Section bar, Bullet
N clearly says this, I can't believe you never knew that...."

If that doesn't occur I'll craft text.
W

---

From: Paul Vixie <[email-masked]>
Date: Thu, 29 Mar 2018 14:06:30 -0700

you do not need to document what won't work. underscored names don't 
match the syntax for host names. that's deliberate. that's why they were 
created. most dns servers will allow you to associate A or AAAA rrsets 
with underscored names, though some might warn you about it when parsing 
the zone file. some getaddrinfo() or gethostbyname() libraries will look 
up A or AAAA rrsets for these names, but many will not.

see RFC 952.

---

From: John C Klensin <[email-masked]>
Date: Thu, 29 Mar 2018 18:02:37 -0400

--On Thursday, March 29, 2018 22:00 +0100 Warren Kumari
<[email-masked]> wrote:

>>> I don't want to get into if this is the*right*  behavior or
>>> not, but it seems like worth mentioning in the draft as it
>>> has much background already...
>>> I can find nothing which states that A / AAAA cannot be
>>> associated with underscore names, but they sure don't seem
>>> to work in practice.

> I'm hoping someone will pipe up with "Gee, RFCfoo, Section
> bar, Bullet N clearly says this, I can't believe you never
> knew that...."
> 

Warren, just to clarify where I'm coming from (and noting Paul
Vixie's recent comment).  I think there is no question that
putting a label starting with an underscore (or containing one)
on an RRSET that includes an address record would be
ill-advised, nor that some implementations (possibly because
they consider it ill-advised or just plain dumb) won't allow it
or won't make it easy.   I think there is no question that
underscores (leading or otherwise) have no more place in either
historical (e.g., RFC 952) host names or the "preferred syntax"
of RFC 1034/1035 than, e.g., "+", "$", "%", or "/" do.  I am
reasonably confident that you are not going to find a normative
statement that says that the term "host name" (with or without
an intervening space) is any label, or the left-most label,
associated with one or more address records, nor as statement
that host names in the DNS MUST conform to the preferred syntax.
Indeed, the description in RFC 7719 appears to me to be
consistent with what the specifications actually say and it
contains the same "any octet value" language that appears in
earlier, normative, documents including RFC 8121.

My objection was narrow.  The text, even at -06, reads

	'"host" (host name) are not allowed to use the
	underscore character, this distinguishes the underscore
	name from all legal host names [RFC1035]"'

That is objectionable for two reasons.  First and most
important, RFC 1035 just does not say that.  If the text had
referenced RFC 952 instead, it would have been correct, but
maybe not so useful.   Similarly, if it had said, more or less
following 7719, that generally-accepted domain names that
identify hosts ("host names") conform to the preferred syntax of
RFC 1034 (or 1035) and hence do not include underscores, there
would be no problem (if someone wants to take that as proposed
text, feel free).  

Second, as has been discussed many times before in the last
decade or two, "legal" is not a good term to use to describe
validity or conformance in RFCs.  Our standards are voluntary,
which makes it hard for them to assign legality or illegality
to, in this case, particular bits of syntax.  Moreover, the
concept of something being legal or illegal implies that, if the
latter is discovered, I should be able to call the Protocol
Police and have the offending label or its perpetrator arrested.
When last I tried, they were not answering their phone or even
their email.  The IESG has pushed back on that term in the past
and should, I believe, be pushing back on it today, regardless
or what might have been said in kinder and gentler times.

However, I believe that this discussion is, however
unintentionally, a distraction from a far more important issue.
The way the DNS, and particularly DNS queries, are defined makes
the idea of a namespace for all labels starting with "_" very
difficult and potentially a source of confusion.  While sorting
the registry by RRTYPE is an improvement over earlier versions,
the correct structure  is to have subregistries by RRTYPE, each
with whatever keywords (starting with underscore) are
appropriate for use with it listed.  I do not believe it is
appropriate to lose that distinction while we quibble about the
language used to describe the syntax of host names.

best,
   john

---

From: Adam Roach <[email-masked]>
Date: Thu, 29 Mar 2018 17:38:49 -0500

On 3/29/18 5:02 PM, John C Klensin wrote:
> appropriate for use with it listed.

I'll note that I made a similar suggestion back in August, but was 
convinced by people I presumed to know more about DNS than I do that I 
only thought this was okay because I had a completely incorrect notion 
of what DNS names really mean.

See, e.g.:

https://mailarchive.ietf.org/arch/msg/art/RsvttUAnSKI9SntCft8c84EGMT0
https://mailarchive.ietf.org/arch/msg/art/ESNRdIBjRYiyVQcRx5zwGVdoHa8
https://mailarchive.ietf.org/arch/msg/art/MZ35ZO8Uig9VXeeHCy1u-1LBtTI
https://mailarchive.ietf.org/arch/msg/art/T4DbIpeyTafs4KWx0Vji3e8Aw9I

I still don't fully understand the nature of the objections I cite above 
or the assertions that having separate tables for different RRTYPEs is 
somehow broken. Based on my (admittedly lay) understanding of how DNS is 
used by other protocols, I agree with your proposal that having distinct 
tables for each RRTYPE makes far more sense than the current structure.

/a

---

From: Dave Crocker <[email-masked]>
Date: Thu, 29 Mar 2018 16:03:40 -0700

> tables for each RRTYPE makes far more sense than the current structure.

1. Another round of thanks. On re-starting the effort, I'd missed that 
exchange.  I think adding

      "Scope is meant as a static property, not one dependent on the 
nature of the query.  It is an artifact of the DNS name."

from it, to the Intro will help a bit.

2. I think the latest round of discussion and change arguably implements 
your view, albeit within a single actual registry.

d/

---

From: "John R. Levine" <[email-masked]>
Date: 31 Mar 2018 08:15:40 -0400

Catching up:

> if you view the use of _tcp by more than one rrtype as a coincidence rather 
> than as evidence for the need for a registry, then we can simply define the 
> global registry out of existence (where it has been until now) and ensure 
> that every rrtype's registry of "_" names is public and easily found on the 
> IANA web site.

I don't think it's a coincidence, but as you noted people will do what 
they do.  One registry should make it easier for sensible people to look 
and say aha, _foo already means something for BAR records so I will use a 
different name for unrelated tags for BAZ records.  Or for unsensible 
people, we can at least be aware of what they do.

Regards,

---

From: Paul Vixie <[email-masked]>
Date: Sat, 31 Mar 2018 11:46:04 -0700

John R. Levine wrote:
>> rather than as evidence for the need for a registry, then we can
>> simply define the global registry out of existence (where it has been
>> until now) and ensure that every rrtype's registry of "_" names is
>> public and easily found on the IANA web site.
>
> and say aha, _foo already means something for BAR records so I will use
> a different name for unrelated tags for BAZ records. Or for unsensible

in one sense there is a registry but in another sense there are 
registries for each RR type whose applications will use underscored 
names for extended subtyping.

what this means is, if someone sees _TCP in use for some rr type, and 
they needed something like this for their own new rr type, they should 
be encouraged to either use _TCP if they find it's the best fit, or use 
something else if they find that a best fit. they should not worry 
either away about either reusing, or not reusing, an existing name.

so while i agree that having a set of per-type registries will inform 
future application developers, my expected use case is the opposite of 
what you said here.

it's vital that the relevant technical constraint be restated at every 
level of underscore documentation, and that is, there is no relationship 
other than coincidence between a given _LABEL used by one rr type and 
that same label used by some other rr type. i know that we think of 
names having rrsets, and they do; however, in practical terms of whether 
conflicts will arise, we can in this case think of an rrset having its 
own parent _LABEL.

dave may profit by referring to the "let's all stop returning ANY 
results" draft, since it's only if ANY actually worked, that we would 
see performance problems from _LABEL reuse across types. but note, even 
in that performance-degrading situation, there would be no *conflicts*, 
only coincidences.

-- 
P Vixie

---

From: "John R. Levine" <[email-masked]>
Date: 31 Mar 2018 15:04:59 -0400

> what this means is, if someone sees _TCP in use for some rr type, and they 
> needed something like this for their own new rr type, they should be 
> encouraged to either use _TCP if they find it's the best fit, or use 
> something else if they find that a best fit. they should not worry either 
> away about either reusing, or not reusing, an existing name.

Well, that, too.  Either way, it'd be nice to have all the underscore 
names in one place rather than spread into N places for N record types.

R's,
John