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.

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.

. > >> > > >> >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.

I’ve uploaded the received comments to mentor:  https://mentor.ieee.org/802.11/dcn/23/11-23-1394-00-00bf-lb276-comments-and-approved-resolutions.xlsx A few action items: -           PoCs : Please review the comments that I have tentatively assigned to your area, and let me know if you any changes are needed. -           PoCs : Once you’ve reviewed the comments assigned to your area, please send a request for volunteers to your TTT. 

- Speeds - Connectivity Study Item 3: Investigating existing mechanismsInvestigating existing mechanisms - 802.3 Clause 64, Clause 65 - 1394 isochronous - Gibson MaGIC Study Item 4: Interactions with 802.1Interactions with 802.1 - Ex: 802.1d, 802.1p, 802.1q, etc… IEEE 802.3 CFI Portland July 2004 7July 2004 Call for InterestCall for Interest Request 802.3 at the Closing Plenary to form a Residential Ethernet Study Group to develop a standards project proposal (PAR and 5 Criteria) for Residential Ethernet.

. • ~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.

. – Identified points of agreement on autonegotiation – Agreed to specify 10 GbE serial, GbE serial and 10 GbE four lane (change of Five Criteria approved to be consistent with these interface objectives) – Adopted definition of “improved FR4” – Signaling ad-hoc to be formed 16 July 2004 IEEE 802.3 Report 7 802.3aq 10GBASE-LRM • Extends Ethernet capabilities at 10 Gb/s – Operation over installed multimode fiber – New physical layer to run under 802.3ae specified XGMII • Working toward first draft 16 July 2004 IEEE 802.3 Report 8 Congestion Management SG • Adopted narrowed problem statement: 802.3 MAC client needs to be able to limit traffic being received from its peer to avoid congestion due to oversubscription • Agreed on a partial set of objectives for a possible project • Study Group extended through November plenary meeting 16 July 2004 IEEE 802.3 Report 9 Frame Expansion SG • Address request from 802.1 to expand 802.3 maximum frame size to allow addition of protocol header and trailer fields – IEEE 802.3 Ad Hoc/CFI held – Also subject of joint technical plenary with 802.1 – Half duplex repeater limits and other PHY layer limitation were discussed, additional study required for PHY layers that support retiming in the data path • Study Group approved by 802.3 and Executive Committee 16 July 2004 IEEE 802.3 Report 10 Residential Ethernet SG • Successful call for interest held on Residential Ethernet – Focus is requirements of consumer electronics within the home – Issues include latency, latency jitter, and timing synchronization for consumer media distribution/playback • Study Group approved by 802.3 and Executive Committee 16 July 2004 IEEE 802.3 Report 11 Other Activities • IEEE 1394 tutorial sponsored • New maintenance requests approved, interpretations response approved • Autumn interim meeting – Details are TBD – Target week: 27 September 2004 – Target location: North America

Firewire UTP – IEEE 1394 over UTP.

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 .

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.

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.

Kind regards Stephen On Thu, 16 Nov 2023 at 14:47, Hanxiao (Tony, WT Lab) < 0000177ab8f731c4-dmarc-request@xxxxxxxxxxxxxxxxx > wrote: --- This message came from the IEEE 802.11 Chairs' Advisory Committee Reflector --- Hi Stephen,          TGbf would like to request one more motion (Now totally 3 motions):     Having approved comment resolutions for all of the comments received from LB276 on P802.11bf D2.0 as contained in document 11-23/1394r12, https://mentor.ieee.org/802.11/dcn/23/11-23-1394-12-00bf-lb276-comments-and-approved-resolutions.xlsx Instruct the editor to prepare P802.11bf D3.0 incorporating these resolutions and, Approve a 30 day Working Group Recirculation Ballot asking the question “Should P802.11bf D3.0 be forwarded to SA Ballot?”  

IEEE 1394 and 1588. • The reliability of Ethernet components and systems can be extrapolated in the target environments with a high degree of confidence. 15 November 2005 IEEE 802.1./802.3 Residential Ethernet 6 Economic Feasibility Cost factors known, reliable data Reasonable cost for performance expected Total installation costs considered • The cost factors for Ethernet components and systems are well known.

I have updated the GEN Comment Spreadsheet: https://mentor.ieee.org/802.11/dcn/12/11-12-1394-01-000m-gen-adhoc-preballot-comment-collection-resolutions.xlsx   The Tab for Vinko's set of comments is now labeled GEN-1297 Dorothy will have a motion prepared for this morning that accepts the resolution for GEN Motion A (Comments from Sept), and GEN-1297 (Vinko's Comments).  

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.

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