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

["Pascal Thubert (pthubert)" <[e-mail]>]

Oh yes. Once you passed me. You may find I was easy ; )

All the best,

Pascal

> -----Original Message-----
> From: Alexandre Petrescu <[e-mail]>
> Sent: lundi 8 avril 2019 21:09
> To: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; draft-ietf-ipwave-ipv6-over-
> [e-mail]
> Subject: Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
> 
> 
> 
> Le 08/04/2019 à 14:58, Pascal Thubert (pthubert) a écrit :
> > Hello Alexandre
> >
> > All the best,please see below
> >
> > *From:*Alexandre Petrescu <[e-mail]>
> > *Sent:* lundi 8 avril 2019 17:01
> > *To:* Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
> > *Cc:* [e-mail]; [e-mail];
> > [e-mail]
> > *Subject:* Re: Intdir early review of
> > draft-ietf-ipwave-ipv6-over-80211ocb-34
> >
> > As a note: please improve the title of this.
> >
> > It is not an early review.
> >
> > It is a late review.
> >
> >   * In the context of document publication I believe this is coming
> >     before all the other areas directorates isn’t it. That’s what early
> >     means here…
> 
> Ah?
> 
> Should we expect more reviews from more directorates?
> 
> How about IESG?
> 
> Alex
> 
> >
> > 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,
> >
> >     seehttps://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
> >