Subject: [i2rs] Feedback on draft-rfernando-i2rs-protocol-requirements-00.txt

From: Joe Marcus Clarke <[email-masked]>
Date: Sat, 02 Nov 2013 19:20:36 -0400

Thanks for putting this draft together.  I have a few comments below.

Section 2:

Along with Joel, I find the terminology a bit strange given the existing 
content of I2RS.  Is "Server" in this context an I2RS Agent?  Or is the 
Server a bigger thing that can implement, among other things, an I2RS 
Agent?  Or is this more of an abstract thing?  I think perhaps in the 
context of I2RS, existing terminology should be used.

Nit: In the definition of Service you have, "...together with the 
policies that control it's usage."  This should be "its usage."

Section 3:

One HLO for me is serviceability (or traceability).  That is, I2RS 
should be designed in a way so that one can understand what Clients 
affected what Agent state and when.  It would be good to see some of the 
requirements from draft-clarke-i2rs-traceability folded in on that front 
(yes, shameless plug).

Section 4.1:

Here is where Agent should be used over Server to be consistent with 
existing I2RS terminology.

In your GEN requirements, you call out that the client initiates a 
connection to the server.  Okay.  However, what about notifications? 
They should be covered as part of the general protocol requirements. 
This would reverse the flow of the "connection" (if there is a 
connection for notifications).

I agree with Joel that GEN-3 and TR-4 seem to contradict each other. 
But I think that the server/Agent can initiate a transport session for 
notifications.

I'm not sure I see where TR-11 fits into I2RS exactly.  I don't recall 
seeing where I2RS needs to deal with dataplane manipulation.

Concerning TR-12, there was a lengthy discussion over using a persistent 
connection.  There are other ways to determine if an Agent has failed 
(which is what was concluded from the thread).  However, if you're 
saying that a participant only needs to be aware if the current, 
transient connection fails, I agree.  A reliable protocol should give 
you that.

ID-8 sounds weird to me.  I would imagine this would just happen if the 
state is associated to a particular client.  I'm not sure it needs to be 
stated.

Nit: In ME-6, I think IDL should be defined.

In MEP-3, why wouldn't a Server acknowledge a Client request?  Are you 
saying the Server may die or timeout?

Nit: In PS-2, "applications responsibility" should be "application's 
responsibility."

PS-4 seems to interfere with ME-9.  They don't contradict per se, but it 
seems like if there SHOULD be a binary protocol, why have a human 
readable one?  I guess what I'm saying is taken with ME-7, maybe a 
binary protocol isn't needed if a human-readble one can be made to 
adhere to the spirit of ME-7.

PS-11 points to not needing persistent connections.  However, how will 
notifications be done to these clients?  This has been the cause of some 
debate on the list.  Perhaps the requirements should spell something 
out.  Maybe the clients register a callback with the agent to receive 
the fire-and-forget notifications.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------