Re: [ssm] Re: last call comments on ssm-arch doc

> > >  * After enumerating the benefits of the SSM model in Section 1,
> > >    what about enumerating its limitations/drawbacks? :)
> > 
> > Fair enough.  I'll come up with something.
> 
> I promised to come up with some text.  How about this:

Overall looks good to me. Few comments included below.

> SSM is particularly well-suited to dissemination-style applications with
> a single sender.  It can be used in multi-source applications, but the
> multi-source "rendezvous" functionality must be implemented by the
> application or by an application-layer library.  For instance, an

"must" is probably a too strong word. Indeed, even though it appears
that application-level solution is the only (reasonable) solution,
someone might be able to come-up with some alternative, so it should
not appear that the document discourages other solutions.

Rewording suggestion:
Replace
  "must be implemented by the application or by an application-layer
   library."
With something like
  "might be implemented in the application level or by some other
alternative solution."

> application that desires to provide a secondary data source in case the
> primary source fails must implement the failover mechanism in the
                       ~~~~
Similar to above: "must" -> "might"

> application itself, presumably by using two channels, as two hosts
> cannot both send to a single SSM channel.  SSM does not support network-
> layer multicast resource discovery.

Strictly speaking, the last sentence is not absolutely true. For
example, lets say that there is something like Resource Discovery
Agent with address S1. Then, all servers supporting service X might
join SSM group (S1,G1), and all servers supporting Y might join SSM
group (S1,G2). If someone wants to do resource discovery, the
Resource Discovery Agent can relay the request to discover the
servers supporting X or Y.

Hence, what about modifying the last sentence to say that resource
discovery might be possible, but with the help of additional
support, such as application-level relay.

Thanks,
Pavlin
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm