Estimated: 15:00 to 16:00 CET.
Performed: 15:00 to 16:10 CET
Agenda
- Introduction
- Approval of previous meeting minutes
- Approval of the agenda
- Resource allocation
- Business analysis
- Review of the document and feedback
- Integration of the SMP with OpenNCP
- Review of the cache mechanism design proposed by Joao Cunha and feedback
- AOB
- Next meeting
Location
- AdobeConnect:
http://ec-wacs.adobeconnect.com/openncp/
Room Passcode: markus.kalliola or michele.foucart
------------------------------------------------------------------------------------------------
If you have never attended an Adobe Connect meeting before:
Test your connection: http://ec-wacs.adobeconnect.com/common/help/en/support/meeting_test.htm
Get a quick overview: http://www.adobe.com/products/adobeconnect.html
Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.
------------------------------------------------------------------------------------------------
Participants
- Introduction
- Approval of previous meeting minutes
- Approval of the agenda
- Resources allocation
- Mainly Jerôme, but also Yacou an Marco. Resource allocation will also depend on the workload
- Business analysis
- Review of the document and feedback
- Yves has received very detailed and constructive feedback which is already integrated in the document
- Yves has additional questions that need to be raised to the task force members => See reference document "Conf call feb 17 2016 - discussion on SMP BA"
- Cf. point 4 above (§3.2.1.4) : it seems that the existing implementation deviates from the specification : implementation uses “endpointReference” tag in XML instead of “EndpointURI“ specified in http://docs.oasis-open.org/bdxr/bdx-smp/v1.0/cs01/bdx-smp-v1.0-cs01.html (§2.3.4.2).
- Discrepency between Oasis specs and endpointReference => Yves ADAM will change the documents. The implementation that is being tested in not the correct one.
- p24: REST service supposed to provide all service metadata. Following Joao Cunha's understanding, the admin SMP is the one responsible to create the service group for a specific country, with country identifier...then responsibility of the service group to create the metadata => Yves ADAM confirms that this is correct.
- Is the admin SMP calling the REST service supposed to provide the complete service collection?
- Adrien FERIAL: only when you create the SMP
- Cf. point 8.d above, §3.4.4: to discuss at technical level: Service “PutSignedServiceMetadata” is unfortunately not completely safe since it involves distributed updates outside ad hoc transactional context that might end up in some inconsistent state.
- p32: The system should try to roll back, but it might not be able to finalize the roll-back. The service can be called multiple times with the same information (until it works) to obtain a final consistent state.
- If one of the update fail, you need to call the SML to go back to a consistent situation. In the roll-back fails, the configuration is becoming inconsistent. This situation is unlikely to happen. Is this a real issue?
- Adrien FERIAL: This risk already exists in the current situation. This risk is accepted and has to be mitigated.
- Massimiliano Masi: Could a malicious user pollute the cash by pushing transactions to fail?
- According to Adrien FERIAL, in the worst case scenario, there will be a record of the participant but with not actualized data. only one end point is registered in the DNS.
- Massimiliano Masi will try to to find a case where it fails
- According to Adrien FERIAL, in the worst case scenario, there will be a record of the participant but with not actualized data. only one end point is registered in the DNS.
- Cf. point 14 above, §3.5.2.2: Is DIGIT responsible to for the System Admin of all SMPs?
- Joao refers to 3.5.2.2 p53
- DIGIT is only responsible for the central SMP. If system uses local SMP they will be admin and responsible for their own SMP
- The second sentence needs to be adapted
- §3.4.2 : PutServiceGroup service specifies ALL ServiceMetadataReference at once (not possible to add one or several to the existing set).
- Already discussed
- §3.4.2 : (PutServiceGroup service) confirm that the client must hash the password in the XML and if confirmed, how the hash is calculated – alternative: password is sent in clear (over ssl) and hash code is calculated by the SMP).
- Decision: password is sent in clear (over ssl) and hash code is calculated by the SMP. Use password and user name. No need to modify the xsd
- H. §3.4.2 : (PutServiceGroup service) Should there be a redirect column in the configuration database.
- Use the extension or create a new sub tree in the xsd? No obligation to create the same. No issue to extend the original one from Oasis.
- Doc: creating the new NCP. In this case, we are not talking about user name (= identifier of the NCP, and that is part of the certificate) and password, we are talking about identifier of the NCP. No password
- Where is the identifier is stored? Doc REST services => Redefinition of xsd. Addition of 2 fields
- Adrien FERIAL:
- it looks from the discussions that the document should be more specific to make the distinction between the GET and the PUT
- the flow has also to be made more clear
- Yves ADAM will also include some examples as illustration
- §3.4.2 : (PutServiceGroup service) Should there be a redirect column in the configuration database.
- There is no additional service group redirect table. Yves ADAM will update the document since the question is not relevant anymore
- §3.3.4 - Comment of Joao to validate: "N/A: As User, I ask the SML to resolve the address of the SMP I need to invoke." -- shouldn't it be "ask DNS"?
- Different perspectives step 4 of the user story. Yves ADAM will update according to Joao's comment
- Review of the document and feedback
- Integration of the SMP with OpenNCP
- Review of the cache mechanism design proposed by Joao Cunha and feedback
- Joao Cunha has investigated andhas already proposed a solution, see document published on the task force page.
- Need to be updated because the current way of working is unpractical in operations. We have an issue with the OpenNCP architecture.
- Suggestion from Massimiliano Masi to put this info in the cache and not in the database
- S problem of distributed cache mechanism (used by several tools eg Terracotta,...) and cache consistency.
- michele.foucart will put this point to the agenda of the Technical committee to be discussed. Attention point: there is a depedency with the SMP/SML deadline, especially for the Connectathon
- Joao Cunha has investigated andhas already proposed a solution, see document published on the task force page.
- Review of the cache mechanism design proposed by Joao Cunha and feedback
- AOB
- Next meeting 2pm
- Actions:
- DIGIT will provide a more detailed use case regarding the services to be called by the NCPs
- DIGIT would like to have an estimate date for the problem of cache mechanism which is a pre-requisite for the integration with OpenNCP. This will be discussed in Technical Committee meeting
- Massimiliano Masi: will try to produce a transaction problem with malicious user