Oh yes. Once you passed me. You may find I was easy ; ) All the best, Pascal > -----Original Message----- > From: Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> > Sent: lundi 8 avril 2019 21:09 > 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 > > > > 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 > >
