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

[Pavlin Radoslavov <pavlin@icir.org>]

> I like both your suggestions regarding the building of multi-sender
> apps with SSM.  Here's a revision that incorporates your requests; I
> think this is an improvement.
> 
>     SSM is particularly well-suited to dissemination-style applications
>     with a single sender.  It can be used to build multi-source
>     applications, but the multi-source "rendezvous" functionality does not
>     occur in the network layer.  Just like in an application that uses
>     unicast as the underlying transport, this functionality can be
>     implemented by the application or by an application-layer library.
>     For instance, an application that desires to provide a secondary data
>     source in case the primary source fails over might implement this by
>     using one channel for each source and advertising both of them to
>     receivers.

Looks good to me.

> I'm having more trouble addressing Pavlin's comments regarding what I
> wrote about resource discovery:
> 
> > 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.
> 
> I don't like the specific phrase that you suggest, Pavlin: "with the
> help of additional support, such as application-level relay" because
> it leaves me wondering what other possibilities there might be besides
> application-level relaying, and I can't actually think of any.
> 
> So how about if I simply say this:
> 
>     Peer-to-peer multicast resource discovery of the form in
>     which a client sends a multicast query directly to a "service
>     location group" to which servers listen is not directly supported
>     by SSM

Fine with me.

> 
> This is true and doesn't rule out other forms of service discovery.
> If the group thinks we need to say more about resource discovery than
> this, then I also wrote this
> 
>     SSM might play a role in a resource discovery
>     service as a mechanism that, for instance, well-known relays can
>     use to forward client queries or server advertisements to
>     interested recipients.

I think there is no need to say that, so the "Peer-to-peer..."
paragraph is just fine.

Thanks,
Pavlin

> The latter bit of text has the problem for me that I don't actually
> think this is a very good application architecture and I hesitate to
> make the text look like it endorses it as a good use of SSM.  Once
> you've got a set of well-known servers, why wouldn't you just register
> the services with them via unicast and let clients do normal unicast
> queries?
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm