[e2md] the RFC5935 process

[Jim Reid <[e-mail]>]

On 17 May 2010, at 16:12, Dean Willis wrote:

> I had a side discussion with Jim about his experience in getting new
> RR-types approved, and to summarize, my impression was that it was  
> kind
> of random. Some RR-types were unexpectedly easy, others unexpectedly
> difficult.

The problems were with what I consider were some interfering busy- 
bodies who seemed to meddle for the sake of it. In fairness, this was  
the first time the 5395 process had been used. So some teething  
problems from well-intentioned but probably misinformed bystanders  
were perhaps to be expected. Oh well.

One of them decided he knew better than me what the requirements were  
for the problem I needed the new RR for. He didn't appear to  
understand he didn't have a say on the allocation of a new type code  
or a veto over the template I submitted either. Others mistakenly felt  
that the suggested name for one of the new RRtypes had some bearing on  
zone semantics. [I doubt they'd read the documentation.] Anyone who  
wants to know the details can buy me beer or consult the dnsext  
archives from late 2008.

There were no difficulties with the expert reviews of the templates.  
Or with the reviewers. They were helpful and did their job of  
allocating the new type codes with the minimum of fuss. Which is how  
the 5935 process is supposed to work.

It's meant to be simple and straightforward to get new RR type codes  
assigned -- no RFC required! -- as long as the new RR does not mess  
with zone cut semantics or entail changes to additional section  
processing. This is perhaps the most important thing to bear in mind  
if a new RRtype turns out to be the path this BOF will follow.