Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Tue, 28 Jun 2005 20:58:16 -0400

See below at ###

-----Original Message-----
From: Edward Lewis [mailto:[email-masked]] 
Sent: Monday, June 27, 2005 1:36 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]; 'Olaf M. Kolkman'
Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt

comments interleaved...

At 11:21 -0400 6/27/05, Eastlake III Donald-LDE008 wrote:
>Hi,
>
>See below at @@@
>
>-----Original Message-----
>From: Olaf M. Kolkman [mailto:[email-masked]]
>Sent: Monday, June 27, 2005 4:00 AM
>To: Eastlake III Donald-LDE008
>Cc: [email-masked]
>Subject: Re: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt
>
>On Wed, 22 Jun 2005 14:25:01 -0400
>Eastlake III Donald-LDE008 <[email-masked]> wrote:
>
>>  Well, I'm open to suggestions as to what forumulation we want for 
>>these allocation decisions.
>
>Thanks, Donald!
>
>@@@ You're welcome.
>
>>  I could replace all occurances of "IETF Standards Action modified 
>>by [RFC 4020]" in the new draft with "the DNS Special Allocation 
>>policy" and then add a section defining that policy as
>>
>>  "1. IETF Standards Action or
>>   2. Approval as an an Experimental Protocol or
>>   3. As provided in RFC 4020, or its successor, for Early 
>>Allocation except that the crieria in Section 2 of RFC 4020 are 
>>replaced by the following:
>>      3.a: The format, semantics, processing, and other rules related to
>>           handling the protocol entities defined by the code points
>>           (henceforth called "specifications") must be adequately described
>>           in an Internet draft that is intended to become Standards Track or
>>           Expeirmental.
>>      3.b: There is sufficient interest in early (pre-RFC) implementation and
>>           deployment in the community as determined by working group
>>           consensus."
>
>I like this line of thought.
>
>One detail in 3.b above; which working group? What if
>the I-D is a personnal submission that falls between working group
>cracks.
>
>@@@ There are always the Specification Required and the Private Use spaces
>@@@ of parameter values. Given that those avenues are also available for RR
>@@@ Types, I'm not all that worried about personal submissions. I guess it
>@@@ wouldn't hurt to say "... as determined by working group consensus (or
>@@@ the IESG in the case of individual submissions)."

Given the direction of the IESG workload, I question laying more on 
that group.  Also, this doesn't really address the "which WG" that 
gives consensus.

### Well, the current criteria for these parameters in RFC 2929 is "IETF Consensus". RFC 2434 defines that as "new assignments are made via RFCs approved by the IESG". So any change is likely to *reduce* the theoretic load on the IESG. As to which wokring group the intent is the working group whose protocol needs the value.

It's possible that DNSEXT WG will someday close (looking at the 6 
work items listed on the charter - they are [very arguably] nearly 
done or languishing).  If that happens we wind up with a situation 
similar to EPP - a WG-less protocol with about 4 or so extensions 
passed since the end of its group.  (EPP has an IANA registry.  No 
"standards action" or "specification required" is needed to update it 
- although the nature of the registry means that its an "unfair" 
comparison.)

### Indeed, it is specifically prohibited to have anything in a standard or any IANA allocation process depend on the perpetual existence of any working group. If you are worried about some random working group approving some RR Type without it going through DNSEXT you are asking for something not possible within IETF procedure. It would be reasonable to add a provision that the early allocation request also be approved by the WG's AD.

Perhaps I'm barking up the wrong tree.  Getting a reserved spot in an 
IANA administered registry ought to take a lot of work.  You can 

### That depends on supply and demand. Some registries are essentially infinte and first come first served works fine as the allocation rule. The great benefit of having Jon Postel be the judge of all these things was that he generally had reasonable judgement and could apply varying back pressure to assignment requests depending on the code point space left and how rapidly requests were arriving. We now have to guess and establish rules. But what people were complaining about was that it was too hard to get an RR Type. So whatever we adopt had better be easier than "Specification Required" has worked out to be in practice.

accomplish that while still address the needs of "early allocations" 
via another means.  For example, we could suggest that "early" 
implementers choose a number (as appropriate) consistent with the 
number range they want to fit into - and use that in their documents. 
If there is no conflict, they get the number once they pass the high 
hurdles.  If there is, well, they get another number and will have to 
re-code anyway.

### But the problem I thought we were trying to address is that after people implement with a number they choose, their code escapes and/or they are too lazy to ever doing anything else about allocation, so you end up with deployed code with random code and no central record and, sooner-or-later, conflicts.

If the number selection comes from the WG, then it's possible two 
post-DNSEXT WGs could assume the same number.  If IANA chooses, then 
individual submitters will be gated on IESG action.

>I also think that you should add that the RR does not required special
>processing for DNS servers and clients, name compression, is
>case-insensitive, &c, &c.
>
>@@@ I suppose some narrow additional restrictions could be added but I'm
>@@@ worried about making it too complex and restrictive. The idea is to be
>@@@ lax :-)

Lax for getting implementers what they need, not so lax (maybe) in 
what gets into the registry.  Certainly not vice versa. ;)

### Perhaps not laxer for permanent registry entries but the Early Allocation idea is basicaly a temporary registry entry. Quoting from RFC 4020:
   5) IANA makes an allocation from the appropriate registry, marking it
      as "temporary", valid for a period of one year from the date of
      allocation.  The date of allocation should also be recorded in the
      registry and made visible to the public.

>In another message you wrote:
>
>>  I'll revise the 2929bis draft to liberalize most assignments along
>>  the lines of my message below and to add a policy for the AFSDB RR
>>  subtype field.
>
>Donald, will you be in Paris? I'd like to have this on the DNSEXT's
>meeting's agenda.
>
>@@@ Yes, I will be in Paris and would be happy to have this on the DNSEXT
>@@@ agenda but I may have to leave around the middle of the day Thursday so
>@@@ it would work best if this was scheduled to be before that.
>
>@@@ I have gone ahead and submitted a revision -01 of the 2929bis draft but
>@@@ would be happy to further modify it.
>
>--Olaf

### Thanks,
### Donald

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

If you knew what I was thinking, you'd understand what I was saying.

--
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: Edward Lewis <[email-masked]>
Date: Wed, 29 Jun 2005 10:30:34 -0400

This message demarcation thing is a pain ;) so I've taken the liberty 
of removing the old context...

At 20:58 -0400 6/28/05, Eastlake III Donald-LDE008 wrote:

>Well, the current criteria for these parameters in RFC 2929 is "IETF
>Consensus". RFC 2434 defines that as "new assignments are made via RFCs
>approved by the IESG". So any change is likely to *reduce* the theoretic
>load on the IESG. As to which working group the intent is the working group
>whose protocol needs the value.

Either way, I think we ought to be shielding the IESG from having to 
make operational (in the sense of moving the bureaucracy along) 
decisions.  OTOH, if there is no DNS WG, I am not sure the other WGs 
are really prepared to make DNS related decisions - and in that case 
it falls to the shepherding AD anyway.

>Indeed, it is specifically prohibited to have anything in a standard or any
>IANA allocation process depend on the perpetual existence of any working
>group. If you are worried about some random working group approving some RR
>Type without it going through DNSEXT you are asking for something not possible
>within IETF procedure. It would be reasonable to add a provision that the
>early allocation request also be approved by the WG's AD.

The way I see it, there are two options in the event of there being 
no sitting DNS WG.

1) With or without DNS WG, IANA is given clear instructions and 
guidance for situations that have not been anticipated in the 
allocation of parameters.  This is moving the bureaucracy out of the 
engineering department and into the operational registry function. 
I'm sure we can quantify some criteria for "innocuous" RR definitions 
that we will be confident can be easily, transparently, and clearly 
followed by someone without having to get involved in a debate.

2) In the absence of a DNS WG, recognize that the WG's AD, or maybe 
the document's shepherding AD, is the ombudsman that will make sure 
suitable DNS expertise is called in.  The big trouble I have with 
this is that the calling of an expert is rarely an open process and 
doesn't tend to scale very well in engineering situations.

>That depends on supply and demand. Some registries are essentially infinte and
>first come first served works fine as the allocation rule. The great benefit
>of having Jon Postel be the judge of all these things was that he generally
>had reasonable judgement and could apply varying back pressure to assignment
>requests depending on the code point space left and how rapidly requests were
>arriving. We now have to guess and establish rules. But what people were
>complaining about was that it was too hard to get an RR Type. So whatever we
>adopt had better be easier than "Specification Required" has worked out to be
>in practice.

I didn't know Jon Postel personally, but I know he made a strong 
impression on many folks still active on this list.  From anecdotal 
evidence, I'll proffer that he was a unique person in a unique era. 
Would someone of his talents, entering the Internet today, be 
available for the same post?  Back in the day, the IANA function was 
a place to be a pioneer.  Nowadays, the chains (and budget) on it 
make it a place where pioneering is not to be encouraged.

I'll reiterate this - I am not commenting on the way IANA's staff is 
operating.  I am commenting on the position the community places the 
"critical infrastructure staffs" in - that of a place where we want 
them to do "the job" in a fair manner above all else.  This tends to 
discourage staff members from sticking their necks out at a 
conformant by unwise request.

Relying on a personality (as opposed to a person) to do a job does 
not scale - not in volume nor in time.

>But the problem I thought we were trying to address is that after people
>implement with a number they choose, their code escapes and/or they are too
>lazy to ever doing anything else about allocation, so you end up with deployed
>code with random code and no central record and, sooner-or-later, conflicts.

I don't think the dynamic works that way, and, above that, I don't 
think that is the problem we face today.

I think the problem is that implementers are rightfully choosing the 
path of least resistance to adding data to the DNS.  And that path 
goes right through the TXT RR and name prefixes because doing the 
"right thing" is a pain becuase of the bureaucratic rules *we* have 
laid down.

I do think that implementers, seeing their code fly off the FTP 
servers, do want to make an official record of it.  That's the early 
RFCs.  And I think of the time the original coder of SSH came to the 
SSH WG meeting and pleaded for them to change the name so he could 
get a trademark on SSH.  Successful efforts to get capped off.

OTOH, it is the unsuccessful (or limited success) cases that are a 
pain.  For this reason, all code ought to follow the "liberal in 
accept, conservative on transmit" bon mot.

>Perhaps not laxer for permanent registry entries but the Early Allocation
>idea is basicaly a temporary registry entry. Quoting from RFC 4020:

I missed the one year term.  But, requiring a high bar (like IESG 
consent) might work out to getting a one year lease two years after 
the code is first developed.

I would suggest that getting a one-year lease be done with a simple 
request to IANA (subject to denial of registry service and subscriber 
fraud checks), that renewal of a lease take something more - maybe 
even an IESG ok.  (But I'd prefer to give two year leases as some 
engineering cycles will take longer.  That's conjecture on my part.)