From owner-cvs-all@FreeBSD.ORG Thu Jan 26 21:09:27 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22B8D16A422; Thu, 26 Jan 2006 21:09:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E70843D55; Thu, 26 Jan 2006 21:09:25 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 26 Jan 2006 13:09:25 -0800 Message-ID: <43D93A84.9090007@elischer.org> Date: Thu, 26 Jan 2006 13:09:24 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <200601261306.k0QD6o4P070834@repoman.freebsd.org> <43D927B4.9040602@elischer.org> <20060126195806.GC83922@FreeBSD.org> <20060126202334.W24703@maildrop.int.zabbadoz.net> In-Reply-To: <20060126202334.W24703@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, Gleb Smirnoff , cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/netgraph ng_pppoe.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 21:09:27 -0000 Bjoern A. Zeeb wrote: > On Thu, 26 Jan 2006, Gleb Smirnoff wrote: > > Hi, > > some brain-dump... > >> The other change I'm planning to do is the following - if the >> original PADI had empty Service-Name, and we are servicing a >> specific Service-Name, then return remove empty one from PADO, >> returning only our specific Service-Name. > > > Why would you want that? I haven't re-read the RFC but I think it said > that PADOs have to include the Service-Name the client requested first, > optionally followed by other Services-Names the AC may want to > announce. > > Only in PADS you will then reply with only the one Name you accepted. > > I can see the problem with your change and the above coming: > What would happen if you > a) accepted the 'any service' request > b) replied with 'any service' and 'service-name1, ...' > c) the client now requests 'any service' > d) you don't want to serve 'any service' > > Well you should have been silent from a) to b) *ups* > > Ok, so the only solution to this problem is what should also be in > that RFC - it's a ploicy decicion of the AC -- of what to accept > as Service-Name in a PADI. We had a clear policy up to now name it > closed system. With your change we will have an open system (everyone > will see the Service-Names we may serve if requested). > > The first thing might be a sysctl to toggle old and new behavior but > actually one may also want to decide on a peer by peer base depending > on a lookup perhaps based on mac address and/or Service-Name requested > or even simpler on a per ("Ethernet") port base and fall back to > a default poilcy if there is nothing (no hook) to do such a lookup. > [ I am () ethernet because it's not always a physical ethernet port > at the other end at the AC ] the reason that the AC side ofthe pppoe code is as it is with the dat of the padi being sent to the user process is so that the user code can decide these things. > > > The other question is what to do with clients requesting Service-Names > we don't know of but we know that we should serve the client? > I think this is a common scenario here in DE that some clients set a > Service-Name to "foo" and the ACs silently ignore and just serves it > (server all Service-Names policy)[1]. It's also a policy decision that > people might need ... > > [1] There are people speculating what will happen if they need to make > use of service-names ... ;) Fun with nnK users ... >