>>I'm beginning to wonder if anyone at Livingston (especially those
>>involved in putting together the manuals) has ever actually read the RFC.
>
>Not only do we read them, we write them. In fact half of the listed
>authors for RFC 1717 work for Livingston. Livingston has always been
>active in developing new technology
OK, OK last post from me on this issue (by the way, nice to hear from you
John -- Kent & Parker say hi :) )
I'm not ignorant of the fact that you guys write some of the RFC's (I've
been grappling with the RADIUS RFC's in an effort to do our own integrated
NT/web based signup/accounting/logging/RADIUS implementation). I apologize
for the low blow -- I didn't mean to insult the developers (a group to
which I belong). It's just that I've worked on implementations of other
protocol-based RFC's and have run into similar language which is
interpreted as a must even when it doesn't explicitly state it as such
within the RFC. Regardless of the interpretation of the language of the
RFC (I certainly admit fault on my part if my interpretation of RFC 1717 is
not what the actual writers intended), I guess I still have a real problem
with calling a box RFC compliant and not including the fact that the RFC's
implementation is conditional. The only place I've been able to find the
conditional to the RFC 1717 implementation (that it only works for ISDN) is
here in this users group -- not from the sales guy, not from the release
notes for any of the ComOS's (I admit that I haven't thoroughly read every
release note in search of this information), nor from any of the techs I
talked to (until I cornered one of them after I had already spent the
better part of a weekend trying to make it work). I'm just frustrated by
the lack of continuity in the various information channels provided us as
customers, not just about this issue, but others as well. I shouldn't have
to find out gotcha's like this after convincing my boss that we should make
$17,000/unit upgrades and having them installed only to find out that the
info we got originally doesn't quite live up to what we get in the product
(I already deal with enough of that from USWorst). It makes you guys look
bad to us, it makes me look bad to my boss, and it makes us look bad to our
customers. I suppose I'm just too used to getting more than what I expect
from Livingston products instead of the other way around. My intention is
not to offend, just to relay my experience thus far regarding the PM3.
>>On the other hand, the PM2E won't ever be compliant due to
>>overwhelming hardware issues involved with its buffers.
>
>?hardware issues involved with its buffers?
>
>Huh?
I was referring to two earlier posts by Megazone (this one's from Thu, 27
Feb 1997 to be exact) regarding the fact that there were no plans to
implement MPPP on the serial ports of PM2E's due to it's buffering
capability not being up to snuff. (I suppose I should have said
"buffering" instead of "buffers" -- semantics again :) )
Megazone wrote:
>Once upon a time Timothy Deem shaped the electrons to say...
>>What would it take (technologically and politically) to get this
offerring
>>in a PM?
>
>Technologically it may take replacing the PM.
>
>As I've said, MP is heavy on buffering. The 5BRI cards were designed for
>this, the rest of the PM-2 hardware is not.
>
>It may be possible, but it isn't likely.
>
>As has been said, the PM-2 came out in 1993. MP didn't exist then, it
>wasn't a consideration. As new standards come out it isn't always
possible
>to do them in existing HW.
>
>-MZ
Don't get me wrong, the PM3 IS the coolest thing around right now (for the
price) -- just a few comparitively little things remain to be fixed which
will hopefully be cleaned up by the new Lucent DSP's.
David Matthews
Webmaster--Internet Technology Systems
webmaster@itsnet.com