Re: [ipwave] Alissa Cooper's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

[Nabil Benamar <[e-mail]>]

Hi Alissa,

Thanks again for your review. Please see my answers below


On Wed, Jul 10, 2019 at 7:27 PM Alissa Cooper via Datatracker <
[e-mail]> wrote:

> Alissa Cooper has entered the following ballot position for
> draft-ietf-ipwave-ipv6-over-80211ocb-49: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I support Roman's DISCUSS.
>
> Overall I am unclear on the privacy properties of what this document
> specifies.
> I think it would help to have a clear statement about the circumstances
> under
> which each kind of address generation scheme is recommended. Were RFC 4941
> addresses not considered because addresses generated according to RFC 8064
> have
> functionally equivalent properties given how often moving vehicle change
> subnets? For link-local addresses, is it possible to give recommendations
> for
> when IIDs should be re-generated?
>
> Here is the new text in -49

An example of change policy is to change the MAC
   address of the OCB interface each time the system boots up.  This may
   help mitigate privacy risks to a certain level.  Futhermore, 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.



> = Section 5.2 =
>
> "An Interface ID SHOULD be of length specified in other documents."
>
> Isn't the length specified for each of the two IID generation mechanisms
> discussed in Section 4.3 and 4.4?
>

We decided to remove this sentence from the text since ther is no other
document.

>
> = Section 5.3 =
>
> "The demand for privacy protection of vehicles' and drivers'
>    identities, which could be granted by using a pseudonym or alias
>    identity at the same time, may hamper the required confidentiality of
>    messages and trust between participants"
>
> Pseudonymity and confidentiality are not mutually exclusive, so I think
> this is
> incorrect.
>

I agree.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Please expand OCB and STA on first use.
>
> = Section 2 =
>
> "Note: compliance with
>    standards and regulations set in different countries when using the
>    5.9GHz frequency band is required."
>
> I'm not familiar with the standards and regulations being referenced here,
> but
> is there any specific reason why this needs to be said here? Presumably
> users
> of regulated spectrum bands the world over must comply with associated
> regulations governing their use. It's not clear to me that it makes sense
> to
> note this here.
>
> = Section 5.1.1 =
>
> "Further
>    correlation of this information with other data captured by other
>    means, or other visual information (car color, others) MAY constitute
>    privacy risks."
>
> The normative MAY is not appropriate here.
>
> = Section 5.2 =
>
> "In 802.11-OCB networks, the MAC addresses MAY change during well
>    defined renumbering events."
>
> The normative MAY is not appropriate here (since this is not the 802.11-OCB
> spec).
>
>
>

-- 

Best Regards

Nabil Benamar
Associate Professor
Department of Computer Sciences
School of Technology
Moulay Ismail University
Meknes. Morocco