Re: [Technical Errata Reported] RFC3331 (1425)

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
>      significant to 12 or 14 bits depending on the SS7 variant which
> |    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

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