MacUserLabs@cup.portal.com (Stephan - Somogyi) (01/18/91)
frankc@skat.usc.edu (Frank Callaham III) writes: >Anyone out there know of any reason why this card could not support >Phase 2?? Why only Phase 2??? Apple wants people to stop using Phase 1. Remember, _many_ people out there in MIS-land hammered on Apple because of the limited adressing scheme in Phase 1. As a result, Apple released Phase 2. If memory serves me correctly, it's been about 2-ish years since Phase 2 was released. The degree of Phase 2 acceptance is less than oveming. The majority of MISniks I've spoken to spend a great deal of time complaining about how migration from Phase 1 to Phase 2 is such a pain. No-one said it would be easy. Every LT<->ET router manufacturer that I'm aware of supports both Phase 1 and Phase 2, and only one router that I can think of can't route between Phase 1 Enet and Phase 2 Enet. ___________________________________________________________________ Stephan Somogyi Contentedness is for sheep MacUser
bhall@pbs.org (Dark Star) (01/18/91)
In article <38141@cup.portal.com>, MacUserLabs@cup.portal.com (Stephan - Somogyi) writes: > frankc@skat.usc.edu (Frank Callaham III) writes: > > > The majority of MISniks I've spoken to spend a great deal of time > complaining about how migration from Phase 1 to Phase 2 is such a > pain. No-one said it would be easy. We switched a couple of months ago. I had been concerned about it but it turned out to be fairly easy. We had 5 FastPaths, about 5 Macs with Ethernet cards and AppleTalk for VMS that needed to be updated. Of course these were all in the same building and that helped a lot. -- Bruce Hall Domain: bhall@pbs.org Public Broadcasting Service UUCP:...{uupsi,vrdxhq,csed-1,ida.org}!pbs!bhall Phone: 703/739-5048 "Experience is the name everyone gives to their mistakes" - Oscar Wilde
hayes@Apple.COM (Jim Hayes) (01/18/91)
bhall@pbs.org (Dark Star) writes in article <1991Jan17.205340.11378@pbs.org>: > >We switched a couple of months ago. I had been concerned about it but >it turned out to be fairly easy. We had 5 FastPaths, about 5 Macs with >Ethernet cards and AppleTalk for VMS that needed to be updated. > >Of course these were all in the same building and that helped a lot. > (These are my opinions, not my beloved employer's) Apple no longer officially supports Phase I. This is partly a Marketing decision and partly an Engineering delusion. I can say (quite plainly) that Apple ships the "Phase II Upgrade Utility" and the "Phase II Node Identifier" with the AppleTalk Internet Router because we couldn't convert our internal internet without them. In fact, we still have a few disparate Phase I nets in use. (About 4 out of the 570 networks within Engineering). It is important to note that Marketing is telling third party router manufacturers to implement Phase II only. Luckily most third party router manufacturers are smarter than that. Converting a large net requires some healthy planning-- if your router vendor does not support both protocols, life gets really hard. Is it worth it? For small networks (a few segments, a couple of zones) probably not. The benefits gained using Phase II really only show up with large networks. Some of the technical benefits: Zone-wide broadcasts use multicast addresses. RTMP now uses Split-Horizon updates for large backbones. This prevents routers on a backbone from re-telling the other routers something they've already heard from another router on the backbone. RTMP now uses "reverse poisoning" to propigate routing information for dead networks faster. NBP uses zone-wide broadcasts to resolve names and adds more wildcarding features The addressing scheme suports >65300 networks with an unlimited number of hosts per network. (actually 254 hosts per net number, but you can have multiple net numbers per each wire.) The addressing scheme supports multiple Zone names for each network. We generally run only one network number per Ethernet and havn't bumped into the 254 host limit. We design our networks that way on purpose. We do, however, make extensive use of the multiple zone name per network feature which allows us move network services to anywhere on the network and still keep the original zone name while people get used to the new location. We tend to reorganize and move quite often, so this feature comes in handy. As for third parties... While I cannot endorse any third-party products, I know of only one high-performance router vendor that routes AppleTalk Phase I/II at the theoretical limits of Ethernet: Cisco Systems. We make extensive use their boxes internally along with our own Internet Router and a few Kinetics Fastpaths for KIP. If anybody is interested, I'll post a "Guts of Apple's Internal Engineering Network" which contains some surprising numbers. Send some e-mail if you want to see it. -- Jim Hayes, Network Manager (I manage the hardware, not the network group) Engineering Network Services, Apple Computer Inc. Inet: hayes@apple.com UUCP: {amdcad|decwrl|ames}!apple!hayes
bhall@pbs.org (Dark Star) (01/19/91)
> We do, however, make extensive use of the multiple zone name per > network feature which allows us move network services to anywhere on > the network and still keep the original zone name while people get used > to the new location. We tend to reorganize and move quite often, so > this feature comes in handy. > How does this work? "Who" supplies the zone names? The Macs themselves? Routers? > > If anybody is interested, I'll post a "Guts of Apple's Internal > Engineering Network" which contains some surprising numbers. > Send some e-mail if you want to see it. > I'd love to see that. I am especially interested in the Wide Area aspects of the network. Thanks for the info. -- Bruce Hall Domain: bhall@pbs.org Public Broadcasting Service UUCP:...{uupsi,vrdxhq,csed-1,ida.org}!pbs!bhall Phone: 703/739-5048 "Experience is the name everyone gives to their mistakes" - Oscar Wilde
kre@cs.mu.OZ.AU (Robert Elz) (01/19/91)
hayes@Apple.COM (Jim Hayes) writes: >Some of the technical benefits: > Zone-wide broadcasts use multicast addresses. This is probably the number one benefit of Phase 2, the huge number of broadcasts bothering all of the ethernet hosts you have which don't give a damn about appletalk are gone in phase 2. > RTMP now uses Split-Horizon updates This is also (obviously) good, but works just as well with Phase 1... > RTMP now uses "reverse poisoning" This is good too - but you only see the effect if you have networks coming and going a lot. The nature of most appletalk nets that exist, and the general quality of the routers used (almost no-one uses hosts to route appletalk) means that in practice this is probably a small benefit. > NBP uses zone-wide broadcasts to resolve names and adds more > wildcarding features The first was always true, I suspect you mean that nbp "broadcasts" are now restricted multicasts (ie: not even all appletalk devices on the cable receive them), so devices in other zones normally need not be bothered handling a lookup that cannot succeed. The extra wildcarding is close to useless, as you can't rely on it being supported by anyone (try hunting for =Writer sometime, where by '=' I mean the 0xC5 character (approx equals) - see how many LaserWriter and ImageWriter devices respond...). > The addressing scheme suports >65300 networks Which is actually less than phase 1 allowed. > (actually 254 hosts per net > number, but you can have multiple net numbers per each wire.) The much touted "need" for phase 2, and most often trumpeted in the marketing, but actually probably the least useful of the enhancements, and just about the biggest problem (caused the most changes). This benefits only people stuck with huge bridged ethernets, which is a position they'd be better off getting out of, than attempting to get more protocols to support. > The addressing scheme supports multiple Zone names for each network. This is undoubtably useful too, but only applies to 'extended' nets. That is: ethernet & token-rings - try giving more than one zone to your localtalk because you've moved a printer to it that used to be in a different zone and you're in for a shock. kre
hayes@Apple.COM (Jim Hayes) (01/19/91)
First of, before I answer this question, I should have clarified myself when I said that Apple does not support Phase I. I meant it strictly in the router/WAN context. Of course LocalTalk (which is Phase I) has not changed and is still vigorously supported by Apple on all platforms. [Thanks to Jim K. for correcting me...] bhall@pbs.org (Dark Star) writes in article <1991Jan18.175928.11397@pbs.org>: >> We do, however, make extensive use of the multiple zone name per >> network feature which allows us move network services to anywhere on >> the network and still keep the original zone name while people get used >> to the new location. We tend to reorganize and move quite often, so >> this feature comes in handy. >> > >How does this work? "Who" supplies the zone names? The Macs themselves? >Routers? > First off, let me clarify why we use it. We have a few file servers that contain site-licensed software. Given Apple's great propensity toward reorganization, the file servers are a moving target in terms of where they physically sit. But it doesn't matter, the zone name moves with them and they still look like they're in the old spot. Note that we don't replace the zone name in the new location, we just *add* another zone to that location's net. The Phase II routers are responsible for keeping track of zone names. The Mac's only care about the zone they appear to be in and the nearest router. It works by using the new "Zone Multicast Address" which provides the ability to send name lookup requests to specific "interested" parties on the net. If there were many routers on a backbone and only two handled a particular zone, only those two would be bothered when folks ask about that zone. Note, however, that a zone name cannot be "disjoint" through routers. Specifically, if you have three nets separated by routers and they're all in the No Parking zone, you can't create an additional Zone on each end without it also appearing in the middle. I.e. This is not allowed: <---Net A---> [router] <---Net B---> [router] <---Net C---> No Parking No Parking No Parking Free Trade End Zone Free Trade For things to work properly, the Free Trade zone must appear on all the routers in between. This works: <---Net A---> [router] <---Net B---> [router] <---Net C---> No Parking No Parking No Parking Free Trade Free Trade Free Trade End Zone [Side Note: If you have more than one zone on a wire, you can put your Macintosh into any of those zones by using the "Network" cdev in the control panel. Clicking on the EtherTalk or TokenTalk icon will bring up a list of available zone names... This is useful for putting fileservers on the same wire into logical groups.] Anyway, I hope this doesn't add any more confusion to things. :-) -- Jim Hayes, Network Manager (I manage the hardware, not the network group) Engineering Network Services, Apple Computer Inc. Inet: hayes@apple.com UUCP: {amdcad|decwrl|ames}!apple!hayes
kre@cs.mu.OZ.AU (Robert Elz) (01/19/91)
hayes@Apple.COM (Jim Hayes) writes: >Of course LocalTalk (which is Phase I) has not changed This isn't quite right, LocalTalk is Phase 2 too if it contains only Phase 2 routers, look closely at the RTMP packets and you will see the difference. But its "non-extended" Phase 2, which means you have the hassle of it being Phase 2 (all your routers on it have to change), and you get none of the benefits at all... Hosts connected to localtalk (especially those with their network code in ROM) don't have to change at all - this is the real cause of the lack of enhancement of localtalk. >The Phase II routers are responsible for keeping track of zone names. Routers (Phase 1 or 2) have always done that >The Mac's only care about the zone they appear to be in and the nearest >router. I think this is the question that was really being asked (which your footnote partially answered) ... if you have multiple zones on a net, the "zone they are in" isn't so simple any more, a mac can't simply ask a router "Hey! what's my zone?" Instead, the mac asks the router "What zones do you have?" and then gives its user (assuming it has one) a list of zones to pick from. That becomes the mac's zone. (For "mac" here, read "appletalk client", it need not be a mac). The mac then remembers that zone, and doesn't ask any more as long as it remains a legal zone on the net. The user can switch zones more or less whenever he likes (some servers running on the mac may not cope all that well). For devices without users to query, and which aren't configured, there is a "default" zone that the device will end up using. >If there were many routers on a backbone and only two >handled a particular zone, only those two would be bothered when folks >ask about that zone. This isn't right - if you have a backbone (ie: net), all the routers on it contain the exact same list of zones for that net (or your configuration is badly broken). Of those routers, only one is "bothered" to handle lookups (one of them receives the request and re-broadcasts it) in either phase 1 or phase 2. However, if you have many hosts on your net (including all the routers in their role as hosts), and only two of the hosts are in a particular zone, then (usually) only those two will be bothered by the lookup packet being broadcast (multicast). Its "usually" because a hash function is onvolved, and its possible that two zones might hash into the same value. >Note, however, that a zone name cannot be "disjoint" through routers. This is simple nonsense. >Specifically, if you have three nets separated by routers and they're >all in the No Parking zone, you can't create an additional Zone on each >end without it also appearing in the middle. Yes you can. kre
urlichs@smurf.sub.org (Matthias Urlichs) (01/19/91)
In comp.protocols.appletalk, article <38141@cup.portal.com>,
MacUserLabs@cup.portal.com (Stephan - Somogyi) writes:
<
< Every LT<->ET router manufacturer
< that I'm aware of supports both Phase 1 and Phase 2, and only one
< router that I can think of can't route between Phase 1 Enet and Phase
< 2 Enet.
<
One notable exception is Ungermann Bass's MaxTalk, which is still
Phase-1-only. (Phase 2 support is announced...)
The MaxTalk also has some routing problems with gateing TCP/IP traffic.
Other than that, we're reasonably satisfied with it.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/hayes@Apple.COM (Jim Hayes) (01/22/91)
kre@cs.mu.OZ.AU (Robert Elz) writes in article <kre.664276889@mundamutti.cs.mu.OZ.AU>: >hayes@Apple.COM (Jim Hayes) writes: > >>Note, however, that a zone name cannot be "disjoint" through routers. > >This is simple nonsense. > Ack. I was asleep at the keyboard here. Apparently that feature was broken for some time on our internal net (due to beta router code) so we didn't talk complete advantage of it. A quick re-read of the Phase II spec. says it should work. My apologies. Thanks to Robert for pointing that out so quickly. :-) -- Jim Hayes, Network Manager (I manage the hardware, not the network group) Engineering Network Services, Apple Computer Inc. Inet: hayes@apple.com UUCP: {amdcad|decwrl|ames}!apple!hayes
frankc@skat.usc.edu (Frank Callaham III) (01/23/91)
>As for third parties... While I cannot endorse any third-party >products, I know of only one high-performance router vendor that routes >AppleTalk Phase I/II at the theoretical limits of Ethernet: Cisco >Systems. We make extensive use their boxes internally along with our >own Internet Router and a few Kinetics Fastpaths for KIP. > >-- >Jim Hayes, Network Manager (I manage the hardware, not the network group) >Engineering Network Services, Apple Computer Inc. > >Inet: hayes@apple.com UUCP: {amdcad|decwrl|ames}!apple!hayes I know the "benifits" of Phase II, the problem I have, is that the Cisco Routers cannot currently route EtherTalk Phase II packets over a FDDI backbone.(This is according to my net admin. He says that apple did something "wrong/strange" with the E-Talk2 packets) My point is... It would not be all that difficult to port the phase 1 code to the new card. Frank Callaham University of Southern California Microcomputer Support frankc@skat.usc.edu These are my opinions not USC's. I just happen to work there...
hayes@Apple.COM (Jim Hayes) (01/23/91)
frankc@skat.usc.edu (Frank Callaham III) writes in article <29515@usc>: > >I know the "benefits" of Phase II, the problem I have, is that the >Cisco Routers cannot currently route EtherTalk Phase II packets over >a FDDI backbone.(This is according to my net admin. He says that >apple did something "wrong/strange" with the E-Talk2 packets) > >My point is... It would not be all that difficult to port the phase 1 >code to the new card. > cisco does *route* Phase II over FDDI. It's in software release 8.2 that started shipping around Christmas. We currently route Phase II on our FDDI backbone using cisco hardware. ---As for bridging Phase II onto/over FDDI: You cannot easily BRIDGE Phase II over FDDI... That's our fault not the bridge vendor's. SHORT STORY: In a particular type of AppleTalk phase II packet, we use a non-standard vendor code (all zeroes) that most bridge manufacturers interpret as meaning "no special format, so use standard 802.3 packets on the other end" which means the packets come out at the other end with the wrong format. LONG STORY: When the powers that be created AppleTalk phase II, they decided to use the IEEE 802.2 packet format with EtherTalk which would be consistent with the packet format for TokenTalk as well. (IEEE is an "engineering professionals" organization that likes to make standards.) The 802.2 packet contains something called a SAP (Service Access Point) which is designed to help differentiate between different IEEE protocols. Since AppleTalk is not an IEEE protocol, it uses as special SAP code ($AA [hex]) that the IEEE set aside for non-standard protocols. To distinguish all the various non-standard protocols, the IEEE created something inside the $AA packet called the SNAP (Sub-Network Access Protocol) that identifies the non-standard protocol and the vendor that created it. What we did wrong (and not just wrong, really *wrong*) was mess up the SNAP header that identifies Phase II. Turns out that for regular Phase II packets we do the right thing. We correctly shove our company code ($080007) into the packet and everything works just fine. For the other type of Phase II packet, the ARP (address resolution protocol) we incorrectly shove in a company code of $000000 which most bridge vendors take to mean "I have no special packet format". Well, 802.2 is a special packet format. When the packet gets to the other end of the network, it shoves it back onto the Ethernet as a regular old 802.*3* packet which looks exactly like a Phase I AARP packet. Needless to say, the Phase II nodes ignore it. This $000000 vendor code also causes problems for hosts on FDDI that speak AppleTalk Phase II. CONCLUSION: Bridge manufacturers should agree on a way to correctly recognize this packet and reconstitute it on the other end. You can tell a Phase I AARP from a Phase II AARP by looking inside the packet. The network number will always be zero in Phase I, and always non-zero in phase II. I don't think there is an easy way to "fix" the Phase II spec. in this regard. Doing so would probably break more implementations than would benefit from its use. -- Jim Hayes, Network Manager (I manage the hardware, not the network group) Engineering Network Services, Apple Computer Inc. Inet: hayes@apple.com UUCP: {amdcad|decwrl|ames}!apple!hayes
pierre@imag.fr (Pierre LAFORGUE) (01/24/91)
In article <38141@cup.portal.com>, MacUserLabs@cup.portal.com (Stephan - Somogyi) writes: |> Apple wants people to stop using Phase 1. |> ... |> The majority of MISniks I've spoken to spend a great deal of time |> complaining about how migration from Phase 1 to Phase 2 is such a |> pain. No-one said it would be easy. Every LT<->ET router manufacturer |> that I'm aware of supports both Phase 1 and Phase 2, and only one |> router that I can think of can't route between Phase 1 Enet and Phase |> 2 Enet. Do you mean you can use all the Appletalk Phase I only softwares (e.g. CAP) if you have at least one "modern" gateway (KFPS4 for instance) configured with the PhaseI/PhaseII transition option, and various old ones (e.g. KFPS2) ? I would be grateful to who experimented this to send me a mail. -- Pierre LAFORGUE laforgue@imag.Fr
brooks@Apple.COM (Kevin Brooks) (01/31/91)
The Real Story - AppleTalk Phase 2 and FDDI bridges
First, the problems with AppleTalk phase 2 and FDDI have been resolved.
Problem Description:
Phase 2 AppleTalk packets that transverse an FDDI transparent bridge are
translated into an Ethernet style packet. The incorrect translation
prevents nodes on two Ethernet segments joined, through "transparent"
bridge, by an FDDI backbone, from communicating with each other using
EtherTalk Phase 2. This is a result of our implementation of the OUI
0000 in the 802.2 SNAP header.
The bridge vendors have implemented their products based on the IEEE
802.1 standard. However there are questions regarding the
interpretation of the standard as it relates to translating "all zeros"
in the OUI field of an 802.2 SNAP header.
The problem has to do with the way in which we implement SNAP in phase
2, and more specifically, how we implement AARP in SNAP in phase 2.
The 802.1 specification calls for all SNAP PDUs have a protocol
identifier associated with them which is 40 bits in length. The first
24 bits are used as an organizational unique identifier which is
assigned by the IEEE, the remaining 16 bits are administered by the
assignee.
UI Assignee Administered
0011 0101 0111 1011 0001 | 0010 0000 0000 0000 0001
| |
lsb msb
Apple's assigned identifier is 08 00 07
1000 0000 0111
network bit order 0001 0000 1110
||
IEEE 802.1 states that: ||
MX
M = 0: (M=1 is reserved)
X = 0: Globally Administered Protocol Identifier
X = 1: Locally Administered Protocol Identifier
For all AppleTalk protocols we use the identifier 08007809B, but for
AARP we use 00000080F3. This is really where the problem begins, in
our use of OUI 00000.
Our use of 0000 as the UI is conflicting with a translating
FDDI-Ethernet bridge which also is using the UI of 00000 to recognize
IP packets which need to be translated from 802 to Ethernet style
packets. The question is who's in the right, us, them, or both of us?
The all-zeros "organizational unique identifier" (OUI) was not
specifically intended to be used for translating Ethernet frames to
802.2/SNAP. Its original intention was (and is) not completely clear;
all that was generally agreed upon was
(1) The low-order 16 bits of the SNAP protocol discriminator indicated
an Ethernet protocol type; and
(2) The format of the data part of the SNAP packet was the same as the
format of the data part of the Ethernet packet of this protocol type.
This "general agreement," as far as I know, was never written down.
AppleTalk Phase 2 and TCP/IP both adopted this convention. The
unfortunate difference is that, on an Ethernet/802.3 data link,
AppleTalk Phase 2 runs on top of 802.3 (and 802.2) and TCP/IP runs on
top of Ethernet. Thus for a TCP/IP Ethernet node to communicate with a
TCP/IP 802.2 node (on token ring or FDDI, say), some type of packet
translation must be performed, whereas for an AppleTalk Phase 2
Ethernet node to communicate with any other AppleTalk Phase 2 802.2
node (on Ethernet, token ring or FDDI) no such translation need occur
(in fact, such translation MUST NOT occur).
This makes it somewhat difficult to build a bridge that "transparently"
allows both forms of communication. However all that really has to be
done is for the bridge to contain a small table of Ethernet protocol
types that either should, or shouldnUt be translated in this manner.
Obviously the smaller the table, and the less translation done, the
better the overall performance. Any bridge between Ethernet and an 802
media which does not translate any OUI zero packets will prevent TCP/IP
nodes (and any others using the same OUI convention) from communicating
between the two media. Any bridge between Ethernet and an 802 media
which translates all OUI zero packets will prevent AppleTalk nodes (and
any others with an OUI of zero who donUt expect translation) from
communicating between the two media. In both cases, routers can of
course be set up to accomplish the communication.
A somewhat equivalent problem could exist if two bridges are used to
connect two Ethernet/802.3 data links across an 802 backbone (say
FDDI). In this case, some type of translation/encapsulation of
Ethernet (non-802.3) packets must be performed to allow them to be
passed across the 802 backbone. There are many ways to do this, one of
which seems to be translating all Ethernet packets to OUI zero packets,
shipping them across the backbone, and then converting them back. This
however does not work for any OUI zero packets which start out on the
Ethernet/802.3 data link. Such packets will not be translated on the
way into the backbone, but will be incorrectly translated before being
delivered on the destination Ethernet. Such packets should be
forwarded entirely without translation.
In terms of actual product implementations, unfortunately DEC is
already shipping an Ethernet-to-FDDI bridge (LanBridge 500) which
translates all OUI zero packets, and thus does not work with AppleTalk
Phase 2. They are aware of this issue. At the recent 802 meetings in
Denver, it became clear that this type of translation is not part of
the 802.1d (Mac Bridging) standard, but is something that many bridge
manufacturers wish to include as a non-802-standard option with their
products. Most have said they will have some type of translation (or
non-translation) table to insure it is possible to work with all known
protocols.
Current Status:
At the most recent IEEE 802.1 meeting (during the week of 11/12/90) an
agreement was reached regarding the translation of Ethernet-like
packets from an FDDI backbone to an Ethernet segment. The creation of a
new OUI for Ethernet (non 802.3) packets will be required. The Bridge
translation decision from an FDDI backbone to Ethernet segment will be
as follows:
If OUI = NEW, then translate back to Ethernet (e.g Phase 1 EtherTalk)
Otherwise if (OUI=0 and TYPE=80F3 or other defined types do NOT
translate), Do not translate (e.g Phase 2 EtherTalk AARP)
Apple and DEC were major sponsors of this proposal, and DEC has agreed
to make changes to their bridges, in accordance with this proposal.
What this means is that EtherTalk Phase 2 AppleTalk end nodes will work
correctly (without modification to the end nodes), when transversing an
Ethernet/FDDI bridge. Furthermore EtherTalk phase 1 end nodes will also
work using the new OUI translation scheme.
The IEEE 802.1 committee is currently formalizing the use of OUI in
Ethernet to FDDI bridges. This should work will define exactly what to
do if a bridge encounters SNAP headers with OUI=0.
DEC has already started shipping new beta ROMs for the LanBridge 500 to
resolve the issues related to OUI 0. During the beta test a problem was
discovered with the Shiva Fastpath, it incorrectly computes the length
field of 802.3 Ethernet packets, because of this the LanBridge discards
all packets from the Fastpaths. Shiva was already aware of the problem
and new ROMs for the Fastpaths should be available soon to resolve this
issue.
If you have any questions concerning this issue please feel free to
send them my way.
Thank you
Kevin
Network and A/UX Engineer
Apple Computer
--
Kevin Brooks A/UX Specialist, Apple Computer
UUCP: {mtxinu,sun,nsc,voder}!apple!brooks
APPLELINK: AUX.DUDE@applelink.apple.com
Internet: brooks@apple.com