idnits 2.17.1 draft-hoffman-dac-domainrepdata-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 293. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2008) is 5911 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft J. Levine 4 Intended status: Standards Track Domain Assurance Council 5 Expires: August 22, 2008 February 19, 2008 7 Format for Domain Reputation Data 8 draft-hoffman-dac-domainrepdata-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 22, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document describes two formats for reputation data for domains. 42 The smaller format contains data that is expected to be used in real- 43 time receiver decisions, while the larger format is used for more 44 complete data that is appropriate for off-line decision making. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Smaller Format for Responses . . . . . . . . . . . . . . . . . 3 50 3. Larger Format for Responses . . . . . . . . . . . . . . . . . . 4 51 4. Examples of Reputation Records . . . . . . . . . . . . . . . . 5 52 5. RELAX NG schema . . . . . . . . . . . . . . . . . . . . . . . . 6 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 54 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 55 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 56 Appendix B. Changes between versions . . . . . . . . . . . . . . . 6 57 B.1. Differenes between -00 and -01 . . . . . . . . . . . . . . 6 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 59 Intellectual Property and Copyright Statements . . . . . . . . . . 8 61 1. Introduction 63 Providers of domain reputation want to be able to publish many types 64 of reputation data. Among these are: 66 o A score along some scale, plus an indication of the confidence in 67 that score 68 o Data about the domain's owner such as their name, how long they 69 have been in business, where they are located, the type of 70 business they are in, they type of mail they send, and so on 71 o Recent mailing statistics for the domain 72 o Number and types of complaints about the domain 73 o Innumerable others 75 There are many models for the ways domain reputation information 76 could be distributed. Some providers might give some data away 77 freely while charging for other data; some providers would give away 78 the data in exchange for valuable feedback from the recipient about 79 the domains; some providers would sell the reputation data to the 80 owner of the domain and certain mail receivers; and so on. 82 There are also many models for the ways the domain reputation data 83 would be used by mail senders and receivers. SMTP servers could use 84 a score of the likelihood that they would want to receive mail from a 85 particular domain, and they might be interested in the type of 86 business of the sender for mixing into their decision on how to 87 deliver the mail (banks might be more likely to be delivered to the 88 inbox, auto dealers to the spam folder). ISPs might buy reputation 89 data in bulk to help create their own in-house scoring systems. 91 This document describes two formats for reputation data for domains. 92 The smaller format contains data that is expected to be used in real- 93 time receiver decisions, while the larger format is used for more 94 complete data that is appropriate for off-line decision making. DAC 95 will later define protocols for retrieving the reputation data; these 96 are likely to be based on DNS queries and responses. 98 [[ The intended status of this document is an Informational RFC that 99 will be submitted as an independent submission to the RFC Editor. ]] 101 2. Smaller Format for Responses 103 The smaller response format is plain text with single spaces as 104 separators. An explicit goal is that the response can be parsed 105 without XML parsers (which are rare on SMTP servers). 107 The format for a small response is: 109 111 All fields, and the single space between each, are required. 113 o version -- a text string; for the first version of the protocol, 114 it is "1". 115 o score -- the likelihood that a recipient who trusts the reputation 116 provider would want to receive mail from the domain. The value 117 specifies a number between 0 and 99 inclusive that is the relative 118 score of the the domain. 119 o confidence -- the confidence of the reputation provider in the 120 score. It is a number between 0 and 99 inclusive with 50 meaning 121 "average confidence". 122 o SIC -- the numeric NAICS code of the business associated with the 123 domain. The value is the numeric code. The most recent list of 124 NAICS codes can be found at [NAICS-CODES]. 126 An example of such a record might be: 128 1 72 99 52213 130 3. Larger Format for Responses 132 The larger response format is XML. The XML overhead for this format 133 is approximately 100 bytes, which leaves plenty of room within even a 134 512-byte UDP DNS response for simple information. In the inevitable 135 cases where the answer is too big for one UDP packet, there is a 136 simple fall-back to TCP, although the number of larger-format queries 137 that have that much data is probably limited. 139 A set of common elements is defined in the namespace 140 "http://domain-assurance.org/rep-3". A reputation provider can use 141 their own XML namespace or other common XML namespaces for elements 142 not defined in the DAC namespace. DAC-defined elements have very 143 short names in order to maximize the number that can fit in a single 144 UDP packet. 146 Every element is optional. Also, every element also has an optional 147 c attribute whose value is a number between 0 and 99 inclusive that 148 is the confidence of the reputation provider in the information in 149 the element. If the c attribute is not given, the default value is 150 50, meaning "average confidence". It is expected that the c 151 attribute will not be used often. 153 The general defined elements are listed here. 155 o sc -- Score, the likelihood that a recipient who trusts the 156 reputation provider would want to receive mail from the domain. 157 The value specifies a number between 0 and 99 inclusive that is 158 the relative score of the the domain. 159 o in -- Industry, the numeric NAICS code of the business associated 160 with the domain. The value is the numeric code. The most recent 161 list of NAICS codes can be found at [NAICS-CODES]. 162 o na -- Name, the true name of the business associated with the 163 domain. 164 o st1, st2, ci, pr, co, pc -- Postal address elements of the 165 business associated with the domain: street address 1, street 166 address 2, city, state or province, country, postal code. The 167 country should be given as the two-letter ISO 3166 code. 168 o te -- Telephone, the telephone number of the business associated 169 with the domain. The value holds the text string that is the 170 telephone number; spaces, periods, and hyphens are explicitly 171 allowed. The value should include the country code prefaced with 172 a "+". 174 4. Examples of Reputation Records 176 An example using just the defined elements might be: 178 179 180 72 181 52213 182 Example Company LLC 183 127 Typical Street, Suite 500 184 AnytownCAUS95782-4410 185 +1 672.487.0091 186 188 An example including provider-defined elements might be: 190 191 193 72 194 a1892c25e959bd7a87161724dfec8c6d 195 196 198 5. RELAX NG schema 200 grammar { 201 c-att = attribute c { xsd:integer } 202 start = element rep { 203 default namespace ='http://domain-assurance.org/rep-3' 204 element sc { c-att?, xsd:integer }?, 205 element in { c-att?, xsd:integer }?, 206 element na { c-att?, text }?, 207 element st1 { c-att?, text }?, 208 element st2 { c-att?, text }?, 209 element ci { c-att?, text }?, 210 element pr { c-att?, text }?, 211 element co { c-att?, text }?, 212 element pc { c-att?, text }?, 213 element te { c-att?, text }?, 214 }} 216 6. Security Considerations 218 There are no security considerations for publishing reputation 219 information about domain names. 221 7. Informative References 223 [NAICS-CODES] 224 U.S. Census Bureau, "2002 NAICS Codes and Titles", 2002, 225 . 227 Appendix A. Acknowledgements 229 Many members of the Domain Assurance Council contributed to the 230 design of the protocol and the wording of this document. 232 Appendix B. Changes between versions 234 [[ This whole section will be removed before being published as an 235 RFC. ]] 237 B.1. Differenes between -00 and -01 239 Minor editorial revisions. 241 Added the intended status of the document. 243 Authors' Addresses 245 Paul Hoffman 246 Domain Assurance Council 248 Email: paul.hoffman@domain-assurance.org 250 John Levine 251 Domain Assurance Council 253 Email: john.levine@domain-assurance.org 255 Full Copyright Statement 257 Copyright (C) The IETF Trust (2008). 259 This document is subject to the rights, licenses and restrictions 260 contained in BCP 78, and except as set forth therein, the authors 261 retain all their rights. 263 This document and the information contained herein are provided on an 264 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 265 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 266 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 267 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 268 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 271 Intellectual Property 273 The IETF takes no position regarding the validity or scope of any 274 Intellectual Property Rights or other rights that might be claimed to 275 pertain to the implementation or use of the technology described in 276 this document or the extent to which any license under such rights 277 might or might not be available; nor does it represent that it has 278 made any independent effort to identify any such rights. Information 279 on the procedures with respect to rights in RFC documents can be 280 found in BCP 78 and BCP 79. 282 Copies of IPR disclosures made to the IETF Secretariat and any 283 assurances of licenses to be made available, or the result of an 284 attempt made to obtain a general license or permission for the use of 285 such proprietary rights by implementers or users of this 286 specification can be obtained from the IETF on-line IPR repository at 287 http://www.ietf.org/ipr. 289 The IETF invites any interested party to bring to its attention any 290 copyrights, patents or patent applications, or other proprietary 291 rights that may cover technology that may be required to implement 292 this standard. Please address the information to the IETF at 293 ietf-ipr@ietf.org. 295 Acknowledgment 297 Funding for the RFC Editor function is provided by the IETF 298 Administrative Support Activity (IASA).