Found 4 records.

Status: Verified (4)

RFC 4824, "The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS)", April 2007

Errata ID: 878
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Henrik Levkowetz
Date Reported: 2007-04-08
Verifier Name: Jogi Hofmueller
Date Verified: 2007-04-16

Section 3.4 says:

                   SFS       \0/     \0__     0/_     0/
                              |       |       |       |\
                             / \     / \     / \     / \
                              U       V       W       X
                   IP-SFS    ACK     KAL     NAK     RTR

                   -----------------------------------------

                   SFS        0__     0__
                             /|       |\
                             / \     / \
                              Y       Z
                   IP-SFS    RTT    unused

It should say:

                   SFS       \0/     |0       0/_     0/
                              |       |\      |       |\
                             / \     / \     / \     / \
                              U       V       W       X
                   IP-SFS    ACK     KAL     NAK     RTR

                   -----------------------------------------

                   SFS       \0__     0__
                              |       |\
                             / \     / \
                              Y       Z
                   IP-SFS    RTT    unused

Notes:

The illustrated SFS for symbol 'Y', signifying control signal 'RTT',
is depicted as identical with symbol 'M', which signals nibble value
0x0C. This means that some implementations may break off receipt with
an error on receiving 0x0C and interpreting it as RTT, while others
may see RTT and interpret it as a spurious 0x0C, and ignore it.

References [JCroft, Wikipedia] gives a different way of signalling 'Y',
which does not coincide with any of the other symbols. This
discrepancy between the current specification and the references may
also result in both implementation and execution differences, as some
interfaces may already have signal 'Y' hard-coded according to [JCroft]
or [Wikipedia], which will result in transmission of an SFS which will
not be understood by an interface that follows the current specification
strictly.

Author: Errors in the forms of SFS representation for SFS V/KAL and SFS Y/RTT.

from pending

Errata ID: 908
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-09
Verifier Name: Jogi Hofmueller
Date Verified: 2007-04-16

Section 4.3 says:

   [...].  If the link partner ready to receive, it returns an RTR
   signal.

It should say:

   [...].  If the link partner is ready to receive, it returns an RTR
   signal.

Notes:

word omission

from pending

Errata ID: 909
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-09
Verifier Name: Jogi Hofmueller
Date Verified: 2007-04-16

RFC 4824 completely fails to appropriatey point out the benefits and
merits of IP-SFS, and to perform a fair comparison with industry
standard strenght security for common wireless protocols.

Apparently, IP-SFS provides for industry standard Wireless Equivalent
Privacy (WEP).  It *is* a wireless protocol!  Its interfaces do not
consume electrical power (if used under daylight conditions) and do not
produce any electromagnetical interference.  The former property
results in great applicability to developing economies that lack
substantial ubiquitous electrical power distribution but have a lot of
cheap manpower available, but it also makes IP-SFS great for countries
with instable electrical power distribution systems, like the U.S.
(and, yet currently still to a lesser degree, Europe).  Both properties
together make IP-SFS strictly immune to any modern cryptanalytical
methods based on the variation of power consumption over time and to
the suspected industry espionage by the electronical 'sky ears' still
deployed in Europe and otherwise mostly idle, since the end of the Cold
War.

Furthermore, IP-SFS apparently is very well suited for environments
with stringent legal requirements for the war against the Axis of
Evil, with its step-by-step increasing legal custody of privacy and
political correctness of content to be performed / enforced by
legal authorities and cooperating access and content providers.

That should make IP-SFS particularly interesting for the emerging
infrastructure of the .cn domain (and for many other countries,
as well).

To change the disadvantageous presentation of IP-SFS and to address
at least a few of its benefits, I recommend to change, via an RFC
Errata Note, the first paragraph of Section 5,

|  By its nature of line-of-sight signaling, IP-SFS is considered
|  insecure.  The transmission of sensitive data over IP-SFS is strongly
|  discouraged unless security is provided by higher level protocols.

to say:

|  By its nature of line-of-sight signaling, IP-SFS is considered to
|  provide industry strength wireless equivalent security and privacy
|  (WEP).  The transmission of sensitive data over IP-SFS is strongly
|  discouraged unless security is provided by legal environments or
|  corporate guidelines of conduct, impending punishment of the
|  interfaces, or other higher level protocols.


:-)

It should say:

[see above]

Notes:

from pending

Errata ID: 880
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Henrik Levkowetz
Date Reported: 2007-04-08
Verifier Name: Jogi Hofmueller
Date Verified: 2007-04-16

Section 3 says:

   IP-SFS adapts the standard SFSS to encode an alphabet of 16 signals
   (flag patterns) to represent data values 0-15 (Section 3.2.1) and 9
   signals to represent control functions (Section 3.2.2).  With 16 data
   signals, IP-SFS transmission is based upon 4-bit nibbles, two per
   octet.  Each of the signal patterns defined in Section 3.2 is called
   an SFS.

It should say:

   IP-SFS adapts the standard SFSS to encode an alphabet of 16 signals
   (flag patterns) to represent data values 0-15 (Section 3.3) and 9
   signals to represent control functions (Section 3.4).  With 16 data
   signals, IP-SFS transmission is based upon 4-bit nibbles, two per
   octet.  Each of the signal patterns defined in Section 3.2 is called
   an SFS.

Notes:

In Section 3. reference is made to sections 3.2.1 and 3.2.2, which
don't exist. I believe you meant to refer to 3.3 and 3.4 respectively.

from pending

Report New Errata