proposal to add two leafs for openconfig-alarms.yang

we apply for adding two leafs （alarm-location, service-affecting）into the grouping alarm state as following:

grouping alarm-state { description "Operational state data for device alarms";

leaf id {
  type string;
  description
    "Unique ID for the alarm -- this will not be a
    configurable parameter on many implementations";
}

...

leaf alarm-location {
  type string;
  description
    "System-supplied description of the location of the component within the system for the alarms. This could be chassis name. For component types that have an explicit slot-id attribute, such as linecards, the system should populate the more specific slot-id.";
}

leaf service-affecting {
  type boolean;
  description
    "if ture, it indicates the service will be affected by the in-active alarms, such as LOS.
     if false, it indicates the service will not be affected but the system is running in risk.";
}

}

 In the current version，leaf resource indicates the fault item, such as component, interface, logical channel. furthermore , we also want to know the location of the fault item. it will be very helpful for operation engineer or SDN controller to check more within the linecard under alarm.

for example, when we get a alarm that indicates the Ethernet channel has loss packets, we want to know which linecard is abnormal quickly. so we think both alarm resource and location are important for network operation and maintenance.

for the leaf service-affecting, it can be a straightforward method to tell us whether the faults affects the services or not.  

both two leaf is commonly used in optical transport equipments, we feel it is necessary to add these two leafs into alarm.yang

openconfig / public

proposal to add two leafs for openconfig-alarms.yang #199