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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Mar 2009 16:44:57 -0400

Thanks much for the comments, Ben. Responses inline. As with Adam's 
comments, much of the work here and many of the responses below come 
from Avshalom, as this is a consolidated response:

Ben Campbell wrote:
> 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.)

I added an overview section near the beginning - hopefully this helps. I 
think something like that is more useful than a glossary.

> 
> -- 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 think its a framework for discussing standards work. It defines the 
problem, discusses models for solving it, and discusses how each would 
work. Follow on documents would be needed to define some of the 
specifics, recommended models, and so on.

I added a sentence in the abstract about this.

> 
> --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 doesn't rule that out; however from a presentation perspective a 
LOT of the issues are similar - routing in particular, which gets a lot 
of discussion, is identical. I think its better to call out differences 
rather than have a whole separate doc or section just on IM.

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

Only in the file name. Deadline submissions is the only reason for that ;)

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

Fair point - though I do think that partitioned federation with 
subdomaining *IS* inter-domain federation. However, unioned and 
exclusive federation can happen even when the subdomains are the same. 
I'll fix the above to talk about administrative domains and mention this 
often implies different RHS.

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

Changed
from:  There is never database replication or state replication
across federated systems (though a database and DB replication might
be used within a component providing routing functions to facilitate
bridging).

to:
   Database replication or state replication
across federated systems are extremely rare (though a database and DB 
replication might
be used within a component providing routing functions to facilitate
bridging).

> 
> -- ... 3rd paragraph: clustering always occurs amongst components from 
> the same
>    vendor"
> 
> Never say "always", either :-)

always -> most usually

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

We're having this discussion in the other thread. The problem is NOT 
that 'people don't follow standards', its that, 'people have business 
reasons for not wanting to have a standardized client/server interface'. 
Those are NOT the same thing; many such vendors/providers have strong 
reason to want standards on the server/server links.

All of that said, this is just one motivation of several for the work.

> 
> -- ... Last Paragraph, last sentence:
> 
> s/specified/specific

fixed

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

Agreed that both feature a central thing, but there are lots of 
differences between that being a database vs. a proxy. Databases can 
provide more information but are often harder to standardize; a routing 
proxy strictly handles routing but would allow us to use an existing 
standardized interface. Those may not be change the fact that there is a 
central DB in both cases, but it is a big difference in terms of 
standards, interop, and other aspects of the architecture.

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

This one is NOT a central database; its multiple databases independently 
provisioned.

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

This is a very good point. I *think* these are orthogonal, but its not 
clear. One thing is certain, we'd need a rewrite to address this :( so 
lets discuss and if there is consensus around such a restructure we can 
do it.

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

This particular use case comes up a lot. People have accounts on Yahoo 
or AOL, and there is a desire to somehow 'reflect' that state into their 
corporate IM systems. That is effectively inter-domain unioned 
federation. I think it warrants at least a mention. The interesting 
thing is - all of the issues in unioned intra-domain federation  - 
presence composition, policy, coherency - all apply to inter-domain 
unioned federation as well. We could expand the scope of this document 
to cover that as well; though I am reluctant to do that....

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

Fair point; the PUBLISH approach is not discussed as much here - the 
bias is clearly towards back-end subscriptions. A more general way to 
express the requirement here is that the 'servers need to be provisioned 
with the topology'.

> 
> -- 7.1.2, third paragraph:
> 
> Any reason not to reference RFC4474 as well as 3325?

Added: " or authenticated identity <xref target="RFC4474"/> "

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

The model itself (distributed provisioning), does hold, but the 
mechanics would be different. THe document has a definite bias in favor 
of back end subscriptions vs. publication; primarily this has to do with 
the fact that you cannot really do ANY policy processing if you only 
PUBLISH. Thus, PUBLISH is something more appropriate for sources of raw 
data.

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

It should. But my experience has shown that this is an enormous area of 
interop problems. The reason is, each client has a particular UI with 
some kind of jellybeans and text, and the code looks for a specific part 
of the presence document to find the thing they use to determine the 
color of that jellybean. As such, if you send it a document that is 
valid pidf but expressing things differently, there is no interop.

A good example of this is, how to determine if the jellybean is 'red' or 
not? Some folks look for 'closed' in the basic status, others look for a 
specific activity element, and so on. And as a consequence, you end up 
with one vendor having the jellybean red, and for the same document, 
some other vendor has it green, and the customer opens a support case 
against it, as being defective.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Mar 2009 16:19:39 -0500

On Mar 9, 2009, at 3:44 PM, Jonathan Rosenberg wrote:

>> --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 doesn't rule that out; however from a presentation perspective  
> a LOT of the issues are similar - routing in particular, which gets  
> a lot of discussion, is identical. I think its better to call out  
> differences rather than have a whole separate doc or section just on  
> IM.

Does the use of session-mode messaging change anything? MSP Relays? I  
think relays _could_ be a very interesting intra and inter-domain  
tool, due to the TCP connection-sharing feature. (Assuming they get  
deployed at all, of course.) If nothing else, session mode bridging  
may start to look more like RTP federation.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Mar 2009 15:58:48 -0400

I don't think session mode changes the issues that are discussed in the 
document. The issues are orthogonal - agreeng on session vs. pager mode, 
for example.

-Jonathan R.

Ben Campbell wrote:
>>> 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.
>>
>> LOT of the issues are similar - routing in particular, which gets a 
>> lot of discussion, is identical. I think its better to call out 
>> differences rather than have a whole separate doc or section just on IM.
> 
> think relays _could_ be a very interesting intra and inter-domain tool, 
> due to the TCP connection-sharing feature. (Assuming they get deployed 
> at all, of course.) If nothing else, session mode bridging may start to 
> look more like RTP federation.
> 
> 
> 
> 
>