Re: nsec++

[Paul Vixie <vixie@vix.com>]

> <chair hat off> This algorithm only optimizes for space, it has serious
> penalty for searching now I add every 64=B4th type and you need to search
> linearly through 1024 blocs as you do not know before hand the size of
> any block.  Is this tradeoff worth it?

when i participated in the discussions with michael graff that led to his
draft on this topic, these other alternatives were considered and dropped.
i now realize that it was foolish of us to not document the roads untaken.

> <chair hat on> Is this whole thread worth the effort when we have many
> more pressing issues like comment on the protocol document, check if the
> protocol documents reflect all the documents they are obsoleting/updating
> correctly ?

the community now embodied by DNSEXT (but previously DNSIND et al) has a
rather poor record when it comes to measuring importance.  18 months ago we
made the decision not to complicate the NXT format with support for n>128
type codes since it would delay deployment.  16 months later we decided
that it wasn't reasonable to go to proposed standard without that support.

let's do this:  let the debate rage on.  let the people who are interested
in this topic discuss it.  let the draft author judge consensus for now.
when it's time to roll out the next -bis docset then the then-current draft
will be frozen and incorporated.

let's not do this:  let leadership mean deciding what (not) to discuss.
-- 
Paul Vixie

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