RFC 8495

Allocation Token Extension for the Extensible Provisioning Protocol (EPP)

📅 published November 2018, from ietf

RFC 8495 💖 Allocation Token Extension for EPP

Allocation Token Extension for the Extensible Provisioning Protocol (EPP) 🎀

Okay bestie, here's the quick intel before we dive in ✨

  • Organization: Internet Engineering Task Force (IETF) 🌈
  • Category: Standards Track 👑 (this is a real Internet Standard, so it's serious business)
  • Authors: J. Gould (VeriSign, Inc.) and K. Feher (Neustar) 🫶
  • Date: November 2018 🍓
  • ISSN: 2070-1721
  • Obsoletes / Updates: the title block doesn't list any, so this one isn't replacing or updating another document 🦋

Abstract ✨

Okay so this doc is an Extensible Provisioning Protocol (EPP) extension that lets you include an Allocation Token in "query" and "transform" commands 💅 The token is basically a credential that says "yep, this client is allowed to request a specific object from the server." It's used with EPP transform commands, like "create" and "transfer," to get that allocation done 🔥

Status of This Memo 🌸

This is an Internet Standards Track document 💜

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨ Want more info on Internet Standards? Check out Section 2 of RFC 7841 🧚

For the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8495.

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can read at https://trustee.ietf.org/license-info (the version in effect on the publication date). Please actually read these, bestie, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License says 💅

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
2.  Object Attributes . . . . . . . . . . . . . . . . . . . . . .   3
  2.1.  Allocation Token  . . . . . . . . . . . . . . . . . . . .   4
3.  EPP Command Mapping . . . . . . . . . . . . . . . . . . . . .   4
  3.1.  EPP Query Commands  . . . . . . . . . . . . . . . . . . .   4
    3.1.1.  EPP <check> Command . . . . . . . . . . . . . . . . .   4
    3.1.2.  EPP <info> Command  . . . . . . . . . . . . . . . . .   8
    3.1.3.  EPP <transfer> Query Command  . . . . . . . . . . . .  10
  3.2.  EPP Transform Commands  . . . . . . . . . . . . . . . . .  11
    3.2.1.  EPP <create> Command  . . . . . . . . . . . . . . . .  11
    3.2.2.  EPP <delete> Command  . . . . . . . . . . . . . . . .  12
    3.2.3.  EPP <renew> Command . . . . . . . . . . . . . . . . .  12
    3.2.4.  EPP <transfer> Command  . . . . . . . . . . . . . . .  12
    3.2.5.  EPP <update> Command  . . . . . . . . . . . . . . . .  13
4.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .  14
  4.1.  Allocation Token Extension Schema . . . . . . . . . . . .  14
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
  5.1.  XML Namespace . . . . . . . . . . . . . . . . . . . . . .  15
  5.2.  EPP Extension Registry  . . . . . . . . . . . . . . . . .  15
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  17
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction 🌸

Okay so this is an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730] 💖 It works like an extension to EPP object mappings, similar to the EPP domain name mapping [RFC5731]. It lets you pass an Allocation Token as a credential, which authorizes a client to request the allocation of a specific object from the server using one of the EPP transform commands, including "create" and "transfer" ✨

So what's "allocation" anyway? It's when a server assigns the sponsoring client of an object based on an Allocation Token credential 🦋 Some examples:

  • allocating a registration based on a pre-eligibility Allocation Token 🌈
  • allocating a premium domain name registration based on an auction Allocation Token 💅
  • allocating a registration based on a founders Allocation Token 👑
  • allocating an existing domain name held by the server or by a different sponsoring client, based on an Allocation Token that's passed with a transfer command 🔥

Clients pass the Allocation Token to the server for validation, and the server figures out whether it's one it supports 🧚 Which EPP transform commands and which objects need the token is up to server policy, so it's not one-size-fits-all bestie 🙈 The Allocation Token MAY be returned to an authorized client, so they can pass it out-of-band to a client that uses it with an EPP transform command 🫶

1.1. Conventions Used in This Document 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀

Okay, the XML part: XML is case sensitive 💅 Unless stated otherwise, the XML specs and examples in this document MUST be interpreted in the character case presented, so you can build a conforming implementation 🌸

In the examples, "C:" is lines sent by a protocol client and "S:" is lines returned by a protocol server 🧚 The indentation and white space are only there to show how the elements relate, and they are not REQUIRED in the protocol. Not a big deal, bestie ✨

The XML namespace prefix allocationToken is used for the namespace urn:ietf:params:xml:ns:allocationToken-1.0, but implementations MUST NOT depend on the prefix. Instead, use a proper namespace-aware XML parser and serializer to read and write the XML documents 🌈 (Prefixes are not the vibe to rely on, iykyk 💀)

The abc123 token value is a placeholder in the examples. The server MUST support token values that follow the Security Considerations (Section 6) 🦋

The domain-object attribute values in the examples, including the 2fooBAR <domain:pw> value, are for illustration only 🍓 If you want the details on domain-object attributes, check [RFC5731] 🫶

2. Object Attributes 🎀

This extension adds extra elements to EPP object mappings, similar to the EPP domain name mapping [RFC5731] 💖 Only those new elements are described here, so no need to re-learn the whole thing 💅

2.1. Allocation Token 🦋

The Allocation Token is a simple XML "token" type ✨ The exact format is up to server policy 👑 The server MAY have the Allocation Token for each object, so it can match against the token the client passes in to authorize allocating that object 🔥

The <allocationToken:allocationToken> element is used for all of the supported EPP commands, plus the info response 🌈 If the supplied Allocation Token doesn't apply to the object, the server MUST return an EPP error result code of 2201. Big ouch, but that's the rule 💀

Now here's the tea 🍵 Authorization information, similar to what's defined in the EPP domain name mapping [RFC5731], is attached to objects to make transfers work 🧚 It gets assigned when the object is created. Both the Allocation Token and the authorization information are credentials, but they're for different jobs and work in different ways 💜

The Allocation Token is used to allocate an object instead of transferring its sponsorship 🌸 The client doesn't manage it. Instead, the server validates it to authorize assigning the initial sponsoring client of the object 🎀 It's giving "server is the bouncer" energy ✨

Here's an example <allocationToken:allocationToken> element with the value "abc123":

<allocationToken:allocationToken xmlns:allocationToken=
          "urn:ietf:params:xml:ns:allocationToken-1.0">
  abc123
</allocationToken:allocationToken>

3. EPP Command Mapping 🌈

A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730] 🫶 Go read that if you want the deep dive, bestie 🧚

3.1. EPP Query Commands 🔥

EPP gives you three commands to retrieve object information 💅 <check> figures out if an object can be provisioned, <info> gets the information associated with an object, and <transfer> gets object-transfer status information 👑

Okay, that's the first half of the doc, babe 💖 The command-by-command details are coming up next, and they are literally where the Allocation Token gets to shine 🦋

3.1.1. EPP <check> Command ✨

okay so this extension adds extra bits to the EPP <check> command for an object mapping, kinda like the one in [RFC5731] 🎀

It lets clients check if an object is available with an Allocation Token (see Section 2.1) 🔑 basically you're asking "could I actually make this with my token?" The Allocation Token gets applied to every object name in the <check> command 💖

Here's an example for allocation.example using the <allocationToken:allocationToken> extension with the token 'abc123':

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <check>
C:      <domain:check
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>allocation.example</domain:name>
C:      </domain:check>
C:    </check>
C:    <extension>
C:      <allocationToken:allocationToken
C:        xmlns:allocationToken=
C:          "urn:ietf:params:xml:ns:allocationToken-1.0">
C:        abc123
C:      </allocationToken:allocationToken>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

If the query worked, the server replies with a <check> response showing the availability status of the object, based on these Allocation Token cases where the object is otherwise available 💅

  1. If an object requires an Allocation Token and the Allocation Token does apply to the object, then the server MUST return the availability status as available (e.g., the "avail" attribute is "1" or "true").
  2. If an object requires an Allocation Token and the Allocation Token does not apply to the object, then the server SHOULD return the availability status as unavailable (e.g., the "avail" attribute is "0" or "false").
  3. If an object does not require an Allocation Token, the server MAY return the availability status as available (e.g., the "avail" attribute is "1" or "true").

Here's an example <check> domain response for a <check> command using the <allocationToken:allocationToken> extension:

S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S:  <result code="1000">
S:   <msg lang="en-US">Command completed successfully</msg>
S:  </result>
S:  <resData>
S:   <domain:chkData
S:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:    <domain:cd>
S:     <domain:name avail="1">allocation.example</domain:name>
S:    </domain:cd>
S:   </domain:chkData>
S:  </resData>
S:  <trID>
S:   <clTRID>ABC-DEF-12345</clTRID>
S:   <svTRID>54321-XYZ</svTRID>
S:  </trID>
S: </response>
S:</epp>

Here's an example <check> command with the <allocationToken:allocationToken> extension for the allocation.example and allocation2.example domain names. Availability of allocation.example and allocation2.example domain names are based on the Allocation Token 'abc123':

C:<?xml version="1.0" encoding="UTF-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C:  <check>
C:   <domain:check
C:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:    <domain:name>allocation.example</domain:name>
C:    <domain:name>allocation2.example</domain:name>
C:   </domain:check>
C:  </check>
C:  <extension>
C:   <allocationToken:allocationToken
C:     xmlns:allocationToken=
C:       "urn:ietf:params:xml:ns:allocationToken-1.0">
C:     abc123
C:   </allocationToken:allocationToken>
C:  </extension>
C:  <clTRID>ABC-DEF-12345</clTRID>
C: </command>
C:</epp>

And here's an example <check> domain response for multiple domain names in the <check> command using the <allocationToken:allocationToken> extension, where the Allocation Token 'abc123' matches allocation.example but does not match allocation2.example:

S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S:  <result code="1000">
S:   <msg lang="en-US">Command completed successfully</msg>
S:  </result>
S:  <resData>
S:   <domain:chkData
S:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:    <domain:cd>
S:     <domain:name avail="1">allocation.example</domain:name>
S:    </domain:cd>
S:    <domain:cd>
S:     <domain:name avail="0">allocation2.example</domain:name>
S:     <domain:reason>Allocation Token mismatch</domain:reason>
S:    </domain:cd>
S:   </domain:chkData>
S:  </resData>
S:  <trID>
S:   <clTRID>ABC-DEF-12345</clTRID>
S:   <svTRID>54321-XYZ</svTRID>
S:  </trID>
S: </response>
S:</epp>

This extension doesn't add any elements to the EPP <check> response described in [RFC5730] 🌸

3.1.2. EPP <info> Command ✨

This extension adds extra bits to the EPP <info> command for an object mapping, similar to the mapping in [RFC5731] 🦋

The EPP <info> command lets a client ask for information about an existing object. Authorized clients MAY retrieve the Allocation Token (Section 2.1) along with the rest of the object info by putting the <allocationToken:info> element in the command 🫶 That element is empty, and it's basically a marker telling the server to include the <allocationToken:allocationToken> element in the info response. If the client isn't authorized to receive the Allocation Token, the server MUST return an EPP error result code of 2201 😭 If the client is authorized but there's no Allocation Token associated with the object, the server MUST return an EPP error result code of 2303. Whether someone is authorized is up to server policy 🔥

Here's an example <info> command with the allocationToken:info extension for the allocation.example domain name:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:   <info>
C:    <domain:info
C:      xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:      <domain:name>allocation.example</domain:name>
C:    </domain:info>
C:   </info>
C:   <extension>
C:      <allocationToken:info
C:        xmlns:allocationToken=
C:          "urn:ietf:params:xml:ns:allocationToken-1.0"/>
C:   </extension>
C:   <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

If the query worked, the server replies with an <allocationToken:allocationToken> element alongside the regular EPP <resData>. The <allocationToken:allocationToken> element is described in Section 2.1 ✨

Here's an example <info> domain response using the <allocationToken:allocationToken> extension:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <domain:infData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name>allocation.example</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:status s="pendingCreate"/>
S:        <domain:registrant>jd1234</domain:registrant>
S:        <domain:contact type="admin">sh8013</domain:contact>
S:        <domain:contact type="tech">sh8013</domain:contact>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crID>ClientY</domain:crID>
S:        <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
S:        <domain:authInfo>
S:          <domain:pw>2fooBAR</domain:pw>
S:        </domain:authInfo>
S:      </domain:infData>
S:    </resData>
S:    <extension>
S:      <allocationToken:allocationToken
S:        xmlns:allocationToken=
S:          "urn:ietf:params:xml:ns:allocationToken-1.0">
S:        abc123
S:      </allocationToken:allocationToken>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

3.1.3. EPP <transfer> Query Command ✨

This extension doesn't add any elements to the EPP <transfer> query command or the <transfer> query response described in [RFC5730] 🧚

3.2. EPP Transform Commands 💅

EPP has five commands for transforming objects: <create> to make an instance of an object, <delete> to delete an instance of an object, <renew> to extend an object's validity period, <transfer> to manage sponsorship changes for an object, and <update> to change the information associated with an object 🌈

3.2.1. EPP <create> Command ✨

This extension adds extra bits to the EPP <create> command for an object mapping, similar to the mapping in [RFC5731] 🎀

The EPP <create> command is a transform operation that lets a client create an instance of an object. On top of the EPP command elements from an object mapping similar to the one in [RFC5731], the command MUST contain a child <allocationToken:allocationToken> element so the client is authorized to create and allocate the object 🔑 If the Allocation Token doesn't apply to the object, the server MUST return an EPP error result code of 2201 💀

Here's an example <create> command to create a domain object with an Allocation Token:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <create>
C:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>allocation.example</domain:name>
C:        <domain:registrant>jd1234</domain:registrant>
C:        <domain:contact type="admin">sh8013</domain:contact>
C:        <domain:contact type="tech">sh8013</domain:contact>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <allocationToken:allocationToken
C:        xmlns:allocationToken=
C:          "urn:ietf:params:xml:ns:allocationToken-1.0">
C:        abc123
C:      </allocationToken:allocationToken>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

This extension doesn't add any elements to the EPP <create> response described in [RFC5730] 🫶

3.2.2. EPP <delete> Command ✨

This extension doesn't add any elements to the EPP <delete> command or <delete> response described in [RFC5730] 🌸

3.2.3. EPP <renew> Command ✨

This extension doesn't add any elements to the EPP <renew> command or <renew> response described in [RFC5730] 🦋

3.2.4. EPP <transfer> Command

okay bestie, the <transfer> command gets an extension too 🦋 It follows the same vibe as the object mapping in [RFC5731], so if you've seen that one you're already halfway there ✨

The EPP <transfer> command is a transform operation that lets a client ask for an object to be transferred. On top of the usual EPP command elements from an object mapping similar to [RFC5731], the command MUST contain a child <allocationToken:allocationToken> element so the client is authorized to transfer and allocate the object 🔐 The Allocation Token check is in addition to the authorization already defined for the object's <transfer> command. It doesn't replace it, so think of it as a second check, not a swap 💅 If the Allocation Token is invalid or not required for the object, the server MUST return an EPP error result code of 2201. no cap, that's a hard rule 🚫

Here's an example <transfer> command that allocates the domain object with the Allocation Token 🎀

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <transfer op="request">
C:      <domain:transfer
C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example1.tld</domain:name>
C:        <domain:period unit="y">1</domain:period>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:transfer>
C:    </transfer>
C:    <extension>
C:      <allocationToken:allocationToken
C:        xmlns:allocationToken=
C:          "urn:ietf:params:xml:ns:allocationToken-1.0">
C:        abc123
C:      </allocationToken:allocationToken>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

This extension does not add any elements to the EPP <transfer> response described in [RFC5730]. Nothing new to see there 🌸

3.2.5. EPP <update> Command

This one's a chill little section 🧚 This extension does not add any elements to the EPP <update> command or <update> response described in [RFC5730]. Literally nothing extra, periodt 💅

4. Formal Syntax ✨

okay so this part is the schema, and it's giving very official 🎀 There's one schema in here: the EPP Allocation Token Extension schema. It's a complete schema representation of the object mapping, so automated validation of EPP XML instances can use it 🤖 The BEGIN and END tags aren't part of the schema. They're just there to mark where it starts and ends for URI registration purposes 🏷️

4.1. Allocation Token Extension Schema

Here's the whole thing, verbatim:

BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
  xmlns:allocationToken="urn:ietf:params:xml:ns:allocationToken-1.0"
  targetNamespace="urn:ietf:params:xml:ns:allocationToken-1.0"
  elementFormDefault="qualified">
  <annotation>
    <documentation>
      Extensible Provisioning Protocol v1.0
      Allocation Token Extension
    </documentation>
  </annotation>

  <!-- Element used in info command to get allocation token. -->
  <element name="info">
    <complexType>
      <complexContent>
        <restriction base="anyType" />
      </complexContent>
    </complexType>
  </element>

  <!-- Allocation Token used in transform
    commands and info response -->
  <element name="allocationToken"
    type="allocationToken:allocationTokenType" />
  <simpleType name="allocationTokenType">
    <restriction base="token">
      <minLength value="1" />
    </restriction>
  </simpleType>

<!-- End of schema. -->
</schema>
END

5. IANA Considerations 🌈

5.1. XML Namespace

okay so this part is about registering the XML namespace and schema, using URNs as described in [RFC3688] 💜 The allocationToken namespace got registered like this:

URI: urn:ietf:params:xml:ns:allocationToken-1.0
Registrant Contact: IESG
XML: None.  Namespace URIs do not represent an XML specification.

And the allocationToken XML schema got registered like this:

URI: urn:ietf:params:xml:schema:allocationToken-1.0
Registrant Contact: IESG
XML: See the "Formal Syntax" section of this document.

5.2. EPP Extension Registry

The following entry was added to the Extensions for the Extensible Provisioning Protocol (EPP) registry, as described in [RFC7451] 🎀

  • Name of Extension: Allocation Token Extension for the Extensible Provisioning Protocol (EPP)
  • Document Status: Standards Track
  • Reference: RFC 8495
  • Registrant: IESG <iesg@ietf.org>
  • TLDs: Any
  • IPR Disclosure: None
  • Status: Active
  • Notes: None

6. Security Considerations 🔐

okay bestie, this section is SERIOUS. Read it like it's your group chat's most important message 💀

The mapping in this document doesn't provide any security services beyond the ones described by EPP [RFC5730] and the protocol layers EPP uses. The security considerations in those other specifications apply here too 🧱

The mapping is basically a conduit for passing Allocation Tokens between a client and a server 🚇 The definition of the Allocation Token SHOULD be defined outside of this mapping. These are the security considerations for defining and using an Allocation Token:

  1. An Allocation Token should be considered secret information by the client. It SHOULD be protected at rest and MUST be protected in transit 🤫
  2. An Allocation Token should be single use, meaning it should be unique per object and per allocation operation 🦋
  3. An Allocation Token should have a limited life with some form of expiry in the Allocation Token if it's generated by a trusted third party, or with a server-side expiry if it's generated by the server ⏳
  4. An Allocation Token should use a strong random value if it's based on an unsigned code 🎲
  5. An Allocation Token should leverage digital signatures to confirm its authenticity if it's generated by a trusted third party ✍️
  6. An Allocation Token that is signed XML should be encoded (e.g., base64 [RFC4648]) to mitigate server validation issues 🧁

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgements 🫶

The authors wanted to acknowledge the original concept for this document, plus the work on the early draft versions by Trung Tran and Sharon Wodjenski 🌸

Special suggestions that went into this document came from Ben Campbell, Scott Hollenbeck, Benjamin Kaduk, Mirja Kuehlewind, Rubens Kuhl, Alexander Mayrhofer, Patrick Mevzek, Eric Rescoria, and Adam Roach 💖

Authors' Addresses 🎀

James Gould
VeriSign, Inc.
12061 Bluemont Way
Reston, VA  20190
United States of America

Email: jgould@verisign.com
URI:   http://www.verisign.com
Kal Feher
Neustar
lvl 8/10 Queens Road
Melbourne, VIC  3004
Australia

Email: ietf@feherfamily.org
URI:   http://www.neustar.biz
📦 where this page comes from