draft-ietf-repute-model-05.txt   draft-ietf-repute-model-06.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: December 8, 2013 Cloudmark Expires: January 4, 2014
A. Sullivan, Ed. A. Sullivan, Ed.
Dyn, Inc. Dyn, Inc.
June 6, 2013 July 3, 2013
A Model for Reputation Reporting A Model for Reputation Reporting
draft-ietf-repute-model-05 draft-ietf-repute-model-06
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 December 8, 2013. This Internet-Draft will expire on January 4, 2014.
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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 7 3. High-Level Architecture . . . . . . . . . . . . . . . . . . . 5
3.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 7 4. Terminology and Definitions . . . . . . . . . . . . . . . . . 8
3.2. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Response Set . . . . . . . . . . . . . . . . . . . . . . . 8
4. Information Represented in a Response Set . . . . . . . . . . 7 4.2. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Information Flow in the Reputation Query Protocol . . . . . . 8 5. Information Represented in a Response Set . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Information Flow in the Reputation Query Protocol . . . . . . 9
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 8 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10
7.2. Collection Of Data . . . . . . . . . . . . . . . . . . . . 9 8.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8.2. Collection Of Data . . . . . . . . . . . . . . . . . . . . 10
8.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 10 9.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 11
8.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 10 9.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . . 10 9.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 11 10. Informative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
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 30 skipping to change at page 4, line 30
a generic query mechanism and basic format for reputation retrieval, a generic query mechanism and basic format for reputation retrieval,
but allows extensions for each application. but allows extensions for each application.
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. Overview
The basic premise of this reputation system involves a client that is
seeking to evaluate content based on an identifier associated with
the content, and a reputation service provider that collects,
aggregates, and makes available for consumption, scores based on the
collected data. Typically client and service operators enter into
some kind of agreement during which some parameters are exchanged
such as the location at which the reputation service can be reached,
the nature of the reputation data being offered, possibly some client
authentication details, and the like.
Upon receipt of some content the client operator wishes to evaluate
(an Internet message, for example), the client extracts from the
content one or more identifiers of interest to be evaluated.
Examples of this include the domain name found in the From: field of
a message, or the domain name extracted from a valid DomainKeys
Identified Mail (DKIM) signature.
Next, the goal is to ask the reputation service provider what the
reputation of the extracted identifier is. This is a two-stage
query. The first query is to the reputation service provider at a
well-known resource location to download a template. The template is
a string into which various parameters about the query, including the
identifier to be evaluated, are substituted. The result is a second
resource location, and a query to this location is the actual
reputation request.
The client then issues a query to the second location to request the
reputation score associated with the extracted identifier. The
client typically folds this information into whatever local
evaluation logic it applies to decide what disposition the content
deserves.
3. High-Level Architecture
A reputation mechanism functions as a component of an overall A reputation mechanism functions as a component of an overall
service. A current example is that of an email system that uses service. A current example is that of an email system that uses
DomainKeys Identified Mail (DKIM; see [DKIM]) to affix a stable DomainKeys Identified Mail (DKIM; see [DKIM]) to affix a stable
identifier to a message and then uses that as a basis for evaluation: identifier to a message and then uses that as a basis for evaluation:
+-------------+ +------------+ +-------------+ +------------+
| Author | | Recipient | | Author | | Recipient |
+-------------+ +------------+ +-------------+ +------------+
| ^ | ^
skipping to change at page 5, line 22 skipping to change at page 6, line 22
+-------------+ +------------+ +-------------+ +------------+
| ^ | ^
| | | |
| +------------+ | +------------+
| | Handling | | | Handling |
| | Filter | | | Filter |
| +------------+ | +------------+
| ^ | ^
| | | |
| +------------+ +------------+ | +------------+ +------------+
| | Reputation |------>| Identifier | | | Reputation |<=====>| Identifier |
| | Service | | Assessor | | | Service | | Assessor |
| +------------+ +------------+ | +------------+ +------------+
| ^ | ^
V | V |
+----------------------------------------------------------+ +----------------------------------------------------------+
| +------------+ Responsible Identifier +------------+ | | +------------+ Responsible Identifier +------------+ |
| | Identifier |. . . . . . . . . . . . . .>| Identifier | | | | Identifier |. . . . . . . . . . . . . .>| Identifier | |
| | Signer | | Verifier | | | | Signer | | Verifier | |
| +------------+ DKIM Service +------------+ | | +------------+ DKIM Service +------------+ |
+----------------------------------------------------------+ +----------------------------------------------------------+
| ^ | ^
V | V |
+-------------+ /~~~~~~~~~~\ +------+-----+ +-------------+ /~~~~~~~~~~\ +------+-----+
| MTA |----->( other MTAs )------>| MTA | | MTA |----->( other MTAs )------>| MTA |
+-------------+ \~~~~~~~~~~/ +------------+ +-------------+ \~~~~~~~~~~/ +------------+
Figure 1: Actors in a Trust Sequence Using DKIM Figure 1: Actors in a Trust Sequence Using DKIM
(See [EMAIL-ARCH] for a general description of the Internet messaging (See [EMAIL-ARCH] for a general description of the Internet messaging
architecture.) Here, the DKIM Service provides one or more stable architecture.) In this figure, the solid lines indicate the flow of
identifiers that is the basis for the reputation query. On receipt a message; the dotted line indicates transfer of validated
of a message from an MTA, the DKIM Service provides a (possibly identifiers within the message content; and the double line shows the
empty) set of validated identifiers -- domain names, in this case -- query and response of the reputation information.
which are the subjects of reputation queries made by the Identity
Assessor. The Identity Assessor queries a Reputation Service to Here, the DKIM Service provides one or more stable identifiers that
determine the reputation of the provided identifiers, and delivers is the basis for the reputation query. On receipt of a message from
the identifiers and their reputations to the Handling Filter. The an MTA, the DKIM Service provides a (possibly empty) set of validated
Handling Filter makes a decision about whether and how to deliver the identifiers -- domain names, in this case -- which are the subjects
message to the recipient based on these and other inputs about the of reputation queries made by the Identity Assessor. The Identity
message, possibly including evaluation mechansisms in addition to Assessor queries a Reputation Service to determine the reputation of
DKIM. 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 document outlines the reputation query and response mechanism. This document outlines the reputation query and response mechanism.
It provides the 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 Internet addresses, such as is one with a DNS BlockList [DNSBL].)
of any other specification. A diagram of the basic query service is Each specification for Repute transport is independent of any other
found in Figure 2. specification. A diagram of the basic query service is found in
Figure 2.
+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . + + . . . . . . . . . . . . . . . . . . . . . . . . . . . . +
. Reputation Service . . Reputation Service .
. +------------+ . . +------------+ .
. | Reputation | . . | Reputation | .
. | Database | . . | Database | .
. +------------+ . . +------------+ .
. | . . | .
. V . . V .
. +-----------+ Query +----------+ . . +-----------+ Query +----------+ .
skipping to change at page 7, line 12 skipping to change at page 8, line 35
UDP UDP
... ...
Figure 2: Basic Reputation Query Service Figure 2: Basic Reputation Query Service
The precise syntaxes of both the query and response are application- The precise syntaxes of both the query and response are application-
specific. An application of the model defines the parameters specific. An application of the model defines the parameters
available to queries of that type, and also defines the data returned available to queries of that type, and also defines the data returned
in response to any query. in response to any query.
3. Terminology and Definitions 4. 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 4.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, in the Reputation Applications Registry, to prevent name with IANA, in the Reputation Applications Registry, to prevent name
collisions. IANA registries are created in a separate document. collisions. IANA registries are created in a separate document.
Each definition of a Response Set also needs to define its registry Each definition of a Response Set also needs to define its registry
entry. entry.
3.2. Reputon 4.2. Reputon
A "reputon" is an object that comprises the basic response to a A "reputon" is an object that comprises the basic response to a
reputation query. It contains the response set relevant to the reputation query. It contains the response set relevant to the
subject of the query. Its specific encoding is left to documents subject of the query. Its specific encoding is left to documents
that implement this model. that implement this model.
4. Information Represented in a Response Set 5. 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 application context for the query (e.g., email address o the application context for the query (e.g., email address
evaluation); evaluation);
skipping to change at page 8, line 23 skipping to change at page 9, line 45
also includes the name of the application for which the reputation also includes the name of the application for which the reputation
data is being expressed. data is being expressed.
Each application requires its own specification of the Response Set. Each application requires its own specification of the Response Set.
For example, a specification might be needed for a reputation For example, a specification might be needed for a reputation
Response Set for an "email-sending-domain"; the Response Set might Response Set for an "email-sending-domain"; the Response Set might
include information on how often spam was received from that domain. include information on how often spam was received from that domain.
Additional documents define a [MIME] type for reputation data, and Additional documents define a [MIME] type for reputation data, and
protocols for exchanging such data. protocols for exchanging such data.
5. Information Flow in the Reputation Query Protocol 6. 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 application might benefit from an extremely lightweight mechanism, An application might benefit from an extremely lightweight mechanism,
supporting constrained queries and responses, while others might need supporting constrained queries and responses, while others might need
to support larger and more complex responses. to support larger and more complex responses.
6. IANA Considerations 7. IANA Considerations
This document 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 8. Privacy Considerations
7.1. Data In Transit 8.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 8.2. Collection Of Data
The basic notion of collection and storage of reputation data is The basic notion of collection and storage of reputation data is
obviously a privacy issue in that the opinions of one party about obviously a privacy issue in that the opinions of one party about
another are likely to be sensitive. Inadvertent or unauthorized another are likely to be sensitive. Inadvertent or unauthorized
exposure of those data can lead to personal or commercial damage. exposure of those data can lead to personal or commercial damage.
8. Security Considerations 9. Security Considerations
This document introduces an overall protocol model, but no This document introduces an overall protocol model, but no
implementation details. As such, the security considerations implementation details. As such, the security considerations
presented here are very high-level. The detailed analyses of the presented here are very high-level. The detailed analyses of the
various specific components of the protocol can be found the various specific components of the protocol can be found the
documents that instantiate this model. documents that instantiate this model.
8.1. Biased Reputation Agents 9.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
skipping to change at page 10, line 7 skipping to change at page 11, line 33
the scope of the present document. 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 9.2. Malformed Messages
Both clients and servers of reputation systems need to be resistant Both clients and servers of reputation systems need to be resistant
to attacks that involve malformed messages, deliberate or otherwise. to attacks that involve malformed messages, deliberate or otherwise.
Malformations can be used to confound clients and servers alike in Malformations can be used to confound clients and servers alike in
terms of identifying the party or parties responsible for the content terms of identifying the party or parties responsible for the content
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 9.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 10. Informative References
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
September 2011. 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.
[DNSBL] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
February 2010.
[EMAIL-ARCH] [EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture", RFC 5598, Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009. 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,
skipping to change at page 11, line 33 skipping to change at page 13, line 17
Nathaniel Borenstein Nathaniel Borenstein
Mimecast Mimecast
203 Crescent St., Suite 303 203 Crescent St., Suite 303
Waltham, MA 02453 Waltham, MA 02453
USA USA
Phone: +1 781 996 5340 Phone: +1 781 996 5340
Email: nsb@guppylake.com Email: nsb@guppylake.com
Murray S. Kucherawy Murray S. Kucherawy
Cloudmark 270 Upland Drive
128 King St., 2nd Floor San Francisco, CA 94127
San Francisco, CA 94107
USA USA
Email: superuser@gmail.com Email: superuser@gmail.com
Andrew Sullivan (editor) Andrew Sullivan (editor)
Dyn, Inc. Dyn, Inc.
150 Dow St. 150 Dow St.
Manchester, NH 03101 Manchester, NH 03101
USA USA
 End of changes. 25 change blocks. 
55 lines changed or deleted 97 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/