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

[Hugh Holbrook <holbrook@dsg.stanford.edu>]

Great.  Thanks for your comments.
-Hugh
> Cc: "Michael Luby" <luby@digitalfountain.com>,
> 	"Pavlin Radoslavov" <pavlin@icir.org>, ssm@ietf.org
> Date: Thu, 16 Jan 2003 20:34:51 -0800
> From: 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
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm