John S. wants to make sure that we provide what is necessary to support requirements for 1394.

All rights reserved 51 This is an unapproved IEEE Standards Draft, subject to change 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 6.6.2 61883-2 timing and synchronization 61883-2 formatted frames shall follow the same timing and synchronization rules as defined in IEC 61883-2 section 6, but using IEEE 802.1AS time in the avbtp_timestamp frame field instead of IEEE 1394 based cycle time in the SYT field.

. >> > >> >As an MSC representative, I would have provided >> >such a follow-up on the addresses used within >> >MSC sponsored projects (754, 1394, etc.), as >> >a duty to my position. >> > >> >I prefer to see the evidence before jumping into >> >denial or conclusions, since (through out my career) >> >I have seen suboptimal decisions made when this >> >ordering is reversed. >> > >> > >> >If you feel strongly about this, >> >Yes, I feel strongly about conservation of OUI space. >> >I naively thoutht that to be the premise of our charter. >> >Times change, I suppose... >> > >> >Cheers, >> >DVJ >> > >> > >> -----Original Message----- >> > >> From: Geoff Thompson [ mailto:gthompso@nortel.com ] >> > >> Sent: Wednesday, August 08, 2007 3:07 PM >> > >> To: Floyd Backes >> > >> Cc: dvj@alum.mit.edu; Geoff Thompson; a.n.weaver@IEEE.ORG; >> > >> stds-rac@IEEE.ORG >> > >> Subject: RE: Request for multiple OUI assignments >> > >> >> > >> >> > >> At 11:48 AM 8/8/2007 , Floyd Backes wrote: >> > >> >If you feel strongly about this, you could review the >> latest version of >> > >> >802.1 MAC Bridging, figure out how it can be made to work >> using the same >> > >> >MAC address on every port, get a PAR to update the >> standard, and then >> > >> >slug it out with Mick over the ensuing 2 years to produce a revised >> > >> >standard.

. > >> > > >> >As an MSC representative, I would have provided > >> >such a follow-up on the addresses used within > >> >MSC sponsored projects (754, 1394, etc.), as > >> >a duty to my position. > >> > > >> >I prefer to see the evidence before jumping into > >> >denial or conclusions, since (through out my career) > >> >I have seen suboptimal decisions made when this > >> >ordering is reversed. > >> > > >> > >> >If you feel strongly about this, > >> >Yes, I feel strongly about conservation of OUI space. > >> >I naively thoutht that to be the premise of our charter. > >> >Times change, I suppose... > >> > > >> >Cheers, > >> >DVJ > >> > > >> > >> -----Original Message----- > >> > >> From: Geoff Thompson [ mailto:gthompso@nortel.com ] > >> > >> Sent: Wednesday, August 08, 2007 3:07 PM > >> > >> To: Floyd Backes > >> > >> Cc: dvj@alum.mit.edu; Geoff Thompson; a.n.weaver@IEEE.ORG; > >> > >> stds-rac@IEEE.ORG > >> > >> Subject: RE: Request for multiple OUI assignments > >> > >> > >> > >> > >> > >> At 11:48 AM 8/8/2007 , Floyd Backes wrote: > >> > >> >If you feel strongly about this, you could review the > >> latest version of > >> > >> >802.1 MAC Bridging, figure out how it can be made to work > >> using the same > >> > >> >MAC address on every port, get a PAR to update the > >> standard, and then > >> > >> >slug it out with Mick over the ensuing 2 years to produce a revised > >> > >> >standard.

. > >As an MSC representative, I would have provided >such a follow-up on the addresses used within >MSC sponsored projects (754, 1394, etc.), as >a duty to my position. > >I prefer to see the evidence before jumping into >denial or conclusions, since (through out my career) >I have seen suboptimal decisions made when this >ordering is reversed. > > >> >If you feel strongly about this, >Yes, I feel strongly about conservation of OUI space.

While most of the current implementations are MAC addresses, and some Firewire (1394) addresses, it is expanding to all elements within the addressable environment with EUI requirements for disk drives to clusters to PCIExpress devices on the mother board and beyond.

. • Technologies such as IEEE 1394, Bluetooth and USB exist today but each has their own encapsulation, protocols, timing control, etc. such that building interworking functions is difficult.

. > >As an MSC representative, I would have provided >such a follow-up on the addresses used within >MSC sponsored projects (754, 1394, etc.), as >a duty to my position. > >I prefer to see the evidence before jumping into >denial or conclusions, since (through out my career) >I have seen suboptimal decisions made when this >ordering is reversed. > > >> >If you feel strongly about this, >Yes, I feel strongly about conservation of OUI space.

. >> >>As an MSC representative, I would have provided >>such a follow-up on the addresses used within >>MSC sponsored projects (754, 1394, etc.), as >>a duty to my position. >> >>I prefer to see the evidence before jumping into >>denial or conclusions, since (through out my career) >>I have seen suboptimal decisions made when this >>ordering is reversed. >> >> >>>>>If you feel strongly about this, >> >>Yes, I feel strongly about conservation of OUI space.

Otherwise, large companies (with many divisions) have to purchase several OUIs (as happended in 1394), because divergent interests conflict with the first user's definitions.

Examples of such applications include LAN devices, wireless access points, ANSI/TIA-862-B building automation and security devices like remote cameras, IP telephone and multimedia devices, all of which may be supported by standards such as IEEE Std 802.3™-2012 Clause 33 DTE Power via MDI or IEEE Std. 1394-2008.

. 802.3af, 802.3at TIA-862 building automation and security devices Remote cameras IP telephone Multimedia devices supported by IEEE Std 1394-2008.

This is one place where the SG received conflicting information, so the more restrictive number was used ... since existence proofs (IEEE 1588 and IEEE 1394) shows that this kind of synchronization can easily be done with very low complexity.

IEEE 1394. • The reliability of Ethernet components and systems can be extrapolated in the target environments with a high degree of confidence.

. > > From IEEE Std 1394 Serial Bus experiences, as well as > the telecom industry as a whole, the value of synchronous > transfers is greatly increased if time-of-day clocks > can also be synchronized. > > DVJ > > > David V.

Best Regards,   Adrian P STEPHENS Tel: +44 (1793) 404 825 Tel: +44 (7920) 084 900 Tel: +1 (408) 239 7485   ---------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47   From: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx] On Behalf Of Jon Rosdahl Sent: Tuesday, December 11, 2012 2:25 PM To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx Subject: [STDS-802-11-TGM] [Gen AdHoc] Update to comment spreadsheet through Dec 7th Telecon   --- This message came from the IEEE 802.11 Task Group M Technical Reflector --- I have uploaded doc 11-12/1394r3 which contains the updated status for the Gen AdHoc Comments through the Dec 7th Telecon. https://mentor.ieee.org/802.11/dcn/12/11-12-1394-03-000m-gen-adhoc-preballot-comment-collection-resolutions.xlsx   Note that there are still a lot of comments that could use some assistance in resolving.

Best Regards,   Adrian P STEPHENS Tel: +44 (1793) 404 825 Tel: +44 (7920) 084 900 Tel: +1 (408) 239 7485   ---------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47   From: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx] On Behalf Of Jon Rosdahl Sent: Tuesday, December 11, 2012 2:25 PM To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx Subject: [STDS-802-11-TGM] [Gen AdHoc] Update to comment spreadsheet through Dec 7th Telecon   --- This message came from the IEEE 802.11 Task Group M Technical Reflector --- I have uploaded doc 11-12/1394r3 which contains the updated status for the Gen AdHoc Comments through the Dec 7th Telecon. https://mentor.ieee.org/802.11/dcn/12/11-12-1394-03-000m-gen-adhoc-preballot-comment-collection-resolutions.xlsx   Note that there are still a lot of comments that could use some assistance in resolving.

References: https://mentor.ieee.org/802.11/dcn/12/11-12-1189-09-000m-mac-adhoc-pre-ballot-comment-collection-resolutions.xls , https://mentor.ieee.org/802.11/dcn/12/11-12-1082-12-0000-revmc-pre-ballot-comments.xls and https://mentor.ieee.org/802.11/dcn/12/11-12-1394-03-000m-gen-adhoc-preballot-comment-collection-resolutions.xlsx .

(ADSL2+, 1394, …) • Any other outreach (companies, countries) of importance to inform or engage?

From IEEE Std 1394 Serial Bus experiences, as well as the telecom industry as a whole, the value of synchronous transfers is greatly increased if time-of-day clocks can also be synchronized.

. > > Examples: > > IEEE Std 802(R)-2002 or IEEE 802(R)-2002 > > IEEE 802(R) Working Group > > IEEE Std 802.11b(TM)-1999 > > IEEE 1394(TM) > > IEEE P1232(TM) > >If you have any questions, CONTACT Claudio Stanziola - IEEE Standards > >Activities - telephone +1 732 562 3804; " MailTo:c.stanziola@ieee.org" ;.

RBR includes features appropriate for the > low-latency > backplane environment: destination-based flow control, low-power > short-haul > PHY, backplane-to-backplane links, transport of IEEE-1394 > isochronous > data, > and support of IEEE-1596 memory-update operations." > > Background material includes: > http://grouper.ieee.org/groups/msc/MSC200404/RbrSlides2004Mar31.pdf > http://grouper.ieee.org/groups/msc/MSC200401/RprBackplane.pdf > > Items on the agenda include: > 1) Formulation of email reflector lists. > 2) Review of approved PAR. > 3) Sollicitation of technical inputs and strawman proposals. > 4) Discussion of related activities. > 5) Future meeting schedule. > 6) Other items as requested. > > In particular, this is an opportunity to suggest directions, revisions > of the slides and objectives, and/or strawman proposals.

Jonathan   From: Das, Dibakar Sent: Thursday, September 10, 2020 10:53 To: Segev, Jonathan ; STDS-802-11-TGAZ@xxxxxxxxxxxxxxxxx Subject: RE: TGaz Sep. 9th Telecon Agenda and Call for Submissions   Hi Jonathan,   Can you please add the following CR submissions to the queue: 11-20-1392- CR for 11.22.6.3.3 (Dibakar Das) 11-20-1393- Misc CR for Clause 9 (Dibakar Das) 11-20-1394- Misc CR for Clause 11 (Dibakar Das) ?  

. • ~20 individuals from ~8 organizations • Goals for the Week – Create a set of non-binding SG Objectives – Presentations • Created ad hocs on plug and play, synchronous issues, and PoE • Set goals for November Plenary IEEE 802.3 RESG San Antonio November 2004 3November 2004 PresentationsPresentations • “Application Objectives,” Dennis Lou, Pioneer • “MaGIC experience,” Alexei Beliaev, Gibson Labs • “Bridging 1394: a requirement for Residential Ethernet, “ Michael Johas Teener, Plumblinks • “Technical and economic feasibility for millisecond deterministic delay in Residential Ethernet,” Michael Johas Teener, Plumblinks • “Residential Ethernet: 2 Criteria,” Mike McCormack, 3Com • “Some Issues and Considerations for RE,” Jae Hun Cho, Chong Ho Yoon, Samsung Electronics IEEE 802.3 RESG San Antonio November 2004 4November 2004 Draft Objectives 9/30/2004Draft Objectives 9/30/2004 • Plug and Play – No user setup required (i.e.

IEEE 802.3 Open Revision Requests
Order by Request Number IEEE 802.3 Open Revision Requests Order by Request Number Req# Status Standard Clause Date Subject 1380 B 802.3.2-2019 Various, see details 08-Sep-20 MAC address format 1383 B 802.3.1-2013 Various, see details 19-Nov-20 References to IEEE Std 802.1D 1394 B 802.3-2022 98.2.1 18-Feb-22 Clause 98 HSM support 1395 B 802.3-2022 147.8 22-Mar-22 Mixing segment specifications 1396 B 802.3-2022 147.8 22-Mar-22 Mixing segment specifications 1397 B 802.3-2022 1.4.473 01-Apr-22 Definition of "PoDL PSE" 1398 B 802.3-2022 Various, see details 23-May-22 Primitive name 1399 B 802.3-2022 56.1.3 06-Jun-22 Split Table 56-1 by media type 1400 B 802.3-2022 4.1.2.2 13-Jul-22 Description of collision 1401 B 802.3-2022 144.3.5 09-Sep-22 Remove GLID from list 1402 B 802.3-2022 135F.1 01-Dec-22 Typo 1403 B 802.3-2022 Table 119-5 09-May-23 Typo 1404 B 802.3-2022 Annex 55A 12-May-23 Machine-readable extracts 1405 B 802.3-2022 Various, see details 26-May-23 Formatting error 1406 B 802.3-2022 Various, see details 26-May-23 Incorrect cross-reference 1407 B 802.3-2022 Various, see details 02-Jun-23 Update interface list 1408 B 802.3-2022 30.12.3.1.59 07-Jul-23 "PD" not "PSE" 1409 B 802.3-2022 30.12.3.1 10-Jul-23 Duplicate subclause numbers 1410 B 802.3-2022 Various, see details 06-Aug-23 Typo 1411 B 802.3-2022 99.3.6 06-Aug-23 mCRC value mapping 1412 B 802.3-2022 99.4.7.1 06-Aug-23 State diagram conventions 1413 B 802.3-2022 99.4.7.7 18-Aug-23 SMDS_ENCODE() definition 1414 B 802.3-2022 99.4.7.7 18-Aug-23 Typo 1415 B 802.3-2022 149.8.2.1 07-Sep-23 Error in return loss limit 1416 B 802.3cy-2023 165.8.2.1 07-Sep-23 Error in return loss limit 1417 B 802.3ck-2022 161.5.3.8 20-Sep-23 am_rxpayloads derivation 1418 B 802.3-2022 Figure 36-3 20-Sep-23 Incorrect title 1419 B 802.3-2022 Figure 99-6 22-Sep-23 Missing action 1420 B 802.3ck-2022 116.4 29-Sep-23 Incorrect delay constraints 1421 I 802.3-2022 97.4.2.4 11-Oct-23 infofield_complete behavior 1422 B 802.3-2022 97.4.2.4.10 11-Oct-23 Requirement conditional on EEE 1423 B 802.3ck-2022 Various, see details 08-Nov-23 AC-coupling to test points 1424 B 802.3ck-2022 Various, see details 08-Nov-23 Add measurement frequency 1425 B 802.3-2022 Figure 119-11 13-Dec-23 Typo 1426 B 802.3-2022 149.1.3 18-Jan-24 Extraneous signal 1427 B 802.3-2022 120G.3.3.5.2 25-Jan-24 Incorrect reference point 1428 R 802.3-2022 132.1.6 07-Feb-24 Incorrect cross reference 1429 R 802.3-2022 46.3.4.3 02-Apr-24 State diagram transition 1430 R 802.3-2022 Table 141-20 03-Apr-24 Incorrect column headings 1431 R 802.3-2022 Various, see details 29-Apr-24 Update reference Return to 802.3 Maintenance Requests Page Last Update: 08 May 2024