Subject: notification configuration info model

From: Andy Bierman <[email-masked]>
Date: Thu, 04 May 2006 06:07:44 -0700

Hi,

Here is a simple "info model" for the notification data model.
This actually allows OR expressions to be processed correctly.

Filter Table - key: filterIndex

   filterIndex : Unsigned32 (1 .. max)

   filterDescr : string

   filterType : string ( andExpr, orExpr )

     # and-expr means all <filterPart> elements form a
     #   logical AND expression
     # or-expr means all <filterPart> elements form a
     #   logical OR expression

   filterPart : Component List (table) - key: filterPartIndex

        # nested table is just 'maxOccurs="unbounded"' in XML
        # 1 or more of these elements is needed to create a
        # meaningful filter

        filterPartIndex : Unsigned32 ( 1 .. max)

          # index is needed to avoid merge problem
          # entries will be evaluated in ascending order
          # sparse numbering is allowed

        filterPartType : string ( subtree, xpath, eventClass )

        filterPartVal : string

Profile Table - key: profileIndex

  profileIndex : Unsigned32 (1 .. max)

  profileDescr : string

  profileFilter : filterIndex

   # optional : if present then this filter entry is used
   #            A missing filter is the same as no filter

Target Table - key: targetName

  # this needs lots more work; it should be a generalized config
  # for all callhome purposes, not just agent-initiated notifications
  # this table is not used by the manager-session interface

  targetName : Name

  targetAddress : InetAddress

  targetUserName : string
 
  targetUserCredType : string

  targetUserCredential : string

--------------------------------

Example config:

<notifications>

  <filters>
    <filter>
      <filterIndex>1</filterIndex>
      <filterDescr>Filter for config or fault event types</filterDescr>
      <filterType>orExpr</filterType>
      <filterPart>
         <filterPartIndex>1</filterPartIndex>
         <filterPartType>eventClass</filterPartType>
         <filterPartVal>config</filterPartVal>
      </filterPart>
      <filterPart>
         <filterPartIndex>2</filterPartIndex>
         <filterPartType>eventClass</filterPartType>
         <filterPartVal>fault</filterPartVal>
      </filterPart>
    </filter>
   </filters>

   <profiles>
     <profile>
       <profileIndex>1</profileIndex>
       <profileDescr>Send only config and fault event classes</profileDescr>
       <profileFilter>1</profileFilter>
     </profile>
   </profiles>

</notifications>

-------------------------------------

For managers:

  <rpc>
    <start-notifications>
      <profile>1</profile>
    </start-notifications>
  </rpc>

For agents:

  - many issues very TBD like target priority,
    multiple targets, target fail-over
  - agent uses callhome mechanism to connect to manager;
    manager checks capabilities (need to figure out how
    the manager knows why the agent is connecting);
    manager uses <start-notifications> RPC to initiate
    notification generation.

Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 May 2006 21:04:30 +0200

> This actually allows OR expressions to be processed correctly.

[...]
 
>    manager uses <start-notifications> RPC to initiate

If I understand things correctly, you want to use <edit-config> as the
only means to configure notification filters and profiles (not sure we
actually need both or what the added value of a profile is over just a
filter) and <start-notifications> <stop-notifications> verbs for
dynamic subscriptions. This approach and devision of work is fine with
me.

/js

PS. With ISMS in mind, we should think about impact of the asymmetry
    of SSH authentication and how that applies to access control. Well,
    netconf currently does not spell out access control so this is not
    really part of the WG concerns a this time. However, I think it
    would be desirable that ISMS and netconf use the same model when
    it comes down to "agent" initiated sessions for the delivery of
    notifications and how you bind access control rules to authenticated
    identities.

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 May 2006 15:00:26 -0700

> dynamic subscriptions. This approach and devision of work is fine with

Yes.
I imagine a profile will end up with more parameters
than the filter index.  If not, the profile table can
be removed.

>     notifications and how you bind access control rules to authenticated

I have been on the 'security bandwagon' for a long time.
I wanted to work on access control, naming, and partial locks
before notifications.

Andy