1. tsc@lists.fd.io
  2. Messages
   Date   
Upcoming LFN Webinar: Intelligent Networking and the Thoth Project – Where do we go from here?

Brandon Wick
 

LFN Community:

This is a notification that we have a webinar with the LFN End User Advisory Group (EUAG) coming up on Tuesday, November 30th, 7:00 AM Pacific Time. Register for the event today to learn more and get your questions answered. The recording and slide deck will be sent to all registrants post-event.

Intelligent Networking and the Thoth Project – Where do we go from here?
November 30 @ 7:00 am - 8:00 am
Based on the recently published LFN End User Advisor Group (EUAG) Intelligent Networking white paper that highlights some recommendations for supporting intelligent networking for Telecom operators, this webinar will focus on some of the work that has been started to address the identified needs. Some of the topics covered will include:

• Thoth, the first LFN AI/ML project
• The need for a common data set to support intelligent networking development
• Is the Open Source community the right place to address the gaps?

Join Beth Cohen (Verizon), Lei Huang (China Mobile), Sridhar K N Rao (Spirent), and Yuhan Zhang (China Mobile) to discuss the future of networking in the Telecom industry.


Best, 

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960
Re: Please review updated TSC fd.io page

Ole Troan
 

Dear TSC,

The changes to the TSC members page is now updated:
https://fd.io/getinvolved/tsc/

Feel free to create a PR for any changes desired.

Cheers,
Ole

On 8 Nov 2021, at 09:14, Ole Troan <otroan@employees.org> wrote:

Signed PGP part
Please take a look at:
https://github.com/FDio/site/pull/111
https://deploy-preview-111--fdio.netlify.app/getinvolved/tsc/


Still missing bio's and pictures for:
Damjan, Neale, Matt and Maciek.

Best regards,
Ole

?
signature.asc

Submit a Session for the LFN Developer & Testing Forum!

Brandon Wick
 

LFN Community:

The next LFN Developer & Testing Forum is scheduled for January 10-13, 2022. Once again we will be virtually gathering the LFN project technical communities to progress our releases; discuss project architecture, direction, and integration points; and further innovate through the open source networking stack. Participating LFN projects include Anuket, EMCO, ODIM, ONAP, OpenDaylight, Tungsten Fabric, and XGVela.

We’ll also be hosting a track with fellow networking projects and initiatives including the 5G Super Blueprint, LFN End User Advisory Group (EUAG), and L3AF.

We welcome you to submit your topic proposals on the wiki page here. Topic Proposals are due December 3rd!

Learn more about the event and register here. The event is free to attend but registration is required.

Please send any questions to ccain@.... You can also join the discussion on our event Slack in the #general channel here.

Best,

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960
Submit a Session for the LFN Developer & Testing Forum!

Trishan de Lanerolle
 

As the principal technical event for the LF Networking projects, this bi-annual gathering, has on average attracted over 500 registrants, provides the opportunity for each participating community to advance their project roadmaps and explore cross-community collaboration and integration points.  The next LFN Developer & Testing Forum is scheduled for January 10-13, 2022.

Once again we will be virtually gathering the LFN project technical communities to progress our releases; discuss project architecture, direction, and integration points; and further innovate through the open source networking stack. Confirmed LFN projects include Anuket, EMCO, ODIM, ONAP, OpenDaylight, Tungsten Fabric and XGVela. 

We’ll also be hosting a track with fellow networking projects and initiatives including the 5G Super Blueprint, LFN End User Advisory Group (EUAG), and L3AF.


We welcome you to submit your FD.io related topic proposals on the wiki page here. Topic Proposals are due December 3rd! 


Learn more about the event and register here. The event is free to attend but registration is required. 


Please send any questions to ccain@.... You can also join the discussion on our event Slack in the #general channel here.


Best, 


Trishan


--
Trishan R. de Lanerolle
Senior Technical Community Architect
Networking, Linux Foundation
voice: +1.203.699.6401
skype: tdelanerolle
REMINDER: Webinar: Deutsche Telekom Deploys ONAP in O-RAN TOWN, Thurs, 8 AM PT

Brandon Wick
 

LFN Community:

This is a reminder that we have a webinar with DT coming up this week on Thursday, November 18th, at 8:00 AM Pacific. Register for the event today to learn about how they deployed ONAP into production and get your questions answered. The recording and slide deck will be sent to all registrants post-event.

LFN Webinar: Deutsche Telekom Deploys ONAP in O-RAN TOWN
Deutsche Telekom is on their way of bringing ONAP from the labs into pilot production. In their O-RAN Town project, DT deployed in the city of Neubrandenburg a multi-vendor Open RAN trial network for 4G and 5G services with massive MIMO integrated into the live network — the first in Europe. To automate services on all network domains, DT introduced a vendor-independent Service Management and Orchestration (SMO) component based on ONAP open source. The SMO is to be at the heart of complete lifecycle management of all O-RAN components in this deployment. In this webinar, hear from  Marc Fiedler, Sebastian Zechlin, and Andreas Geissler from Deutsche Telekom about how they overcame deployment challenges and the benefits using ONAP.

Register Here

And don't miss the other LFN End User Webinars this month!

November Webinars:

Nov 10, 2021 | On Demand | Orange Deploys ONAP in Production | Olivier Augizeau from Orange; Mohamed Hassan, Mohamed Daoud, and Abdel-Muhaimen Seaudi from Orange Egypt | Get the webinar materials

Nov 18, 2021 | Deutsche Telekom Deploys ONAP in O-RAN TOWN | Marc Fiedler, Sebastian Zechlin, and Andreas Geissler from Deutsche Telekom | Learn More & Register

Nov 30, 2021 | Intelligent Networking and the Thoth Project – Where do we go from here? | Beth Cohen, Verizon; Lei Huang, China Mobile; Sridhar K N Rao; Spirent; Yuhan Zhang, China Mobile | Learn More & Register

Best, 

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960
Re: Dave Wallace to be my proxy at FD.io TSC Meeting

Maciek Konstantynowicz (mkonstan)
 

+1

On 11 Nov 2021, at 14:48, Matthew Smith via lists.fd.io <mgsmith=netgate.com@...> wrote:


On Thu, Nov 11, 2021 at 8:00 AM Edward Warnicke <hagbard@...> wrote:
Ole,

I don't see how this actually changes anything about the daylight savings time issues... it just moves those issues around.

If you enter your meeting in your calendar in PST (the timezone) it moves automatically - no issues

If you enter your meeting in your calendar in CEST (the timezone) it moves automatically - no issues

If you enter your meeting in your calendar as an offset from a timezone (any timezone) to your local timezone at the time you add the meeting - it doesn't move, issues.

I can't speak for anyone else, but this is exactly what I did. I looked at the TSC wiki page, saw that the meeting time was 8:00 Pacific Time, converted that to my local time and added an appointment on my calendar at the converted local time. Then my calendar faithfully (,foolishly) believed that I knew what I was talking about when I created the appointment :)

Maybe it would solve some problems if we had an ICS file which contains data on the TSC meeting on the wiki page that people could download in order to add the appointment to their calendars. Then an appointment would be added to calendars associated with the chosen time zone and calendar software could correctly convert it for us to our local time zones. 

And/or we could spell things out in great detail with regards to DST like the CSIT page does about the CSIT weekly meeting.

-Matt
Re: [vpp-dev] [csit-dev] FD.io CSIT-2110 Release Report is published

Maciek Konstantynowicz (mkonstan)
 

Dear Ameen, pls see inline.

On 11 Nov 2021, at 20:19, Ameen Al-Azzawi <ameen.azzawi@...> wrote:

Dear Maciek,

I didn't mean to be rude, but you know how it feels when you see a community of professionals for specific software and no one could help.

Understand.

I know that no one is obliged to help me, I was simply expecting more out of it.

My read is that folks are simply very busy, and number of people versed in ds-lite and other softwire technologies that VPP implements aplenty of, is not that large. So pls bear with this community, and keep trying. Someone wise once said "Energy and (constructive) persistence conquer all things”, especially when done with conviction of being right ;)

Cheers,
Maciek


Regards
Ameen  

On Thu, Nov 11, 2021 at 4:39 PM Maciek Konstantynowicz (mkonstan) <mkonstan@...> wrote:
Dear Ameen,

What specific statement in the email do you disagree with?

This is not a research paper, it is FD.io CSIT release report capturing benchmarking and functional test data for v21.10 release.

Regarding your comment about "VPP and the system doesn't function”, I checked your statement about:

"I have asked here a million times about configuring ds-lite, no one helped.”

And found out that you have sent few emails (between 26-Sep and 28-Oct) to vpp-dev with questions about running ds-lite on vpp, and the last email was not answered.
I suggest you resend the email, and I am confident that FD.io dev community will provide you with support.

Cheers,
Maciek


On 11 Nov 2021, at 14:22, Ameen Al-Azzawi <ameen.azzawi@...> wrote:

I would totally disagree.
It is disappointing when you base your research paper on VPP and the system doesn't function.
I have asked here a million times about configuring ds-lite, no one helped.

On Thu, Nov 11, 2021 at 3:19 PM Maciek Konstantynowicz (mkonstan) via lists.fd.io <mkonstan=cisco.com@...> wrote:
Big thanks to FD.io community contributors and supporters that enabled this data-rich publication.
Great job everyone!

Cheers,
Maciek

On 10 Nov 2021, at 18:12, Tibor Frank via lists.fd.io <tifrank=cisco.com@...> wrote:

Hi All,
 
FD.io CSIT-2110 report is now available on FD.io docs site:
 
 
Another successful release! Many thanks to all contributors in CSIT and
VPP communities for making it happen.
 
See below for CSIT-2110 release summary and pointers to specific
sections in the report.
 
Welcome all comments, best by email to csit-dev@....
 
Tibor
 
 
CSIT-2110 Release Summary
-------------------------
 
BENCHMARK TESTS
 
- Intel Xeon Ice Lake: Added test data for these platforms. Current CSIT-2110
  report data for Intel Xeon Ice Lake comes from an external source (Intel
  labs running CSIT code on “8360Y D Stepping” and “6338N” processors).
 
- MLRsearch improvements: Added support for multiple packet throughput rates
  in a single search, each rate is associated with a distinct Packet Loss Ratio
  (PLR) criterion. Previously only Non Drop Rate (NDR) (PLR=0) and single
  Partial Drop Rate (PDR) (PLR<0.5%) were supported. Implemented number of
  optimizations improving rate discovery efficiency.
 
- TREX performance tests: Added initial tests for testing latency between 2
  ports on nic on the TRex. Added tests: IP4Base, IP4scale2m, IP6Base,
  IP6scale2m, L2bscale1mmaclrn.
 
TEST FRAMEWORK
 
- CSIT test environment version has been updated to ver. 8: Intel NIC 700/800
  series firmware upgrade based on DPDK compatibility matrix.
 
- CSIT in AWS environment: Added CSIT support for AWS c5n instances
  environment.
 
Pointers to CSIT-2110 Report sections
-------------------------------------
 
1. FD.io CSIT test methodology          [1]
2. VPP release notes                    [2]
3. VPP 64B/IMIX throughput graphs       [3]
4. VPP throughput speedup multi-core    [4]
5. VPP latency under load               [5]
6. VPP comparisons v21.10 vs. v21.06    [6]
7. VPP performance all pkt sizes & NICs [7]
8. DPDK 21.08 apps release notes        [8]
9. DPDK 64B throughput graphs           [9]
10. DPDK latency under load             [10]
11. DPDK comparisons 21.08 vs. 21.02    [11]
12. TRex 2.88 apps release notes        [12]
13. TRex 64B throughput graphs          [13]
14. TRex latency under load             [14]
 
Functional device tests (VPP_Device) are also included in the report.
 
 
 
Re: [vpp-dev] [csit-dev] FD.io CSIT-2110 Release Report is published

Maciek Konstantynowicz (mkonstan)
 

Dear Ameen,

What specific statement in the email do you disagree with?

This is not a research paper, it is FD.io CSIT release report capturing benchmarking and functional test data for v21.10 release.

Regarding your comment about "VPP and the system doesn't function”, I checked your statement about:

"I have asked here a million times about configuring ds-lite, no one helped.”

And found out that you have sent few emails (between 26-Sep and 28-Oct) to vpp-dev with questions about running ds-lite on vpp, and the last email was not answered.
I suggest you resend the email, and I am confident that FD.io dev community will provide you with support.

Cheers,
Maciek


On 11 Nov 2021, at 14:22, Ameen Al-Azzawi <ameen.azzawi@...> wrote:

I would totally disagree.
It is disappointing when you base your research paper on VPP and the system doesn't function.
I have asked here a million times about configuring ds-lite, no one helped.

On Thu, Nov 11, 2021 at 3:19 PM Maciek Konstantynowicz (mkonstan) via lists.fd.io <mkonstan=cisco.com@...> wrote:
Big thanks to FD.io community contributors and supporters that enabled this data-rich publication.
Great job everyone!

Cheers,
Maciek

On 10 Nov 2021, at 18:12, Tibor Frank via lists.fd.io <tifrank=cisco.com@...> wrote:

Hi All,
 
FD.io CSIT-2110 report is now available on FD.io docs site:
 
 
Another successful release! Many thanks to all contributors in CSIT and
VPP communities for making it happen.
 
See below for CSIT-2110 release summary and pointers to specific
sections in the report.
 
Welcome all comments, best by email to csit-dev@....
 
Tibor
 
 
CSIT-2110 Release Summary
-------------------------
 
BENCHMARK TESTS
 
- Intel Xeon Ice Lake: Added test data for these platforms. Current CSIT-2110
  report data for Intel Xeon Ice Lake comes from an external source (Intel
  labs running CSIT code on “8360Y D Stepping” and “6338N” processors).
 
- MLRsearch improvements: Added support for multiple packet throughput rates
  in a single search, each rate is associated with a distinct Packet Loss Ratio
  (PLR) criterion. Previously only Non Drop Rate (NDR) (PLR=0) and single
  Partial Drop Rate (PDR) (PLR<0.5%) were supported. Implemented number of
  optimizations improving rate discovery efficiency.
 
- TREX performance tests: Added initial tests for testing latency between 2
  ports on nic on the TRex. Added tests: IP4Base, IP4scale2m, IP6Base,
  IP6scale2m, L2bscale1mmaclrn.
 
TEST FRAMEWORK
 
- CSIT test environment version has been updated to ver. 8: Intel NIC 700/800
  series firmware upgrade based on DPDK compatibility matrix.
 
- CSIT in AWS environment: Added CSIT support for AWS c5n instances
  environment.
 
Pointers to CSIT-2110 Report sections
-------------------------------------
 
1. FD.io CSIT test methodology          [1]
2. VPP release notes                    [2]
3. VPP 64B/IMIX throughput graphs       [3]
4. VPP throughput speedup multi-core    [4]
5. VPP latency under load               [5]
6. VPP comparisons v21.10 vs. v21.06    [6]
7. VPP performance all pkt sizes & NICs [7]
8. DPDK 21.08 apps release notes        [8]
9. DPDK 64B throughput graphs           [9]
10. DPDK latency under load             [10]
11. DPDK comparisons 21.08 vs. 21.02    [11]
12. TRex 2.88 apps release notes        [12]
13. TRex 64B throughput graphs          [13]
14. TRex latency under load             [14]
 
Functional device tests (VPP_Device) are also included in the report.
 
 
 
Re: Dave Wallace to be my proxy at FD.io TSC Meeting

Matthew Smith
 


On Thu, Nov 11, 2021 at 8:00 AM Edward Warnicke <hagbard@...> wrote:
Ole,

I don't see how this actually changes anything about the daylight savings time issues... it just moves those issues around.

If you enter your meeting in your calendar in PST (the timezone) it moves automatically - no issues

If you enter your meeting in your calendar in CEST (the timezone) it moves automatically - no issues

If you enter your meeting in your calendar as an offset from a timezone (any timezone) to your local timezone at the time you add the meeting - it doesn't move, issues.

I can't speak for anyone else, but this is exactly what I did. I looked at the TSC wiki page, saw that the meeting time was 8:00 Pacific Time, converted that to my local time and added an appointment on my calendar at the converted local time. Then my calendar faithfully (,foolishly) believed that I knew what I was talking about when I created the appointment :)

Maybe it would solve some problems if we had an ICS file which contains data on the TSC meeting on the wiki page that people could download in order to add the appointment to their calendars. Then an appointment would be added to calendars associated with the chosen time zone and calendar software could correctly convert it for us to our local time zones. 

And/or we could spell things out in great detail with regards to DST like the CSIT page does about the CSIT weekly meeting.

-Matt
Re: [csit-dev] FD.io CSIT-2110 Release Report is published

Maciek Konstantynowicz (mkonstan)
 

Big thanks to FD.io community contributors and supporters that enabled this data-rich publication.
Great job everyone!

Cheers,
Maciek

On 10 Nov 2021, at 18:12, Tibor Frank via lists.fd.io <tifrank=cisco.com@...> wrote:

Hi All,
 
FD.io CSIT-2110 report is now available on FD.io docs site:
 
 
Another successful release! Many thanks to all contributors in CSIT and
VPP communities for making it happen.
 
See below for CSIT-2110 release summary and pointers to specific
sections in the report.
 
Welcome all comments, best by email to csit-dev@....
 
Tibor
 
 
CSIT-2110 Release Summary
-------------------------
 
BENCHMARK TESTS
 
- Intel Xeon Ice Lake: Added test data for these platforms. Current CSIT-2110
  report data for Intel Xeon Ice Lake comes from an external source (Intel
  labs running CSIT code on “8360Y D Stepping” and “6338N” processors).
 
- MLRsearch improvements: Added support for multiple packet throughput rates
  in a single search, each rate is associated with a distinct Packet Loss Ratio
  (PLR) criterion. Previously only Non Drop Rate (NDR) (PLR=0) and single
  Partial Drop Rate (PDR) (PLR<0.5%) were supported. Implemented number of
  optimizations improving rate discovery efficiency.
 
- TREX performance tests: Added initial tests for testing latency between 2
  ports on nic on the TRex. Added tests: IP4Base, IP4scale2m, IP6Base,
  IP6scale2m, L2bscale1mmaclrn.
 
TEST FRAMEWORK
 
- CSIT test environment version has been updated to ver. 8: Intel NIC 700/800
  series firmware upgrade based on DPDK compatibility matrix.
 
- CSIT in AWS environment: Added CSIT support for AWS c5n instances
  environment.
 
Pointers to CSIT-2110 Report sections
-------------------------------------
 
1. FD.io CSIT test methodology          [1]
2. VPP release notes                    [2]
3. VPP 64B/IMIX throughput graphs       [3]
4. VPP throughput speedup multi-core    [4]
5. VPP latency under load               [5]
6. VPP comparisons v21.10 vs. v21.06    [6]
7. VPP performance all pkt sizes & NICs [7]
8. DPDK 21.08 apps release notes        [8]
9. DPDK 64B throughput graphs           [9]
10. DPDK latency under load             [10]
11. DPDK comparisons 21.08 vs. 21.02    [11]
12. TRex 2.88 apps release notes        [12]
13. TRex 64B throughput graphs          [13]
14. TRex latency under load             [14]
 
Functional device tests (VPP_Device) are also included in the report.
 
 
 
Re: Dave Wallace to be my proxy at FD.io TSC Meeting

Edward Warnicke
 

Ole,

I don't see how this actually changes anything about the daylight savings time issues... it just moves those issues around.

If you enter your meeting in your calendar in PST (the timezone) it moves automatically - no issues

If you enter your meeting in your calendar in CEST (the timezone) it moves automatically - no issues

If you enter your meeting in your calendar as an offset from a timezone (any timezone) to your local timezone at the time you add the meeting - it doesn't move, issues.

The root issue is timezone+offset scheduling, which is made no better or worse by choice of timezone (PST, CEST, UTC).
(or if you prefer, the fact that all of our calendars take their times in Timezones, not Offsets - note: I checked this in both Google Calendar and Outlook, while they *display* todays offset along side their Timezone... they are *respecting* the Timezone, not the offset).

I can completely buy a desire to move the meeting time to an EU timezone if folks would like to... but pretending that actually solves our problems... well... it doesn't.

Ed

On Thu, Nov 11, 2021 at 3:13 AM <otroan@...> wrote:
> It seems to me that we should define it in either CET or US Pacific and be done with it.  We have done it in US Pacific.  If folks want to change it to CET, so be it.  Changing it to a time in UTC would mean that it would be at different times in two halves the year for everyone.  Why would that be good?   (Offset is as far as I can tell irrelevant if you define it as starting at a specific time UTC.  Unless you declare the offset to vary by time of year.  At which point it is easier  to use some other time zone.)

The point of defining the meeting at a fixed time is to avoid the summer time issues. Largely caused by the US and Europe swapping at different times mind you. Look at this as a preemptive strike since summer time is likely to be deprecated anyway.

O.
Today's call

Joel Halpern
 

I will be at the IETF meeting, IDR session during our call slot.

Yours,
Joel

Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone
Get Outlook for Android
Re: Dave Wallace to be my proxy at FD.io TSC Meeting

Ole Troan
 

It seems to me that we should define it in either CET or US Pacific and be done with it. We have done it in US Pacific. If folks want to change it to CET, so be it. Changing it to a time in UTC would mean that it would be at different times in two halves the year for everyone. Why would that be good? (Offset is as far as I can tell irrelevant if you define it as starting at a specific time UTC. Unless you declare the offset to vary by time of year. At which point it is easier to use some other time zone.)
The point of defining the meeting at a fixed time is to avoid the summer time issues. Largely caused by the US and Europe swapping at different times mind you. Look at this as a preemptive strike since summer time is likely to be deprecated anyway.

O.

?
signature.asc

Re: Dave Wallace to be my proxy at FD.io TSC Meeting

Joel Halpern
 

It seems to me that we should define it in either CET or US Pacific and be done with it. We have done it in US Pacific. If folks want to change it to CET, so be it. Changing it to a time in UTC would mean that it would be at different times in two halves the year for everyone. Why would that be good? (Offset is as far as I can tell irrelevant if you define it as starting at a specific time UTC. Unless you declare the offset to vary by time of year. At which point it is easier to use some other time zone.)

Yours,
Joel

-----Original Message-----
From: tsc@lists.fd.io <tsc@lists.fd.io> On Behalf Of Ole Troan via lists.fd.io
Sent: Wednesday, November 10, 2021 12:08 PM
To: Ed Warnicke <hagbard@gmail.com>
Cc: Ray Kinsella <ray.kinsella@intel.com>; Dave Wallace <dwallacelf@gmail.com>; tsc@lists.fd.io
Subject: Re: [tsc] Dave Wallace to be my proxy at FD.io TSC Meeting

Ed,

LOL... I'm OK with us making a choice of timezone to offset into. It just gets my hackles up when folks somehow pretend UTC+offsets are some universal answer to the problem: they aren't.

UTC+offsets is *not* a timezone... ISO 8601 is for identifying *points* in time, not timezones. If we want to set our meetings in the UTC timezone, that's fine, but pretending it's anything but a choice of timezones and is somehow magically universal has been a point of ongoing annoyance for me :)

All of that said, given that the weight of the TSC is in EU, I'm fine picking an EU oriented timezone to anchor the meeting in, like CEST... or even UTC :)
I think it is a misunderstanding that you need a time zone.
You need a fixed reference point in time for when the meeting should happen.
E.g. 1500UTC.

Then it's up to local participants to figure out what they have their watches set to in relation to this.

O.
Dave Wallace to be VPP project represetative at TSC

Damjan Marion
 

Guys,

According to the new fd.io Technical Community Doc:

---
A Core Projects PTL may choose to appoint another committer from that Core Project to represent the core project in their stead.
---

As Dave is already attending TSC meetings for a long period of time and he is very active I decided to appoint Dave to represent VPP project.

Thanks,

—
Damjan
Re: Dave Wallace to be my proxy at FD.io TSC Meeting

Ole Troan
 

Ed,

LOL... I'm OK with us making a choice of timezone to offset into. It just gets my hackles up when folks somehow pretend UTC+offsets are some universal answer to the problem: they aren't.

UTC+offsets is *not* a timezone... ISO 8601 is for identifying *points* in time, not timezones. If we want to set our meetings in the UTC timezone, that's fine, but pretending it's anything but a choice of timezones and is somehow magically universal has been a point of ongoing annoyance for me :)

All of that said, given that the weight of the TSC is in EU, I'm fine picking an EU oriented timezone to anchor the meeting in, like CEST... or even UTC :)
I think it is a misunderstanding that you need a time zone.
You need a fixed reference point in time for when the meeting should happen.
E.g. 1500UTC.

Then it's up to local participants to figure out what they have their watches set to in relation to this.

O.

?
signature.asc

Re: Dave Wallace to be my proxy at FD.io TSC Meeting

Edward Warnicke
 

Ray,

LOL... I'm OK with us making a choice of timezone to offset into.  It just gets my hackles up when folks somehow pretend UTC+offsets are some universal answer to the problem: they aren't.

UTC+offsets is *not* a timezone... ISO 8601 is for identifying *points* in time, not timezones.  If we want to set our meetings in the UTC timezone, that's fine, but pretending it's anything but a choice of timezones and is somehow magically universal has been a point of ongoing annoyance for me :)

All of that said, given that the weight of the TSC is in EU, I'm fine picking an EU oriented timezone to anchor the meeting in, like CEST... or even UTC :)

Ed

On Wed, Nov 10, 2021 at 9:33 AM Ray Kinsella <ray.kinsella@...> wrote:

Thanks Ed,

 

Given your prior experience then.

Can you suggest then, an alternative that might work better?

 

Ray K

 

From: Ed Warnicke <hagbard@...>
Sent: Wednesday 10 November 2021 15:32
To: Ole Troan <otroan@...>
Cc: Kinsella, Ray <ray.kinsella@...>; Dave Wallace <dwallacelf@...>; tsc@...
Subject: Re: [tsc] Dave Wallace to be my proxy at FD.io TSC Meeting

 

Ole,

 

Offset from UTC is not a timezone... it's an identifier of a point in time.  It's intrinsically a *choice* of timezone, no better or worse than any other.

 

Ed, who has had the grave misfortune of having to exercise the distinction between timezones and offsets in code in anger

 

On Thu, Nov 4, 2021 at 11:23 AM Ole Troan <otroan@...> wrote:

I'll repeat what I said last year when this happened, and what I said two years ago when this happened.
Meetings with an international crowd should be set as an offset from UTC. Not some local time zone.

(and Ray you agreed me last year too. ;-))

O.

> On 4 Nov 2021, at 17:09, Ray Kinsella <ray.kinsella@...> wrote:
>
> Yes – Maciek, Neale, Vratko and I showed up 1 hour late.
> Apologies for that!
>
> Ray K
>
> From: tsc@... <tsc@...> On Behalf Of Dave Wallace
> Sent: Thursday 4 November 2021 15:28
> To: tsc@...
> Subject: Re: [tsc] Dave Wallace to be my proxy at FD.io TSC Meeting
>
> Given the DST change in Europe, today’s call was primarily attended by US based TSC members.  It was agreed by at the meeting to skip this week given a lack of urgent agenda items in conjunction with not having a quorum.
>
> US DST ends this Saturday 11/6/2021 at midnight, so next week the time zone difference will not be a issue.
>
> Have a great week!
>
> -daw-
>
>
>
> On 11/3/21 12:59 PM, Edward Warnicke wrote:
> Dave Wallace has kindly agreed to be my proxy for the FD.io TSC Meeting tomorrow.
>
> Ray Kinsella has kindly agreed to chair.
>
> Ed
>
>
>
>
>
>
>
>
>





Re: Dave Wallace to be my proxy at FD.io TSC Meeting

Ray Kinsella
 

Thanks Ed,

 

Given your prior experience then.

Can you suggest then, an alternative that might work better?

 

Ray K

 

From: Ed Warnicke <hagbard@...>
Sent: Wednesday 10 November 2021 15:32
To: Ole Troan <otroan@...>
Cc: Kinsella, Ray <ray.kinsella@...>; Dave Wallace <dwallacelf@...>; tsc@...
Subject: Re: [tsc] Dave Wallace to be my proxy at FD.io TSC Meeting

 

Ole,

 

Offset from UTC is not a timezone... it's an identifier of a point in time.  It's intrinsically a *choice* of timezone, no better or worse than any other.

 

Ed, who has had the grave misfortune of having to exercise the distinction between timezones and offsets in code in anger

 

On Thu, Nov 4, 2021 at 11:23 AM Ole Troan <otroan@...> wrote:

I'll repeat what I said last year when this happened, and what I said two years ago when this happened.
Meetings with an international crowd should be set as an offset from UTC. Not some local time zone.

(and Ray you agreed me last year too. ;-))

O.

> On 4 Nov 2021, at 17:09, Ray Kinsella <ray.kinsella@...> wrote:
>
> Yes – Maciek, Neale, Vratko and I showed up 1 hour late.
> Apologies for that!
>
> Ray K
>
> From: tsc@... <tsc@...> On Behalf Of Dave Wallace
> Sent: Thursday 4 November 2021 15:28
> To: tsc@...
> Subject: Re: [tsc] Dave Wallace to be my proxy at FD.io TSC Meeting
>
> Given the DST change in Europe, today’s call was primarily attended by US based TSC members.  It was agreed by at the meeting to skip this week given a lack of urgent agenda items in conjunction with not having a quorum.
>
> US DST ends this Saturday 11/6/2021 at midnight, so next week the time zone difference will not be a issue.
>
> Have a great week!
>
> -daw-
>
>
>
> On 11/3/21 12:59 PM, Edward Warnicke wrote:
> Dave Wallace has kindly agreed to be my proxy for the FD.io TSC Meeting tomorrow.
>
> Ray Kinsella has kindly agreed to chair.
>
> Ed
>
>
>
>
>
>
>
>
>


Re: Dave Wallace to be my proxy at FD.io TSC Meeting

Edward Warnicke
 

Ole,

Offset from UTC is not a timezone... it's an identifier of a point in time.  It's intrinsically a *choice* of timezone, no better or worse than any other.

Ed, who has had the grave misfortune of having to exercise the distinction between timezones and offsets in code in anger

On Thu, Nov 4, 2021 at 11:23 AM Ole Troan <otroan@...> wrote:
I'll repeat what I said last year when this happened, and what I said two years ago when this happened.
Meetings with an international crowd should be set as an offset from UTC. Not some local time zone.

(and Ray you agreed me last year too. ;-))

O.

> On 4 Nov 2021, at 17:09, Ray Kinsella <ray.kinsella@...> wrote:
>
> Yes – Maciek, Neale, Vratko and I showed up 1 hour late.
> Apologies for that!
>
> Ray K
>
> From: tsc@... <tsc@...> On Behalf Of Dave Wallace
> Sent: Thursday 4 November 2021 15:28
> To: tsc@...
> Subject: Re: [tsc] Dave Wallace to be my proxy at FD.io TSC Meeting
>
> Given the DST change in Europe, today’s call was primarily attended by US based TSC members.  It was agreed by at the meeting to skip this week given a lack of urgent agenda items in conjunction with not having a quorum.
>
> US DST ends this Saturday 11/6/2021 at midnight, so next week the time zone difference will not be a issue.
>
> Have a great week!
>
> -daw-
>
>
>
> On 11/3/21 12:59 PM, Edward Warnicke wrote:
> Dave Wallace has kindly agreed to be my proxy for the FD.io TSC Meeting tomorrow.
>
> Ray Kinsella has kindly agreed to chair.
>
> Ed
>
>
>
>
>
>
>
>
>




Re: Dave Wallace to be my proxy at FD.io TSC Meeting

Maciek Konstantynowicz (mkonstan)
 

Ray, do you mean GMT [1] or UTC [2], they are different [3]. 

And yes, I know, the world of time is confusing, so no surprise we get confused to :)

Cheers,

On 4 Nov 2021, at 16:33, Ray Kinsella <ray.kinsella@...> wrote:


I also remember suggesting getting rid of timezones and the entire world aligning on GMT. 😊

If we aligned on 15:00 hours UTC? Perhaps we can vote on it next week.

Ray K

-----Original Message-----
From: otroan@... <otroan@...>
Sent: Thursday 4 November 2021 16:24
To: Kinsella, Ray <ray.kinsella@...>
Cc: Dave Wallace <dwallacelf@...>; tsc@...
Subject: Re: [tsc] Dave Wallace to be my proxy at FD.io TSC Meeting

I'll repeat what I said last year when this happened, and what I said
two years ago when this happened.
Meetings with an international crowd should be set as an offset from
UTC. Not some local time zone.

(and Ray you agreed me last year too. ;-))

O.

On 4 Nov 2021, at 17:09, Ray Kinsella <ray.kinsella@...>
wrote:

Yes – Maciek, Neale, Vratko and I showed up 1 hour late.
Apologies for that!

Ray K

From: tsc@... <tsc@...> On Behalf Of Dave Wallace
Sent: Thursday 4 November 2021 15:28
To: tsc@...
Subject: Re: [tsc] Dave Wallace to be my proxy at FD.io TSC Meeting

Given the DST change in Europe, today’s call was primarily attended
by US based TSC members.  It was agreed by at the meeting to skip this
week given a lack of urgent agenda items in conjunction with not
having a quorum.

US DST ends this Saturday 11/6/2021 at midnight, so next week the
time zone difference will not be a issue.

Have a great week!

-daw-



On 11/3/21 12:59 PM, Edward Warnicke wrote:
Dave Wallace has kindly agreed to be my proxy for the FD.io TSC
Meeting tomorrow.

Ray Kinsella has kindly agreed to chair.

Ed
1 - 20 of 1629