[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: about channels
At 07:42 AM 11/1/2003, William Caban wrote:
>The netconf draft define 3 channels:
>-Management channel
>-Operation Channel
>-Notification Channel
>
>Now, reading the draft "over SSH" the "management channel" can not be
>supported and only define a "single channel" mechanism.
>
>Since basically the definition on what is an actual channels (i.e. from
>a developer point of view) is an open issue that is defined based on the
>protocol it is encapsulated (i.e. ssh, tls, beep, etc), why not go with
>a more specific definition for these and on protocols like ssh, TLS,
>telnet a channel is just another parallel stream. Something just like
>what happen with ftp and ftp-data ports.
I agree. I think we should do the following:
- define 3 conceptual channels in the protocol document
- management (mandatory)
- operations (mandatory)
- notifications (optional, indicated by a capability)
- do not preclude the definition of other conceptual channels
in the future
- in each application protocol mapping document, define exactly
how each conceptual channel is realized (could be a real
channel like in BEEP or no channel like in SSH)
>Personally I like the "over BEEP" definition since it provides this
>mechanism over a single stream but for the others the same management,
>operation and notification channels functionalities should be there.
>
>
>-William
Andy
>--
>William Caban <william@hpcf.upr.edu>
>High Performance Computing facility
>University of Puerto Rico
>
>
>--
>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/>