Re: [Technical Errata Reported] RFC3331 (1425)

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

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