Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 2 Jul 2006 21:56:28 -0400

The whole thing about IANA allocations is to define the process so an
objection related to that is quite important.

As I understand it, the Expert's job is to, in effect, hold the
delegated authority of IANA to grant or withhold allocation of a code
point. It is not a "recommend/not recommend" thing, they have the
authority, subject to the usual appeal channels to the IESG, etc. Of
course they should try to help proponents. And if they are sufficiently
obstructive or obnoxious or abuse their authority, you would expect a
clamor to the IESG to replace them.

Keep in mind that this is intended to be an open but reasonably rapid
and efficient process. The template specified in 3.1.2 must have been
completed and posted to namedroppers for three weeks so there will be
plenty of time for community input. But someone has to have the
authority and make the call and "Expert Review" means that the
Designated Expert appointed by the IESG is it.

Who did you think had the authority? It can't be the DNSEXT working
group as the IETF process assumption is that all working groups are
temporary. (Although, of course, as long as the DNEXT working group, or
a successor, exists, I would expect its chair or co-chair to have major
input to the Designated Expert selection.)

Thanks,
Donald

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott Rose
Sent: Friday, June 30, 2006 2:40 PM
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt

I have one comment on the new text (or maybe this was old, but I the
first time I saw it).  Unfortunately, it is a high level politics thing.

The first paragraph in Section 3.1.3 has the sentence "The Expert should
reject any RRTYPE allocation request...".  That makes it sound like a
much more formal process than the rest of the document lays out.  From
what I gathered, it is more of a "recommend/not recommend" thing.  The
Expert's job should be more of an endorsement, or failing the criteria,
helping the proponents meet whatever goal they have for the draft.

Yes, this is a process issue and not a technical one, but something that
may catch some poor WG member acting as a expert in the future.

Scott
****************************************
Scott Rose
Adv. Network Tech. Div., NIST
+1 301-975-8439

https://www-x.antd.nist.gov/dnssec/
http://www.dnssec-deployment.org/
****************************************

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Eastlake III
> Donald-LDE008
> Sent: Friday, June 30, 2006 10:36 AM
> To: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt
>
>
> Hi,
>
> The last feedback I got from the working group on this draft was that 
> it was in good shape except for the need for some specific guidelines 
> for the designated RR type allocation expert. So this updated version 
> has such guidelines in section 3.1.3. Hopefully this version, or 
> perhaps -04 is some minor changes are needed, will be ready for WG
last call.
>
> Thanks,
> Donald
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Thursday, June 29, 2006 3:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the DNS Extensions Working Group of the 
> IETF.
>
> 	Title		: Domain Name System (DNS) IANA Considerations
> 	Author(s)	: D. Eastlake 3rd
> 	Filename	: draft-ietf-dnsext-2929bis-03.txt
> 	Pages		: 19
> 	Date		: 2006-6-29
>
> Internet Assigned Number Authority (IANA) parameter assignment 
> considerations are specified for the allocation of Domain Name System
> (DNS) Classes, RR Types, operation codes, error codes, RR header bits,

> and AFSDB subtypes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt
>
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of

> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-dnsext-2929bis-03.txt".
>
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-dnsext-2929bis-03.txt".
>
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> --
> 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/>

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

--
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: Peter Koch <[email-masked]>
Date: Sun, 09 Jul 2006 21:28:47 +0200

Donald Eastlake wrote:

> The last feedback I got from the working group on this draft was that it
> was in good shape except for the need for some specific guidelines for
> the designated RR type allocation expert. So this updated version has
> such guidelines in section 3.1.3. Hopefully this version, or perhaps -04

as one of those asking for such guidance (and apologies for failing to
send text), I am pretty much happy with what Donald came up in 3.1.3, just
modulo some nits.

3.1.3 first:

(nit) s/designed/Designated/
(nit) use consistent spelling of "RR TYPE" vs. "RRTYPE"

>   and to consult with other experts as necessary. The Expert should
>   reject any RRTYPE allocation request which meets the following
>   criterion:

"which meets at least one of the following criteria" to emphazise these
items are ORed.

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

add "or the DNS infrastructure" to cover cases like tree climbing.

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

rephrase /harm interoperability/ to /put interoperability at risk/ to
shift the burden of the proof on the requester.

The template in 3.1.2 I'd like to be amended

>       Does the proposed RR TYPE require special handling within the
>       DNS different from an Unknown RR TYPE or ignorable meta-TYPE?

so that a "no" would require some explanation or discussion.

The document doesn't say what an "ignorable" meta type (nit: consistent
spelling) is, other than

>  2. The RR for which a TYPE code is being requested is either (a) a
>     data TYPE which can be handled as an Unknown RR as described in
>     [RFC 3597] or (b) a Meta TYPE who processing is optional, i.e.,
>     which it is safe to simply discard.

Would that encourage silence in response to a Meta Query?

Also, if this is what makes 2929bis update 3597, could that be mentioned
explicitly?

Other comments, some of which may apply to text that already appeared in
RFC 2929, but since this is an update attempt anyway:

o The introduction and 3.2 call the DNS a database, which it isn't. Slightly
  change that to data store, data repository or something close.

o The Opcode list in 2.2 (and one could argue that such list doesn't
  really belong into the policy setting document in the first place)
  uses mixed case for codes of QUERY, IQUERY and STATUS with a reference
  to RFC 1035, where that uses all caps. Same for NOTIFY and UPDATE.
  Could be these names are either non-normative or case insensitive
  (as everything else in the DNS) but some authoritative words would be fine.

o Same applies to the error code list in 2.3, even more so since RFC 1035
  didn't even define a mnemnonic for every code.

o ``Allocation'' and ``assignment'' are used synonymously throughout the draft.
  Suggest to use one term (assignment) only.

o bottom of page 6: ``TTL is a four octet (32 bit) [bit] unsigned integer''

o page 11: QCLASS None, the case issue again

o still page 11: strictly speaking 255 is for QCLASS=*, not "any" (in any
  case :-)

o 3.3 RR NAME Considerations
  this touches both label type and label content issues, so i'd suggest to
  rename the section to "Label Considerations" and make the split between
  label types (currently the 2nd paragraph) and label content.

o still 3.3

>   A somewhat out-of-date description of name allocation in the IN Class
>   is given in [RFC 1591].  Some information on reserved top level
>   domain names is in BCP 32 [RFC 2606].

  This is kinda level 9ish, but I don't think the WG or the IETF should
  make a statement, however fuzzy, on how outdated RFC 1591 is (2929 said
  "dated"). The main point here is that there is no IETF label registry,
  be that TLD labels or those further down the tree (although there are
  proposals to change the latter).

o There are normative references to experimental RFCs (1183, 2673) that
  are probably really informative references.

-Peter