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

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Mon, 4 Jul 2005 12:46:16 -0400

See below at @@@

-----Original Message-----
From: Edward Lewis [mailto:[email-masked]] 
Sent: Wednesday, June 29, 2005 10:31 AM
To: Eastlake III Donald-LDE008
Cc: [email-masked]; [email-masked]
Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt

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.

@@@ The IESG is where the bulk of the athority and responsibility is in the IETF. There are limits as to how far we can "shield" them and, I'm sure, limits to the extent to which they want to be cut out of things. If we make Early Allocation of these DNS code points for WGs depending on WG consensus plus AD approval, I suppose we could, for individual requests, just require approval of two ADs...

>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.

@@@ I believe the best couse is to never assume the existence of DNSSEC or any similar WG.  You can assume a mailing list. So it would be reasonable to add a requirement that notice be posted to namedroppers or its successor and no action be taken until people have had two weeks to comment.

@@@ I'm not too enamored for technical criteria for "innocuous" RR definitions. I'd generally oppose requiring IANA to make technical judgements.

>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.

@@@ Well, my understanding is that, to a great extent, the trend to more precise mechanical procedures for IANA was instigated at IANA's request and to minimize legal liability, not imposed at the instigation of the community. But what matters is the current situation, not the history.

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

@@@ Sure it does. Everything has either one person in change, like the Administrator of the (US) Federal Aviation Agendy, or a committee, like the (US) Federal Communications Commission. If they have too much to do, they rrecruit helpers or delegate to staff.

>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.

@@@ Well, there are a varity of problems. The problem you list is why we want allocation to be easier. The problem I was listing is why I think we want a coordination mechanism like fairly easy early allocation.

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.

@@@ I'm not entirely sure what you are saying here. If people can get an RFC into the RFC Editor's queue, they should be able to get a permanent typde code in the Specification Required section.

>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.

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.)

@@@ "denial of registry service" on what basis?

@@@ WG + AD approval or 2 * AD approval for individual doesn't seem that hard to me. Annual renewals don't seem like that much of a burden and would serve to remind people they are on a temporary basis and will need to firm things up. Making renewal harder than initial allocation could encourage people who think they can't yet make the higher hurdle yet but still want to persue their development to just get a new initial allocation for a new code rather than renew.

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

@@@ Thanks,
@@@ Donald

--
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: Tue, 5 Jul 2005 15:29:05 -0400

At 12:46 -0400 7/4/05, Eastlake III Donald-LDE008 wrote @@@:

>@@@ I'm not too enamored for technical criteria for "innocuous" RR
>@@@ definitions. I'd generally oppose requiring IANA to make technical
>@@@ judgements.

The point of documenting criteria is to avoid the need for judgements.

>@@@ Sure it does. Everything has either one person in change, like the
>@@@ Administrator of the (US) Federal Aviation Agendy, or a committee, like
>@@@ the (US) Federal Communications Commission. If they have too much to do,
>@@@ they rrecruit helpers or delegate to staff.

The difference is between a "personality" and a "person in charge." 
To me, "personality" generally means that the person involved is 
inventive, a "person in charge" is a person making sure steps are 
checked off - whether that's a literal bureaucratic checklist or a 
sketchy details list.

For scaling, you want a "person in charge" (or "person responsible") 
and not a "personality."

(There's an expression "cult of personality" but there's no "cut of 
'person in charge.'")

>@@@ I'm not entirely sure what you are saying here. If people can get an RFC
>@@@ into the RFC Editor's queue, they should be able to get a permanent type
>@@@ code in the Specification Required section.

That's putting the cart in front of the horse though.

>@@@ "denial of registry service" on what basis?

Flooding the registry with requests to deplete the parameter space.

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