RE: Proposed Edits to Notification Draft

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

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.

I guess we can live without it for the base specification and find a way
to recover when supporting extended content.

Sharon

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