ls 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, active, and SO forth, Fundamentals of EMS, NMS and OSS/BSS and the state is different from the attributes like congestion level or number of con- nections. When the state of a component changes it is notified using SC notifica- tion and a change in any of the attributes will be notified from the EML to NML interface using an AVC 