In order to enable an iCal export link, your account needs to have an API key created. This key enables other applications to access data from within Indico even when you are neither using nor logged into the Indico system yourself with the link provided. Once created, you can manage your key at any time by going to 'My Profile' and looking under the tab entitled 'HTTP API'. Further information about HTTP API keys can be found in the Indico documentation.

I have read and understood the above.

Additionally to having an API key associated with your account, exporting private event information requires the usage of a persistent signature. This enables API URLs which do not expire after a few minutes so while the setting is active, anyone in possession of the link provided can access the information. Due to this, it is extremely important that you keep these links private and for your use only. If you think someone else may have acquired access to a link using this key in the future, you must immediately create a new key pair on the 'My Profile' page under the 'HTTP API' and update the iCalendar links afterwards.

Introduction :
Discussion about agenda.
DaveK to present the status to the GDB on Wednesday and a HepiX talk at KEK.

Discussion about GGUS ticket https://ggus.eu/?mode=ticket_info&ticket_id=129946
--> Possibly need to involve Janet also - offline, as they cannot access the GGUS system
--> We cannot access the Geant ticketing system and they cannot access GGUS
People unanimously happy with the agenda

Actions : None
Minutes : None to review

(Francesco returns and takes over note-taking)

Round-table updates:

CERN (Edoardo M.): There was an action on the AGILE infrastructure team to give out IPV6-ready Centos7 VMs with a ready-to-go AAAA DNS record and a corresponding firewall access entry.

A problem was found: The infrastructure reuses MAC addresses. Stale entries in the neighbour discovery table confuse CERN Brocade routers (which serve as default gateways for the VMs). The current workaround is clearing the ND table. Another possible workaround is refrain from recycling MAC addresses at least for one day.

A case for this issue is open with Brocade. Details will of course be added to the Knowledge Base.

CERN is also in the process of implementing/adding the DHCP relay option forwarding in all routers.

RAL (Catalin C.): SQUID service started 2 months ago. XROOTD redirector set up at CMS's request. The FTS, BDII and Frontier services have to be converted to dual-stack: asking if there any bad experiences reported.

None are known around the table.

About ARC-CE, Bruno reports that there are problems: ARC will try to use Link-Local addresses if IPv6 is enabled and will not fall back to IPv4.

The issue has been reported to ARC developers, but they seem to have had no time to address this yet.

About ARGUS: Raul should have experience and know the details.

VO-Boxes: No problems according to Costin.

Firewalls at RAL are still IPv4-only and need an upgrade.

Martin B. comments on what may be the most viable next steps for RAL.

T1-to-site link uses a separate 10 Gb/s link for IPv6. Can be upgraded to

40 Gb/s when needed.

LHCb (Raja N.): Nothing new. apart from the SARA problem (see above). A consequence is that SARA had to address a number of firewall issues.

Jobs could be successfully submitted to IPv6-only worker nodes @Brunel, but they failed on *dual-stack* worker nodes. Weird.

A new version of Condor will be installed on the testbed to see if it cures this problem.

A CMS-internal survey was conducted: a PDF report and a Twiki link are posted to the meeting Agenda page.

All information reported was collected by contacting the individual sites directly. Easy channels should be available to allow sites to get information about IPv6.

Dave K: There seem to be more sites in 'green' status than Alice.

"It could be worse".

INFN (Francesco P.): No new sites joined IPv6 over the summer. This may need a wake-up call specifically for Tier-2 sites. Still unable to lead this process from Milan: Milan T2 management (Atlas) doesn't want to risk downtime for this purpose.

May try Turin (Alice site), which is close enough.

Currently organising an IPv6 session at INFN security workshop on November 14th.

Do we know whether Nikhef (or SARA) really went to 100% dual stack by end of July ? There needs to be a way of confirming these milestones, possibly from the experiments' viewpoint.

Based on the current status, a list of sites that need to report on their status will be reported to the GDB on Wednesday.

Action on Raja N. to produce a comprehensive status summary table for LHCb.

Actually, all experiments do collect and could/should report on the IPv6 reachability.

Should a common table (or other) format to report information be agreed upon ?

[But ATLAS is currently not represented at the meeting].

Francesco P: A collection of IP names, with role (and size of served storage where applicable) would allow to automate the procedure across the board. Automated procedures are the only way to guarantee sustainability.