Re: [iana-pen@iana.org: RE: Application for Enterprise-number (9586)]
# Under the Debian LDAP number let's assign number 100 onwards to Debian
related# projects.
# 100 is for scalemail which makes scalemail LDAP be 1.3.6.1.4.1.9586.2.100
# 101 is for sourceforge which makes sourceforge LDAP be
1.3.6.1.4.1.9586.2.101
The above is from my latest OSI draft. Please start using
1.3.6.1.4.1.9586.2.101 as you see fit. However please note the usual
limitations on how to do these things, use a part of your number range for
experiments and renumber objects from experimental range to real numbers
after they are finalised. Don't put the experimental numbers in any packages
that you upload to Debian (put them in experimental packages on your personal
web site). If you have any questions ask me or Wichert for guidance, if we
are unable to answer (or don't respond in time) then the OpenLDAP mailing
list is probably a good place to ask.
> > Anyway please clarify whether you want only LDAP or a range that can
> > be used for SNMP as well (any range can be used for either but I
> > would like to try and keep things tidy).
>
> LDAP only. Even if I don't want to rule out future options, I don't
> see how Sourceforge would be able to help SNMP in the foreseeable
> future.
OK. I've attached my latest draft with your number.
> In case it helps you, here's the schema I have now (obviously, the
> 1.1.2.2.* part will be replaced with an official ID if/when I have
> one).
I'll put in my comments.
> | attributetype ( 1.1.2.2.2 NAME 'x-cvsShell'
> | DESC 'The path to the CVS login shell'
> | EQUALITY caseExactIA5Match
> | SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
Firstly it is recommended that each project that has it's own attributes and
objectClasses use it's own name prefix to avoid naming clashes. I don't
think that "x-" is destined to be unique and I think that many of your
attributes are things that other projects may allocate. I suggest
"sfgCvsShell" for this one and prefixing all attributes with "sfg".
> | attributetype ( 1.1.2.2.3 NAME 'x-forward-email'
> | DESC 'The address to which email is forwarded'
> | EQUALITY caseIgnoreIA5Match
> | SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
> |
> | attributetype ( 1.1.2.2.4 NAME 'listPostAddress'
> | DESC 'The address of the mailing-list'
> | EQUALITY caseIgnoreIA5Match
> | SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
I think it would be good to have some of these in the standard Debian schema
so that anyone who needs such features can get them without including the
sourceforge schema. I am thinking of "debForwardEmail" and
"debListPostAddress". Of course this doesn't stop you from having
"sclForwardEmail" etc, but I think it would be handy to not double up.
Generally for any attribute that isn't available in any standard schema and
which has obvious practical uses you can send me the details and I'll make it
a Debian standard attribute.
I am much more hesitant about adding Object Classes because it's much harder
to get them right in a global sense. Also for someone who is creating a
schema for their own project or for private use it's much easier to create an
object class
Also why have these be single-value? Forwarding email to multiple
destinations is often desirable and having a mailing list with multiple
addresses is quite common. Even if Sourceforge doesn't currently support
such things it might be a good idea to allow it in the schema (once the
schema is set you would have to use a different attribute if you later need
multiple values).
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
# under iso.org.dod.internet.private.enterprise (1.3.6.1.4.1) we have Debian
# (9586) giving us the prefix of 1.3.6.1.4.1.9586.
#
# under the base OID I have decided to use 2 for LDAP (leaving 1 for SNMP),
# then under that 1 is for attributes and 2 is for objectClass's. This is
# arbitary but copies some sample schema from the OpenLDAP documentation
#
# under the Debian OID let's delegate .1000 onwards to other open source
# projects
# Currently 1.3.6.1.4.1.9586.1000 is for LVM.
# Under the Debian LDAP number let's assign number 100 onwards to Debian related
# projects.
# 100 is for scalemail which makes scalemail LDAP be 1.3.6.1.4.1.9586.2.100
# 101 is for sourceforge which makes sourceforge LDAP be 1.3.6.1.4.1.9586.2.101
attributetype ( 1.3.6.1.4.1.9586.2.1.1 NAME 'debIpAllowedClients'
DESC 'IP address or IP address range, either CIDR or 1.2.3.4-1.2.3.100 range allowed to connect'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} )
attributetype ( 1.3.6.1.4.1.9586.2.1.2 NAME 'debIpDeniedClients'
DESC 'IP address or IP address range, either CIDR or 1.2.3.4-1.2.3.100 range not allowed to connect'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} )
attributetype ( 1.3.6.1.4.1.9586.2.1.3
NAME ( 'debAllowedService' )
DESC 'Service that this object allows access to, suggested values include "FTP", "SSH", "HTTP", or other names from /etc/services, or "ALL", or it can be classes of service EG "STAFF" to mean that the account works on staff machines'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
attributetype ( 1.3.6.1.4.1.9586.2.1.4
NAME ( 'debDeniedService' )
DESC 'Service that this object denies access to, suggested values include "FTP", "SSH", "HTTP", or other names from /etc/services, or "ALL", or it can be classes of service EG "STAFF" to mean that the account is denied on staff machines'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
objectclass ( 1.3.6.1.4.1.9586.2.2.1
NAME 'debNetworkSecurity'
DESC 'A security object to specify the access that a user has to network services, or the access that a server program provides to the world.'
SUP top
MAY ( debIpAllowedClients $ debIpDeniedClients $ debAllowedService $ debDeniedService ) )
Reply to: