--On Wednesday, May 30, 2018 11:40 AM +0200 Michael Ströder michael@stroeder.com wrote:
Some more comments on a sub-set of the attributes.
Thanks!
On the attributes related to filesystem paths (logfile, etc), I was going with case ignore match since olcConfigFile and olcArgsFile are already caseIgnoreMatch. I.e., the precedent for file paths is already set to be non-case specific. So it seems to me that olcLogFile, olcPidFile, and oldModulePath, etc should all be caseIgnoreMatch for consistency.
Any EQUALITY matching rule needed at all? If yes, use EQUALITY octetStringMatch as with userPassword.
Lack of matching rules is causing problems with cn=config replication, which isn't really highlighted in ITS#8286 (That problem arose later). So the goal is to ensure all attributes used by cn=config have matching rules defined.
olcTCPBuffer -- case ignore match?
Also might contain listener URL. So maybe same like olcReferral even though an LDAPI URI does not make sense with TCP buffers?
Sounds right.
olcTLSCipherSuite -- case ignore match?
I don't have a strong opinion on that because I don't have an oversight how the supported crypto libs treat this strings.
Yeah, I'm not entirely sure on this one either.
olcTLSSECName -- case ignore match?
??? Cannot find this in 2.4 schema. Is that new in 2.5?
Yes, new in 2.5.
--- dds.c olcDDSmaxTtl -- case ignore match? olcDDSminTtl -- case ignore match? olcDDSdefaultTtl -- case ignore match? olcDDSinterval -- case ignore match? olcDDStolerance -- case ignore match?
Why are the TTL attributes strings at all? I see no reason why there are not defined as Integer syntax.
That's a very valid question, since the man page only allows numeric values. But the schema defines them as directory strings instead of integers. Looking at RFC 2589, the "entryTTL" that gets added to a dynamic object is specified as being an integer, so it seems to me that these attributes which control that value should also be required to be an integer. Howard, your thoughts? Is this a bug in the design of slapo-dds? If they are kept as strings, perhaps "numericStringMatch"?
--- memberof.c olcMemberOfDangling -- case ignore match?
This serves as a good example for an enum type. I'd argue that it should be limited to this particular set of lower-cased values.
Per the code, it already is limited to "ignore" or "drop" or "error". The question here is what matching rule is necessary. As far as I can tell it'd consider "igNore", "DroP", etc, all valid since it's just a directory string.
olcMemberOfGroupOC -- case ignore match? olcMemberOfMemberAD -- case ignore match? olcMemberOfMemberOfAD -- case ignore match?
AFAICS these always reference a single object class or attribute type. So why not declare them with syntax OID? Same suggestion for similar attributes of other overlays.
I'm concerned about changing SYNTAX for already released code.
olcMemberOfDanglingError -- case ignore match?
Is this just the LDAP error code? If yes, define it as Integer.
It does seem it would make more sense as an integer. However, I'm not sure that'd work well as a change for 2.4, perhaps 2.5 only.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com