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(_at_)apple(_dot_)com>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf