Re: draft-ietf-dnsext-unknown-rrs-04.txt

[Paul Vixie <paul@vix.com>]

> Seems like the WG needs to figure out whether they want to allow or
> prohibit compression in SIG and NXT.

there are two cases, which might be different.  one case is when dnssec
is signalled by a requestor, causing a responder to add SIG and NXT RR's
to the response to prove the validity of the answer.  the other case is
when a normal query (including zone transfers) are used, targetting or
including SIG and NXT RR's.

in the first case, compression could be used, since there is no reason
to believe that the requestor will not understand compression.  dnssec
signalling is a hop by hop affair, based on EDNS0 and new flag bits.  we
are going to change the flag bits or even type codes to ensure that the
2065 or 2535 implementations will not be confused by new things like DS.

in the second case, compression must not be used, since there is every
reason to believe that the requestor will not know the details of the
RDATA layout of these record types, and they need to be able to handle
them as opaque data, including storing zones on disk, caching and reusing
the data in responding to recursive queries, and so on.

the question is, whether compression of the names buys us enough octets
to pay for the complexity of a strategy like "you can use compression if
using this data in an EDNS0-signalled proof, but not in response to a
normal query or transfer".  my own thinking on this is, "not."  that's
because the names aren't always going to have similarities with other
names in the same message (making compression nonbneficial), and also
even a successful compression delta will be dwarfed by the size of the
signature and key data (making compression irrelevant overall).

> And the WG might also want to figure out how to avoid having the AD be
> the only one that reads the documents for consistency :-)/2

one of the things which has characterized the long continuing failure of
dnssec as a standard is a lack of openness.  people mostly won't read
drafts if they believe that they're being written in a star chamber anyway.

that said, i apologize as an individual for humming in the positive on
this draft, without having checked it for consistency.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>