Subject: [ipwave] Comments on the draft

From: Michelle Wetterwald <[email-masked]>
Date: Sun, 8 Oct 2017 18:10:21 +0200

Hi Alex, all

I had performed a review of the draft-08 but was late for uploading it. In
any case, it looks like most of my comments still apply, so I am sending
them to you (applied to the pdf version of the draft).
My main comments are on the terminology (OBU, OBRU, RSU, RSRU), which I
believe is not fully consistent across the current draft and may generate
confusion for new comers.
I would question that an OBU must have at least 2 interfaces, one of them
being 802.11-OCB. This is fine for the OBRU though. You may want to
introduce both of them in the list. The same applies for an RSU and an
RSRU, where the relationship between RSU and RSRU would make the
definitions clearer.
Other comments, including the use of SHALL and MUST in former annex C, now
annex F of draft-09, can be found in the file attached.

Best regards,
-- 
Michelle Wetterwald
[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 Oct 2017 13:11:15 +0200

Michelle,

Within your review, you are asking to revise this sentence.  FYI it was
introduced in -05 following comments from either Sandra, Sri, Russ or
Mr. Simon.  I cant figure who precisely proposed it and for what reason,
or maybe it was simply me writing under influence of comments from Sri
about link structure.

> The 802.11-OCB links form and terminate; nodes connected to these 
> links peer, and discover each other; the nodes are mobile. However, 
> the precise description of how links discover each other, peer and 
> manage mobility is not given in this document.

If you think it needs to be revised, what would you like the new phrase
to be?

 From my side, I am ok with it as it reads now.  Because it expresses
that there may be some additional mechanisms involved in forming links
(like in Ethernet there are VLANs) yet it does not describe them (like
in Ethernet RFC2460 there is no VLAN description).

Alex

Le 08/10/2017 à 18:10, Michelle Wetterwald a écrit :
> Hi Alex, all
> 
> I had performed a review of the draft-08 but was late for uploading
> it. In any case, it looks like most of my comments still apply, so I
> am sending them to you (applied to the pdf version of the draft). My
> main comments are on the terminology (OBU, OBRU, RSU, RSRU), which I
>  believe is not fully consistent across the current draft and may 
> generate confusion for new comers. I would question that an OBU must
> have at least 2 interfaces, one of them being 802.11-OCB. This is
> fine for the OBRU though. You may want to introduce both of them in
> the list. The same applies for an RSU and an RSRU, where the
> relationship between RSU and RSRU would make the definitions
> clearer. Other comments, including the use of SHALL and MUST in
> former annex C, now annex F of draft-09, can be found in the file
> attached.
> 
> Best regards, -- Michelle Wetterwald [email-masked]
> <mailto:[email-masked]>
> 
> 
> _______________________________________________ its mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 13 Oct 2017 16:06:25 +0200

[Michelle?  What do you think?  This issue is blocking me from advancing].

Michelle,

Alex

> [email-masked] https://www.ietf.org/mailman/listinfo/its

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

---

From: Michelle Wetterwald <[email-masked]>
Date: Mon, 16 Oct 2017 15:23:53 +0200

Hi Alex,

Last week at ETSI ITS has been quite busy, so I apologize for the delay of
my answer.

The sentence

"The 802.11-OCB links form and terminate; nodes connected to these links
peer, and discover each other; the nodes are mobile."

is correct. However, it is quite minimal. Your explanation below clearly
improves the reading.
Please take my comment as a suggestion to improve readability of the text.

Best, Michelle

2017-10-13 16:06 GMT+02:00 Alexandre Petrescu <[email-masked]>
:

> The 802.11-OCB links form and terminate; nodes connected to these links
>> peer, and discover each other; the nodes are mobile. However, the precise
>> description of how links discover each other, peer and manage mobility is
>> not given in this document.
>>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 17 Oct 2017 12:33:22 +0200

Le 17/10/2017 à 00:23, Dick Roy a écrit :
> ------------------------------------------------------------------------
>
>  *From:*its [mailto:[email-masked]] *On Behalf Of *Michelle
> Wetterwald *Sent:* Monday, October 16, 2017 6:24 AM *To:* Alexandre
> Petrescu *Cc:* [email-masked] *Subject:* Re: [ipwave] Comments on the
> draft - links "form and terminate" paragraph
> 
> Hi Alex,
> 
> Last week at ETSI ITS has been quite busy, so I apologize for the
> delay of my answer.
> 
> The sentence
> 
> "The 802.11-OCB links form and terminate; nodes connected to these
> links peer, and discover each other; the nodes are mobile."
> 
> is correct.
> 
> */[RR] The “correctness” of this sentence is completely dependent
> upon how you define “form”, “peer”, “terminate”, and “discover”.  The
> truth is, there is no layer 2 protocol that does any of this in the
> OCB-mode of 802.11.  There are no “here I am” messages with which to
> do discovery, there are NO “ready to send” or “clear to send”
> messages for “peering”, there are no “close” messages to “terminate”
> anything, and there are no “ping” messages either.  In short, there
> are NO L2 management messages that one would normally associate with
> “link establishment, usage, and termination”.

Agreed.

> A node is completely unreachable unless it “announces” itself via a
> data-plane broadcast message sent from some application, and then,
> only those nodes receiving the broadcast know of the node’s presence.

The specification of the mechanism they used to form - a node
'announcing' self via a data-plane broadcast - is out of the scope of
this document.

> Remember, in the RF environments we are considering, the hidden node
> issue is real. /*

The hidden terminal problem is illustrated in Figure 2 of the expired 
draft-ietf-intarea-adhoc-wireless-com-02

The problem applies in OCB mode and in non-OCB ('inside'?CB) mode.

If you want we can refer to that draft in our section "Subnet 
Structure".  If not, not.

Alex

> 
> *//*
> 
> *//*
> 
> However, it is quite minimal. Your explanation below clearly improves
>  the reading.
> 
> 2017-10-13 16:06 GMT+02:00 Alexandre Petrescu 
> <[email-masked]
> <mailto:[email-masked]>>:
> 
> Within your review, you are asking to revise this sentence.  FYI it
> was introduced in -05 following comments from either Sandra, Sri,
> Russ or Mr. Simon.  I cant figure who precisely proposed it and for
> what reason, or maybe it was simply me writing under influence of
> comments from Sri about link structure.
> 
> If you think it needs to be revised, what would you like the new
> phrase to be?
> 
> that there may be some additional mechanisms involved in forming
> links (like in Ethernet there are VLANs) yet it does not describe
> them (like in Ethernet RFC2460 there is no VLAN description).
> 
> Alex
> 
> relationship between RSU and RSRU would make the definitions clearer.
> Other comments, including the use of SHALL and MUST in former annex
> C, now annex F of draft-09, can be found in the file attached.
> 
> <mailto:[email-masked] 
> <mailto:[email-masked]>>
> 
> 
> [email-masked] <mailto:[email-masked]> 
> <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> [email-masked] <mailto:[email-masked]> 
> <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> 
> 
> --
> 
> Michelle Wetterwald
> 
> [email-masked] <mailto:[email-masked]>
>