IEEE P802.3 July 2002 Maintenance Meeting
Unconfirmed Minutes

Pat Thaler convened the meeting. Meeting attendance was, Pat Thaler, Geoff Thompson, Tom Mathey, Bob Grow, Ed Turner

Maintenance request 1001 Still awaiting further input from the submitter.

Maintenance request 1004 Awaiting ballot. To be included in IEEE P802.3aj ballot.

Maintenance request 1023 No update.

Maintenance request 1035 No update.

Maintenance request 1037 Awaiting ballot. To be included in IEEE P802.3aj ballot.

Maintenance request 1051 Pat asked for a volunteer to submit a new change request. Geoff has withdrawn his informal request to change this. While best practice would have been to deprecate the objects and add new correct items, at this point further change would be as likely to produce interoperability problems as to resolve them. Pat covered this error in the maintenance report at the Thursday Closing Plenary where there was nobody concerned enough to submit a change request. No change in status - this Change Request is Published.

Maintenance request 1052 New request #1096 raised to cover this. No change in status - this Change Request is Published.

Maintenance request 1057 Email recived 06/06/2002 from Vivek withdrawing this request. New status Withdrawn - (W)

Maintenance request 1064 Action - Check text in the IEEE P802.3ab drafts. D4.0 - Itemized list does not exist. D4.1 - To ensure robust operation the alien NEXT noise must meet the specification of 40.7.5.1. 40.7.5.1 External Coupled Noise D5.0 - To ensure robust operation the alien NEXT noise must meet the specification of 40.7.5.1. 40.7.5.1 External Coupled Noise D5.1 - To ensure robust operation the alien NEXT noise must meet the specification of 40.7.5.1. 40.7.5.1 External Coupled Noise D6.0 - To ensure robust operation the alien NEXT noise must meet the specification of 40.7.5.1. 40.7.5.1 External Coupled Noise RESULT: 40.7.6 used to be numbered 40.7.5.1. Change change request to correct reference to 40.7.6. Editorial change. Affirmed as Errata by motion at closing 802.3 Plenary meeting. New status: Errata - (E)

Maintenance request 1068 Awaiting ballot. To be included in IEEE P802.3aj ballot.

Maintenance request 1072 Return to submitter - no action taken. (We know it will bounce, but it isn't 802.3's responsiblity to track down submitters who don't update contact info. - put the reject on the web site.) Rationale: The available code space is too small to allow assignment to vendors for proprietary use. Any change to reserve a portion of the code space for vendor use would require a new project to amend the standard. New status - Reject - (J)

Maintenance request 1078 Action: David Law Edit in text received from Bob Noseworthy. New status - Change Text then Ballot - (CB)

Maintenance request 1079 Awaiting ballot. To be included in IEEE P802.3aj ballot.

Maintenance request 1080 Action: David Law Edit in text received from Alan Flatman. New status - Change Text then Ballot - (CB)

Maintenance request 1083 Awaiting ballot. To be included in IEEE P802.3aj ballot.

Maintenance request 1085 Awaiting ballot. To be included in IEEE P802.3aj ballot.

Maintenance request 1086 Awaiting ballot. To be included in IEEE P802.3aj ballot.

Maintenance request 1087 Awaiting ballot. To be included in IEEE P802.3aj ballot.

Maintenance request 1088 In response to the action item the following question was e-mailed to Shimon: Q: The rational for revision includes the text 'The definition of ReceiveFrame function is flawed.' without further explanation. To allow us to progress this request further please could provide an explanation of this statement. A: This is a minor point, and by itself I would not have bothered with it. My objection was to the use of the term "primitive" for a function in Pascal. In the context of 802.3, we typically use this term for service interfaces between sublayers only. Which reminds me that there is one more revision request that I need to submit for the definition of "primitive in clause 1. This came up during the recirculation of 802.3ae/D4.2. The rational for the change to the ReceiveFrame function will be changed to read 'ReceiveFrame is a Pascal function, not a primitive.' New status - Change Text then Ballot - (CB)

Maintenance request 1089 In response to the action item the following question was e-mailed to Shimon: Q: The rational for revision includes the text 'The exit conditions from state WAIT FOR TRANSMISSION COMPLETION in Figure 31B-2 are incorrect.' without further explanation. To allow us to progress this request further please could provide an explanation of this statement. al thea logic equations for the exit conditions from the above state are missing parentheses and can therefore be interpreted incorrectly by implementors. If you just follow the binary logic arithmetic rules for these equations, the result will clearly not be the one that was intended by this standard. The rational for the change to the ReceiveFrame function will be changed to read 'The exit conditions from state WAIT FOR TRANSMISSION COMPLETION in Figure 31B-2 is missing parentheses so can be interpreted incorrectly.'. Affirmed as Errata by motion at closing 802.3 Plenary meeting. New status - Errata - (E)

Maintenance request 1090 In response to the action item the following question was e-mailed to Shimon: Q - There was a concern that a PONs OLT (Head End PHY) will not receive a continuously signal and therefore require the ability to utilize a local clock when an incoming signal is not present. Based on this do you still wish to proceed with this request ? A - Yes, I do. The issue is not whether a local clock reference is used or not, but rather how often the switching between the two clocks is done. The specifications in clauses 22 and 35 allows to do this clock switching on a frame-by-frame basis, and is therefore very tight. This is only necessary for 10BASE-T, where the line will go quiet during the IPG between frames. For EPONs the line will go quiet between slot times when one ONU shuts down its laser and before another one turns it on. This will result in temporary loss of link at the OLT. However, the OLT can easily do the switching between the clock sources well within the guardband that the system will provide. My suggested text will still apply in this case. New status: Editorial/Technical - Tech Ballot Required - Yes Ready for ballot - Yes Ready for Ballot - (B)

Maintenance request 1091 Awaiting ballot. To be included in IEEE P802.3aj ballot.

Maintenance request 1092 No update.

Maintenance request 1093 No Action - It appears that the trademark issue may be resolved this week without the need for this.

Maintenance request 1094 No update.

Maintenance request 1095 No update.

Maintenance request 1096 Editorial/Technical - Tech Ballot Required - Yes Ready for ballot - Yes Ballot - (B)