RE: SIGTRAN Plugtest Day 3

I agree with Mark - the protocol should require the actions for
automatic recovery. This is what carriers will expect.

Cathy Newman
Project Manager - SS7 Testing and Analysis

-----Original Message-----
From: Erickson, Mark [mailto:[email protected]] 
Sent: Friday, April 20, 2007 2:10 AM
To: [email protected]
Cc: SIGTRAN Mailing List
Subject: RE: [Sigtran] SIGTRAN Plugtest Day 3

Brian:

See below


-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Thursday, April 19, 2007 10:32 AM
To: Erickson, Mark
Cc: SIGTRAN Mailing List
Subject: Re: [Sigtran] SIGTRAN Plugtest Day 3

Erickson,,

Erickson, Mark wrote:
(Thu, 19 Apr 2007 08:04:01)
> Brian:
> 
> A robust protocol's description must not only provide the elements to
> for each side to signal what happened, but then must also provide
> recovery mechanisms for faults.  Granted this is an operational issue,
> but doesn't a protocol also provide procedures for other 'operational'
> issues (congestion for one)?

IUT ones yes, IETF ones no.

<MAE> What???

> 
> The ASP, in this case, is not making ANY assumptions - it knows the
far
> end is in the ASP-INACTIVE state, and simply probing to see if the far
> end is ready to change state as it has been commanded.  The point is
> requiring local management to intervene.  What does this mean - the
M3UA
> user now has to implement a retry mechanism for automatic recovery?

This is no different than, say, SCTP where if the connecting peer
receives
and ABORT, the application is issued an error and must reattempt itself.
It does not matter for SCTP whether it is a configuration error,
managment
blocking (firewall), the application is given an error and the
connection
attempt is abadonned.

Informing the application of a certain error as soon as possible is good
design.  If M3UA automatically retransmits automatically, the first
thing a
application is going to want to do is shut it off.

> 
> Treating issues like this one in such a fashion only leads interop
> issues (due to differences in interpretation of the protocol
> description) which detracts from the robustness of the protocol
(which,
> BTW, is why we're here in the first place).

There is no interoperability issue: perhaps an operational in some
environments with some specific implementations.

<MAE> 'Operational' issues expose weak/vague areas in a protocol that
can and should be strengthened.

--brian

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/

_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran