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