On Tue, 2010-12-14 at 18:19 -0800, Stuart Cheshire wrote: > On 23 Nov 2010, at 7:15 AM, Elwyn Davies wrote: > > > Summary: > > This document has at least one open issue that I believe needs > > fixing, either by altering the scope of the applicability of the > > solution or fixing the requirements. The requirements envisage a > > protocol that could be used in an enterprise environment but it > > does not address issues of visibility and accessibility. > > The document describes AppleTalk NBP, and what would be required in > an IP-based equivalent. It does not claim to document all possible > requirements of all possible service discovery protocols. The second sentence is certainly true. My comments do not seek ocean boiling. OTOH the document seeks to be not just an equivalent for Appletalk NBP but a specifically zero-configuration related service discovery protocol running over IP and explicitly targeting enterprise as well as (generally simpler) domestic type environments. Not being an enterprise network manager these days, I don't know what their hot buttons are in respect of service visibility but I do know that controlling visibility may be a factor. > > > This issue is clearly related to the security requirements that > > have been discussed elsewhere but differs from the authentication > > and general authorization aspects that have been the focus there. > > I believe that there needs to be discussion of how the service > > discovery can be controlled so that individual users/machines are > > only informed of services that they might be allowed to use. > > The document describes AppleTalk NBP, and what would be required in > an IP-based equivalent. AppleTalk NBP would find you (for example) > all file servers on the network, not all file servers for which you > know the password. We do not believe it is feasible in general to tie > service discovery to access control. Nor is it useful: Discovering > there's a printer for which you do know the password allows you to > ask someone for the password. Discovering only resources to which you > already have access (and therefore probably already know about) is > significantly less useful. A paranoid (but literate) network manager will ask 'useful to whom'? Being able to determine all the resources available on the network with limited authorisation may not be seen as the most desirable situation. But I leave it to those with more current experience in this area to determine whether this is a genuine hole in the requirements. Regards, Elwyn > > > Nits: > > [refreshingly free of nits!] > > The only comment might be that a pointer to some publically > > available definition or discussion of the existing Appletalk NBP > > miight be helpful if such a thing exists. > > There is not, which is why I wrote this document. > > > Also idnits suggests that RFC 2462 should be replaced by RFC4862 > > which obsoleted it. > > Fixed. > > Stuart Cheshire <cheshire@xxxxxxxxx> > * Wizard Without Portfolio, Apple Inc. > * www.stuartcheshire.org > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf