RFC Errata
Found 6 records.
Status: Verified (1)
RFC 5677, "IEEE 802.21 Mobility Services Framework Design (MSFD)", December 2009
Source of RFC: mipshop (int)
Errata ID: 1964
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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)
RFC 5677, "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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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