RFC Errata
Found 4 records.
Status: Verified (4)
RFC 4824, "The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS)", April 2007
Source of RFC: INDEPENDENT
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