Date   
Upcoming LFN Webinars

Brandon Wick
 

LFN Community:

We've now confirmed 2 webinars in July from LFN Members Kubermatic and PANTHEON.tech:

July 7, 2020 | Why Edge Computing Requires Cloud Native Thinking | Bill Mulligan, Kubermatic | Learn More & Register

July 16, 2020 | Building CNFs with FD.io VPP and Network Service Mesh + VPP traceability in cloud-native deployments | Milan Lenčo & Pavel Kotúček, PANTHEON.tech | Learn More & Register

See all upcoming LFN webinars as well as past webinars available on demand here:


LFN members interested in hosting a webinar should read the guidelines and fill in the webinar submission form

Best, 

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960

Community Input Required: Annual LFN Operations Survey

Brandon Wick
 

I'm not sure the hyperlink was working properly in my last email. Here again is the link to the Survey: https://www.surveymonkey.com/r/KGZNK5Z. Thanks all.

---------- Forwarded message ---------
From: Brandon Wick <bwick@...>
Date: Thu, Jul 2, 2020 at 1:29 PM
Subject: Community Input Required: Annual LFN Operations Survey
To:


LF Communities:

For the second year, LF Networking staff have pulled together an LFN Operations Survey, AKA "staff survey of the community." The goal is to solicit feedback from LFN community members to learn how you are engaging with projects, what you are experiencing, what the challenges are, and how the LFN staff can better support you. Your feedback is very important so please take a few minutes to share your thoughts with us. Responses are due by Friday, July 24th

Take the Survey here: https://www.surveymonkey.com/r/KGZNK5Z

Best,

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960


--

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960

Community Input Required: Annual LFN Operations Survey

Brandon Wick
 

LF Communities:

For the second year, LF Networking staff have pulled together an LFN Operations Survey, AKA "staff survey of the community." The goal is to solicit feedback from LFN community members to learn how you are engaging with projects, what you are experiencing, what the challenges are, and how the LFN staff can better support you. Your feedback is very important so please take a few minutes to share your thoughts with us. Responses are due by Friday, July 24th


Best,

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960

OpenGrok Question

Vanessa Valderrama
 

LF is doing reviewing our INFRA inventory. We'd like to know if the
community actively uses OpenGrok?

Thank you,
Vanessa

Re: Cancelling this weeks TSC?

Edward Warnicke
 

Cancelled

Ed

On Tue, Jun 30, 2020 at 8:01 AM Joel Halpern <joel.halpern@...> wrote:

Fine with me.

Joel

 

From: tsc@... <tsc@...> On Behalf Of Dave Barach via lists.fd.io
Sent: Tuesday, June 30, 2020 6:06 AM
To: George Zhao <george.zhao@...>
Cc: Edward Warnicke <hagbard@...>; tsc@...; ray.kinsella@...
Subject: Re: [tsc] Cancelling this weeks TSC?

 

+1 let’s cancel...

Thanks... Dave



On Jun 30, 2020, at 4:21 AM, George Zhao <george.zhao@...> wrote:



Although I can't go anywhere, but mind probably already in vacation mode.)

George


From: tsc@... <tsc@...> on behalf of Ray Kinsella via lists.fd.io <ray.kinsella=intel.com@...>
Sent: Tuesday, June 30, 2020 12:55:00 AM
To: Edward Warnicke <hagbard@...>; tsc@... <tsc@...>
Subject: Re: [tsc] Cancelling this weeks TSC?

 

Yes – makes sense.

 

Ray K

 

From: tsc@... <tsc@...> On Behalf Of Edward Warnicke
Sent: Tuesday 30 June 2020 04:32
To: tsc@...
Subject: [tsc] Cancelling this weeks TSC?

 

I believe a great many of the TSC members may be on PTO this week due to holidays, do we want to cancel this week's TSC meeting?

 

Ed

 

Re: Cancelling this weeks TSC?

Joel Halpern
 

Fine with me.

Joel

 

From: tsc@... <tsc@...> On Behalf Of Dave Barach via lists.fd.io
Sent: Tuesday, June 30, 2020 6:06 AM
To: George Zhao <george.zhao@...>
Cc: Edward Warnicke <hagbard@...>; tsc@...; ray.kinsella@...
Subject: Re: [tsc] Cancelling this weeks TSC?

 

+1 let’s cancel...

Thanks... Dave



On Jun 30, 2020, at 4:21 AM, George Zhao <george.zhao@...> wrote:



Although I can't go anywhere, but mind probably already in vacation mode.)

George


From: tsc@... <tsc@...> on behalf of Ray Kinsella via lists.fd.io <ray.kinsella=intel.com@...>
Sent: Tuesday, June 30, 2020 12:55:00 AM
To: Edward Warnicke <hagbard@...>; tsc@... <tsc@...>
Subject: Re: [tsc] Cancelling this weeks TSC?

 

Yes – makes sense.

 

Ray K

 

From: tsc@... <tsc@...> On Behalf Of Edward Warnicke
Sent: Tuesday 30 June 2020 04:32
To: tsc@...
Subject: [tsc] Cancelling this weeks TSC?

 

I believe a great many of the TSC members may be on PTO this week due to holidays, do we want to cancel this week's TSC meeting?

 

Ed

 

Re: Cancelling this weeks TSC?

Dave Barach
 

+1 let’s cancel...

Thanks... Dave

On Jun 30, 2020, at 4:21 AM, George Zhao <george.zhao@...> wrote:


Although I can't go anywhere, but mind probably already in vacation mode.)

George


From: tsc@... <tsc@...> on behalf of Ray Kinsella via lists.fd.io <ray.kinsella=intel.com@...>
Sent: Tuesday, June 30, 2020 12:55:00 AM
To: Edward Warnicke <hagbard@...>; tsc@... <tsc@...>
Subject: Re: [tsc] Cancelling this weeks TSC?
 

Yes – makes sense.

 

Ray K

 

From: tsc@... <tsc@...> On Behalf Of Edward Warnicke
Sent: Tuesday 30 June 2020 04:32
To: tsc@...
Subject: [tsc] Cancelling this weeks TSC?

 

I believe a great many of the TSC members may be on PTO this week due to holidays, do we want to cancel this week's TSC meeting?

 

Ed


Re: Cancelling this weeks TSC?

George Zhao
 

Although I can't go anywhere, but mind probably already in vacation mode.)

George


From: tsc@... <tsc@...> on behalf of Ray Kinsella via lists.fd.io <ray.kinsella=intel.com@...>
Sent: Tuesday, June 30, 2020 12:55:00 AM
To: Edward Warnicke <hagbard@...>; tsc@... <tsc@...>
Subject: Re: [tsc] Cancelling this weeks TSC?
 

Yes – makes sense.

 

Ray K

 

From: tsc@... <tsc@...> On Behalf Of Edward Warnicke
Sent: Tuesday 30 June 2020 04:32
To: tsc@...
Subject: [tsc] Cancelling this weeks TSC?

 

I believe a great many of the TSC members may be on PTO this week due to holidays, do we want to cancel this week's TSC meeting?

 

Ed

Re: Cancelling this weeks TSC?

Ray Kinsella
 

Yes – makes sense.

 

Ray K

 

From: tsc@... <tsc@...> On Behalf Of Edward Warnicke
Sent: Tuesday 30 June 2020 04:32
To: tsc@...
Subject: [tsc] Cancelling this weeks TSC?

 

I believe a great many of the TSC members may be on PTO this week due to holidays, do we want to cancel this week's TSC meeting?

 

Ed

Cancelling this weeks TSC?

Edward Warnicke
 

I believe a great many of the TSC members may be on PTO this week due to holidays, do we want to cancel this week's TSC meeting?

Ed

Re: Absence

Edward Warnicke
 

All good!  Look forward to seeing you next week :)

Ed

On Thu, Jun 25, 2020 at 10:51 AM George Zhao <george.zhao@...> wrote:
Oops, my phone automatically turned off alarm for (Chinese) holidays, sorry I missed today's TSC.

thanks,
George

From: tsc@... <tsc@...> on behalf of Edward Warnicke via lists.fd.io <eaw=cisco.com@...>
Sent: Wednesday, June 24, 2020 9:28 AM
To: joel.halpern@... <joel.halpern@...>
Cc: tsc@... <tsc@...>
Subject: Re: [tsc] Absence
 
Thanks for letting us know :)

Ed

On Jun 24, 2020, at 10:12 AM, Joel Halpern via lists.fd.io <joel.halpern=ericsson.com@...> wrote:

I have a conflicting call tomorrow that I can not reschedule.  Sorry.
Yours,
Joel


Re: Absence

George Zhao
 

Oops, my phone automatically turned off alarm for (Chinese) holidays, sorry I missed today's TSC.

thanks,
George


From: tsc@... <tsc@...> on behalf of Edward Warnicke via lists.fd.io <eaw=cisco.com@...>
Sent: Wednesday, June 24, 2020 9:28 AM
To: joel.halpern@... <joel.halpern@...>
Cc: tsc@... <tsc@...>
Subject: Re: [tsc] Absence
 
Thanks for letting us know :)

Ed

On Jun 24, 2020, at 10:12 AM, Joel Halpern via lists.fd.io <joel.halpern=ericsson.com@...> wrote:

I have a conflicting call tomorrow that I can not reschedule.  Sorry.
Yours,
Joel

Re: Absence

Edward Warnicke
 

Thanks for letting us know :)

Ed

On Jun 24, 2020, at 10:12 AM, Joel Halpern via lists.fd.io <joel.halpern=ericsson.com@...> wrote:

I have a conflicting call tomorrow that I can not reschedule.  Sorry.
Yours,
Joel

Absence

Joel Halpern
 

I have a conflicting call tomorrow that I can not reschedule.  Sorry.

Yours,

Joel

FINAL REMINDER: Register for the Virtual LFN Developer & Testing Forum (June 22-25)

Brandon Wick
 

LFN Technical Community:

This is a reminder that the Virtual LFN Developer & Testing Forum will take place next week, June 22-25. View the event schedule and wiki planning page

As the principal technical event for the LF Networking projects, this bi-annual gathering provides the opportunity for each participating community to advance their project roadmaps and explore cross-community collaboration and integration points. The CNTT/OPNFV, ONAP, OpenDaylight, and Tungsten Fabric communities will be participating. Registration is required and we encourage you to register right away. Please email lfn-events@... if you have any questions. Thank you!

Best, 

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960

Re: fdio/release repository on packagecloud now contains 19900 with some odd artifacts

Edward Warnicke
 

Done

Ed

On Thu, Jun 18, 2020 at 9:42 AM Dave Wallace (dwallace) <dwallace@...> wrote:

Luca,

 

Thank you for the excellent write-up on our meeting!

 

@Ed Warnicke, can you please create the hicn repo on packagecloud.io (https://packagecloud/fdio/hicn)?

 

-daw-

 

From: Luca Muscariello <muscariello@...>
Sent: Thursday, June 18, 2020 2:43 AM
To: Andrew 👽 Yourtchenko <ayourtch@...>; Vanessa Valderrama <vvalderrama@...>; Dave Wallace (dwallace) <dwallace@...>; tsc@...
Cc: hicn-dev@...; cicn-dev@...; ci-management-dev@...
Subject: Re: [tsc] fdio/release repository on packagecloud now contains 19900 with some odd artifacts

 

Hi,

 

After meeting with Andrew, Dave and Vanessa, we have decided to

opt for option 4 described in this thread. Tradeoffs have been 

explained in this thread.

 

This decision requires 

- the creation of a new repo https://packagecloud/fdio/hicn;

- update to ci-management on hicn JJB to push artifacts there;

- therefore previous releases are pushed manually to 

   https://packagecloud/fdio/release  via LF tickets.

Plus:

- clean up the release repo to keep actual releases only (there is

  a ci-management patch written by Mauro for this);

- lockdown releases from JJB push;

- https://packagecloud/fdio/attic is used by ci-management to cleanup

  release/ but it may be used to cleanup fdio/hicn at stationary

  regime in the long term.

 

Action points:

- merge the ci-management cleanup job

- create new packagecloud repo

- update hicn ci-management

- lockdown release

 

Thanks

Luca

 

 

 

 

 

 

 

 

On Fri, Jan 31, 2020 at 9:51 AM Luca Muscariello <muscariello@...> wrote:

Dear tsc members,

 

(with hicn/cicn PTL's hat on)

 

The current release repo https://packagecloud.io/fdio/release contains 20214 

artifacts almost entirely from our projects.

The current binary distribution is composed of 60 deb packages and 30 rpm packages.

 

Among hicn dependencies we have the latest VPP release, currently 20.01. 

The hICN project is composed of 6 committers and we do not support multiple releases 

but just the master HEAD. 

 

Our git repo has one single master branch (w/o release branches) and releases are based 

on git tags. The branch is tagged with the latest VPP release code, i.e. v20.01 which

is pushed after the VPP project has released the new version. We start catching up

with all VPP updates during the weeks of release preparation made by Andrew.

As soon as Andrew releases the new distribution under "release/" we merge our patches and 

change git tag in the hicn repo.

 

1 - We do not publish hicn binaries under master/ as the vpp dependencies there would not be

compatible with "hicn master" which depends on "vpp stable/"

 

2 - If we publish under #stable/, we'd create as many artifacts there as currently under 

"release/" and at each release we need to update ci-management. 

 

3 - we have no need to keep all these artifacts. So we could just keep the latest 

artifacts for each hicn release for archival reasons only. We do not backport anything 

in previous releases nor we support our user base with older releases. Packagecloud has a 

REST API to manage that well.

 

4 - as an alternative we could create an independent repo for the hicn project. Still we'd 

like to delete obsolete artifacts ad in option 3.

 

*Option 1* is unfeasible because it requires our user base to have a complex configuration 

of apt repos, which BTW only works if packages are well created. This is not always the case.

 

*Option 2* does not look like a solution to reduce the number of artifacts in a release folder.

It may work in conjunction with option 3. It may work well if we also get one of our committers 

in ci-management, e.g. Mauro Sardara who's substantially contributed to ci-management already.

 

*Option 3* seems useful in general and would allow to 

 (i) keep host configuration simple, 

 (ii) keep repo size to the right size, 

 (iii) avoid  repo duplication as in 4. 

if we keep artifacts under release our user-base would be happier as it need not host upgrades.

 

*Option 4 + 3* would be ok as well.

 

Thanks for you feedback

Best

Luca

 

 

 

On Thu, Jan 30, 2020 at 7:37 PM Andrew 👽 Yourtchenko <ayourtch@...> wrote:

Dear TSC,

In the capacity of the VPP 20.01 release manager, I would like to raise your attention to the fact that the fdio/release now contains 19900 files, and the there are some invalid packages, like “honeycomb”, and “-dev”.

This was found as we started CSIT testing for VPP 20.01, and Peter Mikus has a workaround - so it doesn’t impact the schedule for the 20.01 testing. (VPP packages download fine)

However, I wanted to raise this concern.

Are some projects doing so many releases, that it results in almost 20000 files?

Thanks for consideration.

--a

Re: fdio/release repository on packagecloud now contains 19900 with some odd artifacts

Dave Wallace (dwallace) <dwallace@...>
 

Luca,

 

Thank you for the excellent write-up on our meeting!

 

@Ed Warnicke, can you please create the hicn repo on packagecloud.io (https://packagecloud/fdio/hicn)?

 

-daw-

 

From: Luca Muscariello <muscariello@...>
Sent: Thursday, June 18, 2020 2:43 AM
To: Andrew 👽 Yourtchenko <ayourtch@...>; Vanessa Valderrama <vvalderrama@...>; Dave Wallace (dwallace) <dwallace@...>; tsc@...
Cc: hicn-dev@...; cicn-dev@...; ci-management-dev@...
Subject: Re: [tsc] fdio/release repository on packagecloud now contains 19900 with some odd artifacts

 

Hi,

 

After meeting with Andrew, Dave and Vanessa, we have decided to

opt for option 4 described in this thread. Tradeoffs have been 

explained in this thread.

 

This decision requires 

- the creation of a new repo https://packagecloud/fdio/hicn;

- update to ci-management on hicn JJB to push artifacts there;

- therefore previous releases are pushed manually to 

   https://packagecloud/fdio/release  via LF tickets.

Plus:

- clean up the release repo to keep actual releases only (there is

  a ci-management patch written by Mauro for this);

- lockdown releases from JJB push;

- https://packagecloud/fdio/attic is used by ci-management to cleanup

  release/ but it may be used to cleanup fdio/hicn at stationary

  regime in the long term.

 

Action points:

- merge the ci-management cleanup job

- create new packagecloud repo

- update hicn ci-management

- lockdown release

 

Thanks

Luca

 

 

 

 

 

 

 

 

On Fri, Jan 31, 2020 at 9:51 AM Luca Muscariello <muscariello@...> wrote:

Dear tsc members,

 

(with hicn/cicn PTL's hat on)

 

The current release repo https://packagecloud.io/fdio/release contains 20214 

artifacts almost entirely from our projects.

The current binary distribution is composed of 60 deb packages and 30 rpm packages.

 

Among hicn dependencies we have the latest VPP release, currently 20.01. 

The hICN project is composed of 6 committers and we do not support multiple releases 

but just the master HEAD. 

 

Our git repo has one single master branch (w/o release branches) and releases are based 

on git tags. The branch is tagged with the latest VPP release code, i.e. v20.01 which

is pushed after the VPP project has released the new version. We start catching up

with all VPP updates during the weeks of release preparation made by Andrew.

As soon as Andrew releases the new distribution under "release/" we merge our patches and 

change git tag in the hicn repo.

 

1 - We do not publish hicn binaries under master/ as the vpp dependencies there would not be

compatible with "hicn master" which depends on "vpp stable/"

 

2 - If we publish under #stable/, we'd create as many artifacts there as currently under 

"release/" and at each release we need to update ci-management. 

 

3 - we have no need to keep all these artifacts. So we could just keep the latest 

artifacts for each hicn release for archival reasons only. We do not backport anything 

in previous releases nor we support our user base with older releases. Packagecloud has a 

REST API to manage that well.

 

4 - as an alternative we could create an independent repo for the hicn project. Still we'd 

like to delete obsolete artifacts ad in option 3.

 

*Option 1* is unfeasible because it requires our user base to have a complex configuration 

of apt repos, which BTW only works if packages are well created. This is not always the case.

 

*Option 2* does not look like a solution to reduce the number of artifacts in a release folder.

It may work in conjunction with option 3. It may work well if we also get one of our committers 

in ci-management, e.g. Mauro Sardara who's substantially contributed to ci-management already.

 

*Option 3* seems useful in general and would allow to 

 (i) keep host configuration simple, 

 (ii) keep repo size to the right size, 

 (iii) avoid  repo duplication as in 4. 

if we keep artifacts under release our user-base would be happier as it need not host upgrades.

 

*Option 4 + 3* would be ok as well.

 

Thanks for you feedback

Best

Luca

 

 

 

On Thu, Jan 30, 2020 at 7:37 PM Andrew 👽 Yourtchenko <ayourtch@...> wrote:

Dear TSC,

In the capacity of the VPP 20.01 release manager, I would like to raise your attention to the fact that the fdio/release now contains 19900 files, and the there are some invalid packages, like “honeycomb”, and “-dev”.

This was found as we started CSIT testing for VPP 20.01, and Peter Mikus has a workaround - so it doesn’t impact the schedule for the 20.01 testing. (VPP packages download fine)

However, I wanted to raise this concern.

Are some projects doing so many releases, that it results in almost 20000 files?

Thanks for consideration.

--a

Re: fdio/release repository on packagecloud now contains 19900 with some odd artifacts

Luca Muscariello
 

Hi,

After meeting with Andrew, Dave and Vanessa, we have decided to
opt for option 4 described in this thread. Tradeoffs have been 
explained in this thread.

This decision requires 
- the creation of a new repo https://packagecloud/fdio/hicn;
- update to ci-management on hicn JJB to push artifacts there;
- therefore previous releases are pushed manually to 
   https://packagecloud/fdio/release  via LF tickets.
Plus:
- clean up the release repo to keep actual releases only (there is
  a ci-management patch written by Mauro for this);
- lockdown releases from JJB push;
- https://packagecloud/fdio/attic is used by ci-management to cleanup
  release/ but it may be used to cleanup fdio/hicn at stationary
  regime in the long term.

Action points:
- merge the ci-management cleanup job
- create new packagecloud repo
- update hicn ci-management
- lockdown release

Thanks
Luca








On Fri, Jan 31, 2020 at 9:51 AM Luca Muscariello <muscariello@...> wrote:
Dear tsc members,

(with hicn/cicn PTL's hat on)

The current release repo https://packagecloud.io/fdio/release contains 20214 
artifacts almost entirely from our projects.
The current binary distribution is composed of 60 deb packages and 30 rpm packages.

Among hicn dependencies we have the latest VPP release, currently 20.01. 
The hICN project is composed of 6 committers and we do not support multiple releases 
but just the master HEAD. 

Our git repo has one single master branch (w/o release branches) and releases are based 
on git tags. The branch is tagged with the latest VPP release code, i.e. v20.01 which
is pushed after the VPP project has released the new version. We start catching up
with all VPP updates during the weeks of release preparation made by Andrew.
As soon as Andrew releases the new distribution under "release/" we merge our patches and 
change git tag in the hicn repo.

1 - We do not publish hicn binaries under master/ as the vpp dependencies there would not be
compatible with "hicn master" which depends on "vpp stable/"

2 - If we publish under #stable/, we'd create as many artifacts there as currently under 
"release/" and at each release we need to update ci-management. 

3 - we have no need to keep all these artifacts. So we could just keep the latest 
artifacts for each hicn release for archival reasons only. We do not backport anything 
in previous releases nor we support our user base with older releases. Packagecloud has a 
REST API to manage that well.

4 - as an alternative we could create an independent repo for the hicn project. Still we'd 
like to delete obsolete artifacts ad in option 3.

*Option 1* is unfeasible because it requires our user base to have a complex configuration 
of apt repos, which BTW only works if packages are well created. This is not always the case.

*Option 2* does not look like a solution to reduce the number of artifacts in a release folder.
It may work in conjunction with option 3. It may work well if we also get one of our committers 
in ci-management, e.g. Mauro Sardara who's substantially contributed to ci-management already.

*Option 3* seems useful in general and would allow to 
 (i) keep host configuration simple, 
 (ii) keep repo size to the right size, 
 (iii) avoid  repo duplication as in 4. 
if we keep artifacts under release our user-base would be happier as it need not host upgrades.

*Option 4 + 3* would be ok as well.

Thanks for you feedback
Best
Luca



On Thu, Jan 30, 2020 at 7:37 PM Andrew 👽 Yourtchenko <ayourtch@...> wrote:
Dear TSC,

In the capacity of the VPP 20.01 release manager, I would like to raise your attention to the fact that the fdio/release now contains 19900 files, and the there are some invalid packages, like “honeycomb”, and “-dev”.

This was found as we started CSIT testing for VPP 20.01, and Peter Mikus has a workaround - so it doesn’t impact the schedule for the 20.01 testing. (VPP packages download fine)

However, I wanted to raise this concern.

Are some projects doing so many releases, that it results in almost 20000 files?

Thanks for consideration.

--a

Uncle Hugo's bookstore

Joel M. Halpern <jmh@...>
 

I mentioned that this bookstore burned to the ground in Minneapolis, and was asked to send the link to the go-fund-me to folks. So here it is.

https://www.gofundme.com/f/let-us-help-save-uncle-hugo039s

For those who don't know, until it burned down Uncle Hugo's was the oldest still running independent specialty bookstore in the US.

Full information on the current state, and the owner's (Don Blyly) writeup on the event itself can be found here:
http://www.unclehugo.com/prod/index.shtml

Yours,
Joel

PS: I lived in Minneapolis for 21 years and know most of the folks involved personally.

Register Now for the Virtual LFN Developer & Testing Forum (June 22-25)

Brandon Wick
 

LFN Technical Community,

This is a reminder that the Virtual LFN Developer & Testing Forum will take place June 22-25. View the event schedule and wiki planning page

As the principal technical event for the LF Networking projects, this bi-annual gathering provides the opportunity for each participating community to advance their project roadmaps and explore cross-community collaboration and integration points. The CNTT/OPNFV, ONAP, OpenDaylight, and Tungsten Fabric communities will be participating. Registration is required and we encourage you to register right away. Please let us know directly if you have any questions or feedback. Thank you!

Best, 

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960