Re: Zone Name Change Prototype

[Sari Harrison <[e-mail]>]

Tom Evans writes:
>I (now) notice that in the MIB this table is "optional", so I shouldn't be
>complaining. However this means that MS code writers will either have to
>write (and test) TWO sets of Router-finding-code, or will have not not
>use the table as they can't guarantee it will be there.

We were thinking more along the lines that there had to be at least one router 
on the network in question that supported the list. How this router is found 
is a good question, but possibly merely input by the network administrator.  
This does not preclude stations from finding the routers themselves if they 
are so inclined.  Incidentally, the coding was easy, but I understand your 
concerns about additional memory required.  You could always let the user 
decide whether or not they want it.  I included an overview of our scheme for 
perusal at the bottom of this message if anyone is interested.

As for zone name changing with IP, that is up to the MS developers, and no, 
the neighboring routers list doesn't help them.

>I gather the use of "optional" in official MIBs (as distinct from
>private ones) is "strongly frowned upon".
But not prohibited? :)

About the new zone list.  We put a zone index in there more for simplicity's 
sake than anything else.  I like it better, personally, so if we're voting...
I wasn't sure what you meant by having the two tables be exactly alike (apart 
from the indexing).  The only other difference is the status variable which 
the new zone list doesn't need.  Are you suggesting we add one anyway?  And 
yes, the newZoneName should be AtName (SIZE (1..32)).

Ciao,
Sari Harrison
Apple Computer, Inc.

Our Neighboring Routers List implementation overview:
We allocate one byte per potential router on the net for each AppleTalk port 
on the router.  This is 254 * number of nets in range.  Yes, this gets big if 
the range is large.  When an RTMP packet is received, we update the byte 
corresponding to the router's address to a state of "good".  This is a very 
small percentage of the work we do when we get an RTMP packet.  In addition, 
every 10 seconds (we could easily make this 20 or 30) we go through the whole 
structure decrementing the state of each that is not 0.  This scheme 
admittedley is not going to scale well to a network with a very large net 
range but should be reasonable in most scenarios.  The SNMP agent reports any 
routers with a state of "good" or "good-1".  In conclusion, we think it is a 
very viable scheme in most networks and if the network range is very large 
could be left to one router per network to be designated by the network 
administrator.