CommenterName: Dave Carlson CommenterEmail: dcarlson@netlabs.net CommenterPhone: none CommenterFax: none CommenterCo: netlabs Clause: 01 Subclause: none Page: none Line: none CommentType: E Comment: In Figures 1-1, 2-1, 4-1 and 6.1, please insert a line space between "LAN CSMA/CD LAYERS" and "HIGHER LAYERS" so it appears as in Figures 34-1, 35-1, 36-1 and 37-1. This adds clarity and consistency to those Figures. CommentEnd: SuggestedRemedy: none RemedyEnd: Status: Accepted Response: Will be fixed in next draft. ResponseEnd: CommenterName: Steve Dreyer CommenterEmail: sdreyer@seeq.com CommenterPhone: CommenterFax: CommenterCo: Seeq Technology Clause: 01 SubClause: 1.4 Page: 01.3 Line: 9 CommentType: Comment: Missing reference. CommentEnd: SuggestedRemedy: none RemedyEnd: Status: Accepted Response: References will be added in next draft. ResponseEnd: CommenterName: Don Wong CommenterEmail: donw@nad.3Com.com CommenterPhone: +1 408 764 6636 CommenterFax: +1 408 764 8589 CommenterCo: 3Com Corporation Clause: 04 Subclause: 4.2.2.4 Page: Changes to clause 4.8 Line: fig 4-5(a) - Control flow MAC sublayer CommentType: E Comment: reference to "receivedDataValid" should be Carrier Sense, since receivedDataValid is visible at the GMII or MII, and the MAC layer sees the reconcilation sublayer. CommentEnd: SuggestedRemedy: Change "receivedDataValid" to "Carrier Sense" RemedyEnd: Status: Rejected Response: receiveDataValid refers to a variable, not the signal RX_DV. See 4.3.3 page 4.29, line 12 for a description of this variable. Note also that this variable was introduced in 802.3x, and the control flow diagram for the BitReceiver was changed by that standard to use receiveDataValid rather than carrierSense. ResponseEnd: CommenterName: Don Wong CommenterEmail: donw@nad.3Com.com CommenterPhone: +1 408 764 6636 CommenterFax: +1 408 764 8589 CommenterCo: 3Com Corporation Clause: 04 Subclause: 4.2.3.4 Page: Changes to clause 4.10 Line: 43-44 CommentType: T Comment: The sentence "will treat any collision which occurs within the slot time as a normal collion" should read "will treat any collision which occurs within the Duration of Carrier Event" CommentEnd: SuggestedRemedy: Change "slot time" to "Duration of Carrier Event". RemedyEnd: Status: Accepted Response: Accepted in principle. The proposed change would be incorrect, since late collisions could occur within the Duration of Carrier Event, provided they occurred after the slotTime. However, the actual threshold is slotTime-headerSize. The text will be modified in the next draft to state the threshold correctly. The lateCollision threshold will be clearly identified in figure 4-7. ResponseEnd: CommenterName: Don Wong CommenterEmail: donw@nad.3Com.com CommenterPhone: +1 408 764 6636 CommenterFax: +1 408 764 8589 CommenterCo: 3Com Corporation Clause: 04 Subclause: 4.2.2.4 Page: Changes to clause 4.8 & 4.9 Line: fig 4-5(a) & fig 4-5(b) CommentType: T Comment: In fig 4-5(b) indicates that bursting <= off once the burstLimit is reached. However in fig 4-5(a) under BitTransmitter process, burst=off could shut off a transmitting in a middle of a frame. CommentEnd: SuggestedRemedy: In fig 4-5(a) remove "bursting on" jump condition. In fig 4-4(a) change "burst continuation" to "bursting on". RemedyEnd: Status: Rejected Response: The test for "bursting on?" in figure 4-5(a) will not shut off transmitting in the middle of a frame, because the test is performed only after all of the bits of a given frame have been transmitted. The test is performed to check whether the interframe fill pattern should be sent so as to keep carrier on between frames of a burst. As to the second half of the comment, this is an editorial issue, and either "burst continuation" or "bursting on?" is correct. ResponseEnd: CommenterName: Mart Molle CommenterEmail: mart@cs.ucr.edu CommenterPhone: none CommenterFax: none CommenterCo: UC Riverside Clause: 04 Subclause: Figure 4-4a Page: 4.6 Line: 30 CommentType: T Comment: The figure as drawn implies that lateCollisionCount is incremented only for 1000 Mb/s operation. CommentEnd: SuggestedRemedy: Modify transmit frame control flow summary diagram to omit increment of latecollision count, and insert test for late collision and > 100 Mb/s between increment attempts and test of too many attempts. RemedyEnd: Status: Accepted Response: will be incorporated in next draft. ResponseEnd: CommenterName: Mart Molle CommenterEmail: mart@cs.ucr.edu CommenterPhone: none CommenterFax: none CommenterCo: UC Riverside Clause: 04 Subclause: Figure 4-5a Page: 4.8 Line: 1 CommentType: T Comment: Missing arc from transmission done/receiving done back to initial state in BitTransmitter and BitReceiver process control flow diagrams CommentEnd: SuggestedRemedy: Add arc from the final action block back to the initial test condition. RemedyEnd: Status: Accepted Response: will be incorporated in next draft. ResponseEnd: CommenterName: Howard Frazier CommenterEmail: hfrazier@cisco.com CommenterPhone: 408 527 7607 CommenterFax: 408 527 8254 CommenterCo: Cisco Systems Clause: 04 Subclause: 4.4.2.4 Page: 4.33 Line: 37 CommentType: T Comment: The note concerning IPG shrinkage needs to be converted from an editor's note to a real note, and the value for the minimum IPG between noncolliding frames needs to be confirmed. CommentEnd: SuggestedRemedy: Remove "Editor's Note" verbage. Use a minimum value of 64 BT based on the calculation: mimimum IPG = nominal IPG - repeater clock tolerance - preamble growth - guard band = 96 - 16 - 8 - 8 (BT) = 64 BT RemedyEnd: Status: Accepted Response: will be incorporated in next draft. ResponseEnd: CommenterName: Mohan Kalkunte CommenterEmail: mohan@carmel.amd.com CommenterPhone: none CommenterFax: none CommenterCo: AMD Clause: 04 Subclause: 4.4.2.4 Page: 4.33 Line: 21 CommentType: T Comment: Simulation data demonstrates that a burstLimit of 64 kbits improves all measures of performance compared to a burstLimit of 12 kbits. CommentEnd: SuggestedRemedy: Change burstLimit to 65 536 (64 kbits) in the parameter table for 1000 Mb/s operation. This will also require a change to maxDeferTime in 5.2.4.1 for 1000 Mb/s. Set maxDeferTime = {2 x (burstLimit + maxFrameSize x 8 + headerSize) in bits} = 2 x (65 536 + 1518 x 8 + 64) bits = 155488 bits for 1000 Mb/s. This will also require a change to Jabber Timer in 41.3.2.1.4. Set Jabber Timer = 80 000 - 150 000 BT This is a simply doubling of the Jabber Timer value. The maximum valid carrier event with bursting for a burstLimit of 65 536 is 77744 BT RemedyEnd: Status: Accepted Response: will be incorporated in next draft. ResponseEnd: