Alexandre: Yes. Once the WG sends the document to the IESG, there will be more review. Resolving the current set of comments will put us in a much better place, and increase the number of people that are supporting the approach in the document. Russ > On Apr 8, 2019, at 9:09 AM, Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> wrote: > > > > Le 08/04/2019 à 14:58, Pascal Thubert (pthubert) a écrit : >> Hello Alexandre >> All the best,please see below >> *From:*Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> >> *Sent:* lundi 8 avril 2019 17:01 >> *To:* Pascal Thubert (pthubert) <pthubert@xxxxxxxxx>; int-dir@xxxxxxxx >> *Cc:* ietf@xxxxxxxx; its@xxxxxxxx; draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx >> *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 > > _______________________________________________ > its mailing list > its@xxxxxxxx > https://www.ietf.org/mailman/listinfo/its
