Re: Zone Name Change Prototype

[Tom Evans <[e-mail]>]

	Date:	23-Apr-93
	To:	Apple-IP Mailing List
	From:	Tom Evans
	Re:	Re: Zone Name Change Prototype
	Cc:	[e-mail]@munnari

Congratulations on the rapid prototyping.

I'll raise three points now, maybe more next week:

First point.

> Step 1:  Find all routers that are directly connected (hopcount
> distance of 0) to a network N.  The management station must be able
> to find one SNMP-speaking router on that network, and then query
> that router to get the Neighboring Routers list.

I initially mis-read this as "find all routers using AppleTalk, and
THEN get the Neigbouring Routers list from one of them", which is
effectively a duplicate operation.

I would prefer there not to be a "Neighboring Routers list" unless it
can be "proved" to be necessary. Not just "nice to have", but
necessary and essential. AppleTalk already provides plenty of
good ways to get this information (all routers on network "N") without
the extra work, memory and coding required by all Router vendors to
support this table (Yes, I don't want to have to write the code for
it :-).

Please refer back to Brad Parker's mail of 8 Dec 92 on "Re: Vote, PH2
zone time bomb" for more reasons why not.

I know there's an "IP-only-based SNMP management station" crowd who
would like to be able to perform zone-name-changing from
non-AppleTalk-capable MSs, but this table doesn't help here, as it
only contains the AppleTalk addresses of the other Routers and not
their IP addresses (no, it can't store them as well).

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.

I gather the use of "optional" in official MIBs (as distinct from
private ones) is "strongly frowned upon".


Second point.
Mention should be made (if it is already then please ignore this) of
the fact that a zone-name-change is required to be followed by
reconfiguration of all seed routers, or the network may be unuseable
after the next power-fail. If the reconfig can't be guaranteed, then
the zone-change better not be done.


Third point.
The format of the new zone list is:

	newZoneTable OBJECT-TYPE SYNTAX SEQUENCE OF NewZoneEntry
	newZoneEntry OBJECT-TYPE SYNTAX NewZoneEntry
	INDEX { newZonePortIndex, newZoneIndex }
	
	NewZoneEntry ::= SEQUENCE {
	newZonePortIndexINTEGER,
	newZoneIndexINTEGER,
	newZoneName AtName

(Might this be "newZoneName AtName (SIZE (1..32))"?)

What we have here is a list of zones in a completely different format,
and differently indexed to:

	atportZoneTable OBJECT-TYPE SYNTAX SEQUENCE OF AtportZoneEntry
	atportZoneEntry OBJECT-TYPE SYNTAX AtportZoneEntry
	INDEX { atportZonePort, atportZoneName }

	AtportZoneEntry ::= SEQUENCE {
	atportZonePort     INTEGER,
	atportZoneName     ATName (SIZE (1..32)),
	atportZoneStatus   INTEGER

It would help a lot if these zone-lists could be made more
"compatible" (read "identical") so they could use common code in
both the Routers and in the MS.

Preferably change the atportZoneEntry to be the same as the
newZoneEntry with separate indexes - using the atportZoneName as an
index is a hack (because of the case-insensitive compare).

========================
Tom Evans  [e-mail]
Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179
Victoria, Australia 61-3-764-1100  FAX ...[phone]  A.C.N. 004 818 455