Subject: Re: [Sigtran] M3UA/SUA Diagnostic Information parameter

From: Ken Morneault <[email-masked]>
Date: Wed, 01 May 2002 11:34:51 -0400

The "MUST" was added for invalid message type and
message class errors so that the receiver of the Error
Indication could correlate the error.  This was one of
the outcomes of the plugtest and was discussed on
the list.

Ken

At 06:01 PM 4/30/2002 -0500, Brian F. G. Bidulock wrote:
>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" wrote:
>> 
>> > Vince,
>> >
>> > Vince Deters wrote:                                         (Mon, 29 Apr 2002 22:44:54)
>> > > Brian,
>> > >
>> > > "Brian F. G. Bidulock" wrote:
>> > >
>> > > > 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.
>> > >
>> > > I think so too. And therefore we include the offending message, among other things.
>> > >
>> > > > Why doesn't your diagnotic contain just the offending message as
>> > > > indicated by this SHOULD in the RFC?
>> > >
>> > > Well, because the extra information helps in diagnosing why the error was reported,
>> > > obviously.
>> > >
>> > > > 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?
>> > >
>> > > 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.
>> >
>> > The RFC doesn't say anything about 40 bytes: it says "The Diagnostic
>> > 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
>> 
>> >
>> >
>> > --brian
>> >
>> > >
>> > > Vince
>> > >
>> > > >
>> > > >
>> > > > --brian
>> > > >
>> > > > Vince Deters wrote:                                         (Mon, 29 Apr 2002 16:49:13)
>> > > > > 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
>> > > >
>> > > > --
>> > > > Brian F. G. Bidulock
>> > > > [email-masked]
>> > > > http://www.openss7.org/
>> >
>> > --
>> > Brian F. G. Bidulock
>> > [email-masked]
>> > http://www.openss7.org/
>> >
>> > _______________________________________________
>> > Sigtran mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/sigtran
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/
>
>_______________________________________________
>Sigtran mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/sigtran 

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