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
<brian.e.carpenter@xxxxxxxxx <mailto:brian.e.carpenter@xxxxxxxxx>> 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)
<sgundave@xxxxxxxxx <mailto:sgundave@xxxxxxxxx>
<mailto: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>
<mailto: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
>
