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

[Abdussalam Baryun <[e-mail]>]

On Mon, Apr 8, 2019 at 3:01 PM 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…*
>

just to point one important issue, the most important issue is not the
review, but the WG convinced and  clear and true technical discussions. The
working group can clarify things to reviewers even iesg, so the WG can
always discuss with ant reviewer.


>
>
>
> *   Cheers,   Pascal   From: NABIL BENAMAR <[e-mail]
> <[e-mail]>> Sent: lundi 8 avril 2019 17:53 To: Alexandre
> Petrescu <[e-mail] <[e-mail]>> Cc:
> Pascal Thubert (pthubert) <[e-mail] <[e-mail]>>;
> [e-mail] <[e-mail]>; [e-mail] <[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.*
>

also there are things that are necessary and things that are optional, I
don't agree to add optional issues in first RFC of WG.

*   On Mon, Apr 8, 2019, 10:01 Alexandre Petrescu
> <[e-mail] <[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/
> <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/bcp14
> <https://tools.ietf.org/html/bcp14>    [https://tools.ietf.org/html/rfc2119
> <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] <[e-mail]> https://www.ietf.org/mailman/listinfo/its
> <https://www.ietf.org/mailman/listinfo/its> *