Subject: Re: [Simple] WGLC review and comments ondraft-ietf-simple-intradomain-federation-04

From: Avshalom Houri <[email-masked]>
Date: Tue, 11 May 2010 15:54:51 +0300

Thanks for your review.

Very sorry for the extremely long time that it took for me to get to this.

A version -05 of the doc will be published shortly that will reflect that
changes based on your comments.

Please see comments in-line.

Thanks
avshalom

[email-masked] wrote on 27/11/2009 01:55:23 PM:

> Re: [Simple] WGLC review and comments ondraft-ietf-simple-
> intradomain-federation-04
> 
> Christer Holmberg 
> 
> to:
> 
> simple
> 
> 27/11/2009 01:55 PM
> 
> Sent by:
> 
> [email-masked]
> 
> 
> 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?

One of the main reason may be servers from different vendors. A situation
that may happen a lot in mergers etc.

> 
> 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?

Database was only one example of the advantage of federation over 
clustering.
Removed it as an example.

> 
> 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 :)

Removed reference to the work that is done in the IETF today and simply
stated that it requires standardization across vendors.

> 
> Regards,
> 
> Christer
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Avshalom Houri <[email-masked]>
Date: Tue, 11 May 2010 15:54:51 +0300

Thanks for your review.

Thanks
avshalom

[email-masked] wrote on 19/11/2009 05:13:32 PM:

> [Simple] WGLC review and comments on draft-ietf-simple-intradomain-
> federation-04
> 
> Alan Johnston 
> 
> to:
> 
> simple
> 
> 19/11/2009 05:13 PM
> 
> Sent by:
> 
> [email-masked]
> 
> 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.

Added in the abstract.

> 
> 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?
> 

pager mode is also used. E.g. RFCs 5509, 5365.

> 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.
> 

Not sure since SUBSCRIBE and NOTIFY can be regarded as generically here.

> Figure 2 Caption:
> 
> As this figure relates to SIP Session Mode IM, perhaps the caption 
> should indicate this.

Added.

> 
> 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.

The use federation in a lot of places in the document is a remnant of
previous versions of the document where we have used federation instead
of bridging. Fixed in the document. We still use federation for inter
domain but that is defined in the document.

Noted that clustering is out of scope.

> 
> 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.

Not sure if this will add to the clarity of the document.

> 
> Section 6.1 Applicability:
> 
> Including the definition of AoR would be helpful.
> 

Done

> 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. 

Redirection is mentioned in section 6.2.2 Routing Proxy and 6.2.3 
Subdomaining.

> 
> Section 6.2.4 Peer-to-Peer:
> 
> Replace "gorup" with "group"

Fixed

> 
> Section 7.1.4 Peer-to-Peer:
> 
> Define "P2P" the first time it is used.

Done

> 
> Section 7.1.5 Forking:
> 
> Delete space in "test-and- set" and "on- behalf-of"

Fixed

> 
> Section 8.1.2.2 Distributed Provisioning:
> 
> Second to last paragraph should begin with "If" instead of "if"

Fixed

> 
> Figures 13 and 14:
> 
> These figures should be kept on a single page if possible.
> 

OK

> Section 8.1.4:
> 
> Replace "ALice" with "Alice"

Fixed

> 
> 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."

Suggestion accepted. Moved open issue to out of scope.

> 
> 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?

Fixed

> 
> 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..."

Rephrased the paragraph to include reference to base protocol as SIP
security mechanisms. 

> 
> Section 13. References:
> 
> As RFC 3261 is referenced, a reference to RFC 3265 and RFC 3903 might 
> not be a bad idea.
> 
> 

Done

---

From: Alan Johnston <[email-masked]>
Date: Tue, 11 May 2010 10:34:59 -0500

Avshalom,

Thanks for the reply.  This will address all my comments on the document.

- Alan -