[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: about channels
>>>>> William Caban writes:
William> Personally I like the "over BEEP" definition since it
William> provides this mechanism over a single stream but for the
William> others the same management, operation and notification
William> channels functionalities should be there.
The key question the WG needs to answer is whether channels are a
first class netconf concept or not. Note that the answer to this
question depends on one's vision of the future of netconf and thus I
fear there is no clear technical answer. This is really a fundamental
design decision which the WG needs to make.
If a decision is made that channels are a first class netconf concept,
then transports^Wsubstrates have to support channels. While BEEP over
TCP does this to a certain extend, I like to encourage people to
carefully read RFC 3081 and in particular section 3.1.4 which
basically explains that a fair BEEP implementation needs to know TCP
internals to "avoid pathological interactions with the transport
service". On some systems, this might be hard to achieve.
So from a purely technical perspective, one can argue that SCTP is a
better substrate^Wtransport for netconf than BEEP since SCTP provides
real independent channels and does all the necessary work on a
protocol layer where all the necessary information is available. BEEP
over TCP kind of tries to emulate channels over a byte stream
transport which is really not channel friendly.
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
--
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/>