Subject: Re: rfc2538bis IANA considerations

From: Samuel Weiler <[email-masked]>
Date: Mon, 23 May 2005 18:12:16 -0400 (EDT)

> I'm not entirely certain the IANA part is closed by
> this; Sam, can you confirm one way or the other?

The new text resolves one issue (cleaning up the documentation), but
still leaves the below questions unanswered.  Unless the WG breaks its
resounding silence on them, I propose that we pretend to be ostriches,
stick our heads in the sand, and leave this for another generation to
sort out.

-- Sam

On Tue, 22 Mar 2005, Samuel Weiler wrote:

> I think there are two remaining open questions related to the CERT RR
> and the DNSSEC algorithm number registry.  Any input?  Do we want to
> allow CERT RRs to contain ALL algorithm types specified in this
> registry, or do we want to add another applicability list?
>
> > > -- Can CERTs use private algorithms (type 253/254)?  If so, do you
> > >    still want to use the same encoding as for KEY/DNSKEY, with the
> > >    algorithm in the RDATA?  Some explicit mention of the private
> > >    algorithms might be a good idea, in any case.  Also note David
> > >    Blacka's DNSSEC experiment draft, which encourages use of
> > >    the private algorithms.
> >
> > I have no idea how to address this, nor can I answer the question.  I
> > hope that others will give input on this.
> >
> > > -- Given that 3755 added applicablility columns to the algorithm
> > >    registry (see the registry itself and 3755 for details), do you
> > >    want another column for CERT, along with a requirement that new
> > >    algorithm definitions say whether they can be used for CERTs or
> > >    not?
> >
> > It seem to require some work for new algorithm definers.  My
> > experience is that the key tag and algorithm fields of CERT RRs are
> > rarely useful, nor consistently populated.  So the additional work
> > will lead to little practical advantage, in my opinion.  That would
> > suggest we shouldn't worry about this.
> >
> > However, this seem to be more of a process issue, than a technical
> > concern, so I'd be interested to hear what others feel.

--
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, 24 May 2005 00:26:58 +0200

> stick our heads in the sand, and leave this for another generation to

That would work for me.

My impression is that these parts have little practical purpose today
anyway.

I have submitted the draft, if there are further comments about this
from the WG, I can update it.

Thanks,
Simon

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 24 May 2005 16:53:42 +0200

My 0.02 Euro:

If we can identify cases where the algorithm number match between
KEY/DNSKEY/CERT _will_ lead to (interoperability) problems we should
make sure we address those problems. If the match _might_ lead to
problems --- and nobody really knows how to catch that in text that would
fit into the draft --- then I'd say lets get this beast moving.

--Olaf

-- 

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 May 2005 17:15:37 +0200

My input on this would be that none of my uses of CERT pay much
attention to the algorithm number field (nor the key tag) anyway.  So
from my point of view, I cannot identify any scenario where this will
matter.

Input from others appreciated.

Thanks,
Simon