I presume I am misreading this exchange.
Brian seems to have suggested publishing the I-D under discussion as an
RFC, with a warning that implementors should not start implementing
because we have not figured out other critical bits that will affect the
implementation.
Is that really a useful thing to do? Why?
If what you want to do is put in a normative reference to the missing
bits, put it through the IESG process, and then have it wait at the RFC
Editor until the working group finishes the missing bits and the IETF
approves them, I would have to ask again, why?
Yours,
Joel
On 4/14/19 5:50 AM, Nabil Benamar wrote:
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
>
