Subject: [i2rs] some comments on draft-rfernando-i2rs-protocol-requirements-00

From: Alia Atlas <[email-masked]>
Date: Tue, 5 Nov 2013 04:07:50 -0500

(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