Text 1470, 106 rader
Skriven 2008-03-24 20:14:10 av Carol Shenkenberger (402.ftsc_pub)
   Kommentar till text 1436 av Alexey Vissarionov (2:5020/545)
Ärende: Proper nodelist format for Internet-only nodes?
=======================================================
    
 >  >>>> INA is the proper place for a host name. If something has be changed
 >  >>>> in the above example, that is s/000-0-0-0-0/-Unpublished-/
 >  >>> Janis has to tell folks in Z1 that it's ok to start doing that first.
 >  >> Why that isn't done, then?
 >  CS> The way the software works, it has to be a top down change. It's like
 >  CS> when we put in the bit to allow above 9600 speeds to be listed. If an
 >  CS> NC did it and the RC wasnt set, the NC's segment update failed.
 > 
 > That would be the RC's fault.

No, first Janis has to know the ZC's can process the Z1 segment (or in your
case, Ward has to know the others can process his).

Then they make sure the RC's are ready.  Then it's 'open season' and you will
start seeing both mixed until everyone catches up and the old 000-'s are
gone.


 >  CS> Janis may or may not have coordinated the shift with the other ZC's
 >  CS> yet or it may be in progress. I don't know. Once she's ready (or in
 >  CS> your case it would be Ward), notification goes the the RC's to shift
 >  CS> then each RC tells their NC's when they can start using it.
 > 
 > Incorrect. The decent solution would be accepting both syntax during the
 > transition period.

But the upper level have to be using the new settings or the segments fail.

Say for example:  I send a segment to my RC (1:13/0) with the new settings. 
If he isnt ready, my net segment fails to process.  Worst case, my net doesnt
show up at all the next week.

Say he's ready and it flys through but Janis isnt ready (or isnt set to allow
it).  RC13's segment fails to process, or worst case, R13 disappears from the
nodelist.

What should happen is the ZC's (all agree I think now) set a date for them to
implement at their level.  Once all them have a set date, the RC's of each
zone then are given a date.  This can be pretty close (could even be same
week).

RC's then tell their nets, what week they can start sending segments in the
new format, as based on when they have implemented the changes.

You'll see both for a time as all catch up.

 
 >  CS> Come to think of it, this might be part of why Ward was doing all
 >  CS> those RC checks? Not sure, he didnt mention it that I saw (could have
 >  CS> just been time to check again).
 > 
 > Perhaps using the validator written in Perl will be a good solution...

That is interesting!  But the problem devolves to Makenl, even the new one.

 
 >  CS> Anyways if an NC files the new way when the RC or ZC above them is stil
 >  CS> lon the older software or hasnt changed the settings to allow the
 >  CS> '-Unpublished- without a PVT at the front, the segment will fail upstre
 > 
 > That will be the upper *C's fault.

No, as there is a set pattern it has to be worked at.  It's inherent in the
software used.  We dont have to like it, we just have to work with it.

Think of it like this:  ZC's all set to 'accept the new feature' and change
there makenl on 1April.  ZC's tell their RC's they can start sending by say 3
April.  RC's then tell their nets as they setup, when to go.  This might be
like 14 April or some might be ready by 7April.

Soon as you get word from your RC, you can send in new format.  It's not
harder than that.


 >  CS> This is why Malcolm processes and internal one with the 'Unpublished'
 >  CS> without PVT, and exports and external one without that.
 > 
 > Very pity.

Yes, we've been ready for years it seems but for various reasons it has been
delayed.

 >  >>  CS> Implict though in the Z1 method is 000-0-0-0-0 means
 >  >> '-Unpublished-'.
 >  >> It does not comply with FTS-5000 and, even worse, it may be
 >  >> misinterpreted.
 >  CS> It is not documented in the FTSC series, correct.
 > 
 > Incorrect. It is neither valid phone number nor valid IP address.

;-)  It is not used in your zone.  It is not _documented_ in any FTSC
document.

 
 >  CS> We know there is a more current one and that the 000-0-0-0-0 entries
 >  CS> will go away (hopefully soon!) but for reasons as above listed, has to
 >  CS> be an organized approach.
 > 
 > Good reason to rework the FTS-5000...

Hehe could well be!  For sure the FTSC will need to document that you no
longer have to have PVT if carrying -UnPublished- for a phone!
              xxcarol
--- SBBSecho 2.12-Win32
 * Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)