RE: message to nanog

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I am (personally) not sure we should already list which underlying
protocols can (easily) support multiple channels or which ones have
trouble.

I would focus on the the functionality, i.e.
- do operators want/need multiple channels to do their work.
- do operators need (asynchronous) notifications.

If we list pros/cons of such things, then I would focus on the
operational pros/cons, not on pros/cons w.r.t. how easy or not
one can put them over other underlying protocols.

And I think I would prefer that we ask similar questions 
for other functions/operations. So that we figure out what
is needed, and do not go down a path where we develop/design 
what we think might be nice.

Once we know the set of functions/operations that MUST be
supported, then we can start to list how easy/difficult it is
to put THOSE functions on top of the underlying protocols.
And if we see issues with that, we can again check.


Thanks,
Bert 

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