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