Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-04.txt

From: Peter Koch <[email-masked]>
Date: Tue, 06 Sep 2005 11:59:20 +0200

[minor issues, resent to the list since we're past WGLC]

Simon,

> http://josefsson.org/rfc2538bis/

two more issues:

> Following some of the guidelines below may result in the use in DNS names
> with characters that require DNS quoting, which is to use a backslash
> followed by the octal representation of the ASCII code for the character
> (e.g., \000 for NULL).

This has come up multiple times and I'm not sure about the right answer,
but section 5.1 of RFC 1035 claims that the values are decimal. Perhaps
here it's best to say "... require DNS quoting as per section 5.1 of RFC 1035"
which also covers the "\." case.

> Implementations SHOULD use the purpose-based owner name guidelines described
> in this document, and MAY use CNAMEs of content-based owner names (or other
> names), pointing to the purpose-based owner name.

change to "... use CNAME RRs at ..." since the "CNAMEs of ... owner names"
are already what's in the RDATA section, i.e. "the CNAME" is the target, not
the owner.

-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: Simon Josefsson <[email-masked]>
Date: Tue, 06 Sep 2005 13:03:31 +0200

Thanks, Peter.  I have incorporated both of these in the upcoming -05.

Regards,
Simon

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 7 Sep 2005 18:48:07 +0200

Simon,

> I added:
>
> Note that two different keys may have the same key tag.
>
> If you need more text, please suggest it.

That's enough, I think.

> > Besides: What about using RFC2606 domains instead of the existing
> > john-doe.com?
> > * Section 3.1, 2nd example: I suggest using RFC3330 IP addresses for
> > examples (192.0.2.0/24)
>
> I recall that Olaf specified in the document write-up that we decided
> to not do this, to preserve similarity with RFC 2538.

Fine by me

> > Besides: What about including a preference in the order of
> > appearance (simmilar to the order in section 3.1)? Like for
> > instance, first looking for the fingerprint and then for the key ID.
>
> I'm not sure about this.  I don't think it is useful.  My
> implementations do both fingerprint and key ID lookups, but the
> priority order is per-application.

I still think that a guideline could be useful, for different 
implementations could lead to different results in case there were one 
CERT under the fingerprint AND a different one under the key ID. I admit 
this is a very artificial argument. Since I don't have any strong feelings 
on this and in the light of the potential need for a new LC, we just can 
leave it as it is.

Regards,
Marcos

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 Sep 2005 15:07:39 +0200

> on this and in the light of the potential need for a new LC, we just can 

I'm not sure it is as problematic as you describe, every
application/implementation that uses CERT RRs will need to make an
implicit profile of the document by using one of the owner name
standards.  However, let suppose we want to address this.  What would
the preference order be?  Some applications only has the 4 octet key
id, some has the 8 octet key id, and some will have the full 16/20
octet fingerprint.  Applications can remove digits, but not add them,
so the only generally possible approach that would work for all
implementations would be 4 octet key ids.  But that create complexity
to handle the case of collisions; some applications may not want to
bother with that extra complexity, but would rather see that the
recommendation was for full fingerprints.

All in all, I think the document shouldn't go into more detail about
this.  I believe it is better to let applications profile this
document to require a particular owner name guideline instead, if
there really is a need.

Thanks,
Simon