Subject: Re: DNSEXT WGLC: RFC2929bis

From: Peter Koch <[email-masked]>
Date: Wed, 1 Nov 2006 19:48:17 +0100

On Wed, Jul 19, 2006 I wrote:

> as agreed upon in Montreal I'd like to re-insert my comments expressed in
> <http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00936.html>
> into the WGLC. Modulo those I support this document.

I'd like to add one issue that came up during the work on NSEC3 (so credit
is really due to the nsec3 draft authors, but I'll take the blame):

{warning: the following text may contain adult protocol matter, reader
 descretion is advised.}

While both 1034 and 1035 currently say that the mnemonics for CLASS and TYPE
have to be disjoint, there is no guidance what character set (see warning
above) they ought to use.  Traditionally, it has been [A-Z0-9] with the
only exception being "-" in the now deprecated NSAP-PTR. Can we just hardcode
this, please?

-Peter

--
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: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 1 Nov 2006 15:15:39 -0500

Sounds like a reasonable idea to me as regards character set.
	Does 2929bis need to say something about who specifies the
mnemonic? Presumably the mnemonic should be included in the Standards
Action RFC for RR Types allocated that way, perhaps there should be a
"Suggested mnemonic (optional):" entry on the template, and the
Designated Expert would get to specify if they didn't like one provided
by the applicant...

Donald 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Peter Koch
Sent: Wednesday, November 01, 2006 1:48 PM
To: IETF DNSEXT WG
Subject: Re: DNSEXT WGLC: RFC2929bis

On Wed, Jul 19, 2006 I wrote:

> as agreed upon in Montreal I'd like to re-insert my comments expressed

> in 
> <http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00936.htm
> l> into the WGLC. Modulo those I support this document.

I'd like to add one issue that came up during the work on NSEC3 (so
credit is really due to the nsec3 draft authors, but I'll take the
blame):

While both 1034 and 1035 currently say that the mnemonics for CLASS and
TYPE have to be disjoint, there is no guidance what character set (see
warning
above) they ought to use.  Traditionally, it has been [A-Z0-9] with the
only exception being "-" in the now deprecated NSAP-PTR. Can we just
hardcode this, please?

-Peter

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Nov 2006 09:46:11 +0100

> only exception being "-" in the now deprecated NSAP-PTR. Can we just hardcode

I suggest adding a requirement that class mnemonics MUST NOT consists
only of [0-9] characters.  How about adding this to section 3.2?

  New class mnemonics MUST consist of only ASCII characters 'A'...'Z',
  '0'...'9'.  Class mnemonics MUST contain at least one character from
  the set 'A'...'Z'.

And similarly to section 3.1:

  New type mnemonics MUST consist of only ASCII characters 'A'...'Z',
  '0'...'9'.  Type mnemonics MUST contain at least one character from
  the set 'A'...'Z'.

Maybe it makes sense to have even harder requirements, e.g., that
mnemonics MUST start with [A-Z] to simplify master file parsers?

/Simon

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 2 Nov 2006 12:09:06 -0500

I believe that "-" should also be allowed. Requiring that mnemonics
start with a letter is reasonable to simplify parsing.

Donald 

-----Original Message-----
From: Simon Josefsson [mailto:[email-masked]] 
Sent: Thursday, November 02, 2006 3:46 AM
To: Peter Koch; Eastlake III Donald-LDE008
Cc: IETF DNSEXT WG
Subject: Re: DNSEXT WGLC: RFC2929bis

Peter Koch <[email-masked]> writes:

> While both 1034 and 1035 currently say that the mnemonics for CLASS 
> and TYPE have to be disjoint, there is no guidance what character set 
> (see warning
> above) they ought to use.  Traditionally, it has been [A-Z0-9] with 
> the only exception being "-" in the now deprecated NSAP-PTR. Can we 
> just hardcode this, please?

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Nov 2006 20:12:16 +0100

I don't see any additional parser difficulty by allowing '-' in
type/classes, so I'd agree.

Another worry is classes/types that are interchangeable with the TTL
time syntax that some implementations support.  Consider a class
mnemonic 1H23M, how should the following be parsed?

www.example.org.  1H23M A 1.2.3.4

Does 1H23M refer to a TTL value, or a class?

We can solve this by requiring that type/classes begin with letters.

I suggest adding this to 3.2:

   Class mnemonics MUST consist of only ASCII characters 'A'...'Z',
   '-', '0'...'9' and the initial character of the mnemonic MUST be
   from the set 'A'...'Z'.

And this to 3.1:

   Type mnemonics MUST consist of only ASCII characters 'A'...'Z',
   '-', '0'...'9' and the initial character of the mnemonic MUST be
   from the set 'A'...'Z'.

/Simon

---

From: Peter Koch <[email-masked]>
Date: Fri, 3 Nov 2006 09:42:09 +0100

> type/classes, so I'd agree.

there is an implementation convention reason to avoid '-', but I'll leave
that to the perl hackers. Also, there is no need to stick with LDH.

> Does 1H23M refer to a TTL value, or a class?

Since TTLs are defined to be represented as integers, it must be a class
value. I do not see a good reason to change the TTL format to deal with
something that should never have been more than an application option for
influencing the presentation of the TTL.

> We can solve this by requiring that type/classes begin with letters.

Still that's reasonable.

-Peter