idnits 2.17.1 draft-faltstrom-uri-06.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3404, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3959, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: One SHOULD not include userinfo (see User Information, Section 3.2.1, in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record as DNS data must be viewed as publicly available information. (Using the creation date from RFC3404, updated by this document, for RFC5378 checks: 2000-07-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 11, 2010) is 4917 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) == Missing Reference: 'RFCXXXX' is mentioned on line 323, but not defined == Missing Reference: 'X' is mentioned on line 381, but not defined == Missing Reference: 'RFC3597' is mentioned on line 464, but not defined == Unused Reference: 'E164' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC4848' is defined on line 525, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Faltstrom 3 Internet-Draft Cisco 4 Updates: 3404, 3959 O. Kolkman 5 (if approved) NLNet 6 Intended status: Standards Track October 11, 2010 7 Expires: April 14, 2011 9 The Uniform Resource Identifier (URI) DNS Resource Record 10 draft-faltstrom-uri-06.txt 12 Abstract 14 This document defines a new DNS resource record, called the Uniform 15 Resource Identifier (URI) RR, for publishing mappings from hostnames 16 to URIs. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 14, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 54 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 4 55 4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 4 56 4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4 57 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 61 5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 6 62 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Homepage at one domain, but two domains in use . . . . . . 7 64 7. Relation to S-NAPTR . . . . . . . . . . . . . . . . . . . . . 7 65 8. Relation to U-NAPTR . . . . . . . . . . . . . . . . . . . . . 7 66 9. Relation to SRV . . . . . . . . . . . . . . . . . . . . . . . 8 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 10.1. Registration of the URI Resource Record Type . . . . . . . 8 69 10.2. Registration of services . . . . . . . . . . . . . . . . . 8 70 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 72 Appendix A. RRTYPE Allocation Request . . . . . . . . . . . . . . 9 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 75 13.2. Non-normative references . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 This document explains the use of the Domain Name System (DNS) for 81 the storage of URIs, and how to resolve hostnames to such URIs that 82 can be used by various applications. For resolution the application 83 need to know both the hostname and the protocol that the URI is to be 84 used for. The protocol is registered by IANA. 86 Currently, looking up URIs given a hostname uses the DDDS [RFC3401] 87 application framework with the DNS as a database as specified in RFC 88 3404 [RFC3404]. This has a number of implications such as the 89 inability to select what NAPTR records that match the query are 90 interesting. The RRSet returned will always consist of all URIs 91 "connected" with the domain in question. 93 The URI resource record specified in this document enables the 94 querying party to select which ones of the NAPTR records one is 95 interested in. This because data in the service field of the NAPTR 96 record is included in the owner part of the URI resource record type. 98 Querying for URI resource records is not replacing querying for NAPTR 99 resource records (or use of S-NAPTR [RFC3958]). Instead, the URI 100 resource record type provides a complementary mechanism to use when 101 one already knows what service field is interesting. With it, one 102 can directly query for the specific subset of the otherwise possibly 103 large RRSet given back when querying for NAPTR resource records. 105 This document updates RFC 3958 and RFC 3404 by adding the flag "D" to 106 the list of defined terminal flags in section 2.2.3 of RFC 3958 and 107 4.3 of RFC 3404. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in BCP 14, RFC 2119 112 [RFC2119]. 114 2. Applicability Statement 116 In general, it is expected that URI records will be used by clients 117 for applications where the relevant protocol to be used is known, 118 but, for example, an extra abstraction is needed in order to separate 119 a domain name from a point of service (as addressed by the URI). One 120 example of such a situation is when an organisation has many domain 121 names, but only one official web page. 123 Applications MUST know the specific service fields to prepend the 124 hostname with. Using repetitive queries for URI records MUST NOT be 125 a replacement for querying for NAPTR records according to the NAPTR 126 (DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose to 127 discover the various services and URIs for looking up access points 128 for a given service. Those are two very different kinds of needs. 130 3. DNS considerations 132 Using prefix labels, such as underscored service tags, prevents the 133 use of wildcards, as constructs as _s2._s1.*.example.net. are not 134 possible in the DNS, see RFC 4592 [RFC4592]. Besides, underscored 135 service tags used for the URI RR (based on the NAPTR service 136 descriptions) may have slightly different semantics than service tags 137 used for underscored prefix labels that are used in combination with 138 other (yet unspecified) RR types. This may cause subtle management 139 problems when delegation structure that has developed within the 140 context of URI RRs is also to be used for other RR types. Since the 141 service labels might be overloaded, applications should carefully 142 check that the application level protocol is indeed the protocol they 143 expect. 145 Subtle management issues may also arise when the delegations from 146 service to sub service label involves several parties and different 147 stake holders. 149 4. The format of the URI RR 151 This is the presentation format of the URI RR: 153 Ownername TTL Class URI Priority Weight Target 155 The URI RR does not cause any kind of Additional Section processing. 157 4.1. Ownername, class and type 159 The URI ownername is subject to special conventions. 161 Just like the SRV RR [RFC2782] the URI RR has service information 162 encoded in its ownername. In order to encode the service for a 163 specific owner name one uses service parameters. Valid service 164 parameters used are those used for SRV resource records, or 165 registered by IANA for Enumservice Registrations. The Enumservice 166 Registration parameters are reversed (subtype(s) before type), 167 prepended with an underscore (_) and prepended to the owner name in 168 separate labels. The underscore is prepended to the service 169 parameters to avoid collisions with DNS labels that occur in nature, 170 and the order is reversed to make it possible to do delegations, if 171 needed, to different zones (and therefore providers of DNS). 173 It should be noted that the usage of a prefix must be described in 174 detail in for example the Enumservice Registration documentation, or 175 in a specific document that clarifies potential overload of 176 parameters in the same URI. Specifically, registered URI schemes are 177 not automatically acceptable as a service. With the HTTP scheme, one 178 can for example have multiple methods (GET, PUT, etc), and this with 179 the same URI. 181 For example, suppose we are looking for the URI for a service with 182 Service Parameter "A:B:C" for host example.com.. Then we would query 183 for (QNAME,QTYPE)=("_C._B._A.example.com","URI") 185 The type number for the URI record is TBD1 (to be assigned by IANA). 187 The URI resource record is class independent. 189 The URI RR has no special TTL requirements. 191 4.2. Priority 193 The priority of the target URI in this RR. Its range is 0-65535. A 194 client MUST attempt to contact the URI with the lowest-numbered 195 priority it can reach; URIs with the same priority SHOULD be tried in 196 the order defined by the weight field. 198 4.3. Weight 200 A server selection mechanism. The weight field specifies a relative 201 weight for entries with the same priority. Larger weights SHOULD be 202 given a proportionately higher probability of being selected. The 203 range of this number is 0-65535. 205 4.4. Target 207 The URI of the target, enclosed in double-quote characters ('"'). 208 Resolution of the URI is according to the definitions for the Scheme 209 of the URI. 211 The URI is encoded as one or more RFC1035 section 212 3.3 [RFC1035]. 214 4.5. URI RDATA Wire Format 216 The RDATA for a URI RR consists of a 2 octet Priority field, a two 217 octet Weight field, and a variable length target field. 219 Priority and Weight are unsigned integers in network byte order. 221 The Target field contains the URI (without the enclosing double- 222 quote characters used in the presentation format), encoded as a 223 sequence of one or more (as specified in section 224 3.3 of RFC 1035 [RFC1035]), where all but the last 225 are filled up to the maximum length of 255 octets. 227 The Target field can also contain an IRI, but with the additional 228 requirements that it is in UTF-8 [RFC3629] and possible to convert to 229 a URI according to section 3.1 of RFC 3987 [RFC3987] and back again 230 to an IRI according to section 3.2. Other character sets than UTF-8 231 are not allowed. The domain name part of the IRI can be either an 232 U-LABEL or A-LABEL as defined in RFC 5890 [RFC5890]. 234 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 235 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Priority | Weight | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 / / 240 / Target / 241 / / 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 5. Definition of the flag 'D' for NAPTR records 246 This document specifies the flag "D" for use as a flag in NAPTR 247 records. The flag indicate a terminal NAPTR record because it 248 denotes the end of the DDDS/NAPTR processing rules. In the case of a 249 "D" flag, the Replacement field in the NAPTR record, prepended with 250 the service flags, is used as the Owner of a DNS query for URI 251 records, and normal URI processing as defined in this document is 252 applied. 254 The replacement field MUST NOT include any of the service parameters. 255 Those are to be prepended (together with underscore) as described in 256 other places in this document. 258 The Regexp field in the NAPTR record MUST be empty when the 'D' flag 259 is in use. 261 6. Examples 263 6.1. Homepage at one domain, but two domains in use 265 An organisation has the domain names example.com and example.net, but 266 the official URI http://www.example.com/. Given the service type 267 "web" and subtype "http" (from the IANA registry), the following URI 268 Resource Records could be made available in the respective zones 269 (example.com and example.net): 271 $ORIGIN example.com. 272 _http._web IN URI 10 1 "http://www.example.com/" 274 $ORIGIN example.net. 275 _http._web IN URI 10 1 "http://www.example.com/" 277 7. Relation to S-NAPTR 279 The URI resource record type is not a replacement for the S-NAPTR. 280 It is instead an extension and the seond step of the S-NAPTR 281 resolution can resolve a URI resource record instead of using SRV 282 records and yet another algorithm for how to use SRV records for the 283 specific protocol. 285 $ORIGIN example.com. 286 ;; order pref flags 287 IN NAPTR 100 10 "s" "EM:ProtA" ( ; service 288 "" ; regexp 289 _ProtA._tcp.example.com. ; replacement 290 _ProtA._tcp IN URI "schemeA:service.example.com/example" 292 8. Relation to U-NAPTR 294 The URI Resource Record Type, together with S-NAPTR, can be viewed as 295 a replacement for the U-NAPTR. The URI Resource Record Type is 296 though only interesting when one know a base domain name, a protocol 297 and service so that one can compose the record to look up. NAPTR 298 records of any kind are used to look up what services exists for a 299 certain domain, which is one step before the URI resource record is 300 used. 302 9. Relation to SRV 304 The URI Resource Record Type can be viewed as a replacement for the 305 SRV record. This because it like the SRV record can only be looked 306 up if one know the base domain, the protocol and the service. It has 307 a similar functionality, but instead of returning a hostname and port 308 number, the URI record return a full URI. As such, it can be viewed 309 as a more powerful resource record than SRV. 311 10. IANA Considerations 313 10.1. Registration of the URI Resource Record Type 315 IANA has assigned Resource Record Type TBD1 for the URI Resource 316 Record Type and added the line depicted below to the registry named 317 Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395 318 [RFC5395] and located at 319 http://www.iana.org/assignments/dns-parameters. 321 TYPE Value and meaning Reference 322 ----------- --------------------------------------------- --------- 323 URI TBD1 a URI for a service (per the owner name) [RFCXXXX] 325 10.2. Registration of services 327 No new registry is needed for the registration of services as the 328 Enumservice Registrations registry is used also for the URI resource 329 record type. 331 11. Security Considerations 333 The authors do not believe this resource record cause any new 334 security problems. Deployment must though be done in a proper way as 335 misconfiguration of this resource record might make it impossible to 336 reach the service that was originally intended to be accessed. 338 Using the URI resource record together with security mechanisms that 339 relies on verification of authentication of hostnames, like TLS, 340 makes it important to choose the correct domain name when doing the 341 comparison. 343 The basic mechanism works as follows: 345 1. Announce the fact example.com is hosted at example.org (with 346 some URL) in DNS 347 2. Secure the URI resource record with DNSSEC. 348 3. Verify the TLS (for example) certificate for the connection to 349 example.org matches, i.e. use the hostname in the URI and not 350 the hostname used originally when looking up the URI resource 351 record. 352 4. If needed, do application layer authentication etc over the then 353 encrypted connection. 355 What also can happen is that the URI in the resource record type has 356 errors in it. Applications using the URI resource record type for 357 resolution should behave similarly as if the user typed (or copy and 358 pasted) the URI. At least it must be clear to the user that the 359 error is not due to any error from his side. 361 One SHOULD not include userinfo (see User Information, Section 3.2.1, 362 in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record 363 as DNS data must be viewed as publicly available information. 365 12. Acknowledgements 367 Ideas on how to split the two different kind of queries "What 368 services exists for this domain name" and "What is the URI for this 369 service" came from Scott Bradner and Lawrence Conroy. Other people 370 that have contributed to this document include Richard Barnes, Leslie 371 Daigle, Olafur Gudmundsson, Ted Hardie, Peter Koch and Penn Pfautz. 373 Appendix A. RRTYPE Allocation Request 375 A. Submission Date: 377 May 23, 2009 379 B. Submission Type: 381 [X] New RRTYPE 382 [ ] Modification to existing RRTYPE 384 C. Contact Information for submitter: 386 Name: Patrik Faltstrom 387 Email Address: paf@cisco.com 388 International telephone number: +46-8-6859131 389 Other contact handles: 390 (Note: This information will be publicly posted.) 392 D. Motivation for the new RRTYPE application? 394 There is no easy way to get from a domain name to a URI (or 395 IRI). Some mechanisms exists via use of the NAPTR [RFC3403] 396 resource record. That implies quite complicated rules that are 397 simplified via the S-NAPTR [RFC3958] specification. But, the 398 ability to directly look up a URI still exists. This 399 specification uses a prefix based naming mechanism originated in 400 the definition of the SRV [RFC2782] resource record, and the 401 RDATA is a URI, encoded as one text field. 403 See also above (Section 1). 405 E. Description of the proposed RR type. 407 The format of the URI resource record is as follows: 409 Ownername TTL Class URI Priority Weight Target 411 The URI RR has service information encoded in its ownername. In 412 order to encode the service for a specific owner name one uses 413 service parameters. Valid service parameters used are either 414 Enumservice Registrations registered by IANA, or prefixes used 415 for the SRV resource record. 417 The wire format of the RDATA is as follows: 419 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 420 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Priority | Weight | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 / / 425 / Target / 426 / / 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 F. What existing RRTYPE or RRTYPEs come closest to filling that 430 need and why are they unsatisfactory? 432 The RRTYPE that come closest is the NAPTR resource record. It 433 is for example used in the DDDS and S-NAPTR algorithms. The 434 main problem with the NAPTR is that selection of what record (or 435 records) one is interested in is based on data stored in the 436 RDATA portion of the NAPTR resource record. This, as explained 437 in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, 438 most applications using NAPTR resource records uses regular 439 expression based rewrite rules for creation of the URI, and that 440 has shown be complicated to implement. 442 The second closest RRTYPE is the SRV record that given a 443 prefixed based naming just like is suggested for the URI 444 resource record, one get back a port number and domain name. 445 This can also be used for creation of a URI, but, only URIs 446 without path components. 448 G. What mnemonic is requested for the new RRTYPE (optional)? 450 URI 452 H. Does the requested RRTYPE make use of any existing IANA Registry 453 or require the creation of a new IANA sub-registry in DNS 454 Parameters? 456 Yes, partially. 458 One of the mechanisms to select a service is to use the 459 Enumservice Registry managed by IANA. Another is to use 460 services and protocols used for SRV records. 462 I. Does the proposal require/expect any changes in DNS servers/ 463 resolvers that prevent the new type from being processed as an 464 unknown RRTYPE (see [RFC3597])? 466 No 468 J. Comments: 470 None 472 13. References 473 13.1. Normative References 475 [E164] ITU-T, "The International Public Telecommunication Number 476 Plan", Recommendation E.164, May 1997. 478 [RFC1035] Mockapetris, P., "Domain names - implementation and 479 specification", STD 13, RFC 1035, November 1987. 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 485 10646", STD 63, RFC 3629, November 2003. 487 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 488 Service Location Using SRV RRs and the Dynamic Delegation 489 Discovery Service (DDDS)", RFC 3958, January 2005. 491 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 492 Identifiers (IRIs)", RFC 3987, January 2005. 494 [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA 495 Considerations", BCP 42, RFC 5395, November 2008. 497 [RFC5890] Klensin, J., "Internationalized Domain Names for 498 Applications (IDNA): Definitions and Document Framework", 499 RFC 5890, August 2010. 501 13.2. Non-normative references 503 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 504 specifying the location of services (DNS SRV)", RFC 2782, 505 February 2000. 507 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 508 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 510 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 511 Part Three: The Domain Name System (DNS) Database", 512 RFC 3403, October 2002. 514 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 515 Part Four: The Uniform Resource Identifiers (URI)", 516 RFC 3404, October 2002. 518 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 519 Resource Identifier (URI): Generic Syntax", STD 66, 520 RFC 3986, January 2005. 522 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 523 System", RFC 4592, July 2006. 525 [RFC4848] Daigle, L., "Domain-Based Application Service Location 526 Using URIs and the Dynamic Delegation Discovery Service 527 (DDDS)", RFC 4848, April 2007. 529 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 530 Choices When Expanding the DNS", RFC 5507, April 2009. 532 Authors' Addresses 534 Patrik Faltstrom 535 Cisco Systems 537 Email: paf@cisco.com 539 Olaf Kolkman 540 NLnet Labs 542 Email: olaf@NLnetLabs.nl