Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestions for the terminology draft #4

Open
fanf2 opened this issue Jun 15, 2020 · 0 comments
Open

Suggestions for the terminology draft #4

fanf2 opened this issue Jun 15, 2020 · 0 comments

Comments

@fanf2
Copy link

fanf2 commented Jun 15, 2020

Regarding the DNS, I think it's worth pointing out that the old
terminology is actively misleading, because the upstream side of a zone
transfer is unable to command the downstream side to do anything: all zone
transfers are demanded by the downstream side. The downstream doesn't have
to refuse the upstream, it can just do nothing.

Re. your suggested alternatives, it's useful to point out that it is often
a mistake to lazily use a binary classification. For instance it's common
to have multiple layers of replication, in which case terms like upstream
/ downstream or source / sink work better, because they don't imply a
single layer in the way other suggestions often do.

There are frequenly more than two roles, for example a database system
might have a single writable primary, readable replicas, standby replicas,
point-in-time recovery replicas, etc.

For a long time primary/secondary has been a very bad model for SMTP MX
servers, and it's a very bad model for the DNS. In the mail world it's
more common now to use more specific terms like submission agent, delivery
agent, relay server, MX server, etc., and in the DNS it's similarly more
helpful to talk about update servers, signing servers, zone transfer
servers, public authoritative servers, etc.

In general it seems to be easier to come up with better (more descriptive)
terms by discarding the binary model first, rather than trying to fit
better terms into an incorrect model.

Regarding exception lists, I like denylist rather than blocklist :-) I
have heard of cases where a system configuration has got into a horrible
tangle when they only have a notion of "blacklist" as a set of special
cases; if that is then used for exemptions to a default-deny policy then
the blacklist is an allowlist (?!?!). The metaphor was too weak to support
the functionality it was supposed to describe, so it caused confusion.

@mallory mallory transferred this issue from IRTF-HRPC/drafts Mar 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant