(WG-chair hat off)
Hi Jan, Rex, Ed, and Keyur,
" GEN-3: The client and the server communicate using a simple transport
connection. The client initiates the transport connection to the server.
The server does not know the number and timing of the connections from its
clients."
I have two comments here. First, I think that the client and agent can
communicate over more than one transport connection. Second, the agent can
need to initiate a transport connection to the client if one doesn't exist
and a notification is required.
"GEN-5: The I2RS MUST define a data model to describe the SDMs supported in
the server and MUST define a data modeling language to formally describe
that data model. I2RS MUST specify the mapping from the service data model
to the message data model and subsequently to the client API."
This is interesting. We haven't discussed standardizing a client API. I
am curious about the motivations and what the opinion of the WG (and our
esteemed ADs) is.
"TR-4: A client could connect to multiple servers. Similarly, a server
could accept connections from multiple clients. Any participant may
initiate the transport connection."
Doesn't this contradict GEN-3?
"TR-7: Point-to-multipoint transports are mainly used to scale the system
by avoiding ingress replication when the same message has to be delivered
to multiple receivers. P2MP transport would work hand-in-hand with a P2MP
MEP. The subject of P2MP transport and P2MP MEP is for future work."
The primary use I see for P2MP transport is to support a pub/sub model for
information streams. While I understand that it may add complexity, I am
interested in the specific reasons that you think it is ok to put it as
future work. What gaps would not having cause and when would that work be
done?
"TR-9: After the transport is established, the participants exchange
capabilities and other session parameters before exchanging
service related messages."
This presupposes that a transport session stays up or that the overhead of
exchanging capabilities and such beforehand is low. In the case, say, of
an agent sending a notification to a client, that seems very heavyweight.
I certainly agree that we need to think about capabilities and other
session parameters - but, at a minimum, there should be a very simple, fast
and quick way to exchange a "nothing changed" or "capability summary" if
this were to be required.
"TR-12: For operational reasons, a participant MUST be able to detect
a transport connection failure. To satisfy this requirement,
transport level keep-alives could be used. If the underlying
transport connection does not provide a keep-alive mechanism, it
should be provided at the I2RS protocol level. For example, if
TCP is used as a transport, TCP keep-alives could be used to
detect transport session failures."
Why? Transport keep-alives - much less at the I2RS level - just seem to
decrease scalability and increase work. I'd much rather see the
operational reasons articulated so they can be discussed.
" ID-2: The server should use the client's identity to track state
provided by the client. State ownership enables multiple clients
to edit their shared state. This is useful for troubleshooting
and during client death or disconnection when the client's state
may have to be purged or delegated to another client that shares
the same identity."
Can you clarify what you mean by multiple clients having shared state? What
use-cases require this? How are different clients identified if not by
their identity?
" ID-5: A clients ability to operate on a state held by the server is
expressed at the granularity of a service. A service could be
read-only or read-write by a client possessing a particular
identity."
This I emphatically disagree with. I understand that it is a lovely
simplification - but I don't think that it meets realistic operational
policy requirements. For instance, can any client that might want to write
a single route into the RIB service be allowed to modify any route??
" ID-7: A client can edit (write, delete) only the state that was
injected by it or other clients with the same shared identity.
Therefore, two conditions must be met for a client to edit a state
through a session. First, the client should receive capability
from the server that it has 'edit' permissions for the service in
question, and, secondly, the state that it edits should be its own
state."
This conflicts with the I2RS Architecture where, for error cases, state
might be preempted by another client with a higher priority. What is
articulated here gives a time-based ownership which can lead to
unpredictability.
"ID-8: The server retains the client's identity till all of that
client's state is purged from the server."
I would clarify at least that all the client registrations (i.e. for events
and info streams) must also be gone. Also, for faster verification,
capability exchanges, etc., there are advantages to holding on to
authenticated clients' identities.
"MEP-1: I2RS defines three types of messages between the client and
the server. First, capabilities need to be exchanged on session
establishment. Second, API commands are sent from a client to a
server to add, delete, modify and query state. And third,
asynchronous notifications are sent from a server to a client when
interesting state changes occur."
What about information streams?
"MEP-4: The response message in a request-response MEP SHOULD
indicate that the server has received the message, done some basic
sanity checking on its contents and has accepted the message. The
arrival of a response does not mean all post processing of the
message has completed."
Can you please describe the use-case and need for this requirement? A
response indicating an error if the message has problems makes sense to me.
Otherwise, why not wait until the operations inside have been completed?
What issues are caused by delaying the response and having it indicate
that meaningful work has completed?
" MEP-6: Error codes SHOULD indicate to the client which layer
generated that error (transport, message parsing, schema
validation, application level failure, etc). The I2RS framework
should specify a standard set of error codes."
I think this would be in an I2RS protocol data model.
" MEP-7: The request-response messages SHOULD be asynchronous. That
is, the client should not be required to stop-and-wait for one
message to be acknowledged before it transmits the next request.
[ed: there must be a method for dependency tracking in the
protocol. possibly negotiate as an optional capability?]"
I agree we need to do something about dependency tracking. One possibility
is to have multiple operations in the same message to be done in that
order. My original concept was to have a start triggered by the completion
of another operation. That's been removed from the architecture, of course,
but we do need a standard solution.
" MEP-13: The fire-and-forget MEP does not carry a message-id but it
SHOULD carry a cookie that can be set by the sender and processed
by the receiver. The cookie could help the receiver of the
message to use the message for its intended purpose."
I'm not sure why the fire-and-forget MEP doesn't carry a message-id. I can
certainly see having it carry one that, for example, matches to the
original subscription request. Unless there's a reason for it not to, I'd
tone this down.
" API-7: All API methods SHOULD support a batched mode for efficiency
purposes. In this mode multiple state entries are transmitted in
a single message with a single operation such as add, delete, etc.
For methods described in A.1 and A.2 which elicit a response, the
failure mechanism that is specific to a subset of state in the
batch should be devised. The Notify method SHOULD also support a
batched mode."
Why do you see a single operation (add, delete, etc) as being in the
message? I agree that the the I2RS protocol needs a batched mode - and the
architecture describes different behaviors that can be requested.
" API-8: Since the API methods are primarily oriented towards state
transfer between the client and server, there SHOULD be a
identifier (or a key) to uniquely identify the state being
addressed."
Please clarify. Obviously there's the State data model info to identify
the data. Do you mean more/different than this?
"API-11: Transactions allow a set of operations to be completed
atomically (all or nothing) and that the end result is consistent.
Transactions MAY be required for some network applications. [ed:
i'd like to remove this for the the first version. it's a bit of
a canard']"
Are you picturing more than the mechanisms specified in the architecture?
I think we'd need pretty strong use-cases and reasoning to support
multi-message transactions and the associated complexity.
"SVC-8: For every service that it wishes to expose to a client, the
server SHOULD send capabilities that indicate the existence and
identity of the service data model, as well as valid states and
parameter ranges, any exceptions to it and the optional features
of the data model that it supports."
This doesn't sound particularly lightweight to do frequently. I'm not sure
I see the arguments for valid states and parameter ranges - but I'd presume
that those are part of the policy authorization.
" SVC-17: The server SHOULD indicate to the client the availability of
infrastructure to manage the state that it maintains. This
includes but is not limited to the availability of persistent
store, the availability of timer to clean up state after a
specified timeout, the ability to clean up state on the occurrence
of an event, etc. Equipped with this information, the client is
responsible for the lifetime of the state."
Please reread the architecture draft and determine if you are adding
persistent store back in. I recall that we'd discussed having an optional
timer to clean up state after a specified timeout - but that was when we
had an end-time per operation instead of continuing forever. IF that is
still needed, then please capture the reasoning and we can discuss it on
the mailing list to see if the Architecture needs to add this particular
case back in.
" SEC-2: Every client MUST have an authorized role whereby only
certain state can be accessed and only certain operations can be
performed by that client. To keep the model simple and
applications portable, authorization MUST be at a per service
level and not on individual state element level."
I am not convinced that this trivial authorization is sufficient to be
used. Obviously, I'd encourage others to provide their perspectives - but
I don't see security as something we can just add on later.
" SEC-3: The framework MUST provide for information confidentiality
and information integrity as options."
Do you mean in the default transport connection and the
mandatory-to-implement transport? Please clarify - and if not, then how
would it be securely added?
" PS-6: The transport protocol MUST provide for message
prioritization."
Could you please explain the reasoning and cases that need this?
" PS-8: The server MUST be kept stateless with respect to the number
and location of each client."
Do you mean that it shouldn't be told about the clients beforehand or that
it shouldn't store state about them?? The latter is what I'd interpret
stateless to mean - but that makes no sense to me.
" PS-10: An efficient synchronization mechanism between a client and a
server SHOULD be provided that avoids transferring all the state
between them."
Please describe the specific scenarios where this exchange is expected to
occur??? Then we can see if there are implications to the architecture (if
there's agreement on those scenarios).
General comment in Sec 4.9: What about, say, not requiring that the agent
operate on all messages in order? What about the agent operating on
messages from multiple clients at the same time? Those are mechanisms
that can improve performance and scale - by taking advantage of
multi-threading and so on. I'd like to see more thought and details here,
because without requirements like those, I think performance issues are
likely.
" HA-1: A 'superuser' identity SHOULD be provided that is capable of
changing security policies, clearing state and perform actions
that override client initiated actions in the system."
Hmm, this is interesting. I think that some of this is configuration of
policies and data-models. I.e., if we define a data-model for the security
policies, then a client with write-scope for that service could modify it.
For clearing state and such, the architecture does define a priority to be
used as a tie-breaker, but that is considered an error-condition. Is this
a sufficiently strong reason that shouldn't be an error condition? There
was a strong consensus for the current state. Obviously, one could delete
or modify client-initiated actions via non-I2RS mechanisms.
" PGM-2: The application once written to certain requirements should
be portable to other identical environments. The framework should
not have fine grained data access controls as this would lead to a
poorly written application with portability issues."
I'm confused by why the existence of fine-grained data access controls
would lead to portability issues? Can you clarify?
General comment on Sec 4.12: I'm delighted to see operational requirements
- though some of these seem to be not so much requirements on the protocol
(detailed workflow) as specifying the need to do work to think through
these aspects (I smell more drafts) so that the protocol and data-model
aspects are clearer.
Finally, PLEASE do reread draft-ietf-i2rs-architecture, align terminology
(or discuss why you loathe it on the list), and consider what should be
done about requirements that you have that depended on features in the
architecture that have been simplified out.
I'm happy to see the updated draft is much improved.
Regards,
Alia
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
