20160217 - Meeting minutes, Wednesday February 17th 2016 - Task force SML/SMP

 

Estimated: 15:00 to 16:00 CET.

Performed: 15:00 to 16:10 CET

Agenda

  1. Introduction
    1. Approval of previous meeting minutes
    2. Approval of the agenda
    3. Resource allocation
  2. Business analysis
    1. Review of the document and feedback
  3. Integration of the SMP with OpenNCP
    1. Review of the cache mechanism design proposed by Joao Cunha and feedback
  4. AOB
    1. 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.
------------------------------------------------------------------------------------------------

Adrien FERIAL

Yves ADAM

Hugo Soares

Joao Cunha

Massimiliano Masi

Uwe Roth

YacoubouY

michele.foucart

Support documents

See also section /wiki/spaces/ncp/pages/72417295 where all support document are published:

Meeting Notes

  1. Introduction
    1. Approval of previous meeting minutes
    2. Approval of the agenda
    3. Resources allocation
      1. Mainly Jerôme, but also Yacou an Marco. Resource allocation will also depend on the workload
  2. Business analysis
    1. Review of the document and feedback
      1. Yves has received very detailed and constructive feedback which is already integrated in the document
      2. 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"
        1. 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).
          1. Discrepency between Oasis specs and endpointReference => Yves ADAM will change the documents. The implementation that is being tested in not the correct one.
        2. 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.
          1. Is the admin SMP calling the REST service supposed to provide the complete service collection?
          2. Adrien FERIAL: only when you create the SMP
        3. 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.
          1. 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.
          2. 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?
            1. Adrien FERIAL: This risk already exists in the current situation. This risk is accepted and has to be mitigated.
            2. Massimiliano Masi: Could a malicious user pollute the cash by pushing transactions to fail?
              1. 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.
        4. Cf. point 14 above, §3.5.2.2: Is DIGIT responsible to for the System Admin of all SMPs?
          1. Joao refers to 3.5.2.2 p53
            1. DIGIT is only responsible for the central SMP. If system uses local SMP they will be admin and responsible for their own SMP
            2. The second sentence needs to be adapted
        5. §3.4.2 : PutServiceGroup service specifies ALL ServiceMetadataReference at once (not possible to add one or several to the existing set).
          1. Already discussed
        6. §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).
          1. 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
        7. H. §3.4.2 : (PutServiceGroup service) Should there be a redirect column in the configuration database.
          1. 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.
          2. 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
          3. Where is the identifier is stored? Doc REST services => Redefinition of xsd. Addition of 2 fields
          4. Adrien FERIAL:
            1. it looks from the discussions that the document should be more specific to make the distinction between the GET and the PUT
            2. the flow has also to be made more clear
            3. Yves ADAM will also include some examples as illustration
        8. §3.4.2 : (PutServiceGroup service) Should there be a redirect column in the configuration database.
          1. There is no additional service group redirect table. Yves ADAM will update the document since the question is not relevant anymore
        9. §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"?
          1. Different perspectives step 4 of the user story. Yves ADAM will update according to Joao's comment
  3. Integration of the SMP with OpenNCP
    1. Review of the cache mechanism design proposed by Joao Cunha and feedback
      1. Joao Cunha has investigated and has already proposed a solution, see document published on the task force page.
        1. Need to be updated because the current way of working is unpractical in operations. We have an issue with the OpenNCP architecture.
        2. Suggestion from Massimiliano Masi to put this info in the cache and not in the database
        3. S problem of distributed cache mechanism (used by several tools eg Terracotta,...) and cache consistency.
        4. michele.foucart will put this point to the agenda of the Technical committee to be discussed. Attention point: there is a dependency with the SMP/SML deadline, especially for the Connectathon
  4. AOB
    1. Next meeting 2pm
    2. Actions:
      1. DIGIT will provide a more detailed use case regarding the services to be called by the NCPs
      2. 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
      3. Massimiliano Masi: will try to produce a transaction problem with malicious user