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

From: Ben Campbell <[email-masked]>
Date: Fri, 20 Feb 2009 17:21:13 -0600

Hi,

Hisham asked me to review draft-ietf-simple-intradomain-federation-02:

General:

--I think this is a good analysis in general, but I found it easy to  
get lost in all the models. An early summary or terminology section  
might help readers get the whole picture, prior to diving into detail  
on each model. Maybe even a taxonomy diagram.

(There are a lot of new terms in this draft, so a glossary would help  
one way or another.)

-- It's not clear to me what this document sets out to accomplish.  
Will it become a framework for discussing standards work? An  
architecture document? Recommended best practices? Something else?

--I am a little skeptical that the same set of models apply for both  
presence and messaging. Certainly some models work better for one than  
the other. I think it is likely to have overlaid models where presence  
and messaging are treated differently. I can also imagine buying a  
presence product from one vendor, and a messaging product from another.

--This version appears to change the terminology from "federation" to  
"bridging" to avoid confusion with inter-domain federation. The term  
"federation" still shows up quite a bit, though. (In particular, in  
the file name.)

Specifics:

Section 1, third from last paragraph (definition of "domain")

The draft defines domain in terms of "the right hand side of the @- 
sign". I think we are really talking about administrative domains,  
which may or may not line up with DNS domains. In fact, limiting  
domains to DNS domains has the effect of prejudicing us against the  
use of different DNS domains for the purposes of partitioning. There  
are well known limitations to that approach, but it should be  
evaluated based on those limitations. (I point to the fact that this  
draft goes on to discuss such approaches as evidence that "intra- 
domain" describes administrative domains rather than DNS domains.)

(I find it mildly ironic this draft lists Avshalom with a sub-domained  
email address :-)   )

-- Section 2, 2nd paragraph: "There is never
    database replication or state replication across federated systems"

Never say never. Such replication may not be common, but it is  
certainly possible.

-- ... 3rd paragraph: clustering always occurs amongst components from  
the same
    vendor"

Never say "always", either :-)

-- Section 3.4:

I am skeptical of using "people don't follow standards" as a  
motivation for more standards. (assuming any standards work comes out  
of this, of course.)

-- ... Last Paragraph, last sentence:

s/specified/specific

-- Section 5.2:

I think the distinction between "central database" and "routing proxy"  
is artificial, at least at a logical level. The routing proxy approach  
is likely to have in practice multiple proxies looking at a central  
database. The central database approach simply moves the routing  
function into each PS--but the function still logically exists.

-- Section 5.2.6: 

Any deployable version of this is probably the same as "central  
database" for all practical purposes. Or more to the point, two models  
that differ only in how the provisioning system works are probably the  
same model from a presence and IM perspective.

-- Section 6:

The term "exclusive" seems a bit off to me. The difference between the  
exclusive and partitioned model seems sort of apples and oranges.  A  
cleaner taxonomy might distinguish between "static" and "dynamic"  
assignment of users to servers, and "single-server" vs "multiple- 
servers" at any point in time. Can't you have static multi-server,  
static single-server, dynamic single-server, and dynamic multi-server?

-- Section 7, last paragraph:

Since the example is really not intra-domain bridging, can we omit it?  
Or maybe have a separate section for things that might look like intra- 
domain bridging at first, but on inspection are not?

-- Section 7.1.1, first sentence:

All of these items may or may not be needed, depending on how the  
servers communicate (back-end subscriptions vs PUBLISH, etc.) I think  
we mean to say "and/or", or that "each server needs to be provisioned  
with some combination of...".

-- 7.1.2, third paragraph:

Any reason not to reference RFC4474 as well as 3325?

-- 7.1.2.2, starting in paragraph 2:

I think it's important to mention (again) that this approach to  
privacy assumes that back-end subscriptions always happen on behalf of  
the end watcher. Also, this model does not hold if servers send  
PUBLISH to each other, does it? (i.e. back-end subscriptions are  
recommended over PUBLISH?)

Discussion of security differences between publish and sub/not models  
may be worthy of the security considerations section.

Section 7.1.3, 2nd bullet:

It seems like this statement is true in any multi-vendor network,  
isn't it?