Text 999, 114 rader
Skriven 2012-07-20 19:08:19 av mark lewis (1:3634/12.0)
    Kommentar till text 967 av Michiel van der Vlist (2:280/5555)
Ärende: dupes!
==============
 MvdV>> The only one I now of now is 250/1.  RC25 had the opportunity
 MvdV>> to prevent this when renumbering the region to a single net. He
 MvdV>> missed out. His bad.

 ml> there is no restrictions on it...

 MvdV> There should be...

why?

 ml> it can and may very well come up again... why waste numbers by
 ml> skipping them if there is no good reason?

 MvdV> 1) Wasting is only a problem when there is shortage. There is no
 MvdV> shortage of Fidonet node numers, even if we only use 2D
 MvdV> numbering.

nonsequiter...

 MvdV> 2) There is a good reason to avoid duplicate net/node
 MvdV> combinations. 

there is no problem with duplicate 2d addresses as long as things are handled
properly and take them into consideration... those throwing 20+ years of
practise and esperience out the window are causing or going to cause problems
for everyone else...

 MvdV> When introducing zones, a basic flaw in echomail distribution was
 MvdV> introduced by not upgrading the seen-by and path infornation to
 MvdV> 3D. Avoiding duplicate net/node combinations is a workaround for
 MvdV> this flaw.

i understand this and i've participated in the discussions and arguments on
both sides of this many years ago... long before you came out of Z2 and into
the development side of fidonet... there were numerous long and very heated
discussions on this very topic...

 MvdV>> Plus that 1:250/1 is an administrative AKA that should not be
 MvdV>> used in echomail anyway.

 ml> really? why?

 MvdV> P4 3.4

 MvdV> Coordinators are discouraged from acting as echomail and
 MvdV> software-distri- bution hubs.  If they do so, they should handle
 MvdV> echomail (or other volume distribution) on a system other than
 MvdV> the administrative system.  A coordina- tor's system should be
 MvdV> readily available to the levels immediately above and below.

agreed... so who is going to file a PC about it? there are several doing just
this... at least one or two in Z2 and one of those very well known...

 ml>  and if this is so, how come 2:203/0 is in the path and seenby lines?

 MvdV> Someone is not following that part of P4.

obviously ;)

 ml> if they are not to be used in echomail then that would include all
 ml> aspects of echomail, would it not?

 MvdV> Yes.

ok...

 MvdV> Other than that: 1:250/1 is a vanity listing, The NEC user flag
 MvdV> in (one of) the regular listing(s) of the NEC suffices to
 MvdV> identify the NEC.

nonsequiter...

 ml>> some are reporting that posts are still not propagating fully...
 ml>> this is one possible reason for such...

 MvdV>> No, that is not the reason.

 ml> you say that as if you know the reason...

 MvdV> You are jumping to conclusions. 

no i'm not... you flatly state that that is not the reason... you cannot know
this unless you do know the reason, can you?

 MvdV> It is very well possible to eliminate one or more items from a 
 MvdV> list of possible causes, without eliminating all but one. 

of course...

 MvdV>> The very few duplicates are not involved.

 MvdV> The duplicate net/number combination(s).

 ml> it isn't the duplicates that are the problem... it is the lack of full
 ml> propogation that is the problem... there are only so many reasons for
 ml> this...

 MvdV> And I have eliminated the duplicate of 1:250/1 and 2:250/1 from
 MvdV> my list. 

that system is not involved in the lack of message flow that others are
reporting...

 MvdV> Still on my list are:

 MvdV> A) Messages are lost at 1:140/1. This is known to have happened
 MvdV> before. B) Someone is censoring this echo. It is known to have
 MvdV> happened before. 

are those the only two items on that list?

)\/(ark

 * Origin:  (1:3634/12)