Subject: wildcard optimization - another topic

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Oct 2002 09:55:42 -0400

In the draft the no wildcard/possible wildcard information is encoded 
into the value of the SIG bit.  This mimics the choice in opt-in of 
using the NXT bit.

Two problems - the relationship between the NXT and opt-in is a bit 
(no pun intended) stronger than the SIG and wildcards.  Also, if we 
do this, we run out of "easily overloaded" bits in the type bit map.

The next proposal is to use the type bits for the "bogus" types.  I 
mean, what's the chance you'll see an MB record ever again?

Another choice is to create new bit values in the type bit map just 
for indicating "whatever."  There are a few consequences of this. 
One is that if the bit positions used are low in number (e.g., 49, 
50, etc.), then IANA had better be warned to never issue any type 
codes of that value.  (This is true of any number chosen.)  If the 
numbers chosen are higher, like around the metatypes (ANY), then bit 
0 has to be turned on - which says the bit map uses an alternate 
encoding for values over 128.

Then there is the option of scraping NXT and replacing it with a new 
record that has an explicit flags field before the type bit map.  Hey 
- it's an option.

It looks like there is a requirement that the NXT has flags, a 
requirement not known in the old days.  The question is: will we 
honor the requirement, and if so, will we settle for having the flags 
be intermixed with the type bit map, or do we set aside a separate 
location for them?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

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