On Sat, 09 Jan 1999, Thomas Sailer wrote:
>You're referring to AX25 V2.2?
>
>Whe had a rather long discussion last year in Darmstadt. Several
>AX.25 implementers (FlexNet, NordLink, Matthias Welwarsky,
>the current Linux AX.25 hacker) were there. We agreed that this new
>spec is completely bogus.
I think you are a little hard ...
>These are some of the more severe reasons:
>
>SABME/SREJ is an attempt to implement selective repeat
>(instead of go back N). We (in central europe) already
>use a selective repeat scheme called "frame collector"
>for almost 10 years now. It uses existing protocol elements
>(RR P/F), is backward compatible, and does not incur much
>complexity.
The fact that the same can be done with the "same current elements" doesn't
mean that new implementations are bad. In hdlc SREJ is for doing selective
reject. You can do something similar without them, and ??
>The reduction of digipeater fields to 4 is just ridiculous.
>It kills FlexNet, but doesn't give any advantage (_still_
>variable length header).
At less AX25 v.2.2 is public, not like Flexnet. Saying that AX25 v.2.2 is
"bad" because it has been done is "obscurity", and saying that it doesn't
respect Flexnet, is a nonsense. Flexnet is top secret, and ax25 2.2 is public.
What is important is the result, and there is one document. How many
projects of this kind are arriving at its end in ham-radio ? Not very much, the
actitude should be constructive, and promove that someone implement that
protocol.
>The Spec mandates things that are not needed to be specified
>for interoperability, and it makes a complete layering mess.
>Just look at the timer chapter.
There is no need to implement all. In a protocol, not all is needed, but things
must be defined. I looked the timers they are a big improvement, relating them
with the Physical layer through primitives. For example that allow to stop some
timers while the system is transmiting (the solution of some problems that
currently exist); all that is not implementable with all the current devices,
but with many of them yes.
>I can't see how anyone would be able to implement this mess
>in a TNC with less than 1Meg RAM and 1Meg ROM.
1Mega is very much today ? I don't think so.
And who is going to use inteligent tncs today, Linux can do all the work.
>The authors were SDL guys. I've already been bitten by
>SDL enthusiasts basing design decisions on SDL's features
>and thereby killing performance.
Who is speaking of performance ? We have very fast computers, with a lot of
memory. That's the way the telecomunicacions are moving today, the protocols
are designed in sdl because the definitions, the working are clear. I think
it's much more easy to developp a protocol with the sdl definition.
>The SDL generated C code is unusable if you want performance
>(we _want_ performance, 100kBps++ link transceivers
>already exist!!)
For this speed maybe there is no need of ax25 2.2. Sure, ax25 2.2 is more heavy
than precendent ax25, and is not implementable in the same hardware.
>The way TAPR did the design process (essentially secretly,
>no one of the major AX.25 implementors, such as
>Nordlink or Flexnet) new anything about it or was even
>asked what they think of it.
So I think they decided to do it that way. Maybe because they wanted to be
independent of the ax25 implementors restrictions, and do the better.
>If you want a public standard followed by all major
>implementors, make the standard setting process open!!
Yes, but maybe they didn't want to do a standard followed by all major
implementors, but do the best. So that's maybe why there isn't any
implementation of ax25 v.2.2; but that implementable, because it has been
already implementend in hdlc protocols (selective reject, XID protocol
negotiation frames, SDL is used in very much telecomunication protocols).
--
Saludos de Juli�n
-.-
