Subject: RE: draft-dunlap-dns-duxfr-00.txt

From: "James Gilroy (Exchange)" <[email-masked]>
Date: Wed, 29 Sep 1999 16:40:06 -0700

I've got a modest suggestion.

Instead of a completely new mechanism, perhaps Masataka could simply add to
his RFC the ability to do RR set and name deletes.   It's the need to keep
the full change history that make the implementation of IXFR unnecessrily
complicated.   It's also what keeps the mapping with dynamic-update from
being straightforward.

If I could specify the full delete of an RR set
foo.bar A  class=NONE
or name
foo.bar ANY class=NONE

then I need no longer keep a complete change history.  I need only know that
an RR set has changed at some given serial number, and have current data
available.

Example:
version 1
foo.bar A	1.1.1.1
foo.bar A	2.2.2.2
takes an update add -- 3.3.3.3
foo.bar A   1.1.1.1
foo.bar A   2.2.2.2
foo.bar A   3.3.3.3
takes an update delete -- 1.1.1.1
foo.bar A	2.2.2.2
foo.bar A	3.3.3.3
takes another update delete -- 2.2.2.2
foo.bar A	3.3.3.3

Instead of having to save and send deleted and added records, if I can just
send

foo.bar A  NONE
foo.bar A  3.3.3.3
 
my implementation is much cleaner (I can probably toss several hundred lines
of code myself) and in general more compact on the wire.

	jim

-----Original Message-----
From: Masataka Ohta [mailto:[email-masked]]
Sent: Wednesday, September 29, 1999 2:46 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: draft-dunlap-dns-duxfr-00.txt

Rob;

> Paul, Kevin,
> 
> In the introduction to draft-dunlap-dns-duxfr-00.txt you say:
> 
>    The simple method described for Incremental transfer (IXFR), in
>    [RFC1995], does not adequately address the complexity of the problem.
> 
> but do not further explain the motivation for DUXFR.  Perhaps I was
> drinking decaf this morning by mistake, but the complexity you're
> attempting to deal with is not immediately obvious.

The simple (?) method described for duxfr does not adequately
address the optional complexity of the problem to enable UDP
transfer.

> Care to elaborate?

It seems to me that the simple description style of duxfr is a
copy of ixfr, for which I should be proud of.

Can't Paul and Kevin elaborate to update the style of RFC2136,
instead?

						Masataka Ohta

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 29 Sep 1999 17:21:46 -0700

> [...]   It's also what keeps the mapping with dynamic-update from
> being straightforward.

right.  under DUXFR, the mapping from UPDATE to IXFR is done with memcpy().

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 30 Sep 99 10:06:41 JST

James;

> complicated.   It's also what keeps the mapping with dynamic-update from

It is a doable change and shrinks wire format a little in special cases.

However, why do you think the current IXFR specification make
the implementation unnecessarily complex?

With the current DDNS specificaiton, the implementation must
be unnecessrily complex and inefficient to perform wild card
matching to check all the possible RRs.

But, all that necessary to add IXFR is to record the change
at the place where actural RRs are added or deleted.

DDNS implementations have code to actually delete or add individual
RRs that the coding is straightforward. Right?

On the other hand, with the current IXFR, secondary servers do not
have to be unnecessrily complex and inefficient to perform wild
card matching to check all the possible RRs.

							Masataka Ohta