Subject: FW: RE: rfc2929bis comments, Part 2

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

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

[[[Large part of original and response excised. See Part 1.]]]

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?

@@@ Recommend? YOU ARE IT! You make the decision.

@@@ The Expert can make recommendations to the applicant to improve
their application, but once the Expert has come to their decision, they
either (1) direct IANA (working with IANA to avoid conflicts because
valid requests can also come through standards actions which by-pass the
Expert) to allocate the code point(s) and mnemonic(s) or (2) deny the
application and send the applicant away (to try again later with a
different template if they want).

@@@ It is almost entirely up to your discretion what "properly
submitted" is. I would say that being a pedant, as you say you are, is
fine for reviewing this draft but is not how the Expert should exercise
their judgment. If the criterion for allocating RRTYPE code points could
be reduced to a purely mechanical set of rules ("good grammar" ...),
there would be no need for an Expert. IANA could just follow those
mechanical rules themselves.

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.

@@@ I think the current guidelines in the draft are fine and it's a bit
late to try completely rewriting them. And I don't think the alternative
suggested guidelines below are any clearer...

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

@@@ What exactly is a "non-DNS application"? Surely some would say that
anything which uses RRs is, to some extent, a "DNS application".

@@@ The goal of the guidelines is to help answer IANA Considerations.
What is "wider DNS protocol analysis"? By who? Where? That's not a valid
IANA Consideration. You can say things like "requires IETF Consensus" or
you can say "requires IESG Approval" or "requires Expert Approval" or
"requires RFC documentation" or the like, along with additional
procedural details. And, while you can assume a mailing list will exist
indefinitely, you can not assume that any particular working group, such
as the DNSEXT working group, will be around. "with wider DNS protocol
analysis" is just a total hand wave as far as IANA Considerations go.

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

@@@ See above re this nebulous "wider DNS protocol analysis". I don't
see why it makes any difference if the contents are exclusively for the
DNS protocol. Sure, that makes it much more likely that it could not be
processed as Unknown Data or an ignorable Meta-type and thus, under the
draft, would be "allocated by IETF Standards Action as modified by
[RFC4020]" where "Standards Action" is defined in RFC 2434. But, even if
the contents are "exclusively for the DNS protocol" there is no
particular problem if it can be processed as Unknown Data or ignorable
Meta-type.

@@@ (Say someone starts building an outboard DNS assist hardware box
that goes between a host and its net connection and these boxes throw in
a meta-RR with their serial number in all requests and responses and
maybe add some other proprietary glop, maybe even provide a TSIG like
capability when these boxes are on both ends. Is that part of the "DNS
protocol"? It doesn't matter as long as they can be freely ignored.
Probably many would say such a meta-RR "really isn't" part of the "real"
DNS protocol but I wonder how many of them are, possibly subconsciously,
reasoning backward and saying that it isn't part of the real DNS
protocol precisely because it can be ignored... Of course I'm not saying
such a meta-RR is a good idea or that it would necessarily be approved
or would meet other guidelines...) 

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

@@@ Adding something like this question wouldn't hurt anything, but it
is the duty of the Expert to determine if this is a Meta or non-special
Data type or something else. If they can't figure that out, with a
reasonable amount of effort, from the Template and document provided,
the application should be refused on the basis of guideline #2 in the
draft. There is no need for your second two kinds to be distinguished;
if it's a Query or Special Processing kind, the draft requires that it
be "allocated by IETF Standards Action as modified by [RFC4020]" and it
is not the Expert's problem.

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

@@@ I don't like the assumption of one RR type per application. If a use
of DNS requires 2 or more new RRs, the whole use should be considered by
the Expert at once. The requirement to be treatable as an Unknown Data
type or an ignorable Meta-type already implies enough conformance to the
basic model.

@@@ In your proposed consequences of answering your question "no", who
is this "consultation" with? In what forum? "acceptable" to whom? The
draft makes it clear that this is all vested in the Expert who should
consult with the namedroppers mailing list or experts in the particular
usage area as needed.

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

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

@@@ Ah, I guess you suggest here re-grouping the separate requests for
one use. This seems much more complicated than simply having a single
application. Instead of just "recommending" they be considered as group,
they should be required to be grouped into one application, as provided
by the draft.

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

@@@ I guess I don't really see how much of this can apply to a simple RR
that is treatable as an Unknown Data type or an ignorable Meta-type. If
it is really a serious possibility that such complications need to be
considered for such simple RRs, then probably something like this
question should be added to the Template. But if such a question were
added, it needs to yield a simple OK, not-OK result. "rejected until the
conflict is resolved" is meaningless as an IANA Consideration. Resolved
by who? In what forum? Who decides that its "resolved"? If there is a
problem here for an application for such a simple RR, which isn't clear
to me, then that application just needs to be denied. It would then be
entirely up to the application to change or augment their application as
they saw fit so as to attempt to re-apply in a way that convincingly
showed there was no such problem (or try to follow the Standards Action
route if the chose to do so).

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

@@@ "imply"? The draft is quite clear on this point. The application can
recommend, but not require, that certain additional data be included in
the response. If additional data is *required*, the allocation has to
follow the "allocated by IETF Standards Action as modified by [RFC4020]"
route.

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

@@@ This is addressed by guideline #3 in the draft.

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

@@@ See guideline #7 in the draft. I do not believe this can be reduced
to Standards track versus Experimental (or very limited). While
Standards track implies non-private allocation, a widespread
multi-organization Experiment that, if successful, would develop into
wide deployment would also warrant non-private allocation. Furthermore,
it is entirely reasonable for RRTYPE code points to be allocated for RRs
that have nothing to do with any IETF Standard or Experiment but are for
the use of a protocol devised and maintained by an outside organization.
Like so much of this issue, it calls for the judgment of the Expert, not
a mechanical response to whether something is Standards track or not.

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

@@@ See comment above. 

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

@@@ No. This is not supposed to be a popularity context among those in
the DNS in-crowd.

@@@ Allocation decisions should be based on technical and deployment
probability considerations ONLY. Even if there is a storm of protest
against some RR (say one designed to store ratings of how "adult" the
material is that is stored on a host with that owner name, protested by
many free speech advocates), if the Expert believes it does not run
afoul of the guidelines in the draft and that it will get enough
deployment (implied by not running afoul of guideline #7 in the draft),
it should normally (and "normally" is used in the draft to give wiggle
room for Expert judgment) get allocated a non-private code point.

@@@ By the way, if the Expert determines that a private code point is
more appropriate, they should just deny the application and tell the
applicant that. Private code points aren't allocated. It is up to the
private use to select one or more from the range defined.

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.

@@@ Sorry if you find this offensive but I believe that the guidelines
in the draft, which have passed working group last call, while not
perfect, are better and provide crisper decision criterion than the
procedural series of steps you suggest.

@@@ It is outside of the scope of the Expert and not related to IANA
Considerations to say what "ought to be researched and refined further".
The Expert could make recommendations to the application whose
application is denied but it is entirely up to that applicant what
"research" they what to do in what forum and whether they want to
"refine"/modify their application and try again. The Expert's is only
required to make and promulgate their decision on the application as
presented.

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

@@@ I'm not sure what can be done at this point with the draft having
passed working group last call and the PROTO write-up requesting
publication having been sent to the Area Director. Certainly, an IETF
Last Call will be needed in any case and anyone can comment as they see
fit during that. However, I think the following changes would be good
and are only editorial, so possibly they can be included at this point.
If not, I'd be happy to suggest them as a comment during IETF Last Call.

@@@  1. Make the DNS RRTYPE PARAMETER ALLOCATION TEMPLATE stand out more
by making it a separate page and possibly an appendix. [Note: The RFC
editor has a strong tendency to delete page breaks and run everything
together so a special note to the RFC editor may be called for.]

@@@  2. Put the "Name", "Email", and "Telephone number" items on
different lines and provide an item for optional "Other contact
information". Add "(including country code)" to the telephone number
item.

@@@  3. Fix the "us" -> "use" typo in the IANA Registry item of the
Template.

@@@  4. Add "[RFC3597]" reference after "Unknown RRTYPE" in the "special
handling" question in the Template.

@@@  5. Number the items in the Template.

@@@ Thanks,
@@@ Donald
 =========================================================
 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/>