Subject: An IANA Registry for DNS TXT RDATA (I-D Action: draft-klensin-iana-txt-rr-registry-00.txt)

From: John C Klensin <[email-masked]>
Date: Fri, 30 Aug 2013 09:35:50 -0400

Hi.

Inspired by part of the SPF discussion but separate from it,
Patrik, Andrew, and I discovered a shortage of registries for
assorted DNS RDATA elements.  We have posted a draft to
establish one for TXT RDATA.  If this requires significant
discussion, we seek guidance from relevant ADs as to where they
would like that discussion to occur.

Three notes:

* As the draft indicates, while RFC 5507 and other documents
explain why subtypes are usually a bad idea, the registry
definition tries to be fairly neutral on the subject -- the idea
is to identify and register what is being done, not to pass
judgment. 

* While the use of special labels (in the language of 5507,
prefixes and suffixes) mitigates many of the issues with
specialized use of RDATA fields, they do not eliminate the
desirability of a registry (especially for debugging and
analysis purposes).

* While examining the DNS-related registries that exist today,
we discovered that some other registries seemed to be missing
and that the organization of the registries seemed to be
sub-optimal.  We considered attempting a "fix everything" I-D,
but concluded that the TXT RDATA registry was the most important
need and that it would be unwise to get its establishment bogged
down with other issue.  The I-D now contains a temporary
appendix that outlines the other issues we identified.  IMO,
thinking through the issues in that appendix, generating the
relevant I-D(s), and moving them through the system would be a
good exercise for someone who has little experience in the IETF
and who is interested in IANA registries and/or DNS details.  I
am unlikely to find time to do the work myself but would be
happy to work with a volunteer on pulling things together.

    best,
      john

---------- Forwarded Message ----------
Date: Friday, August 30, 2013 05:52 -0700
From: [email-masked]
To: [email-masked]
Subject: I-D Action: draft-klensin-iana-txt-rr-registry-00.txt

A New Internet-Draft is available from the on-line
Internet-Drafts directories.

	Title           : An IANA Registry for Protocol Uses of Data
with the DNS TXT RRTYPE 	Author(s)       : John C Klensin
                          Andrew Sullivan
                          Patrik Faltstrom
	Filename        : draft-klensin-iana-txt-rr-registry-00.txt
	Pages           : 8
	Date            : 2013-08-30

Abstract:
   Some protocols use the RDATA field of the DNS TXT RRTYPE for
holding    data to be parsed, rather than for unstructured free
text.  This    document specifies the creation of an IANA
registry for protocol-    specific structured data to minimize
the risk of conflicting or    inconsistent uses of that RRTYPE
and data field.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-klensin-iana-txt-rr-registry

[...]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Aug 2013 10:16:46 -0400

On Fri, Aug 30, 2013 at 9:35 AM, John C Klensin <[email-masked]> wrote:

> judgment

RFC 5507 does indeed say that but it is an IAB document, not an IETF
consensus document and it is wrong.

The document was written by authors who wanted to promote the notion that
the DNS should accept deployment of new RR types and to do otherwise is a
standards violation. So it makes claims about some subtyping strategies
that are wildly inaccurate.

Prefixing works fine unless you need to use wildcards. What the draft does
not mention is that it is easy to fix the wildcarding problem. (see XPTR).

The consequence of this is that we still don't seem to have a registry for
DNS prefixes, or at least not in the place I expect it which is

Domain Name System (DNS) Parameters

Instead we have a bunch of registries that are protocol specific. Which
when the prefixes are from a common namespace is borked.

The IANA should be tracking SRV prefix allocations and DNSEXT seems to have
discussed numerous proposals. I have written some myself. But I can't find
evidence of one and we certainly have not updated SRV etc. to state that
the registry should be used.

Fixing TXT is optional, fixing the use of prefixes and having a proper
registry that is first come first served is essential. Right now we have
thousands of undocumented ad-hoc definitions.

This task has to be taken away from people who think cutting a new RR is
always the answer. It isn't. We are going to have hundreds of thousands of
Web Services and the DNS RR space is a 16 bit number.

Service discovery requires prefixes.

Here is a draft that works fine (except for the IETF review mistake). Just
put IETF last call on it:

http://tools.ietf.org/html/draft-gudmundsson-dns-srv-iana-registry-04

-- 
Website: http://hallambaker.com/

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 30 Aug 2013 10:38:31 -0400

Hi Phillip,

> http://tools.ietf.org/html/draft-gudmundsson-dns-srv-iana-registry-04

I believe that draft was superseded by RFC6335 and all service names (SRV 
prefix labels) are now recorded at 
<http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml> 
- indeed several of those come from RFCs I have written that add new SRV 
names.

-- 
Cyrus Daboo

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Aug 2013 11:48:06 -0400

On Fri, Aug 30, 2013 at 10:38 AM, Cyrus Daboo <[email-masked]> wrote:

> Hi Phillip,
>
>
> --On August 30, 2013 at 10:16:46 AM -0400 Phillip Hallam-Baker <
> [email-masked]> wrote:
>
>> http://tools.ietf.org/html/**draft-gudmundsson-dns-srv-**iana-registry-04<http://tools.ietf.org/html/draft-gudmundsson-dns-srv-iana-registry-04>
>>
>
> prefix labels) are now recorded at <http://www.iana.org/**
> assignments/service-names-**port-numbers/service-names-**
> port-numbers.xhtml<http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml>>

Ah, its there but not in the DNS area where I was looking.

Thanks.

---

From: John C Klensin <[email-masked]>
Date: Fri, 30 Aug 2013 12:13:29 -0400

--On Friday, August 30, 2013 11:48 -0400 Phillip Hallam-Baker
<[email-masked]> wrote:

>> I believe that draft was superseded by RFC6335 and all
>> service names (SRV prefix labels) are now recorded at
>> <http://www.iana.org/**
>> port-numbers.xhtml<http://www.iana.org/assignments/service-na
>> mes-port-numbers/service-names-port-numbers.xhtml>> - indeed
>> several of those come from RFCs I have written that add new
>> SRV names.
> 
> 

And that is exactly the reason why that temporary appendix calls
for some rethinking and reorganization of how the registries are
organized so as to make that, and similar registries, easier to
find.  

While I continue to believe that doing the work would be a good
exercise for a relative newcomer, if one of you wants to go at
it, please do so with my blessings.

   john

---

From: Michelle Cotton <[email-masked]>
Date: Fri, 30 Aug 2013 10:21:23 -0700

This is helpful feedback.
We are looking at how the listing of the registries is used by the
community.  
There have been suggestions of adding keywords to help when people search
for registries.
As the list of registries grows, we want to make sure it is useful and
that registries can easily be found.
We may be requesting community feedback in the near future about how the
listing of registries could change.

Thank you,

--Michelle

Michelle Cotton
Manager, IANA Services
ICANN

---

From: John C Klensin <[email-masked]>
Date: Fri, 30 Aug 2013 15:35:51 -0400

Hi.  I'm going to comment very sparsely on responses to this
draft, especially those that slide off into issues that seem
basically irrelevant to the registry and the motivation for its
creation.   My primary reason is that I don't want to burden the
IETF list with a back-and-forth exchange, particularly about
religious matters.  The comments below are as much to clarify
that plan as they are to response to the particular comments in
Phillip's note.

--On Friday, August 30, 2013 10:16 -0400 Phillip Hallam-Baker
<[email-masked]> wrote:

> RFC 5507 does indeed say that but it is an IAB document, not
> an IETF consensus document and it is wrong.

Yes. it is an IAB document.  And, yes, one of the coauthors of
this draft is a coauthor of 5507 and presumably doesn't share
your opinion of its wrongness.

But that is irrelevant to this particular document.  5507 is
used to set context for discussing the need for the registry and
to establish some terminology.  If the Hallam-Baker Theory of
DNS Extensions had been published in the RFC Series, we might
have drawn on it for context and terminology instead.  Or not,
but we didn't have the choice.   Your description of the motives
of the authors of 5507 is an even better example.  Perhaps you
are correct.  Perhaps you aren't.  But whether you are correct
or not makes absolutely no difference to the actionable content
of this draft.  

The "more prefixes" versus "more RRTYPES" versus subtypes versus
pushing some of these ideas into a different CLASS versus
whatever else one can think of are also very interesting... and
have nothing to do with whether this registry should be created
or what belongs in it.

Since you obviously don't like 5507, I would suggest that you
either prepare a constructive critique and see if you can get it
published or, even better, prepare an alternate description of
how things should be handled and see if you can get consensus
for it.   This document is not a useful place to attack it
because its main conclusions just don't make any difference to
it.  If you have contextual or introductory text that you prefer
wrt justifying or setting up the registry, by all means post it
to the list.  If people prefer it to the 5507 text, there is no
reason why it shouldn't go into a future version of the draft.

> The consequence of this is that we still don't seem to have a
> registry for DNS prefixes, or at least not in the place I
> expect it which is
> 
>...

Yes.  It it too hard to find.  That also has nothing to do with
this particular registry.  It is connected to why the I-D
contains a temporary and informative appendix about DNS-related
registries and where one might expect to find them.  Our hope is
that the appendix will motivate others (or IANA) to do some work
to organize things differently or otherwise make them easier to
find.  But whether action is taken on the appendix or not has
nothing to do with whether this registry is created.

> The IANA should be tracking SRV prefix allocations and DNSEXT
> seems to have discussed numerous proposals. I have written
> some myself. But I can't find evidence of one and we certainly
> have not updated SRV etc. to state that the registry should be
> used.

The IANA is extremely constrained about what it can do without
some direction from the IETF.  The appendix is there to provide
a preliminary pointer to some areas that might need work (at
least as much or more by the IETF as by IANA).  If you have
specific things that belong on the list (the working version of
what will become -01 already is corrected to point to the SRV
registry), I'd be happy to add them, with one condition: if we
end up in a discussion of the details of the appendix rather
than the particular proposed registry, the appendix will
disappear.  It is a forward pointer to work that probably should
be done, not the work itself.

> Fixing TXT is optional, fixing the use of prefixes and having
> a proper registry that is first come first served is
> essential. Right now we have thousands of undocumented ad-hoc
> definitions.

Let me restate that.  Some of us believe that it is time to "fix
TXT" or, more specifically, to create a registry that can
accommodate identification of what is being done, whether one
approves of it or not.  If other things need fixing too --and I
agree that at least some of them do-- please go to it.  If the
appendix is useful in that regard, great.  If not, I'm not
particularly attached to it.
 
Neither the structure and organization of IANA registries
generally nor the future of service discovery have anything to
do with this draft.  If you want to discuss them, please start
another thread.

  thanks,
    john

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 30 Aug 2013 21:47:15 +0200

> have nothing to do with whether this registry should be created

One of the key messages in RFC 5507 is that one should have a selector of what RR you want in the triple {owner, type, class} and not as part of the RDATA.

This document is about creating a registry for the selectors that obviously are needed *IF* one have structured data in the RDATA part of the TXT resource record type.

Two very different things indeed.

   Patrik

---

From: manning bill <[email-masked]>
Date: Sat, 31 Aug 2013 02:52:20 -0700

given the nature of the TXT RR, in particular the RDATA field,
I presume it is the path of prudence to set the barrier to registration
in this new IANA registry to be -VERY- low.

Or is the intent to create a "two" class system, registered and unregistered types?

/bill

---

From: John C Klensin <[email-masked]>
Date: Sat, 31 Aug 2013 09:28:14 -0400

--On Saturday, August 31, 2013 02:52 -0700 manning bill
<[email-masked]> wrote:

> I presume it is the path of prudence to set the barrier to
> registration in this new IANA registry to be -VERY- low.

That is indeed the intent.  If the document isn't clear enough
about that, text would be welcome.  I'm still searching for the
right words (and hoping that the discussion will interact in
both directions with the 5226bis effort
(draft-leiba-cotton-iana-5226bis), but our thought is that the
"expert reviewer" will provide advice and education about the
desirability of good quality registrations back up by good
quality and stable documents.  But, if the best we can get is
registrant contact info, name of a protocol, and a clue about
distinguishing information, then that is the best we can get.

> Or is the intent to create a "two" class system, registered

In one sense, that result is inevitable because some of the
locally-developed and used stuff that lives in TXT records will
probably not be registered no matter what we do.  That is still
better than the current situation of a one-class system in which
nothing is registered.  But the intent is to get as much
registered as possible.

Again, if the I-D isn't clear, text would be welcome.

   john

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 01 Sep 2013 06:13:44 +0900

The draft does not assure that existing usages are compatible
with each other.

Still, the draft may assure new usages compatible with each other.

However, people who want to have new (sub)types for the new usages
should better simply request new RRTYPEs.

If we need subtypes because 16bit RRTYPE space is not enough
(I don't think so), the issue should be addressed by itself
by introducing a new RRTYPE (some considerations on subtype
dependent caching may be helpful), not TXT, which can assure
compatibilities between subtypes.

For the existing usages, some informational RFC, describing
compatibilities (or lack of them) between the existing usages,
might help.

						Masataka Ohta