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 <[email protected]> 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 <[email protected]> > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ > its mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/its >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
