-----Message d'origine-----
De : Peter Thomassen <[email protected]>
Envoyé : vendredi 17 juillet 2026 12:59
À : [email protected]; Steve Sheng <[email protected]>
Cc : [email protected]; [email protected];
[email protected]; BOUCADAIR Mohamed INNOV/NET
<[email protected]>; [email protected]; ops-
[email protected]
Objet : Re: Final Review: RFC-to-be 10026 (draft-ietf-dnsop-ds-
automation) in XML
[Re-sending with co-author Steve Sheng's email address corrected.
Not sure why the original message went to his old address; the
document actually has the current one. -- Steve, can you respond
whether you approve of publication after the below fixes have been
made? Thanks!]
Dear RFC Editor, Alanna and Sandy,
Thank you for the editing.
With the below addressed, I approve of this RFC for publication.
I've spotted the following things that I'd like to comment on.
#1 You changed
ORIGINAL
both the registrar and the registry can effect
CURRENT
both the registrar and the registry can affect
The intended meaning is in fact "effect" (bring about), not
"affect" (influence). Can this please be changed back?
#2 At "Readers are expected to be familiar with DNSSEC", please
add RFC9975 (it wasn't published at the time of writing, but is a
central component of the document and referenced in various
places).
#3 At "records of DS automation decisions, including", you changed
data elements (timestamp, decision outcome) to plural. Let's keep
singular, but change to "records of each DS automation decision,
including". Also, "DS RRset application" is not correct, so please
change back to "applied DS RRset".
#4 "change in an SOA serial" is not correct. Please change back to
"change in SOA serial", or "change of SOA serial", or "SOA serial
change".
#5 We received additional feedback that RFC9859 is mentioned in a
few places but is not properly tied into the recommendations, so
the related guidance is inappropriately disconnected. This is
predominantly an editorial omission as RFC9859 didn't exist at the
time of writing. I've consulted with the responsible AD for how to
fix this, and we agreed on the following four adjustments (which
are expected to receive Med's approval):
## Section 4.1 and Appendix A.1
OLD
2. Parent-side entities (such as registries) SHOULD reduce a
DS
record set's TTL to a value between 5-15 minutes when a
new set
of records is published and restore the previous (or, if
unavailable, default) TTL value at a later occasion (but
not
before the previous DS RRset's TTL has expired).
NEW
2. Parent-side entities (such as registries) SHOULD allow for
effective rollback by reducing a DS record set's TTL to a
value
between 5-15 minutes when a new set of records is
published, and
restore the previous (or, if unavailable, default) TTL
value at a
later occasion (but not before the previous DS RRset's TTL
has
expired).
Besides a prudent choice of TTL, prompt DS changes also
require
timely discovery of update requests. For recommended
methods,
see Section 4.2.2.
## Section 4.2.2 (changes title, adds a first paragraph)
OLD
4.2.2. TTLs and Caching
NEW
4.2.2. Timing, TTLs, and Caching
For timely execution of DS provisioning requests, it is
important to
discover them reasonably quickly. The best way to do so is
for the
Child DNS operators to send an RFC 9859 notification to the
parent
(RFC 9859 Sections 4.1 and 4.2). In addition to publication
of the
relevant notification targets, this requires the advertised
endpoint
to actually listen (RFC 9859 Sections 3 and 4.3). By
explicitly
naming a responsible endpoint, this method also resolves
potential
contention between Registry and Registrar when the RRR model
is used
(see Section 7.2.3). Note that periodic scanning is a
suboptimal
alternative as it introduces policy-dependent delays and does
not
scale well for large zones.
## Section 5.1 and Appendix A.2
OLD
3. Child DNS operators SHOULD be notified of errors using a
report
query [RFC9567] to the agent domain as described in
Section 4 of
[RFC9859]. Notifications to humans (domain holder) will
be
performed in accordance with the communication preferences
established with the parent-side entity. The same
condition
SHOULD NOT be reported unnecessarily frequently to the
same
recipient.
NEW
3. Child DNS operators SHOULD be notified of errors using a
report
query [RFC9567] to the agent domain as described in
Section 4 of
[RFC9859]. Note that this requires listening to
notifications
and that appropriate notification targets are in place
(RFC 9859
Section 3).
Notifications to humans (domain holder) will be performed
in
accordance with the communication preferences established
with
the parent-side entity. The same condition SHOULD NOT be
reported unnecessarily frequently to the same recipient.
## Section 7.1 and Appendix A.4
OLD
the registry SHOULD publish the registrar's notification
endpoint
[RFC9859] (if applicable) and refrain from registry-side
DS
automation.
NEW
the registry SHOULD publish the registrar's notification
endpoint
[RFC9859] (if applicable) instead of their own and refrain
from
registry-side DS automation.
Other feedback below.
On 7/9/26 23:33, [email protected] wrote:
While reviewing this document during Final Review, please
resolve (as
necessary) the following questions, which are also in the source
file.
1) <!-- [rfced] Please insert any keywords (beyond those that
appear
in the title) for use on
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
www.
rfc-
editor.org%2Fsearch&data=05%7C02%7Cmohamed.boucadair%40orange.com%
7C5c2fb4d7793645abccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5
d20%
7C0%7C0%7C639198827405437888%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
GkiO
nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
yfQ%
3D%3D%7C0%7C%7C%7C&sdata=CO1jMc45GOaWav99DNx%2FXpUsPtCqw44zxVEfItG
kdTA
%3D&reserved=0. -->
DNS
DS # in the title already, but in ()
2) <!--[rfced] Should the citation to Section 5 be updated to
Section
5.1 to be more specific?
Original:
Any failures - such as a missing DNSKEY due to improper
rollover timing
([RFC6781], Section 4.1), or changed algorithm requirements
- can
then be communicated in line with Section 5, without
altering or
removing the existing DS RRset.
-->
Sure.
3) <!--[rfced] Should instances of "DNSSEC security" be updated
to
read simply "DNSSEC" to avoid redundancy (if expanded, "DNSSEC
security" would read "DNS Security security"). Please review and
let us know if any updates are needed.
Original:
... in non-technical language, such as
"DNSSEC security for your domain has been enabled and will
be
maintained automatically"
...
DNSSEC security guarantees and associated
benefits are no longer in effect.
-->
No.
Rationale: Most people consider "DNSSEC" the proper noun of the
technology. Consider a different technology, e.g., VPN, where
these would read "VPN security has been enabled" and "VPN security
guarantees". That's reasonable phrasing, and when people read
"DNSSEC", they don't think of the expansion.
4) <!--[rfced] It's unclear how "further" fits into this
sentence. May
we remove it?
Original:
DS automation by the registry further is consistent with
Section 2.3
of [RFC5731], which explicitly notes that an EPP server
(registry)
may override status values set by an EPP client (registrar),
subject
to local server policies.
Perhaps:
DS automation by the registry is consistent with Section 2.3
of [RFC5731], which explicitly notes that an EPP server
(registry)
may override status values set by an EPP client (registrar),
subject
to local server policies.
-->
The section lists arguments for the technical recommendation, and
this is a "further" argument (in case a reason would have
formulated the potential related objection in their head).
However, the word is not needed to make the point, so I'll leave
it to your editorial preference.
5) <!--[rfced] It is unclear how "either" fits into this
sentence. May
we remove it?
Original:
However, it is not expected to be
harmful as either DS RRset will allow for the validation
function to
continue to work, as ensured by Recommendation 1b of Section
4.
Perhaps:
However, it is not expected to be
harmful as the DS RRset will allow for the validation
function to
continue to work, as ensured by Recommendation 1b of Section
4.
-->
The previous sentence talks about DS flapping: two different
RRsets could be processed in an alternating fashion. The section
is about whether that is a problem. In the context at hand, both
RRsets are functional, so it is not a problem "either DS RRset
works". Replacing "either" by "the" is not correct.
Many reviewers have not flagged this as a problem, so I'd suggest
to leave as is, in particular as it's only part of the analysis
and not normative. If you feel strongly that this is very
confusing, feel free to suggest an alternative that better conveys
the intended meaning (but again, I think it's fine).
6) <!--[rfced] Throughout the text, the following terminology
appears
to be used inconsistently. Please review these occurrences and
let us
know if/how they may be made consistent.
Parent vs. parent
Child vs. child
-->
Those all look fine.
7) <!-- [rfced] FYI - We have added expansions for the following
abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide").
Please
review each expansion in the document carefully to ensure
correctness.
DNS-Based Authentication of Named Entities (DANE)
-->
OK.
8) <!-- [rfced] Please review the "Inclusive Language" portion
of the
online Style Guide
<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fwww
.rfc-
editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7
C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4d7793645abccde08dee3f
2651
1%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639198827405470572%
7CUn
known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl
AiOi
JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=x5g6
h0rW
8DkCwzPvWHWXNWYYe8b6fXsP0EskPbIu%2BPQ%3D&reserved=0>
and let us know if any changes are needed. Updates of this
nature
typically result in more precise language, which is helpful for
readers.
Note that our script did not flag any words in particular, but
this
should still be reviewed as a best practice.
-->
OK.
Best,
Peter
Thank you.
Alanna Paloma and Sandy Ginoza
RFC Production Center
On Jul 9, 2026, at 2:30 PM, [email protected] wrote:
*****IMPORTANT*****
RFC Author(s):
--------------
Final Review for RFC-to-be 10026 <draft-ietf-dnsop-ds-
automation>
Your document is now available for Final Review (previously
AUTH48).
Once it has been reviewed and approved by you and all coauthors,
it will be published as an RFC.
If an author is no longer available, there are several remedies;
see
the Unavailable Authors section
(https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fauthors.ietf.org%2Frfc-publication-process%23unavailable-
authors&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4d779
3645abccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
7C639198827405492069%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
3D%3D%7C0%7C%7C%7C&sdata=u1ybJxNgsq9h8Wn7iTSZmWrAmGDsioP2Qf6SYGc3k
jw%3D&reserved=0).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before
providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC
Editor
that have been included in the XML file as comments marked
as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this
cannot
change once the RFC is published. Please pay particular
attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP –
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
trustee.ietf.org%2Flicense-
info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4d779364
5abccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
39198827405508580%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs
IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
3D%7C0%7C%7C%7C&sdata=lX2vF40hvM5PYEWU7pYMAtGWeM8a3cDs%2B35eDXgNKB
A%3D&reserved=0).
* Semantic markup
Please review the markup in the XML file to ensure that
elements of
content are correctly tagged. For example, ensure that
<sourcecode>
and <artwork> are set correctly. See details at
<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
Fauthors.ietf.org%2Frfcxml-
vocabulary&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4d
7793645abccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
C0%7C639198827405524771%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
fQ%3D%3D%7C0%7C%7C%7C&sdata=%2B1oOd%2BlXx%2BNyZWzY7aQZbfUhWrYQQUdU
Fnn11XcC%2BSM%3D&reserved=0>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that
the
formatted output, as generated from the markup in the XML
file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using 'REPLY ALL'
as all
the parties CCed on this message need to see your changes. The
parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream
(e.g.,
IETF Stream participants are your working group chairs,
the
responsible ADs, and the document shepherd).
* [email protected], which is an archival
mailing list
to preserve discussion about the document while in the
RPC editorial
queue; it is not an active discussion list:
* More info:
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
mail
archive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-
4Q9l2USxIAe6P
8O4Zc&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4d77936
45ab
ccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6391
9882
7405545160%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI
wLjA
uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7
C%7C
&sdata=Uc%2F9AcFdQV6xjlEk9R%2FzK97InDnw9XnkrxFYhUYyEsg%3D&reserved
=0
* The archive itself:
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
mail
archive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7
Cmoh
amed.boucadair%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C9
0c7a
20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639198827405563252%7CUnknown
%7CT
WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4
zMiI
sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xRqCTSLwr2yf3
qbE3
nq%2Bejr87gabELYeahRK8V1%2FiUQ%3D&reserved=0
* Note: If only absolutely necessary, you may temporarily
opt out
of the archiving of messages (e.g., to discuss a
sensitive matter).
If needed, please add a note at the top of the message
that you
have dropped the address. When the discussion is
concluded,
[email protected] will be re-added to the CC
list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an
explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes
that
seem beyond editorial in nature, e.g., addition of new text,
deletion
of text, and technical changes. Information about stream
managers can
be found in the FAQ. Editorial changes do not require approval
from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email
stating that you approve this RFC for publication. Please use
'REPLY
ALL', as all the parties CCed on this message need to see your
approval.
Files
-----
The files are available here:
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
www.rfc-
editor.org%2Fauthors%2Frfc10026.xml&data=05%7C02%7Cmohamed.boucada
ir%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c7a20af34b4
0bfbc48b9253b6f5d20%7C0%7C0%7C639198827405580395%7CUnknown%7CTWFpb
GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=46nhBRIW7zwI%
2B%2F8st3PMh1YqoKFMm8CxOp%2B5ny1CUvA%3D&reserved=0
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
www.rfc-
editor.org%2Fauthors%2Frfc10026.html&data=05%7C02%7Cmohamed.boucad
air%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c7a20af34b
40bfbc48b9253b6f5d20%7C0%7C0%7C639198827405597712%7CUnknown%7CTWFp
bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AWqGZCZLKRqb
uJ5UIMGtmjVOADAe65iqUkMT6jEz4Xk%3D&reserved=0
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
www.rfc-
editor.org%2Fauthors%2Frfc10026.pdf&data=05%7C02%7Cmohamed.boucada
ir%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c7a20af34b4
0bfbc48b9253b6f5d20%7C0%7C0%7C639198827405613287%7CUnknown%7CTWFpb
GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hL1VfG9z%2B5h
ax5CbhUSwEfZlrARQD7cZdk9aDWGTkr8%3D&reserved=0
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
www.
rfc-
editor.org%2Fauthors%2Frfc10026.txt&data=05%7C02%7Cmohamed.boucada
ir%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c7a20af34b4
0bfb
c48b9253b6f5d20%7C0%7C0%7C639198827405629650%7CUnknown%7CTWFpbGZsb
3d8e
yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
iTWF
pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w6BXbzY1d1zCHYujO3FoB5phl
m2Xc
cWU7mOsX35E12o%3D&reserved=0
Diff file of the text:
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
www.rfc-editor.org%2Fauthors%2Frfc10026-
diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4d7
793645abccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
0%7C639198827405645620%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
Q%3D%3D%7C0%7C%7C%7C&sdata=8dHlCJz1%2FuOoGtXepRMDg1%2BqGLQrMgBbZYm
yzaD9PfM%3D&reserved=0
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
www.
rfc-editor.org%2Fauthors%2Frfc10026-
rfcdiff.html&data=05%7C02%7Cmohame
d.boucadair%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c7
a20a
f34b40bfbc48b9253b6f5d20%7C0%7C0%7C639198827405662628%7CUnknown%7C
TWFp
bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
IsIk
FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9qjloCAuISz6960P
6tDg
LP1s9JioVEElldxLeg7X2I4%3D&reserved=0 (side by side)
Diff of the XML:
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
www.
rfc-editor.org%2Fauthors%2Frfc10026-
xmldiff1.html&data=05%7C02%7Cmoham
ed.boucadair%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c
7a20
af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639198827405684125%7CUnknown%7
CTWF
pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM
iIsI
kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=b9bBfZ%2Bg%2BLq
F3yM
Xz4clZA6Og%2BSCfUIl%2FayDZYZMhCM%3D&reserved=0
Tracking progress
-----------------
Details on the status of your Final Review are here:
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
queu
e.rfc-editor.org%2Ffinal-
review%2Frfc10026%2F&data=05%7C02%7Cmohamed.b
oucadair%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c7a20
af34
b40bfbc48b9253b6f5d20%7C0%7C0%7C639198827405703161%7CUnknown%7CTWF
pbGZ
sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
kFOI
joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MF2jXMT1AB1KhFR9tYe
lw1i
pvngq%2BhH9dhpDcP1%2Bq%2Fw%3D&reserved=0
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 10026 (draft-ietf-dnsop-ds-automation)
Title : Operational Recommendations for DNSSEC
Delegation Signer (DS) Automation
Author(s) : Steve Sheng,
Peter Thomassen
WG Chair(s) : Benno Overeinder, Ondřej Surý
Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani
--
Like our community service? 💛
Please consider donating at
https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
desec.io%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4
d7793645abccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
7C0%7C639198827405717094%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
yfQ%3D%3D%7C0%7C%7C%7C&sdata=Hxwq%2BQeqPahgVO%2FdhAv1YmE2AZvj94Oma
gjTC4wNhPM%3D&reserved=0
deSEC e.V.
Möckernstraße 74
10965 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
