Sharon,
Hi
As promised, here is the list of issues I think require a bit more
discussion. Note that this does not mean that I, as a technical
contributor, necessarily disagree with the person who raised the issue
or proposed a change.
1. In section 5.2.1.2, do we need this new construct? As this is
related to the Beep transport mapping which is currently not properly
understood, it is difficult to say for sure. (source Balazs & Andy)
a. We should remove any reference to non-existent BEEP
modifications in this document. This is not an option. Stuff like
this will only get stuck later anyway in the publication process. -
The NETCONF over BEEP authors (and others clueful in BEEP) need to
provide input on all of sec. 5.2
To be clear, I do not have a huge amount of time to devote to this, and
almost assuredly Ken has less. The fundamental issue is what level of
acknowledgment you want. If you want NONE, then just use one large MSG
that is chunked, and let the client parse the page real time. However,
I don't know what XML junkies would say about that. On the other hand,
if you want application level acknowledgments, then group the messages
into groups you want acknowledged and use MSGs that should be ANSed
(this is my recommendation, since you can in effect implement the other
approach by using VERY large groupings). Either way, the notifier sends
the agent sends the MSGs and the manager sends the responses (RPY for
one big page or ANS for multiples).