Subject: rfc2929bis comments

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Jan 2007 15:53:20 -0500

As part of the "expert" review for the ENUM branch location resource 
record, I was asked to make comments on whether the rules were clear 
enough to follow.  Being known for personality traits that some would 
call "over pedantic" I was asked to review the instructions with my 
peculiar world view.

So, yes, my comments may seem eccentric.

Comments on sections 3.1.2 and 3.1.3 of the draft found at this URL:
      http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-04.txt

#3.1.2 Expert Review DNS RRTYPE Expert Review Template

It took me a while to locate this, I had to call Olafur to find the 
template in the doc.  This doesn't look much like a template, for one 
thing, I would have put it on a separate page so it stands out as a 
template and not just more text on the process.  Perhaps include it 
as an appendix.

#
#                 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE
#
#        Date:
#
#        Name, email, and telephone number of originator:

How about this -

          Name:
          Email Address:
          E.164 Telephone Number:
          Other contact address (e.g., SIP):  <or somesuch>

#
#
#D. Eastlake 3rd                                                 [Page 8]
##
#
#INTERNET-DRAFT           DNS IANA Considerations           November 2006

Having the page break makes it annoying to cut and paste the form 
into another document and then edit that.  About as annoying as the 
extraneous quotes in the ID boilerplate instructions.

#
#
#        Provide a pointer to internet-draft or other public document
#        giving a detailed description of the protocol use of the new
#        RRTYPE, or, alternatively, append detailed documentation to
#        this template:

How about -

          URL of document describing the new RR:

Much shorter, and I think any reasonable applicant would know what the
document has to include before seeing the template instructions.  However,
URL's are fleeting but there is likely no RFC or other permanent document
to which to refer.

(Perhaps the application should be thought of as a working item.  If 
you want to archive them, archive the template and the supporting 
documentation as a bundle.)

#        What need is the new RRTYPE intended to satisfy?

Lousy question - why is it needed?  If anything, this ought to be in 
the document referred to above.  But does it really matter what an RR 
is to be used for if it meets the criteria for having a value 
assigned?

All I can think of is that this would satisfy my curiosity but I 
can't imagine how it would impact the decision to grant it a number.

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

I don't think this is a reasonable question.  Does this mean an 
radical new idea loses points for bucking the status quo?  This is 
something best dicussed when preparing the describing document.

#        What mnemonic is requested for the new RRTYPE (optional)?

"optional?"  I would think this is required but negotiable.  (Like 
the request years ago for the RR RR.  I talked the editor out of that 
quite easily.)  BTW, there's no request for the long name here.

Or do you mean "leave it as an option for the mnemonic to be assigned 
by the expert or IANA staff?"

#        Does the requested RRTYPE make us of any existing IANA Registry
#        or require the creation of a new IANA Registry and if so what
#        is that registry or registries?

s/us/use/

I don't see that as important to the process of assigning a value to 
the type, perhaps it is important to the success of the proposal 
though.  Is it the case that the decision to grant/deny a value is 
linked to acceptance of a proposal?

#        Does the proposed RRTYPE require special handling within the
#        DNS different from an Unknown RRTYPE or ignorable Meta-TYPE?

Does support of the proposed RR type require alteration and upgrading 
of name server software or require "special handling" in any way?

#        Comments:

Hopefully there is some guidance on what might go here, but I guess 
that is something that time will tell.

#3.1.3 DNS RRTYPE Expert Guidelines
#
#   The designed DNS RRTYPE Expert is required to monitor discussion of
#   the proposed RRTYPE which may occur on the namedroppers mailing list
#   and to consult with other experts as necessary. The Expert should
#   normally reject any RRTYPE allocation request which meets one or more
#   of the following criterion:

I would rather have a checklist of necessary and sufficient items to 
show that the process was followed.

#   1. Did not have a complete template as specified above posted to the
#      namedroppers mailing list for at least three weeks.
#
#   2. Was documented in a manner that was not sufficiently clear to
#      evaluate or ensure interoperability.

Interoperability of what?  Name servers or applications?  The latter 
would be hard to judge - for a DNS expert.

#   3. The intended use of the proposed RRTYPE would cause problems with
#      existing DNS deployments or the DNS infrastructure.

What about unintended consequences?  Far more insidious.

#   4. The requested RRTYPE would conflict with one under development
#      within the IETF and the existence of more than one such type would
#      harm interoperability.

This would be hard to do.  First, the IETF has no membership 
boundaries.  What is meant by "development within the IETF" when you 
can't tell if the persons talking in the bar are registered or not 
with the conference.  Stretching this pedantically, it's hard to 
prove that something doesn't exist anywhere in the universe.

#   5. An existing RRTYPE or RRTYPEs appear to adequately meet the
#      purpose of the RR for which a RRTYPE value or values are
#      requested.

Well, the TXT can adequately meet most needs when you boil it down.

#   6. An excessive number of RRTYPE values is being requested when the
#      purpose could be met with a smaller number.

I don't know about this.  Do you want the expert to re-engineer 
sub-optimal solutions?

#
#
#D. Eastlake 3rd                                                 [Page 9]
##
#
#INTERNET-DRAFT           DNS IANA Considerations           November 2006
#
#
#   7. The request appears to be for a RRTYPE value that would not
#      genuinely be used in the DNS or whose use would be insignificant
#      or whose near term use would be better met by a value from the
#      range reserved for Private Use.

That's hard to judge without being a domain expert in the application 
using the RR.

Here's my "response" to all this.

First, what is my job?  Is it to recommend that the request be 
granted, is it to recommend a particular number "pool" 
(private/meta/etc?)?  Is my job to see that the request is properly 
submitted, formatted and has good grammar?

Second, I would be more comfortable showing that the request meets 
criteria than that the request fails criteria.  Here are some rough 
cut, proposed criteria questions and answers.

#) Is the use of the RDATA contents for non-DNS application purposes?

Yes: nominal request
No: request can only proceed with wider DNS protocol analysis

#) Is the use of the RDATA contents exclusively for the DNS protocol?

Yes: request can proceed only with wider DNS protocol analysis
No: nominal request

#) What kind of type is the request for?

Meta: should go for a meta type range
Nominal (Data): should be in the data type range
Query (Q): should be in the Q type range
Special Processing: Number assignment determined by other factors (too)

#) Does the new RR type (assuming each request has one type) conform 
to the basic model of QNAME, QTYPE, and QCLASS corresponding to one 
RR set?

Yes: request can proceed
No: consultation is needed to determine if the deviance is acceptable.

#) Does the request rely on another request to be approved to be useful?

Yes: recommend considering the requests as a group
No: nominal request

#) Is the request clearly defined when present at a zone cut, present 
at a non-zone cut, wildcards, CNAME, DNAME and dynamic update are 
involved?

Yes, without conflict: request can proceed, possibly a canonical type
In conflict: the request ought to be rejected until the conflict is resolved
No: require specifics to be defined

#) Does the inclusion of a set of the RR type in a response imply 
that another set of data ought to be included?

No: proceed, perhaps as canonical type
Yes: determination of the inclusion's impact on the response preparation

#) Does the RDATA of the RR type have any impact on DNS processing of 
the current context or lead to another query being generated?

Yes: Analyze whether this is an amplification problem in the making.
No: nominal request

#) Will the RR be used in a protocol that is on the standards track? 
Or is the protocol experimental?  Or will the protocol have only a 
limited applicability?

Standards track: normal
Experimental or very limited: private use

Note that this is a tricky criteria, as once a number gets burned 
into fielded devices there's a case for the inertia argument.

#) Is the RR proposed for use in a standards track development, as 
opposed to an experiment?

An extension to a standard: normal
An experimental extension: private use

Also subject to "inertia."

#) Has the proposal been made public in a substantive way and has it 
faced any challenges?  (I don't say support, because it is not up to 
the DNS group to decide if a different protocol merits consideration.)

Proposal has subject matter backing: nominal request
Proposal has a skeptical acceptance or limited scope: private use

These are the criteria I'll throw on the mat for now.  The idea is to 
find the requests that should just get a number, those that will be 
harmful to the operation of DNS, and those that ought to be 
researched and refined further.  For those that should just get a 
number, what pot of numbers is to be used is the next question.

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

Dessert - aka Service Pack 1 for lunch.

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