[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notification architecture

Juergen Schoenwaelder wrote:


On Tue, Jan 24, 2006 at 10:09:45AM -0800, Andy Bierman wrote:

1. Notifications are not layered on the <rpc>, but rather a new wrapper
of <one-way-rpc> which is at the same Netconf layer as <rpc> but is
different. Therefore there should be no issues surrounding statistics
and I don't think the beep mapping is hindered by this wrapper.

I don't like it at all.
The document is not very clear at all.
There are many details that are buried in
hard-to-read XSD and not explained in
any human-readable text.


[...]

Andy, I find your comments related to notifications a bit harsh and
not really very constructive. If you think details are missing, please
pose the question and let people have a chance to supply the details
that are not well explained in human readable text. (I note that the
level of detail you provided on this list was also not that great.)

OK, I understand you don't like the proposed <one-way-rpc> framing of
notifications while others seem to think this is a good idea to have.
So lets talk about the pros and cons of introducing <one-way-rpc>.
Once we have a clear cut list of the pros and cons, the WG might come
to an informed conclusion. Right now, I have the feeling that the tone
of the debate is counter productive and upsetting contributors.


okay.

I will be quiet now and let others read the draft
and make comments.

I have found that there is no better way to improve a design
than by implementing it.  I believe both co-Chairs of this WG
would rather start (any charter item) with a deployed working
solution than with an untested proposal. 
BTW, I will not interpret silence as positive consensus,
so speak up if you have opinions.



Perhaps it helps if Sharon posts an itemized list why having the
<one-way-rpc> framing is a good idea and Andy posts an itemized list
why the addition of <one-way-rpc> is not needed and a really bad idea.
If both manage to stick to clear technical arguments, we might have an
easier way to move forward on this issue.


I don't think we should have a complicated architecture
unless we FULLY UNDERSTAND WHY.
I am never swayed by arguments like "we might
want to do some unknown thing the future".
If the WG agrees on specific future extensions, that's
something else.  All engineering tradeoffs need to be cost-justified.


/js



Andy


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