Hello Carol.

28 Oct 02 16:31, you wrote to me:

 MG>> This still does not address the problem of marking non-private IP
 MG>> base nodes as PVT. That problem restricts connectivity for IP
 MG>> nodes, causes

 CS> In what way?  I'm not aware of any IP mailers that aviod dialing those
 CS> with the PVT flag header.  They ignore it by policy.

That's the whole point. The authors of IP based mailers are making them
/ignore/ the nodelist, because this non-solution forces them into that
situation. The whole *point* of having a nodelist is so that our mailers
can take cues from it for connectivity. If the mailer ignores the flags
that signify connectivity, then we might as well not even have a nodelist.

 MG>> Your comments that, "Its harmless for an ION and protects
 MG>> stupid POTS people from making mistakes due to them not being
 MG>> setup right" Is inco it *is* harmful to ION's, and your
 MG>> comments also insult the intelligen of POTS nodes at the same
 MG>> time, by assuming that they are so technical inept as to not
 MG>> know how to configure their systems properly. It's far better
 MG>> to /assist/ those who are having trouble to correctly configure
 MG>> their systems, than to make global accomodations for them at
 MG>> the expen of all others, just because you think a few
 MG>> individuals are "stupid".

 CS> No, far too many fear the 000-ip listing due to fears that POTS
 CS> nodes will not block it.  Go deal with those who fear that POTS
 CS> nodes are stupid.

Do North Americans fear the 911- listing? Yet if a node is added in New
Delhi, the listing will start with 91-1*. The argument is rediculous; those
who have 000- in their local areas as the emergency number have an
obligation to ensure their mailers will not dial it. It's /their/
obligation, and /no one/ else's.

Yet you prefer to chain IP mailers to accomodating local obligations.
That's also rediculous.

 CS> I've done far more to 'assist' in this than the vast majority.
 CS> Try writing your own FAQ's on how to help folks to see how hard
 CS> it is to get one out clearly and followable.
 CS> Did you know i also wrote the one for Z1 and how to adapt Makenl
 CS> to above 9600 baud? Notice it worked?

I'm not saying your work wasn't worthwhile; all I'm saying is that by
promoting the "party line", you try to smooth over a problem that
exists, and has existed for quite some time now, and *needs* to be
resolved. We cannot go on treating IP based nodes differently than POTS
based nodes; if not so already, IP based nodes are going to soon make up
the majority of nodes in this network.

It's time to drop this "solution" that is a non-solution, and
look for better ways to solve the problem.

 MG>> I'm quite suprised, being a former RC, that you lack any real
 MG>> insight to this issue. This is a problem that /must/ be dealt with
 MG>> if Fidonet is to move forward; ignoring it just makes things
 MG>> worse. The PVT kludg is /unacceptable/, and a much better solution
 MG>> needs to be found.

 CS> Check into Makenl and how to list a node who has no phone
 CS> number.  The only acceptable sub is a *STATIC* Ip address.  That
 CS> has to be preceeded by a non-country code to prevent accidental
 CS> dialing.  So far, no one has come up with one other than 000.
 CS> 000 is problematic if dialed wrongly from within OZ but no
 CS> problem outside it as it doesnt have the OZ dialcode appended
 CS> before it.

So re-write MakeNL already. There is some source available, and it's not
such a complicated task; those writing IP based mailers have a far more
difficult task before them, trying to decipher the confusion over flag use
and decide if their mailer should read a flag or ignore it. The answer
should be simple; /all/ mailers /should/ read /all/ flags, and each flag
should have /one/ meaning, and /not/ dual meanings depending on connection
method.

 CS> Equally bad are the Z1 sites who are adding 1- to the 000 set.
 CS> Thatcan cause dialing of the operator in the USA from outside
 CS> USA.  BAD JUJU!!!

Again, that is a local peculiarity, and it is the obligation of those
affected to know their local phone company's policy, and to make
accomodations for it. The nodelist is *not* there to make those local
accomodations for members of this network; it's there for our mailers to
use as a guide to communicate in the most efficient manner possible. Once
you start to make accomodations for localities in the nodelist, where does
it stop? What if the phone company in some small country starts doing
something strange tomorrow? if we have a node listed there, do we make a
new accomodation, or expect the node to make the accomodation?

*Every* member of this network has the obligation to ensure their mailer
complies with their local phone company's policy and local laws, otherwise
they ought not to be running a mailer. Any cost incurred by their
mis-configuration is their /own fault/, and is /not/ the fault of any
listing. To push the idea that anything else is true is to shirk the
individual's responsibility.


--- GoldED/386 3.0.1-dam3