[IP-SFS] errata in RFC 4824

[Jogi Hofmüller]

RFC-Editor,

Unfortunately I have to report some errors found by observant readers. I
can confirm all the errors reported and suggest publication on your
errata page whenever possible.

Clive D.W. Feather <clive_AT_demon.net>  and Henrik Levkowetz
<henrik_AT_levkowetz.com> found errors in the forms of SFS representation
for SFS V/KAL and SFS Y/RTT:

Section 3.4

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

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

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

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

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

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

And Henrik Levkowetz also found this one:

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:

  OLD:
    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.
  
  NEW:
    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.

Alfred Hoenes <ah_AT_tr-sys.de> reports a word omission:

Section 4.3

  OLD:
    If the link partner ready to receive, it returns an RTR
    signal.

  NEW:
    If the link partner is ready to receive, it returns an RTR
    signal.            ^^^^

He also argues as follows:

  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,

Section 5, first paragraph

  OLD:
    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.

  NEW:
    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.

I hope you agree to the corrections suggested above. Again, thanks for
all the support!

Regards,
j.
-- 
Gut informierte Kreise berichten, dass Bernhard Neugebauer am liebsten mit Friedrich Tietjen im Park spazieren geht. <<< http://plagi.at/geruecht/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mur.at/pipermail/ip-sfs/attachments/20070416/12825fd9/attachment-0002.pgp