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 protected]
----------------------------------------------------------------------------
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
