Subject: [Simple] WGLC review and comments on draft-ietf-simple-intradomain-federation-04

From: Alan Johnston <[email-masked]>
Date: Thu, 19 Nov 2009 09:13:32 -0600

I believe this is a useful document for implementors and is ready to 
progress.  I have noted a few minor comments below that should be 
considered by the authors but should not be considered blocking.

A suggestion for closing the one open issue listed in the document is 
contained below.

Thanks,
Alan

- - - - -

Title and Abstract:

Currently, neither the title or abstract of the document mention SIP by 
name.  While many of the concepts and models described in the document 
are not SIP-specific, all the realization discussions are very SIP 
specific.  I would suggest adding a mention of SIP to at least the 
Abstract if not the title as well.

Section 1. Introduction:

This section mentions "pager mode" which is also mentioned later.  I 
have always used "page mode" in my writing but perhaps "pager mode" is 
also commonly in usage?

Figure 1 Caption:

Again, perhaps SIP should be in the caption of this figure as it does 
show SIP specific mechanisms such as SUBSCRIBE and NOTIFY.

Figure 2 Caption:

As this figure relates to SIP Session Mode IM, perhaps the caption 
should indicate this.

Section 2 Intra-Domain Bridging vs. Clustering

This section uses the word "federated" without defining it.  The word is 
used in a few places elsewhere.  Perhaps a definition could be included 
or a reference.  Also, in this section, the differences between bridging 
and clustering are described.  If the intent is to rule a detailed 
discussion of clustering out of scope for this document, it might be 
worth saying this.

Figure 4:

I'm  OK with leaving off the URI schemes of the users - presumably they 
are either sip: or sips: - for clarity.   However,  it might be worth 
stating up front that all users are actually fully URIs.

Section 6.1 Applicability:

Including the definition of AoR would be helpful.

Section 6.2.1:

The discussion of the protocol used in this section doesn't mention the 
possible use of SIP with redirection, although this is discussed in 
Figure 7. 

Section 6.2.4 Peer-to-Peer:

Replace "gorup" with "group"

Section 7.1.4 Peer-to-Peer:

Define "P2P" the first time it is used.

Section 7.1.5 Forking:

Delete space in "test-and- set" and "on- behalf-of"

Section 8.1.2.2 Distributed Provisioning:

Second to last paragraph should begin with "If" instead of "if"

Figures 13 and 14:

These figures should be kept on a single page if possible.

Section 8.1.4:

Replace "ALice" with "Alice"

Section 8.2.1 Routing:

This section has an Open Issue in the last paragraph about mixing peer 
and exclusive bridging for different users.    To channel, Rohan, I'd 
say, "If it hurts, don't do it."

Section 9. More About Policy:

Is there a reason why this section talks about servers A and B instead 
of 1 and 2 in the rest of the document?

Section 11. Security Considerations:

While this section is OK, the security folks might appreciate a little 
repetition by adding a paragraph saying that "Normal SIP mechanisms for 
securing presence and instant messaging  should be used including..."

Section 13. References:

As RFC 3261 is referenced, a reference to RFC 3265 and RFC 3903 might 
not be a bad idea.

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Nov 2009 12:55:23 +0100

Hi,

First, my main issue is related to the assumptions about the databases,
and claimed advantages of federation over clustering.

The draft claims that clustering often requires database replication,
and that it is tightly bound with the internal implementation of the
product.

However, in figure 5 (Partitioned) a database is used. And, in a big
domain this database could very well be replicated, which means you have
exactly the same issue as for clusters. 

And, if all the servers communicate with the database anyway, what is
the advantage of each server being able to handle only a subset of the
users?

The same goes for figure 6 (Partitioned) where the routing proxy/proxies
would communicate with the database(s).

The same goes for figure 7 (Subdomain). If the subdomains are big, the
database may be replicated.

The same goes for Section 7 (exclusive), and it alwo puts additional
requirement on the database.

So, should the document contain some assumptions which are made
regarding the database(s) used?

Second, I am a little confused about section 6.2.4. What is stated may
be true, but isn't the reason we are working on things in IETF to solve
identified problems and needs? So, shouldn't 6.2.4 instead simply
describe how this is done with a peer-to-peer technique. "Today" depends
on when someone reads the draft, and what is stated for "today" may not
be true tomorrow :)

Regards,

Christer