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

["Sharon Chisholm" <schishol@nortel.com>]

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 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/>