Subject: RE: (unofficial issue 2) Subscription versus never-ending command

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 27 Mar 2006 13:51:56 -0500

hi

<Andy>
I like the publish/subscribe model, but that is not
what is in the draft.  
</Andy>
What do you view as being missing then?

<Andy>
IMO the classifications and content
of each notification should be defined independently
of this document.
</Andy>
The classification of content into a small set of very big buckets is
powerful and does not take up much room. I think it is comparable to
defining running and candidate configurations in the base protocol
specification. I don't think it needs a separate specification.

<Andy>
This document should just define how a standard NETCONF agent publishes
a set of IANA-registered event-type URIs to indicate it can meet all the
requirements specified for generating those event types.
</Andy>
To advertise the notifications supported? This is a new requirement. We
were thinking you would advertise them the same way you advertise that
you support XML Schema. We didn't use URIs for this, but I did see the
discussion on the mailing list earlier suggesting that particular
approach.

<Andy>
This document must also specify how a manager subscribes/unsubscribes to
receive an arbitrary subset of those event types.
<Andy>
It does currently, assuming that the filtering mechanisms are
sufficiently powerful.

<Andy>
The only real difference in your list is:
  - the ability to change the event type subscription from
    the same session.
  - the ability to use the same session for operations and
    notifications.
</Andy>

This is overly simplified. The implementation in the draft cleanly
supports creation, modification and cancelling of subscriptions. It also
enables additional useful functionality. The draft tries to balance the
needs of the netconf server against those of the operator/manager acting
in the client role. 

Sharon

--
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: Martin Bjorklund <[email-masked]>
Date: Mon, 27 Mar 2006 22:36:45 +0200 (CEST)

Hi,

> It does currently, assuming that the filtering mechanisms are

Regarding filtering, I have a comment on the current draft.  It uses
subtree filtering as defined in the protocol, but then in the examples
in section 6.2 it shows how what I think is a boolean OR expression is
built using a tag <neb>, which isn't further described.  What's the
intention here?

/martin