Re: ITS#8286 pending questions

[Quanah Gibson-Mount <quanah@symas.com>]

--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>