Subject: [Sigtran] [Editorial Errata Reported] RFC4666 (4475)

From: RFC Errata System <[email-masked]>
Date: Mon, 14 Sep 2015 16:48:27 -0700 (PDT)

The following errata report has been submitted for RFC4666,
"Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4666&eid=4475

--------------------------------------
Type: Editorial
Reported by: Valentin Micic <[email-masked]>

Section: 3.6.1, Pg 53

Original Text
-------------
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.

Corrected Text
--------------
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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4666 (draft-ietf-sigtran-rfc3332bis-06)
--------------------------------------
Title               : Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
Publication Date    : September 2006
Author(s)           : K. Morneault, Ed., J. Pastor-Balbas, Ed.
Category            : PROPOSED STANDARD
Source              : Signaling Transport
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

---

From: David Laight <[email-masked]>
Date: Tue, 15 Sep 2015 10:14:32 +0000

From: Sigtran [mailto:[email-masked]] On Behalf Of RFC Errata System
> Sent: 15 September 2015 00:48
..
> Original Text

I'd question the entire statement about padding.
The padding isn't part of the parameter, but exists between parameters.

So something like:
    If the SI parameter does not contain a multiple of four SIs the Length
    will not be a multiple of 4 and there will be pad bytes following the
    parameter.
would be more correct.

	David

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 15 Sep 2015 07:42:16 -0600

This is a good correction.  We certainly meant 32 bits.

--brian

RFC Errata System wrote:                     (Mon, 14 Sep 2015 16:48:27)
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran

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

---

From: David Laight <[email-masked]>
Date: Wed, 16 Sep 2015 09:30:09 +0000

(Sorry I’m forced to top post)

It would be interesting to know what has actually been implemented.
(No one will have generated 32 byte alignment.)
We’d assumed that the parameter length excluded any required pad, and that
the diagram showed it because this was one place where padding was likely to be needed.

Indeed how many implementations actually support the key management messages.
AFAICT the main commercial implementation of M3UA still uses RFC 3332.

If the length of this parameter includes these pad bytes, then what should you do
if a zero is followed by a non-zero byte?

                David

There's a clear statement on page 32 of RFC 4666 that indicates that the "Parameter Length does not include any padding octets".
Even though SI parameter specification violates this "rule", it is quite plausible that there may be a number of implementations that may have followed this specification with padding octets.

Thus, how practical would it be to indicate that there will be no padding for SI parameter that does not contain multiple of four SIs, considering that we may end up converting a number of  compliant implementations into a score of non-compliant ones.

I think that changing 32-byte to 32-bit alignment is much safer (and considerably cheaper) option.

Kind regards

V/