Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

[NABIL BENAMAR <[e-mail]>]

I agree with you Sri!

It's worth noting that during the 2 last IETF meetings, we got the
impression that the draft needs just few adjustments. I think that the ND
issues should be tackled in a seperated document.

On Fri, Apr 12, 2019, 15:39 Sri Gundavelli (sgundave) <[e-mail]>
wrote:

> I am not following these discussions.  From my point of view, many of the
> discussions are totally out of scope for this document.
>
> Some one needs to moderate these discussions.
>
> Sri
>
>
>
> From: its <[e-mail]> on behalf of Nabil Benamar <
> [e-mail]>
> Date: Friday, April 12, 2019 at 7:34 AM
> To: "Pascal Thubert (pthubert)" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, Nabil Benamar <
> [e-mail]>, "
> [e-mail]" <
> [e-mail]>, Alexandre Petrescu <
> [e-mail]>
> Subject: Re: [ipwave] Intdir early review of
> draft-ietf-ipwave-ipv6-over-80211ocb-34
>
> Hello Pascal,
>
> I seconded Akex and would like to suggest you to add the missing text in
> the draft.
>
> Best regards
> Nabil
>
>
>
> On Mon, Apr 8, 2019, 14:01 Pascal Thubert (pthubert) <[e-mail]>
> wrote:
>
>> Hello Nabil.
>>
>>
>>
>> You will get a number of IESG reviews as part of the submission process,
>> one per area. This is just a beginning…
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Pascal
>>
>>
>>
>> *From:* NABIL BENAMAR <[e-mail]>
>> *Sent:* lundi 8 avril 2019 17:53
>> *To:* Alexandre Petrescu <[e-mail]>
>> *Cc:* Pascal Thubert (pthubert) <[e-mail]>; [e-mail];
>> [e-mail]; [e-mail];
>> [e-mail]
>> *Subject:* Re: Intdir early review of
>> draft-ietf-ipwave-ipv6-over-80211ocb-34
>>
>>
>>
>> Yes definitely Alex....
>>
>>
>>
>> There have been many reviews until now. This should be a late or
>> final review.
>>
>>
>>
>> On Mon, Apr 8, 2019, 10:01 Alexandre Petrescu <
>> [e-mail]> wrote:
>>
>> As a note: please improve the title of this.
>>
>> It is not an early review.
>>
>> It is a late review.
>>
>> There have been several reviews of this document until here, and two
>> shepherd reviews.
>>
>> Alex
>>
>> Le 04/03/2019 à 12:24, Pascal Thubert a écrit :
>>
>> Reviewer: Pascal Thubert
>>
>> Review result: Not Ready
>>
>>
>>
>> Reviewer: Pascal Thubert
>>
>> Review result: Not ready. Need to clarify IEEE relationship, IOW which SDO
>>
>> defines the use of L2 fields, what this spec enforces vs. recognizes as being
>>
>> used that way based on IEEE work. The use of IPv6 ND requires a lot more
>>
>> thoughts, recommendation to use 6LoWPAN ND. The definition of a subnet is
>>
>> unclear. It seems that RSUs would have prefixes but that is not discussed.
>>
>>
>>
>> I am an assigned INT and IOT directorates reviewer for <
>>
>> draft-ietf-ipwave-ipv6-over-80211ocb-34 >. These comments were written
>>
>> primarily for the benefit of the Internet Area Directors. Document editors and
>>
>> shepherd(s) should treat these comments just like they would treat comments
>>
>> from any other IETF contributors and resolve them along with any other Last
>>
>> Call comments that have been received. For more details on the INT Directorate,
>>
>> see https://datatracker.ietf.org/group/intdir/about/
>>
>>
>>
>> Majors issues
>>
>> -----------------
>>
>>
>>
>> “
>>
>>
>>
>> o  Exceptions due to different operation of IPv6 network layer on
>>
>>       802.11 than on Ethernet.
>>
>>
>>
>> “
>>
>> Is this doc scoped to OCB or 802.11 in general? Is there an expectation that an
>>
>> implementer of IPv6 over Wi-Fi refers to this doc? Spelled as above, it seems
>>
>> that you are defining the LLC. Figure 1 shows the proposed adaptation layer as
>>
>> IEEE LLC work. Who defines those fields, IETF or IEEE, or mixed? Who defines
>>
>> their use? If this spec defines a new LLC header (vs. how to use an IEEE field)
>>
>>  then it should be very clear, and the newly defined fields should be isolated
>>
>> from IEEE fields.
>>
>>
>>
>> "
>>
>>    The IPv6 packet transmitted on 802.11-OCB MUST be immediately
>>
>>    preceded by a Logical Link Control (LLC) header and an 802.11 header.
>>
>>
>>
>> "
>>
>> Is there anything new or specific to OCB vs. classical 802.11 operations?
>>
>> If/when this is echoing the IEEE specs then this text should not use uppercase
>>
>> but say something like: 'Per IEEE Std 802.11, the IPv6 packet transmitted on
>>
>> 802.11-OCB is immediately  preceded by a Logical Link Control (LLC) header and
>>
>> an 802.11 header ...'
>>
>>
>>
>> different things? Why define both?
>>
>>
>>
>> "   An 'adaptation' layer is inserted between a MAC layer and the
>>
>>    Networking layer.  This is used to transform some parameters between
>>
>>    their form expected by the IP stack and the form provided by the MAC
>>
>>    layer.
>>
>> "
>>
>> Is this different from what an AP does when it bridges Wi-Fi to Ethernet? Is
>>
>> this IETF business?
>>
>>
>>
>> "
>>
>>    The Receiver and Transmitter Address fields in the 802.11 header MUST
>>
>>    contain the same values as the Destination and the Source Address
>>
>>    fields in the Ethernet II Header, respectively.
>>
>> "
>>
>> Same,  this is IEEE game isn't it?
>>
>>
>>
>> "
>>
>>
>>
>> Solutions for these problems SHOULD
>>
>>    consider the OCB mode of operation.
>>
>> "
>>
>> This is not specific enough to be actionable. I suggest to remove this sentence.
>>
>> It would be of interest for the people defining those solutions to understand
>>
>> the specific needs of OCB vs. Wi Fi, but I do not see text about that.
>>
>>
>>
>> "
>>
>>
>>
>> The method of forming IIDs
>>
>>    described in section 4 of [RFC2464] MAY be used during transition
>>
>>    time.
>>
>> "
>>
>> Contradicts section 4.3 that says
>>
>> "
>>
>> Among these types of
>>
>>    addresses only the IPv6 link-local addresses MAY be formed using an
>>
>>    EUI-64 identifier.
>>
>> "
>>
>>
>>
>> "
>>
>>
>>
>> This
>>
>>    subnet MUST use at least the link-local prefix fe80::/10 and the
>>
>>    interfaces MUST be assigned IPv6 addresses of type link-local.
>>
>> "
>>
>> If this is conforming IPv6 then the MUST is not needed.
>>
>>
>>
>> "
>>
>>    A subnet is formed by the external 802.11-OCB interfaces of vehicles
>>
>>    that are in close range (not by their in-vehicle interfaces).
>>
>> "
>>
>> Is the definition transitive? Do we really get a subnet?
>>
>>  A is close to  B who is close to C .... to Z, makes Paris one subnet! Are you
>>
>>  talking about a link, rather?
>>
>>
>>
>> "
>>
>>    The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over
>>
>>    802.11-OCB links.
>>
>> "
>>
>>
>>
>> IPv6 ND is not suited for a non-broadcast network. How does DAD work?
>>
>> Maybe you could consider RFC 6775 / RFC 8505 instead.
>>
>>
>>
>> "
>>
>> In the moment the MAC address is changed
>>
>>    on an 802.11-OCB interface all the Interface Identifiers of IPv6
>>
>>    addresses assigned to that interface MUST change.
>>
>> "
>>
>> Why is that? This is unexpected, and hopefully wrong.
>>
>>
>>
>> Minor issues
>>
>> ---------------
>>
>>
>>
>> "   OCB (outside the context of a basic service set - BSS): A mode of
>>
>>    operation in which a STA is not a member of a BSS and does not
>>
>>    utilize IEEE Std 802.11 authentication, association, or data
>>
>>    confidentiality.
>>
>>
>>
>>    802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB
>>
>>    attribute dot11OCBActivited is true.  Note: compliance with standards
>>
>>    and regulations set in different countries when using the 5.9GHz
>>
>>    frequency band is required.
>>
>> "
>>
>>
>>
>> Are these 2 different things?
>>
>>
>>
>> "
>>
>> Among these types of
>>
>>  addresses only the IPv6 link-local addresses MAY be formed using an
>>
>>   EUI-64 identifier.
>>
>> "
>>
>> This text should not be in a LL specific section since it deals with the other
>>
>> addresses. Maybe rename the section to "addressing" or something?
>>
>>
>>
>> "
>>
>>    For privacy, the link-local address MAY be formed according to the
>>
>>    mechanisms described in Section 5.2.
>>
>> "
>>
>> The MAY is not helpful. I suggest to remove the sentence that does not bring
>>
>> value vs. 5.2
>>
>>
>>
>> Could you make sections 4.3 and 4.5 contiguous?
>>
>>
>>
>> "
>>
>> If semantically
>>
>>    opaque Interface Identifiers are needed, a potential method for
>>
>>    generating semantically opaque Interface Identifiers with IPv6
>>
>>    Stateless Address Autoconfiguration is given in [RFC7217]..
>>
>>
>>
>>    Semantically opaque Interface Identifiers, instead of meaningful
>>
>>    Interface Identifiers derived from a valid and meaningful MAC address
>>
>>    ([RFC2464], section 4), MAY be needed in order to avoid certain
>>
>>    privacy risks.
>>
>>
>>
>> ...
>>
>>
>>
>>    In order to avoid these risks, opaque Interface Identifiers MAY be
>>
>>    formed according to rules described in [RFC7217].  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.
>>
>>
>>
>> "
>>
>> Duplicate and mis ordered text, isn't it?
>>
>>
>>
>> " For this reason, an attacker may realize many
>>
>>    attacks on privacy.
>>
>> "
>>
>> Do we attack privacy? Maybe say that privacy is a real concern, and maybe move
>>
>> that text to security section?
>>
>>
>>
>> "
>>
>>    The way Interface Identifiers are used MAY involve risks to privacy,
>>
>>    as described in Section 5.1.
>>
>> "
>>
>> Also duplicate
>>
>>
>>
>> Nits
>>
>> ------
>>
>>
>>
>> "
>>
>>    IP packets MUST be transmitted over 802.11-OCB media as QoS Data
>>
>>    frames whose format is specified in IEEE Std 802.11.
>>
>> "
>>
>> Please add link to the reference
>>
>>
>>
>> " the 802.11 hidden node"
>>
>> Do not use 802.11 standalone (multiple occurrences).
>>
>> => "the IEEE Std. 802.11 [ ref ] hidden node", or just "the hidden terminal".
>>
>>
>>
>> BCP 14 text:
>>
>>
>>
>> Suggest to use this text:
>>
>> “
>>
>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>
>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>
>>    "OPTIONAL" in this document are to be interpreted as described in
>>
>>    https://tools.ietf.org/html/bcp14 https://tools.ietf.org/html/bcp14
>>
>>    [https://tools.ietf.org/html/rfc2119][RFC8174] when, and only when, they
>>
>>    appear in all capitals, as shown here.
>>
>>
>>
>> “
>>
>>
>>
>> All the best
>>
>>
>>
>> Pascal
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> its mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/its
>>
>