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

[Nabil Benamar <[e-mail]>]

I agree with this view. ..so can we solve the ND issue this way and move
the draft forward?

Best regards
Nabil



On Sun, Apr 14, 2019, 03:20 Brian E Carpenter <[e-mail]>
wrote:

> >> 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) <
> [e-mail] <mailto:[e-mail]>> 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" <
> [e-mail] <mailto:[e-mail]>>
> >     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
> >
>
>