he TMN608 Interface Information Agreement details a protocol neutral model using UML that includes: Interface problem Interface information requirement Set of interface information use cases Information exchanged over the interface needs to be structured based on the TMF 045 document on common information structure (CIS). CIS details how data attributes need to be structured in protocol neutral expressions for business and information agreements. NamingAttributes_T structure is used: As a naming scheme between the NMS and EMS interface To define identifiers for managed entities To represent the containment relationship between objects While the interface follows a NamingAttributes_T structure, the information model objects are defined as name-value pairs. For example when the object is "Example" and both name and value is a string. Then the representation is: struct Example_T { string name ; string value; TMF 608 has multiple supporting documents (SD) for details on information exchange. Some of the most important supporting documents are discussed next. Object naming: These naming rules will add consistency to the object names used by different vendors in designing the EML-NML interface. Some of the gen- eral rules and semantics for equipment naming discussed in "SD1-25_objectNam- ing" are: 1. A name-value pair is used to identify a component and has name=value syntax. 2. Component hierarchy will be separated by "I". That is an entry "Shelf-12/ Slot-1/Card-0" and means that the Card-0 is placed in "Slot-1" that is in "Shelf-12." The left most thus represents the highest level of containment. 3. The equipment-holder class is identified before the circuit packs. 4. "Equipment" is used to identify the circuit-pack and there is a separate name associated with physical and logical components. Document on attribute value change (AVC) notification or a state change (SC) notification: Every physical component has a state and a set of attributes associated to it. For example a link state would be busy, in service trouble