Subject: M3UA v9: Diagnostic Information

From: Ken Morneault <[email-masked]>
Date: Mon, 22 Oct 2001 11:47:37 -0400

Based on discussions on the list, here is an update to "Section 3.8.1 Error".  Comments
and suggestions welcomed.

3.8.1  Error

The Error message is used to notify a peer of an error event associated 
with an incoming message.  For example, the message type might be 
unexpected given the current state, or a parameter value might be 
invalid.  

The Error message contains the following parameters:

      Error Code                 Mandatory
      Routing Context            Mandatory*
      Network Appearance         Mandatory*
      Affected Point Code        Mandatory*
      Diagnostic Information     Optional

(*) only mandatory for specific error codes

The format for the Error message is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x000c         |          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Error Code                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0006          |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /                       Routing Context                         / 
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |         Tag = 0x0012          |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Mask     |                 Affected PC 1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /                              ...                              /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Mask     |                 Affected PC n                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0200          |         Length = 8            |   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    |                     Network Appearance                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x0007         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /                     Diagnostic Information                    /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Error Code: 32-bits (unsigned integer)

    The Error Code parameter indicates the reason for the Error Message. 
    The Error parameter value can be one of the following values:

      0x01      Invalid Version 
      0x02      Not Used in M3UA
      0x03      Unsupported Message Class
      0x04      Unsupported Message Type 
      0x05      Unsupported Traffic Handling Mode 
      0x06      Unexpected Message
      0x07      Protocol Error
      0x08      Not used in M3UA
      0x09      Invalid Stream Identifier
      0x0a      Not used in M3UA
      0x0b      Not used in M3UA
      0x0c      Not used in M3UA
      0x0d      Refused - Management Blocking
      0x0e      ASP Identifier Required
      0x0f      Invalid ASP Identifier
      0x10      Invalid Routing Context
      0x11      Invalid Parameter Value
      0x12      Parameter Field Error
      0x13      Unexpected Parameter
      0x14      Destination Status Unknown
      0x15      Invalid Network Appearance          

The "Invalid Version" error is sent if a message was received with an 
invalid or unsupported version.  The Error message contains the 
supported version in the Common header.  The Error message could 
optionally provide the supported version in the Diagnostic Information 
area.

The "Invalid Network Appearance" error is sent by a SGP if an ASP sends 
a message with an invalid (unconfigured) Network Appearance value.  For
this error, the invalid (unconfigured) Network Appearance MUST be 
included in the Network Appearance parameter.

The "Unsupported Message Class" error is sent if a message with an 
unexpected or unsupported Message Class is received.

The "Unsupported Message Type" error is sent if a message with an 
unexpected or unsupported Message Type is received.

The "Unsupported Traffic Handling Mode" error is sent by a SGP 
if an ASP sends an ASP Active message with an unsupported Traffic Mode 
Type  or a Traffic Mode Type that is inconsistent with the presently 
configured mode for the Application Server.  An example would be a case 
in which the SGP did not support loadsharing.

The "Unexpected Message" error MAY be sent if a defined and recognized 
message is received that is not expected in the current state (in some 
cases the ASP may optionally silently discard the message and not send 
an Error message).  For example, silent discard is used by an ASP if it 
received a DATA message from an SGP while it was in the ASP-INACTIVE 
state. If the Unexpected message contained Routing Context(s), the Routing Context(s) SHOULD be included in the Error message.

The "Protocol Error" error is sent for any protocol anomaly (i.e., 
reception of a parameter that is syntactically correct but unexpected 
in the current situation.

The "Invalid Routing Context" error is sent if a message is received 
from a peer with an invalid (unconfigured) Routing Context value, or if 
a message is received from a peer without a Routing Context parameter 
and it is not known by configuration data which Application Servers are 
referenced.  For this error, the invalid Routing Context(s) MUST be
included in the Routing Context parameter.

The "Invalid Stream Identifier" error is sent if a message is received 
on an unexpected SCTP stream (e.g., a Management message was received 
on a stream other than "0").

The "Invalid Parameter Value " error is sent if a message is received 
with an invalid parameter value (e.g., a DUPU message was received with 
a Mask value other than "0").

The "Refused - Management Blocking" error is sent when an ASP Up or 
ASP Active message is received and the request is refused for 
management reasons (e.g., management lockout").  If this error is in 
response to an ASP Active message, the Routing Context(s) in the ASP 
Active message SHOULD be included in the Error message.

The "ASP Identifier Required" is sent by a SGP in response to an ASP Up 
message which does not contain an ASP Identifier parameter when the SGP 
requires one.  The ASP SHOULD resend the ASP Up message with an ASP 
Identifier.

The "Invalid ASP Identifier" is send by a SGP in response to an ASP Up 
message with an invalid (i.e., non-unique) ASP Identifier.

The "Destination Status Unknown" Error MAY be sent if a DAUD is 
received at an SG enquiring of the availability/congestion status of a 
destination, and the SG does not wish to provide the status (e.g., the 
sender is not authorized to know the status). For this error, the 
invalid or unauthorized Point Code(s) MUST be included along with the 
Network Appearance and/or Routing Context associated with the Point 
Code(s).

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 be the first 40 bytes of the offending message.

Error messages MUST NOT be generated in response to other Error messages.

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Ken Morneault <[email-masked]>
Date: Mon, 22 Oct 2001 11:55:22 -0400

Kurt,

Please review the proposal that I just sent to the list to see if it
is sufficient for your needs.   I think you would want the "SHOULD"
change to "MUST" for Diagnostic Info and possibly that the 
entire message be included instead of just the first 40 bytes.

Regards,

Ken

At 10:23 AM 10/22/01 -0500, you wrote:
>Hi Ken,
>
>A while back I submitted a proposal for the ERR message that you might
>want to take a look at. See thread "M3UA version 7 comments." The premise
>of the proposal was that the offending message is always included in the ERR
>message and that the error code would be unique enough to point out the
>erroneous part of the message. One case where the above is not sufficient is where
>a parameter can have multiple values (e.g., routing context). In this case, the ERR
>message also contains another parameter which only contains the offending value.
>
>Regards,
>Kurt
>
>
>
>
>"Brian F. G. Bidulock" wrote:
>
> > Ken,
> >
> > The DAUD stuff sounds very reasonable.
> >
> > I'm a little confused on errored parameters though.  You say that
> > an errored parameter must be included in the message.  Say for
> > example that I receive a Routing Context parameter in an ASPAC
> > that is 5 bytes long.  What do I place in the ERR message?  A
> > 5-byte long Routing Context?
> >
> > What ERR do I send when I get an parameter with an invalid or
> > unsupported tag?
> >
> > When I send Destination Status Unknown, shouldn't the ERR also
> > include the RC and even NA value in circumstances where the form
> > of the APC is not implied by the association?
> >
> > Are there not also other errors for which Routing Context should
> > be included, particularly where ASPTM message are being rejected?
> >
> > --brian
> >
> > Ken Morneault wrote:                              (Thu, 18 Oct 2001 21:25:34)
> > >
> > >
> > > A proposal for changes to the error message is below.  These
> > > changes better explain how some offending parameters would
> > > be included in the error message in order to feedback
> > > important diagnostic information the the sender.  This
> > > diagnostic information is intended to help enable
> > > resolution of the error (most likely a provisioning error).
> > >
> > > This proposal has some open discussion points:
> > >
> > > 1)  is it important to be able to correlate the error with
> > > the offending message?  if so, then the Diagnostic Information
> > > MUST (instead of MAY) contain the entire message in error.
> > > This would be in addition to placing the offending
> > > parameter, when appropriate, in the Error message.
> > >
> > > 2)  It seems better to handle Brian's concern of DAUD(*)
> > > and DAUD(cluster) in Section 3.4.3.
> > >
> > > When the SG receives a DAUD with a mask that indicates some bits of the
> > > point code are wildcarded, the SG shall respond with the status of the point
> > > codes authorized to be seen by the sender.  The SG will not send an Error
> > > message for the other point codes.
> > >
> > > 3)  The only parameters that could be included would be:  Routing
> > > Context, Affected Point Code, and Network Appearance.  Traffic Mode
> > > and Invalid Parameter were removed.  There does not seem to be a
> > > need for Traffic Mode type since ASP would know which traffic mode
> > > type it supports.   Invalid Parameter is too general.
> > >
> > > I look forward to comments.
> > >
> > > Ken
> > >
> > >
> > > 3.8.1  Error
> > >
> > > this error, the invalid Network Appearance parameter MUST be included.
> > >
> > > state.
> > > The "Invalid Routing Context" error is sent if a message is received from a
> > > peer with an invalid (unconfigured) Routing Context value, or if a message
> > > is received from a peer without a Routing Context parameter and it is not
> > > known by configuration data which Application Servers are referenced.  For
> > > this error, the invalid Routing Context(s) MUST be included.
> > >
> > > management reasons (e.g., management lockout").
> > >
> > > The "ASP Identifier Required" is sent by a SGP in response
> > > to an ASP Up message which does not contain an ASP Identifier
> > > parameter when the SGP requires one.  The ASP should resend the
> > > ASP Up message with an ASP Identifier.
> > >
> > > The "Invalid ASP Identifier" is send by a SGP in response
> > > to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier.
> > >
> > > The "Destination Status Unknown" Error MAY be sent if a DAUD is received at
> > > an SG enquiring of the availability/congestion status of a destination, and
> > > the SG does not wish to provide the status (e.g., the sender is not
> > > authorized to know the status). For this error, the invalid or unauthorized
> > > Point Code(s) MUST be included.
> > >
> > >
> > >     MAY be the first 40 bytes of the offending message.
> > >
> > > At 08:39 PM 10/16/01 -0500, you wrote:
> > > >Ken,
> > > >
> > > >Ken Morneault wrote:                (Tue, 16 Oct 2001 21:12:56)
> > > > >
> > > > >
> > > > > Brian,
> > > > >
> > > > > I don't intend to use the information internal to the ASP.   The
> > > > > invalid NA, invalid RC, unknown PC and invalid Traffic Mode
> > > > > indicate that something has been mis-configured.  This
> > > > > information could be passed to an operator in an alarm
> > > > > or logged so that the problem could be quickly resolved.
> > > > >
> > > > > I agree (and have complained in the past) that there needs
> > > > > to be more discussion on coding these parameters.  Further,
> > > > > I agree a PC would need NA or RC from the offending
> > > > > DAUD if NA or RC was present.
> > > >
> > > >If it has MUST, lets get the diagnostic coding complete and
> > > >ensure that all the necessary information is present in the
> > > >diagnostic.
> > > >
> > > >Better still, why not include the offending message as it was
> > > >recieved?  (i.e., the entire DAUD complete with message type).
> > > >This would not be much trouble.
> > > >
> > > >Further there is the question as to what PC is included in the
> > > >diagnostic if the ASP does DAUD(*) or does a DAUD(cluster)
> > > >on which it is only allowed to access information for several
> > > >members in the cluster.  The ERR message would have to contain
> > > >a list of all the other PCs in the cluster to which the ASP
> > > >was being denied access (particularly if you leave it at "MUST").
> > > >This means that there might be a need to represent almost
> > > >2^24 point codes in the diagnostic!
> > > >
> > > >First off, the SHOULD for PC needs to be relaxed to permit the
> > > >SGP to not include all the other members of the cluster or
> > > >entire network.  If it is not relaxed all the way to MAY, then
> > > >the format of the diagnostic, the necessary parameters included
> > > >and the point codes which will be included (certainly not 2^24!).
> > > >
> > > >If the MUST is not relaxed on RC and others, the format of the
> > > >potentially mangled parameter (e.g., too short, not padded) in
> > > >the diagnostic must be specified and the parameters necessary
> > > >to correlate the error with the offending message must be
> > > >included as well.
> > > >
> > > >The draft should certainly not say that an implementation "MUST"
> > > >or "SHOULD" do something, but then leave how that is to be done
> > > >unspecified.  "MUST" and "SHOULD" need to be used to promote
> > > >interoperability, not to require vague non-interoperable procedures.
> > > >
> > > >We need to either specify how it is to be done, or remove the
> > > >requirement ("MUST" and "SHOULD" diction).
> > > >
> > > >Since you are such an advocate of the uses of the diagnostic,
> > > >perhaps you would propose a specification of its coding in support
> > > >of maintianing the requirement to provide it?
> > > >
> > > >I eagerly await your proposed text. ;)
> > > >
> > > >--brian
> > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Ken
> > > > >
> > > > >
> > > > > At 05:38 PM 10/16/01 -0500, you wrote:
> > > > > >Ken,
> > > > > >
> > > > > >Then perhaps you can explain how the ASP is going to interpret
> > > > > >the point code without RC or NA to provide reference to the
> > > > > >numbering space.  Perhaps you can also describe how you see
> > > > > >the ASP correlating which AS generated the DAUD from the ERR
> > > > > >message which doesn't appear to contain the RC of the AS.
> > > > > >
> > > > > >--brian
> > > > > >
> > > > > >
> > > > > >Ken Morneault wrote:                                          (Tue, 16 Oct 2001 13:48:20)
> > > > > > >
> > > > > > >
> > > > > > > I agree with Javier on both of these issues.
> > > > > > >
> > > > > > > Ken
> > > > > > >
> > > > > > > At 07:32 PM 10/16/01 +0200, you wrote:
> > > > > > > >Hi Brian,
> > > > > > > >
> > > > > > > >See comments below...
> > > > > > > >
> > > > > > > >
> > > > > > > >Cheers // Javier.
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > > > > Sent: Thursday, October 11, 2001 10:28 PM
> > > > > > > > > To: sigtran
> > > > > > > > > Subject: M3UA v9: Diagnostic Information
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Section 3.8.1 says:
> > > > > > > > >
> > > > > > > > >    identification of the error condition.  In the case of an Invalid
> > > > > > > > >    Network Appearance, Traffic Handling Mode, Routing Context or
> > > > > > > > >    Parameter Value, the Diagnostic information parameter MUST
> > > > > > > > > be added
> > > > > > > > >    and include the offending parameter.  In the case of Destination
> > > > > > > > >    Status Unknown, the Diagnostic information SHOULD include
> > > > > > > > > the Point
> > > > > > > > >    Code in the original DAUD request.
> > > > > > > > >
> > > > > > > > > There is certainly no reason for a MUST here.  In most implementations
> > > > > > > > > the diagnostic information will be ignored during normal operation.
> > > > > > > > >
> > > > > > > > > Change MUST to MAY.
> > > > > > > >
> > > > > > > >I can happen in your implementation, but maybe the others take actions depending on that. From my point of view is important enough to keep the MUST.
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > There is no reason for the SHOULD either.  Implementations
> > > > > > > > > sending DAUD
> > > > > > > > > must remember for which point code it was sent and from the
> > > > > > > > > discussion on
> > > > > > > > > DAUD there is little point to auditing specific point codes
> > > > > > > > > periodically
> > > > > > > > > or otherwise.  Only restart (basically DAUD(*)) are useful.
> > > > > > > > >
> > > > > > > > > Change SHOULD to MAY.
> > > > > > > >
> > > > > > > >Same thing. If an implementation decides to use DAUD with a single SPC, and it sends two different DAUDs with two different SPCs and receives only an error, it would like to know which one had the problem. Therefore the remote implementation should give this information back. I think we should keep the SHOULD here as well...
> > > > > > > >
> > > > > > > > >
> > > > > > > > > --brian
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> > > > > > > > > [email-masked]    ¦ world; the unreasonable one persists in  ¦
> > > > > > > > > http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
> > > > > > > > >                         ¦ Therefore  all  progress  depends on the ¦
> > > > > > > > >                         ¦ unreasonable man. -- George Bernard Shaw ¦
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ---
> > > > > > > > > You are currently subscribed to sigtran as:
> > > > > > > > > [email-masked]
> > > > > > > > > To unsubscribe send a blank email to
> > > > > > > > > [email-masked]
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >---
> > > > > > > >You are currently subscribed to sigtran as: [email-masked]
> > > > > > > You are currently subscribed to sigtran as: [email-masked]
> > > > > >--
> > > > > >Brian F. G. Bidulock
> > > > > >[email-masked]
> > > > > >http://www.openss7.org/
> > > > > >You are currently subscribed to sigtran as: [email-masked]
> > > > > You are currently subscribed to sigtran as: [email-masked]
> > > >--
> > > >Brian F. G. Bidulock
> > > >[email-masked]
> > > >http://www.openss7.org/
> > > >You are currently subscribed to sigtran as: [email-masked]
> > > You are currently subscribed to sigtran as: [email-masked]
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > You are currently subscribed to sigtran as: [email-masked]
>You are currently subscribed to sigtran as: [email-masked]

---

---

From: Kurt Kite <[email-masked]>
Date: Mon, 22 Oct 2001 12:33:00 -0500

Hi Ken,

Yes, I think that the erroneous message should always be included in its
entirety in the ERR message. If it is then it is certain that the receiver can
correlate the ERR message back to the original message. I also think that
the erroneous message should be separate from the Diagnostic Info, i.e., a
separate parameter.

I don't see it as necessary to have separate parameters, i.e., routing context,
affected PC, network appearance. You can just have a generic parameter
tag and put the offending value in it and determine what it is from the error
code. Then if you have missed some cases or they define new ones then you
just have to add a new error code to the specification. However, both techniques
work for me.

I don't understand why you have not allowed routing context to be repeated like
affected PC.

The new proposal states:

     The "Invalid Routing Context" error is sent if a message is
     received
     from a peer with an invalid (unconfigured) Routing Context
     value, or if
     a message is received from a peer without a Routing Context
     parameter
     and it is not known by configuration data which Application
     Servers are
     referenced.  For this error, the invalid Routing Context(s)
     MUST be
     included in the Routing Context parameter.

What should the routing context value be if none is specified in the
original message. Perhaps separate error codes should be provided?

/Kurt

Ken Morneault wrote:

> > > > > > > > >To unsubscribe send a blank email to [email-masked]
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ---
> > > > > > > > To unsubscribe send a blank email to [email-masked]
> > > > > > >
> > > > > > >--
> > > > > > >Brian F. G. Bidulock
> > > > > > >[email-masked]
> > > > > > >http://www.openss7.org/
> > > > > > >
> > > > > > >
> > > > > > >---
> > > > > > >To unsubscribe send a blank email to [email-masked]
> > > > > >
> > > > > >
> > > > > >
> > > > > > ---
> > > > > > To unsubscribe send a blank email to [email-masked]
> > > > >
> > > > >--
> > > > >Brian F. G. Bidulock
> > > > >[email-masked]
> > > > >http://www.openss7.org/
> > > > >
> > > > >
> > > > >---
> > > > >To unsubscribe send a blank email to [email-masked]
> > > >
> > > >
> > > >
> > > > ---
> > > > To unsubscribe send a blank email to [email-masked]
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > >
> > > ---
> > > To unsubscribe send a blank email to [email-masked]
> >
> >
> >
> >---
> >To unsubscribe send a blank email to [email-masked]
>
> ---
> To unsubscribe send a blank email to [email-masked]

---

---

From: Ken Morneault <[email-masked]>
Date: Mon, 22 Oct 2001 21:26:26 -0400

Kurt,

See comments below.

Ken

>the erroneous message should be separate from the Diagnostic Info, i.e., a

what would diagnostic info be used for then?  it doesn't seem valuable to
create another parameter.

>just have to add a new error code to the specification. However, both techniques

i think the current technique is easier to follow and understand.

>I don't understand why you have not allowed routing context to be repeated like

i will update the proposal to add support.

>original message. Perhaps separate error codes should be provided?

good question.  what do others think?

---

---

From: Kurt Kite <[email-masked]>
Date: Tue, 23 Oct 2001 08:51:05 -0500

Hi Ken,

Please see comments below.

/Kurt

> create another parameter.

As long as the erroneous message is always included in the message I will be happy.

> i think the current technique is easier to follow and understand.

As I said both work for me.

> good question.  what do others think?

I would vote for separate error codes. As I said before I believe the error
code should uniquely identify each error.

---

---

From: Ken Morneault <[email-masked]>
Date: Wed, 24 Oct 2001 02:08:32 -0700

Kurt,

Are these changes sufficient?  (note KAM below).

Ken

3.8.1  Error

     Error Code                 Mandatory

    0                   1                   2                   3

     0x01      Invalid Version 
     0x02      Not Used in M3UA
     0x16      No Configured AS for ASP  [KAM]         

[KAM]

The "No Configured AS for ASP" error is sent if a message is received 
from a peer without a Routing Context parameter and it is not known by 
configuration data which Application Servers are referenced.  

[KAM]

   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. [KAM]

---

---

From: Kurt Kite <[email-masked]>
Date: Thu, 25 Oct 2001 11:23:25 -0500

Hi Ken,

As I said before, I think that the erroneous message MUST be included in
the ERR message in order to guarantee correlation. However, in a draft already
riddled with interop issues this one is not worth the argument.

See below for one more comment.

Regards,
Kurt

> Are these changes sufficient?  (note KAM below).

[snip]

> from a peer with an invalid (unconfigured) Routing Context value [, or if
> referenced].  For this error, the invalid Routing Context(s) MUST be

The bracketed text should be deleted.

---

---

From: Ken Morneault <[email-masked]>
Date: Wed, 24 Oct 2001 21:38:33 -0700

Kurt,

I left it as SHOULD in case the message had an invalid length 
and was quite long.  We could change to MUST but we may want
to consider any special cases.

Ken

---

---

From: Vince Deters <[email-masked]>
Date: Thu, 25 Oct 2001 12:53:56 -0400

Ken...do you have am & pm reversed on your pc clock? :-)
Vince

Ken Morneault wrote:

> You are currently subscribed to sigtran as: [email-masked]

---