Subject: FW: RE: rfc2929bis comments, Part 1

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 28 Jan 2007 11:23:56 -0500

Looks like my original reply isn't getting through. I'm guessing that is
because it exceeded some length limit, so I'm dividing it into two
messages and trying again...

-----Original Message-----
From: Eastlake III Donald-LDE008 
Sent: Friday, January 26, 2007 5:23 PM
To: [email-masked]
Subject: RE: rfc2929bis comments

Hi,

See below at @@@

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Edward Lewis
Sent: Tuesday, January 23, 2007 3:53 PM
To: [email-masked]
Cc: [email-masked]
Subject: rfc2929bis comments

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.

@@@ I agree it would be better if the Template stood out more but it is
really a bit hard to understand how you couldn't find it. I think that
most people will find it fairly easily in the process of reading the
document or by reading the Table of Contents or searching for the word
"template".

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

@@@ Putting these on separate lines is an improvement but I certainly
wouldn't use "E.164" as I think it would just cause confusion. Perhaps
"Telephone Number (including country code):". And while there is noting
wrong with the final "Other ..." line it would need to say "(optional)"
so the applicant would know it was not required.

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

@@@ I think it is important that the applicant be required to describe
"the protocol use of the new RRTYPE", not just the "the new RR" which
could just be its RDATA structure. I think it is good that the Template
make it clear that it must be a "public" document so anyone seeing the
Template posted to namedroppers can go look at it and so that the expert
and IANA can copy it. I think the option of appending the document to
the Template is a good one. In short, while the current wording isn't
perfect, I think it is superior to the suggested "shorter" version.

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

@@@ Rather than being superfluous, this may be THE MOST IMPORTANT
QUESTION in the Template.

@@@ I think you have a fundamentally wrong view of what an Expert is
supposed to do for IANA allocations. Basically, the Expert is supposed
to channel John Postel and understand the application enough to
determine whether it is best, under all the circumstances, in their
judgment, to allocate the code point. The specific guidelines are there
to help the Expert and the applicant out, not to make the judgment for
the Expert.

@@@ The document the applicant is required to attach need only describe
the RR and protocol use intended. The answer to this Template question
could be almost anything and could be the dominant factor. What if the
applicant says "I need this code point to win the $1 bet with my friend
that I could get an RRTYPE allocated."? How about "Although this RRTYPE
violates guidelines A, B, and C, industry X is currently shipping
100,000,000 widgets a year with chips in them hardwired to use RRTPE
code # so you need to allocate that to avoid later collisions."? I am
not saying it is necessarily clear what the Expert's judgment would be
in such cases and I am not saying that it would not be influenced by
other parts of the Template, I'm just saying that this question asks for
information which could be critical to that judgment and which is not
necessarily revealed by the answers to other questions in the Template
or the attached/referenced document.

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

@@@ Well, this does impose a burden on the applicant to have looked at
existing RRTYPEs and try to figure out if existing RRTYPEst will fit
their need and if not why not. The Expert should do this in any case and
this Template item attempts to transfer some of that work to the
applicant. I have a hard time figuring out how you came up with your
question just above. Surely a "radical new idea" would propose something
far from existing RRTYPEs and have no problem showing major differences
from any existing RRTYPE. On the other hand, an application for an
RRTYPE identical to an existing RRTYPE in all respects except that the
RDATA fields are in a different order should almost certainly be denied.

@@@ If you are assuming that "preparing the describing document" will
occur within an IETF or namedroppers context, that assumption is not
warranted.

@@@ This is the sort of question that might be left blank when an
applicant first posts an incomplete Template to namedroppers to solicit
feedback for improvement, as suggested in the draft.

#        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?"

@@@ This Template is completed and posted to namedroppers by the
applicant. "optional" means optional for the applicant to fill in. I
should think the Expert would use the mnemonic suggested by the
applicant unless there was none or the Expert saw some problem with it,
in which case the Expert would specify the mnemonic while assigning the
code point.

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

@@@ Thanks for finding this typo.

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?

@@@ I would agree that it is not important to the narrowly viewed
selection of a code point but it is an important enough factor feeding
into the Expert's judgment that it should be asked. In any case, it is
roughly the equivalent of the required "IANA Considerations" section in
a draft. It is the required "IANA Considerations" section of the RRTYPE
allocation application and in some cases could just be a cut and paste
from the required document or answered by a pointer to a section of that
document.

#        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?

@@@ Your version of the question holds the applicant hostage to vagaries
of implementations and loads everything onto the words "special
handling". I believe the question in the draft is better because it
makes it much clearer what is ordinary handling and what is special
handling. Possibly the question in the Template should include a
reference to [RFC3597] to make "Unknown RRTYPE" even clearer.

#        Comments:

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

@@@ This is for the stuff that we couldn't think of so I'm not sure why
one would expect it to be possible to give much guidance for it.

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

@@@ I can't see that it makes much difference whether things are
expressed negatively or positively. Either way, the Expert has
discretion to grant or refuse and application regardless of the
guidelines. The "process" is that a complete Template is posted to
namedroppers. The Expert then takes the Template, the required document,
any discussions on namedroppers, and any comments of other experts the
Expert sees fit to consult into consideration and, no earlier than three
weeks after the Template was posted, renders a judgment. That's the
process.

@@@ The Expert doesn't have to and really isn't supposed to exercise
their powers in isolation. They can consult anyone they like. They can
post a tentative decision to namedroppers to get people's reaction. They
can comment on a partial Template that has been posted to solicit
feedback. They can point out flaws or gaps or places where they think
more detail is needed and recommend that a Template be beefed up and
re-submitted. Etc.

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

@@@ Interoperability is meant in the usual IETF sense that multiple
independent implementations of the proposed RRTYPE would interoperate.
The document referred to, which is the only document required by the
Template, is the document of the "protocol use" of the RRTYPE. So it's
the applications. If evaluating this requires expertise beyond that held
by the Expert, they should solicit input from others.

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

@@@ "unintended consequences"? Everything has some level of unintended
consequences, which can be good or bad. Like anything else, you do your
best to predict what problems would be caused. I don't see how you can
do better than that.

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

@@@ The intent was to interpret this in the same way the IESG does when
it determines if an RFC submitted by an individual to the RFC Editor is
an attempt to run around IETF process. Its approximate meaning is
whether there is an IETF working group chartered or BoF coming up which
would encompass the use intended. In marginal cases, this is another
instance where the Expert is required to make their best judgment.

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

@@@ See my comment above. The Expert is a judge. There are always
conflicting arguments on such matters. You can always argue that TXT
would be adequate and you can always find some reason that a completely
new RR is needed. It is the duty of the Expert to use their judgment as
to the balance of these arguments and make a decision.

#   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?

@@@ Where do you get this "re-engineer" idea? There is nothing anywhere
in this draft requiring the Expert to help the applicant or requiring
that the Expert suggest improvements in their application. One would
hope that, in most cases where the Expert believes the application is
submitted in good faith, the Expert and/or others on the namedroppers
list would be helpful, but this isn't required.

@@@ As with all the other guidelines, the expert is required to use
judgment on this factor. 

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

@@@ I didn't say the Expert's job was easy. But if making the judgments
and balancing the factors for a particular application requires the
expertise of someone from a particular application domain, the Expert
should find such people and ask them.

[[[For the rest of this response, see Part 2]]]

 =========================================================
 Donald E. Eastlake III       [email-masked]
 Motorola Laboratories              +1-508-786-7554 (work)
 111 Locke Drive
 Marlboro, MA 01752 USA

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