[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Agenda for BDXR TC call 07 October 2020 15:00UTC - Voting meeting
Agenda for BDXR TC call 07 October 2020 15:00UTC
http://www.timeanddate.com/worldclock/fixedtime.html?iso=2020-10-07T15:00:00 Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe Conferencing info
Meeting ID: 547 975 473 Passcode: oasis Join from PC, Mac, Linux, iOS or Android: https://us02web.zoom.us/j/547975473?pwd=bjVvdDhDcEZXZ3R3cldRYkpuQU13Zz09 Or iPhone one-tap (US toll): +13462487799,,547975473#,,,,,,0#,,130346# US (Houston) +16465588656,,547975473#,,,,,,0#,,130346# US (New York) Or international dial-in number (toll): https://us02web.zoom.us/u/kchtpYJm7L Meeting ID: 547 975 473 Passcode: 130346 Standing items
Review of Pacific call minutes
https://lists.oasis-open.org/archives/bdxr/202010/msg00008.html Review of Atlantic call minutes
https://lists.oasis-open.org/archives/bdxr/202009/msg00009.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
-
Sander Fieten
-
Philip Helger
-
Ken Holman
-
Levine Naidoo
-
Dennis Weddig Members gaining voting status after this meeting: -
Erlend Klakegg Bergheim Members losing voting status after this meeting: -
Todd Albers SMP 2.0
Statements of Use received:
-
IBM:
https://lists.oasis-open.org/archives/bdxr/202010/msg00001.html
-
Philip Helger:
https://lists.oasis-open.org/archives/bdxr/202010/msg00003.html
-
Federal Reserve Bank of Minneapolis:
https://lists.oasis-open.org/archives/bdxr/202010/msg00004.html
-
Efact:
https://lists.oasis-open.org/archives/bdxr/202010/msg00000.html Does the TC accept the above Statements of Use for Service Metadata Publishing (SMP) Version 2.0 Committee Specification 02 approved on January 16, 2020? All Statements of Use were approved by the Pacific call. Pending Atlantic call approval. Does the TC approve the Chair requesting that TC Administration hold a Special Majority Vote to approve submitting Service Metadata Publishing (SMP) Version 2.0 Committee Specification 02 at
https://docs.oasis-open.org/bdxr/bdx-smp/v2.0/cs02/bdx-smp-v2.0-cs02.zip as a Candidate OASIS Standard? The motion was made by Kenneth. Seconded by Levine. Approved by the Pacific call, pending Atlantic call approval. Exchange Header Envelope (XHE)
Does the TC approve Exchange Header Envelope (XHE) Version 1.0 located in the folder labelled âoasisâ of the archive contained in
https://www.oasis-open.org/committees/document.php?document_id=67799&wg_abbrev=bdxr as a Committee Specification Draft and designate the XML version of the specification as authoritative, and furthermore approve submitting the Committee Specification Draft
for a 15-day public review? The motion was made by Kenneth. Seconded by Levine. Approved by the Pacific call, pending Atlantic call approval. 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:
1)
Map the API interface from the existing specification previously submitted to the TC (Kenneth)
2)
Describing functionality (group)
3)
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. It was agreed at the August 12 TC meeting that the introductory sentence in section 2.2 (normative), which states that âBecause the goal is to find URLs, the NAPTR RR with âUâ value in its Flags field (U-NAPTR)â narrows the scope of U-NAPTR
records in the specification to those with âUâ-flags, and that âU-NAPTRâ elsewhere in the specification consequently refers to only those NAPTR records with âUâ-flags. 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 meetings until further notice. Face-to-face meeting
Should we schedule online work sessions to replace the face-to-face meeting? Call schedule
2020-10-06/2020-10-07 -
Pacific: 17:00MSP/00:00Europe/18:00Ottawa/22:00UTC/09:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe 2020-10-13/2020-10-14 -
Pacific: 17:00MSP/00:00Europe/18:00Ottawa/22:00UTC/09:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe 2020-10-20/2020-10-21 -
Pacific: 17:00MSP/00:00Europe/18:00Ottawa/22:00UTC/09:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/15:00UTC/17:00Europe 2020-10-27/2020-10-28 -
Pacific: 17:00MSP/23:00Europe/18:00Ottawa/22:00UTC/09:00Sydney -
Atlantic:
11:00MSP/12:00Ottawa/16:00UTC/17:00Europe 2020-11-03/2020-11-04 -
Pacific: 17:00MSP/00:00Europe/18:00Ottawa/23:00UTC/10:00Sydney -
Atlantic:
10:00MSP/11:00Ottawa/16:00UTC/17:00Europe 2020-11-10/2020-11-11 -
Pacific: 17:00MSP/00:00Europe/18:00Ottawa/23:00UTC/10:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/16:00UTC/17:00Europe 2020-11-17/2020-11-18 -
Pacific: 17:00MSP/00:00Europe/18:00Ottawa/23:00UTC/10:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/16:00UTC/17:00Europe 2020-11-24/2020-11-25 -
Pacific: 17:00MSP/00:00Europe/18:00Ottawa/23:00UTC/10:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/16:00UTC/17:00Europe 2020-12-01/2020-12-02 -
Pacific: 17:00MSP/00:00Europe/18:00Ottawa/23:00UTC/10:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/16:00UTC/17:00Europe 2020-12-08/2020-12-09 -
Pacific: 17:00MSP/00:00Europe/18:00Ottawa/23:00UTC/10:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/16:00UTC/17:00Europe 2020-12-15/2020-12-16 -
Pacific: 17:00MSP/00:00Europe/18:00Ottawa/23:00UTC/10:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/16:00UTC/17:00Europe 2020-12-22/2020-12-23 -
Pacific: 17:00MSP/00:00Europe/18:00Ottawa/23:00UTC/10:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/16:00UTC/17:00Europe 2020-12-29/2020-12-30 -
Pacific: 17:00MSP/00:00Europe/18:00Ottawa/23:00UTC/10:00Sydney -
Atlantic: 10:00MSP/11:00Ottawa/16:00UTC/17:00Europe Other business
As comes forward |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]