idnits 2.17.1 draft-ietf-eppext-keyrelay-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 6, 2015) is 3056 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 eppext H.W. Ribbers 3 Internet-Draft M.W. Groeneweg 4 Intended status: Standards Track SIDN 5 Expires: June 8, 2016 R. Gieben 7 A.L.J. Verschuren 9 December 6, 2015 11 Key Relay Mapping for the Extensible Provisioning Protocol 12 draft-ietf-eppext-keyrelay-11 14 Abstract 16 This document describes an Extensible Provisioning Protocol (EPP) 17 mapping for a key relay object that relays DNSSEC key material 18 between EPP clients using the poll queue defined in RFC5730. 20 This key relay mapping will help facilitate changing the DNS operator 21 of a domain while keeping the DNSSEC chain of trust intact. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 8, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 59 1.2. Secure Transfer of DNSSEC Key Material . . . . . . . . . 3 60 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. DNSSEC Key Material . . . . . . . . . . . . . . . . . . . 4 62 2.1.1. element . . . . . . . . . . . . . . . 5 63 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 65 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 6 66 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 6 67 3.1.3. EPP Command . . . . . . . . . . . . . . . 8 68 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 8 69 3.2.1. EPP Command . . . . . . . . . . . . . . . . 8 70 3.2.2. EPP Command . . . . . . . . . . . . . . . . 10 71 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 10 72 3.2.4. EPP Command . . . . . . . . . . . . . . . 11 73 3.2.5. EPP Command . . . . . . . . . . . . . . . . 11 74 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 12 77 5.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 12 78 5.3. EPP Extension Registry . . . . . . . . . . . . . . . . . 13 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 8.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 14 85 A.1. draft-gieben-epp-keyrelay-00 . . . . . . . . . . . . . . 15 86 A.2. draft-gieben-epp-keyrelay-01 . . . . . . . . . . . . . . 15 87 A.3. draft-gieben-epp-keyrelay-02 . . . . . . . . . . . . . . 15 88 A.4. draft-gieben-epp-keyrelay-03 . . . . . . . . . . . . . . 15 89 A.5. draft-ietf-eppext-keyrelay-00 . . . . . . . . . . . . . . 15 90 A.6. draft-ietf-eppext-keyrelay-01 . . . . . . . . . . . . . . 15 91 A.7. draft-ietf-eppext-keyrelay-02 . . . . . . . . . . . . . . 16 92 A.8. draft-ietf-eppext-keyrelay-03 . . . . . . . . . . . . . . 16 93 A.9. draft-ietf-eppext-keyrelay-04 . . . . . . . . . . . . . . 16 94 A.10. draft-ietf-eppext-keyrelay-05 . . . . . . . . . . . . . . 16 95 A.11. draft-ietf-eppext-keyrelay-06 . . . . . . . . . . . . . . 16 96 A.12. draft-ietf-eppext-keyrelay-07 . . . . . . . . . . . . . . 17 97 A.13. draft-ietf-eppext-keyrelay-08 . . . . . . . . . . . . . . 17 98 A.14. draft-ietf-eppext-keyrelay-09 . . . . . . . . . . . . . . 17 99 A.15. draft-ietf-eppext-keyrelay-10 . . . . . . . . . . . . . . 17 100 A.16. draft-ietf-eppext-keyrelay-11 . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 There are certain transactions initiated by a DNS-operator that 106 require an authenticated exchange of information between DNS- 107 operators. Often, there is no direct channel between these parties 108 or it is non-scalable and insecure. 110 One such transaction is the exchange of DNSSEC key material when 111 changing the DNS operator for DNSSEC signed zones. We suggest that 112 DNS-operators use the administrative EPP channel to bootstrap the 113 delegation by relaying DNSSEC key material for the zone. 115 In this document we define an EPP extension to provide automation and 116 a reliable transfer of DNSSEC key material. 118 1.1. Conventions Used in This Document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in BCP 14, RFC 2119 123 [RFC2119]. 125 XML is case sensitive. Unless stated otherwise, XML specifications 126 and examples provided in this document MUST be interpreted in the 127 character case presented in order to develop a conforming 128 implementation. 130 In examples, "C:" represents lines sent by a protocol client, and 131 "S:" represents lines returned by a protocol server. Indentation and 132 white space in examples is provided only to illustrate element 133 relationships and is not a mandatory feature of this protocol. 135 1.2. Secure Transfer of DNSSEC Key Material 137 Exchanging DNSSEC key material in preparation of a domain name 138 transfer is one of the phases in the lifecycle of a domain name 139 [I-D.koch-dnsop-dnssec-operator-change]. 141 DNS-operators need to exchange DNSSEC key material before the 142 registration data can be changed to keep the DNSSEC chain of trust 143 intact. This exchange is normally initiated through the gaining 144 registrar. 146 The gaining and losing DNS operators could talk directly to each 147 other (the ~ arrow in Figure 1) to exchange the DNSKEY, but often 148 there is no trusted path between the two. As both can securely 149 interact with the registry over the administrative channel through 150 the registrar, the registry can act as a relay for the key material 151 exchange. 153 The registry is merely used as a relay channel. Therefore it is up 154 to the losing DNS-operator to complete the intended transaction. The 155 registry SHOULD have certain policies in place that require the 156 losing DNS operator to cooperate with this transaction, however this 157 is beyond this document. This document focuses on the EPP protocol 158 syntax. 160 +--------------------+ DNSKEY +---------------------+ 161 |gaining DNS operator| ~~~~~~~~> | losing DNS operator | 162 +--------------------+ +---------------------+ 163 | ^ 164 | | 165 V | 166 +--------------------+ +---------------------+ 167 | gaining registrar | | registrar of record | 168 +--------------------+ +---------------------+ 169 | ^ 170 EPP keyrelay | | EPP poll 171 V | 172 +-----------------------------+ 173 | registry | 174 +-----------------------------+ 176 Figure 1: Transfer of DNSSEC key material. 178 There is no distinction in the EPP protocol between Registrars and 179 DNS-operators, there is only mention of an EPP client and EPP server. 180 Therefore the term EPP client will be used for the interaction with 181 the EPP server for relaying DNSSEC key material. 183 2. Object Attributes 185 2.1. DNSSEC Key Material 187 The DNSSEC key material is represented in EPP by a 188 element. 190 2.1.1. element 192 The contains the following elements: 194 o One REQUIRED element that contains the DNSSEC key 195 material as described in [RFC5910], Section 4.2. 197 o An OPTIONAL element that describes the expected lifetime 198 of the relayed key(s) in the zone. When the element is 199 provided the losing DNS operator SHOULD remove the inserted key 200 material from the zone after the expire time. This may be because 201 the transaction that needed the insertion should either be 202 completed or abandoned by that time. If a client receives a key 203 relay object that has been sent previously it MUST update the 204 expire time of the key material. This enables the clients to 205 update the lifetime of the key material when a transfer is 206 delayed. 208 The element MUST contain exactly one of the following child 209 elements: 211 * : The DNSSEC key material is valid from the current 212 date and time until it expires on the specified date and time. If a 213 date in the past is provided this MUST be interpreted as a revocation 214 of a previously sent key relay object. 216 * : The DNSSEC key material is valid from the current date 217 and time until the end of the specified duration. If a period of 218 zero is provided this MUST be interpreted as a revocation of a 219 previously sent key relay object. 221 3. EPP Command Mapping 223 A detailed description of the EPP syntax and semantics can be found 224 in the EPP core protocol specification [RFC5730]. The command 225 mapping described here is specifically for use in this key relay 226 mapping. 228 3.1. EPP Query Commands 230 EPP provides three commands to retrieve object information: 231 to determine if an object is known to the server, to retrieve 232 detailed information associated with an object, and to 233 retrieve object transfer status information. 235 3.1.1. EPP Command 237 Check semantics do not apply to key relay objects, so there is no 238 mapping defined for the EPP command and the EPP 239 response. 241 3.1.2. EPP Command 243 Info command semantics do not apply to the key relay objects, so 244 there is no mapping defined for the EPP Command. 246 The EPP response for key relay objects is used in the EPP poll 247 response, as described in [RFC5730]. The key relay object created 248 with the command, described in Section 3.2.1 is inserted 249 into the receiving client's poll queue. The receiving client will 250 receive the key relay object using the EPP command, as 251 described in [RFC5730]. 253 When a command has been processed successfully for a key relay 254 poll message, the EPP element MUST contain a child 255 element that is identified by the keyrelay 256 namespace. The element contains the following 257 child elements: 259 o A REQUIRED element containing the domain name for which the 260 DNSSEC key material is relayed. 262 o A REQUIRED element that contains authorization 263 information associated with the domain object ([RFC5731], 264 Section 3.2.1). 266 o One or more REQUIRED elements containing data to be 267 relayed, as defined in Section 2.1. A server MAY apply a server 268 policy that specifies the number of elements that can 269 be incorporated. When a server policy is violated, a server MUST 270 respond with an EPP result code 2308 "Data management policy 271 violation". 273 o An OPTIONAL element that contains the date and time of the 274 submitted command. 276 o An OPTIONAL element that contains the identifier of the 277 client that requested the key relay. 279 o An OPTIONAL element that contains the identifier of the 280 client that SHOULD act upon the key relay. 282 Example response: 284 S: 285 S: 289 S: 290 S: 291 S: Command completed successfully; ack to dequeue 292 S: 293 S: 294 S: 1999-04-04T22:01:00.0Z 295 S: Keyrelay action completed successfully. 296 S: 297 S: 298 S: 299 S: example.org 300 S: 301 S: JnSdBAZSxxzJ 302 S: 303 S: 304 S: 305 S: 256 306 S: 3 307 S: 8 308 S: cmlraXN0aGViZXN0 309 S: 310 S: 311 S: P1M13D 312 S: 313 S: 314 S: 315 S: 1999-04-04T22:01:00.0Z 316 S: 317 S: 318 S: ClientX 319 S: 320 S: 321 S: ClientY 322 S: 323 S: 324 S: 325 S: 326 S: ABC-12345 327 S: 54321-ZYX 328 S: 329 S: 330 S: 332 3.1.3. EPP Command 334 Transfer semantics do not apply to key relay objects, so there is no 335 mapping defined for the EPP command. 337 3.2. EPP Transform Commands 339 EPP provides five commands to transform objects: to create 340 an instance of an object, to delete an instance of an 341 object, to extend the validity period of an object, 342 to manage object sponsorship changes, and to 343 change information associated with an object. 345 3.2.1. EPP Command 347 The EPP command provides a transform operation that allows a 348 client to create a key relay object that includes the domain name and 349 DNSSEC key material to be relayed. When the command is 350 validated, the server MUST insert an EPP message, using the 351 key relay info response (See Section 3.1.2), in the receiving 352 client's poll queue that belongs to the registrar on record of the 353 provided domain name. 355 In addition to the standard EPP command elements, the 356 command MUST contain a element that is identified 357 by the keyrelay namespace. The element contains 358 the following child elements: 360 o A REQUIRED element containing the domain name for 361 which the DNSSEC key material is relayed. 363 o A REQUIRED element that contains authorization 364 information associated with the domain object ([RFC5731], 365 Section 3.2.1). 367 o One or more REQUIRED element containing 368 data to be relayed, as defined in Section 2.1 370 Example commands: 372 Note that in the provided example the second 373 element has a period of zero and thus represents the revocation of a 374 previouly send key relay object (see Section 2.1.1). 376 C: 377 C: 381 C: 382 C: 383 C: 384 C: example.org 385 C: 386 C: JnSdBAZSxxzJ 387 C: 388 C: 389 C: 390 C: 256 391 C: 3 392 C: 8 393 C: cmlraXN0aGViZXN0 394 C: 395 C: 396 C: P1M13D 397 C: 398 C: 399 C: 400 C: 401 C: 256 402 C: 3 403 C: 8 404 C: bWFyY2lzdGhlYmVzdA== 405 C: 406 C: 407 C: P0D 408 C: 409 C: 410 C: 411 C: 412 C: ABC-12345 413 C: 414 C: 416 When a server has succesfully processed the command it MUST 417 respond with a standard EPP response. See [RFC5730], Section 2.6. 419 Example response: 421 S: 422 S: 423 S: 424 S: 425 S: Command completed successfully 426 S: 427 S: 428 S: ABC-12345 429 S: 54321-ZYX 430 S: 431 S: 432 S: 434 When a server cannot process the command due to the server 435 policy it MUST return an EPP 2308 error message. This might be the 436 case when the server knows that the receiving client does not support 437 keyrelay transactions. See [RFC5730], Section 2.6. 439 Example response: 441 S: 442 S: 443 S: 444 S: 445 S: Data management policy violation 446 S: 447 S: 448 S: ABC-12345 449 S: 54321-ZYX 450 S: 451 S: 452 S: 454 3.2.2. EPP Command 456 Delete semantics do not apply to key relay objects, so there is no 457 mapping defined for the EPP command and the EPP 458 response. 460 3.2.3. EPP Command 462 Renew semantics do not apply to key relay objects, so there is no 463 mapping defined for the EPP command and the EPP 464 response. 466 3.2.4. EPP Command 468 Transfer semantics do not apply to key relay objects, so there is no 469 mapping defined for the EPP command and the EPP 470 response. 472 3.2.5. EPP Command 474 Update semantics do not apply to key relay objects, so there is no 475 mapping defined for the EPP command and the EPP 476 response. 478 4. Formal Syntax 480 481 490 491 492 Extensible Provisioning Protocol v1.0 protocol 493 extension schema for relaying DNSSEC key material. 494 495 497 498 499 500 502 503 504 506 507 508 509 510 512 513 515 516 517 518 519 521 522 523 524 525 527 528 529 530 532 533 535 536 537 538 539 540 541 543 5. IANA Considerations 545 5.1. XML Namespace 547 This document uses URNs to describe a XML namespace conforming to a 548 registry mechanism described in [RFC3688]. The following URI 549 assignment is requested of IANA: 551 URI: urn:ietf:params:xml:ns:keyrelay-1.0 553 Registrant Contact: See the "Author's Address" section of this 554 document. 556 XML: See the "Formal Syntax" section of this document. 558 5.2. XML Schema 560 This document uses URNs to describe a XML schema conforming to a 561 registry mechanism described in [RFC3688]. The following URI 562 assignment is requested of IANA: 564 URI: urn:ietf:params:xml:schema:keyrelay-1.0 566 XML: See the "Formal Syntax" section of this document. 568 5.3. EPP Extension Registry 570 The EPP extension described in this document should be registered by 571 the IANA in the EPP Extension Registry described in [RFC7451]. The 572 details of the registration are as follows: 574 Name of Extension: "Key Relay Mapping for the Extensible Provisioning 575 Protocol" 577 Document status: Standards Track 579 Reference: (insert reference to RFC version of this document) 581 Registrant Name and Email Address: IESG, iesg@ietf.org 583 TLDs: Any 585 IPR Disclosure: https://datatracker.ietf.org/ipr/2393/ 587 Status: Active 589 Notes: None 591 6. Security Considerations 593 A server SHOULD NOT perform any transformation on data under server 594 management when processing a command. 596 Any EPP client can use this mechanism to put data on the message 597 queue of another EPP client, allowing for the potential of a denial 598 of service attack. However this can, and SHOULD be detected by the 599 server. A server MAY set a server policy which limits or rejects a 600 command if it detects the mechanism is being 601 abused. 603 For the data a correct 604 element SHOULD be used as an indication that putting the key material 605 on the receiving EPP clients poll queue is authorized by the 606 _registrant_ of that domain name. The authorization of EPP clients 607 to perform DNS changes is not covered in this document as it depends 608 on registry specific policy. 610 7. Acknowledgements 612 We like to thank the following individuals for their valuable input, 613 review, constructive criticism in earlier revisions or support for 614 the concepts described in this document: 616 Maarten Wullink, Marco Davids, Ed Lewis, James Mitchell, David Peal, 617 Patrik Faltstrom, Klaus Malorny, James Gould, Patrick Mevzek, Seth 618 Goldman, Maarten Bosteels, Ulrich Wisser, Kees Monshouwer and Scott 619 Hollenbeck. 621 8. References 623 8.1. Normative References 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, March 1997. 628 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 629 January 2004. 631 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 632 STD 69, RFC 5730, August 2009. 634 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 635 Domain Name Mapping", STD 69, RFC 5731, August 2009. 637 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 638 Security Extensions Mapping for the Extensible 639 Provisioning Protocol (EPP)", RFC 5910, May 2010. 641 8.2. Informative References 643 [I-D.koch-dnsop-dnssec-operator-change] 644 Koch, P., Sanz, M., and A. Verschuren, "Changing DNS 645 Operators for DNSSEC signed Zones", draft-koch-dnsop- 646 dnssec-operator-change-06 (work in progress), February 647 2014. 649 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 650 Provisioning Protocol", RFC 7451, February 2015. 652 Appendix A. Changelog 654 [This section should be removed by the RFC editor before publishing] 656 A.1. draft-gieben-epp-keyrelay-00 658 1. Initial document. 660 A.2. draft-gieben-epp-keyrelay-01 662 1. Style and grammar changes; 664 2. Added an expire element as per suggestion by Klaus Malorny; 666 3. Make the authInfo element mandatory and make the registry check 667 it as per feedback by Klaus Malorny and James Gould. 669 A.3. draft-gieben-epp-keyrelay-02 671 1. Added element to identify the relaying EPP client as suggested by 672 Klaus Malorny; 674 2. Corrected XML for missing and excess clTRID as noted by Patrick 675 Mevzek; 677 3. Added clarifications for the examples based on feedback by 678 Patrick Mevzeck; 680 4. Reviewed the consistency of using DNS operator versus registrar 681 after review comments by Patrick Faltstrom and Ed Lewis. 683 A.4. draft-gieben-epp-keyrelay-03 685 1. Style and grammar changes 687 2. Corrected acknowledgement section 689 3. Corrected XML for Expire element to not be mandatory but only 690 occur once. 692 A.5. draft-ietf-eppext-keyrelay-00 694 1. Added feedback from Seth Goldman and put him in the 695 acknowledgement section. 697 2. IDnits formatting ajustments 699 A.6. draft-ietf-eppext-keyrelay-01 701 1. Introducing the command, and thus separating the data and 702 the command. 704 2. Updated the Introduction, describing the general use of relay vs 705 the intended use-case of relaying DNSSEC key data. 707 3. Restructuring the document to make it more inline with existing 708 EPP extensions. 710 A.7. draft-ietf-eppext-keyrelay-02 712 1. Updated the XML structure by removing the command based 713 on WG feedback 715 2. Updated the wording 717 A.8. draft-ietf-eppext-keyrelay-03 719 1. Updated the document title in the EPP Extension Registry section 721 2. Restored Acknowledgement section, thanks to Marco Davids 723 3. Incorperated feedback from Patrick Mevzek 725 A.9. draft-ietf-eppext-keyrelay-04 727 1. Incorperated feedback from James Gould 729 2. Added additional text when server is aware that receiving clients 730 do not support keyrelay transactions or DNSSEC as suggested by 731 Kees Monshouwer. 733 3. Added additional text for supporting key revocation as suggested 734 by Kees Monshouwer 736 4. Updated some of the wording 738 5. Fix the usage of multiple keys in a create message 740 A.10. draft-ietf-eppext-keyrelay-05 742 1. Review comments after WG last call 744 A.11. draft-ietf-eppext-keyrelay-06 746 1. Review comments by Ulrich Wisser during IESG writeup 748 A.12. draft-ietf-eppext-keyrelay-07 750 1. fixed changelog 752 A.13. draft-ietf-eppext-keyrelay-08 754 1. fixed issue with authinfo 756 2. fixed issue with relative period in example xml 758 A.14. draft-ietf-eppext-keyrelay-09 760 1. fixed issue with naming 762 A.15. draft-ietf-eppext-keyrelay-10 764 1. removed 4 spaces 766 A.16. draft-ietf-eppext-keyrelay-11 768 1. Processed editorial changes from AD review 770 2. Processed comments made during IETF last call 772 Authors' Addresses 774 Rik Ribbers 775 SIDN 776 Meander 501 777 Arnhem 6825 MD 778 NL 780 Email: rik.ribbers@sidn.nl 781 URI: https://www.sidn.nl/ 783 Marc Groeneweg 784 SIDN 785 Meander 501 786 Arnhem 6825 MD 787 NL 789 Email: marc.groeneweg@sidn.nl 790 URI: https://www.sidn.nl/ 791 Miek Gieben 793 Email: miek@miek.nl 795 Antoin Verschuren 797 Email: ietf@antoin.nl