From nobody Sun Feb 5 18:08:52 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1520F129565 for ; Sun, 5 Feb 2017 18:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDESLHzjwDS1 for ; Sun, 5 Feb 2017 18:08:50 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C291B129502 for ; Sun, 5 Feb 2017 18:08:49 -0800 (PST) Received: (qmail 45420 invoked from network); 6 Feb 2017 02:08:48 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 6 Feb 2017 02:08:48 -0000 Date: 6 Feb 2017 02:08:26 -0000 Message-ID: <20170206020826.1108.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [dispatch] Updating DKIM for stronger crypto X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 02:08:51 -0000 The DKIM spec RFC 6376 specifies the hash algorithm to use to make hashes of e-mail message bodies and headers, and the signing algorithm to use to sign them, with the results placed in a header in the message. To check signatures, the recipient looks up the verification keys in the DNS, where it's stored in TXT records. Every signature includes a tag saying what hash and signature algorithms it used, and every key record includes a tag saying what signature algorithm the key is for. The plan was always that we'd be able to move to newer algorithms when needed. Early versions of DKIM used SHA1 hashes, but by the time the original spec was published in 2007, we'd added SHA256 and the spec says that everyone should use SHA256 hashes but also has to verify SHA1 hashes. In practice everyone uses SHA256. The only signature algorithm is RSA, and the spec says that verifiers must handle signatures from 512 to 2K bits and strongly suggests at least 1K bits. So far, that has not changed. Needless to say, 512 bits is now way too weak, and 1K is iffy, so it would be a good idea to update the advice. Over in DMARC land, there is an anti-DMARC design called ARC which uses DKIM's signing algorithms, and it would be nice to launch ARC with up to date crypto too. The obvious change would be a one sentence update to the DMARC spec saying to sign with at least 2K keys and verifiers must handle at least 4K keys. The code changes to DKIM signers and verifiers would be trivial, and it is my impression that most verifiers handle larger keys now, since they just pass them to OpenSSL or the like. Unfortunately, we have a stupid but significant problem. DKIM keys are published in DNS TXT records, the strings in TXT records are limited to 256 characters, and keys longer than 1K bits don't fit in 256 characters. No problem you might think, since the DKIM spec says that verifiers catenate multiple strings together, so you just break the key into two or three strings. A lot of people manage their DNS using web based crudware at their registrar or DNS provider, and most of the crudware only handles TXT records with one string. You don't have to tell me how broken that is, but the cruddy state of DNS provisioning has been a problem for many years, and nothing we say is going to fix it in any finite amount of time. I note RFCs 7748 and 8032 which remind us that ed25519 has excellent performance with much smaller keys. So I would like to publish a small update to the DKIM spec to add ed25519 as a signature algorithm, require that ed25519 signatures use at least 256 bits, and provide some advice for migration, e.g., publish both keys in separate TXT records and sign with both algorithms for a while. 256-bit keys fit in a single TXT string with ease. Does this seem reasonable? R's, John From nobody Sun Feb 5 18:15:25 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D781293E9 for ; Sun, 5 Feb 2017 18:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OJOcvdYyp-x for ; Sun, 5 Feb 2017 18:15:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B3F120727 for ; Sun, 5 Feb 2017 18:15:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BF867BE39; Mon, 6 Feb 2017 02:15:18 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66xqfmOmN8jV; Mon, 6 Feb 2017 02:15:17 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1CAD1BDF9; Mon, 6 Feb 2017 02:15:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1486347317; bh=Kz0vBnyhf62FGtMKKjfbnMQMU9zS1anaEnS1fOxWiuU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=dtusat06qzvqWsGGJRZiPZF2/NGvArOe3GNq4UQtU2LuhC3sQgLfOp0+A9pi1QUW3 j/5up65fjyZeX7JoUB1a3vNvbJ3GoUGFoJ3+7b/G3nNPcnJo3esQeIVUkIpHyi34FF S1MM5W3GsNs9Zw8xHbgcWy/QjB/sn8pwuFR5fG3E= To: John Levine , dispatch@ietf.org References: <20170206020826.1108.qmail@ary.lan> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 6 Feb 2017 02:15:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170206020826.1108.qmail@ary.lan> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080303000507080001010700" Archived-At: Subject: Re: [dispatch] Updating DKIM for stronger crypto X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 02:15:23 -0000 This is a cryptographically signed message in MIME format. --------------ms080303000507080001010700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/02/17 02:08, John Levine wrote: > Does this seem reasonable? Eminently, assuming implementers want ed25519 and those deploying will adopt it. There are, IMO, good reasons for both to also like that idea, but whether or not they realise that is to be seen I guess. S. --------------ms080303000507080001010700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDYw MjE1MTZaMC8GCSqGSIb3DQEJBDEiBCATP9mj7vztRWm2MmsIfBvgzbwa5YZ0W89elKp9X+Jm UjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAjM3gXmxBFGM5KKTGFo/e37YyI7ziMfGBRtZHdYrnJyrkyNj4NedKv ajVKvGyl9gDb7JzYc+7imIjNeNKOXg7w9Rr0Ie+zL62QzbZQmw6sC5rR80TWoFb7bLLnIC4J rBHn4QZZ8YSHDhFVsLtQd/yJk6hE9CRaDvrnVOGxINZEQjDLoHjv8SPInVLkiLqYTE8i8E+d dKsIEgD8cuD9gg4N1uhEe/UMQONY/Q/viqEpxXa5BkC9au5xrx28Xe8JlSOyasjgjfiyCme8 J5wHGfiC1o189mWVUkXmJITjN8XlhsZyX4wFBxQUpy0bvC3a8qZSH2V0zc5A5xHoOmFT51uV AAAAAAAA --------------ms080303000507080001010700-- From nobody Sun Feb 5 18:33:45 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C061294AD for ; Sun, 5 Feb 2017 18:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=fEVYZhUS; dkim=pass (1536-bit key) header.d=taugh.com header.b=z31bjisP; dkim=pass (1536-bit key) header.d=iecc.com header.b=IMq3UqP7; dkim=pass (1536-bit key) header.d=taugh.com header.b=llHbQ92a Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsZXlceG1Iql for ; Sun, 5 Feb 2017 18:33:39 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7064D129459 for ; Sun, 5 Feb 2017 18:33:39 -0800 (PST) Received: (qmail 49357 invoked from network); 6 Feb 2017 02:33:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=resent-date:resent-from:resent-to:resent-message-id:date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c0cb.5897e082.k1702; bh=KBVbajzxzYIwbyZFkn/DBSi7iNVstJQswtixUPiqmJc=; b=fEVYZhUS/l55NpRaesr6ISqwHqHbVP+J3EEmExeqgJGptKu6QZhEx5njf32Mn7GdYFK3eJlEIZiDoXZ6yJdJ1lzjlKYUCFpDLf/muoFKBv9h3j6RRye0OEa9gK9hLT+bsZfYnxuvBntdNBxPGwfFVNXr3nGVQLRhGxH8MEoYQs4py9LMlVzCcl49kthuL5uaY3qtO8GJ2UTsL4270LY0Kjvew0HY6goSnL/RyRzQMt6Wm9/gVe7bH0P0GE5o+KLw DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=resent-date:resent-from:resent-to:resent-message-id:date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c0cb.5897e082.k1702; bh=KBVbajzxzYIwbyZFkn/DBSi7iNVstJQswtixUPiqmJc=; b=z31bjisPlQPIYs5KzRen7ptubDLLQtBI8oBmuJdrJ7rWmFfpTmrzoC06KkrUvwxq2Z168j9ioyDU24FizZF6AtMx9w8079gHiQY+mpSF0C7r9v8q0DP45azUrnJmvmFvv7ijuqd+fBxloXIaMxIvIS54OCu/FbCZ683IOHlWVvKnY+uJvEj32PIpFKYd2FsZE505sZkhvZAT8KSpCQeM24jsQIRD9zwQWZ6lFBBnC8tvYcmzHV+jKBQVpVVGyh7m Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 06 Feb 2017 02:33:38 -0000 ReSent-Date: Sun, 5 Feb 2017 21:33:32 -0500 (EST) ReSent-From: "John R. Levine" ReSent-To: Dispatch WG ReSent-Message-ID: Date: 5 Feb 2017 21:33:17 -0500 Message-ID: From: "John R Levine" To: "Stephen Farrell" X-Return-Path: X-Delivered-To: johnl@iecc.com X-Received: (qmail 49286 invoked by uid 1014); 6 Feb 2017 02:33:17 -0000 X-Delivered-To: virtual-taugh-johnl@taugh.com X-Received: (qmail 49283 invoked from network); 6 Feb 2017 02:33:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c081.5897e06d.k1702; bh=KBVbajzxzYIwbyZFkn/DBSi7iNVstJQswtixUPiqmJc=; b=IMq3UqP7pXAwYDkWJXmvRZNtOHM4r0PGbX/lnE9SSeeystNyO2syECFz9AxSfc0Jj+EEYx06qmOT4Rq+0PJZWQprvEDYpRoxwqGgdh/EEEDYgFyOBMyiF8tqyr52yrnqtQAceWOEsqE2Sj6wmZDvh92KBWapqOwx9ddgOzqc2wvp2s3Qir0L+TaPSh1m0nr66ajjRMwfHPKG8smaqn5atuKseGg7xX7MhVnvGCHlY28TgIqvK7W2rM6ZJ9DVuVAq DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c081.5897e06d.k1702; bh=KBVbajzxzYIwbyZFkn/DBSi7iNVstJQswtixUPiqmJc=; b=llHbQ92aXqcXAsjTGURi3c8TEx0z3v5OlzbHjC+mTGyqJWMK5rue+IAOLYYVoRvcTaT2dIeh8ZHMaV1+J4KnIW+/STnDHik6gpvM2b7aOdDn3SluUISmPEF1wrwQ2prUOxg8f1/rkmRlzKqULI0LwnP9E9SwLqaYfNJPl11FQ3hHEQGeas59sea0ADYn/QBApDNeH3h8cFsCThfJcQbbwT0ynVwnvL21yDInMQ04wg8EjboTgDdMw4Ost789tsSd X-Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 06 Feb 2017 02:33:17 -0000 In-Reply-To: References: <20170206020826.1108.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-DCC-iecc-Metrics: miucha.iecc.com 1107; Body=1 Fuz1=1 Fuz2=1 ReSent-Subject: Re: [dispatch] Updating DKIM for stronger crypto ReSent-User-Agent: Alpine 2.20 (OSX 67 2015-01-07) Archived-At: Cc: John Levine Subject: Re: [dispatch] Updating DKIM for stronger crypto X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 02:33:44 -0000 > On 06/02/17 02:08, John Levine wrote: >> Does this seem reasonable? > > Eminently, assuming implementers want ed25519 and those deploying will > adopt it. There are, IMO, good reasons for both to also like that idea, > but whether or not they realise that is to be seen I guess. It is my impression that the majority of DKIM signing and verifying is done using a small number of libraries. If we can get the big gorillas on board, and arrange to upgrade the C opendkim, perl Mail::DKIM, and python pydkim, routine upgrades will do most of the rest. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Feb 6 15:22:48 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DC51296B6 for ; Mon, 6 Feb 2017 15:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp86VvcnInHg for ; Mon, 6 Feb 2017 15:22:45 -0800 (PST) Received: from smtp88.iad3a.emailsrvr.com (smtp88.iad3a.emailsrvr.com [173.203.187.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D781296B3 for ; Mon, 6 Feb 2017 15:22:45 -0800 (PST) Received: from smtp28.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8688D51E2; Mon, 6 Feb 2017 18:22:44 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 4473A50E2; Mon, 6 Feb 2017 18:22:44 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.92.108.145] (192-195-83-200.static.monkeybrains.net [192.195.83.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Mon, 06 Feb 2017 18:22:44 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <20170206020826.1108.qmail@ary.lan> Date: Mon, 6 Feb 2017 15:22:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <530C44E1-62EF-4DFF-AED6-ECF78B396C4F@iii.ca> References: <20170206020826.1108.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Updating DKIM for stronger crypto X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 23:22:47 -0000 Hi John,=20 Assuming that some groupr of people wnated to work on this, how would = you suggest organizing the work in IETF? Is this just a draft that gets = AD sponsored be a sec AD, or do we spin up a mini WG that does just one = RFC, or is it an amount of work that it ends up with a WG that produces = more than one RFC? I'm just trying to get a feel of how much work is = involved here.=20 Cullen > On Feb 5, 2017, at 6:08 PM, John Levine wrote: >=20 > The DKIM spec RFC 6376 specifies the hash algorithm to use to make > hashes of e-mail message bodies and headers, and the signing algorithm > to use to sign them, with the results placed in a header in the > message. To check signatures, the recipient looks up the verification > keys in the DNS, where it's stored in TXT records. >=20 > Every signature includes a tag saying what hash and signature > algorithms it used, and every key record includes a tag saying what > signature algorithm the key is for. The plan was always that we'd be > able to move to newer algorithms when needed. Early versions of DKIM > used SHA1 hashes, but by the time the original spec was published in > 2007, we'd added SHA256 and the spec says that everyone should use > SHA256 hashes but also has to verify SHA1 hashes. In practice = everyone > uses SHA256. =20 >=20 > The only signature algorithm is RSA, and the spec says that verifiers > must handle signatures from 512 to 2K bits and strongly suggests at > least 1K bits. So far, that has not changed. >=20 > Needless to say, 512 bits is now way too weak, and 1K is iffy, so it > would be a good idea to update the advice. Over in DMARC land, there > is an anti-DMARC design called ARC which uses DKIM's signing > algorithms, and it would be nice to launch ARC with up to date crypto > too. >=20 > The obvious change would be a one sentence update to the DMARC spec > saying to sign with at least 2K keys and verifiers must handle at > least 4K keys. The code changes to DKIM signers and verifiers would > be trivial, and it is my impression that most verifiers handle larger > keys now, since they just pass them to OpenSSL or the like. >=20 > Unfortunately, we have a stupid but significant problem. DKIM keys > are published in DNS TXT records, the strings in TXT records are > limited to 256 characters, and keys longer than 1K bits don't fit > in 256 characters. No problem you might think, since the DKIM spec > says that verifiers catenate multiple strings together, so you just > break the key into two or three strings. >=20 > A lot of people manage their DNS using web based crudware at their > registrar or DNS provider, and most of the crudware only handles TXT > records with one string. You don't have to tell me how broken that > is, but the cruddy state of DNS provisioning has been a problem for > many years, and nothing we say is going to fix it in any finite amount > of time. >=20 > I note RFCs 7748 and 8032 which remind us that ed25519 has excellent > performance with much smaller keys. So I would like to publish a > small update to the DKIM spec to add ed25519 as a signature algorithm, > require that ed25519 signatures use at least 256 bits, and provide > some advice for migration, e.g., publish both keys in separate TXT > records and sign with both algorithms for a while. 256-bit keys fit > in a single TXT string with ease. >=20 > Does this seem reasonable? >=20 > R's, > John >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Feb 6 15:40:28 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40211296F2 for ; Mon, 6 Feb 2017 15:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 280vZj8Fm9QB for ; Mon, 6 Feb 2017 15:40:25 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0577D1296F0 for ; Mon, 6 Feb 2017 15:40:25 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id v200so57771553ywc.3 for ; Mon, 06 Feb 2017 15:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a7N2wMx8GKb4i6yWIkJhucbDn/MMekub921S95y9B/s=; b=JLoBqLwpYA3H2cZL7EmN2feCQdaCrcGU4qjWoyk4L2ym12R5PiA7spo7s3KkAfPAVH VjZE9cxKwNLkrij8hPGdKY9Oqjcy2QI45kvT8w2LYBqb17wMjPrijZKIbB29ZeFJ6hvD EBKzob8ve0oCWWRZ+/kqK6eg1DAi62oQbw/OPpNYt031LuLNsTkl3ksU/0j+6Vz7Jnak 0bSPc9PgI7sL5ntZtyQTkNRa/PrQH6qc12DZwORHid6PwAJBfw1FxykiH9kCgQD58BWN IOOkeetO9hC7ztCiNsJ1RPt7rPS/YoIPoTkXDaTyjD9Io/JcsGa6+qLCseLRev8DBMMk ZwRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a7N2wMx8GKb4i6yWIkJhucbDn/MMekub921S95y9B/s=; b=t0fuBnHl7nXaAsujLINN+2MSxWbQ1JdQlwXxx2ZbibLYauAwVrO3Ey/5G07l1sswZc xqO50UMt5v3chwn2rvhIkbjQ2VJ8iMROq5fpesYgT/d1gGcIRtESfafnMx9aNOL6bSBF BnN5pd744zU0mJ0eqTg8iVUAIISM0sfygaYU2OV1fn/DE1uJDXDmgAn3k8/7rl6sj7nL +avIqsPV2+o1M5NhBbGCd7trEFACpUeRxgkz4DkOs2vUVxjKwv52ghRbs7Dik7rFLFAl GUIR5xMc5hpPbjDJdqbvJ5Q0O0pvLXyC/VvEBxUi4I0qCeTCvPQFEYngP1FnMiztO6UG eiLA== X-Gm-Message-State: AMke39m1rwhv0pf79FqzoZJlntevimiJwkjDTKhz3/ScQGapFUz3U5+mp33gNUnt9mOrbzIINNhuV+TliogGag== X-Received: by 10.129.162.151 with SMTP id z145mr8826582ywg.337.1486424424321; Mon, 06 Feb 2017 15:40:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Mon, 6 Feb 2017 15:39:43 -0800 (PST) In-Reply-To: <20170206020826.1108.qmail@ary.lan> References: <20170206020826.1108.qmail@ary.lan> From: Eric Rescorla Date: Mon, 6 Feb 2017 15:39:43 -0800 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=94eb2c11555ecc45a00547e5274b Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Updating DKIM for stronger crypto X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 23:40:26 -0000 --94eb2c11555ecc45a00547e5274b Content-Type: text/plain; charset=UTF-8 On Sun, Feb 5, 2017 at 6:08 PM, John Levine wrote: > > Needless to say, 512 bits is now way too weak, and 1K is iffy, so it > would be a good idea to update the advice. Well, I certainly agree that at some point it would be good to get to larger than 1024-bit RSA keys, we're fairly far from the point where it's cheap to factor a 1024-bit RSA key (absent a quantum computer, in which case we've got bigger problems), and given that the impact of a complete break here is you get to forge mail, I'm not sure how urgent this is. The obvious change would be a one sentence update to the DMARC spec > saying to sign with at least 2K keys and verifiers must handle at > least 4K keys. The code changes to DKIM signers and verifiers would > be trivial, and it is my impression that most verifiers handle larger > keys now, since they just pass them to OpenSSL or the like. > > Unfortunately, we have a stupid but significant problem. DKIM keys > are published in DNS TXT records, the strings in TXT records are > limited to 256 characters, and keys longer than 1K bits don't fit > in 256 characters. No problem you might think, since the DKIM spec > says that verifiers catenate multiple strings together, so you just > break the key into two or three strings. > > A lot of people manage their DNS using web based crudware at their > registrar or DNS provider, and most of the crudware only handles TXT > records with one string. You don't have to tell me how broken that > is, but the cruddy state of DNS provisioning has been a problem for > many years, and nothing we say is going to fix it in any finite amount > of time. > > I note RFCs 7748 and 8032 which remind us that ed25519 has excellent > performance with much smaller keys. So I would like to publish a > small update to the DKIM spec to add ed25519 as a signature algorithm, > require that ed25519 signatures use at least 256 bits, and provide > some advice for migration, e.g., publish both keys in separate TXT > records and sign with both algorithms for a while. 256-bit keys fit > in a single TXT string with ease. > > Does this seem reasonable? > Well, sort of. It seems like this message suggests that the decision to store the key in the TXT record is perhaps not the optimal design. If you were storing a digest (as DANE does) then you could use arbitrary sized RSA keys without running into the 256-character limit. This would also have the advantage that if you ever needed to move to some post-quantum algorithm with big keys (e.g., digest signatures), you would be in a somewhat better position. With that said, moving to elliptic curve is a good idea and Ed25519 seems like a reasonable choice. Note that the requirement that "ed25519 signatures use at least 256 bits" is incoherent. Ed25519 denotes a specific elliptic curve of size 255 bits. -Ekr > > R's, > John > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --94eb2c11555ecc45a00547e5274b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Feb 5, 2017 at 6:08 PM, John Levine <johnl@taugh.com> wrot= e:
Needless to say, 512 bits is now way too weak, and 1K is iffy, so it
would be a good idea to update the advice.=C2=A0

Well, I certainly agree that at some point it would be good to get to= larger
than 1024-bit RSA keys, we're fairly far from the poi= nt where it's cheap
to factor a 1024-bit RSA key (absent a qu= antum computer, in which case
we've got bigger problems), and= given that the impact of a complete break
here is you get to for= ge mail, I'm not sure how urgent this is.


=
The obvious change would be a one sentence update to the DMARC spec
saying to sign with at least 2K keys and verifiers must handle at
least 4K keys.=C2=A0 The code changes to DKIM signers and verifiers would be trivial, and it is my impression that most verifiers handle larger
keys now, since they just pass them to OpenSSL or the like.

Unfortunately, we have a stupid but significant problem.=C2=A0 DKIM keys are published in DNS TXT records, the strings in TXT records are
limited to 256 characters, and keys longer than 1K bits don't fit
in 256 characters.=C2=A0 No problem you might think, since the DKIM spec says that verifiers catenate multiple strings together, so you just
break the key into two or three strings.

A lot of people manage their DNS using web based crudware at their
registrar or DNS provider, and most of the crudware only handles TXT
records with one string.=C2=A0 You don't have to tell me how broken tha= t
is, but the cruddy state of DNS provisioning has been a problem for
many years, and nothing we say is going to fix it in any finite amount
of time.

I note RFCs 7748 and 8032 which remind us that ed25519 has excellent
performance with much smaller keys.=C2=A0 So I would like to publish a
small update to the DKIM spec to add ed25519 as a signature algorithm,
require that ed25519 signatures use at least 256 bits, and provide
some advice for migration, e.g., publish both keys in separate TXT
records and sign with both algorithms for a while.=C2=A0 256-bit keys fit in a single TXT string with ease.

Does this seem reasonable?

Well, sort o= f.

It seems like this message suggests that the de= cision to store the key in
the TXT record is perhaps not the opti= mal design. If you were storing a
digest (as DANE does) then you = could use arbitrary sized RSA keys without
running into the 256-c= haracter limit. This would also have the advantage
that if you ev= er needed to move to some post-quantum algorithm with big
keys (e= .g., digest signatures), you would be in a somewhat better position.
<= div>
With that said, moving to elliptic curve is a good idea = and Ed25519 seems
like a reasonable choice. Note that the require= ment that "ed25519 signatures
use at least 256 bits" is= incoherent. Ed25519 denotes a specific elliptic curve
of size 25= 5 bits.

-Ekr
=C2=A0

R's,
John



_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--94eb2c11555ecc45a00547e5274b-- From nobody Mon Feb 6 15:48:55 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2592129785 for ; Mon, 6 Feb 2017 15:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=oHFLDj8Q; dkim=pass (1536-bit key) header.d=taugh.com header.b=fDSfr9CU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRuVTBydNcp5 for ; Mon, 6 Feb 2017 15:48:52 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E138E129762 for ; Mon, 6 Feb 2017 15:48:51 -0800 (PST) Received: (qmail 26953 invoked from network); 6 Feb 2017 23:48:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6947.58990b63.k1702; bh=c0+9Ps1YM4spBaM1N/35yIfE/TI8ycUlJr5HAhXuycY=; b=oHFLDj8QzQw+OmU0co/wOwi+Oo1jbe6qCa83A4jUUK22RiswRo0LMvujz5OnZv/ViCnNCXVxIVlctyuMT4dXNUmtRzsD80DiNyCI+6juGgfzHhOUdy6Zs3T3+HkwV5olM6aM8TUW3ktyr3nRXhBMUWpHVx/3lEFXkXLSL16bHwfUNcUeRQoqYQoqSvTn1dTDIuv9l7o4tWo+vmx9tijvvEkINSlCiUBaMldlT1PHRYvotjpU8NezwGB5+EWFv6kH DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6947.58990b63.k1702; bh=c0+9Ps1YM4spBaM1N/35yIfE/TI8ycUlJr5HAhXuycY=; b=fDSfr9CUmNDMiVSwPaoT3f+en10psQ0HUqxklf8FeoqU8pEvlCHT80Bbu9TaywiFbgqt5ZdpM2WxvaVERoQt69UNbeYnbVYYlWn9Q6O+DhSN6Aw3rhw0bO26xK/jhllvvwuW3ZtE2rtQ0LlVMhONosf2kEo6cgOXTa/h/Dm+qIJ8cAgs1tbpPWMjf9j1s0nIO9XZqt7TmYFCpc9pk6mUy5VjzLs3AQ8WOyROn4XAK7yX95FhN4C5FDj8YSO+FJEO Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 06 Feb 2017 23:48:50 -0000 Date: 6 Feb 2017 18:48:50 -0500 Message-ID: From: "John R Levine" To: "Eric Rescorla" In-Reply-To: References: <20170206020826.1108.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Updating DKIM for stronger crypto X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 23:48:53 -0000 >> Needless to say, 512 bits is now way too weak, and 1K is iffy, so it >> would be a good idea to update the advice. > > Well, I certainly agree that at some point it would be good to get to larger > than 1024-bit RSA keys, we're fairly far from the point where it's cheap > to factor a 1024-bit RSA key ... It's not urgent, but given the ARC work, it'd be nice to do this once rather than twice. > It seems like this message suggests that the decision to store the key in > the TXT record is perhaps not the optimal design. If you were storing a > digest (as DANE does) then you could use arbitrary sized RSA keys without > running into the 256-character limit. This would also have the advantage > that if you ever needed to move to some post-quantum algorithm with big > keys (e.g., digest signatures), you would be in a somewhat better position. Hmmn. So we'd put a copy of the verification key into the signature, and the verifier would hash that and see if it matched the hash in the DNS? I suppose that could work, but if we're going to open up the code, given that elliptic signers and verifiers are showing up in crypto libraries it's be a lot simpler change to DKIM. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Feb 6 15:50:27 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A0512952D for ; Mon, 6 Feb 2017 15:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=IkP6TBx7; dkim=pass (1536-bit key) header.d=taugh.com header.b=CLudHo3x Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsZPdQZzGs4s for ; Mon, 6 Feb 2017 15:50:24 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BE51294E6 for ; Mon, 6 Feb 2017 15:50:24 -0800 (PST) Received: (qmail 27280 invoked from network); 6 Feb 2017 23:50:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6a8d.58990bbf.k1702; bh=qCZZx/OYF5MzdohiuztscZPvZV625nZwvz3ahLYECAI=; b=IkP6TBx7d1YL2/facFc6NDNnryqaPeLqi3z7z0qWrv/SAUZvIPhV7Q52UxtfGPwnuH9MQmwMaprkOsj7H79evX7te6eTpf0CLSfzaYF8savjOjJzhvO8kmC//w35ENZOPihjt254FufSCl7jpf9yd/DQyvEvccdxrKYrZDc1T8K9010Yg2YkEloVEdn09D1Lr10KcZAUqghWRiq5abQe3VEHnP0tXd35nstHB8OumYGbBUpXwJDc9QtRXlrfmoqp DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6a8d.58990bbf.k1702; bh=qCZZx/OYF5MzdohiuztscZPvZV625nZwvz3ahLYECAI=; b=CLudHo3xcUz8fRluKoz8HsQYjCTgU4Vk57M5t2Grg5iNvyjasbg72CaJoWt6JqPcybWEjFvoAxtFF/OP3fm831a2oZyC3oAGAGoMZ7THmWXm/kIDXvz6oaI1cNa1psbSDaWnIifOHSycViRo3cBiSEKjjolhXZOxZ7dmoBg5WJBbm3h+Wxosaie1rth7sJqyboKsjfkDIMOZPjrz3a+cil9HjIqhzmkEhGfSmKRsGGkfVjqNDnCfZyKGmbz7SIKO Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 06 Feb 2017 23:50:23 -0000 Date: 6 Feb 2017 18:50:23 -0500 Message-ID: From: "John R Levine" To: "Cullen Jennings" In-Reply-To: <530C44E1-62EF-4DFF-AED6-ECF78B396C4F@iii.ca> References: <20170206020826.1108.qmail@ary.lan> <530C44E1-62EF-4DFF-AED6-ECF78B396C4F@iii.ca> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: Dispatch WG Subject: Re: [dispatch] Updating DKIM for stronger crypto X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 23:50:25 -0000 > Assuming that some groupr of people wnated to work on this, how would > you suggest organizing the work in IETF? Is this just a draft that gets > AD sponsored be a sec AD, or do we spin up a mini WG that does just one > RFC, or is it an amount of work that it ends up with a WG that produces > more than one RFC? I'm just trying to get a feel of how much work is > involved here. I should ask the authors of the current DKIM spec. If we all agree what we need to do, it could be a straightforward AD sponsored draft. If there's disagreement, e.g., about the migration strategy, it'd likely need a mini WG. R's, John From nobody Mon Feb 6 16:06:17 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32DC1297C3 for ; Mon, 6 Feb 2017 16:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpzIa24HsND8 for ; Mon, 6 Feb 2017 16:06:15 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F5E1297BF for ; Mon, 6 Feb 2017 16:06:15 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id w75so58064386ywg.1 for ; Mon, 06 Feb 2017 16:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VQwenK9eYrAOAi5I4HyEh91kXV0pP3keX2bg1eydLuY=; b=A8UNE2hlDDcAqzcfuT6Gk4UBS1rA8FZH+9d9OEol+w8GxVAnUhIgR/iChrvisfaqRc OQqbPtxvOcZEJw67WwF9wMwaSiusCQj/r2qed6rxDfIA+StJn2j9a14lUVsc2a+2CqUz 5MBwci5JRP/VltcDlzJnN6xwLCmwGZ+Tm3qUG4ymWWg/oCpsIR7kHYGorUMyjX5xZCQ1 QRPi9V7KQ6a42xSfyGDe7y28anE8oRIq9Jy+zmO+UvJs8298D/V4IkVAIogVB5Ku7KpP sNtWI873HaOtElpa7Mx/wcQQV+16xMQCKCCev+TSo3bQV++lBwwQorRge0YLu/O0jk9F lW4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VQwenK9eYrAOAi5I4HyEh91kXV0pP3keX2bg1eydLuY=; b=e7mi20dOZTnyMVMAYDpV0j50pIDus46s3XmxMK3ByrmTpgqhpdXzMhCJ9zT/wStBhF uN38/mOVe6AnlGqQrsU+Mx+wNZUu5hHUhmtE9+u+NwVC8nvO+Q7qmbmn8LpBJdeYnua9 R4oMyXhctblXi1CXMpf9Pjr8X/+0GN27gpvakkq80kShXV22P+zEhKL8cQn42IV7B0CK tpU3VIovQGdfmXmla1i3eMa07Mhe9Talbtvx9EFL+0/egZYbysmhQGTbhRC0cINfmiz5 rDXzWhSNR3v9+VDTLuanp8L6E2IpReSIBI/RcSWcLNRV7m/dFoWuGCw0kjb4lco3jEm5 p8Iw== X-Gm-Message-State: AMke39ledZrHKwbdioBxRsZjiPjgvP5q+C6RLg5JGFiNbXGsBf8OVaUEEToxweFcv7OT0Efuobrdv/HSK9Wxhw== X-Received: by 10.129.162.151 with SMTP id z145mr8892851ywg.337.1486425974818; Mon, 06 Feb 2017 16:06:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Mon, 6 Feb 2017 16:05:34 -0800 (PST) In-Reply-To: References: <20170206020826.1108.qmail@ary.lan> From: Eric Rescorla Date: Mon, 6 Feb 2017 16:05:34 -0800 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=94eb2c11555e36ee6b0547e58460 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Updating DKIM for stronger crypto X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 00:06:17 -0000 --94eb2c11555e36ee6b0547e58460 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 6, 2017 at 3:48 PM, John R Levine wrote: > Needless to say, 512 bits is now way too weak, and 1K is iffy, so it >>> would be a good idea to update the advice. >>> >> >> Well, I certainly agree that at some point it would be good to get to >> larger >> than 1024-bit RSA keys, we're fairly far from the point where it's cheap >> to factor a 1024-bit RSA key ... >> > > It's not urgent, but given the ARC work, it'd be nice to do this once > rather than twice. > > It seems like this message suggests that the decision to store the key in >> the TXT record is perhaps not the optimal design. If you were storing a >> digest (as DANE does) then you could use arbitrary sized RSA keys without >> running into the 256-character limit. This would also have the advantage >> that if you ever needed to move to some post-quantum algorithm with big >> keys (e.g., digest signatures), you would be in a somewhat better >> position. >> > > Hmmn. So we'd put a copy of the verification key into the signature, and > the verifier would hash that and see if it matched the hash in the DNS? Yes. > I suppose that could work, but if we're going to open up the code, given > that elliptic signers and verifiers are showing up in crypto libraries it's > be a lot simpler change to DKIM. I don't see why this would be the case. Think of signature verification as a function F(K, M) -> {true, false} Ordinarily K is the public key, and M is the message, but if you instead store H(K_pub) in the DNS, and send M = {K_pub, Message}, it's the same underlying interface. And as I indicated, this has other benefits, which include being able to handle cryptographic systems with much larger public keys if we ever need them. -Ekr > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > --94eb2c11555e36ee6b0547e58460 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 6, 2017 at 3:48 PM, John R Levine <johnl@taugh.com> wrote:
Needless to say, 512 bits is now way too weak, and 1K is iffy, so it
would be a good idea to update the advice.

Well, I certainly agree that at some point it would be good to get to large= r
than 1024-bit RSA keys, we're fairly far from the point where it's = cheap
 to factor a 1024-bit RSA key ...

It's not urgent, but given the ARC work, it'd be nice to do this on= ce rather than twice.

It seems like this message suggests that the decision to store the key in the TXT record is perhaps not the optimal design. If you were storing a
digest (as DANE does) then you could use arbitrary sized RSA keys without running into the 256-character limit. This would also have the advantage that if you ever needed to move to some post-quantum algorithm with big
keys (e.g., digest signatures), you would be in a somewhat better position.=

Hmmn.=C2=A0 So we'd put a copy of the verification key into the signatu= re, and the verifier would hash that and see if it matched the hash in the = DNS?

Yes.

=C2=A0
=C2=A0 I suppose that could work, but if= we're going to open up the code, given that elliptic signers and verif= iers are showing up in crypto libraries it's be a lot simpler change to= DKIM.

I don't see why this would be th= e case. Think of signature verification as a function

<= div>=C2=A0 F(K, M) -> {true, false}

Ordinarily = K is the public key, and M is the message, but if you instead store H(K_pub= )
in the DNS, and send M =3D {K_pub, Message}, it's the same = underlying interface. And
as I indicated, this has other benefits= , which include being able to handle cryptographic
systems with m= uch larger public keys if we ever need them.

-Ekr<= /div>
=C2=A0
Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

--94eb2c11555e36ee6b0547e58460-- From nobody Mon Feb 6 16:38:49 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A58E129503 for ; Mon, 6 Feb 2017 16:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=qsb4O2bY; dkim=pass (1536-bit key) header.d=taugh.com header.b=vDolPep3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x07Ecsj_Y1S for ; Mon, 6 Feb 2017 16:38:47 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE691294FB for ; Mon, 6 Feb 2017 16:38:47 -0800 (PST) Received: (qmail 33420 invoked from network); 7 Feb 2017 00:38:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=828a.58991716.k1702; bh=U2jC1kFhzBFkK7M87PExOcgzPgMbwN/0s0NGyZUTN9U=; b=qsb4O2bYCm7av4GKk3EXh/KyBbfnf5KjNFLnUBtN37KujTZN+Pdy7Z+derYDzfnmCSNDn8gH/2zrJ3y/QaSD4kVjiirRT2BmZWU9EcUiKHkXScb0P6fNBdcJuopMQVr+B60XOExQYHqrpUOv1Hh9F4/xpsvfN5/GvyJGV1lgUyLytvTQzryqVwTJo9ulV65N8/8ixMi7oTb/Nnznhqd/bREC9swS32TV2ytO1dMTuMUROUhs0DELMCZBnZ9yi9Cs DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=828a.58991716.k1702; bh=U2jC1kFhzBFkK7M87PExOcgzPgMbwN/0s0NGyZUTN9U=; b=vDolPep3SPxDruxwKF+98c++bdbRAnw/S3szsChLQO2mTpRE4gHUK7Z8yy+CzwMdYJVFiIpSjvCLfgpQaxVXAhN9mZKHWZ0+JZS4pzRecxbFNUhkcW12f0imc1jesxygbLegLdrAwbDShKwUQzXIKhkGJjphkFOI09fNdBX+voY2pBKy8ND3Z3rSmCj1TerlXcYUKDbGAHQSZogZNoQMr68lnEZV2pF8sFs7AMCxTJ1tkiSmLH3AMgSzTCmTZoc8 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 07 Feb 2017 00:38:46 -0000 Date: 6 Feb 2017 19:38:45 -0500 Message-ID: From: "John R Levine" To: "Eric Rescorla" In-Reply-To: References: <20170206020826.1108.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Updating DKIM for stronger crypto X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 00:38:48 -0000 >> I suppose that could work, but if we're going to open up the code, given >> that elliptic signers and verifiers are showing up in crypto libraries it's >> be a lot simpler change to DKIM. > I don't see why this would be the case. Think of signature verification as > a function ... I meant a simpler change to the code. R's, John From nobody Mon Feb 6 16:40:51 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DDF1293E4 for ; Mon, 6 Feb 2017 16:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hUca_6pvYYr for ; Mon, 6 Feb 2017 16:40:49 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDE4126D73 for ; Mon, 6 Feb 2017 16:40:47 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id v200so58379802ywc.3 for ; Mon, 06 Feb 2017 16:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ysoXmOHC2q9564wkiKLYAQE05DPzYYeXaffAyR1eTW0=; b=h+dWAI6gEFlmQ8z5V/+w1MASTSGqgtfsMdfHJZERK5fBOsyTfiEQugqriqE0ZCwBaz S6tSt/UtMYq5jFr6Gcc+Fhkq/g+j6TjLkWPPOEC/gUTs1QajaV0t1dRcS0v2Mh6mYX04 8oEZVByZkFodU4As5Ps/L9mHGv/wOZaNnnlQXlGRsjUjqzeqUjfgSQRNoUyJH+ZHXcjy oSxEOmN71oE9QHFnQn0bHsREia0LWB6pkQYWRwtOR6/fHYQMZYNxY+CJzE8FigUbT9SE 0ziRgHa++TMcs83lMABBm37eolXyeYrNqlPZyfF4HlMCjHhqXiCxvQPOZf46uNTqx47c x+Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ysoXmOHC2q9564wkiKLYAQE05DPzYYeXaffAyR1eTW0=; b=II5WsM9VHBUTZ6NbLNrtralnYapxyieSJ7gAVxIVvGsM8AHEEREgHsaYm3DitWfGk0 7VWsU/eYzqSECGTEkvt3MkbqTxBA4hMPFJ1613s4pcPMAt+3N2M/CY0tYorMY89bz0YK c1W1TM19SMDgVU7wN52vJy83dACBf9VZXOb+RiYKTPHe5puW1NGty/tLKQ9kzH5jXwct XN0Ior+e1zy6ml4HOhzxJRGc0wL81MaOBB6uNAh5SKpM7WsRnpoOXfPmHldlWG1PVMjs XmzUwFjOYkB3/c3fK2rMOXYtl1oWxE1dVY2ikpNdja6Fr2sUpsyjfvZmiksSpfVFp4R4 TTww== X-Gm-Message-State: AIkVDXKckdOa5JpuO6V8ZLdH7eiUVWT1fLZiH3gx5jpwSzrjZXIB/esWhCSioVO3n6mtQwd6avEkD+Ni0aBzJA== X-Received: by 10.129.125.84 with SMTP id y81mr8510182ywc.120.1486428046180; Mon, 06 Feb 2017 16:40:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Mon, 6 Feb 2017 16:40:05 -0800 (PST) In-Reply-To: References: <20170206020826.1108.qmail@ary.lan> From: Eric Rescorla Date: Mon, 6 Feb 2017 16:40:05 -0800 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a114928baadf2580547e5ffcf Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Updating DKIM for stronger crypto X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 00:40:50 -0000 --001a114928baadf2580547e5ffcf Content-Type: text/plain; charset=UTF-8 On Mon, Feb 6, 2017 at 4:38 PM, John R Levine wrote: > I suppose that could work, but if we're going to open up the code, given >>> that elliptic signers and verifiers are showing up in crypto libraries >>> it's >>> be a lot simpler change to DKIM. >>> >> > I don't see why this would be the case. Think of signature verification as >> a function ... >> > > I meant a simpler change to the code. > So did I and I don't think it's "a lot simpler" -Ekr > R's, > John > --001a114928baadf2580547e5ffcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 6, 2017 at 4:38 PM, John R Levine <johnl@taugh.com> wrote:
=C2=A0 I suppose that could work, but if we're going to open up the cod= e, given
that elliptic signers and verifiers are showing up in crypto libraries it&#= 39;s
be a lot simpler change to DKIM.

I don't see why this would be the case. Think of signature verification= as
 a function ...

I meant a simpler change to the code.

S= o did I and I don't think it's "a lot simpler"
=
-Ekr


R's,
John

--001a114928baadf2580547e5ffcf-- From nobody Wed Feb 8 13:46:23 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AD4129408 for ; Wed, 8 Feb 2017 13:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=thinkingcat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRCvo_pD8bz7 for ; Wed, 8 Feb 2017 13:46:19 -0800 (PST) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D213C1293FB for ; Wed, 8 Feb 2017 13:46:19 -0800 (PST) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 8C53D20047601; Wed, 8 Feb 2017 13:46:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :subject:date:message-id:references:mime-version:content-type :content-transfer-encoding; s=thinkingcat.com; bh=B/RUUhOn5gpi3W z9q17xSd0ag3M=; b=l9qgOXpj/zFgLHSupZMszZZRNQGCMGLoO+2DGGNDI5Lb3t 3yjjblrRNSGCEjE5CUbD7dyBU08IgL5WXq46YBhCuS/eselwpLKhE6kWnjn0GkUV FT+VyAn7EMiH9sL7ruCMzY1gK/cUJEoT2GA4VNyxerhLeWjdHta99OzsGKuLc= Received: from [192.168.1.5] (pool-71-171-98-61.clppva.fios.verizon.net [71.171.98.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id F035520047607; Wed, 8 Feb 2017 13:46:18 -0800 (PST) From: "Leslie Daigle" To: dispatch@ietf.org Date: Wed, 08 Feb 2017 16:46:17 -0500 Message-ID: <7CF5BF4F-7410-4FBE-BE36-8577E4F90C17@thinkingcat.com> References: <3F95E981-D341-4FAB-8C25-4A018A9761A7@thinkingcat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_8C7BEC80-37B0-401D-8054-687C36B02084_=" X-Mailer: MailMate (1.9.6r5319) Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] Fwd: [GGIE] DRAFT bof proposal for IETF 98 in Chicago X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:46:22 -0000 --=_MailMate_8C7BEC80-37B0-401D-8054-687C36B02084_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Hi, Following up the discussion of GGIE at the last 2 DISPATCH meetings, we=20 are going to propose a BoF for IETF 98. Please see below for 1/=20 information about the GGIE mailing list [*] where it=E2=80=99s being=20 discussed, and 2/ the draft BoF proposal. As noted in the message, we=20 are happy to have suggestions on how to improve the proposal/move the=20 work forward. Thanks, Leslie. [*] Subscription and other info here: =20 https://www.ietf.org/mailman/listinfo/ggie/ --=20 ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises LLC ldaigle@thinkingcat.com ------------------------------------------------------------------- Forwarded message: > From: Leslie Daigle > To: ggie@ietf.org > Cc: Deen, Glenn > Subject: DRAFT bof proposal for IETF 98 in Chicago > Date: Wed, 08 Feb 2017 16:32:16 -0500 > > Hi, > > Please find below a proposal for a GGIE BoF (WG-forming) at IETF 98 in=20 > Chicago. We will be submitting the proposal by the deadline this=20 > Friday, but would be happy to have suggestions to improve the proposal=20 > before then. > > One of the things we=E2=80=99ve beed advised is that=20 > GGIE-proponents-other-than-Glenn-and-Leslie are pretty invisible to=20 > the IESG. If there doesn=E2=80=99t seem to be other interest, there wo= n=E2=80=99t=20 > be much justification for a BoF. > > Now is the time, and here is the place, to voice your support for=20 > furthering this discussion! > > Thanks, > Leslie. > > =E2=80=948<=E2=80=94=E2=80=948<=E2=80=94=E2=80=948<=E2=80=94=E2=80=94 > > Name: Glass to Glass Internet Ecosystem (GGIE) > > Description: > > Video is without rival the top use of Internet bandwidth, and its ever=20 > growing demand for more bandwidth easily out paces the new capacity=20 > being added both globally and regionally with no let up in sight. =20 > Users are frustrated by quality, buffering, and stuttering problems.=20 > Video providers and access networks are investing heavily to keep up=20 > with demand. Significant work has be done at the application layer=20 > producing more efficient codecs and innovative adaptive bitrate=20 > transports like MPEG-DASH. These access investments and application=20 > layer work have helped but they alone have not been enough. > > This BoF will introduce the Glass to Glass Internet Ecosystem (GGIE)=20 > which focuses on network level innovations to compliment the efforts=20 > at the application layer and access networks. The proposed GGIE work=20 > includes enabling adaptive bitrate transports like MPEG-DASH to use=20 > IPv6 as their video segment addressing scheme which in turn permits=20 > use of advanced IPv6 network features such as Segment Routing. A GGIE=20 > goal is to enabling video and network routing and management to work=20 > more cooperatively and efficiently to transport video, and to do so in=20 > a backward compatible ways to permit exiting devices and players to=20 > take advantage of the improved network efficiencies. > > > > Agenda > Agenda bash, scribe, minute taker [10min] > > Context setting [15min] > Highlights of the Internet Video Scaling Problem > Specific aims of the GGIE work > Relationship to other IETF activity > Relationship to work in other fora > =09 > Overview of existing GGIE work =E2=80=94 Network level proposal= s,=20 > demo [50min] > - IPv6 Prefix addressing of MPEG-DASH packaged video > - Content identifier to content address mapping using=20 > MARS > - GGIE prototype demo > > Where from here? [45min] > Known open questions > Potential for IETF work =E2=80=94 is there interest to pursue? > If applicable: Discussion of draft charter for WG > =09 > > Demo of GGIE prototype > Q&A & Discussion > > Status: WG Forming > Responsible AD: Ben Campbell > BoF proponents: Glenn Deen / Leslie Daigle > BoF chairs: TBD > Number of people expected to attend: TBD > Length of session (1, 1.5, 2, or 2.5 hours): 2 hours > Conflicts to avoid (whole Areas and/or WGs): DISPATCH WG and TBD > Links to the mailing list, draft charter if any, relevant=20 > Internet-Drafts, etc. > Mailing List: =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/gg= ie > Draft charter: see below > Relevant drafts: > draft-deen-daigle-ggie-02 : Glass to Glass Internet=20 > Ecosystem Introduction > draft-rose-deen-ggie-use-cases-00 : GGIE Internet Video Use=20 > Cases =09 > draft-daigle-deen-ggie-uri-snaptr-00 : Glass to Glass Internet=20 > Ecosystem URI and S-NAPTR Use > draft-deen-naik-ggie-men-mpeg-dash-00 : Using Media Encoding=20 > Networks to address MPEG-DASH video (This is expired, but we can=20 > easily re-spin, or wait for WG input). > > > > > Glass to Glass Internet Ecosystem (GGIE) -- Draft Charter > > Due to its size and sensitivity to network conditions, the transport=20 > of video over the Internet has highlighted a significant scalability=20 > problem for the Internet. Addressing this scalability problem=20 > requires better integration between application transport and=20 > networking technologies and leveraging IPv6. The GGIE working group=20 > will define a set of fundamental building blocks bridging video=20 > application use of the network and core network services of=20 > addressing, routing, and naming. Through standardization, of such=20 > fundamentals, a common base platform for new interoperable innovation=20 > on video transport efficiency and scalability will be enabled. > > The scalability problem is driven by both professional and user=20 > generated content, fortunately both types of content use the same=20 > transport technologies which permits the working group=E2=80=99s output= to=20 > apply equally to them. Likewise, in addition to the use the network to=20 > transport video for viewing, the network is extensively used in video=20 > creation workflows of capture and editing, and distribution workflows=20 > of encoding, packaging, and distribution to edge caches for playback. =20 > The working group will address both viewing and creation/distribution=20 > workflows. > > To that end, the GGIE working group will define missing pieces of=20 > Internet technology standards, as well as provide pointers to use of=20 > existing standards. > > Specifically, the GGIE working group will: > > + complete an overview document outlining the GGIE problem statement=20 > and general solution approach > + develop a set of use cases representative of GGIE problem scope > + develop a standardized URI for referring to specific media objects=20 > within a domain > + develop a standardized means for mapping IPv6 addresses to video=20 > data > + develop a media address resolution service protocol (MARS) to map=20 > URIs and addresses for video > + provide a mechanism for discovering media address resolution=20 > services > + document integration methods with lower level fundamental network=20 > services (eg. routing) > + develop media encoding network (MEN) definitions for video packaging=20 > such as MPEG-DASH > + illustrate how these technologies address the use cases already=20 > developed for GGIE > > Out of scope are: video technologies including codecs, digital rights=20 > management, and DRM enforcement technologies. > > > > --=20 > > ------------------------------------------------------------------- > Leslie Daigle > Principal, ThinkingCat Enterprises LLC > ldaigle@thinkingcat.com > ------------------------------------------------------------------- --=_MailMate_8C7BEC80-37B0-401D-8054-687C36B02084_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

Following up the discussion of GGIE at the last 2 DISPATC= H meetings, we are going to propose a BoF for IETF 98. Please see below = for 1/ information about the GGIE mailing list [*] where it=E2=80=99s bei= ng discussed, and 2/ the draft BoF proposal. As noted in the message, we= are happy to have suggestions on how to improve the proposal/move the wo= rk forward.

Thanks,
Leslie.
[*] Subscription and other info here: https://www.ietf.org/mailma= n/listinfo/ggie/

--

Leslie Daigle
Principal, ThinkingCat Enterprises LLC

ldaigle@thinkingcat.com

Forwarded message:

From: Leslie Daigle ldaigle@thinkingcat.com
To: ggie@ietf.org
Cc: Deen, Glenn glenn.deen@nbcuni.com
Subject: DRAFT bof proposal for IETF 98 in Chicago
Date: Wed, 08 Feb 2017 16:32:16 -0500

Hi,

Please find below a proposal for a GGIE BoF (WG-forming) = at IETF 98 in Chicago. We will be submitting the proposal by the deadlin= e this Friday, but would be happy to have suggestions to improve the prop= osal before then.

One of the things we=E2=80=99ve beed advised is that GGIE= -proponents-other-than-Glenn-and-Leslie are pretty invisible to the IESG.= If there doesn=E2=80=99t seem to be other interest, there won=E2=80=99t= be much justification for a BoF.

Now is the time, and here is the place, to voice your sup= port for furthering this discussion!

Thanks,
Leslie.

=E2=80=948<=E2=80=94=E2=80=948<=E2=80=94=E2=80=948&= lt;=E2=80=94=E2=80=94

Name: Glass to Glass Internet Ecosystem (GGIE)

Description:

Video is without rival the top use of Internet bandwidth,= and its ever growing demand for more bandwidth easily out paces the new = capacity being added both globally and regionally with no let up in sight= =2E Users are frustrated by quality, buffering, and stuttering problems= =2E Video providers and access networks are investing heavily to keep up = with demand. Significant work has be done at the application layer produ= cing more efficient codecs and innovative adaptive bitrate transports lik= e MPEG-DASH. These access investments and application layer work have he= lped but they alone have not been enough.

This BoF will introduce the Glass to Glass Internet Ecosy= stem (GGIE) which focuses on network level innovations to compliment the = efforts at the application layer and access networks. The proposed GGIE = work includes enabling adaptive bitrate transports like MPEG-DASH to use = IPv6 as their video segment addressing scheme which in turn permits use o= f advanced IPv6 network features such as Segment Routing. A GGIE goal is= to enabling video and network routing and management to work more cooper= atively and efficiently to transport video, and to do so in a backward co= mpatible ways to permit exiting devices and players to take advantage of = the improved network efficiencies.

Agenda
Agenda bash, scribe, minute taker [10min]

Context setting [15min]
    Highlights of the Internet Video Scaling Problem
    Specific aims of the GGIE work
    Relationship to other IETF activity
    Relationship to work in other fora

    Overview of existing GGIE work =E2=80=94 Network level proposals, dem=
o  [50min]
         - IPv6 Prefix addressing of MPEG-DASH packaged video
         - Content identifier to content address mapping using MARS
     - GGIE prototype demo

Where from here? [45min]
    Known open questions
    Potential for IETF work =E2=80=94 is there interest to pursue?
    If applicable: Discussion of draft charter for WG


    Demo of GGIE prototype
    Q&A & Discussion

Status: WG Forming
Responsible AD: Ben Campbell
BoF proponents: Glenn Deen / Leslie Daigle
BoF chairs: TBD
Number of people expected to attend: TBD
Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
Conflicts to avoid (whole Areas and/or WGs): DISPATCH WG and TBD
Links to the mailing list, draft charter if any, relevant Internet-Drafts=
, etc.
    Mailing List: =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/ggie
    Draft charter: see below
    Relevant drafts:
        draft-deen-daigle-ggie-02 :  Glass to Glass Internet Ecosystem In=
troduction
    draft-rose-deen-ggie-use-cases-00 : GGIE Internet Video Use Cases    =
    =

    draft-daigle-deen-ggie-uri-snaptr-00 :  Glass to Glass Internet Ecosy=
stem URI and S-NAPTR Use
    draft-deen-naik-ggie-men-mpeg-dash-00 : Using Media Encoding Networks=
 to address MPEG-DASH video (This is expired, but we can easily re-spin, =
or wait for WG input).

Glass to Glass Internet Ecosystem (GGIE) -- Draft Charter=

Due to its size and sensitivity to network conditions, th= e transport of video over the Internet has highlighted a significant scal= ability problem for the Internet. Addressing this scalability problem re= quires better integration between application transport and networking te= chnologies and leveraging IPv6. The GGIE working group will define a set= of fundamental building blocks bridging video application use of the net= work and core network services of addressing, routing, and naming. Throug= h standardization, of such fundamentals, a common base platform for new i= nteroperable innovation on video transport efficiency and scalability wil= l be enabled.

The scalability problem is driven by both professional an= d user generated content, fortunately both types of content use the same = transport technologies which permits the working group=E2=80=99s output t= o apply equally to them. Likewise, in addition to the use the network to = transport video for viewing, the network is extensively used in video cre= ation workflows of capture and editing, and distribution workflows of enc= oding, packaging, and distribution to edge caches for playback. The wor= king group will address both viewing and creation/distribution workflows.=

To that end, the GGIE working group will define missing p= ieces of Internet technology standards, as well as provide pointers to us= e of existing standards.

Specifically, the GGIE working group will:

  • complete an overview document outlining the GGIE problem statement an= d general solution approach
  • develop a set of use cases representative of GGIE problem scope
  • develop a standardized URI for referring to specific media objects wi= thin a domain
  • develop a standardized means for mapping IPv6 addresses to video data=
  • develop a media address resolution service protocol (MARS) to map URI= s and addresses for video
  • provide a mechanism for discovering media address resolution services=
  • document integration methods with lower level fundamental network ser= vices (eg. routing)
  • develop media encoding network (MEN) definitions for video packaging = such as MPEG-DASH
  • illustrate how these technologies address the use cases already devel= oped for GGIE

Out of scope are: video technologies including codecs, d= igital rights management, and DRM enforcement technologies.

--

Leslie Daigle
Principal, ThinkingCat Enterprises LLC

ldaigle@thinkingcat.com

--=_MailMate_8C7BEC80-37B0-401D-8054-687C36B02084_=-- From prvs=20617bda8=A.Seus@telekom.de Thu Feb 9 05:46:44 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B580712951B for ; Thu, 9 Feb 2017 05:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pL2JOp3U1vL for ; Thu, 9 Feb 2017 05:46:42 -0800 (PST) Received: from MAILOUT11.telekom.de (MAILOUT11.telekom.de [80.149.113.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F097212953E for ; Thu, 9 Feb 2017 05:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1486648000; x=1518184000; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=XIP5P3HPdXux0zhmPnQBbl4OJMV/zXm2rbv7LIy5cAY=; b=sQBIDoDpi4cX3IltkJkeo4iTkFlsIe/3BoRyj3PTaUg98LNon+KKfAtX jrApwy2nRYmYTMmpNiW1ZBMasmpUqlIQmLgktBXnRedTObF3xHAOEhPxP ZK6sO0RhEU1oSLpGVj+KGwFtkuGu6ngyvElXUDbQ/ArpExQlUsTyaENTJ afnV/HPYzPDSvaihysR4XBAVpBmcueyK8F3CsbMemBhuyZQvDEmt7nH72 T8n9tcpz8QThbm3b/ejE3vpazvqb6zqGa8u2Pf2kkD+8gZuISLxCZB0R9 2+b+IDNu0ef7OCV3Q7E2S/puXgsAF2jnF0cOHhpPHEveL3OEA613jw/dj Q==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 09 Feb 2017 14:46:36 +0100 X-IronPort-AV: E=Sophos;i="5.35,349,1484002800"; d="scan'208,217";a="615977557" Received: from he105878.emea1.cds.t-internal.com ([10.169.118.32]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 09 Feb 2017 14:46:35 +0100 Received: from HE104696.EMEA1.cds.t-internal.com (10.134.226.36) by HE105878.emea1.cds.t-internal.com (10.169.118.32) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 9 Feb 2017 14:46:34 +0100 Received: from HE104696.EMEA1.cds.t-internal.com ([fe80::654f:18ec:446b:e914]) by HE104696.emea1.cds.t-internal.com ([fe80::654f:18ec:446b:e914%26]) with mapi id 15.00.1263.000; Thu, 9 Feb 2017 14:46:34 +0100 From: To: , Thread-Topic: new draft: draft-winterbottom-dispatch-locparam-02.txt Thread-Index: AdJyZKwydZ5w95xgRXyhcWS+jzq62gQdQvEwAAAPopA= Date: Thu, 9 Feb 2017 13:46:34 +0000 Message-ID: <17c2ddaa8a534ec9aaa28d6cfaaf61a6@HE104696.emea1.cds.t-internal.com> References: <116b4e381feb4a26b82b7bb5f401bbea@HE105828.emea1.cds.t-internal.com> In-Reply-To: <116b4e381feb4a26b82b7bb5f401bbea@HE105828.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.168.15] Content-Type: multipart/alternative; boundary="_000_17c2ddaa8a534ec9aaa28d6cfaaf61a6HE104696emea1cdstintern_" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 14:50:31 -0000 --_000_17c2ddaa8a534ec9aaa28d6cfaaf61a6HE104696emea1cdstintern_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you Roland for this activity. From the ETSI M493 point of view, the d= ifferentiation of network-provided and user-provided location values would = be a great relief, especially for the public safety answering points (PSAPs= ), but also for the SIP proxies which have to construct the Geolocation hea= der with multiple location values from different sources. This would help t= o meet the requirements from regulation. Kind regards Albrecht _____________________________________________ Von: Jesske, Roland Gesendet: Donnerstag, 19. Januar 2017 16:00 An: 'dispatch@ietf.org' Betreff: new draft: draft-winterbottom-dispatch-locparam-02.txt Dear all, now I have taken the task to proceed with James draft on the "Location Sour= ce Parameter for the SIP Geolocation". This is needed to support ETSI the work as part of their M/493 stage-3 docu= ment. They would like to finalize their work mid of 2017. https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-02 There was one comment on the list: https://www.ietf.org/mail-archive/web/di= spatch/current/msg06193.html which I have addressed within the new draft. Thank you and Best Regards Roland Mit freundlichen Gr=FC=DFen Roland Jesske Deutsche Telekom Technik GmbH Fixed Mobile Engineering Deutschland Roland Jesske FMED93-5 Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 58-12766 (Tel.) +49 6151 58-13395 (Fax) +49 171 8618-445 (Mobil) http://www.telekom.com Erleben, was verbindet. < OLE-Objekt: Picture (Device Independent Bitmap) >> [cid:image001.png@01C= FD71F.3CB1D880] Pflichtangaben gem=E4=DF =A7 35 a GmbHG www.telekom.de/pflichtangaben-dttechnik Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. --_000_17c2ddaa8a534ec9aaa28d6cfaaf61a6HE104696emea1cdstintern_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you Roland for this activity. From the ETSI M493 point of view, = the differentiation of network-provided and user-provided location values w= ould be a great relief, especially for the public safety answering points (= PSAPs), but also for the SIP proxies which have to construct the Geolocation header with multiple location value= s from different sources. This would help to meet the requirements from reg= ulation.
 
 
Kind regards
 
Albrecht
 
 
_____= ________________________________________
Von: Jesske, Roland
Gesendet: Donnerstag, 19. Januar 2017 16:00
An: 'dispatch@ietf.org'
Betreff: new draft: draft-winterbottom-dispatch-locparam-02.txt
 
 
Dear all,
now I have taken the task to proceed with James= draft on the “Location Source Parameter for the SIP Geolocation̶= 1;. 
This is needed to support ETSI the work as part= of their M/493 stage-3 document. They would like to finalize their work mi= d of 2017.
 
https://tools.ietf= .org/html/draft-winterbottom-dispatch-locparam-02
 
There was one comment on the list: https://www.ietf.org/mail-archive/web/dispatch/current/ms= g06193.html  which I have addressed within the new draft.
 
Thank you and Best Regards
 
Roland
 
 
Mit = freundlichen Gr=FC=DFen
&nbs= p;
Rola= nd Jesske
Deutsche Telekom Technik GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
FMED93-5
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151 58-12766 (Tel.)
+49 6151 58-13395 (Fax)
+49 171 8618-445 (Mobil)
http://www.telek= om.com
 
Erleben, was verbin= det. 
 


Pflich= tangaben gem=E4=DF =A7 35 a GmbHG
<= b>www.telekom.de/pflichtangaben-dttechnik
Gro=DFe Ver=E4nderungen fangen klein an – Ressourcen schonen und nicht jede E-Mail dr= ucken.
 
 
 
 --_000_17c2ddaa8a534ec9aaa28d6cfaaf61a6HE104696emea1cdstintern_-- From nobody Thu Feb 9 07:53:26 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA1B129AF2 for ; Thu, 9 Feb 2017 07:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHTLAE_2MMG4 for ; Thu, 9 Feb 2017 07:53:23 -0800 (PST) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0297129AE5 for ; Thu, 9 Feb 2017 07:53:22 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4FE88209EE; Thu, 9 Feb 2017 16:53:21 +0100 (CET) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.56]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 22F0D1C006F; Thu, 9 Feb 2017 16:53:21 +0100 (CET) Received: from OPEXCNORM2D.corporate.adroot.infra.ftgroup ([fe80::7919:5bec:48cc:ccdf]) by OPEXCNORM64.corporate.adroot.infra.ftgroup ([fe80::106b:21e6:5c19:8c11%21]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 16:53:20 +0100 From: To: "A.Seus@telekom.de" , "R.Jesske@telekom.de" , "dispatch@ietf.org" Thread-Topic: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.txt Thread-Index: AdJyZKwydZ5w95xgRXyhcWS+jzq62gQdQvEwAAAPopAABKfbIA== Date: Thu, 9 Feb 2017 15:53:19 +0000 Message-ID: <23820_1486655601_589C9071_23820_103_1_88CAD1D4E8773F42858B58CAA28272A017E719C6@OPEXCNORM2D.corporate.adroot.infra.ftgroup> References: <116b4e381feb4a26b82b7bb5f401bbea@HE105828.emea1.cds.t-internal.com> <17c2ddaa8a534ec9aaa28d6cfaaf61a6@HE104696.emea1.cds.t-internal.com> In-Reply-To: <17c2ddaa8a534ec9aaa28d6cfaaf61a6@HE104696.emea1.cds.t-internal.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_88CAD1D4E8773F42858B58CAA28272A017E719C6OPEXCNORM2Dcorp_" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 15:53:25 -0000 --_000_88CAD1D4E8773F42858B58CAA28272A017E719C6OPEXCNORM2Dcorp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de A.Seus@telek= om.de Envoy=E9 : jeudi 9 f=E9vrier 2017 14:47 =C0 : R.Jesske@telekom.de; dispatch@ietf.org Objet : Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.t= xt Thank you Roland for this activity. From the ETSI M493 point of view, the d= ifferentiation of network-provided and user-provided location values would = be a great relief, especially for the public safety answering points (PSAPs= ), but also for the SIP proxies which have to construct the Geolocation hea= der with multiple location values from different sources. This would help t= o meet the requirements from regulation. Kind regards Albrecht _____________________________________________ Von: Jesske, Roland Gesendet: Donnerstag, 19. Januar 2017 16:00 An: 'dispatch@ietf.org' Betreff: new draft: draft-winterbottom-dispatch-locparam-02.txt Dear all, now I have taken the task to proceed with James draft on the "Location Sour= ce Parameter for the SIP Geolocation". This is needed to support ETSI the work as part of their M/493 stage-3 docu= ment. They would like to finalize their work mid of 2017. https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-02 There was one comment on the list: https://www.ietf.org/mail-archive/web/di= spatch/current/msg06193.html which I have addressed within the new draft. Thank you and Best Regards Roland Mit freundlichen Gr=FC=DFen Roland Jesske Deutsche Telekom Technik GmbH Fixed Mobile Engineering Deutschland Roland Jesske FMED93-5 Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 58-12766 (Tel.) +49 6151 58-13395 (Fax) +49 171 8618-445 (Mobil) http://www.telekom.com Erleben, was verbindet. [cid:image001.png@01CFD71F.3CB1D880] Pflichtangaben gem=E4=DF =A7 35 a GmbHG www.telekom.de/pflichtangaben-dttechnik Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_88CAD1D4E8773F42858B58CAA28272A017E719C6OPEXCNORM2Dcorp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1

 

De : disp= atch [mailto:dispatch-bounces@ietf.org] De la part de A.Seus@telekom.de
Envoy=E9 : jeudi 9 f=E9vrier 2017 14:47
=C0 : R.Jesske@telekom.de; dispatch@ietf.org
Objet : Re: [dispatch] new draft: draft-winterbottom-dispatch-l= ocparam-02.txt

 

Thank you Roland for this activity. = >From the ETSI M493 point of view, the differentiation of network-provided a= nd user-provided location values would be a great relief, especially for the public safety answering points (PSAPs), but also for th= e SIP proxies which have to construct the Geolocation header with multiple = location values from different sources. This would help to meet the require= ments from regulation.

 

 

Kind regards

 

Albrecht

 

 

________________________________________= _____
Von: Jesske, Roland
Gesendet: Donnerstag, 19. Januar 2017 16:00
An: 'dispatch@ietf.org'
Betreff: new draft: draft-winterbottom-dispatch-locparam-02.txt

 

 

Dear all,

now I have taken the task to proceed wi= th James draft on the “Location Source Parameter for the SIP Geolocat= ion”. 

This is needed to support ETSI the work= as part of their M/493 stage-3 document. They would like to finalize their= work mid of 2017.

 

 

Thank you and Best Regards

 

Roland

 

 

Mit freundlichen Gr=FC=DFen

 

Roland Jesske

Deutsche Telekom Technik G= mbH
Fixed Mobile Engineering Deutschland
Roland Jesske

 

= Erleben, was verbindet. 

 



Pflichtangaben gem=E4=DF =A7 35 a GmbHG
www.telekom.de/pflichtangaben-dttechnik=

Gro=DFe Ver=E4nderungen f= angen klein an – Ressourcen schonen und nicht jede E-Mail drucken.

 

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_88CAD1D4E8773F42858B58CAA28272A017E719C6OPEXCNORM2Dcorp_-- From nobody Fri Feb 10 02:11:21 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5286712941E for ; Fri, 10 Feb 2017 02:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGLQ-MxRM2lq for ; Fri, 10 Feb 2017 02:11:18 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600F6129487 for ; Fri, 10 Feb 2017 02:11:18 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id r141so43926086wmg.1 for ; Fri, 10 Feb 2017 02:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2dYf0QbAJnqRfc9E+0MiYjnVvkBTwQtBVSJhEFtls+o=; b=A69z2MOZJxQ9tZde65fLp8zV66JW0ILX8HHWQ5sD86yl51RLIpvX0sJi3X7Mi4+nXJ KRvA9gsO8C+iGE+HPXFKdZFdkeWpRLlP/LGN9slZkPwmDkZ3YUOXJMyPLaHf5i+vaG88 xPSseNVbY5WB/wukdI32zY4s1dNVsMIh9HWtswx7LqZJg/kpdkihd4rl41WeGsPBtiTl UsOm92dhpzNYMc69G2TmAQ3CxBZUl7+w6fRgn4LtAqIF3Bp2mwGNmfF3ktVReIEaPAWT XW6YI/VcrvCSN4/XdCveHxmn1XDI7m8NM7DpG50KuMsYUvhKbqVQU4Y754ZAKRH9fkpP QMmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2dYf0QbAJnqRfc9E+0MiYjnVvkBTwQtBVSJhEFtls+o=; b=oanE9nJcUEcichekniDy7vjVLK0jOj0n+E+QCzpUubb+pfi5CS4sZCHWC8zAZcX60/ LcFk9jKmulVlC5zhyC5rvmUKcSbfJFQlSiLJTyJCvscMpbKehDKbE1ogPpCkfDcY70OZ 2mX03c7WavwbzEnSTfql4QSW55N7EWPQfBM72gbbhhg6bqQMBceTiyCEiLsZJV+2A3Ik 4CDynezmQNMPLqhAxPGychXBpjEmlWIttxpEerb4OXgWUcYKvISvR07ygL5rjPmbCEng 6dKsjiA1yJHrjcvMbirU2udcEFF2lC+TNv4UDlQy0H++3sHzCJnsiVPWMoNJoQlMLoZe /QwQ== X-Gm-Message-State: AMke39nbdJlDSWSQrwUfVRYLPdQZRAvtcxml831J8k1eZHBH3psRhALnEU0J2ZpUrthYlMta1fpKWCaTdDUGAQ== X-Received: by 10.28.165.196 with SMTP id o187mr24780101wme.6.1486721476933; Fri, 10 Feb 2017 02:11:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.136.91 with HTTP; Fri, 10 Feb 2017 02:11:16 -0800 (PST) In-Reply-To: <17c2ddaa8a534ec9aaa28d6cfaaf61a6@HE104696.emea1.cds.t-internal.com> References: <116b4e381feb4a26b82b7bb5f401bbea@HE105828.emea1.cds.t-internal.com> <17c2ddaa8a534ec9aaa28d6cfaaf61a6@HE104696.emea1.cds.t-internal.com> From: Andy Hutton Date: Fri, 10 Feb 2017 10:11:16 +0000 Message-ID: To: A.Seus@telekom.de Content-Type: multipart/alternative; boundary=001a114b443c83432605482a5115 Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 10:11:20 -0000 --001a114b443c83432605482a5115 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This issue has arisen in a number of conversations I am currently having regarding location provision from private networks. I would also like to see this draft progress. Regards Andy On Thu, Feb 9, 2017 at 1:46 PM, wrote: > Thank you Roland for this activity. From the ETSI M493 point of view, the > differentiation of network-provided and user-provided location values wou= ld > be a great relief, especially for the public safety answering points > (PSAPs), but also for the SIP proxies which have to construct the > Geolocation header with multiple location values from different sources. > This would help to meet the requirements from regulation. > > > Kind regards > > Albrecht > > > _____________________________________________ > *Von:* Jesske, Roland > *Gesendet:* Donnerstag, 19. Januar 2017 16:00 > *An:* 'dispatch@ietf.org' > *Betreff:* new draft: draft-winterbottom-dispatch-locparam-02.txt > > > Dear all, > now I have taken the task to proceed with James draft on the =E2=80=9CLoc= ation > Source Parameter for the SIP Geolocation=E2=80=9D. > This is needed to support ETSI the work as part of their M/493 stage-3 > document. They would like to finalize their work mid of 2017. > > *https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-02* > > > There was one comment on the list: > *https://www.ietf.org/mail-archive/web/dispatch/current/msg06193.html* > > which I have addressed within the new draft. > > Thank you and Best Regards > > Roland > > > Mit freundlichen Gr=C3=BC=C3=9Fen > > Roland Jesske > Deutsche Telekom Technik GmbH > Fixed Mobile Engineering Deutschland > Roland Jesske > FMED93-5 > Heinrich-Hertz-Stra=C3=9Fe 3-7, 64295 Darmstadt > +49 6151 58-12766 <+49%206151%205812766> (Tel.) > +49 6151 58-13395 <+49%206151%205813395> (Fax) > +49 171 8618-445 <+49%20171%208618445> (Mobil) > *http://www.telekom.com* > > *Erleben, was verbindet.* > > > > > *Pflichtangaben gem=C3=A4=C3=9F =C2=A7 35 a GmbHG * > *www.telekom.de/pflichtangaben-dttechnik* > > *Gro=C3=9Fe Ver=C3=A4nderungen fangen klein an **=E2=80=93** Ressourcen s= chonen und nicht > jede E-Mail drucken.* > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --001a114b443c83432605482a5115 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This issue has arisen in a number of conversations I am cu= rrently having regarding location provision from private networks.

=
I would also like to see this draft progress.

Regards
Andy

On Thu, Feb 9, 2017 at 1:46 PM, = <A.Seus@telekom.d= e> wrote:
Thank you Roland for this activity. From the ETSI M493 point of view, = the differentiation of network-provided and user-provided location values w= ould be a great relief, especially for the public safety answering points (= PSAPs), but also for the SIP proxies which have to construct the Geolocation header with multiple location value= s from different sources. This would help to meet the requirements from reg= ulation.
=C2=A0
=C2=A0
Kind regards
=C2=A0
Albrecht
=C2=A0
=C2=A0
______= _______________________________________
Von: Jesske, Roland
Gesendet: Donnerstag, 19. Januar 2017 16:00
An: 'disp= atch@ietf.org'
Betreff: new draft: draft-winterbottom-dispatch-locparam-02.txt=
=C2=A0
=C2=A0
Dear all,
now I have taken the task to proceed with James= draft on the =E2=80=9CLocation Source Parameter for the SIP Geolocation=E2= =80=9D.=C2=A0
This is needed to support ETSI the work as part= of their M/493 stage-3 document. They would like to finalize their work mi= d of 2017.
=C2=A0
=C2=A0
There was one comment on the list: https://www.ietf.org/mail-archive/= web/dispatch/current/msg06193.html=C2=A0 which I have addressed within the new draft.
=C2=A0
Thank you and Best Regards
=C2=A0
Roland
=C2=A0
=C2=A0
Mit f= reundlichen Gr=C3=BC=C3=9Fen
=C2= =A0
Rolan= d Jesske
Deutsche Telekom=C2=A0Technik GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
FMED93-5
Heinrich-Hertz-Stra=C3=9Fe 3-7, 64295 Darmstadt
+49 6151 58-12766 (Tel.)
+49 6151 58-13395 (Fax)
+49 171 8618-445 (Mobil)
<= u>http://www.telekom.com
=C2=A0
Erleben, was verbinde= t.=C2=A0
=C2=A0


Pflicht= angaben gem=C3=A4=C3=9F =C2=A7 35 a GmbHG
www.telekom.de/pflichtangaben-dttechnik
Gro=C3=9Fe Ver=C3=A4nderungen fangen klein an =E2=80=93 Ressourcen schonen und nicht jede E-= Mail drucken.
=C2=A0
=C2=A0
=C2=A0

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--001a114b443c83432605482a5115-- From nobody Fri Feb 10 08:11:46 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297E4129A28 for ; Fri, 10 Feb 2017 08:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdrRZJG2TdY2 for ; Fri, 10 Feb 2017 08:11:41 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD2C129A26 for ; Fri, 10 Feb 2017 08:11:40 -0800 (PST) Received: from [85.158.138.179] by server-1.bemta-3.messagelabs.com id C9/5B-20518-A36ED985; Fri, 10 Feb 2017 16:11:38 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRWlGSWpSXmKPExsWi75nTpWv1bG6 Ewc0DbBYr+pUtvl98yGyxdNICVoumO11sDiweS5b8ZPJoeXaSzaPtpUIAcxRrZl5SfkUCa8au K4vYCn5sZKyYfecpawPj38WMXYxcHEIC2xkl1v2ZwtTFyAnkHGaUaPsRDZHYxCjR3jKRuYuRg 4NNwF5ixp4YkLiIwC5GiR+7rrKCNAgL+EtM+zCREcQWEQiQmHXyAitIvYiAm8TFObogYRYBVY mDZ36wg9i8AqESd44eZIaYP5lJYsfiXUwgDqdAB6PE9tdP2ECqGAVkJb40rmYGsZkFxCVuPZk Pdp2EgIDEkj3nmSFsUYmXj/+xQtTkSTx4cIcVYoOgxMmZT1ggvlGV+LdyEdMERuFZSEbNQtIy C0kLRFxP4sbUKWwQtrbEsoWvmSFsXYkZ/w6xIIsvYGRfxahenFpUllqka6aXVJSZnlGSm5iZo 2toYKyXm1pcnJiempOYVKyXnJ+7iREYe/UMDIw7GK+0OR9ilORgUhLlFTg9N0KILyk/pTIjsT gjvqg0J7X4EKMMB4eSBO/Cp0A5waLU9NSKtMwcYBKASUtw8CiJ8F4ESfMWFyTmFmemQ6ROMSp KifMagiQEQBIZpXlwbbDEc4lRVkqYl5GBgUGIpyC1KDezBFX+FaM4B6OSMO82kCk8mXklcNNf AS1mAlrs+gBscUkiQkqqgXHH2Tq7tVHL73Rffjbb4IXcBztX88U7KzacztV7FjVxXXV9is3/O AHJde/8T5doZW7b+cvTfe+OhatrM6Se/Heo4T5TFcm39JbB6buCc2fG6Wxm979qv+bmsToTly OfxZqeiJ9IaLGTabELOuv/bmLXnuK3F3qeS2tKnbuudfv0s+8i8UL679yUWIozEg21mIuKEwH FpCBLNwMAAA== X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-5.tower-169.messagelabs.com!1486743097!96926384!1 X-Originating-IP: [47.73.108.138] X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28350 invoked from network); 10 Feb 2017 16:11:37 -0000 Received: from vgdpm12vr.vodafone.com (HELO voxe04hw.internal.vodafone.com) (47.73.108.138) by server-5.tower-169.messagelabs.com with AES256-SHA256 encrypted SMTP; 10 Feb 2017 16:11:37 -0000 Received: from VOEXH10W.internal.vodafone.com (47.73.211.214) by edge1.vodafone.com (195.232.244.49) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 10 Feb 2017 17:11:36 +0100 Received: from VOEXC04W.internal.vodafone.com (145.230.101.24) by VOEXH10W.internal.vodafone.com (47.73.211.214) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 10 Feb 2017 17:11:35 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by VOEXC04W.internal.vodafone.com ([145.230.101.24]) with mapi id 14.03.0294.000; Fri, 10 Feb 2017 17:11:34 +0100 From: "Dawes, Peter, Vodafone Group" To: "bruno.chatras@orange.com" , "A.Seus@telekom.de" , "R.Jesske@telekom.de" , "dispatch@ietf.org" Thread-Topic: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.txt Thread-Index: AdJyZKwydZ5w95xgRXyhcWS+jzq62gQdQvEwAAAPopAABKfbIAAynmDA Date: Fri, 10 Feb 2017 16:11:34 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7D8B7@VOEXM31W.internal.vodafone.com> References: <116b4e381feb4a26b82b7bb5f401bbea@HE105828.emea1.cds.t-internal.com> <17c2ddaa8a534ec9aaa28d6cfaaf61a6@HE104696.emea1.cds.t-internal.com> <23820_1486655601_589C9071_23820_103_1_88CAD1D4E8773F42858B58CAA28272A017E719C6@OPEXCNORM2D.corporate.adroot.infra.ftgroup> In-Reply-To: <23820_1486655601_589C9071_23820_103_1_88CAD1D4E8773F42858B58CAA28272A017E719C6@OPEXCNORM2D.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7D8B7VOEXM31Winterna_" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:11:44 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7D8B7VOEXM31Winterna_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 One comment, the draft contains the text "Thus it is intended to use this p= arameter in trust domains where Spec(T) as described in [RFC3325] exists on= ly." but does not define a Spec(T) instance. I think the draft needs to say= something about what would be a suitable Spec(T). Regards, Peter From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of bruno.chatra= s@orange.com Sent: 09 February 2017 15:53 To: A.Seus@telekom.de; R.Jesske@telekom.de; dispatch@ietf.org Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.= txt +1 De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de A.Seus@telek= om.de Envoy=E9 : jeudi 9 f=E9vrier 2017 14:47 =C0 : R.Jesske@telekom.de; dispatch@ietf.org Objet : Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.t= xt Thank you Roland for this activity. >From the ETSI M493 point of view, the = differentiation of network-provided and user-provided location values would= be a great relief, especially for the public safety answering points (PSAP= s), but also for the SIP proxies which have to construct the Geolocation he= ader with multiple location values from different sources. This would help = to meet the requirements from regulation. Kind regards Albrecht _____________________________________________ Von: Jesske, Roland Gesendet: Donnerstag, 19. Januar 2017 16:00 An: 'dispatch@ietf.org' Betreff: new draft: draft-winterbottom-dispatch-locparam-02.txt Dear all, now I have taken the task to proceed with James draft on the "Location Sour= ce Parameter for the SIP Geolocation". This is needed to support ETSI the work as part of their M/493 stage-3 docu= ment. They would like to finalize their work mid of 2017. https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-02 There was one comment on the list: https://www.ietf.org/mail-archive/web/di= spatch/current/msg06193.html which I have addressed within the new draft. Thank you and Best Regards Roland Mit freundlichen Gr=FC=DFen Roland Jesske Deutsche Telekom Technik GmbH Fixed Mobile Engineering Deutschland Roland Jesske FMED93-5 Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 58-12766 (Tel.) +49 6151 58-13395 (Fax) +49 171 8618-445 (Mobil) http://www.telekom.com Erleben, was verbindet. [cid:image001.png@01CFD71F.3CB1D880] Pflichtangaben gem=E4=DF =A7 35 a GmbHG www.telekom.de/pflichtangaben-dttechnik Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7D8B7VOEXM31Winterna_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

One comment, the draft co= ntains the text “Thus it is intended to use this parameter in trust d= omains where Spec(T) as described in [RFC3325] exists only.” but does not define a Spec(T) instance. I think the draft needs to say somethi= ng about what would be a suitable Spec(T).

 <= /p>

Regards,

Peter

 <= /p>

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of bruno.chatras@orange.com
Sent: 09 February 2017 15:53
To: A.Seus@telekom.de; R.Jesske@telekom.de; dispatch@ietf.org
Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locpa= ram-02.txt

 

+1

 

De : dispatch [= mailto:dispatch-bounces@ietf.org] De la part de A.Seus@telekom.de=
Envoy=E9 : jeudi 9 f=E9vrier 2017 14:47
=C0 : R.Jesske@telekom.d= e; dispatch@ietf.org
Objet : Re: [dispatch] new draft: draft-winterbottom-dispatch-l= ocparam-02.txt

 

Thank you Roland for this activity. >From the ETSI = M493 point of view, the differentiation of network-provided and user-provid= ed location values would be a great relief, especially for the public safety answering points (PSAPs), but also for th= e SIP proxies which have to construct the Geolocation header with multiple = location values from different sources. This would help to meet the require= ments from regulation.

 

 

Kind regards

 

Albrecht

 

 =

____________________________= _________________
Von: Jesske, Roland
Gesendet: Donnerstag, 19. Januar 2017 16:00
An: 'dispatch@ietf.org'
Betreff: new draft: draft-winterbottom-dispatch-locparam-02.txt

 

 

Dear all,

now I have taken the task t= o proceed with James draft on the “Location Source Parameter for the = SIP Geolocation”. 

This is needed to support E= TSI the work as part of their M/493 stage-3 document. They would like to fi= nalize their work mid of 2017.

 

 

 

Thank you and Best Regards<= /span>

 

Roland

 

 

Mit freundlichen Gr=FC=DFen=

 

Roland Jesske

Deutsche Telekom&nb= sp;Technik GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske

 

Erleben, was verbindet. 

 



Pflichtangaben gem=E4=DF =A7 35= a GmbHG
www.telekom.de/pflichtangaben-dtte= chnik

Gro=DFe Ver= =E4nderungen fangen klein an – Ressourcen schonen und nicht jede E-Mail = drucken.

 

 

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7D8B7VOEXM31Winterna_-- From nobody Fri Feb 10 12:50:55 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D096F129BDF for ; Fri, 10 Feb 2017 12:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uQlBf0MeH2g for ; Fri, 10 Feb 2017 12:50:51 -0800 (PST) Received: from smtp144.dfw.emailsrvr.com (smtp144.dfw.emailsrvr.com [67.192.241.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C27129BDB for ; Fri, 10 Feb 2017 12:50:50 -0800 (PST) Received: from smtp23.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 3C988E0358; Fri, 10 Feb 2017 15:50:50 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp23.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B373CE033A; Fri, 10 Feb 2017 15:50:49 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.119] ([UNAVAILABLE]. [128.107.241.188]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 10 Feb 2017 15:50:50 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <20170206020826.1108.qmail@ary.lan> Date: Fri, 10 Feb 2017 13:50:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> References: <20170206020826.1108.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3259) Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] Updating DKIM for stronger crypto X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:50:52 -0000 The Chairs and ADs discussed this today and we plan to allocate some = agenda time for it at IETF 98. At the meeting we can try and figure out = best way to dispatch this.=20 It seems like a mini WG or possibly AD sponsor by ART or SEC AD are = within the range of possibilities we should consider for how to move the = work forward.=20 From nobody Sat Feb 11 08:37:27 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3201299B7 for ; Sat, 11 Feb 2017 08:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.487 X-Spam-Level: X-Spam-Status: No, score=-4.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuLk2v3IjbMU for ; Sat, 11 Feb 2017 08:37:23 -0800 (PST) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED371299A5 for ; Sat, 11 Feb 2017 08:37:22 -0800 (PST) Received: from EVHUB03-UKBR.domain1.systemhost.net (193.113.108.185) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 11 Feb 2017 16:37:19 +0000 Received: from tpw09926dag17e.domain1.systemhost.net (10.9.212.17) by EVHUB03-UKBR.domain1.systemhost.net (193.113.108.185) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 11 Feb 2017 16:37:19 +0000 Received: from tpw09926dag17f.domain1.systemhost.net (10.9.212.25) by tpw09926dag17e.domain1.systemhost.net (10.9.212.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 11 Feb 2017 16:37:18 +0000 Received: from tpw09926dag17f.domain1.systemhost.net ([fe80::711b:5967:c81c:bfb0]) by tpw09926dag17f.domain1.systemhost.net ([fe80::711b:5967:c81c:bfb0%12]) with mapi id 15.00.1210.000; Sat, 11 Feb 2017 16:37:18 +0000 From: To: , , , Thread-Topic: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.txt Thread-Index: AdJyZKwydZ5w95xgRXyhcWS+jzq62gQdQvEwAAAPopAABKfbIABl9JMw Date: Sat, 11 Feb 2017 16:37:18 +0000 Message-ID: References: <116b4e381feb4a26b82b7bb5f401bbea@HE105828.emea1.cds.t-internal.com> <17c2ddaa8a534ec9aaa28d6cfaaf61a6@HE104696.emea1.cds.t-internal.com> <23820_1486655601_589C9071_23820_103_1_88CAD1D4E8773F42858B58CAA28272A017E719C6@OPEXCNORM2D.corporate.adroot.infra.ftgroup> In-Reply-To: <23820_1486655601_589C9071_23820_103_1_88CAD1D4E8773F42858B58CAA28272A017E719C6@OPEXCNORM2D.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.9.202.242] Content-Type: multipart/alternative; boundary="_000_bf1636ec491046b8973e3bc91d1bf2dbtpw09926dag17fdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 16:37:25 -0000 --_000_bf1636ec491046b8973e3bc91d1bf2dbtpw09926dag17fdomain1sy_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am supportive of this draft - it will help UK PSAPs to clearly know the o= rigin of any location information received. Thanks From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of bruno.chatra= s@orange.com Sent: 09 February 2017 15:53 To: A.Seus@telekom.de; R.Jesske@telekom.de; dispatch@ietf.org Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.= txt +1 De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de A.Seus@telek= om.de Envoy=E9 : jeudi 9 f=E9vrier 2017 14:47 =C0 : R.Jesske@telekom.de; dispatch@ietf.org Objet : Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.t= xt Thank you Roland for this activity. >From the ETSI M493 point of view, the = differentiation of network-provided and user-provided location values would= be a great relief, especially for the public safety answering points (PSAP= s), but also for the SIP proxies which have to construct the Geolocation he= ader with multiple location values from different sources. This would help = to meet the requirements from regulation. Kind regards Albrecht _____________________________________________ Von: Jesske, Roland Gesendet: Donnerstag, 19. Januar 2017 16:00 An: 'dispatch@ietf.org' Betreff: new draft: draft-winterbottom-dispatch-locparam-02.txt Dear all, now I have taken the task to proceed with James draft on the "Location Sour= ce Parameter for the SIP Geolocation". This is needed to support ETSI the work as part of their M/493 stage-3 docu= ment. They would like to finalize their work mid of 2017. https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-02 There was one comment on the list: https://www.ietf.org/mail-archive/web/di= spatch/current/msg06193.html which I have addressed within the new draft. Thank you and Best Regards Roland Mit freundlichen Gr=FC=DFen Roland Jesske Deutsche Telekom Technik GmbH Fixed Mobile Engineering Deutschland Roland Jesske FMED93-5 Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 58-12766 (Tel.) +49 6151 58-13395 (Fax) +49 171 8618-445 (Mobil) http://www.telekom.com Erleben, was verbindet. [cid:image001.png@01CFD71F.3CB1D880] Pflichtangaben gem=E4=DF =A7 35 a GmbHG www.telekom.de/pflichtangaben-dttechnik Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_bf1636ec491046b8973e3bc91d1bf2dbtpw09926dag17fdomain1sy_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am supportive of this draft= - it will help UK PSAPs to clearly know the origin of any location informa= tion received.   Thanks

 

 

 

From: = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of bruno.chatras@orange.com
Sent: 09 February 2017 15:53
To: A.Seus@telekom.de; R.Jesske@telekom.de; dispatch@ietf.org
Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locpa= ram-02.txt

 

+1

 

De : disp= atch [mailto:dispatch-bounces@= ietf.org] De la part de A.Seus@telekom.de=
Envoy=E9 : jeudi 9 f=E9vrier 2017 14:47
=C0 : R.Jesske@telekom.d= e; dispatch@ietf.org
Objet : Re: [dispatch] new draft: draft-winterbottom-dispatch-l= ocparam-02.txt

 

Thank you Roland for this activity. >From the ETSI = M493 point of view, the differentiation of network-provided and user-provid= ed location values would be a great relief, especially for the public safety answering points (PSAPs), but also for th= e SIP proxies which have to construct the Geolocation header with multiple = location values from different sources. This would help to meet the require= ments from regulation.

 

 

Kind regards

 

Albrecht

 

 

________________________________________= _____
Von: Jesske, Roland
Gesendet: Donnerstag, 19. Januar 2017 16:00
An: 'dispatch@ietf.org'
Betreff: new draft: draft-winterbottom-dispatch-locparam-02.txt

 

 

Dear all,=

now I have taken the task to proceed wi= th James draft on the “Location Source Parameter for the SIP Geolocat= ion”. 

This is needed to support ETSI the work= as part of their M/493 stage-3 document. They would like to finalize their= work mid of 2017.

 

 

 

Thank you and Best Regards

 

Roland

 

 

Mit freundlichen Gr=FC=DFen

 

Roland Jesske<= o:p>

Deutsche Telekom Technik G= mbH
Fixed Mobile Engineering Deutschland
Roland Jesske

 

= Erleben, was verbindet. 

 



Pflichtangaben gem=E4=DF =A7 35 a GmbHG
www.telekom.de/pflichtangaben-dttechnik

Gro=DFe Ver=E4nderungen f= angen klein an – Ressourcen schonen und nicht jede E-Mail drucken.

 

 

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_bf1636ec491046b8973e3bc91d1bf2dbtpw09926dag17fdomain1sy_-- From nobody Sun Feb 12 18:03:22 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267C6129448 for ; Sun, 12 Feb 2017 18:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac9PJlUe-ukY for ; Sun, 12 Feb 2017 18:03:18 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CB712946C for ; Sun, 12 Feb 2017 18:03:18 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6EFD322E1F3 for ; Sun, 12 Feb 2017 21:03:11 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Mon, 13 Feb 2017 13:03:08 +1100 To: DISPATCH X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [dispatch] rfc5988bis X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 02:03:21 -0000 Hi DISPATCH, Could I please have ~15 minutes in Chicago to present proposed changes = to RFC5988, with an eye towards finding an appropriate home for the = work? I've briefly mentioned this before, would appreciate a bit more time to = go into detail and have the discussion. Draft: https://tools.ietf.org/html/draft-nottingham-rfc5988bis-04 Thanks, -- Mark Nottingham https://www.mnot.net/ From nobody Sun Feb 12 18:42:48 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FE71294D4 for ; Sun, 12 Feb 2017 18:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2biRxh9FcCn for ; Sun, 12 Feb 2017 18:42:44 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0108.outbound.protection.outlook.com [104.47.92.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1828F129456 for ; Sun, 12 Feb 2017 18:42:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KIkt0zum2W1yMvP9uggmWvMd1IyZN+4icE2hayCmdZw=; b=FCtZt7khM74TDfgc8w6kxxg++MZDHgPi7Ul/TBLi4nnUqJbpJ+R4yJKv61w24tZlRYHRH0oiVeQstk3Fh/IPoSSezagxg2tk57ILV03NKKMy2IhGqLXLIH8Ji22DqBk57qGnFInAPlnABqmDQ6Yv9RbPsQIPIFEPExnU0JNdOf4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0642.jpnprd01.prod.outlook.com (10.167.176.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 13 Feb 2017 02:42:40 +0000 To: Mark Nottingham , DISPATCH References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <42720193-513f-d7a8-aebc-1ce9e4f426ed@it.aoyama.ac.jp> Date: Mon, 13 Feb 2017 11:42:37 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: KAWPR01CA0047.jpnprd01.prod.outlook.com (10.165.48.157) To OS2PR01MB0642.jpnprd01.prod.outlook.com (10.167.176.140) X-MS-Office365-Filtering-Correlation-Id: 8830c23b-1fb4-4a0c-89e8-08d453b9fa9d X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:OS2PR01MB0642; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0642; 3:dYu6e2xE4XGtZZl0aFPe2EL3fwbwVLNekJ/rtdR60RkA2USnEr+psp24RdKnM5sMZlJaZ/uY+pYyLoFGJS70lu9DG6XABGdGgk/AeIOrDHI1e8/ijj4tBK3qpjT6+n7n1CBnOJxAihqy2x1twGMtvKkr15ug/by64H9p4+RJRjsN8zBXvHiNPE8fWy45GFnlfkeiwlJkJebzCc5Yrgbcl2Vd3V210XKsCoM9nOJ2JLVIgVd/UNMziEXd9Xn+4ODwP4EJT+KapJiCSvimz3FTCg==; 25:i5jtdZHs+xqmuo6T/1IqR9KX4oSlTQ8YUv9pnIG9ftK4hOc6MD6q+bU8zibyKfT/3s0ZbFuqvSR7Fc1vKCC5z2GngG2I/qYcsmHsgzZ6xfS3fFYh3poycLIj3og1P5c48tIb+gXdbqXNJTUGbngbdKqcAKhlplunrq0eyGZCDq9QO13HRSwD9fT6c0cR1l/0FyMB3aEiJVDLh47ZhCec0yfhpDZkb5qDaUys97qK4cK8WbcuBOQmec08vFBbDDtfy6MWDQicCyxZbHFKrAjsDEmdk30BMmd7e5BbodrMK/bzldEYEq3BxH0hfTI7Ktkz3j+XclnP2+VuIdyykpyJjeYJVej5DO4APvbVDk2jM2NnNoVJYVBehjOu/k/cI5eS9cMJKa8gNj2uI7KHUD/ymeolvBw5yV/Vy4BKeNRp2Ib3HQ5LYr5HCfh1PYpz34/ZMtZDMDKJh5lfhgJuCAukqA== X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0642; 31:x8pFzhu2K5n5hyynl1/A2hC9yjJaJA6Z13IN/xEgW7n5HeLCogOzWA8QjCgRWRsUknjcj4Klyj792ebOFeSx/dYObhp7Qslx+bEPQqrBIHDv+teFpU5aNW2sO/ID4bdDILU4Izc1Ppt6fWRYHCzkgpsOH2JH1oiqeb2UtcGBmoV5bAl/mScaGu87TKeBvIeGKCvHOBx+hMJ4sOmDqTdmmQ1ZEHHDvD0AW1+0Se9WQLRdg70DuOsoXxbaxz4Kx+1WlqedG7Y/nKdSdJ0O3SvpaSc41pgSxnxxVJaZAm2idRA=; 4:9b5J57f/8Z6CSCgVZynthYbOHL551fF4VUjeybQdJTxSd3e3IgxCXi6/CJcogejnuoVoIzOFHEwtuP0j8nlj1T0f2xBmZqtWtUyb43ZGqKZ9Lkbm0FRMvCIE6/A7MUKxwaTf6ItMWnyPFk13sUvF85k2BsUiaKpX/3CQ7ijH/oOpUphF0Oy2CD6x07sen0rXZYQ/4a6l0caolhAGEQ0uz20qqz/hZCyqS7Ndj5Pq5YdBMg2fZyK0GMbqe5iwVZAox7eSUTShN2jXVb4iPzTOLBLcJQHEG5Iund4ZFeUvOAnYz5qu3foJwIDrcZbeTt1j3OFLiqx5/E2ubIuur2szcja7JX9Ek7u3b83I/TCw/o3a0YfbNdD2UXHh1m3qFHdvMtoF3gDHMZLp1x5kFF72O1d09Jwrs/38SQErI2JtmlVIVeZssAsg7/cgCGu34L4uq9zIFQJ5iyuumfwIMpQW6zHDeijfnbfQTixoBY7E0B6zKuSAIgjQYjlzdL7HKEM2V4GUJkBayStBB7D4C32CC3Hndo/kjnMXhQkxWFEQfr/SCCvQOFhgkMThs8JTXSdUUMJHnosHMePr2yRzj190yA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(6072148); SRVR:OS2PR01MB0642; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0642; X-Forefront-PRVS: 02176E2458 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(189002)(199003)(24454002)(42186005)(50466002)(189998001)(68736007)(25786008)(53936002)(92566002)(2906002)(5660300001)(38730400002)(6246003)(50986999)(53546003)(229853002)(76176999)(54356999)(3846002)(64126003)(90366009)(65826007)(65806001)(47776003)(23676002)(65956001)(6116002)(66066001)(4001350100001)(105586002)(101416001)(7736002)(305945005)(6486002)(97736004)(33646002)(2950100002)(42882006)(106356001)(31686004)(83506001)(6666003)(6306002)(81166006)(81156014)(31696002)(8676002)(74482002)(230700001)(86362001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0642; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwNjQyOzIzOjNnL0gzRTNodFRHS3o4bk5NTmhoa0UzMFNX?= =?utf-8?B?cmI2UEhuQmRMOG5EamhhL0tVeDM0VktFTnVxWGZzYmUyVjNPK2YwbnRQTVU2?= =?utf-8?B?TEY0Z1JNdWFQWi9IellMVE56UzF0VlQzWENYSllMS0hMeVN6elBPQ2U5WHNF?= =?utf-8?B?N1VWL2d6SDhMWCszdzRrTVFFWDdDbmJtSzQwQUJsUnNVUUFySmRYM1pXVHdQ?= =?utf-8?B?RFg1aE9LM3l4K284UW01UFFNMEpqVWVpdTFReWdnYzJnd21YVmNRbjB2Mmgw?= =?utf-8?B?Ky9GazlIWHJGZlI0anB4N3VTQlJKSlNxVHNVa3pOU2t1U01HL0VETzdEbFlo?= =?utf-8?B?VXNJSmxkM2hJclZEb2tKa1JwblRiYkpFRm1YdWd5bXU1NWE3cHR6Sm9SRlNx?= =?utf-8?B?aTF2cG5JQnQ0eW9BdXdrZXJFUFZYR3pEeDUxOHhWb3RubG5obmovamtsRzk2?= =?utf-8?B?SlBZcithM245L0ZTY0NqbzRKL3VQY1QrelZFcEZOb1ZPc3M3eVZBbktVeE5a?= =?utf-8?B?cDFDbnM0YjhZaWc0dWpSemtXd1VzVUYrTGhEcU1FVDFkYU1EMEpua1ZNN2dF?= =?utf-8?B?TkxreDIwWktDSE9GOWZhRW1HQkliVmhxQ1dNSjVSTGhpUWdjV1d0VE1KWVEy?= =?utf-8?B?eGRGWHVQL004Rjc1TG15QVg5bUlha3pIQkNUQkZVZ1gxVUpoRUpkM2RPVXI5?= =?utf-8?B?ZEhUMmNEV2dUZGhUY2pWaUkvcCtBL3pkdXY2UCtwenFleS94TnVObllyMXhQ?= =?utf-8?B?M0x6RlFvZU1MQUo4VXRIaG5nTFIvVEd1d3BTc3JreUtzUkIyZm01ZUdhdklt?= =?utf-8?B?Wk8wUlp6enJRY3VOdEg3UFJRSGlEVmxISlNoSW5qb2lhTzBRTkdTZnB3ZDRG?= =?utf-8?B?TUI4cTN1RDhwaU9qOEtFV1NvMmJjK0pYTCtkNVBnQ2RIclZYQVdlK3UxUTZX?= =?utf-8?B?bVhMQ0RrZkdEQ0I0N29ncEloOWV2SVJVVzBCL2I3ZWh4OHZYVmpSUFR6Yklx?= =?utf-8?B?UElnLzY0eHdjUG5QQ0pKSVZsY2kwVDVNR2FnSjc5VDZ0eHFaNU1ZNkVHM3Ba?= =?utf-8?B?Qm9XRzBZVjNaVFpXUVNaM24zdjBDaEtKN1I2L3c0RUhrMER1bExIL1VOSUdE?= =?utf-8?B?bXFFR2VjUUtQRHJ0d1A4VUx1L0x0OG5qVkNCTXNKUXFERCtYUkM4OTFtS1Vu?= =?utf-8?B?ZDlweGlWT3BhNm9BMEtjQ1dHVGk2SWZ4ZnFVZEVmWkpFNFppYXhxR2RCVFFW?= =?utf-8?B?dU93d2xBLzY2c2lQT3RkODVGUTJ3WEFiWDd3Z1RzeVNVVGtwWHlzZW96RFAv?= =?utf-8?B?WFVJVS8yR1Nna3orWGF6OVFNRjh1L0g1RTBCTzFBa01uUGZwdVpwNHAycEdm?= =?utf-8?B?ekNRYU41blRQR21FY3E1VS9vSFB6eEZjRU0yR0pRN3EvQVlZNjllVnRML1hr?= =?utf-8?B?RGZjTkJkekNiMmNUdm8yRVhiZzd4SzQxODlWTWE1a2Q2QmhkalZxWUlzbG5U?= =?utf-8?B?bXZIcmV2NGNiQ1Q3UHoreEJwaTUrTnhkOWtDZ3pBR2hZY2V0UUZtM1FDazNn?= =?utf-8?B?TGx2SWxmZUFUamN0R2xVRDNrSHAzVnZkNXlBN3lHWlN4VzVZdDlSQTZTNVNk?= =?utf-8?B?Yk9pU0E1U1Q4dW56b2NpVE90YnByd3FSRmRES2E3QUJtTDBiOEZnYXJyNVBz?= =?utf-8?B?bm1HVGg2QzNOZ3VJWTdrRTJVaVl1Ym83dlYwNnpjUWgvZ0l4d0hrVmJhTWNJ?= =?utf-8?B?QkZMY0lXZzRYS2RrVmc0S0szUGJXV2F1N3Z2Nlg0akR3QzdjbDcxSllaejB4?= =?utf-8?B?TkV3cTM4b3RMTGpTWEttTUphMEtWMW1NMGMvNHA0SjRRclE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0642; 6:5BCnHTgYWYwkF4rg4P5l999VkCJL7rT9e25+mebkFvqYNLt0iZCoVf+n9JMHV1m2fmr1YULuXmMwrshRRkXdBgmh4V6WgsqiP24unjACwzJ8LTiz2gysWfFr7NEbpGpqTts/KlHc6AGgpH8Mq1nI8X5Ln28Pk37Tu44P9cb5DwKEsQCIAK0Nur92+Xmeh0VdpuWVq9rtN2+cLRTkEG/aTUMSHNhILOhUJ2Ns6HIu5e4a/K50VYQUSp5ZNcH+gxC374ZKz4E2MGgzt2Di6UEYXDva7gN5vF+TsICG2En8QU7CDNDvWWNbG1Zvxk0RkZXvAbZPwW/4w8hflSLie7F6UFO7b2psZwwmU7s0hHbaU3AI25Pt5k7lRp/x9eTbtA6IlWwW1m0rlXoEBDxZGT2+Ag==; 5:IFMsVap6L9fRgf4qPCfO3eubhGROnuZ3O39Pzv8CHW0lzwc6giukfGMEZsCffsbNWtZSdcwM7Y1Tc9gi+HehxuW1G2aX/jUzmpBMmj5MvOsxiPby4kiB0AtwIQnY7HIiT0DTJhGMLaSsva70Awchhw==; 24:OMkQlyVZa5zSkO60LzBxLsOmk2Hrb3V0TntGw7gJT8yzPyJRD/L4anXWRrbka1KD1CymxORP8DVX7G+njWUs2XspJ/Z9HXH8pU4SLf4bBEE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0642; 7:18EqhdxQeBOEuUAZsFPbG147LUnR6rypj6WF6+bQty/I4eDd3h45QVo0CXIJ8yYmSfFJFiNwvmMVE1iDfy5lbBNNhxOg2w/SwVMMG3EZ2G9q4K5ITO1gqItIrwrcewMIpQ566M1QU0ZpAZ0Ixk3jdgyZm4s0ihtWFZtzj5r6aBn4j9eqWjP3eUrSAJ2xHqEMgTcAJMlJyWUPLfYS+Owy+9e1pda+jvuNZJPKWPfmtFORbLQsC6CKWMMnVTzD4hM+BpbY/eWA69whQxHUEJBMnxuDKESYDcMTmS0dYWGThCBd5Sj/+H8axG7b/CuSnXFYjmx2IglH/IsEaJi0UpGlf6HBFAavEh50zr/lAw0MuFb6FQ6edNAbSpP5cqC0H48yf3qkNVvOsjHaOi1NMrlWt2wJtrqD3NTYQYbPKH72dsbPTINpbPhhuaJ0urT9dEM4iTTq6WloTFBAULot3RZcfls0E3BSW41OX/vw7j2fw3/7kO4ydv6lZqUZUJQZzk/Yv9VIy3V8T4Jy7z8E2NF5QQ== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2017 02:42:40.3875 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0642 Archived-At: Subject: Re: [dispatch] rfc5988bis X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 02:42:46 -0000 On 2017/02/13 11:03, Mark Nottingham wrote: > Hi DISPATCH, > > Could I please have ~15 minutes in Chicago to present proposed changes to RFC5988, with an eye towards finding an appropriate home for the work? For those who don't want to look this up, nor are able to remember all the RFC numbers and their topics, RFC 5988 is "Web Linking". Regards, Martin. > I've briefly mentioned this before, would appreciate a bit more time to go into detail and have the discussion. > > Draft: > https://tools.ietf.org/html/draft-nottingham-rfc5988bis-04 > > Thanks, From nobody Mon Feb 13 02:11:30 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0101295C1 for ; Mon, 13 Feb 2017 02:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rY4LUbNKEl4Z for ; Mon, 13 Feb 2017 02:11:20 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0701295A7 for ; Mon, 13 Feb 2017 02:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KXBZ/YUt5U0ojWYA6zYYDHdXwGnrlGBERoeNQyEOsEY=; b=JiC8bs0NCnVNx69XmuBJUGRmKeHkaMTL+Q9ee29ACfI960XFlPzWWaag2NjBBw0sAH5AQu4DAdDcmcZ60XVViLPwmbjmzWq7FLL9kJHjwy2gUeKjLJOrhcGpF2vNYgZKC8Kcqephkuqu4DEnUERjyhOllwA1xhOZIHRqXZT3ERM= Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp0177.outbound.protection.outlook.com [216.32.181.177]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-162-YUMiiZLzNhqg5FTslCw5qA-1; Mon, 13 Feb 2017 05:11:17 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 13 Feb 2017 10:11:14 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0888.030; Mon, 13 Feb 2017 10:11:13 +0000 From: "Asveren, Tolga" To: "dispatch@ietf.org" Thread-Topic: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.txt Thread-Index: AdJyZKwyKLOj9WTjXE6lqZ73W/PzAQQdQvEwAAAPopAABKfbIAAynmDAAILqLVA= Date: Mon, 13 Feb 2017 10:11:13 +0000 Message-ID: References: <116b4e381feb4a26b82b7bb5f401bbea@HE105828.emea1.cds.t-internal.com> <17c2ddaa8a534ec9aaa28d6cfaaf61a6@HE104696.emea1.cds.t-internal.com> <23820_1486655601_589C9071_23820_103_1_88CAD1D4E8773F42858B58CAA28272A017E719C6@OPEXCNORM2D.corporate.adroot.infra.ftgroup> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7D8B7@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7D8B7@VOEXM31W.internal.vodafone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 050374e7-497e-4493-d2b6-08d453f8a40d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2351; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:VKGMLIljy8iv6tFHiAq9SCwn/iZTiQj9EZP2gwMzx2nanNeKpI4zSzbo1Y7IS1FuSJYcWS2qoc3o3cJpiEtiYkMmSmiffR2Srws64NFq3nmMMJfm7nP7hYyrcIGWgRCH+s+c6X1t3b1DStCuWqpWAPtAmnbi9hJ+zYyserkMkyfoBOdcItrt+IQFgXdYYoyibTL6K01TZPGejgLSeZ5ekI9lw9K7/V9Ur1sWr6Al+Z8MIhJAaxI7tvt1jcCVIljFo9HEiLS20I8nexhOnbYlx8YinHOiTL94+3bqrHxRJ7dmrrEG4Z05mJLL96JgKYGENUmILalI9wTWSfNfRBRWPCJXuYd0qYIz+BlfIt557SUqlevc+wThL9IUKpOiuQstz/stQcUJkjn/YHMLY8J+h7eZU5m9xXb+RWYOnvNVfSBu+OUwfKJy0nquvRBfFGOkEZ1EIjFYHLkfH+oH5YBizM3DTjmehqEJQ0FCC0fPua1kzddAnetEMYazWUiG9rYhR+LpQ5uZ/zyR/u1R1vEmzw==; 20:/t8LYxkW5jAsR9ufE32Ne1OsZBpwECkzGfOt5iDqOfvcAhBCHwlv6xsvJOn7J0GwZmCd2et/w0DdTNzrZljk0y0fF2TAYxIDzgP8MMY+TAzW601YIk8pdMBcsXS2EHcSH9DuqBYhvbk5O1aG/PvtF/cHxyV6uS3ql310pVgT99Y= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(267521308742693)(18271650672692)(21748063052155)(218173480177578); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(6072148); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 02176E2458 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(199003)(377454003)(189002)(30584003)(8936002)(105586002)(2906002)(101416001)(106356001)(7736002)(3280700002)(2351001)(3660700001)(81166006)(6506006)(110136004)(81156014)(54356999)(76176999)(66066001)(3846002)(790700001)(102836003)(50986999)(6116002)(68736007)(33656002)(5630700001)(1730700003)(5890100001)(77096006)(6436002)(229853002)(230783001)(25786008)(54556002)(5640700003)(54896002)(6306002)(236005)(99286003)(55016002)(2501003)(733005)(606005)(2900100001)(92566002)(9686003)(189998001)(97736004)(38730400002)(53386004)(7696004)(6916009)(6246003)(5660300001)(2950100002)(966004)(53936002)(93886004)(450100001)(122556002)(7906003)(86362001)(74316002)(19609705001)(7099028)(15669805003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2017 10:11:13.2774 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 X-MC-Unique: YUMiiZLzNhqg5FTslCw5qA-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350879604A2F940F8EA8B4AB2590SN2PR03MB2350namp_" Archived-At: Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 10:11:28 -0000 --_000_SN2PR03MB2350879604A2F940F8EA8B4AB2590SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I also support moving this work forward. It also would make sense to mention about possibility of Geolocation header= to be used during signature generation in the context of RFC4474bis. If th= ere is agreement, I can provide relevant text. Thanks, Tolga From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Dawes, Peter= , Vodafone Group Sent: Friday, February 10, 2017 11:12 AM To: bruno.chatras@orange.com; A.Seus@telekom.de; R.Jesske@telekom.de; dispa= tch@ietf.org Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.= txt +1 One comment, the draft contains the text "Thus it is intended to use this p= arameter in trust domains where Spec(T) as described in [RFC3325] exists on= ly." but does not define a Spec(T) instance. I think the draft needs to say= something about what would be a suitable Spec(T). Regards, Peter From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of bruno.chatra= s@orange.com Sent: 09 February 2017 15:53 To: A.Seus@telekom.de; R.Jesske@telekom.de; dispatch@ietf.org Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.= txt +1 De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de A.Seus@telek= om.de Envoy=E9 : jeudi 9 f=E9vrier 2017 14:47 =C0 : R.Jesske@telekom.de; dispatch@ietf.org Objet : Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.t= xt Thank you Roland for this activity. >From the ETSI M493 point of view, the = differentiation of network-provided and user-provided location values would= be a great relief, especially for the public safety answering points (PSAP= s), but also for the SIP proxies which have to construct the Geolocation he= ader with multiple location values from different sources. This would help = to meet the requirements from regulation. Kind regards Albrecht _____________________________________________ Von: Jesske, Roland Gesendet: Donnerstag, 19. Januar 2017 16:00 An: 'dispatch@ietf.org' Betreff: new draft: draft-winterbottom-dispatch-locparam-02.txt Dear all, now I have taken the task to proceed with James draft on the "Location Sour= ce Parameter for the SIP Geolocation". This is needed to support ETSI the work as part of their M/493 stage-3 docu= ment. They would like to finalize their work mid of 2017. https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-02 There was one comment on the list: https://www.ietf.org/mail-archive/web/di= spatch/current/msg06193.html which I have addressed within the new draft. Thank you and Best Regards Roland Mit freundlichen Gr=FC=DFen Roland Jesske Deutsche Telekom Technik GmbH Fixed Mobile Engineering Deutschland Roland Jesske FMED93-5 Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 58-12766 (Tel.) +49 6151 58-13395 (Fax) +49 171 8618-445 (Mobil) http://www.telekom.com Erleben, was verbindet. [cid:image001.png@01CFD71F.3CB1D880] Pflichtangaben gem=E4=DF =A7 35 a GmbHG www.telekom.de/pflichtangaben-dttechnik Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_SN2PR03MB2350879604A2F940F8EA8B4AB2590SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

I also support moving this work forward.=

 

It also would make sense to mention about possibili= ty of Geolocation header to be used during signature generation in the cont= ext of RFC4474bis. If there is agreement, I can provide relevant text.

 

Thanks,

Tolga

 

From: dispatch [mailto:dispatch-boun= ces@ietf.org] On Behalf Of Dawes, Peter, Vodafone Group
Sent: Friday, February 10, 2017 11:12 AM
To: bruno.chatras@orange.com; A.Seus@telekom.de; R.Jesske@telekom.de= ; dispatch@ietf.org
Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locpa= ram-02.txt

 

+1

 

One comment, the draft= contains the text “Thus it is intended to use this parameter in trus= t domains where Spec(T) as described in [RFC3325] exists only.” but does not define a Spec(T) instance. I think the draft nee= ds to say something about what would be a suitable Spec(T).

 

Regards,

Peter

 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of bruno.chatr= as@orange.com
Sent: 09 February 2017 15:53
To: A.Seus@telekom.de; R.Jesske@telekom.de; dispatch@ietf= .org
Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locpa= ram-02.txt

 

+1

 

De : disp= atch [mailto:dispatch-bounces@= ietf.org] De la part de A.Seus@telekom.de=
Envoy=E9 : jeudi 9 f=E9vrier 2017 14:47
=C0 : R.Jesske@telekom.d= e; dispatch@ietf.org
Objet : Re: [dispatch] new draft: draft-winterbottom-dispatch-l= ocparam-02.txt

 

Thank you Roland for this activity. >From the ETSI = M493 point of view, the differentiation of network-provided and user-provid= ed location values would be a great relief, especially for the public safety answering points (PSAPs), but also for th= e SIP proxies which have to construct the Geolocation header with multiple = location values from different sources. This would help to meet the require= ments from regulation.

 

 

Kind regards

 

Albrecht

 

 

________________________________________= _____
Von: Jesske, Roland
Gesendet: Donnerstag, 19. Januar 2017 16:00
An: 'dispatch@ietf.org'
Betreff: new draft: draft-winterbottom-dispatch-locparam-02.txt

 

 

Dear all,=

now I have taken the task to proceed wi= th James draft on the “Location Source Parameter for the SIP Geolocat= ion”. 

This is needed to support ETSI the work= as part of their M/493 stage-3 document. They would like to finalize their= work mid of 2017.

 

 

 

Thank you and Best Regards

 

Roland

 

 

Mit freundlichen Gr=FC=DFen

 

Roland Jesske<= o:p>

Deutsche Telekom Technik G= mbH
Fixed Mobile Engineering Deutschland
Roland Jesske

 

= Erleben, was verbindet. 

 



Pflichtangaben gem=E4=DF =A7 35 a GmbHG
www.telekom.de/pflichtangaben-dttechnik

Gro=DFe Ver=E4nderungen f= angen klein an – Ressourcen schonen und nicht jede E-Mail drucken.

 

 

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_SN2PR03MB2350879604A2F940F8EA8B4AB2590SN2PR03MB2350namp_-- From nobody Tue Feb 14 21:01:46 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3721F1294B0 for ; Tue, 14 Feb 2017 21:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9_Eed0yrank for ; Tue, 14 Feb 2017 21:01:40 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82416129422 for ; Tue, 14 Feb 2017 21:01:40 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 189A422E257 for ; Wed, 15 Feb 2017 00:01:34 -0500 (EST) From: Mark Nottingham Content-Type: multipart/alternative; boundary="Apple-Mail=_3242CCED-792F-4C94-9921-3CAA1769735A" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: References: <148713467221.9998.16183093258381452535.idtracker@ietfa.amsl.com> To: DISPATCH Date: Wed, 15 Feb 2017 16:01:31 +1100 X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [dispatch] Fwd: New Version Notification for draft-nottingham-json-home-06.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 05:01:44 -0000 --Apple-Mail=_3242CCED-792F-4C94-9921-3CAA1769735A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi DISPATCH, I've been working on this spec for a while on the back burner, and am = getting a certain amount of pressure from a community of people that use = it to move towards publication. I'm very happy to go independent stream on it, but since one of the = primary audiences is defining HTTP-based protocols in standards, it = might be better to do it through the IETF. I'd LOVE to hear feedback about whether this sort of thing is useful for = defining such things; I firmly believe that we need better practices and = tools for defining protocols based upon HTTP if we're going to do it at = the IETF (and we seem to be doing so regularly). This *could* be one of = those tools. Chairs, if there's time I'd like to chat about this for a few minutes in = Chicago. Thanks, > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-json-home-06.txt > Date: 15 February 2017 at 3:57:52 pm AEDT > To: "Mark Nottingham" >=20 >=20 > A new version of I-D, draft-nottingham-json-home-06.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Name: draft-nottingham-json-home > Revision: 06 > Title: Home Documents for HTTP APIs > Document date: 2017-02-15 > Group: Individual Submission > Pages: 18 > URL: = https://www.ietf.org/internet-drafts/draft-nottingham-json-home-06.txt > Status: = https://datatracker.ietf.org/doc/draft-nottingham-json-home/ > Htmlized: = https://tools.ietf.org/html/draft-nottingham-json-home-06 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-json-home-06 >=20 > Abstract: > This document proposes a "home document" format for non-browser HTTP > clients. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_3242CCED-792F-4C94-9921-3CAA1769735A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi DISPATCH,

I've been working on this spec for a while on the back = burner, and am getting a certain amount of pressure from a community of = people that use it to move towards publication.

I'm very happy to go independent stream = on it, but since one of the primary audiences is defining HTTP-based = protocols in standards, it might be better to do it through the = IETF.

I'd LOVE = to hear feedback about whether this sort of thing is useful for defining = such things; I firmly believe that we need better practices and tools = for defining protocols based upon HTTP if we're going to do it at the = IETF (and we seem to be doing so regularly). This *could* be one of = those tools.

Chairs, if there's time I'd like to chat about this for a few = minutes in Chicago.

Thanks,



Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-nottingham-json-home-06.txt
Date: = 15 February 2017 at 3:57:52 pm = AEDT
To: = "Mark Nottingham" <mnot@mnot.net>

A new version of I-D, draft-nottingham-json-home-06.txt
has been successfully submitted by Mark Nottingham and posted = to the
IETF repository.

Name: = = draft-nottingham-json-home
Revision: 06
Title:= = Home Documents for HTTP APIs
Document date: = 2017-02-15
Group: Individual Submission
Pages:= = 18
URL: =            https://www.ietf.org/internet-drafts/draft-nottingham-json-home= -06.txt
Status: =         https://datatracker.ietf.org/doc/draft-nottingham-json-home/
Htmlized:       https://tools.ietf.org/html/draft-nottingham-json-home-06Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-json-home-= 06

Abstract:
=   This document proposes a "home document" format for = non-browser HTTP
  clients.




Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--
Mark Nottingham =   https://www.mnot.net/

= --Apple-Mail=_3242CCED-792F-4C94-9921-3CAA1769735A-- From nobody Wed Feb 15 05:03:21 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87B31295D6 for ; Wed, 15 Feb 2017 05:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg3nvjR5hmy5 for ; Wed, 15 Feb 2017 05:03:18 -0800 (PST) Received: from smtp144.dfw.emailsrvr.com (smtp144.dfw.emailsrvr.com [67.192.241.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4C6129573 for ; Wed, 15 Feb 2017 05:03:18 -0800 (PST) Received: from smtp31.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp31.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 6BB59400E4; Wed, 15 Feb 2017 08:03:17 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp31.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id D8EFB40089; Wed, 15 Feb 2017 08:03:16 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 15 Feb 2017 08:03:17 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <42720193-513f-d7a8-aebc-1ce9e4f426ed@it.aoyama.ac.jp> Date: Wed, 15 Feb 2017 06:03:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42720193-513f-d7a8-aebc-1ce9e4f426ed@it.aoyama.ac.jp> To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Mark Nottingham X-Mailer: Apple Mail (2.3259) Archived-At: Cc: DISPATCH Subject: Re: [dispatch] rfc5988bis X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 13:03:20 -0000 Yes, we can have some agenda time for this. What should the agenda say = about Web Linking ? Is there a draft ? charter proposal ?=20 > On Feb 12, 2017, at 7:42 PM, Martin J. D=C3=BCrst = wrote: >=20 > On 2017/02/13 11:03, Mark Nottingham wrote: >> Hi DISPATCH, >>=20 >> Could I please have ~15 minutes in Chicago to present proposed = changes to RFC5988, with an eye towards finding an appropriate home for = the work? >=20 > For those who don't want to look this up, nor are able to remember all = the RFC numbers and their topics, RFC 5988 is "Web Linking". >=20 > Regards, Martin. >=20 >> I've briefly mentioned this before, would appreciate a bit more time = to go into detail and have the discussion. >>=20 >> Draft: >> https://tools.ietf.org/html/draft-nottingham-rfc5988bis-04 >>=20 >> Thanks, >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Feb 15 14:48:59 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639A6129B94 for ; Wed, 15 Feb 2017 14:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5OwEvmjLY8d for ; Wed, 15 Feb 2017 14:48:55 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD451298BA for ; Wed, 15 Feb 2017 14:48:54 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BF64722E1F3; Wed, 15 Feb 2017 17:48:35 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Mark Nottingham In-Reply-To: Date: Thu, 16 Feb 2017 09:48:32 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42720193-513f-d7a8-aebc-1ce9e4f426ed@it.aoyama.ac.jp> To: Cullen Jennings X-Mailer: Apple Mail (2.3259) Archived-At: Cc: DISPATCH Subject: Re: [dispatch] rfc5988bis X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 22:48:57 -0000 > On 16 Feb 2017, at 12:03 am, Cullen Jennings wrote: >=20 >=20 > Yes, we can have some agenda time for this. What should the agenda say = about Web Linking ? Is there a draft ? charter proposal ?=20 See my original message below for a link to the draft. Straw-man charter: ---8<--- WG Name: 5988bis Acronym: 5988bis Area: ART Area Director: TBD Chair: TBD RFC5988 "Web Linking" has seen extensive deployment since publication. = Since that time, various clarifications, corrections and operational = issues have been noticed.=20 This Working Group will publish a "bis" document for RFC5988, focusing = on clarifying the document and registry operation.=20 Its focus will be on preserving interoperability with existing = deployments of web linking, especially the `Link` HTTP header fields, = HTML5 and Atom. Changes that are backwards-incompatible with RFC5988 are = acceptable, provided that the Working Group judges there is sufficient = motivation, and that such changes do not break compatibility with Web = linking as widely deployed. The only deliverable of this Working Group is a RFC5988bis document. Topics that are out of scope for this Working Group include: * Defining new features, capabilities or registries * Defining new link relation types * Defining new target attributes * Defining new link serialisations The Working Group will use draft-nottingham-rfc5988bis-04 as a starting = point for its work. Doing so does not imply consensus on the contents of = that document. ## Milestones Chartering+3 months -- Submit RFC5988bis to IESG for consideration as a = Standards-Track document --->8--- >=20 >=20 >=20 >> On Feb 12, 2017, at 7:42 PM, Martin J. D=C3=BCrst = wrote: >>=20 >> On 2017/02/13 11:03, Mark Nottingham wrote: >>> Hi DISPATCH, >>>=20 >>> Could I please have ~15 minutes in Chicago to present proposed = changes to RFC5988, with an eye towards finding an appropriate home for = the work? >>=20 >> For those who don't want to look this up, nor are able to remember = all the RFC numbers and their topics, RFC 5988 is "Web Linking". >>=20 >> Regards, Martin. >>=20 >>> I've briefly mentioned this before, would appreciate a bit more time = to go into detail and have the discussion. >>>=20 >>> Draft: >>> https://tools.ietf.org/html/draft-nottingham-rfc5988bis-04 >>>=20 >>> Thanks, >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Sat Feb 18 15:46:16 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E31129698 for ; Sat, 18 Feb 2017 15:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj5Tsaw3AeHT for ; Sat, 18 Feb 2017 15:46:13 -0800 (PST) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B31A129697 for ; Sat, 18 Feb 2017 15:46:13 -0800 (PST) Received: from [IPv6:2601:648:8301:730f:ec31:c93d:177c:cc9a] (unknown [IPv6:2601:648:8301:730f:ec31:c93d:177c:cc9a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3B261AE7AC for ; Sun, 19 Feb 2017 00:46:11 +0100 (CET) To: DISPATCH From: Marc Petit-Huguenin Message-ID: <56353963-c569-711d-c891-7ae901c81cd7@acm.org> Date: Sat, 18 Feb 2017 15:46:04 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mv71NeRsw0nJV452Lo79wPm2s1l3LpkUk" Archived-At: Subject: [dispatch] draft-petithuguenin-ice-pmtud-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 23:46:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mv71NeRsw0nJV452Lo79wPm2s1l3LpkUk Content-Type: multipart/mixed; boundary="LqCsjEfdMfjpkTKkPGFSCcWeQfqDf00oF"; protected-headers="v1" From: Marc Petit-Huguenin To: DISPATCH Message-ID: <56353963-c569-711d-c891-7ae901c81cd7@acm.org> Subject: draft-petithuguenin-ice-pmtud-00 --LqCsjEfdMfjpkTKkPGFSCcWeQfqDf00oF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear Dispatch, I would like 5 minutes to present draft-petithuguenin-ice-pmtud-00 (not y= et published) during the dispatch session. This draft started with the I= CE specific stuff that was removed from draft-ietf-tram-stun-pmtud-02, wi= th the goal of defining a usage of stun-pmtud to discover the Path MTU fo= r an RTP/RTCP session. Thanks. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --LqCsjEfdMfjpkTKkPGFSCcWeQfqDf00oF-- --mv71NeRsw0nJV452Lo79wPm2s1l3LpkUk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlio3MEACgkQKcRFldZq fsSldhAAuiPzbK1t1NzhOAlORmYqszYyL/y7IM7xlWK0jV6rbjaZdqssZV+YV7GH uBwjm3s9hXpKRCCDJSzK8ZQer4H0wcx4us5RAaYQrZOAHWJVwVBP+H32XMaY6wjZ 2MxI5tMMfUnGltCo3c7bZq8DoV9rDpx2/p9gYbPiZQb3P/0EjA6swO40SFmQwfRg O9ttLQyLMmCWVa3y3FAtOKVeBbwZiiusRVl0X44DKqzYtoSzO/sUqXFtL0o/B9Yl mbqa1j6WKsch0wFQ86Hlu7u0xy0X73ZrMXFcxs9xanY7xu2Z5hdLX2GfYggDQehA /NdKNpXAKzweFxOZ9V1bW63wFLNrBxiIoouBDnY1DPpeQKsEXI6yuk9M4XwI5pAv zMLgkSzLKRfMN01he/6XxpW1RUzTW7UXumkuEACC5DVwuIHqPZ2BHKDoDfD589J6 QvR1eisrVVRiusJmupWSHfDkIsvmPwEHCJbVuhG8SYCFNo8ah7naifSGhBpciLSX BfUucG1V/DCR0vMS/1F2J+J11B9jzln+Ogt9OgcimMtaWngptHvkH5AynzfTy0Mo IrA4Skfycxu5ED/UbWFuLtI+5Vhc7pBKP2OOwrZ73X5B/1zZUR/2Hup6Sj0kCUav 03u53GpKRxt3iV0bsb+Ho8+uO5rQ5ZpJwCm9wtCk8pGlpln5Vik= =Noft -----END PGP SIGNATURE----- --mv71NeRsw0nJV452Lo79wPm2s1l3LpkUk-- From nobody Tue Feb 21 04:11:30 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAD71298CA for ; Tue, 21 Feb 2017 04:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.785 X-Spam-Level: X-Spam-Status: No, score=-3.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9waZjp7Z7z0 for ; Tue, 21 Feb 2017 04:11:27 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF90F1298C5 for ; Tue, 21 Feb 2017 04:11:26 -0800 (PST) Received: from [193.109.254.3] by server-4.bemta-6.messagelabs.com id 20/4F-25093-C6E2CA85; Tue, 21 Feb 2017 12:11:24 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRWlGSWpSXmKPExsWi75nTrZuttyb C4PtLEYulkxawOjB6LFnykymAMYo1My8pvyKBNePZi1NsBTdFK9b3XWZuYPwi3MXIxSEksJ1R 4n7PRiYI5zCjxPwz99ggnCOMEgfOfmSEcOYySrz8eo+5i5GDg03AXmLGnpguRk4OEQFtiaOru phBbGEBG4nFB16wQcQdJRqev2aGsPUkpp4/D9bKIqAq8f5YAUiYVyBU4sbPkywgNqOArMSXxt Vg5cwC4hK3nsxnArElBAQkluw5zwxhi0q8fPyPFaImT2LLsQcsEHMEJU7OfAJmCwGN/7dyEdM ERqFZSEbNQtIyC0kLRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8WoUZxaVJZapGtooZdU lJmeUZKbmJmja2hgppebWlycmJ6ak5hUrJecn7uJERgxDECwg/HmxoBDjJIcTEqivNlSayKE+ JLyUyozEosz4otKc1KLDzHKcHAoSfCq6gLlBItS01Mr0jJzgLELk5bg4FES4ZUASfMWFyTmFm emQ6ROMSpKifNGgyQEQBIZpXlwbbB0cYlRVkqYlxHoECGegtSi3MwSVPlXjOIcjErCvCEgU3g y80rgpr8CWswEtPimx0qQxSWJCCmpBkaJKSEqv0Scu6Z1nXRVuDFF//KkS583GryvfdRY4f/f zPVr7snEaF/Xry9SX1qYPGAXEQtyFNobdEVqApOE+cLm3tYZ3WU2zFNCGyozri1T+9Dxh+OUA SfTueMPDmsccPGfq7OIxe6ves1UR+ZlAX+1ChkrNuVLn+L259609PO6Fo+o2MLidUosxRmJhl rMRcWJAG5zPbsSAwAA X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-3.tower-184.messagelabs.com!1487679082!104229080!2 X-Originating-IP: [47.73.108.139] X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5151 invoked from network); 21 Feb 2017 12:11:23 -0000 Received: from vgdpm13vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.139) by server-3.tower-184.messagelabs.com with AES256-SHA256 encrypted SMTP; 21 Feb 2017 12:11:23 -0000 Received: from VOEXH10W.internal.vodafone.com (47.73.211.214) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Feb 2017 13:11:03 +0100 Received: from VOEXC03W.internal.vodafone.com (145.230.101.23) by VOEXH10W.internal.vodafone.com (47.73.211.208) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 21 Feb 2017 13:11:03 +0100 Received: from VOEXC28W.internal.vodafone.com (145.230.103.200) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.294.0; Tue, 21 Feb 2017 13:11:03 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by voexc28w ([145.230.103.200]) with mapi id 14.03.0294.000; Tue, 21 Feb 2017 13:11:02 +0100 From: "Dawes, Peter, Vodafone Group" To: "dispatch@ietf.org" Thread-Topic: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 Thread-Index: AdKMOkqULjfTFqrpRdKJrK4k4ecBVg== Date: Tue, 21 Feb 2017 12:11:02 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C8BD8B@VOEXM31W.internal.vodafone.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C8BD8BVOEXM31Winterna_" MIME-Version: 1.0 Archived-At: Subject: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 12:11:28 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C8BD8BVOEXM31Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have read through draft-jesske-dispatch-reason-loc-q850-00 and I think it= is clearly written and useful. One comment, I think the example in clause = 5 should say "resp-location=3DLN" instead of "location=3DLN". Regards, Peter --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C8BD8BVOEXM31Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

I have read through draft-jesske-d= ispatch-reason-loc-q850-00 and I think it is clearly written and useful. On= e comment, I think the example in clause 5 should say “resp-location= =3DLN” instead of “location=3DLN”.

 

Regards,

Peter

--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C8BD8BVOEXM31Winterna_-- From nobody Wed Feb 22 08:35:30 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935901296CE for ; Wed, 22 Feb 2017 08:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_EMBEDS=1.799, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ll5I_4m8cz6 for ; Wed, 22 Feb 2017 08:35:27 -0800 (PST) Received: from email.salsgiver.com (email.salsgiver.com [206.67.234.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98B51294FD for ; Wed, 22 Feb 2017 08:35:27 -0800 (PST) Received: from [10.96.43.71] ([156.154.81.54]) (authenticated bits=0) by email.salsgiver.com (8.15.2/8.15.2) with ESMTPA id v1MGZO5Z006457; Wed, 22 Feb 2017 11:35:25 -0500 (EST) (envelope-from br@salsgiver.com) X-Authentication-Warning: email.salsgiver.com: Host [156.154.81.54] claimed to be [10.96.43.71] Content-Type: multipart/alternative; boundary="Apple-Mail=_989A6B5D-91AD-4382-9984-EF4F120DC676" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Wed, 22 Feb 2017 11:35:24 -0500 Message-Id: <76D7E645-8CAB-4AF6-AF42-EE4FB06CC6BD@salsgiver.com> References: <116b4e381feb4a26b82b7bb5f401bbea@HE105828.emea1.cds.t-internal.com> <17c2ddaa8a534ec9aaa28d6cfaaf61a6@HE104696.emea1.cds.t-internal.com> <23820_1486655601_589C9071_23820_103_1_88CAD1D4E8773F42858B58CAA28272A017E719C6@OPEXCNORM2D.corporate.adroot.infra.ftgroup> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7D8B7@VOEXM31W.internal.vodafone.com> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] new draft: draft-winterbottom-dispatch-locparam-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 16:35:29 -0000 --Apple-Mail=_989A6B5D-91AD-4382-9984-EF4F120DC676 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The location is a PIDF-LO, which has a element. That = tells you who created the location information. This mechanism describes who put it in the SIP signaling, which of = course is different. However, the text doesn=92t say why the is not sufficient = for the purpose. In general, it=92s more useful to understand who created the information = and less interesting to know who added it. Brian > On Feb 13, 2017, at 5:11 AM, Asveren, Tolga = wrote: >=20 > I also support moving this work forward. > =20 > It also would make sense to mention about possibility of Geolocation = header to be used during signature generation in the context of = RFC4474bis. If there is agreement, I can provide relevant text. > =20 > Thanks, > Tolga > =20 > From: dispatch [mailto:dispatch-bounces@ietf.org = ] On Behalf Of Dawes, Peter, Vodafone = Group > Sent: Friday, February 10, 2017 11:12 AM > To: bruno.chatras@orange.com ; = A.Seus@telekom.de ; R.Jesske@telekom.de = ; dispatch@ietf.org = > Subject: Re: [dispatch] new draft: = draft-winterbottom-dispatch-locparam-02.txt > =20 > +1 > =20 > One comment, the draft contains the text =93Thus it is intended to use = this parameter in trust domains where Spec(T) as described in [RFC3325] = exists only.=94 but does not define a Spec(T) instance. I think the = draft needs to say something about what would be a suitable Spec(T). > =20 > Regards, > Peter > =20 > From: dispatch [mailto:dispatch-bounces@ietf.org = ] On Behalf Of = bruno.chatras@orange.com > Sent: 09 February 2017 15:53 > To: A.Seus@telekom.de ; R.Jesske@telekom.de = ; dispatch@ietf.org = > Subject: Re: [dispatch] new draft: = draft-winterbottom-dispatch-locparam-02.txt > =20 > +1 > =20 > De : dispatch [mailto:dispatch-bounces@ietf.org = ] De la part de A.Seus@telekom.de = > Envoy=E9 : jeudi 9 f=E9vrier 2017 14:47 > =C0 : R.Jesske@telekom.de ; = dispatch@ietf.org > Objet : Re: [dispatch] new draft: = draft-winterbottom-dispatch-locparam-02.txt > =20 > Thank you Roland for this activity. >=46rom the ETSI M493 point of = view, the differentiation of network-provided and user-provided location = values would be a great relief, especially for the public safety = answering points (PSAPs), but also for the SIP proxies which have to = construct the Geolocation header with multiple location values from = different sources. This would help to meet the requirements from = regulation. > =20 > =20 > Kind regards > =20 > Albrecht > =20 > =20 > _____________________________________________ > Von: Jesske, Roland=20 > Gesendet: Donnerstag, 19. Januar 2017 16:00 > An: 'dispatch@ietf.org ' > Betreff: new draft: draft-winterbottom-dispatch-locparam-02.txt > =20 > =20 > Dear all, > now I have taken the task to proceed with James draft on the =93Location= Source Parameter for the SIP Geolocation=94.=20 > This is needed to support ETSI the work as part of their M/493 stage-3 = document. They would like to finalize their work mid of 2017. > =20 > https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-02 = > =20 > There was one comment on the list: = https://www.ietf.org/mail-archive/web/dispatch/current/msg06193.html = = which I have addressed within the new draft. > =20 > Thank you and Best Regards > =20 > Roland > =20 > =20 > Mit freundlichen Gr=FC=DFen > =20 > Roland Jesske > Deutsche Telekom Technik GmbH > Fixed Mobile Engineering Deutschland > Roland Jesske > FMED93-5 > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 58-12766 (Tel.) > +49 6151 58-13395 (Fax) > +49 171 8618-445 (Mobil) > http://www.telekom.com > =20 > ERLEBEN, WAS VERBINDET.=20 >=20 > =20 >=20 >=20 > Pflichtangaben gem=E4=DF =A7 35 a GmbHG > www.telekom.de/pflichtangaben-dttechnik = > Gro=DFe Ver=E4nderungen fangen klein an =96 Ressourcen schonen und = nicht jede E-Mail drucken. > =20 > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_989A6B5D-91AD-4382-9984-EF4F120DC676 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The location is a PIDF-LO, which has a <provided-by> = element.  That tells you who created the location information.

This mechanism describes = who put it in the SIP signaling, which of course is different.

However, the text = doesn=92t say why the <provided-by> is not sufficient for the = purpose.

In = general, it=92s more useful to understand who created the information = and less interesting to know who added it.

Brian

On Feb 13, 2017, at 5:11 AM, Asveren, Tolga <tasveren@sonusnet.com> wrote:

I = also support moving this work forward.
 
It also would make sense to mention about = possibility of Geolocation header to be used during signature generation = in the context of RFC4474bis. If there is agreement, I can provide = relevant text.
 
Thanks,
Tolga
 
From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf = Of Dawes, Peter, = Vodafone Group
Sent: Friday, February 10, 2017 = 11:12 AM
To: bruno.chatras@orange.com; A.Seus@telekom.de; R.Jesske@telekom.de; dispatch@ietf.org
Subject: Re: [dispatch] new draft: = draft-winterbottom-dispatch-locparam-02.txt
 
+1
 
One comment, = the draft contains the text =93Thus it is intended to use this parameter = in trust domains where Spec(T) as described in [RFC3325] exists only.=94 = but does not define a Spec(T) instance. I think the draft needs to say = something about what would be a suitable Spec(T).
 
Regards,
Peter
 
From: dispatch = [mailto:dispatch-bounces@ietf.org] On Behalf = Of bruno.chatras@orange.com
Sent: 09 February 2017 15:53
To: A.Seus@telekom.de; R.Jesske@telekom.de; dispatch@ietf.org
Subject: Re: [dispatch] new draft: = draft-winterbottom-dispatch-locparam-02.txt
 
+1
 
De : dispatch = [mailto:dispatch-bounces@ietf.org] De la part = de A.Seus@telekom.de
Envoy=E9 : jeudi 9 f=E9vrier 2017 = 14:47
=C0 : R.Jesske@telekom.de; dispatch@ietf.org
Objet : Re: [dispatch] new draft: = draft-winterbottom-dispatch-locparam-02.txt
 
Thank you Roland for this activity. = >=46rom the ETSI M493 point of view, the differentiation of = network-provided and user-provided location values would be a great = relief, especially for the public safety answering points (PSAPs), but = also for the SIP proxies which have to construct the Geolocation header = with multiple location values from different sources. This would help to = meet the requirements from regulation.
 
 
Kind regards
 
Albrecht
 
 
_____________________________________________
Von: Jesske, Roland 
Gesendet: Donnerstag, 19. Januar 2017 = 16:00
An: 'dispatch@ietf.org'
Betreff: new draft: = draft-winterbottom-dispatch-locparam-02.txt
 
 
Dear all,
now I have taken the task to proceed with James draft on the = =93Location Source Parameter for the SIP Geolocation=94. 
This is needed to support ETSI the work as part of their = M/493 stage-3 document. They would like to finalize their work mid of = 2017.
 
https://tools.ietf.org/html/draft-winterbottom-dispatch-locpara= m-02
 
There was one comment on the list: https://www.ietf.org/mail-archive/web/dispatch/current/msg06193= .html  which I have addressed within the new draft.
 
Thank you and Best = Regards
 
Roland
 
 
Mit freundlichen = Gr=FC=DFen
 
Roland Jesske
Deutsche = Telekom Technik GmbH
Fixed Mobile Engineering = Deutschland
Roland Jesske
FMED93-5
Heinrich-Hertz-Stra=DFe 3-7, 64295 = Darmstadt
+49 6151 58-12766 (Tel.)
+49 6151 = 58-13395 (Fax)
+49 171 8618-445 (Mobil)
http://www.telekom.com
 
ERLEBEN, = WAS VERBINDET. 
 

Pflichtangaben gem=E4=DF =A7 35 a GmbHG
www.telekom.de/pflichtangaben-dttechnik
Gro=DFe Ver=E4nderungen fangen = klein an =96<= b class=3D""> Ressourcen schonen und = nicht jede E-Mail drucken.
 
 
 
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes =
peuvent contenir des informations confidentielles ou privilegiees et ne =
doivent donc
pas etre diffuses, exploites ou =
copies sans autorisation. Si vous avez recu ce message par erreur, =
veuillez le signaler
a l'expediteur =
et le detruire ainsi que les pieces jointes. Les messages electroniques =
etant susceptibles d'alteration,
Orange decline =
toute responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and =
its attachments may contain confidential or privileged information that =
may be protected by law;
they should not =
be distributed, used or copied without authorisation.
If you have received this email in error, please notify the =
sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages =
that have been modified, changed or falsified.
Thank you.
_______________________________________________
dispatch mailing = list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_989A6B5D-91AD-4382-9984-EF4F120DC676-- From nobody Tue Feb 28 06:04:30 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAAE129543 for ; Tue, 28 Feb 2017 06:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwwnQX2v4sHn for ; Tue, 28 Feb 2017 06:04:27 -0800 (PST) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086821294EB for ; Tue, 28 Feb 2017 06:04:27 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id AC615120597 for ; Tue, 28 Feb 2017 15:04:25 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 8ECFA60069 for ; Tue, 28 Feb 2017 15:04:25 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0319.002; Tue, 28 Feb 2017 15:04:25 +0100 From: To: "dispatch@ietf.org" Thread-Topic: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 Thread-Index: AdKMOkqULjfTFqrpRdKJrK4k4ecBVgFjynMg Date: Tue, 28 Feb 2017 14:04:24 +0000 Message-ID: <27469_1488290665_58B58369_27469_5953_1_8B970F90C584EA4E97D5BAAC9172DBB81C92401C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C8BD8B@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C8BD8B@VOEXM31W.internal.vodafone.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB81C92401COPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 14:04:29 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB81C92401COPEXCLILMA4corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I support this Internet-Draft to progress in IETF. I suggest to have some text to refer to RFC 6432 to ease the knowledge of t= he background and the usage of the Reason header field in error responses. = I can help to provide some text. On Peter's comment, I think it is correct to have "location=3DLN" in the ex= ample as the new parameter syntax is resp-location =3D "l= ocation" EQUAL string Best Regards, Marianne De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de Dawes, Peter= , Vodafone Group Envoy=E9 : mardi 21 f=E9vrier 2017 13:11 =C0 : dispatch@ietf.org Objet : [dispatch] draft-jesske-dispatch-reason-loc-q850-00 Hi All, I have read through draft-jesske-dispatch-reason-loc-q850-00 and I think it= is clearly written and useful. One comment, I think the example in clause = 5 should say "resp-location=3DLN" instead of "location=3DLN". Regards, Peter ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8B970F90C584EA4E97D5BAAC9172DBB81C92401COPEXCLILMA4corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I suppo= rt this Internet-Draft to progress in IETF.

&n= bsp;

I sugge= st to have some text to refer to RFC 6432 to ease the knowledge of the back= ground and the usage of the Reason header field in error responses. I can h= elp to provide some text.

&n= bsp;

On Peter’s comment, I think it is corre=
ct to have "location=3DLN" in the example as the new parameter syntax is &n=
bsp;             res=
p-location    =3D  "location" EQUAL string

&n= bsp;

Best Re= gards,

Mariann= e

&n= bsp;

&n= bsp;

De : dispatch [mailto:dispatch-bounc= es@ietf.org] De la part de Dawes, Peter, Vodafone Group
Envoy=E9 : mardi 21 f=E9vrier 2017 13:11
=C0 : dispatch@ietf.org
Objet : [dispatch] draft-jesske-dispatch-reason-loc-q850-00

 

Hi All,

I have read through draft-jesske-dispatch-reason-loc-q850-00 and I think it is cl= early written and useful. One comment, I think the example in clause 5 shou= ld say “resp-location=3DLN” instead of “location=3DLNR= 21;.

 

Regards,

Peter

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8B970F90C584EA4E97D5BAAC9172DBB81C92401COPEXCLILMA4corp_-- From nobody Tue Feb 28 07:11:45 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C131295BB for ; Tue, 28 Feb 2017 07:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5xAcXSb0Sj7 for ; Tue, 28 Feb 2017 07:11:42 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1F9129574 for ; Tue, 28 Feb 2017 07:11:42 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v1SF6GiD045953; Tue, 28 Feb 2017 10:11:41 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 28w8rs4q7y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Feb 2017 10:11:41 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1SFBetC028425; Tue, 28 Feb 2017 10:11:41 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v1SFBVrB028147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Feb 2017 10:11:37 -0500 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 28 Feb 2017 15:11:23 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.57]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0319.002; Tue, 28 Feb 2017 10:11:23 -0500 From: "DOLLY, MARTIN C" To: "marianne.mohali@orange.com" Thread-Topic: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 Thread-Index: AdKMOkqULjfTFqrpRdKJrK4k4ecBVgFjynMgAALd7o4= Date: Tue, 28 Feb 2017 15:11:22 +0000 Message-ID: <1F0BB3B0-C521-4059-9573-A8EC80CB16DC@att.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C8BD8B@VOEXM31W.internal.vodafone.com>, <27469_1488290665_58B58369_27469_5953_1_8B970F90C584EA4E97D5BAAC9172DBB81C92401C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <27469_1488290665_58B58369_27469_5953_1_8B970F90C584EA4E97D5BAAC9172DBB81C92401C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1F0BB3B0C52140599573A8EC80CB16DCattcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-28_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702280139 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 15:11:44 -0000 --_000_1F0BB3B0C52140599573A8EC80CB16DCattcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support as well Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Feb 28, 2017, at 9:04 AM, "marianne.mohali@orange.com" > wrote: Hi All, I support this Internet-Draft to progress in IETF. I suggest to have some text to refer to RFC 6432 to ease the knowledge of t= he background and the usage of the Reason header field in error responses. = I can help to provide some text. On Peter=92s comment, I think it is correct to have "location=3DLN" in the = example as the new parameter syntax is resp-location =3D = "location" EQUAL string Best Regards, Marianne De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de Dawes, Peter= , Vodafone Group Envoy=E9 : mardi 21 f=E9vrier 2017 13:11 =C0 : dispatch@ietf.org Objet : [dispatch] draft-jesske-dispatch-reason-loc-q850-00 Hi All, I have read through draft-jesske-dispatch-reason-loc-q850-00 and I think it= is clearly written and useful. One comment, I think the example in clause = 5 should say =93resp-location=3DLN=94 instead of =93location=3DLN=94. Regards, Peter ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ dispatch mailing list dispatch@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dispatch&d=3DDQICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw= 7ItG0r2g&m=3D9y5R3pOq5Oz0unZ73c_Z6ifowd5txi2vvpvlY7MtzoY&s=3DJGQJ2uxeZGcN3W= dhemtyHXnm2Iy-OSng_l27WUYpOlI&e=3D --_000_1F0BB3B0C52140599573A8EC80CB16DCattcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I support as well

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Feb 28, 2017, at 9:04 AM, "marianne.mohali@orange.com" <marianne.mohali@orange.com> wrote:

Hi All,

 

I suppo= rt this Internet-Draft to progress in IETF.

&n= bsp;

I sugge= st to have some text to refer to RFC 6432 to ease the knowledge of the back= ground and the usage of the Reason header field in error responses. I can h= elp to provide some text.

&n= bsp;

On Peter=92s comment, I think it is correct t=
o have "loc=
ation=3DLN" in the example as the new parameter syntax is  =
             resp-lo=
cation    =3D  "location" EQUAL string=

&n= bsp;

Best Re= gards,

Mariann= e

&n= bsp;

&n= bsp;

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_1F0BB3B0C52140599573A8EC80CB16DCattcom_-- From nobody Tue Feb 28 07:18:37 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8331A129574 for ; Tue, 28 Feb 2017 07:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_vJg0Nl0WwN for ; Tue, 28 Feb 2017 07:18:33 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927D812953F for ; Tue, 28 Feb 2017 07:18:32 -0800 (PST) Received: from [193.109.255.99] by server-11.bemta-6.messagelabs.com id C8/84-04971-6C495B85; Tue, 28 Feb 2017 15:18:30 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRWlGSWpSXmKPExsWi75nTo3t0ytY Ig9X/zS2WTlrAarGteR+TxaEHT9kdmD1e9s9h9Fiy5CeTR8uzk2wBzFGsmXlJ+RUJrBnPbl5k LugorLj7YwFLA+OW9C5GLg4hge2MEld/7GWHcA4zSkzefpgVwtnEKLHlx0G2LkYODjYBe4kZe 2K6GDk5RASSJOYcOsoGYjMLaEv8v76OEcQWFnCQ+HF7GTtEjaNEw/PXzBC2k0Rj80KwehYBVY nzz14zgdi8AqES35bNYoTY1coksaXjPtggTgFridv/+sEaGAVkJb40rmaGWCYucevJfLBmCQE BiSV7zjND2KISLx//YwW5k1kgT6JtjQ3EfEGJkzOfsIDYQkB7/61cxDSBUWQWkkmzEDpmIemA KNGTuDF1CtssqC+XLXzNDGHrSsz4d4gFWXwBI/sqRo3i1KKy1CJdI0u9pKLM9IyS3MTMHF1DA zO93NTi4sT01JzEpGK95PzcTYzAOGQAgh2MBxYFHmKU5GBSEuXNSt4aIcSXlJ9SmZFYnBFfVJ qTWnyIUYaDQ0mCt34yUE6wKDU9tSItMweYEGDSEhw8SiK8Z0DSvMUFibnFmekQqVOMilLivAk gCQGQREZpHlwbLAldYpSVEuZlBDpEiKcgtSg3swRV/hWjOAejkjDvZpApPJl5JXDTXwEtZgJa /EIFbHFJIkJKqoHR+vxf7b5VmtOupffxzXiz1f/focvcv7n7fAVUOKaYqBVclbaJyTy67pG63 P8g/cecBm6W9ucXTIgoLfO5Zb3xe8vziwbbPrnqyrc2uQWps31QNvhY+r09e86CE2dWvb0ot/ N13S9X+13pMpVb434u35WRFZS2JYkp23fWCnsztgwXl7tbti9XYinOSDTUYi4qTgQARL174T0 DAAA= X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-7.tower-48.messagelabs.com!1488295109!95265269!1 X-Originating-IP: [47.73.108.140] X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3075 invoked from network); 28 Feb 2017 15:18:29 -0000 Received: from vgdpm14vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.140) by server-7.tower-48.messagelabs.com with AES256-SHA256 encrypted SMTP; 28 Feb 2017 15:18:29 -0000 Received: from VOEXH10W.internal.vodafone.com (47.73.211.214) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Feb 2017 16:18:24 +0100 Received: from VOEXC02W.internal.vodafone.com (145.230.101.22) by VOEXH10W.internal.vodafone.com (47.73.211.214) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 28 Feb 2017 16:18:23 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by VOEXC02W.internal.vodafone.com ([145.230.101.22]) with mapi id 14.03.0294.000; Tue, 28 Feb 2017 16:18:23 +0100 From: "Dawes, Peter, Vodafone Group" To: "DOLLY, MARTIN C" , "marianne.mohali@orange.com" Thread-Topic: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 Thread-Index: AdKMOkqULjfTFqrpRdKJrK4k4ecBVgFjynMgAALd7o4AADC54A== Date: Tue, 28 Feb 2017 15:18:23 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C94D94@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C8BD8B@VOEXM31W.internal.vodafone.com>, <27469_1488290665_58B58369_27469_5953_1_8B970F90C584EA4E97D5BAAC9172DBB81C92401C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1F0BB3B0-C521-4059-9573-A8EC80CB16DC@att.com> In-Reply-To: <1F0BB3B0-C521-4059-9573-A8EC80CB16DC@att.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C94D94VOEXM31Winterna_" MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 15:18:35 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C94D94VOEXM31Winterna_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable you are right Marianne, my mistake Rgds, Peter From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DOLLY, MARTI= N C Sent: 28 February 2017 15:11 To: marianne.mohali@orange.com Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 I support as well Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Feb 28, 2017, at 9:04 AM, "marianne.mohali@orange.com" > wrote: Hi All, I support this Internet-Draft to progress in IETF. I suggest to have some text to refer to RFC 6432 to ease the knowledge of t= he background and the usage of the Reason header field in error responses. = I can help to provide some text. On Peter's comment, I think it is correct to have "location=3DLN" in the ex= ample as the new parameter syntax is resp-location =3D "l= ocation" EQUAL string Best Regards, Marianne De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de Dawes, Peter= , Vodafone Group Envoy=E9 : mardi 21 f=E9vrier 2017 13:11 =C0 : dispatch@ietf.org Objet : [dispatch] draft-jesske-dispatch-reason-loc-q850-00 Hi All, I have read through draft-jesske-dispatch-reason-loc-q850-00 and I think it= is clearly written and useful. One comment, I think the example in clause = 5 should say "resp-location=3DLN" instead of "location=3DLN". Regards, Peter ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ dispatch mailing list dispatch@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dispatch&d=3DDQICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw= 7ItG0r2g&m=3D9y5R3pOq5Oz0unZ73c_Z6ifowd5txi2vvpvlY7MtzoY&s=3DJGQJ2uxeZGcN3W= dhemtyHXnm2Iy-OSng_l27WUYpOlI&e=3D --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C94D94VOEXM31Winterna_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

you are right Marianne= , my mistake

 

Rgds,

Peter

 

From:= dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: 28 February 2017 15:11
To: marianne.mohali@orange.com
Cc: dispatch@ietf.org
Subject: Re: [dispatch] draft-jesske-dispatch-reason-loc-q850-00

 

I support as well

Martin C. Dolly

Lead Member of Technical Staff

Core & Government/Regulatory Standards

AT&T

Cell: += 1.609.903.3360

Email: md3= 135@att.com

 


On Feb 28, 2017, at 9:04 AM, "marianne.mohali@orange.com" <marianne.mohali@orange.com> wrote:

Hi All,

 

I suppo= rt this Internet-Draft to progress in IETF.

 <= /span>

I sugge= st to have some text to refer to RFC 6432 to ease the knowledge of the back= ground and the usage of the Reason header field in error responses. I can h= elp to provide some text.

 <= /span>

On Peter’s comment, I think it is corre=
ct to have "location=3DLN" in the example as the new parameter syntax is &n=
bsp;            =
; resp-location    =3D  "location" EQUAL stri=
ng

 <= /span>

Best Re= gards,

Mariann= e

 <= /span>

 <= /span>

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C94D94VOEXM31Winterna_--