RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Held for Document Update (2)

RFC 4666, "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", September 2006

Source of RFC: sigtran (rai)

Errata ID: 2065
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: AMIR KHAN
Date Reported: 2010-03-04
Held for Document Update by: Robert Sparks

Section 3.8.2 says:

The Notify message contains the following parameters:

      Status                     Mandatory
      ASP Identifier             Conditional
      Routing Context            Optional
      INFO String                Optional

It should say:

The Notify message contains the following parameters:

      Status                     Mandatory
      ASP Identifier             Conditional
      Routing Context            Conditional <Changed>
      INFO String                Optional

Notes:

Considering the scenario below I think the Routing Context in Notify must be conditional.

If ASP1 is Actively processing traffic for both AS1(Override) and AS2(Loadshare) and another ASP2 of AS1 becomes ACTIVE. Then I think it becomes mandatory for SG to send Notify message ("Alternate ASP Active") with AS1 Routing Context. ASP1 will use this Notify (containing AS1 Routing Context) to become INACTIVE for AS1, without this AS1 Routing Context ASP1 will become INACTIVE for both AS1 and AS2, which is not desired here.

Also please go through mailing list with subject line "M3UA Notification and Routing Context" for more on this.

Errata ID: 4475
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Valentin Micic
Date Reported: 2015-09-14
Held for Document Update by: Ben Campbell
Date Held: 2015-10-31

Section 3.6.1, Pg 53 says:

The optional SI [7,8] field contains one or more Service
      Indicators from the values described in the MTP3-User Identity
      field of the DUPU message.  The absence of the SI parameter in the
      Routing Key indicates the use of any SI value, excluding of course
      MTP management.  Where an SI parameter does not contain a multiple
      of four SIs, the parameter is padded out to 32-byte alignment.

It should say:

The optional SI [7,8] field contains one or more Service
      Indicators from the values described in the MTP3-User Identity
      field of the DUPU message.  The absence of the SI parameter in the
      Routing Key indicates the use of any SI value, excluding of course
      MTP management.  Where an SI parameter does not contain a multiple
      of four SIs, the parameter is padded out to 32-bit alignment.

Notes:

It seems obvious that diagram is referring to 32-bit and not 32-byte (as in 32-octets) alignment.

Status: Rejected (1)

RFC 4666, "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", September 2006

Source of RFC: sigtran (rai)

Errata ID: 2518
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Suyash Karmarkar
Date Reported: 2010-09-14
Rejected by: Robert Sparks
Date Rejected: 2010-09-14

Section 3.2. says:

3.2. Variable-Length Parameter Format

M3UA-Specific parameters. These TLV parameters are specific to the
M3UA protocol:

Registration Result                               0x0208
Deregistration Result                             0x0209
Local Routing Key Identifier                      0x020a

It should say:

3.2. Variable-Length Parameter Format

Common Parameters. These TLV parameters are common across the
different adaptation layers:

Registration Result                 0x0014,
Deregistration Result               0x0015,
Local Routing Key Identifier        0x0018,

Notes:

As the above three parameters mentioned are used for the same purpose in RFC 3868 and in RFC 4666. So the above parameters in RFC 4666 Section 3.2, the M3UA-Specific parameters can be considered to move them into the common parameters section 3.2 of RFC 4666 with the above sepecified values.

The advantage could be, for one who implements both SUA & M3UA can use the same encoding and decoding mechanisms/code for both the implementations.
--VERIFIER NOTES--
Per discussion on the SIGTRAN list, this is a fundamental and non-interoperable change to the protocol.

Report New Errata



Advanced Search