As written, it is hard to answer the questions. Particularly since
RestConf is still under development, I expect that most of the
requirements can be met. But I do not have enough information to know
whether they are met.
Further, the questions seem to assume specific means of meeting the
requirement. They may well be the best means, but it is not obvious.
Further comments in-line.
Yours,
Joel
On 3/2/15 5:27 PM, Susan Hares wrote:
I2RS WG:
We are trying to wrap of the protocol requirements for I2RS within
March. This post ask 3 questions regarding the I2RS requirements.
*Question 1 context: *
The I2RS architecture states in section 1.1 that the I2RS interface
should be: programmatic, asynchronous, and offers fast, interactive
access for atomic operations. This posts asks if we need to require a
checkpoint to make asynchronous functions work.
In a review by the security directorate, the reviewer asked: βIs
security and the support for the asynchronous nature of the protocol
fully supported?β In the reviewers mind Asynchronous usually means the
following:
1)The protocol can launch operations and then check back later whether
they successfully completed.
2) If you want to execute a second operation only if a first succeeds
(or to guarantee the order in which they execute), you need to at some
point wait for operations to complete.
3)There is also substantial overhead in supporting asynchronous
operation in that all transactions need labels so that they can be queried?
*Question 1:* Do we believe that netconf or restconf augmented by the
traceability requirements and the pub/sub requirements provides this
support?
Drawing on the traceability requirement here assumes that the
traceability reporting is to be within I@RS. This was not obvious. Inf
act, if one is trying to diagnose problems / corruption of I2RS
activity, one might well want traceability via means other than I2RS.
It is clear that one can create an information model with access contro
recording the results of operations, and allowing a reader to determine
what has happened. It is not at all clear that pub/sub is needed to
meet these requirements, although one could subscribe to such a table to
get notifications of success / failure, which is not one of the listed
requirements, but is clearly nice to have.
Statement 3 asserts taht there is substantial overhead associated with
this. While I would have to agree that there is overhead, I have
trouble seeing it as "substantial".
*Question 2:* Do we need a checkpoint (monotonically incrementing
counter to accomplish #2)?
I can imagine multiple techniques to achieve goal #2. A monotonically
increasing counter, across multiple clients, seems like one of the
harder answers to actual use, although it would seem to work.
Question 3 Context:
The security directorate reviewer of the I2RS architecture stated:
β A conceptually simpler strategy [than the asynchronous strategy] is to
say that since a client can make multiple parallel connections to an
agent that in cases where a client wants asynchronous operation he opens
multiple connections and launches one asynchronous operation on each.
The cost is that is has lower performance in cases where there are large
numbers of parallel operations tying up lots of connection state.β
In my understanding RESTCONF provides one operations per session.
*Question 3:* If the I2RS client requires a tradeoff where that
restricts the space requirements for parallel sessions, is the space
requirement for output only (so that pub/sub requirements) are
sufficient. Or should this tradeoff be considered in the I2RS protocol
requirements.
I am unable to parse the question. Is the question "should we allow
multiple parallel sessions, but restrict the number of such sessions?"
Or is the question whether we want to require parallel sessions to be
used for asynchronous operations? The driver I understood for this
requirement was that some operations may take time, and / or may produce
significant volumes of response.
Thank you for your help,
Sue Hares
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
