[ldapext] NIS, RFC2307, RFC2307bis, DBIS, whatever...
Michael Ströder <firstname.lastname@example.org> Tue, 01 December 2015 19:19 UTC
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F1C1A1A4B for <email@example.com>; Tue, 1 Dec 2015 11:19:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([18.104.22.168]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq8AT1Psd8IC for <firstname.lastname@example.org>; Tue, 1 Dec 2015 11:19:48 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [22.214.171.124]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C681A1A36 for <email@example.com>; Tue, 1 Dec 2015 11:19:45 -0800 (PST)
Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id B751C1CFB1 for <firstname.lastname@example.org>; Tue, 1 Dec 2015 19:19:38 +0000 (UTC)
Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 583DA1D776 for <email@example.com>; Tue, 1 Dec 2015 19:19:36 +0000 (UTC)
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <firstname.lastname@example.org>
Date: Tue, 1 Dec 2015 19:29:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000108090009000208020408"
Subject: [ldapext] NIS, RFC2307, RFC2307bis, DBIS, whatever...
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2015 19:19:51 -0000
HI! This is a purely organizational posting. *** Please do not follow-up on technical details in this thread!!! *** Reviewing the recent RFC2307bis/DBIS e-mail thread I think long texts discussing various topics at once is a real obstacle to get people involved. I also strongly feel that trying to solve all problems at once with one big solution will make it really hard to reach some sort of consensus on particular work items. Rather people should be able to pick certain aspects to solve part of the problem in their particular deployment. I'd vote for dividing the NIS/LDAP topic into several sub-topics already raised and start separate mail threads: 1. Case-sensitive vs. case-insensitive names further divided into: - Scope: POSIX vs. rest-of-world - User/login names - Group names - Service names 2. posixAccount vs. posixUserAccount (DBIS) vs. whatever - current common posixAccount usage (structural object class etc.) - gecos field: displayName vs. configurable mapping etc. - IANA considerations 3. Groups - current groupOfNames/posixGroup practice - empty groups (groupOfEntries) - attribute memberUID vs. member vs. whatever - IANA considerations 4. Host/service groups - NIS netgroups vs. groupOfNames vs. other host groups schema - which approaches are really used? 5. Client configuration profiles: - RFC 4876 usage - DBIS Feel free to extend this. Next steps: 1. I'd be very thankful if people could step up picking *one* sub-topic and start a separate discussion thread ideally first summarizing which approaches for this particular sub-topic were considered in the past or lying on the table as I-D. Please stay neutral and do not start such a sub-thread endorsing a particular solution. 2. The goal for each discussion thread should be to work out a set of real hard requirements or to agree that there is no consensus on the requirements. 3. After that hopefully we can agree which work items are put into the charter. I'm quite aware that some of the topics above overlap. But please let's try to be disciplined and get more structure into the discussion. Otherwise I don't see a chance to get work done. Ciao, Michael.
- [ldapext] NIS, RFC2307, RFC2307bis, DBIS, whateve… Michael Ströder