[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pre-release 2 of Notification Update

tom.petch wrote:

Neither of these seem quite to nail down my concern, which is that we are not
specifying how the notifications are stored in whatever database or log they may
or not be stored in, which may or may not be specified in some future time in a
standards or proprietary format.



But the WG decided it wanted a "tail" and "tail -f" type of interface,
done with a new RPC method (create-subscription).  The idea of
justing having a log that could be retrieved with <get> was
discussed several times, and rejected.

I don't see why you could not define a data model that had
stored <notification> elements in it.



Rather, it is the format that is used in the Notification protocol that matters
for filtering, and I was using 'on the wire' to refer to that protocol format.

Something like "The filter is applied to the notification as it would be
transmitted as part of an event stream"

If the use of "would be transmitted" is too cryptic, then I would insert - but
might not be as a result of a filter being applied - after transmitted



The filter seems fine to me being defined against
conceptual XML instances.  A filter is defined
with XML or Xpath, so there is no ambiguity about
internal or on-the-wire formats.


Tom Petch


Andy



----- Original Message -----
From: "Andy Bierman" <ietf@andybierman.com>
To: "Sharon Chisholm" <schishol@nortel.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Sent: Wednesday, August 22, 2007 9:12 PM
Subject: Re: Pre-release 2 of Notification Update



Sharon Chisholm wrote:

Hi

I find the reference to 'on the wire' a bit confusing, so instead I
propose saying in section 3.2.5.2.1 the following:

It made more sense before 802.11


The filter element is specified against the contents of the
<notification> wrapper and not the wrapper itself.  See section 5 for
examples.

How about:

s/specified/applied/



Sharon

Andy


-----Original Message-----
From: tom.petch [mailto:cfinss@dial.pipex.com]
Sent: Tuesday, August 14, 2007 10:13 AM
To: Chisholm, Sharon (CAR:ZZ00); Netconf (E-mail)
Subject: Re: Pre-release 2 of Notification Update

Sharon

I raised the question of whether a filter would be applied to the event
as it would appear on the wire, or as it might appear in the datastore
(thinking of XPath roots and namespaces).  Andy reported back, after a
hallway BoF with Martin

'The filtering in Notifications is different for 2 reasons, as Martin
has described in hallway BoFs...
   1) the filter applies to the notification message, not the conceptual
      NETCONF configuration database..'

I would like to see that explicit.  I suggest adding to 3.2.5.2.1 para 1
"Conceptually, the filter is applied to the event notification as it
would appear on the wire and not to it as it might appear in the
conceptual NETCONF database."

Tom Petch

----- Original Message -----
From: "Sharon Chisholm" <schishol@nortel.com>
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Sent: Wednesday, August 08, 2007 9:24 PM
Subject: Pre-release 2 of Notification Update


Hi

I'm almost done the update (hopefully). Attached is a pre-release.
Please let me know if anything was incorrectly executed.
 <<rfcdiff.pyht_two.htm>>

Disclaimers:

1. I have not validated much of the schema or examples 2. I got a bit
confused in the updates to section 5.2. These may still have issues.
3. I have not done anything about replays in the future. The text
remains unchanged in this area.
4. I need to double check that I have not missed updates.
5. There were a few changes (mainly editorial) that I did not make for
specific reasons which I need to send an email to discuss.
6. Not sure if using correct namespace in section 2.1.1.1. Andy said
what was there was wrong, but it validates for me and there was no
suggestions. I tried something else, but it didn't validate.
7. There was a request to add description of how to define notification
instances, which has not been added, but there are now two examples (one
in replayComplete and one in the examples in section 5). Is this
sufficient?
8.  I have not validate that I am always using the correct The URI
string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER)

Sharon Chisholm
Nortel
Ottawa, Ontario
Canada


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




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







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