Subject: [dnsext] RRTYPE request: template for ZS record

From: Andrew Sullivan <[email-masked]>
Date: Fri, 21 Nov 2008 13:03:48 -0600

Dear colleagues,

Attached is a completed template requesting an RRTYPE assignment under
the procudures of draft-ietf-dnsext-2929bis.

This request will be evaluated by expert review.  This mail initiates
a three week comment period on the RRTYPE request.  If you have
comments on the request, please post them to this list.

As we've been doing so far, we'll have all the appointed experts do
the work this round.  This is slightly at variance with the procedures
as outlined in 2929bis; we're still getting experience with the
procedures, and so it seems to me to be advantageous to duplicate
effort for now to gain that experience.  I anticipate that at some
point in the future, we'll return to the practice of asking just one
expert to perform the review.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
#
#	$Id: zs-template.txt,v 1.3 2008/11/06 09:43:45 jim Exp $
#
                  DNS RRTYPE PARAMETER ALLOCATION TEMPLATE

    A.    Submission Date:

	6/11/08

    B.   Submission Type:
         [x] New RRTYPE
         [ ] Modification to existing RRTYPE

    C.   Contact Information for submitter:
                Name: Jim Reid
                Email Address: [email-masked]
                International telephone number: +44 20 7467 6474
                Other contact handles: none
         (Note: This information will be publicly posted)

    D.   Motivation for the new RRTYPE application?

    	There is a need to provide a mechanism in the DNS to publish
    	descriptive information about the status of the zone,
    	particularly for zones holding real-time contact data. At
    	present a variety of ad-hoc schemes and conventions are
    	used. These approaches are confusing and impractical since an
    	arbitrary DNS client needs a priori knowledge of which of
    	these schemes, if any, has been used by a zone administrator.
	Assigning a new RRtype for a resource record to hold this
    	information will provide a simple, standardised way of
    	publishing and retrieving zone status information.

    E.   Description of the proposed RR type.

    	The proposed RRtype is essentially identical to a TXT record:
    	the zone status information contained as free text in the
    	RDATA. Further details about the record format and its
    	potential applications is given in draft-reid-dnsext-zs-01.txt.

    F.   What existing RRTYPE or RRTYPEs come closest to filling that
         need and why are they unsatisfactory?

	The TXT record is the closest RRtype to the one proposed
	here. However TXT records are already used in many zones for
	a variety of purposes. This makes it awkward and impractical
	to differentiate a TXT record containing zone status
	information from other TXT records that may exist for a
	domain name. Allocating a new, dedicated RRtype for zone
	status is the cleanest way to deal with this issue. It would
	also prevent further mission creep by overloading the already
	overloaded TXT RRtype.

    G.   What mnemonic is requested for the new RRTYPE (optional)?
         Note: this can be left blank and the mnemonic decided after the
         template is accepted.

	ZS

    H.   Does the requested RRTYPE make use of any existing IANA
         Registry or require the creation of a new IANA Sub-registry and
         in DNS Parameters?

	No.

    I.   Does the proposal require/expect any changes in DNS
         servers/resolvers that prevent the new type from being
         processed as an unknown RRTYPE (see [RFC3597])?

	No.

    J.   Comments:

    	None.

_______________________________________________
dns-rrtype-applications mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-rrtype-applications

---

From: Ted Hardie <[email-masked]>
Date: Fri, 21 Nov 2008 13:46:59 -0600

Reading this, the justification says:

I don't see how the proposed ZS RRTYPE solves this problem.  It seems
like it has exactly the same problem as TXT does:  it will be completely
unstructured data.  It also seems likely that different zones might
diverge on how they present zone status information.  Is there a draft
that describes the standard for zone status information?

				regards,
					Ted Hardie

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 21 Nov 2008 14:24:42 -0600

>that describes the standard for zone status information?

Olafur was kind enough to point out I had missed the reference
to draft-reid-dnsext-zs-01.txt.  I've gone and read that now,
and I still have the same issue.  It says:

   Apart from its type code, the wire and text formats for the proposed
   ZS RRtype are identical to the definitions of the TXT record given in
   RFC1035:

   ZS RDATA format

               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
               /                   ZS-DATA                    /
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where: ZS-DATA One or more character-strings.

   The ZS RRtype will hold descriptive text intended to contain
   information reflecting the status of the zone in which it is held.

It goes on in the End User Considerations:

  Users publishing ZS records SHOULD pay attention to the needs of
   potential readers of these resource records, especially with respect
   to character sets and language.  Although arbitrary text can be
   stored in character-strings, publishers of ZS records SHOULD
   carefully consider the capabilities of the devices and end users who
   query for ZS records.  For example, a mobile phone or other hand-held
   device may not have the font information or suitable rendering
   capabilities to display (say) Chinese or Arabic characters.
   Similarly, publishers of ZS records should try to avoid displaying
   information in multiple languages or assume that all readers of these
   records understand the same language or languages they have chosen to
   use.  In these circumstances it would be inadvisable to publish a
   string in a ZS record that is unlikely to be intelligible to those
   who lookup ZS records.

This does not seem to me enough information for anyone
wanting to use this to do so without zone specific information.  It
replicates the same issue raised in the template:

	These approaches are confusing and impractical since an
   	arbitrary DNS client needs a priori knowledge of which of
   	these schemes, if any, has been used by a zone administrator.

If I am missing yet more context, my apologies, but I
still don't get the real advantage.
			regards,
				Ted Hardie

---

From: Jim Reid <[email-masked]>
Date: Fri, 21 Nov 2008 20:44:37 +0000

On Nov 21, 2008, at 19:46, Ted Hardie wrote:

> diverge on how they present zone status information.

Well, I suppose the I-D could say something like "don't put more than  
one ZS RR at any node/zone". An unstructured (human readable) text  
string is all that's needed here: anything fancier is overkill IMO. A  
TXT record can't easily provide that info because these are already  
used for too many ad-hoc purposes.

> Is there a draft that describes the standard for zone status  
> information?

No. Though there's an I-D for the template explaining how the RR could  
be used. There is a demonstrated need for this and applications  
in .tel that will use the proposed RRtype. Provided a type code gets  
issued.

All the proposed RRtype tries to achieve is provide a simple,  
lightweight method to get an unstructured string from the DNS that  
presents hopefully informative information about the zone. If a more  
structured record is needed for something more elaborate perhaps that  
could be given yet another RRtype?

---

From: Ted Hardie <[email-masked]>
Date: Fri, 21 Nov 2008 15:24:39 -0600

>used for too many ad-hoc purposes.

Imagine for a moment we're dealing with four zones.  One is
subdomain.delegateddomain.example; one is .example;
one is in-addr.arpa; and one is nic.edu.cctld.  Do you expect
zone status from each one of them to share any common
vocabulary at all?  Is there any common set of tokens or
understandings about what semantics this carries?  In nic.edu.cctld,
if the zone maintainer put "Gleep" and in subdomain.delegateddommain.example
the zone maintainer put "Gleep" do you expect them to mean the same
thing?

I think I would understand this much better if ZS had a well-described
set of potential statuses, even if these are not standardized. 
"Bob's looking at it" and similarly ad-hoc descriptions seem really unlikely
to be helpful outside of the tiny set of people who know who Bob is.
But I can't tell if that sort of thing is in the universe of what you consider
reasonable things to put here.
				regards,
					Ted

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 21 Nov 2008 18:08:49 -0600

>   	descriptive information about the status of the zone,

I observe that the term 'zone' is used in the proposal.

That suggests that the applications that use this RR need to be aware  
of the administrative boundaries in the domain namespace. We do not  
have a good mechanism to find those zone boundaries and that indicates  
that there is more to this than simply query-response; there will be a  
bit of searching.

If the above assumption is correct I would claim that:
Application use as documented makes incorrect assumptions about DNS  
protocol behavior, such as wild cards, CNAME, DNAME etc.

--Olaf

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 21 Nov 2008 19:51:38 -0500

Jim Reid wrote:
> An unstructured (human readable) text string is all that's needed 
> here: anything fancier is overkill IMO. A TXT record can't easily 
> provide that info because these are already used for too many ad-hoc 
> purposes.
Which should be a warning against yet another "unstructured text" RRTYPE.

Lesson learned.

- Kevin

---

From: Jim Reid <[email-masked]>
Date: Sat, 22 Nov 2008 05:02:59 +0000

> I observe that the term 'zone' is used in the proposal.

Well I would have liked to call this the name status or node status  
record. Unfortunately the NS mnemonic is already in use. :-)

If another name beside "zone status" would make people more  
comfortable, please make a suggestion. I don't care what the proposed  
RRtype is called or even what its mnemonic is. What I would like is an  
registered type code instead of being forced to just pluck one from  
the air. I have assumed this was what the 2929bis process would provide.

> That suggests that the applications that use this RR need to be  
> aware of the administrative boundaries in the domain namespace.

They don't. They lookup a name (singular) and if they get a ZS record  
back, that's it. If there's nothing there, they give up. No searching  
or tree walking is involved whatsoever.

> We do not have a good mechanism to find those zone boundaries and  
> that indicates that there is more to this than simply query- 
> response; there will be a bit of searching.

There is nothing more than a simple query-response going on. It's  
wrong to suggest or imply otherwise. If the draft has language which  
gives that misleading impression, please point it out. The proposed  
RRtype is not making any assumptions about DNAME, CNAME, zone cuts,  
wildcards or any of that stuff and doesn't need to. There is  
absolutely no need for any special server or client processing for  
this proposed RRtype. It can be handled according to RFC3597.

---

From: Jim Reid <[email-masked]>
Date: Sat, 22 Nov 2008 05:26:17 +0000

> to be helpful outside of the tiny set of people who know who Bob is.

This is precisely the audience/application for this RRtype. Suppose  
you buy ted.tel. [Available from all good registrars Real Soon  
Now. :-)] You will use this zone to publish your contact details in  
NAPTR records. An application looking up those NAPTRs could also ask  
for the ted.tel ZS record (if it existed). This would hopefully  
contain some sort of status message that you wish to associate with  
that RRset of contact details which the application could then present  
to the end user: "I'm in the IETF bar with a dead laptop", "Don't call  
my mobile because I'm overseas", that sort of thing. You would publish  
that message as a string in whatever language made most sense to  
whoever you expected to lookup the record. It's that simple.

A more structured RRtype really isn't needed for this particular  
requirement. It's also undesirable IMO since that implies subtyping  
and maintaining a registry of codes and their significance. Plus  
whatever other structure and add-on features someone might want to  
throw in. All of which will require on-going maintenance and a process  
for updating that registry. Not to mention documenting how an  
application/client/server is expected to behave when presented with  
one of these codes, etc, etc. Seems like a very large sledgehammer to  
crack a very small nut.

If you want to work on a more structured record for some future  
application, I'll be happy to help. But the requirements that ZS meets  
needs nothing fancier than a blob of text. If the proposal merited a  
more complex structure and semantics, it would have got them.

---

From: [email-masked]
Date: Sat, 22 Nov 2008 13:11:11 +0000

> whoever you expected to lookup the record. It's that simple.

	have you considered resurecting the WKS RR for this purpose?

--bill

---

From: Olaf Kolkman <[email-masked]>
Date: Sat, 22 Nov 2008 07:26:12 -0600

On Nov 21, 2008, at 11:02 PM, Jim Reid wrote:

> They don't. They lookup a name (singular) and if they get a ZS  
> record back, that's it. If there's nothing there, they give up. No  
> searching or tree walking is involved whatsoever.

The name of the record and the specification made me wonder: question  
needed to be asked. Your answer is clear. It is probably good to add  
this clarification to the request before it disappears in the archives.

> wrong to suggest or imply otherwise.

Although my mail did not contain question marks it was intended as a  
question ('if the above assumption is correct').

More to draft-ietf-dnsext-2929bis than to your request. I think that  
if a specification assumes knowledge of administrative boundaries in  
the domain namespace than that is an argument to deny the code point.  
I would think that such would be an incorrect assumption about DNS  
protocol behavior. Which could be, absent further specification, a  
reason to deny the code point. Is that a reasonable assumption?

--Olaf

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 22 Nov 2008 07:39:50 -0600

On 22 nov 2008, at 07.26, Olaf Kolkman wrote:

> I think that if a specification assumes knowledge of administrative  
> boundaries in the domain namespace than that is an argument to deny  
> the code point.

+(+(+(+1)))

    paf

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sat, 22 Nov 2008 15:05:08 +0100

+(+(+(+1)))
    
        paf
    
Yes, indeed,

	jaap

---

From: [email-masked]
Date: Sat, 22 Nov 2008 14:37:13 +0000

> the domain namespace than that is an argument to deny the code point.  

perhaps a (-1) is useful here.  there are two points in the namespace graph
that assume some knowledge of the administrative boundaries...  the root and
the leaf.

if this WKS look-alike emerges -AND- is used in the RRset of a leaf, then it
is reasonable to assume certain adminstrative bounds and no real good reason
to deny the code point.

if someone uses this elsewhere in the graph, then it has no meaning.

--bill

---

From: Ted Hardie <[email-masked]>
Date: Sat, 22 Nov 2008 08:51:25 -0600

>whoever you expected to lookup the record. It's that simple.

This seems to me to attempt to replicate the presence infrastructure
in a single DNS record.  We have a presence system already (see RFC 3859
for the pres uri, RFC 3861 for the resolution service for IM & presence,
and rfc 3953 for the ENUM presence service), along with the SIP and XMPP
RFCs for the systems supporting this.

Even if pushing presence directly into the DNS without all of the
existing presence infrastructure is a good idea (and there is a lot
this leaves out, especially in terms of ability to give multiple
different views to different requesters), this RR doesn't seem to
guarantee that other uses of this map to presence.  in-addr
records, for example, wouldn't have the same sorts of presence,
nor would sub.domain.example.  With this being unstructured,
they might well get re-used in zones like those in very different ways.

			regards,
				Ted

---

From: Jim Reid <[email-masked]>
Date: Sat, 22 Nov 2008 23:38:09 +0000

> have you considered resurecting the WKS RR for this purpose?

No. Some bad ideas should remain dead. :-)

---

From: Jim Reid <[email-masked]>
Date: Sat, 22 Nov 2008 15:54:51 +0000

On Nov 22, 2008, at 14:51, Ted Hardie wrote:

in a single DNS record.

Not really. Though it is a very dumbed down and informal way of providing a very limited form of presence info. It doesn't replicate or compete or conflict or overlap with the much more robust and reliable presence services you outline below. It's orthogonal to them.

We have a presence system already (see RFC 3859

I am aware of this. These solutions don't fit the requirements. One of which is to retrieve this info from the DNS in a single lookup. We can guarantee anyone holding a .tel domain will have DNS servers running. We cannot and must not assume they have access to a SIP or XMPP service. If the domain holders want to use those services for presence, that's their choice. But this proposed RRtype is not interfering with those mechanisms and choices. Another requirement is to avoid the complexity and latency of fishing through a bunch of NAPTRs, looking for SIP or XMPP URIs, then talking to the servers at the end of these URIs in the hope of maybe getting presence info out of them.

The mechanism is supposed to be something very simple and lightweight, without involving lots of protocols. And ideally avoiding a TCP connection. DNS does the job. Adding SIP or XMPP stacks to these applications would be unreasonable, especially when there might not be something at the other end which is providing true presence info because the domain owner isn't using SIP or whatever.

archive:

---

From: [email-masked]
Date: Sun, 23 Nov 2008 22:01:37 +0000

> No. Some bad ideas should remain dead. :-)

	i'm not seeing how the ZS proposal is functionally distinct
	from WKS.

--bill

---

From: Peter Koch <[email-masked]>
Date: Mon, 24 Nov 2008 17:43:18 +0100

> reason to deny the code point. Is that a reasonable assumption?

absolutely.  Zones provide provisioning only boundaries that MUST NOT
influence client side processing or interpretation of the data.

-Peter

---

From: bert hubert <[email-masked]>
Date: Mon, 24 Nov 2008 18:25:40 +0100

> 	here. However TXT records are already used in many zones for

How about RP, Responsible Person?

It even lists some of the things we are talking about:

   sayshell.umd.edu. A     128.8.1.14
                     MX    10 sayshell.umd.edu.
                     HINFO NeXT UNIX
                     WKS   128.8.1.14 tcp ftp telnet smtp
                     RP    louie.trantor.umd.edu.  LAM1.people.umd.edu.

   LAM1.people.umd.edu. TXT (
         "Louis A. Mamakos, (301) 454-2946, don't call me at home!" )

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Peter Koch <[email-masked]>
Date: Mon, 24 Nov 2008 18:40:46 +0100

Jim,

> or tree walking is involved whatsoever.

good.  The term "zone", however, implies, that the semantics apply to
more than just the node queried for. So, in your vision, would the "status"
RR for "jim.example" also cover "another.jim.example"?

> this proposed RRtype. It can be handled according to RFC3597.

This proposed RR type reminds me of HINFO (rather than WKS), recognizing
that HINFO had - at least in the beginning - stricter semantics and indeed
a "registry" for its values.  Now, given that the new RR's sematics
aren't at all specified, wouldn't "TXT2" better describe it?
More serious, is the RR definition general enough or is it only useful
in a particular, maybe even highly regulated, namespace?  If the resolution
context is provided by the namespace, wouldn't a "Private Use" code do better?

-Peter

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 25 Nov 2008 15:45:54 +0100

>        descriptive information about the status of the zone,

This makes sense. I can see a number of registries making use of such
a record to indicate that the delegation isn't active any more, because
a domain

* has expired
* was removed by court order
* was deleted due to missed payment
* ...

(A number of registries seem to use TXT records right now to indicate
some of these states in their zone.)

>        particularly for zones holding real-time contact data. 

Here you lost me, especially with the examples you quote later in this thread.

They do not contain information about the status of a domain/zone, but
about the status (reachability, location, ...) of the _owner_ of that domain.

In the context of .tel, I can imagine a ZS record to indicate whether
the information in the zone is up-to-date or stale.

For anything else, the name just doesn't fit.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Nov 2008 10:06:26 -0500

>* was deleted due to missed payment

(A digression...)

That is what WhoIs or IRIS is for.  The DNS should neither be a 
database nor a database inspection tool.  It's just a lookup protocol.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Jim Reid <[email-masked]>
Date: Tue, 25 Nov 2008 15:06:04 +0000

> For anything else, the name just doesn't fit.

I am painfully aware of this. :-) There would have been far less noise  
on this list if the template was for the FOO record. Too much emphasis  
has been placed on the proposed name, which has sparked a discussion  
that has nothing to do with the proposed RRtype's semantics. I  
inadvertedly picked a name that needlessly caused this. Sigh.

So can we pick some other name and stop obsessing about that? The name  
of the proposed RRtype does not matter.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 25 Nov 2008 20:01:36 +0000

--On 21 November 2008 13:03:48 -0600 Andrew Sullivan <[email-masked]> 
wrote:

> draft-reid-dnsext-zs-01.txt

OK, so quite apart from the ZI/NI/NINFO point, my observations are as
follows.

The above draft notes correctly (at 2) that:
   The DNS does
   not currently provide a well defined mechanism for obtaining
   information about the status of a zone: what it is being used for,
   the significance of the zone's contents, when the zone was last
   updated and so on.  This means a variety of ad-hoc techniques are
   deployed whenever zone administrators choose to make this information
   available

and that (at 4):
   TXT records are unsuitable for providing this sort of zone status
   information because the semantics of TXT record RDATA are
   unstructured.  TXT records can and are used for all sorts of
   purposes: version control strings, comments or reminders to zone
   administrators, anti-spam information, references to ticketing
   systems, contact details of the zone administrator and so on.  It
   would be impractical for an application to interpret the contents of
   a response to a TXT query and guess which, if any, of the returned
   TXT records contained meaningful data about the status of the zone.

I don't see how ZI/NI/NINFO helps here. As far as I can tell, the
proposed record is similarly unstructured. The draft gives the
proposed (I think) example of a ZI record (at 3) the textual string
   "Use of example.net was
   deprecated on April 1st.  Please visit example.com instead."

OK so that can be separated from various other non-informational
possible uses of TXT records (i.e. anything outside the rather
broad scope of this proposal), but I don't see how an
"application can interpret" the contents of a ZI record
any more than it can a TXT record.

Equally, as the proposed purpose is so broad, it might be
necessary to use it for two purposes, e.g. pending deprecation,
and "Bill's not on this number right now, he's on that number".
The proposed scheme gives no means of determining between the two.
So in an environment where it can be parsed by an application,
it isn't even possible for application X to distinguish between
strings intended for application X and strings that X can parse
that were in fact intended for application Y.

I'm sort of reading between the lines as to the proposed usage,
and thinking perhaps (ab)using an SRV type structure might be the
right way forward. If one (mis)used a protocol definition
to mean "application / end user specific data" (say a
rogue value of _app for the protocol field), one could
at least distinguish fooco's app "out of office" by
something like:

 _outofoffice._fooco_com.jim.example.com 3600 IN NINFO "ABC123: Jim is out 
of the office until 3pm"

(and letting the underscore translation from fooco.com act as
the sufficient guarantee of uniqueness).

On the other hand, perhaps even this could be done with a TXT record
equally well.

Alex

---

From: Jim Reid <[email-masked]>
Date: Wed, 26 Nov 2008 12:10:17 +0000

On Nov 25, 2008, at 20:01, Alex Bligh wrote:

> but I don't see how an "application can interpret" the contents of a  
> ZI record

This is true. However with a new RRtype, these messages can at least  
be separated from whatever TXT record gunk is already in use. BTW,  
there are no semantics here for applications to interpret: if they  
lookup an NINFO record, they just present it/them to the end user.

> one could at least distinguish fooco's app "out of office" by
> something like:
>
> _outofoffice._fooco_com.jim.example.com 3600 IN NINFO "ABC123: Jim  
> is out of the office until 3pm"
>

And both would rely on clients having a priori knowledge of which  
string to prepend to the name to get a status message for a particular  
purpose. Or would force clients to enumerate all possible prefix  
combinations in order to find out which one, if any, has the flavour- 
of-the-moment NINFO record. Which can't work.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 26 Nov 2008 12:17:57 +0000

--On 26 November 2008 12:10:17 +0000 Jim Reid <[email-masked]> wrote:

> And both would rely on clients having a priori knowledge of which string
> to prepend to the name to get a status message for a particular purpose.
> Or would force clients to enumerate all possible prefix combinations in
> order to find out which one, if any, has the flavour-of-the-moment NINFO
> record. Which can't work.

If an *application* can interpret it (as per the draft), it must have a
priori knowledge of the format of the record, which makes it no harder
to give it a priori knowledge of the name to prepend (or whatever).

If your idea is to give a status field which cannot necessarily be
interpreted by an application (but perhaps can be by a human being who
speaks the appropriate language), then this isn't an issue. But then this
isn't what the draft says, and I don't really understand what it's for
(sorry).

Alex

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Nov 2008 10:04:44 -0500

At 12:10 +0000 11/26/08, Jim Reid wrote:

>And both would rely on clients having a priori knowledge of which string to
>prepend to the name to get a status message for a particular purpose. Or would
>force clients to enumerate all possible prefix combinations in order to find
>out which one, if any, has the flavour-of-the-moment NINFO record. Which can't
>work.

Clients have to have a priori knowledge of the type to as ask for. 
You can standardize on one prefix.  The difference is between asking 
for:

        domain.name.tld / NINFO / INclass
or for this:
        ninfo.domain.name.tld. / TXT / INclass

I know I prefer the former myself, but, I also get the willies adding 
TXT2.  The only place there is unstructured data in DNS is the TXT 
record.

"Node Information" is something that could be generally co-opted for 
other purposes and hence the string it contains might take on other 
semantics.  This is my reluctance.  What keeps other records - other 
than TXT - from being co-opted?  Hmmm.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Ted Hardie <[email-masked]>
Date: Wed, 26 Nov 2008 16:22:35 -0800

>lookup an NINFO record, they just present it/them to the end user.

I believe I understand the requirements here, but I don't believe
a new record is indicated.  In the .tel example Jim has given there
is no real reason for the TXT records with "lots of other gunk" to be
present--what, someone is going to be putting SPF records in my
.tel aor record? 

If we do include this, I strongly believe it will be immediately
re-used for other "whatever you'd like" style records, and that the
gunk argument *there* will repeat.  There is nothing to protect
this from re-use.

There are lots of other ways to do presence; doing it in the DNS
isn't that great an optimization, and doing it in TXT in the DNS
is not greatly different from this.  Tell the application to display
TXT records with the prefix NINFO and none others.   Yes, if
you somehow have both NINFO and 13-dozen other TXT records,
you might have to fall back to TCP.  But the chance of that in
the given use case seems reasonably remote, and the chance
of additional clutter with another unstructured record seems
pretty high.

2 cents,
				Ted

---

From: Shane Kerr <[email-masked]>
Date: Thu, 27 Nov 2008 13:12:33 +0100

Ted,

> of additional clutter with another unstructured record seems

I guess the IETF does not want to support standards that it does not
consider "good". However, in the past this has led to people simply
ignoring the IETF and doing things their own way, in an undocumented and
non-interoperable way. Why yes, I *am* thinking of NAT and Skype and P2P
and SPF and plenty of other things I use daily...

IIRC, the SPF folks put records into TXT records because they had no
other way to do it. In the midst of the nuclear-hot flames that were
directed their way when they entered the IETF arena were complaints that
they were putting structured data into an unstructured field. So, now we
have the SPF record. (I may not be remembering this perfectly, so
someone involved with the effort feel free to correct me.)

Based on that history, I think Jim is Doing the Right Thing by trying to
get the NINFO RR assigned.

Regarding whether or not we want DNS to allow "gunk" or "clutter", I
have to admit I don't share the DNS religion about wanting to keep stuff
*out* of the DNS. I think there are huge classes of problems that share
similar properties to things that do work well with DNS-style lookups,
and given that DNS is arguably the most successful distributed database
it makes sense that these will appear.

This desire has been there as long as I have been working with DNS, and
will only get worse once people have the ability to authenticate the
contents of DNS.

Regarding the specific proposal... I agree that asking for a bit more
structure makes sense. Perhaps some ideas from existing presence
mechanisms can be used?

--
Shane

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 28 Nov 2008 09:12:25 +0100

On Thu, Nov 27, 2008 at 01:12:33PM +0100,
 Shane Kerr <[email-masked]> wrote 
 a message of 77 lines which said:

> directed their way when they entered the IETF arena were complaints
> that they were putting structured data into an unstructured
> field. So, now we have the SPF record. (I may not be remembering
> this perfectly, so someone involved with the effort feel free to
> correct me.)

No, no, you're right. But there is one more thing to consider: it was
before RFC 5395 and, at this time, registering a new RR type was very
complicated (even if the IETF denied it).