Finland votes "NO" for the progression of the document CD14753 Interface References and Binding, because the document does not yet reach the level of consistency and clarity required for CDs. Especially we have the following comments:

    1. Clauses 1, 6, 8, 9 -- Major editorial

      Expressions of the scope of the standard are contradictory. Review clauses 1, 6, 8, and 9 in this respect. Simple contradictions appear for example in statements about including unbinding behaviour, or node management functions that are required for federated binding behaviour. More complicated contradictions arise, when a binding is in effect and instantiation and termination of channel structures can appear. The current text usually leaves out all terminating behaviours, but allows the reader to consider the other parts of the life-cycle to be covered in total.

    2. Clauses 7.2.3 -- Technical

      The definition of binding factory is too vague. The definition should point out that the binding factory may itself be a federated entity that has local representatives at each administrative domain involved to the channel instantiation process. This is essential already in the information viewpoint, because each administrative domain is governed by policy information that has different sources. The policies under which the factory partners work contribute to the notion of environment contract.

    3. Clauses 7.2.1.,7.2.2 -- Editorial

      The clauses use terms "target object" and "target interface" inconsistently.

    4. Clause 7.2.1, 7 -- Editorial

      The term "initiator" is poorly used. It should be specified each time, which activity is initiated. The current text is unclear and unnecessarily requires that binding and unbinding must be initiated by the same object.

    5. Clauses 7.2.4., 7.2.5 and 8.5., 8.6. vs. 9 -- Technical

      In order to allow implementation of the liaison/binding that is preserved over a period when a channel is reconfigured (due to optimisation, relocation, resource saving during low traffic) the concept of contract should be introduced in the computational viewpoint.

      If the interface reference is used to support the necessary data, the information viewpoint should reflect the state changes between interface references that serve as channel end-points and interface references that are dormant.

    6. Clause 8 -- Technical

      At least the information viewpoint should capture the work done in the group of QoS in ODP.

      Additional statements for the definition of contract can be gathered from the QoS document. The last comment of this paper opens discussion of the positioning of QoS negotiation process in the binding framework.

    7. Clauses 8.1., 8.4 -- Editorial

      The distinction between environment contract and interface reference is difficult to understand from this document.

    8. Clause 8.4 -- Technical/editorial

      There should be a note explaining that the channel templates can be stored to a distributed repository, where each repository component can have a private, platform-specific sub-template. The binding factory is then able to derive at each domain a suitable sub-template for the federated instantiation process. A reference to the type repository function standard is possible.

    9. Clause 8.4. -- Technical

      The definition of structures is claimed to be abstract. It is also claimed that this abstract definition is then mapped to the corresponding CORBA structures in Annex A. However, this definition contains concrete termination characters like ";" and a finite list of key words. The definition of structures should be consistently abstract or more concrete.

    10. Clause 9.2. Figure 2 -- Editorial

      The figure does not conform with the text any more.

    11. Clauses 8 and 9 -- Technical

      The text does not define to which extent the channel is able to evolve during the established binding.

      • Is it possible that some of the target interfaces/objects are relocated?
      • Is is possible that the platform of some object is changed because of relocation?
      • Is it possible to change the protocol because of optimisation after relocation?
      • Is it possible to change the agreed QoS values after the channel creation?
      • Is it allowed to have different QoS values after the channel has been reconfigured for other reasons?
      The contracts should be dynamic in respect to these aspects. Current standards should support for example mobile communication and integration of fixed (fast) and mobile (slow) transport media. The mechanisms of fault tolerance also require such dynamicity.