Text 3868, 170 rader
Skriven 2012-09-13 14:12:11 av mark lewis (1:3634/12.0)
   Kommentar till text 3361 av Robert Bashe (2:2448/44)
Ärende: Pvt nodes vs points
===========================
RB>> As described. I simply do not believe that _all_ the various methods
RB>> of listing domains will be covered by such a "selection" program.

ml> dude... there's only two or three places that the domains can be
ml> listed...

 RB> "Dude" - that was exactly my point. Why not agree on _one_ place
 RB> and make things easier for everybody?

the "agreement" has already been made years ago and it has been accepted and
documented by the FTSC... there is no "formal this is what we agree to" type of
document... the developers came up with the idea and implemented the code...
they discussed problems and situations and developed more code... that's how it
was done... the best idea, IMO, was trashed by politicos and sundry others and
the developers who could, would, and wanted to help further the network simply
left and left everyone else holding the bag to figure out on their own... i'm
one of the few remaining ones even willing to talk about the shit and try to
help others understand how we got here and why we are here in the first
place...

RB>>> ,290,Wueppel-BBS,Merzenich,Doris_Schmitz,49-2421-981180,9600,MO,C M,
RB>>> XA,V32B,V34, X75,IBN:24555,INA:wueppel.doene.de

ml>> this one is basically backwards...

RB>> May be, but it exists. That's the point of what I wrote above.

ml> has anyone contacted that NC and pointed out that it is backwards?

 RB> Whose job is that? 

everyone's job if they pay attention to things and have a helping nature and
offer assistance to others so they won't keep making the same mistake(s)... or
would you rather just complain about it and not let them know about the
problem? if you really feel that it should be formal, then let the RC and ZC
know as well as the NC... dress it all up in fancy words and a new outfit with
a black tie... or just write a quick netmail to that NC and say, "hey, this
entry is slightly out of kilter. here's how it should look" but i can see where
that's kinda hard to do if one doesn't know how it should look to start with...

 RB> If someone has problems contacting the node, they'll complain. I 
 RB> don't go running around checking the nodelist for proper usage 
 RB> just because I have nothing else to do. Note that I found this 
 RB> example by pure chance, just glancing through the nodelist.

exactly how i've found many of those that i've sent notes about... not only
there but also looking in the binkd.txt file and the associated except.txt
file... some things in except are not really exceptions but that script has
thrown them out... but those two files are good sources of things to look at
out of curiousity...

RB>> And my comment about agreeing on a _binding_ method of including
RB>> domains in a nodelist entry stands. In my opinion, that would be the
RB>> key to preparing a really reliable "include" list for binkd.

ml> there is a "binding" agreement... it is detailed in the FTS document
ml> describing the nodelist...

 RB> And then you remark that there are multiple places where a domain
 RB> can be entered in the nodelist. A "binding agreement" to do what
 RB> you please isn't exactly what I had in mind.

you are expecting too much and too late... the developers already made the
decisions years ago and then many of them left because of others doing
everything they could to stifle the advancement of the technology... now what
do we have? a huge majority of systems using exactly that type of technology
that was being stifled and only one or two really decent and working
packages... but has anyone really taken notice of the deeper rooted problems?
no... they haven't... their loss...

[...]

ml>> it is even moreso not required with the f.n.z conversion that is
ml>> default...

RB>> Assuming anyone knows what domain that's supposed to go to.

ml> i've been telling folks and the binkd guys have as well since they are
ml> the ones handling that stuff... unfortunately those using other
ml> software that can't change the base domain for f.n.z lookups have a
ml> problem... all lookups of *.fidonet.net return the same IP number...

 RB> The binkd.cfg I got with my copy, admittedly a while ago, includes:

root-domain is the one in question... root-domain should be binkp.net...
everything else is for the network in question...

 RB> domain fidonet \\fido\\outbound\\fidonet 2
 RB> domain fido alias-for fidonet
 RB> domain fidonet.org alias-for fidonet

you don't have fidonet.net alias-for or fido.net alias-for? those are all
examples of folks not paying attention and just doing what the hell they wanted
and then it spreading all over the place even though it is/was quite wrong...
it is just as bad that folks can't understand the difference between a domain
with a dot and those without them like netbios, netbeui and novell networks
use... even worse that these networks are used all the time by folk every day
and they don't even know it :?

there are at least four (4) alias-for lines for fidonet that i'm aware of...

domain fido alias-for fidonet
domain fido.net alias-for fidonet
domain fidonet.org alias-for fidonet
domain fidonet.net alias-for fidonet

remember, too, that that example config is/was exactly that... an example... it
was never said to be complete ;)

 RB> Most people, like me, will simply accept that without change. Now
 RB> tell me if fidonet.org still exists and is operative.

fidonet.org has nothing to do with mail transportation... it never has...
that's what fidonet.net was for... fidonet.org came later and is, as the TLD
(Top Level Domain) extension indicates, about the ORGanization... it and others
came along when there was the rush to grab up fidonet.* so that folks could
have their feel-good moment and contribution to (or confoundment of) the
network...

ml>> ... in fact, with so many folks using binkd and the f.n.z
ml>> conversion...

RB>> Binkd yes, the f.n.z. conversion absolutely no. Maybe where you are,
RB>> certainly not here.

ml> binkd has it built in and uses it even if you don't... to be more
ml> specific, it uses it each and every time there's a connection and the
ml> AKAs are presented... you cannot prevent that... it /is/ used, period!

 RB> May be, but you still can't contact anyone with binkd without
 RB> specifying a domain in the configuration or an "include" file. If
 RB> you can, it'd be new to me. 

so have you actually tried it yet?

1:120/419 is the first entry in binkd.txt without a domain specified... that's
one of jame (RJ) clay's systems... he is the z1 maintainer of the binkp.net DNS
zone... but that machine is an eeePC and IPv6 so there may not be an IPv4 entry
for it... there definitely shouldn't be any entry if it is dynamic and offline
which is when i'm seeing now from my IPv4 only system...

the next ones are 1:2320/100 and 300 but they are both listed as down... then
there's 1:14/0, 1:138/389, 1:130/41 and then we start with z2 systems... the
first three of those all being in Dresden and operated by the same individual
who is also the NC of 2:249... 2:249/1, 2, and 3... then 2:2426/3, 2:2432/715,
2:2432/900... 2:2448/0 also shows IBN with no domain as does 600 and 615... all
three run by the same person... i'll stop there as the next is region 31 and
i'm not going to keep manually going thru both lists (day 209's binkd.txt and
the current nodelist.251) in two windows looking at the entries and then trying
DNS lookups on them from a third command line window...

there's no way, at this point, to tell if these nodes are DOWN and gone OR
simply misconfigured in the nodelist OR if they are dynamic and offline at the
time of my lookups...

ml> i keep telling you this but you refuse to accept it :sigh:

 RB> As you refuse to accept that PVT nodes are essentially identical to
 RB> sysop points unless the PVT node (as here) includes a domain to
 RB> allow it to be crashmailed ;-) We all have our problems.

that's political and/or opinion... the f.n.z in binkd is not... it is an
operational fact... and attempting to compare the two are as wrong as comparing
apples and oranges...

besides, i've never stated that i refuse to accept that...

)\/(ark

 * Origin:  (1:3634/12)