doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc8117.txt b/doc/rfc/rfc8117.txt
new file mode 100644
index 0000000..fa6907c
--- /dev/null
+++ b/doc/rfc/rfc8117.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        C. Huitema
+Request for Comments: 8117                          Private Octopus Inc.
+Category: Informational                                        D. Thaler
+ISSN: 2070-1721                                                Microsoft
+                                                               R. Winter
+                                 University of Applied Sciences Augsburg
+                                                              March 2017
+
+
+              Current Hostname Practice Considered Harmful
+
+Abstract
+
+   Giving a hostname to your computer and publishing it as you roam from
+   one network to another is the Internet's equivalent of walking around
+   with a name tag affixed to your lapel.  This current practice can
+   significantly compromise your privacy, and something should change in
+   order to mitigate these privacy threats.
+
+   There are several possible remedies, such as fixing a variety of
+   protocols or avoiding disclosing a hostname at all.  This document
+   describes some of the protocols that reveal hostnames today and
+   sketches another possible remedy, which is to replace static
+   hostnames by frequently changing randomized values.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8117.
+
+
+
+
+
+
+
+
+
+
+
+Huitema, et al.               Informational                     [Page 1]
+
+RFC 8117                Harmful Hostname Practice             March 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Naming Practices  . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Partial Identifiers . . . . . . . . . . . . . . . . . . . . .   4
+   4.  Protocols That Leak Hostnames . . . . . . . . . . . . . . . .   5
+     4.1.  DHCP  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
+     4.2.  DNS Address to Name Resolution  . . . . . . . . . . . . .   5
+     4.3.  Multicast DNS . . . . . . . . . . . . . . . . . . . . . .   6
+     4.4.  Link-Local Multicast Name Resolution  . . . . . . . . . .   6
+     4.5.  DNS-Based Service Discovery . . . . . . . . . . . . . . .   7
+     4.6.  NetBIOS-over-TCP  . . . . . . . . . . . . . . . . . . . .   7
+   5.  Randomized Hostnames as a Remedy  . . . . . . . . . . . . . .   8
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
+   8.  Informative References  . . . . . . . . . . . . . . . . . . .   9
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huitema, et al.               Informational                     [Page 2]
+
+RFC 8117                Harmful Hostname Practice             March 2017
+
+
+1.  Introduction
+
+   There is a long established practice of giving names to computers.
+   In the Internet protocols, these names are referred to as "hostnames"
+   [RFC7719].  Hostnames are normally used in conjunction with a domain
+   name suffix to build the Fully Qualified Domain Name (FQDN) of a host
+   [RFC1983].  However, it is common practice to use the hostname
+   without further qualification in a variety of applications from file
+   sharing to network management.  Hostnames are typically published as
+   part of domain names and can be obtained through a variety of name
+   lookup and discovery protocols.
+
+   Hostnames have to be unique within the domain in which they are
+   created and used.  They do not have to be globally unique
+   identifiers, but they will always be at least partial identifiers, as
+   discussed in Section 3.
+
+   The disclosure of information through hostnames creates a problem for
+   mobile devices.  Adversaries that monitor a remote network such as a
+   Wi-Fi hot spot can obtain the hostname through passive monitoring or
+   active probing of a variety of Internet protocols, such as DHCP or
+   Multicast DNS (mDNS).  They can correlate the hostname with various
+   other information extracted from traffic analysis and other
+   information sources, and they can potentially identify the device,
+   device properties, and its user [TRAC2016].
+
+2.  Naming Practices
+
+   There are many reasons to give names to computers.  This is
+   particularly true when computers operate on a network.  Operating
+   systems like Microsoft Windows or Unix assume that computers have a
+   "hostname."  This enables users and administrators to do things such
+   as ping a computer, add its name to an access control list, remotely
+   mount a computer disk, or connect to the computer through tools such
+   as telnet or remote desktop.  Other operating systems maintain
+   multiple hostnames for different purposes, e.g., for use with certain
+   protocols such as mDNS.
+
+   In most consumer networks, naming is pretty much left to the
+   discretion of the user.  Some will pick names of planets or stars,
+   others will pick names of fruits or flowers, and still others will
+   pick whatever suits their mood when they unwrap the device.  As long
+   as users are careful to not pick a name already in use on the same
+   network, anything goes.  Very often, however, the operating system
+   suggests a hostname at the time of installation, which can contain
+   the user name, the login name, and information learned from the
+   device itself such as the brand, model, or maker of the device
+   [TRAC2016].
+
+
+
+Huitema, et al.               Informational                     [Page 3]
+
+RFC 8117                Harmful Hostname Practice             March 2017
+
+
+   In large organizations, collisions are more likely and a more
+   structured approach is necessary.  In theory, organizations could use
+   multiple DNS subdomains to ease the pressure on uniqueness, but in
+   practice many don't and insist on unique flat names, if only to
+   simplify network management.  To ensure unique names, organizations
+   will set naming guidelines and enforce some kind of structured
+   naming.  For example, within the Microsoft corporate network,
+   computer names are derived from the login name of the main user,
+   which leads to names like "huitema-test2" for a machine that one of
+   the authors used to test software.
+
+   There is less pressure to assign names to small devices including,
+   for example, smart phones, as these devices typically do not enable
+   sharing of their disks or remote login.  As a consequence, these
+   devices often have manufacturer-assigned names, which vary from
+   generic names like "Windows Phone" to completely unique names like
+   "BrandX-123456-7890-abcdef" and often contain the name of the device
+   owner, the device's brand name, and often also a hint as to which
+   language the device owner speaks [TRAC2016].
+
+3.  Partial Identifiers
+
+   Suppose an adversary wants to track the people connecting to a
+   specific Wi-Fi hot spot, for example, in a railroad station.  Assume
+   that the adversary is able to retrieve the hostname used by a
+   specific laptop.  That, in itself, might not be enough to identify
+   the laptop's owner.  Suppose, however, that the adversary observes
+   that the laptop name is "dthaler-laptop" and that the laptop has
+   established a VPN connection to the Microsoft corporate network.  The
+   two pieces of information, put together, firmly point to Dave Thaler,
+   employed by Microsoft.  The identification is successful.
+
+   In the example, we saw a login name inside the hostname, and that
+   certainly helped identification.  But generic names like "jupiter" or
+   "rosebud" also provide partial identification, especially if the
+   adversary is capable of maintaining a database recording, among other
+   information, the hostnames of devices used by specific users.
+   Generic names are picked from vocabularies that include thousands of
+   potential choices.  Finding the name reduces the scope of the search
+   significantly.  Other information such as the visited sites will
+   quickly complement that data and can lead to user identification.
+
+   Also, the special circumstances of the network can play a role.
+   Experiments on operational networks such as the IETF meeting network
+   have shown that, with the help of external data such as the publicly
+   available IETF attendees list or other data sources such as
+
+
+
+
+
+Huitema, et al.               Informational                     [Page 4]
+
+RFC 8117                Harmful Hostname Practice             March 2017
+
+
+   Lightweight Directory Access Protocol (LDAP) servers on the network
+   [TRAC2016], the identification of the device owner can become trivial
+   given only partial identifiers in a hostname.
+
+   Unique names assigned by manufacturers do not directly encode a user
+   identifier, but they have the property of being stable and unique to
+   the device in a large context.  A unique name like "BrandX-
+   123456-7890-abcdef" allows efficient tracking across multiple
+   domains.  In theory, this only allows tracking of the device but not
+   of the user.  However, an adversary could correlate the device to the
+   user through other means, for example, the one-time capture of some
+   cleartext traffic.  Adversaries could then maintain databases linking
+   a unique hostname to a user identity.  This will allow efficient
+   tracking of both the user and the device.
+
+4.  Protocols That Leak Hostnames
+
+   Many IETF protocols can leak the "hostname" of a computer.  A non-
+   exhaustive list includes DHCP, DNS address to name resolution,
+   Multicast DNS, Link-local Multicast Name Resolution, and DNS service
+   discovery.
+
+4.1.  DHCP
+
+   Shortly after connecting to a new network, a host can use DHCP
+   [RFC2131] to acquire an IPv4 address and other parameters [RFC2132].
+   A DHCP query can disclose the "hostname."  DHCP traffic is sent to
+   the broadcast address and can be easily monitored, enabling
+   adversaries to discover the hostname associated with a computer
+   visiting a particular network.  DHCPv6 [RFC3315] shares similar
+   issues.
+
+   The problems with the hostname and FQDN parameters in DHCP are
+   analyzed in [RFC7819] and [RFC7824].  Possible mitigations are
+   described in [RFC7844].
+
+4.2.  DNS Address to Name Resolution
+
+   The domain name service design [RFC1035] includes the specification
+   of the special domain "in-addr.arpa" for resolving the name of the
+   computer using a particular IPv4 address, using the PTR format
+   defined in [RFC1033].  A similar domain, "ip6.arpa", is defined in
+   [RFC3596] for finding the name of a computer using a specific IPv6
+   address.
+
+   Adversaries who observe a particular address in use on a specific
+   network can try to retrieve the PTR record associated with that
+   address and thus the hostname of the computer, or even the FQDN of
+
+
+
+Huitema, et al.               Informational                     [Page 5]
+
+RFC 8117                Harmful Hostname Practice             March 2017
+
+
+   that computer.  The retrieval may not be useful in many IPv4 networks
+   due to the prevalence of NAT, but it could work in IPv6 networks.
+   Other name lookup mechanisms, such as [RFC4620], share similar
+   issues.
+
+4.3.  Multicast DNS
+
+   Multicast DNS (mDNS) is defined in [RFC6762].  It enables hosts to
+   send DNS queries over multicast and to elicit responses from hosts
+   participating in the service.
+
+   If an adversary suspects that a particular host is present on a
+   network, the adversary can send mDNS requests to find, for example,
+   the A or AAAA records associated with the hostname in the ".local"
+   domain.  A positive reply will confirm the presence of the host.
+
+   When a new responder starts, it must send a set of multicast queries
+   to verify that the name that it advertises is unique on the network
+   and to populate the caches of other mDNS hosts.  Adversaries can
+   monitor this traffic and discover the hostname of computers as they
+   join the monitored network.
+
+   mDNS further allows queries to be sent via unicast to port 5353.  An
+   adversary might decide to use unicast instead of multicast in order
+   to hide from, e.g., intrusion detection systems.
+
+4.4.  Link-Local Multicast Name Resolution
+
+   Link-Local Multicast Name Resolution (LLMNR) is defined in [RFC4795].
+   The specification did not achieve consensus as an IETF standard, but
+   it is widely deployed.  Like mDNS, it enables hosts to send DNS
+   queries over multicast and to elicit responses from computers
+   implementing the LLMNR service.
+
+   Like mDNS, LLMNR can be used by adversaries to confirm the presence
+   of a specific host on a network by issuing a multicast request to
+   find the A or AAAA records associated with the hostname in the
+   ".local" domain.
+
+   When an LLMNR responder starts, it sends a set of multicast queries
+   to verify that the name that it advertises is unique on the network.
+   Adversaries can monitor this traffic and discover the hostname of
+   computers as they join the monitored network.
+
+
+
+
+
+
+
+
+Huitema, et al.               Informational                     [Page 6]
+
+RFC 8117                Harmful Hostname Practice             March 2017
+
+
+4.5.  DNS-Based Service Discovery
+
+   DNS-based Service Discovery (DNS-SD) is described in [RFC6763].  It
+   enables participating hosts to retrieve the location of services
+   proposed by other hosts.  It can be used with DNS servers or in
+   conjunction with mDNS in a serverless environment.
+
+   Participating hosts publish a service described by an "instance
+   name", which is typically chosen by the user responsible for the
+   publication.  While this is obviously an active disclosure of
+   information, privacy aspects can be mitigated by user control.
+   Services should only be published when deciding to do so, and the
+   information disclosed in the service name should be well under the
+   control of the device's owner.
+
+   In theory, there should not be any privacy issue, but in practice the
+   publication of a service also forces the publication of the hostname
+   due to a chain of dependencies.  The service name is used to publish
+   a PTR record announcing the service.  The PTR record typically points
+   to the service name in the local domain.  The service names, in turn,
+   are used to publish TXT records describing service parameters and SRV
+   records describing the service location.
+
+   SRV records are described in [RFC2782].  Each record contains four
+   parameters: priority, weight, port number, and hostname.  While the
+   service name published in the PTR record is chosen by the user, the
+   "hostname" in the SRV record is indeed the hostname of the device.
+
+   Adversaries can monitor the mDNS traffic associated with DNS-SD and
+   retrieve the hostname of computers advertising any service with DNS-
+   SD.
+
+4.6.  NetBIOS-over-TCP
+
+   Amongst other things, NetBIOS-over-TCP [RFC1002] implements a name
+   registration and resolution mechanism called the NetBIOS Name
+   Service.  In practice, NetBIOS resource names are often based on
+   hostnames.
+
+   NetBIOS allows an application to register resource names and to
+   resolve such names to IP addresses.  In environments without a
+   NetBIOS Name Server, the protocol makes extensive use of broadcasts
+   from which resource names can be easily extracted.  NetBIOS also
+   allows querying for the names registered by a node directly (node
+   status).
+
+
+
+
+
+
+Huitema, et al.               Informational                     [Page 7]
+
+RFC 8117                Harmful Hostname Practice             March 2017
+
+
+5.  Randomized Hostnames as a Remedy
+
+   There are several ways to remedy the hostname practices.  We could
+   instruct people to just turn off any protocol that leaks hostnames,
+   at least when they visit some "insecure" place.  We could also
+   examine each particular standard that publishes hostnames and somehow
+   fix the corresponding protocols.  Or, we could attempt to revise the
+   way devices manage the hostname parameter.
+
+   There is a lot of merit in turning off unneeded protocols when
+   visiting insecure places.  This amounts to attack-surface reduction
+   and is clearly beneficial -- this is an advantage of the stealth mode
+   defined in [RFC7288].  However, there are two issues with this
+   advice.  First, it relies on recognizing which networks are secure or
+   insecure.  This is hard to automate, but relying on end-user judgment
+   may not always provide good results.  Second, some protocols such as
+   DHCP cannot be turned off without losing connectivity, which limits
+   the value of this option.  Also, the services that rely on protocols
+   that leak hostnames such as mDNS will not be available when switched
+   off.  In addition, not always are hostname-leaking protocols well-
+   known, as they might be proprietary and come with an installed
+   application instead of being provided by the operating system.
+
+   It may be possible in many cases to examine a protocol and prevent it
+   from leaking hostnames.  This is, for example, what is attempted for
+   DHCP in [RFC7844].  However, it is unclear that we can identify,
+   revisit, and fix all the protocols that publish hostnames.  In
+   particular, this is impossible for proprietary protocols.
+
+   We may be able to mitigate most of the effects of hostname leakage by
+   revisiting the way platforms handle hostnames.  In a way, this is
+   similar to the approach of Media Access Control (MAC) address
+   randomization described in [RFC7844].  Let's assume that the
+   operating system, at the time of connecting to a new network, picks a
+   random hostname and starts publicizing that random name in protocols
+   such as DHCP or mDNS, instead of the static value.  This will render
+   monitoring and identification of users by adversaries much more
+   difficult without preventing protocols such as DNS-SD from operating
+   as expected.  This, of course, has implications on the applications
+   making use of such protocols, e.g., when the hostname is being
+   displayed to users of the application.  They will not as easily be
+   able to identify, e.g., network shares or services based on the
+   hostname carried in the underlying protocols.  Also, the generation
+   of new hostnames should be synchronized with the change of other
+   tokens used in network protocols such as the MAC or IP address to
+   prevent correlation of this information.  For example, if the IP
+
+
+
+
+
+Huitema, et al.               Informational                     [Page 8]
+
+RFC 8117                Harmful Hostname Practice             March 2017
+
+
+   address changes but the hostname stays the same, the new IP address
+   can be correlated to belong to the same device based on a leaked
+   hostname.
+
+   Some operating systems, including Windows, support "per network"
+   hostnames, but some other operating systems only support "global"
+   hostnames.  In that case, changing the hostname may be difficult if
+   the host is multihomed, as the same name will be used on several
+   networks.  Other operating systems already use potentially different
+   hostnames for different purposes, which might be a good model to
+   combine both static hostnames and randomized hostnames based on their
+   potential use and threat to a user's privacy.
+
+   Obviously, further studies are required before the idea of randomized
+   hostnames can be implemented.
+
+6.  Security Considerations
+
+   This document does not introduce any new protocol.  It does point to
+   potential privacy issues in a set of existing protocols.
+
+   There are obvious privacy gains to changing to randomized hostnames
+   and also to changing these names frequently.  However, wide
+   deployment might affect security functions or current practices.  For
+   example, incident response using hostnames to track the source of
+   traffic might be affected.  It is common practice to include
+   hostnames and reverse lookup information at various times during an
+   investigation.
+
+7.  IANA Considerations
+
+   This document does not require any IANA actions.
+
+8.  Informative References
+
+   [RFC1002]  NetBIOS Working Group in the Defense Advanced Research
+              Projects Agency, Internet Activities Board, and End-to-End
+              Services Task Force, "Protocol standard for a NetBIOS
+              service on a TCP/UDP transport: Detailed specifications",
+              STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987,
+              <http://www.rfc-editor.org/info/rfc1002>.
+
+   [RFC1033]  Lottor, M., "Domain Administrators Operations Guide",
+              RFC 1033, DOI 10.17487/RFC1033, November 1987,
+              <http://www.rfc-editor.org/info/rfc1033>.
+
+
+
+
+
+
+Huitema, et al.               Informational                     [Page 9]
+
+RFC 8117                Harmful Hostname Practice             March 2017
+
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <http://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC1983]  Malkin, G., Ed., "Internet Users' Glossary", FYI 18,
+              RFC 1983, DOI 10.17487/RFC1983, August 1996,
+              <http://www.rfc-editor.org/info/rfc1983>.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
+              RFC 2131, DOI 10.17487/RFC2131, March 1997,
+              <http://www.rfc-editor.org/info/rfc2131>.
+
+   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+              Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
+              <http://www.rfc-editor.org/info/rfc2132>.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              DOI 10.17487/RFC2782, February 2000,
+              <http://www.rfc-editor.org/info/rfc2782>.
+
+   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+              C., and M. Carney, "Dynamic Host Configuration Protocol
+              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
+              2003, <http://www.rfc-editor.org/info/rfc3315>.
+
+   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+              "DNS Extensions to Support IP Version 6", RFC 3596,
+              DOI 10.17487/RFC3596, October 2003,
+              <http://www.rfc-editor.org/info/rfc3596>.
+
+   [RFC4620]  Crawford, M. and B. Haberman, Ed., "IPv6 Node Information
+              Queries", RFC 4620, DOI 10.17487/RFC4620, August 2006,
+              <http://www.rfc-editor.org/info/rfc4620>.
+
+   [RFC4795]  Aboba, B., Thaler, D., and L. Esibov, "Link-local
+              Multicast Name Resolution (LLMNR)", RFC 4795,
+              DOI 10.17487/RFC4795, January 2007,
+              <http://www.rfc-editor.org/info/rfc4795>.
+
+   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
+              DOI 10.17487/RFC6762, February 2013,
+              <http://www.rfc-editor.org/info/rfc6762>.
+
+   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
+              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
+              <http://www.rfc-editor.org/info/rfc6763>.
+
+
+
+
+Huitema, et al.               Informational                    [Page 10]
+
+RFC 8117                Harmful Hostname Practice             March 2017
+
+
+   [RFC7288]  Thaler, D., "Reflections on Host Firewalls", RFC 7288,
+              DOI 10.17487/RFC7288, June 2014,
+              <http://www.rfc-editor.org/info/rfc7288>.
+
+   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
+              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
+              2015, <http://www.rfc-editor.org/info/rfc7719>.
+
+   [RFC7819]  Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy
+              Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819,
+              April 2016, <http://www.rfc-editor.org/info/rfc7819>.
+
+   [RFC7824]  Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
+              Considerations for DHCPv6", RFC 7824,
+              DOI 10.17487/RFC7824, May 2016,
+              <http://www.rfc-editor.org/info/rfc7824>.
+
+   [RFC7844]  Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
+              Profiles for DHCP Clients", RFC 7844,
+              DOI 10.17487/RFC7844, May 2016,
+              <http://www.rfc-editor.org/info/rfc7844>.
+
+   [TRAC2016] Faath, M., Winter, R., and F. Weisshaar, "How Broadcast
+              Data Reveals Your Identity and Social Graph", IEEE,
+              Wireless Communications and Mobile Computing Conference
+              (IWCMC), 2016 International,
+              DOI 10.1109/IWCMC.2016.7577084, September 2016.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huitema, et al.               Informational                    [Page 11]
+
+RFC 8117                Harmful Hostname Practice             March 2017
+
+
+Acknowledgments
+
+   Thanks to the members of the INTAREA Working Group for discussions
+   and reviews.
+
+Authors' Addresses
+
+   Christian Huitema
+   Private Octopus Inc.
+   Friday Harbor, WA  98250
+   United States of America
+
+   Email: huitema@huitema.net
+
+
+   Dave Thaler
+   Microsoft
+   Redmond, WA  98052
+   United States of America
+
+   Email: dthaler@microsoft.com
+
+
+   Rolf Winter
+   University of Applied Sciences Augsburg
+   Augsburg
+   DE
+
+   Email: rolf.winter@hs-augsburg.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huitema, et al.               Informational                    [Page 12]
+