Subject: IANA type code registration clean up

From: Edward Lewis <[email-masked]>
Date: Wed, 13 Jun 2007 12:57:17 -0400

Yet another non-technical bureaucratic thread...

Looking at this URL:

http://www.iana.org/assignments/dns-parameters

the IANA has allocated a number of RR type codes that are not 
documented in RFC documents.  I don't really care much about the 
procedural problem, but imagine someone trying to implement a DNS 
element without looking at the BIND source code.

I would point an implementer to the IANA pages to see what, for 
instance, RTYPE codes have been defined.  I would expect that the 
IANA registry would then identify the document describing the type. 
The URL above has a bunch of lame or weak pointers (to some of the 
types) and I have been trying to get IANA to change that (going back 
a few years now).

That's not the question or matter for this group though. The question 
is what should be done about these undocumented types?

Answer A - document them.
Answer B - deprecate them.

Answer A's downside is that this would mean work.  I can find the 
last known drafts for many of them, but finding out why they 
died/expired is rather hard.  The IETF is notorious for not 
documenting the rationale for disposing of ideas.  (I tried to do 
this recently for ULA-Central and wound up having to send mail to the 
editors, whose email's in the last draft still fortunately worked.)

Besides the threat of having to do work, something I try to avoid 
personally, the bigger problem would be that if we did publish an RFC 
containing the definition of these types, like SINK, EID, NIMROD, 
folks might take it that we have approved of these types.  I have 
nothing against the types - it's just that they are ideas that have 
been killed and have seemingly successfully have stayed dead and 
buried.

But if you have to write compliant software...ok, what's compliant? 
I'll leave that to your imagination.

Answer B's downside is that we don't like to do garbage management in 
the IETF.  The number one reason for not progressing ideas is that we 
are afraid we'd have to cull them later on, and we don't do that. 
(Yes, Bill, I know there is probably somewhere someone using a BIND 
3.12.34s05May1983 version out there that has been modified to use 
SINK and thinks that if we deprecate the number we will cause their 
island economy to go belly up.)

As both of these Answers have down sides, I'll propose this:

Answer C - do nothing and hope no one cares.

I bet that is the answer that will win out here.  The downside is 
that we will continue to have a gray area of information about the 
DNS protocol.  When others read up on the DNS and get confused, we 
won't be able to say "RTFM" - we'll have to say "sorry, my bad."

Is there any desire to try to clean up what is in the IANA registry? 
Other than at least getting updated references?  Do we want to mark 
the undocumented types as deprecated, not to be implemented?  NIMROD, 
EID - does Patton's BBN account still work? ;)

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

Sarcasm doesn't scale.

--
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: Douglas Otis <[email-masked]>
Date: Wed, 13 Jun 2007 11:43:02 -0700

On Jun 13, 2007, at 9:57 AM, Edward Lewis wrote:

> types) and I have been trying to get IANA to change that (going  
> back a few years now).
>
> That's not the question or matter for this group though. The  
> question is what should be done about these undocumented types?
>

+B.

Would this require a draft listing these items to assist IANA in  
making the changes?

-Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Jun 2007 14:42:41 -0400

> Answer B - deprecate them.

Answer AB: document _and_ deprecate.  

I'm serious.  I know this is work, but I think we should write these
down somewhere, and say they're deprecated and needn't be implemented.
At least then someone writing a compliant system that gets one of
these types in a query knows what it is supposed to be and that it can
be ignored.

Yes, I am volunteering.  Do you have some pointers that I should go
read, so that I don't have to start all your forensic work from
scratch?

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 13 Jun 2007 14:55:12 -0400

Edward Lewis wrote:

> the IANA has allocated a number of RR type codes that are not documented 
> in RFC documents.  [...]
> 
> [...] The question is 
> what should be done about these undocumented types?
> 
> [...]
> [...]

Many of these RR type codes would, if re-registered with 
draft-ietf-dnsext-2929bis, answer NO to the following IANA registration 
template question:

Does the proposed RR TYPE require special handling within the DNS 
different from an Unknown RR TYPE or ignorable meta-TYPE?

Thus, you may consider

  Answer D - identify those not requiring special implementation handling

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 13 Jun 2007 15:26:01 -0400

At 11:43 -0700 6/13/07, Douglas Otis wrote:

>Would this require a draft listing these items to assist IANA in making the
>changes?

More so than getting changes in IANA is the document saying that the 
types have no definition with respect to the names registered.  It's 
not that these are unknown type codes - they have names.  We should 
say that the type code, say, 32, isn't to be assumed to be NIMROD 
anymore.  It could be, it might be, just don't count on it and don't 
sweat implementing it.

What I want to defend against here is that some business contract 
says "implement a full DNS server" and the poor coders can't find the 
RDATA format for NIMROD.  Neither the IETF nor IANA require/enforce 
compliance, it is in the hands of the contracts we run under.

I see this has a potentially multi-step process.

1) Note that the types are meaningless and discourage anyone from *requiring*
their implementation.

2) Request IANA revert the values to undefined and tell folks to rip 
the implementations of these types from their future releases and 
instead treat them as unknown types when seen on the wire.

3) Reusing the type values and tell folks to to add code to future 
releases to handle the type a certain way.

I don't think we want to do step 2 now, much less step 3.  I'm 
stating them just to give the contrast of what step 1 is.  The 
document I have in mind ought not rule out anyone from using the 
types as they might already be doing, the document is strictly there 
to warn against requiring any implementation to do the types.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 13 Jun 2007 15:12:18 -0400

>read, so that I don't have to start all your forensic work from

Yeah I do.  While thinking more about this, I realized that all we 
would need to do is list the values and the mnemonics and then say 
"just don't do it."  So I agree on an answer AB.

But there is one possible exception to outright deprecation of all 
the un-RFC'd types, the ATMA record.  All but the ATMA died when 
their draft expired.  The ATM one is defined in a document published 
external to the IETF.  (But I get heartburn over that - the ATM Forum 
is where the document was originally published.  The ATM Forum is no 
longer amongst the living and even it's web site is gone.)

In talking to IANA on the side I noticed that they had cleaned up a 
lot of the references (there were a few types in 2005 that were 
RFC'd, like AAAA, that weren't documented as such and now are) but 
these remain:

old NSAP-PTR        23
new NSAP-PTR        23 for domain name pointer, NSAP style   [RFC1348]

old EID             31 Endpoint Identifier           [Patton]
new EID             31 Endpoint Identifier
     [http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt]

old NIMLOC          32 Nimrod Locator                [Patton]
new NIMLOC          32 Nimrod Locator
     [http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt]

old ATMA            34 ATM Address                   [Dobrowski]
new ATMA            34 ATM Address
     [http://www.mfaforum.org/ftp/pub/approved-specs/af-saa-0069.000.pdf]

old SINK            40 SINK                          [Eastlake]
new SINK            40 SINK
     [http://bgp.potaroo.net/ietf/all-ids/draft-eastlake-kitchen-sink-02.txt]

The first may be just an editor's choice (see the page for what I 
mean), the next two and last are types that were not quite formed. 
The ATMA is the one defined elsewhere.  All URLs work as of today.

What I haven't considered are RFC'd types that are dead too - because 
I am not looking at a bureaucratic cleansing, more at "what do we 
need to leave for new implementors."

Sarcasm doesn't scale.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Jun 2007 10:39:44 +1000

> The ATMA is the one defined elsewhere.  All URLs work as of today.

	Of the list above BIND 9 only implements NSAP-PTR.
	ATM looks like it is straight forward to implement.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 13 Jun 2007 15:16:26 -0400

>	SINK came much later.

I knew you'd say that, which is why I added "has been modified to" in 
the paragraph!

>	the sad part about RFC's is that they are fixed in time.
>	I do note that the IANA has tweeked the registry...  UID/GID
>	are now [IANA-reserved]

Works for me. ;)

Sarcasm doesn't scale.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 13 Jun 2007 23:25:37 -0400

>	ATM looks like it is straight forward to implement.

The question isn't how easy they are to implement.  It's whether they 
should be	defined in such a way that it is trivial to find the 
specification.

For ATMA, I have kept my eye on that reference for years, ever since 
I wrote DNSSEC code in the late 90's.  It's a no-brainer, if you have 
the document.  Back then, it was on the ATM Forum's web site, I found 
it via a MSN technical documents page that I probably got to via 
Altavista or some such antique search engine.

When the ATM Forum disbanded I learned that web site was transferred 
to the MFA Forum.  Eventually the MFA Forum retired the ATM Forum web 
site and moved the document to their public store.

Today I tried to contact the IANA-listed mail address for the 
document.  The host of the mail address is no longer in DNS.  I was 
hoping to ask the listed contact person whether the record was still 
in use.

I tried to Google for the contact while writing this and learned that 
Amazon is selling a book by him (or someone with the same name and a 
lot of other intangible similarities) and that he's a CTO of some 
company.  Googling for that company I see it was merged into another 
in 2001.  Umm, maybe you get the idea that it's a bit hard to chase 
down the references.  Maybe he's now [email-masked] 
from a March 2006 attendee list on the web.

I've been concerned that we may lose this document at some point. 
Not that the MFA Forum would have a reason to hide it or yank it, it 
might just be thrown out as obsoleted trash someday. It's not trivial 
to implement what you can't get the specification for.

For the other records, I am sure they are also trivial to implement, 
I recall EID being simple.  But these never for adopted by the IETF 
(I don't know why).  Should we take this as an implicit statement 
that those type values ought to be "reserved by IANA?"  I think it is 
a no-brainer that we document the types we know and "control" (in the 
sense of an IETF action) that are dead but have type values.

The ATMA is a weird case - it never was reviewed by the IETF, not as 
far as I can find.  So we can't really pass judgement on it.  Still 
it would be nice to know that there is a specification for it, where 
it is, and if it is ever deprecated by the owning organization that 
we make a note of that in the IANA registry for DNS parameters.

Sarcasm doesn't scale.

---

From: Danny Mayer <[email-masked]>
Date: Thu, 14 Jun 2007 00:08:39 -0400

Edward Lewis wrote:
> in RFC documents.  I don't really care much about the procedural
> problem, but imagine someone trying to implement a DNS element without
> looking at the BIND source code.
> 
> instance, RTYPE codes have been defined.  I would expect that the IANA
> registry would then identify the document describing the type. The URL
> above has a bunch of lame or weak pointers (to some of the types) and I
> have been trying to get IANA to change that (going back a few years now).
> 
> That's not the question or matter for this group though. The question is
> Answer A's downside is that this would mean work.  I can find the last
> known drafts for many of them, but finding out why they died/expired is
> rather hard.  The IETF is notorious for not documenting the rationale
> for disposing of ideas.  (I tried to do this recently for ULA-Central
> and wound up having to send mail to the editors, whose email's in the
> last draft still fortunately worked.)
> 
> containing the definition of these types, like SINK, EID, NIMROD, folks
> might take it that we have approved of these types.  I have nothing
> against the types - it's just that they are ideas that have been killed
> and have seemingly successfully have stayed dead and buried.
> 
> But if you have to write compliant software...ok, what's compliant? I'll
> leave that to your imagination.
> 
> are afraid we'd have to cull them later on, and we don't do that. (Yes,
> Bill, I know there is probably somewhere someone using a BIND
> 3.12.34s05May1983 version out there that has been modified to use SINK
> and thinks that if we deprecate the number we will cause their island
> economy to go belly up.)
> 
> I bet that is the answer that will win out here.  The downside is that
> we will continue to have a gray area of information about the DNS
> protocol.  When others read up on the DNS and get confused, we won't be
> able to say "RTFM" - we'll have to say "sorry, my bad."
> 
> Other than at least getting updated references?  Do we want to mark the
> undocumented types as deprecated, not to be implemented?  NIMROD, EID -
> does Patton's BBN account still work? ;)
> 

Weren't other types like MAILA, MD, MF and WKS deprecated somewhere? I
can't find a document on it. If so then it's been done before and the
same path can be followed.

Danny

Danny

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Jun 2007 16:29:49 +1000

> should be	defined in such a way that it is trivial to find the 

	I think the best solution for ATM would be for the IETF
	Trust to get permission to hold and distribute the pdf.
 
> we make a note of that in the IANA registry for DNS parameters.

	The reverse naming scheme for ATM seems to be fundementally
	broken.  It requires too much pre knowledge to construct the
	name.  You should be able to take the address and be able to
	constuct a appropriate name without having to have a set of
	country code values to know what to put into which label.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 14 Jun 2007 08:35:14 -0400

(Answers to Bill's, Danny's, and Mark's replies.)

At 4:42 +0000 6/14/07, [email-masked] wrote:
>On Thu, Jun 14, 2007 at 12:08:39AM -0400, Danny Mayer wrote:

(Bill)
>	So Ed is concerned that the IANA registry points to documents
>	and people who (might) change/move over time and the original
>	reference will be lost ... the IANA has a dangling pointer.
>
>	Is this the jist of your concern Ed?

Not exactly.  Although I have been labelled anal retentive [1] about 
keeping things in order, I agree that would be too much work.  The 
jist of mu concern is ... if I were to walk off the street and try to 
write up a DNS protocol element (server, stub, etc.) can I find all 
of the documentation to create a compliant hunk of code.

IANA's role, as registry of protocol parameters, is that it is the 
authority on things like the standardized RR types - much like ARIN 
will let you know who is responsible for an IP address or my employer 
would let you know who is responsible for a name registered with us.

IANA's registrations ought to be kept up to date as much as ARIN's. 
With the case of ARIN, we expect the registrants to do this work, not 
the registry and I think it is fair to expect the same with IANA. 
(That is why I am pressing this within the DNSEXT working group and 
not throwing flames at IANA.)

So, the job is on us to clean this up and hand the work to IANA.

>	Back in the day, I understood the IANA took the stance that
>	they would document assignments but it was not in their charter
>	to hold copies of the defining documents... that was the role of
>	the hosting organization, be it IETF, ITU, ATMF, BBN, MIT, etc.
>	If the hosting org chose to let the reference document lapse,
>	so be it.

I agree with that, IANA is a registry, not the Library of the 
Internet.  IANA is also not responsible to make sure that the entries 
in the registries they run are accurate, well-thought ought, etc.

My recent spate of email isn't about cleaning up IANA, it's making 
sure that a person can come in and find the resources to create an 
interoperable implementation without having to read BIND's source 
code or buy more beer for any one of us that do know the protocol.

Ok, so my main motivation is to lose weight, okay?  I admit it, I 
need to lose a few fat cells.  This really came from my medical care 
professional, still not from my tendency to be anal retentive.

(Danny)
>>  same path can be followed.

Yeah, I've heard the same rumor. ;)  I've also been asked for a 
reference document on "forward zones" and other such (Loch) 
Nessie[2]-like creatures of the DNS protocol.  (They are 
implementation specific configuration elements, not protocol 
standards.)  In recent years I have come to be surprised how little 
(percentage wise) of the DNS protocol is really in a document, 
instead residing in our brains.  'Course, it is good for job security.

But once we all retire, will the next generation of engineers be able 
to keep it up?

>	There may be a handful of people who -KNOW- why these RR codes were
>	created.  The documentation for their creation is, to my knowledge,
>	nonexistant.  Now the IANA has flagged the codes as [IANA-reserved],
>	but there is no data on how they got there, other than hearsay.

Ahh, Bill, perfect timing.  That's exactly the condition I want to 
reverse.  There's no reason not to document something and say here's 
how it is now.  (Kinda like the testament of the "Church of What's 
Happening Now.[3]")  This handful of people no doubt will want to go 
away and no longer be bothered with their youthful indiscretions.

Just because something came and left tracks doesn't mean we have to 
preserve it, we should document that these things are no longer in 
the mainstream.  It's alright to leave them reserved for some 
unknown, undocumented reason but let's put something down in writing 
that the class of 2173 engineers of La Univeridad del San Manning can 
use to reclaim the numbers when needed to allocate the VIXIE resource 
record.  By then, I'm sure there won't be one computer still around 
on the face of Mars still using the MB record.

>	Trust to get permission to hold and distribute the pdf.

Something to consider.  Who is the contact for that request?  Ray Palletier?

[1] http://en.wikipedia.org/wiki/Anal_retentive
[2] http://en.wikipedia.org/wiki/Nessie
[3] http://en.wikipedia.org/wiki/Flip_Wilson, "His characters 
included Reverend Leroy, pastor of the Church of What's Happening Now"
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 14 Jun 2007 12:00:30 -0400

>Yes, I am volunteering.  Do you have some pointers that I should go

Oh, and I heard that...

First steps before trying to cut English is to agree on what types 
need a few words and what to say.

Here are the type values that I think don't quite add up.  Perhaps 
there are more - I was merely looking to see if there were documents 
that support the general knowledge of the type.  When I say IANA 
should do something or doesn't list something, I am referring to the 
dns-parameters web page.

11 - WKS is widely rumored to be dead, but I can't find a document to 
back that up.  (I suppose other types are as dead, but no 
documentation.)
14 - IANA should mark this as EXPERIMENTAL as per 1035.
16 and 17 - these are the two types in RFC 1002 that conflict with 
the TXT and the RP types.
23 - NSAP-PTR is blank, presumably that is meant as a "ditto" to the 
previous line.
31 and 32 - EID and NIMLOC have no document to define them.
34 - IANA's reference is an email address that is out of date.
38 - IANA doesn't list 3363 which moved A6 to experimental.
40 - SINK has no defining document listed.
100-103 - no explanation why these are IANA reserved are documented.

I am sure we can consider other types dead or in a vegetative state, 
like X25, but my goal here is just to make sure that if you are told 
to implement a DNS protocol speaking element, you have access to a 
complete specification, not necessarily a sensible specification.

I'm sure that the "problems" with types 14, 23, and 38 are just 
editorial moves needed on the web page.

I am only "excited" about the conflicting definitions of types 16 and 
17 because the types that we don't recognize are defined in a 
document that has attained "STD" status.

Are there other types people would like to see treated?

Sarcasm doesn't scale.

---

From: Jim Reid <[email-masked]>
Date: Thu, 14 Jun 2007 17:33:35 +0100

Ed, if you're going to clean out the RR type code stable, how about  
declaring all codes that don't have documentation as dead or retired?  
Presumably if someone is still using such codes they would scream  
about their impending termination. And if that was to happen, they  
could then become the stuckees who eat their own dog food and  
document those type codes.
Perhaps this is being naive.

---

From: "Blacka, David" <[email-masked]>
Date: Thu, 14 Jun 2007 13:00:35 -0400

Jim Reid wrote:
> Presumably if someone is still using such codes they would scream about
> their impending termination. And if that was to happen, they could then
> become the stuckees who eat their own dog food and document those type
> codes.

> Perhaps this is being naive.

I think it is a little naive, in that I think that the likelihood that
the user of one of these types will be paying attention to what this WG
does is quite low.

However, as long as we don't assign new types to the old numbers, these
potential stuckees are free to pipe up at any time in the future, and,
in the mean time, the rest of us don't have to waste time trying to
implement these types.  Or even find their specifications.

Hm, I think this means that I'm in favor of Ed's option B.
-- 
David Blacka                          <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

---

From: Danny Mayer <[email-masked]>
Date: Thu, 14 Jun 2007 13:06:43 -0400

[email-masked] wrote:
> 	wrt deprication, sure, it can be done.  but that step is a different
> 	activity than the concerns listed above.  Even if a DNS attribute is
> 	depricated, the source document that caused its creation may be
> 	in doubt.  ...  witness UID and GID.   
> 

Yes but if you have deprecation documents you can at least say that they
don't need to be implemented and if you can find the documents you can
reference them and if not you can say that they could not be found. You
don't need to implement something that's been deprecated as long as
there's a document saying so.

You can drag a dead horse to water, but how do you get it to drink?

Danny

---

From: David Conrad <[email-masked]>
Date: Thu, 14 Jun 2007 10:19:43 -0700

> declaring all codes that don't have documentation as dead or  
> retired? Presumably if someone is still using such codes they would  
> scream about their impending termination.

How would they know?

Rgds,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Thu, 14 Jun 2007 13:43:23 -0400

At 17:19 +0000 6/14/07, [email-masked] wrote:
>On Thu, Jun 14, 2007 at 01:06:43PM -0400, Danny Mayer wrote:

I looked up these this morning.  MD and MF are marked as obsolete in 
RFC 1035.  IANA has that correctly recorded, so I consider those 
types "handled."  I.e., I have no problem seeing them listed and am 
happy that I can find a reference that tells me whether I ought to 
code them up or not, and if so, how to.

WKS is something that seems to be a fat rumor.  I think that if it is 
a bad idea, someone owes a document to say that just for posterity 
and then include an IANA action to mark the registration of that code 
as obsolete.

MAILA is also listed as obsolete in RFC 1035 (see section 3.2.3).

To my surprise, most of the early registrations are clean.  Of the 
first 30, only the WKS is what amounts to an "issue".  Others are 
look like registration edits.  It's the newer stuff that gets sloppy.

>>  > 	in doubt.  ...  witness UID and GID.

Deprecation is different from just fixing the registrations.  If 
someone wants to keep using NXT, so be it.  It ain't gonna hurt no 
one.  But I don't want some hapless college junior to miss out on a 
night drinking at the local pub because he's wasting time testing out 
the NXT code in his project.

>	(and as the designer/original implementor of NSAP-PTR, while there
>	is no document deprecating it, there was near universal WG agreement
>	that it was superfulous (nearly everything NSAP-PTR did can be done w/
>	PTR and w/ the IANA's permission, we "declared" it deprecated... which
>	is why you don't see AAAA-PTR today.. )**

Well, then some WG owes the IETF a document.  That's a different 
issue than what I set out to do.  But if we want to roll in a 
"deprecate anything Bill has ever defined" I could see that being a 
benefit.

Uh, ;).

Sarcasm doesn't scale.

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 14 Jun 2007 14:13:17 -0400

We're not short of RR codes so there is no reason to recycle them for
the foreseeable future. It seems to me that what is called for is a
simple RFC. For each of the handful of RR codes in question, the RFC
should presumably say that the code is reserved, say whether or not the
use is deprecated, say a few words about this history of the RR, and
possibly point to or even incorporate documentation for the RR.

As the proud author of the Kitchen SINK RR, I'd be happy to help.

Donald

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Danny Mayer
Sent: Thursday, June 14, 2007 1:07 PM
To: [email-masked]
Cc: Edward Lewis; [email-masked]
Subject: Re: IANA type code registration clean up

Danny

---

From: Edward Lewis <[email-masked]>
Date: Thu, 14 Jun 2007 14:32:34 -0400

At 17:27 +0000 6/14/07, [email-masked] wrote:

>	WG meeting minutes.  WKS was deemed an atack vector.
>	Prudent operators stopped using it.

RFC 5013 - Bill's Notes from DNSIND.

>	nit-picker.

If I had known it was Bill's.

>	wait... i have copies in my archives.

http://bill's brain/notes...

Seriously, I have located copies on the web, but they are not in 
archival documents.  I think all would be happy asking IANA to just 
list them as IANA reserved.

>	whiner.   do ALL email addresses have to continue to work
>	forever?

Try sending comments to the editor of RFC 3090 and see if he cares.

>	perhaps it should

I consider that a minor registration clean up.

>	again ...  check WG meeting minutes.

As Donald replies later...just needs doin', nothing big.

>	One really needs to get DocMoc to write it down... along
>	with Keith Sklower or any of the other original Berkeley team
>	who might remember.

I don't want to make too much out of this.  Perhaps the registration 
is okay as it is.  The registry doesn't need the rationale, just 
maintains the links from object (type code name and number) to 
subject (document).

>	actually, a valid response to such a request is "I can't,
>	the documentation has been erased"...  Witness the problems
>	building a SaturnV booster.  The blueprints are listed
>	as being @ Houston and Goddard... but there are no prints left.

Even that would be good - recall I am concerned that a fresh 
implementer couldn't determine how to implement a "required" type. 
If the type is forgotten, just say that.

BTW, the Saturn V plans are probably in a store room in GSFC building 
5.  If you  ever tried to trace the 10Base2 cable in the basement 
you'd probably find the backups of the Iran-Contra emails too.

I'm serious.  No smiley here.

Sarcasm doesn't scale.

---

From: Danny Mayer <[email-masked]>
Date: Thu, 14 Jun 2007 14:36:14 -0400

David Conrad wrote:
>> about their impending termination.
> 
> How would they know?
> 

Actually it doesn't make any difference. You are still compliant with
DNS if you implement something that's been deprecated, just don't expect
everyone else to have implemented it. And since Unknown type handling is
now part of the mix it doesn't matter to anyone except the servers that
need to use it.

Danny

---

From: Edward Lewis <[email-masked]>
Date: Thu, 14 Jun 2007 14:38:19 -0400

At 14:23 -0400 6/14/07, Danny Mayer wrote:

>Well this brings up the problem that there is no one place that one can
>go to to get the official complete list of IETF RFCs and other documents
>and whatnot that one would need to implement and comply with in order to
>build your new edifice that one could then say is completely DNS
>compliant (assuming we know what that really means).

100% right, mostly.

There isn't any universal single list of RFCs that define DNS.  But 
in the scope of contacted work, there is a single list that matters. 
;)

RFCs don't matter in the real world, RFPs and contracts do.  The 
latter documents will cherry pick the RFCs they want to include in 
the delivery.  This is why I want to make sure we clean up the frayed 
edges of the RR type registry.  (Spurred mostly be the ATMA document 
too.)

Sarcasm doesn't scale.

---

From: Rob Austein <[email-masked]>
Date: Thu, 14 Jun 2007 14:41:40 -0400

> back that up.  (I suppose other types are as dead, but no 

Not sure about "dead", but try RFC 1123 2.2, 5.2.12, and 6.1.3.6.

---

From: Danny Mayer <[email-masked]>
Date: Thu, 14 Jun 2007 14:23:32 -0400

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Edward Lewis wrote:
> keeping things in order, I agree that would be too much work.  The jist
> of mu concern is ... if I were to walk off the street and try to write
> up a DNS protocol element (server, stub, etc.) can I find all of the
> documentation to create a compliant hunk of code.
> 

Danny

---

From: Rob Austein <[email-masked]>
Date: Thu, 14 Jun 2007 16:05:08 -0400

At Thu, 14 Jun 2007 15:53:41 -0400, Danny Mayer wrote:
> 
> I have this vague recollection that MIT wanted it for HESIOD or
> something like that. The trouble is that I don't know where I get my
> vague feelings from! :( Some mailing list or other, probably this one.

Symbolics (an MIT spin-off) used WKS heavily in their attempt to fit
DNS into the Lisp Machine Namespace system and the associated generic
heterogeneous network access code, because it was, in theory, a good
match for the existing semantics that their code assumed.  In
practice, WKS was not deployed widely enough for this to work right.

I don't think Project Athena ever cared much about WKS, but I could be
wrong, they were Unix weenies on the wrong side of the tracks and
those two cultures didn't talk much in those days.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 14 Jun 2007 22:32:12 +0200

Another way is to ask people what they do when implementing nam server
software from scratch. I seem to remember that when we did nsd we only
implemented the documented RR types. We also left out the deprecated
versions. It is somewhere in the requirements documents (see the source
Luke). I wonder what PowerDNS sid when they started.

	jaap

---

From: Edward Lewis <[email-masked]>
Date: Thu, 14 Jun 2007 16:45:08 -0400

At 20:33 +0000 6/14/07, [email-masked] wrote:

>	perhaps...  but I am aware that the folks who did the movie
>	"Apollo 13" did an exaustive search (and paid big bucks for
>	dedicated people to do it) and were unable to locate them...
>	NASA finally declared them "lost".
>
>	it sounds kind of like you are working toward a crisp suite of
>	"required" options that MUST be supported.... others mentioned
>	DNS conformance as in DNS conformance suite...  I think that
>	IETF protocols, in general, suffer/excel BECAUSE there is little
>	in the way of conformance mandates.   The TCP folks are already
>	in that rathole and there is no indication they will surface anytime
>	soon.   Ditto SMTP, Telnet, and SNMP...

My 'serious' was more about where copies of the Sat V plans and the 
Iran-Contra tapes are.

As far as anything on '"required" options that MUST' - ha!  Having 
once been a rat myself, rat holes are vastly overrated.

>	A fresh implementor should document WHICH types are implemented and
>	based on what specification.  Then folks won't have to guess and
>	-we- don't have to play implementor police.

I'm talking about the other way around.  The Internet is no longer 
driven by fresh faced implementers pushing the envelope, exceeding 
the minimum level of necessary functionality.  That's so 20th 
century.  Now it's driven by contract negotiators who want to pay as 
little as possible for anything that winds up as a cost in the 
ledger.  And telecommunications is a cost, just like security.

I don't care what RR types an implementer does, I care about what RR 
types a regulator demands.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 14 Jun 2007 16:49:30 -0400

>Luke). I wonder what PowerDNS sid when they started.

One reason I roused this topic up was reminiscing on the days when I 
still had talent and knew all the options of an ld command.  I once 
did write up DNS stuff from scratch.  I went to the IANA page and 
coded everything that wasn't marked as .  It wasn't until I met 
ne'er-do-wells at an IETF that I learned all the time spent on things 
like WKS, EID, NSAP, etc., were all wasted effort.  That's why I know 
so much about the ATMA record and document.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

---

From: Danny Mayer <[email-masked]>
Date: Thu, 14 Jun 2007 21:58:20 -0400

[email-masked] wrote:
> 	that it was superfulous (nearly everything NSAP-PTR did can be done w/ PTR)
> 	and w/ the IANA's permission, we "declared" it deprecated... which

So you have a pointer to where it's "declared" deprecated?

> 	easy.  push all the air/gas out, submerge it and release.
> 	when the corpse expands, it sucks up (drinks) the water.
> 

Gives a whole new meaning to bloatware...

> --bill
>> Danny
> 
> ** almost everything.  NSAP-PTR had the latent capability to support
> variable length addresses ...  which evolved into A6/BITSTRING... and
> we know what happend there...  as long as we have fixed address lengths,
> PTR does the job just fine.
> 
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 Jun 2007 15:50:27 +1000

> back that up.  (I suppose other types are as dead, but no 

	RFC 1123 deprecates its use w/o deprecating it.

      2.2  Using Domain Name Service

      An application SHOULD NOT rely on the ability to locate a WKS
      record containing an accurate listing of all services at a
      particular host address, since the WKS RR type is not often used
      by Internet sites.  To confirm that a service is present, simply
      attempt to use it.

	and

      5.2.12  WKS Use in MX Processing: RFC-974, p. 5

         RFC-974 [SMTP:3] recommended that the domain system be queried
         for WKS ("Well-Known Service") records, to verify that each
         proposed mail target does support SMTP.  Later experience has
         shown that WKS is not widely supported, so the WKS step in MX
         processing SHOULD NOT be used.

      The following are notes on RFC-822, organized by section of that
      document.

> the TXT and the RP types.

	No.  32 (NIMLOC) and 33 (SRV) are the conflicting types.

From RFC 1002
   Symbol      Value   Description:

   NB         0x0020   NetBIOS general Name Service Resource Record
   NBSTAT     0x0021   NetBIOS NODE STATUS Resource Record (See NODE
                       STATUS REQUEST)

---

From: Edward Lewis <[email-masked]>
Date: Fri, 15 Jun 2007 08:46:06 -0400

>	No.  32 (NIMLOC) and 33 (SRV) are the conflicting types.

Showing age - I was thinking octal again.

Sarcasm doesn't scale.

---

From: Danny Mayer <[email-masked]>
Date: Fri, 15 Jun 2007 13:16:32 -0400

> Showing age - I was thinking octal again.

You must be *really* showing your age: you mean hex!

Danny

---

From: Danny Mayer <[email-masked]>
Date: Thu, 14 Jun 2007 15:53:41 -0400

Danny

---

From: Doug Barton <[email-masked]>
Date: Sun, 17 Jun 2007 13:59:52 -0700

> looking at the BIND source code.

Ed,

I applaud your efforts in this area (both now, and in the past). It's
much needed, and very unappreciated work.

Forgive me if this is premature, but I'd like to move toward a more
concrete recommendation for IANA, whether it would require a draft or
not. For example, for the WKS record:

TYPE            value and meaning                         Reference
----------      --------------------------------------    ---------
DEPRECATED	11 Reserved, formerly WKS		  [IANA] [1]

And then add a note that says something to the effect of, [1] 'All RRs
with type "DEPRECATED" are subject to reallocation if all other code
points are exhausted.'

Donald is right in saying that we're not in any danger of running out,
but I think if we're going to clean up this space, let's make sure we
make our intentions clear to the future generations.

If the consensus is that we will need a draft to update this stuff,
I'd be glad to assist.

Doug

-- 

	If you're never wrong, you're not trying hard enough

---

From: Doug Barton <[email-masked]>
Date: Sun, 17 Jun 2007 13:15:06 -0700

> 	RFC 1123 deprecates its use w/o deprecating it.

And in 1912:

2.6.1 WKS

   WKS records are deprecated in [RFC 1123].  They serve no known
   useful function, except internally among LISP machines.  Don't
   use them.

hth,

Doug

--

---

From: Mark Andrews <[email-masked]>
Date: Mon, 18 Jun 2007 09:34:06 +1000

>    useful function, except internally among LISP machines.  Don't

	We still need to formally deprecate the record.  This allows
	nameserver vendors to remove support.

	In general, to deprecate a type, we need several milestones.

	* notice of intention to deprecate
	* notice of when all applications should cease to request type
	* notice of when all nameservers should cease to load type
	* notice of when type is free for re-use.

	I would also suggest that there be 10 or so years between
	each step.

	For WKS we are only at step 1 or 2 depending on how you read
	RFC 1123.

	For MD and MF we are at step 3.

---

From: Geoff Huston <[email-masked]>
Date: Mon, 18 Jun 2007 14:09:09 +1000

>>
>> This example you have here is a classic example of a certain level of
>> confusion that has been a consistent, but annoying, property of many of
>> the IANA registries for many years, and your suggestion continues to
>> promulgate this.
>>
>> There are three attributes of a registry that are of interest to clients
>> of a registry
>>
>>   1 - its current contents, and
>>
>>   2 - the 'audit' trail of chnages over time that have lead to the the
>> current status.
>>
>>   3 - the management policies of the registry
>>
>> I suggest that it is a lot easier for clients of a registry when these
>> three views of the registry are clearly delineated.
> 
> Geoff,
> 
> That's a very interesting perspective, do you think that you could
> expand a little on why you think this is true?

We digress from the namedroppers charter, so I'll answer just once, and 
then take the conversation away from this list, as for many this is 
getting well off topic.

For many clients of a registry, the substantive question is "what 
codepoints are currently valid?" How the registry arrived at this, and 
why are not exactly relevant to such a query. So the registry should be 
capable of presenting a clear, consistent and unambiguous display of the 
the current status of the registry. And here of course I use the term 
"client" in the broadest possible sense, in that there are many 
automated clients that sweep such registries.

For some, the question of what changes have been made and when are of 
interest.

And of course for others the basic policy framework that manages the 
registry is of interest.

The current status of the IANA registries are, objectively speaking less 
than stellar. While ascii is a lowest common demonimator encoding, and 
alignment into columns is about as basic as you can get, the results in 
the registries reflect a varied history of human handling of the data - 
registries contain inaccuracies to be sure, but also inconsistencies and 
ambiguities. Perhaps to a human clent some of these may be readily 
resolved, but to an automated parser this stuff gets downright challenging.

So in "cleaning up" a registry I am asking that some thought goes into 
what sort of clients out there use the registry and what form of 
information structuring would make the lives of the registry manager and 
of the clients of the registry just a little easier? Who could a 
registry be capable of presenting a clear and coherent view of what "is" 
and at the same time also be capable of presenting the set of registry 
actions that culminates in today's view. Maybe instead of the "one  file 
of ascii columniated (mis)fits all" we move to something that pulls 
apart presentation from semantic content in these registries?

But enough from me on this topic - its already off in the weeds! :-)

   Geoff

---

From: Geoff Huston <[email-masked]>
Date: Mon, 18 Jun 2007 10:05:28 +1000

> TYPE            value and meaning                         Reference

Doug,

If a value is currently "reserved" then its "reserved". nothing more. 
That's view 1.

If a registry code point was formerly assigned to WKS on some date and 
on the basis of some advice or reference, and then deprecated and the 
value returned to the reserved pool on some later date and upon some 
subsequent advice or reference then thats what you get in view 2.

And the policy of managing the registration of these code points is best 
done as a single statement that applies to the entire registry. Thats 
the 3rd view of a registry.

But mixing the three concepts by using registry entries such as 
"Reserved, formerly WKS" and adding notes to say that this code point 
will be reused upon the third transit of Venus during a lunar equinox ( 
;-)) really only adds to the potential confusion for registry clients, 
rather than adding to the clarity and consistency of interpretation of 
the registry and its contents.

    Geoff

---

From: David Conrad <[email-masked]>
Date: Mon, 18 Jun 2007 11:10:12 -0700

> The current status of the IANA registries are, objectively speaking  
> less than stellar.

Hey!  I am shocked, *shocked* to hear someone question the lack of  
perfection in IANA registries!  :-)

For what it is worth, IANA has been working on some prototype XML- 
ized versions of some of the registries to make them more easily  
parsed.  We should be providing those prototypes for comment in the  
near future.

Rgds,
-drc

---

From: Peter Koch <[email-masked]>
Date: Mon, 18 Jun 2007 20:08:08 +0200

[...]
> 	For WKS we are only at step 1 or 2 depending on how you read

that I doubt. RFC 1123 only deprecates use of WKS in the MX based mail routing
given in RFC 974.  It doesn't say anything about the applicability for
other uses and does not make a recommendation w.r.t. implementation.
WKS has been operationally discouraged, as probably has HINFO, but that's
a different issue.

> 	For MD and MF we are at step 3.

Well, yes, but what does this mean protocol wise?  Should servers just
ignore MD and MF RRSets (acting as placeholders for to-be-deprecated types)?
MUST they now respond NOTIMP to QTYPE=MD?  This probably collides with the
spirit of RFC 3597.

In my reading NSAP-PTR was dropped by RFC 1637 obsoleting RFC 1348
without saying a word about NSAP-PTR.

So, it might be that Ed's demands can't be satisfied by the current
content of the "dns-parameters" registry.  Good old RFC 2026 knows
"requirements levels" at least for standards track documents.
Something along that line could help to identify the right set of
record types.  But then, this isn't enough: what about the non-RRtype
additions to STD13?  Do we need EDNS0 today? Or RFC 3597 compliance?
Negative caching? All PS RFCs?

I've always been suspicious of RFPs, contracts or tenders that claim
"DNS will be implemented according to RFC 1034 and RFC 1035", usually
accompanied by some more or less arbitrary and most often incomplete
list of the "relevant" RFCs.  If this is a task for the WG, so be it,
but that's more than "cleaning up" the IANA registry.

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Mon, 18 Jun 2007 14:39:32 -0400

>but that's more than "cleaning up" the IANA registry.

What I find even harder to deal with are RFPs in which the respondent 
is asked to supply information about the DNS standards they support, 
etc.  (I'm paraphrasing.)  The open ended question is a pain because 
there isn't an really pat answer.

As far as "first steps" I have sent a request into IANA to see if 
some changes can be made under the banner of "editorial fixes to the 
web page."  Sooner or later a draft will emerge for comments, the 
goal of which is to ask IANA to update the registrations "in place."

We have other things looking at broader changes to the IANA registry 
for DNS (2929bis), and I believe later we can try to the question of 
whether we ought to really deprecate something (as opposed to let it 
lie in it's lamentable but implementable state).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Jun 2007 08:53:30 +1000

> WKS has been operationally discouraged, as probably has HINFO, but that's

	No.  There is a general deprecation in Sections 2.2 "Using
	Domain Name Service".

> but that's more than "cleaning up" the IANA registry.

	Agreed we need some profile documents which describe which
	parts of which RFCs need to be implemented in a modern
	nameserver and client.

---

From: Doug Barton <[email-masked]>
Date: Mon, 18 Jun 2007 16:44:16 -0700

Geoff,

Thanks for confirming that it was this particular windmill you were
tilting at. While I look forward to seeing David's XML prototype,
given the _current_ state of the registry, my suggestion stands for
the group to evaluate.

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 17 Jun 2007 20:36:22 -0700

Geoff,

> If a value is currently "reserved" then its "reserved". nothing more.

For the particular snapshot in time that a person might view the web
page that is the registry, yes, I agree with you.

> subsequent advice or reference then thats what you get in view 2.

Well, you've sort of said, "The sky is blue" here, which is of course
correct, but not very interesting. :) At some point in the future when
we have a reliable method of tracking "what used to be" then I think
what you're trying to say will be the right way to do things; which is
a clear separation between the current contents of the registry at
this moment in time, and what used to be the content of the registry
at some point in the past.

Unfortunately, right now we don't have that. (Yes, I realize that
there are ideas about how to get it, some of them are even my ideas,
but we don't have it right now.) Therefore, I think it's perfectly
reasonable to mention that in the "recent" past (even if we accept
Mark's definition of 10 years as "recent"), there was a thing that
used this code point. That's beneficial not only for the person who's
spelunking in existing code so that they can know what the heck that
weird QTYPE 11 is that they've never heard of or seen on the wire,
it's also useful for the developer of some future project that thinks
11 is the PERFECT number for his new QTYPE, and doesn't see any reason
not to use it from the current content of the registry.

This BTW is not a theoretical issue, it's something that has bitten me
before, and I know I'm not alone.

At some future time when it's trivial for an implementor to discover
what used to be, then by all means let's have those clear bright lines
that you're talking about. But until then, my vote is that we err on
the side of utility rather than theoretical perfection.

> the 3rd view of a registry.

I think my suggested text pretty clearly does that. "All such things
that are X are subject to the following conditions." It's pretty
pointless to suggest that a policy regarding REuse of a code point
apply to code points that have never been allocated, or that are
currently allocated.

> the registry and its contents.

I certainly hear the passion in your voice, but I am sorry to say I
don't agree with you. If I saw a statement that said something was
subject to reuse at some point in the future, I am pretty sure I know
how I'd handle that information in relation to any application I might
want to develop in that space. However, like I said at the outset, I'm
willing to be convinced otherwise.

Doug

PS, it should go without saying that I am not speaking here for any
current or former employers, just stating my personal opinion.

--

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Jun 2007 11:57:39 +1000

Just for a data point.  BIND 9 refuses to load MD and MF when the
	server is a master.  We also refuse to add MD and MF records via 
	UPDATE.  We will however serve them from a slave server and when
	acting as a caching server.

	At some point we will remove this code and the code display and
	parse MD and MF records.  Having a date when this should be done
	would be useful.

	Mark

                /*
                 * RFC1123: MD and MF are not allowed to be loaded from
                 * master files.
                 */
                if ((lctx->options & DNS_MASTER_ZONE) != 0 &&
                    (lctx->options & DNS_MASTER_SLAVE) == 0 &&
                    (type == dns_rdatatype_md || type == dns_rdatatype_mf)) {
                        char typename[DNS_RDATATYPE_FORMATSIZE];

                        result = DNS_R_OBSOLETE;

                        dns_rdatatype_format(type, typename, sizeof(typename));
                        (*callbacks->error)(callbacks,
                                            "%s:%lu: %s '%s': %s",
                                            source, line,
                                            "type", typename,
                                            dns_result_totext(result));
                        if (MANYERRS(lctx, result)) {
                                SETRESULT(lctx, result);
                        } else
                                goto insist_and_cleanup;
                }

---

From: Edward Lewis <[email-masked]>
Date: Mon, 18 Jun 2007 23:16:54 -0400

Just curious, as a measure of how the specs drive use and vice versa, 
has anyone/how many have complained that these types are not 
currently supported in your code?  (Asking about the "at some point 
we will" comment.)

At 11:57 +1000 6/19/07, Mark Andrews wrote:

...

Sarcasm doesn't scale.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Jun 2007 13:39:33 +1000

> currently supported in your code?  (Asking about the "at some point 

	We had one because we wern't rejecting them.  None as far
	as I can see for rejecting them.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Jun 2007 14:42:05 +1000

> well, BIND did deprecate A6 support - even though the spec was moved
> to experimental and not depecated...  effectively killing it.
> 
> --bill

	The type is still there.  You can still load it.  Named
	just doesn't use it for looking up nameservers addresses.
	i.e. we are not part of the experiment other than allowing
	the record to be loaded.
 
	Mark

---

From: Geoff Huston <[email-masked]>
Date: Tue, 19 Jun 2007 07:18:47 +1000

> perfection in IANA registries!  :-)

Whoops - I'm now a heretic! Quick, better call up the mob to fetch a 
stake, some rope and some fire!

> 
> For what it is worth, IANA has been working on some prototype XML-ized 
> versions of some of the registries to make them more easily parsed.  We 
> should be providing those prototypes for comment in the near future.

xactly!That way presentation and semantic content can be delineated and 
automated paring of registries can be undertaken with greater levels of 
confidence than we have today!

thanks.

(OK - Now will someone untie me from this stake?)

   Geoff

---

From: [email-masked]
Date: Tue, 19 Jun 2007 04:16:36 +0000

--bill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 25 Jun 2007 09:33:19 -0700

I suggest that instead of saying WKS is depricated it states that WKS is depricated in favor of something else.

In the case of WKS the original service point is effectively replaced by the SRV record.

On the reclamation issue, I really think we should design the DNS so that we never come close to exhaustion. We should only assign RRs to support new infrastructure capabilities, not individual protocols.  

So a new RR for describing protocol policy would be acceptable. A new RR for describing policy for protocol foo would not be.

The reason to do reclamation is to look to see if there are features that we should explicitly drop from the DNS protocol and to advise that servers NOT present as preferred options. WKS is a good candidate there as the specification is so limited in scope.

> [mailto:[email-masked]] On Behalf Of Doug Barton
> Sent: Sunday, June 17, 2007 5:00 PM
> To: Edward Lewis
> Cc: [email-masked]
> I applaud your efforts in this area (both now, and in the 
> past). It's much needed, and very unappreciated work.
> 
> Forgive me if this is premature, but I'd like to move toward 
> a more concrete recommendation for IANA, whether it would 
> require a draft or not. For example, for the WKS record:
> 
> And then add a note that says something to the effect of, [1] 
> 'All RRs with type "DEPRECATED" are subject to reallocation 
> if all other code points are exhausted.'
> 
> Donald is right in saying that we're not in any danger of 
> running out, but I think if we're going to clean up this 
> space, let's make sure we make our intentions clear to the 
> future generations.
> 
> If the consensus is that we will need a draft to update this 
> stuff, I'd be glad to assist.
> 
> Doug
> 
> -- 
> 
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' 
> in a single line as the message text body.