RE: Issues for a bit more Discussion - Netconf Notifications

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

Hi

While the text in the transport mapping sections in the notification
draft is not earth shattering, it does seem necessary. My take on what
is necessary is currently defined in section 5.

For example, section 5.1 says

" Session establishment and two-way messages are based on the NETCONF
   over SSH transport mapping [NETCONF-SSH]

   One-way event messages are supported as follows: Once the session has
   been established and capabilities have been exchanged, the server may
   send complete XML documents to the NETCONF client containing
   notification elements.  No response is expected from the NETCONF
   client."

Sharon



-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com] 
Sent: Wednesday, October 18, 2006 9:37 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: netconf@ops.ietf.org
Subject: Re: Issues for a bit more Discussion - Netconf Notifications

Sharon Chisholm wrote:
> Hi
> 
> Ideally we will issue updates to the various transport mapping 
> documents with any required changes in order to be able to support
notifications.
> Presumably we can't start that work until the documents are published 
> as RFCs. We've been holding the text in our document for safe keeping 
> (although I agree the BEEP text is a bit broken currently).
> 
> Are we suggesting now is the time to remove this text from the
document?
> Where would it go? 
> 

The key phrase here is 'required changes'.
We don't have app-level ACKs, so there should be no text related to
that.  If there are any required changes to the transport documents,
let's identify them now.

We should decide where they go, once we know what they are.


> Sharon

Andy

> 
> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com]
> Sent: Monday, October 16, 2006 11:28 AM
> To: Andy Bierman
> Cc: Chisholm, Sharon (CAR:ZZ00); netconf@ops.ietf.org
> Subject: Re: Issues for a bit more Discussion - Netconf Notifications
> 
> Andy,
>> The WG already decided we do not want app-level ACKs.
>> They are supposed to be removed completely.
> My point was that you get this for free with BEEP (like so many other
> things) simply by choosing your grouping of messages and how you would

> process them (e.g., not waiting for the whole page).  You really need 
> no additional PROTOCOL support for those acknowledgments (although 
> some additional *application library* support on the part of the agent

> would be necessary).
> 
>> My comment (a) above is fairly clear -- we cannot create new BEEP 
>> features or in any way rely on BEEP features that do not exist in a 
>> Proposed Standard RFC.
> 
> I agree.
> 
> Eliot
> 
> --
> 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/>