RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Report New Errata