IETF Logo Mail Archive

Re: [ldapext] DBIS commentary

Jordan Brown <Jordan.Brown@oracle.com> Thu, 03 December 2015 17:00 UTC

Return-Path: <Jordan.Brown@oracle.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DC71A8F34 for <ldapext@ietfa.amsl.com>; Thu, 3 Dec 2015 09:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlTBhVPGDqnv for <ldapext@ietfa.amsl.com>; Thu, 3 Dec 2015 09:00:34 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A711A901D for <ldapext@ietf.org>; Thu, 3 Dec 2015 09:00:34 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB3H0XlU006149 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Dec 2015 17:00:33 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tB3H0WBb011174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2015 17:00:33 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tB3H0V4C014920; Thu, 3 Dec 2015 17:00:32 GMT
Received: from [10.159.138.9] (/10.159.138.9) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Dec 2015 09:00:31 -0800
To: "Bannister, Mark" <Mark.Bannister@morganstanley.com>
References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> <565F1EB2.9060405@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com>
From: Jordan Brown <Jordan.Brown@oracle.com>
Message-ID: <56607528.9050905@oracle.com>
Date: Thu, 03 Dec 2015 09:00:24 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com>
Content-Type: multipart/alternative; boundary="------------060409080206060504060102"
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/7F2mmQT4FDBAZO533og09kE6Ltk>
Cc: "'ldapext@ietf.org'" <ldapext@ietf.org>
Subject: Re: [ldapext] DBIS commentary
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2015 17:00:36 -0000

On 12/3/2015 2:35 AM, Bannister, Mark wrote:
>
>> It doesn't look like you've got 4876 completely covered, though.  Attribute 
>> mapping is only one of the things it does - it also tells the clients which 
>> servers to connect to and what authentication schemes to use.  If you're 
>> replacing 4876, there should be a plan for replacing that capability.
>
> Yes I’ve not quite understood that.  You need to configure the client to talk to 
> an LDAP server, in order
>
> to obtain a profile that tells it to talk to a different LDAP server instead.  
> Why would you not just
>
> configure the client to talk to the correct LDAP server in the first place?  
> Please explain the use-case.
>

Centralized reconfiguration.  Your initial configuration is a bootstrap; after 
that, changes in the profile can direct you to use new sets of servers as existing 
servers are replaced.  Similarly, if you've got PKI or Kerberos infrastructure in 
place, the profile can tell you to start using it.

v2.26.15 | Report a Bug | By Email | System Status