As a pre-release changes according to public comments and OGF20. The following changes are intended to be made for 
version 1.9.
1. Abstract and Introduction are rephrased for generic expression instead of gMarket or MCS-RUS implementation specific.
 But gMarket will be put into the added section, "example usage scenarios", as a use case. Other use cases including 
usage policing and banking service that access URF through RUS.

2. Configuration (Normative)
there will be only mandatory usage record element while leaving access control to security section. The configuration is
 extended to support attribute based configuration as well aligned with URF extension frameowrk. Although this feature 
might undermine interoperability, it is worthwhile to allow URF extension propreties to be specified but with similar 
clarification as URF extension framework. However, restriction on value as what Rosario proposed will not considered in 
the specificaiton and leaves implementations to support this feature. Again RUS has close relationship with OGF URF and 
should support what feature URF would possibly provide. 

3. Usage Record Representation will be full OGF-UR compatible.

4. Fault Framework (Normative)
    A complex Type used as a common data type for all RUS faults.
    <xsd:complexType name="RUSFaultType">
        <xsd:sequence>
            <xsd:element name="errorCode" type="xsd:string" minOccurs="1" maxOccurs="1"/>
             <xsd:element name="rusAction" type="xsd:string" minOccurs="0" maxOccurs="1" />
             <xsd:element name="recordId" type="xsd:string" maxOccurs="1" minOccurs="0" />
             <xsd:element name="description" type="xsd:string" minOccurs="0" maxOccurs="1" />
        </xsd:sequence>
       <xsd:complexType>
The definition of this general fault type gives flexibility on both operations and fine-granularity usage record fault 
handling. 

Clarification on RUS faults and corresponding errorCodes:
- RUSProcessingFault: RUS server-side internal processing error [errorCode: INTERNAL_PROCESSING_ERROR];
-RUSDuplicateFault: trying to insert usage record(s) already exist(s) [errorCode: DUPLICATE_USAGE_RECORD]
-RUSUserNotAuthorisedFault: user not authorised to pexecute rus operation (on particular usage record)[ErrorCode: 
USER_NOT_AUTHORISED]
-RUSNotExistentFault:trying to process usage records not existent [ErrorCode: USAGE_RECORD_NOT_EXISTENT]
-RUSTooComplexFault: try to process complex operation or huge amount of usage records that exceeds service's capacity [
ErrorCode:TOO_COMPLEX_OPERATION]
-RUSInputFault: trying to process operations with invalid input statement or invalid usage records [ErrorCode: 
INVALID_INPUT]

5. Operation Result 
There is no "recordIdList" element specified in version 1.7 based on following consideration:
1). RUSId not existent anymore;
2). Only error message will be returned to client;
3). the "recordIdList" element requires client to memorise recordId properties in sequence. However, it is impossible 
for client to known exact sequence when submitting a batch of usage records. 
Accordingly the operation results should provide the overall operation result as well as error information.
Therefore:
<xsd:element name="operationResult">
   <xsd:complexType>
        <xsd:sequence>
        <xsd:element name="totalProcessed" type="xsd:boolean" />
        <xsd:element name="processed" type="xsd:unsigned-long">
        <xsd:element ref="RUSDuplicateFault" minOccurs="0" maxOccurs="unbounded" />
        <xsd:element ref="RUSUserNotAuthorisedFault" minOccurs="0" maxOccurs="unbounded" />
        <xsd:element ref="RUSTooComplexFault" minOccurs="0" maxOccurs="unbounded" />
        <xsd:element ref="RUSProcessingFault" minOccurs="0" maxOccurs="unbounded" />
        <xsd:element ref="RUSInputFault" minOccurs="0" maxOccurs="unbounded" />
        <xsd:element ref="RUSNotExistentFault" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
    </xsd:complexType>
</xsd:element>

6. Service Interface Definition
The SID defined in the specification allows batch processing by default. However, the implementation might restrict this
 capacity by throwing "RUSTooComplexFault". For example, an implementation would like to restrict inserting single usage
 record per transcation. When a client submitting multiple usage records as parameter to RUS insert service interface, 
then a RUSTooComplexFault will be thrown. 

There are two new service interfaces being defined:
1). RUS::ListUsageRecordHistory
     This is the only operation that restrict the transaction on single usage record for querying record modification 
history.
     Input: RecordId
     Output: RecordHistory Element
     Faults: RUSUserNotAuthorisedFault
                RUSProcessingFault
2). RUS::ListAssignedRoles
     allows the user to obtain assigned roles relating to the user identity (i.e. userDN). The definition of this 
operation explicitly requires the implementation providing role-based access control mechanism.
     INPUT:user id;
     Output: a list of valid roles assigned to the user
     Faults: RUSProcessingFault

7. Security and Authorisation
    Clarification on Role-baed access control (RBAC) and fine-granuarlity access control over usage records. 

As OGF-RUS roadmap, the document will be available soon (by the end of June). Please give some feedbacks on 
aforementioned points.