Agenda for Atlantic BDXR TC call 05 August 2020 15:00UTC

Agenda for Atlantic BDXR TC call 05 August 2020 15:00UTC

http://www.timeanddate.com/worldclock/fixedtime.html?iso=2020-08-05T15:00:00
  Atlantic: 10:00MSP/10:00Lima/11:00Ottawa/15:00UTC/17:00Europe


  Conferencing info



Meeting ID: 547 975 473



Join from PC, Mac, Linux, iOS or Android:

https://zoom.us/j/547975473



Or iPhone one-tap (US toll):

+14086380968,,547975473#  or +16465588656,,547975473#



Or international dial-in number (toll):

https://zoom.us/zoomconference?m=tZYVoCjT6sw0zaoKK3bbfRHUX43prdSf


  Standing items


  Review of Pacific call minutes

https://lists.oasis-open.org/archives/bdxr/202008/msg00001.html


  Review of Atlantic call minutes

https://lists.oasis-open.org/archives/bdxr/202007/msg00027.html


  Membership status review

https://www.oasis-open.org/policies-guidelines/tc-process#membership


  Voting status is determined by the following:
  existing voting members must not miss two consecutive meetings to maintain voting status
  non-voting members must attend two consecutive meetings to obtain voting status
  members formally on leave by prior request must not attend and their voting status is not impacted


  Current BDXR TC voting member list (alphabetical):



-

Todd Albers

-

Kenneth Bengtsson

-

Erlend Klakegg Bergheim

-

Ger Clancy

-

Sander Fieten

-

Philip Helger

-

Ken Holman

-

Levine Naidoo

-

Matt Vickers

-

Dennis Weddig


  SMP 2.0


  SMP 2.0 Committee Specification 02 has been approved and published:
  https://lists.oasis-open.org/archives/bdxr/202001/msg00009.html


  Status of Statements of Use:

-

Difi (OpenPEPPOL?)

-

IBM

-

Philip Helger

-

DG-DIGIT?

-

Sander Fieten

-

Business Payments Coalition

-

Efact


  Requirements:
 https://www.oasis-open.org/policies-guidelines/oasis-defined-terms-2018-05-22#dStatementUse


  Erlend will set up an SMP test server and share sample participant and service IDs.


  Kenneth has set up an SMP client and service for the BPC project. A sample participant can be tested here:

https://bpc-smp.bdxhub.com/bdxr-smp-2/urn%3Aoasis%3Anames%3Atc%3Aebcore%3Apartyid-type%3Aiso6523%3A0060%3A%3A123456789
  And there s an SMP test client here, for those implementing SMP services here:

https://bpc.bdxhub.com/smp-servicegroup-lookup.jsp  (use  retrieve from URL  if not retrievable from a BDXL service).


  Exchange Header Envelope (XHE)

Public review of XHE 1.0 COS01 has been announced and will end September 21:
  https://lists.oasis-open.org/archives/bdxr/202007/msg00023.html


  UN/CEFACT has published XHE 1.0 here:
 http://www.unece.org/tradewelcome/un-centre-for-trade-facilitation-and-e-business-uncefact/outputs/uncefacttechnicalspecifications/ummumm-index0html0.html


  BDXL


  BDXL administration API


  Proposal from Erlend:
 https://lists.oasis-open.org/archives/bdxr/201905/msg00015.html


  There have been discussions within Peppol regarding requirements for the BDXL Administration API. Sander will reach out to the involved participants to gather further requirements.


  Agreed that the updated BDXL 1.1 specification will mention the BDXL Administration API and its features for updating and maintaining BDXL records.


  Discussed that the BDXL Administration API  could  include a section for how to update a primary BDXL in a federated model.


  Steps forward:

  Map the API interface from the existing specification previously submitted to the TC (Kenneth)

Describing functionality (group)

Work on XML and JSON bindings (Sander, Dennis and Kenneth)


  Kenneth presented a map of the Peppol SML registration interface as well as a class diagram showing the data model. It was discussed that the data model for the BDXL administration API may need to be developed in parallel to the API if
  special functions such as batch updating ( grouping  participants with services) need to be supported. Diagrams used for discussions:
  https://lists.oasis-open.org/archives/bdxr/202007/msg00017.html .


  Discussed whether NAPTR records other than  U -flag records are allowed in BDXL 1.0, and whether redirect type NAPTR records can be used as a strategy Agreed that we need to advance further with the updated BDXL specification before moving
  forward with the API.


  BDXL 1.1


  Starter document received from OASIS:
 https://lists.oasis-open.org/archives/bdxr/202002/msg00015.html


  Discussed that the hostname to look up the NAPTR record (commonly done as  BASE32([SHA256 hash of participant ID])  and  B-[MD5 hash of participant ID] ) should be standardized.


  Federated BDXL


  Agreed to add a section about BDXL network federation to BDXL 1.1. Both Peppol and the Business Payment Coalition are working towards federated BDXL designs.


  BPC rationale is to create competition among several BDXL service providers, allowing network participants to freely choose among available services. All BDXL services will offer similar and compatible services.
  Requirements:
 https://lists.oasis-open.org/archives/bdxr/202006/msg00003.html


  Peppol is looking at delegating control of different participant identifier schemes to different SML services, as well as possibly separating groups of participants based on their ID. There would be an algorithm that enables APs to locate
  the appropriate SML service based on the calculation of the participant identifier. Part of the rationale is that the transactional footprint on the current SML has increased with the addition of DNSSEC, and grouping participants into different SML services
  is a strategy for distributing the load.


  Discussion paper for multiple registration services with only one DNS provider:
  https://lists.oasis-open.org/archives/bdxr/202006/msg00003.html


  Discussed that in DNS, zone changes are replicated from primary DNS to secondary DNS services through zone transfers and that the update of primary DNS services can be done using DNS Update:
  https://tools.ietf.org/html/rfc2136


  Sander and Kenneth had a meeting to come up with a proposal for an architectural drawing of a federated BDXL model within the complete 4-corner network. The outcome is shared here:
  https://lists.oasis-open.org/archives/bdxr/202007/msg00010.html


  Discussed that the BDXL specification could/should hold information about the current registrar service of a given participant, so that BDXL and registrar services can prevent unauthorized updates of participant identifiers registered through
  a different registrar service.


  Discussed to include a non-normative section describing different network policies and approached to KYC and participant registration.


  Kenneth will begin drafting an introduction for BDXL 1.1.


  TC conference call schedule



Agreed to hold weekly Atlantic meetings until further notice. Pacific calls will continue to be held biweekly and will follow the current schedule.


  Face-to-face meeting
  Should we schedule online work sessions to replace the face-to-face meeting?


  Call schedule



2020-08-04/2020-08-05

-

Pacific: 17:00MSP/17:00Lima/18:00Ottawa/22:00UTC/08:00Sydney

-

Atlantic: 10:00MSP/10:00Lima/11:00Ottawa/15:00UTC/17:00Europe

2020-08-11/2020-08-12

-

Pacific: 17:00MSP/17:00Lima/18:00Ottawa/22:00UTC/08:00Sydney

-

Atlantic: 10:00MSP/10:00Lima/11:00Ottawa/15:00UTC/17:00Europe

2020-08-18/2020-08-19

-

Pacific: 17:00MSP/17:00Lima/18:00Ottawa/22:00UTC/08:00Sydney

-

Atlantic: 10:00MSP/10:00Lima/11:00Ottawa/15:00UTC/17:00Europe

2020-08-25/2020-08-26

-

Pacific: 17:00MSP/17:00Lima/18:00Ottawa/22:00UTC/08:00Sydney

-

Atlantic: 10:00MSP/10:00Lima/11:00Ottawa/15:00UTC/17:00Europe


  Other business


  As comes forward