[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed Edits to Notification Draft
Sharon Chisholm wrote:
Hi
I don't remember any discussion explicitly as to whether we needed this
identifier which is why I added it to the list of issues to discuss.
Yes, it is obviously helpful for implementations which support
proprietary or future capabilities that build on the base notification
specification. There are a number of add-ons that could result in the
one-session to one subscription ratio not being true. I know you aren't
really into supporting extensibility in that way, so I just want to
confirm that we don't need it to support the base specification.
For implementations only supporting the base protocol specification,
there is a one-to-one correspondence between session id and subscription
id. In these cases the session id can be used for many of the cases
where you would want subscription id. One potential case, even with the
current minimal base, where you would still have more then one
subscription associated with the same session is if you had a replay
subscription and after it completes you start another subscription.
Since these don't exist at the same time, it may not be necessary to be
able to distinguish them.
IMO it is bad engineering to add extra cruft because you might
need it someday. The WG consensus is that we do not need this
feature at all. If we ever change our minds, it is cleaner
engineering to add the parameter if and when we actually need it.
If you add a under-specified parameter in "1.0", it will in no way
indicate that the agent supports some future multi-subscription
notification capability. Then you have to specify how the real
capability interacts and coexists with the "old" subscriptionID.
In that case, we incur extra complexity for no benefit.
Proprietary 'replacements' to the standard (e.g., use your own
<create-subscription> RPC) are somewhat out of scope.
I guess we can live without it for the base specification and find a way
to recover when supporting extended content.
Yes we can live without it. The sessionID is sufficient.
Sharon
Andy
-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Wednesday, October 18, 2006 9:42 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: netconf@ops.ietf.org
Subject: Re: Proposed Edits to Notification Draft
Sharon Chisholm wrote:
hi
I have a clarifying question on one of the editing instructions. I
had interpreted the following to be decoupled from the subscriptionId
or not subscriptionId discussion which is listed in the issues for
discussion section. I had interpreted this to simply be that Andy is
saying the correct way to return the subscription Id is with <ok> and
not <data>.
On re-read, that sounds a bit off. What is the correct way to return
a subscription ID?
I think the WG already decided we do not need or want the subscriptionId
parameter at all.
The <ok> rpc-reply should be used because there is no data that needs to
be returned. You do not return any data with <ok>.
The WG did not decide to keep the subscriptionId "in case we want it
someday in the future", as you have interpreted it.
Andy
> 1 5. In section 2.1.1, in create subscription (source Andy)
> a. This should be <ok> instead of a <data> element containing
the subscription ID. The WG decided there is only one stream active
per session. That means there is no need for a subscription ID in the
document.
--
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/>