<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=US-ASCII" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 9.00.8112.16464"></HEAD>
<BODY style="FONT-FAMILY: Arial; COLOR: #000000; FONT-SIZE: 10pt" id=role_body 
bottomMargin=7 leftMargin=7 rightMargin=7 topMargin=7><FONT id=role_document 
color=#000000 size=2 face=Arial>
<DIV>I don't understand why you don't get it.  It is LEGAL TO ORDER PIZZA 
ON HAM RADIO unless you own or work for the pizza business.  PERIOD.  
<BR><BR>If you  are a pizza delivery driver you can't use amateur radio to 
get direction to a customer.</DIV>
<DIV> </DIV>
<DIV>We have swap net on amateur radio.  We talk about money on the 
air.  This is OK TOO!</DIV>
<DIV> </DIV>
<DIV>Daniel Stevens, KL7WM</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>
<DIV>In a message dated 2/20/2013 11:38:40 P.M. Pacific Standard Time, 
cory@nq1e.hm writes:</DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: blue 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px"><FONT 
  style="BACKGROUND-COLOR: transparent" color=#000000 size=2 face=Arial>
  <DIV dir=ltr>It appears that we're getting our layers mixed up. 
  <DIV><BR></DIV>
  <DIV>Phone patches to the pizza place are legitimate because the patching 
  system itself is run by a licensed control operator.  In this case, the 
  RF link is layer 1 and the phone call is at least layer 3.  The rules are 
  for governing who gets to use layer 1 and for what purpose.  It would be 
  totally inappropriate for a pizza place to get a radio and camp on a frequency 
  for the purpose of accepting orders.  However, contacting another ham and 
  asking them to order a pizza for you on their phone (or giving you an auto 
  patch to do it yourself) is appropriate because the RF portion is 
  still ham-to-ham, even if the message being relayed is not.</DIV>
  <DIV><BR></DIV>
  <DIV>The same goes for "broadcasting".  Your transmission must be 
  intended for one or more hams, even if the message must be relayed by them to 
  reach its final destination.  If you knew the general public all had 
  scanners tuned to a ham frequency, it would not be appropriate to create your 
  own radio show meant for them.<BR></DIV>
  <DIV><BR></DIV>
  <DIV>Regarding AAA, I think we were also thinking about different layers. 
   Securing the configuration of a network device and providing "security" 
  for a network service (think SSL/TLS) is quite a bit different.  I 
  was referring to the latter.</DIV>
  <DIV><BR></DIV>
  <DIV>Using IPSec(AH) is a very good idea.</DIV>
  <DIV><BR></DIV>
  <DIV>I have high hopes that this will all work out.  It sounds like so 
  much fun, I can't contain myself! ;)</DIV>
  <DIV><BR></DIV>
  <DIV>-Cory</DIV>
  <DIV><BR></DIV></DIV>
  <DIV class=gmail_extra><BR><BR>
  <DIV class=gmail_quote>On Wed, Feb 20, 2013 at 9:55 PM, Bart Kus <SPAN 
  dir=ltr><<A title=mailto:me@bartk.us href="mailto:me@bartk.us" 
  target=_blank>me@bartk.us</A>></SPAN> wrote:<BR>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
  class=gmail_quote>
    <DIV text="#000000" bgcolor="#FFFFFF">
    <DIV>First of all, +1, Informative. 
    <DIV class=im><BR><BR>On 2/20/2013 11:22 AM, Cory (NQ1E) 
    wrote:<BR></DIV></DIV>
    <DIV class=im>
    <BLOCKQUOTE type="cite">
      <DIV dir=ltr>It's not just optimization.  We have serious 
      restrictions on what type of content can be moved over our RF links. 
       Everyone who runs a device that transmits is responsible for its 
      operation.  Luckily there is precedent here since each node 
      can be considered the same as a "digital packet repeater" in historical 
      context.  In those cases, the repeater operator is not held liable 
      for illegal content relayed through them as long as they take "reasonable 
      measures" to limit it and when discovered, stop it. 
      <DIV><BR></DIV>
      <DIV>While it's not preferable to get into the distributed firewall 
      business, it may be necessary if this network carries traffic to or from 
      the internet.  If we had another "reasonable" way to make sure only 
      licensed hams were able to originate content on the network, firewalls 
      likely wouldn't be needed.</DIV>
      <DIV><BR></DIV></DIV></BLOCKQUOTE><BR></DIV>I think of the case of an audio 
    repeater phone patch.  A ham can call someone via hammy spectrum, but 
    the return voice traffic may not belong to a ham.  This has been 
    allowed in the past as fair use.<BR><BR>Now if we tweak the scenario and say 
    the phone call is originally inbound from the repeater to the ham by a 
    non-ham, but consists of content which the ham (in control of hanging up) 
    considers appropriate as per the hammy rules of airwave content, should the 
    conversation be allowed to continue? :)  My read on this is yes.  
    99% of the airtime will be the bidirectional content of the conversation, 
    just as it is in the outbound case.  As long as this content is in 
    compliance with ham law, it ought not matter who sent the original 
    ring.<BR><BR>The next step in this line of thinking is to translate the 
    concepts of the analog telephone call to that of opening a digital inbound 
    TCP session to a ham server.  It's up to the ham who is hosting the 
    server to ensure that the content of such conversations complies with ham 
    rules.  Hang up (TCP RST) the session if the content goes outside the 
    law.  The role of HamWAN is simply to facilitate the exchange of 
    signals, and we're not held responsible (as per voice repeater rules) should 
    hams decide to break the rules of content.<BR><BR>There is of course that 
    little lingering issue of the initial unsolicited ring in the analog world, 
    or TCP SYN in the digital world making its way onto hammy spectrum.  I 
    like to think HamWAN could even set some useful precedent here, by 
    delivering worthy use-cases, and perhaps cause an eventual tweak to the 
    official rules to allow for short control messages ("I would like to talk") 
    to be sent over hammy spectrum by non-hammies.<BR><BR>Another way of 
    thinking about this inbound ring from non-hams is that while the actual ring 
    is received by ham equipment (repeater / digital microwave router) on a 
    non-hammy medium (telco / ISP network), the hammy RF spectrum transmission 
    from the repeater or digital microwave router is not a signal relay, but 
    rather a whole new communication, initiated by a ham-licensed station (the 
    repeater and its owner) to inform the target ham of the presence of an 
    inbound message on the non-hammy medium, and is therefore ham2ham traffic 
    after all!<BR><BR>We can do these legal mental gymnastics for a long time, 
    but the bottom line is unless someone actually complains and the FCC decides 
    to care, we should just go on and operate instead of shying away in 
    fear.  If the practices are eventually ruled as illegal, we can cease 
    such operations easily by applying new firewall rules.  I hope it does 
    not come to that as it would greatly stall the progress of digital ham 
    radio. 
    <DIV class=im><BR><BR>
    <BLOCKQUOTE type="cite">
      <DIV dir=ltr>
      <DIV>In a somewhat related issue, there is also precedent for hams using 
      encrypted WiFi links with part 97 rules.  Supposedly, it's only 
      acceptable to encrypt when the purpose is not to hide the content of your 
      message.  This means that it's okay to run encryption as long you 
      publish the decryption keys so that they could be found by the public 
      (negating the point of using encryption in most cases).</DIV>
      <DIV><BR></DIV></DIV></BLOCKQUOTE><BR></DIV>Agreed, and I know of people who 
    do this with P25 gear.  But I don't see any useful cases in which 
    HamWAN could make use of encryption while publishing the keys. 
    <DIV class=im><BR><BR>
    <BLOCKQUOTE type="cite">
      <DIV dir=ltr>
      <DIV>The frequencies that we're allowed to use as licensed radio amateurs 
      belong to the public and we're allowed to use them for the purposes of 
      experimentation and communication with other amateurs.  In order to 
      assure the fair use of such a valuable resource, we have to follow 
      strict rules that prevent commercial interests from taking over. 
       That's why we're not allowed to conduct business on the air or 
      communicate with the general public (broadcast).  That's also why 
      it's important that anything transmitted is not intentionally obfuscated 
      from anyone else's ability to view it.</DIV>
      <DIV><BR></DIV></DIV></BLOCKQUOTE><BR></DIV>I see the <A 
    title=http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&SID=ad552c047464dd8e611924492c5b41c6&rgn=div5&view=text&node=47:5.0.1.1.6&idno=47#47:5.0.1.1.6.1.157.2 
    href="http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&SID=ad552c047464dd8e611924492c5b41c6&rgn=div5&view=text&node=47:5.0.1.1.6&idno=47#47:5.0.1.1.6.1.157.2" 
    target=_blank>definition of broadcast</A> you cite there, and boy is that a 
    weird one.  I'd counter this with my phone patch example, and cite the 
    <A title=http://www.arrl.org/phone-patch-guidelines 
    href="http://www.arrl.org/phone-patch-guidelines" target=_blank>ARRL 
    guidance</A> on the matter, which allow communication with non-amateur third 
    parties (is that the same as "general public"?).  In fact, the ARRL 
    guidance counters what has been said about commercial communications in a 
    previous thread:<BR><BR><SMALL><FONT 
    face="Courier New, Courier, monospace">Calls to place an order for a 
    commercial product may be made such as the proverbial call to the pizza 
    restaurant to order food, but not calls to one's office to receive or to 
    leave business messages since communications on behalf of ones employer are 
    not permitted.<BR></FONT></SMALL><BR>The ARRL guidance on reverse autopatch 
    (inbound TCP) actually runs counter to my views on the subject.  In 
    part, it states:<BR><BR><SMALL><FONT 
    face="Courier New, Courier, monospace">Incoming calls to an autopatch must 
    be answered and screened off the air by the control operator to ensure rule 
    compliance. If an incoming call automatically causes the repeater to 
    transmit, even if it's just a signal tone or notification message, then it 
    is possible for an unlicensed person to initiate a transmission without the 
    control operator's knowledge or approval, which is not 
    permitted.<BR></FONT></SMALL><BR>This to me sounds like we absolutely need a 
    ham-controlled edge firewall mechanism to "screen the calls off the air" as 
    per the individual hams' specifications.<BR><BR>One thing is for sure: we're 
    in brand new territory.  We need to tread with the utmost character so 
    we set a good example for others who follow us. 
    <DIV class=im><BR><BR>
    <BLOCKQUOTE type="cite">
      <DIV dir=ltr>
      <DIV>As a long-time computer engineer with a strong emphasis on 
      security, the idea of having such an open network is very scary to me. 
       However, it's also why I'm excited about the challenge.  When 
      most people think about security, they only think about secrecy (hiding 
      your messages).  However, security also includes authentication 
      (making sure messages really come from the intended sender) and integrity 
      (has this message been altered in transit).  With those two aspects 
      and a lot of help from public key cryptography, my hope is to contribute 
      to making a network that is both open *and* secure.</DIV>
      <DIV><BR></DIV>
      <DIV>I've already made some strides in this area for other ham-related 
      projects of mine, and now I'm hoping to translate that to the needs of the 
      overall network.</DIV>
      <DIV><BR></DIV></DIV></BLOCKQUOTE><BR></DIV>This is exactly right.  
    Well, almost.  :)  Cisco's thinking gets it right when they refer 
    to AAA: Authentication, Authorization and Accounting.  For anyone 
    unfamiliar with what these concepts mean exactly, can <A 
    title=http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfaaa.html#wp1000889 
    href="http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfaaa.html#wp1000889" 
    target=_blank>refer to this page</A>.  Also Wikipedia has a <A 
    title=http://en.wikipedia.org/wiki/AAA_protocol 
    href="http://en.wikipedia.org/wiki/AAA_protocol" target=_blank>page on 
    AAA</A>.  The additional point you make about Integrity may not 
    necessarily fall under the "Authentication" concept, since that deals more 
    with actors in a network rather than the non-molestation of their messages, 
    but can be served nicely by an implementation of <A 
    title=http://en.wikipedia.org/wiki/Ipsec#Authentication_Header 
    href="http://en.wikipedia.org/wiki/Ipsec#Authentication_Header" 
    target=_blank>IPSec in AH mode</A>.<BR><BR>Tons of work here for sure, after 
    the lower layers of the network (RF) are up and running.<SPAN 
    class=HOEnZb><FONT color=#888888><BR><BR>--Bart</FONT></SPAN> 
    <DIV>
    <DIV class=h5><BR><BR><BR><BR><BR><BR><BR><BR>
    <BLOCKQUOTE type="cite">
      <DIV dir=ltr>
      <DIV><BR></DIV>
      <DIV><BR></DIV></DIV>
      <DIV class=gmail_extra><BR><BR>
      <DIV class=gmail_quote>On Wed, Feb 20, 2013 at 12:16 AM, Bart Kus <SPAN 
      dir=ltr><<A title=mailto:me@bartk.us href="mailto:me@bartk.us" 
      target=_blank>me@bartk.us</A>></SPAN> wrote:<BR>
      <BLOCKQUOTE 
      style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
      class=gmail_quote>
        <DIV text="#000000" bgcolor="#FFFFFF">
        <DIV>It's just a little more efficient to stop unwanted traffic early, 
        before it takes up a bunch of airtime.  Just an optimization, which 
        may not be worth the complexity right up front.  Your suggestion 
        works too.<SPAN><FONT color=#888888><BR><BR>--Bart</FONT></SPAN> 
        <DIV>
        <DIV><BR><BR>On 2/19/2013 8:46 PM, Benjamin Krueger 
        wrote:<BR></DIV></DIV></DIV>
        <DIV>
        <DIV>
        <BLOCKQUOTE type="cite">
          <DIV dir=ltr>Just saw this, "just needs to push an ACL update". Why 
          can't we just route all traffic and let the client nodes run their own 
          firewalls? We *really* don't want to be in the distributed firewall 
          business. :)</DIV>
          <DIV class=gmail_extra><BR><BR>
          <DIV class=gmail_quote>On Wed, Feb 13, 2013 at 4:04 PM, Bart Kus <SPAN 
          dir=ltr><<A title=mailto:me@bartk.us href="mailto:me@bartk.us" 
          target=_blank>me@bartk.us</A>></SPAN> wrote:<BR>
          <BLOCKQUOTE 
          style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
          class=gmail_quote>
            <DIV text="#000000" bgcolor="#FFFFFF">
            <DIV>Global reachability is not in conflict with autonomy.  
            Achieving both simultaneously just requires careful design of HamWAN 
            network services.  If the HamWAN internet feed drops off, the 
            routing, DNS and other services need to continue working.  The 
            first word in ASN is Autonomous after all. :)<BR><BR>I consider NAT 
            and Proxies as old crusty hacks from the age of ISPs giving out just 
            1 IP/customer.  It's time to put these ideas to rest.  
            IPv6 will do this on the commercial internet in the coming years, 
            and AMPRnet will allow us to do it immediately here.  For the 
            cases where communication is to be restricted due to user 
            preference, we can push filtering rules to firewalls at the edges of 
            the network, and at the HamWAN <-> user site interface.  
            In short, firewalls: yes, nat+gateways: no.<BR><BR>If a user wants 
            to make a service running on one of his servers public, he just 
            needs to push an ACL update to HamWAN and it'll be opened up.  
            No need to re-IP, update DNS, change NICs, whatever else.  And 
            most importantly, it makes everyone equal.  Your subnet 
            allocation has the same powers as mine.  There is no special 
            ground to fight over, such as space on a public subnet, or access to 
            some officially sanctioned gateway servers that are allowed to do 
            special things.<BR><BR>If you want though, you can of course live in 
            the world of private IPs and NAT.  Just configure your LAN 
            router that way.<BR><BR>Complete freedom of configuration.  
            This is the way the internet should have evolved for 
            geeks!<SPAN><FONT color=#888888><BR><BR>--Bart</FONT></SPAN> 
            <DIV>
            <DIV><BR><BR><BR>On 2/13/2013 8:30 AM, Cory (NQ1E) 
            wrote:<BR></DIV></DIV></DIV>
            <DIV>
            <DIV>
            <BLOCKQUOTE type="cite">
              <DIV dir=ltr>Unless I've misunderstood the point of this network 
              all together, there shouldn't be a case where we want the entire 
              network address space to be reachable from the global internet. 
               It's much more likely that the network will remain as 
              autonomous as possible and any connections to the internet will be 
              for connecting specific services through a gateway of some sort. 
              <DIV><BR></DIV>
              <DIV>A subnet of at least /23 (typical minimum for global BGP 
              announcements) should be reserved for the purpose of being 
              globally routable in the future, if/when HamWAN decides 
              to peer with one or more ISPs.  An address in the /23 can be 
              given to each service gateway for connecting to the 
internet.</DIV>
              <DIV><BR></DIV>
              <DIV>The rest of the 44-net allocation can be treated as private 
              address space, except that it's 
              essentially guaranteed not to cause conflicts with the 
              user-level networks since it's still globally unique.</DIV>
              <DIV><BR></DIV></DIV>
              <DIV class=gmail_extra><BR><BR>
              <DIV class=gmail_quote>On Wed, Feb 13, 2013 at 2:28 AM, Bart Kus 
              <SPAN dir=ltr><<A title=mailto:me@bartk.us 
              href="mailto:me@bartk.us" target=_blank>me@bartk.us</A>></SPAN> 
              wrote:<BR>
              <BLOCKQUOTE 
              style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
              class=gmail_quote>
                <DIV text="#000000" bgcolor="#FFFFFF">
                <DIV>Clever ;)<BR><BR>What if HamWAN switches ISPs?  All 
                that IPv6 space would need to be given up.  It can't follow 
                you AFAIK.  Or the ISP may charge whatever they feel like 
                to let you take it with you.  Also bad.<BR><BR>The fees for 
                IPv6 are not as low as I had hoped, but not as high as you think 
                either!  There's a 25% discount in effect for "extra-small" 
                allocations (which are still larger than the entire IPv4 
                internet).  The cost looks to be $937.50/yr.  Not sure 
                it's worth the cost, given the IPv4 AMPRnet situation.  We 
                can very likely just expand our AMPRnet allocation if we 
                out-grow the /20.<SPAN><FONT 
                color=#888888><BR><BR>--Bart</FONT></SPAN> 
                <DIV>
                <DIV><BR><BR><BR>On 2/13/2013 1:10 AM, Cory (NQ1E) 
                wrote:<BR></DIV></DIV></DIV>
                <DIV>
                <DIV>
                <BLOCKQUOTE type="cite">
                  <DIV dir=ltr>Here's an IPv6 allocation for you ;) 
                  <DIV><BR></DIV>
                  <DIV>::ffff:<A title=http://44.24.240.0/116 
                  href="http://44.24.240.0/116" 
                  target=_blank>44.24.240.0/116</A></DIV>
                  <DIV><BR></DIV>
                  <DIV>With the obvious exception of AMPRNet addresses for 
                  amateur radio use, IP allocations should come from an ISP. 
                   Obtaining a direct allocation from ARIN would cost 
                  around a couple grand per year.</DIV></DIV>
                  <DIV class=gmail_extra><BR><BR>
                  <DIV class=gmail_quote>On Wed, Feb 13, 2013 at 12:46 AM, Bart 
                  Kus <SPAN dir=ltr><<A title=mailto:me@bartk.us 
                  href="mailto:me@bartk.us" 
                  target=_blank>me@bartk.us</A>></SPAN> wrote:<BR>
                  <BLOCKQUOTE 
                  style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                  class=gmail_quote>Result: APPROVED<BR>Your allocated subnet 
                    is: <A title="tel:44.24.240.0 / 20" 
                    href="tel:44.24.240.0%20%2F%2020" target=_blank 
                    value="+14424240020">44.24.240.0 / 20</A><BR><BR><A 
                    title=https://portal.ampr.org/networks.php?a=region&id=191 
                    href="https://portal.ampr.org/networks.php?a=region&id=191" 
                    target=_blank>https://portal.ampr.org/networks.php?a=region&id=191</A><BR><BR>HamWAN 
                    now has 4096 real Internet IPs to play with.  Next up: 
                    we gotta crack the mystery of getting IPv6 net space. 
                     Any volunteers? :)<BR><BR>What an incredibly 
                    productive 
                    day,<BR><BR>--Bart<BR><BR><BR>_______________________________________________<BR>PSDR 
                    mailing list<BR><A title=mailto:PSDR@hamwan.org 
                    href="mailto:PSDR@hamwan.org" 
                    target=_blank>PSDR@hamwan.org</A><BR><A 
                    title=http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org 
                    href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" 
                    target=_blank>http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</A><BR></BLOCKQUOTE></DIV><BR></DIV><BR>
                  <FIELDSET></FIELDSET> <BR><PRE>_______________________________________________
PSDR mailing list
<A title=mailto:PSDR@hamwan.org href="mailto:PSDR@hamwan.org" target=_blank>PSDR@hamwan.org</A>
<A title=http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target=_blank>http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</A>
</PRE></BLOCKQUOTE><BR></DIV></DIV></DIV><BR>_______________________________________________<BR>PSDR 
                mailing list<BR><A title=mailto:PSDR@hamwan.org 
                href="mailto:PSDR@hamwan.org" 
                target=_blank>PSDR@hamwan.org</A><BR><A 
                title=http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org 
                href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" 
                target=_blank>http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</A><BR><BR></BLOCKQUOTE></DIV><BR></DIV><BR>
              <FIELDSET></FIELDSET> <BR><PRE>_______________________________________________
PSDR mailing list
<A title=mailto:PSDR@hamwan.org href="mailto:PSDR@hamwan.org" target=_blank>PSDR@hamwan.org</A>
<A title=http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target=_blank>http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</A>
</PRE></BLOCKQUOTE><BR></DIV></DIV></DIV><BR>_______________________________________________<BR>PSDR 
            mailing list<BR><A title=mailto:PSDR@hamwan.org 
            href="mailto:PSDR@hamwan.org" 
            target=_blank>PSDR@hamwan.org</A><BR><A 
            title=http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org 
            href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" 
            target=_blank>http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</A><BR><BR></BLOCKQUOTE></DIV><BR><BR 
          clear=all>
          <DIV><BR></DIV>-- <BR>
          <DIV dir=ltr>Benjamin<BR></DIV></DIV><BR>
          <FIELDSET></FIELDSET> <BR><PRE>_______________________________________________
PSDR mailing list
<A title=mailto:PSDR@hamwan.org href="mailto:PSDR@hamwan.org" target=_blank>PSDR@hamwan.org</A>
<A title=http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target=_blank>http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</A>
</PRE></BLOCKQUOTE><BR></DIV></DIV></DIV><BR>_______________________________________________<BR>PSDR 
        mailing list<BR><A title=mailto:PSDR@hamwan.org 
        href="mailto:PSDR@hamwan.org" target=_blank>PSDR@hamwan.org</A><BR><A 
        title=http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org 
        href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" 
        target=_blank>http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</A><BR><BR></BLOCKQUOTE></DIV><BR></DIV><BR>
      <FIELDSET></FIELDSET> <BR><PRE>_______________________________________________
PSDR mailing list
<A title=mailto:PSDR@hamwan.org href="mailto:PSDR@hamwan.org" target=_blank>PSDR@hamwan.org</A>
<A title=http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target=_blank>http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</A>
</PRE></BLOCKQUOTE><BR></DIV></DIV></DIV><BR>_______________________________________________<BR>PSDR 
    mailing list<BR><A title=mailto:PSDR@hamwan.org 
    href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</A><BR><A 
    title=http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org 
    href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" 
    target=_blank>http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</A><BR><BR></BLOCKQUOTE></DIV><BR></DIV><BR><BR>_______________________________________________<BR>PSDR 
  mailing 
  list<BR>PSDR@hamwan.org<BR>http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org<BR></FONT></BLOCKQUOTE></DIV></FONT></BODY></HTML>