diff --git a/apps/yms/api/src/main/java/org/onosproject/yms/ynh/YangNotificationService.java b/apps/yms/api/src/main/java/org/onosproject/yms/ynh/YangNotificationService.java
index 1beb498..a32f45f 100644
--- a/apps/yms/api/src/main/java/org/onosproject/yms/ynh/YangNotificationService.java
+++ b/apps/yms/api/src/main/java/org/onosproject/yms/ynh/YangNotificationService.java
@@ -16,17 +16,86 @@
 
 package org.onosproject.yms.ynh;
 
+import org.onosproject.event.ListenerService;
+
 /**
  * Abstraction of an entity which provides interfaces to YANG notification
- * service. YNH handles notification from the application/core and provide
- * it to the protocols.
- * <p>
+ * service. YANG notification handler receives the event notifications from
+ * application/core and provide it to the protocols.
+ *
  * NBI Protocols which can support notification delivery for application(s)
  * needs to add themselves as a listeners with YANG notification service.
- * Protocols can use YANG notification service to check if a received
+ * Also based on registered schema YMS add themselves as a listener to
+ * applications. Application sends their notification in YANG utils generated
+ * notification. YMS obtains the module/sub-module schema tree in which this
+ * notification is contained and then convert this data to an abstract tree
+ * notation (YDT) with root node as the module/sub-module node in which
+ * notification is contained. It sends the same to all the protocol who has
+ * added them as a listener as a YANG notification.
+ *
+ * Also Protocols can use YANG notification service to check if a received
  * notification should be filtered against any of their protocol specific
  * filtering mechanism.
  */
-public interface YangNotificationService {
-    //TODO
+public interface YangNotificationService
+        extends ListenerService<YangNotificationEvent,
+        YangNotificationListener> {
+
+   /*
+    *      Example of a use case of notification filtering.
+    *      The following example illustrates how to select fault events which
+    *      have severities of critical, major, or minor.  The filtering criteria
+    *      evaluation is as follows:
+    *
+    *      ((fault & severity=critical) | (fault & severity=major) | (fault &
+    *      severity=minor))
+    *
+    *           <netconf:rpc netconf:message-id="101"
+    *                   xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
+    *             <create-subscription
+    *                 xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+    *               <filter netconf:type="subtree">
+    *                 <event xmlns="http://example.com/event/1.0">
+    *                   <eventClass>fault</eventClass>
+    *                   <severity>critical</severity>
+    *                 </event>
+    *                 <event xmlns="http://example.com/event/1.0">
+    *                   <eventClass>fault</eventClass>
+    *                   <severity>major</severity>
+    *                 </event>
+    *                 <event xmlns="http://example.com/event/1.0">
+    *                   <eventClass>fault</eventClass>
+    *                   <severity>minor</severity>
+    *                 </event>
+    *               </filter>
+    *             </create-subscription>
+    *           </netconf:rpc>
+    */
+
+    /**
+     * Protocols have their own mechanism to support notification filtering
+     * or notification subscription. Depending on the protocol specification,
+     * the filtering is implemented in the protocol.
+     * The Protocol implementations are abstracted of the Schema, there are
+     * scenarios in which  they need to check if the received notification
+     * is of interest as per the schema filtering / subscription.
+     * In such scenario, protocols can create a filtering / subscription YANG
+     * data tree and use the notification service to filter the notification
+     * subject against their filter.
+     *
+     * Filters the notification subject YANG data tree, with the specified
+     * filter of the NBI protocol. If the filter does not match for the
+     * passed notification subject, null will be returned.
+     * Otherwise, the part of the subject matching the filter will be returned.
+     *
+     * @param notificationSubject YANG notification subject reported by YANG
+     *                            notification service.
+     * @param notificationFilter  Protocols data model specific notification
+     *                            filter represented in YANG data tree.
+     * @return filtered notification which passes the data model specific
+     * notification filter.
+     */
+    YangNotification getFilteredSubject(YangNotification notificationSubject,
+                                        YangNotification notificationFilter);
+
 }