Re: Help decoding parameter Diagnostic Information

Michael,

Michael Tuexen wrote:                      (Thu, 18 Jan 2007 19:56:48)
> On Jan 18, 2007, at 6:35 PM, Fernandes, António Carlos, VF-PT wrote:
> 
> > Hello Michael,
> > Thx for the tip!
> > I manage to dissect part of the message.
> > The SG basically sends in the diagnostic information filed some  
> > sort of header followed by the exact message that cause the ERR (a  
> > copy of the DAUD message received by the SG in my case).
> > The only thing I could not decode was the header:
> >
> > 00001F3500000000
> That is implementation dependent. You have to ask your vendor...
> If he provides that information, I might be able to integrate that
> into Wireshark...

A parameter that cannot be machine decoded isn't very useful is it?
It was my understanding when we put the passages in the UA RFCs that
the Diagnostic SHOULD contain at least the first 40 bytes of the
offending message and _just_ the offending message (without proprietary
header fields or other sundry undecodable information).

My point being that although RFC 4666 says the Diagnostic "SHOULD contain
the offending message," we didn't mean `amoungst other things'.  Any
implementation that does not put the message first in the field, and as
the only information in the field, is not following the recommendation.

Supporting passages:

So, in RFC 3331:

   The optional Diagnostic information can be any information germane to
   the error condition, to assist in the identification of the error
   condition.  In the case of an Invalid Version Error Code the
   Diagnostic information includes the supported Version parameter.  In
   the other cases, the Diagnostic information SHOULD be the first 40
   bytes of the offending message.

In RFC 3332

   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.

RFC 4666 goes farther:

   The "Unsupported Message Class" error is sent if a message with an
   unexpected or unsupported Message Class is received.  For this error,
   the Diagnostic Information parameter MUST be included with the first
   40 octets of the offending message.

   The "Unsupported Message Type" error is sent if a message with an
   unexpected or unsupported Message Type is received.  For this error,
   the Diagnostic Information parameter MUST be included with the first
   40 octets of the offending message.

   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.  A Diagnostic Information
      parameter with a zero length parameter is not considered an error
      (this means that the Length field in the TLV will be set to 4).

RFC 3868

3.9.7.  Diagnostic Information

   The Diagnostic Information can be used to convey any information
   relevant to an error condition, to assist in the identification of
   the error condition.  In the case of an Adaptation Layer Identifier
   or Traffic Handling Mode, the Diagnostic Information includes the
   received parameter.  In the other cases, the Diagnostic information
   may be the first 40 bytes of the offending message.


--brian

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