Re: [Gen-art] Gen-art LC review of draft-cheshire-dnsext-nbp-09.txt

Elwyn Davies <elwynd@dial.pipex.com> Wed, 15 December 2010 18:17 UTC

Return-Path: <elwynd@dial.pipex.com>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D043A6FBF; Wed, 15 Dec 2010 10:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.276
X-Spam-Level:
X-Spam-Status: No, score=-102.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53x0UQDGlaDv; Wed, 15 Dec 2010 10:17:32 -0800 (PST)
Received: from auth.a.painless.aaisp.net.uk (a.painless.aaisp.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by core3.amsl.com (Postfix) with ESMTP id 3A1F63A6F9B; Wed, 15 Dec 2010 10:17:32 -0800 (PST)
Received: from 250.254.187.81.in-addr.arpa ([81.187.254.250]) by a.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <elwynd@dial.pipex.com>) id 1PSvwT-0006w8-5F; Wed, 15 Dec 2010 18:19:09 +0000
From: Elwyn Davies <elwynd@dial.pipex.com>
To: Stuart Cheshire <cheshire@apple.com>
In-Reply-To: <E87C25DE-BFF5-44CE-B5F5-C44337DFD145@apple.com>
References: <1290525315.4284.7622.camel@mightyatom.folly.org.uk> <E87C25DE-BFF5-44CE-B5F5-C44337DFD145@apple.com>
Content-Type: text/plain
Date: Wed, 15 Dec 2010 18:19:53 +0000
Message-Id: <1292437193.17554.2809.camel@mightyatom.folly.org.uk>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.3
Content-Transfer-Encoding: 7bit
Cc: General Area Reviwing Team <gen-art@ietf.org>, draft-cheshire-dnsext-nbp.all@tools.ietf.org, ietf@ietf.org
Subject: Re: [Gen-art] Gen-art LC review of draft-cheshire-dnsext-nbp-09.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Dec 2010 18:17:33 -0000

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@apple.com>
> * Wizard Without Portfolio, Apple Inc.
> * www.stuartcheshire.org
>