Subject: RE: nsec++

From: Ólafur Guðmundsson<[email-masked]>
Date: Fri, 05 Dec 2003 11:36:55 -0500

At 05:45 2003-12-05, Andrew Draper wrote:

> >       In otherword start a new bitmap if you save more than the
> >       cost of introducing a new bitmap.
> >
> >       If the last two octets of the current map are zero it is
> >       a break even situation so you include the next 32 bit
> >       window in the current map.
>
>This is exactly the algorithm I was intending to describe, both with my 
>suggested set of MUSTs and with my pseudo-code.  Thanks for describing it 
>in an easier to understand way.
>
>     Andy
<chair hat off>

This algorithm only optimizes for space, it has serious penalty for
searching now I add every 64´th 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?

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

         Olafur

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: 05 Dec 2003 18:22:49 +0000

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 11 Dec 2003 16:21:07 +0100

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

Well eh... leadership... who me ?  ;-)

Given that I have not seen major support on the list in favour of
'more compression', few people worried about additional comlexity and
we really need to get this done I propose to keep the document with
the specification as is and go for last call early next week.

If you have editorial issues please mail them to Jakob ASAP, maybe 
we can do another document roll.

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC