Subject: Re: DNSEXT WGLC: RFC2929bis

From: Sam Weiler <[email-masked]>
Date: Tue, 19 Sep 2006 10:50:46 -0400 (EDT)

On Sat, 26 Aug 2006, Sam Weiler wrote:

> Summary: I do NOT support the publication of this document in its
> present form.
>
> While I strongly support a templating system for typecodes, I don't
> like this one.  First, I'm not sure we need evaulation criteria 3-8 --
> why aren't 1 & 2 enough?  Second, I'd rather see a template that can,
> in most cases, provide the full spec of the typecode, including the
> wire format and presentation format, so that reference to an outside
> document is not needed -- I'd like to see the template itself be an
> adequate record for most typecode requests.  I'll try to post a sample
> template to the list.

First noting that I've seen no answer to my question above re: why 
2929bis needs criteria 3-8...

Below is a proposed template.  Unlike the one in the document, this 
one makes the template itself a self-contained record of the RR, 
indepdendent of any other document.  It also makes disclosure of the 
use of the typecode optional, and it does not require justification 
for use of a new typecode.

I also think this template could be implemented at the IANA's 
discretion without needing to revise 2929 at all -- 2929 already 
allows typecode assignments with a metric of Specification Required, 
and an archived template like this could provide a low impedence path 
to such an assignment.

Name:

Email address:

Requested mnemonic (optional):

What need is the new RR TYPE intended to satisfy? (optional)

Does this RR type duplicate both the wire and presentation formats of
an existing RR type?

    If yes, which one, and which document(s) specify that RR?

    If no:
 	Wire format of record:

 	Presentation format of record:

Does this RR type reuse any IANA registry (ie. DNSSEC Algorithm 
numbers)?  Which ones?

Does the proposed RR TYPE require special handling within the DNS
different from an Unknown RR TYPE (see RFC3597) or ignorable
meta-TYPE?  In particular:

    1. Does this RR require any special equality comparison rules
       (e.g., for dynamic update)?

    2. Does this RR allow for the compression of any domain names
       contained in the RDATA?

------------

I propose that the only criteria used for evaluating such a request 
be:

    1. Was a complete template posted to the designated mailing list
       for at least three weeks?

    2. Was the specification sufficiently clear to evaluate and ensure
       interoperability?  (e.g., are the wire and presentation formats
       clear and unambiguous?)

    3. Does the RR type require handling inconsistent with RFC3597?

    4. Does the request otherwise overstep the bounds of this process?
       (e.g., does the typecode require a new IANA registry be created,
       which can't be done within this process)

To be completely clear, I specifically object to giving the expert
discretion to judge the merits of the need for a typecode (criteria
6-8 in the current doc), nor do I think criteria 3-5 are necessary. 
If we're going to keep them (and continue giving the expert such 
discretion), I'd like to hear a specific justification for doing so.

-- Sam

--
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: Thomas Narten <[email-masked]>
Date: Tue, 19 Sep 2006 16:28:11 -0400

> > why aren't 1 & 2 enough?

Here are 1 & 2:

   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.

Note that 1&2 say nothing about when a request should be granted, and
when rejected. If this document doesn't provide guidance on that
question, we're just pushing off the hard question until later (i.e.,
when the first request comes in). That is not the best time to decide
the rules.

3-8 seem pretty important to me, because they provide guidance to the
Designated Expert so that he/she knows whether to approve or reject a
request. If there is no guidance, when can the expert say no? I'll
note that figuring out the criteria for saying yes or no to an RR has
been somewhat challenging for this group in the past, when looking at
specific RRs, especially ones that weren't well liked or thought to be
useless.

Reading through 3-8, they seem rather familiar, looking a lot like
generic criteria that has been added to Section 3.3 of 2434bis (I
submitted -05 last week, but it's not out yet, til then, look here:
http://www.cs.duke.edu/~narten/ietf/draft-narten-iana-considerations-rfc2434bis-05.txt))

So, one possibility is to look at the wording in 2434bis and say
"close enough for our use" and not repeat the criteria here. However,
I think it would be helpful to specify (in more detail) what is meant
in a DNS context.

Personally, I think this document should contain principles, not
rules. The principles say what the intention is, which the expert then
carries out. Having rules makes it too easy to lose track of the
principles, and get caught up on process and interpreting the
rules. Or forget an important principle, and find the rules don't
mention them, so the expert can't say no when no is the right answer.

Here is a cut at what I'd like to see in the document:

       DNS is designed to carry opaque RRs, that is, RRs that DNS
       servers and resolvers do not need to understand the semantics
       of in order to correctly process. Higher-layer software (e.g.,
       applications) are the only entities that need to understand the
       semantics of the RRs being using. So long as a request for an
       RR TYPE requires no special, RR-specific processing by DNS
       software (i.e., resolvers and servers) and is not expected to
       lead to operational or interoperability problems (at the DNS
       level), the request for an RR TYPE code should be granted.
       Note: the review process should focus on the impact on the DNS
       of the requested RR, and not on whether the proposed usage is
       justified or has the optimal semantics. The question of whether
       the semantics of a proposed RR makes sense to an application is
       best addressed by appropriate subject matter experts.

We could also add examples of things to look for (as long as they are
examples and not viewed as the full list). Example I can think of for
pushing back is if the RR or RRSet is too big and will lead to packet
size issues.

I'm not inherently opposed to a template, but I don't quite like the
one proposed. For one thing, it puts the burden on the end user to
answer the questions that DNS experts need to know. However,
experience has shown that those requesting RRs often aren't very
familiar with the DNS - so asking them to provide answers doesn't seem
like it will work.

Second, I think the template may need to evolve, as we gain
experience.  Thus, I'd prefer that theexpert maintain a "review
criteria" containing general questions that need to be answered. That
list can be updated over time, and it is the job of the expert (and
namedroppers) to obtain answers to those questions to the point of
being comfortable that the request will not cause problems in the DNS.

> > Second, I'd rather see a template that can,

If the template includes the full spec, then why not just require an
ID to review? Seems simpler...

> 2929bis needs criteria 3-8...

For example,

   4. The intended use of the proposed RRTYPE would cause problems with
      existing DNS deployments.

This is exactly the type of RR I'd like to push back on. We don't want
to allow random application programmers to define RRs that redefine
the way an RR is supposed to be processed by DNS servers...

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

Seems like a reasonable reason to push back on a request. Do you
really not want the expert to say "no" in this case?

   8. The request appears to be for an 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.

This one I agree is a little iffy. We've got 16 bits of RCODE
space. We aren't in any real danger of using up the space.

> for use of a new typecode.

Why should disclosure of the use of the typecode by optional? How can
you evaluate an RR if its not explained how it will be used?

> and an archived template like this could provide a low impedence path 

We need to revise 2929 because it doesn't allow early assignment of
codepoints. So I think we do need a 2929bis.

Thomas

---

From: Sam Weiler <[email-masked]>
Date: Wed, 20 Sep 2006 00:18:00 -0400 (EDT)

(sorry for quoting so much -- it seemed better to preserve the 
context)

On Tue, 19 Sep 2006, Thomas Narten wrote:

> when rejected. ...

Just before the list of eight criteria in 2929bis is the text: "The 
Expert should reject any RRTYPE allocation request which meets the 
following criterion."  I infer that the expert should approve all 
other requests.

> request. If there is no guidance, when can the expert say no?

We have a couple of choices here.  We could say "say 'no' when any of 
the criteria we agree on aren't satisfied, and only then".  Or we 
could give the expert signifigant discretion, noting that a fallback 
option (standards track) is available.  I'm inclined to err on the 
side of giving little discretion.

> rules. The principles say what the intention is, which the expert 
> then carries out. Having rules makes it too easy to lose track of 
> the principles, and get caught up on process and interpreting the 

I concur.  I think it's sufficient to allow the "rules" to be set by 
IANA and/or the expert (with our advice).  I think IANA could adopt 
the template I proposed, along with the evalution criteria, without 
requiring any document action nor explicit rules setting on our part.

>       best addressed by appropriate subject matter experts.

In general, I agree with this.  I worry a bit about the "operational 
problems" item -- that seems like one that might be very hard for an 
expert to judge and it could lead to needless rejections.  On the 
other hand, we already have most of this in 3597, and I'm not sure we 
need to restate it.

> pushing back is if the RR or RRSet is too big and will lead to packet

RR/RRset/packet size sound like things worthy of "pushing back on" in 
the sense of "asking a second time to make sure the requestor knows 
what they're doing" but not worthy of rejecting a request over.

> familiar with the DNS - so asking them to provide answers doesn't seem

I imagine that most requestors of a typecode would need or want 
someone familiar with the DNS to fill out the template, if only to 
make sure that the wire and presentation formats are clearly 
specified.  Incoherence in the template should result in a rapid "no" 
from the expert.

> experience.

I concur that the template may need to evolve.  As I said before, I 
think IANA can implement a template system without our encoding it in 
an RFC, which would then allow them to evolve the template.

> ID to review? Seems simpler...

Because the IANA must reject typecode requests based on ID's because 
ID's aren't permanent references.  We need something that is a 
permanent reference, and an IANA-archived template would seem to do 
the trick.

> the way an RR is supposed to be processed by DNS servers...

There's a difference between "requires special processing", which we 
don't want to see (and the expert should stop) and "would cause 
problems for existing DNS deployments due to packet size, etc.", which 
I don't necessarily want to give the expert discretion to judge.

> really not want the expert to say "no" in this case?

Like packet size issues, I think it's reasonable to "push back" on 
such a request by asking a second time to make sure the requestor has 
considered an alternative, but I think it's inappropriate to give the 
expert discretion to say "no" if the requestor insists.

> you evaluate an RR if its not explained how it will be used?

Turning the question back at you: what evaluation do we need to do 
that requires us knowing the use of the typecode?  I don't think we 
need to know the use to do the sort of evaluation I'm talking about.

> codepoints. So I think we do need a 2929bis.

I'm assuming you mean "early assignment of codepoints for 
standards-track RFCs".  Could we get around the need for early 
assignment by making it even easier to get assignments under 
specification required rules, perhaps through the templating system I 
proposed?  Then the RFC, whenever it's published, could reference the 
codepoint assigned through the earlier process.

-- Sam

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 20 Sep 2006 09:29:20 +0200

On 20Sep 2006, at 6:18 AM, Sam Weiler wrote:

> There's a difference between "requires special processing", which  
> we don't want to see (and the expert should stop) and "would cause  
> problems for existing DNS deployments due to packet size, etc.",  
> which I don't necessarily want to give the expert discretion to judge.

Why would an export be allowed to reject RR specifications that will  
cause operational harm? Obviously such assessment is a judgment call  
that should be motivated, but that is why you consult an expert.

Please explain why operational concerns should not be taken into  
account. (That is at least what I understand you argue).

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 20 Sep 2006 09:29:20 +0200

--Olaf

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 20 Sep 2006 10:16:56 +0200

On 20Sep 2006, at 9:29 AM, Olaf M. Kolkman wrote:

> Why would an export be allowed to reject RR specifications that  
> will cause operational harm? Obviously such assessment is a
oops that should have read:
Why would an export not be allowed ....

> judgment call that should be motivated, but that is why you consult  
> an expert.
>

---

From: [email-masked]
Date: Wed, 20 Sep 2006 13:47:07 +0000

> I don't necessarily want to give the expert discretion to judge.

	we certainly do want to see special processing. why do you
	think it should be stopped?

	and i remain unconvinved that backward compatability is
	always the guiding principle here.  

	that said, if the IESG is going to anoint a judge for life
	on approving changes, then i would expect that such an
	anointing would allow for the judge to have subjective powers
	to make her rulings.

--bill

---

From: Thomas Narten <[email-masked]>
Date: Wed, 20 Sep 2006 09:47:55 -0400

> following criterion."  I infer that the expert should approve all 

This type of reading is too rigid, IMO, and exactly what I don't think
we want. The whole point of Expert Review is to have a human do the
evaluation, one who can take into consideration things that might not
have been written into the RFC. Judgement is good. Blind adherence to
rigid rules written into an RFC some years back is not always good.

Please also read Section 3.3 of
draft-narten-iana-considerations-rfc2434bis (which is now out). I
think (or at least hope) that it should address what I suspect is your
basic concern. Experts are accountable to the community. If the
community view (e.g., after discussion on namedroppers) says "make the
assignment", there is a pretty strong presumption that the expert will
follow that advice.

> side of giving little discretion.

Again, see my comments above. The Expert isn't intended to sit on
Mount Olympus and do as he/she sees fit. We do want to give them
discretion, precisely because it's not generally possible to
anticipate all future scenarios.

> requiring any document action nor explicit rules setting on our

Note: IANA can't and shouldn't set the rules. They have no expertise
in this space. Hence, this role needs to fall on the Expert. Someone
who actually does have knowledge about the DNS.

Yes, we can formally have a template, but IMO, that can be done
informally just as well, and would be less hassle to update over time.

> other hand, we already have most of this in 3597, and I'm not sure we 

It might be good to cite RFC 3597 explicitely as an example of what we
expect new RRs to satisfy.

> what they're doing" but not worthy of rejecting a request over.

I think we may be closer to agreement than seems. I view "being able
to say no" as necessary to have the discussion and to be able to "push
back on" on a request. This is never black-and-white. Whether to say
"no" at the end of the discussion really depends on the specifics at
hand (e.g., just how big are the RRsets? There is presumably a big
differnce between 5K and 50K).

[snip]

> permanent reference, and an IANA-archived template would seem to do 

We may be mixing things here now. Indeed, I do not see wording in
2929bis (under the new section) that requires the RR writeup to be a
"permanent reference". That may well be a bug. But the current
proposed rules do not seem to require a permanent spec be available,
ala the "specification required" rules.

> I don't necessarily want to give the expert discretion to judge.

No suprise here, but I strongly disagree with the latter. If the
expert doesn't have the ability to push back and say no, I don't
really know what the point of expert review is.

> expert discretion to say "no" if the requestor insists.

Again, I think this depends on the specifics.

> need to know the use to do the sort of evaluation I'm talking about.

Fair enough. I don't think the DNS portion of the review needs to know
the semantics of the RR, other than that it is clear how the fields in
the RR itself are laid out.

However, I've come to the personal conclusion that having IANA keep
simple, non-critical information "private" or under "NDA" to be a big
hassle with almost no benefit. It's rarely used (except by requestors
who see it is an option so decide to go that route for no particular
reason) and it (unncessarily) complicates the handling of IANA
requests. This is a general issue, and not one specific to DNS.

Let me turn it around and ask why such information should remain
private. If the RR type appears on the public internet, is useful to
be able to have very simple/basic information about the RR type, such
as a name and what vendor it is assigned to. Think of things like
tcpdump. And what we are asking to make public is not any kind of
trade secret.

As an analogy, should port number assignments be allowed to be kept
private?

> standards-track RFCs".

Yes, or something similar. My point is that we can't just continue
using 2929, some changes are needed.  You seem to imply above that we
wouldn't need to respin 2929 at all.

> Could we get around the need for early assignment by making it even
> easier to get assignments under specification required rules,

That is what I thought having "expert review" was going to
achieve. Expert review is presumably a lower bar, so will be easier.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 20 Sep 2006 09:53:55 -0400

> 	always the guiding principle here.

Who said it was "always" the guiding principle? It is one factor, but
not the only one, and I would assume the specifics of the situation
matters. If something only impacts an implementation thought to be
extinct for ten years, I agree, it would be silly to care. If it
impacts servers that are still widely deployed, we'd want to think
about the implication carefully.

Note: the above is exactly why you want a human involved in making the
decision. Presumably one who will actually think and make a reasonable
decision.

> 	anointing would allow for the judge to have subjective powers

Gee Bill, this is pure FUD.

From the above, I can only conclude you have not read 2434bis (or even
2434) and you have a view of how things work that differs from
reality.

Sigh.

Thomas

---

From: Sam Weiler <[email-masked]>
Date: Wed, 20 Sep 2006 13:27:30 -0400 (EDT)

> 	think it should be stopped?

rfc3597, section 8.

-- Sam

---

From: [email-masked]
Date: Wed, 20 Sep 2006 18:44:01 +0000

> >	think it should be stopped?

	for those who do not have the RFC archives on their laptoys...

RFC 3597 :  Handling of Unknown DNS RR Types
8.  Additional Section Processing

   Unknown RR types cause no additional section processing.  Future RR
   type specifications MAY specify type-specific additional section
   processing rules, but any such processing MUST be optional as it can
   only be performed by servers for which the RR type in case is known.

	-----------------------------------------------

	i see nothing here that depricates additional section processing.
	what i see here is a formal method for enabling additional section
	processing for those cases that MAY require such.  The caveat in
	this RFC is that not all servers may know how to do such processing...

	so do you want to stop addtional section processing because not
	all deployed server code will be able to understand/accomodate
	such processing requests? 

	or are there other reasons?

--bill