Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF

["Joel M. Halpern" <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>