Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-02 - minor textual issues

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 May 2017 11:39:20 +0200

Hello,

A set of private comments early March pointed to a need of clarifying a
few aspects.  Here is the resolution.

OLD:
> The IPv6 network layer operates on 802.11 OCB in the same manner as
> it operates on 802.11 WiFi.

This makes think that, below IPv6, 802.11 OCB works as 802.11 WiFi
works.  It is not true.  As such, the resolution is this.

NEW:
> The IPv6 network layer operates on 802.11 OCB in the same manner as
> it operates on 802.11 WiFi, with a few particular exceptions.

End issue.

OLD:
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                 IPv6 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |       Ethernet
> Adaptation Layer       | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> 802.11 WiFi MAC           | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | 802.11 WiFi PHY           |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this figure, a clarification was requested, in the form of adding a
figure caption clarifying whether this represents a WiFi profile or a
OCB profile.

At this time I dont know how to add figure captions in xml2rfc, but the
clarification can be added right before the figure.  This is the
clarification:

NEW:
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                 IPv6 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |       Ethernet
> Adaptation Layer       | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> 802.11 WiFi MAC           | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | 802.11 WiFi PHY           |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> (in the above figure, a WiFi profile is represented; this is used
> also for OCB profile.)

End issue.

OLD:
> RSU: Road Side Unit. An IP router equipped with, or connected to, at
> least one interface that is 802.11 and that is an interface that
> operates in OCB mode.

A comment was made stating that an RSU is not a router, and that an RSU
may be connected to a router via an interface, e.g. Ethernet, to access
the infrastructure if required.

But I think that some Road Side Units are indeed IP routers and they
access the infrastructure and the Internet.  This is an important point
when using the IP protocol - be connected.

I think I keep that text that way at this time.

End issue.

OLD:
> The link 802.11 OCB was specified in IEEE Std 802.11p(TM)-2010
> [ieee802.11p-2010] as an amendment to the 802.11 specifications

It was suggested that the "802.11 specifications" are in fact "IEEE Std
802.11-2007".  As such the resolution is:

NEW:
> The link 802.11 OCB was specified in IEEE Std 802.11p(TM)-2010
> [ieee802.11p-2010] as an amendment to IEEE Std 802.11-2007

End issue.

OLD:
> The used identifier of BSS (BSSID) has a hexadecimal value always
> ff:ff:ff:ff:ff:ff (48 '1' bits, or the 'wildcard' BSSID),

It was suggested that the base 16 numerical notation convention is
0xffffffffffff, and not ff:ff:ff:ff:ff:ff.  As such the resolution is
this new text:

NEW:
> The used identifier of BSS (BSSID) has a hexadecimal value always
> 0xffffffffffff (48 '1' bits, represented as MAC address
> ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' BSSID)

End issue.

OLD:
> On the hand

It was suggested it is not goog English expression.  So it becomes:

NEW:
> On the other hand

End issue.

OLD:
> Prohibition of IPv6 on some channels relevant for the PHY of IEEE
> 802.11-OCB, as opposed to IPv6 not being prohibited on any channel on
> which 802.11a/b/g/n runs; at the time of writing, this prohibition is
> explicit in IEEE 1609 documents.

It was suggested that this is not a PHY prohibition, but rather a higher
layer protocols providing services to the application.

As such the new text is the following:

NEW:
> Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB,
> as opposed to IPv6 not being prohibited on any channel on which
> 802.11a/b/g/n runs; at the time of writing, this prohibition is
> explicit at higher layer protocols providing services to the
> application; these higher layer protocols are specified in IEEE 1609
>  documents.

End issue.

OLD:
> In vehicular communications using 802.11-OCB links, there are strong
>  privacy concerns with respect to addressing. While the 802.11-OCB
> standard does not specify anything in particular with respect to MAC
>  addresses

It has been suggested that there is something to think about here, which
may affect the above statement: there is at least one country where the
vehicle|driver information, be it physical or electronic, must be
allowed access by law enforcement if so required.

This is noted.  I suggest we discuss this separately.

At this time I do not modify this text.

End issue.

OLD:
> If IPv6 packets of size larger than 1500 bytes are sent on an
> 802.11-OCB interface then the IP stack will fragment.

There was a question whether we should substitute "SAP - Service Access
Point" for "interface" in the above phrase.

I think the current text is right: it talks about an interface card, not
about a SAP between layers.

NEW:
> If IPv6 packets of size larger than 1500 bytes are sent on an
> 802.11-OCB interface card then the IP stack will fragment.

End issue.

OLD:
>       +--------+                                +-------+
>       |        |        802.11-OCB Link         |       |
>    ---| Router |--------------------------------| Host  |
>       |        |                                |       |
>       +--------+                                +-------+

There was a question whether that "802.11-OCB Link" is the air
interface, and, if yes, then the question further asks whether the OBU
or RSU is integrated int he router and host?

The clarification is that the Host may be an OBU (that is not a IP
router) and the Router may be a Road Side Unit that is an IP router.

'Host' and 'Router' are terms defined.

End issue.

OLD:
> There are considerations for 2 or more IEEE 802.11-OCB interface
> cards per vehicle. For each vehicle taking part in road traffic, one
> IEEE 802.11-OCB interface card MUST be fully allocated for Non IP
> safety-critical communication. Any other IEEE 802.11-OCB may be used
> for other type of traffic.

There was a comment stating that while "fully allocated" certaiinly
improves performance in many ways, that is not a MUST.  As such, the new
clarified text is the following.

NEW:
> There are considerations for 2 or more IEEE 802.11-OCB interface
> cards per vehicle. For each vehicle taking part in road traffic, one
> IEEE 802.11-OCB interface card could be fully allocated for Non IP
> safety-critical communication. Any other IEEE 802.11-OCB may be used
> for other type of traffic.

End of minor textual issues.

Alex

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 May 2017 09:33:49 -0400

> On May 18, 2017, at 5:39 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> OLD:

Alex:

Some RSUs will be routers, but others will not.  For example, an RSU that sends messages to vehicles about foggy conditions does not need to be a router.  I think the definition should allow both cases.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 May 2017 09:38:06 -0400

Alex:

I do not believe that the "(TM)" should appear in the name.  I suggest IEEE Std 802.11p-2010.

Also, it might help people locate the specification if we tell people that OCB was first specified in IEEE Std 802.11p-2010 as an amendment to IEEE Std 802.11-2007, and then it was incorporated into the base standard in …

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 May 2017 09:43:50 -0400

> At this time I do not modify this text.

IEEE 1609 does impose MAC address requirements.  Is this the right place to call that out?

Russ

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 18 May 2017 15:57:24 +0200

Dear Russ, Dear Alex,

Indeed, and so does ETSI ITS. So, we can keep what is there, and maybe add
something like: 

(…)While the 802.11-OCB standard does not specify anything particular with
respect to MAC addresses, higher layer stack architecture, such as IEEE 1609
and ETSI ITS does impose MAC requirements. Accordingly, similar requirements
might be expected or required when operating IPv6 over 802.11-OCB without
these architectures (…) 

Do we need to  define what we mean by ‘MAC requirements’? 

Best Regards,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday 18 May 2017 15:44
To: Alexandre Petrescu
Cc: [email-masked]
Subject: [ipwave] MAC Address minor textual issue

On May 18, 2017, at 5:39 AM, Alexandre Petrescu
<[email-masked]> wrote:

OLD:

End issue.

IEEE 1609 does impose MAC address requirements.  Is this the right place to
call that out?

Russ

---

From: François Simon <[email-masked]>
Date: Thu, 18 May 2017 10:47:19 -0400

Mr. Housley;

See comments in the text.

Fygs

From: its [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, May 18, 2017 9:44 AM
To: Alexandre Petrescu <[email-masked]>
Cc: [email-masked]
Subject: [ipwave] MAC Address minor textual issue

On May 18, 2017, at 5:39 AM, Alexandre Petrescu
<[email-masked] <mailto:[email-masked]> > wrote:

OLD:

[Fygs: if we are talking about privacy, I believed the statement is correct.
Other methods are used in IEEE 802.11 Security to support privacy.  This
function would not be expected to be in the MAC sub-layer]. 

[Fygs: This is correct.  IEEE 1609 recognize this fact and such does not
mandate the implementations to secure privacy – “whatever privacy services
are provided, there may be a legal right for appropriately authorized
parties to reverse that privacy for law enforcement or to ensure the correct
operation of the system. ‘].

End issue.

[Fygs: I do not think there is an “imposition” implied here.  IEEE 1609.0:
IEEE 1609 standards provide primitives to change local WAVE MAC addresses to
protect the privacy of  the device operator. The process by which a decision
is made to change the WAVE MAC address is not addressed in the IEEE 1609
standards. See 5.13.10 for further discussion.”]

---

From: John Kenney <[email-masked]>
Date: Thu, 18 May 2017 07:50:50 -0700

Hello All:

I do not agree with the statement that "there are strong privacy concerns".
I suggest changing "concerns" to "requirements".

I think stating that there are strong concerns conveys a sense of this
being a big unsolved problem. For the DSRC/ITS-G5 community this is not the
case. Privacy protection, including careful avoidance of PII in messages,
pseudonymous certificates, and frequent identifier randomization, has been
designed into DSRC/ITS-G5 from day 1.

The requirements are cross-layer and systemic, but also not universal for
OCB (e.g. RSUs are licensed for a site and do not need privacy protection),
so 802.11 would not have been the best place to address them. Stating that
they are not addressed in 802.11 sounds to me like it was an oversight or
omission. It was not.

I agree with noting that some standards already address privacy protection,
but I don't think it helps to list standards (like 802.11) that do not.

I hope these comments are helpful.

Best Regards,
John

On Thu, May 18, 2017 at 6:57 AM, Jérôme Härri <[email-masked]>
wrote:

> (…)While the 802.11-OCB standard does not specify anything particular
> with respect to MAC addresses, higher layer stack architecture, such as
> IEEE 1609 and ETSI ITS does impose MAC requirements. Accordingly, similar
> requirements might be expected or required when operating IPv6 over
> 802.11-OCB without these architectures (…)
>
>
>
> *From:* its [mailto:[email-masked]] *On Behalf Of *Russ Housley
> *Sent:* Thursday 18 May 2017 15:44
> *To:* Alexandre Petrescu
> *Cc:* [email-masked]
> *Subject:* [ipwave] MAC Address minor textual issue
>
>
>
>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
>

-- 
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644

---

From: Tony Li <[email-masked]>
Date: Thu, 18 May 2017 08:00:52 -0700

> On May 18, 2017, at 7:50 AM, John Kenney <[email-masked]> wrote:
> 
> I do not agree with the statement that "there are strong privacy concerns". I suggest changing "concerns" to "requirements".
> 
> I think stating that there are strong concerns conveys a sense of this being a big unsolved problem. For the DSRC/ITS-G5 community this is not the case. Privacy protection, including careful avoidance of PII in messages, pseudonymous certificates, and frequent identifier randomization, has been designed into DSRC/ITS-G5 from day 1.  

Well, I for one am still mystified by how the solution maps to IP.  DSRC can do all of this work, but if my IP addressing doesn’t change in synchrony, it seems like it all doesn’t help. And if the IP addresses do change in synchrony, you abort upper layer TCP connections.

So I’m still concerned.

Tony

---

From: François Simon <[email-masked]>
Date: Thu, 18 May 2017 11:05:21 -0400

Gentlemen;

Regardless if we are talking about MAC address changes or any other methods related to privacy, this would not be a data-plane MAC sub-layer function.

Fygs

From: its [mailto:[email-masked]] On Behalf Of John Kenney
Sent: Thursday, May 18, 2017 10:51 AM
To: Jérôme Härri <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; Russ Housley <[email-masked]>; [email-masked]
Subject: Re: [ipwave] MAC Address minor textual issue

Hello All:

The requirements are cross-layer and systemic, but also not universal for OCB (e.g. RSUs are licensed for a site and do not need privacy protection), so 802.11 would not have been the best place to address them. Stating that they are not addressed in 802.11 sounds to me like it was an oversight or omission. It was not.

I agree with noting that some standards already address privacy protection, but I don't think it helps to list standards (like 802.11) that do not.

Best Regards,

John

 

On Thu, May 18, 2017 at 6:57 AM, Jérôme Härri <[email-masked] <mailto:[email-masked]> > wrote:

Dear Russ, Dear Alex,

Indeed, and so does ETSI ITS. So, we can keep what is there, and maybe add something like: 

(…)While the 802.11-OCB standard does not specify anything particular with respect to MAC addresses, higher layer stack architecture, such as IEEE 1609 and ETSI ITS does impose MAC requirements. Accordingly, similar requirements might be expected or required when operating IPv6 over 802.11-OCB without these architectures (…) 

Best Regards,

Jérôme

From: its [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Russ Housley
Sent: Thursday 18 May 2017 15:44
To: Alexandre Petrescu
Cc: [email-masked] <mailto:[email-masked]> 
Subject: [ipwave] MAC Address minor textual issue

On May 18, 2017, at 5:39 AM, Alexandre Petrescu <[email-masked] <mailto:[email-masked]> > wrote:

OLD:

End issue.

Russ

_______________________________________________
its mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/its

-- 

John Kenney

465 Bernardo Avenue

Mountain View, CA 94043

---

From: John Kenney <[email-masked]>
Date: Thu, 18 May 2017 08:09:19 -0700

FYI, when the IEEE 1609 WG recently prepared a document that cited our
standards, we were told by IEEE to do it this way:

The NPRM references IEEE standards that have been superseded by these more
recently published IEEE standards: IEEE Std 802.11TM-2016, IEEE Std 1609.2
TM -2016, IEEE Std 1609.3 TM -2016, IEEE Std 1609.4 TM -2016, and IEEE Std
1609.12 TM -2016

Here is a quote from the IEEE-SA Standards Style Manual
<https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf>
(section 7):

"IEEE designations are trademarks of the IEEE and shall be identified as
trademarks (® or ™, as appropriate) at first citation of each designation
in the frontmatter and in the body of the draft."

So, if the text quoted by Alex is the first citation in the ID, I believe
it would be correct to include TM not only for the 11p amendment, but also
for 802.11-2007 since it is a different publication.

Best Regards,
John

On Thu, May 18, 2017 at 6:38 AM, Russ Housley <[email-masked]> wrote:

> Also, it might help people locate the specification if we tell people that
> OCB was first specified in IEEE Std 802.11p-2010 as an amendment to IEEE
> Std 802.11-2007, and then it was incorporated into the base standard in …
>
> Russ
>
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 May 2017 11:13:58 -0400

Thanks.  For providing this quote.  I think it makes searching difficult for the reader, but we should follow IEEE-SA guidelines.

Russ

> On May 18, 2017, at 11:09 AM, John Kenney <[email-masked]> wrote:
> 
> FYI, when the IEEE 1609 WG recently prepared a document that cited our standards, we were told by IEEE to do it this way:
> 
> The NPRM references IEEE standards that have been superseded by these more recently published IEEE standards: IEEE Std 802.11TM-2016, IEEE Std 1609.2 TM -2016, IEEE Std 1609.3 TM -2016, IEEE Std 1609.4 TM -2016, and IEEE Std 1609.12 TM -2016
> 
> Here is a quote from the IEEE-SA Standards Style Manual <https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf> (section 7):
> "IEEE designations are trademarks of the IEEE and shall be identified as trademarks (® or ™, as appropriate) at first citation of each designation in the frontmatter and in the body of the draft."
> 
> So, if the text quoted by Alex is the first citation in the ID, I believe it would be correct to include TM not only for the 11p amendment, but also for 802.11-2007 since it is a different publication.
> 
> Best Regards,
> John
> 
> 
> 
> On Thu, May 18, 2017 at 6:38 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On May 18, 2017, at 5:39 AM, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> OLD:
> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> 
> 
> -- 
> John Kenney

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 May 2017 11:22:23 -0400

> Well, I for one am still mystified by how the solution maps to IP.  DSRC can do all of this work, but if my IP addressing doesn’t change in synchrony, it seems like it all doesn’t help. And if the…

I agree that the IPv6 address needs to change whenever the MAC address changes.  This is not a problem for UDP traffic, but it can be a problem for TCP.  In my view, there is no privacy benefit to changing the MAC/IPv6 address while the vehicle is stationary, like in a garage overnight.  In fact, this is the time when long-lived TCP connections are extremely likely for actives like software update.  Is this a place we can add value with crisp recommendations?

Russ

---

From: John Kenney <[email-masked]>
Date: Thu, 18 May 2017 08:36:21 -0700

Hi Tony,

Frequent identifier changes are one component of the privacy protection
solution in DSRC. If IP is involved, I believe you are correct that IP
addressing would need to change in synchrony with other identifiers. That's
partly what I meant by "cross-layer and systemic." I don't know what the
technical challenges associated with that are, but I believe that is the
requirement where privacy needs to be protected.

You're right to have concerns, but these are technical concerns that stem
from privacy requirements, not privacy concerns. We have good solutions, so
I want to avoid saying there are "strong privacy concerns." We would not
deploy technology for which there were strong privacy concerns.

To use an analogy, it would be horrible if a plane crashed, but the people
flying on it need not have "strong concerns" that it will.  The plane was
designed, built, and maintained according to strong requirements to make
sure it doesn't crash.

Thanks,
John

On Thu, May 18, 2017 at 8:00 AM, Tony Li <[email-masked]> wrote:

> I do not agree with the statement that "there are strong privacy
> concerns". I suggest changing "concerns" to "requirements".
>
> Well, I for one am still mystified by how the solution maps to IP.  DSRC
> can do all of this work, but if my IP addressing doesn’t change in
> synchrony, it seems like it all doesn’t help. And if the IP addresses do
> change in synchrony, you abort upper layer TCP connections.
>
> So I’m still concerned.
>
> Tony
>
>

---

From: François Simon <[email-masked]>
Date: Thu, 18 May 2017 12:23:41 -0400

In the US, RSUs ARE NOT ROUTERS. There are logical boundaries between RSU
and functions accessing the infrastructure (when required):

FHWA Definition: 

“1.6. Roadside Units

DSRC enables communication between vehicles and roadside equipment, but does
not

generate data necessary to provide warnings and advisories from
infrastructure to drivers. To

support V2I applications, DSRC must be integrated with existing traffic
equipment, such as

Signal Controllers and backhaul connections to Traffic Management Centers
(TMCs). DSRC

devices that serve as the demarcation component between vehicles and other
mobile devices

and existing traffic equipment will be referred to DSRC Roadside Units (RSU)
in this document.”

RSU - A connected device that is only allowed to operate from a fixed
position

(which may in fact be a permanent installation or from temporary

equipment brought on-site for a period of time associated with an

incident, road construction, or other event). Some RSEs may have

connectivity to other nodes or the Internet.

From: its [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, May 18, 2017 9:34 AM
To: Alexandre Petrescu <[email-masked]>
Cc: [email-masked]
Subject: [ipwave] RSU minor textual issue

OLD:

End issue.

Alex:

Some RSUs will be routers, but others will not.  For example, an RSU that
sends messages to vehicles about foggy conditions does not need to be a
router.  I think the definition should allow both cases.

Russ

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 18 May 2017 11:11:56 -0700

Russ,

You said:

> Some RSUs will be routers, but others will not.  For example, an RSU
> that sends messages to vehicles about foggy conditions does not need
> to be a router.  I think the definition should allow both cases.> 

I think that a specific focus on RSU would make some sense.  Some
thoughts:

- router.  RSU would be a router.  plain/simple.  The wired internet on
its backside (terrestrial-WAN in my classroom terminology) would
certainly be made up of routable networks.  And the radio-WANs on the
front side would be routable network(s) too.  

- yes, but...  There are major differences, both qualitative and
quantitative between terrestrial-WANs and radio-WANs.  
     o terrestrial plumbing is largely made up of point-point links
(example, fiber optic strings between routers).  Radio-WANs are shared
media (with consequent need for MAC which is absent in point-point
stuff). 
     o capacity.  Radio-WANs are measured, on good days, in Mbit/sec
and that capacity is pro-rated across all stations on the net.  By
contrast, fiber links are routinely provisioned at 10Gbit/sec -- four
orders of magnitude more capacious (a capacity essentially infinite
compared to the radio-WAN).  This disparity will continue to grow over
time -- compare the potential of 1) DWDM advances and 2) more fibers to
the limitations of spectrum.   Multicast has far more payoff in radio-
WAN than in point-point plumbing.  Especially in a bandwidth-limited
radio-WAN.  
     o noise.  The radio-WAN will experience orders of magnitude more
bit error rate than the terrestrial-WAN.  This tends to influence
variables like packet size -- the noisier the environment the smaller
the packets, minimizing the expense per bit error.  
     Some of these limitations might indicate some layer 7 gateway
functions rather than the simple layer 3 forwarding that a router does.

- server functions.  RSU is ideally situated to provide some auxiliary
functions. And some are vital. DNS is a fairly obvious example.  DNS
lookups can consume a considerable amount of connection setup time so
colocating a caching DNS server at RSU strikes  me as cost-effective.
And as noted in last message, serving public keys would be required
somewhere in the internetwork; closer to the moving vehicle should be
better.
    Another server function that comes immediately to my mind is
differential GPS* (or differential Galileo if you are to be Euro and
eschew US GPS;-). An auxiliary function as a dGPS reference receiver
makes sense to me; the marginal cost is low.
    It'd make sense to mount cameras as peripherals to RSU, at least in
some situations -- your foggy conditions example.  This list is
flexible and open-ended; both functions to help automobile traffic and
functions to help traffic managers ashore.

Suggestion.  Would a standards-track RFC titled 'Requirements for
RoadSi
de Units' make sense?  Not unlike the old RFC1812

(*in a former life, I designed the differential GPS program that US
Coas
t Guard ran in maritime areas to provide integrity check and
improved
accuracy to raw GPS.  I can explain, ad nauseum, why this is a
good idea
and how it would work.  As we are discovering how fragile GPS
is, we may
see Loran reappear and differential Loran works too --
indeed that's
where we got the dGPS idea from.)

On Thu, 2017-05-18 at 09:33 -0400, Russ Housley wrote:

(*in a former life, I designed the differential GPS program that US
Coast Guard ran in maritime areas to provide integrity check and
improved accuracy to raw GPS.  I can explain, ad nauseum, why this is a
good idea and how it would work.  As we are discovering how fragile GPS
is, we may see Loran reappear and differential Loran works too --
indeed that's where we got the dGPS idea from.)

> Some RSUs will be routers, but others will not.  For example, an RSU
> that sends messages to vehicles about foggy conditions does not need
> to be a router.  I think the definition should allow both cases.
> 
> Russ
>

---

From: François Simon <[email-masked]>
Date: Thu, 18 May 2017 16:45:34 -0400

In the US, RSUs ARE NOT ROUTERS. There are logical boundaries between RSU
and devices accessing the infrastructure (when required):

 

OLD:

End issue.

Alex:

Russ

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 May 2017 18:54:27 +0300

Rex,

Le 18/05/2017 à 20:11, Rex Buddenberg a écrit :
[...]
> Road Side Units' make sense?  Not unlike the old RFC1812

I think it can make sense to have a separate document listing the 
requirements for Road-Sode Units.

I agree with you that some characteristics of IP RSUs are:
- there is huge difference between the radio interfaces and the wired
   interfaces situated on an RSU;
- some RSUs may provide Internet service like DNS, and other IP
   presence indication like RA or DHCP.
- some RSUs may provide application-layer services like POI broadcast,
   or charge spot information, or time info.
- some RSUs may connect to the Internet at large.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 May 2017 18:56:18 +0300

François,

Some RSUs, including in America, may need to be securely connected to 
the Internet.  Some not.

When connected to the Internet, and if they are not Routers, they may 
induce some inefficiencies, break the Internet model (like bidirectional 
reachability), and other risks; it depends how it is done.

There is now an updated RSU definition in the upcoming -03 draft.

Alex

Le 18/05/2017 à 22:45, François Simon a écrit :
> In the US, RSUs ARE NOT ROUTERS. There are logical boundaries between
> RSU and devices accessing the infrastructure (when required):
>
>
>
>
>
>
>
> *Sent:* Thursday, May 18, 2017 9:34 AM
> *To:* Alexandre Petrescu <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [ipwave] RSU minor textual issue
>
>
>
>
>
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>
>
>     OLD:
>
> that sends messages to vehicles about foggy conditions does not need to
> be a router.  I think the definition should allow both cases.
>
>
>
> Russ
>
>
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 May 2017 18:56:40 +0300

Russ,

I propose the following new definition.  It allows both cases:

>         RSU: Road Side Unit.  A computer equipped with at least one
>         IEEE 802.11 interface operated in OCB mode.  An RSU may be
>         connected to the Internet, and may be equipped with additional
>         wired or wireless network interfaces running IP.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 May 2017 18:57:16 +0300

Le 18/05/2017 à 18:23, François Simon a écrit :
> In the US, RSUs ARE NOT ROUTERS. There are logical boundaries
> between RSU and functions accessing the infrastructure (when
> required):
>
>
>
> FHWA Definition:
>
> /“1.6. Roadside Units/
>
> /DSRC enables communication between vehicles and roadside equipment,
> but does not/
>
> /generate data necessary to provide warnings and advisories from
> infrastructure to drivers. To/
>
> /support V2I applications, DSRC must be integrated with existing
> traffic equipment, such as/
>
> /Signal Controllers and backhaul connections to Traffic Management
> Centers (TMCs). DSRC/
>
> /devices that serve as the demarcation component between vehicles
> and other mobile devices/
>
> /and existing traffic equipment will be referred to DSRC Roadside
> Units (RSU) in this document.”/
>
> / /
>
> /RSU - A connected device that is only allowed to operate from a
> fixed position/
>
> /(which may in fact be a permanent installation or from temporary/
>
> /equipment brought on-site for a period of time associated with an/
>
> /incident, road construction, or other event). Some RSEs may have/
>
> /connectivity to other nodes or the Internet./

François - but this definition is not related to 802.11-OCB, right?  I 
may suggest that that document talks 802.11-OCB in the definition of an RSU.

Alex

>
>
>
>
>
>
>
> *From:* its [mailto:[email-masked]] *On Behalf Of *Russ
> Housley *Sent:* Thursday, May 18, 2017 9:34 AM *To:* Alexandre
> Petrescu <[email-masked]> *Cc:* [email-masked] *Subject:*
> [ipwave] RSU minor textual issue
>
>
>
>
>
> A comment was made stating that an RSU is not a router, and that an
> RSU may be connected to a router via an interface, e.g. Ethernet, to
> access the infrastructure if required.
>
> access the infrastructure and the Internet.  This is an important
> point when using the IP protocol - be connected.
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 May 2017 18:57:37 +0300

> concerns". I suggest changing "concerns" to "requirements".

Ok, changed to "requirements".

Alex

> being a big unsolved problem. For the DSRC/ITS-G5 community this is not
> the case. Privacy protection, including careful avoidance of PII in
> messages, pseudonymous certificates, and frequent identifier
> randomization, has been designed into DSRC/ITS-G5 from day 1.
>
> The requirements are cross-layer and systemic, but also not universal
> for OCB (e.g. RSUs are licensed for a site and do not need privacy
> protection), so 802.11 would not have been the best place to address
> them. Stating that they are not addressed in 802.11 sounds to me like it
> was an oversight or omission. It was not.
>
> I agree with noting that some standards already address privacy
> protection, but I don't think it helps to list standards (like 802.11)
> that do not.
>
> On Thu, May 18, 2017 at 6:57 AM, Jérôme Härri <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Dear Russ, Dear Alex,____
>
>     __ __
>
>     Indeed, and so does ETSI ITS. So, we can keep what is there, and
>     maybe add something like: ____
>
>     __ __
>
>     (…)While the 802.11-OCB standard does not specify anything
>     particular with respect to MAC addresses, higher layer stack
>     architecture, such as IEEE 1609 and ETSI ITS does impose MAC
>     requirements. Accordingly, similar requirements might be expected or
>     required when operating IPv6 over 802.11-OCB without these
>     architectures (…) ____
>
>     __ __
>
>     Do we need to  define what we mean by ‘MAC requirements’? ____
>
>     __ __
>
>     Best Regards,____
>
>     __ __
>
>     Jérôme____
>
>     __ __
>
>     __ __
>
>     __ __
>
>     *From:*its [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Russ Housley
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* [ipwave] MAC Address minor textual issue____
>
>     __ __
>
>     __ __
>
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:____
>
>         __ __
>
>         OLD:
>
>         ____
>
>         addresses____
>         End issue.____
>     __ __
>     IEEE 1609 does impose MAC address requirements.  Is this the right
>     place to call that out?____
>
>     __ __
>
>     Russ____
>
>     __ __
>
>
>     <https://www.ietf.org/mailman/listinfo/its>
>
>
>
>
> --
> John Kenney

---

From: William Whyte <[email-masked]>
Date: Tue, 30 May 2017 09:40:46 +1000

Hi Alex,

This doesn't cover the difference between an RSU and an OBU :-)

Maybe "a computer equipped with at least one IEEE 802.11 interface operated
in OCB mode, which is physically located in communications range of
vehicles but is not a vehicle device itself".

Cheers,

William

-- 

PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS:
[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 30 May 2017 17:29:47 +0300

Le 30/05/2017 à 08:08, Dick Roy a écrit :
> And when a police car with an “OBU” parks along the side of the road
> and “becomes an RSU” by broadcasting warning messages to oncoming
> vehicles

So we could "a computer equipped with at least one IEEE 802.11 interface
operated in OCB mode, which is physically located in communications
range of vehicles but is typically not a vehicle device itself"

(remark "typically").

> while the officer(s) are out of the car perusing the scene, then
> what. Point is, OBUs and RSUs are not devices … they are roles that
> real devices can take on.

When we discuss handovers we need this RSU term because of being fixed.
  The handover nature is such a mobile device is 'handed
over' from one RSU to another, likely to be fixed.

But but.

Now I realize we moved the handover discussion out of this draft, so 
maybe the "RSU" term is not that important.  It no longer appears 
throughout the draft...

> You might want to look at ISO 21217 for definitions of all these
> things, or not.  It has been around for almost a decade however:^))))

Will have to check.

Maybe we need another term instead of RSU, that is just a computer 
running at least one interface in OCB mode, and that implements what 
this IPv6-over-OCB draft says.

Alex

>
>
>
>
> Furthermore, tying the definition of these objects to a particular
> communication interface (IEEE802.11 in OCB mode) really makes no
> sense. You would be the only standards group to take such a stance,
> and frankly, the communication interface is out of scope for the IETF
> and I would recommend against it.
>
>
>
> My two euro cents …
>
>
>
> RR
>
>
>
> ------------------------------------------------------------------------
>
>  *From:*its [mailto:[email-masked]] *On Behalf Of *William
> Whyte *Sent:* Monday, May 29, 2017 4:41 PM *To:* Alexandre Petrescu
> *Cc:* Russ Housley; [email-masked] *Subject:* Re: [ipwave] RSU minor
> textual issue
>
>
>
> Hi Alex,
>
>
>
>
> RSU: Road Side Unit.  A computer equipped with at least one IEEE
> 802.11 interface operated in OCB mode.  An RSU may be connected to
> the Internet, and may be equipped with additional wired or wireless
> network interfaces running IP.
>
>
>
> Maybe "a computer equipped with at least one IEEE 802.11 interface
> operated in OCB mode, which is physically located in communications
> range of vehicles but is not a vehicle device itself".
>
>
>
> Cheers,
>
>
>
> William
>
>
>
> On Tue, May 30, 2017 at 1:56 AM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]
> <mailto:[email-masked]>>> wrote:
>
> OLD:
>
> RSU: Road Side Unit.  A computer equipped with at least one IEEE
> 802.11 interface operated in OCB mode.  An RSU may be connected to
> the Internet, and may be equipped with additional wired or wireless
> network interfaces running IP.
>
>
> Alex
>
>
>
>
> Russ
>
>
> [email-masked] <mailto:[email-masked]>
>

---

From: François Simon <[email-masked]>
Date: Wed, 31 May 2017 11:11:48 -0400

Three definitions related to RSx in the U.S.:

FCC (CFR 90.7 - 2010):

*	RSU: “Roadside unit (RSU). A Roadside Unit is a DSRC transceiver that is mounted along a road or pedestrian passageway. An RSU may also be mounted on a vehicle or is hand carried, but it may only operate when the vehicle or hand-carried unit is stationary. Furthermore, an RSU operating under this part is restricted to the location where it is licensed to operate. However, portable or hand-held RSUs are permitted to operate where they do not interfere with a site-licensed operation. A RSU broadcasts data to OBUs or exchanges data with OBUs in its communications zone. An RSU also provides channel assignments and operating instructions to OBUs in its communications zone, when required”.

FHWA ( Vehicle to Infrastructure Deployment Guidance and Products – 2015):

*	RSU: “A connected device that is only allowed to operate from a fixed position (which may in fact be a permanent installation or from temporary equipment brought on-site for a period of time associated with an incident, road construction, or other event). Some RSEs may have connectivity to other nodes or the Internet.”;

*	RSE: “Term used to describe the compliment of equipment to be located at the roadside; the RSE will prepare and transmit messages to the vehicles and receive messages from the vehicles for the purpose of supporting the V2I applications. This is intended to include the DSRC radio, traffic signal controller where appropriate, interface to the backhaul communications network necessary to support the applications, and support such functions as data security, encryption, buffering, and message processing. It may also be referred to as the 2015 FHWA Vehicle to Infrastructure Deployment Guidance and Products HANDOUT September 12, 2014 (Rev. 1) Page 7 Term Description roadside ITS station. When speaking of the DSRC radio alone, the correct term is RSU.”.

Sincerely,

Francois Simon

 

From: its [mailto:[email-masked]] On Behalf Of William Whyte
Sent: Monday, May 29, 2017 7:41 PM
To: Alexandre Petrescu <[email-masked]>
Cc: Russ Housley <[email-masked]>; [email-masked]
Subject: Re: [ipwave] RSU minor textual issue

Hi Alex,

Maybe "a computer equipped with at least one IEEE 802.11 interface operated in OCB mode, which is physically located in communications range of vehicles but is not a vehicle device itself".

Cheers,

William

On Tue, May 30, 2017 at 1:56 AM, Alexandre Petrescu <[email-masked] <mailto:[email-masked]> > wrote:

On May 18, 2017, at 5:39 AM, Alexandre Petrescu
<[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>
wrote:

OLD:

End issue.

Alex:

Russ,

Alex

Russ

 

-- 

PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: [email-masked] <mailto:[email-masked]>