Hi Joel,
Thanks a lot for the review & comments. Please see inline.
/Jan
On 10/28/13 3:38 AM, "Joel M. Halpern" <[email protected]> wrote:
This strikes me as an interesting and useful step in our effort. I am
however confused by certain aspects of the document.
1) The document introduces new terminology in several regards. It seems
to replace the I2RS agent with "server". It makes no reference to
Information model, but makes several references to different kinds of
data models. And it makes these changes without any comment or
observation about the change. Can you please motivate the changes?
This is an oversight. The draft's terminology will be aligned with the
I2RS terminology
2) I think that OP-3 on providing a detailed workflow for bringing about
new services is a MAJOR new tasking for the WG, and does noit follow
from the charter. I understand that it is useful. But many things are
useful that are outside our charter.
I agree. We can leave it out of the draft for now.
Detail:
3) GEN-3 and TR-4 seem to contradict each other. GEN-3 says that the
client always initiates the transport connection to the server, and TR-4
says either participant may initiate the transport connection.
Thanks for catching this. My preference would be a client connecting to
the server (I2RS Agent), but there are examples of each behavior deployed
in real world (client connecting to server: Netconf, server connecting to
client: OpenFlow).
4) Is TR-12 intended to require persistent connections between clients
and servers?
Yes.
I had thought this was still under discussion, with many
of us at least wanting to avoid requiring a transport connection during
the lifetime of the state created by an I2RS client. It is possible
that you only mean the keep-alives for as long as the participants want
the connection alive.
We were requiring a persistent transport connection during the state's
lifetime. I can understand the desire to ease this requirement, but this
introduces complexity in other parts of the system. For example, we have
to allow either the Agent or the client to initiate the transport
connection (The Agent in case it wants to notify to the client about a
state change). Also, the state cleanup/timeout procedures & policies will
likely be more complex.
I agree that this is something that we should discuss and consider all the
pros/cons.
It is not obvious that this is worth the cost,
since failure will be detected (if communication has failed and not
recovered) when the participant next attempts to use the transport
connection.
Failure detection w/o keepalives can take a long time. Detecting a failure
early is critical in some applications. But, I think we could make
keepalives optional.
5) ID-7 implicitly creates the notion of shared identity. Is that
really the right model?
We need to have something to support redundant clients implementation.
Alternatively, we could have explicit state delegation (similar to PCEP) -
but that's probably more complex.
Or should we have multi-part identity, one part
for attribution purposes, and another part for permission purposes?
(With all of it authenticated of course.)
That's a viable model too. But how would it support redundant client
implementation?
6) MessageExchangePattern-2 says that capabilities can be exchanged in a
fire-and-forget fashion that is the same as that used for notifications.
fire-and-forget leads this reader to think unreliable. And capability
exchange messages would seem to need reliability.
I think you're right. For capabilities exchange we need app-level
reliability, which can only be achieved by request-response (where the
reply is an ACK), not by fire-and-forget.
7) MessageExchangePatter-3 seems to require an application level
acknowledgment even if we use a reliable transport. This may be
reasonable, but if so it needs more motivation. And an explanation as
to why a reliable transport is not sufficient would be appreciated.
Ok. A reliably delivered request does not mean an operation has truly been
performed - a positive 'ACK' response is needed. The document will be
updated.
It may be that this requirement is merely intended to say that every
operation should have a success or failure reply.
That's another way to describe it.
I would not call that an acknowledgment.
8) API-11 seems to be a subset of what is called for in the WG
architecture document. Shouldn't we either agree to change the
architecture or put the full requirement in the protocol requirements?
I'd rather put the full requirements in one place - the protocol
requirement document.
Minor:
Can we find another term than MEP? I realize that acronyms are
overloaded, and some collisions are inevitable. But MEP and MIP are
sufficiently pervasive and confusing on their own in the OAM space, I
would really like to avoid talking about the MEP (Message Exchange
Pattern) for performing manipulation of the MEP (Maintenance End Point.)
Could we use Communication Pattern or COmmunication Exchange Pattern?
I like that, will be changed in the next rev of the document.
On 10/21/13 4:33 PM, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : I2RS Protocol Requirements
Author(s) : Rex Fernando
Jan Medved
Edward Crabbe
Keyur Patel
Filename : draft-rfernando-i2rs-protocol-requirements-00.txt
Pages : 21
Date : 2013-10-21
...
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rfernando-i2rs-protocol-requiremen
ts
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-rfernando-i2rs-protocol-requirements-00
...
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
