William Allen Simpson writes:
> Although, to be pedantic, multilink was first envisioned and
> implemented to cover multiple async links, and we argued for a long
> time about the size of fields to cover simultaneous use of async, ISDN,
> and FrameRelay links. (I'm pretty sure we gave up on async backup for
> SONET/SDH. ;-) So, that would seem to be a "self defeating"
> configuration....
Certainly -- and the first MP implementation I did was tested using
async because that's all we had at the time. The point is not whether
async is usable with MP, but rather what the local policy on its use
might be.
> > That's what I was trying to get across. The code that you're staring
> > at might have the capability of responding to a particular option, but
> > still be forced to send Configure-Reject anyway because (with the
> > current configuration) there's no way to continue using that option.
> >
> Ahh, you are talking about code reuse, and I was talking about
> operation. It may be true that there is code somewhere in the
> system that understands an option, but when the options are
> inapplicable to a particular *kind* of interface, I've always
> understood that to be "not recognizable".
OK; then it's just a word usage issue. By "not recognizable" I mean
"not implemented in any way at all." "Not recognizable" covers what
you do with options such as 201 -- never defined or used anywhere, no
idea what it might mean, and must be Configure-Rejected. It's where
you end up in the "default:" case in your switch statement. ;-}
"Recognized but unwanted" was a slightly different case, at least for
someone looking at some bit of PPP code and trying to understand how
the options work, but it's indistinguishable in behavior on the wire.
> Well, actually, there _is_ a "police squad". It's the purchaser!
I completely agree. There's *no* IETF-related enforcement -- it's up
to customers to complain when a vendor violates an RFC *AND* that
violation causes interoperability trouble.
I think that lack of specific IETF enforcement is a good thing,
because it puts the focus right where it belongs -- on quality of
implementation and interoperability rather than on abstract
"conformance" to some specification. Using "conformance" as a proxy
for correct operation is a problem seen in other standards bodies, and
it tends to result in forcing customers to buy all of their equipment
from a sole vendor because of minor differences in interpretation.
Or, in other words, vendors are required to be smart, rather than
being slaves to the standards process.
As we well know, there are many possible violations that do not affect
interoperability, or that actually make an implementation *more*
interoperable. (E.g., violating the unnecessary RFC 2453 requirement
of dropping authenticated datagrams when you have no authentication
configured, even though a 1058 router would have accepted the those
same datagrams.)
> I have also seen such "PPP Lite" idiocy.
As far as I've seen, the bug seems to bite people who think that PPP's
default three second restart timer has something to do with
"performance." It's a pretty profound bit of confusion, and often not
repairable.
--
James Carlson, Solaris Networking <james.d.carlson@xxxxxxxxxxxx>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
|
