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

["Susan Hares" <[e-mail]>]

Melinda:

Thank you for your clear question - let me try to unpack and answer your
question.  I really appreciate your aid in working through these cases. 

<chair-hat off> 
The asynchronous models we've discussed are:
1) polling based - I2RS client queries at a set of agents to receive status
information
2) call-back based - the I2RS Client performs an action (adds an interface)
and the I2RS agent returns a response after the sequence is done.
3) pub/sub based - meaning the I2RS clients sign up to receive publications
of results. 
4) atomic based - a sequence of commands that are done and then returned
with a call-back.  
(if you think I've missed one, please let me know). 

IHMO the use of a checkpoint in each of the cases is the following. 
1) polling 
The checkpoint (or revision counter) would be used to indicate if something
else had written or change the portion of the tree after the polling began.
This checkpoint can be for the whole tree or a model.  The keeping of a
checkpoint per item within a model may be prohibited. 

2) call-back item
If another higher priority interrupt, interrupts the write with call-back
response - then an error message would indicated the interrupt.  If a lower
priority commands tries to interrupt, the architecture indicates the lower
priority command will receive an error in the call-back.  If a same priority
command tries to interrupt the command, it is an error and both commands
should be flagged. In my understanding, the checking point is not of a use
in this case. 

3) pub/sub item 
A checkpoint may provide an indication if something changes between
subsequent updates from a pub/sub.  This information may be sent in the
pub/sub message sequences. 

4) atomic groupings of commands that return with a command. 
The atomic groupings of a commands either succeeds or fails based on same
circumstances as the call-back.   A checkpoint really doesn't aid the result
here. 

My understanding on the support of each of these four functions in
RESTCONF/NETCONF depends on Ephemeral data store issues.  Without a NETCONF
solution to the ephemeral datastore, only restconf can share definitions and
data between I2RS agent models and netconf data models.  IMHO this sharing
makes data-model creation a lot easier.  Therefore, let me comment on the
RESTCONF support for the four functions: 
 
1) polling - RESTCONF GET/QUERY can poll for data I2RS data (no ephemeral
data store issues) 
2) call/back item: RESTCONF RPC mechanism seem to be supported as well as
the POST, PUT, PATCH, and DELETE. 
 
3) pub/sub:  call-home features exist and a pub/sub feature solution has
been proposed.  
4) atomic group: RESTCONF provides the automatic 

RESTCONF provides integrity and confidentiality of the data and mutually
authenticated client-server identities. 	

Sue Hares  


-----Original Message-----
From: Melinda Shore [mailto:[e-mail]] 
Sent: Monday, March 02, 2015 5:45 PM
To: Susan Hares; [e-mail]; [e-mail]
Subject: Re: [secdir] Asynchronous Nature of the I2RS Protocol - vs RESTCONF
and NETCONF

On 3/2/15 1:27 PM, Susan Hares wrote:
> This posts asks if we need to require a checkpoint to make 
> asynchronous functions work.

Hi, Sue:  I don't really understand the question.  If you're going to
specify that there's going to be support for asynchronous event processing,
you need a model for that.  It can be polling-based, callback-based,
interrupt-based, and so on, and what data structures you'll require will
depend on the model you choose.  That includes both for naming and for
coordination/scheduling.  I'm not sure exactly what you mean by "checkpoint"
(semaphores?  locks?) but it may actually be out of scope - an
implementation question.

At any rate the first place to start is with coming up with a concurrency
(or asynchrony) model, and then proceeding from there.

Melinda