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)


Return to IEEE 802.3 Maintenance Home Page
Last Update: 07 Jul 03


[Search] [e-mail] [Standards Home Page] [Corporate Home Page]