Subject: WG last call: Local Compression

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 14 Oct 1999 12:36:46 -0400

As indicated in the minutes of the DNSIND meeting, the WG meeting 
in Oslo concluded that the "Local Compression" draft is ready for WG last 
call.

This is that WG last call. We will run it through October, deadline is
23:59:59 UTC October 31.  

The draft is: draft-ietf-dnsind-local-compression-05.txt

It is known that an "IANA Considerations" section will need to be added 
to the draft before it can proceed further, so there's no need to make 
that particular comment. 
It is also known that the References section is out of date, due to the
delay in issuing this Last Call. 

Please send other comments to the list.

Issues raised during this last call can be resolved in the working group
meeting in Washington. 

Anyone that has raised issues with this document in the past and feels the
issues have not been adequately addressed, repost the issues. 

This draft is targeted to become standards track, if you disagree with that
please state so during this last call. 

	Olafur 
----------------------------------------------------
Olafur Gudmundsson - NAI Labs 
the Security Research Division of Network Associates, Inc.
3060 Wasthington Road, Rt 97, Glenwood MD 21738
[email-masked]  [email-masked]
443-259-2389 
Private: [email-masked]

---

From: [email-masked]
Date: Fri, 15 Oct 1999 16:25:14 +1000

> issues have not been adequately addressed, repost the issues. 

	I still think that having two different type dependent
	mechanisms for getting records into cannonical form is
	not a good idea.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Oct 1999 11:30:57 -0400

>please state so during this last call.

Bottom line - I disagree with this going on the standards track.

My issue is "cost vs. benefit" of the suggestion.

Benefit - I don't think that the bytes saved via compression are
significant when compared to DNSSEC-enhanced responses.  With multiple keys
(multiple algorithms), I usually see 2000 bytes of response to even simple
queries, most of these bytes in the uncompressable key and signature fields.

Cost - building the code to do this and executing the code is not trivial.
Having written some DNSSEC processing code, having yet another compression
mechanism makes signing and verifying more of a problem.

Another question raised while reading the draft: If the canonical form for
signing is to use local compression, how will local compression DNSSEC
interoperate with older server/resolvers that do not do local compression?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

Opinions expressed are property of my evil twin, not my employer.