Conscious language improvements #6

droideck · 2023-07-21T22:05:29Z

No description provided.

tbordaz

Few comments

tbordaz · 2023-07-25T07:30:13Z

docs/389ds/FAQ/esc-guide.md

@@ -27,7 +27,7 @@ The Dogtag Certificate System creates, manages, renews, and deletes certificates
 -   The Data Recovery Manager (DRM), which archives and recovers keys.
 -   The Online Certificate Status Manager, which stores lists of revoked certificates for client applications to use to check if a certificate is valid.
 -   The Token Processing System (TPS), which interacts with smart cards to generate and store keys and certificates for a specific user.
-   The Token Key Service (TKS), which generates and stores master keys used by the TPS.


Are you sure we can change this word. Someone from PKI should confirm

I've changed it back as I confirmed with the recent docs that they still use 'master' terminology.
I've created the issue on their repo - dogtagpki/pki#4515

tbordaz · 2023-07-25T07:31:54Z

docs/389ds/FAQ/faq.md


-389 replication uses a push model. A replication supplier is a server that pushes updates to other servers. A master is a supplier that can receive update requests from clients. A hub is a supplier that receives update requests from other replication suppliers and pushes updates to other replicas.
+389 replication uses a push model. A replication supplier is a server that pushes updates to other servers. A supplier is a supplier that can receive update requests from clients. A hub is a supplier that receives update requests from other replication suppliers and pushes updates to other replicas.


Would change it into: A supplier is a LDAP server that can receive and process update requests from clients.

tbordaz · 2023-07-25T07:36:30Z

docs/389ds/FAQ/selinux-policy.md

@@ -75,7 +75,7 @@ When the service command is used, **ldap-agent** will use **/etc/dirsrv/config/l

 #### Port Access

-The subagent does not listen on any ports itself. The sub-agent simply communicates with the snmpd master agent, which accesses the ports itself.
+The subagent does not listen on any ports itself. The sub-agent simply communicates with the snmpd supplier agent, which accesses the ports itself.


I would say 'main' agent as it is not related to replication

tbordaz · 2023-07-25T07:37:28Z

docs/389ds/FAQ/update-resolution-for-single-valued-attributes.md


-To determine the correct behaviour all combinations in a two master topology are considered. If more masters are involved the variety increases, but in URP there will always be only the resolution of a current state with a state change received via replication.
+To determine the correct behaviour all combinations in a two supplier topology are considered. If more suppliers are involved the variety increases, but in URP there will always be only the resolution of a current state with a state change received via replication.


two suppliers

I think it okay as it means "a topology of two suppliers". So it should be two supplier topology.

But I think even better option will be to say: "two-supplier topology". Hence, I'll fix like that.

tbordaz · 2023-07-25T07:37:48Z

docs/389ds/FAQ/update-resolution-for-single-valued-attributes.md

 -------------------

-The following table lists all the combinations of state changes in two master topology, each state change has to be executed with the potential operations to achieve this state change. It is assumed that the CSN of the state change on master 1 is always lower than that on master 2. This is also the reason that the table contains the full combinations since (--\>S0,--\>S1) and (--\>S1,--\>S0) are not symmetric.
+The following table lists all the combinations of state changes in two supplier topology, each state change has to be executed with the potential operations to achieve this state change. It is assumed that the CSN of the state change on supplier 1 is always lower than that on supplier 2. This is also the reason that the table contains the full combinations since (--\>S0,--\>S1) and (--\>S1,--\>S0) are not symmetric.


two suppliers

tbordaz · 2023-07-25T07:38:05Z

docs/389ds/FAQ/update-resolution-for-single-valued-attributes.md

 ---------------------

-Although with more than two masters the update resolution procedure should sequentially applied and result in the same state resolution existing bugs show that this is not the case with the current implementation. This chapter will handle all scenarios with 3 masters, this also allows all three different state changes applied in parallel. An extension to more than three master should not be necessary. In the tests a consumer should be added to the topology, it serves as a reference where the modifications are applied in the csn order.
+Although with more than two suppliers the update resolution procedure should sequentially applied and result in the same state resolution existing bugs show that this is not the case with the current implementation. This chapter will handle all scenarios with 3 suppliers, this also allows all three different state changes applied in parallel. An extension to more than three supplier should not be necessary. In the tests a consumer should be added to the topology, it serves as a reference where the modifications are applied in the csn order.


three suppliers

tbordaz · 2023-07-25T07:45:02Z

docs/389ds/design/dna-plugin-proposal.md


 ### Possible Solutions

 It is certainly important to retain the ability to allocate IDs from a range or slice so that communication with other DCs is kept to a minimum and necessary only when ranges are depleted and reconfiguration is needed.

 Using ranges of IDs instead of an algorithm to split a uniquely available space would make this easier.

-Manually splitting the ID space into ranges would be easy. And assigning a range to each server too. The advantage of using a range is that if one server is running low on IDs all is needed is only one other master available that has a big enough range assigned. The 2 servers can in fact be reconfigured so that half of the range previously assigned to one server can be reassigned to the other without the need for other masters to be online. The change of ownership information will be replicated to them as soon as they come up. There is no possibility that one master will steal ranges from another one as communication between the new and the old owner is required to allow the transfer of ownership.
+Manually splitting the ID space into ranges would be easy. And assigning a range to each server too. The advantage of using a range is that if one server is running low on IDs all is needed is only one other supplier available that has a big enough range assigned. The 2 servers can in fact be reconfigured so that half of the range previously assigned to one server can be reassigned to the other without the need for other suppliers to be online. The change of ownership information will be replicated to them as soon as they come up. There is no possibility that one supplier will steal ranges from another one as communication between the new and the old owner is required to allow the transfer of ownership.


I have a doubt here with the terminology of the DNA plugin. With DNA a server can request range to another server. I do not know how it was express in DNA plugin description. We should stick to what is in the doc

I checked both Admin and Config guides and we use the supplier terminology there.

tbordaz · 2023-07-25T07:45:42Z

docs/389ds/design/dna-plugin-proposal.md

@@ -106,5 +106,5 @@ The first operation will fail if the range has already been manipulated by someo

 ### Considerations

-What happen if the server is directly reachable but the replication topology is broken and the changes do not reach back the original server ? After the first change the plugin will have outdated information, when the grace period expires the plugin will, probably, try again with the same server and fail to the operation to grab a new range, at this point it will switch to another server. The Master requesting the new ranges cannot use them until the replication is over and its db has been changed accordingly to inform it of the new ownership.
+What happen if the server is directly reachable but the replication topology is broken and the changes do not reach back the original server ? After the first change the plugin will have outdated information, when the grace period expires the plugin will, probably, try again with the same server and fail to the operation to grab a new range, at this point it will switch to another server. The Supplier requesting the new ranges cannot use them until the replication is over and its db has been changed accordingly to inform it of the new ownership.


The same, we should use the terminology that is in the DNA plugin documentation

tbordaz · 2023-07-25T07:48:29Z

docs/389ds/design/managing-repl-conflict-entries.md

@@ -10,15 +10,15 @@ title: "Managing Replication Conflict Entries"
 Overview
 ========

-In multimaster replication the same entry (entries with the same DN), can be added concurrently and will be accepted by the masters whhic handle the ADD. After replication there would be two entries with the same DN, which violates the LDAP data model. So replication needs to “resolve this conflict.
+In multisupplier replication the same entry (entries with the same DN), can be added concurrently and will be accepted by the suppliers whhic handle the ADD. After replication there would be two entries with the same DN, which violates the LDAP data model. So replication needs to “resolve this conflict.


Here a typo. 'whhic' -> 'which'

tbordaz · 2023-07-25T07:51:21Z

docs/389ds/howto/howto-bind.md

@@ -57,7 +57,7 @@ To implement this solution, the following things need to happen:
        dnszonename: foobar.com
        dnsclass: IN
        dnstype: SOA
-        dnszonemaster: tim.foobar.com
+        dnszonesupplier: tim.foobar.com


I have a doubt. Is dnszonemaster a valid term ?

IMHO the whole howto-bind document is outdated, the links to ldap2dns now leads to sourceforge main page but they do not have any project about ldap2dns ...
IMHO we should rather left it as it and move it in an "Outdated" section ...

Move "How to Bind" with DNS to the legacy section.

droideck · 2023-07-25T22:26:34Z

Fixed. Please, review...

tbordaz

Thanks for your answers. LGTM

droideck · 2023-07-28T15:46:22Z

Thanks for your answers. LGTM

Thanks for the review!

@progier389 I haven't found "Outdated" section, so I moved it to "Legacy How To's" one. Is it okay with you?

progier389

LGTM

Conscious language improvements

8c77ac1

droideck force-pushed the conscious-lang branch from 8987642 to 8c77ac1 Compare July 21, 2023 22:06

tbordaz reviewed Jul 25, 2023

View reviewed changes

Fix wordings

8cbc047

Move "How to Bind" with DNS to the legacy section.

tbordaz approved these changes Jul 26, 2023

View reviewed changes

progier389 approved these changes Jul 28, 2023

View reviewed changes

droideck merged commit 18132d2 into 389ds:main Jul 28, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Conscious language improvements #6

Conscious language improvements #6

droideck commented Jul 21, 2023

tbordaz left a comment

tbordaz Jul 25, 2023

droideck Jul 25, 2023 •

edited

tbordaz Jul 25, 2023

tbordaz Jul 25, 2023

tbordaz Jul 25, 2023

droideck Jul 25, 2023

tbordaz Jul 25, 2023

droideck Jul 25, 2023

tbordaz Jul 25, 2023

tbordaz Jul 25, 2023

droideck Jul 25, 2023

tbordaz Jul 25, 2023

droideck Jul 25, 2023

tbordaz Jul 25, 2023

tbordaz Jul 25, 2023

progier389 Jul 25, 2023

droideck commented Jul 25, 2023

tbordaz left a comment

droideck commented Jul 28, 2023

progier389 left a comment


		389 replication uses a push model. A replication supplier is a server that pushes updates to other servers. A master is a supplier that can receive update requests from clients. A hub is a supplier that receives update requests from other replication suppliers and pushes updates to other replicas.
		389 replication uses a push model. A replication supplier is a server that pushes updates to other servers. A supplier is a supplier that can receive update requests from clients. A hub is a supplier that receives update requests from other replication suppliers and pushes updates to other replicas.


		To determine the correct behaviour all combinations in a two master topology are considered. If more masters are involved the variety increases, but in URP there will always be only the resolution of a current state with a state change received via replication.
		To determine the correct behaviour all combinations in a two supplier topology are considered. If more suppliers are involved the variety increases, but in URP there will always be only the resolution of a current state with a state change received via replication.

Conscious language improvements #6

Conscious language improvements #6

Conversation

droideck commented Jul 21, 2023

tbordaz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

droideck Jul 25, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

droideck commented Jul 25, 2023

tbordaz left a comment

Choose a reason for hiding this comment

droideck commented Jul 28, 2023

progier389 left a comment

Choose a reason for hiding this comment

droideck Jul 25, 2023 •

edited