| MR # | Current Status | Subject | Date | Standard | Page | Subclause | Figure | Table | Classification | Last | First | Perceived Problem | Proposed Remedy | Rationale For Remedy | Remedy's Effect On Existing Equipment | Mar-05 Status | Jul-05 Status | Mar-06 Status | Jul-06 Status | Nov-06 Status | Jul-07 Status | Nov-07 Status | Jul-08 Status |
| 0001 | B | The definition of the NOT_USED define for the secMac variable is incorrect. | 21-Jan-05 | 802.17-2004 | 298 | 11.2.5 | Technical | Lemon | John | The definition of the NOT_USED define for the secMac variable is incorrect. | Change "zero" to "all-ones". | 0xFFFFFFFFFFFF is used as the indication of an invalid address for a secondary MAC address in Table 11.21. | None. | B | B | ||||||||
| 0002 | B | MS-MS scenario does not retain closed ring topology as described in Figure 11.29. | 24-Jan-05 | 802.17-2004 | 336 | 11.6.5.1 | Technical | Chathnath | Praveen | MS-MS scenario does not retain closed ring topology as described in Figure 11.29. Two Manual switches retain single EDGE caused by the first Manual Switch. | The Figure 11.29 and all the associated text should be updated to capture that if there is a Manual Switch present in the ring, second Manual Switch directive would be rejected. | Rationale is captured in the txt file MR_MS-MS-Rationale.txt | Should not affect the exsisting 802.17 equipment. | B | B | ||||||||
| 0003 | B | Ringlet Selection checks for reachability on wrong ringlet. | 24-Jan-05 | 802.17-2004 | 161 | 7.7.1.6.3 | 7.29 | Technical | Chathnath | Praveen | Ringlet Selection checks for reachability on wrong ringlet which would lead to traffic loss in case of a failure in ring. Reachable() function refers to the transmit direction and the topology database is computing reachability based on the receive direction. Detailed problem description is captured in MR_Reachable_PD.txt. | Remedy 1: The function Reachable() should be referring to Other(ringlet), since ringlet refers to the transmit ringlet and the topology database is computing reachability based on the receive ringlet. Remedy 2: Another solution could be changing topology database update reachability on transmit direction. Reachable(address, ringlet) should be modified as to indicate if the Topology database shows that the specified MAC address is reachable via the specified ringlet. Reachablility is determined from topoEntry[Other(ringlet)][index] where index is the index value of the station entry with topoEntry[Other(ringlet)][index] equal to address. Remedy 1 is suggested. | The Reachable() function change is simpler compared to the second option of modifying Topology state machine. | Proper ringlet selection for data frames for steering in case of a failure in ring. No side effects identified. | B | B | |||||||
| 0004 | B | The variable unreservedRate[ri] used in Fairness clause (Pages 273 & 269) should refer to the ringInfo.unreservedRate[ri]. | 24-Jan-05 | 802.17-2004 | 245 | 10.2.4 | Technical | Chathnath | Praveen | The variable unreservedRate[ri] used in Fairness clause (Pages 273 [ed: 249] & 269 [ed: 245]) should refer to the ringInfo.unreservedRate[ri]. Currently it referes to myTopoInfo.unreservedRate[ri] . | Correct the variable reference in 10.2.4 (Page 269 [ed: 245]) to ringInfo.unreservedRate[ri]. | ringInfo.unreservedRate[ri] is the variable which contains information of total unreserved bandwidth in the ringlet. More over myTopoInfo does not have a variable unreservedRate[ri]. | Should not affect the exsisting 802.17 equipment. | B | B | ||||||||
| 0005 | B | Data frames with wrong FCS are copied to the client without any verification or validation. | 25-Jan-05 | 802.17-2004 | 145 | 7.6.3.10.4 | 7.24 | Technical | Bruckman | Leon | In row 6 of table 7.24 data frames with wrong FCS (payload error) are copied to the client without any verification or validation. Since only the payload is errored, the header is presumably right, so the frames should also reach rows 8 to 16, as any other frame. | Remove row 6. Change the condition of row 7 (original 7, before removing 6) to : frame.ft == FT_DATA && !copyBadFcs && frame.fcs != Crc32(frame) | Minimum change. Note also that it is the way it was specified in draft 2.4. | If table 7.24 was implemented "as is", then a minor change in the state machine will be required. | B | B | |||||||
| 0006 | B | The ps is verified for all frames, but SCFF and MCFF frames do not have this bit. | 25-Jan-05 | 802.17-2004 | 139 | 7.6.3.8.4 | 7.22 | Technical | Bruckman | Leon | In rows 4 and 5 of table 7.22 the ps is verified for all frames, but SCFF and MCFF frames do not have this bit (no extendedControl filed in these frames) | In rows 4 and 5 in the condition cell, add the condition: frame.ft != FT_FAIRNESS | Minimum change. | Since this is an obvious error, implementors should have seen this problem and no effect is expected | R | B | |||||||
| 0007 | B | In the case of frame.ri != Other (myRi), the value of receivedTtl is not set. | 25-Jan-05 | 802.17-2004 | 270 | 10.4.8.4 | 10.13 | Technical | Bruckman | Leon | According to row 5 in table 10.13, if frame.ri != Other (myRi) the receivedTtl is not set, but in Table 10.10 row 13 the value of receivedTtl is used to set frame.ttl. Actually, in the case of frame.ri != Other (myRi) the value of receivedTtl is not set at all. | In table 10.13 row 5 add the action: receivedTtl = frame.ttl | Minimum change. | Since this is an obvious error, implementors should have seen this problem and no effect is expected | R | B | |||||||
| 0008 | B | In the box labeled crcB = HeadCrc16(.c), the c within the parenthesys should be replaced with d. | 25-Jan-05 | 802.17-2004 | 590 | E.1.3 | E.3 | Technical | Bruckman | Leon | In the box labeled crcB = HeadCrc16(.c) the c within the parenthesys should be replaced with d. | Replace the label in this box with: crcB = headCrd16(d) | Minimum change. | Since this is an obvious error, implementors should have seen this problem and no effect is expected | R | B | |||||||
| 0009 | B | Four lines are missing at the very end of page 339, so DistantStateMax does not return the correct value. | 10-Mar-05 | 802.17-2004 | 339 | 11.6.5.5 | Technical | Fan | Jason | Four lines are missing at the very end of page 339, so DistantStateMax does not return the correct value. | The four lines are: If ((hops == 1) && (ringlet == ri)) awayState = Max(awayState, tp.spanProtState[ri]); else awayState = Max(awayState, Max(tp.spanProtState[ri], tp.spanProtState[Other(ri)])); In addition, the function Max needs to be directly defined in 11.2.7, rather than referring to Clause 10. Clause 10 refers to the function Max defined in Clause 11 in 10.2.4. | These four lines ensure that awayState takes into account the protection states of all of the appropriate links on the ring, some of which would be missed otherwise. | Equipment with this change will work correctly given the protection states that this equipment sees on the ring. Equipment without this change will not work correctly. | B | B | ||||||||
| 0010 | B | Max() is not defined in Clause 11. | 10-Mar-05 | 802.17-2004 | 245 | 10.2.4 | Technical | Lemon | John | Max() is not defined in Clause 11. | Remove the reference to Max() from 10.2.4 and define the Max() routine in 10.2.3. | A definition is needed instead of the existing circular reference. | None. | R | B | ||||||||
| 0011 | B | Not all conditions are covered for declaring the operational state of the RPR interface to be down. | 10-Mar-05 | 802.17-2004 | 405 | 13.3.1.2 | Technical | Lemon | John | Not all conditions are covered for declaring the operational state of the RPR interface to be down. Both spans can be down by any reason that causes an edge. | Change the entire text of 13.2.1.2 to "The RPR interface operational state (RFC 2863) is determined as follows: * Down if either of the following conditions is true: * RPR interface administrative state (RFC 2863) is down. * Both spans are edges. * Otherwise up.". | It doesn't make sense to include PHY problems, keepalive timeout, and ringlet mismatch and not include other edge reasons. | None. | R | B | ||||||||
| 0012 | B | The values encoded into the station bandwidth ATT should not be weight normalized, and should be converted to timescale used by fairness. | 11-Mar-05 | 802.17-2004 | 311 | 11.4.2.1 | Technical | Lemon | John | The values encoded into the station bandwidth ATT should not be weight normalized, and should be converted to timescale used by fairness. | In 11.4.2.1 and 11.4.2.2, change ", normalized as per 10.1.3.8." to ". The bandwidth is reported in units of bytes per ageCoef agingIntervals, and normalized by dividing by the product of ageCoef and rateCoef to provide the numbers in the units and scale used by the fairness algorithm (see 10.1.3.8).". | The description is incomplete and at least misleading, if not completely incorrect. | Correcting the setting of this field could mislead existing equipment that may have implemented an incorrect assumption of what this field means. | R | B | ||||||||
| 0013 | B | There are a number of issues with the MIB text not conforming to the main clauses in the standard, having invalid ranges or incorrect cross references. | 11-Mar-05 | 802.17-2004 | 472 | D.6 | Technical | Jones | Peter | There are a number of issues with the MIB text not conforming to the main clauses in the standard, having invalid ranges or incorrect cross references. The quick list is as follows: rprIfProtectionSlowTimer should be range (1..10) in 100 ms units with default value=1. RprIfAtdTimer should be (1..10) in 1 seconds units with default value=1. RprIfKeepaliveTimeout should be (2..200) in 1 ms units and fix cross-reference All xxxxTimeElapsed attributes need to change from (0..899) to (0..910) otherwise a completed interval of 900 shows an invalid value. The interval definition allows an interval to be valid for 900 seconds +- 10 seconds, so the elapsed range should match this. RprTopoImageStationIfIndex needs to change to InterfaceIndexOrZero so that if you do not have the information, you can legally report 0. | A copy of the proposed new MIB text and a “diff “ against the current MIB text are separately provided. | Make sure the MIB text matches the main body clauses, and make sure that the data reported matches the MIB definitions. | None. | C | B | ||||||||
| 0014 Closed | J | There is no way to configure the MAC to not operate in a strict ordered mode for clients that do no support the strict_order parameter | 11-Mar-05 | 802.17-2004 | 60 | 6.4.1 | Technical | Holness | Marc | There is no way to configure the MAC to not operate in a strict ordered mode for clients that do no support the strict_order parameter (e.g., bridges). The only way for the MAC not to operate in a stricted ordered mode is for the forceStrict variable to be set to FALSE and the MAC client explicitly sets the strict_order parameter to FALSE. The strict_order mode should be a system configuration. For example, for rings with bridge clients (or clients that don't support the strict_order parameter), a means to turn off strict ordering is required. | Set the (null) behavior of the strict_order parameter to default to FALSE. Proposed text is: (null) - The default value is FALSE. | The standards should support a way for the RPR MAC to operate in both a strict ordered and non strict ordered mode for clients that don't support the strict_order parameter (e.g., bridge clients). | No effect. | R | J | ||||||||
| 0015 Closed | J | No specified manner to collect summary stats associated with rprSpan*Group and rprClient*Group MIBs. | 11-Mar-05 | 802.17-2004 | 580 | D.5 | Technical | Holness | Marc | No specified manner to collect summary (i.e, totals) stats associated with rprSpan*Group (e.g., rprSpanCurrentGroup, rprSpanIntervalGroup, rprSpanDayGroup, etc) and rprClient*Group (e.g., rprClientCurrentGroup, rprClientIntervalGroup, etc.) MIBs. Ceratin carrier customers may want a standard way to collecting the summary stats, as opposed to collecting the plethora of individual counters. | Within rpr[Span/Client][Current/Interval/Day/Stats]Group MIB, add the following objects: rpr[Span/Client]*[In/Out]ClassA[Frames/Octets], rpr[Span/Client]*[In/Out]ClassB[Frames/Octets], rpr[Span/Client]*[In/Out]ClassC[Frames/Octets]. | Service Providers may want to collect the rprSpan*Group and rprClient*Group stats on a more granular basis so that they don't get swamped by all of the fine granular stats. | No impact. | J | |||||||||
| 0016 | B | Range of rprIfKeepaliveTimeout object is (2..50) ms. | 11-Mar-05 | 802.17-2004 | 476 | D.6 | Technical | Holness | Marc | Range of rprIfKeepaliveTimeout object is (2..50) ms. However the state machine description provided in Section 11.6.2.2 states that the range should be (2..200) ms. This inconsistency needs to be resolved. | Change range of rprIfKeepaliveTimeout object to (2..200). | Consistency within the specifications. | No impact. | C | B | ||||||||
| 0017 | B | Range of rprSpanProtectionHoldOffTimer object is (0..500) ms. | 11-Mar-05 | 802.17-2004 | 476 | D.6 | Technical | Holness | Marc | Range of rprSpanProtectionHoldOffTimer object is (0..500) ms. However the state machine description provided in Section 11.2.3 states that the range should be (0..200) ms. This inconsistency needs to be resolved. | Change range of rprIfKeepaliveTimeout object to (0..200). | Consistency within the specifications. | No impact. | B | B | ||||||||
| 0018 Closed | W | 802.3 MAC attributes were mistakenly added to the PacketPHY. | 13-Mar-05 | 802.17-2004 | 416 | B.2.1.6.1 | Technical | Lemon | John | 802.3 MAC attributes were mistakenly added to the PacketPHY. | Remove the 802.3 preamble and IPG from the PacketPHY. | See attached text. | 1G and 10G PHYs are capable of working with without these 10/100 leftovers. | R | W | ||||||||
| 0019 | B | The classC credits are being saved before updating them. | 13-Mar-05 | 802.17-2004 | 112 | 7.5.7.2.4 | 7.11 | Technical | Lemon | John | The classC credits are being saved before updating them. | Move "lastCreditC = creditC;" from first line to last line of the action for Row 9. | The credit amount is stored for comparison in subsequent runs through the shaper in Row 5. This is done to determine if frames are being held too long. So, the credit amount needs to be saved after shaper adjustment. | New equipment with this fixed will not impact equipment already deployed with this incorrect order of setting the saved value. | R | B | |||||||
| 0020 | B | The frame example shown in Figure E.8 shows the protocolType, and therefore the FCS, starting at the wrong offset into the frame. | 13-Mar-05 | 802.17-2004 | 594 | E.2.4 | E.8 | Technical | Lemon | John | The frame example shown in Figure E.8 shows the protocolType, and therefore the FCS, starting at the wrong offset into the frame. | Show protocolType (and therefore FCS) starting 16 bits into a 32-bit alignment of the frame. | Someone implementing what the figure shows would start the FCS 8 bits too early. | New equipment with this fixed will not interoperate with equipment already deployed with an incorrect offset for starting the FCS calculation. | R | B | |||||||
| 0021 | B | SM22 refers to the wrong state machine. | 13-Mar-05 | 802.17-2004 | 193 | 7.8.3.1 | Technical | Lemon | John | SM22 refers to the wrong state machine. | Change "TransmitCount" to "TransmitRoute". | It needs to be clear which statemachine is meant. | None. | R | B | ||||||||
| 0022 | B | SP3 and SP4 refer to the wrong frame type. | 13-Mar-05 | 802.17-2004 | 399 | 12.7.3.4 | Technical | Lemon | John | SP3 and SP4 refer to the wrong frame type. | In SP3, change "MA_CONTROL.request with an opcode value of OAM_ECHO_REQ" to "MA_CONTROL.request with an opcode value of OAM_FLUSH_REQ", and change "Echo flush formats" to "Flush request formats". In SP4, change "MA_CONTROL.indication with an opcode value of OAM_ECHO_IND" to "MA_CONTROL.indication with an opcode value of OAM_FLUSH_IND", and change "Echo flush formats" to "Flush request formats". | It needs to be clear which opcode and frame types are meant. | None. | R | B | ||||||||
| 0023 | B | Table 7.11, Table 7.12, and Table 7.13 direct taking the Min() of 0 and the credit value after being decremented for one byte. | 13-Mar-05 | 802.17-2004 | 112 | 7.5.7.2.4 | 7.11 | Technical | Lemon | John | Table 7.11, Table 7.12, and Table 7.13 direct taking the Min() of 0 and the credit value after being decremented for one byte. | In Table 7.11 Row 1, Table 7.12 Row 1, Table 7.13 Row 1, and Table 7.13 Row 2, change "Min" to "Max". Move the definition of Max forward to Clause 7. | The current text would always drop the credits to zero or to negative credits for every byte transmitted. This check is supposed to be preventing the credits from dropping below zero. | None. | R | B | |||||||
| 0024 | B | Table 7.11 and Table 7.12 do not check at entry to the statemachine if the TICK time has expired. | 13-Mar-05 | 802.17-2004 | 112 | 7.5.7.2.4 | 7.11 | Technical | Lemon | John | Table 7.11 and Table 7.12 do not check at entry to the statemachine if the TICK time has expired. | In Table 7.11, reverse the order of Row 1 and Row 2. In Table 7.12, reverse the order of Row 1 and Row 2. | The current text would always wait for no FE bytes to be available before providing new credits. | None. | R | B | |||||||
| 0025 | B | Table 7.11 and Table 7.12 make use of an undefined constant, NORM. | 13-Mar-05 | 802.17-2004 | 112 | 7.5.7.2.4 | 7.11 | Technical | Lemon | John | Table 7.11 and Table 7.12 make use of an undefined constant, NORM. | Define NORM, preferably in Clause 10 to be ageCoef * rateCoef. Maybe name it DENORM or denorm. | The current text does not specify what this value is intended to be. | None. | R | T | T | B | |||||
| 0026 | B | The description of Table D.2 incorrectly limits the applicability to the operational state of down. | 13-Mar-05 | 802.17-2004 | 468 | D.5.1.3 | Technical | Lemon | John | The description of Table D.2 incorrectly limits the applicability to the operational state of down. | Change "operational down state" to "operational state". | It is clear that this is supposed to be referring to the operational state, regardless of whether it is down or up. | None. | B | B | ||||||||
| 0027 Closed | J | The OAM service primitives and the MIB allow specification of a mac_protection parameter. | 13-Mar-05 | 802.17-2004 | 387 | 12.4 | Technical | Lemon | John | The OAM service primitives and the MIB allow specification of a mac_protection parameter. | Remove the mac_protection parameter from the OAM service primitives and the MIB. | The RingletSelection state machine does not allow control frames to be protected. Implying that the OAM frames can be protected leads to a false conclusion. | None. | R | J | ||||||||
| 0028 | B | The MIB specifies WTR and keepalive as being configured per ring. | 13-Mar-05 | 802.17-2004 | 474 | D.6 | Technical | Lemon | John | The MIB specifies WTR and keepalive as being configured per ring. | Move these configurations from the rprIfEntry to the rprSpanProtectionEntry | WTR and keepalive are specified in 11.2.3 to be per-span. | None. | R | B | ||||||||
| 0029 | B | The PerByte statemachine allows neither RATE_BASED nor SHAPER_BASED admission methods to be chosen. | 13-Mar-05 | 802.17-2004 | 250 | 10.4.1.4 | 10.5 | Technical | Lemon | John | The PerByte statemachine allows neither RATE_BASED nor SHAPER_BASED admission methods to be chosen. | Remove Row 16. Remove the condition from Row 15 (but leave as a comment as is done for Table 10.10 Row 8). | Row 16 conflicts with the PICS and with the rest of the text and could be interpreted to imply that one is allowed to not support any admission method. | None. | R | B | |||||||
| 0030 | B | transmitTpFrame is not being set to FALSE. | 13-Mar-05 | 802.17-2004 | 353 | 11.6.7.4 | 11.17 | Technical | Lemon | John | transmitTpFrame is not being set to FALSE. | Change "transmitTpFrame == FALSE;" to "transmitTpFrame = FALSE;". | C syntax interprets this to mean to check for equivalence and do nothing with the result whereas a set is desired. | None. | B | B | |||||||
| 0031 | B | The row descriptions for Row 3 and Row 4 are switched. | 13-Mar-05 | 802.17-2004 | 355 | 11.6.8.4 | Technical | Lemon | John | The row descriptions for Row 3 and Row 4 are switched. | Switch the row descriptions for Row 3 and Row 4. | The current statemachine is ambiguous as to which interpretation to prefer. | None. | R | B | ||||||||
| 0032 | B | holdoffTimeout and keepaliveTimeout are not shown to be using per-ringlet values. | 13-Mar-05 | 802.17-2004 | 326 | 11.6.2.3 | 11.12 | Technical | Lemon | John | holdoffTimeout and keepaliveTimeout are not shown to be using per-ringlet values. | Modify the statemachine table and 11.6.2.2 to correctly apply these on a per-ringlet basis. | Different spans canhave different characteristics and therefore can need different holdoff values and therefore also keepalive values. It is also clear from 11.2.3 that these are intended to by configured and measured on a per-ringlet basis. | None. | R | B | |||||||
| 0033 | B | There is no adminReqProtection defined. | 13-Mar-05 | 802.17-2004 | 327 | 11.6.3.2 | Technical | Lemon | John | There is no adminReqProtection defined. | Change all references to adminReqProtection to instead reference adminRequestProtection, or vice versa. | Correct and consistent variable names are needed, especially when so many similar names are provided. | None. | R | B | ||||||||
| 0034 | B | The statemachine rows 10, 11, and 12 do not correspond to the row descriptions. | 13-Mar-05 | 802.17-2004 | 342 | 11.6.5.6 | 11.15 | Technical | Lemon | John | The statemachine rows 10, 11, and 12 do not correspond to the row descriptions. | Change the row descriptions to match the statemachine. | The statemachine is correct and the row descriptions are not. | None. | R | T | B | ||||||
| 0035 | B | The row description for Row 12 is incorrect. | 13-Mar-05 | 802.17-2004 | 335 | 11.6.4.4 | Technical | Lemon | John | The row description for Row 12 is incorrect. | Change the row description to "Otherwise, no topology database update is needed." | Row 12 does not continue with database update. | None. | R | B | ||||||||
| 0036 Closed | J | The figure shows two links that don't exist. | 13-Mar-05 | 802.17-2004 | 323 | 11.6.1 | 11.28 | Technical | Lemon | John | The figure shows two links that don't exist. | Remove the link from ReceiveTpFrame to ParseTpFrame. Remove the link from ReceiveMonitor to ProtectionUpdate. | ReceiveTpFrame notifies TopologyControl of the received TP frame (via the Q_RX_TP_PARSE queue), and then TopologyControl calls ParseTpFrame. So the frame in enqued by ReceiveTpFrame and dequeued by ParseTpFrame, but only with the intermediate interaction of TopologyControl. A change in span status is detected by ReceiveMonitor, which then sets spanOperStatus. The change in spanOperStatus is detected by TopologyControl, which calls ProtectionUpdate. There is no direct linkage from ReceiveMonitor to ProtectionUpdate. | None. | R | J | |||||||
| 0037 Closed | J | This allows an FS to be replaced by an MS. | 13-Mar-05 | 802.17-2004 | 341 | 11.6.5.6 | 11.15 | Technical | Lemon | John | This allows an FS to be replaced by an MS. | Add the following row after Row 4: Condition: adminReqProtection[ri] == MS && myTopoInfo.spanProtState[ri] >= MS Action: spanProtAdmin = IDLE; adminReqProtection = NULL; Next State: MAIN | If you start with FS on the east side of a station and then command MS on the east side of the same station, the standard will currently allow the FS to be replaced by MS. | None. | R | T | J | ||||||
| 0038 | B | There is no PICS entry for the "may" in the definition of localWeight, and no corresponding text in the MIB definition. | 13-Mar-05 | 802.17-2004 | 242 | 10.2.2 | Technical | Lemon | John | There is no PICS entry for the "may" in the definition of localWeight, and no corresponding text in the MIB definition. | Add a PICS entry and correct the MIB description. | The PICS and MIB do not correspond to the standard. | None. | R | B | ||||||||
| 0039 | B | There is no MIB attribute for stabilityTimeout. | 13-Mar-05 | 802.17-2004 | 346 | 11.6.6.3 | Technical | Lemon | John | There is no MIB attribute for stabilityTimeout. | Add a MIB attribute for stabilityTimeout. | The configurable attribute is missing from the MIB. | None. | R | B | ||||||||
| 0040 | B | rprIfCurrentStatus is does not provide status and is missing most of 11.2.9. | 13-Mar-05 | 802.17-2004 | 480 | D.6 | Technical | Lemon | John | rprIfCurrentStatus is does not provide status and is missing most of 11.2.9. | Change rprIfCurrentStatus to rprIfCurrentDefects. Add the defects in 11.2.9 that are not included in this bit field. | Status implies much more than which defects are in effect. This list of defects is missing most of the defects. | None. | R | B | ||||||||
| 0041 | B | RprTopoImageEntry is missing an attribute corresponding to spanEdge[ri]. | 13-Mar-05 | 802.17-2004 | 489 | D.6 | Technical | Lemon | John | RprTopoImageEntry is missing an attribute corresponding to spanEdge[ri]. | Add an attribute corresponding to spanEdge[ri]. | This needs to be reported in the MIB. | None. | R | B | ||||||||
| 0042 | B | rprTopoImageWestProtectionStatus and rprTopoImageEastProtectionStatus are not statuses and are not bit fields. | 13-Mar-05 | 802.17-2004 | 492 | D.6 | Technical | Lemon | John | rprTopoImageWestProtectionStatus and rprTopoImageEastProtectionStatus are not statuses and are not bit fields. | Change rprTopoImageWestProtectionStatus and rprTopoImageEastProtectionStatus to rprTopoImageWestProtectionState and rprTopoImageEastProtectionState. Change them from bit fields to integers. | These provide the current protection state. Only one state can be active at a time. | None. | R | B | ||||||||
| 0043 | B | rprTopoImageStatus fields receivedBadFcs and receivedMultichokeFairness are not events indicating such things have been received. | 13-Mar-05 | 802.17-2004 | 493 | D.6 | Technical | Lemon | John | rprTopoImageStatus fields receivedBadFcs and receivedMultichokeFairness are not events indicating such things have been received. | Change receivedBadFcs to receivesBadFcs. Change receivedMultichokeFairness to receivesMultichokeFairness. Correct their descriptions to indicate that these advertise what a station wishes to receive, not some events that have happened. | The current names and descriptions are incorrect. | None. | R | B | ||||||||
| 0044 | B | Extraneous '{' and '}'s. | 13-Mar-05 | 802.17-2004 | 363 | 11.6.13.3 | Technical | Lemon | John | Extraneous '{' and '}'s. There is an extraneous '}' after the first for statement of SecondaryMacCount(), an extraneous '}' before the return statement of SecondaryMacCount(), and an extraneous '{' at the end of the line of the third for statement of SecondaryMacValidation(). | Remove extraneous '{' and '}'s. | Extra '{' and '}'s are syntactically incorrect. | None. | R | B | ||||||||
| 0045 | B | The protMisconfigDefect is not cleared even after the configuration mismatch has been corrected. | 14-Mar-05 | 802.17-2004 | 333 | 11.6.4.4 | 11.14 | Technical | Sultan | Bob | The protMisconfigDefect is not cleared even after the configuration mismatch has been corrected. This occurs because topoChanged is not set to TRUE in Table row 11.14.11 when a TpFrame is received with a new value tpFrame.prefs.wc. As a result, protMisconfigDefect = MismatchedProtection() is not invoked by table tow 11.16.9, and protMisconfigDefect is not cleared unless a topology change subsequently occurs. (request submitted on behalf of Wendy Lao who found this problem). | Insert the action topoChanged = TRUE in Table row 11.14.11. | Simple change that fixes problem. | None except to fix problem. | B | B | |||||||
| 0046 | B | DistantStateMax() does not return the correct value of awayState for cases in which a station has an edge, but the edge is not caused by the station on the far-end of the span. | 14-Mar-05 | 802.17-2004 | 339 | 11.6.5.5 | Technical | Sultan | Robert | DistantStateMax() does not return the correct value of awayState for cases in which a station has an edge, but the edge is not caused by the station on the far-end of the span. Specifically, the code on lines 38-44 describes an action only in the case that tp.spanEdge[ringlet] && tp.spanProtState[ringlet] == IDLE but does not describe an action for other cases of tp.spanEdge[ringlet]. (Reported on behalf of Sanjay Sharma of Fujitsu Network Communications). | // Edge reached. Determine whether or not idle edge. if (tp.spanEdge[ringlet]) { // Idle edge reached. Determine if reported by neighbor if (tp.spanProtState[ringlet] == IDLE) { idleEdge[ringlet] = TRUE; if (topoEntry[Other(ringlet)][1].valid && tp.macAddress != topoEntry[Other(ringlet)][1].macAddress) idleEdgeNotFromNbr[ringlet] = TRUE; } else { // Edge reached is not idle. Report away state. awayState = tp.spanProtState[ringlet]; } break; } | Simple fix returns expected awayState. | Corrects problem in existing equipment. | T | T | I | B | ||||||
| 0047 Closed | J | A station may become the head of a congestion domain based solely on the rate of transiting non-reserved traffic. | 14-Mar-05 | 802.17-2004 | 256 | 10.4.3.4 | 10.8 | Technical | Sultan | Robert | In the case of the aggressive fairness method, a station may become the head of a congestion domain based solely on the rate of transiting non-reserved traffic, even when the local station is not adding fairness-eligible traffic or when transiting fairness-eligible traffic is sufficient to exceed the rateLowThreshold without the contribution of the local station. In such cases, add rates within the congestion domain are unnecessarily (and repeatedly) throttled to a small value, significantly reducing ring utilization. | T | T | J | |||||||||
| 0048 | B | The definition of classCAccessDelayTimer suggests that the timer specifies the longest waiting time of any traffic waiting for transmission. | 14-Mar-05 | 802.17-2004 | 79 | 7.2.2 | Technical | Sultan | Robert | The definition of classCAccessDelayTimer suggests that the timer specifies the longest waiting time of any traffic waiting for transmission. The definition of classCAccessDelayTimerExpired suggests that the classCAccessDelayTimer specifies the time since the most recent transmission. In general, the latter definition makes it less likely that access-delay expiration will occur (same problem for classA and ClassB definitions. | Make both definitions of classCAccessDelayTimer and classCAccessDelayTimerExpired consistent with the definition of classCAccessDelayTimerThreshold. Specifically: classCAccessDelayTimer - Indicates the largest amount of time any classC add traffic having met requirements for transmission, has been waiting for transmission. classCAccessDelayTimerExpired - Indicates whether the access delay timer for classC add traffic has exceeded the classCAccessDelayTimerThreshold. (Similar changes for classA and C) | Simple fix, consistent with definition of classCAccessDelayTimerThreshold, preserves the effectiveness of the accessDelayTimer. | Allows accessDelay to be an effective means of congestion detection. | T | T | B | |||||||
| 0049 Closed | J | Table 7.10 Row 4 does not cover the case in which there are multiple frames waiting, and only some were sent. | 14-Mar-05 | 802.17-2004 | 108 | 7.5.6.4 | 7.10 | 7.10 | Technical | Sultan | Robert | Table 7.10—ClassBShaper state table row 4 increments the classBAccessDelayTimer when: ClassBEntryAvailable() && startingCreditB == lastCreditB. This increments the timer when there are frames waiting and no frames have been sent. The row does not cover the case in which there are multiple frames waiting, and only some were sent. | Add a row to the table for the case of ClassBEntryAvailable() && startingCreditB != lastCreditBclassBAccessDelayTimer. In this case, the accessDelayTimer takes its value from the frame remaining to be transmitted that has spent the longest time on the transmission queue. Since this method requires the maintainance of multiple time values, an alternative is to declare accessDelay based on the length of the queue of frames awaiting transmission. | Prevents accessDelayTimer mechanism from being defeated by a 'trickle' of transmitted traffic. | Allows accessDelay to be an effective means of congestion detection. | T | T | J | |||||
| 0050 | B | The value of creditS is always equal to zero. | 15-Mar-05 | 802.17-2004 | 115 | 7.5.7.4.4 | 7.13 | 7.13 | Technical | Caizzone | Giuseppe | According to Table 7.13 if creditS = Min(0, creditS - 1) as shown in row 1 or creditS = Min(0, creditS + 1) as shown in row 2, the value of creditS is always equal to zero. | In Table 7.13 row 1 replace Min(0,creditS-1) with Max(0,creditS-1) and in row 2 replace Min(0,creditS+1) with Max(0,creditS+1). In this way the minimum value of creditS is equal to zero | Minimum change | This is an obvious error and the implementors should have seen it. No particular effect is expected | R | B | ||||||
| 0051 | B | Echo frames are requested by the client, and not the management system. | 15-Mar-05 | 802.17-2004 | 381 | 12.1.4 | Technical | Bruckman | Leon | Echo frames are requested by the client, and not the management system. The text is wrong | "allows the management system" shall be replaced with: "allows the client" | Fix the text to reflect the standard | None | R | B | ||||||||
| 0052 | B | rprSpanStatsInOamEchoFrames and rprSpanStatsOutOamEchoFrames each mistakenly combined two counters from the standard. | 15-Mar-05 | 802.17-2004 | 525 | D.6 | Technical | Lemon | John | rprSpanStatsInOamEchoFrames and rprSpanStatsOutOamEchoFrames each mistakenly combined two counters from the standard. | Divide rprSpanStatsInOamEchoFrames into rprSpanStatsInOamEchoReqFrames and rprSpanStatsInOamEchoRspFrames. Divide rprSpanStatsOutOamEchoFrames into rprSpanStatsOutOamEchoReqFrames and rprSpanStatsOutOamEchoRspFrames. | The standard purposely counted the two types of echo frames separately, and the MIB was supposed to follow the standard. | None. | R | B | ||||||||
| 0053 Closed | J | The control frames counters in RprSpanCountersStatsEntry are in the wrong location. | 15-Mar-05 | 802.17-2004 | 525 | D.6 | Technical | Lemon | John | The control frames counters in RprSpanCountersStatsEntry are in the wrong location. | Move the control frames counters from RprSpanCountersStatsEntry (and associated span tables) to RprClientCountersStatsEntry (and associated client tables). | The standard counts control frames at client receive (Table 7.26) and client transmit (Table 7.33), and does not count control frames separately at span receive (Table 7.21) and span transmit (Table 7.36). | None. | R | J | ||||||||
| 0054 | B | DistantStateMax() does not correctly handle the 2-station case. | 15-Mar-05 | 802.17-2004 | 339 | 11.6.5.5 | Technical | Fan | Jason | The if statement if (ringlet != ri && topoEntry[Other(ringlet)][1].valid && tp.macAddress == topoEntry[Other(ringlet)][1].macAddress) { awayState = Max(awayState, tp.spanProtState[ri]); break; } is designed to prevent WTR from being pre-empted when a broken span is reconnected in a ring with 2 stations. WTR is being pre-empted because this if statement is not entered. The reason that the if statement is not entered is that the neighbor station is not yet valid, because TP frames that may be received over an SF link are discarded. | The remedy is to replace the if statement with: if (ringlet != ri && tp.macAddress == topoEntry[Other(ringlet)][1].macAddress) { awayState = Max(awayState, tp.spanProtState[ri]); break; } This enables the if statement to be entered in the two station case, so that WTR will remain if the neighbor station has not changed from before the span break. This does not cause a problem if the neighbor station has changed in the meantime (which requires that WTR be cleared). Once WTR is entered, the next TP frame received from the new neighbor will result in newNeighbor[rid] beoing set to true in Row 15 of Table 11.14, which will result in WTR being cleared in row 21 of Table 11.15. | See remedy. | Equipment with this change will enter WTR correctly on a 2 station ring. Equipment without this change will go directly from SF to IDLE in many cases on a 2 station ring. | R | T | B | |||||||
| 0055 Closed | J | Multicast or broadcast control frames can increment the ttlExpiredFrames counter. | 16-Mar-05 | 802.17-2004 | 139 | 7.6.3.8.4 | 7.22 | 7.22 | Technical | Lemon | John | Multicast or broadcast control frames can increment the ttlExpiredFrames counter. | Add "frame.ft == FT_DATA" to the condition for Table 7.22 Row 15. | TTL expiration was not supposed to be applied to control frames. | None. | R | T | J | |||||
| 0056 | B | The term "flow" is used without a definition. | 16-Mar-05 | 802.17-2004 | 121 | 7.6.2 | Technical | Lemon | John | The term "flow" is used without a definition here and on page 380. | Replace "flow" with "conversation". | IEEE 100 defines "flow" to mean something very different from how the term is being used in this standard. This standard provides no definition of "flow", thereby implying the IEEE 100 definition. The term "conversation" is defined in IEEE 100 and is consistent with the usage of "flow" in this standard. | None. | - | R | B | |||||||
| 0057 | B | The heading for the third row of Table 10.16 is incorrect. | 23-Mar-05 | 802.17-2004 | 281 | 10.5 | 10.16 | Technical | Lemon | John | The heading for the third row of Table 10.16 is incorrect. | Replace "LINK_RATE (bytes per ageCoef agingIntervals)" with "bytes per agingInterval" and add text explaining that the LINK_RATE is the value shown multiplied by the value of ageCoef. | It is not possible to show the actual LINK_RATE because the value of ageCoef is implementation dependent. | None. | - | R | B | ||||||
| 0058 | B | Incorrect row description for Row 10.5-5. | 23-Mar-05 | 802.17-2004 | 251 | 10.4.1.4 | 10.5 | Technical | Lemon | John | Incorrect row description for Row 10.5-5. | Change "A byte of fairness eligible transit traffic bound for a destination beyond the congestion point" to "A byte of fairness eligible transit traffic bound for a destination short of the congestion point". | This row handles traffic that is not going through the congestion point. | None. | - | R | B | ||||||
| 0059 | B | For a center-wrapping ring with bidirectional flooding, wouldn't that still be replicated with the we==1? | 05-Apr-05 | 802.17-2004 | 157 | 7.7.1.2.5 | Technical | James | David | I was looking over the ringlet selection, with simplifications (in my judgment) appropriate for RBR. A few questions arose. The text notes that: >>For wrapping rings, if the frame is not replicated, the we field is set. >>For wrapping rings, if the frame is replicated, the we field is not set. >>For steering rings, the we field has no meaning and is not set. What about a center-wrapping ring with bidirectional flooding. Wouldn't that still be replicated with the we==1? I would have thought that was necessary to be protected. | Correct text as appropriate. | - | R | B | |||||||||
| 0060 Closed | J | Incorrect ringlet selection for a bidirectional flooded frame on a center-wrapped station. | 05-Apr-05 | 802.17-2004 | 164 | 7.7.1.6.4 | 7.29 | Technical | James | David | This code appears to send a bidirectional flooded frame on both ringlets. This will not work on a center-wrapped station. Instead, they should be sent through the same datapath, but with distinct frame.ri identifiers. | 1) Provide text that clarifies how bidirectional frames are processed on a center-wrapped station, so the intent is clear. 2) Revise state machines to track the text of (1). | - | R | T | J | |||||||
| 0061 Closed | J | Problems with topo frames and fairness frames for a center-wrapped station. | 05-Apr-05 | 802.17-2004 | 164 | 7.7.1.6.4 | Technical | James | David | I believe the Transmit states will send all topo frames to the single connected datapath on a center wrapped ring. This should not be forced to be the case. Also, its unclear how fairness frames go across the wrapped center-wrapped station. | 1) Provide text that clarifies how control frames are processed, so the intent is clear. 2) Revise state machines to track the text of (1). | - | R | T | J | ||||||||
| 0062 | B | Extra space in "size Stq". | 05-Apr-05 | 802.17-2004 | 477 | D.6 | Technical | James | David | Extra space in: size Stq | Change: size Stq ==> sizeStq | - | R | B | |||||||||
| 0063 | B | The rprOamRequestCount is not cross-referenced to an RPR variable. | 05-Apr-05 | 802.17-2004 | 502 | D.6 | Technical | James | David | The rprOamRequestCount no has meaning within the current definition, but appears to be from the history of when we assumed the MAC would support some sort of auto-retry and timeouts. Furthermore, there is no cross-reference to an RPR variable, which reinforced the aforementioned thoughts. | Delete rprOamRequestCount material at the end of page 502 to top of page 503 as well as other rprOamRequestCount related material. | - | R | B | |||||||||
| 0064 | B | The rprOamTimeout is not cross-referenced to an RPR variable. | 05-Apr-05 | 802.17-2004 | 503 | D.6 | Technical | James | David | The rprOamTimeout has no meaning within the current definition, but appears to be from the history of when we assumed the MAC would support some sort of auto-retry and timeouts. Furthermore, there is no cross-reference to an RPR variable, which reinforced the aforementioned thoughts. | Delete rprOamTimeout material at the top of page 503 to further down on page 503 as well as other rprOamTimeout related material. | - | R | B | |||||||||
| 0065 | B | The rprOamControl is not cross-referenced to an RPR variable. | 05-Apr-05 | 802.17-2004 | 503 | D.6 | Technical | James | David | The rprOamControl has no meaning within the current definition, but appears to be from the history of when we assumed the MAC would support some sort of auto-retry and timeouts. Furthermore, there is no cross-reference to an RPR variable, which reinforced the aforementioned thoughts. | Delete rprOamControl material at the top of page 503 to further down on page 503 as well as other rprOamControl related material. | - | R | B | |||||||||
| 0066 | B | The rprOamResponseCount is not cross-referenced to an RPR variable. | 05-Apr-05 | 802.17-2004 | 503 | D.6 | Technical | James | David | The rprOamResponseCount has no meaning within the current definition, but appears to be from the history of when we assumed the MAC would support some sort of auto-retry and timeouts. Furthermore, there is no cross-reference to an RPR variable, which reinforced the aforementioned thoughts. | Delete rprOamResponseCount material at the middle of page 503 to further down on page 503 as well as other rprOamResponseCount related material. | - | R | B | |||||||||
| 0067 | B | The rprOamAvResponseTime is not cross-referenced to an RPR variable. | 05-Apr-05 | 802.17-2004 | 503 | D.6 | Technical | James | David | The rprOamAvResponseTime has no meaning within the current definition, but appears to be from the history of when we assumed the MAC would support some sort of auto-retry and timeouts. Furthermore, there is no cross-reference to an RPR variable, which reinforced the aforementioned thoughts. | Delete rprOamAvResponseTime material at the middle of page 503 to further down on page 503 as well as other rprOamAvResponseTime related material. | - | R | B | |||||||||
| 0068 | B | The rprOamResponseStatus is not cross-referenced to an RPR variable. | 05-Apr-05 | 802.17-2004 | 503 | D.6 | Technical | James | David | The rprOamResponseStatus has no meaning within the current definition, but appears to be from the history of when we assumed the MAC would support some sort of auto-retry and timeouts. Furthermore, there is no cross-reference to an RPR variable, which reinforced the aforementioned thoughts. | Delete rprOamResponseStatus material at the bottom of page 503 to top on page 504 as well as other rprOamResponseStatus related material. | - | R | B | |||||||||
| 0069 | B | Wrong name: "toClientUcastClassBCirAFrames". | 05-Apr-05 | 802.17-2004 | 556 | D.6 | Technical | James | David | Wrong name: toClientUcastClassBCirAFrames | Change: toClientUcastClassBCirAFrames to toClientUcastClassBCirFrames | - | R | B | |||||||||
| 0070 Closed | J | There is an entry for client-in broadcast counts, but not multicast. | 05-Apr-05 | 802.17-2004 | 558 | D.6 | Technical | James | David | There is an entry for broadcast counts, but not multicast. | Insert something like the following: rprClientStatsInMcastFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MAC to client multicast frames. This is used only when deriving the multicast and broadcast packet counters for the interface MIB." REFERENCE "IEEE 802.17 Subclause 7.2.5, toClientMcastFrames" ::= { rprClientCountersStatsEntry 18 } | - | R | J | |||||||||
| 0071 Closed | J | There is an entry for client-out broadcast counts, but not multicast. | 05-Apr-05 | 802.17-2004 | 561 | D.6 | Technical | James | David | There is an entry for broadcast counts, but not multicast. | Insert something like the following: rprClientStatsOutMcastFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of client to MAC multicast frames. This is used only when deriving the multicast and broadcast packet counters for the interface MIB." REFERENCE "IEEE 802.17 Subclause 7.2.5, fromClientMastFrames" ::= { rprClientCountersStatsEntry 35 } | - | R | J | |||||||||
| 0072 | B | rampUpCoef does not belong in the condition of Row 5. | 20-May-05 | 802.17-2004 | 258 | 10.4.4.4 | 10.9 | Technical | Wu | Guoliang | Condition of Row 5 contains error. The condition is: localFairRate/localWeight >= unreservedRate[myRi] - rampUpCoef. On the Right Hand Side of the inequality, unreservedRate is in bytes and rampUpCoef is a pure number. | Revise the condition of Row 5. Row 5 description on Page 259 mgiht be updated for alignment with Row 5 contents. Necdet Uzun proposed the following remedy (in 5/17/2005 email): localFairRate/localWeight >= unreservedRate[myRi]. | - | R | T | B | |||||||
| 0073 | B | allowedRate is calculated twice in Row 5 and Row 16. The later calculation overrides the early one. | 20-May-05 | 802.17-2004 | 258 | 10.4.4.4 | 10.9 | Technical | Wu | Guoliang | allowedRate calculated twice in Row 5 and Row 16. The later calculation overrides the early one. One of the calculations should be removed or changed. | Two options: A) delete allowedRate calculation in Row 5, B) add normLocalFairRate calculation in Row 5 and change next state to RETURN. | Eliminates double calculation of allowedRate. | Option A does not affect equipment behavior. Option B ramps up allowedRate towards maxAllowedRate, which is a reasonable behavior. | - | R | B | ||||||
| 0074 | B | Incorrect comparison between fairRate and receivedRate. | 31-May-05 | 802.17-2004 | 262 | 10.4.5.4 | 10.10 | Technical | Bruckman | Leon | In Table 10.10 the condition of row 5 is: localCongested && normLocalFairRate | Reaplace the condition in Table 10.10 row 5 to: localCongested && normLocalFairRate <= receivedRate. For consistency, the condition in row 7 can be changed to: downstreamCongeted && normLocalFairRate > receivedRate. | Minimal change that fixes a problem | None | - | R | B | ||||||
| 0075 | B | Wrong table name. | 01-Jun-05 | 802.17-2004 | 189 | 7.7.10.4 | Technical | Bruckman | Leon | Wrong table name in the first sentence of the section. | Change: The TransmiCount to: The TransmitRoute | Consistency | None | - | R | B | |||||||
| 0076 | B | A frame with a multicast DA can be sent on the ring with frame.fi = FI_NONE. | 13-Jul-05 | 802.17-2004 | 163 | 7.7.1.6.4 | 7.29 | Technical | Jones | Peter | In row 21 in this state machine, the text permits a frame with a multicast DA and a provided flooding form of FLOOD_NONE to be sent on the ring with frame.fi = FI_NONE. Transmitting a multicast frame with FI_NONE is not valid | Insert a new row between 20 and 21 with Condition = !unicast(frame.da), Action = “-”, State = “FORM”. Change rows 24 to 27 to remove the test for “Unicast(frame.da)” | This will ensure that all multicats frames are sent with the frame.fi set to FI_BIDIR or FI_UNIDIR, and also removes the need to test for "unicast(da)" in later rows within the state. | none | - | R | B | ||||||
| 0077 Closed | J | If there's a fiber loopback, ReceiveTpFrame can not report this specific error, just a large scope error of miscabling. | 25-Jul-05 | 802.17-2004 | 355 | 11.6.8.4 | 11.18 | Technical | li | jian | If there's a fiber loopback, ReceiveTpFrame state can not clear notify this error, just detect a large scope error - miscable. | 1. insert a row between row4 and row5, the content in new row is following: condition " frame.ri!=ri && frame.ttl==MAX_STATION && frame.sa==myMacAddress" action "loopbackDefect[ri] = TRUE" state "START" 2. add content as following at the action of row5: loopbackDefect[ri] = FALSE | Clearly and definitely islate the fiber loopback that is a very normal problem. If we add this remedy, we can easyly notify this problem, rather than a widely common problem - "miscabling". | very simply. | - | - | J | ||||||
| 0078 | B | ResetStqWatermarks() resets stqHighWatermark to stqSize. | 28-Jul-05 | 802.17-2004 | 254 | 10.4.2.3 | Technical | Sood | Mohit | Logical error in ResetStqWatermarks() routine in Section 10.4.2.3. This routine resets stqHighWatermark to stqSize. As a result, in the routine RecordStqWatermarks(), stqHighWatermark never gets updated to the highest measured occupancy of STQ. It will always remain at stqSize (maximum size of STQ). | stqHighWatermark should either be reset to 'zero' in ResetStqWatermarks() routine in Section 10.4.2.3. | RecordStqWatermarks() updates stqHighWatermark by calculating the maximum between previous value of stqHighWatermark and stqDepth (current occupancy of STQ). If stqHighWatermark is reset to stqDepth or 'zero', then stqHighWatermark will not be fixed at stqSize, but will represent the highest measured occupancy of STQ. | Currently use of stqHighWatermark is not specified in the standard. However, whoever uses this value (say client), would see a correctly measured value of stqHighWatermark. | - | - | B | |||||||
| 0079 | B | Wrong routine name, InitLowPassFilteredRates(), in Table 10.6. | 29-Jul-05 | 802.17-2004 | 255 | 10.4.2.4 | 10.6 | Technical | Sood | Mohit | Wrong routine name : InitLowPassFilteredRates(), in table 10.6 | Change InitLowPassFilteredRates() to InitLpFilteredRates() | Refer to routine definition, 10.6 in Section 10.4.2.3 on page 253 | None | - | - | B | ||||||
| 0080 | B | frtt is computed before LrttToTail is computed. | 23-Sep-05 | 802.17-2004 | 277 | 10.4.10.5 | 10.15 | Technical | Sood | Mohit | Table 10.15, lines 11 and 12 : FRTT is computed before LRTT-To-Tail is computed. This is a redundant computation, since the same computation is done again in line 18. | Remove "frtt = fdd + lrttToTail;" from lines 11 and 12 and let it remain in line 18. | Based on the formula "frtt = fdd + lrttToTail", 'frtt' should be computed only after both 'fdd' and 'lrttToTail' have been computed, which is OK for line 18. But there is no point in calculating 'frtt' in lines 11 and 12. | None | - | - | B | ||||||
| 0081 | B | The MAC service interface provides the number of hops to the congestion point, not the nearest congested station. | 25-Sep-05 | 802.17-2004 | 56 | 6.3.1 | Technical | Sultan | Robert | The statement "the MAC service interface also provides the number of hops to the nearest congested station." is not strictly correct. The MAC service interface provides the number of hops to "the congestion point" or "the head of the congestion domain in which the local station lies". | Change "For service class classC, the MAC service interface also provides the number of hops to the nearest congested station." to "For service class classC, the MAC service interface of a station lying within a congestion domain also provides the number of hops to the head of the congestion domain in which that station lies." | More accurate description. | None. | - | - | B | |||||||
| 0082 Closed | J | Add a timestamp mechanism for oam echo request/response frame. | 27-Sep-05 | 802.17-2004 | 409 | 12.3.1 | 12.4 | Technical | li | jian | Add a timestamp mechanism for oam echo request/response frame just as LRRT frame to remove the latency of host dealing with. | just like the LRRT frame, add request-send timestamp(4 bytes), request-receive timestamp(4 bytes) and response-send timestamp(4 bytes) in oam echo request and response frame. When receive the response, mark the current time. So the delay time of oam is current-time - request-send - (response-send - request-receive). | 1. get the ClassA/ClassB/ClassC service delay time on RPR ring. 2. remove the host latency. 3. increase the precision of delay time. | 1. revise the oam echo request/reponse frame playload. 2. give the correct timestamp when send or receive oam echo frame. 3. using the timestamp to caculate the delay time. | - | - | J | ||||||
| 0083 Closed | J | Problems of cross-ring RPR reliability and rapid switchover. | 29-Sep-05 | 802.17-2004 | 624 | F | Technical | li | jian | The problems of cross RPR bridge ring reliability and rapid switchover. When two RPR bridge rings intersect, usually two or more stations are deployed for exchanging packets between the rings to ensure the reliability.Since they are in the same broadcast domain, a broadcast storm will be generated if no restriction is made on the intersecting stations. In such a case, we can resort to the Layer 2 Spanning Tree Protocols, such as STP and RSTP for solution. Since the protocols are limited by the algorithm, the convergence speed is slow. | To solve this problem, we can use a mechanism where one from the intersecting stations is selected as the main node to exchange traffic between two rings while the other stations are backup and do not exchange traffic. If a fault comes out at the main station, the function of traffic exchange will soon be switched to the backup stations within 50ms through the new protocol and RPR topology monitoring, ensuring the reliability and rapid switchover between rings.The detail is just as following: 1. Group the intersecting stations, and set the respective station ID, group ID and station priority. 2. Add a kind of control packet on the RPR. Advertise the information on each station in the group through the two RPRs in a multicast or broadcast manner. The station with highest priority acts as the main station, responsible for forwarding packets that cross rings, while others are backup stations. 3. backup stations need to store the MAC address of the current main station in the two rings. If the RPR topology changes, the backup station needs to check for its interconnection with the main station in both rings. If yes, no processing will be done. If not, a control packet will be sent out for selecting a station with the highest priority as the main station from the backup stations that are interconnected with the two rings. 4. Add a new control packet and send it out periodically. The main station sends out a control packet whenever the topology changes. It should quit from the main station mode when one main station receives control packets from the station with higher priority in the two RPRs. 5. Through the packet exchange and the application of topology, the rapid switchover between the main station and the backup station can be implemented. | 1. Solve the problems of cross RPR bridge ring reliability and rapid switchover. 2. Mitigate slow convergence of STP and RSTP. | Add a new protocol on RPR to complete the information advertising as well as negotiation on the switchover between the main and backup stations. | - | - | J | |||||||
| 0084 | B | frame.ri of an FDD frame is wrongly assigned the value of receivedRi. | 30-Sep-05 | 802.17-2004 | 272 | 10.4.9.4 | 10.14 | Technical | Sood | Mohit | Table 10.14, lines 1 and 3: 'frame.ri' of an FDD frame is wrongly assigned the value of 'receivedRi', which is the received ringlet ID of a FAIR frame. A FDD frame, in this case would take the (feedback) path traced by FAIR frame and not the actual data path. So, instead the FDD frames would be received by fairness instance related to the opposite ringlet instead of being received by the head (fairness instance) of congestion domain. As a result, the FRTT value would not be calculated at the head and shall remain 'zero'. This would drastically affect the working of Conservative method of rate adjustment. | Change "frame.ri = receivedRi;" in lines 1 and 3 to "frame.ri = myRi;" | The path of a FDD frame is same as the path taken by a data frame. Remember the purpose of sending FDD frames is to find the differential delay between Class A and Class C data frames. | The effect is relevant if the head of congestion is using Conservative Method of Rate adjustment. In such a case, the head of congestion domain would be able to receive FDD frames and calculate FRTT values. This would enable the head to send FAIR frames with desired fair-rate values. | - | - | B | ||||||
| 0085 | B | The attributes of RprSpanErrorCountersCurrentEntry do not state where they get their values. | 03-Oct-05 | 802.17-2004 | 562 | D.6 | Technical | Lemon | John | The attributes of RprSpanErrorCountersCurrentEntry do not state where they get their values. | Change the descriptions of the attributes of RprSpanErrorCountersCurrentEntry to state which variables of the standard provide the values used for the MIB attribute values. | Specifying the origin of the values disambiguates the assumed values of these MIB attributes. | None. | - | - | T | B | ||||||
| 0086 | B | scffErrors is insufficiently defined. | 03-Oct-05 | 802.17-2004 | 395 | 12.6.1.2 | Technical | Lemon | John | scffErrors is insufficiently defined, yielding posisbly different results in different implementations. | Formally define scffErrors in Clause 7 by adding the variable declaration to 7.2.2 and then to 7.6.3.6.2 and then by adding the incrementing of the variable to Table 7.20 in each of the following rows: 12, 13, 20, 21, and 23. | Specifying the precise cases in which the variable is incremented disambiguates the assumed conditions that lead to the final value of this variable. | None. | - | - | T | B | ||||||
| 0087 Closed | J | Line 9 condition "myWrappingMethod ==CENTER_WRAP" is not relevant when "myEdgeState==FROM_EDGE". | 18-Oct-05 | 802.17-2004 | 270 | 10.4.8.4 | 10.13 | Technical | Sood | Mohit | Line 9 condition "myWrappingMethod ==CENTER_WRAP" is not relevant when "myEdgeState==FROM_EDGE". We are basically trying to check for a source address match for a fairness frame which is never received ! A ringlet's datapath in a 'center-wrapped' station can receive data/control frames only from the ringlet to which it belongs. (Refer Fig. 10.4). E.g. datapath D0 can receive frames from RI = 0 only. Since, FROM EDGE means that the span on the Rx side of the relevant datapath is broken, it is not possible for this datapath to receive any frames. If there are no frames received by this datapath then this condition becomes irrelevant. | Change "myWrappingMethod ==CENTER_WRAP" to "myWrappingMethod ==EDGE_WRAP". | First, the condition "myWrappingMethod ==EDGE_WRAP" is more relevant when "myEdgeState == FROM_EDGE" than the condition "myWrappingMethod ==CENTER_WRAP". Second, although the first one of the two fairness instances may take care of it (by executing action for line 7's condition), this condition can be kept in the state machine to be sure that receivedRate is not propagated unnecessarily in case of EDGE_WRAP. | May save the ring from having a station's fair-rate getting circulated around forever, when the 'edge' station are using EDGE_WRAP. | - | - | T | J | |||||
| 0088 | B | Wrong wrapPoint values in FrttComputation. | 18-Oct-05 | 802.17-2004 | 278 | 10.4.10.6 | 10.15 | Technical | Sood | Mohit | Line 13 : dsWrapPoint = totalHopsTx[otherRi], Line 15 and 16 : wrapPoint = totalHopsRx[otherRi] do not give the desired wrap points in the respective scenarios. | Line 13 : dsWrapPoint = totalHopsTx[myRi], Line 15 and 16 : wrapPoint = totalHopsRx[myRi] | Line 13 : totalHopsTx[otherRi] gives hops to upstream wrap point instead of hops to downstream wrap point. Line 15 & 16 : totalHopsRx[otherRi] gives hops to downstream wrap point instead of hops to upstream wrap point. | The Head station would be able to calculate correct values of lrttToTail and FRTT. | - | - | R | T | B | ||||
| 0089 | B | The function AgeFdd (fdd, newFdd) does not declare 'lastReceivedFdd' as a variable or as a function parameter. | 18-Oct-05 | 802.17-2004 | 276 | 10.4.10.5 | Technical | Sood | Mohit | The function AgeFdd (fdd, newFdd) does not declare 'lastReceivedFdd' as a variable or as a function parameter. | Change 'lastReceivedFdd' to 'newFdd' | newFdd' is declared as a function parameter. | None | - | - | R | B | ||||||
| 0090 | B | Wrong value used for hop count to tailIndex. | 24-Oct-05 | 802.17-2004 | 278 | 10.4.10.6 | 10.15 | Technical | Sood | Mohit | Line 15 condition: The comparison (totalHopsTx[myRi] < tailIndex), is wrong. Refering to Fig. 10.19, totalHopsTx[myRi] gives hops to downstream wrap point. However, we are interested in comparing hops to upstream wrap point with 'tailIndex'. | Line 15 : Change the comparison (totalHopsTx[myRi] < tailIndex) to (totalHopsRx[myRi] < tailIndex) | Line 15 : Data (in Figure 10.19) wraps around the upstream wrap point. Therefore, 'tailIndex' would be hops from 'tailSa' station to upstream wrap point on 'tailRi' ringlet. To find out, which station ('head' or 'tail') is closer to the upstream wrap point, we should compare 'totalHopsRx[myRi]' (which gives hops from 'head' to upstream wrap point) with 'tailIndex' instead of comparing totalHopsTx[myRi] (which gives hops from 'head' to downstream wrap point) with 'tailIndex' | The Head station would be able to calculate correct values of lrttToTail and FRTT. | - | - | R | T | B | ||||
| 0091 | B | If a Multichoke fairness frame (MCFF) is caught on the wrong ringlet, it will stay forever. | 07-Nov-05 | 802.17-2004 | 132 | 7.6.3.6.4 | 7.20 | Technical | Bruckman | Leon | According to Table 7.20 row 27 Fairness frames are not checked for wrong ringlet, since they skip row 38. If a Multichoke fairness frame (MCFF) is caugth in the wrong ringlet it will stay forever. Note that the source of the MCFF removes it only if it is in the right ringlet, as defined in Table 7.22 row 7 | Remove row 27 from Table 7.20 | Minimum change | No impact, since the change only fixes a potential problem, and is fully inteoperable with standard compliant equipment. | - | - | R | B | |||||
| 0092 | B | The description of Row 7.23-4 is not consistent with the action in the table, and it is wrong. | 08-Nov-05 | 802.17-2004 | 142 | 7.6.3.9.4 | 7.23 | Technical | Bruckman | Leon | The description of Row 7.23-4 is not consistent with the action in the table, and it is wrong (the action in the table is right) since Fairness frames do not have a "ps" bit | Replace the description of Row 7.23-4 with: Wrapped fairness frames don't have a ps bit, so no need to adjust it | Make text consistent with table | No impact since the table is right | - | - | R | B | |||||
| 0093 | B | The figure seems to imply that there is a failure in the ring, but it describes the normal operating case. | 12-Feb-06 | 802.17-2004 | 167 | 7.7.2 | 7.11 | Technical | Bruckman | Leon | The figure seems to imply that there is a failure in the ring (a "X"), but it describes the normal operating case | Replace the "X" in the figure with a dotted line, or another sign that does not imply a failure | Easier to understand | None | - | - | R | B | |||||
| 0094 | B | Table row 7.22-7 has the wrong parameter name in the condition column. | 12-Feb-06 | 802.17-2004 | 139 | 7.6.3.8.4 | 7.22 | Technical | Bruckman | Leon | In row 7.22-7 in the condition column wrong parameter name: "frame.sacompact" | Replace "frame.sacompact" with: "frame.saCompact" | Consistency | No effect | - | - | R | B | |||||
| 0095 | B | Table row 7.23-4 has the wrong parameter name in the condition column. | 12-Feb-06 | 802.17-2004 | 142 | 7.6.3.9.4 | 7.23 | Technical | Bruckman | Leon | In row 7.23-4 in the condition column wrong parameter name: "frame.sa", since the frame.ft is Firness, then the sa is saCompact | Replace "frame.sa" with: "frame.saCompact" | Consistency | No effect | - | - | R | B | |||||
| 0096 | B | Table row 7.19-6 has the wrong function name in the condition column. | 13-Feb-06 | 802.17-2004 | 127 | 7.6.3.5.4 | 7.19 | Technical | Bruckman | Leon | In row 7.19-6 in the condition column wrong function name: "CrcCompact" | Replace "CrcCompact" with: "Crc32Compact" | Consistency | No effect | - | - | R | B | |||||
| 0097 | B | stqSize is not a defined variable. | 20-Feb-06 | 802.17-2004 | 254 | 10.4.2.3 | Technical | Bruckman | Leon | stqSize is not a defined variable, in other places of the standard stqDepth is used | Replace "stqSize" with: "stqDepth" | Consistency | No effect | - | - | R | B | ||||||
| 0098 | B | myWrappingMethod is not a defined variable. | 21-Feb-06 | 802.17-2004 | 245 | 10.2.4 | Technical | Bruckman | Leon | myWrappingMethod is not a defined variable (see Clause 7), in other places of the standard myProtectMethod is used | Replace all occurences of: "myWrappingMethod" (Pages 245, 269, 270 3 times in table 10.13) with: "myProtectMethod" | Consistency | No effect | - | - | R | B | ||||||
| 0099 | B | Wrong description for table row 10.10-4. | 22-Feb-06 | 802.17-2004 | 264 | 10.4.5.4 | 10.10 | Technical | Bruckman | Leon | Wrong description od row 10.10-4. The station becomes a "head" not a tail. | In the decription of Row 10.10-4 replace :"..and it is the tail of the.." with: "..and it is the head of the…" | Consistency | No effect | - | - | R | B | |||||
| 0100 | B | In the ringlet_id definition, the reference table is wrong. | 02-Mar-06 | 802.17-2004 | 387 | 12.4.1 | Technical | Bruckman | Leon | In ringlet_id definition the refernce table is wrong | Replace "Table 6.3" with "Table 6.2" | Consistency | No effect | - | - | R | B | ||||||
| 0101 | B | The definition of rprIfWrapConfig incorrectly uses "Wrap preferred". | 02-Mar-06 | 802.17-2004 | 478 | D.6 | Technical | Bruckman | Leon | The definition of rprIfWrapConfig mentions "Wrap preferred" but it should use the term: "wrap configured" | Replace : "wrap preferred" with: "wrap configured" | Consistency | No effect | - | - | R | B | ||||||
| 0102 | B | In the definition of rprIfJumboFramePreferred, rprIfMacCapability should be replaced with rprIfRingOperModes. | 02-Mar-06 | 802.17-2004 | 479 | D.6 | Technical | Bruckman | Leon | In the definition of rprIfJumboFramePreferred: rprIfMacCapability should be replaced with: rprIfRingOperModes | Replace "rprIfMacCapability" with: "rprIfRingOperModes" | Consistency | No effect | - | - | R | B | ||||||
| 0103 | B | Table-Row 11.14-17 does not save the checksum value. | 19-Jun-06 | 802.17-2004 | 334 | 11.6.4.4 | 11.14 | Technical | Lemon | John | The action of Row 17 does not result in the checksum value being stored for later use. | Change the action of Row 17 to: myTopoInfo.myChecksum.value = ComputeTc() | ComputeTc() returns the checksum value, so the returned value needs to be obtained from the function result, and it needs to be stored in the standard location used elsewhere. | None. | - | - | - | R | B | ||||
| 0104 | B | There is no such literal: "AGECOEF". | 19-Jun-06 | 802.17-2004 | 11 | 3.2.78 | Technical | Lemon | John | There is no such literal: "AGECOEF". | Change the referenced item from "AGECOEF" to "ageCoef". | Even if someone makes the connection between the apparent literal and the variable, this could still cause them to believe that it holds a fixed value. | None. | - | - | - | R | B | |||||
| 0105 | B | ttlExpiredFrames is not defined in 7.2.2. | 19-Jun-06 | 802.17-2004 | 138 | 7.6.3.8.2 | Technical | Lemon | John | ttlExpiredFrames is not defined in 7.2.2. | Move the definition of ttlExpiredFrames from 7.6.3.6.2 to 7.2.2, and instead reference the definition in 7.2.2. | The reference to 7.2.2 in 7.6.3.8.2 works once the definition is placed in 7.2.2, which is where it belongs. | None. | - | - | - | R | B | |||||
| 0106 | B | There is no such routine: "PHY_READY.inidication()". | 19-Jun-06 | 802.17-2004 | 181 | 7.7.7.2.4 | 7.34 | Technical | Lemon | John | There is no such routine: "PHY_READY.inidication()". | Change the routine name to "PHY_READY.indication()". | This was the intended routine. | None. | - | - | - | R | B | ||||
| 0107 | B | Table-Row 10.9 condition uses an undefined routine: "IsCongested()". | 19-Jun-06 | 802.17-2004 | 258 | 10.4.4.4 | 10.9 | Technical | Lemon | John | The Row 3 condition uses an undefined routine: "IsCongested()". | Add the following to 10.4.4.3: IsCongested( ) See 10.2.3. | This was the intended routine. | None. | - | - | - | R | B | ||||
| 0108 | B | Reference is given to the wrong subclause, and no reference is given to myTopoInfo.conservativeMode. | 19-Jun-06 | 802.17-2004 | 311 | 11.4.3.3 | Technical | Lemon | John | Reference is given to the wrong subclause, and no reference is given to the variable from which this obtains its value. | Change "conservative mode fairness (see 10.2.2)." to "conservative mode fairness, based on the value of myTopoInfo.conservativeMode defined in 11.2.5." | This corrects the reference, specifies the correct variable, and makes this subclause consistent with its neighboring subclauses. | None. | - | - | - | R | B | |||||
| 0109 | B | Reference is given to the wrong subclause, and no reference is given to myTopoInfo.multichokeUser. | 19-Jun-06 | 802.17-2004 | 311 | 11.4.3.4 | Technical | Lemon | John | Reference is given to the wrong subclause, and no reference is given to the variable from which this obtains its value. | Change "multiChokeIndOption defined in 10.2.2." to "myTopoInfo.multichokeUser defined in 11.2.5." | This corrects the reference, specifies the correct variable, and makes this subclause consistent with its neighboring subclauses. | None. | - | - | - | R | B | |||||
| 0110 | B | The text wrongly implies separate actions for multichoke behavior for each ringlet. | 19-Jun-06 | 802.17-2004 | 311 | 11.4.3.4 | Technical | Lemon | John | The text wrongly implies separate actions for multichoke behavior for each ringlet. | Delete: "(If any station on ringlet rid advertises a nonzero mu value, every station is required to send multi-choke fairness frames onto ringlet rid.)" Add the following as a separate paragraph, following the existing paragraph: "The ringInfo.multichokeUser bit indicates if any station on the ring uses multi-choke fairness frames and, therefore, that every station transmits multi-choke fairness frames." | This corrects the text to reflect actual behavior specified elsewhere throughout the standard. | None. | - | - | - | R | B | |||||
| 0111 | B | The last paragraph on page 311 appears to belong to 11.4.3.4. | 19-Jun-06 | 802.17-2004 | 311 | 11.4.3.4 | Technical | Lemon | John | The last paragraph on page 311 appears to belong to 11.4.3.4, which would limit its scope to only the mu bit. | Move the last paragraph on page 311 to be the last sentence of the sole paragraph of 11.4.3. | This corrects the text to reflect actual behavior. | None. | - | - | - | R | B | |||||
| 0112 | B | Checking the Yes box of PP6 does not indicate that nonrevertive operation "may be" supported. | 19-Jun-06 | 802.17-2004 | 377 | 11.7.3.4 | Technical | Lemon | John | Checking the Yes box of PP6 does not indicate that nonrevertive operation "may be" supported. | Change "may be" to "is" in the comment field of PP6. | This corrects the text to reflect actual behavior. | None. | - | - | - | R | B | |||||
| 0113 | B | The reference for rprFairnessReservedRate refers to 11.2.4. | 19-Jun-06 | 802.17-2004 | 495 | D.6 | Technical | Lemon | John | The reference for rprFairnessReservedRate refers to 11.2.4, wrongly implying that it refers to a ring-wide value when it actually refers to the local station's value. | Change "11.2.4" to "11.2.5" in the reference for rprFairnessReservedRate. | This corrects the text to reflect actual behavior. | None. | - | - | - | R | B | |||||
| 0114 | B | tailSa, tailRi, and tailIndex are not defined. | 21-Jun-06 | 802.17-2004 | 277 | 10.4.10.6 | 10.15 | Technical | Lemon | John | tailSa, tailRi, and tailIndex are not defined. | Add the following to 10.4.10.4: tailIndex Index into topoEntry for the current tail station. tailRi Ringlet on which the tail station sent the FDD. tailSa The MAC address of the tail station. | This declares these variables and defines their usage. | None. | - | - | - | R | B | ||||
| 0115 | B | The badRxFcsFrames statistics counter is not reflected in any MIB item. | 03-Jul-06 | 802.17-2004 | 143 | 7.6.3.10.2 | Technical | Ram | Rafi | The badRxFcsFrames statistics counter is not reflected in any MIB item. | Add the following MIB items : rprSpanErrorCurrentBadRxFcsFrames rprSpanErrorIntervalBadRxFcsFrames rprSpanErrorDayBadRxFcsFrames rprSpanErrorStatsBadRxFcsFrames | Minimal change, consistent with the way the badFcsFrames counter is reflected in the MIB. | No effect. | - | - | - | R | T | B | ||||
| 0116 | B | There is no definition of variable advertisementInterval used in context of function LrttResponseHandle(). | 15-Sep-06 | 802.17-2004 | 370 | 11.6.14.3 | 11.20 | Technical | Juzwiak | Piotr | There is no definition of variable advertisementInterval used in context of function LrttResponseHandle(). | Change advertisementInterval to advertisingInterval or add some definition. | 0 | No impact. | - | - | - | R | B | ||||
| 0117 | B | TP frames should be broadcasted in both ringlets. | 15-Sep-06 | 802.17-2004 | 353 | 11.6.7.4 | 11.17 | Technical | Juzwiak | Piotr | TP frames should be broadcasted in both ringlets, but EnqueueRi(0,Q_TX_RS,frame) and EnqueueRi(1,Q_TX_RS,frame) (Table 11.17, row 11) are actions with the same effect. Both copies of frame will be send in one ringlet by the RingletSelection state machine when EnqueueRi() works according to definition (7.2.3). Identical problem appears during TC frame transmission (table 11.19 row 6). Probably there are similar ones in the definition of routine LrttRequestTransmit( ) (11.6.14.3 - Equation 11.19 ) and in TimingLrttFrame state machine (table 11.22 row 10). | There are many ways to fix this problem. The one is to change a definition of routine EnqueueRi() from: "If the requested queue is Q_TX_RS, ringlet is ignored, and the only instance of Q_TX_RS is used." to e.g.: "If the requested queue is Q_TX_RS, ringlet should be set as value of ringlet_id indication for RingletSelection state machine, and the only instance of Q_TX_RS is used." The other way is to add some new row with special rules for setting ringlet_id value to control frames in the state START of RingletSelection state machine table or maybe to change a definition of DefaultRinglet routine. | The frames will be transmitted in both ringlets according to specification. | No effect except fixing a problem. | - | - | - | R | T | B | |||
| 0118 | B | Inconsistent notation "frame.checksumValid" in Table 11.20 rows 6 and 9. | 15-Sep-06 | 802.17-2004 | 357 | 0 | 11.20 | Technical | Juzwiak | Piotr | Inconsistent notation "frame.checksumValid" in Table 11.20 rows 6 and 9 although subclause 11.3.2.5 calls this field of TC frame "cv" and Table 11.19 contains notation frame.cv (row 6). | Change all occurrence of "frame.checksumValid" to "frame.cv". | Notation will be more clear. | No impact. | - | - | - | R | B | ||||
| 0119 | B | Final hec field value may be incorrect for frame header. | 15-Sep-06 | 802.17-2004 | 172 | 7.7.4 | Technical | Juzwiak | Piotr | Frame.hec field is set in RingletSelection state machine (i.e. rows 34, 37) and next in StageQueueSelection the frame content is changed (fields frame.fe and frame.sc) so finally hec field value may be incorrect for frame header. | Move frame.hec setting from RingletSelection state machine to e.g. StageQueueSelection state machine to point after setting frame.sc and frame.fe values. | Frame.hec value of frame will get a proper value during transmit operations. | Fix the problem only. | - | - | - | R | B | |||||
| 0120 | B | "EntryInQueue(Q_RX_TP_PARSE) != NULL" (Table 11.13, Row 3) is a tautology. | 15-Sep-06 | 802.17-2004 | 329 | 11.6.3.4 | 11.13 | Technical | Juzwiak | Piotr | EntryInQueue(queue) can return values TRUE or FALSE (definition in 7.2.3). Definition of NULL constant excludes "confused with a valid value" (7.2.1), so condition "EntryInQueue(Q_RX_TP_PARSE) != NULL" (Table 11.13, Row 3) is a tautology. | Change wrong notation: "EntryInQueue(Q_RX_TP_PARSE) != NULL" to: "EntryInQueue(Q_RX_TP_PARSE) != FALSE" | Now it's a real condition, not a tautology in the meaning of standards definitions. | None. | - | - | - | R | B | ||||
| 0121 | B | There is no holdoffStartTime[ri] variable definition. | 15-Sep-06 | 802.17-2004 | 326 | 11.6.2 | Technical | Juzwiak | Piotr | There is no "holdoffStartTime[ri]" variable definition. | Add some definition to subclause 11.6.2.2. | 0 | None. | - | - | - | R | B | |||||
| 0122 | B | keepaliveTime is an integer variable in some places, but it is defined as an array. | 15-Sep-06 | 802.17-2004 | 127 | 7.6.3.5.4 | 7.19 | Technical | Juzwiak | Piotr | The keepaliveTime is an integer variable in some places (Table 7.19—ReceiveFromEdge state table & Table 7.22-ReceiveStrip state table) but it is defined as an array in 11.2.3 Common state machine variables. | I suggest changing notation in tables 7.19 & 7.22 from: keepaliveTime = currentTime; to (for example): keepaliveTime[myRi] = currentTime; where myRi is a ringlet number. | It's a small change but it makes the code of state machines more clear. | I don't expect any. | - | - | - | R | B | ||||
| 0123 | B | There is no definition of queue Q_TX_ROUTE. | 15-Sep-06 | 802.17-2004 | 78 | 7.2.1 | Technical | Juzwiak | Piotr | There is no definition of queue Q_TX_ROUTE in 7.2.1. Queue is used in TransmitCount and TransmitRoute state machines. | Add some definition of Q_TX_ROUTE. | 0 | No impact. | - | - | - | R | R | B | ||||
| 0124 | B | There are missing exclamation marks in Table J.1. | 15-Sep-06 | 802.17-2004 | 651 | J.3 | J.1 | Technical | Juzwiak | Piotr | There are missing exclamation marks ("!") in the J.1 Table. | Should be change from "SEND" to "!SEND" in cells: Col: SendA Row: 2 Col: SendB Row: 2 Col: SendC Row: 4 | 0 | No impact, its only editorial mistake. | - | - | - | R | R | B | |||
| 0125 | B | ReceiveStrip state machine is allowed to update keepalive variable when station has span failure. | 15-Sep-06 | 802.17-2004 | 139 | 7.6.3.8.4 | 7.22 | Technical | Juzwiak | Piotr | ReceiveStrip state machine is allowed to update keepalive variable when station has span failure. Problem appears when station uses a WRAPPING protection method with EDGE_WRAPPING variant. In efect of updating keepalive variable, spanOperState variable can be set on wrong value (ReceiveMonitor state machine can set spanOperStatus on IDLE when real state of span is SF because station hasn't got any neighbour's SCFF frames). | Add a row to the ReceiveStrip state machine between rows 7 and 8, that contains i.e.: Conditions: frame.ft == RPR_FT_FAIRNESS && frame.ffType == RPR_SINGLE_CHOKE && frame.saCompact == myMacAddress && frame.ri == myRi Actions: - Next state: START | Keepalive variable will not update, so state of spanOperStatus will not change without actual change of span state. | Only fix the problem. | - | - | - | R | R | T | B | ||
| 0126 | B | If topoEntryInvalidDefect is set in TopologyValidation state machine, it isn`t cleared when topology is valid. | 15-Sep-06 | 802.17-2004 | 351 | 1.6.6.5 | 11.16 | Technical | Juzwiak | Piotr | If topoEntryInvalidDefect is set in TopologyValidation state machine It isn`t cleared when topology is valid. | Add line: topoEntryInvalidDefect = FALSE; to actions of row 9 in table 11.16. | If there is no defect and topology is valid, topology defect shouldn`t be announced. | None. | - | - | - | R | R | B | |||
| 0127 | B | Inconsistent notation "frame.seq" in ReceiveTpFrame state machine specification. | 15-Sep-06 | 802.17-2004 | 355 | 11.6.8.4 | 11.18 | Technical | Juzwiak | Piotr | Inconsistent notation "frame.seq" in ReceiveTpFrame machine specification. | Condition in row 8 of table 11.18 should be changed from: "topoEntry[ri][hops].sequenceNumber == frame.seq" to: "topoEntry[ri][hops].sequenceNumber == frame.seqnum" | Definition of TP frame field prefs (11.3.1.4) calls these bits "seqnum" not a "seq". | Rather no impact – error must have been found during implementation process. | - | - | - | R | R | B | |||
| 0128 | B | Wrong notation of condition currentTime-wtr[ri].time >= wtr.timeout[ri]. | 15-Sep-06 | 802.17-2004 | 330 | 0 | 11.13 | Technical | Juzwiak | Piotr | There is a wrong notation of condition "currentTime-wtr[ri].time >= wtr.timeout[ri]" in Row 11 Table 11.13. | Change "wtr.timeout[ri]" to "wtr[ri].timeout". | Timeout variable in wtr struct defined in 11.2.3 is not an array. | None. | - | - | - | R | R | B | |||
| 0129 | B | Definition of routine SetSourceCheck() contains wrong condition. | 15-Sep-06 | 802.17-2004 | 349 | 11.6.6.4 | Technical | Juzwiak | Piotr | Definition of routine SetSourceCheck() (Equation 11.13) contains wrong condition in line: "if (myTopoInfo.protConfig == WRAPPING && myTopoInfo.topoType == OPEN_RING)". There isn't any topoType variable in the myTopoInfo part of topology database. | TopoType is a variable from ringInfo. Change line: "if (myTopoInfo.protConfig == WRAPPING && myTopoInfo.topoType == OPEN_RING)" to: "if (myTopoInfo.protConfig == WRAPPING && ringInfo.topoType == OPEN_RING)". | 0 | None. | - | - | - | R | R | B | ||||
| 0130 | B | Incorrect description in the rprIfIdleThreshold MIB item. | 04-Oct-06 | 802.17-2004 | 478 | D.6 | Technical | Ram | Rafi | The following description in the rprIfIdleThreshold MIB item is incorrect - "When the PTQ depth exceeds this value, the incoming link is considered adversely rate mismatched". | The sentence should be corrected to "When the free space in the PTQ becomes less than or equal to this value, the incoming link is considered adversely rate mismatched" | The original description contradicts the example in the MIB description and the text in subclauses 7.5.3 and 7.5.3.2, and the implementation described in table 7.7. | None. | - | - | - | R | R | B | ||||
| 0131 | B | txSlowTimeout variable specified a default of 100msec | 25-Apr-07 | 802.17-2004 | 295 | 11.2.3 | Technical | Holness | Marc | txSlowTimeout variable specified a default of 100msec. However, in clause D.6, the rprIfProtectionSlowTimer MIB specifies a default of 1 sec. The value conflict each other. | Change the txSlowTimeout variable default (defined in 11.2.3) to 1 second. | There is no need to run at 100msec when there is no fault on the system. | 0 | - | - | - | R | R | T | B | |||
| 0132 | B | Figure 11.27f lists the wrong topoType. | 10-Jul-08 | 802.17-2004 | 322 | 11.5.4 | 11.27 | Technical | Lemon | John | Figure 11.27f lists the wrong topoType. | Change "topoType = CLOSED_RING" to "topoType = OPEN_RING". | The ring shown in Figure 11.27f is still broken between S8 and S9. | None. | - | - | - | - | - | - | - | B | |
| 0133 | B | Control frame fields are being treated as data frames. | 10-Jul-08 | 802.17-2004 | 162 | 7.7.1.6.4 | 7.29 | Technical | Lemon | John | Control frame fields are being treated as data frames. | From Row 5, delete the following assignments from the action column: frame.ef = 0; frame.fi = FI_NONE; frame.so = 0; | Control frames do not have an extendedControl field, and therefore do not have these subfields. | None, because no one could have created equipment that filled in fields that don't exist. | - | - | - | - | - | - | - | B | |
| 0134 | B | FDD frames are not being allowed to wrap. | 10-Jul-08 | 802.17-2004 | 162 | 7.7.1.6.4 | 7.29 | Technical | Lemon | John | FDD frames are not being allowed to wrap. | Add a row immediately preceding Row 5, with the following characteristics: state: "STRICT" condition: "frame.ft == FT_CONTROL && frame.controlType == CT_FDD" action: same as for Row 5, except with "frame.we = 0;" removed next state: "TRANSMIT" row comment: "FDD control frames have their frame.we value set by Table 10.14, and they pass the remaining checks." (Also remove extra period at end of second paragraph of 10.3.2.) | FDD frames are supposed to be allowed to wrap in wrapping systems. | Equipment that both wraps and uses conservative mode fairness would need to be modified if the implementation followed the dictates of Table 7.29 rather than the dictates of Table 10.4 and Table 10.14. But the correction would provide more accurate results. And if not corrected, the implementation would continue to operate as well as it currently does. | - | - | - | - | - | - | - | B |