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

[Alexandre Petrescu <[e-mail]>]

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