>On Fri, Dec 14, 2001 at 11:27:09AM -0500, Howard C. Berkowitz wrote:
>>
>>
>> While I always hesitate to cite something ISO-ish, there is
>> terminology in the ISO 9646 conformance testing methodology that
>> might serve as a _starting_ point for explicit formulation.
>>
>> 9646 defines three kinds of test cases:
>> 1. Correct, where the PDU is completely appropriate but may
>>test boundary
>> conditions within the specification,
>> 2. Incorrect, where there are syntactical errors, possibly of
>>a type that
>> a PDU can be partially decoded,
>> 3. Inopportune, which could be better defined. In general, it appears to
>> refer to the behavior caused by the reception of a PDU not
>>relevant to
>> the current state of the receiver (e.g., a BGP speaker receiving an
>> UPDATE before the peering is established).
>>
>> Depending on how one defines "state," I think the inopportune case is
>> a starting point for what is being called semantic correctness. Other
>> things that might fall under semantic incorrectness include:
>>
>> 1. Reception of information dependent on a negotiable capability that
>> was refused during capability establishment
>> 2. Martian/bogon addressing and the like
>>
>> This taxonomy really doesn't have a place for such things as sanity
>> checking (e.g., BGP prefix limit) or DoS detection. But it's a start.
>>
>
>I don't think this addresses the issue of semantic correctness at all.
>The example being hinted at by some, I suspect, is confederation components
>in a syntactically correct AS_PATH causing a peer to reset simple because
>the peer didn't understand those components. In other words, good syntax
>with bad semantics caused a network failure, and that is something to be
>avoided, if possible.
>
>
Ben
Thanks for the comment.
Clearly, it's not quite the same as an inopportune case that is
merely defined with respect to a state machine. My example #1 is
closer to what you are describing, but it's not precisely on target.
Using the word "state" loosely, if I understand your example, the
state of the receiver is such that it didn't understand the received
AS_PATH.
I'm rapidly beginning to believe that a better taxonomy of errors may
be needed quite early in the requirements.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT