RFC Errata
Found 16 records.
Status: Verified (1)
RFC 5087, "Time Division Multiplexing over IP (TDMoIP)", December 2007
Source of RFC: pwe3 (int)
Errata ID: 1215
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Verifier Name: Stewart Bryant
Date Verified: 2011-08-04
Section 6, 7th para says:
When the L flag is set there are four possibilities for treatment of payload content. The default is for IWF1 to fill the payload with the appropriate amount of AIS (usually all-ones) data. If the AIS has been generated before the IWF this can be accomplished by copying the received TDM data; if the penultimate TDM link fails and the IWF needs to generate the AIS itself. [...]
It should say:
When the L flag is set there are four possibilities for treatment of
payload content. The default is for IWF1 to fill the payload with
the appropriate amount of AIS (usually all-ones) data. If the AIS
has been generated before the IWF this can be accomplished by copying
| the received TDM data; if the penultimate TDM link fails, the IWF
needs to generate the AIS itself. [...]
^^^^^^
Status: Held for Document Update (11)
RFC 5087, "Time Division Multiplexing over IP (TDMoIP)", December 2007
Source of RFC: pwe3 (int)
Errata ID: 1212
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant
Section 4.3 says:
Protocol (8 bits) is the IP protocol field. It must be set to 0x73
(115), the user port number that has been assigned to L2TP by
IANA.
It should say:
Protocol (8 bits) is the IP protocol field. It must be set to 0x73
| (115), the protocol number that has been assigned to L2TP by
IANA.
^^^^^^^^
Notes:
Near the bottom of page 14, the explanations belo Figure 5
confuse the terms "port number" and "protocol". Sigh!
Errata ID: 1214
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant
Section 4.4 says:
Rows 1 through 6 are the (DIX) Ethernet header; for 802.3 there may be additional fields, depending on the value of the length field, see [IEEE802.3]. Fields not previously described will now be explained.
It should say:
| Rows 1 through 5 are the (DIX) Ethernet header; for 802.3 there may be additional fields, depending on the value of the length field, see [IEEE802.3]. Fields not previously described will now be explained.
Notes:
On page 16, the explanation immediately below Figure 6 gives the wrong
number of rows (6) -- it should be 5 !
Errata ID: 1210
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant
Section 1, 2nd para says:
[...]. In contrast to SAToP, structure-aware methods such as
TDMoIP ensure the integrity of TDM structure and thus enable the PW
to better withstand network degradations. [...]
It should say:
[...]. In contrast to SAToP, structure-aware methods such as
TDMoIP ensure the integrity of the TDM structure and thus enable the
PW to better withstand network degradations. [...]
Notes:
Missing article.
Errata ID: 1211
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant
Section 2, 6th para says:
When structure-aware TDM transport is employed, it is possible to explicitly safeguard TDM structure during transport over the PSN, thus making possible to effectively conceal packet loss events.
It should say:
When structure-aware TDM transport is employed, it is possible to | explicitly safeguard the TDM structure during transport over the PSN, thus making possible to effectively conceal packet loss events.
Notes:
Missing article.
Errata ID: 1213
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant
Date Held: 2011-08-04
Section 4.4, 3rd p. says:
Ethernet encapsulation introduces restrictions on both minimum and maximum packet size. Whenever the entire TDMoIP packet is less than 64 bytes, padding is introduced and the true length indicated by using the Length field in the control word. In order to avoid fragmentation, the TDMoIP packet MUST be restricted to the maximum payload size. For example, the length of the Ethernet payload for a UDP/IP encapsulation of AAL1 format payload with 30 PDUs per packet is 1472 bytes, which falls below the maximal permitted payload size of 1500 bytes.
It should say:
Ethernet encapsulation introduces restrictions on both minimum and maximum packet size. Whenever the entire TDMoIP packet is less than 64 bytes, padding is introduced and the true length indicated by using the Length field in the control word. In order to avoid fragmentation, the TDMoIP packet MUST be restricted to the maximum payload size. For example, the length of the Ethernet payload for a | UDP/IP encapsulation of the AAL1 format payload with 30 PDUs per packet is 1472 bytes, which falls below the maximal permitted payload size of 1500 bytes.
Errata ID: 1216
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant
Section 6, 10th para says:
a)
... trail terminated scenario ...
b)
... trail extended scenario ...
It should say:
a)
... trail-terminated scenario ...
b)
... trail-extended scenario ...
Notes:
Two missing hyphens.
Errata ID: 1217
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant
Section 6, 11th para says:
The final possibility is that of a unidirectional defect in the PSN. In such a case, TDMoIP IWF1 sends packets toward IWF2, but these are not received. [...]
It should say:
The final possibility is that of a unidirectional defect in the PSN. | In such a case, the TDMoIP IWF1 sends packets toward IWF2, but these are not received. [...]
Notes:
Missing article.
Errata ID: 1218
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant
Section 6, 12th para says:
[...]
Since TDM PWs are inherently bidirectional, a persistent defect in
| either directional results in a bidirectional service failure. [...]
^^
It should say:
[...] Since TDM PWs are inherently bidirectional, a persistent defect in | either direction results in a bidirectional service failure. [...]
Notes:
Typo/grammar.
Errata ID: 1222
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant
Section App. B says:
When the TDM circuit is channelized according to [G704], and in particular when it is desired to fractional E1 or T1, it is advantageous to use one of the structured AAL1 circuit emulation services. [...]
It should say:
When the TDM circuit is channelized according to [G704], and in | particular when it is desired to transport fractional E1 or T1, it is advantageous to use one of the structured AAL1 circuit emulation services. [...]
Notes:
In the first paragraph on page 33, the verb "transport" (or similar)
is missing.
Errata ID: 1223
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant
Section App. C says:
CID (8 bits) channel identifier is an identifier that must be unique
for the PW. The values 0-7 are reserved for special purposes,
(and if interworking with VoDSL is required, so are values 8
through 15 as specified in [LES]), thus leaving 248 (240) CIDs per
PW. The mapping of CID values to channels MAY be manually
configured manually or signaled.
It should say:
CID (8 bits) channel identifier is an identifier that must be unique
for the PW. The values 0-7 are reserved for special purposes,
(and if interworking with VoDSL is required, so are values 8
through 15 as specified in [LES]), thus leaving 248 (240) CIDs per
| PW. The mapping of CID values to channels MAY be configured
manually or signaled.
Notes:
Replication of "manually" fixed.
Errata ID: 1224
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Held for Document Update by: Stewart Bryant
Section Norm. Ref's says:
[RFC2119] Bradner, S., "Key Words in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
It should say:
[RFC2119] Bradner, S., "Key Words in RFCs to Indicate Requirement
| Levels", BCP 14, RFC 2119, March 1997.
^^^^^^^^
Notes:
The "BCP14, " tag for RFC 2119 is missing.
Status: Rejected (4)
RFC 5087, "Time Division Multiplexing over IP (TDMoIP)", December 2007
Source of RFC: pwe3 (int)
Errata ID: 1219
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Rejected by: Stewart Bryant
Date Rejected: 2011-08-04
Section 7.3 says:
vvv
1. If the TDMoIP PW has been set up using the PWE3 control
protocol [RFC4447], the regular PW teardown procedures of these
protocols SHOULD be used.
^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
It should say:
1. If a TDMoIP PW over MPLS has been set up using the PWE3 control
protocol [RFC4447], the regular PW teardown procedures of that
protocol SHOULD be used.
Notes:
In the last part of Section 7.3, on mid-page 27, the RFC again does
not fulfill its promises of covering all kind of PW technology.
The first part of the sentence above again only talks about a single
control protocol - RFC 4447 (PW setup & maintenance for MPLS using LDP),
but the second part inconsistently says "procedures of these protocols".
So what about L2TPv3 ???
The text needs to be restricted in scope and made consistent as proposed
in the NEW text, or it needs to be expanded to cover L2TPv3 as well.
--VERIFIER NOTES--
This (pre-RFc5611) text was correct at the time of publication.
Errata ID: 1220
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Rejected by: Stewart Bryant
Date Rejected: 2011-09-13
Section 9 says:
For MPLS PSNs, PW Types for TDMoIP PWs are allocated in [RFC4446].
It should say:
For MPLS PSNs, PW Types for TDMoIP PWs have originally been allocated
provisionally in [RFC4446]; IANA has updated the References for MPLS
pseudowire types 0x0016 and 0x0018 (for TDMoIP AAL1 mode and TDMoIP
AAL2 mode respectively) in the "pwe3-parameters" registry to point
to RFC 5087.
IANA has allocated two pseudowire type values for these encapsulations
from the "L2TPv3 Pseudowire Types" sub-registry of the "l2tp-parameters"
registry as follows:
<TBD1> - TDMoIP AAL1 Mode [RFC5087]
<TBD2> - TDMoIP AAL2 Mode [RFC5087]
Notes:
The IANA considerations given are incomplete and much too imprecise.
The net result is that IANA has *not* reparented the assignments
for TDMoIP to RFC 5087, leaving the registry inconsistent and
confusing for all but the real PWE3 gurus.
And it has been missed entirely to request allocation of L2TPv3
PW types for the two encapsulations described in RFC 5087.
The NEW text shows what IANA better should have been advised to do
during the publication process of RFC 5087.
Perhaps, it is not too late to have these allocations be performed
after the publication of RFC 5087.
--VERIFIER NOTES--
The PW types registry has been updated so that types 0x16 and 0x18 now point to RFC5087. There seems to be limited value to the reader of RFC5087 in directing them to an erratum describing this registry update.
RFC5611 is the document that describes the signalling for TDM PWs using L2TPv3 and allocation of associated code points.
Errata ID: 1221
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Rejected by: Stewart Bryant
Date Rejected: 2011-08-04
Section App. A says:
if D > 0 then
{ packets expected, expected+1, ... received-1 are lost }
while not over-run
place filler (all-ones or interpolation) into playout buffer
if not over-run then
place packet contents into playout buffer
else
discard packet contents
set expected = (received + 1) mod 2^16
else { late packet arrived }
[...]
It should say:
if D > 0 then
{ packets expected, expected+1, ... received-1 are lost }
while not over-run and D > 0
place filler (all-ones or interpolation) into playout buffer
set D = D - 1
if not over-run then
place packet contents into playout buffer
else
discard packet contents
set expected = (received + 1) mod 2^16
else { late packet arrived }
[...]
Notes:
The pseudocode on mid-page 31 is severely flawed.
The counter value 'D' is never decremented and hence almost useless.
The code will erroneously loop until over-run.
Also, the final treatment must be taken out of the loop,
which needs to be indicated by reducing the indentation of 5 lines
by two character positions.
--VERIFIER NOTES--
D is a local temporary variable that is recalculated whenever a new packet is received and the condition (received = expected) is false. The scope of D is the else condition in which it is calculated.
Errata ID: 1209
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-03
Rejected by: Stewart Bryant
Date Rejected: 2011-08-04
Section 1, 5th para says:
As with all PWs, TDMoIP PWs may be manually configured or set up using the PWE3 control protocol [RFC4447]. Extensions to the PWE3 control protocol required specifically for setup and maintenance of TDMoIP pseudowires are described in [TDM-CONTROL].
It should say:
| As with all PWs over MPLS, TDMoIP PWs may be manually configured or set up using the PWE3 control protocol [RFC4447]. Extensions to the PWE3 control protocol required specifically for setup and maintenance of | TDMoIP pseudowires over MPLS are described in [TDM-CONTROL].
Notes:
The RFC pretends to cover all kinds of PWs; RFC 4447 only applies
to PWE3 over MPLS (with LDP signaling).
Either the abover text needs to be restricted in scope as porposed in the NEW
text or it should be amended to correctly cover the L2TPv3 case as well.
--VERIFIER NOTES--
This was correct at the time of publication. It was only with the later publication of RFC5611 that it became possible to signal L2TPv3 TDM PWs.