Re: AXFR "clarify"

[Brian Dickson <briand@ca.afilias.info>]

Wouter Wijngaards wrote:
> Hi,
>
> As an implementor of AXFR nameservers, I think it's fine to completely
> specify the AXFR (and or IXFR) protocol element.
In case it wasn't clear from my earlier comments in the thread:
+1 from me, too.
> I like the idea (from Mark) to clean up the header specification for
> followup messages, and implementations can then conform to that on the
> sending side. Things like ID bits, flags. On the reading side those are
> still not trustworthy.
Also +1.

I think this helps provide context to where the need is strongest.

The most important issue is what the sender (of an AXFR) does,
or more specifically, that this be very clearly specified.

What the receiver does with an AXFR or IXFR is less important,
*except* in the case where the receiver is also a sender.
> About case preservation.
[snip]
> We choose to completely remove case (downcase), for ease and simplicity of
> implementation. Storing the case-preserved names would mean double the
> memory use for the names.

Correct me if I'm wrong, but the latest version of NSD only supports IXFR
as a receiver, not as a sender, correct? (For AXFR it supports both.)

As for storing case:
There are certainly implementation tricks that can reduce the impact of 
being able
to reconstitute case sensitivity for doing AXFR.

Those are generally space/time trade-offs: more computation needs to be 
done, but
less memory gets used.

For example:
Track the case *changes* that occur, using one bit per byte. Store the 
modified value,
and store a one-bit value in a bit vector indicating whether the case 
was changed.

This allows reasonably efficient storage and reasonably fast 
reconstitution of case.

E.g. : "AbcDefgH" -> "abcdefgh",  plus 0b10010001 (0x91) as an unsigned 
char.
Have a fixed 256-element array of 8-byte strings, representing the 
corresponding
byte values to "OR" in (or XOR, whatever your preference is), to avoid 
the binary
arithmetic on reconstitution. Do a string-wise OR (or XOR) between the 
value stored,
"abcdefgh", and the array element at subscript 0x91, 0x3000003000000030 
(I think!).

The only times the bit vector would be used would be at AXFR or IXFR 
time, sending
and receiving of either.

This is not performance impacting to the main lookup threads, answering 
normal queries.
The memory footprint cost is 1/8th, 12.5%, much better than double.

Thoughts?

Brian Dickson



--
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/>