On Mon, Apr 8, 2019 at 3:01 PM Pascal Thubert (pthubert) <pthubert@xxxxxxxxx> 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 <n.benamar@xxxxxxxxxxxxx>
Sent: lundi 8 avril 2019 17:53
To: Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx>
Cc: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx>; int-dir@xxxxxxxx; 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
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 <alexandre.petrescu@xxxxxxxxx> 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 ThubertReview result: Not ReadyReviewer: Pascal ThubertReview result: Not ready. Need to clarify IEEE relationship, IOW which SDOdefines the use of L2 fields, what this spec enforces vs. recognizes as beingused that way based on IEEE work. The use of IPv6 ND requires a lot morethoughts, recommendation to use 6LoWPAN ND. The definition of a subnet isunclear. 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 writtenprimarily for the benefit of the Internet Area Directors. Document editors andshepherd(s) should treat these comments just like they would treat commentsfrom any other IETF contributors and resolve them along with any other LastCall 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 on802.11 than on Ethernet.“Is this doc scoped to OCB or 802.11 in general? Is there an expectation that animplementer of IPv6 over Wi-Fi refers to this doc? Spelled as above, it seemsthat you are defining the LLC. Figure 1 shows the proposed adaptation layer asIEEE LLC work. Who defines those fields, IETF or IEEE, or mixed? Who definestheir 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 isolatedfrom IEEE fields."The IPv6 packet transmitted on 802.11-OCB MUST be immediatelypreceded 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 uppercasebut say something like: 'Per IEEE Std 802.11, the IPv6 packet transmitted on802.11-OCB is immediately preceded by a Logical Link Control (LLC) header andan 802.11 header ...'different things? Why define both?" An 'adaptation' layer is inserted between a MAC layer and theNetworking layer. This is used to transform some parameters betweentheir form expected by the IP stack and the form provided by the MAClayer."Is this different from what an AP does when it bridges Wi-Fi to Ethernet? Isthis IETF business?"The Receiver and Transmitter Address fields in the 802.11 header MUSTcontain the same values as the Destination and the Source Addressfields in the Ethernet II Header, respectively."Same, this is IEEE game isn't it?"Solutions for these problems SHOULDconsider 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 understandthe specific needs of OCB vs. Wi Fi, but I do not see text about that."The method of forming IIDsdescribed in section 4 of [RFC2464] MAY be used during transitiontime."Contradicts section 4.3 that says"Among these types ofaddresses only the IPv6 link-local addresses MAY be formed using anEUI-64 identifier.""Thissubnet MUST use at least the link-local prefix fe80::/10 and theinterfaces 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 vehiclesthat 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 youtalking about a link, rather?"The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over802.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."