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?
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.
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.
4) Is TR-12 intended to require persistent connections between clients
and servers? 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. 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.
5) ID-7 implicitly creates the notion of shared identity. Is that
really the right model? 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.)
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.
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. It
may be that this requirement is merely intended to say that every
operation should have a success or failure reply. 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?
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?
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-requirements
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
