errata logo graphic

Found 6 records.

Status: Verified (1)

RFC5677, "IEEE 802.21 Mobility Services Framework Design (MSFD)", December 2009

Source of RFC: mipshop (int)

Errata ID: 1964

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Verifier Name: Brian Haberman
Date Verified: 2012-09-07

Section 7, Fig. 9 says:

|                MN                                         MoS
 |===================================|    |======| |===================|
 + ---------+                                                +---------+
 | MIH USER |       +------+  +------+    +------+  +------+ | MIH USER|
 | +------+ |       | TCP  |  |DHCP  |    |DHCP  |  | TCP  | | +------+|
 | | MIHF | |       |Client|  |Client|    |Server|  |Server| | | MIHF ||
 +----------+       +------+  +------+    +------+  +------++----------+
     |                 |         |           |         |          |
 ...

It should say:

|                MN                                   Mobility Server
 |===================================|    |======| |===================|
 + ---------+                                                +---------+
 | MIH USER |       +------+  +------+    +------+  +------+ | MIH USER|
 | +------+ |       | TCP  |  |DHCP  |    |DHCP  |  | TCP  | | +------+|
 | | MIHF | |       |Client|  |Client|    |Server|  |Server| | | MIHF ||
 +----------+       +------+  +------+    +------+  +------++----------+
     |                 |         |           |         |          |
 ...

Notes:

Rationale:
The published RFC uses improved terminology, distinguishing
between "MoS" (IEEE 802.21 Mobility Services) and "Mobility
Servers" providing these services -- cf. Section 2 of the RFC.
Unfortunately, this change has been missed for the heading of
Figure 9, on top of page 20.


Status: Held for Document Update (5)

RFC5677, "IEEE 802.21 Mobility Services Framework Design (MSFD)", December 2009

Source of RFC: mipshop (int)

Errata ID: 1962

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Brian Haberman

Section 11.2 says:

   [IEEE80221] "IEEE Standard for Local and Metropolitan Area Networks -
               Part 21: Media Independent Handover Services", IEEE
               LAN/MAN Std 802.21-2008, January 2009,
|              http://www.ieee802.org/21/private/Published%20Spec/
|              802.21-2008.pdf (access to the document requires
|              membership).


It should say:

   [IEEE80221] "IEEE Standard for Local and Metropolitan Area Networks -
               Part 21: Media Independent Handover Services", IEEE
               LAN/MAN Std 802.21-2008, January 2009,
|              http://standards.ieee.org/getieee802/802.21.html.

Notes:

Rationale: By the time of publication of the RFC, the 6-month
IEEE 802 grace period had passed for more than 5 months, and
the specification is now available freely as usual.


Errata ID: 1963

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Brian Haberman

Section 5.3,1st para says:

|  To discover a Mobility Server in a remote network other than home
   network, the MN MUST use the DNS-based MoS discovery method described
   in [RFC5679].  [...]

It should say:

|  To discover a Mobility Server in a remote network other than the home
   network, the MN MUST use the DNS-based MoS discovery method described
   in [RFC5679].  [...]

Notes:

Rationale: Missing article.

Other editorial flaw (keep for update!):
The text of Section 2.1 (page 7) is indented too much;
should be same indentation as for the body of Section 3.


Errata ID: 1965

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Brian Haberman

Section 6.3,2nd para says:

                             [...]  The default maximum number of
   retransmissions is set to 2 and the initial retransmission timer
|  (TMO) is set to 3s when RTT is not known.  The maximum TMO is set to
   30s.

It should say:

                             [...]  The default maximum number of
   retransmissions is set to 2 and the initial retransmission timer
|  (TMO) is set to 3s when the RTT is not known.  The maximum TMO is set
   to 30s.

Notes:

Rationale:
Missing article; adjustment to use of language in preceding text.


Errata ID: 1966

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Brian Haberman

Section 8 says:

|             [...]  Since IEEE 802.21 base specification does not
   provide MIH protocol level security, it is assumed that either lower
   layer security (e.g., link layer) or overall system-specific (e.g.,
   proprietary) security solutions are available.  [...]

It should say:

|             [...]  Since the IEEE 802.21 base specification does not
   provide MIH protocol level security, it is assumed that either lower
   layer security (e.g., link layer) or overall system-specific (e.g.,
   proprietary) security solutions are available.  [...]

Notes:

Rationale: Missing article. (Keep for update!)


Errata ID: 1967

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2009-12-21
Held for Document Update by: Brian Haberman

Section 8.1 says:

a)  1st para:
  
       [...]  In such cases, the link between the DHCP client and Layer
   2 termination point may be protected, but the DHCP message source and
   its messages cannot be authenticated or the integrity of the latter
|  checked unless there exits a security binding between link layer and
   DHCP layer.

b) 2nd para:
                    v
|  In the case where DNS is used for discovering MoS, fake DNS requests
   and responses may cause denial of service (DoS) and the inability of
   the MN to perform a proper handover, respectively.  Where networks
   are exposed to such DoS, it is RECOMMENDED that DNS service providers
   use the Domain Name System Security Extensions (DNSSEC) as described
   in [RFC4033].  Readers may also refer to [RFC4641] to consider the
   aspects of DNSSEC operational practices.

It should say:

a)  1st para:
  
       [...]  In such cases, the link between the DHCP client and Layer
   2 termination point may be protected, but the DHCP message source and
   its messages cannot be authenticated or the integrity of the latter
|  checked unless there exists a security binding between link layer and
   DHCP layer.

b) 2nd para:
                    vvvvv
|  In the case where the DNS is used for discovering MoS, fake DNS
   requests and responses may cause denial of service (DoS) and the
   inability of the MN to perform a proper handover, respectively.
   Where networks are exposed to such DoS, it is RECOMMENDED that DNS
   service providers use the Domain Name System Security Extensions
   (DNSSEC) as described in [RFC4033].  Readers may also refer to
   [RFC4641] to consider the aspects of DNSSEC operational practices.


Notes:

Rationale:
a) typo
b) missing article


Report New Errata