Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15409; 3 May 93 9:47 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02348; 3 May 93 9:47 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15394; 3 May 93 9:47 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14704; 3 May 93 9:21 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: apple-ip@apple.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-appleip-mib2-01.txt Date: Mon, 03 May 93 09:21:13 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9305030921.aa14704@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over AppleTalk Working Group of the IETF. Title : AppleTalk Management Information Base II Author(s) : S. Waldbusser, K. Frisa Filename : draft-ietf-appleip-mib2-01.txt Pages : 102 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing AppleTalk networks. RFC1243 defines a set of MIB objects for managing the lower layers of the AppleTalk protocol stack, up to the Network layer. This memo defines additional objects that exist in the AppleTalk portion of the MIB. These objects provide for the management of the transport and session layers of the AppleTalk protocol stack, as well as extensions to the lower layers. This is achieved in an upwardly-compatable fashion. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-appleip-mib2-01.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-appleip-mib2-01.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-appleip-mib2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-appleip-mib2-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10475; 6 May 93 15:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10471; 6 May 93 15:57 EDT Received: from cayman.cayman.com by CNRI.Reston.VA.US id aa21430; 6 May 93 15:57 EDT Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA02621; Thu, 6 May 93 15:03:54 EDT Return-Path: Received: from nisc.jvnc.net by cayman.Cayman.COM (4.1/SMI-4.0) id AA02617; Thu, 6 May 93 15:03:53 EDT Received: from secureSUN250.timeplex.com by nisc.jvnc.net (5.65/1.34) id AA17350; Thu, 6 May 93 15:03:46 -0400 Received: from doelztc.timeplex.com (doelztc.timeplex.com) by bigguy.timeplex.com (4.1/SMI-4.1) id AA09908; Thu, 6 May 93 13:03:18 EDT Received: from sd5.doelz by doelztc.timeplex.com (4.1/SMI-4.1) id AA12697; Thu, 6 May 93 12:02:42 PDT Date: Thu, 6 May 93 12:02:42 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Raj Bhagwat Message-Id: <9305061902.AA12697@ doelztc.timeplex.com> To: apple-ip@cayman.com Subject: AppleTalk over WAN standards Hi netters, I would like to know if there are any standards for AppleTalk over various WANS(Frame Relay, X.25, PPP etc.). I am just ignorant of the way AARPing is done over the WANs. Any help would be appreciated. Raj.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13618; 6 May 93 17:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13614; 6 May 93 17:32 EDT Received: from cayman.cayman.com by CNRI.Reston.VA.US id aa24805; 6 May 93 17:32 EDT Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA05223; Thu, 6 May 93 16:38:53 EDT Return-Path: Received: from dirt.cisco.com by cayman.Cayman.COM (4.1/SMI-4.0) id AA05219; Thu, 6 May 93 16:38:52 EDT Received: from glare.cisco.com by dirt.cisco.com with TCP; Thu, 6 May 1993 13:38:42 -0700 Message-Id: <199305062038.AA28700@dirt.cisco.com> To: Raj Bhagwat Cc: apple-ip@cayman.com Subject: Re: AppleTalk over WAN standards In-Reply-To: Your message of "Thu, 06 May 93 12:02:42 PDT." <9305061902.AA12697@ doelztc.timeplex.com> Date: Thu, 06 May 93 13:38:42 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David S.A. Stine" On Thu, 6 May 93 12:02:42 PDT, raj@doelztc.timeplex.com (Raj Bhagwat) said: > Hi netters, > I would like to know if there are any standards for AppleTalk over various > WANS(Frame Relay, X.25, PPP etc.). I am just ignorant of the way AARPing > is done over the WANs. Any help would be appreciated. Apple has published specifications for AppleTalk over SMDS; the Apple-IP working group has published a spec for AppleTalk over PPP. That's it to date. dsa   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12228; 13 May 93 20:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12224; 13 May 93 20:48 EDT Received: from cayman.cayman.com by CNRI.Reston.VA.US id aa08303; 13 May 93 20:48 EDT Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA09453; Thu, 13 May 93 20:23:16 EDT Return-Path: Received: from Shiva.COM by cayman.Cayman.COM (4.1/SMI-4.0) id AA09449; Thu, 13 May 93 20:23:15 EDT Received: by Shiva.COM (1.34b) Thu, 13 May 93 20:23:14 EDT Date: Thu, 13 May 93 20:23:14 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jonathan Wenocur Message-Id: <9305140023.AA25099@Shiva.COM> To: apple-ip@cayman.com, atalk-routing@shiva.com Subject: AppleTalk Networking Forum Kits Hi Folks, AppleTalk Networking Forum Membership and Meeting Registration Kits were mailed Monday (May 10) via 2-day priority mail to all of those on the ANF "interested parties" list. This kit contains a list of Proposed Working Groups, as well as background and application information. There is also an agenda and registration form for the first ANF meeting taking place in conjunction with Mactivity on Monday, 28 June 1993 in San Jose, CA. If your kit has not yet arrived, or you don't think you are on the "interested parties" list and would like to receive a kit, please contact: The AppleTalk Networking Forum 688 Fourth Avenue San Francisco, CA 94118 415-750-8351 415-751-4829 (fax) or e-mail Michael LoBue, the ANF Executive Director, at: lobue@well.sf.ca.us Thank you very much. The ANF looks forward to your participation! -- Jonathan Wenocur President, AppleTalk Networking Forum   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03367; 20 May 93 9:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03362; 20 May 93 9:17 EDT Received: from cayman.cayman.com by CNRI.Reston.VA.US id aa07926; 20 May 93 9:17 EDT Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA19964; Thu, 20 May 93 08:46:55 EDT Return-Path: Received: from stemwinder.fcr.com by cayman.Cayman.COM (4.1/SMI-4.0) id AA19960; Thu, 20 May 93 08:46:52 EDT Received: from localhost.fcr.com by stemwinder.fcr.com (4.1/SMI-4.1) id AA22917; Thu, 20 May 93 08:43:45 EDT Message-Id: <9305201243.AA22917@stemwinder.fcr.com> To: Sari Harrison Cc: apple-ip@cayman.com Subject: Re: Zone Name Change Prototype In-Reply-To: Mail from Sari Harrison dated Tue, 27 Apr 1993 16:19:19 PDT <9304272319.AA14213@apple.com> Date: Thu, 20 May 1993 08:43:44 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brad Parker >> Ciao, [ my understanding is that you would only use "ciao" with people you would the the "familiar you" with ;-) but then, the same people would tell you that one does not drink cappaccino after lunch ;-) ] >> 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 yes, I think we all understand the memory/speed tradeoff (we could use a table for multiplies also, which would be fast, but it would take a lot of memory). This scheme is impractical if the entire system has a small amount of memory, say 512k. but hey, this is old news. I'm interested in (and supportive of) the zone name changing proposal - it sounds a lot like what we used to do in phase 1. I'm curious, however, why the routers need to stop emitting rtmp packets. Is there a technical reason besides causing all the end-nodes to timeout? (i think the wording needs to be made a bit less ambiguous - it needs to be clear that the routers stop advertising the network range out their *other* ports) I'd prefer to see the end-nodes not all loose connectivity and end up in the default zone. (maybe I misread that - do they only end up in the default zone if they where in a zone which went away?) but then, that would require an upgrade to the end nodes, wouldn't it. [warning - possibly il-informed hot-air filled opinion follows] I find it humorous that we protocol/router people are so adverse to making changes to the end nodes while the system software people at apple have made changes with wild abandon. (I can count 3 recent revs in my head. I would guess there have been over 5 in the last 2 years). am I wrong? ] -brad   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20407; 24 May 93 5:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20403; 24 May 93 5:43 EDT Received: from cayman.cayman.com by CNRI.Reston.VA.US id aa22049; 24 May 93 5:43 EDT Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA20631; Mon, 24 May 93 05:22:47 EDT Return-Path: Received: from munnari.oz.au by cayman.Cayman.COM (4.1/SMI-4.0) id AA20627; Mon, 24 May 93 05:22:41 EDT Received: from wcc.oz by munnari.oz.au with SunIII (5.83--+1.3.1+0.50) id AA26019; Mon, 24 May 1993 19:22:33 +1000 (from tom@wcc.oz.au) Message-Id: <9305240922.26019@munnari.oz.au> Date: 24 May 93 18:29:29 +1000 (Mon) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Evans To: apple-ip <@munnari.oz.au:apple-ip@cayman.com> Subject: Re: Zone Name Change Prototype Date: 24-May-93 To: Apple-IP Mailing List From: Tom Evans Re: Re: Zone Name Change Prototype Brad Parker : > I'm curious, however, why the routers need to stop emitting rtmp > packets. Is there a technical reason besides causing all the > end-nodes to timeout? That isn't enough reason? :-) It might also be there to support all the non-zone-name-change-capable AppleTalk Routers on that network that you have to configure non-seed and then power-cycle during the time that all the zone-name-change-capable Routers are in "hold-off" and not emitting packets. Just a wild guess. ======================== Tom Evans tom@wcc.oz.au Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179 A.C.N. 004 818 455   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08210; 25 May 93 14:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08206; 25 May 93 14:46 EDT Received: from cayman.cayman.com by CNRI.Reston.VA.US id aa16448; 25 May 93 14:46 EDT Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA16663; Tue, 25 May 93 14:23:56 EDT Return-Path: Received: from apple.com by cayman.Cayman.COM (4.1/SMI-4.0) id AA16659; Tue, 25 May 93 14:23:53 EDT Received: from [17.190.56.127] by apple.com with SMTP (5.61/7-Aug-1992-eef) id AA09792; Tue, 25 May 93 11:23:44 -0700 for apple-ip@Cayman.com Date: Tue, 25 May 93 11:23:44 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sari Harrison Message-Id: <9305251823.AA09792@apple.com> To: apple-ip@cayman.com Subject: Re>Zone Name Change Protoype Brad Parker writes: > I'm curious, however, why the routers need to stop emitting rtmp packets. >Is there a technical reason besides causing all the end-nodes to timeout? Nope. That's the only reason. >I'd prefer to see the end-nodes not all loose connectivity and end up >in the default zone. (maybe I misread that - do they only end up in >the default zone if they where in a zone which went away?) An end node whose default zone does not go away *will* stay there. No upgrades necessary! Ciao, <-- (I feel like I know you all so well :-)) Sari