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

Re: A question on notifications-03

Hector Trevino (htrevino) wrote:
Yan, Hi, see in-line 
Hector

    ------------------------------------------------------------------------
    *From:* owner-netconf@ops.ietf.org
    [mailto:owner-netconf@ops.ietf.org] *On Behalf Of *Li Yan
    *Sent:* Saturday, September 30, 2006 3:49 AM
    *To:* 'Sharon Chisholm'
    *Cc:* netconf@ops.ietf.org
    *Subject:* A question on notifications-03

    Hi,

    I have a question on notifications-03.

    2.3  Terminating the Subscription

       Closing of the event notification subscription is done by terminating

       the Netconf session ( <kill-session> )or via some action outside the

       scope of this specification.

    Does it imply that configuration and notification MUST run in two
    different sessions?
    [HT:] It can be a different session/channel. But yes, configuration
    and notifications are independent. This was one of the agreements
    that came out of the Montreal meeting (i.e. no mixing of commands
    and notifications).


     Otherwise, configuration operations could be broke by <kill-session>.

    In addition, I believe the Subscription Id doesn't make sense any
    more, because <cancel-subscription> and <modify-subscription>
    operations have been eliminated. A notification subscription should
    associate with a session-id, thus we can use <kill-session> to close
    a notification subscription.
    [HT:] Sharon and I had this discussion and left the Subscription Id
    in because: it is used in the notification subscription schema (i.e.
    unique identifier & search key) & also to allow for possible future
    enhancements.



This is a bit disturbing to me.
The WG already decided to take this out.
At the point when the WG makes a decision,
the document Editor is supposed to carry out that decision.

The search key argument is not really valid since there
is only 1 subscription per session (because the session ID
is the only relevant identifier).

The future enhancements argument is even less compelling
because whatever XML is needed can be added WHEN it is needed.
Adding parameters with no current use is not good engineering.





    Yan




Andy


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