Thank you Roni, There was a privacy review of the draft and I think we have reflected all concerns.
In MHO, the security review will be done as part of the process. On Tue, Jun 18, 2019, 11:40 Roni Even (A) <[email protected]> wrote: > Hi, > > I am not a security expert, I was just trying to reflect that when reading > the document I got the impression that privacy is a major concern since the > IP-OBU is moving and its location can be traced by sniffing the MAC > addresses. > > Maybe it will be good to have a security review of the document. I also > noticed that there is support in IEEE SA - 1609.4-2016 for MAC address change. > > > > Roni Even > > > > *From:* Dick Roy [mailto:[email protected]] > *Sent:* Monday, June 17, 2019 10:48 PM > *To:* Roni Even (A); 'NABIL BENAMAR'; 'Roni Even' > *Cc:* [email protected]; 'IETF Discussion'; [email protected]; > [email protected] > *Subject:* RE: [ipwave] [Gen-art] Genart last call review of > draft-ietf-ipwave-ipv6-over-80211ocb-46 > > > > > > > ------------------------------ > > *From:* its [mailto:[email protected] <[email protected]>] *On > Behalf Of *Roni Even (A) > *Sent:* Monday, June 17, 2019 6:26 AM > *To:* NABIL BENAMAR; Roni Even > *Cc:* [email protected]; IETF Discussion; [email protected]; > [email protected] > *Subject:* Re: [ipwave] [Gen-art] Genart last call review of > draft-ietf-ipwave-ipv6-over-80211ocb-46 > > > > Thanks, > > The only comment left is: > > > 2. In section 5.2 "The policy dictating when the MAC address is changed on > the > 802.11-OCB interface is to-be-determined.". Reading the next sentence it > looks > to me that this is needed as part of the solution and should not be left > for > the unknown future. > > > > Should we reformulate here? > > > > I was expecting some recommendation since the changing of MAC address is > important to address privacy issues (discussed in section 5). Currently it > is left open with no recommendation , only saying that dynamic change of > MAC address is needed. > > Maybe the document should have some normative language for example in > section 5.1 that will say that IP-OBU MUST dynamic change their MAC > addresses > > *[RR] I highly recommend AGAINST this! There will be a number OBU and RSU > implementations that DO NOT require anonymity, and don’t want it either. > Furthermore, immutable identifier change must be coordinated with all other > interfaces and protocols otherwise changing them is useless.* > > > > Did the document go through security area review? > > *[RR] If it did, and the above was not mentioned, then something was > missed.* > > > > Roni > > > > > > *From:* Gen-art [mailto:[email protected] > <[email protected]>] *On Behalf Of *NABIL BENAMAR > *Sent:* Monday, June 17, 2019 12:48 PM > *To:* Roni Even > *Cc:* [email protected]; IETF Discussion; [email protected]; > [email protected] > *Subject:* Re: [Gen-art] Genart last call review of > draft-ietf-ipwave-ipv6-over-80211ocb-46 > > > > Dear Roni, > > > > Thank you for your review. > > Please, see my answers below. > > > > > > > > > > > > On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracker <[email protected]> > wrote: > > Reviewer: Roni Even > Review result: Almost Ready > > 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 treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-ipwave-ipv6-over-80211ocb-?? > Reviewer: Roni Even > Review Date: 2019-06-16 > IETF LC End Date: 2019-06-26 > IESG Telechat date: Not scheduled for a telechat > > Summary: > The document is almost ready for publication as a standard track RFC > > Major issues: > > Minor issues: > > 1. Section 4.2 says "IP packets MUST be transmitted over 802.11-OCB media > as > QoS Data" while appendix F say "The STA may send data frames of subtype > Data, > Null, QoS Data, and > QoS Null. > > > > I will update the appendix to reflect the text in section 4.2. > > > 2. In section 5.2 "The policy dictating when the MAC address is changed on > the > 802.11-OCB interface is to-be-determined.". Reading the next sentence it > looks > to me that this is needed as part of the solution and should not be left > for > the unknown future. > > > > Should we reformulate here? > > > 3. In Appendix I 4th paragraph " However, this does not apply if TBD TBD > TBD. " > .. What are the TBDs? > > > > The whole sentence will be removed. > > > Nits/editorial comments: > 1. In appendix I last paragraph "Support of RFC 8505 is may be implemented > on > OCB." should be "Support of RFC 8505 may be implemented on OCB." 2. In > Appendix > I "OCB nodes that support RFC 8505 would support the 6LN operation in > order to > act as a host". I think that instead of "would" it should be "should" > also if > this is a recommendation why not have this paragraph not in an appendix > with > "MAY" and "SHOULD > > > > > > Agreed. > > > >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
