Subject: Re: [Sigtran] [Technical Errata Reported] RFC3331 (1425)

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 16 May 2008 13:44:47 -0600

RFC,

There is nothing the matter with the diagram or text.

All that this change would accomplish would be making the description
for the Signalling Data Terminal Identifier field be the same as the
description for the Signalling Data Link Identifier field, which would
then result in two descriptions for SDLI and none for SDTI.

--brian

On Fri, 16 May 2008, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC3331,
> "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.RFC-Editor.ORG/errata_search.php?rfc=3331&eid=1425
> 
> --------------------------------------
> Type: Technical
> Reported by: Alfred Hoenes <[email-masked]>
> 
> Section: 3.3.4.1,p.53
> 
> Original Text
> -------------
> a)
> |     The SDT Identifier is a 32-bit unsigned value which may only be
>       significant to 12 or 14 bits depending on the SS7 variant which is
>       supported by the MTP Level 3 at the ASP.  Insignificant SDT
>       Identifier bits are coded 0.
> 
> b)
> |     The SDL Identifier is a 32-bit unsigned value which may only be
>       significant to 12 or 14 bits depending on the SS7 variant which
>       is supported by the MTP Level 3 at the ASP.  Insignificant SDLI
>       bits are coded 0.
> 
> 
> Corrected Text
> --------------
> a)
> |     The SDT Identifier is a 16-bit unsigned value which may only be
>       significant to 12 or 14 bits depending on the SS7 variant which is
>       supported by the MTP Level 3 at the ASP.  Insignificant SDT
>       Identifier bits are coded 0.
> 
> b)
> |     The SDL Identifier is a 16-bit unsigned value which may only be
>       significant to 12 or 14 bits depending on the SS7 variant which
>       is supported by the MTP Level 3 at the ASP.  Insignificant SDLI
>       bits are coded 0.
> 
> 
> Notes
> -----
> In both cases, the field width "32-bit" in the text does not match
> the parameter breakdown in the immediately preceding artwork.
> The above corrections are based on the assumption that the figures
> are correct and the text is in error.
> 
> Instructions:
> -------------
> This errata 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. 
> 
> --------------------------------------
> RFC3331 (draft-ietf-sigtran-m2ua-15)
> --------------------------------------
> Title               : Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer
> Publication Date    : September 2002
> Author(s)           : K. Morneault, R. Dantu, G. Sidebottom, B. Bidulock, J. Heitz
> Category            : PROPOSED STANDARD
> Source              : Legacy
> Area                : Legacy
> Stream              : IETF
> Verifying Party     : IESG

-- 
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 ¦
_______________________________________________
Sigtran mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 16 May 2008 14:50:31 -0600

Alfred,

Sorry, but the change is still not required.  The
SDT Identifier field is 32-bits (4 octets as indicated
by the parameter length), but the value within that
field only occupies 16 its of which only 12-14 bits
are significant.  No change to the document is necessary.

--brian

Alfred Hönes wrote:                          (Fri, 16 May 2008 22:10:19)
> Brian,
> Sorry, I do not understand the conclusions above.
> 
> To avoid the replication of ensuant mail exchanges and for
> the ease of prospective readers, two parallel corrections
> have been requested in one Errata Note, tagged a) and b),
> for SDTI and SDLI text, respectively, and both changing
> "32-bit" to "16-bit" to bring the text in alignment with
> the figures showing 16-bit field width.
> This 'parallel correction' style is well established.
> 
> Please reconsider your statement after closely re-reading
> the Errata Note.  Thanks.
> 
>   Alfred.
> 
> > 
> > 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 |
> > 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 16 May 2008 18:25:47 -0600

Alfred,

Alfred Hönes wrote:                          (Fri, 16 May 2008 23:29:46)
> Brian,
> 
> Again, sorry, I do not agree.
> The text snippits say:
>                                                          vvvvv    vvv
> |     The SDx Identifier is a 32-bit unsigned value which may only be
>       significant to 12 or 14 bits depending on the SS7 variant [...]
> 
> They do *not* say:
>                                                          vvvv
> |     The SDx Identifier is a 32-bit unsigned value which is only
>       significant to 12 or 14 bits depending on the SS7 variant [...]
> 
> The original version with the "may" obviously is incompatible
> with the attribute value layout (16-bit Reserved, 16-bit used)
> depicted in both figures, since it admits up to 32 significant
> bits.  That's the problem.

It does not "admit up to 32 significant bits".  You see,
the Signalling Data Link Identifier is not just some value
invented for the purpose of M2UA.  It happens to be the value
that is used by SS7 MTP Level 3 for identifying the signalling
link facility, where it is defined as a Circuit Identification
Code.  Now, for ITU-T based SS7 variants, the Circuit
Identification Code is a value only significant to 12-bits.  For
ANSI (24-bit point code) derived variants, a Circuit Identification
Code can be significant to 14-bits.

Now, the "Far, Far, Away" national variant could have 16-bit CICs.

Therefore, IT MAY ONLY BE SIGNIFICANT TO 12 OR 14 BITS DEPENDING ON
NATIONAL VARIANT is precisely what I wanted to say and is precisely
correct.

>
> 
> If the latter is closer to what you wanted to say in the RFC
> -- and your above statement clearly seems to confirm this
> interpretation --, as a compromise I suggest to replace the
> original change proposal by this corrected text variant,
> i.e. leave "32-bit" unchanged and  s/may only be/is only/
> in both snippits, if you prefer this version.

I disagree with both.

> Remaining caveat: "significant to n bits" commonly does NOT
> mean that the more significant bits are zero.
> The addition you have included above, "but the value within that
> field only occupies 16 bits ..." is not part of the RFC text.

The diagram is just as normative as the text and the diagram shows
the value as occupying the low order 16 bits of a 32 bit field where
the more significant 16 bits of the 32 bit field are "reserved", which
according to the text are coded as zero, making it also identical with
a 32-bit value that is significant only to 12 or 14 bits (or whatever
the "Far, Far, Away" national variant might happen to specify.

> Effectively, this clause amounts to saying the SDxIs are a 16-bit 
> unsigned values, as my original change proposal requested.

They are not necessarily.  Please stop with the nits.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 17 May 2008 05:46:00 -0600

Alfred,

Alfred Hönes wrote:                          (Sat, 17 May 2008 12:40:18)
> 
> Brian,
> I'm getting even more confused; the arguments appear to be
> contradictory.  In particular, you "disagree with both" --
> leaving the original 'Corrected Text' unchanged, as well as
> changing it.

By both, I meant both changing "may" to "is" and changing
"32-bit" to "16-bit".

> The diagrams clearly show two independent 16-bit wide fields,
> and not a sub-partitioned 32-bit field. I had considered to
> file an Errata Note changing the diagrams to indeed show a
> 32-bit field, but decided that this would be inappropriate.

In fact, the diagram shows a 32-bit value partitioned into a
16-bit reserved field and a 16-bit field which contains a value
that the text identifies may be significant only to 12 or 14
bits.

> The existing inconsistencies in the RFC, for both SDTI and SDLI:
>   - artwork showing a 16 bit wide field, and

No, the artwork shows a 32-bit wide field (unsigned integer
value) containing an 16-bit reserved part and a 16-bit field
that may be significant only to 12 or 14 bits.  Nevertheless,
the parameter (TLV) is a 32-bit unsigned value.

>   - prose talking about a 32-bit unsigned value

The parameter (TLV) as shown is a 32-bit unsigned value.

> is neither a 'nit' nor resolved by waiving circular arguments.

It's a nit.  Both the text and the diagram make it blatantly
obvious how to both: enter the information into the field for
transmission, and extract the information from the field on
reception.  That the 16-bit reserved field and the 16-bit field
containing the value that may be significant to 12 or 14 bits,
combine to form a 32-bit unsigned integer value for the TLV, is
not contradictory.

> You have attempted to cure the inconsistency twofold by adding
> more details, once about the text, and once about diagrams.
> In both cases, these details are not written in the RFC, but both
> would essentially amount in the same clarification as attempted
> by the original Errata Report, but in a much more complicated way.

The information I offered is contained in NORMATIVE references
[2], [3], [4] and [5], and is therefore not repeated in the text.
Implementors should read them if they intend to implement this
OPTIONAL feature.  They are normative.

> Both of these versions give strong evidence that
>   - clarification by an Errata Note is indeed needed, and
>   - the clarification attempted is in the spirit of the RFC.
> 
> Your explanations above confirm that, in any present and foreseeable
> scenario, the values can be represented by (at most) a 16-bit unsigned
> integer.  Under these circumstances, I cannot understand why it might
> be illegitimate or unreasonable to actually designate these values as
> 16-bit unsigned (as had been done in the Errata Note), in a perfect
> match to the field widths shown in the diagrams.

The TLV width is 32-bits.  The reserved portion was diagrammed to make
it clear that the 32-bit unsigned value can be assumed to never be
significant to more than 16-bits.  Removing the reserved field would
make it IMO less clear.  Referring the the TLV value as a 16-bit
unsigned number could confuse the implementor into believing
that they can code the TLV as  X'030B0006xxxx0000' or
X'030C0006xxxx0000', where xxxx is the 12 or 14 significant bit
value, which is not the case.

> To accommodate your insisting on "32-bit", here's a final alternate
> proposal to integrate your reasoning into the Replacement text (again,
> please substitute "SDT" and "SDL", respectively, for all occurrences
> of "SDx" below to get the two instances of 'Corrected Text' required):
> 
>      The SDx Identifier is a 32-bit unsigned value which may only be
> |    is supported by the MTP Level 3 at the ASP; its least significant
> |    16 bits are placed in the SDx Identifier field of the parameter.
>      Insignificant SDxI bits are coded 0.

See, now there you go and say that the implementor can put a 16-bit
field in the TLV when they cannot: they must put a 32-bit field in the
TLV.  I disagree with your third proposal.

> There apparently is significant disagreement on the utility of RFC
> Errata Notes, which reportedly are offered 'to record typos and other
> editorial and technical flaws of RFCs' (as long as the latter do not
> change the intended content of the RFC), as a service to readers and
> prospective authors of derived work, and to off-load RFC authors and
> the RFC Editor from repeated reports of the same issues.

Yours being the only attempted errata report on this text in 6 years
does not meet the purpose of offloading repeated reports of the same
issues.  IMO your proposed changes would be a disservice to readers
of the RFC and could lead to implementation errors and
interoperability issues.

> Therefore, I suggest to not engage in further email exchanges,
> but instead defer the decision on the final errata text to the
> Verifying Party.

I am confident that the verifying party will take into account the
comments of the authors presented here, but, regardless is bound by
the consensus.

--brian

---

From: "David Laight" <[email-masked]>
Date: Mon, 19 May 2008 10:21:56 +0100

I'm getting confused about this discussion about the SDT and SDL
identifiers (not helped by something discarding half of the emails).

Why should M2UA know anything about ISUP CIC values when attempting
to allocate a singalling link?
In many cases the timeslot on a TDM link used for signalling
isn't allocated a CIC number.

I would have thought that any values used here have local
significance to the M2UA server (ie the TDM side) and be
used to determine which TDM timeslot to use.
So the SDTI would select between the physical hardware
units that run MTP2, and the SDLI would select a port.
This would mean that both values might be 32 bit numbers.

We used (a slightly modified) M2UA to link MTP3 to MTP2 on
some of our cards. One difference/problem was the registration
procedures because the MTP2 code was reponsible for allocating
the TDM timslot on an internal link to a local TDM switch,
which has to be switched to the desired external port/timeslot
by the management code. So we needed to return an identifier
back to the M2UA client :-(

> Now, the "Far, Far, Away" national variant could have 16-bit CICs.

16 bit CICs could easily be in use in international links.

	David

Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)  
P Please consider the environment and don't print this e-mail unless you really need to
_______________________________________________
Sigtran mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 May 2008 15:07:29 -0600

David,

David Laight wrote:                                                                                                                                                                                                         (Mon, 19 May 2008 10:21:56)
> isn't allocated a CIC number.

See Q.704/1996 Clause 15.13.4.

> This would mean that both values might be 32 bit numbers.

SDLI is per MTP specifications and is externally significant,
SDTI is only of significance to the ASP and the SG.

> 16 bit CICs could easily be in use in international links.

The field in Q.704/1996 Figure 22 is 12 bits.

--brian