idnits 2.17.1 draft-ietf-stir-passport-rcd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 22, 2018) is 1985 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCThis' is mentioned on line 469, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-stir-oob-03 == Outdated reference: A later version (-08) exists of draft-ietf-stir-passport-shaken-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar Inc. 4 Intended status: Informational C. Wendt 5 Expires: April 25, 2019 Comcast 6 October 22, 2018 8 PASSporT Extension for Rich Call Data 9 draft-ietf-stir-passport-rcd-01 11 Abstract 13 This document extends PASSporT, a token for conveying 14 cryptographically-signed information about personal communications, 15 to include rich data that can be rendered to users, such as a human- 16 readable display name comparable to the "Caller ID" function common 17 on the telephone network. The element defined for this purpose is 18 extensible to include related information about calls that helps 19 people decide whether to pick up the phone. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 25, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. PASSporT 'rcd' Claim . . . . . . . . . . . . . . . . . . . . 3 58 4. Further Information Associated with Callers . . . . . . . . . 4 59 5. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Signing as a Third Party . . . . . . . . . . . . . . . . 6 61 6. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 6 62 7. Using 'rcd' in SIP . . . . . . . . . . . . . . . . . . . . . 7 63 7.1. Authentication Service Behavior . . . . . . . . . . . . . 7 64 7.2. Verification Service Behavior . . . . . . . . . . . . . . 7 65 8. Using 'rcd' as additional claims to other PASSporT extensions 8 66 8.1. Procedures for applying 'rcd' as claims only . . . . . . 9 67 8.2. Example for applying 'rcd' as claims only . . . . . . . . 9 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 10.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 10 71 10.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 10 72 10.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 10 73 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 12.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 PASSporT [RFC8225] is a token format based on JWT [RFC7519] for 82 conveying cryptographically-signed information about the people 83 involved in personal communications; it is used to convey a signed 84 assertion of the identity of the participants in real-time 85 communications established via a protocol like SIP [RFC8224]. The 86 STIR problem statement [RFC7340] declared securing the display name 87 of callers outside of STIR's initial scope, so baseline STIR provides 88 no features for caller name. This specification documents an 89 optional mechanism for PASSporT and the associated STIR mechanisms 90 which extends PASSporT to carry additional elements conveying richer 91 information: information that is intended to be rendered to an end 92 user to assist a called party in determining whether to accept or 93 trust incoming communications. This includes the name of the person 94 on one side of a communications session, the traditional "Caller ID" 95 of the telephone network, along with related display information that 96 would be rendered to the called party during alerting, or potentially 97 used by an automaton to determine whether and how to alert a called 98 party. 100 In the traditional telephone network, the display name associated 101 with a call is typically provided in one of three ways: by a third- 102 party service queried at the terminating side, by the originator of 103 the call, or through a local address book maintained by a device on 104 the terminating side. The STIR architecture lends itself especially 105 to the first of these approaches, as it assumes that an authority on 106 the originating side of the call provides a cryptographic assurance 107 of the validity of the calling party number in order to prevent 108 impersonation attacks. That same authority could sign for a display 109 name associated with that number, which the terminating side could 110 render to the user when the call is alerting. Even when the 111 originating side does not provide a display name for the caller, the 112 cryptographic attestation of the validity of the calling number 113 provided by STIR still allows the terminating side to query a local 114 or remote service for a name associated with that number without fear 115 that the number has been impersonated by the caller; STIR thus makes 116 "Caller ID" more secure even when there is no first-party attestation 117 of a display name. For these cases, this specification outlines 118 various ways that a display name for a calling party could be 119 determined at the terminating side in a secure fashion. 121 2. Terminology 123 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 124 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 125 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 126 described in [RFC2119] and [RFC6919]. 128 3. PASSporT 'rcd' Claim 130 This specification defines a new JSON Web Token claim for "rcd", Rich 131 Call Data, the value of which is an array of JSON subelements. The 132 initial subelement defined here is a display name, "nam", associated 133 with the originator of personal communications, which may for example 134 derive from the display-name component of the From header field value 135 of a SIP request, or a similar field in other PASSporT using 136 protocols. 138 The "rcd" claim may appear in any PASSporT claims object as an 139 optional element. The creator of a PASSporT MAY however add a "ppt" 140 value of "rcd" to the header of a PASSporT as well, in which case the 141 PASSporT claims MUST contain a "rcd" claim, and any entities 142 verifying the PASSporT object will be required to understand the 143 "ppt" extension in order to process the PASSporT in question. A 144 PASSporT header wih the "ppt" included will look as follows: 146 { "typ":"passport", 147 "ppt":"rcd", 148 "alg":"ES256", 149 "x5u":"https://www.example.com/cert.cer" } 151 The PASSporT claims object will then contain the "rcd" key with its 152 corresponding value. The value of "rcd" is an array of JSON objects, 153 of which one, the "nam" object, is mandatory. The key syntax of 154 "nam" follows the display-name ABNF given in [RFC3261]. 156 { "orig":{"tn":"12155551212"}, 157 "dest":{"tn":"12155551213"}, 158 "iat":1443208345, 159 "iss":"Example, Inc.", 160 "rcd":{"nam":"Alice Atlanta"} } 162 After the header and claims PASSporT objects have been constructed, 163 their signature is generated normally per the guidance in [RFC8225]. 165 4. Further Information Associated with Callers 167 Beyond naming information, there may be additional human-readable 168 information about the calling party that should be rendered to the 169 end user in order to help the called party decide whether or not to 170 pick up the phone. This is not limited to information about the 171 caller, but includes information about the call itself, which may 172 derive from analytics that determine based on call patterns or 173 similar data if the call is likely to be one the called party wants 174 to receive. Such data could include: 176 information related to the location of the caller, or 178 any organizations or institutions that the caller is associated 179 with, or even categories of institutions (is this a government 180 agency, or a bank, or what have you), or 182 hyperlinks to images, such as logos or pictures of faces, or to 183 similar external profile information, or 185 information that will be processed by an application before 186 rendering it to a user, like social networking data that shows 187 that an unknown caller is a friend-of-a-friend, or reputation 188 scores derived from crowdsourcing, or confidence scores based on 189 broader analytics about the caller and callee. 191 All of these data elements would benefit from the secure attestations 192 provided by the STIR and PASSporT frameworks. A new IANA registry 193 has been defined to hold potential values of the "rcd" array; see 194 Section 10.3. Specific extensions to the "rcd" PASSporT claim are 195 left for future specification. 197 While in the traditional telephone network, the business relationship 198 between calling customers and their telephone service providers is 199 the ultimate root of information about a calling party's name, some 200 other forms of data like crowdsourced reputation scores might derive 201 from third parties. It is more likely that when those elements are 202 present, they will be in a third-party "rcd" PASSporT. 204 5. Third-Party Uses 206 While rich data about the call can be provided by an originating 207 authentication service, the terminating side or an intermediary in 208 the call path could also acquire rich call data by querying a third- 209 party service. In telephone operations today, a third-party 210 information service is commonly queried with the calling party's 211 number in order to learn the name of the calling party, and 212 potentially other helpful information could also be passed over that 213 interface. The value of using a PASSporT to convey this information 214 from third parties lies largely in the preservation of the original 215 authority's signature over the data, and the potential for the 216 PASSporT to be conveyed from intermediaries to endpoint devices. 217 Effectively, these use cases form of subcase of out-of-band 218 [I-D.ietf-stir-oob] use cases. The manner in which third-party 219 services are discovered is outside the scope of this document. 221 An intermediary use case might look as follows: a SIP INVITE carries 222 a display name in its From header field value and an initial PASSporT 223 object without the "rcd" claim. When the a terminating verification 224 service implemented at a SIP proxy server receives this request, and 225 determines that the signature is valid, it might query a third-party 226 service that maps telephone numbers to calling party names. Upon 227 receiving the PASSport in a response from that third-party service, 228 the terminating side could add a new Identity header field to the 229 request for the "rcd" PASSporT object provided by the third-party 230 service. It would then forward the INVITE to the terminating user 231 agent. If the display name in the "rcd" PASSporT object matches the 232 display name in the INVITE, then the name would presumably be 233 rendered to the end user by the terminating user agent. 235 A very similar flow could be followed by an intermediary closer to 236 the origination of the call. Presumably such a service could be 237 implemented at an originating network in order to decouple the 238 systems that sign for calling party numbers from the systems that 239 provide rich data about calls. 241 In an alternative use case, the terminating user agent might query a 242 third-party service. In this case, no new Identity header field 243 would be generated, though the terminating user agent might receive a 244 PASSporT object in return from the third-party service, and use the 245 "rcd" field in the object as a calling name to render to users while 246 alerting. 248 5.1. Signing as a Third Party 250 When a third party issues a PASSporT with an "rcd" claim, the 251 PASSporT MUST contain the "rcd" "ppt" type in its header object. It 252 moreover MUST include an "iss" claim as defined in [RFC7519] to 253 indicate the source of this PASSporT; that field SHOULD be populated 254 with the subject of the credential used to sign the PASSporT. 256 A PASSporT with a "ppt" of "rcd" MAY be signed with credentials that 257 do not have authority over the identity that appears in the "orig" 258 element of the PASSporT claims. Relying parties in STIR have always 259 been left to make their own authorization decisions about whether or 260 not the trust the signers of PASSporTs, and in the third-party case, 261 where an entity has explicitly queried a service to acquire the 262 PASSporT object, it may be some external trust or business 263 relationship that induces the relying party to trust a PASSporT. 265 6. Levels of Assurance 267 As "rcd" can be provided by either first or third parties, relying 268 parties could benefit from an additional claim that indicates the 269 relationship of the attesting party to the caller. Even in first 270 party cases, this admits of some complexity: the Communications 271 Service Provider (CSP) to which a number was assigned might in turn 272 delegate the number to a reseller, who would then sell the number to 273 an enterprise, in which case the CSP might have little insight into 274 the caller's name. In third party cases, a caller's name could 275 derive from any number of data sources, on a spectrum between public 276 data scraped from web searches to a direct business relationship to 277 the caller. As multiple PASSporTs can be associated with the same 278 call, potentially a verification service could receive attestations 279 of the caller name from multiple sources, which have different levels 280 of granularity or accuracy. 282 Therefore PASSporTs that carry "rcd" data SHOULD also carry an 283 indication of the relationship of the generator of the PASSporT to 284 the caller. [TBD claim - take from SHAKEN?] 286 7. Using 'rcd' in SIP 288 This section specifies SIP-specific usage for the "rcd" claim in 289 PASSporT, and in the SIP Identity header field value. Other using 290 protocols of PASSporT may define their own usages for the "rcd" 291 claim. 293 7.1. Authentication Service Behavior 295 An authentication service creating a PASSporT containing a "rcd" 296 claim MAY include a "ppt" for "rcd" or not. Third-party 297 authentication services following the behavior in Section 5.1 MUST 298 include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any 299 SIP authentication services MUST add a "ppt" parameter to the 300 Identity header containing that PASSporT with a value of "rcd". The 301 resulting Identity header might look as follows: 303 Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 304 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 305 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \ 306 info=;alg=ES256;ppt="rcd" 308 This specification assumes that by default, a SIP authentication 309 service will derive the value of "rcd" from the display-name 310 component of the From header field value of the request. It is 311 however a matter of authentication service policy to decide how it 312 populates the value of "rcd", which MAY also derive from other fields 313 in the request, from customer profile data, or from access to 314 external services. If the authentication service generates a 315 PASSporT object containing "rcd" with a value that is not equivalent 316 to the From header field display-name value, it MUST use the full 317 form of the PASSporT object in SIP. 319 7.2. Verification Service Behavior 321 [RFC8224] Section 6.2 Step 5 requires that specifications defining 322 "ppt" values describe any additional verifier behavior. The behavior 323 specified for the "ppt" values of "rcd" is as follows. If the 324 PASSporT is in compact form, then the verification service SHOULD 325 extract the display-name from the From header field value, if any, 326 and use that as the value for the "rcd" key when it recomputes the 327 header and claims of the PASSporT object. If the signature validates 328 over the recomputed object, then the verification should be 329 considered successful. 331 However, if the PASSport is in full form with a "ppt" value of "rcd", 332 then the verification service MUST extract the value associated with 333 the "rcd" "nam" key in the object. If the signature validates, then 334 the verification service can use the value of the "rcd" "nam" key as 335 the display name of calling party, which would in turn be rendered to 336 alerted users or otherwise leveraged in accordance with local policy. 337 This will allow SIP networks that convey the display name through a 338 field other than the From header field to interoperate with this 339 specification. 341 The third-party "rcd" PASSporT cases presents some new challenges, as 342 an attacker could attempt to cut-and-paste such a third-party 343 PASSporT into a SIP request in an effort to get the terminating user 344 agent to render the display name or confidence values it contains to 345 a call that should have no such assurance. A third-party "rcd" 346 PASSporT provides no assurance that the calling party number has not 347 been spoofed: if it is carried in a SIP request, for example, then 348 some other PASSporT in another Identity header field value would have 349 to carry a PASSporT attesting that. A verification service MUST 350 determine that the calling party number shown in the "orig" of the 351 "rcd" PASSporT corresponds to the calling party number of the call it 352 has received, and that the "iat" field of the "rcd" PASSporT is 353 within the date interval that the verification service would 354 ordinarily accept for a PASSporT. 356 Verification services may alter their authorization policies for the 357 credentials accepted to sign PASSporTs when third parties generate 358 PASSporT objects, per Section 5.1. This may include accepting a 359 valid signature over a PASSporT even if it is signed with a 360 credential that does not attest authority over the identity in the 361 "orig" claim of the PASSporT, provided that the verification service 362 has some other reason to trust the signer. No further guidance on 363 verification service authorization policy is given here. 365 The behavior of a SIP UAS upon receiving an INVITE containing a 366 PASSporT object with a "rcd" claim will largely remain a matter of 367 implementation policy. In most cases, implementations would render 368 this calling party name information to the user while alerting. Any 369 user interface additions to express confidence in the veracity of 370 this information are outside the scope of this specification. 372 8. Using 'rcd' as additional claims to other PASSporT extensions 374 Rich Call Data, including, for example, calling name information, is 375 often data that is additive data to the personal communications 376 information defined in the core PASSporT data required to support the 377 security properties defined in [RFC8225]. For cases where the entity 378 that is originating the personal communications and additionally is 379 supporting the authentication service and also is the authority of 380 the Rich Call Data, rather than creating multiple identity headers 381 with multiple PASSporT extensions or defining multiple combinations 382 and permutations of PASSporT extension definitions, the 383 authentication service can alternatively directly add the 'rcd' 384 claims to the PASSporT it is creating, whether it is constructed with 385 a PASSporT extension or not. 387 8.1. Procedures for applying 'rcd' as claims only 389 For a given PASSporT using some other extension than 'rcd,' the 390 Authentication Service MAY additionally include the 'rcd' claim as 391 defined in this document. This would result in a set of claims that 392 correspond to the original intended extension with the addition of 393 the 'rcd' claim. 395 The Verification service that receives the PASSporT, if it supports 396 this specification and chooses to, should interpret the 'rcd' claim 397 as simply just an additional claim intended to deliver and/or 398 validate delivered Rich Call Data. 400 8.2. Example for applying 'rcd' as claims only 402 In the case of [I-D.ietf-stir-passport-shaken] which is the PASSporT 403 extension supporting the SHAKEN specification [ATIS-1000074], a 404 common case for an Authenication service to co-exist in a CSP network 405 along with the authority over the calling name used for the call. 406 Rather than require two identity headers, the CSP Authenticaton 407 Service can apply both the SHAKEN PASSporT claims and extension and 408 simply add the 'rcd' required claims defined in this document. 410 For example, the PASSporT claims for the 'shaken' PASSporT with 'rcd' 411 claims would be as follows: 413 Protected Header 414 { 415 "alg":"ES256", 416 "typ":"passport", 417 "ppt":"shaken", 418 "x5u":"https://cert.example.org/passport.cer" 419 } 420 Payload 421 { 422 "attest":"A" 423 "dest":{"uri":["sip:alice@example.com"]} 424 "iat":"1443208345", 425 "orig":{"tn":"12155551212"}, 426 "origid":"123e4567-e89b-12d3-a456-426655440000" 427 "rcd":{"nam":"Alice Atlanta"} } 428 } 429 A Verification Service that supports 'rcd' and 'shaken' PASSporT 430 extensions will be able to receive the above PASSporT and interpret 431 both the 'shaken' claims as well as the 'rcd' defined claim. 433 If the Verification Service only understands the 'shaken' extension 434 claims but doesn't support 'rcd', the 'rcd' can simply be ignored and 435 disregarded. 437 9. Acknowledgements 439 We would like to thank Robert Sparks for helpful suggestions. 441 10. IANA Considerations 443 10.1. JSON Web Token Claim 445 This specification requests that the IANA add a new claim to the JSON 446 Web Token Claims registry as defined in [RFC7519]. 448 Claim Name: "rcd" 450 Claim Description: Caller Name Information 452 Change Controller: IESG 454 Specification Document(s): [RFCThis] 456 10.2. PASSporT Types 458 This specification requests that the IANA add a new entry to the 459 PASSporT Types registry for the type "rcd" which is specified in 460 [RFCThis]. 462 10.3. PASSporT RCD Types 464 This document requests that the IANA create a new registry for 465 PASSporT RCD types. Registration of new PASSporT RCD types shall be 466 under the Specification Required policy. 468 This registry is to be initially populated with a single value for 469 "nam" which is specified in [RFCThis]. 471 11. Security Considerations 473 Revealing information such as the name, location, and affiliation of 474 a person necessarily entails certain privacy risks. Baseline 475 PASSporT has no particular confidentiality requirement, as the 476 information it signs over in a using protocol like SIP is all 477 information that SIP carries in the clear anyway. Transport-level 478 security can hide those SIP fields from eavesdroppers, and the same 479 confidentiality mechanisms would protect any PASSporT(s) carried in 480 SIP. 482 More TBD. 484 12. References 486 12.1. Normative References 488 [I-D.ietf-stir-oob] 489 Rescorla, E. and J. Peterson, "STIR Out-of-Band 490 Architecture and Use Cases", draft-ietf-stir-oob-03 (work 491 in progress), July 2018. 493 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 494 A., Peterson, J., Sparks, R., Handley, M., and E. 495 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 496 DOI 10.17487/RFC3261, June 2002, 497 . 499 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 500 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 501 DOI 10.17487/RFC6919, April 2013, 502 . 504 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 505 Telephone Identity Problem Statement and Requirements", 506 RFC 7340, DOI 10.17487/RFC7340, September 2014, 507 . 509 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 510 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 511 . 513 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 514 "Authenticated Identity Management in the Session 515 Initiation Protocol (SIP)", RFC 8224, 516 DOI 10.17487/RFC8224, February 2018, 517 . 519 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 520 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 521 . 523 12.2. Informative References 525 [ATIS-1000074] 526 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 527 of Asserted information using toKENs (SHAKEN) 528 ", January 2017. 531 [I-D.ietf-stir-passport-shaken] 532 Wendt, C. and M. Barnes, "PASSporT SHAKEN Extension 533 (SHAKEN)", draft-ietf-stir-passport-shaken-04 (work in 534 progress), October 2018. 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, 538 DOI 10.17487/RFC2119, March 1997, 539 . 541 Authors' Addresses 543 Jon Peterson 544 Neustar Inc. 545 1800 Sutter St Suite 570 546 Concord, CA 94520 547 US 549 Email: jon.peterson@neustar.biz 551 Chris Wendt 552 Comcast 553 Comcast Technology Center 554 Philadelphia, PA 19103 555 USA 557 Email: chris-ietf@chriswendt.net