Issues for Mailing list of the PIM & PSM For Software Radio Finalization Task Force

List of Open Issues. Other options: All Issues; Closed Issues.

(red=unresolved; yellow=pending Board vote)

Issue 1. Unable to retrieve a specific provided interface for a port
(PortSupplier getPort operation)
Proposed Solution: Add additional parameter to the getPort operation to
qualify which provided interface object reference is needed from the
getPort operation.
Rationale: A provided port can have multiple interfaces

Resolution:
As part of the resolution to issue 7953, a constraint has been added that states each port has a set of 1 required and 1 provided interface at most.  This invalidates issue 7578.  Hence, issue 7578 should be closed with no change required to the specification based on the resolution for issue 7953.
Revised Text:
N/A
Disposition:	Closed, no change

 Obtaining resource provided interfaces during deployment. Does it
make sense to retrieve a set of provided interfaces from a resource?
Proposed Solution: Modify getPort operation to return a list back or add a
new operation.
Rationale: Efficiency could be achieved by returning all the provided or
the requested interfaces from a resource thus eliminating multiple calls to
a resource.

 DisconnectPort operation does not indicate, which required port
the disconnection is for.
Proposed Solution: add requiredPort name parameter to disconnectPort
operation.
Rationale: This is necessary unless connection id is unique at the resource
level not at the required port level.Connection ID and required port name
are parameters for the connectPort operations.

 Circular Dependency between CF and File Services IDL Name space.
This got introduced from the errata.
Proposed Solution: file Service becomes part of the CF name space.

 Comm channel data descriptors need to be defined in the annex
(currently TBD)
Rationale: Lack of XML definition

Discussion:
·	Jerry will take care of them after he is done with the OCL issues. 
·	Now that the properties resolution is in place, it will be easier to handle this issue
·	Tansu will provide a resolution for issue 7703 adding sections Databus, Interconnect etc. This needs to be done before the XML elements. 

Disposition:	Deferred
1.	Remove CharacteristicProperty from Communication Equipment. Use the definitions that are in the Properties section 8.1.3. 
2.	Make Channel an extension of Class, not a specialization
3.	Make Channel attributes CharacteristicProperty types.
4.	The Properties XML is modified to make the locallyManaged and capabilityModel elements optional so they can be used by CommEquipment definition.
5.	Update the rose model based upon changes below.

Specify which interfaces are mandatory, and which ports are
required for components
Rationale: Consistency and standardization of components, improves waveform
portability of code and XML descriptors.

Discussion:
October 7, 2004 FTF Telecon:
Jerry's suggestion for how to tackle the solution for this issue:  Treat it as a base component definition.  E.g. for an audio component, at a minimum, it should have these types of features.  If audio or serial should have a required control or data port, we should specify that in the constraint section
Tansu Demirbilek provided the resolution included below, and this issue was included in the 1st ballot. However, there was some discussion on the scope of the provided resolution and the issue was pulled from the 1st ballot. 
March 10, 2005 Telecon:
Jerry:  Not sure if there is any more to be done here.  Perhaps Tansu's already submitted resolution is fine.  Tansu will touch base with Jerry during 2nd FTF.
Revised Text:
In Section 9.3.1.2.1, (ConnectionlessLink Component), pg 211, replace the following sentence in the Constraints section: 
 "ConnectionlessLinkComponent shall provide at least one bi-directional DataControl port."
with "ConnectionlessLinkComponent shall provide one ControlPort, at least one input DataControl port and at least one output DataControl port." 

In Section 9.3.1.3.1, (AckConnectionlessLink Component), pg 214, replace the following sentence in the Constraints section: 
 "AckConnectionlessLinkComponent shall provide at least one bi-directional DataControl port."
with "AckConnectionlessLinkComponent shall provide one ControlPort, at least one input DataControl port and at least one output DataControl port."
 
In Section 9.3.1.4.2, (ConnectionLinkComponent), pg 220, replace the following sentence in the Constraints section: 
 "ConnectionLinkComponent shall provide at least one bi-directional DataControl port."
with "ConnectionLinkComponent shall provide one ControlPort and at least one StreamPort."  

In Section 9.3.2.3, (MediumAccessController Component), pg 226, replace the following sentence in the Constraints section:  
 "The MediumAccessController Component shall provide at least one DataControl port."
with "MediumAccessController component shall provide one ControlPort, at least one input DataControl port and at least one output DataControl port."
 
In Section 9.5.2.1.1, (ModemComponent), pg 236, create a Constrains section and add this statement: 
 "ModemComponent shall provide one ControlPort and at least one DataControlPort or DataPort. All of the device definitions shown in Figure 9-74 that specialize ModemComponent shall provide these ports at a minimum."
  
In Section 9.5.2.2.1, (ModemComponent), pg 242, create a Constrains section and add this statement: 
 "RFIFComponent shall provide one ControlPort and at least one DataControlPort or DataPort. All of the device definitions shown in Figure 9-77 that specialize RFIFComponent shall provide these ports at a minimum."

Disposition:	Deferred                                                                                                                          
Discussion:
Not sure if there is any more to be done here.  Perhaps Tansu's already submitted resolution is fine.  Tansu will touch base with Jerry during 2nd FTF.
2nd FTF will include the changes included with this issue and the disposition. 

Disposition:	Deferred   Discussion:
No longer an issue.  What is imporptant are the interfaces, and the components are there for references.  We are only interested in platform service components being standardized and not the WFs. This issue has been overcome by events, In the Data Link Layer Facilities volume spec, DLL component definitions have constraints for the types of ports that needs to be supported.

Break the spec into multiple volumes
Proposed solution: UML Profile for SWRadio and Facilities into a separate
document of the specification
Rationale: Easier to understand, separation of concepts

Discussion:
The group (Jerry, Neli, Tansu) that the resolution for this issue (breaking up the spec into multiple volumes) does belong to this FTF.  The group agreed to 3 volumes:   PIM (UML Profile), Radio Facilities, and PSM
The group also agreed to wait until after the resolution to issue 7742 to take care of this break up.
Based on resolution for 8251 and 8259, we'll decide how to break up the spec.
Disposition:	Deferred
The issue is deferred to the follow-on R/FTF, since FTF #2 ran out of time.

Lack of OCL Statements for constraints.
Proposed Solution: Replace text constraint descriptions with OCL.
Rationale: formal language for expressing constraints and recommended
mechanism within OMG.

Discussion:
The FTF would like to get comments from the AB about the amount of OCL currently in the spec. This issue is related to issue 7742. The 2nd FTF will continue the progress based on the comments from the AB.
Disposition:	Deferred

Proposed Solution: For all CORBA Modules (e.g., CF, PortTypes,
StandardEvents, FileServices, etc.) replace IDL in the these files with
include statements.
Rationale: Definitions are based upon existing files and not duplicated,
which can lead to inconsistencies in IDL files.

What is the association or behavior in
regards to resource operations and provides and uses ports?
Proposed Solution: Association is for the uses and provides ports and no
effect on resource operations.
Rationale: Consistent behavior of resource components.

Keep text constraint descriptions in addition to OCL as OCL is hard to read

Discussion:
This is not an issue but a submitted comment on issue #7586.  It was added as an issue by mistake by the OMG. Neli has asked OMG to remove it from the issues list.
Revised Text:
N/A
Disposition:	Closed, no change

Simple primitive types are used in the specification but not
defined. Examples are the types used in Physical Layer Facilities types
(9.5) and the SimpleProperty (8.1.2.11) (e.g., double, single,  and float,
etc. ).


Recommendation:
In section 8.1.1 Base Types, section 8.1.1.7 PropertyValue add a Types
section that captures the primitive data types for boolean, char, double,
float, short, long, objtref, octet, string,
ulong, ushort and sequence of these types that are not defined UML. Octet
and OctetSequence are already defined in section 8.1.1