home *** CD-ROM | disk | FTP | other *** search
/ HAM Radio 1 / HamRadio.cdr / packet / packpro2 / pd91035.txt < prev    next >
Internet Message Format  |  1991-02-06  |  23KB

  1. From wang!elf.wang.com!ucsd.edu!packet-radio-relay Wed Feb  6 15:58:34 1991 remote from tosspot
  2. Received: by tosspot (1.63/waf)
  3.     via UUCP; Thu, 07 Feb 91 07:01:57 EST
  4.     for lee
  5. Received: from somewhere by elf.wang.com id aa11640; Wed, 6 Feb 91 15:58:32 GMT
  6. Received: from ucsd.edu by uunet.uu.net (5.61/1.14) with SMTP 
  7.     id AA15013; Wed, 6 Feb 91 09:54:05 -0500
  8. Received: by ucsd.edu; id AA20319
  9.     sendmail 5.64/UCSD-2.1-sun
  10.     Wed, 6 Feb 91 04:30:12 -0800 for hpbbrd!db0sao!dg4scv
  11. Received: by ucsd.edu; id AA20312
  12.     sendmail 5.64/UCSD-2.1-sun
  13.     Wed, 6 Feb 91 04:30:08 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list
  14. Message-Id: <9102061230.AA20312@ucsd.edu>
  15. Date: Wed,  6 Feb 91 04:30:04 PST
  16. From: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>
  17. Reply-To: Packet-Radio@ucsd.edu
  18. Subject: Packet-Radio Digest V91 #35
  19. To: packet-radio@ucsd.edu
  20.  
  21.  
  22. Packet-Radio Digest         Wed,  6 Feb 91       Volume 91 : Issue  35
  23.  
  24. Today's Topics:
  25.                     'To:' field anarchy! (3 msgs)
  26.                   Internet->packet Gateway (3 msgs)
  27.             KA9Q NOS for the Commodore Amiga availability
  28.                   PACKET->Internet Gateway (3 msgs)
  29.                  The FCC, the rules, and us (longish)
  30.  
  31. Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
  32. Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
  33. Problems you can't solve otherwise to brian@ucsd.edu.
  34.  
  35. Archives of past issues of the Packet-Radio Digest are available 
  36. (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
  37.  
  38. We trust that readers are intelligent enough to realize that all text
  39. herein consists of personal comments and does not represent the official
  40. policies or positions of any party.  Your mileage may vary.  So there.
  41. ----------------------------------------------------------------------
  42.  
  43. Date: Mon, 04 Feb 91 13:58:20 GMT
  44. From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <PJML@ibma.nerc-wallingford.ac.uk>
  45. Subject: 'To:' field anarchy!
  46. To: PACKET-RADIO@UCSD.edu
  47.  
  48. Greetings; i have recently been having a battle of wits :-) with a lot of
  49. users in the UK who seem intent on addressing their messages to 'ALL@GBR'
  50. or some similarly uninformative destination. I have done a count  of the
  51. messages on several BBS; something around 30-40% of messages are sent to
  52. 'ALL' !!!
  53. I rarely bother to read those messages addressed to 'ALL' from users
  54. who further alienate their intended audience by putting something totally
  55. uninformative (like 'HELP') as the only thing in the 'Subject:' field.
  56.  
  57. I have been trying to draw up a list of preferred 'To:' fields so that
  58. people can make best use of the limited addressability they have in headers,
  59. and so obtain the best targetting of their messages to the intended
  60. audience. Nothing i am doing is aimed at producing a 'restricted'
  61. list, purely a list showing common usages for the benefits of others.
  62. Also note that my list will include popular European variants of 'All'
  63. depending on national language variations.
  64. I was wondering - what is the normal procedure in the States and the rest
  65. of the world for these sorts of thing.... Do you have the usual 'to' fields
  66. anarchy, or are there 'preferred' ones as well as ALL ????
  67. And what do you do to those users who send 'local' news  (regarding club
  68. meets etc) to ALL@WWW. (you know, it arrives in Tasmania six weeks after the
  69. event took place)    There must be a special place in Hell for these people.
  70.  
  71.      Pete Lucas PJML@UK.AC.NWL.IA   or  G6WBJ@GB7SDN.GBR.EU
  72.  
  73. (Please reply via the List, or via Internet/Bitnet; my mailer has just been
  74.    attacked by the Data Loss Monster who eats anything with a '!' in the path)
  75.  
  76. ------------------------------
  77.  
  78. Date: 6 Feb 91 03:37:43 GMT
  79. From: elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!news.cs.indiana.edu!ux1.cso.uiuc.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu!steve@handies.ucar.edu  (Steve Schallehn)
  80. Subject: 'To:' field anarchy!
  81. To: packet-radio@ucsd.edu
  82.  
  83. In the 9th Amateur Radio Networking Conference (Sorry, I don't remember the
  84. official name), there was a paper presented on using netnews for packet 
  85. radio.  Perhaps someone could post a copy if they have a chance.  
  86.  
  87. I feel this sort of 'segmentization' is going to be extremely important
  88. for message distribution continuing in packet radio.
  89.  
  90. -Steve Schallehn, KB0AGD
  91.  Kansas State University
  92.  
  93. ------------------------------
  94.  
  95. Date: 5 Feb 91 13:37:31 GMT
  96. From: mcsun!ukc!acorn!agodwin@uunet.uu.net  (Adrian Godwin)
  97. Subject: 'To:' field anarchy!
  98. To: packet-radio@ucsd.edu
  99.  
  100. In article <04.Feb.91.14:12:43.GMT.#4981@UK.AC.NWL.IA> PJML@ibma.nerc-wallingford.ac.uk 
  101.   ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes:
  102. >Greetings; i have recently been having a battle of wits :-) with a lot of
  103. >users in the UK who seem intent on addressing their messages to 'ALL@GBR'
  104. >or some similarly uninformative destination. I have done a count  of the
  105. >messages on several BBS; something around 30-40% of messages are sent to
  106. >'ALL' !!!
  107.  
  108. You hero!
  109.  
  110. However, I feel the real problem is due to the use of a mail-like interface
  111. for bulletin traffic. It isn't sufficient just to reduce the use of ALL,
  112. but also (as you show by your suggestion of a preferred list) to limit
  113. bulletin 'destinations' to a number of names that are universally 
  114. recognised, rather than using the field as a sort of summarised subject.
  115.  
  116. It surprises me that this hasn't already happened, as many packet users 
  117. (and more especially packet BBS writers) must also be familiar with telephone 
  118. BBSs and surely appreciate the advantages of grouping bulletins in an 
  119. _intentionally_ restricted list of areas.
  120.  
  121. I'd therefore suggest that you tackle the BBS writers to provide categories
  122. to which bulletins may be addressed. In order to provide maximum anarchy -
  123. if that's how the users like it - I'd suggest that a message _could_ be 
  124. written to a previously unknown group, but it would result in a warning
  125. to the effect "Nobody's ever heard of this subject. Post somewhere else if
  126. you want your bulletin to have a fighting chance of being read".
  127.  
  128. When all the poorly-directed dross falls into the ALL area, it will become
  129. so boring that nobody will read it. Enterprising BBS writers might care to
  130. time out subjects that are either never written to or never read ...
  131.  
  132.  
  133. -- 
  134. --------------------------------------------------------------------------
  135. Adrian Godwin                                        (agodwin@acorn.co.uk)
  136.  
  137. ------------------------------
  138.  
  139. Date: 6 Feb 91 00:11:57 GMT
  140. From: drago.tgv.com!sjogren@ames.arc.nasa.gov  (Sam Sjogren)
  141. Subject: Internet->packet Gateway
  142. To: packet-radio@ucsd.edu
  143.  
  144. In article <27441@ucsd.Edu>, brian@ucsd.Edu (Brian Kantor) writes...
  145. >They way I plan (someday, in my copious free time) to implement an
  146. >internet<->packet mail gateway is actually rather simple:  traffic from
  147. >the ham side to the internet is not restricted, except for the odd
  148. >callsign on the idiot list.  Traffic from the internet to the ham side
  149. >is filtered; it must be from a mailbox (i.e., contents of the FROM
  150. >line) that is on my list of known hams, which is built by observation
  151. >and registration.
  152.  
  153. It's terribly trivial to create fake mail.  I can send mail to you
  154. with just about anything in the From: line, using SMTP over TCP.
  155. Perhaps this would be a case where we'd need authenticated mail,
  156. with some sort of public-key crypto-authentication system being
  157. used.  A conversation I had in December with Phil seemed to indicate
  158. that using cryptography for the purpose of authentication, as opposed
  159. to hiding the meaning of the message thru encryption of a message's
  160. contents, was not illegal under FCC rules, so the authentication
  161. data could even be conveyed along with the text of the message to
  162. provide end-to-end authentication even across the packet link(s).
  163. Of course, the strength of the authentication is only as secure as
  164. the person's private key's secrecy, but it may provide a high enough
  165. degree of authentication to make the FCC happy.  I could see an
  166. Internet->Ampr gateway allowing someone to log in over the Internet
  167. and then hop out over packet, with the person logged in having to
  168. be a ham to be allowed by the software to do this.  Direct TCP
  169. connections, or the passing of random IP packets, from Internet to
  170. packet are a bit harder, as I guess that you'd have to make the
  171. superuser of a particular machine (as designated by the IP address
  172. of a packet) be considered the control operator; you'd want to
  173. have control on that machine of just who was able to send IP
  174. packets to the Internet->packet gateway, and the gateway would
  175. have to restrict the routing of IP packets to radio links to those
  176. from an approved list of ham-operated Internet hosts.  It looks
  177. doable, but probably would be messy to implement.
  178.  
  179. -Sam, WB6RJH 
  180.  
  181. ------------------------------
  182.  
  183. Date: 6 Feb 91 06:08:55 GMT
  184. From: brian@ucsd.edu  (Brian Kantor)
  185. Subject: Internet->packet Gateway
  186. To: packet-radio@ucsd.edu
  187.  
  188. <description of forging mail, encryption, etc included by reference>
  189.  
  190. I would hope that it's only necessary to make a good-faith effort to
  191. ensure that the sender is a ham.  There is no way to be absolutely sure;
  192. it's only a question of how much effort you have to put forth to keep
  193. the pharisees happy.
  194.     - Brian
  195.  
  196. P.S.  There's a wonderful invention called the paragraph.  People who
  197. employ it often find that readers enjoy their writings more.
  198.  
  199. ------------------------------
  200.  
  201. Date: 6 Feb 91 06:08:47 GMT
  202. From: tgv.com!sjogren@ames.arc.nasa.gov  (Sam Sjogren)
  203. Subject: Internet->packet Gateway
  204. To: packet-radio@ucsd.edu
  205.  
  206. In article <27536@ucsd.Edu>, brian@ucsd.Edu (Brian Kantor) writes...
  207. ><description of forging mail, encryption, etc included by reference>
  208. >I would hope that it's only necessary to make a good-faith effort to
  209. >ensure that the sender is a ham.  There is no way to be absolutely sure;
  210. >it's only a question of how much effort you have to put forth to keep
  211. >the pharisees happy.
  212.  
  213. I'd love to be able to operate on this basis, in general.  I'm a
  214. big fan of honour systems.  However, if the asshole bureaucrats
  215. are going to be, well, assholes, it's good to know that you can
  216. come up with the technology to allow connectivity to continue
  217. despite the legal requirements.  We have the technology, let's
  218. hope that we're not forced to use it.
  219.  
  220. Btw, I find the FCC BBS citations offensive and scary.  I hope
  221. that they're overturned.
  222.  
  223. >    - Brian
  224.  
  225. -me
  226.  
  227. >P.S.  There's a wonderful invention called the paragraph.  People who
  228. >employ it often find that readers enjoy their writings more.
  229.  
  230. Well excuuuuuse my train of thought, and I'll excuse your pedancy!  >B-}
  231.  
  232. ------------------------------
  233.  
  234. Date: 5 Feb 91 05:05:41 GMT
  235. From: haven!ni.umd.edu!sayshell.umd.edu!louie@purdue.edu  (Louis A. Mamakos)
  236. Subject: KA9Q NOS for the Commodore Amiga availability
  237. To: packet-radio@ucsd.edu
  238.  
  239. Contrary to what is published in this month's QST in the Packet
  240. Perspectives column, I am NOT a source for the KA9Q NOS for the Amiga.
  241. Heck, I'm not an ARRL member and don't even receive QST.  Imagine my
  242. suprise when I started getting these mysterious phone calls "about the
  243. packet article in QST."
  244.  
  245. I am selling off my Amiga system, and no longer have facilities for
  246. copying Amiga disks.  Can only support one computer toy (now a
  247. NeXTstation) at a time...
  248.  
  249. I've already received a number of phone calls from amateurs who read
  250. that article, and I'm hoping to save others spending a few dollars in
  251. long distance charges to talk to my answering machine.
  252.  
  253. I wish authors would try to check this type of information before
  254. publishing it, as I have NEVER offered to to diskette distribution of
  255. the code that I ported even when I did have the facilities to do so..
  256. I suspect people will "discover" this incorrect information in the
  257. article for years to come.  Oh well.
  258.  
  259. As far as I know, the latest work being done on the Amiga version of NOS
  260. is being done by John Heaton, G1YYH, who started with my version and
  261. added his own changes.  I point folks at thumper.bellcore.com in the
  262. anonymous FTP directory /pub/ka9q/amiga for the distributions.  Or, you
  263. might try to contact the author:
  264.  
  265.     John Heaton, G1YYH
  266.  
  267.     Janet:     J.Heaton@uk.ac.MCC           MCC Network Unit (g111)
  268.     DARPA:     J.Heaton@MCC.ac.uk           The University
  269.     AX.25:     g1yyh @ gb7nwp.gbr.eu        Oxford Road
  270.           or   g1yyh @ gb7crg.gbr.eu        Manchester       M13 9PL
  271.     Ampr:      amiga.G1YYH.ampr.org         England
  272.                [44.131.1.71]
  273.  
  274. for other information about his version.
  275.  
  276. 73,
  277. Louis Mamakos
  278. WA3YMH
  279.  
  280. ------------------------------
  281.  
  282. Date: 4 Feb 91 18:52:24 GMT
  283. From: cs.utexas.edu!helios!photon!willis@uunet.uu.net  (Willis Marti)
  284. Subject: PACKET->Internet Gateway
  285. To: packet-radio@ucsd.edu
  286.  
  287. Jon,
  288.   You gave a relatively reasoned response and I'd like to respond.  But 
  289. before I do, let me say why I believe Internet gateways (i.e., routers)
  290. can be legal, even assuming you're 100% correct.
  291.  
  292. First, there are three major services (among many) that are part of the
  293. TCP/IP suite that we'd like to use:
  294. --TELNET {connection to a host}
  295. --FTP {file transfer}
  296. --SMTP {email}
  297. For all except SMTP, it is easy to configure a router so that no one on the
  298. Internet side can initiate a connection.  I then claim that since an
  299. amateur would be initiating the host session and/or file transfer, that
  300. passing traffic back and forth thru the router is within the rules.
  301. For SMTP, one needs a cooperating host on the Internet (a POPmail server)
  302. and the ham can initiate reception of his own email.
  303. If the routing is done by a host, then only one machine is necessary --
  304. though most hosts don't, by default, support the kind of filtering
  305. necessary to prevent Internet initiated connections.
  306.  
  307. Is that satisfactory?
  308.    Willis Marti
  309. ----------------------------------------------------------------------------
  310. In article <446@ultrix.uhasun.hartford.edu>, jbloom@uhasun.hartford.edu (Jon Bloom) writes:
  311. [much quoted material deleted, mostly asserting that repeater operation
  312.   is not comparable to Internet gateway operation - wfm]
  313.  
  314. |> repeater is explicitly allowed [see 97.205(d)].  In the case of the
  315. |> cross-band repeater with an output on 10m, the Technician cannot be
  316. |> the control operator.  Fortunately, since a repeater is allowed to
  317. |> be under automatic control, no control operator is needed.  But if
  318.  
  319. I'll go back and read, but are you saying the rules explicitly say that an
  320. amateur operator can work frequencies on which he doesn't have
  321. privileges, as long as he goes through a repeater belonging to someone else?
  322. Or is that your interpretation?
  323.  
  324. [more things deleted]
  325.  
  326. |> 
  327. |> At the risk of (once again) being accused of being a technology-bashing,
  328. |> Luddite, ARRL old fart, let me try to (once again) explain how it is that
  329. |> the existing rules unfortunately prohibit unattended Internet->AMPR
  330. |> gateways.
  331.  
  332. I'd recommend a couple of books that might help you understand the 
  333. differences in technology, and what can be done to alleviate concerns
  334. instead of just saying "It can't be done.":
  335.  
  336. _Internetworking with TCP/IP_ (1st or 2d edition) by Douglas Comer
  337. _Computer Networks_ (2d edition) by Andrew S. Tanenbaum
  338.  
  339. |> 97.109(e) allows packet stations operating above 50 MHz to pass third-
  340. |> party traffic under automatic control, but "The retransmitted messages
  341. |> must originate at a station that is being locally or remotely controlled."
  342. |> Even worse, messages originated by non-hams (where the notion of a control
  343. |> operator can't possibly be stretched to cover the originator) surely come
  344. |> under the requirements of 97.115(b) which states in part:
  345. |> 
  346. |> (b) The third party may participate in stating the message where:
  347. |>    (1) The control operator is present at the control point and is
  348. |>        continuously *monitoring* and supervising the third party's
  349. |>        participation.  [Emphasis mine.]
  350.  
  351. I think you're stretching it here, unless you consider retrieval of stored, machine readable data to be the same as a live person talking into the mike.
  352.  
  353. ------------------------------
  354.  
  355. Date: 4 Feb 91 23:33:15 GMT
  356. From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu!mig@ucsd.edu  (Meir)
  357. Subject: PACKET->Internet Gateway
  358. To: packet-radio@ucsd.edu
  359.  
  360. In article <446@ultrix.uhasun.hartford.edu> jbloom@uhasun.hartford.edu (Jon Bloom) writes:
  361. >
  362. >This means that, under the current rules, you have to monitor (read)
  363. >the data being sent by the Internet participant.  A bit difficult in
  364. >an IP gateway!
  365. >
  366. Unfortunately, also impossible on high speed AMATEUR data links.
  367. I forsee many legal problems related to that in the near future.
  368. >-- 
  369. >Jon Bloom, KE3Z                              | American Radio Relay League
  370. >Internet: jbloom@uhasun.hartford.edu         |
  371. >Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."
  372.  
  373.  * * * * * * *  ======================= Meir Green                 
  374. * * * * * * * * ======================= mig@cunixb.cc.columbia.edu 
  375.  * * * * * * *  ======================= N2JPG                      
  376.  
  377. ------------------------------
  378.  
  379. Date: 5 Feb 91 18:11:38 GMT
  380. From: brian@ucsd.edu  (Brian Kantor)
  381. Subject: PACKET->Internet Gateway
  382. To: packet-radio@ucsd.edu
  383.  
  384.  
  385.  
  386. ------------------------------
  387.  
  388. Date: 5 Feb 91 04:53:40 GMT
  389. From: snorkelwacker.mit.edu!usc!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!fafnir.la.locus.com!dana@bloom-beacon.mit.edu  (Dana H. Myers)
  390. Subject: The FCC, the rules, and us (longish)
  391. To: packet-radio@ucsd.edu
  392.  
  393.    As many other amateurs are, I'm concerned about the recent
  394. report of citations issued to the operators of automatic Bulletin
  395. Board Systems which automatically forwarded a message with illegal
  396. content. The issue I am concerned about is NOT that of freedom of
  397. speech and selective enforcement of the law by the FCC.
  398.  
  399. [ For those not aware, several operators of packet BBSes on the
  400.   East coast were recently reported to be cited for the content of
  401.   a message soliciting business for an anti-war organization. Though
  402.   the operators of the BBSes did not originate the message, their
  403.   stations transmitted it ]
  404.  
  405.  
  406.   I see several issues at play:
  407.  
  408. -> The message appears to be a truly illegal solicition of money.
  409.  
  410.     The content of the message, as described by a trustworthy source,
  411.   appears to be solicitation of business for a non-amateur radio
  412.   related organization. The rules have always been clear with regards
  413.   to business activity on amateur radio - it is illegal. I don't wish to
  414.   raise the issue of "what is business activity?" here; I think it is
  415.   clear the content of the message in question is outside the bounds
  416.   of what is acceptable. (Frankly, I'm surprised at how many advertisments
  417.   I see on packet where someone has several radios at a time for sale....).
  418.  
  419. -> The message appears anti-war in nature
  420.  
  421.     Granted. The message appears anti-war. The reported citations are not
  422.   for 'treasonous activity' or the like; the poster can pretty much say what
  423.   he wants as long as he doesn't cuss or ask for money.
  424.  
  425. -> It appears the FCC is cracking down on anti-war activity
  426.  
  427.     I doubt the FCC normally cares. I doubt the FCC normally monitors
  428.   packet radio (or any other amateur service).  The FCC appears to want
  429.   amateur radio to 'take care of itself'. My guess is that some *RADIO
  430.   AMATEUR* read that illegal message, and that *RADIO AMATEUR* didn't
  431.   like the commercial nature, and that *RADIO AMATEUR* called the FCC
  432.   up. Furthermore, my guess is that the FCC official who reviewed this
  433.   case decided the message path indicated this illegal message had been
  434.   transmitted from a multiple number of stations. The rules do not
  435.   distinguish between 'originate' and 'transmit'; therefore, everyone
  436.   who transmitted this message is technically in violation of the
  437.   law.
  438.  
  439. -> The FCC rules are deficient.
  440.  
  441.     Currently, the FCC rules do not distinguish between what an operator
  442.   does and a machine does. In all cases, the operator is responsible for
  443.   what is transmitted from a station, though automatic operation is
  444.   allowed. We've had automatic stations for years; conventional repeaters
  445.   are no different than packet BBSes with regards to the ability to
  446.   transmit illegal traffic. What has been different, however, is the
  447.   response of the FCC; when was the last time a repeater operator was
  448.   cited for the activities of a jammer? While I am certain such a thing
  449.   is possible, I've never heard of this case.
  450.  
  451. -> The rules need to relax.
  452.  
  453.     The notion of origination in automatic service needs to be
  454.   formalized. Originators of illegal traffic should be held liable;
  455.   operators of automatic stations who make a 'good faith' effort
  456.   to prevent illegal operation should not be held liable. Origination
  457.   the intentional transmission of a message. Forwarding is the
  458.   automatic re-transmission of a message. In general, a human
  459.   originates; for instance, playing a tape of an illegal message
  460.   over the local repeater would be origination; the repeater in
  461.   question would be forwarding the message (an intermediate issue
  462.   is that of a human who knowingly allows illegal traffic to be
  463.   forwarded - I would think, in the case this is proved, this would
  464.   count as origination).
  465.  
  466. -> Amateurs need to relax
  467.  
  468.     We are basically our own police. If we can't handle things on
  469.   our own, there is no reason to believe the FCC can handle things
  470.   any better. If you see an illegal message on a BBS, CONTACT THE
  471.   INVOLVED PARTIES **BEFORE** CALLING THE FCC!!  Don't just run
  472.   off and call Big Brother! I'm certain some ham thought he was
  473.   doing amateur radio a favor to report the anti-war solicitation of
  474.   money. Think, for a moment, about a parent who really doesn't want
  475.   to be bothered. Consider, for a moment, the errant child and the
  476.   righteous sibling. We've all see this; the righteous sibling goes
  477.   to tattle and the parents, annoyed at the irritation, punish BOTH
  478.   children. THIS WILL HAPPEN TO US!
  479.  
  480.   
  481.   Think this over. We can help shape the amateur radio service of the
  482. next millenia if we act now to petition the FCC to modernize the concepts
  483. used in the rules. If we just squabble and act self-righteously, we'll
  484. ALSO shape our service; likely the same way 220-222 Mhz is shaped.
  485.  
  486.  
  487. -- 
  488.  * Dana H. Myers KK6JQ         | Views expressed here are    *
  489.  * (213) 337-5136         | mine and do not necessarily    *
  490.  * dana@locus.com        | reflect those of my employer    *
  491.  
  492. ------------------------------
  493.  
  494. End of Packet-Radio Digest
  495. ******************************
  496.