Issue 9217 - Audit all schema definitions to have official non-experimental OIDs where possible
Summary: Audit all schema definitions to have official non-experimental OIDs where pos...
Status: VERIFIED SUSPENDED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: documentation (show other issues)
Version: 2.5.4
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-15 20:05 UTC by Quanah Gibson-Mount
Modified: 2023-11-07 16:43 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Quanah Gibson-Mount 2020-04-15 20:05:57 UTC 
From a past discussion with hyc on 2.5 requirements:

[09:27] <hyc> we also need to audit all of these schema defs
[09:27] <hyc> we're supposed to have official, non-experimental OIDs for released schema
[09:28] <hyc> accesslog is still using 666, experimental arc
[09:29] <hyc> I think this means we should polish up the logschema draft, Informational status, and publish it again as final
Comment 1 Michael Ströder 2020-04-15 20:16:34 UTC 
How about just giving up this .666-is-experimental nonsense, define .666 assignments as "official" and leave all OID assignments as is?
Comment 2 Howard Chu 2020-04-22 15:59:03 UTC 
(In reply to Michael Ströder from comment #1)
> How about just giving up this .666-is-experimental nonsense, define .666
> assignments as "official" and leave all OID assignments as is?

Something like that. We probably should never have had such a grab-bag "experimental" arc in the first place. A full audit of what uses .666 is
still a a necessary step before deciding what else to do though.

In the future, we should simply allocate per-feature arcs, which remain
unchanged throughout a feature's evolution from experimental to release.
Just like the config schema delegates sub-arcs for every backend and overlay,
etc.

We're probably stuck with the current .666 usages. Again, OIDs aren't
supposed to change after they've been used in the wild. But someone should
still document what the current .666 uses are.
Comment 3 Michael Ströder 2020-04-22 17:48:33 UTC 
(In reply to Howard Chu from comment #2)
> (In reply to Michael Ströder from comment #1)
> > How about just giving up this .666-is-experimental nonsense, define .666
> > assignments as "official" and leave all OID assignments as is?
> 
> Something like that. We probably should never have had such a grab-bag
> "experimental" arc in the first place.

Yes!

> In the future, we should simply allocate per-feature arcs,

Full ack!

> We're probably stuck with the current .666 usages. Again, OIDs aren't
> supposed to change after they've been used in the wild. But someone should
> still document what the current .666 uses are.

This means e.g. updating this:
https://tools.ietf.org/html/draft-chu-ldap-logschema-00

BTW: I can't find this draft in doc/drafts/ though...
Comment 4 Quanah Gibson-Mount 2021-01-28 17:42:15 UTC 
Need to move everything to non-experimental OID arc
Comment 5 Quanah Gibson-Mount 2021-06-14 16:29:45 UTC 
Keep all OIDs as is
Document all OIDs that are not currently documented.
Comment 6 Quanah Gibson-Mount 2023-11-07 16:43:56 UTC 
unclear where/how to document