From nobody Tue Sep 4 14:13:06 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B023130F5C for ; Tue, 4 Sep 2018 14:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FxiaGAqxZzI for ; Tue, 4 Sep 2018 14:13:00 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC2D130F02 for ; Tue, 4 Sep 2018 14:13:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E2438300A54 for ; Tue, 4 Sep 2018 17:12:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dlz2n1DzCvSn for ; Tue, 4 Sep 2018 17:12:56 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id E3E24300435 for ; Tue, 4 Sep 2018 17:12:55 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_31F4D8FA-B4D1-4EF7-A5B2-B852AE8530F7" X-Priority: 1 Date: Tue, 4 Sep 2018 17:12:56 -0400 References: To: IP Wireless Access in Vehicular Environments Discussion List Message-Id: <17A52E1D-A0C2-485B-B95F-E520BC8E4B9B@vigilsec.com> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [ipwave] Fwd: Creation of a new ITU-T Focus Group on Vehicular Multimedia (FG-VM) and its first meeting to be held in Ottawa, Ontario, Canada on 11 October 2018 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 21:13:03 -0000 --Apple-Mail=_31F4D8FA-B4D1-4EF7-A5B2-B852AE8530F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This may be of interest to some people on this mail list. > From: "Polidori, Stefano" > Subject: Creation of a new ITU-T Focus Group on Vehicular Multimedia = (FG-VM) and its first meeting to be held in Ottawa, Ontario, Canada on = 11 October 2018 > Date: August 31, 2018 at 5:39:22 AM EDT > To: "cits@lists.itu.int" > Cc: "TSB FG VM Secretariat, ITU" , = "harry.li@gvmedia.com.cn" , Gaelle = Martin-Cocher , "t17sg16all@lists.itu.int" = , "Campos, Simao" > Resent-From: > Resent-From: wg-alias-bounces@tools.ietf.org > Resent-To: housley@vigilsec.com, cjbc@it.uc3m.es > Resent-To: ipwave-chairs@ietf.org >=20 > Dear colleagues, > =20 > I am very pleased to announce to you the establishment of a new ITU-T = Focus Group on Vehicular Multimedia (FG-VM) = and its first meeting that will be held in Ottawa, Ontario, Canada on 11 = October 2018, kindly hosted by BlackBerry. > =20 > The aim of this new FG is to analyze and identify gaps in the = vehicular multimedia standardization landscape and to draft technical = reports and specifications covering, among others, vehicular multimedia = use cases, requirements, applications, interfaces, protocols, = architectures and security. > =20 > More details on the first FG-VM meeting objectives, including = logistics information, can be found in the TSB Circular 110 = . > =20 > Attending the FG-VM is free of charge and open to all interested = stakeholders.=20 > For the =E2=80=9Crequired=E2=80=9D online registration, please visit = the FG-VM homepage: https://itu.int/go/fgvm .=20= > =20 > Key deadlines for the 1st FG-VM meeting: > 11 September 2018 (soft deadline) > - Submit requests for visa support letters (see Annex 3 of Circular = 110 ) > 4 October 2018 > - Pre-registration (online via the FG-VM homepage = ) > - Submit written contributions (by e-mail to tsbfgvm@itu.int = ) > =20 > We look forward to your participation at this important meeting. > =20 > PLEASE NOTE: Few days before the FG meeting, the ITU and SAE = International are organizing a workshop on "How communications will = change vehicles and transport ", from 8 = to 9 October 2018, in Detroit, MI, United States. Participation in the = workshop is also free of charge and open to all. More details about the = workshop, including online registration, can be found at = http://itu.int/go/ITS-SAE/2018 . > =20 > For any questions, please contact: tsbfgvm@itu.int = > =20 > Best regards, > =20 > Stefano Polidori > Advisor > Study Group 9, CITS, FG-VM and TSAG RG-WM > TSB, Study Groups Department > International Telecommunication Union > Tel : +41 22 730 5858 | Mobile : +41 79 599 1413 > stefano.polidori@itu.int > http://www.itu.int/go/tsg9 > https://www.itu.int/go/cits > https://www.itu.int/go/fgvm > --Apple-Mail=_31F4D8FA-B4D1-4EF7-A5B2-B852AE8530F7 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_F90D98E5-60BD-4A09-BF53-89202944E15C" --Apple-Mail=_F90D98E5-60BD-4A09-BF53-89202944E15C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = may be of interest to some people on this mail list.



From: "Polidori, Stefano" <stefano.polidori@itu.int>
Subject: = Creation of a new = ITU-T Focus Group on Vehicular Multimedia (FG-VM) and its first meeting = to be held in Ottawa, Ontario, Canada on 11 October 2018
Date: = August 31, 2018 at 5:39:22 AM = EDT
To: = "cits@lists.itu.int" = <cits@lists.itu.int>
Cc: "TSB FG VM Secretariat, ITU" <tsbfgvm@itu.int>, "harry.li@gvmedia.com.cn" <harry.li@gvmedia.com.cn>, Gaelle Martin-Cocher <gmartincocher@blackberry.com>, "t17sg16all@lists.itu.int" <t17sg16all@lists.itu.int>, "Campos, Simao" <simao.campos@itu.int>
Resent-From: = <alias-bounces@ietf.org>
Resent-From: = wg-alias-bounces@tools.ietf.org
Resent-To:= housley@vigilsec.com, = cjbc@it.uc3m.es
Resent-To:= ipwave-chairs@ietf.org

Dear = colleagues,
 
I am very pleased to announce to you the establishment of a = new ITU-T Focus Group on Vehicular = Multimedia (FG-VM) and its first meeting = that will be held in Ottawa, Ontario, Canada on 11 October 2018, kindly hosted = by BlackBerry.
 
The aim of this = new FG is to analyze and identify gaps in the vehicular multimedia = standardization landscape and to draft technical reports and = specifications covering, among others, vehicular multimedia use cases, = requirements, applications, interfaces, protocols, architectures and = security.
 
More details on = the first FG-VM meeting objectives, including logistics information, can = be found in the TSB = Circular 110.
 
Attending the FG-VM is free of charge and open to all interested = stakeholders. 
For the =E2=80=9Crequired=E2=80=9D online registration, = please visit the FG-VM homepage: https://itu.int/go/fgvm. 
 
Key deadlines for = the 1st FG-VM = meeting:
4 October = 2018
11 September 2018 = (soft deadline)
- Submit requests = for visa support letters (see Annex 3 of Circular = 110)
- = Pre-registration (online via the FG-VM = homepage)
- Submit written = contributions (by e-mail to tsbfgvm@itu.int)
 
We look forward = to your participation at this important meeting.
 
PLEASE NOTE: Few days before the FG meeting, the ITU and SAE = International are organizing a workshop on "How communications will = change vehicles and transport", from 8 to 9 October 2018, in = Detroit, MI, United States. Participation in the workshop is also free = of charge and open to all. More details about the workshop, including = online registration, can be found at http://itu.int/go/ITS-SAE/2018.
 
For any questions, please contact: tsbfgvm@itu.int
 
Best regards,
 
Stefano Polidori
Advisor
Study Group 9, CITS, FG-VM and TSAG RG-WM
TSB, = Study Groups Department
International Telecommunication Union
Tel : +41 22 730 5858 | Mobile : +41 79 599 1413
3D""Committed

= --Apple-Mail=_F90D98E5-60BD-4A09-BF53-89202944E15C Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=image001.gif Content-Type: image/gif; x-unix-mode=0666; name="image001.gif" Content-Id: R0lGODlhyABYAPcAAEY8flwydXgqazo9ggBKlQxSmRtJjxNMlBdWnBtdoB5goShCiCFcnyNdoChk pDJmpTRopjRsqTlppzptqjVwqztzrDR2sz51sDx7tj19uEU/gF1km0Bvq0JzrUh1r0V2sEN6sUF+ uEt3sEt7slJ+s31PhXVYj2l7rEOBuk2BtUqEu1OBtVOGuVWJu1qDtluGuF6LumGHumCOvGmNvWSR vmuRvnqQvE6MwlSNwVqUxmKOwWaSwGOczGuUwW6Yw22cyXKVwnSaxHObyHiXwnqbxXqeyWmhz2qi 0Xqgx3yiyXaq1X2z3JcfX4YlZYs3dJIgYqoWV7YUU7YlX7c3bcMMTM4LSs4YUtMARdQFSNUMR9MK SdkIS9YPUNESTtAVUNQZUskmXNQkWtQpXdklW9krXMYrYco2aNspY9Q1ZdoxYt47cchNecxRe9tD bttEct9IedZUfOBKe5VMg7RbiKxvmql1n7hjjrJmkLtxl6d6o7d6oMNahN1kidR3mOReiuVijOd0 m+h6no6Cq4qGsZKKtZqUuqSDq72PsoGexoOkyoWozImmy4uqzYKs04yt0Im12ZKrzpKu0Jiu0JSy 0pO22ZW425q11J251pu52oi84pK/5KC21aO61qO82aq00aq+2bu2z7u81ZjD5aXA26vC27HF3bPI 3rrK36PG5aTJ5qTK6KvG4azJ5avN6a7Q67HH4bTK4rHO6bvM4rPR673Q5LrV7L7Y7s+LqNiKqteW rs2hvOKGn+SNpOuIqeuTqeKiteCkuOyms+qsvcSuxuWswOK1w+qywvGrw/K0yPO6zfS90M/E2MDO 4sPT5cTW6sPZ7snW5snW6MjY58va6sXc8Mne8NfY5tLd69rd6M3h8dXh7dnj7tPk89vl8d3p9OLA zefN2e/G0O7M1ebQ2vXE1PbI1/bI2PLT3ePd5/Ta4eTh6uDm8ePr9OTu+Onu9ejv+ebw+Ovx9uzy +ffh5/rj6vzt8vHy9vL1+fX4+/zx9f32+f7+/gAAAAAAAAAAAAAAACH5BAEAAP8ALAAAAADIAFgA AAj/APcJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGMezKdPps2bLpPh3MmzpDJzPYMK3ZgPUL6hSJNKPNZLqdOnCuOUg0q1KjI19apqVarPTaCG+OKx YxcP39azKJNx0WlQXjNLSYgUSeTIUaIiQYgwauYOrV+Qcc7QI9gsCJBO1+QpXgxPXrt2sCokSiTL 7N/LGMlp+SPQVJAInOThu3cPH77Fj9s5gxUEE7dOQUhhnl3RDxZcQSzV6JEECJAePXwHSYSp2aQa jjpN+vBCkbNRPZrRnv7wHJcqg0gkmuautOnR8ro1/4MRg4ilae1kJaIlJMk0R4zuUZ+PMN4KJ1fQ 2GBHerTp0qTdA4Q87KjXwys9cNMNLDLUAgsQ3dAnoUDajGCJOmRcwYY9/X333z3yBKEYPO2wM0kF PThSBA4TqADDCtNMON82MkwDDzy/XHEFLx4O9KGIjqk3XAUiuPaMDNU800M0MtLGToLstKOYG1do YYxl+1j2nSWdMNLDed54M8okjQAxzSpJZGNLD9o0eZk8NUbZTmPgdHHFF+FgKZBp0RAxgSyOPeYN Nz10U4sOnfTwzDOzyCCfm2glkYg3JUpJoBw6jpEOQfhcU0Qk7GwDoaDteJOEM9xUk8QFtTxjyypE QP96VjMOVBNmaoohYoaOZMwjUDyQLMKfYt3UAEuUYa4yCTfcZPPCDs/UUosSpcha1T1B9HBrlMX8 QswheOh4RRrpNANENKORphg7jgghS5jd7NANN6MIgYoOtcwSyw7xWAsVJ6toG2aUwIhr8BViFCJa gIzJc40jPRRByQgQF/FMNZ3IMIsrj0zir1PxBDFNEWFSWmIbB4tLhjjpolZpmNXAIoQj1GSTJDWU 6OBKKzg8+vFQpXRCaMneRPlNyuJ+QcxpI8KDbKnz0pJIs9VQE60SP6jS8c9IBZHN0LeWCA8fSOuo xS7xjPgYOyUzW02C1VQt7Sw7PILKDlwLxU4SzPb/kA3RJaITRtk6ujHO2qW2zewONieZryuoqCAK DtAMdE8KiRwkDyk+U2RKhNOAEGFEI3gs4yWwNOYMO4rdM6dp5Pgi++y0+xKMPY6JtphihMZta9uy 1MKDIgPF4wAN+5hyySSP2MNOCgUwso88lyRhyj7xODKKbJaMosgoApWSBCPe4BMEATDco00P7OzT TBKKSGciKdvtc88kSVxiWgJJNElENu4AwgwGOANAycMUBEygAgdoCXzwhwgEBMI7uCGEWlTtHkT4 DRCI4I4dpKB4x9uHDBAwCQRwImQIgMU+kpAAJCCgGd0gQAU4pwAQIKEA2rjHDoLgABjsgxQEUAQ+ /2RBgGtMAwGKcKE3aFEAJICgAvuYBgx8UADZKAAJMsIWN9aBAAJ4kQCQUEwivkjGMnrRBfgoGgO+ iIB5JWEW1KCGPLroRQSswwEqkMevHCCDfcCAAvFQwCP2UUJa+JF/IIAhAap1DwUEgYnTaEYBfOCA D2qDAB6DRRElSQpLFOAakmxGDxywQgQEoQCd2EcLZcSORlSDi2SERGMYgYBaIqAAZbQlAmKQRnc0 gI2DSgIsFjVHNrIjAjfYxp564LFJBCEeNbieNlLgA/XBoAXPZEcLYoQPH3RCGzDYBjtgQAMfEA8f NEgBO7TRAm8QkgUtuMQ+wNmNS/hgH7BIARJgYP/IHYBvQtJwxCvp6EVZrmss7iACGRFwDXasgx0c Ktov69iNbCShFa4qZh23AQIUyCJvO5FFJajRDYKCETKTCpM8xvhFBrDNEkCAxcAmSoA2WpQV0tJo TdmRCQukEqQ3IUUlnsEOk0KiHT54RjeWutKFugNmEMMEO2jaxmoIAae10CkCeGoB022DBmDdwU8t F4TrsaQbNIjRQvAhDbOQIghU6QQllGrUZhSBWcyCxyLIyAB15IJZ3cDYNtZI0bfFYhaz0Co7NKEC 4u3DHaMAAQLOs49rjCJGxiPePWBBivZVdhSVsZ8sLisQWkzDFNo4rVmacVojci6K0xhi+2hxDVP/ xGhvynQHKTorkGaMQjrx6AECwAcLx1oWFvLRhmlLoSeZkCIJtYDlFyExA6HhtR0srSM6tNCHbeB1 qmzUBiZU8IhHKKGobHRHJnIwyIGMUo+lKIBwSWG8JOAjBQ5ogQPwQYroVYB4K3AALTtxDwdEQLI7 IOE+IuCAFcgXifuoAAu0UcVAUmAFCHDHNAoAC3nktwcgiEfoaIDKcRbAY0hIwA8LoAgKfDAJBQgC AjKHE1m0oBYljWUndgCL6+61perIwhXgcA1mgbeO2qBEB5SgiEegt46LNQInCLIDB/RLETFOQScC qQgPV8AHIU4CAu7RiU54mAbtcKSHfTCJAnjD/wH9o4AMgLiNCPRgHyBIAScDmYRX4HDDsKAwJ66h iHh0wgGnbCYC2oQEBZTSHT1QwD2SoADj4Q0n03DALHI8XW9QQwerYBZ2F6oOcaFhGdk4ck27MYsc xKIVrVBsJnhgVoEoAgTy4SgIQDANeViIkBTAAFy9sYILXECFo6hAnss3AkaMggLP81gLkiCLCHij BcS7RA8pgFwQWIIWFPCGNiggnSRUoAJYHAUfKYAJ91VyH48YwT68kYILVAB8kwjxChx7E3ZQ4BGc Lqg34sbMVP/Yiy7tgxZ09AVdGI+MpZDFRVVBDWaQ0QE8zcE1gHoTfOygBQEHo6erloQijDq92f+4 xcKrJIwaXBxQrKMVGWXAjUzgoF8ct0kQfnDEWHLDFs+gRjUwEYmDE8ClcdOFna7QBmuYlAAO+MAD cgkNVdjcR5aQzjRMV5BnTKK5OedIJwBuVG5IC+jU8EZ2a+qOOFJjGIO7gi9K8XQzIuAT2Zh1/36l gP4xogDxUB87piGfUgRBPuxwxjXMEo9teCO2Ya8IO3LQDQk4oAGX30Q2ECutWnBDEphvQAM4wA5b dD4UaKiSL7CBiKmb0QFEuEY2NJEJB0iH7/17RAHuQQsEwCCEjLBypmkQAeSVkAYIcETkK9KDEm1D Md6QBzVagVjEcgNEpAnVPfJV/VesQUdp8MX/OdDBjFJ8ohTM6IY8siGKTGQiAyjQo0A8nD4ZD7EA RyKlIirNiATszf+PgADwQAE+tHwTYQpGIAoo8AiTIwqpoAqw1gqx4ArVNwus8AMw0AjUF4GpsAfi ogVjAAeg4AquoArt535LgAI5ID0EMQkOUAEO4DG0cg1BAALAFg/jtgIU0D+WEAHuMAL3ZIASIQ85 kAmPkAGZwAKi4ICqAIEQGIERiApKwAI4QAmq4Al28AUp0wV28Aju5345kAFKgAOeRRBigXP40Bfy 0C/3gHP3MBZ70i9pI4QTwQlHYIQYkAGasIR8mAoP2IR/6IesAAkmIAWEoyNeQAdJcAMYYASZ/8Bk dCgT9wADKOgASsCHmMiHqCAKm6gHZrByhyguVCAIX0iGkSgTzVCEmYACFqAE7reHmYiJkGAGWBCK 4mIFeeCFmXAEU3aKMpEIrogDSqCCX/iFtHeMmaAJj3AHoIg0WFAGdaCLmbAEl+aLMSEPOLBed8gD KLAExfiNxVgIZZAyWlAGc1AI0uh+LVCG1ggT2nQEqrgEIaCK4PiNj2AHzWgFhVCPLfAM7XgT2qAC KFCMPJABd1iP33gCU2AwXZAH34gDhvSPN3ENFeCNxRiGPICQ7ocDRWgI4yguc6CLECmROzFOrviN PIABOGCRxXgD9PgIhgAG4gIGhLBNJMkT+P+QCPRYjMOogneoBCFwkMUIkx95BXwwGDe5EfjQDIrQ AzLwlFAZlVIplTQAA+DTDDjgiPUIjw7gABmQAzxwBEqgBPCIAyjgACYQB1twBWOgBzWwAzsAVjQA l3RZl3Z5l3hJA1O5l3zZl375l4AZmE/ZA3txEfhgCQ6AS2a0mIzpRQUAA93AXy0glF9oBAY5jWSZ A5qZA2V5CQ6zAU1ABVcABRrQmKZ5mqiZmqq5mqyJmgXgAPI0Ed0wAq2JmjPmTqbgA5ypBDkwj/W4 BPDoA5zTDTLmRQcQAFCABUwwALXZnM75nNCZmingThDxZtHZmArgAxvHDqaQBCmAAxy5meD/uQOJ wArsgA/T0AMJsJgLIABR8AQLcJ3yOZ/0aZoRwI5rVQH1uZgFQAGJ0AyBByLdoA3X0A0Byg60kAQR kJoD0AQCEJ/7GaES6pw26BCMMKGMiQAVAANBoAh1oQhB8Ed1h5oHAAAaYAAYmqIqyphcpxAPt6Iw GqMyiqEOIH8KAUQzWpsFoJg5iqEjKp9Pd0v8WWsJcT6NiQAjQARBMAHXuQKy0EVCWlOnqR5kVAA/ CqOExQkKxZpd5ADX8AERygDTEANkxAxrR0ZYtBAr0JgOAA3uUAqGd50Q4AIEIAPX0EUzsA2mOWYz QEanYHQzWgTNUFMusKCraaYE8AL7cKXP/9kBC9ZScMKYBagQLNCY03ANVMUIzEAKTBoEixAJzbAC i9AMMkAAk5F1IwAJzUACYAQENaB+MLUO9wAJMtQJVNoAnCALiLAPTFpT1XINI4AARCALssCqZAQE ssAMwTqsskCbL2AJgqpQNQAJiQANPVBTQACnTNoBn8AMi5AI7uAOiQABpcAANVB0ouRFI9AJzVAK E4UAsgGskLAOo3qtpnQKpWCoBEAEY/QCpdABBBAJMFAAiECszmoJiQAJQHAPUMcJf3oPrmdGK8AQ a7qYjlqqX3QNzNABrHUA0QCs29ANJNAM0HAA2wANI8AOwHoNdJdQPlgKE9AB7tAJMesOM/8QA+4g Ac3QDB5wDdJVAIlwDzKAq9rgAZzgDgQVCe4gAxzgAJywDUZbVJ3ADiTQWQggC9swArJwp5zQDBIg C50wAvbACBMwASKwD5AAAQNyteswAqegp4nADjIACUhbR0ErAwwgC90gAsygp137AMywCV+UdQfA Fz1QAe7wAJ9wDR7wCVz0CffACSPwCdDwQht7De7Ao2U0qUXKmI7Sq4l6D0waCevQAPEABAegDRfa DJ/gAPbgAlulUNsQCRNwDx3AAEILdfdAp7LADpAADZZAAvsAsKRARF+UCNuAABGwD3RaA/cwUa4L BF4UAffwAnVqDw9wDYK7CZXrDnsVcRP/sA9Bsw0dwAyDOr3DSwCf0AxtNEboV7tkur5ktAjdcAAZ hgiLJAuO+gmLq59etAjTQALlFwScwAkTgA902gPGsw2l4EXXEAnyBrAR15hwtRA4akbyJr1eBK4I cADXQAqOOgEOcA8kkGFA4AL70ABQNAENYA8x4LxICrEEMLEMsFWccLsEAASL2kYX+kWy0MAoPHWk cA1fdLa0SQBBvEjXYGWlOg2b8AD3QJvssAhAEA8x4HrsYAlfxD5dhA2Q8AD7EKzbsAhDcA8I0ADu 0MNe9MMEsLwd0L5DEA8uELFeBATaIAsuYAmfwA58tA8OQACnAA1QbL0NoA8v8Ey1tA5n/0pGRIoQ fMyYsnAPmwAJMbAC98AInbAOaltUwusA4dsBiaAOBDADZjwC+OAAlkDEyAMJCAAE+MDK0NAMLkAE CKCoi7AJ+2C9X4QN1+ACEiDJdHvEBNAA7GAuKwABkqy0IyBvD4AAp/sCBdYAzCu8iBADfVoKCSW9 kGAPiLBfMvAC8oB5JNxHi1AtFetFBOoCMuBLpEQCK4APiPCUM1dZB+Axn0AAtbsJSisCJCDDpvwA isoIU3bOZWRlDaEIGSoDk5AIf+wCkUAEvzQCpToBLvcAMrYC1isCLjcB51PJNbUIRGCljKBQDZAI kTADuESYHQAEJlU6tNkBjJAIdEwAEOPACIygnzAt0218PgwwBA3QAdfaACxNACQQCYnApMI6CaXq AJHQAw1Ayx3gck/dRdaMCGZMRkXdAR/Qpw4wBF3k0Ed9cUQAsB1ABH9MADn9xxOgwWuNS0DACCv9 o+3FEPfgvz161xhKAhPgAtsguHiNmh0AdgmxDWf914Y9n5bADLJAy4fNpusQEdtg14092ZRdnyBA nRGBD8GnuZXd2Z6dmg7wCIL9EPHQnXr5lDCQ2qq92lC52q792rAd27I927Rd27Yd231527q926xN A9SGc0kZ3MI93MRd3MZ93Mid3BkREAA7 --Apple-Mail=_F90D98E5-60BD-4A09-BF53-89202944E15C-- --Apple-Mail=_31F4D8FA-B4D1-4EF7-A5B2-B852AE8530F7-- From nobody Thu Sep 6 05:25:56 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358131293FB for ; Thu, 6 Sep 2018 05:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjM-VqmfTfhG for ; Thu, 6 Sep 2018 05:25:53 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 D8955128CF3 for ; Thu, 6 Sep 2018 05:25:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w86CPcD8032862; Thu, 6 Sep 2018 14:25:38 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 28CA9202773; Thu, 6 Sep 2018 14:25:38 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1AEB2202472; Thu, 6 Sep 2018 14:25:38 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w86CPbH2028435; Thu, 6 Sep 2018 14:25:38 +0200 To: Erik Nordmark References: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> From: Alexandre Petrescu Cc: its Message-ID: <0e20b930-5c45-2110-865e-6809332f06ec@gmail.com> Date: Thu, 6 Sep 2018 14:25:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 12:25:55 -0000 Le 18/07/2018 à 17:03, Erik Nordmark a écrit : > > I volunteered (or was volunteered) to review this document during the > ipwave meeting this week. > Here are my comments and suggested modifications. > > > Level 0. My assumption is that the OCB interface (in vehicles and > infrastructure nodes) are attached to a router, and not a host. Is that > correct? > That assumption has a significant implication on the subnet/ND material. > (And appendix H talks about hosts!) For completeness, I would like to add that there are some hw manufacturers proposing cheap dedicated 802.11-OCB boxes without IP forwarding functionality. These could be the ones to consider as Hosts. Often called a "DSRC box", it is an aftermarket add-on to a car. It beacons some messages (not IP) and receives others' beacons on the same interface. It does not run IP as of today. If it did IP it were an IP Host. I speculate a certain market future for such small cheap devices (under 100eur), as more and more highways are equipped with RSUs sending live data about traffic state. Also, some deployed Road-Side Units do send Router Advertisements on 802.11-OCB, even though they do not forward packets between their 802.11-OCB interface and their Ethernet interface. These would be Non-Forwarding Routers. One could consider them to be Hosts that wrongly send RAs instead of NAs. That said, I would not oppose the draft to not talk about these Hosts. The question would be what would be the implications to the subnet/ND material if we only discussed Routers. Alex > > > Section 4.5: "see the privacy considerations described in Appendix F." > I think the key privacy considerations are (or should be if something is > missing) in the security considerations section and not in an appendix. > Appendix F provides useful background and design considerations, but I > think this reference to appendix F is confusing. > > Section 4.3: > I think the section should explicitly say that at most the link-local > address can use the EUI-64 based interface identifier, by saying that > any other IPv6 address should use either RFC8064 or RFC7217. I think > that is the intent, but the wording doesn't make it clear. > > Section 4.6 first paragraph: > I don't understand why there needs to be a subnet prefix assigned to the > ephemeral connectivity between the vehicles in range. AFAIU that is > router to router communication which can use link-local IPv6 addresses. > The routing protocols I know can operate using link-local addresses. > > Section 4.6 third paragraph: > 802.11 does not provide reliability for the ND multicast messages. > Thus I don't think OCB is any different than 802.11 in this respect. > I think this paragraph can be removed. If not, it should say the > opposite of that it says right now. > > Section 4.6 forth paragraph: > I don't know why one would have a mobile host directly attached to the > OCB link. My understanding is that only routers are attached to the OCB > link. Is that correct? > > In summary I think section 4.6 should say that the OCB link might not > have any IP address prefix apart from the link-local prefix. > > If it does have some other IP prefix, then one would need to determine > who would advertise that/those prefixes (will the infrastructure nodes > send RAs with prefixes? Each vehicle??) > > After the reference to RFC5889 it might make sense to explicitly restate > this from that RFC: >    o  no on-link subnet prefix should be configured on such an >       interface. > > RFC5889 seems to suggest that it would be useful and in some cases > required to configure a non-link-local address for the OCB interface. > But such an address would probably need to be checked for uniqness in > the routing domain, and it isn't clear to me whether that would fit the > timing requirements for v2x. > > Section 5 IPSec and SeND discussion. I'll defer to security experts on > this. I suspect it requires a separate draft to specify how IPsec and/or > SeND can be part of a security solution. > > Section 5 last paragraph. I think this section should say at the instant > the MAC address is changed on the OCB interface, the node needs to also > change all of the IIDs on the OCB interface (link-local and any globals). > > Section 5 last paragraph. I don't understand what this text is trying to > say and I suggest it be dropped: >    On another hand, it may >    have an impact in the way typical IPv6 address auto-configuration is >    performed for vehicles (SLAAC would rely on MAC addresses and would >    hence dynamically change the affected IP address), in the way the >    IPv6 Privacy addresses were used, and other effects. > > The actual policy for when the MAC address is changed on the OCB > interface is presumably to-be-determined. Might make sense to note that > in the text. I note there is some mention of this in appendix C thus it > might make sense to add a reference to that appendix. > > Appendix C last paragraph: > The "may have an influence" followed by the reference to 4.6 seems to > imply that something special is going on in section 4.6 which isn't > there. That's confusing. I suggest dropping that paragraph. > > Appendix F.4 uses the term pseudonyme without ever defining it. Hence it > isn't clear what the stated requirement is. > > Appendix H refers to a geolocation database and a GeoIP, yet the > changelog claims that those concepts have been removed from the > document. (I don't know how useful appendix H is to an implementor. It > isn't about how to implement things but what wireshark will show so > doesn't match the name of the section.) > > Appendix I seems misplaced. > If the reader needs to know these terms, then they should be in the > terminology section and not in an appendix. If the reader doesn't need > to know then, then they don't need to be in the document. > > Note that the document has a lot more of appendix text than body text. > It is a 15 page document with 25 pages of appendices. > I don't know how useful those appendices will be to a new reader; they > might have been useful as part of producing the document. But might want > to consider which part of the appendices are still needed. > >    Erik > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Thu Sep 6 05:43:13 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28104130E6B for ; Thu, 6 Sep 2018 05:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 CB--frZwGfTW for ; Thu, 6 Sep 2018 05:43:09 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 31836130E42 for ; Thu, 6 Sep 2018 05:43:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w86CgrWm136438; Thu, 6 Sep 2018 14:42:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 813222046CC; Thu, 6 Sep 2018 14:42:53 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 73E602027F5; Thu, 6 Sep 2018 14:42:53 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w86CgrNA008158; Thu, 6 Sep 2018 14:42:53 +0200 To: Erik Nordmark References: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> From: Alexandre Petrescu Cc: its Message-ID: <943cae30-e721-8c59-58f8-42ad867145f4@gmail.com> Date: Thu, 6 Sep 2018 14:42:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 12:43:11 -0000 Hi Erik, Le 18/07/2018 à 17:03, Erik Nordmark a écrit : [...] > Appendix H refers to a geolocation database and a GeoIP, yet the > changelog claims that those concepts have been removed from the > document. (I don't know how useful appendix H is to an implementor. It > isn't about how to implement things but what wireshark will show so > doesn't match the name of the section.) 'GeoIP' is the name given by wireshark to a mechanism that associates a cityname to an IP address. This 'GeoIP' is altogether different than the GeoNetworking IP of ETSI, and that of the failed IETF GeoNet BoF. That said, I believe the appendix H _is_ useful to implementor because it shows detailed packet dumps. Probably the 'GeoIP' text is not useful, and potentially misleading because of this risk of misunderstanding with GeoNetworking. I will remove that GeoIP text, but keep the appendix. Alex From nobody Fri Sep 7 02:49:27 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0852130DDE for ; Fri, 7 Sep 2018 02:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 QTnZNbOwqC_K for ; Fri, 7 Sep 2018 02:49:22 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 97B04128CB7 for ; Fri, 7 Sep 2018 02:49:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w879nHsK031645; Fri, 7 Sep 2018 11:49:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B36582029EE; Fri, 7 Sep 2018 11:49:17 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A2D3D201073; Fri, 7 Sep 2018 11:49:17 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w879nH5C006552; Fri, 7 Sep 2018 11:49:17 +0200 To: Erik Nordmark References: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> From: Alexandre Petrescu Cc: its , cjbc@it.uc3m.es Message-ID: <09175f15-7fdc-a94d-5ce3-641880ccfbdd@gmail.com> Date: Fri, 7 Sep 2018 11:49:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9d28cf19-408f-9748-6f4d-1fce8290eedd@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 09:49:26 -0000 Le 18/07/2018 à 17:03, Erik Nordmark a écrit : [...] > Section 4.5: "see the privacy considerations described in Appendix F." > I think the key privacy considerations are (or should be if something is > missing) in the security considerations section and not in an appendix. > Appendix F provides useful background and design considerations, but I > think this reference to appendix F is confusing. Moved some parts from section 4.5 and from other place into a new 'Privacy Considerations' sub-section of the Security Considerations section. > > Section 4.3: > I think the section should explicitly say that at most the link-local > address can use the EUI-64 based interface identifier, by saying that > any other IPv6 address should use either RFC8064 or RFC7217. I think > that is the intent, but the wording doesn't make it clear. Reformulated the SLAAC and LL sections. > Section 4.6 first paragraph: > I don't understand why there needs to be a subnet prefix assigned to the > ephemeral connectivity between the vehicles in range. AFAIU that is > router to router communication which can use link-local IPv6 addresses. > The routing protocols I know can operate using link-local addresses. Clarified the paragraph. > > Section 4.6 third paragraph: > 802.11 does not provide reliability for the ND multicast messages. > Thus I don't think OCB is any different than 802.11 in this respect. > I think this paragraph can be removed. If not, it should say the > opposite of that it says right now. I remove it, but I let the last phrase "ND is used over OCB" if that is ok. > Section 4.6 forth paragraph: > I don't know why one would have a mobile host directly attached to the > OCB link. My understanding is that only routers are attached to the OCB > link. Is that correct? Typically it should be a router, indeed. Do you mean we should not mention the operation of Mobile IPv6? At the moment I keep it. > In summary I think section 4.6 should say that the OCB link might not > have any IP address prefix apart from the link-local prefix. Added a sentence in that way. > If it does have some other IP prefix, then one would need to determine > who would advertise that/those prefixes (will the infrastructure nodes > send RAs with prefixes? Each vehicle??) Some infrastructure IP-RSU nodes do send RAs with GUA and ULA prefixes towards cars. I dont think we want to rule them out. Vehicles do not send RAs with GUA nor ULA prefixes. Some vehicles do send RAs but with no prefix inside. > After the reference to RFC5889 it might make sense to explicitly restate > this from that RFC: >    o  no on-link subnet prefix should be configured on such an >       interface. I add it, because the 'should' is not in capitals. > RFC5889 seems to suggest that it would be useful and in some cases > required to configure a non-link-local address for the OCB interface. > But such an address would probably need to be checked for uniqness in > the routing domain, and it isn't clear to me whether that would fit the > timing requirements for v2x. That is a good remark. The timing requirements are something like this live environment: a car at 110km/h stays within the coverage of an IP-RSU for approximately 5 seconds. Each 2ms a message can be sent or received. During that time, it is possible to exchange some application data packets (http GET state of traffic), and, probably, or probably not, possible to verify uniqueness of address in the routing domain. > Section 5 IPSec and SeND discussion. I'll defer to security experts on > this. I suspect it requires a separate draft to specify how IPsec and/or > SeND can be part of a security solution. Ok then: for the moment I leave it that way. > Section 5 last paragraph. I think this section should say at the instant > the MAC address is changed on the OCB interface, the node needs to also > change all of the IIDs on the OCB interface (link-local and any globals). Added a phrase in that sense. > Section 5 last paragraph. I don't understand what this text is trying to > say and I suggest it be dropped: >    On another hand, it may >    have an impact in the way typical IPv6 address auto-configuration is >    performed for vehicles (SLAAC would rely on MAC addresses and would >    hence dynamically change the affected IP address), in the way the >    IPv6 Privacy addresses were used, and other effects. Dropped. > The actual policy for when the MAC address is changed on the OCB > interface is presumably to-be-determined. Might make sense to note that > in the text. I note there is some mention of this in appendix C thus it > might make sense to add a reference to that appendix. Noted that in text, and reference added. > Appendix C last paragraph: > The "may have an influence" followed by the reference to 4.6 seems to > imply that something special is going on in section 4.6 which isn't > there. That's confusing. I suggest dropping that paragraph. Dropped. > Appendix F.4 uses the term pseudonyme without ever defining it. Hence it > isn't clear what the stated requirement is. Dropped the phrase saying 'pseudonyme'. I think it is not necessary to change all addresses on all interfaces when the change in pseudonym occurs. > > Appendix H refers to a geolocation database and a GeoIP, yet the > changelog claims that those concepts have been removed from the > document. (I don't know how useful appendix H is to an implementor. It > isn't about how to implement things but what wireshark will show so > doesn't match the name of the section.) Changed the title to: example of packet formats. > Appendix I seems misplaced. > If the reader needs to know these terms, then they should be in the > terminology section and not in an appendix. If the reader doesn't need > to know then, then they don't need to be in the document. The appendix has basic terms that are needed by the terms in the Terminology (e.g. appendix defines IP-OBU using the term OBU). The main text in the draft does not use the terms defined in the appendix. We find that too many terms in the Terminology section may clutter the view unnecessarily. > Note that the document has a lot more of appendix text than body text. > It is a 15 page document with 25 pages of appendices. > I don't know how useful those appendices will be to a new reader; they > might have been useful as part of producing the document. But might want > to consider which part of the appendices are still needed. I tend to agree. Probably I could remove appendices C, D, E, F and G for a total of 10 pages, if there is no strong disagreement. The titles of these appendices are: 802.11p Aspects introduced by the OCB mode to 802.11 Changes Needed on a software driver 802.11a to become a 802.11-OCB driver EtherType Protocol Discrimination (EPD) Design Considerations IEEE 802.11 Messages Transmitted in OCB mode Alex > >    Erik > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Fri Sep 7 02:51:28 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 416FD128CB7; Fri, 7 Sep 2018 02:51:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: its@ietf.org Message-ID: <153631388720.29005.15405297677452263053@ietfa.amsl.com> Date: Fri, 07 Sep 2018 02:51:27 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-26.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 09:51:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu Nabil Benamar Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-26.txt Pages : 40 Date : 2018-09-07 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-26 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-26 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 Sep 7 02:53:48 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55803128CB7 for ; Fri, 7 Sep 2018 02:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 RRxebeHNYUVl for ; Fri, 7 Sep 2018 02:53:43 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 11665130E05 for ; Fri, 7 Sep 2018 02:53:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w879retI030887 for ; Fri, 7 Sep 2018 11:53:40 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 352EF202E24 for ; Fri, 7 Sep 2018 11:53:40 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2963220209E for ; Fri, 7 Sep 2018 11:53:40 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w879rcEk009293 for ; Fri, 7 Sep 2018 11:53:40 +0200 References: <153631388740.29005.10414928545598748626.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <153631388740.29005.10414928545598748626.idtracker@ietfa.amsl.com> Message-ID: <81a4bf5e-6133-b47c-d651-0bf996c7b4ab@gmail.com> Date: Fri, 7 Sep 2018 11:53:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153631388740.29005.10414928545598748626.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------63E2EB1AE1C7D9FCCB40F2E9" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-26.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 09:53:46 -0000 This is a multi-part message in MIME format. --------------63E2EB1AE1C7D9FCCB40F2E9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, I submitted a new version of the IP/OCB draft - the 26th. It addresses most if not all comments from Erik. This is the ChangeLog:  -26: moved text from SLAAC section and from Design Considerations    appendix about privacy into a new Privacy Condiderations subsection    of the Security section; reformulated the SLAAC and IID sections to    stress only LLs can use EUI-64; removed the "GeoIP" wireshark    explanation; reformulated SLAAC and LL sections; added brief mention    of need of use LLs; clarified text about MAC address changes; dropped    pseudonym discussion; changed title of section describing examples of    packet formats. Yours, Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-26.txt Date : Fri, 7 Sep 2018 02:51:27 -0700 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-26.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 26 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2018-09-07 Group: ipwave Pages: 40 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-26.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-26 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-26 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------63E2EB1AE1C7D9FCCB40F2E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

I submitted a new version of the IP/OCB draft - the 26th.

It addresses most if not all comments from Erik.

This is the ChangeLog:

 -26: moved text from SLAAC section and from Design Considerations
   appendix about privacy into a new Privacy Condiderations subsection
   of the Security section;

reformulated the SLAAC and IID sections to
   stress only LLs can use EUI-64;

removed the "GeoIP" wireshark
   explanation;

reformulated SLAAC and LL sections;

added brief mention
   of need of use LLs;

clarified text about MAC address changes;

dropped
   pseudonym discussion;

changed title of section describing examples of
   packet formats.

Yours,

Alex



-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-26.txt
Date : Fri, 7 Sep 2018 02:51:27 -0700
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr> 


A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-26.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	26
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2018-09-07
Group:		ipwave
Pages:		40
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-26.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-26
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-26

Abstract:
   In order to transmit IPv6 packets on IEEE 802.11 networks running
   outside the context of a basic service set (OCB, earlier "802.11p")
   there is a need to define a few parameters such as the supported
   Maximum Transmission Unit size on the 802.11-OCB link, the header
   format preceding the IPv6 header, the Type value within it, and
   others.  This document describes these parameters for IPv6 and IEEE
   802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
   similarly to other known 802.11 and Ethernet layers - by using an
   Ethernet Adaptation Layer.

                                                                                  


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

The IETF Secretariat
--------------63E2EB1AE1C7D9FCCB40F2E9-- From nobody Fri Sep 7 03:08:26 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E10130DE5; Fri, 7 Sep 2018 03:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 N1N0i9ENN14y; Fri, 7 Sep 2018 03:08:21 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 56D661277D2; Fri, 7 Sep 2018 03:08:20 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1fyDgY-0006jF-2y; Fri, 07 Sep 2018 12:08:19 +0200 To: Hrpc , its@ietf.org From: Amelia Andersdotter Openpgp: preference=signencrypt Autocrypt: addr=amelia@article19.org; prefer-encrypt=mutual; keydata= xsFNBFjWlnsBEAC+jUN+LJE+mmxEL8lHSrvg47xSBMb9GdtH1Jr8tRSxXiO6R5E+FydsfqkL sjO0dI3x/VnNBi/kgPFFWiAzDEwGTiR/C9b/Muo+xrY+it6e49N56LTPGezrY2dy5yo6VcLl 7UwGz3fIWiNIj7dvuoPMBoO1uacF073E+dqDM5CmNh6o+OrHW8zhUlC9hKgXCq+8XpZJw90H un1zsHF0sRDiurjfYaCcbdAGK9+th9378ed1ZvLVo5uBVQXdydl3eJkNCOELq7VOS7oxSliA uX5/nj9A4LjeeYXgNbwGfKrMjlffP0FcAcgfzg9seqDd1DEk9EVaUMTr32fbWOQHjinXSC7r Lw4xaNfoBebIe1M6z16Xg7+bXXCTdmJYcL9ugmkvT6tGnR12Pfoca1oBwXPvA0VIRi86kCSU D9qvZ3Vl07MKD2hsvFkGZJOQfEaYv5QLpCWv6RCjfDNC05IyMeSW4H18Fr/BoHX8FXHV3+9H LsbJQ/Zrofd/Cm+TKEmXLAtYc7iXvzV+mw3/u0VYqjEy/CRYa62Ah0NNNVIuswfRVIfx3UZo jX4y8j2Kh0jtUV5A4GGf8H3SzQ/cB0I7wTRHU9mCPVCtH6M26nPumL4Zr4D6uGnAmPf9xnlX lokOn2Qxf/mBldsL41PDbEpYhZvvn5kJ/Z9Qh7Fks/hfTbbJowARAQABzSxBbWVsaWEgQW5k ZXJzZG90dGVyIDxhbWVsaWFAYW5kZXJzZG90dGVyLmNjPsLBlwQTAQgAQQIbIwUJCWYBgAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYhBD1dtsq4UrmIBVpqb/7xwpS06AtVBQJY1pdiAhkB AAoJEP7xwpS06AtVI0sP/Al6eUycymdT1R7v0uEQv4coonnOUV6FKj/4wc+wM+A0h7vlqADr j4nS7RRSQRUo8xJ9tvR9J1Eyske5bvakOYv64f9PrNY1Z6ABhJzK34kJxekEfeLmpXAB4wst GhD8dGC/z/b9Oau0AW1GWIP0eNWq4acDf9Qf+j0wqQi25OZUXnu5KeUX7mvPTHKZLyEZlwHV atXmZHWKnQWtEPZTQfv/zESsoBAm1TbaLapgxVG9uLW+I9kj72TB/AZ5hMSKMYWZ2dC+8eEs Xd22tn6907aUmZhFT89jbEyS996WeZ+SQ5G1Okrq02qYXcCi5vm3AuvLlbRYHguh42TLaVq1 er7PiYOYH77FFmnZWW6ChFnf7xsDep2tpNxn+QUZLgO3+5kL7TfO7D2H57kjVVMdkNn+01nz kfcn76K7nuU6Dc4pItPzbDndhdxulnm9cicOEfGQqvta9ffxk4YWyAu9PUNARVRNf6OnoDQQ Zo8l1o37q9PFXJyQwzvxdd9u6uzTny2wp9eig75pD3dYHCRIQeYmkv1kB81mc86cwgvuw1Qy /QwiCBNXSSuIvLO78b+/dB0DLVQC/c6gtyWXRpC4ysF4EaEZophjT60d12YRanR+fWuH+qu2 wsT+z1d4tC5/6UJMPr3bxREh9JHThm5Y3cDBmcn0PGqtDKkwjCkqex5bzsFNBFjWlnsBEADF jusaTo9W8VeWluCK/oJqyyyF1wMvou0ldfuoOpUZrOqsY67TM7yBqsv5COPVgAV+xp+axor5 oHWxibd283w0Ok4dK6tvtNGwUqyDRlHtQ92DG/u4Tg5eOwrHNUn73/rfeBD9KhKAXcNKKPoc cLgR8oQTXpO7eRo+0NI52pXQ6LdZ0wddYeTcHglsNKN1TK+CyYS7xfGolsZXXoBOKcyhfj/c kPFVIHWpGpEtcYWTZWvXgLprzHvpKzkzNyBwejaXE+bqCT2dRl3omI/e2t3Vq33hFUUSAdxr FF29vMX/YsSnYqsFOIoayna+TRsDFAfZvbvHBOMckeJzvA8yBdadw7CM08Uw8wqH7n9BA3oq //QpZJekPfrc2E9nM9H0d51T0uStLMbYDWdwxvfPA3p9z8L91vobt8bM/Jbhl9h+X2Yq9oBC iTI7b2izYd9FVG4BwBIdeh3bh9R9HExgRjF3XQ6uafT3pcVOPASdv9FRUYH1Va7QWQifoha0 B7UXKx1OpX1Z6XR2NQ9KN2MvlwvBKdHtm6tBzUIFzW6D8vUOxiYKBA4fppJt/LJF4jsaCEyI /CVQnkC0yL5DKFOdigxTipwEL9Uc6r7VfR5OAGFd6vzuJFy+j+/WhzaVT1oVYp6eQXh0bBtq qH2Mq9sAMnIjvaNYIKiQKgMa1Pa3OWQbQQARAQABwsF8BBgBCAAmFiEEPV22yrhSuYgFWmpv /vHClLToC1UFAljWlnsCGwwFCQlmAYAACgkQ/vHClLToC1XnRw//W4lzE8FddceKXGRwO/T1 u4uzH9EjPCj+3/eHCrLI+h1m7QPyH1DrFAtZBoA6UoaF0+vIAJXM9/HI1FZ09EUdJr5X/+YR EErFom4DbE1FK8fpK1/Hw2zI+7Xa8bVkmYrKhMGhi1Gq6Dtksn/H4USdJL53ZPt10SVNK7H3 w93Yp1GC4+0zWjfrsKfsHYZZr2SZyb5/gZlngfgaqiQLhIcPYmiU1GQi9QWkGxWRxk0YQXBw hekewvgltATxlRSCwguAi4uck9fAct9GGdpsshSOgAb9YIAnEV3EqaGnf0PknXp3vNHAZWrf M+RyuNdm2L5TjDU0rIrvyqGP3pR33cREGOAil5Sz2uFArmwsPt8VffbEXlf7qZqRBKaYeKt0 qnxKMx1+e1JilVsfb8qtnAWAFDyR0HMlVj/dvGAmq/auPSOAUWRSnDRyT6rv/vXxrbkL4uxW ax46qdpDhR15mS5MTng6b5b3Uox7xlveo/Sx71AdNf4goPvB/ntv0DiMuh+fmLGk3zrxs4Xd 30Sx+qQwVaXR5xc5rgnF81wvfmuAOb2eP9mpD6DoabkpxC8fLk17AK7Q1ZTgcZ+8XLRFnavd PrwCa9RU0BF53lJMSTPzyBcMwZ4sqA6Z5IRFVt7rEbSeeD8REiawo+FvVt9j0fKdNEBeaJ3W Y5hlhNPcUXr4q1U= Organization: ARTICLE19 Message-ID: <0103d901-baf7-6a2f-391f-4d6e905fdefd@article19.org> Date: Fri, 7 Sep 2018 12:08:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US-large X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: ff8282cba176f16c0cd93a6055202d23 Archived-At: Subject: [ipwave] Human Rights Review of draft-ietf-ipwave-vehicular-networking-04 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 10:08:24 -0000 Dear all, As part of efforts in the Human Rights Protocol Considerations (HRPC) group, I have reviewed the human rights considerations (RFC 8280) in IPWAVE Problem Statement. https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ The below text has been sent to the author of the document on August 28. I'm now hoping for input from the larger community. best regards, Amelia # Summary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D I understand that the draft contains a satisfactory treatment of the human rights concerns listen in Section 6.2.1 (Connectivity), 6.2.3 (Content agnosticism), 6.2.8 (Heterogeneity support), Section 6.2.14 (Reliability), Section 6.2.16 (Integrity), Section 6.2.17 (Authenticity) and 6.2.18 (Adaptability) of RFC8280. I have also traced some of the dependencies of the draft on less accessible standards in accordance with Section 6.2.7 (Open Standards) in RFC8280. I have suggested improvements with respect to human rights concerns listed in Sections 6.2.2 (Privacy), 6.2.4 (Security), 6.2.6 (Censorship Resistenace), 6.2.9 (Anonymity), 6.2.10 (Pseudonymity), 6.2.13 (Decentralization), 6.2.15 (Confidentiality) and 6.2.19 (Outcome transparency) in RFC8280. I finally make two suggestions related to Sections 6.2.5 (Internationalization), 6.2.11 (Accessibility) and 6.2.12 (Localization) in RFC8280. # Topical human rights review =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ## Part 1: Privacy, decentralization, transparency ----------------------------------------------------------------------- This part reviews IPWAVE Problem Statement draft from the perspectives of Sections 6.2.2 (Privacy), 6.2.4 (Security), 6.2.6 (Censorship Resistenace), 6.2.9 (Anonymity), 6.2.10 (Pseudonymity), 6.2.13 (Decentralization), 6.2.15 (Confidentiality) and 6.2.19 (Outcome transparency) in RFC8280. In Section 4.1.7 Current Protocols for Vehicular Networking: Security and Privacy, the focus is only on encryption and certificate exchanges. I believe this can be complemented by raising topics that have been prevalent in vehicular communications for a large number of years. Notably data minimization and geolocalisation threats (see e.g. RFC6973, section 6.1: Data minimization). It is generally recognised that vehicular communications face particular security and privacy challenges, with the driver of the connected vehicle perhaps being obliged by law to disseminate specified, and verifiably accurate, data. This makes the driver unable to deploy common privacy strategies, such as obfuscation, and calls for extra careful consideration of durable connections (such as connections that last over pseudonym changes, thereby opening new privacy attack vectors). Pseudonym changes are therefore proposed as alternative privacy risk mitigations. In Section 5.3, there is focus on integrity (RFC8280, Section 6.2.16) and authenticity (RFC8280, Section 6.2.17), where the privacy and security complications arising from vehicular networks are, I insist, broader in scope. It is not clear that the Vehicle Identification Number (VIN) would not be used to track a vehicle or its driver against his or her wishes, even if the MAC address and IP address are randomized or re-addressed. Of particular importance are those situations where drivers are not legally alloId to discontinue a particular connection (see also RFC6973, Section 6.2: User Control or RFC8280, Section 6.2.6: Censorship Resistance and Section 6.2.15: Confidentiality). I see a need for at least reflection on the centralized properties of authentication and certificate schemes in Section 5.3 (see e.g. RFC8280, Section 6.2.13: Decentralization). Depending on which agent is ultimately endoId with the responsibility of issuing certificates for security purposes, there may be large downstream market effects on drivers and the service providers available for drivers to choose. In fact, this is a central issue in drivers' associations concerns with vehicular communications and, in general, telematics[2]. Both of these considerations call into question whether the "same" network should be used for all use-cases listed in Section 3 of the Problem Statement. It may be, for instance, that pseudonym self-issuance should be considered for some use-cases, but not for others. An overview of pseudonym issuance strategies is found in [3]. Finally, there has been some attention in literature to the use of OBU caching as a way of minimizing contacts with RSU[4], or including options to collect information from other near-by vehicles instead of from the RSU when a querying need arises. IPWAVE may want to delve further into the topic of how this might work in an ad hoc 802.11 network and whether IPWAVE gives options for solutions that are not as well present in other technologies. ## Part 2: Internationalization and accessibility ------------------------------------------------------------------ This part reviews IPWAVE Problem Statement draft from the perspectives of Sections 6.2.5 (Internationalization), 6.2.11 (Accessibility) and 6.2.12 (Localization) in RFC8280. These sections deal with ways in which affected parties can interact effortlessly with resulting specifications.= The IPWAVE Problem Statement draft any obvious efforts to address the issues raised in those sections of RFC8280. That said, accessibility as in Sections 6.2.11 or 6.2.12 may require the cooperation of user interface designers and higher layers. In the context of internationalization and localization, I note that references to regulatory frameworks that put natural boundaries on the scope of the projects proposed within the Problem Statement are limited to North America and Europe. It is not clear whether those geographical regions that use different alphabets or logographs have a greater interest in internationalization and localization, than those geographical regions that predominantly rely on the latin alphabet. This could be clarified. In the context of privacy options discussed above, it is the case that the standards developed in IPWAVE are more likely to be consumed by implementers and user interface designers at higher layers than by drivers of vehicles. In the interest of accessibility and localization, clarity with respect to privacy-, user control- or security-enhancing features for the implementers is paramount to ensure that these features do not end up obscured. ## Part 3: Open standards -------------------------------------- This part reviews IPWAVE Problem Statement draft from the perspective of Section 6.2.7 (Open Standards) in RFC8280. It may be noted that the IETF as such makes open standards and maintains openness throughout the standard developments deliberations. Many of the standards referenced in Problem Statement are not open. IEEE 1609 and IEEE 802.11-OCB may require subscriptions for researchers and implementers to accesss for some time after the completion of a standardisation project, while ISO standards are always closed to the public, in the sense that they sell access to their standards. ETSI and 3GPP standards become accessible to the public only upon their conclusion= =2E # Recommendations ----------------------------- 1. In our literature review, I found one proposal to use Multipath TCP to enable lasting connections in spite of re-addressing[1]. This study could be tentatively inserted in Section 4.1.7. Reference [3] should be added to section 5.3 together with observations made above. Similarly section 5.3 could cover reference [4]. 2. Due consideration should be given to the fact that a lasting connection risks defeating some of the purposes of pseudonym randomization/re-issuance, since the lasting connection would then in and of itself become a way to track the vehicle. The Vehicle Identification Number (VIN) risks defeating the purpose of re-addressing or pseudonym handling, if it is used as an authentication mechanism. Section 4.2.4 Pseudonym Handling or Section 5.3 could raise this issue. Of particular importance for a vehicle owner or driver will be whether these durable connections are mandatory to enable under any legislation. It could be considered whether different certificate issuance strategies can be deployed for different types of connections. 3. I believe an additional definition is needed for the word "pseudonym", in order to clarify that by this word the document means the same thing as is meant by MAC/Layer-2 Randomization in P802.11aq, the readdressing feature described in IEEE 1609.4-2016, or the temporary identifiers referenced in ETSI TS 102 941. 4. IPWAVE should make it clear it intends that privacy-friendly options should be made explicit to implementers in the developed standards. 5. The working group may consider whether to undertake greater internationalization efforts inside the group, or request it from other working groups, bearing in mind that some of the geographical regions not covered by the regulatory review may consider this a perk. [1] S. Han, H. Kim and Y. Park, "Overcoming IP communication breakdown upon pseudonym changes in the IEEE WAVE," 2017 IEEE Vehicular Networking Conference (VNC), Torino, 2017, pp. 183-186. doi: 10.1109/VNC.2017.8275622 URL: http://ieeexplore.ieee.org.ludwig.lub.lu.se/stamp/stamp.jsp?tp=3D&arnumbe= r=3D8275622&isnumber=3D8275590 [2] FIA, http://mycarmydata.eu [3] J. Petit, F. Schaub, M. Feiri and F. Kargl, "Pseudonym Schemes in Vehicular Networks: A Survey," in IEEE Communications Surveys & Tutorials, vol. 17, no. 1, pp. 228-255, Firstquarter 2015. doi: 10.1109/COMST.2014.2345420 URL: http://ieeexplore.ieee.org.ludwig.lub.lu.se/stamp/stamp.jsp?tp=3D&arnumbe= r=3D6873216&isnumber=3D7061782 [4] B. Liu, W. Zhou, T. Zhu, L. Gao, T. H. Luan and H. Zhou, "Silence is Golden: Enhancing Privacy of Location-Based Services by Content Broadcasting and Active Caching in Wireless Vehicular Networks," in=C2=A0/IEEE Transactions on Vehicular Technology/, vol. 65, no. 12, pp.= 9942-9953, Dec. 2016. doi: 10.1109/TVT.2016.2531185 URL:=C2=A0http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D741= 4507&isnumber=3D7779452 --=20 Amelia Andersdotter Technical Consultant, Digital Programme ARTICLE19 www.article19.org PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55 From nobody Fri Sep 7 04:18:36 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7480B130DD5 for ; Fri, 7 Sep 2018 04:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 EUF2Pgf5z7Zo for ; Fri, 7 Sep 2018 04:18:27 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 0F314130DDD for ; Fri, 7 Sep 2018 04:18:27 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id b19-v6so9428519qkc.6 for ; Fri, 07 Sep 2018 04:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=0u1g/gTjsE+7dIbjJb9NBK+otOGZI29UUHD4oSb0GWM=; b=V8CSlku6DVtahBjH7gDEOCUIT+8x6hGSBEEPULlr60a9bKsy8kbhkbsU+5lEbPp+dJ CHqkBqPXeUVlD6on4o2kUWRUFY2lb8AnMxn25pQxKjj6Jgv0jP9jF8fPfW1RWPouaFib gzN3h/guHowI7sX1bBpwYrG+qdNOgKrn72DsSsYDCjvmiSO0tdFOAuvZnyBuDZX8Ep6l eOnkjQDj170pYkrcPBpdCZyv13R7LrrC60lwNcPy2UPuSa6C/12H44gCmbL++nPA8U2w D0yScii2Iiiop4XyFh1gLhJFQRrNUbih+nGcUszw/mUQAe3xjanNtWg3ZLBRYCEYSty+ MG7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=0u1g/gTjsE+7dIbjJb9NBK+otOGZI29UUHD4oSb0GWM=; b=nKDF4AYaopSK+cYqR2Ojt4aJSayxhOkCAKA0MgxmBCON1HlGkFrb5tro2NLr6A1kGQ 2lzTWZnaEX3wQqfrgd1i3XtAfgLNZXdciVSQ8F+2pf//TujeX34HFwBYxebY4Jse5n0t ztliaA/wehPK33qm48OVa6Xo+y26Y1I1KdJueLf+aGV5ePyCHibSpaSKSQU9cRe+C692 D19RopFAGUExcROOmD4HmRnihworBN1s9APXp+0dq66I/g4qoJUNQNJSZX1lzO4IKppU pwvaaPL4P/DzsbEbhyCmvHHWfn0RUZZvwH+FasMgrvi7kfqxUVzA3gO+X89YIHD/ENN8 7W1w== X-Gm-Message-State: APzg51BUaCmhZfqm+pZXALcptOUxEi+xzQdWI0t+ScDGls7Sn8FloUIg Qu+w9VzUj9paYi/gZsIHUgyBhUnS X-Google-Smtp-Source: ANB0VdZ+XEqTqHPnCbmsw1wv4TLFxdHWcJLu2/nO6N9VsT+ertUTXs4whsUH/rmCfZctngxyYx3+nQ== X-Received: by 2002:a37:7704:: with SMTP id s4-v6mr5226847qkc.358.1536319105726; Fri, 07 Sep 2018 04:18:25 -0700 (PDT) Received: from [192.168.1.53] (pool-70-106-196-109.clppva.fios.verizon.net. [70.106.196.109]) by smtp.gmail.com with ESMTPSA id o18-v6sm5321731qki.38.2018.09.07.04.18.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 04:18:25 -0700 (PDT) To: Amelia Andersdotter , Hrpc , its@ietf.org References: <0103d901-baf7-6a2f-391f-4d6e905fdefd@article19.org> From: Tony Rutkowski Openpgp: preference=signencrypt Autocrypt: addr=rutkowski.tony@gmail.com; prefer-encrypt=mutual; keydata= xsFNBFolz+gBEACo+XkmnKmogov4Fccwgmn8L6mwqVQEU6dkW0Pwbw+PBnRf1RNAZk6J960Q C6Omh9NjQCANG5B9WMiXGd7WPdodD8ghuTJBJpFaB6omvix9SJ1NOiirbtA676AR035cV6y7 7wb0mZ+Boyq72UFgcjsKxpZxK+dIK9UcbkvceSrpAr7fxIaAi/2eTU6EA0+5MX2nhPdLTQHt S1FKRW56++pMUbpKkQjEvj3qMku6WUPnqKrnpaH/DP1fSwTkbIr6pkcby8V+DcY5+mnjRc7L FFp15OX9SmNWDSs0rYkhJ6tlPR1DVmzzhG05dZtI+fbxF20AJfO19U5vIQumZwshOHiLvjqn 9x1bjoiAXng9KQMDwmV5/TQhEdXddiDnPkbNv6XNAYJFevlS766xsG4QMrgzjaAbPEfpGcP7 PBRstyHHTgUbbOaWPUEiaq7eGM6MWCovv30aVpa2hM9MTmDeBvJAm9F0V3a/8uWQtRqWTUid RmfJKkI66w26k6XQcszhaVAkH5cr7/s1QF63Vnr33nxW6vG1iT3FPE+o3Wo3892oj+mORclx BK/4ZL+vF7LoWcoOCu6Id0dEhrkHLjmsnO2Pf+uU+OH68a7mMkz1gS6Fq0NEOy+4WbhiwLK4 3N/g1lZJh3f0f664JjTHlpL3pTZSnMZLlfy0Q1J0CKVCNgdXwwARAQABzSlUb255IFJ1dGtv d3NraSA8cnV0a293c2tpLnRvbnlAZ21haWwuY29tPsLBfwQTAQgAKQUCWiXP6AIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJENhM+Z2YMDfkZYsP/As/vxZTkm5MGqI8 T/F+0EJyaNlRaN94JaDeh0khRY9aKs0hio3iwT+uRC7UXXjpCdeOhjKn8wjtFYaOSGzBWRPO zxWRntmZY0g+Jxx9dkFXXCYeuMzlnQagnJ/MFjsLWZQg+/j9kBoQZiXzyEGoYYOd46OIvViZ 4HWEE+dV/23UjiYuU70AcoMPOtQ+9UIIxPISQwhZMLyZmQDEdI9OgKmrOpXeIb0Ctba3/OmW mx/PjsJJIA7s/IoOsmgVZBFQ2lQluMcM9SJrNkzPdpsAz2cp9L0XgREIdCz+1FvMmYs5NFTO ln/ATXYAxuBbTg953ZuIpjT9c2D6R6ji98h43zzp3F82v9t6SiaqkjJbUXzTVi4QpqIWmRx6 beTBUdnUVQxw+QpK8+EFp6QHC5MGFKo1FoJDWbn4FNYPQfEmuq7MgjCDUGfErU7M0wvxhZ3o /mgtfR44pk8KMKSfVY1rvzXgMDrMFu/Mv9HvBlNoyTydgV2dX4O+106Olv0fwKwdj3yqHNmS hkBdq5GeACEsEuVFQiOdbmdPmcvONJZx478yUsSRP0iTEgy5qc7RlsSNGV/12B+GHEeE4OTy LWm3s5LO40nveULeeWwZ+0Q6iTfSWLhXjbaNNdZnBt/DaM6qn9h21Px42PyE8NGQvjKXOX7+ 3JXViCzbeHkgIfTo73gozsFNBFolz+gBEAC2jf+HVxcM3AdwP88bK/XLA/K0pWmszImDT41y wSpZ7asVuawuO1Bl+byHOukTmsnOQ/PFiQ19j+HXSlIxsEDgoc9OqkMVrj0BDevKM9krwyyZ lC0TbtwH6KugmJ2eUeJnfMpuwLUVq7Icqh5qwneoBj5j2gxWeMZJ8FeT0I5lBHDhu4W3iFuj akku4fCF2gpNnXCXh8WGuTCsDXyBe+kwbUIBBQBwVaUSJAQh/ai7xnB1GZOGSqfBkyCJ7C/A ZVu13lgX747keGiNwWQAFiYuhzgSrGHex9tvRLuzkmg/xfLrYdVOubr6M3JGpIK64YeIQskC O7OCyH5u/tT3w5lNqMIufJ43lISu54Gaqwb7ddNfNLqnF/k+IghYStJo7OL9OqoA77GO15xH 52j7aMiiwPKxJAdhLArg+YAB+iD3LUfnMvWKO9gWvtmlHw3fhZ9zG+hjOUUe+QSKqPvmop48 tzuPEYC91HYNEvXN7d/p1T9Ms95qjvTdVCbV1ibsfW6NAeQjsvecvJVk1kvdCGoe5PZycF3D vJf+jyH/K832BJS4jQFob9tRjXTKEcL+E3V7IKVHJTRU4M1xo4iOQ7mT3+uNBVFMVqybY7f/ 9ipHKhCH3fAavuabAyczOznO0d54uz0J8Vdl+kWBrTdWyeipm9ai4M/vgfhcWQXELYEWPwAR AQABwsFlBBgBCAAPBQJaJc/oAhsMBQkJZgGAAAoJENhM+Z2YMDfkl40P/2AndYTSm4bRas5D j6og/hJE6uFKAL6IaP6U5ZWq5PUzWxlO/D4CP6z5JZ/w75yXDGuTcVhBGgmTVFmF1zfNP+Vy d4ieMSzCxal6m7EPVkh6H6O2nwuhVZZe9qhtXN73h1j85+FzuwkEffhFlSct4eEAVJLQ6bDI vo/2OVPx1HTqvHs5+DOKz73WVLVuYsR+e1jpu/bErlsMeUop9k0S9Dm4/jeCX7IW5fH4Yfcr 6pHhp44IsGLV2T9/HrgfN/TXnBpEJDdSvLlDqgr2bjphvvSX+YLDOunp/SZMOV+sY6Qz7TTs thkJDUbVk1/ibm6XYFEL4zFkm+MC0xeKCUmSTctkPul13VKBjZa6W2iX0saGgEGFHElwCqiT fSiO8mW49ObrMVdX+cBbIP72KN+VyAyGt3IWAt/tA9TuRe4zMAm8zsVXBisE0xm0FrPdsH+N xoMAY2Qe2unFH0Vh3OYquhlCO6DVY7qcLu143QH1JmL7MiXmDnOssxxz+uVKzKIHdfU9zHpB aOeJz8TzYeIs2JaCqFVcRowbGxFlFQ3oOjuqJXyz7fk/1JjBkRg5OwfYZBS+GCCDX6T/ckUr mMfjGd8DJgBzO+OIRRSybdwTu03LcWykVN2y7Mh2FPDtYPVSR5XCrMK3vbRszVk0Dg5Eui1A /n/jNSP5qSipdY2r3FxX Message-ID: Date: Fri, 7 Sep 2018 07:18:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0103d901-baf7-6a2f-391f-4d6e905fdefd@article19.org> Content-Type: multipart/alternative; boundary="------------57BE5E18E129E2FA90311164" Content-Language: en-US Archived-At: Subject: Re: [ipwave] [hrpc] Human Rights Review of draft-ietf-ipwave-vehicular-networking-04 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 11:18:30 -0000 This is a multi-part message in MIME format. --------------57BE5E18E129E2FA90311164 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Amelia, Very interesting and potentially useful. It appears, however, that the draft is based on relatively old specifications and work - in an arena where the activity changes from week to week.=C2=A0 There are also significant venues that are not even recognized. For example, ITU-T Study Group 17 (security) met the past two weeks in Geneva where it consider 56 documents.=C2=A0 This venue is also a global intergovernmental one with liaison relationships to numerous over venues, so it is of some increased significance.=C2=A0 It has an entire rapporteur group now dedicated to vehicular communication security and privacy chaired by Korea's ETRI and Hyundai Motors.=C2=A0 You can check out its terms of reference and 9 current work= items here https://www.itu.int/net4/ITU-T/lists/loqr.aspx?Group=3D17&Peri= od=3D16 They also just added five new work items - all of=C2=A0 which have hrpc implications: * Requirements of security information sharing and analysis for connected vehicles =C2=A0 =C2=A0 * Information of gap analysis for proposed new work item, security aspects of cloud-based EDR in ITS context =C2=A0 =C2=A0 * Security guideline for automotive Ethernet in In-Vehicle networks =C2= =A0 =C2=A0 * Security guidelines for cloud-based event data recorders in ITS context =C2=A0 =C2=A0 * Distributed Ledger based Vehicle Information Sharing=C2=A0 There is also an enormous amount of ongoing work in 3GPP and GSMA in this area that is not reflected in the draft. So admittedly, timeliness here is a challenge.=C2=A0 However, you probabl= y don't want to start out using material that is many years out of date and significantly incomplete. --tony ps. +1 on the plea for open standards!=C2=A0 It costs thousands of Euros = to even look at some of sets. --------------57BE5E18E129E2FA90311164 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Amelia,

Very interesting and potentially useful.

It appears, however, that the draft is based on relatively old specifications and work - in an arena where the activity changes from week to week.  There are also significant venues that are not even recognized.

For example, ITU-T Study Group 17 (security) met the past two weeks in Geneva where it consider 56 documents.  This venue is also a global intergovernmental one with liaison relationships to numerous over venues, so it is of some increased significance. 

It has an entire rapporteur group now dedicated to vehicular communication security and privacy chaired by Korea's ETRI and Hyundai Motors.  You can check out its terms of reference and 9 current work items here https://www.itu.int/net4/ITU-T/lists/loqr.aspx?Group=17&Period=16

They also just added five new work items - all of  which have hrpc implications:
  • Requirements of security information sharing and analysis for connected vehicles    
  • Information of gap analysis for proposed new work item, security aspects of cloud-based EDR in ITS context    
  • Security guideline for automotive Ethernet in In-Vehicle networks    
  • Security guidelines for cloud-based event data recorders in ITS context    
  • Distributed Ledger based Vehicle Information Sharing 
There is also an enormous amount of ongoing work in 3GPP and GSMA in this area that is not reflected in the draft.

So admittedly, timeliness here is a challenge.  However, you probably don't want to start out using material that is many years out of date and significantly incomplete.

--tony

ps. +1 on the plea for open standards!  It costs thousands of Euros to even look at some of sets.



--------------57BE5E18E129E2FA90311164-- From nobody Fri Sep 7 04:23:45 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB7D130DE3; Fri, 7 Sep 2018 04:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 dCHXAjmhbwxA; Fri, 7 Sep 2018 04:23:36 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 10978128B14; Fri, 7 Sep 2018 04:23:36 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1fyErO-0004pX-Aq; Fri, 07 Sep 2018 13:23:34 +0200 To: Tony Rutkowski , Hrpc , its@ietf.org References: <0103d901-baf7-6a2f-391f-4d6e905fdefd@article19.org> From: Amelia Andersdotter Openpgp: preference=signencrypt Autocrypt: addr=amelia@article19.org; prefer-encrypt=mutual; keydata= xsFNBFjWlnsBEAC+jUN+LJE+mmxEL8lHSrvg47xSBMb9GdtH1Jr8tRSxXiO6R5E+FydsfqkL sjO0dI3x/VnNBi/kgPFFWiAzDEwGTiR/C9b/Muo+xrY+it6e49N56LTPGezrY2dy5yo6VcLl 7UwGz3fIWiNIj7dvuoPMBoO1uacF073E+dqDM5CmNh6o+OrHW8zhUlC9hKgXCq+8XpZJw90H un1zsHF0sRDiurjfYaCcbdAGK9+th9378ed1ZvLVo5uBVQXdydl3eJkNCOELq7VOS7oxSliA uX5/nj9A4LjeeYXgNbwGfKrMjlffP0FcAcgfzg9seqDd1DEk9EVaUMTr32fbWOQHjinXSC7r Lw4xaNfoBebIe1M6z16Xg7+bXXCTdmJYcL9ugmkvT6tGnR12Pfoca1oBwXPvA0VIRi86kCSU D9qvZ3Vl07MKD2hsvFkGZJOQfEaYv5QLpCWv6RCjfDNC05IyMeSW4H18Fr/BoHX8FXHV3+9H LsbJQ/Zrofd/Cm+TKEmXLAtYc7iXvzV+mw3/u0VYqjEy/CRYa62Ah0NNNVIuswfRVIfx3UZo jX4y8j2Kh0jtUV5A4GGf8H3SzQ/cB0I7wTRHU9mCPVCtH6M26nPumL4Zr4D6uGnAmPf9xnlX lokOn2Qxf/mBldsL41PDbEpYhZvvn5kJ/Z9Qh7Fks/hfTbbJowARAQABzSxBbWVsaWEgQW5k ZXJzZG90dGVyIDxhbWVsaWFAYW5kZXJzZG90dGVyLmNjPsLBlwQTAQgAQQIbIwUJCWYBgAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYhBD1dtsq4UrmIBVpqb/7xwpS06AtVBQJY1pdiAhkB AAoJEP7xwpS06AtVI0sP/Al6eUycymdT1R7v0uEQv4coonnOUV6FKj/4wc+wM+A0h7vlqADr j4nS7RRSQRUo8xJ9tvR9J1Eyske5bvakOYv64f9PrNY1Z6ABhJzK34kJxekEfeLmpXAB4wst GhD8dGC/z/b9Oau0AW1GWIP0eNWq4acDf9Qf+j0wqQi25OZUXnu5KeUX7mvPTHKZLyEZlwHV atXmZHWKnQWtEPZTQfv/zESsoBAm1TbaLapgxVG9uLW+I9kj72TB/AZ5hMSKMYWZ2dC+8eEs Xd22tn6907aUmZhFT89jbEyS996WeZ+SQ5G1Okrq02qYXcCi5vm3AuvLlbRYHguh42TLaVq1 er7PiYOYH77FFmnZWW6ChFnf7xsDep2tpNxn+QUZLgO3+5kL7TfO7D2H57kjVVMdkNn+01nz kfcn76K7nuU6Dc4pItPzbDndhdxulnm9cicOEfGQqvta9ffxk4YWyAu9PUNARVRNf6OnoDQQ Zo8l1o37q9PFXJyQwzvxdd9u6uzTny2wp9eig75pD3dYHCRIQeYmkv1kB81mc86cwgvuw1Qy /QwiCBNXSSuIvLO78b+/dB0DLVQC/c6gtyWXRpC4ysF4EaEZophjT60d12YRanR+fWuH+qu2 wsT+z1d4tC5/6UJMPr3bxREh9JHThm5Y3cDBmcn0PGqtDKkwjCkqex5bzsFNBFjWlnsBEADF jusaTo9W8VeWluCK/oJqyyyF1wMvou0ldfuoOpUZrOqsY67TM7yBqsv5COPVgAV+xp+axor5 oHWxibd283w0Ok4dK6tvtNGwUqyDRlHtQ92DG/u4Tg5eOwrHNUn73/rfeBD9KhKAXcNKKPoc cLgR8oQTXpO7eRo+0NI52pXQ6LdZ0wddYeTcHglsNKN1TK+CyYS7xfGolsZXXoBOKcyhfj/c kPFVIHWpGpEtcYWTZWvXgLprzHvpKzkzNyBwejaXE+bqCT2dRl3omI/e2t3Vq33hFUUSAdxr FF29vMX/YsSnYqsFOIoayna+TRsDFAfZvbvHBOMckeJzvA8yBdadw7CM08Uw8wqH7n9BA3oq //QpZJekPfrc2E9nM9H0d51T0uStLMbYDWdwxvfPA3p9z8L91vobt8bM/Jbhl9h+X2Yq9oBC iTI7b2izYd9FVG4BwBIdeh3bh9R9HExgRjF3XQ6uafT3pcVOPASdv9FRUYH1Va7QWQifoha0 B7UXKx1OpX1Z6XR2NQ9KN2MvlwvBKdHtm6tBzUIFzW6D8vUOxiYKBA4fppJt/LJF4jsaCEyI /CVQnkC0yL5DKFOdigxTipwEL9Uc6r7VfR5OAGFd6vzuJFy+j+/WhzaVT1oVYp6eQXh0bBtq qH2Mq9sAMnIjvaNYIKiQKgMa1Pa3OWQbQQARAQABwsF8BBgBCAAmFiEEPV22yrhSuYgFWmpv /vHClLToC1UFAljWlnsCGwwFCQlmAYAACgkQ/vHClLToC1XnRw//W4lzE8FddceKXGRwO/T1 u4uzH9EjPCj+3/eHCrLI+h1m7QPyH1DrFAtZBoA6UoaF0+vIAJXM9/HI1FZ09EUdJr5X/+YR EErFom4DbE1FK8fpK1/Hw2zI+7Xa8bVkmYrKhMGhi1Gq6Dtksn/H4USdJL53ZPt10SVNK7H3 w93Yp1GC4+0zWjfrsKfsHYZZr2SZyb5/gZlngfgaqiQLhIcPYmiU1GQi9QWkGxWRxk0YQXBw hekewvgltATxlRSCwguAi4uck9fAct9GGdpsshSOgAb9YIAnEV3EqaGnf0PknXp3vNHAZWrf M+RyuNdm2L5TjDU0rIrvyqGP3pR33cREGOAil5Sz2uFArmwsPt8VffbEXlf7qZqRBKaYeKt0 qnxKMx1+e1JilVsfb8qtnAWAFDyR0HMlVj/dvGAmq/auPSOAUWRSnDRyT6rv/vXxrbkL4uxW ax46qdpDhR15mS5MTng6b5b3Uox7xlveo/Sx71AdNf4goPvB/ntv0DiMuh+fmLGk3zrxs4Xd 30Sx+qQwVaXR5xc5rgnF81wvfmuAOb2eP9mpD6DoabkpxC8fLk17AK7Q1ZTgcZ+8XLRFnavd PrwCa9RU0BF53lJMSTPzyBcMwZ4sqA6Z5IRFVt7rEbSeeD8REiawo+FvVt9j0fKdNEBeaJ3W Y5hlhNPcUXr4q1U= Organization: ARTICLE19 Message-ID: Date: Fri, 7 Sep 2018 13:23:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 5a1627636b35b65657045ef62631cd80 Archived-At: Subject: Re: [ipwave] [hrpc] Human Rights Review of draft-ietf-ipwave-vehicular-networking-04 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 11:23:39 -0000 Dear Tony, On 2018-09-07 13:18, Tony Rutkowski wrote: > > For example, ITU-T Study Group 17 (security) met the past two weeks in > Geneva where it consider 56 documents.=C2=A0 This venue is also a globa= l > intergovernmental one with liaison relationships to numerous over > venues, so it is of some increased significance.=C2=A0 > > It has an entire rapporteur group now dedicated to vehicular > communication security and privacy chaired by Korea's ETRI and Hyundai > Motors.=C2=A0 You can check out its terms of reference and 9 current wo= rk > items here > https://www.itu.int/net4/ITU-T/lists/loqr.aspx?Group=3D17&Period=3D16 > The working group was brought to my attention and I have surveyed their documents. For the purposes of this review, I considered the recently initiated ITU-T SG 17 initiatives too undeveloped for an RFC8280 Section 6.2.7 Open Standards mention. best regards, Amelia --=20 Amelia Andersdotter Technical Consultant, Digital Programme ARTICLE19 www.article19.org PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55 From nobody Fri Sep 7 13:49:34 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB39812F18C; Fri, 7 Sep 2018 13:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 qUbQxRfca31P; Fri, 7 Sep 2018 13:49:21 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 B177B130DE2; Fri, 7 Sep 2018 13:49:21 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1fyNgs-0005tB-MJ; Fri, 07 Sep 2018 22:49:19 +0200 To: Hrpc , its@ietf.org From: Amelia Andersdotter Openpgp: preference=signencrypt Autocrypt: addr=amelia@article19.org; prefer-encrypt=mutual; keydata= xsFNBFjWlnsBEAC+jUN+LJE+mmxEL8lHSrvg47xSBMb9GdtH1Jr8tRSxXiO6R5E+FydsfqkL sjO0dI3x/VnNBi/kgPFFWiAzDEwGTiR/C9b/Muo+xrY+it6e49N56LTPGezrY2dy5yo6VcLl 7UwGz3fIWiNIj7dvuoPMBoO1uacF073E+dqDM5CmNh6o+OrHW8zhUlC9hKgXCq+8XpZJw90H un1zsHF0sRDiurjfYaCcbdAGK9+th9378ed1ZvLVo5uBVQXdydl3eJkNCOELq7VOS7oxSliA uX5/nj9A4LjeeYXgNbwGfKrMjlffP0FcAcgfzg9seqDd1DEk9EVaUMTr32fbWOQHjinXSC7r Lw4xaNfoBebIe1M6z16Xg7+bXXCTdmJYcL9ugmkvT6tGnR12Pfoca1oBwXPvA0VIRi86kCSU D9qvZ3Vl07MKD2hsvFkGZJOQfEaYv5QLpCWv6RCjfDNC05IyMeSW4H18Fr/BoHX8FXHV3+9H LsbJQ/Zrofd/Cm+TKEmXLAtYc7iXvzV+mw3/u0VYqjEy/CRYa62Ah0NNNVIuswfRVIfx3UZo jX4y8j2Kh0jtUV5A4GGf8H3SzQ/cB0I7wTRHU9mCPVCtH6M26nPumL4Zr4D6uGnAmPf9xnlX lokOn2Qxf/mBldsL41PDbEpYhZvvn5kJ/Z9Qh7Fks/hfTbbJowARAQABzSxBbWVsaWEgQW5k ZXJzZG90dGVyIDxhbWVsaWFAYW5kZXJzZG90dGVyLmNjPsLBlwQTAQgAQQIbIwUJCWYBgAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYhBD1dtsq4UrmIBVpqb/7xwpS06AtVBQJY1pdiAhkB AAoJEP7xwpS06AtVI0sP/Al6eUycymdT1R7v0uEQv4coonnOUV6FKj/4wc+wM+A0h7vlqADr j4nS7RRSQRUo8xJ9tvR9J1Eyske5bvakOYv64f9PrNY1Z6ABhJzK34kJxekEfeLmpXAB4wst GhD8dGC/z/b9Oau0AW1GWIP0eNWq4acDf9Qf+j0wqQi25OZUXnu5KeUX7mvPTHKZLyEZlwHV atXmZHWKnQWtEPZTQfv/zESsoBAm1TbaLapgxVG9uLW+I9kj72TB/AZ5hMSKMYWZ2dC+8eEs Xd22tn6907aUmZhFT89jbEyS996WeZ+SQ5G1Okrq02qYXcCi5vm3AuvLlbRYHguh42TLaVq1 er7PiYOYH77FFmnZWW6ChFnf7xsDep2tpNxn+QUZLgO3+5kL7TfO7D2H57kjVVMdkNn+01nz kfcn76K7nuU6Dc4pItPzbDndhdxulnm9cicOEfGQqvta9ffxk4YWyAu9PUNARVRNf6OnoDQQ Zo8l1o37q9PFXJyQwzvxdd9u6uzTny2wp9eig75pD3dYHCRIQeYmkv1kB81mc86cwgvuw1Qy /QwiCBNXSSuIvLO78b+/dB0DLVQC/c6gtyWXRpC4ysF4EaEZophjT60d12YRanR+fWuH+qu2 wsT+z1d4tC5/6UJMPr3bxREh9JHThm5Y3cDBmcn0PGqtDKkwjCkqex5bzsFNBFjWlnsBEADF jusaTo9W8VeWluCK/oJqyyyF1wMvou0ldfuoOpUZrOqsY67TM7yBqsv5COPVgAV+xp+axor5 oHWxibd283w0Ok4dK6tvtNGwUqyDRlHtQ92DG/u4Tg5eOwrHNUn73/rfeBD9KhKAXcNKKPoc cLgR8oQTXpO7eRo+0NI52pXQ6LdZ0wddYeTcHglsNKN1TK+CyYS7xfGolsZXXoBOKcyhfj/c kPFVIHWpGpEtcYWTZWvXgLprzHvpKzkzNyBwejaXE+bqCT2dRl3omI/e2t3Vq33hFUUSAdxr FF29vMX/YsSnYqsFOIoayna+TRsDFAfZvbvHBOMckeJzvA8yBdadw7CM08Uw8wqH7n9BA3oq //QpZJekPfrc2E9nM9H0d51T0uStLMbYDWdwxvfPA3p9z8L91vobt8bM/Jbhl9h+X2Yq9oBC iTI7b2izYd9FVG4BwBIdeh3bh9R9HExgRjF3XQ6uafT3pcVOPASdv9FRUYH1Va7QWQifoha0 B7UXKx1OpX1Z6XR2NQ9KN2MvlwvBKdHtm6tBzUIFzW6D8vUOxiYKBA4fppJt/LJF4jsaCEyI /CVQnkC0yL5DKFOdigxTipwEL9Uc6r7VfR5OAGFd6vzuJFy+j+/WhzaVT1oVYp6eQXh0bBtq qH2Mq9sAMnIjvaNYIKiQKgMa1Pa3OWQbQQARAQABwsF8BBgBCAAmFiEEPV22yrhSuYgFWmpv /vHClLToC1UFAljWlnsCGwwFCQlmAYAACgkQ/vHClLToC1XnRw//W4lzE8FddceKXGRwO/T1 u4uzH9EjPCj+3/eHCrLI+h1m7QPyH1DrFAtZBoA6UoaF0+vIAJXM9/HI1FZ09EUdJr5X/+YR EErFom4DbE1FK8fpK1/Hw2zI+7Xa8bVkmYrKhMGhi1Gq6Dtksn/H4USdJL53ZPt10SVNK7H3 w93Yp1GC4+0zWjfrsKfsHYZZr2SZyb5/gZlngfgaqiQLhIcPYmiU1GQi9QWkGxWRxk0YQXBw hekewvgltATxlRSCwguAi4uck9fAct9GGdpsshSOgAb9YIAnEV3EqaGnf0PknXp3vNHAZWrf M+RyuNdm2L5TjDU0rIrvyqGP3pR33cREGOAil5Sz2uFArmwsPt8VffbEXlf7qZqRBKaYeKt0 qnxKMx1+e1JilVsfb8qtnAWAFDyR0HMlVj/dvGAmq/auPSOAUWRSnDRyT6rv/vXxrbkL4uxW ax46qdpDhR15mS5MTng6b5b3Uox7xlveo/Sx71AdNf4goPvB/ntv0DiMuh+fmLGk3zrxs4Xd 30Sx+qQwVaXR5xc5rgnF81wvfmuAOb2eP9mpD6DoabkpxC8fLk17AK7Q1ZTgcZ+8XLRFnavd PrwCa9RU0BF53lJMSTPzyBcMwZ4sqA6Z5IRFVt7rEbSeeD8REiawo+FvVt9j0fKdNEBeaJ3W Y5hlhNPcUXr4q1U= Organization: ARTICLE19 Message-ID: <32d8c171-2586-e2db-7cc6-26c3385b6946@article19.org> Date: Fri, 7 Sep 2018 22:49:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US-large X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 72be745e4a817e3b6c39dafddcade14f Archived-At: Subject: [ipwave] RFC8280 Human Rights Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 20:49:25 -0000 Dear all, As part of efforts in the Human Rights Protocol Considerations (HRPC) group, I have reviewed the human rights considerations (RFC 8280) in IPv6-over-OCB v25. https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/25/= I've briefly reviewed v26 of the document, and find that the general recommendations and observations below still hold in general. The review is ended with an ERRATA (editorial remarks). The below text has been sent to the author of the document on September 4, and some comments were received today (September 7). In this submission, I'm hoping to open up for input from the larger community. best regards, Amelia # Summary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D I understand that Sections 6.2.1 (Connectivity), 6.2.3 (Content agnosticism), 6.2.6 (Censorship Resistenace), 6.2.8 (Heterogeneity support) and 6.2.18 (Adaptability) of RFC8280 are taken into account by the draft. References in the draft on less accessible standards in accordance with Section 6.2.7 (Open Standards) in RFC8280 follows a previously submitted evaluation. I suggest expansions on topics related to Sections 6.2.2 (Privacy), 6.2.4 (Security), 6.2.9 (Anonymity), 6.2.10 (Pseudonymity), 6.2.14 (Reliability), 6.2.16 (Integrity) and 6.2.17 (Authenticity) in RFC8280. I do not identify any concerns raised by Sections 6.2.5 (Internationalization), 6.2.11 (Accessibility), 6.2.12 (Localization) and 6.2.19 (Outcome transparency) in RFC8280. # Topical human rights review =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ## Part 1: Privacy, reliability, integrity and authenticity =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This part reviews IPv6-over-80211-OCB draft with respect to Sections 6.2.2 (Privacy), 6.2.4 (Security), 6.2.9 (Anonymity), 6.2.10 (Pseudonymity), 6.2.14 (Reliability), 6.2.16 (Integrity) and 6.2.17 (Authenticity) in RFC8280. Privacy and security issues are raised in various places of the documents, for instance in Section 1, Section 4.5, Section 5 and Appendix C, D and F. HoIver, while they are raised, no specific recommendations to mitigate concerns are made. It is only mentioned that other documents and standards do propose risk mitigation strategies. The considerations raised in Appendix F.3 regarding the reliability and integrity of the transmission schemes seem like they could have a big impact on what functionalities must be included in this draft. If the IPv6 transmission itself needs to guarantee specified senders and receivers, this would require different privacy trade-offs in the rest of the document. It was not immediately clear whether link-local addresses are recommended for any particular purposes or use-cases. It is my understanding that link-local addresses restrict the ability of an interface to communicate with other interfaces than those with whom they share a direct link, and that this may entail privacy benefits. But in Section 4.6 there are conflicting references to RFC5889, where it's specified that IPv6 link-local addressing should be avoided in ad hoc networks. Many considerations in the draft are impacted by the strong necessity to use protection tools such as dynamic MAC re-addressing. This impacts the ability to use IPv6 address generation as described in Section 4 of RFC2464. But dynamic MAC re-addressing also would appear to justify the recommendation to use stable IPv6 address generation as described in RFC8064 or RFC7217. Currently, pseudonym handling is just briefly mentioned at the end of Section 5 as a security issue but given its impact on addressing and IPv6 address generation, I believe they merit their own section. In Appendix F.1, it is not clear why a mechanism to uniquely identify a vehicle is necessary. It should be clarified whether this is a technical requirement (for instance, whether this constitutes a proposal to introduce a unique identifier different from the Layer-2 MAC unique identifier), or a legal requirement, and whether this new unique identifier is intended for use in networking in general, or only for specific circumstances. ## Part 2: Internationalization, accessibility and transparency =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The functions described in this draft do not appear to be impacted by Sections 6.2.5 (Internationalization), 6.2.11 (Accessibility) or 6.2.12 (Localization) in RFC8280. Similarly, the applicability of Section 6.2.19 (Outcome transparency) in RFC8280 seems largely related to issues relating to authenticity, reliability and integrity. # Recommendations: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Collect all references to privacy and security in one place. If privacy and security is in Section 4.5, 5 and Appendix F (as specified in Section 4.5), this should be noted in Section 1. Also, privacy and security issues are only mentioned in this document: recommendations for their resolution are not present. This should be reflected in the Section= 1. 2. In Section 4, add a section named "Pseudonym handling" at the very top, describing the issues raised in the final paragraph of Section 5. Remove the last paragraph of Section 5. 3.=C2=A0 The potential privacy benefits of link-local addresses could be raised, especially since OCB transmissions are not secure against curious nodes. On the other hand, RFC5889 Section 6.1 states that link-local addressing is discouraged for ad hoc IPv6 networks. These trade-offs could be expanded upon. 4. In Section 4.3 and 4.5 it should be clarified what privacy benefits, if any, are expected from using semantically obscure IIDs as proposed in RFC7217. It will at least be relevant to clarify whether privacy benefits could arise in contexts that are explicitly out of scope (such as during forming, termination or handover), e.g. with respect to parameter selection as specified in Appendix A of RFC7217. # References: =3D=3D=3D=3D=3D=3D=3D=3D=3D [RFC8280] Research into Human Rights Protocol Considerations https://tools.ietf.org/html/rfc8280 =3D=3D# ERRATA: =3D=3D=3D=3D=3D=3D=3D=3D=3D Neither the term IP-RSU nor the term IP-OBU defined in Section 2 are actually used in the document. In Section 2, definitions, the definition of IP-RSU can be made more succinct by removing the second sentence (that is, remove "An IP-RSU has at least two distinct IP-enabled interfaces; at least one interface is operated in mode OCB of IEEE 802.11 and is IP-enabled."). Section 4.5 only needs to recommend following the procedures in RFC8064 once. In Appendix C, p. 26, 2nd to last paragraph, it is mentioned that MAC re-addressing is described in IEEE-1609.4 Section 6.7. HoIver, in my copy of IEEE-1609.4 this feature is described in Section 6.6. --=20 Amelia Andersdotter Technical Consultant, Digital Programme ARTICLE19 www.article19.org PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55 From nobody Fri Sep 7 15:59:40 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414CC130E1E for ; Fri, 7 Sep 2018 15:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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, HK_NAME_FM_MR_MRS=1.499, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 CIJfPWQfTYyf for ; Fri, 7 Sep 2018 15:59:35 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 5D22C130DC7 for ; Fri, 7 Sep 2018 15:59:35 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id q5-v6so2763418iop.3 for ; Fri, 07 Sep 2018 15:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zqglpSBBM+X8iVKZmXQcgQbAPXg+JNG4aXdOrNb1A0w=; b=DWhTD/B5onjHwDeIVXMh755Y81YSgZuXW2It+9/glh620xBh2M1Ogt1v94SM4JgH82 PSIpnMaGYmgJav+dDJ/0RjsYY8hO6trr6ojgWbwUfwW54d6Cn0D/gyC6AjItvsjVmS+S UWW9Vb6BQfjQZei9xRzBWsgD+cjI/AZv3+4XtwHqWglKCSpX0pn07m+0qf4+94odPGvX lSe2kc4MgJJW6mMgd3oqA6RLpzwYh6bBu49nsg2d9uPKtBvletyw4ZErbBQohv6W0Ly2 ZZHVX/UTNR/MB+Wh4ZEgXpYV06dECjEi/2y23qxo3tB2AOo7NhnnRmQDgxXTXhVVOtV/ 0jGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zqglpSBBM+X8iVKZmXQcgQbAPXg+JNG4aXdOrNb1A0w=; b=s5jo0zUn0MVjNp0pd3TFUrf+6vhAy+kqu4pYUbb3ZSUS7ebM8j7FhEvI9mZg7kj203 6lREquJxS2xErYDRjjhseiZTVpxD9LqyRbIlfbC1X4HW1vjT3x6ZDURJkwqD1cTjay96 xVaQX3Yvclwg+Az9DU4TCrJEznrr0IFa//ZZ3jqUimzqZzF3Icb6MwHq7ZIjS1PYzr5N aJMLLbukO8mvJo3FKGdujOS8eX0JOGAMxfOK0AgGlOYSD/k5YlrfLL8NDM7K+G+CLJWr /4UlErUa4QfRIEtXCg0YinNNmbh6yPymvMso7IsWKM5F3LGrhejZgcS2W2XbUdgwC+hp WXBA== X-Gm-Message-State: APzg51C5y2BeIxZiwYCElvVu+rfAKnR8PBtQE+msMt1rgwboCjHZAYrI isxY5UHfOEnrJiwcLFQ9NxKluQ1DzM3Kqq7l9d8= X-Google-Smtp-Source: ANB0VdbTBoljIfKBPd/rb80sIBv/uoQobby3/AK1mOGNILh/IYV03UrLcmLGoLqmZodoNt8Dv7uUMK3zpDpWGcRaLjI= X-Received: by 2002:a6b:928b:: with SMTP id u133-v6mr8082099iod.296.1536361174247; Fri, 07 Sep 2018 15:59:34 -0700 (PDT) MIME-Version: 1.0 References: <0103d901-baf7-6a2f-391f-4d6e905fdefd@article19.org> In-Reply-To: <0103d901-baf7-6a2f-391f-4d6e905fdefd@article19.org> From: "Mr. Jaehoon Paul Jeong" Date: Sat, 8 Sep 2018 07:59:23 +0900 Message-ID: To: Amelia Andersdotter Cc: Hrpc , its@ietf.org Content-Type: multipart/alternative; boundary="00000000000009afe805754ff655" Archived-At: Subject: Re: [ipwave] Human Rights Review of draft-ietf-ipwave-vehicular-networking-04 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 22:59:38 -0000 --00000000000009afe805754ff655 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Amelia, As the editor of this document, I sincerely appreciate your review and will use it in the next revision. Thanks Best Regards, Paul 2018=EB=85=84 9=EC=9B=94 7=EC=9D=BC (=EA=B8=88) =EC=98=A4=ED=9B=84 7:08, Am= elia Andersdotter =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84= =B1: > Dear all, > > As part of efforts in the Human Rights Protocol Considerations (HRPC) > group, I have reviewed the human rights considerations (RFC 8280) in > IPWAVE Problem Statement. > https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ > > The below text has been sent to the author of the document on August 28. > I'm now hoping for input from the larger community. > > best regards, > > Amelia > > # Summary > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > I understand that the draft contains a satisfactory treatment of the > human rights concerns listen in Section 6.2.1 (Connectivity), 6.2.3 > (Content agnosticism), 6.2.8 (Heterogeneity support), Section 6.2.14 > (Reliability), Section 6.2.16 (Integrity), Section 6.2.17 (Authenticity) > and 6.2.18 (Adaptability) of RFC8280. I have also traced some of the > dependencies of the draft on less accessible standards in accordance > with Section 6.2.7 (Open Standards) in RFC8280. > > I have suggested improvements with respect to human rights concerns > listed in Sections 6.2.2 (Privacy), 6.2.4 (Security), 6.2.6 (Censorship > Resistenace), 6.2.9 (Anonymity), 6.2.10 (Pseudonymity), 6.2.13 > (Decentralization), 6.2.15 (Confidentiality) and 6.2.19 (Outcome > transparency) in RFC8280. > > I finally make two suggestions related to Sections 6.2.5 > (Internationalization), 6.2.11 (Accessibility) and 6.2.12 (Localization) > in RFC8280. > > # Topical human rights review > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > ## Part 1: Privacy, decentralization, transparency > ----------------------------------------------------------------------- > > This part reviews IPWAVE Problem Statement draft from the perspectives > of Sections 6.2.2 (Privacy), 6.2.4 (Security), 6.2.6 (Censorship > Resistenace), 6.2.9 (Anonymity), 6.2.10 (Pseudonymity), 6.2.13 > (Decentralization), 6.2.15 (Confidentiality) and 6.2.19 (Outcome > transparency) in RFC8280. > > In Section 4.1.7 Current Protocols for Vehicular Networking: Security > and Privacy, the focus is only on encryption and certificate exchanges. > I believe this can be complemented by raising topics that have been > prevalent in vehicular communications for a large number of years. > Notably data minimization and geolocalisation threats (see e.g. RFC6973, > section 6.1: Data minimization). > > It is generally recognised that vehicular communications face particular > security and privacy challenges, with the driver of the connected > vehicle perhaps being obliged by law to disseminate specified, and > verifiably accurate, data. This makes the driver unable to deploy common > privacy strategies, such as obfuscation, and calls for extra careful > consideration of durable connections (such as connections that last over > pseudonym changes, thereby opening new privacy attack vectors). > Pseudonym changes are therefore proposed as alternative privacy risk > mitigations. > > In Section 5.3, there is focus on integrity (RFC8280, Section 6.2.16) > and authenticity (RFC8280, Section 6.2.17), where the privacy and > security complications arising from vehicular networks are, I insist, > broader in scope. It is not clear that the Vehicle Identification Number > (VIN) would not be used to track a vehicle or its driver against his or > her wishes, even if the MAC address and IP address are randomized or > re-addressed. Of particular importance are those situations where > drivers are not legally alloId to discontinue a particular connection > (see also RFC6973, Section 6.2: User Control or RFC8280, Section 6.2.6: > Censorship Resistance and Section 6.2.15: Confidentiality). > > I see a need for at least reflection on the centralized properties of > authentication and certificate schemes in Section 5.3 (see e.g. RFC8280, > Section 6.2.13: Decentralization). Depending on which agent is > ultimately endoId with the responsibility of issuing certificates for > security purposes, there may be large downstream market effects on > drivers and the service providers available for drivers to choose. In > fact, this is a central issue in drivers' associations concerns with > vehicular communications and, in general, telematics[2]. Both of these > considerations call into question whether the "same" network should be > used for all use-cases listed in Section 3 of the Problem Statement. It > may be, for instance, that pseudonym self-issuance should be considered > for some use-cases, but not for others. An overview of pseudonym > issuance strategies is found in [3]. > > Finally, there has been some attention in literature to the use of OBU > caching as a way of minimizing contacts with RSU[4], or including > options to collect information from other near-by vehicles instead of > from the RSU when a querying need arises. IPWAVE may want to delve > further into the topic of how this might work in an ad hoc 802.11 > network and whether IPWAVE gives options for solutions that are not as > well present in other technologies. > > ## Part 2: Internationalization and accessibility > ------------------------------------------------------------------ > > This part reviews IPWAVE Problem Statement draft from the perspectives > of Sections 6.2.5 (Internationalization), 6.2.11 (Accessibility) and > 6.2.12 (Localization) in RFC8280. These sections deal with ways in which > affected parties can interact effortlessly with resulting specifications. > > The IPWAVE Problem Statement draft any obvious efforts to address the > issues raised in those sections of RFC8280. That said, accessibility as > in Sections 6.2.11 or 6.2.12 may require the cooperation of user > interface designers and higher layers. > > In the context of internationalization and localization, I note that > references to regulatory frameworks that put natural boundaries on the > scope of the projects proposed within the Problem Statement are limited > to North America and Europe. It is not clear whether those geographical > regions that use different alphabets or logographs have a greater > interest in internationalization and localization, than those > geographical regions that predominantly rely on the latin alphabet. This > could be clarified. > > In the context of privacy options discussed above, it is the case that > the standards developed in IPWAVE are more likely to be consumed by > implementers and user interface designers at higher layers than by > drivers of vehicles. In the interest of accessibility and localization, > clarity with respect to privacy-, user control- or security-enhancing > features for the implementers is paramount to ensure that these features > do not end up obscured. > > ## Part 3: Open standards > -------------------------------------- > > This part reviews IPWAVE Problem Statement draft from the perspective of > Section 6.2.7 (Open Standards) in RFC8280. > > It may be noted that the IETF as such makes open standards and maintains > openness throughout the standard developments deliberations. Many of the > standards referenced in Problem Statement are not open. IEEE 1609 and > IEEE 802.11-OCB may require subscriptions for researchers and > implementers to accesss for some time after the completion of a > standardisation project, while ISO standards are always closed to the > public, in the sense that they sell access to their standards. ETSI and > 3GPP standards become accessible to the public only upon their conclusion= . > > # Recommendations > ----------------------------- > > 1. In our literature review, I found one proposal to use Multipath TCP > to enable lasting connections in spite of re-addressing[1]. This study > could be tentatively inserted in Section 4.1.7. Reference [3] should be > added to section 5.3 together with observations made above. Similarly > section 5.3 could cover reference [4]. > > 2. Due consideration should be given to the fact that a lasting > connection risks defeating some of the purposes of pseudonym > randomization/re-issuance, since the lasting connection would then in > and of itself become a way to track the vehicle. The Vehicle > Identification Number (VIN) risks defeating the purpose of re-addressing > or pseudonym handling, if it is used as an authentication mechanism. > Section 4.2.4 Pseudonym Handling or Section 5.3 could raise this issue. > Of particular importance for a vehicle owner or driver will be whether > these durable connections are mandatory to enable under any legislation. > > It could be considered whether different certificate issuance strategies > can be deployed for different types of connections. > > 3. I believe an additional definition is needed for the word > "pseudonym", in order to clarify that by this word the document means > the same thing as is meant by MAC/Layer-2 Randomization in P802.11aq, > the readdressing feature described in IEEE 1609.4-2016, or the temporary > identifiers referenced in ETSI TS 102 941. > > 4. IPWAVE should make it clear it intends that privacy-friendly options > should be made explicit to implementers in the developed standards. > > 5. The working group may consider whether to undertake greater > internationalization efforts inside the group, or request it from other > working groups, bearing in mind that some of the geographical regions > not covered by the regulatory review may consider this a perk. > > [1] S. Han, H. Kim and Y. Park, "Overcoming IP communication breakdown > upon pseudonym changes in the IEEE WAVE," 2017 IEEE Vehicular Networking > Conference (VNC), Torino, 2017, pp. 183-186. > doi: 10.1109/VNC.2017.8275622 > URL: > > http://ieeexplore.ieee.org.ludwig.lub.lu.se/stamp/stamp.jsp?tp=3D&arnumbe= r=3D8275622&isnumber=3D8275590 > > [2] FIA, http://mycarmydata.eu > > [3] J. Petit, F. Schaub, M. Feiri and F. Kargl, "Pseudonym Schemes in > Vehicular Networks: A Survey," in IEEE Communications Surveys & > Tutorials, vol. 17, no. 1, pp. 228-255, Firstquarter 2015. > doi: 10.1109/COMST.2014.2345420 > URL: > > http://ieeexplore.ieee.org.ludwig.lub.lu.se/stamp/stamp.jsp?tp=3D&arnumbe= r=3D6873216&isnumber=3D7061782 > > > [4] B. Liu, W. Zhou, T. Zhu, L. Gao, T. H. Luan and H. Zhou, "Silence is > Golden: Enhancing Privacy of Location-Based Services by Content > Broadcasting and Active Caching in Wireless Vehicular Networks," > in /IEEE Transactions on Vehicular Technology/, vol. 65, no. 12, pp. > 9942-9953, Dec. 2016. > doi: 10.1109/TVT.2016.2531185 > URL: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D7414507&isnum= ber=3D7779452 > > -- > Amelia Andersdotter > Technical Consultant, Digital Programme > > ARTICLE19 > www.article19.org > > PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55 > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --00000000000009afe805754ff655 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Amelia,
As the editor of this documen= t, I sincerely appreciate your review and will use it in the next revision.=

Thanks=C2=A0

Best Regards,
Paul

2018=EB= =85=84 9=EC=9B=94 7=EC=9D=BC (=EA=B8=88) =EC=98=A4=ED=9B=84 7:08, Amelia An= dersdotter <amelia@article19.org= >=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
Dear all,

As part of efforts in the Human Rights Protocol Considerations (HRPC)
group, I have reviewed the human rights considerations (RFC 8280) in
IPWAVE Problem Statement.
https://datatrack= er.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/

The below text has been sent to the author of the document on August 28. I'm now hoping for input from the larger community.

best regards,

Amelia

# Summary
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

I understand that the draft contains a satisfactory treatment of the
human rights concerns listen in Section 6.2.1 (Connectivity), 6.2.3
(Content agnosticism), 6.2.8 (Heterogeneity support), Section 6.2.14
(Reliability), Section 6.2.16 (Integrity), Section 6.2.17 (Authenticity) and 6.2.18 (Adaptability) of RFC8280. I have also traced some of the
dependencies of the draft on less accessible standards in accordance
with Section 6.2.7 (Open Standards) in RFC8280.

I have suggested improvements with respect to human rights concerns
listed in Sections 6.2.2 (Privacy), 6.2.4 (Security), 6.2.6 (Censorship
Resistenace), 6.2.9 (Anonymity), 6.2.10 (Pseudonymity), 6.2.13
(Decentralization), 6.2.15 (Confidentiality) and 6.2.19 (Outcome
transparency) in RFC8280.

I finally make two suggestions related to Sections 6.2.5
(Internationalization), 6.2.11 (Accessibility) and 6.2.12 (Localization) in RFC8280.

# Topical human rights review
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
## Part 1: Privacy, decentralization, transparency
-----------------------------------------------------------------------

This part reviews IPWAVE Problem Statement draft from the perspectives
of Sections 6.2.2 (Privacy), 6.2.4 (Security), 6.2.6 (Censorship
Resistenace), 6.2.9 (Anonymity), 6.2.10 (Pseudonymity), 6.2.13
(Decentralization), 6.2.15 (Confidentiality) and 6.2.19 (Outcome
transparency) in RFC8280.

In Section 4.1.7 Current Protocols for Vehicular Networking: Security
and Privacy, the focus is only on encryption and certificate exchanges.
I believe this can be complemented by raising topics that have been
prevalent in vehicular communications for a large number of years.
Notably data minimization and geolocalisation threats (see e.g. RFC6973, section 6.1: Data minimization).

It is generally recognised that vehicular communications face particular security and privacy challenges, with the driver of the connected
vehicle perhaps being obliged by law to disseminate specified, and
verifiably accurate, data. This makes the driver unable to deploy common privacy strategies, such as obfuscation, and calls for extra careful
consideration of durable connections (such as connections that last over pseudonym changes, thereby opening new privacy attack vectors).
Pseudonym changes are therefore proposed as alternative privacy risk
mitigations.

In Section 5.3, there is focus on integrity (RFC8280, Section 6.2.16)
and authenticity (RFC8280, Section 6.2.17), where the privacy and
security complications arising from vehicular networks are, I insist,
broader in scope. It is not clear that the Vehicle Identification Number (VIN) would not be used to track a vehicle or its driver against his or
her wishes, even if the MAC address and IP address are randomized or
re-addressed. Of particular importance are those situations where
drivers are not legally alloId to discontinue a particular connection
(see also RFC6973, Section 6.2: User Control or RFC8280, Section 6.2.6:
Censorship Resistance and Section 6.2.15: Confidentiality).

I see a need for at least reflection on the centralized properties of
authentication and certificate schemes in Section 5.3 (see e.g. RFC8280, Section 6.2.13: Decentralization). Depending on which agent is
ultimately endoId with the responsibility of issuing certificates for
security purposes, there may be large downstream market effects on
drivers and the service providers available for drivers to choose. In
fact, this is a central issue in drivers' associations concerns with vehicular communications and, in general, telematics[2]. Both of these
considerations call into question whether the "same" network shou= ld be
used for all use-cases listed in Section 3 of the Problem Statement. It
may be, for instance, that pseudonym self-issuance should be considered
for some use-cases, but not for others. An overview of pseudonym
issuance strategies is found in [3].

Finally, there has been some attention in literature to the use of OBU
caching as a way of minimizing contacts with RSU[4], or including
options to collect information from other near-by vehicles instead of
from the RSU when a querying need arises. IPWAVE may want to delve
further into the topic of how this might work in an ad hoc 802.11
network and whether IPWAVE gives options for solutions that are not as
well present in other technologies.

## Part 2: Internationalization and accessibility
------------------------------------------------------------------

This part reviews IPWAVE Problem Statement draft from the perspectives
of Sections 6.2.5 (Internationalization), 6.2.11 (Accessibility) and
6.2.12 (Localization) in RFC8280. These sections deal with ways in which affected parties can interact effortlessly with resulting specifications.
The IPWAVE Problem Statement draft any obvious efforts to address the
issues raised in those sections of RFC8280. That said, accessibility as
in Sections 6.2.11 or 6.2.12 may require the cooperation of user
interface designers and higher layers.

In the context of internationalization and localization, I note that
references to regulatory frameworks that put natural boundaries on the
scope of the projects proposed within the Problem Statement are limited
to North America and Europe. It is not clear whether those geographical
regions that use different alphabets or logographs have a greater
interest in internationalization and localization, than those
geographical regions that predominantly rely on the latin alphabet. This could be clarified.

In the context of privacy options discussed above, it is the case that
the standards developed in IPWAVE are more likely to be consumed by
implementers and user interface designers at higher layers than by
drivers of vehicles. In the interest of accessibility and localization,
clarity with respect to privacy-, user control- or security-enhancing
features for the implementers is paramount to ensure that these features do not end up obscured.

## Part 3: Open standards
--------------------------------------

This part reviews IPWAVE Problem Statement draft from the perspective of Section 6.2.7 (Open Standards) in RFC8280.

It may be noted that the IETF as such makes open standards and maintains openness throughout the standard developments deliberations. Many of the standards referenced in Problem Statement are not open. IEEE 1609 and
IEEE 802.11-OCB may require subscriptions for researchers and
implementers to accesss for some time after the completion of a
standardisation project, while ISO standards are always closed to the
public, in the sense that they sell access to their standards. ETSI and
3GPP standards become accessible to the public only upon their conclusion.<= br>
# Recommendations
-----------------------------

1. In our literature review, I found one proposal to use Multipath TCP
to enable lasting connections in spite of re-addressing[1]. This study
could be tentatively inserted in Section 4.1.7. Reference [3] should be
added to section 5.3 together with observations made above. Similarly
section 5.3 could cover reference [4].

2. Due consideration should be given to the fact that a lasting
connection risks defeating some of the purposes of pseudonym
randomization/re-issuance, since the lasting connection would then in
and of itself become a way to track the vehicle. The Vehicle
Identification Number (VIN) risks defeating the purpose of re-addressing or pseudonym handling, if it is used as an authentication mechanism.
Section 4.2.4 Pseudonym Handling or Section 5.3 could raise this issue.
Of particular importance for a vehicle owner or driver will be whether
these durable connections are mandatory to enable under any legislation.
It could be considered whether different certificate issuance strategies can be deployed for different types of connections.

3. I believe an additional definition is needed for the word
"pseudonym", in order to clarify that by this word the document m= eans
the same thing as is meant by MAC/Layer-2 Randomization in P802.11aq,
the readdressing feature described in IEEE 1609.4-2016, or the temporary identifiers referenced in ETSI TS 102 941.

4. IPWAVE should make it clear it intends that privacy-friendly options
should be made explicit to implementers in the developed standards.

5. The working group may consider whether to undertake greater
internationalization efforts inside the group, or request it from other
working groups, bearing in mind that some of the geographical regions
not covered by the regulatory review may consider this a perk.

[1] S. Han, H. Kim and Y. Park, "Overcoming IP communication breakdown=
upon pseudonym changes in the IEEE WAVE," 2017 IEEE Vehicular Networki= ng
Conference (VNC), Torino, 2017, pp. 183-186.
doi: 10.1109/VNC.2017.8275622
URL:
http://ieeexplore.ieee.org.ludwig.lub.lu.se/stamp/s= tamp.jsp?tp=3D&arnumber=3D8275622&isnumber=3D8275590

[2] FIA, http://mycarmydata.eu

[3] J. Petit, F. Schaub, M. Feiri and F. Kargl, "Pseudonym Schemes in<= br> Vehicular Networks: A Survey," in IEEE Communications Surveys & Tutorials, vol. 17, no. 1, pp. 228-255, Firstquarter 2015.
doi: 10.1109/COMST.2014.2345420
URL:
http://ieeexplore.ieee.org.ludwig.lub.lu.se/stamp/s= tamp.jsp?tp=3D&arnumber=3D6873216&isnumber=3D7061782


[4] B. Liu, W. Zhou, T. Zhu, L. Gao, T. H. Luan and H. Zhou, "Silence = is
Golden: Enhancing Privacy of Location-Based Services by Content
Broadcasting and Active Caching in Wireless Vehicular Networks,"
in=C2=A0/IEEE Transactions on Vehicular Technology/, vol. 65, no. 12, pp. 9942-9953, Dec. 2016.
doi: 10.1109/TVT.2016.2531185
URL:=C2=A0http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumbe= r=3D7414507&isnumber=3D7779452

--
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55


_______________________________________________
its mailing list
its@ie= tf.org
https://www.ietf.org/mailman/listinfo/its
--00000000000009afe805754ff655-- From nobody Sat Sep 8 04:21:47 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047691286E3 for ; Sat, 8 Sep 2018 04:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 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, FREEMAIL_REPLY=1, HK_NAME_FM_MR_MRS=1.499, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 cFgps0UgdKqc for ; Sat, 8 Sep 2018 04:21:43 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 BC8221277D2 for ; Sat, 8 Sep 2018 04:21:43 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id x79-v6so1744442ita.1 for ; Sat, 08 Sep 2018 04:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AoQE/rwp9WWERu+/pACIn+xOJIgOmXPKt71gyzPV/t0=; b=NQ2vgzzp/h0NJaE0R0lYraDaX/xRwi7au7NsPPBKK4nEKY4N00iekqkOals2GaKSv4 onThnYBlW6N/IAmlaf9Ik8d1MhgTZZ4lHgbZcGswWk92JeTWkJuxBa9s2kGA/k/k2GZv Kg2+vZXAymOd15aLV7Biulh0v0MMgH5l/pXM9DcwrOjlV2Xjc7EQbR+WEWsQbUZ64T3R EZCLA8AbO8pAMPJYpD4sn7brnVkLx8iOlRUl8XpQdiNygdBlTYPWnypjmzbQkXA84GAF 9NxzQ9CW3KE0prXg932ZGQHyZKeNIz59s/vqsZIj3M4o6ejXgAubG0ntQRGK6vqB2Og8 59jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AoQE/rwp9WWERu+/pACIn+xOJIgOmXPKt71gyzPV/t0=; b=FL7dk9ueyaxaCZ++q1k/iuuO5zm5ODT9cf87TkJZ8raQH7OJbTe0eMvJFBxMX51Jsn 6CjaOcVynK/RAMmGbR1sGTuwAjAu8VvGiJEnIWIYYRtifbp0apPYRabiP7uT7v93TgE3 O7yP0XWyFaTnmFIX58urA3CxcErARq+htoqhmSpSExT7+xVTQrjt6goVgGgCnsMVt0IL qZtctV6r1zJunNXN/Ut5peJ2sjC1ZBECoQc/8WW4+svRI5SCHvEH3itGoLwcfGqUJrci tWvm65g/g80KD+bMQmOv2GJE3ezUcjXWrL5kjBf+eOckJRS9RxYm/etgN+oc01OYmkab MbYQ== X-Gm-Message-State: APzg51CYcnMDgUAtKMeysd/WF3/Vv0aRfJAD5jDp0ii4f4ZYQWj5FmTf kHfmOjtEvCFJ8bsiNFRs/BRItyxWGkzq4KmST80= X-Google-Smtp-Source: ANB0VdYOa7tKOHEGjPLVd+qVr2QmX4B1BNZHMHD+psqsd5VzVGzVxExUjMJtVKNaij1Upt2dvXRp8sKsfsZ/guYkN7A= X-Received: by 2002:a24:d9d6:: with SMTP id p205-v6mr10236283itg.89.1536405702915; Sat, 08 Sep 2018 04:21:42 -0700 (PDT) MIME-Version: 1.0 References: <153173368076.22957.11710630143747180156@ietfa.amsl.com> In-Reply-To: From: "Mr. Jaehoon Paul Jeong" Date: Sat, 8 Sep 2018 20:21:02 +0900 Message-ID: To: Michelle Wetterwald Cc: its@ietf.org Content-Type: multipart/alternative; boundary="000000000000273b0e05755a5465" Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-04.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 11:21:46 -0000 --000000000000273b0e05755a5465 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michelle, Thanks for your review. I will reflect your comments on the next revision. Best Regards, Paul On Fri, Aug 31, 2018 at 11:55 PM Michelle Wetterwald wrote: > Hi Paul, > > During the Montreal meeting, I committed as well to review the draft but > could not make it before my holidays. Please find attached a marked Word > file with all my comments. > Best regards, > -- > Michelle Wetterwald > michelle.wetterwald@gmail.com > > > Le lun. 16 juil. 2018 =C3=A0 11:35, a =C3=A9cr= it : > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IP Wireless Access in Vehicular >> Environments WG of the IETF. >> >> Title : IP Wireless Access in Vehicular Environments >> (IPWAVE): Problem Statement and Use Cases >> Author : Jaehoon Paul Jeong >> Filename : draft-ietf-ipwave-vehicular-networking-04.txt >> Pages : 30 >> Date : 2018-07-16 >> >> Abstract: >> This document discusses the problem statement and use cases on IP- >> based vehicular networks, which are considered a key component of >> Intelligent Transportation Systems (ITS). The main topics of >> vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- >> infrastructure (V2I), and vehicle-to-everything (V2X) networking. >> First, this document surveys use cases using V2V, V2I, and V2X >> networking. Second, it analyzes proposed protocols for IP-based >> vehicular networking and highlights the limitations and difficulties >> found on those protocols. Third, it presents a problem exploration >> for key aspects in IP-based vehicular networking, such as IPv6 >> Neighbor Discovery, Mobility Management, and Security & Privacy. For >> each key aspect, this document discusses a problem statement to >> analyze the gap between the state-of-the-art techniques and >> requirements in IP-based vehicular networking. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-04 >> >> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networ= king-04 >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-vehicular-networki= ng-04 >> >> >> 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/ >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --000000000000273b0e05755a5465 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michelle,
Thanks for your review.

I will reflect your comments on the next revision.

Best Regards,
Paul


On Fri, Aug 31, 2018 at 11:55 PM Miche= lle Wetterwald <mlwetterwald@g= mail.com> wrote:
Hi Paul,

During the Mo= ntreal meeting, I=C2=A0committed as well to review the draft but could not = make it before my holidays. Please find attached a=C2=A0marked Word file=C2= =A0with all my comments.
Best regards,
--
Michelle Wetterwald
=


Le=C2= =A0lun. 16 juil. 2018 =C3=A0=C2=A011:35, <internet-drafts@ietf.org> a =C3=A9cr= it=C2=A0:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IP Wireless Access in Vehicular Environmen= ts WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement a= nd Use Cases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Jaeh= oon Paul Jeong
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ipwave-vehicular-networking-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-07-16

Abstract:
=C2=A0 =C2=A0This document discusses the problem statement and use cases on= IP-
=C2=A0 =C2=A0based vehicular networks, which are considered a key component= of
=C2=A0 =C2=A0Intelligent Transportation Systems (ITS).=C2=A0 The main topic= s of
=C2=A0 =C2=A0vehicular networking are vehicle-to-vehicle (V2V), vehicle-to-=
=C2=A0 =C2=A0infrastructure (V2I), and vehicle-to-everything (V2X) networki= ng.
=C2=A0 =C2=A0First, this document surveys use cases using V2V, V2I, and V2X=
=C2=A0 =C2=A0networking.=C2=A0 Second, it analyzes proposed protocols for I= P-based
=C2=A0 =C2=A0vehicular networking and highlights the limitations and diffic= ulties
=C2=A0 =C2=A0found on those protocols.=C2=A0 Third, it presents a problem e= xploration
=C2=A0 =C2=A0for key aspects in IP-based vehicular networking, such as IPv6=
=C2=A0 =C2=A0Neighbor Discovery, Mobility Management, and Security & Pr= ivacy.=C2=A0 For
=C2=A0 =C2=A0each key aspect, this document discusses a problem statement t= o
=C2=A0 =C2=A0analyze the gap between the state-of-the-art techniques and =C2=A0 =C2=A0requirements in IP-based vehicular networking.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org= /doc/draft-ietf-ipwave-vehicular-networking/

There are also htmlized versions available at:
https://tools.ietf.org/html/dra= ft-ietf-ipwave-vehicular-networking-04
https://datatracker.i= etf.org/doc/html/draft-ietf-ipwave-vehicular-networking-04

A diff from the previous version is available at:
https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-ipwave-vehicular-networking-04


Please note that it may take a couple of minutes from the time of submissio= n
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/

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



<= /div>
_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


--
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department= of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email= : jaehoon.paul@= gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>
--000000000000273b0e05755a5465-- From nobody Wed Sep 12 07:31:26 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F030F130E4A for ; Wed, 12 Sep 2018 07:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 x1pa3674wYp9 for ; Wed, 12 Sep 2018 07:31:23 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 99E171277C8 for ; Wed, 12 Sep 2018 07:31:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8CEVKRE042469 for ; Wed, 12 Sep 2018 16:31:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E7359200C68 for ; Wed, 12 Sep 2018 16:31:20 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DBFD52020C1 for ; Wed, 12 Sep 2018 16:31:20 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8CEVKBQ022276 for ; Wed, 12 Sep 2018 16:31:20 +0200 References: <009b4336-616b-d190-8cde-61a49c1beddf@gmail.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <009b4336-616b-d190-8cde-61a49c1beddf@gmail.com> Message-ID: <66c3f37e-06c4-f41b-f1b2-f6f9856106bf@gmail.com> Date: Wed, 12 Sep 2018 16:31:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <009b4336-616b-d190-8cde-61a49c1beddf@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: [ipwave] Fwd: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 14:31:25 -0000 I am very happy that vehicle networks were cited in this draft about Limited Domains. -------- Message transfr -------- Sujet: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt Date: Wed, 12 Sep 2018 15:30:30 +1200 De: Brian E Carpenter Pour: int-area@ietf.org New version, with a first draft of a taxonomy added. Discussion welcome. Brian + Bing -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-limited-domains-03.txt Date: Tue, 11 Sep 2018 20:18:56 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Limited Domains and Internet Protocols Authors : Brian Carpenter Bing Liu Filename : draft-carpenter-limited-domains-03.txt Pages : 19 Date : 2018-09-11 Abstract: There is a noticeable trend towards network requirements, behaviours and semantics that are specific to a limited region of the Internet and a particular set of requirements. Policies, default parameters, the options supported, the style of network management and security requirements may vary. This document reviews examples of such limited domains and emerging solutions, and develops a related taxonomy. It shows the needs for a precise definition of a limited domain boundary and for a corresponding protocol to allow nodes to discover where such a boundary exists. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-limited-domains-03 https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-03 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Sep 14 06:18:33 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DB5130E35; Fri, 14 Sep 2018 06:18:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: its@ietf.org Message-ID: <153693110126.17576.8175333664304175777@ietfa.amsl.com> Date: Fri, 14 Sep 2018 06:18:21 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-27.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 13:18:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu Nabil Benamar Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-27.txt Pages : 38 Date : 2018-09-14 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-27 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-27 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 Sep 14 06:19:30 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8CE12F295; Fri, 14 Sep 2018 06:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 UfA3i5ylGCMJ; Fri, 14 Sep 2018 06:19:12 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 227F4130EDB; Fri, 14 Sep 2018 06:19:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8EDJ1fU098713; Fri, 14 Sep 2018 15:19:01 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B7AB7205B0B; Fri, 14 Sep 2018 15:19:01 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A77E5205A7D; Fri, 14 Sep 2018 15:19:01 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8EDJ0gW012581; Fri, 14 Sep 2018 15:19:01 +0200 To: Amelia Andersdotter , Hrpc , its@ietf.org References: <32d8c171-2586-e2db-7cc6-26c3385b6946@article19.org> From: Alexandre Petrescu Message-ID: <882e4a44-4842-8d14-50ed-425141f98ba4@gmail.com> Date: Fri, 14 Sep 2018 15:19:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <32d8c171-2586-e2db-7cc6-26c3385b6946@article19.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] RFC8280 Human Rights Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 13:19:29 -0000 Dear Amelia, Thank you for the Human Rights Review of the IPv6-over-OCB draft version 25. In this email I address 'part 1' of the comments. Alex Le 07/09/2018 à 22:49, Amelia Andersdotter a écrit : > Dear all, > > As part of efforts in the Human Rights Protocol Considerations (HRPC) > group, I have reviewed the human rights considerations (RFC 8280) in > IPv6-over-OCB v25. > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/25/ > > I've briefly reviewed v26 of the document, and find that the general > recommendations and observations below still hold in general. The review > is ended with an ERRATA (editorial remarks). > > The below text has been sent to the author of the document on September > 4, and some comments were received today (September 7). In this > submission, I'm hoping to open up for input from the larger community. > > best regards, > > Amelia > > # Summary > =============================== > > I understand that Sections 6.2.1 (Connectivity), 6.2.3 (Content > agnosticism), 6.2.6 (Censorship Resistenace), 6.2.8 (Heterogeneity > support) and 6.2.18 (Adaptability) of RFC8280 are taken into account by > the draft. References in the draft on less accessible standards in > accordance with Section 6.2.7 (Open Standards) in RFC8280 follows a > previously submitted evaluation. > > I suggest expansions on topics related to Sections 6.2.2 (Privacy), > 6.2.4 (Security), 6.2.9 (Anonymity), 6.2.10 (Pseudonymity), 6.2.14 > (Reliability), 6.2.16 (Integrity) and 6.2.17 (Authenticity) in RFC8280. > > I do not identify any concerns raised by Sections 6.2.5 > (Internationalization), 6.2.11 (Accessibility), 6.2.12 (Localization) > and 6.2.19 (Outcome transparency) in RFC8280. > > # Topical human rights review > ==================== > > ## Part 1: Privacy, reliability, integrity and authenticity > =================================== > This part reviews IPv6-over-80211-OCB draft with respect to Sections > 6.2.2 (Privacy), 6.2.4 (Security), 6.2.9 (Anonymity), 6.2.10 > (Pseudonymity), 6.2.14 (Reliability), 6.2.16 (Integrity) and 6.2.17 > (Authenticity) in RFC8280. > > Privacy and security issues are raised in various places of the > documents, for instance in Section 1, Section 4.5, Section 5 and > Appendix C, D and F. HoIver, while they are raised, no specific > recommendations to mitigate concerns are made. It is only mentioned that > other documents and standards do propose risk mitigation strategies. I agree with the comment. To that end, I created a new "Privacy Considerations" subsection of the "Security Considerations" section, trying to gather most of the privacy discussion. The privacy considerations are raised in section "Privacy Considerations". The methods to address these privacy considerations (what you rightfully name 'risk mitigation strategies') are described in subsection "MAC Address Generation" and in section "SLAAC". If necessary, I can explain why both subsections are needed, and situated at two distinct places. > The considerations raised in Appendix F.3 regarding the reliability and > integrity of the transmission schemes seem like they could have a big > impact on what functionalities must be included in this draft. If the > IPv6 transmission itself needs to guarantee specified senders and > receivers, this would require different privacy trade-offs in the rest > of the document. I think the requirements in F.2 are necessary. They are necessary for future mechanisms of improving the basic works of IPv6-over-OCB. Ex.: this draft describes how IPv6 works basically over OCB. But future drafts would describe how a common channel is selected between two parties, among 6 possible, thanks to this req in F.3 to "converge to a common channel". That is why F.2 is there. That said, I take into account your remark that what these requirements require is not present in this draft, and I take into account an earlier comment that suggests the same; thus I will remove appendix F.2. The same reasoning applyes to appendifx F.3 "Multiple Interfaces" - I will remove F.3. [ll discussion, pseudonym topic and unique identifiability question - to be addressed] > > ## Part 2: Internationalization, accessibility and transparency > ======================================= > > The functions described in this draft do not appear to be impacted by > Sections 6.2.5 (Internationalization), 6.2.11 (Accessibility) or 6.2.12 > (Localization) in RFC8280. Similarly, the applicability of Section > 6.2.19 (Outcome transparency) in RFC8280 seems largely related to issues > relating to authenticity, reliability and integrity. > > # Recommendations: I will treat these recommendations soon. > ============== > > 1. Collect all references to privacy and security in one place. If > privacy and security is in Section 4.5, 5 and Appendix F (as specified > in Section 4.5), this should be noted in Section 1. Also, privacy and > security issues are only mentioned in this document: recommendations for > their resolution are not present. This should be reflected in the Section 1. > > 2. In Section 4, add a section named "Pseudonym handling" at the very > top, describing the issues raised in the final paragraph of Section 5. > Remove the last paragraph of Section 5. > > 3.  The potential privacy benefits of link-local addresses could be > raised, especially since OCB transmissions are not secure against > curious nodes. On the other hand, RFC5889 Section 6.1 states that > link-local addressing is discouraged for ad hoc IPv6 networks. These > trade-offs could be expanded upon. > > 4. In Section 4.3 and 4.5 it should be clarified what privacy benefits, > if any, are expected from using semantically obscure IIDs as proposed in > RFC7217. It will at least be relevant to clarify whether privacy > benefits could arise in contexts that are explicitly out of scope (such > as during forming, termination or handover), e.g. with respect to > parameter selection as specified in Appendix A of RFC7217. > > # References: > ========= > > [RFC8280] Research into Human Rights Protocol Considerations > https://tools.ietf.org/html/rfc8280 > > ==# ERRATA: > ========= > > Neither the term IP-RSU nor the term IP-OBU defined in Section 2 are > actually used in the document. The term IP-RSU and the term IP-OBU are used in -25, ex. "The link model is the following: STA --- 802.11-OCB --- STA. In vehicular networks, STAs can be IP-RSUs and/or IP-OBUs." > In Section 2, definitions, the definition of IP-RSU can be made more > succinct by removing the second sentence (that is, remove "An IP-RSU has > at least two distinct IP-enabled interfaces; at least one interface is > operated in mode OCB of IEEE 802.11 and is IP-enabled."). I do not understand why removing that sentence? HAving two IP-enabled interfaces qualifies it as a router. It is important we say the IP-RSU is a router because: many deployed RSUs (not IP-RSU) are routers yet do not forward IP packets to the OCB interface; so, an IP-RSU would forward IP packets to the OCB interface if that IP-RSU is a router. It is circular, but it is positive, in the right direction: it allows to correct people who call an RSU a 'router' and suggest them to call it a 'router' _only_ if it forwards on the OCB interface too. That said, I agree the definition could be made more succinct. TO that end, here is one part that is redundant: "at least one interface is operated in mode OCB of IEEE 802.11" and "the wireless PHY/MAC layer of at least one of its IP-enabled interfaces is configured to operate in 802.11-OCB mode". For this reason, I will remove "at least one interface is operated in mode OCB of IEEE 802.11", and so the definition will be a little more succinct. > Section 4.5 only needs to recommend following the procedures in RFC8064 > once. I agree. In next rev we only refer once to RFC8064 in section 4.5. > In Appendix C, p. 26, 2nd to last paragraph, it is mentioned that MAC > re-addressing is described in IEEE-1609.4 Section 6.7. HoIver, in my > copy of IEEE-1609.4 this feature is described in Section 6.6. Ah! For confirmation - is your 1609.4 document the IEEE 1609.4-2016? (i.e. the document of year 2016). But looks as these versions change often. Maybe I want to remove the phrase "a relevant function is described in [1609...] ..." Alex From nobody Fri Sep 14 06:22:12 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E759130E3A for ; Fri, 14 Sep 2018 06:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 XbaP-SjAgZk5 for ; Fri, 14 Sep 2018 06:22:07 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 2883A130E39 for ; Fri, 14 Sep 2018 06:22:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8EDM570028989 for ; Fri, 14 Sep 2018 15:22:05 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6C7AD205A0F for ; Fri, 14 Sep 2018 15:22:05 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6143B203195 for ; Fri, 14 Sep 2018 15:22:05 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8EDM5ZR014312 for ; Fri, 14 Sep 2018 15:22:05 +0200 References: <153693110184.17576.17244066939775641357.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <153693110184.17576.17244066939775641357.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 14 Sep 2018 15:22:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153693110184.17576.17244066939775641357.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------7546F06F15E4207306DC85B0" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-27.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 13:22:10 -0000 This is a multi-part message in MIME format. --------------7546F06F15E4207306DC85B0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, I addressed some comments from the Human Rights review (part 1). Changelog: Removed appendices F.2 and F.3. Shortened definition of IP-RSU. Removed reference to 1609.4. A few other small changes, see the Diff: pointed to below. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-27.txt Date : Fri, 14 Sep 2018 06:18:21 -0700 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-27.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 27 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2018-09-14 Group: ipwave Pages: 38 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-27.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-27 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-27 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------7546F06F15E4207306DC85B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

I addressed some comments from the Human Rights review (part 1).

Changelog:

Removed appendices F.2 and F.3. 

Shortened definition of IP-RSU. 

Removed reference to 1609.4. 

A few other small changes, see the Diff: pointed to below.

Alex



-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-27.txt
Date : Fri, 14 Sep 2018 06:18:21 -0700
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr> 


A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-27.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	27
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2018-09-14
Group:		ipwave
Pages:		38
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-27.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-27
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-27

Abstract:
   In order to transmit IPv6 packets on IEEE 802.11 networks running
   outside the context of a basic service set (OCB, earlier "802.11p")
   there is a need to define a few parameters such as the supported
   Maximum Transmission Unit size on the 802.11-OCB link, the header
   format preceding the IPv6 header, the Type value within it, and
   others.  This document describes these parameters for IPv6 and IEEE
   802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
   similarly to other known 802.11 and Ethernet layers - by using an
   Ethernet Adaptation Layer.

                                                                                  


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

The IETF Secretariat
--------------7546F06F15E4207306DC85B0-- From nobody Wed Sep 19 03:16:05 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A872130EE1; Wed, 19 Sep 2018 03:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MODb0vzSIVmq; Wed, 19 Sep 2018 03:15:54 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 CAC97130ECF; Wed, 19 Sep 2018 03:15:53 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1g2ZWR-0003X0-42; Wed, 19 Sep 2018 12:15:51 +0200 To: Alexandre Petrescu , Hrpc , its@ietf.org References: <32d8c171-2586-e2db-7cc6-26c3385b6946@article19.org> <882e4a44-4842-8d14-50ed-425141f98ba4@gmail.com> From: Amelia Andersdotter Openpgp: preference=signencrypt Autocrypt: addr=amelia@article19.org; prefer-encrypt=mutual; keydata= xsFNBFjWlnsBEAC+jUN+LJE+mmxEL8lHSrvg47xSBMb9GdtH1Jr8tRSxXiO6R5E+FydsfqkL sjO0dI3x/VnNBi/kgPFFWiAzDEwGTiR/C9b/Muo+xrY+it6e49N56LTPGezrY2dy5yo6VcLl 7UwGz3fIWiNIj7dvuoPMBoO1uacF073E+dqDM5CmNh6o+OrHW8zhUlC9hKgXCq+8XpZJw90H un1zsHF0sRDiurjfYaCcbdAGK9+th9378ed1ZvLVo5uBVQXdydl3eJkNCOELq7VOS7oxSliA uX5/nj9A4LjeeYXgNbwGfKrMjlffP0FcAcgfzg9seqDd1DEk9EVaUMTr32fbWOQHjinXSC7r Lw4xaNfoBebIe1M6z16Xg7+bXXCTdmJYcL9ugmkvT6tGnR12Pfoca1oBwXPvA0VIRi86kCSU D9qvZ3Vl07MKD2hsvFkGZJOQfEaYv5QLpCWv6RCjfDNC05IyMeSW4H18Fr/BoHX8FXHV3+9H LsbJQ/Zrofd/Cm+TKEmXLAtYc7iXvzV+mw3/u0VYqjEy/CRYa62Ah0NNNVIuswfRVIfx3UZo jX4y8j2Kh0jtUV5A4GGf8H3SzQ/cB0I7wTRHU9mCPVCtH6M26nPumL4Zr4D6uGnAmPf9xnlX lokOn2Qxf/mBldsL41PDbEpYhZvvn5kJ/Z9Qh7Fks/hfTbbJowARAQABzSxBbWVsaWEgQW5k ZXJzZG90dGVyIDxhbWVsaWFAYW5kZXJzZG90dGVyLmNjPsLBlwQTAQgAQQIbIwUJCWYBgAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYhBD1dtsq4UrmIBVpqb/7xwpS06AtVBQJY1pdiAhkB AAoJEP7xwpS06AtVI0sP/Al6eUycymdT1R7v0uEQv4coonnOUV6FKj/4wc+wM+A0h7vlqADr j4nS7RRSQRUo8xJ9tvR9J1Eyske5bvakOYv64f9PrNY1Z6ABhJzK34kJxekEfeLmpXAB4wst GhD8dGC/z/b9Oau0AW1GWIP0eNWq4acDf9Qf+j0wqQi25OZUXnu5KeUX7mvPTHKZLyEZlwHV atXmZHWKnQWtEPZTQfv/zESsoBAm1TbaLapgxVG9uLW+I9kj72TB/AZ5hMSKMYWZ2dC+8eEs Xd22tn6907aUmZhFT89jbEyS996WeZ+SQ5G1Okrq02qYXcCi5vm3AuvLlbRYHguh42TLaVq1 er7PiYOYH77FFmnZWW6ChFnf7xsDep2tpNxn+QUZLgO3+5kL7TfO7D2H57kjVVMdkNn+01nz kfcn76K7nuU6Dc4pItPzbDndhdxulnm9cicOEfGQqvta9ffxk4YWyAu9PUNARVRNf6OnoDQQ Zo8l1o37q9PFXJyQwzvxdd9u6uzTny2wp9eig75pD3dYHCRIQeYmkv1kB81mc86cwgvuw1Qy /QwiCBNXSSuIvLO78b+/dB0DLVQC/c6gtyWXRpC4ysF4EaEZophjT60d12YRanR+fWuH+qu2 wsT+z1d4tC5/6UJMPr3bxREh9JHThm5Y3cDBmcn0PGqtDKkwjCkqex5bzsFNBFjWlnsBEADF jusaTo9W8VeWluCK/oJqyyyF1wMvou0ldfuoOpUZrOqsY67TM7yBqsv5COPVgAV+xp+axor5 oHWxibd283w0Ok4dK6tvtNGwUqyDRlHtQ92DG/u4Tg5eOwrHNUn73/rfeBD9KhKAXcNKKPoc cLgR8oQTXpO7eRo+0NI52pXQ6LdZ0wddYeTcHglsNKN1TK+CyYS7xfGolsZXXoBOKcyhfj/c kPFVIHWpGpEtcYWTZWvXgLprzHvpKzkzNyBwejaXE+bqCT2dRl3omI/e2t3Vq33hFUUSAdxr FF29vMX/YsSnYqsFOIoayna+TRsDFAfZvbvHBOMckeJzvA8yBdadw7CM08Uw8wqH7n9BA3oq //QpZJekPfrc2E9nM9H0d51T0uStLMbYDWdwxvfPA3p9z8L91vobt8bM/Jbhl9h+X2Yq9oBC iTI7b2izYd9FVG4BwBIdeh3bh9R9HExgRjF3XQ6uafT3pcVOPASdv9FRUYH1Va7QWQifoha0 B7UXKx1OpX1Z6XR2NQ9KN2MvlwvBKdHtm6tBzUIFzW6D8vUOxiYKBA4fppJt/LJF4jsaCEyI /CVQnkC0yL5DKFOdigxTipwEL9Uc6r7VfR5OAGFd6vzuJFy+j+/WhzaVT1oVYp6eQXh0bBtq qH2Mq9sAMnIjvaNYIKiQKgMa1Pa3OWQbQQARAQABwsF8BBgBCAAmFiEEPV22yrhSuYgFWmpv /vHClLToC1UFAljWlnsCGwwFCQlmAYAACgkQ/vHClLToC1XnRw//W4lzE8FddceKXGRwO/T1 u4uzH9EjPCj+3/eHCrLI+h1m7QPyH1DrFAtZBoA6UoaF0+vIAJXM9/HI1FZ09EUdJr5X/+YR EErFom4DbE1FK8fpK1/Hw2zI+7Xa8bVkmYrKhMGhi1Gq6Dtksn/H4USdJL53ZPt10SVNK7H3 w93Yp1GC4+0zWjfrsKfsHYZZr2SZyb5/gZlngfgaqiQLhIcPYmiU1GQi9QWkGxWRxk0YQXBw hekewvgltATxlRSCwguAi4uck9fAct9GGdpsshSOgAb9YIAnEV3EqaGnf0PknXp3vNHAZWrf M+RyuNdm2L5TjDU0rIrvyqGP3pR33cREGOAil5Sz2uFArmwsPt8VffbEXlf7qZqRBKaYeKt0 qnxKMx1+e1JilVsfb8qtnAWAFDyR0HMlVj/dvGAmq/auPSOAUWRSnDRyT6rv/vXxrbkL4uxW ax46qdpDhR15mS5MTng6b5b3Uox7xlveo/Sx71AdNf4goPvB/ntv0DiMuh+fmLGk3zrxs4Xd 30Sx+qQwVaXR5xc5rgnF81wvfmuAOb2eP9mpD6DoabkpxC8fLk17AK7Q1ZTgcZ+8XLRFnavd PrwCa9RU0BF53lJMSTPzyBcMwZ4sqA6Z5IRFVt7rEbSeeD8REiawo+FvVt9j0fKdNEBeaJ3W Y5hlhNPcUXr4q1U= Organization: ARTICLE19 Message-ID: Date: Wed, 19 Sep 2018 12:15:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <882e4a44-4842-8d14-50ed-425141f98ba4@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US-large X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: c79f821e14dbe0332c6ab890ccc0387d Archived-At: Subject: Re: [ipwave] RFC8280 Human Rights Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 10:15:57 -0000 Dear Alexander, On 2018-09-14 15:19, Alexandre Petrescu wrote: > Dear Amelia, > > Thank you for the Human Rights Review of the IPv6-over-OCB draft > version 25. > > In this email I address 'part 1' of the comments. > Thank you, and I'm sorry for this delayed response. See responses in line= : > I agree with the comment. > > To that end, I created a new "Privacy Considerations" subsection of > the "Security Considerations" section, trying to gather most of the > privacy discussion. > > The privacy considerations are raised in section "Privacy > Considerations". > > The methods to address these privacy considerations (what you > rightfully name 'risk mitigation strategies') are described in > subsection "MAC Address Generation" and in section "SLAAC". > > If necessary, I can explain why both subsections are needed, and > situated at two distinct places. > It looks easier to follow now, to me. Thanks! >> The considerations raised in Appendix F.3 regarding the reliability an= d >> integrity of the transmission schemes seem like they could have a big >> impact on what functionalities must be included in this draft. If the >> IPv6 transmission itself needs to guarantee specified senders and >> receivers, this would require different privacy trade-offs in the rest= >> of the document. > > I think the requirements in F.2 are necessary.=C2=A0 They are necessary= for > future mechanisms of improving the basic works of IPv6-over-OCB.=C2=A0 = Ex.: > this draft describes how IPv6 works basically over OCB.=C2=A0 But futur= e > drafts would describe how a common channel is selected between two > parties, among 6 possible, thanks to this req in F.3 to "converge to a > common channel".=C2=A0 That is why F.2 is there. > > That said, I take into account your remark that what these > requirements require is not present in this draft, and I take into > account an earlier comment that suggests the same; thus I will remove > appendix F.2. > > The same reasoning applyes to appendifx F.3 "Multiple Interfaces" - I > will remove F.3. > > [ll discussion, pseudonym topic and unique identifiability question - > to be addressed] > OK! >> >> =3D=3D# ERRATA: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Neither the term IP-RSU nor the term IP-OBU defined in Section 2 are >> actually used in the document. > > The term IP-RSU and the term IP-OBU are used in -25, ex. "The link > model is the following: STA --- 802.11-OCB --- STA.=C2=A0 In vehicular > networks, STAs can be IP-RSUs and/or IP-OBUs." > Hm. They come up when I search for them now, but didn't before. Sorry for the confusion. >> In Section 2, definitions, the definition of IP-RSU can be made more >> succinct by removing the second sentence (that is, remove "An IP-RSU h= as >> at least two distinct IP-enabled interfaces; at least one interface is= >> operated in mode OCB of IEEE 802.11 and is IP-enabled."). > > I do not understand why removing that sentence?=C2=A0 HAving two IP-ena= bled > interfaces qualifies it as a router.=C2=A0 It is important we say the > IP-RSU is a router because: many deployed RSUs (not IP-RSU) are > routers yet do not forward IP packets to the OCB interface; so, an > IP-RSU would forward IP packets to the OCB interface if that IP-RSU is > a router.=C2=A0 It is circular, but it is positive, in the right direct= ion: > it allows to correct people who call an RSU a 'router' and suggest > them to call it a 'router' _only_ if it forwards on the OCB interface > too. > An IP-RSU is already defined as being "similar to an Access Network Router" which is defined in RFC3753 as "An IP router in the Access Network." So I thought perhaps that already covered its qualification as router. Also, maybe the "similar to an Access Point as defined in IEEE documents" should go, since OCB networks specifically do not have Access Points. My new suggestion would be: "An IP-RSU is situated along the road. It has at least two distinct IP-enabled interfaces and the wireless PHY/MAC layer of at least one of its IP-enabled interfaces is configured to operate in 802.11-OCB mode. An IP-RSU communicates with the IP-OBU in the vehicle over 802.11 wireless link operating in OCB mode. It is similar to a Wireless Termination Point (WTP), as defined in [RFC5415] or an Access Network Router (ANR) defined in [RFC3753]." It preserves the technical requirements listed first, and puts analogies with other similar terms last. > >> In Appendix C, p. 26, 2nd to last paragraph, it is mentioned that MAC >> re-addressing is described in IEEE-1609.4 Section 6.7. HoIver, in my >> copy of IEEE-1609.4 this feature is described in Section 6.6. > > Ah!=C2=A0 For confirmation - is your 1609.4 document the IEEE 1609.4-20= 16? > (i.e. the document of year 2016). > > But looks as these versions change often.=C2=A0 Maybe I want to remove = the > phrase "a relevant function is described in [1609...] ..." It is this one: 1609.4-2016 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Multi-Channel Operation, Revision of IEEE Std 1609.4-2010 (Revision of IEEE Std 1609.4-2006) cited as DOI: 10.1109/IEEESTD.2016.7435228. I assumed it was just a typo? best regards, Amelia > > Alex --=20 Amelia Andersdotter Technical Consultant, Digital Programme ARTICLE19 www.article19.org PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55 From nobody Wed Sep 19 05:28:01 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB27130F40; Wed, 19 Sep 2018 05:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 o8c-0qnFJNk0; Wed, 19 Sep 2018 05:27:50 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 30B74130DE3; Wed, 19 Sep 2018 05:27:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8JCRjn0079325; Wed, 19 Sep 2018 14:27:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A4FA5204BC8; Wed, 19 Sep 2018 14:27:45 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 95196201B16; Wed, 19 Sep 2018 14:27:45 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8JCRjUA022841; Wed, 19 Sep 2018 14:27:45 +0200 To: Amelia Andersdotter , Hrpc , its@ietf.org References: <32d8c171-2586-e2db-7cc6-26c3385b6946@article19.org> <882e4a44-4842-8d14-50ed-425141f98ba4@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 19 Sep 2018 14:27:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] RFC8280 Human Rights Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 12:27:52 -0000 Le 19/09/2018 à 12:15, Amelia Andersdotter a écrit : [...] > My new suggestion would be: "An IP-RSU is situated along the road. It > has at least two distinct IP-enabled interfaces and the wireless PHY/MAC > layer of at least one of its IP-enabled interfaces is configured to > operate in 802.11-OCB mode. An IP-RSU communicates with the IP-OBU in > the vehicle over 802.11 wireless link operating in OCB mode. It is > similar to a Wireless Termination Point (WTP), as defined in [RFC5415] > or an Access Network Router (ANR) defined in [RFC3753]." > > It preserves the technical requirements listed first, and puts analogies > with other similar terms last. Sounds good, I modified it accordingly. >>> In Appendix C, p. 26, 2nd to last paragraph, it is mentioned that MAC >>> re-addressing is described in IEEE-1609.4 Section 6.7. HoIver, in my >>> copy of IEEE-1609.4 this feature is described in Section 6.6. >> >> Ah!  For confirmation - is your 1609.4 document the IEEE 1609.4-2016? >> (i.e. the document of year 2016). >> >> But looks as these versions change often.  Maybe I want to remove the >> phrase "a relevant function is described in [1609...] ..." > > It is this one: 1609.4-2016 - IEEE Standard for Wireless Access in > Vehicular Environments (WAVE) -- Multi-Channel Operation, Revision of > IEEE Std 1609.4-2010 (Revision of IEEE Std 1609.4-2006) cited as DOI: > 10.1109/IEEESTD.2016.7435228. > > I assumed it was just a typo? I am not sure it was a typo. There was some discussion about this number of the section in the IEEE document. Some people argued about it, based on what appeared to me to be intermediary working IEEE documents, not fully released to the public. This is moving ground. So I removed that reference. Alex > > best regards, > > Amelia > > >> >> Alex > > From nobody Wed Sep 19 05:35:14 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A279D130FE8; Wed, 19 Sep 2018 05:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT1OQ_No7KmM; Wed, 19 Sep 2018 05:35:02 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 B31F3131054; Wed, 19 Sep 2018 05:34:58 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1g2bh2-00073I-Rz; Wed, 19 Sep 2018 14:34:57 +0200 To: Alexandre Petrescu , Hrpc , its@ietf.org References: <32d8c171-2586-e2db-7cc6-26c3385b6946@article19.org> <882e4a44-4842-8d14-50ed-425141f98ba4@gmail.com> From: Amelia Andersdotter Openpgp: preference=signencrypt Autocrypt: addr=amelia@article19.org; prefer-encrypt=mutual; keydata= xsFNBFjWlnsBEAC+jUN+LJE+mmxEL8lHSrvg47xSBMb9GdtH1Jr8tRSxXiO6R5E+FydsfqkL sjO0dI3x/VnNBi/kgPFFWiAzDEwGTiR/C9b/Muo+xrY+it6e49N56LTPGezrY2dy5yo6VcLl 7UwGz3fIWiNIj7dvuoPMBoO1uacF073E+dqDM5CmNh6o+OrHW8zhUlC9hKgXCq+8XpZJw90H un1zsHF0sRDiurjfYaCcbdAGK9+th9378ed1ZvLVo5uBVQXdydl3eJkNCOELq7VOS7oxSliA uX5/nj9A4LjeeYXgNbwGfKrMjlffP0FcAcgfzg9seqDd1DEk9EVaUMTr32fbWOQHjinXSC7r Lw4xaNfoBebIe1M6z16Xg7+bXXCTdmJYcL9ugmkvT6tGnR12Pfoca1oBwXPvA0VIRi86kCSU D9qvZ3Vl07MKD2hsvFkGZJOQfEaYv5QLpCWv6RCjfDNC05IyMeSW4H18Fr/BoHX8FXHV3+9H LsbJQ/Zrofd/Cm+TKEmXLAtYc7iXvzV+mw3/u0VYqjEy/CRYa62Ah0NNNVIuswfRVIfx3UZo jX4y8j2Kh0jtUV5A4GGf8H3SzQ/cB0I7wTRHU9mCPVCtH6M26nPumL4Zr4D6uGnAmPf9xnlX lokOn2Qxf/mBldsL41PDbEpYhZvvn5kJ/Z9Qh7Fks/hfTbbJowARAQABzSxBbWVsaWEgQW5k ZXJzZG90dGVyIDxhbWVsaWFAYW5kZXJzZG90dGVyLmNjPsLBlwQTAQgAQQIbIwUJCWYBgAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYhBD1dtsq4UrmIBVpqb/7xwpS06AtVBQJY1pdiAhkB AAoJEP7xwpS06AtVI0sP/Al6eUycymdT1R7v0uEQv4coonnOUV6FKj/4wc+wM+A0h7vlqADr j4nS7RRSQRUo8xJ9tvR9J1Eyske5bvakOYv64f9PrNY1Z6ABhJzK34kJxekEfeLmpXAB4wst GhD8dGC/z/b9Oau0AW1GWIP0eNWq4acDf9Qf+j0wqQi25OZUXnu5KeUX7mvPTHKZLyEZlwHV atXmZHWKnQWtEPZTQfv/zESsoBAm1TbaLapgxVG9uLW+I9kj72TB/AZ5hMSKMYWZ2dC+8eEs Xd22tn6907aUmZhFT89jbEyS996WeZ+SQ5G1Okrq02qYXcCi5vm3AuvLlbRYHguh42TLaVq1 er7PiYOYH77FFmnZWW6ChFnf7xsDep2tpNxn+QUZLgO3+5kL7TfO7D2H57kjVVMdkNn+01nz kfcn76K7nuU6Dc4pItPzbDndhdxulnm9cicOEfGQqvta9ffxk4YWyAu9PUNARVRNf6OnoDQQ Zo8l1o37q9PFXJyQwzvxdd9u6uzTny2wp9eig75pD3dYHCRIQeYmkv1kB81mc86cwgvuw1Qy /QwiCBNXSSuIvLO78b+/dB0DLVQC/c6gtyWXRpC4ysF4EaEZophjT60d12YRanR+fWuH+qu2 wsT+z1d4tC5/6UJMPr3bxREh9JHThm5Y3cDBmcn0PGqtDKkwjCkqex5bzsFNBFjWlnsBEADF jusaTo9W8VeWluCK/oJqyyyF1wMvou0ldfuoOpUZrOqsY67TM7yBqsv5COPVgAV+xp+axor5 oHWxibd283w0Ok4dK6tvtNGwUqyDRlHtQ92DG/u4Tg5eOwrHNUn73/rfeBD9KhKAXcNKKPoc cLgR8oQTXpO7eRo+0NI52pXQ6LdZ0wddYeTcHglsNKN1TK+CyYS7xfGolsZXXoBOKcyhfj/c kPFVIHWpGpEtcYWTZWvXgLprzHvpKzkzNyBwejaXE+bqCT2dRl3omI/e2t3Vq33hFUUSAdxr FF29vMX/YsSnYqsFOIoayna+TRsDFAfZvbvHBOMckeJzvA8yBdadw7CM08Uw8wqH7n9BA3oq //QpZJekPfrc2E9nM9H0d51T0uStLMbYDWdwxvfPA3p9z8L91vobt8bM/Jbhl9h+X2Yq9oBC iTI7b2izYd9FVG4BwBIdeh3bh9R9HExgRjF3XQ6uafT3pcVOPASdv9FRUYH1Va7QWQifoha0 B7UXKx1OpX1Z6XR2NQ9KN2MvlwvBKdHtm6tBzUIFzW6D8vUOxiYKBA4fppJt/LJF4jsaCEyI /CVQnkC0yL5DKFOdigxTipwEL9Uc6r7VfR5OAGFd6vzuJFy+j+/WhzaVT1oVYp6eQXh0bBtq qH2Mq9sAMnIjvaNYIKiQKgMa1Pa3OWQbQQARAQABwsF8BBgBCAAmFiEEPV22yrhSuYgFWmpv /vHClLToC1UFAljWlnsCGwwFCQlmAYAACgkQ/vHClLToC1XnRw//W4lzE8FddceKXGRwO/T1 u4uzH9EjPCj+3/eHCrLI+h1m7QPyH1DrFAtZBoA6UoaF0+vIAJXM9/HI1FZ09EUdJr5X/+YR EErFom4DbE1FK8fpK1/Hw2zI+7Xa8bVkmYrKhMGhi1Gq6Dtksn/H4USdJL53ZPt10SVNK7H3 w93Yp1GC4+0zWjfrsKfsHYZZr2SZyb5/gZlngfgaqiQLhIcPYmiU1GQi9QWkGxWRxk0YQXBw hekewvgltATxlRSCwguAi4uck9fAct9GGdpsshSOgAb9YIAnEV3EqaGnf0PknXp3vNHAZWrf M+RyuNdm2L5TjDU0rIrvyqGP3pR33cREGOAil5Sz2uFArmwsPt8VffbEXlf7qZqRBKaYeKt0 qnxKMx1+e1JilVsfb8qtnAWAFDyR0HMlVj/dvGAmq/auPSOAUWRSnDRyT6rv/vXxrbkL4uxW ax46qdpDhR15mS5MTng6b5b3Uox7xlveo/Sx71AdNf4goPvB/ntv0DiMuh+fmLGk3zrxs4Xd 30Sx+qQwVaXR5xc5rgnF81wvfmuAOb2eP9mpD6DoabkpxC8fLk17AK7Q1ZTgcZ+8XLRFnavd PrwCa9RU0BF53lJMSTPzyBcMwZ4sqA6Z5IRFVt7rEbSeeD8REiawo+FvVt9j0fKdNEBeaJ3W Y5hlhNPcUXr4q1U= Organization: ARTICLE19 Message-ID: <44af53c5-2f3e-5c5d-ede0-07bfd677374f@article19.org> Date: Wed, 19 Sep 2018 14:34:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: d58e29c6f4e42f76447094ef3ccb23d2 Archived-At: Subject: Re: [ipwave] RFC8280 Human Rights Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 12:35:12 -0000 On 2018-09-19 14:27, Alexandre Petrescu wrote: >>> Ah!=C2=A0 For confirmation - is your 1609.4 document the IEEE 1609.4-= 2016? >>> (i.e. the document of year 2016). >>> >>> But looks as these versions change often.=C2=A0 Maybe I want to remov= e the >>> phrase "a relevant function is described in [1609...] ..." >> >> It is this one: 1609.4-2016 - IEEE Standard for Wireless Access in >> Vehicular Environments (WAVE) -- Multi-Channel Operation, Revision of >> IEEE Std 1609.4-2010 (Revision of IEEE Std 1609.4-2006) cited as DOI: >> 10.1109/IEEESTD.2016.7435228. >> >> I assumed it was just a typo? > > I am not sure it was a typo. > > There was some discussion about this number of the section in the IEEE > document.=C2=A0 Some people argued about it, based on what appeared to = me > to be intermediary working IEEE documents, not fully released to the > public.=C2=A0 This is moving ground. > > So I removed that reference. > You could have also put Clause 6 without subclause classifier, because it's unlikely to change main clause (I guess)? (although it was added only in 2010, so it's not in the 1609.4-2006 standard, for instance) Otherwise it might be difficult to find for individuals reading the text. Esp. if the entire reference is removed. There is some terminology problem there as well, which I pointed out in the Problem Statement review: the pseudonymization is known alternately as "re-addressing", "pseudonymisation" or "randomization". But well, every document can't solve every issue, that's how it is. best regards, Amelia > Alex > > >> >> best regards, >> >> Amelia >> >> >>> >>> Alex >> >> --=20 Amelia Andersdotter Technical Consultant, Digital Programme ARTICLE19 www.article19.org PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55 From nobody Wed Sep 19 06:20:40 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8861A130FDF; Wed, 19 Sep 2018 06:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 9KFoU5OR4OSD; Wed, 19 Sep 2018 06:20:30 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 72E0D130DBE; Wed, 19 Sep 2018 06:20:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8JDKRao101750; Wed, 19 Sep 2018 15:20:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6027A2036F6; Wed, 19 Sep 2018 15:20:27 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4FDB4201D0D; Wed, 19 Sep 2018 15:20:27 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8JDKRlW025511; Wed, 19 Sep 2018 15:20:27 +0200 To: Amelia Andersdotter , Hrpc , its@ietf.org References: <32d8c171-2586-e2db-7cc6-26c3385b6946@article19.org> <882e4a44-4842-8d14-50ed-425141f98ba4@gmail.com> <44af53c5-2f3e-5c5d-ede0-07bfd677374f@article19.org> From: Alexandre Petrescu Message-ID: <01335001-e49b-4fe2-8ba6-6d489bb13dc5@gmail.com> Date: Wed, 19 Sep 2018 15:20:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <44af53c5-2f3e-5c5d-ede0-07bfd677374f@article19.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] RFC8280 Human Rights Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 13:20:33 -0000 Le 19/09/2018 à 14:34, Amelia Andersdotter a écrit : > On 2018-09-19 14:27, Alexandre Petrescu wrote: >>>> Ah! For confirmation - is your 1609.4 document the IEEE >>>> 1609.4-2016? (i.e. the document of year 2016). >>>> >>>> But looks as these versions change often. Maybe I want to >>>> remove the phrase "a relevant function is described in >>>> [1609...] ..." >>> >>> It is this one: 1609.4-2016 - IEEE Standard for Wireless Access >>> in Vehicular Environments (WAVE) -- Multi-Channel Operation, >>> Revision of IEEE Std 1609.4-2010 (Revision of IEEE Std >>> 1609.4-2006) cited as DOI: 10.1109/IEEESTD.2016.7435228. >>> >>> I assumed it was just a typo? >> >> I am not sure it was a typo. >> >> There was some discussion about this number of the section in the >> IEEE document. Some people argued about it, based on what appeared >> to me to be intermediary working IEEE documents, not fully released >> to the public. This is moving ground. >> >> So I removed that reference. >> > You could have also put Clause 6 without subclause classifier, > because it's unlikely to change main clause (I guess)? (although it > was added only in 2010, so it's not in the 1609.4-2006 standard, for > instance) I agree with the guessing part. > Otherwise it might be difficult to find for individuals reading the > text. Esp. if the entire reference is removed. So you suggest to keep paragraph and remove clause, like this? OLD: > A relevant function is described in IEEE 1609.3-2016 [IEEE-1609.3], > clause 5.5.1 and IEEE 1609.4-2016 [IEEE-1609.4], clause 6.7. NEW: > A relevant function is described in IEEE 1609.3-2016 [IEEE-1609.3] > and IEEE 1609.4-2016 [IEEE-1609.4]. > There is some terminology problem there as well, which I pointed out > in the Problem Statement review: the pseudonymization is known > alternately as "re-addressing", "pseudonymisation" or > "randomization". But well, every document can't solve every issue, > that's how it is. One can hear some vehi net talk about pseudonimisation as the use of an equivalent identifier, like in calling someone the prince of persia instead of true name. Send packets to pseudonym 'car1' instead of MAC address '00:09:0F:AA:00:01'. Having agreement on the concept may need much work. I will look at the psedonimisation earlier remarks in this sense. Alex > > best regards, > > Amelia > > >> Alex >> >> >>> >>> best regards, >>> >>> Amelia >>> >>> >>>> >>>> Alex >>> >>> > From nobody Wed Sep 19 08:00:46 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42F9130E1B; Wed, 19 Sep 2018 08:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pgc8acNQEADO; Wed, 19 Sep 2018 08:00:37 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 A59641310C4; Wed, 19 Sep 2018 08:00:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8JF0S7d035563; Wed, 19 Sep 2018 17:00:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7757F204DBB; Wed, 19 Sep 2018 17:00:28 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 671D9204D7E; Wed, 19 Sep 2018 17:00:28 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8JF0STb027481; Wed, 19 Sep 2018 17:00:28 +0200 To: Amelia Andersdotter , Hrpc , its@ietf.org References: <32d8c171-2586-e2db-7cc6-26c3385b6946@article19.org> From: Alexandre Petrescu Message-ID: <51b3f5a1-62fd-1842-9b4b-ba56858a124b@gmail.com> Date: Wed, 19 Sep 2018 17:00:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <32d8c171-2586-e2db-7cc6-26c3385b6946@article19.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] RFC8280 Human Rights Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 15:00:45 -0000 part 2 of addressing the Human Rights reviewer comments. Le 07/09/2018 à 22:49, Amelia Andersdotter a écrit : [...] > > It was not immediately clear whether link-local addresses are > recommended for any particular purposes or use-cases. It is my > understanding that link-local addresses restrict the ability of an > interface to communicate with other interfaces than those with whom they > share a direct link, and that this may entail privacy benefits. But in > Section 4.6 there are conflicting references to RFC5889, where it's > specified that IPv6 link-local addressing should be avoided in ad hoc > networks. We clarified that by saying this in -28: > As recommended in , when the timing > requirements are very strict (e.g. fast drive through IP-RSU > coverage), no on-link subnet prefix should be configured on > an 802.11-OCB interface. In such cases, the exclusive use > of IPv6 link-local addresses is RECOMMENDED. > > Additionally, even if the timing requirements are not very > strict (e.g. the moving subnet formed by two following > vehicles is stable, a fixed IP-RSU is absent), the subnet is > disconnected from the Internet (a default route is absent), > and the addressing peers are equally qualified (impossible > to determine that some vehicle owns and distributes > addresses to others) the use of link-local addresses is > RECOMMENDED. > > Many considerations in the draft are impacted by the strong necessity to > use protection tools such as dynamic MAC re-addressing. This impacts the > ability to use IPv6 address generation as described in Section 4 of > RFC2464. But dynamic MAC re-addressing also would appear to justify the > recommendation to use stable IPv6 address generation as described in > RFC8064 or RFC7217. Currently, pseudonym handling is just briefly > mentioned at the end of Section 5 as a security issue but given its > impact on addressing and IPv6 address generation, I believe they merit > their own section. What is a pseudonym? It's easy to make a section for it. > > In Appendix F.1, it is not clear why a mechanism to uniquely identify a > vehicle is necessary. It should be clarified whether this is a technical > requirement (for instance, whether this constitutes a proposal to > introduce a unique identifier different from the Layer-2 MAC unique > identifier), or a legal requirement, and whether this new unique > identifier is intended for use in networking in general, or only for > specific circumstances. This I do not know. At ETSI it is usual to say that every emitter of CAM messages must have a unique Station ID. And, sure, every car must send CAMs. But from there to say that the whole car is identified just by the Station ID there is a long way. In the prototypes I work with there are very many identifiers. Each is relevant for the particular application. Then there is License Plate number, Vehicle Identification Number, insurance numbers, etc. Then there is the IMEI of the SIMs of the cellular interface(s). For IPv6-over-OCB - even here there is not only one MAC address, because there are multiple 802.11-OCB interfaces in one car. They are so cheap you can put as many as you want. I will remove Appendix F.1 "Vehicle ID". > ## Part 2: Internationalization, accessibility and transparency > ======================================= > > The functions described in this draft do not appear to be impacted by > Sections 6.2.5 (Internationalization), 6.2.11 (Accessibility) or 6.2.12 > (Localization) in RFC8280. Similarly, the applicability of Section > 6.2.19 (Outcome transparency) in RFC8280 seems largely related to issues > relating to authenticity, reliability and integrity. It is good. > > # Recommendations: > ============== > > 1. Collect all references to privacy and security in one place. If > privacy and security is in Section 4.5, 5 and Appendix F (as specified > in Section 4.5), this should be noted in Section 1. Also, privacy and > security issues are only mentioned in this document: recommendations for > their resolution are not present. This should be reflected in the Section 1. I collected all privacy and security in one place: the security considerations section. We do have now the MAC address change and the subsequent Interface ID change, in Security Considerations section, as a recommendation for resolution of some of the privacy issues left over after RFC8064 and RFC7217 are referred. For section 1: I added > The Security Considerations section describes security and > privacy aspects of 802.11-OCB. > 2. In Section 4, add a section named "Pseudonym handling" at the very > top, describing the issues raised in the final paragraph of Section 5. > Remove the last paragraph of Section 5. Earlier, I removed the last par of section 5. Rewrote it largely and put it in a new sub-section 'Privacy Considerations' within the 'Security Considerations' section. Now, I created a new section 'Pseudonym Handling' at the beginning of section 4. I do not know what to put inside. > 3.  The potential privacy benefits of link-local addresses could be > raised, especially since OCB transmissions are not secure against > curious nodes. On the other hand, RFC5889 Section 6.1 states that > link-local addressing is discouraged for ad hoc IPv6 networks. These > trade-offs could be expanded upon. Well. The use of link-local addresses are not a panacea to privacy worries. It could even be the reverse. But a new method to form link-local addresses offering more privacy than existing privacy methods is given in this draft that is not described anywhere else. As for RFC5889 forbidding LLs, I think I adressed that in other comment. I made clear in the draft which case the LLs are recommended, against RFC5889. This is in section 4.7 "Subnet Structure". > 4. In Section 4.3 and 4.5 it should be clarified what privacy benefits, > if any, are expected from using semantically obscure IIDs as proposed in > RFC7217. It will at least be relevant to clarify whether privacy > benefits could arise in contexts that are explicitly out of scope (such > as during forming, termination or handover), e.g. with respect to > parameter selection as specified in Appendix A of RFC7217. This requires some work to understand. It will be in part 3. > > # References: > ========= > > [RFC8280] Research into Human Rights Protocol Considerations > https://tools.ietf.org/html/rfc8280 Should this RFC be referenced in the Internet Draft and how? Alex From nobody Wed Sep 19 08:02:05 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3FA131072; Wed, 19 Sep 2018 08:01:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: its@ietf.org Message-ID: <153736931684.21416.5252778556937319277@ietfa.amsl.com> Date: Wed, 19 Sep 2018 08:01:56 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-28.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 15:02:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu Nabil Benamar Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-28.txt Pages : 39 Date : 2018-09-19 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-28 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-28 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 Sep 19 08:04:45 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBC1130E27 for ; Wed, 19 Sep 2018 08:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7GDDXZwNm26 for ; Wed, 19 Sep 2018 08:04:33 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 7B9B51271FF for ; Wed, 19 Sep 2018 08:04:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8JF4Vhh146370 for ; Wed, 19 Sep 2018 17:04:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 86699204DBD for ; Wed, 19 Sep 2018 17:04:31 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7AB64204D56 for ; Wed, 19 Sep 2018 17:04:31 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8JF4VAA030024 for ; Wed, 19 Sep 2018 17:04:31 +0200 References: <153736931712.21416.5554771021843725744.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <153736931712.21416.5554771021843725744.idtracker@ietfa.amsl.com> Message-ID: <5d8c7db0-9820-0c53-7a3a-9b194c15536f@gmail.com> Date: Wed, 19 Sep 2018 17:04:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153736931712.21416.5554771021843725744.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------0711169F7106B8523215ACB1" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-28.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 15:04:38 -0000 This is a multi-part message in MIME format. --------------0711169F7106B8523215ACB1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, This is the new version (28) of the IPv6-over-OCB draft. It addresses the part 2 of the reviewer's comments for Human Rights aspects. This is the changelog:         Created a new section 'Pseudonym Handling'.         removed the 'Vehicle ID' appendix.         improved the address generation from random MAC address.         shortened Term IP-RSU definition.         removed refs to two detail Clauses in IEEE documents, kept         just these latter. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-28.txt Date : Wed, 19 Sep 2018 08:01:57 -0700 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-28.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 28 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2018-09-19 Group: ipwave Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-28.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-28 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-28 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------0711169F7106B8523215ACB1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

This is the new version (28) of the IPv6-over-OCB draft.

It addresses the part 2 of the reviewer's comments for Human Rights aspects.

This is the changelog:

        Created a new section 'Pseudonym Handling'.

        removed the 'Vehicle ID' appendix.

        improved the address generation from random MAC address.

        shortened Term IP-RSU definition.

        removed refs to two detail Clauses in IEEE documents, kept
        just these latter.

Alex



-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-28.txt
Date : Wed, 19 Sep 2018 08:01:57 -0700
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr> 


A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-28.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	28
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2018-09-19
Group:		ipwave
Pages:		39
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-28.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-28
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-28

Abstract:
   In order to transmit IPv6 packets on IEEE 802.11 networks running
   outside the context of a basic service set (OCB, earlier "802.11p")
   there is a need to define a few parameters such as the supported
   Maximum Transmission Unit size on the 802.11-OCB link, the header
   format preceding the IPv6 header, the Type value within it, and
   others.  This document describes these parameters for IPv6 and IEEE
   802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
   similarly to other known 802.11 and Ethernet layers - by using an
   Ethernet Adaptation Layer.

                                                                                  


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

The IETF Secretariat
--------------0711169F7106B8523215ACB1-- From nobody Thu Sep 20 05:40:51 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EACE130EA3; Thu, 20 Sep 2018 05:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 3xJsMh5m5rHb; Thu, 20 Sep 2018 05:40:40 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 ABC83130E8D; Thu, 20 Sep 2018 05:40:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8KCeajJ025356; Thu, 20 Sep 2018 14:40:36 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 28F42205306; Thu, 20 Sep 2018 14:40:36 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1872520534C; Thu, 20 Sep 2018 14:40:36 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8KCeZgV020471; Thu, 20 Sep 2018 14:40:36 +0200 To: Amelia Andersdotter References: <32d8c171-2586-e2db-7cc6-26c3385b6946@article19.org> From: Alexandre Petrescu Cc: Hrpc , its@ietf.org Message-ID: <51043908-f33a-ffb4-db2b-baeb5cc0fbe2@gmail.com> Date: Thu, 20 Sep 2018 14:40:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <32d8c171-2586-e2db-7cc6-26c3385b6946@article19.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] RFC8280 Human Rights Review of draft-ietf-ipwave-ipv6-over-80211ocb-25 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 12:40:42 -0000 This is part 3, and last, of addressing comments Human Rights. Le 07/09/2018 à 22:49, Amelia Andersdotter a écrit : [...] > 4. In Section 4.3 and 4.5 it should be clarified what privacy > benefits, if any, are expected from using semantically obscure IIDs > as proposed in RFC7217. It will at least be relevant to clarify > whether privacy benefits could arise in contexts that are explicitly > out of scope (such as during forming, termination or handover), e.g. > with respect to parameter selection as specified in Appendix A of > RFC7217. I propose the following NEW text to address your comment. ----------------------------------------------------------------------- Semantically opaque Interface Identifiers, instead of meaningful Interface Identifiers derived from a valid and meaningful MAC address (RFC 2464, section 4), MAY be needed in order to avoid certain privacy risks. A valid MAC address includes a unique identifier pointing to a company together with its postal address, and a unique number within that company MAC space (see the oui.txt file). The calculation operation of the MAC address back from a given meaningful Interface Identifier is straightforward (RFC 2464, section 4). The Interface Identifier is part of an IPv6 address that is stored in IPv6 packets. The IPv6 packets can be captured in the Internet easily. For these reasons, an attacker may realize many attacks on privacy. One such attack on 802.11-OCB is to capture, store and correlate Company ID information of many cars in public areas (e.g. listen for Router Advertisements, or IPv6 application data packets, and record the value of the source address in these packets). Further correlation of this information with other data captured by other means, or other visual information (car color, others) MAY constitute privacy risks. In order to avoid these risks, opaque Interface Identifiers MAY be formed according to rules described in RFC 7217. These opaque Interface Identifiers are formed starting from identifiers different than the MAC addresses, and from cryptographically strong material. Thus, privacy sensitive information is absent from Interface IDs, and it is impossible to calculate the initial value from which the Interface ID was calculated. Some applications that use IPv6 packets on 802.11-OCB links (among other link types) may benefit from IPv6 addresses whose Interface Identifiers don't change too often. It is RECOMMENDED to use the mechanisms described in RFC 7217 to permit the use of Stable Interface Identifiers that do not change within one subnet prefix. A possible source for the Net-Iface Parameter is a virtual interface name, or logical interface name, that is decided by a local administrator. From nobody Thu Sep 20 05:47:00 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E604130DE2; Thu, 20 Sep 2018 05:46:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: its@ietf.org Message-ID: <153744761013.2052.7967213546726135052@ietfa.amsl.com> Date: Thu, 20 Sep 2018 05:46:50 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-29.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 12:46:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu Nabil Benamar Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-29.txt Pages : 40 Date : 2018-09-20 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-29 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-29 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-29 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 Thu Sep 20 05:48:42 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08A0130EAB for ; Thu, 20 Sep 2018 05:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 S3lrg6k9m3d3 for ; Thu, 20 Sep 2018 05:48:30 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 70A73130F30 for ; Thu, 20 Sep 2018 05:48:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8KCmScN028196 for ; Thu, 20 Sep 2018 14:48:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BE70620534E for ; Thu, 20 Sep 2018 14:48:28 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B1D6C2052B2 for ; Thu, 20 Sep 2018 14:48:28 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8KCmSFO025610 for ; Thu, 20 Sep 2018 14:48:28 +0200 References: <153744761038.2052.3765341754632432188.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <153744761038.2052.3765341754632432188.idtracker@ietfa.amsl.com> Message-ID: <5ccc414a-aa99-8010-3339-175c75afc922@gmail.com> Date: Thu, 20 Sep 2018 14:48:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153744761038.2052.3765341754632432188.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------96E8EDC8E0C8D8CFF026E453" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-29.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 12:48:42 -0000 This is a multi-part message in MIME format. --------------96E8EDC8E0C8D8CFF026E453 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This draft includes the last part of the Human Rights review. It adds more explanation of why it's good to use RFC7217 'stable and opaque IIDs'. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-29.txt Date : Thu, 20 Sep 2018 05:46:50 -0700 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-29.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 29 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2018-09-20 Group: ipwave Pages: 40 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-29.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-29 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-29 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------96E8EDC8E0C8D8CFF026E453 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This draft includes the last part of the Human Rights review.

It adds more explanation of why it's good to use RFC7217 'stable and opaque IIDs'.

Alex



-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-29.txt
Date : Thu, 20 Sep 2018 05:46:50 -0700
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr> 


A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-29.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	29
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2018-09-20
Group:		ipwave
Pages:		40
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-29.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-29
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-29

Abstract:
   In order to transmit IPv6 packets on IEEE 802.11 networks running
   outside the context of a basic service set (OCB, earlier "802.11p")
   there is a need to define a few parameters such as the supported
   Maximum Transmission Unit size on the 802.11-OCB link, the header
   format preceding the IPv6 header, the Type value within it, and
   others.  This document describes these parameters for IPv6 and IEEE
   802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
   similarly to other known 802.11 and Ethernet layers - by using an
   Ethernet Adaptation Layer.

                                                                                  


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

The IETF Secretariat
--------------96E8EDC8E0C8D8CFF026E453-- From nobody Mon Sep 24 23:48:41 2018 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CA713107E; Mon, 24 Sep 2018 23:48:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: its@ietf.org Message-ID: <153785811354.31139.15311374799753884569@ietfa.amsl.com> Date: Mon, 24 Sep 2018 23:48:33 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-30.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 06:48:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Alexandre Petrescu Nabil Benamar Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-30.txt Pages : 40 Date : 2018-09-24 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-30 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-30 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-30 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 Mon Sep 24 23:50:54 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED63E13122A; Mon, 24 Sep 2018 23:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh_uriRmdtiF; Mon, 24 Sep 2018 23:50:49 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 63CCF131232; Mon, 24 Sep 2018 23:50:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8P6ollw009127; Tue, 25 Sep 2018 08:50:47 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 05EAA201421; Tue, 25 Sep 2018 08:50:47 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E5EAC2013C9; Tue, 25 Sep 2018 08:50:46 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8P6oksW023571; Tue, 25 Sep 2018 08:50:46 +0200 References: <153785811387.31139.7588796819972127479.idtracker@ietfa.amsl.com> To: "its@ietf.org" Cc: Brian E Carpenter , IPv6 From: Alexandre Petrescu X-Forwarded-Message-Id: <153785811387.31139.7588796819972127479.idtracker@ietfa.amsl.com> Message-ID: <5f5eef42-23bf-810a-22a3-fb612b729cc7@gmail.com> Date: Tue, 25 Sep 2018 08:50:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153785811387.31139.7588796819972127479.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------666DF6AC0E86AE22C511281B" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-30.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 06:50:53 -0000 This is a multi-part message in MIME format. --------------666DF6AC0E86AE22C511281B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, This is an update of the IPv6-over-OCB draft. It has a clarification paragraph on the reliability of the ND protocol over OCB and over 802.11. This clarification was requested by discussion in the 6MAN Working Group. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-30.txt Date : Mon, 24 Sep 2018 23:48:33 -0700 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-30.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 30 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2018-09-24 Group: ipwave Pages: 40 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-30.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-30 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-30 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------666DF6AC0E86AE22C511281B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

This is an update of the IPv6-over-OCB draft.

It has a clarification paragraph on the reliability of the ND protocol over OCB and over 802.11.

This clarification was requested by discussion in the 6MAN Working Group.

Alex


-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-30.txt
Date : Mon, 24 Sep 2018 23:48:33 -0700
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr> 


A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-30.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	30
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2018-09-24
Group:		ipwave
Pages:		40
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-30.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-30
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-30

Abstract:
   In order to transmit IPv6 packets on IEEE 802.11 networks running
   outside the context of a basic service set (OCB, earlier "802.11p")
   there is a need to define a few parameters such as the supported
   Maximum Transmission Unit size on the 802.11-OCB link, the header
   format preceding the IPv6 header, the Type value within it, and
   others.  This document describes these parameters for IPv6 and IEEE
   802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
   similarly to other known 802.11 and Ethernet layers - by using an
   Ethernet Adaptation Layer.

                                                                                  


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

The IETF Secretariat
--------------666DF6AC0E86AE22C511281B-- From nobody Tue Sep 25 01:55:39 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D0713114A for ; Tue, 25 Sep 2018 01:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 X9D-0CJRK983 for ; Tue, 25 Sep 2018 01:55:36 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 449E7131260 for ; Tue, 25 Sep 2018 01:55:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8P8tYjS040897 for ; Tue, 25 Sep 2018 10:55:34 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 987D72019E1 for ; Tue, 25 Sep 2018 10:55:34 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8E0552007FE for ; Tue, 25 Sep 2018 10:55:34 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8P8tYHF027355 for ; Tue, 25 Sep 2018 10:55:34 +0200 To: "its@ietf.org" References: <152814227815.30650.13041947227574583212.idtracker@ietfa.amsl.com> From: Alexandre Petrescu Message-ID: Date: Tue, 25 Sep 2018 10:55:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <152814227815.30650.13041947227574583212.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] New Liaison Statement, "LS from ITU-R WP 5A to External Organizations" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 08:55:38 -0000 Le 04/06/2018 à 21:57, Liaison Statement Management Tool a écrit : [...] > Body: In the November 2017 liaison statement, Working Party (WP) 5A > had informed that it is working on the revision of Recommendation > ITU-R M.2084-0 “Radio interface standards of vehicle-to-vehicle and > vehicle to-infrastructure communications for Intelligent Transport > System applications”. [...] > WP 5A invites external organizations to submit updated information, > if any, on technical standards, and will consider the input > contributions at its next meeting in November 2018. The deadline for > submission of contributions is prior to 16:00 (UTC) on 29 October > 2018. I would like to work on an Internet Draft for IPv6-over-OCB for vehicle-to-vehicle communications. Is anybody else working on IP technology between cars? Alex