Found 1 record.

Status: Held for Document Update (1)

RFC 4888, "Network Mobility Route Optimization Problem Statement", July 2007

Errata ID: 1039
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-11
Held for Document Update by: Ralph Droms

(1)  outdated / inappropriate Reference

The second bullet in Section 2.1 of RFC 4888, on top of page 5, says:

              [...].  For instance, given a voice application using an 8
      kbps algorithm (e.g., G.729) and taking a voice sample every 20 ms
|     (as in RFC 1889 [6]), the packet transmission rate will be 50
      packets per second.  [...]

and Section 6.2, on page 12, contains the details for the ref. [6].

RFC 1889 has long been obsoleted by STD 64, RFC 3550.
Furthermore, I seriously doubt whether the reference to the core
RTP specification is appropriate here; most probably, a reference
to the RTP A/V profile specification, STD 65, RFC 3551, would have
been much more appropriate, because Section 4.5.6 of that RFC
contains the current specification with the relevant details
for the G.729 codec mentioned in the example.


(2)  textual issues in Section 1

The first paragraph of Section 1, on page 3 of RFC 4888, says:

   With current Network Mobility (NEMO) Basic Support [1], all
   communications to and from nodes in a mobile network must go through
   the bi-directional tunnel established between the Mobile Router and
   its Home Agent (also known as the MRHA tunnel) when the mobile
|  network is away.  Although such an arrangement allows Mobile Network
   Nodes to reach and be reached by any node on the Internet,
   limitations associated to the base protocol degrade overall
   performance of the network and, ultimately, can prevent all
   communications to and from the Mobile Network Nodes.

It should perhaps better say, inserting "from home" for clarification:

   With current Network Mobility (NEMO) Basic Support [1], all
   communications to and from nodes in a mobile network must go through
   the bi-directional tunnel established between the Mobile Router and
   its Home Agent (also known as the MRHA tunnel) when the mobile
|  network is away from home.  Although such an arrangement allows
   Mobile Network Nodes to reach and be reached by any node on the
   Internet, limitations associated to the base protocol degrade overall
   performance of the network and, ultimately, can prevent all
   communications to and from the Mobile Network Nodes.

In the subsequent second paragraph of Section 1,

   Some of these concerns already exist with Mobile IPv6 [4] and were
   addressed by the mechanism known as Route Optimization, which is part
   of the base protocol.  With Mobile IPv6, Route Optimization mostly
|  improves the end-to-end path between the Mobile Node and
   Correspondent Node, with an additional benefit of reducing the load
   of the Home Network, thus its name.

perhaps another article "the" should have been inserted:

   Some of these concerns already exist with Mobile IPv6 [4] and were
   addressed by the mechanism known as Route Optimization, which is part
   of the base protocol.  With Mobile IPv6, Route Optimization mostly
|  improves the end-to-end path between the Mobile Node and the
   Correspondent Node, with an additional benefit of reducing the load
   of the Home Network, thus its name.


(3) Appendix A,  Section A.4.3

In the last paragraph of Section A.4.3, at the bottom of page 21,
RFC 4888 says:

              [...].  This is particularly useful for a short-term
   communications that may easily be retried if it fails.  [...]

the phrase
            "a short-term communications"

should have been corrected to say either

            "a short-term communication"
or:
            "short-term communications" .

Report New Errata