< draft-ietf-repute-model-04.txt		draft-ietf-repute-model-05.txt >
	REPUTE Working Group N. Borenstein		REPUTE Working Group N. Borenstein
	Internet-Draft Mimecast		Internet-Draft Mimecast
	Intended status: Informational M. Kucherawy		Intended status: Informational M. Kucherawy
	Expires: September 1, 2013 Cloudmark		Expires: December 8, 2013 Cloudmark
	A. Sullivan, Ed.		A. Sullivan, Ed.
	Dyn, Inc.		Dyn, Inc.
	February 28, 2013		June 6, 2013
	A Model for Reputation Reporting		A Model for Reputation Reporting
	draft-ietf-repute-model-04		draft-ietf-repute-model-05
	Abstract		Abstract
	This document describes a general architecture for a reputation-based		This document describes a general architecture for a reputation-based
	service and a model for requesting reputation-related data over the		service and a model for requesting reputation-related data over the
	Internet, where "reputation" refers to predictions or expectations		Internet, where "reputation" refers to predictions or expectations
	about an entity or an identifier such as a domain name. The document		about an entity or an identifier such as a domain name. The document
	roughly follows the recommendations of RFC4101 for describing a		roughly follows the recommendations of RFC4101 for describing a
	protocol model.		protocol model.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 1, 2013.		This Internet-Draft will expire on December 8, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. High-Level Architecture . . . . . . . . . . . . . . . . . . . 4		2. High-Level Architecture . . . . . . . . . . . . . . . . . . . 4
	3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6		3. Terminology and Definitions . . . . . . . . . . . . . . . . . 7
	3.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Information Represented in a Response Set . . . . . . . . . . 6		3.2. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Information Flow in the Reputation Query Protocol . . . . . . 7		4. Information Represented in a Response Set . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. Information Flow in the Reputation Query Protocol . . . . . . 8
			6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 8		7.2. Collection Of Data . . . . . . . . . . . . . . . . . . . . 9
	8.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 9		8.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 9
	9. Informative References . . . . . . . . . . . . . . . . . . . . 9		8.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 10
	Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 10		8.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		9. Informative References . . . . . . . . . . . . . . . . . . . . 10
			Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Historically, many Internet protocols have operated between		Historically, many Internet protocols have operated between
	unauthenticated entities. For example, an email message's author		unauthenticated entities. For example, an email message's author
	field (From) [MAIL] can contain any display name or address and is		field (From) [MAIL] can contain any display name or address and is
	not verified by the recipient or other agents along the delivery		not verified by the recipient or other agents along the delivery
	path. Similarly, a sending email server using [SMTP] trusts that the		path. Similarly, a sending email server using [SMTP] trusts that the
	[DNS] has led it to the intended receiving server. Both kinds of		[DNS] has led it to the intended receiving server. Both kinds of
	trust are easily betrayed, opening the operation to subversion of		trust are easily betrayed, opening the operation to subversion of
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 32 ¶
	Omitted from this model is the means by which a reputation-reporting		Omitted from this model is the means by which a reputation-reporting
	agent goes about collecting such data and the method for creating an		agent goes about collecting such data and the method for creating an
	evaluation. The mechanism defined here merely enables asking a		evaluation. The mechanism defined here merely enables asking a
	question and getting an answer; the remainder of an overall service		question and getting an answer; the remainder of an overall service
	provided by such a reputation agent is specific to the implementation		provided by such a reputation agent is specific to the implementation
	of that service and is out of scope here.		of that service and is out of scope here.
	2. High-Level Architecture		2. High-Level Architecture
	A reputation mechanism functions as a component of a service, such as		A reputation mechanism functions as a component of an overall
	that depicted in Figure 1 of [RFC5863], reproduced here:		service. A current example is that of an email system that uses
			DomainKeys Identified Mail (DKIM; see [DKIM]) to affix a stable
			identifier to a message and then uses that as a basis for evaluation:
	+------+------+ +------+------+		+-------------+ +------------+
	| Author | | Recipient |		| Author | | Recipient |
	+------+------+ +------+------+		+-------------+ +------------+
	| ^		| ^
	| |		V |
	| +------+------+		+-------------+ +------------+
	| -->| Handling |<--		| MSA | | MDA |
	| -->| Filter |<--		+-------------+ +------------+
	| +-------------+		| ^
	| ^		| |
	V Responsible |		| +------------+
	+-------------+ Identifier +------+------+		| | Handling |
	| Responsible |. . . . . . . . . . .>| Identity |		| | Filter |
	| Identity | . . | Assessor |		| +------------+
	+------+------+ . . +-------------+		| ^
	| V . ^ ^		| |
	V . . | |		| +------------+ +------------+
	+------------------.-------.------------------+ | |		| | Reputation |------>| Identifier |
	| +------+------+ . . . > . +-------------+ | | | +------------+		| | Service | | Assessor |
	| | Identifier | | Identifier +-|-+ +-+ Assessment |		| +------------+ +------------+
	| | Signer +------------>| Validator | | | Databases |		| ^
	| +-------------+ +-------------+ | +------------+		V |
	| DKIM Service |		+----------------------------------------------------------+
	+---------------------------------------------+		| +------------+ Responsible Identifier +------------+ |
			| | Identifier |. . . . . . . . . . . . . .>| Identifier | |
			| | Signer | | Verifier | |
			| +------------+ DKIM Service +------------+ |
			+----------------------------------------------------------+
			| ^
			V |
			+-------------+ /~~~~~~~~~~\ +------+-----+
			| MTA |----->( other MTAs )------>| MTA |
			+-------------+ \~~~~~~~~~~/ +------------+
	Figure 1: RFC5683 'Actors in a Trust Sequence Using DKIM'		Figure 1: Actors in a Trust Sequence Using DKIM
	Here, the reputation mechanism is shown only as a query by an		(See [EMAIL-ARCH] for a general description of the Internet messaging
	Identity Assessor, made to Assessment Databases.		architecture.) Here, the DKIM Service provides one or more stable
			identifiers that is the basis for the reputation query. On receipt
			of a message from an MTA, the DKIM Service provides a (possibly
			empty) set of validated identifiers -- domain names, in this case --
			which are the subjects of reputation queries made by the Identity
			Assessor. The Identity Assessor queries a Reputation Service to
			determine the reputation of the provided identifiers, and delivers
			the identifiers and their reputations to the Handling Filter. The
			Handling Filter makes a decision about whether and how to deliver the
			message to the recipient based on these and other inputs about the
			message, possibly including evaluation mechansisms in addition to
			DKIM.
	This memo outlines the query and response mechanism. It provides the		This document outlines the reputation query and response mechanism.
	following definitions:		It provides the following definitions:
	o Vocabulary for the current work and work of this type;		o Vocabulary for the current work and work of this type;
	o The types and content of queries that can be supported;		o The types and content of queries that can be supported;
	o The extensible range of response information that can be provided;		o The extensible range of response information that can be provided;
	o A query/response protocol;		o A query/response protocol;
	o Query/response transport conventions.		o Query/response transport conventions.
	It provides an extremely simple query/response model that can be		It provides an extremely simple query/response model that can be
	carried over a variety of transports, including the Domain Name		carried over a variety of transports, including the Domain Name
	System. (Although not typically thought of as a 'transport', the DNS		System. (Although not typically thought of as a 'transport', the DNS
	provides generic capabilities and can be thought of as a mechanism		provides generic capabilities and can be thought of as a mechanism
	for transporting queries and responses that have nothing to do with		for transporting queries and responses that have nothing to do with
	addresses.) Each specification for Repute transport is independent		addresses.) Each specification for Repute transport is independent
	of any other specification. A diagram of the basic query service is		of any other specification. A diagram of the basic query service is
	found in Figure 2.		found in Figure 2.
	+-----------+ Query +----------+		+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . +
	| +. . . . . . . . . . . . . .>| |		. Reputation Service .
	| Client | | Server |		. +------------+ .
	| <. . . . . . . . . . . . . . + |		. | Reputation | .
	+-----+-----+ Response +-------+--+		. | Database | .
	| ^ |		. +------------+ .
	V | |		. | .
	+------+----+ +-----------+ | | Response		. V .
	| Transport |--------------->| Transport |--+ | Set		. +-----------+ Query +----------+ .
	+-----------+ DNS +-----------+ |		. | |. . . . . . . . . . . . . .>| | .
	TCP V		. | Client | | Server | .
	UDP +------------+		. | |< . . . . . . . . . . . . . | | .
	... | Reputation |		. +-----+-----+ Response +----------+ .
	| Database |		. ^ ^ .
	+------------+		+ . . . | . . . . . . . . . . . . . . . . . . . | . . . . +
			V |
			+-----------+ +-----------+ |
			| Transport |<-------------->| Transport |<---+
			+-----------+ DNS +-----------+
			TCP
			UDP
			...
	Figure 2: Basic Reputation Query Service		Figure 2: Basic Reputation Query Service
	Both the query and response are application-specific. An application		The precise syntaxes of both the query and response are application-
	of the model defines the parameters available to queries of that		specific. An application of the model defines the parameters
	type, and also defines the data returned in response to any query.		available to queries of that type, and also defines the data returned
			in response to any query.
	3. Terminology and Definitions		3. Terminology and Definitions
	This section defines terms used in the rest of the document.		This section defines terms used in the rest of the document.
	3.1. Response Set		3.1. Response Set
	A "Response Set" comprises those data that are returned in response		A "Response Set" comprises those data that are returned in response
	to a reputation query about a particular entity. The types of data		to a reputation query about a particular entity. The types of data
	are specific to an application; the data returned in the evaluation		are specific to an application; the data returned in the evaluation
	of email senders would be different than the reputation data returned		of email senders would be different than the reputation data returned
	about a movie or a baseball player.		about a movie or a baseball player.
	Response Sets have symbolic names, and these have to be registered		Response Sets have symbolic names, and these have to be registered
	with IANA to prevent name collisions. IANA registries are created in		with IANA, in the Reputation Applications Registry, to prevent name
	a separate memo. Each definition of a Response Set needs to define		collisions. IANA registries are created in a separate document.
	its registry entry.		Each definition of a Response Set also needs to define its registry
			entry.
			3.2. Reputon
			A "reputon" is an object that comprises the basic response to a
			reputation query. It contains the response set relevant to the
			subject of the query. Its specific encoding is left to documents
			that implement this model.
	4. Information Represented in a Response Set		4. Information Represented in a Response Set
	The basic information to be represented in the protocol is fairly		The basic information to be represented in the protocol is fairly
	simple, and includes the following:		simple, and includes the following:
	o the identity of the entity providing the reputation information;		o the identity of the entity providing the reputation information;
	o the identity of the entity being rated;		o the identity of the entity being rated;
	o the overall rating score for that entity;		o the application context for the query (e.g., email address
			evaluation);
			o the overall rating score for that entity;
	o the level of confidence in the accuracy of that rating; and		o the level of confidence in the accuracy of that rating; and
	o the number of data points underlying that score.		o the number of data points underlying that score.
	Beyond this, arbitrary amounts of additional information might be		Beyond this, arbitrary amounts of additional information might be
	provided for specific uses of the service. The entire collection is		provided for specific uses of the service. The entire collection is
	the Response Set for that application. The query/response protocol		the Response Set for that application. The query/response protocol
	defines a syntax for representing such Response Sets, but each		defines a syntax for representing such Response Sets, but each
	application defines its own Response Set. Thus, the basic information		application defines its own Response Set. Thus, the basic information
	also includes the name of the application for which the reputation		also includes the name of the application for which the reputation
	skipping to change at page 7, line 40 ¶		skipping to change at page 8, line 32 ¶
	5. Information Flow in the Reputation Query Protocol		5. Information Flow in the Reputation Query Protocol
	The basic Response Set could be wrapped into a new MIME media type		The basic Response Set could be wrapped into a new MIME media type
	[MIME] or a DNS RR, and transported accordingly. It also could be		[MIME] or a DNS RR, and transported accordingly. It also could be
	the integral payload of a purpose-built protocol. For a basic		the integral payload of a purpose-built protocol. For a basic
	request/response scenario, one entity (the Client) will ask a second		request/response scenario, one entity (the Client) will ask a second
	entity (the Server) for reputation data about a third entity (the		entity (the Server) for reputation data about a third entity (the
	Target), and the second entity will respond with that data.		Target), and the second entity will respond with that data.
	An applications might benefit from an extremely lightweight		An application might benefit from an extremely lightweight mechanism,
	mechanism, supporting constrained queries and responses, while others		supporting constrained queries and responses, while others might need
	might need to support larger and more complex responses.		to support larger and more complex responses.
	6. IANA Considerations		6. IANA Considerations
	This memo presents no actions for IANA.		This document presents no actions for IANA.
	[RFC Editor: Please remove this section prior to publication.]		[RFC Editor: Please remove this section prior to publication.]
	7. Privacy Considerations		7. Privacy Considerations
			7.1. Data In Transit
	Some kinds of reputation data are sensitive, and should not be shared		Some kinds of reputation data are sensitive, and should not be shared
	publicly. For cases that have such sensitivity, it is imperative to		publicly. For cases that have such sensitivity, it is imperative to
	protect the information from unauthorized access and viewing. The		protect the information from unauthorized access and viewing. The
	model described here neither suggests nor precludes any particular		model described here neither suggests nor precludes any particular
	transport mechanism for the data. However, for the purpose of		transport mechanism for the data. However, for the purpose of
	illustration, a reputation service that operates over HTTP might		illustration, a reputation service that operates over HTTP might
	employ any of its well-known mechanisms to solve these problems,		employ any of its well-known mechanisms to solve these problems,
	which include OpenPGP [OPENPGP], Transport Layer Security [TLS], and		which include OpenPGP [OPENPGP], Transport Layer Security [TLS], and
	S/MIME [SMIME].		S/MIME [SMIME].
			7.2. Collection Of Data
			The basic notion of collection and storage of reputation data is
			obviously a privacy issue in that the opinions of one party about
			another are likely to be sensitive. Inadvertent or unauthorized
			exposure of those data can lead to personal or commercial damage.
	8. Security Considerations		8. Security Considerations
	This memo introduces an overall protocol model, but no implementation		This document introduces an overall protocol model, but no
	details. As such, the security considerations presented here are		implementation details. As such, the security considerations
	very high-level. The detailed analyses of the various specific		presented here are very high-level. The detailed analyses of the
	components of the protocol can be found the documents that		various specific components of the protocol can be found the
	instantiate this model.		documents that instantiate this model.
	8.1. Biased Reputation Agents		8.1. Biased Reputation Agents
	As with [VBR], an agent seeking to make use of a reputation reporting		As with [VBR], an agent seeking to make use of a reputation reporting
	service is placing some trust that the service presents an unbiased		service is placing some trust that the service presents an unbiased
	"opinion" of the object about which reputation is being returned.		"opinion" of the object about which reputation is being returned.
	The result of trusting the data is, presumably, to guide action taken		The result of trusting the data is, presumably, to guide action taken
	by the reputation client. It follows, then, that bias in the		by the reputation client. It follows, then, that bias in the
	reputation service can adversely affect the client. Clients		reputation service can adversely affect the client. Clients
	therefore need to be aware of this possibility and the effect it		therefore need to be aware of this possibility and the effect it
	might have. For example, a biased system returning a reputation		might have. For example, a biased system returning a reputation
	about a DNS domain found in email messages could result in the		about a DNS domain found in email messages could result in the
	admission of spam, phishing or malware through a mail gateway (by		admission of spam, phishing or malware through a mail gateway (by
	rating the domain name more favourably than warranted) or could		rating the domain name more favourably than warranted) or could
	result in the needless rejection or delay of mail (by rating the		result in the needless rejection or delay of mail (by rating the
	domain more unfavourably than warranted). As a possible mitigation		domain more unfavourably than warranted). As a possible mitigation
	strategy, clients might seek to interact only with reputation		strategy, clients might seek to interact only with reputation
	services that offer some disclosure of the computation methods for		services that offer some disclosure of the computation methods for
	the results they return. Such disclosure and evaluation is beyond		the results they return. Such disclosure and evaluation is beyond
	the scope of the present memo.		the scope of the present document.
	Similarly, a client placing trust in the results returned by such a		Similarly, a client placing trust in the results returned by such a
	service might suffer if the service itself is compromised, returning		service might suffer if the service itself is compromised, returning
	biased results under the control of an attacker without the knowledge		biased results under the control of an attacker without the knowledge
	of the agency providing the reputation service. This might result		of the agency providing the reputation service. This might result
	from an attack on the data being returned at the source, or from a		from an attack on the data being returned at the source, or from a
	man-in-the-middle attack. Protocols, therefore, need to be designed		man-in-the-middle attack. Protocols, therefore, need to be designed
	so as to be as resilient against such attacks as possible.		so as to be as resilient against such attacks as possible.
	8.2. Malformed Messages		8.2. Malformed Messages
	skipping to change at page 9, line 21 ¶		skipping to change at page 10, line 23 ¶
	under evaluation. This can result in delivery of undesirable or even		under evaluation. This can result in delivery of undesirable or even
	dangerous content.		dangerous content.
	8.3. Further Discussion		8.3. Further Discussion
	Numerous other topics related to use and management of reputation		Numerous other topics related to use and management of reputation
	systems can be found in [I-D.REPUTE-CONSIDERATIONS].		systems can be found in [I-D.REPUTE-CONSIDERATIONS].
	9. Informative References		9. Informative References
	[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,		[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
	J., and M. Thomas, "DomainKeys Identified Mail (DKIM)		"DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
	Signatures", RFC 4871, May 2007.		September 2011.
	[DNS] Mockapetris, P., "Domain names - implementation and		[DNS] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
			[EMAIL-ARCH]
			Crocker, D., "Internet Mail Architecture", RFC 5598,
			July 2009.
	[I-D.REPUTE-CONSIDERATIONS]		[I-D.REPUTE-CONSIDERATIONS]
	Kucherawy, M., "Operational Considerations Regarding		Kucherawy, M., "Operational Considerations Regarding
	Reputation Services", draft-ietf-repute-considerations		Reputation Services", draft-ietf-repute-considerations
	(work in progress), November 2012.		(work in progress), November 2012.
	[MAIL] Resnick, P., "Internet Message Format", RFC 5322,		[MAIL] Resnick, P., "Internet Message Format", RFC 5322,
	October 2008.		October 2008.
	[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message		Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, November 1996.		Bodies", RFC 2045, November 1996.
	[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.		[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
	Thayer, "OpenPGP Message Format", RFC 4880, November 2007.		Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
	[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
	"DomainKeys Identified Mail (DKIM) Development,
	Deployment, and Operations", RFC 5863, May 2010.
	[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet		[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
	Mail Extensions (S/MIME) Version 3.2: Message		Mail Extensions (S/MIME) Version 3.2: Message
	Specification", RFC 5751, January 2010.		Specification", RFC 5751, January 2010.
	[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	October 2008.		October 2008.
	[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security		[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By		[VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
	Reference", RFC 5518, April 2009.		Reference", RFC 5518, April 2009.
	Appendix A. Public Discussion		Appendix A. Public Discussion
	Public discussion of this suite of memos takes place on the		Public discussion of this suite of documents takes place on the
	domainrep@ietf.org mailing list. See		domainrep@ietf.org mailing list. See
	https://www.ietf.org/mailman/listinfo/domainrep.		https://www.ietf.org/mailman/listinfo/domainrep.
	Authors' Addresses		Authors' Addresses
	Nathaniel Borenstein		Nathaniel Borenstein
	Mimecast		Mimecast
	203 Crescent St., Suite 303		203 Crescent St., Suite 303
	Waltham, MA 02453		Waltham, MA 02453
	USA		USA
End of changes. 26 change blocks.
	87 lines changed or deleted		139 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/