Re: [ipwave] [Gen-art] Genart telechat review of draft-ietf-ipwave-ipv6-over-80211ocb-47

Dear Alissa,

I have previously replied to Roni as follows:

If we look at https://tools.ietf.org/html/rfc8065 which recommends the
generic https://tools.ietf.org/html/rfc8064, we can say that we  comply by
inheritance from Ethernet since our current draft is targeted at using the
RFC 2464 (plus IPv6 suite over Ethernet) with minimal changes, as we
mention in the abstract (...for using IPv6 to communicate among nodes in
range of

   one another over a single IEEE 802.11-OCB link *with minimal change to *

*   existing stacks*).

However, there are some specificities related to vehicles. Since they roam
a lot, the use of the same Link-Local Address over time can leak the
presence of the same vehicle in multiple places. Location tracking, if the
same interface identifier is used with different prefixes as a
device/vehicle moves between different networks.

Hence, a vehicle should get hints about a change of environment (e.g. ,
engine running, GPS, whatever) and renew the IID in LLAs.

and then I updated the to -49 by adding this text: "Furthermore, for

   pricavy concerns ([RFC8065 <https://tools.ietf.org/html/rfc8065>])
recommends using an address generation
   scheme rather than addresses generated from a fixed link-layer

   address."

When I got no further comment from Roni, I thought it was resolved!

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

On Wed, Jul 10, 2019 at 9:47 PM Alissa Cooper <alissa@cooperw.in> wrote:

> I reviewed the -49 version so my questions are on that version.
> Alissa
>
> On Jul 10, 2019, at 4:44 PM, Suresh Krishnan <Suresh@kaloom.com> wrote:
>
> Hi Nabil,
>   Roni's telechat review is for the version on which I issued the ballot
> (in this case it is -47). If you think the issue is resolved in a later
> version (I do not believe so in this case), you can respond to point out
> the actual text change that you made to address Roni’s comment.
>
> Thanks
> Suresh
>
> On Jul 10, 2019, at 4:38 PM, Nabil Benamar <benamar73@gmail.com> wrote:
>
> Hi Alissa,
>
> Thank you for your review. However, I have updated the draft and now it's
> in -49 reflecting previous comments.
>
>
> Best regards
> Nabil Benamar
> -------------------
> نبيل بنعمرو
>
>
>
>
>
>
>
> On Wed, Jul 10, 2019 at 7:29 PM Alissa Cooper <alissa@cooperw.in> wrote:
>
>> Roni, thanks for your review. Alex, Nabil, thanks for your responses. I
>> entered a DISCUSS ballot to try to get more clarity about the relationship
>> between MAC address changes and IID changes, among other things.
>>
>> Alissa
>>
>> > On Jul 4, 2019, at 2:05 AM, Roni Even via Datatracker <noreply@ietf.org>
>> wrote:
>> >
>> > Reviewer: Roni Even
>> > Review result: Ready with Issues
>> >
>> > I am the assigned Gen-ART reviewer for this draft. The General Area
>> > Review Team (Gen-ART) reviews all IETF documents being processed
>> > by the IESG for the IETF Chair. Please wait for direction from your
>> > document shepherd or AD before posting a new version of the draft.
>> >
>> > For more information, please see the FAQ at
>> >
>> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>> >
>> > Document: draft-ietf-ipwave-ipv6-over-80211ocb-47
>> > Reviewer: Roni Even
>> > Review Date: 2019-07-03
>> > IETF LC End Date: None
>> > IESG Telechat date: 2019-07-11
>> >
>> > Summary:
>> > The document is ready to be published as a standard track RFC with an
>> issue
>> >
>> > Major issues:
>> >
>> > Minor issues:
>> >
>> > this is about my previous comment.
>> > The text in section 5.1 "A vehicle embarking  an IP-OBU whose egress
>> interface
>> > is 802.11-OCB may expose itself to  eavesdropping and subsequent
>> correlation of
>> > data; this may reveal data considered private by the vehicle owner;
>> there is a
>> > risk of being tracked.  In outdoors public environments, where vehicles
>> > typically circulate, the privacy risks are more important than in
>> indoors
>> > settings." and "there is a strong necessity to use protection tools
>> such  as
>> > dynamically changing MAC addresses"
>> > so even though there are privacy concerns there is no normative text
>> saying
>> > that some method is needed. "strong necessity" is not normative .
>> >
>> > A new sentence was added to section 5.1 "An example of change policy is
>> to
>> > change the MAC address of the OCB interface each time the system boots
>> up"
>> >
>> > I got more confused by section 5.2 text "The policy dictating when the
>> MAC
>> > address is changed on the 802.11-OCB interface is to-be-determined."
>> >
>> > So what I got from section 5.1 and 5.2 is that protection tools to
>> address
>> > privacy concern are needed but without any normative text.  Dynamic
>> changing
>> > of MAC address is an option, no other option is mentioned.  Example for
>> when to
>> > change MAC address is on system boot and the policy when to change MAC
>> address
>> > is to be determined.
>> >
>> > To summarize what the document currently says is that privacy risks are
>> more
>> > important for outdoor public environment and it is left for
>> implementations to
>> > decide if and how to address it.
>> >
>> > Nits/editorial comments:
>> >
>> >
>> > _______________________________________________
>> > Gen-art mailing list
>> > Gen-art@ietf.org
>> > https://www.ietf.org/mailman/listinfo/gen-art
>>
>> _______________________________________________
>> its mailing list
>> its@ietf.org
>> https://www.ietf.org/mailman/listinfo/its
>>
>
>
>