Subject: [Simple] Comments on draft-ietf-simple-intradomain-federation

From: Adam Roach <[email-masked]>
Date: Tue, 17 Feb 2009 16:34:15 -0600

I have been asked to do a dedicated review of 
draft-ietf-simple-intradomain-federation, and have a number of comments.

In general: much of the explanatory text is based on some of the
growing pains associated with a relatively new technology. For example:

   In an ideal world, clients would
   all implement to standards and this would not happen, but in
   practice, the vast majority of presence and IM endpoints work only
   (or only work well) with the server from the same vendor.

While this is true for the time being, I would hope that these
impedance mismatches fade over time as people implement
increasingly standard functionality (in fact, section 7.1.3
relies on this fact). Keep in mind that RFCs are permanent, while
this problem is (hopefully) temporary.

Section 5.2.2: The scaling problems mentioned here assume a
very naïve design. Any product that performs this kind of task
will cluster the routing proxy. Because the data used to process
transactions is slow-changing hard state, such clusters can scale
effectively infinitely.

Section 5.2.3: it would be useful to detail some potential
protocols for the client/database interaction. Making "Database" a
SIP redirect server, for example, would allow this scenario to
work with a broad base of deployed clients.

Section 5.2.4: it would be helpful to cite the p2psip work
as a candidate for doing this in the future.

Section 5.2.5: the caveat about the number of servers should
probably be stronger here; this approach completely defeats any
scaling-related partitioning.

Section 6.1.1: if the percentage of the community that is offline
at any given time is large, this approach simply moves any subscription
scaling problem up to the subscriptions on the database. While not
a show-stopper, this is an important property of the system that
should be explained. It should also be noted that static assignment
to a partitioned database can be used to solve this problem (i.e.,
you're using the approaches from section 5, but at the database
level instead of the presence/IM server level).

Section 6.1.2: this has the same scaling issues as 6.1.1.

Section 6.1.5: This should go into more detail about what
happens when multiple servers think they're authoritative
for a user -- e.g., the forked SUBSCRIBE will establish
multiple subscriptions, and the forking server will be
forced to form a coherent (if not necessarily complete)
state for the subscribing user...

Section 6.2: this should also talk about storing policy
on an external server using, e.g., presence rules and
XCAP. That way, each presence server can access the same
policy information.

Section 7.1.1: in the third bullet, why is the request routed
to the parent instead of to the root? Routing to the root
would achieve the same effect, but with less traffic.

Section 7.1.2.2: The advice on presence subscription rejection
is precisely opposite from the common policy model, in which
rights are absent unless granted; and, once granted by a rule,
cannot be revoked. The interaction between these two diametrically
opposed models is likely to lead to some unwanted surprises. I
think the common policy approach is the correct one to take here.

Consider, for example, the case in which I instruct
an off-the-shelf geoloc server to allow Robert to subscribe to
my location information, but no one else. It interprets this
to mean "reject subscriptions from everyone but Robert" (which is
a reasonable implementation choice). Now, this server is used as
a leaf in a hierarchical tree of presence servers. Suddenly, no
one can see *any* of my presence information except for Robert!
That's certainly not what I intended. It seems quite reasonable
for a subscription rejection at a node other than the root simply
be interpreted to mean "the presence information from this
branch of the tree shall not be composed into the document, but
other information is still allowed."

Section 7.1.2.3: Figure 11 (and the accompanying text) implies
a push model. This can, of course, be achieved through a pull model
as well, such as XCAP. Such an approach requires more integrated
client support, but eliminates the need for a portal (with the
trade-off being deployment of an XCAP server).

Section 7.2: The formula given to demonstrate commutativity
is a bit confusing. I think you actually mean something like:

  Pi(Pj(x1..xm),y1..yn) = Pj(Pi(y1..yn),x1..xm)

  for all possible inputs x1..xm and y1..yn.

Section 7.2.1: This entire scheme seems less well baked than
the rest of the document. For example, I could point to concrete
standardized mechanisms to create all the systems described so
far; but for 7.2.1, I'd have to do some non-standard stuff (e.g.,
indication of a loop in a back-end subscription).

/a