Subject: [Sigtran] M3UA/SUA Diagnostic Information parameter

From: Vince Deters <[email-masked]>
Date: Mon, 29 Apr 2002 16:49:13 -0400

Hi,

The M3UA implementor's guide has text in section 3.8.1 that defines
the Diagnostic Information parameter in an "Unsupported Message Type" or
"Unsupported Message Class" error message as being "the first 40 bytes
of the offending message".

Since the diag info parameter in an error message has never been well
defined, we've refined the concept of returning the offending message a
bit to make it more useful. As it stands, our SG implementation has this
format for the diag info parm -

tag + length + value, where value is:

32-bit code + 32-bit offset + complete offending message

The "code" value is typically a unique integer that identifies the line
of code that detected and/or reported the error. The "offset" value is
simply the offset into the offending message of the data that triggered
the error, if any.

We use this across the board for all error messages. Since it conflicts
with the "first 40 bytes" approach, we'd like to propose it as a
possible alternative. Comments?

Thanks,
Vince

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Apr 2002 16:33:21 -0500

Vince,

That's funny, 'cause the RFC says:

" Diagnostic Information: variable length
" 
"    When included, the optional Diagnostic information can be any 
"    information germane to the error condition, to assist in 
"    identification of the error condition. The Diagnostic information 
"    SHOULD contain the offending message.

I thought that after Ken rewrote this section that "The Diagnostic
Information SHOULD contain the offending message" was pretty clear.

Why doesn't your diagnotic contain just the offending message as
indicated by this SHOULD in the RFC?

I would suggest that to print the offending code line, offset into
the message and even the entire message into your log file.  Dumping
it out of the network is of no use to the peer implementation.  Did
you expect the peer to collect your logs for you?

--brian

Vince Deters wrote:                                         (Mon, 29 Apr 2002 16:49:13)

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

---

From: Vince Deters <[email-masked]>
Date: Mon, 29 Apr 2002 22:44:54 -0400

Brian,

> Information SHOULD contain the offending message" was pretty clear.

I think so too. And therefore we include the offending message, among other things.

> indicated by this SHOULD in the RFC?

Well, because the extra information helps in diagnosing why the error was reported,
obviously.

> you expect the peer to collect your logs for you?

Of course not, and we do log all this stuff. But in a customer environment with a remote SG
and ASP's that log or echo this stuff, any kind of diagnostic info should be made
available, especially when it's just a few extra bytes to enhance the usefulness of the 40
bytes that we're now required to send.

Vince

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Apr 2002 22:55:21 -0500

Vince,

Vince Deters wrote:                                         (Mon, 29 Apr 2002 22:44:54)
> bytes that we're now required to send.

The RFC doesn't say anything about 40 bytes: it says "The Diagnostic
Information SHOULD contain the offending messages."

--brian

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

---

From: Vince Deters <[email-masked]>
Date: Tue, 30 Apr 2002 06:40:44 -0400

> Information SHOULD contain the offending messages."

It's "message", not "messages". I assume that's a typo because you quoted it correctly in your
first reply above.

I just mentioned 40 bytes because the implementor's guide says the diag info parm "MUST be
included with the first 40 bytes of the offending message" when reporting unsupported message
class or type. But having the entire message reported back just strengthens the case for
including an offset along with it.

Vince

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Apr 2002 18:01:05 -0500

Vince,

I disagee with the "MUST" in the IG.  The "SHOULD" in the RFC
is sufficient as it represents the concensus from a long ladder
of discussion on error reporting which prompted Ken to rewrite
these sections.  We all agreed on the current RFC text.  None
of these view are new.  They were all discussed in arriving at
the RFC text.  Put the message in the Diagnotic.  Fill out the
other ERR parameters as required in the RFC.  No offset is needed.
Where a parameter is the cause, the parameter is included in the
message.  If you want to find out where messages have syntactic
errors, use a packet sniffer.  Etherreal works pretty good a those
things I am told.

--brian

Vince Deters wrote:                                         (Tue, 30 Apr 2002 06:40:44)

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