Subject: (Almost final) Agenda for dnsind/dnssec in Oslo

From: Robert Elz <[email-masked]>
Date: Sun, 27 Jun 1999 01:29:54 +1000

If there are any more requests related to this agenda, you will need to
send them soon - the agenda needs to be at the secretariat by
Thursday (after which I will be out of e-mail contact for almost a
week - and for this I mean Thursday Australian time, not US).

For anyone who won't be in Oslo, feel free to begin (or continue)
discussions on any of these issues on the list.

The dns* meeting is scheduelled for Monday July 12, 15:30, in the Kunst
room (but don't believe the room until you get to Oslo and see it
confirmed there).

If I have listed your name beside a topic below, them I am expecting you to
lead the discussion.   If you're unable, please let me know soon (and if
you can suggest a proxy, please do).

Please don't bring a prepared presentation - or at most no more than one or two
slides (max of *one* for a 5 minute slot), for any of these.  We have a very
full workload, and no time to go through what is in drafts for the benefit
of those who have not read them.   Where no name is listed, Randy, Jim Galvin,
or I (or some combination thereof) will be looking after it.

As listed below, the 2 hour slot is fully allocated, though it is possible
that one or two of the items below might be relegated to the list.

To all - expect the time limits below to be rigorously enforced.   Please
assist by making as many comments as you can via e-mail in advance of
the meeting.   The meeting *will* start on time!

1. Administrativia, agenda bashing, etc				(3 minutes)

2. Review of current PS RFCs and progress on advancing them. 	(5 minutes)

	rfc1982 rfc1995 rfc1996 rfc2136 rfc2137 rfc2181
	rfc2308 rfc2535 rfc2536 rfc2537 rfc2538 rfc2539

3. Updating status on all known dns* drafts			(15 minutes)

	The idea here is that we go through everything which seems to
	be on the dns* plate, and determine just what we're really
	working on, what the priority for eevrything is, when we expect to
	complete each doc, and what status we currently expect they will have.

4. Attempting to resolve rfc2052bis.				(15 minutes)

	<draft-ietf-dnsind-rfc2052bis-02.txt>

	The IESG rejected rfc2052bis, and requested several changes.
	So far, we haven't been able to agree on exactly what to do.
	One option is to defer this indefinitely, or even drop it
	(simply leave 2052 as the experimental protocol as it is).
	Otherwise we need to find some way to satisfy the IESG demands
	if we ever expect tos ee this one become a RFC.

5. EDNS1			(10 minutes)		Paul Vixie

	<draft-ietf-dnsind-edns1-03.txt>

	This draft is currently an ongoing work item.	Please be
	prepared to (briefly) suggest improvements, and/or where it
	should go next.

Securing the DNS ...

6. TKey				(5 minutes)		Don Eastlake

	<draft-ietf-dnssec-tkey-01.txt>

	Now tsig is (apparently) done, it makes sense to get tkey
	out there following it asap, if it is ever going to.

7. Simple Secure Update		(10 minutes)		Brian Wellington
	<draft-ietf-dnsind-simple-secure-update-00.txt>

	This shows how to secure dns dynamic update using tsig.
	How close are we to being finished with this draft?
	(the -00 is misleading, it moved from dnssec)

8. DNSSEC update (update2)	(10 minutes)		Don Eastlake
	<draft-ietf-dnssec-update2-00.txt>   (or later draft if it appears)

	The alternative (original) way of securing DNS updates.
	This is an intended replacement for rfc2137. 

9. GSS Tsig			(5 minutes)		Stuart Kwan
	<draft-skwan-gss-tsig-04.txt>

	An alternate algorithm for tsig.

10. Security Key Rollover	(5 minutes)		Don Eastlake
	<draft-ietf-dnsind-rollover-00.txt>

	Dealing with key time rollover (since the time is imbedded
	in a fixed width field, it has to rollover sometime - this
	draft specifies how that works).

New Resource Records...

11. SECure-RR			(5 minutes)		Edward Lewis
	<draft-ietf-dnsind-sec-rr-00.txt>

	This general topic has changed names several times (the dnsind
	appellation is new, hence the -00).

12. Kitchen Sink RR		(5 minutes)		Don Eastlake
	<draft-ietf-dnsind-kitchen-sink-00.txt>

	This has also changed names, it has been floating for ages.

13. Address Prefix List RR	(5 minutes)		Peter Koch
	<draft-ietf-dnsind-apl-rr-02.txt>

Extended functionality...

14. Internationalising DNS Names (5 minutes)		Stuart Kwan
	<draft-skwan-utf8-dns-02.txt>

15. Deferred Dynamic Delete	(5 minutes)		Brian Wellington
	<draft-ietf-dnsind-dddd-01.txt>

16. Verifying Resource Records	(5 minutes)		Mark Andrews
	<draft-ietf-dnsind-verify-00.txt>

17. Local Names			(5 minutes)		Don Eastlake
	<draft-ietf-dnsind-local-names-07.txt>

Reading list:

Note that a few of the drafts listed below are not yet available in
the I-D directories (these URLs will not yet work).   They should be
available by the time the backlog of last minute drafts has drained.

For access via HTTP:

http://www.ietf.org/internet-drafts/draft-ietf-dnsind-apl-rr-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-dddd-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-edns1-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-kitchen-sink-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-local-names-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-rfc2052bis-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-rollover-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-sec-rr-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-simple-secure-update-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-verify-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnssec-tkey-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnssec-update2-00.txt
http://www.ietf.org/internet-drafts/draft-skwan-gss-tsig-04.txt
http://www.ietf.org/internet-drafts/draft-skwan-utf8-dns-02.txt

(or) for access via FTP:

ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-apl-rr-02.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-dddd-01.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-edns1-03.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-kitchen-sink-00.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-local-names-07.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-rfc2052bis-02.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-rollover-00.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-sec-rr-00.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-simple-secure-update-00.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsind-verify-00.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-tkey-01.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-update2-00.txt
ftp://ftp.ietf.org/internet-drafts/draft-skwan-gss-tsig-04.txt
ftp://ftp.ietf.org/internet-drafts/draft-skwan-utf8-dns-02.txt

---

From: Paul A Vixie <[email-masked]>
Date: Sat, 26 Jun 1999 12:11:04 -0700

> discussions on any of these issues on the list.

i, for example, will not be in oslo this year.

> 	if we ever expect tos ee this one become a RFC.

as microsoft has implemented rfc2052bis rather than rfc2052, we would need at
a minimum to reissue rfc2052bis as an experimental.  or a bcp, since it's in
win2k and no other SRV usage is extant in the field.

> 	prepared to (briefly) suggest improvements, and/or where it

since i won't be in oslo, any edns1 comments will come to me via the list,
either by direct comment or from the oslo notes being posted here.

> 	An alternate algorithm for tsig.

"additional" not "alternate".  tsig specifies a base protocol and an initial
algorithm (hmac-md5).  gss-tsig is just another algorithm, not an alternative
to the protocol.

> 	appellation is new, hence the -00).

i very much hope that john gilmore will be at the oslo meeting to defend his
point of view (that we can't deploy a new RR at this time if we're expecting
to use dnssec widely this year.)

> 	<draft-skwan-utf8-dns-02.txt>

there is also a UTF-5 proposal -- hopefully its proponent will be in oslo to
explain why it's a viable alternative to stuart's utf-8 proposal.

> available by the time the backlog of last minute drafts has drained.

and updated versions of ISC's drafts are always at http://www.vix.com/ietf/.

---

From: [email-masked]
Date: Sun, 27 Jun 1999 10:25:49 +1000

> 	<draft-ietf-dnsind-verify-00.txt>
	I won't be at Oslo either, impending fatherhood.  This needs to be
	looked at along with draft-ietf-dnsind-local-compression-04.txt as
	they are alternatives to the same problem.

	The major problem with local-compression is once it is used you
	have to use it for all time for that RR as it is the compressed
	form that is signed not the uncompressed.

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

---

From: Brian Wellington <[email-masked]>
Date: Sat, 26 Jun 1999 21:48:20 -0400 (EDT)

> discussions on any of these issues on the list.

I won't be in Oslo either.

> you can suggest a proxy, please do).

Ed Lewis should be able to talk about simple secure update and deferred
delete.

> 	(the -00 is misleading, it moved from dnssec)

Based on feedback from the last IETF and various discussions recently, I
modified the draft to allow updates to be signed by DNSSEC SIG(0)
transaction signatures as well as TSIG records.  This doesn't change the
fundamental nature of the draft, and should make it more acceptable, since
it doesn't have the scaling problems associated with TSIG manual
configuration.  -01 was submitted Friday at about 11AM EDT, so it should
be announced soon (if it hasn't been announced already).

dnssec-simple-update-01 and dnsind-simple-secure-update-00 were identical,
so the numbering is only one off...

> 	<draft-ietf-dnsind-dddd-01.txt>

The only major change since -00 is that the TTL modification policy has
been changed from reuired to optional, and several vague sections were
cleaned up.  There have been no changes or comments since -01 was written
in mid April.

If there are any comments, I'll try to address them here.

Brian

---

From: Robert Elz <[email-masked]>
Date: Mon, 28 Jun 1999 01:02:54 +1000

Date:        Sat, 26 Jun 1999 12:11:04 -0700
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | we would need at a minimum to reissue rfc2052bis as an experimental.

That is certainly an option.

  | or a bcp, since it's in
  | win2k and no other SRV usage is extant in the field.

I think PS would raise less obstacles than BCP...

  | "additional" not "alternate".  tsig specifies a base protocol and an
  | initial algorithm (hmac-md5).  gss-tsig is just another algorithm, not
  | an alternative to the protocol.

Unfortunate choice of words on my part ... that's exactly what I meant,
an alternative for the application to choose, not an alternative to the
protocol.

  | there is also a UTF-5 proposal -- hopefully its proponent will be in oslo to
  | explain why it's a viable alternative to stuart's utf-8 proposal.

I have not seen that one.   Do you have a reference?

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 28 Jun 1999 01:21:00 +1000

Date:        Sun, 27 Jun 1999 10:25:49 +1000
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | > 16. Verifying Resource Records	(5 minutes)		Mark Andrews
  | > 	<draft-ietf-dnsind-verify-00.txt>
  | > 
  | 	I won't be at Oslo either, impending fatherhood.  This needs to be
  | 	looked at along with draft-ietf-dnsind-local-compression-04.txt as
  | 	they are alternatives to the same problem.

OK.   And thanks for the reminder, somehow I had managed to omit
local-compression from the agenda...   It is there now, to be considered
along with verify (in a longer slot for the two of them, using time
taken from the edns1 slot, as it doesn't appear there will be as much
discussion of that one as I had anticipated there might be).

  | 	The major problem with local-compression is once it is used you
  | 	have to use it for all time for that RR as it is the compressed
  | 	form that is signed not the uncompressed.

Would you like to expand upon this a little please?

While I certainly understand that a server for a signed zone will always
return the same data, and in this case, that means the same format as
well, but I'm not sure how that extends to "all time".   Maybe I'm missing
something, I'm certainly no dnssec expert, or even competent, but I would
have thought that when the zone is re-signed, nothing that had been there
before would matter too much - that is, if the server is upgraded such that
it now supports some new functionality, and then the zone is re-signed, could
not the RR that was using local-compression (in this particular zone) now
switch to something different?

I would have also assumed (perhaps totally incorrectly) that it would be
possible for the server to keep two signed representations of the RR, and
simply emit whichever one best met the needs of the resolver making the
query, if that seemed to be a good thing to do.

kre

---

From: [email-masked]
Date: Mon, 28 Jun 1999 11:59:48 +1000

> switch to something different?

	No, as global compression *may* cause case conversion, we
	can't use EDNS to say we know about this RR and hence use
	global compression unless we also state that all domain
	names in RRs that are to be locally compressed MUST be down
	cased.  Also there is no definition of exactly how to arrive
	at the same bit patten given that you can have a LCP (local
	compression pointer) -> LCP -> label.  Also there are cases
	where using a LCP will make the resulting wire form larger
	than the uncompressed form, do we use LC or not?

> query, if that seemed to be a good thing to do.

	You would have to emit both as in intermediate client (forwarder
	chain) may require the compressed signature where the current client
	needs the uncompressed one.  This assumes both will get sent on
	and the one that didn't verify was not discarded.

	Mark

---

From: John Gilmore <[email-masked]>
Date: Mon, 28 Jun 1999 01:49:48 -0700

> to use dnssec widely this year.)

I won't be in Oslo, unfortunately.  Hugh Daniel will be there, but
he doesn't have the history.

Deploying an RR type that only exists in superzones is not quite as
bad as deploying one that exists everywhere.  The number of superzones
is smaller than the number of zones, and the most critical superzones
(. and .com and etc) are running on machines that "nominally" always
upgrade to the latest BIND anyway, so they'll be able to serve new RR
types.

Having scanned the draft once:

Summary: REJECT WITH PREJUDICE.  Poorly defined, unnecessarily complex,
doesn't solve the problem it claims to, doesn't even address the
real problems of DNSSEC.

The biggest problem with DNSSEC appears to be paper designs that do
not benefit from operational evolution.  In other words, DNSSEC is not
going through the winning part of the IETF process (draft, implement,
try, redraft, implement, try, ... standardize).  Instead we go through
a series of paper specs trying to standardize them with no operational
experience.  Note I said operational, not programming.

I suggest that we operate with the specs we have and learn from 'em.
THEN change 'em.

This paper design continues many of the problems of prior DNSSEC
drafts; it lays out grand schemes without considering the operational
details.  The open-ended "Security parameters of a zone" is one
example (including things like "Signature policy.  This is an untested
issue.").

The draft goes to even more ridiculous lengths than NXT to secure
negative answers.  (NXT more than doubles the size of your zone, to
give definitive "NO"s for names that aren't in the zone.)  In addition
to NXT, we now have a bitmap in the parent zone (!!!) that gives five
options on how the child zone might handle negative answers.  These
options can be used in combination.  (At least if the WG thinks this
level of abomination is needed, it should be expressed in the child
zone rather than in the parent.  Such a record in the child would be
signed by the zone key, so it can't be spoofed.  Though I suppose its
*absence* could be spoofed, hmm...)

Then we get to the meat.  The SEC record doesn't really have fields
that specify security parameters.  Instead it holds little
sub-packets, each of which has to be parsed, each of which specifies
security parameters.  These sub-packets have option specifier bytes,
optional lengths, and data.  The length of most of the options is
defined in the spec, so that when new options are added, all existing
implementations will be unable to parse them.  The draft specifies
various combinations of options that are not permitted together.  I
don't see why we don't just go straight to X.509 and ASN.1 instead --
it's simpler and easier.

The text file format is highly readable, consisting of a series of hex
numbers.  (At least the numbers are in hex; the DNSSEC KEY record has
bit-flags expressed in decimal.)  The parsing of the hex is screwy;
some fields have 0x, some do not, and this difference appears to have
some meaning, though it's not clear what meaning.

The draft claims it's a successor to Zone Key Referral by me and Jerry
Scharf.  Did I really do that?   It doesn't actually include the name of
the Zone Key Referral draft, but elsewhere it says it's "by the same
authors" (as itself, presumably).

	John

---

From: Edward Lewis <[email-masked]>
Date: Mon, 28 Jun 1999 07:11:03 -0400

>doesn't solve the problem it claims to, doesn't even address the

Hey - it's a -00.  I'd like to hear comments from operators, but there
aren't many yet.

One question - is the problem statement right?  I'd like to at least get
that straightened up before trying to solve the wrong problem.

>authors" (as itself, presumably).

I figured that the SEC RR might not be a cure all, but I wanted to describe
the idea in detail.  By linking the two drafts, I was trying to save folks
time if they planned to read both - I copied vast amounts of text in the
introduction from Referral to SEC.  However, I wasn't confident that the
SEC RR would fly far, so I also kept the names separate.

As far as putting planning ahead of implementation, the excuse is that
"isn't getting something secure" a bit different that "getting something to
work?"  (I'll leave the question as that for now.)

One reason there's a lot of planning smoke around even without much
operational fire is the need to secure dynamic update.  There are still
issues there.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 28 Jun 1999 14:47:46 +0200

>work?"  (I'll leave the question as that for now.)

actually I think not - "secure" can never mean more than "secure against a 
certain class of attacks".
So you can see the "working" here as "a particular attack fails".
There are ALWAYS other attack paths.

                         Harald A

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 28 Jun 1999 10:08:28 -0500

> win2k and no other SRV usage is extant in the field.

There are some (non-MS) Kerberos 5 implementations that use
2052bis -- NOT 2052 -- style lookups to locate the KDCs for
a realm. 
				Matt

---

From: Greg Hudson <[email-masked]>
Date: Mon, 28 Jun 1999 11:46:18 EDT

> [Criticism of encoding in SEC RR]
> I don't see why we don't just go straight to X.509 and ASN.1 instead
> -- it's simpler and easier.

If anyone is considering using an externally specified encoding
schemes in drafts (this one or others), I'd appreciate it if they
could consider simpler alternatives to ASN.1/BER.

My own simpler alternative is SPADE:

	http://www.ietf.org/internet-drafts/draft-hudson-spade-01.txt

And there's also XDR (RFC 1832), which is perfectly capable of
standing apart from sunrpc.  (I'm deliberately omitting XML here; I
don't think it's simpler than ASN.1 and I doubt anyone would propose
using such a verbose encoding for DNS.)

I realize that the phrase "X.509 and ASN.1" covers directory stuff as
well as data encoding, so XDR or SPADE would only do half of what John
was talking about.  But a full-fledged directory may not be necessary
here.

Anyway, apologies for the digression.  The IETF doesn't have a working
group or other forum to discuss encodings (as far as I know), so I
kind of have to pipe up whenever I see the topic come up in a working
group list I follow.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 28 Jun 1999 13:14:41 -0400

I wasn't proposing anything like ASN.1 - more like DHCP (or the OPT RR)
options.

---

From: [email-masked] (Alexander Krotov)
Date: Tue, 29 Jun 1999 13:52:24 +0300 (EEST)

Hello!

Please forgive me my ignorance.
But I cannot fetch following drafts:

> http://www.ietf.org/internet-drafts/draft-ietf-dnsind-apl-rr-02.txt
....
> http://www.ietf.org/internet-drafts/draft-ietf-dnsind-local-names-07.txt
...

Any ideas ?

-- 
Alexander Krotov	gsm: +358 40-725 7216
Product Developer	fax: +358 9-8599 0599
NameSurfer Ltd.		http://www.namesurfer.com

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 29 Jun 1999 13:33:59 -0400

If they haven't made it into the ID directories yet, you can get my
drafts from
ftp://ftp.pothole.com/pub/dee3/draft-ietf-dnsind-kitchen-sink-00.txt and
ftp://ftp.pothole.com/pub/dee3/draft-ietf-dnsind-local-names-07.txt

Donald

From:  [email-masked] (Alexander Krotov)
Message-Id:  <[email-masked]>
In-Reply-To:  <[email-masked]> from Robert Elz at "Jun 27, 1999  1:29:5
4 am"
To:  [email-masked]
Date:  Tue, 29 Jun 1999 13:52:24 +0300 (EEST)

---

From: Robert Elz <[email-masked]>
Date: Wed, 30 Jun 1999 10:06:42 +1000

Date:        Tue, 29 Jun 1999 13:52:24 +0300 (EEST)
    From:        [email-masked] (Alexander Krotov)
    Message-ID:  <[email-masked]>

  | But I cannot fetch following drafts:

As I said in the agenda, some of the drafts have not yet made it through
the I-D processing queue yet.   The last days before an IETF deadlline they
get deluged with drafts (hundreds of them).   It typically takes more than
a week (after the deadline) to get the queue cleared.

I believe that all the drafts I listed have in fact been submitted, and
will appear before the meeting (and hopefully enough before it that
people will have an adequate chance to read them).

I see Donald has indicated from where you can fetch his two drafts now,
if Peter could give an indication where the apl-rr draft can be found,
and anyone any others that may not hey have been announced, that would
help everyone.

Beyond this IETF, I think we're going to give dnsind an earlier deadline
for drafts next time, and avoid this craziness.   This isn't urgent right
now, but I propose setting a 6 week cutoff - drafts for the 46th IETF will
need to be available for everyone to read 6 weeks in advance, so we can do
a better job or preparing the agenda, making sure we have the right kind of
timeslot(s) available (time in Oslo is going to be very precious), and
avoid this absurdity where we're hoping to be processing drafts that we
just believe are going to make it through processing in time.

kre

---

From: Peter Koch <[email-masked]>
Date: Wed, 30 Jun 1999 10:14:53 +0200

> and anyone any others that may not hey have been announced, that would

sorry, I didn't copy my answer to the list. The draft is available at

http://www.TechFak.Uni-Bielefeld.DE/~pk/dns/draft-ietf-dnsind-apl-rr-02.txt.gz

-Peter

---

From: Robert Elz <[email-masked]>
Date: Thu, 01 Jul 1999 01:34:59 +1000

Date:        Wed, 30 Jun 1999 08:24:33 -0700
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | the working group is the mailing list, not the meetings.

Yes, it is, but having all the drafts appear immediately before an IETF
meeting, when many people are likely to be attending, is even worse in
that case.    We need to start getting drafts pubished at some time other
than in the last week before an IETF deadline.

  | isc would be happy to host a dnsind draft repository and namedroppers
  | archive.

I believe there's already a namedroppers archive (having a mirror wouldn't
hurt).   A dnsind draft repository doesn't help, doesn't solve the problem,
and aside from having a place where the drafts can be made aailable in the
couple of days it (usually) takes between submission and their availability,
just adds to confusion - people would have two places they have to go and
look.

In any case, we can discuss this sometime after the Oslo meeting, when there
is a bit more time to think clearly.

kre

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 30 Jun 1999 08:24:33 -0700

> just believe are going to make it through processing in time.

this is just wrong.  the working group is the mailing list, not the meetings.

isc would be happy to host a dnsind draft repository and namedroppers archive.

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 30 Jun 1999 08:24:33 -0700

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Jun 1999 09:51:56 -0700 (PDT)

> than in the last week before an IETF deadline.

s/published/written and submitted/

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Jun 1999 09:59:14 -0700 (PDT)

> isc would be happy to host a dnsind draft repository and namedroppers

not clear to me how this would help as both exist already and seem to
function.

there is also a poorly-maintained archive which includes out of data drafts
for comparison, ftp://psg.com/pub/dnsind/

randy