Subject: Re: [Simple] WGLC review of draft-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 09/11/2009 10:35:41 PM:

> [Simple] WGLC review of draft-ietf-simple-intradomain-federation-04
> 
> Michael Froman 
> 
> to:
> 
> simple
> 
> 09/11/2009 10:42 PM
> 
> Sent by:
> 
> [email-masked]
> 
> In general I think the draft is ready to progress, but I have a few 
> comments/suggestions and a few nits.
> 
> Comments/Suggestions:
> Section 8.1.1 - I understand the routing rule, but I think an example 
> of why the
>          root node wouldn't always be the one to serve the initial 
> request would
>          be useful.

I think that the paragraph below figure 10 gives an example.

> Section 8.1.2.2 - It is difficult to see how "This means that a 
> presence server
>          cannot send notifications on its own until it has confirmed
>          subscriptions from downstream servers." can be accomplished 
> and still
>          comply with "immediate" initial NOTIFY requirements and 
> additionally
>          keep the initiating watcher from starting retry logic.

The server can send empty notification and then reject or send further
notifications based on the subscriptions responses from the downstream
servers.

> Section 8.1.2.2 - Distributed provisioning is making many assumptions 
> about each of
>          the potentially different vendors' presence servers making 
> the same
>          "unioned presence" approved decisions on what gets 
> propagated.  Given
>          that some of these servers may not know that they're 
> cooperating in a
>          unioned presence environment, this might be a difficult 
> section to
>          realize in the field.  I guess this is talked about some in 
> section 9,
>          but I think it would be fair to admit to the difficulty 
> briefly in
>          advance of section 9 in order to assure the reader the 
> problem was
>          considered, but is addressed elsewhere in the document.

The assumption here is that vendors will do some work in order to enable
this. The target is to make this work as minimal as possible.
So servers will be aware that they are participating in a unioned
presence environment. This assumption does not make everything easy...

> Section 8.1.2.4, 4th paragraph - "Standardized database interface" 
> between various
>          vendors - is this at all reasonable to expect?  It seems like 
> much of the
>          document it geared toward dealing making "incompatible" 
> implementations from
>          different vendors work together.  This seems like an odd 
> place to assume
>          they will be compatible.

The assumption here is that vendors will do some work in order to enable
this. The target is to make this work as minimal as possible.

> Section 8.2.1 "it rejects the second subscription with an indication 
> of a loop"
>          Does that indication exist for presence already?

Not aware for specific loop detection for presence by 482 "Loop detected"
may be used.

> Section End of 8.2.1 - still an open issue?

Moved open issue to out of scope

> 
> 
> Nits:
> Section 2, 2nd to last paragraph, last sentence: "This is a 
> consequence to their
>    loose coupling."  Should that be "This is a consequence of their 
loose
>    coupling." ?

Fixed.

> Section 5, last paragraph: "In the exclusive model, its one at a 
> time."  its ==> it's
> 
Fixed

> Section 7.1.4, 2nd paragraph: "to terminate its ongoing 
> subscriptions"  its ==> it's
> 
its is correct here.

> Section 8.1.2.2, last (full) paragraph: "if these rules are followed" 
> is missing
>    leading capitalization.
Fixed
> 
> Section 8.2.1, 2nd to last paragraph: "basically knows its the child" 
> its ==> it's
> 
Fixed
> 
> Cheers,
> Michael.
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple