>> All we need is a simple statement in the spec which puts some scope >> limits, w.r.t the missing ND pieces and issues. Yes, that is clearly essential, as well as an associated health warning that implementers must not rush ahead because of the risk of non-interoperability. Regards Brian On 14-Apr-19 13:58, NABIL BENAMAR wrote: > +1 Sri > > On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave) <sgundave@xxxxxxxxx <mailto:sgundave@xxxxxxxxx>> wrote: > > I understand your point Brian, but IMO there are enough reasons not to > delay this work. > > There are many use-cases/applications where there is a stable topology of > RSU¹s and OBU¹s. The regulations around 5.9 Ghz (DSRC) band allows the > channel use for non-priority/non-traffic safety related applications. For > example, a vehicle in a gas station can receive a coupon from the > 802.11-OCB radio (AP/RSU) in the gas station. There, its a stable topology > that classic ND is designed for. In this operating mode, its perfectly > reasonable to use classic ND and it works. The authors have shown enough > lab data on the same. > > Ideally, I agree with you that it makes lot more sense to publish both the > specs at the same time. But, for what ever reasons the WG went on this > path. Authors have spent incredible amount of efforts in getting the draft > this far and we cannot ignore that. You can see the efforts from the > version number; when did we last see a draft version -037? > > We also need to distill the recent ND discussions and filter out the > threads that are clearly motivated to insert a ND protocol that is > designed for a totally different operating environment. An argument that a > protocol designed for low-power environments is the solution for vehicular > environments requires some serious vetting. Looking at the > characteristics, always-sleeping, occasional internet connectivity, > low-power, no memory, no processing power, no mobility ..etc, meeting > vehicular requirements is some thing most people in the WG do not get it. > > Bottom line, IMO, we should move this forward and publish the document. > All we need is a simple statement in the spec which puts some scope > limits, w.r.t the missing ND pieces and issues. There are other proposals > in the WG that will address the gaps and bring closure to the work. > > Sri > > > > > > > > > > > On 4/12/19, 1:28 PM, "Brian E Carpenter" <brian.e.carpenter@xxxxxxxxx <mailto:brian.e.carpenter@xxxxxxxxx>> > wrote: > > >On 13-Apr-19 02:59, Sri Gundavelli (sgundave) wrote: > >>If you go back and check 2017 archives, I did raise many of these > >>issues. But, we clearly decided to limit the scope excluding address > >>configuration, DAD, ND aspect, link models. When there is such a scope > >>statement, it should clearly move these comments to the draft that > >>defines how ND works for 802.11-OCB links. > > > >This is of course possible. In general the IETF hasn't done that, but has > >followed the lead set by RFC 2464 with the complete specification of > >IPv6-over-foo in one document. > > > >However, I don't believe that publishing an RFC about the frame format > >without *simultaneously* publishing an RFC about ND etc would be a good > >idea. That would leave developers absolutely unable to write useful > >code, and might easily lead to incompatible implementations. Since > >we'd presumably like Fords to be able to communicate with Peugeots, > >that seems like a bad idea. > > > >Regards > > Brian >
