From nobody Fri Jul 1 03:40:51 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF6412D550 for ; Fri, 1 Jul 2016 03:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 PwK5FZGZ0mM7 for ; Fri, 1 Jul 2016 03:40:48 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDB812D548 for ; Fri, 1 Jul 2016 03:40:47 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-ee-577648ad1cbd Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.EC.12926.DA846775; Fri, 1 Jul 2016 12:40:45 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.294.0; Fri, 1 Jul 2016 12:40:45 +0200 To: Jeff Ahrenholz , "hipsec@ietf.org" References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> <576BF266.4040703@ericsson.com> <01A2E941-8F85-4964-8B2A-347CF48B21A0@temperednetworks.com> <5774D482.6010509@ericsson.com> <350A26F6-5DE6-4B00-A354-1186D37B6883@temperednetworks.com> From: Miika Komu Organization: Ericsson AB Message-ID: <577648AD.3000907@ericsson.com> Date: Fri, 1 Jul 2016 13:40:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <350A26F6-5DE6-4B00-A354-1186D37B6883@temperednetworks.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080704040507050503000406" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7q+5aj7JwgxNP9C2mLprMbNE65Saz A5PHkiU/mTy27ulkCWCK4rJJSc3JLEst0rdL4Mp4tfcha8Ea14rVe5MbGOfbdzFyckgImEh8 P/+CGcIWk7hwbz1bFyMXh5DAEUaJf+sfMUE4qxglug6eYASpEhbwkbj5+xGYLSIQI3Fx3hoW iKJGJolJ/TvYQBJsAloSq+5cBxvLLyApsaFhN5DNwcEroC1xYLYfSJhFQEXi8ZoPYOWiAhES s7b/YAKxeQUEJU7OfMICYnMKeEg09SxnB5nPLNDNKPH2+n8mkDlCQM0XjwVPYBSYhaRlFrIy kASzgJnEvM0PmSFsbYllC19D2dYSM34dZIOwFSWmdD9kh7BNJV4f/cgIYRtLLFv3l20BI8cq RtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMCIOLjlt+oOxstvHA8xCnAwKvHwLjhXGi7EmlhW XJl7iFEFaM6jDasvMEqx5OXnpSqJ8L51LgsX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFc SCA9sSQ1OzW1ILUIJsvEwSnVwNidpf9k3w37U++tkrcoLWlYcGUi+07ua3tSd6yo1JFUN+Dg zHlvxjmp/+r5iLtyDdmP6noCG14vCbjS3ux35f51//9Xw0oFsr9uDM58pGNwgHtq/IpbZ+Zq vLrqdHeCwgzRKU1bGKXvr7h/blbTOv2zjbcu6r5WrCo/WSIRVbxX2UGp2CLyurESS3FGoqEW c1FxIgDOaHL+kAIAAA== Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 10:40:50 -0000 --------------ms080704040507050503000406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jeff, On 06/30/2016 07:08 PM, Jeff Ahrenholz wrote: > Miika, > >> On 6/30/16, 1:12 AM, "Miika Komu" wrote: >> >> Is it actually a problem for the Responder that two different Initiato= rs >> happen to claim different SPIs? The Initiators have different IP >> addresses (or at least UDP ports if they are behind the same NAT). > > You=E2=80=99re right, it seems like it is not a problem for the Respond= er since there are different IP/ports. Ok. I added the following sentence (separated with starts) to the draft: "In first case, the SPI collision problem occurs when two Initiators run a base exchange to the same Responder (i.e. registered=20 host), and both the Initiators claim the same inbound SPI. ***This is not a problem for Responder since the two Initiators can be distinguished by their transport addresses. *** However, it is an issue for the data relay because the it cannot demultiplex packets from the Initiator to the correct Responder." >> It is a problem for the data relay, so the text says: >> >> "Upon receiving an I2 with a colliding SPI, the Responder MUST not >> include the relayed address in the R2 message because the data relay >> would not be able demultiplex the related ESP packet to the correct >> Initiator." > > Does this mean the Responder should not even send the R2 message upon c= ollision? Since we agreed that it is not an (IPsec) problem for the Responder, the = answer is "no". The text says that the Responder can send R2 but without = the locator of the data relay because the data relay would be confused=20 about the conflicting SPIs. > The draft also says this: > > =E2=80=9CThe described > collision scenario can be avoided if the Responder delivers a new > relayed address candidate upon SPI collisions. Each relayed addres= s > has a separate UDP port reserved to it, so the relay can demultiple= x > properly conflicting SPIs of the Initiators based on the SPI and po= rt > number towards the correct Responder.=E2=80=9D > > What if the Responder sends the R2 message (established state) and the= n immediately follows with an UPDATE packet to initiate a rekey? > The rekey would cause both sides to select new SPI values. Good catch, added: "The same applies also the handover procedure; the registered host MUST NOT include the relayed address candidate when sending its new locator set in an UPDATE to its peer if it would=20 cause a SPI conflict with another peer." > Not sure what happens if you send the R2 without the relayed address --= proper state not created on the Initiator? If NAT connectivity tests fail to set up a direct path, the indirect=20 path through the data relay will be unavailable =3D> no path for data tra= ffic. --------------ms080704040507050503000406 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 DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNzAxMTA0MDQ1 WjAvBgkqhkiG9w0BCQQxIgQgD50hrNg0dox0G+jf8I68/xXANxav9bAXd2a5tMqPyk0wXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCJwvfU0131 GsGi2kGDEYcLe4Dmr6GGOEo4ATG0L4gc8P1SQShX/xSAdvFuov0KM1hayZjPMIgawVA08yxN O2fCZUQoJFlZ8zVwoWM9p1rGm5h6d3BjRKP7VstM02pqlVRY9tjk1c32ZgdfgBc2x0VbKY6g Ym1mYmzuwD2AQXkRPIx2WoGc/I76WYoK7c9J4V73O7aHo2ZdvDsgd5QCYix5IvMwR3KAcpec QzHJgbADAtqSlK9JILXUA6eaDDasklkLw/6afn9MCXK/01xvdSxSVTDQXJdHMVNpbqkuSSoN Pm7F8IEpwZwKkST/VdCKvvr0LYw603q4PmJEVDFX25s+AAAAAAAA --------------ms080704040507050503000406-- From nobody Fri Jul 1 03:58:27 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3793B12D567 for ; Fri, 1 Jul 2016 03:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 1RAOkkFHBV_b for ; Fri, 1 Jul 2016 03:58:24 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E532112D548 for ; Fri, 1 Jul 2016 03:58:23 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-52-57764cce7011 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0C.44.18043.ECC46775; Fri, 1 Jul 2016 12:58:22 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.294.0; Fri, 1 Jul 2016 12:57:38 +0200 To: Jeff Ahrenholz , "hipsec@ietf.org" References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> <576BF266.4040703@ericsson.com> <5C1F7EB9-3B99-47E1-A929-B79E97F56F57@temperednetworks.com> <577543A1.9060507@ericsson.com> From: Miika Komu Organization: Ericsson AB Message-ID: <57764CA2.6050304@ericsson.com> Date: Fri, 1 Jul 2016 13:57:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030102030608090106050001" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2J7uO45n7Jwg88t/BZTF01mtmidcpPZ gcljyZKfTB5b93SyBDBFcdmkpOZklqUW6dslcGW0vDzPVrDKsuL5u+nsDYwvTbsYOTkkBEwk /t+4wgxhi0lcuLeeDcQWEjjCKHFhv3YXIxeQvYpRYu254ywgCWEBH4mbvx8xgtgiAjESF+et YYEoamSS6LqwkBUkwSagJbHqznWwqfwCkhIbGnaD2bwC2hK7b+4DG8QioCJxY107E4gtKhAh MWv7DyaIGkGJkzOfgNVwCnhIPPzzA+wiZoFuRol7f3m7GDmAlqlIXDwWPIFRYBaSjllIqiBs M4l5mx8yQ9jaEssWvoayrSVm/DrIBmErSkzpfsgOYZtKvD76kRHCNpZYtu4v2wJGjlWMosWp xcW56UZGeqlFmcnFxfl5enmpJZsYgfFwcMtvqx2MB587HmIU4GBU4uFdcK40XIg1say4MvcQ owrQnEcbVl9glGLJy89LVRLhnedRFi7Em5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpi SWp2ampBahFMlomDU6qBsdfl767362q+RezfLp33b5FJ+3FZkR2FD9QvfLLkLVrwm+Orh/FS RVmv1QV+31J0X7KcNUqJ+jmBX2raPsHZueeXRulYX3OdvWFdgbnZRN80K+UqE939/cc5D0px 7yp7IZAxbUG27vmHe3uXKxeYR6rc0zAyui2s9edJ0xZ548mZPp63pM5HK7EUZyQaajEXFScC AOHWF+GPAgAA Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 10:58:27 -0000 --------------ms030102030608090106050001 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jeff, On 06/30/2016 07:33 PM, Jeff Ahrenholz wrote: > On 6/30/16, 9:06 AM, "Miika Komu" wrote: >>> >>Seems like a good idea. No ESP_TRANSFORM -> no need to establish tw= o-way comms between peers. >>> >>For example, when performing a registration procedure with a relay = server. >> > >> >The direct path could be, of course, used for exchange HIP messages >> >directly (including hiccups v2). Does this make sense? > yes, makes sense > >> >If not, what should happen when both ESP_TRANSFORM and ICE-HIP-UDP ar= e >> >both negotiated? Or should we just be proactive and state that upon >> >receiving R1, the Initiator MUST NOT include ICE-HIP-UDP if it is not= >> >going to employ any ESP_TRANSFORM. > > This proposed sentence seems like a good revision. we need to choose between the two alternatives: 1. Either always set up the direct path with connectivity tests when ICE = mode negotiated 2. ...or set it up only when both ESP and ICE-HIP-UDP are present After this discussion, I would actually lean towards the first option=20 because this would make the two options independent. And even if you=20 don't use ESP, you would still get a direct path for hiccups v2. So actually no change to the draft :) What say you? --------------ms030102030608090106050001 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 DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNzAxMTA1NzM4 WjAvBgkqhkiG9w0BCQQxIgQgIqs4uFrGNSXwXRggc73PswZpLeG/k/z7vqMw/A9POhswXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAiHw08G6Db jPUyOSimoB9CFNHrLkZiATGH88zo3ljYQ7DBAf448KNfBKro9XgxCSDcIlTV2y+zJ5QYaYif kwGWjikD62mW0CMQmtdN+jUeMKMrbn+DFizv7XRLFWOErGDJvMmIfNd4WsLck2bLahKB1E09 g2aYV1+/9aGpHbhGHQEGzXd6B9crz+9Hh0nZSb+0Xx7vSfQDHyMErDhMcsSGNzWvH6QpHt6F lTFY9QXBaaQilK5usCbiVlYuq/ShSIxiut/9ijIQQSqmjLo3xPOoYAId6M0wntof+dl+a2WB lDrMO9pipTBHkhORxuLr2fKRnSeZlHENh3teC8ASGdsHAAAAAAAA --------------ms030102030608090106050001-- From nobody Fri Jul 1 06:37:47 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AAC12D1DC for ; Fri, 1 Jul 2016 06:37:46 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 gjrIR6gw0g9o for ; Fri, 1 Jul 2016 06:37:45 -0700 (PDT) Received: from out.west.exch081.serverdata.net (cas081-co-8.exch081.serverdata.net [199.193.204.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCC312D5C5 for ; Fri, 1 Jul 2016 06:30:21 -0700 (PDT) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-1 (10.224.129.84) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 1 Jul 2016 06:30:19 -0700 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1178.000; Fri, 1 Jul 2016 06:30:19 -0700 From: Jeff Ahrenholz To: Miika Komu , "hipsec@ietf.org" Thread-Topic: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt Thread-Index: AQHRzVleTAP7xruKpU6gf7y7RtV0i5/3khUAgAEr1QCACe+WgP//kggAgAGp4AD//7VPAA== Date: Fri, 1 Jul 2016 13:30:19 +0000 Message-ID: <12F20749-8306-4FAA-8CC9-D43A481F2BC1@temperednetworks.com> References: <20160623141232.31224.21763.idtracker@ietfa.amsl.com> <576BF266.4040703@ericsson.com> <5C1F7EB9-3B99-47E1-A929-B79E97F56F57@temperednetworks.com> <577543A1.9060507@ericsson.com> <57764CA2.6050304@ericsson.com> In-Reply-To: <57764CA2.6050304@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [73.97.2.49] Content-Type: text/plain; charset="utf-8" Content-ID: <74B9B600F2C4854C9932B1301357EB18@exch081.serverpod.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 13:37:46 -0000 T24gNy8xLzE2LCAzOjU3IEFNLCAiTWlpa2EgS29tdSIgPG1paWthLmtvbXVAZXJpY3Nzb24uY29t PiB3cm90ZToNCj4NCj4gd2UgbmVlZCB0byBjaG9vc2UgYmV0d2VlbiB0aGUgdHdvIGFsdGVybmF0 aXZlczoNCj4NCj4gMS4gRWl0aGVyIGFsd2F5cyBzZXQgdXAgdGhlIGRpcmVjdCBwYXRoIHdpdGgg Y29ubmVjdGl2aXR5IHRlc3RzIHdoZW4gSUNFIA0KPiBtb2RlIG5lZ290aWF0ZWQNCj4gMi4gLi4u b3Igc2V0IGl0IHVwIG9ubHkgd2hlbiBib3RoIEVTUCBhbmQgSUNFLUhJUC1VRFAgYXJlIHByZXNl bnQNCj4NCj4gQWZ0ZXIgdGhpcyBkaXNjdXNzaW9uLCBJIHdvdWxkIGFjdHVhbGx5IGxlYW4gdG93 YXJkcyB0aGUgZmlyc3Qgb3B0aW9uIA0KPiBiZWNhdXNlIHRoaXMgd291bGQgbWFrZSB0aGUgdHdv IG9wdGlvbnMgaW5kZXBlbmRlbnQuIEFuZCBldmVuIGlmIHlvdSANCj4gZG9uJ3QgdXNlIEVTUCwg eW91IHdvdWxkIHN0aWxsIGdldCBhIGRpcmVjdCBwYXRoIGZvciBoaWNjdXBzIHYyLg0KPg0KPiBT byBhY3R1YWxseSBubyBjaGFuZ2UgdG8gdGhlIGRyYWZ0IDopIFdoYXQgc2F5IHlvdT8NCg0KT0ss IGl0IHNvdW5kcyBnb29kIHRvIHVzZSB0aGUgZmlyc3Qgb3B0aW9uIQ0KDQotSmVmZg0KDQo= From nobody Fri Jul 1 07:48:43 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2485F12D671 for ; Fri, 1 Jul 2016 07:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 IOsxGP_PJn6g for ; Fri, 1 Jul 2016 07:48:38 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBE112B00A for ; Fri, 1 Jul 2016 07:48:34 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-11-577682c00d23 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B0.E0.12516.0C286775; Fri, 1 Jul 2016 16:48:32 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.294.0; Fri, 1 Jul 2016 16:48:21 +0200 To: References: From: Miika Komu Organization: Ericsson AB Message-ID: <577682B5.7090008@ericsson.com> Date: Fri, 1 Jul 2016 17:48:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070209040406000308080105" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7nO6BprJwg7/7tC2mLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPX9TcwFvxwrmld+ZGtgvGHTxcjJISFgIrHg8gcWCFtM4sK9 9WxdjFwcQgJHGCWunj/CAuGsYpTYeOo+WJWwgL3EyX232EFsEQFRiSkfTjN3MXIAFXlKTHzn CBJmE9CSWHXnOjOIzS8gKbGhYTeYzSugLbHkRz8biM0ioCLReOILmC0qECExa/sPJogaQYmT M5+AreIU8JKY2/mcFcRmFuhmlNj8rg5ilYrExWPBExgFZiHpmIWkCsK2lbgzdzczhK0tsWzh ayjbWmLGr4NsELaixJTuh+wQtqnE66MfGSFsY4ll6/6yLWDkWMUoWpxaXJybbmSsl1qUmVxc nJ+nl5dasokRGPgHt/zW3cG4+rXjIUYBDkYlHt4F50rDhVgTy4orcw8xqgDNebRh9QVGKZa8 /LxUJRFe9caycCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTByc Ug2MvbOW7zr/yDm9Ojz8R77g8q/qjh9dnlVye7yYwhIX9P1cm8/yjpu2i3/yHmN9Unr3pazS sovrL/6JqA4wq7CqEXe+Etww6WzrtGcCcnk/nz5+vefwuUfKie1M1qod20+kxtVufHjKSe/F Lplw5tCpNuecXTNf3VDUf7v7/6o1B5gjpzv5X1F4pcRSnJFoqMVcVJwIAEC0T8WEAgAA Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 14:48:40 -0000 --------------ms070209040406000308080105 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On 06/30/2016 08:44 AM, Tom Henderson wrote: > Hi Miika, > >> >> trying to recap your complete opinion... do you think the >> UDP-ENCAPSULATION should be MUST and ICE-HIP-UDP SHOULD? And >> RFC5770 MAY? Or do you think the draft should just deprecate >> RFC5770? > > I think that UDP-ENCAPSULATION should be a MUST option because that > option is sufficient if the implementation does not have to deal with > inbound connections. Ok. Btw, you mean "Responder" by inbound? I think you're referring to=20 this section: https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-12#sectio= n-4.7.2 > ICE-HIP-UDP should be a MUST for implementations that wish to support > inbound, and I don't think that RFC5770 solutions for inbound should > be suggested as options. Added the following to the NAT Traversal Mode Parameter" section: "Implementations conforming to this specification MUST implement both UDP-ENCAPSULATION and ICE-HIP-UDP modes." > Maybe the use of STUN servers for candidate > gathering is fine as a MAY since it doesn't affect HIP > interoperability, but otherwise, why suggest to support two parallel > implementations for the same function? A host behind a NAT will need a HIP relay anyway which can provide STUN=20 functionality. The draft currently says: Gathering of candidates MAY also be performed as specified in Section 4.2 of [RFC5770] if STUN servers are available, or if the host has just a single interface and no TURN or HIP data relay servers are available. Do you want this to be removed or is it ok? > I would be fine with making an allowance for RFC5770 implementations > to live on as an option; by this I mean to not overwrite RFC5770 > codepoints, etc. but stop short of suggesting it as a MAY in this > document. The draft does not reference RFC5770 as MAY implement. The current draft = is completely a parallel to the RFC, and is described in a=20 self-sufficient way. >> Btw, RFC5770 is still a normative reference because we are >> redundantly explaining some parts of the RFC in the draft. >> > > I still believe that it would be better if this draft did not depend > on reading RFC5770. It doesn't anymore. RFC5770 is mostly referenced because some parameters = are borrowed from there, but are always redundantly described in the draf= t. --------------ms070209040406000308080105 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 DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNzAxMTQ0ODIx WjAvBgkqhkiG9w0BCQQxIgQgyU8olwJt0XPfzoVV0tfwuHj8g4HuMkNgL2u22rAREsIwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAZGmlW6fvZ pNzyZO0r9xD6S4I/E7PLvq8l/BaBOEXvX2CXoD2d2zhONMqmmlf2VWFzzx0u8LCstUFkBKiK 8X5PkH5xG+ED4Tl9TdtEh06JU9PVhieyEGTFGttHac9SUVw0xVYStUKTiYplwNOn8qNCs/kU nVq5V+hFNAw7H2lAHnKLvl9IAR5iXL5l5Nz5H8vL8iultLhM1Exima4sgVbTBILK9UH0VMR5 dmK9Cj2CZq0nAbIl9UlA0V9tIoYkF+TRjW9Y8WloCMtslQL6Sr/oDFXHiWTy7ZiCIpCOGvf9 mt8+l4q6HtlqhAfaluDISEiYjvQPq+XGr1CXsOcYDhpKAAAAAAAA --------------ms070209040406000308080105-- From nobody Fri Jul 1 08:17:57 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B88B612D169; Fri, 1 Jul 2016 08:17:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160701151756.24682.55259.idtracker@ietfa.amsl.com> Date: Fri, 01 Jul 2016 08:17:56 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-13.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:17:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Native NAT Traversal Mode for the Host Identity Protocol Authors : Ari Keranen Jan Melén Miika Komu Filename : draft-ietf-hip-native-nat-traversal-13.txt Pages : 44 Date : 2016-07-01 Abstract: This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-13 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 1 08:22:08 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D1012D6B8 for ; Fri, 1 Jul 2016 08:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 bnl6-G6SAUoU for ; Fri, 1 Jul 2016 08:21:57 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6466B12D6B9 for ; Fri, 1 Jul 2016 08:21:56 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-8d-57768a922832 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4E.93.18043.29A86775; Fri, 1 Jul 2016 17:21:54 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.294.0; Fri, 1 Jul 2016 17:21:52 +0200 To: , Tom Henderson , Jeff Ahrenholz References: <20160701151756.24682.55259.idtracker@ietfa.amsl.com> From: Miika Komu Organization: Ericsson AB Message-ID: <57768A91.5030806@ericsson.com> Date: Fri, 1 Jul 2016 18:21:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160701151756.24682.55259.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030204080004030809030502" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbE9XHdSV1m4wbHL8hZTF01mtmidcpPZ Yub5g2wOzB5Llvxk8ti6p5PFo+V6TABzFJdNSmpOZllqkb5dAlfGnQPPGAse21V09B5nbGA8 b9nFyMkhIWAiMWfxckYIW0ziwr31bF2MXBxCAkcYJX4vvscI4axilHi44TczSJWwgI/EuX+X 2EFsEYESiQXnlrKA2EICjhJfnj4Fi7MJaEmsunMdrJ5fQFJiQ8NuMJtXQFvibus+sBoWARWJ zW82MYHYogIRErO2/2CCqBGUODnzCdhMTgEnieUf1oAdwSzQzSgxY8E9oAQH0DIViYvHgicw CsxC0jILWRlIglnATGLe5ofMELa2xLKFr6Fsa4kZvw6yQdiKElO6H7JD2KYSr49+ZISwjSWW rfvLtoCRYxWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYJQc3PLbagfjweeOhxgFOBiVeHgX nCsNF2JNLCuuzD3EqAI059GG1RcYpVjy8vNSlUR4r7eWhQvxpiRWVqUW5ccXleakFh9ilOZg URLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpgLD/8vzm3dHcTW9cxibccnxebBH/5dP/JOkn5 SBcz+y/e2uELneNPxR/+MJNLp3gJP5tu7LuXHax39sn5687K/p16R8Pw79TFj3bOOCH3aHep tsTXi2YJi7n3flu16ZT5jO+Gt2aLHcsUVyne53p1sUd8o8XWEzwTxL6x328NEGloOJYz/5ZB uhJLcUaioRZzUXEiAER8L9+aAgAA Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-13.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:21:59 -0000 --------------ms030204080004030809030502 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, this new version addresses the discussion items based on Tom's and=20 Jeff's feedback. IETF cut off is in one week, so we can still update the = draft before that if needed. On 07/01/2016 06:17 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Host Identity Protocol of the IETF. > > Title : Native NAT Traversal Mode for the Host Ident= ity Protocol > Authors : Ari Keranen > Jan Mel=C3=A9n > Miika Komu > Filename : draft-ietf-hip-native-nat-traversal-13.txt > Pages : 44 > Date : 2016-07-01 > > Abstract: > This document specifies a new Network Address Translator (NAT) > traversal mode for the Host Identity Protocol (HIP). The new mode = is > based on the Interactive Connectivity Establishment (ICE) methodolo= gy > and UDP encapsulation of data and signaling traffic. The main > difference from the previously specified modes is the use of HIP > messages for all NAT traversal procedures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-native-nat-traversal= -13 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > --------------ms030204080004030809030502 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 DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNzAxMTUyMTUz WjAvBgkqhkiG9w0BCQQxIgQga+V8YPXg5v2GlJ5hIQsUpKpr38rdMs+Cs2Xw4fBvkSUwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBa7ZOITe2o OE7XqPxoB31ZXUI+8u5m/u5EPPQH4QZnoo5vxJEcb4NCkEvdtSLqOyujaVg9nozN2Q8xqoUV o9rXOIcElufz5P2oplmHHoJaJzNDKO+rmMV0VNSLVOOlvHRy2ikGhYnAlV4ip8P2mk2hxO1/ U8BpefHbKq/ml2RhlEMUiF7XVzvWR3+MIGFGSDnILtDsTO/Oko6dga5QJSPNpwAS+Near0K5 1QPJZ8AcQxusRFEeQaS55QCOmgvGmAMied4BiPMEfeCb1f+U23/N1F9D0KcRthh6MwWXS6fg btzSXUF9Om5Eq0gnYqxGiAD6TcT8GUrP9sjpTolr36NdAAAAAAAA --------------ms030204080004030809030502-- From nobody Sat Jul 2 03:21:40 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAEA12D11E; Sat, 2 Jul 2016 03:21:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160702102134.14878.57766.idtracker@ietfa.amsl.com> Date: Sat, 02 Jul 2016 03:21:34 -0700 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, hipsec@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc5203-bis-10: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 10:21:34 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-hip-rfc5203-bis-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- -bis documents require "changes since" section. I don't believe IANA Considerations section is correct: it points to a document that gets obsoleted by this one, yet the original document creates new subregistries. This makes the status of earlier established registries unclear. Also, other sections have references to Section 7 (e.g. for registration types) which no longer contain relevant information. I think you should copy the original IANA registration section in its entirety and clearly mark new allocations in it. From nobody Sat Jul 2 03:31:55 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFA812D121; Sat, 2 Jul 2016 03:31:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160702103153.14866.7276.idtracker@ietfa.amsl.com> Date: Sat, 02 Jul 2016 03:31:53 -0700 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, hipsec@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc5203-bis-10: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 10:31:54 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-hip-rfc5203-bis-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I don't believe IANA Considerations section is correct: it points to a document that gets obsoleted by this one, yet the original document creates new subregistries. This makes the status of earlier established registries unclear. Also, other sections have references to Section 7 (e.g. for registration types) which no longer contain relevant information. I think you should copy the original IANA registration section in its entirety and clearly mark new allocations in it. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I found the "changed since" Appendix, so never mind that ;-) It would be good if the document said that a registration type is 1 octet without the need to look at the packet diagrams or IANA registration text from RFC 5203 that you deleted. From nobody Sat Jul 2 03:58:14 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1782C12B018; Sat, 2 Jul 2016 03:58:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160702105813.14802.25495.idtracker@ietfa.amsl.com> Date: Sat, 02 Jul 2016 03:58:13 -0700 Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-rfc6253-bis@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc6253-bis-08: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 10:58:13 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-hip-rfc6253-bis-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I don't believe IANA Considerations section is correct: it points to a document that gets obsoleted by this one, yet the original document creates new subregistries. This makes the status of earlier established registries unclear. I think you should copy the original IANA registration section in its entirety and clearly mark new allocations in it. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Subject DN doesn't necessarily identify a single certificate. But I am not sure whether this is a problem for HIP. From nobody Mon Jul 4 18:08:50 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 981A612B024; Mon, 4 Jul 2016 18:08:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160705010848.2630.57374.idtracker@ietfa.amsl.com> Date: Mon, 04 Jul 2016 18:08:48 -0700 Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-rfc6253-bis@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Kathleen Moriarty's No Objection on draft-ietf-hip-rfc6253-bis-08: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 01:08:48 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-hip-rfc6253-bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Why is MAY used int he error handling and not MUST or listing these actions as RECOMMENDED? Thanks for addressing the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg06366.html From nobody Tue Jul 5 07:01:48 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E591512D592; Tue, 5 Jul 2016 07:01:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160705140143.22339.24069.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2016 07:01:43 -0700 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, hipsec@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Stephen Farrell's Discuss on draft-ietf-hip-rfc5203-bis-10: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 14:01:44 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-hip-rfc5203-bis-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 3.3 - This fails to distinguish between an invalid certificate (e.g. bad signature, unknown signer) and one that is valid, but is not acceptable for this purpose. I don't get why that is ok for HIP, can you explain? If it is ok, I think you need to say so. If it is not ok (as I'd suspect) then you appear to need to change text or one more new error code. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 7 - I'm fine that this doesn't repeat stuff from 5203, but a sentence saying to go look there too would maybe be good. (I'm not sure if that would fix Alexey's discuss or not. If not, then ignore me and just talk to him about his discuss.) From nobody Tue Jul 5 18:13:34 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B67212B028; Tue, 5 Jul 2016 18:13:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706011332.22267.32619.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2016 18:13:32 -0700 Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-rfc6253-bis@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Ben Campbell's No Objection on draft-ietf-hip-rfc6253-bis-08: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 01:13:32 -0000 Ben Campbell has entered the following ballot position for draft-ietf-hip-rfc6253-bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alexey's discuss comment that the IANA considerations from the obsoleted RFC need to be pulled forward to this one. In my opinion, if the RFC is obsoleted, one should no longer need to read it. From nobody Tue Jul 5 18:25:17 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B132812B025; Tue, 5 Jul 2016 18:25:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706012512.22287.3244.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2016 18:25:12 -0700 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, hipsec@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Ben Campbell's No Objection on draft-ietf-hip-rfc5203-bis-10: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 01:25:13 -0000 Ben Campbell has entered the following ballot position for draft-ietf-hip-rfc5203-bis-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alexey's discuss comment. From nobody Tue Jul 5 18:33:08 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C3012B025; Tue, 5 Jul 2016 18:33:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706013307.22358.99313.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2016 18:33:07 -0700 Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, draft-ietf-hip-rfc5204-bis@ietf.org Subject: [Hipsec] Ben Campbell's No Objection on draft-ietf-hip-rfc5204-bis-07: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 01:33:07 -0000 Ben Campbell has entered the following ballot position for draft-ietf-hip-rfc5204-bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5204-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The IANA considerations section does not seem to stand alone without reading RFC 5204. In my opinion, this draft should replicate the appropriate information, so that one does not need to read the obsoleted RFC to fully understand the IANA considerations. From nobody Tue Jul 5 18:37:07 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D5D12B016; Tue, 5 Jul 2016 18:37:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706013706.22302.59656.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2016 18:37:06 -0700 Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-rfc5205-bis@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Ben Campbell's No Objection on draft-ietf-hip-rfc5205-bis-09: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 01:37:06 -0000 Ben Campbell has entered the following ballot position for draft-ietf-hip-rfc5205-bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please replicate the appropriate info from the RFC 5205 IANA considerations. The similar section in this draft does not seem to stand alone. Readers should not need to refer back to the obsoleted RFC to understand this version. From nobody Wed Jul 6 00:10:09 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDDD12D68F; Wed, 6 Jul 2016 00:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=fastmail.fm header.b=P62+Sscr; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ZgAx1qJy 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 LejNtgxOfkRc; Wed, 6 Jul 2016 00:10:05 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D7E12D67E; Wed, 6 Jul 2016 00:10:05 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C3E5E20233; Wed, 6 Jul 2016 03:10:04 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 06 Jul 2016 03:10:04 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=MnHm9VKaRHGpfGcafnoKyuFl50s=; b=P62+Ss cr16AOwp0ghoIT8N3xqludepZv2U5IeRwmUPYIc0Rv/XG5YQYPN5QgrDzYt+1T9N t1VjzXXiv3CP3IuBlH8spq7dQjpuOWYLUa9/qEYy6crPz3bZB63qYZ3btyJx7cv6 ssnNi+nrr7JYLfGvUUluSIMazchN2ILOlNvCE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=MnHm9VKaRHGpfGc afnoKyuFl50s=; b=ZgAx1qJyGtyQeeFqXgCrEX1qU9/misIoJHnRUkVov4I4PHm DWeAsiboQv2sqLERUoDLgDpMzk60iIIbqqtTi56J9p0tSW5ky0u1vo/Xmgk0Ikr7 YySJOGxbu1YOfgh+2cNxCFm03bqCLZzTcGNwXWI3nxK0T4bgmaCwfVDBat+A= X-Sasl-enc: 3aYgO5/DfZUJYRXGGfCHgcTBsaFMB88cOgxVDzMVWGSf 1467789003 Received: from [10.6.96.199] (unknown [85.255.235.121]) by mail.messagingengine.com (Postfix) with ESMTPA id 9BF59CCDB2; Wed, 6 Jul 2016 03:10:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13F69) In-Reply-To: <20160706011332.22267.32619.idtracker@ietfa.amsl.com> Date: Wed, 6 Jul 2016 08:18:59 +0100 Content-Transfer-Encoding: 7bit Message-Id: <571D68AB-C327-4ABE-9B40-D6BDBC75E669@fastmail.fm> References: <20160706011332.22267.32619.idtracker@ietfa.amsl.com> To: draft-ietf-hip-rfc6253-bis@ietf.org Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Ben Campbell's No Objection on draft-ietf-hip-rfc6253-bis-08: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 07:10:07 -0000 > On 6 Jul 2016, at 02:13, Ben Campbell wrote: > > I agree with Alexey's discuss comment that the IANA considerations from > the obsoleted RFC need to be pulled forward to this one. In my opinion, > if the RFC is obsoleted, one should no longer need to read it. The last sentence is exactly what I was trying to convey. From nobody Wed Jul 6 03:56:38 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A21A12D1A5; Wed, 6 Jul 2016 03:56:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706105636.7910.18254.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2016 03:56:36 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-09.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 10:56:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Host Identity Protocol Certificates Authors : Tobias Heer Samu Varjonen Filename : draft-ietf-hip-rfc6253-bis-09.txt Pages : 12 Date : 2016-07-06 Abstract: The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3). The concrete use cases of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter. This document updates RFC7401 and obsoletes RFC6253. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc6253-bis-09 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 6 04:00:15 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F59F12D18A; Wed, 6 Jul 2016 04:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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=-1.426, SPF_HELO_PASS=-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.helsinki.fi 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 kIh9vTxCtOL3; Wed, 6 Jul 2016 04:00:05 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A4912D0CC; Wed, 6 Jul 2016 04:00:05 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2016-01-27 mail.cs.helsinki.fi Wed, 06 Jul 2016 14:00:00 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= dkim20130528; bh=Nzd4GfpSZQowAhNalleyRNp7Fpq5TjlHB2L3zepKOEg=; b= DWr/TIFqwuJL19IRYadmxAhp7LerouKrjyAiSDu6BXiB+B0KP5OSb0rCjGviSfdj lhQHrH+uIa829fPHDxSRhaXvrl1i+RM+9TSXi7fMuFOZLAQAm3PSYs0Qr5p4duoZ r6zLTcBH0tNiSnmfI3k0Jc6SreEP+mpSlw0jhEUw1Vc= Received: from [128.214.10.115] (hpf-7.cs.helsinki.fi [128.214.10.115]) (AUTH: PLAIN sklvarjo, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by mail.cs.helsinki.fi with ESMTPSA; Wed, 06 Jul 2016 14:00:00 +0300 id 00000000005A0027.00000000577CE4B0.00002E78 To: Alexey Melnikov , The IESG References: <20160702105813.14802.25495.idtracker@ietfa.amsl.com> From: Varjonen Samu Message-ID: <577CE4AF.6070003@cs.helsinki.fi> Date: Wed, 6 Jul 2016 13:59:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160702105813.14802.25495.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, draft-ietf-hip-rfc6253-bis@ietf.org Subject: Re: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc6253-bis-08: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 11:00:08 -0000 Hi, bis-09 has a new IANA considerations section that is based on the old one and clearly marks the changes to be made to the registry. I agree that the DN problem is not a HIP problem. -Samu On 02/07/16 13:58, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-hip-rfc6253-bis-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I don't believe IANA Considerations section is correct: it points to a > document that gets obsoleted by this one, yet the original document > creates new subregistries. This makes the status of earlier established > registries unclear. > I think you should copy the original IANA registration section in its > entirety and clearly mark new allocations in it. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Subject DN doesn't necessarily identify a single certificate. But I am > not sure whether this is a problem for HIP. > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From nobody Wed Jul 6 04:00:54 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278CD12D18A; Wed, 6 Jul 2016 04:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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=-1.426, SPF_HELO_PASS=-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.helsinki.fi 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 f7gM8iadA_3J; Wed, 6 Jul 2016 04:00:51 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6418F12D0CC; Wed, 6 Jul 2016 04:00:51 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2016-01-27 mail.cs.helsinki.fi Wed, 06 Jul 2016 14:00:46 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= dkim20130528; bh=wGcZQJQ1q+69vabFHoRiAGvy9cnhlYmQe4Xz5f/SlSo=; b= aBBWuYtLuLlPI40+gDj7h7Pmu/6BiM9UZm4mH0ghvWaAnrqO2gm3TRSYs7TWtG2P 30hKQDD9ES6jrxhb/0iUJcOumi4Tj3VLd2OkVPt/Argsu/7yRtnE3pCjQ7e1po3u S6GX7ound+06gtXa67n3lHBNrW8clK0lqymW2ksGF7k= Received: from [128.214.10.115] (hpf-7.cs.helsinki.fi [128.214.10.115]) (AUTH: PLAIN sklvarjo, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by mail.cs.helsinki.fi with ESMTPSA; Wed, 06 Jul 2016 14:00:46 +0300 id 00000000005A0027.00000000577CE4DE.000035D6 To: Ben Campbell , The IESG References: <20160706011332.22267.32619.idtracker@ietfa.amsl.com> From: Varjonen Samu Message-ID: <577CE4DE.6000300@cs.helsinki.fi> Date: Wed, 6 Jul 2016 14:00:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160706011332.22267.32619.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, draft-ietf-hip-rfc6253-bis@ietf.org Subject: Re: [Hipsec] Ben Campbell's No Objection on draft-ietf-hip-rfc6253-bis-08: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 11:00:53 -0000 HI, bis-09 has a new IANA considerations section that is based on the old one and clearly marks the changes to be made to the registry. -Samu On 06/07/16 04:13, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-hip-rfc6253-bis-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Alexey's discuss comment that the IANA considerations from > the obsoleted RFC need to be pulled forward to this one. In my opinion, > if the RFC is obsoleted, one should no longer need to read it. > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From nobody Wed Jul 6 07:22:18 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8303612D57B; Wed, 6 Jul 2016 07:22:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706142213.7773.71894.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2016 07:22:13 -0700 Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-rfc5205-bis@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc5205-bis-09: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 14:22:14 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-hip-rfc5205-bis-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is the same as Ben's DISCUSS point, but I think this is important enough to fix: Please replicate the appropriate info from the RFC 5205 IANA considerations. The similar section in this draft does not seem to stand alone. Readers should not need to refer back to the obsoleted RFC to understand this version. RFC 4648 actually has 2 base64 encodings, so you should say which section number you mean (section 4 or section 5). I suspect you meant section 5. From nobody Wed Jul 6 07:32:07 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D804D12D78F; Wed, 6 Jul 2016 07:32:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706143205.7888.47534.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2016 07:32:05 -0700 Archived-At: Cc: hipsec@ietf.org, draft-ietf-hip-rfc5205-bis@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Stephen Farrell's No Objection on draft-ietf-hip-rfc5205-bis-09: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 14:32:06 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-hip-rfc5205-bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- intro, nit: the RR is no longer "new" I guess. From nobody Wed Jul 6 11:31:37 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A0712B035; Wed, 6 Jul 2016 11:31:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706183132.26740.62538.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2016 11:31:32 -0700 Archived-At: Cc: hipsec@ietf.org, hip-chairs@ietf.org, draft-ietf-hip-rfc5204-bis@ietf.org Subject: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc5204-bis-07: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 18:31:32 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-hip-rfc5204-bis-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5204-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The IANA considerations section does not seem to stand alone without reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't be expected to read it in order to discover original IANA instructions. I think you should copy information from RFC 5204. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 6: This section is to be interpreted according to the Guidelines for Writing an IANA Considerations Section in RFCs [RFC5226]. This sentence is not needed, because RFC 5204 didn't define any registries, so none of the text from RFC 5226 applies. I suggest you delete this sentence. From nobody Wed Jul 6 14:08:30 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D6112B04E; Wed, 6 Jul 2016 14:08:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706210829.26812.48474.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2016 14:08:29 -0700 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, hipsec@ietf.org, hip-chairs@ietf.org Subject: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-rfc5203-bis-10: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 21:08:29 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-hip-rfc5203-bis-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This bis draft was an improvement. I did have one question. I'm trying to visualize why The registrar indicates the minimum and maximum registration lifetime that it is willing to offer to a requester. A requester SHOULD NOT request registration with lifetime greater than the maximum registration lifetime or smaller than the minimum registration lifetime. is a SHOULD NOT - why would a requester choose to disregard the SHOULD and send a request registration with (for example) a lifetime greater than the maximum registration lifetime? Is the intention for the requester to allow this, and then (for example) cap the lifetime at the maximum registration lifetime? Or is something else supposed to happen? Whatever the intention is, it might be helpful to provide an explanation about that. From nobody Thu Jul 7 03:51:50 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2570512D10B; Thu, 7 Jul 2016 03:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 cgT8O3hPMjui; Thu, 7 Jul 2016 03:51:35 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 4751212D674; Thu, 7 Jul 2016 03:51:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 87BF42CC9A; Thu, 7 Jul 2016 13:51:32 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw8ab8A7NGMe; Thu, 7 Jul 2016 13:51:32 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 29D982CC45; Thu, 7 Jul 2016 13:51:32 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FF921585-D580-45F8-AC00-16DFF207FDE4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: Date: Thu, 7 Jul 2016 13:51:30 +0300 Message-Id: References: <567055B1.1080806@nostrum.com> <5671AEF1.5000109@joelhalpern.com> To: Julien Laganier , "Joel M. Halpern" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: HIP , General Area Review Team Subject: Re: [Hipsec] [Gen-art] Review: draft-ietf-hip-rfc5204-bis-06 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 10:51:39 -0000 --Apple-Mail=_FF921585-D580-45F8-AC00-16DFF207FDE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Returning to this topic after a long time, as the document is on = tonight=92s IESG telechat agenda. Thanks for the review, Joel. And thanks Julien for reacting to the = comments. I see that -07 includes the discussed changes. Jari --Apple-Mail=_FF921585-D580-45F8-AC00-16DFF207FDE4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXfjQyAAoJEM80gCTQU46qL4cP+wf31pJZwrCLOkLzF0Ci55B0 NZLieqKnA9bXsiW/asH3bSrIV3fms1f31JjQxP7wKw5B7Xr47Qa4cJG751Lb9kSR +eY0MhlSvdzQchAelsi4ZG5DKs6DHocH+apiC55MKFXBIFRiuIuTZjNshmJ02FMz KIt7XIvXM3MPAkerTTim5qt3xce8UdIEg6BlZiGwh9PAvBNuCBnrTR6PpfUOWR0g cX5Ac9vSc0pHTXvkgk1ZdjTPl1VTMhFTNAS0GsBzhlTucG/91KAjbEj9kea/ju6A 6O8MD7JdkQ1bCuEVpcSQKuIm4efc+xd5UI9xSEuPZq+vFUnGiD6pKYe+cwe9xswd 6mKInGGLjBE5BdDabYygfTEpFitZ9kJVAcCQ6Yltg1+nAdBXXiiVAQXSdGEpXYII AdHQT/X2sYG1C5+IbLRKTZ0YT43DXuqnk44HNeFJQQhhS08KP9FdiQLJyxhBESEQ WJTgmg77ACdQLA22+XKnadSQNQzMerPHHoKYSwrMN1zywL06FxYXtmutwnUN3d84 PyKx7Ik2TAn/z0yv4o3W5/QWRT0B9lCtyWc8NK8Cz+UDLT2LNBp/MYkrFJBU96Wp u0x7wo0bnI+QM+NU9HXerK1vXwmNNpi6fDzB+7Dww/5Aa6icHVb9KLtZHXR/K62O kLLO06xAwTKq5Do+9/yA =0ljq -----END PGP SIGNATURE----- --Apple-Mail=_FF921585-D580-45F8-AC00-16DFF207FDE4-- From nobody Fri Jul 8 07:18:04 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24D612B00F; Fri, 8 Jul 2016 07:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 I7AElGG6KBFv; Fri, 8 Jul 2016 07:17:54 -0700 (PDT) Received: from mail-ob0-x243.google.com (mail-ob0-x243.google.com [IPv6:2607:f8b0:4003:c01::243]) (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 0AFC712B077; Fri, 8 Jul 2016 07:17:51 -0700 (PDT) Received: by mail-ob0-x243.google.com with SMTP id jg10so2068781obb.0; Fri, 08 Jul 2016 07:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a+M8USoNRkI9uLerew/99GKkIPbQlTx+5ppv2yVOKSU=; b=X6IMlOSgKNTIbNCB9Zulby3ceMr+zszmWa8h4bZMyaFe5XrwX0159EwMCXMwQJpD9F qDJNSgxIzee7liUdMqbBrzirbVgg9FcfPeM6b91L2RcEBd22phEEe1GwOk5YkMQ9qJUA 7BHbczdHO4FiK0xAWuUzg49TOlEnpZkWFNC3GqYFr66dDjdtjnUeH3xEpRfFGs5kMi3S /2Zx2jl7KTuw13IB63hNzyYV0Vdeh6Pf8fvdD53OfS597eJD2goK7DEFlSXVOZtAAt9D 98YzoaKNiC6rEnx6pKg/FCyj4CyUfVvKCCI9jC2O9zVMQ+vLe47uImVZHXMB0kHHXjpt B6/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a+M8USoNRkI9uLerew/99GKkIPbQlTx+5ppv2yVOKSU=; b=VAr372qTzcigqGxpsmnMHXuoKcPHbI6JqQzcfvGr+Wn0R4SqYtsZB0TMbD8FWcJvVA 5KA6exI2HzIGeZ+daTJjAglXSwHbpech9j4RLK2/+UJ5AWVJBvZiBRwFqNxQq2DDXKNm Yl5vQW9WCPHja4KdY7keVpGmQZXvGy5vE9lkUKRbvqT1ygNU5ofpVmsRsgEWyA0M95Gx kQnT15zv4MH+fg9t4RmAUdWcAOhGna1Wg2xaV5MxOqujEJJ5+Hu3fQk6Dhft5TjvRfyZ fXr7ZFJH6q5mn1Dvl8pvkEHs4IfZqBPex6JjrxTJUOUlONVFeJjqISIigQocS9fAED4D VFZw== X-Gm-Message-State: ALyK8tLQEJ5mw4l9xfb9sHAP5CBI/apDlieAbdqbE9xxS/jOKeK2yJ+cmUXTeJpBUhwwwR8dGSXByIL2at9DWw== X-Received: by 10.157.7.17 with SMTP id 17mr3252973ote.168.1467987470314; Fri, 08 Jul 2016 07:17:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.164 with HTTP; Fri, 8 Jul 2016 07:17:49 -0700 (PDT) In-Reply-To: <20160706183132.26740.62538.idtracker@ietfa.amsl.com> References: <20160706183132.26740.62538.idtracker@ietfa.amsl.com> From: Julien Laganier Date: Fri, 8 Jul 2016 07:17:49 -0700 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: HIP , hip-chairs@ietf.org, The IESG , draft-ietf-hip-rfc5204-bis@ietf.org Subject: Re: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc5204-bis-07: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:17:57 -0000 Hi Alexey, The IANA Considerations used to be a copy of RFC 5204 but someone asked that it be cleaned up. I will copy it back in the next revision. Thanks. --julien On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-hip-rfc5204-bis-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5204-bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The IANA considerations section does not seem to stand alone without > reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't be > expected to read it in order to discover original IANA instructions. > I think you should copy information from RFC 5204. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In Section 6: > > This section is to be interpreted according to the Guidelines for > Writing an IANA Considerations Section in RFCs [RFC5226]. > > This sentence is not needed, because RFC 5204 didn't define any > registries, so none of the text from RFC 5226 applies. I suggest you > delete this sentence. > > From nobody Fri Jul 8 07:23:19 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB4C12D736; Fri, 8 Jul 2016 07:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 Ycm7PCst3LZR; Fri, 8 Jul 2016 07:23:17 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 A1E8812D098; Fri, 8 Jul 2016 07:23:13 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id s17so10410368oih.1; Fri, 08 Jul 2016 07:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hR6pvkebm67nWrUFkBvl6b+arkE0kGcmtDMH4aqrlfc=; b=o2Pqs3F8+maN0rS47e9BygISGYWeaNoBgS8soqk/0CRfinmy04REp54CquQ4jfqnCx C4lrF217hMmjmNQ12/BxH749Gkhk0GdDSXC3v7dP/g5ReYmzfp2VQWeMFYIf+Ft+9B9t r7N0VUJ8N38brou7cGVpKo0KyV0HhJlYd2gfnoRG8/RCuF07b8K4OOaW02h6IaMANj7d 7nHIG8oo7dJSHOACgF2L9UgD2dUjo4V1CiaRkCLUbMoxF4cxtv3R0PqvZXh47xHL8Z0f OLXe/vf3Je9aU8VepnISjOfGg46AZWXumLiTRbLBxJ9W3ObSPf97d5vmf9hB2eeHtElj yLKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hR6pvkebm67nWrUFkBvl6b+arkE0kGcmtDMH4aqrlfc=; b=XJU5aSTM1jjTzhgAdxYg3fWLMcjKRda2b0wM050lre7+fafko7RhhMu3XkIF4kavd7 k5C+x7NbUZw2C17YkpBIVol8s9NzvsdkVRECoUw1kuCBOfU4WvUZEn4AzmezasZNnVXU wuwzSKSSad9HQ4ODMV02X32aLPta3RC7HnbCwSWAhUjrEL9VTCWMP08FRfB9OTQMjrWt 0WMLVdN/OF8oxtrOO/qyneAEMBL8OdVDC5N48OgyMwwOilYaNJtdwvVRfzIYDnkXIjBI DMneQgmMVnDJ4OaxEMZZzYCkpTEP3BR0b98nVlHFKtlZaETYc4soZ3bW/pNWV6TuO0l2 55/g== X-Gm-Message-State: ALyK8tKPhCTl28v9wElRE4bMdE2K9HOmhd/9ejx6btYnKMeHPHDewnQaqq7poHTyNyMhvxqxm6SB+wOwosyGnw== X-Received: by 10.202.96.137 with SMTP id u131mr3088253oib.71.1467987792866; Fri, 08 Jul 2016 07:23:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.164 with HTTP; Fri, 8 Jul 2016 07:23:12 -0700 (PDT) In-Reply-To: <20160706142213.7773.71894.idtracker@ietfa.amsl.com> References: <20160706142213.7773.71894.idtracker@ietfa.amsl.com> From: Julien Laganier Date: Fri, 8 Jul 2016 07:23:12 -0700 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: HIP , draft-ietf-hip-rfc5205-bis@ietf.org, hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Alexey Melnikov's Discuss on draft-ietf-hip-rfc5205-bis-09: (with DISCUSS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:23:19 -0000 Hi Alexey, The IANA Considerations used to be a copy of RFC 5205 but someone asked that it be cleaned up. I will copy it back in the next revision. I will also clarify that the base64 encoding from section 4 is to be used, similar to DNSSEC RRs. Thanks. --julien On Wed, Jul 6, 2016 at 7:22 AM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-hip-rfc5205-bis-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is the same as Ben's DISCUSS point, but I think this is important > enough to fix: > > Please replicate the appropriate info from the RFC 5205 IANA > considerations. The similar section in this draft does not seem to stand > alone. Readers should not need to refer back to the obsoleted RFC to > understand this version. > > RFC 4648 actually has 2 base64 encodings, so you should say which section > number you mean (section 4 or section 5). I suspect you meant section 5. > > > > From nobody Fri Jul 8 07:25:03 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA3B12D587; Fri, 8 Jul 2016 07:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 HQ__lN7nJMgL; Fri, 8 Jul 2016 07:24:58 -0700 (PDT) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (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 D82A012D501; Fri, 8 Jul 2016 07:24:56 -0700 (PDT) Received: by mail-oi0-x244.google.com with SMTP id w141so10441108oia.0; Fri, 08 Jul 2016 07:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jnw4rIC8B57l0zPgqgfSooSMAzUUo+s0Y/g7jubuL9s=; b=obafVtMg9vvYwMeWR0vkT5YctHYqG/h62nz70WhPME+pvMxPv09S2+E5V8rqWdJqPt GJtS6NGSkIJLDSHc9RTU13HIkkvE9Jppwg56hDvV55LJgAP3IV0Krl+tlgA0d2kkcKaU InRGx1K7DrNVMM2ldf/wKlw2G972VePAWwOYQuzb8A1hpJHj5o/cWg6R8xJnc5t7upYX WGsaGudv/zJlKBldo39fK5fK3uBz0Qy1RrCusLG/b0IcNIRo0N4YR/7xA70F7P7jQnHo t3YJOmTRD2kfSBI0+pghRj1K4AwgH32KnHogEVIPhwpkieVVi90pUCCq4sQ6BrW/YoNN 4igw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jnw4rIC8B57l0zPgqgfSooSMAzUUo+s0Y/g7jubuL9s=; b=ex/5KSpVGE3XgDxG6k/GvQcsEyMGUEiNmQIN0crDIhsQUMvDfhNUVPI5fR+ofwCtYz +QxphJxtRvDXUES0R76i9BRHxCyqg48rvwspfu5HPh69frS7v8rASXochaPSLXsGRciU GeBC65mPOnbUq4eJt7QP4dq5Rj8jqItwplrjsEcEb33qSId9/SQ+I/vzNqB3lXzsQmdT h6vBcTp0N4h9DeDu7q0cXaojz9nXAjY94r4hk4AmwCWfJbp2IxtoFPU3TwDXI2CF3IRv VYNOMOcpX/+iGLFr0acrCpI7dboHy9aPMT2dEtvqw1rSAD/sWFPqc8S3Z3ch1o6IIwYK Y9Mw== X-Gm-Message-State: ALyK8tLaj0aX7cxQLGLupeKEzgcQxdoTrPjT3NcPSbzJDFSm+q74IxvLZH3bETQS9oHnu4qiGRlnE0GoYnHc5w== X-Received: by 10.202.189.198 with SMTP id n189mr3352228oif.111.1467987896226; Fri, 08 Jul 2016 07:24:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.164 with HTTP; Fri, 8 Jul 2016 07:24:55 -0700 (PDT) In-Reply-To: <20160706013706.22302.59656.idtracker@ietfa.amsl.com> References: <20160706013706.22302.59656.idtracker@ietfa.amsl.com> From: Julien Laganier Date: Fri, 8 Jul 2016 07:24:55 -0700 Message-ID: To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: HIP , draft-ietf-hip-rfc5205-bis@ietf.org, hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Ben Campbell's No Objection on draft-ietf-hip-rfc5205-bis-09: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:25:01 -0000 Hi Ben, The IANA Considerations used to be a copy of RFC 5205 but someone asked that it be cleaned up. I will copy it back in the next revision. Thanks. --julien On Tue, Jul 5, 2016 at 6:37 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-hip-rfc5205-bis-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please replicate the appropriate info from the RFC 5205 IANA > considerations. The similar section in this draft does not seem to stand > alone. Readers should not need to refer back to the obsoleted RFC to > understand this version. > > From nobody Fri Jul 8 08:53:49 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9FF12D1B9 for ; Fri, 8 Jul 2016 08:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 yUWu4N6x2-q3 for ; Fri, 8 Jul 2016 08:53:36 -0700 (PDT) Received: from mxout23.cac.washington.edu (mxout23.cac.washington.edu [140.142.32.140]) (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 2275512D7C3 for ; Fri, 8 Jul 2016 08:53:36 -0700 (PDT) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.9.110]) by mxout23.cac.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u68FrGQS015317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jul 2016 08:53:17 -0700 Received: from hymn01.u.washington.edu (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u68FrGHX014811; Fri, 8 Jul 2016 08:53:16 -0700 Received: from localhost (Unknown UID 21258@localhost) by hymn01.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u68FrEYR014797; Fri, 8 Jul 2016 08:53:15 -0700 X-Auth-Received: from [73.239.169.224] by hymn01.u.washington.edu via HTTP; Fri, 08 Jul 2016 08:53:14 PDT Date: Fri, 8 Jul 2016 08:53:14 -0700 (PDT) From: Tom Henderson To: hipsec@ietf.org Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.8.154217 X-PMX-Server: mxout23.cac.washington.edu X-Uwash-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1900_1999 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, MSG_THREAD 0, MULTIPLE_RCPTS_RND 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __MULTIPLE_URI_TEXT 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_START 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_IN_BODY 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0' Archived-At: Cc: Julien Laganier , ben@nostrum.com, aamelnikov@fastmail.fm Subject: [Hipsec] regarding IANA sections in bis documents X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:53:41 -0000 > On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov wrote: >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-hip-rfc5204-bis-07: Discuss >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> The IANA considerations section does not seem to stand alone without >> reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't be >> expected to read it in order to discover original IANA instructions. >> I think you should copy information from RFC 5204. >> On 07/08/2016 07:17 AM, Julien Laganier wrote: > Hi Alexey, > > The IANA Considerations used to be a copy of RFC 5204 but someone > asked that it be cleaned up. I will copy it back in the next revision. > > Thanks. > > --julien I was probably the person suggesting the current writeup, based on my previous interaction with IANA regarding RFC 7401 publication. Before making any IANA section changes, I would like to ask for further clarification, because it seems to me that the guidance being given now conflicts with instructions we received from IANA when revising RFC 5201 to become RFC 7401. When RFC 5201 was updated to RFC 7401, we originally followed the "copy forward the IANA section" approach, but were told by IANA that they preferred that we instead state the updates to be taken on existing registries rather than repeating earlier actions that were already taken to create the registries. That led to the following revisions (where you can see, when using the IETF rfcdiff tool, in version 14 it is a copy forward while version 15 it updates the existing registries): https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-14.txt https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-15.txt - Tom From nobody Fri Jul 8 09:34:40 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B6312D0B0 for ; Fri, 8 Jul 2016 09:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 SKLh48fY6_u9 for ; Fri, 8 Jul 2016 09:34:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2AC0D12D0A8 for ; Fri, 8 Jul 2016 09:34:30 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u68GYPep047607 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 8 Jul 2016 11:34:26 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Tom Henderson" Date: Fri, 08 Jul 2016 11:34:24 -0500 Message-ID: <1D5C6666-54B6-4DFA-9E3D-D32068EF2B3C@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: hipsec@ietf.org, aamelnikov@fastmail.fm, Julien Laganier Subject: Re: [Hipsec] regarding IANA sections in bis documents X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 16:34:39 -0000 On 8 Jul 2016, at 10:53, Tom Henderson wrote: >> On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov >> wrote: >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-hip-rfc5204-bis-07: Discuss >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> The IANA considerations section does not seem to stand alone without >>> reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't >>> be >>> expected to read it in order to discover original IANA instructions. >>> I think you should copy information from RFC 5204. >>> > > On 07/08/2016 07:17 AM, Julien Laganier wrote: >> Hi Alexey, >> >> The IANA Considerations used to be a copy of RFC 5204 but someone >> asked that it be cleaned up. I will copy it back in the next >> revision. >> >> Thanks. >> >> --julien > > I was probably the person suggesting the current writeup, based on my > previous interaction with IANA regarding RFC 7401 publication. > > Before making any IANA section changes, I would like to ask for > further clarification, because it seems to me that the guidance being > given now conflicts with instructions we received from IANA when > revising RFC 5201 to become RFC 7401. > > When RFC 5201 was updated to RFC 7401, we originally followed the > "copy forward the IANA section" approach, but were told by IANA that > they preferred that we instead state the updates to be taken on > existing registries rather than repeating earlier actions that were > already taken to create the registries. In my opinion, you need both. The text needs to make it clear what actions IANA needs to take _now_. But it also needs to fully document any registries/registrations so that other readers can find it, keeping in mind that an obsoleted RFC is, well, obsolete. Note that this is usually at least somewhat different from simply copying the old text forward. This is especially true when updating the reference for a registry or registration to point to the bis document; this only makes sense if the bis draft actually describes that registry or registration. I think it's perfectly reasonable to say something of the form of "RFCXXXX, obsoleted by this document, made these requests of IANA: . This document mades these additional requests: " > > That led to the following revisions (where you can see, when using the > IETF rfcdiff tool, in version 14 it is a copy forward while version 15 > it updates the existing registries): > > https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-14.txt > https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-15.txt > > - Tom From nobody Thu Jul 14 18:17:07 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4020212B017 for ; Thu, 14 Jul 2016 18:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 oi6_iRDvtd9G for ; Thu, 14 Jul 2016 18:17:04 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 760AA12D8B6 for ; Thu, 14 Jul 2016 18:17:04 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id l65so57018024oib.1 for ; Thu, 14 Jul 2016 18:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IKLtV9Z5bTzfqu57tIDoN0ZgR+K+zyQiRu4U7qib+Kw=; b=CJTdrBSAGAx4DJN3ONF1B8GlD1COK4WFTIONaWCxtO5x0N7byPjh7ypRnGcpTTjuIa j0ECEf+lFyWEu3wwe02OHM2EF115rcYe06H70LkmWyE326x09Ek9bSwNOJ4kGlAqqVqS VMlluHsR+hx0gRb1IvAugskE40yLZXtGFaAZIkkbvq8qOOk8RM3P3Rq4YpZvEgawrbsq Dxpj9xdTj4LyK5EtqgTcUYukUfHAVEoguOONI2F4vo7zhbouGPyre6AgrWdkYC7Zc+Bg M2TIEIoZ4VNPBjKpkVebpyyE+XNEJ1+d8Ri816TyARVwY0RrHYZqV7OtgWV/l+2g90NH dWqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IKLtV9Z5bTzfqu57tIDoN0ZgR+K+zyQiRu4U7qib+Kw=; b=RZDgwTwUcRQBAqA8oZCgLDBVoEXF3s7UDAzHzok/DNmN/laRkVGUFs17NrjzoRjK/K NCXnkF/+oeDWrJbjQV14Fn5K+dIUsK0AWKsIT7vL/6uoWNhu7UcT0Wg1srgbkZRstBoQ WqSXBX9Dflh9osSrod/enXNQv2OrsLvh8BHF3dbi+2GSLxeTA7KvA+bW7yVKBCfIy55y XoCwuguzRLJ0w9nf4UJt5CokN/eJF/afUyEfcEYXmHVl55m1q42C6sup5oEpzGwIBf0c 11Ibqwmz+WvXVeU/m34YO8PNd/9lxG1BUK2kasx3UwWEY0G+S6FKE7OqC7bS0WG3F1Tt l9NA== X-Gm-Message-State: ALyK8tLbUzReP079pBEl1A4SMRipp/rKGh82oqDZYohMNxNpEITNEXFS3U8aILvLhpKlEbjEWVgyQbWDKq4aNQ== X-Received: by 10.157.2.5 with SMTP id 5mr10782094otb.184.1468545423674; Thu, 14 Jul 2016 18:17:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.164 with HTTP; Thu, 14 Jul 2016 18:17:03 -0700 (PDT) In-Reply-To: <1D5C6666-54B6-4DFA-9E3D-D32068EF2B3C@nostrum.com> References: <1D5C6666-54B6-4DFA-9E3D-D32068EF2B3C@nostrum.com> From: Julien Laganier Date: Thu, 14 Jul 2016 18:17:03 -0700 Message-ID: To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: HIP , Alexey Melnikov Subject: Re: [Hipsec] regarding IANA sections in bis documents X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 01:17:06 -0000 Hi Ben & Alexey, Thanks for clarifying. We've discussed your suggestion with Terry Manderson from IANA and have agreed on proceeding as follows: RFCXXXX, obsoleted by this document, made the following IANA allocation in : . IANA is requested to replace references to [RFCXXXX] by references to this document in the the registry. This document also requests IANA to make these additional in ". If this is okay with you both I will proceed with updating draft-ietf-hip-rfc520{3,4,5}-bis accordingly. Best, --julien On Fri, Jul 8, 2016 at 9:34 AM, Ben Campbell wrote: > On 8 Jul 2016, at 10:53, Tom Henderson wrote: > >>> On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov >>> wrote: >>>> >>>> Alexey Melnikov has entered the following ballot position for >>>> draft-ietf-hip-rfc5204-bis-07: Discuss >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> The IANA considerations section does not seem to stand alone without >>>> reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't be >>>> expected to read it in order to discover original IANA instructions. >>>> I think you should copy information from RFC 5204. >>>> >> >> On 07/08/2016 07:17 AM, Julien Laganier wrote: >>> >>> Hi Alexey, >>> >>> The IANA Considerations used to be a copy of RFC 5204 but someone >>> asked that it be cleaned up. I will copy it back in the next revision. >>> >>> Thanks. >>> >>> --julien >> >> >> I was probably the person suggesting the current writeup, based on my >> previous interaction with IANA regarding RFC 7401 publication. >> >> Before making any IANA section changes, I would like to ask for further >> clarification, because it seems to me that the guidance being given now >> conflicts with instructions we received from IANA when revising RFC 5201 to >> become RFC 7401. >> >> When RFC 5201 was updated to RFC 7401, we originally followed the "copy >> forward the IANA section" approach, but were told by IANA that they >> preferred that we instead state the updates to be taken on existing >> registries rather than repeating earlier actions that were already taken to >> create the registries. > > > In my opinion, you need both. The text needs to make it clear what actions > IANA needs to take _now_. But it also needs to fully document any > registries/registrations so that other readers can find it, keeping in mind > that an obsoleted RFC is, well, obsolete. Note that this is usually at least > somewhat different from simply copying the old text forward. This is > especially true when updating the reference for a registry or registration > to point to the bis document; this only makes sense if the bis draft > actually describes that registry or registration. > > I think it's perfectly reasonable to say something of the form of "RFCXXXX, > obsoleted by this document, made these requests of IANA: . This > document mades these additional requests: " > > >> >> That led to the following revisions (where you can see, when using the >> IETF rfcdiff tool, in version 14 it is a copy forward while version 15 it >> updates the existing registries): >> >> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-14.txt >> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-15.txt >> >> - Tom From nobody Thu Jul 14 19:07:08 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D349A12D941 for ; Thu, 14 Jul 2016 19:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 eWri_H-1yRKq for ; Thu, 14 Jul 2016 19:07:05 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ACCC12D8A3 for ; Thu, 14 Jul 2016 19:07:04 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 14 Jul 2016 19:07:02 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 14 Jul 2016 19:07:02 -0700 From: Terry Manderson To: Julien Laganier Thread-Topic: [Hipsec] regarding IANA sections in bis documents Thread-Index: AQHR2TD8kptu5IJdTk+Fsf/GCrMm/qAPMCIAgAoABID//5id9w== Date: Fri, 15 Jul 2016 02:07:00 +0000 Message-ID: <51E130EF-483A-497F-99EC-73C86CFE8906@icann.org> References: <1D5C6666-54B6-4DFA-9E3D-D32068EF2B3C@nostrum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Ben Campbell , Alexey Melnikov , HIP Subject: Re: [Hipsec] regarding IANA sections in bis documents X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 02:07:07 -0000 Just to clarify I am NOT from IANA. I do work at ICANN but my role here is = as INT area AD.=20 - Gorilla typing on iPhone.=20 > On 15 Jul 2016, at 09:17, Julien Laganier wrote: >=20 > Hi Ben & Alexey, >=20 > Thanks for clarifying. We've discussed your suggestion with Terry > Manderson from IANA and have agreed on proceeding as follows: >=20 > RFCXXXX, obsoleted by this document, made the following IANA > allocation in : . > IANA is requested to replace references to [RFCXXXX] by references to > this document in the the registry. >=20 > This document also requests IANA to make these additional new allocation> in ". >=20 > If this is okay with you both I will proceed with updating > draft-ietf-hip-rfc520{3,4,5}-bis accordingly. >=20 > Best, >=20 > --julien >=20 >=20 >=20 >> On Fri, Jul 8, 2016 at 9:34 AM, Ben Campbell wrote: >> On 8 Jul 2016, at 10:53, Tom Henderson wrote: >>=20 >>>> On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov >>>> wrote: >>>>>=20 >>>>> Alexey Melnikov has entered the following ballot position for >>>>> draft-ietf-hip-rfc5204-bis-07: Discuss >>>>> ---------------------------------------------------------------------= - >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------= - >>>>>=20 >>>>> The IANA considerations section does not seem to stand alone without >>>>> reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't b= e >>>>> expected to read it in order to discover original IANA instructions. >>>>> I think you should copy information from RFC 5204. >>>>>=20 >>>=20 >>>> On 07/08/2016 07:17 AM, Julien Laganier wrote: >>>>=20 >>>> Hi Alexey, >>>>=20 >>>> The IANA Considerations used to be a copy of RFC 5204 but someone >>>> asked that it be cleaned up. I will copy it back in the next revision. >>>>=20 >>>> Thanks. >>>>=20 >>>> --julien >>>=20 >>>=20 >>> I was probably the person suggesting the current writeup, based on my >>> previous interaction with IANA regarding RFC 7401 publication. >>>=20 >>> Before making any IANA section changes, I would like to ask for further >>> clarification, because it seems to me that the guidance being given now >>> conflicts with instructions we received from IANA when revising RFC 520= 1 to >>> become RFC 7401. >>>=20 >>> When RFC 5201 was updated to RFC 7401, we originally followed the "copy >>> forward the IANA section" approach, but were told by IANA that they >>> preferred that we instead state the updates to be taken on existing >>> registries rather than repeating earlier actions that were already take= n to >>> create the registries. >>=20 >>=20 >> In my opinion, you need both. The text needs to make it clear what actio= ns >> IANA needs to take _now_. But it also needs to fully document any >> registries/registrations so that other readers can find it, keeping in m= ind >> that an obsoleted RFC is, well, obsolete. Note that this is usually at l= east >> somewhat different from simply copying the old text forward. This is >> especially true when updating the reference for a registry or registrati= on >> to point to the bis document; this only makes sense if the bis draft >> actually describes that registry or registration. >>=20 >> I think it's perfectly reasonable to say something of the form of "RFCXX= XX, >> obsoleted by this document, made these requests of IANA: . Th= is >> document mades these additional requests: " >>=20 >>=20 >>>=20 >>> That led to the following revisions (where you can see, when using the >>> IETF rfcdiff tool, in version 14 it is a copy forward while version 15 = it >>> updates the existing registries): >>>=20 >>> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-14.txt >>> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-15.txt >>>=20 >>> - Tom >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From nobody Thu Jul 14 19:12:30 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AB612D69C for ; Thu, 14 Jul 2016 19:12:28 -0700 (PDT) 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 cOawHUpAYKUM for ; Thu, 14 Jul 2016 19:12:26 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 3339A12D69E for ; Thu, 14 Jul 2016 19:12:26 -0700 (PDT) Received: by mail-pa0-x22d.google.com with SMTP id dx3so34322060pab.2 for ; Thu, 14 Jul 2016 19:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=Owke3vIH9iPitCm45azd00zIxQ0eXOibv9+5ubCOuA4=; b=L0SS4KIarcIMPahOBxK+ZOfK6rhzKOyGr3Q1U91dylsvsKZABUaeDlBXMObaJmfYh6 0lTxE4bq54i/d+Lxp4Xr1QacXd2vre33r9MWTb/H6LgOAIlrrzVsKy4eW9jVjALZUGTj QwmiACdtjVnXc9XbvJECMp/x0yZrCzfwyo//vktfiSdMduHfko7fqykYPTgNliH+A3WF PyTAaaTARf6ggpgb8TZ3z8PE/LPiWUJd+7C05DEzzsC7Atk2gRXQ8w8L+LPqo6CHOrNl ismN+J+mbzC/YfNDdrFDRLDec/aOn87RlZh0ixOae3/7++4xdFbK9zezgBw6KPOX2VJk 8Msw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=Owke3vIH9iPitCm45azd00zIxQ0eXOibv9+5ubCOuA4=; b=G3hZkyaiW8XVNV3pN15Pt+7TT/fGxTVP4z7GfU2rXomsZ38UeqUvfrAo1sBtPmcrLL USPPok7iQGB1x7Bg9XWMNBpWCHyOvE6qoVep2hktbVr9mtPq/DouEJrOKG8tF8SjVi3G Ojlmp3tU4jGYNfaNeYEz4/QgyDFRkq/eptruZdjBAx2EXhV5KCz9oKUxL/4+45GwNC85 rDHxXLnW+pxJYEgl+nv1vB5GPs4otVjXRaCmc17+LnaMyodOe0ouGABMqilyNkqjIJ+T zLkf/FDWgvQzoLPFqAKrc7mnL9/vlSgPas+LgIEl6ifXml6sXVLFCvCWPOuC38MilhON LxJw== X-Gm-Message-State: ALyK8tKMd3bEU7YxFe9v7dBK1JdhHQvB7kBDPId0GtXbiJiekeUqods0KvImZYmheg+I1g== X-Received: by 10.66.73.166 with SMTP id m6mr9722414pav.122.1468548745753; Thu, 14 Jul 2016 19:12:25 -0700 (PDT) Received: from mail.outlook.com (ec2-52-33-57-33.us-west-2.compute.amazonaws.com. [52.33.57.33]) by smtp.gmail.com with ESMTPSA id s23sm5936943pfd.23.2016.07.14.19.12.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jul 2016 19:12:24 -0700 (PDT) Date: Fri, 15 Jul 2016 02:12:24 +0000 (UTC) From: Julien Laganier To: Terry Manderson , Julien Laganier Message-ID: In-Reply-To: <51E130EF-483A-497F-99EC-73C86CFE8906@icann.org> References: <1D5C6666-54B6-4DFA-9E3D-D32068EF2B3C@nostrum.com>, <51E130EF-483A-497F-99EC-73C86CFE8906@icann.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3393_168776638.1468548744270" X-Mailer: Outlook for iOS and Android Archived-At: Cc: Ben Campbell , Alexey Melnikov , HIP Subject: Re: [Hipsec] regarding IANA sections in bis documents X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 02:12:28 -0000 ------=_Part_3393_168776638.1468548744270 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My mistake, sorry for the confusion and thanks for clarifying.=C2=A0 Best, --julien On Thu, Jul 14, 2016 at 7:07 PM -0700, "Terry Manderson" wrote: Just to clarify I am NOT from IANA. I do work at ICANN but my role here is = as INT area AD.=20 - Gorilla typing on iPhone.=20 > On 15 Jul 2016, at 09:17, Julien Laganier wrote: >=20 > Hi Ben & Alexey, >=20 > Thanks for clarifying. We've discussed your suggestion with Terry > Manderson from IANA and have agreed on proceeding as follows: >=20 > RFCXXXX, obsoleted by this document, made the following IANA > allocation in : . > IANA is requested to replace references to [RFCXXXX] by references to > this document in the the registry. >=20 > This document also requests IANA to make these additional new allocation= > in ". >=20 > If this is okay with you both I will proceed with updating > draft-ietf-hip-rfc520{3,4,5}-bis accordingly. >=20 > Best, >=20 > --julien >=20 >=20 >=20 >> On Fri, Jul 8, 2016 at 9:34 AM, Ben Campbell wrote: >> On 8 Jul 2016, at 10:53, Tom Henderson wrote: >>=20 >>>> On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov=20 >>>> wrote: >>>>>=20 >>>>> Alexey Melnikov has entered the following ballot position for >>>>> draft-ietf-hip-rfc5204-bis-07: Discuss >>>>> ---------------------------------------------------------------------= - >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------= - >>>>>=20 >>>>> The IANA considerations section does not seem to stand alone without >>>>> reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't b= e >>>>> expected to read it in order to discover original IANA instructions. >>>>> I think you should copy information from RFC 5204. >>>>>=20 >>>=20 >>>> On 07/08/2016 07:17 AM, Julien Laganier wrote: >>>>=20 >>>> Hi Alexey, >>>>=20 >>>> The IANA Considerations used to be a copy of RFC 5204 but someone >>>> asked that it be cleaned up. I will copy it back in the next revision. >>>>=20 >>>> Thanks. >>>>=20 >>>> --julien >>>=20 >>>=20 >>> I was probably the person suggesting the current writeup, based on my >>> previous interaction with IANA regarding RFC 7401 publication. >>>=20 >>> Before making any IANA section changes, I would like to ask for further >>> clarification, because it seems to me that the guidance being given now >>> conflicts with instructions we received from IANA when revising RFC 520= 1 to >>> become RFC 7401. >>>=20 >>> When RFC 5201 was updated to RFC 7401, we originally followed the "copy >>> forward the IANA section" approach, but were told by IANA that they >>> preferred that we instead state the updates to be taken on existing >>> registries rather than repeating earlier actions that were already take= n to >>> create the registries. >>=20 >>=20 >> In my opinion, you need both. The text needs to make it clear what actio= ns >> IANA needs to take _now_. But it also needs to fully document any >> registries/registrations so that other readers can find it, keeping in m= ind >> that an obsoleted RFC is, well, obsolete. Note that this is usually at l= east >> somewhat different from simply copying the old text forward. This is >> especially true when updating the reference for a registry or registrati= on >> to point to the bis document; this only makes sense if the bis draft >> actually describes that registry or registration. >>=20 >> I think it's perfectly reasonable to say something of the form of "RFCXX= XX, >> obsoleted by this document, made these requests of IANA: . This >> document mades these additional requests: " >>=20 >>=20 >>>=20 >>> That led to the following revisions (where you can see, when using the >>> IETF rfcdiff tool, in version 14 it is a copy forward while version 15 = it >>> updates the existing registries): >>>=20 >>> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-14.txt >>> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-15.txt >>>=20 >>> - Tom >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec ------=_Part_3393_168776638.1468548744270 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
My mistake, sorry for the confusion and thanks for clarifying. 

Best,

--julien




On Thu, Jul 14, 2016 at 7:07 PM -0700, "Terry Manderson" <terry.manderson@icann.org> wrote:

Just to clarify I am NOT from IANA. I do work at ICANN but my role here is as INT area AD. 

- Gorilla typing on iPhone. 

> On 15 Jul 2016, at 09:17, Julien Laganier  wrote:
> 
> Hi Ben & Alexey,
> 
> Thanks for clarifying. We've discussed your suggestion with Terry
> Manderson from IANA and have agreed on proceeding as follows:
> 
> RFCXXXX, obsoleted by this document, made the following IANA
> allocation in : .
> IANA is requested to replace references to [RFCXXXX] by references to
> this document in the the  registry.
> 
> This document also requests IANA to make these additional  new allocation> in ".
> 
> If this is okay with you both I will proceed with updating
> draft-ietf-hip-rfc520{3,4,5}-bis accordingly.
> 
> Best,
> 
> --julien
> 
> 
> 
>> On Fri, Jul 8, 2016 at 9:34 AM, Ben Campbell  wrote:
>> On 8 Jul 2016, at 10:53, Tom Henderson wrote:
>> 
>>>> On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov 
>>>> wrote:
>>>>> 
>>>>> Alexey Melnikov has entered the following ballot position for
>>>>> draft-ietf-hip-rfc5204-bis-07: Discuss
>>>>> ----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>> 
>>>>> The IANA considerations section does not seem to stand alone without
>>>>> reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't be
>>>>> expected to read it in order to discover original IANA instructions.
>>>>> I think you should copy information from RFC 5204.
>>>>> 
>>> 
>>>> On 07/08/2016 07:17 AM, Julien Laganier wrote:
>>>> 
>>>> Hi Alexey,
>>>> 
>>>> The IANA Considerations used to be a copy of RFC 5204 but someone
>>>> asked that it be cleaned up. I will copy it back in the next revision.
>>>> 
>>>> Thanks.
>>>> 
>>>> --julien
>>> 
>>> 
>>> I was probably the person suggesting the current writeup, based on my
>>> previous interaction with IANA regarding RFC 7401 publication.
>>> 
>>> Before making any IANA section changes, I would like to ask for further
>>> clarification, because it seems to me that the guidance being given now
>>> conflicts with instructions we received from IANA when revising RFC 5201 to
>>> become RFC 7401.
>>> 
>>> When RFC 5201 was updated to RFC 7401, we originally followed the "copy
>>> forward the IANA section" approach, but were told by IANA that they
>>> preferred that we instead state the updates to be taken on existing
>>> registries rather than repeating earlier actions that were already taken to
>>> create the registries.
>> 
>> 
>> In my opinion, you need both. The text needs to make it clear what actions
>> IANA needs to take _now_. But it also needs to fully document any
>> registries/registrations so that other readers can find it, keeping in mind
>> that an obsoleted RFC is, well, obsolete. Note that this is usually at least
>> somewhat different from simply copying the old text forward. This is
>> especially true when updating the reference for a registry or registration
>> to point to the bis document; this only makes sense if the bis draft
>> actually describes that registry or registration.
>> 
>> I think it's perfectly reasonable to say something of the form of "RFCXXXX,
>> obsoleted by this document, made these requests of IANA: . This
>> document mades these additional requests: "
>> 
>> 
>>> 
>>> That led to the following revisions (where you can see, when using the
>>> IETF rfcdiff tool, in version 14 it is a copy forward while version 15 it
>>> updates the existing registries):
>>> 
>>> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-14.txt
>>> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-15.txt
>>> 
>>> - Tom
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
------=_Part_3393_168776638.1468548744270-- From nobody Thu Jul 14 23:42:41 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D2512B042 for ; Thu, 14 Jul 2016 23:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=lYUruuCt; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=f8AJW5zP 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 6i8D2czOG2u7 for ; Thu, 14 Jul 2016 23:42:36 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CAD12B02B for ; Thu, 14 Jul 2016 23:42:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 387882028A; Fri, 15 Jul 2016 02:42:33 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 15 Jul 2016 02:42:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=I0WOOXGqCW8Mj2xASgkx+GVYWaE=; b=lYUruu CtSBIzclRN/BLMmqC6e0lnXtAvSGsdocK8jqeJBBwNPeqmgw12VCWC/EfnHl+fvT XKivfrQLTKwXRO3DUKukb47psKKrfBacw7zQWxVw7FlJJ9nmz8V2iTBtFbeHzqRE Wx7TnYoNgHbnzc6nimq5PqWpT9oGsfKLWncGY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=I0WOOXGqCW8Mj2x ASgkx+GVYWaE=; b=f8AJW5zPAY5EIpFtxSfXsdE62gvGh1HaYSgZj5Rekdt8bTT azUnZKtEi8v70R156YGMhwxziKyiJNzNPZrNWPRGUQVvnqRYnigXNTxRPGPAQhEj QUK51GehYHaHHlv6TM5xxbvPySfoj+r+XmNu5T78TZa8dmy/jUQQ7ya3BLA8= X-Sasl-enc: ymrk0Xt147M5NraXGDdra2fRwpd3HaJ4OnF4Gk/jYgyn 1468564952 Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by mail.messagingengine.com (Postfix) with ESMTPA id 79C93F29E1; Fri, 15 Jul 2016 02:42:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (13F69) In-Reply-To: Date: Fri, 15 Jul 2016 07:53:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5B9D2D78-F299-4A9A-A9AF-62FB12D30777@fastmail.fm> References: <1D5C6666-54B6-4DFA-9E3D-D32068EF2B3C@nostrum.com> To: Julien Laganier Archived-At: Cc: Ben Campbell , HIP Subject: Re: [Hipsec] regarding IANA sections in bis documents X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 06:42:38 -0000 Hi Julien, > On 15 Jul 2016, at 02:17, Julien Laganier wrote: >=20 > Hi Ben & Alexey, >=20 > Thanks for clarifying. We've discussed your suggestion with Terry > Manderson from IANA and have agreed on proceeding as follows: >=20 > RFCXXXX, obsoleted by this document, made the following IANA > allocation in : . ... and the allocation policy. > IANA is requested to replace references to [RFCXXXX] by references to > this document in the the registry. >=20 > This document also requests IANA to make these additional new allocation> in ". >=20 > If this is okay with you both I will proceed with updating > draft-ietf-hip-rfc520{3,4,5}-bis accordingly. Sounds good to me. Thank you, Alexey >=20 > Best, >=20 > --julien >=20 >=20 >=20 >> On Fri, Jul 8, 2016 at 9:34 AM, Ben Campbell wrote: >> On 8 Jul 2016, at 10:53, Tom Henderson wrote: >>=20 >>>> On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov >>>> wrote: >>>>>=20 >>>>> Alexey Melnikov has entered the following ballot position for >>>>> draft-ietf-hip-rfc5204-bis-07: Discuss >>>>> ----------------------------------------------------------------------= >>>>> DISCUSS: >>>>> ----------------------------------------------------------------------= >>>>>=20 >>>>> The IANA considerations section does not seem to stand alone without >>>>> reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't be= >>>>> expected to read it in order to discover original IANA instructions. >>>>> I think you should copy information from RFC 5204. >>>=20 >>>> On 07/08/2016 07:17 AM, Julien Laganier wrote: >>>>=20 >>>> Hi Alexey, >>>>=20 >>>> The IANA Considerations used to be a copy of RFC 5204 but someone >>>> asked that it be cleaned up. I will copy it back in the next revision. >>>>=20 >>>> Thanks. >>>>=20 >>>> --julien >>>=20 >>>=20 >>> I was probably the person suggesting the current writeup, based on my >>> previous interaction with IANA regarding RFC 7401 publication. >>>=20 >>> Before making any IANA section changes, I would like to ask for further >>> clarification, because it seems to me that the guidance being given now >>> conflicts with instructions we received from IANA when revising RFC 5201= to >>> become RFC 7401. >>>=20 >>> When RFC 5201 was updated to RFC 7401, we originally followed the "copy >>> forward the IANA section" approach, but were told by IANA that they >>> preferred that we instead state the updates to be taken on existing >>> registries rather than repeating earlier actions that were already taken= to >>> create the registries. >>=20 >>=20 >> In my opinion, you need both. The text needs to make it clear what action= s >> IANA needs to take _now_. But it also needs to fully document any >> registries/registrations so that other readers can find it, keeping in mi= nd >> that an obsoleted RFC is, well, obsolete. Note that this is usually at le= ast >> somewhat different from simply copying the old text forward. This is >> especially true when updating the reference for a registry or registratio= n >> to point to the bis document; this only makes sense if the bis draft >> actually describes that registry or registration. >>=20 >> I think it's perfectly reasonable to say something of the form of "RFCXXX= X, >> obsoleted by this document, made these requests of IANA: . Thi= s >> document mades these additional requests: " >>=20 >>=20 >>>=20 >>> That led to the following revisions (where you can see, when using the >>> IETF rfcdiff tool, in version 14 it is a copy forward while version 15 i= t >>> updates the existing registries): >>>=20 >>> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-14.txt >>> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-15.txt >>>=20 >>> - Tom From nobody Fri Jul 15 00:17:58 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1E312D8FC for ; Fri, 15 Jul 2016 00:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 fzU7yuFYtF7t for ; Fri, 15 Jul 2016 00:17:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 672BA12D7EF for ; Fri, 15 Jul 2016 00:17:55 -0700 (PDT) Received: from [10.0.2.233] ([104.207.136.119]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6F7HgKr030837 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 15 Jul 2016 02:17:45 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [104.207.136.119] claimed to be [10.0.2.233] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (13F69) In-Reply-To: <5B9D2D78-F299-4A9A-A9AF-62FB12D30777@fastmail.fm> Date: Fri, 15 Jul 2016 09:17:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D5C6666-54B6-4DFA-9E3D-D32068EF2B3C@nostrum.com> <5B9D2D78-F299-4A9A-A9AF-62FB12D30777@fastmail.fm> To: Alexey Melnikov Archived-At: Cc: Julien Laganier , HIP Subject: Re: [Hipsec] regarding IANA sections in bis documents X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 07:17:57 -0000 > On Jul 15, 2016, at 8:53 AM, Alexey Melnikov wrot= e: >=20 > Hi Julien, >=20 >> On 15 Jul 2016, at 02:17, Julien Laganier wrote: >>=20 >> Hi Ben & Alexey, >>=20 >> Thanks for clarifying. We've discussed your suggestion with Terry >> Manderson from IANA and have agreed on proceeding as follows: >>=20 >> RFCXXXX, obsoleted by this document, made the following IANA >> allocation in : . >=20 > ... and the allocation policy. Yes, that too. >=20 >> IANA is requested to replace references to [RFCXXXX] by references to >> this document in the the registry. >>=20 >> This document also requests IANA to make these additional > new allocation> in ". >>=20 >> If this is okay with you both I will proceed with updating >> draft-ietf-hip-rfc520{3,4,5}-bis accordingly. >=20 > Sounds good to me. Me, too. Thanks! Ben >=20 > Thank you, > Alexey >>=20 >> Best, >>=20 >> --julien >>=20 >>=20 >>=20 >>> On Fri, Jul 8, 2016 at 9:34 AM, Ben Campbell wrote: >>> On 8 Jul 2016, at 10:53, Tom Henderson wrote: >>>=20 >>>>> On Wed, Jul 6, 2016 at 11:31 AM, Alexey Melnikov >>>>> wrote: >>>>>>=20 >>>>>> Alexey Melnikov has entered the following ballot position for >>>>>> draft-ietf-hip-rfc5204-bis-07: Discuss >>>>>> ---------------------------------------------------------------------= - >>>>>> DISCUSS: >>>>>> ---------------------------------------------------------------------= - >>>>>>=20 >>>>>> The IANA considerations section does not seem to stand alone without >>>>>> reading RFC 5204. As you are obsoleting RFC 5204, readers shouldn't b= e >>>>>> expected to read it in order to discover original IANA instructions. >>>>>> I think you should copy information from RFC 5204. >>>>=20 >>>>> On 07/08/2016 07:17 AM, Julien Laganier wrote: >>>>>=20 >>>>> Hi Alexey, >>>>>=20 >>>>> The IANA Considerations used to be a copy of RFC 5204 but someone >>>>> asked that it be cleaned up. I will copy it back in the next revision.= >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> --julien >>>>=20 >>>>=20 >>>> I was probably the person suggesting the current writeup, based on my >>>> previous interaction with IANA regarding RFC 7401 publication. >>>>=20 >>>> Before making any IANA section changes, I would like to ask for further= >>>> clarification, because it seems to me that the guidance being given now= >>>> conflicts with instructions we received from IANA when revising RFC 520= 1 to >>>> become RFC 7401. >>>>=20 >>>> When RFC 5201 was updated to RFC 7401, we originally followed the "copy= >>>> forward the IANA section" approach, but were told by IANA that they >>>> preferred that we instead state the updates to be taken on existing >>>> registries rather than repeating earlier actions that were already take= n to >>>> create the registries. >>>=20 >>>=20 >>> In my opinion, you need both. The text needs to make it clear what actio= ns >>> IANA needs to take _now_. But it also needs to fully document any >>> registries/registrations so that other readers can find it, keeping in m= ind >>> that an obsoleted RFC is, well, obsolete. Note that this is usually at l= east >>> somewhat different from simply copying the old text forward. This is >>> especially true when updating the reference for a registry or registrati= on >>> to point to the bis document; this only makes sense if the bis draft >>> actually describes that registry or registration. >>>=20 >>> I think it's perfectly reasonable to say something of the form of "RFCXX= XX, >>> obsoleted by this document, made these requests of IANA: . Th= is >>> document mades these additional requests: " >>>=20 >>>=20 >>>>=20 >>>> That led to the following revisions (where you can see, when using the >>>> IETF rfcdiff tool, in version 14 it is a copy forward while version 15 i= t >>>> updates the existing registries): >>>>=20 >>>> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-14.txt >>>> https://www.ietf.org/archive/id/draft-ietf-hip-rfc5201-bis-15.txt >>>>=20 >>>> - Tom >=20 From nobody Wed Jul 20 08:11:15 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31D712D8F7; Wed, 20 Jul 2016 08:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 46BQVawtgqjO; Wed, 20 Jul 2016 08:11:05 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 66C5312D8C1; Wed, 20 Jul 2016 08:11:05 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id l72so75677403oig.2; Wed, 20 Jul 2016 08:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/PXIWcNh0HAEnmvSI49cBXuE1BoGPlPmd/Of61j+PLY=; b=JOWs1/ZuIre/K6FnR7f9qD8F6ZJTZfY4+w2ZVUAKS9jAO6VVXNOnvNSJ79Ga9KFmtl CP/pHmbQmbbS9HkQQ82R6jC+S+xgmCnhhFTeY5RCtjMDcp0ZALkxq/YdVPrus9ibvuRM isrmlGBOH8Q+U5DwS11yZeKVNwydo1UALAJv92SJMfbf/xyO0UxHyzuNMp+7vCQqBvAh j2cTUgRhxkxAlrgYtYs6LQAdZJLIvB5CxpDsWqGOKm+KjEKJ1MGhfRItgeB6ebNIN0m/ nulqg1XGI3gmazK7QE1PElvdfKpa1fnTfM+6td+F7dJZ5A7BoUT7N6JYlHZ+kovtl3v8 bEbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/PXIWcNh0HAEnmvSI49cBXuE1BoGPlPmd/Of61j+PLY=; b=KSoQPhy5Gw9yCr5R9X9qCrTrGd6YG9fXumFNYoOpt8DGVK3HR4lJ7e/cB5deLJDAou cihNeIc4Te/eQZngg4e4J37OknTyK1gNuXd62Ll2a1Yyt39q4yOcZiiAylo9pk9Cj28r IaQx/2TDWN9L/Jd1C5Oou8udTXCQ+rURdao+IQXMGohSZQwTk6emtyfSY2d5OQoH1N1G y67WgmIOovpHlJEaYjZvikSSv8W0sfBTDAxtrTeXhQZRYLlt3XGfW55wlBdx1o1lPuAV OH2eEHhrsk1HsrncTEjx2Ck1aN/UqlxqTBg24HkA6dBaRkPLt/USOI5/w8WvlZtV/fDm QiJg== X-Gm-Message-State: ALyK8tL8NgRAV72dmqEUIgCHdDBjBkviOoCmJw8dVkgCTlV3Kuf1KZbBN6jvHXFgWI3XnKDUfyxDNcYkIS9E2A== X-Received: by 10.157.6.134 with SMTP id 6mr26506752otx.186.1469027464683; Wed, 20 Jul 2016 08:11:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.164 with HTTP; Wed, 20 Jul 2016 08:11:04 -0700 (PDT) In-Reply-To: <20160705140143.22339.24069.idtracker@ietfa.amsl.com> References: <20160705140143.22339.24069.idtracker@ietfa.amsl.com> From: Julien Laganier Date: Wed, 20 Jul 2016 08:11:04 -0700 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, HIP , hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Stephen Farrell's Discuss on draft-ietf-hip-rfc5203-bis-10: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 15:11:09 -0000 Hi Stephen, Thanks for reviewing the document. I think there would be value in making the cause of certificate error explicit. Would the following change be acceptable? OLD: If the certificate in the parameter is not accepted, the registrar MUST reject the corresponding registrations with Failure Type [IANA TBD] (Invalid certificate). NEW: If the certificate in the parameter is not accepted, the registrar MUST reject the corresponding registrations with the appropriate Failure Type: [IANA TBD] (Bad certificate): The certificate is corrupt, contains invalid signatures, etc. [IANA TBD] (Unsupported certificate): The certificate is of an unsupported type. [IANA TBD] (Certificate expired): The certificate is no longer valid. [IANA TBD] (Certificate other): The certificate could not be validated for some unspecified reason. [IANA TBD] (Unknown CA): The issuing CA certificate could not be located or is not trusted. Please let us know. Best, --julien On Tue, Jul 5, 2016 at 7:01 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-hip-rfc5203-bis-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > 3.3 - This fails to distinguish between an invalid > certificate (e.g. bad signature, unknown signer) and one > that is valid, but is not acceptable for this purpose. I > don't get why that is ok for HIP, can you explain? If it > is ok, I think you need to say so. If it is not ok (as I'd > suspect) then you appear to need to change text or one more > new error code. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Section 7 - I'm fine that this doesn't repeat stuff > from 5203, but a sentence saying to go look there too > would maybe be good. (I'm not sure if that would fix > Alexey's discuss or not. If not, then ignore me and > just talk to him about his discuss.) > > From nobody Thu Jul 21 04:25:50 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6564412DC4D; Thu, 21 Jul 2016 04:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 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=-1.287, 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 sDnpoTLa0DJb; Thu, 21 Jul 2016 04:25:40 -0700 (PDT) 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 501F812DDDA; Thu, 21 Jul 2016 04:22:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 52F39BE38; Thu, 21 Jul 2016 12:22:51 +0100 (IST) 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 LU4p2feHtSEN; Thu, 21 Jul 2016 12:22:49 +0100 (IST) Received: from [31.133.141.42] (dhcp-8d2a.meeting.ietf.org [31.133.141.42]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EC50EBE32; Thu, 21 Jul 2016 12:22:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469100169; bh=xmHjqeAQu2hXBdlym5A/UVw+S8VDbIMR9FmBPgVSWVQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=VpFU8bBbNIjTcNthHys/UUN6gui0jSKfSjO7ThockX0ptgSuqKjIe14ZpBjmElXjl +SFA9FXYlURw7jRITjhIO2l2cdkeOkfCo5t17hToTGrdR4oU/wTFREOO+yJqKEnu26 jf/6IintMddrRqTFJM+r4NXZRNhcDLwamHO9OwBA= To: Julien Laganier References: <20160705140143.22339.24069.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <102eb607-f1c5-9dc8-e7bb-fa5fd1daf838@cs.tcd.ie> Date: Thu, 21 Jul 2016 12:22:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060603090806050004050507" Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, HIP , hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Stephen Farrell's Discuss on draft-ietf-hip-rfc5203-bis-10: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 11:25:43 -0000 This is a cryptographically signed message in MIME format. --------------ms060603090806050004050507 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, That'd be fine for clearing my discuss. I'd encourage you to also get feedback from the WG though as I don't think I've ever seen a list of cert handling errors that was correct first time around:-) Cheers, S. On 20/07/16 16:11, Julien Laganier wrote: > Hi Stephen, >=20 > Thanks for reviewing the document. >=20 > I think there would be value in making the cause of certificate error > explicit. Would the following change be acceptable? >=20 > OLD: >=20 > If the certificate in the parameter is not accepted, the registrar > MUST reject the corresponding registrations with Failure Type [IANA > TBD] (Invalid certificate). >=20 > NEW: >=20 > If the certificate in the parameter is not accepted, the registrar > MUST reject the corresponding registrations with the appropriate > Failure Type: > [IANA TBD] (Bad certificate): The certificate is corrupt, contains > invalid signatures, etc. > [IANA TBD] (Unsupported certificate): The certificate is of an > unsupported type. > [IANA TBD] (Certificate expired): The certificate is no longer valid= =2E > [IANA TBD] (Certificate other): The certificate could not be > validated for some unspecified reason. > [IANA TBD] (Unknown CA): The issuing CA certificate could not be > located or is not trusted. >=20 > Please let us know. >=20 > Best, >=20 > --julien >=20 >=20 >=20 >=20 > On Tue, Jul 5, 2016 at 7:01 AM, Stephen Farrell > wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-hip-rfc5203-bis-10: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> 3.3 - This fails to distinguish between an invalid >> certificate (e.g. bad signature, unknown signer) and one >> that is valid, but is not acceptable for this purpose. I >> don't get why that is ok for HIP, can you explain? If it >> is ok, I think you need to say so. If it is not ok (as I'd >> suspect) then you appear to need to change text or one more >> new error code. >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> Section 7 - I'm fine that this doesn't repeat stuff >> from 5203, but a sentence saying to go look there too >> would maybe be good. (I'm not sure if that would fix >> Alexey's discuss or not. If not, then ignore me and >> just talk to him about his discuss.) >> >> --------------ms060603090806050004050507 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MjEx MTIyNDhaMC8GCSqGSIb3DQEJBDEiBCAIZGeSOVlDf8BbCvRwX3Lr2W+wBq5mcqx+zywyjn8t TTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAFNvMC9/AEmPYmiY1Kja/zzjifNhUSTvznwlqpvvrIXPqymhqNuCRq Oqe7DXR/Yu50hUi3PpHl1vBfUUEuT8e0yrdtK2itD4I8SwZF+zISHr0EMj/O4bbxZPjgYxUr nq0RxCMdvmxHNKZ0CIiRiuOAta/99WETBmw70mxFFLSQUcVTvj4F0cAwiwvAnaECvT1XFGy7 Z5z0ArlRrliLT9lR/xSQkIIWADSnb2d1aJu2TBuWdSneYoWtpDzfE6XK7gKTCIPD+GgUc9JN k1GXNX7Bs1SnrJx/VTQ7N3t9RqO/UgLNN+TNpHYjN9ATemQ0BfXUWSfYAycmLbcfCsVrRsCK AAAAAAAA --------------ms060603090806050004050507-- From nobody Thu Jul 21 07:35:47 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524CB12D5C0; Thu, 21 Jul 2016 07:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 G4qjwsrbchnm; Thu, 21 Jul 2016 07:35:39 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 6F71412B058; Thu, 21 Jul 2016 07:35:38 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id l72so120372786oig.2; Thu, 21 Jul 2016 07:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FH/nwrNpF7xmf5zMbgzPu0z7PkkQtYd9SVtRWYvd98U=; b=q8mzD8VcLWtXJfGqvBgc2MOP6iiYHWCyaG/YNri/c68TZ85z8wdtU8dbW9NWg7BD3U o8e6yxoZHxfB1eyPlOrUji8wmF+nZ4JmA0O7c/rq2yMDVPDq/onEo9YTHap2JMgzflc8 EP5sH59EpzHvdOOlFe1q5tFjPWKgn1Xce4Jk1YLilgCR04+d5Bg+HvW5bNddO6l1U3j3 Qsy5cdpa+S/Ft7COi8H3RwMQj0g89ADIESRsPp2OEogtS2kVH6XYqibrzi7Gf2lQ369v AU8nBe8pqsX0KhcdQrRCvluc237lV1cOV0Tx1p5U9mSrhXqkzH8WMjeRWMUFw+gC4bwP 3IAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FH/nwrNpF7xmf5zMbgzPu0z7PkkQtYd9SVtRWYvd98U=; b=K/hmsYmfsYrK6mJGGjWhXZopQjk9jRSOSXeAzcQ/jwN2k5uYz5PgEftWeRdw0zsfma oFbXe+zae/Z8y2sBcuKhGwItJpmFQmx2UVm/jLF7A7BddylwEDuP5vPKOUUJND32zacy 6GDDx+YM2h5xcuNHvT9LOZ7DtSE0jD4AMdzP2km6txNvv/XTQ/qPbbMqTqdT+3owEDaU i7DYU+HfbkEzTb6WsJiyNdKD/XBoQvQu8DOy6LVBz8N587L06ETmVeTy/5TZImYY5ZtW X0TysiGQA/vCn2Y0u9R3IH9XeJzIsxUffqWGHC29yEOU/Zysqv5VbpPHTli67dSR82EY r/zw== X-Gm-Message-State: ALyK8tJ0ykgaZ/XOyMMgC/vM2gxYMw0DiwnmfSuUI3g+OWBJM5Dy20E/H8SAYCtc5VPBcLm72FY8GonYHxvB9g== X-Received: by 10.202.84.72 with SMTP id i69mr26092973oib.93.1469111737850; Thu, 21 Jul 2016 07:35:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.164 with HTTP; Thu, 21 Jul 2016 07:35:37 -0700 (PDT) In-Reply-To: <102eb607-f1c5-9dc8-e7bb-fa5fd1daf838@cs.tcd.ie> References: <20160705140143.22339.24069.idtracker@ietfa.amsl.com> <102eb607-f1c5-9dc8-e7bb-fa5fd1daf838@cs.tcd.ie> From: Julien Laganier Date: Thu, 21 Jul 2016 07:35:37 -0700 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, HIP , hip-chairs@ietf.org, The IESG Subject: Re: [Hipsec] Stephen Farrell's Discuss on draft-ietf-hip-rfc5203-bis-10: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 14:35:45 -0000 Thanks, Stephen. The HIP WG was CC'd on these emails so participants have seen the proposal, I will seek their feedback in a separate note. Best, --julien On Thu, Jul 21, 2016 at 4:22 AM, Stephen Farrell wrote: > > Hiya, > > That'd be fine for clearing my discuss. > > I'd encourage you to also get feedback from the WG though as I > don't think I've ever seen a list of cert handling errors that > was correct first time around:-) > > Cheers, > S. > > > > On 20/07/16 16:11, Julien Laganier wrote: >> Hi Stephen, >> >> Thanks for reviewing the document. >> >> I think there would be value in making the cause of certificate error >> explicit. Would the following change be acceptable? >> >> OLD: >> >> If the certificate in the parameter is not accepted, the registrar >> MUST reject the corresponding registrations with Failure Type [IANA >> TBD] (Invalid certificate). >> >> NEW: >> >> If the certificate in the parameter is not accepted, the registrar >> MUST reject the corresponding registrations with the appropriate >> Failure Type: >> [IANA TBD] (Bad certificate): The certificate is corrupt, contains >> invalid signatures, etc. >> [IANA TBD] (Unsupported certificate): The certificate is of an >> unsupported type. >> [IANA TBD] (Certificate expired): The certificate is no longer valid. >> [IANA TBD] (Certificate other): The certificate could not be >> validated for some unspecified reason. >> [IANA TBD] (Unknown CA): The issuing CA certificate could not be >> located or is not trusted. >> >> Please let us know. >> >> Best, >> >> --julien >> >> >> >> >> On Tue, Jul 5, 2016 at 7:01 AM, Stephen Farrell >> wrote: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-hip-rfc5203-bis-10: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> 3.3 - This fails to distinguish between an invalid >>> certificate (e.g. bad signature, unknown signer) and one >>> that is valid, but is not acceptable for this purpose. I >>> don't get why that is ok for HIP, can you explain? If it >>> is ok, I think you need to say so. If it is not ok (as I'd >>> suspect) then you appear to need to change text or one more >>> new error code. >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> Section 7 - I'm fine that this doesn't repeat stuff >>> from 5203, but a sentence saying to go look there too >>> would maybe be good. (I'm not sure if that would fix >>> Alexey's discuss or not. If not, then ignore me and >>> just talk to him about his discuss.) >>> >>> > From nobody Thu Jul 21 07:39:41 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B94012D666; Thu, 21 Jul 2016 07:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 5RCZMiuGjPwM; Thu, 21 Jul 2016 07:39:36 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 247BC12D67D; Thu, 21 Jul 2016 07:39:31 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id l65so120255895oib.1; Thu, 21 Jul 2016 07:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=01xb8avQf0RP+IW8cX8F8NuD+LQa1chVKNukW3I5pPk=; b=N9aMrVrXb80roTr+4TAeL/ae9zltD07gUtW/TcH+XId4ZoqRHklkrS4CCq/EQyyaOh FGfhcxqDq/z0FD4vVmu3Mb5IN/zeoexyGe2+3rmNi6DqHKd0I2Os8s2uRTXD7Q5iZyIA A1mve0+BFthK3hJtu5xX4IOYJR3cGHV1ufKx/YCpru2HMGFGKWVTd7dFVWpgkWdwnBg2 vzQY+7UP7kVaKFTRpH/ywUro+P7pHuXxLFGcgXunpZqv3aGTHo9GgSYlYhpZAL66bRAh oFBJuVoX3osSdxM2zw686JOHWO2rXZqEPJJeoG+QOfnwsDCQK82FkoEybMGozw9YbF+w vlNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=01xb8avQf0RP+IW8cX8F8NuD+LQa1chVKNukW3I5pPk=; b=S3HnOVH1/PygYM6rqp7wh/Rp6aT+Day30KlGHOo4BUMZ4qw8WnqFScPqQAlFJnnP/p RwvbzWKSGxIJ2dFyFyR+Q8S8vwRbryJvMoY1Qhw+ggM6KzWV8JXpzzs7nWL6cp0CpPUo yIWRn4HHWy0TZ/hWN5XffGXs+sIp7rivML+WGde4AvxfOUUPLDRHeYqGw/ZxTR1cqRSn JKZdWJq2bkgYtVhZXCkHFbkL7JBSiJI8f3LTFAI4gmSX3Yifw/BbwjwnCJi4AvRLap0V NU8BVTeDYT9UNR8piYlF7wSFYHWill6LrQM27WcJN1TTOMj2OrjsgaHA98R3A9Hw9fEb Qusg== X-Gm-Message-State: ALyK8tImXdNF4Pse5EMpKOZZHagYOlxG7FQQ5awJSx6I+FOKXWRGVYXNo9WOC2GNET389ANhRR2bZXlFBNeMDA== X-Received: by 10.157.39.114 with SMTP id r105mr31981030ota.136.1469111970452; Thu, 21 Jul 2016 07:39:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.164 with HTTP; Thu, 21 Jul 2016 07:39:30 -0700 (PDT) In-Reply-To: References: <20160705140143.22339.24069.idtracker@ietfa.amsl.com> <102eb607-f1c5-9dc8-e7bb-fa5fd1daf838@cs.tcd.ie> From: Julien Laganier Date: Thu, 21 Jul 2016 07:39:30 -0700 Message-ID: To: HIP Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, Stephen Farrell , hip-chairs@ietf.org Subject: Re: [Hipsec] Stephen Farrell's Discuss on draft-ietf-hip-rfc5203-bis-10: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 14:39:40 -0000 (trimming the whole IESG from the thread for now) HIP WG folks: Unless someone objects or has a better proposal, I intend to implement the following proposal to resolve Stephen's DISCUSS. OLD: If the certificate in the parameter is not accepted, the registrar MUST reject the corresponding registrations with Failure Type [IANA TBD] (Invalid certificate). NEW: If the certificate in the parameter is not accepted, the registrar MUST reject the corresponding registrations with the appropriate Failure Type: [IANA TBD] (Bad certificate): The certificate is corrupt, contains invalid signatures, etc. [IANA TBD] (Unsupported certificate): The certificate is of an unsupported type. [IANA TBD] (Certificate expired): The certificate is no longer valid. [IANA TBD] (Certificate other): The certificate could not be validated for some unspecified reason. [IANA TBD] (Unknown CA): The issuing CA certificate could not be located or is not trusted. Thanks, --julien On Thu, Jul 21, 2016 at 7:35 AM, Julien Laganier wrote: > Thanks, Stephen. > > The HIP WG was CC'd on these emails so participants have seen the > proposal, I will seek their feedback in a separate note. > > Best, > > --julien > > On Thu, Jul 21, 2016 at 4:22 AM, Stephen Farrell > wrote: >> >> Hiya, >> >> That'd be fine for clearing my discuss. >> >> I'd encourage you to also get feedback from the WG though as I >> don't think I've ever seen a list of cert handling errors that >> was correct first time around:-) >> >> Cheers, >> S. >> >> >> >> On 20/07/16 16:11, Julien Laganier wrote: >>> Hi Stephen, >>> >>> Thanks for reviewing the document. >>> >>> I think there would be value in making the cause of certificate error >>> explicit. Would the following change be acceptable? >>> >>> OLD: >>> >>> If the certificate in the parameter is not accepted, the registrar >>> MUST reject the corresponding registrations with Failure Type [IANA >>> TBD] (Invalid certificate). >>> >>> NEW: >>> >>> If the certificate in the parameter is not accepted, the registrar >>> MUST reject the corresponding registrations with the appropriate >>> Failure Type: >>> [IANA TBD] (Bad certificate): The certificate is corrupt, contains >>> invalid signatures, etc. >>> [IANA TBD] (Unsupported certificate): The certificate is of an >>> unsupported type. >>> [IANA TBD] (Certificate expired): The certificate is no longer valid. >>> [IANA TBD] (Certificate other): The certificate could not be >>> validated for some unspecified reason. >>> [IANA TBD] (Unknown CA): The issuing CA certificate could not be >>> located or is not trusted. >>> >>> Please let us know. >>> >>> Best, >>> >>> --julien >>> >>> >>> >>> >>> On Tue, Jul 5, 2016 at 7:01 AM, Stephen Farrell >>> wrote: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-hip-rfc5203-bis-10: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> 3.3 - This fails to distinguish between an invalid >>>> certificate (e.g. bad signature, unknown signer) and one >>>> that is valid, but is not acceptable for this purpose. I >>>> don't get why that is ok for HIP, can you explain? If it >>>> is ok, I think you need to say so. If it is not ok (as I'd >>>> suspect) then you appear to need to change text or one more >>>> new error code. >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> Section 7 - I'm fine that this doesn't repeat stuff >>>> from 5203, but a sentence saying to go look there too >>>> would maybe be good. (I'm not sure if that would fix >>>> Alexey's discuss or not. If not, then ignore me and >>>> just talk to him about his discuss.) >>>> >>>> >> From nobody Sun Jul 24 08:06:22 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A7612D0EF; Sun, 24 Jul 2016 08:06:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160724150620.19326.92360.idtracker@ietfa.amsl.com> Date: Sun, 24 Jul 2016 08:06:20 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-multihoming-10.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 15:06:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Host Multihoming with the Host Identity Protocol Authors : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-multihoming-10.txt Pages : 23 Date : 2016-07-24 Abstract: This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-multihoming-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-multihoming-10 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 27 06:12:11 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267F012D0FA; Wed, 27 Jul 2016 06:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 alfAaWkMhKS7; Wed, 27 Jul 2016 06:12:07 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 2DE8612D791; Wed, 27 Jul 2016 06:12:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id CB2EA621A8; Wed, 27 Jul 2016 09:12:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id roxzxdzH0vCj; Wed, 27 Jul 2016 09:11:48 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [209.65.105.133]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2E4FD621A7; Wed, 27 Jul 2016 09:11:39 -0400 (EDT) To: Julien Laganier , HIP References: <20160705140143.22339.24069.idtracker@ietfa.amsl.com> <102eb607-f1c5-9dc8-e7bb-fa5fd1daf838@cs.tcd.ie> From: Robert Moskowitz Message-ID: Date: Wed, 27 Jul 2016 06:11:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-hip-rfc5203-bis@ietf.org, hip-chairs@ietf.org, Stephen Farrell Subject: Re: [Hipsec] Stephen Farrell's Discuss on draft-ietf-hip-rfc5203-bis-10: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 13:12:10 -0000 Sorry for being late to the show. Email and health problems then catch up times... I agree. On 07/21/2016 07:39 AM, Julien Laganier wrote: > (trimming the whole IESG from the thread for now) > > HIP WG folks: > > Unless someone objects or has a better proposal, I intend to implement > the following proposal to resolve Stephen's DISCUSS. > > OLD: > > If the certificate in the parameter is not accepted, the registrar > MUST reject the corresponding registrations with Failure Type [IANA > TBD] (Invalid certificate). > > NEW: > > If the certificate in the parameter is not accepted, the registrar > MUST reject the corresponding registrations with the appropriate > Failure Type: > [IANA TBD] (Bad certificate): The certificate is corrupt, contains > invalid signatures, etc. > [IANA TBD] (Unsupported certificate): The certificate is of an > unsupported type. > [IANA TBD] (Certificate expired): The certificate is no longer valid. > [IANA TBD] (Certificate other): The certificate could not be > validated for some unspecified reason. > [IANA TBD] (Unknown CA): The issuing CA certificate could not be > located or is not trusted. > > Thanks, > > --julien > > > On Thu, Jul 21, 2016 at 7:35 AM, Julien Laganier wrote: >> Thanks, Stephen. >> >> The HIP WG was CC'd on these emails so participants have seen the >> proposal, I will seek their feedback in a separate note. >> >> Best, >> >> --julien >> >> On Thu, Jul 21, 2016 at 4:22 AM, Stephen Farrell >> wrote: >>> Hiya, >>> >>> That'd be fine for clearing my discuss. >>> >>> I'd encourage you to also get feedback from the WG though as I >>> don't think I've ever seen a list of cert handling errors that >>> was correct first time around:-) >>> >>> Cheers, >>> S. >>> >>> >>> >>> On 20/07/16 16:11, Julien Laganier wrote: >>>> Hi Stephen, >>>> >>>> Thanks for reviewing the document. >>>> >>>> I think there would be value in making the cause of certificate error >>>> explicit. Would the following change be acceptable? >>>> >>>> OLD: >>>> >>>> If the certificate in the parameter is not accepted, the registrar >>>> MUST reject the corresponding registrations with Failure Type [IANA >>>> TBD] (Invalid certificate). >>>> >>>> NEW: >>>> >>>> If the certificate in the parameter is not accepted, the registrar >>>> MUST reject the corresponding registrations with the appropriate >>>> Failure Type: >>>> [IANA TBD] (Bad certificate): The certificate is corrupt, contains >>>> invalid signatures, etc. >>>> [IANA TBD] (Unsupported certificate): The certificate is of an >>>> unsupported type. >>>> [IANA TBD] (Certificate expired): The certificate is no longer valid. >>>> [IANA TBD] (Certificate other): The certificate could not be >>>> validated for some unspecified reason. >>>> [IANA TBD] (Unknown CA): The issuing CA certificate could not be >>>> located or is not trusted. >>>> >>>> Please let us know. >>>> >>>> Best, >>>> >>>> --julien >>>> >>>> >>>> >>>> >>>> On Tue, Jul 5, 2016 at 7:01 AM, Stephen Farrell >>>> wrote: >>>>> Stephen Farrell has entered the following ballot position for >>>>> draft-ietf-hip-rfc5203-bis-10: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> 3.3 - This fails to distinguish between an invalid >>>>> certificate (e.g. bad signature, unknown signer) and one >>>>> that is valid, but is not acceptable for this purpose. I >>>>> don't get why that is ok for HIP, can you explain? If it >>>>> is ok, I think you need to say so. If it is not ok (as I'd >>>>> suspect) then you appear to need to change text or one more >>>>> new error code. >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> Section 7 - I'm fine that this doesn't repeat stuff >>>>> from 5203, but a sentence saying to go look there too >>>>> would maybe be good. (I'm not sure if that would fix >>>>> Alexey's discuss or not. If not, then ignore me and >>>>> just talk to him about his discuss.) >>>>> >>>>> > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Wed Jul 27 06:20:02 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9910412D7A8 for ; Wed, 27 Jul 2016 06:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 fnJW3n2brdEx for ; Wed, 27 Jul 2016 06:20:00 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 278C112D79D for ; Wed, 27 Jul 2016 06:20:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2C52762239 for ; Wed, 27 Jul 2016 09:19:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id u37USUKk1-lb for ; Wed, 27 Jul 2016 09:19:54 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [209.65.105.133]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id B7BF0621B0 for ; Wed, 27 Jul 2016 09:19:53 -0400 (EDT) To: HIP From: Robert Moskowitz Message-ID: <76ef2589-9016-cdde-afb2-99224327effd@htt-consult.com> Date: Wed, 27 Jul 2016 06:19:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Hipsec] Using a PAKE within HIP for enrollment X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 13:20:01 -0000 I am looking at a HIT enrollment function using 5403-bis. But why should the Registrar accept the Register. This is our basic need of an Out-off-Band process to trust an enrollment. So assume that some process establishes a PSK between the two parties. Perhaps a failed enrollment that sent the phone's # that returns an SMS message with the PSK. The enrollment then grabs that PSK and uses a PAKE HIP parameter for authentication. This would be stronger than what I have in DEX... I would like to get the draft done this week, or early next week. It is mostly written. But I need to put in the trust for the enrollment. I can either lift what I have in DEX, or go with one of the PAKE efforts in CFRG. But which one and how would it work in HIP BEX/DEX? Thanks From nobody Wed Jul 27 06:34:48 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C423A12D0E3 for ; Wed, 27 Jul 2016 06:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 YtyHARxdJms4 for ; Wed, 27 Jul 2016 06:34:45 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 1FEF212B030 for ; Wed, 27 Jul 2016 06:34:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 290FF62218 for ; Wed, 27 Jul 2016 09:34:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fJDbtQBoPRW6 for ; Wed, 27 Jul 2016 09:34:30 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [209.65.105.133]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 8EDB9621D2 for ; Wed, 27 Jul 2016 09:34:30 -0400 (EDT) To: HIP References: <76ef2589-9016-cdde-afb2-99224327effd@htt-consult.com> From: Robert Moskowitz Message-ID: Date: Wed, 27 Jul 2016 06:34:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <76ef2589-9016-cdde-afb2-99224327effd@htt-consult.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Hipsec] Using a PAKE within HIP for enrollment X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 13:34:46 -0000 I am going to just use the DEX authentication for now. But moving to a PAKE-styled authentication, given that we have a DH exchange is rather enticing. Dragonfly may be easy to do; I did follow it in 802.11. But maybe one of the others might be where cfrg is headed and where I should look at? On 07/27/2016 06:19 AM, Robert Moskowitz wrote: > I am looking at a HIT enrollment function using 5403-bis. But why > should the Registrar accept the Register. This is our basic need of > an Out-off-Band process to trust an enrollment. > > > So assume that some process establishes a PSK between the two > parties. Perhaps a failed enrollment that sent the phone's # that > returns an SMS message with the PSK. The enrollment then grabs that > PSK and uses a PAKE HIP parameter for authentication. This would be > stronger than what I have in DEX... > > > I would like to get the draft done this week, or early next week. It > is mostly written. But I need to put in the trust for the > enrollment. I can either lift what I have in DEX, or go with one of > the PAKE efforts in CFRG. But which one and how would it work in HIP > BEX/DEX? > > > Thanks > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec >