Minutes - Meeting 2 - Jun 11 2020

Attending
- Jari Hirvonen (Fingrid – Convener of group)
- Mika Niemi (eSett)
- Magnus Bosson (SvK)
- Kristian Skov (ENDK)
- Kristian Bjørklund (RSC - member of CSSg)
- Morten Simonsen (Statnett - Secretary of group, part of CSSg)


•	Mika told about eSett and the various challenges ahead
	* Many message (36M/yr) -> 
		- We think ECP/EDX should handle it, but expect endpoint at eSett to be the weakest point
		- The GUI of the ECP/EDX must be improved
	* Long-term goal (unofficially) is to have all message on ECP, perhaps within 5 yrs
	* High demands on availability (99.86%) -> Could be necessary to establish their own broker.
		In favor of eSett-broker:
			- All messages go through one single broker, instead of mulitiple, easier to find missing messages
			- Assuming this broker must have higher uptime than others, it easier to that with one broker than many
		Against eSett-broker:
			- We must roll out Central Message Path to all Marketplayers. Current Central Message path implementation in ECP cannot automatically add new endpoints (or handle changes) to the path. This must be fixed.
			- An extra broker must be establishsed which is not essential at this point
			- Special flow for eSett, in some sense easier if everything in NEM follow the same standard			
		Decision: Postpone the decision
	* Many different types of messages are sent from eSett to all the various Market Players, but what standard to use for specifying the ECP Message Type?
		- Decision is that it is mandatory to have a unique (in NEM) prefix to the message type. Suggestions: NBS- or NBS-ESETT-. If we have a unique prefix, we can later use the Central Message Path concept if we like.
		- Another decision is to recommend a postfix which clearly identifies the document type (perhaps taken from the CIM-document)
	* eSett need to be able to send 30MB+ documents. That requires EDX + Message slicing. That *may*, in turn, require that Market Players must use fileshare (fssf) on their EDX upon reception.
		- eSett must investigate this, and probably provide a special guide for the Market Players for this?
	* Comment from Morten S: EDX Service can still be a valueable concept, when used to divide the eSett-business into logical units for which some (but not all) Market Players are interetsted in some of those units.
•	Synchronizing Fingrid/Statnett in production
	* Most like something which will happen in early fall 2020. The number one reason to synchronize is eSett.
•	Status from each TSO/RSC (in particular upgrade of RSC-network)
	* SvK: Trying to install a test-network. They do not have a root-CA yet, but use some self-signed by Filip for testing. Morten S will provide some help. Think they might have something up and running during summer 2020.
	* NRSC: In the process of moving prodcution ECP/EDX onto a new hosting platform. They want to use DNS instead of IP (for endpoints to connect to CD/Broker), but there are some challenges. Fall 2020?
	* FG: No particular issue, but must upgrade to 4.6.1 in production before sync with Statnett. Fall 2020
	* ENDK: Explained the issue where Nasdaq-endpoint got the endpoint-code of ENDK. Discussion around the how that should have been prevented, since it that particular case many things failed. 
	
-----
Not time to cover these:
•	Status from CSSg
•	Particular problems we should prioritize with the development of ECP? 
•	If we have time, maybe introduce the EDX-concept DOMAIN & SERVICE – we need to discuss the use of it later