Subject: [ipwave] Why is IP/OCB draft not advancing?

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Dec 2018 15:55:33 +0100

Hi IPWAVErs,

Why is the IP/OCB draft not advancing?

We have addressed all comments from 6MAN WG and from last IPWAVE WG meeting.

Alex

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 5 Dec 2018 00:03:43 +0900

Alex and IPWAVE WG,
I support the advance of IP/OCB draft because
I think that all comments from 6MAN WG and
the last IPWAVE WG meeting are reflected well on the latest revision.

Thanks.

Best Regards,
Paul

On Tue, Dec 4, 2018 at 11:55 PM Alexandre Petrescu <
[email-masked]> wrote:

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

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 11 Dec 2018 09:26:39 +0100

Hi Alex,

Apologies for my belated reply.

> Why is the IP/OCB draft not advancing?

Because we need time to review the draft. As you saw, there were
significant traffic discussing key points of the draft after your e-
mail.

> We have addressed all comments from 6MAN WG and from last IPWAVE WG

I've reviewed the document and I have some additional comments. Once
they have been discussed in the mailing list and closed, I'll proceed
to issue a 1-week WGLC. After that we can ask our AD to request a new
6MAN review.

Here are my comments:

- The draft talks about "handover behaviour". I think this is not the
right terminology. "Handovers" or better "mobility management" is
certainly not in the scope of IP-over-foo, but it is of RFC6275 and
related documents. I suggest to rather talk about "movement detection",
which is something protocols such as RFC6275 describe how to do relying
on IPv6 ND procedures.

- The sentence "The Security Considerations section describes security
and privacy aspects of 802.11-OCB." is a bit redundant, as this is
somehow mentioned in the previous bullet. If you want to reinforce this
point, move at least the text to the bullet before.

- I think the sentence "The mechanisms for forming and terminating,
discovering, peering and mobility management for 802.11-OCB links" is
not clear. Link setup and termination is not something the IP layer
should be concerned about, it an L2 task. Mobility management is
already left out of the scope before in the doc. So I think this
sentence should be removed.

- The content of Section 4.1 should be moved to a different part of the
document. First, I think it's better to deal with MTU and frame format
aspects in Section 4. Then, I think the pseudonym part needs some
previous context and it is probably better if included when discussing
addressing or in the security considerations part.

- Should the "should" in "These issues may be
   exacerbated in OCB mode.  Solutions for these problems should
   consider the OCB mode of operation." be "SHOULD"?

- I think the paragraph "A valid MAC address includes a unique
identifier pointing to a company together with its postal address, and
a unique number within that company MAC space (see the oui.txt
file).  The calculation operation of the MAC address back from a given
meaningful Interface Identifier is straightforward ([RFC2464], section
4).  The Interface  Identifier is part of an IPv6 address that is
stored in IPv6 packets." should be removed, as this includes well known
information that is not specific to -OCB. I also find weird mentioning
an oui.txt file in the text.

- The sentence "The Neighbor Discovery protocol (ND) [RFC4861] is used
over 802.11-OCB links.", I know it's been discussed heavily, but as is,
I think it's not good enough. The document is "IPv6-over-80211-OCB",
so, shouldn't the document normatively state something about ND? What
would an implementer do when reading that sentence?

Thanks!

Carlos

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Dec 2018 13:15:46 +0100

Le 11/12/2018 à 09:26, Carlos Jesús Bernardos Cano a écrit :
[...]
> which is something protocols such as RFC6275 describe how to do relying

Terms substituted, hoping that's what's requested.

> point, move at least the text to the bullet before.

Indeed redundant, so removed.
> sentence should be removed.

Makes sense.

> addressing or in the security considerations part.

True, it's good to start Section 4 with MTU and frame format.  So I 
moved the pseudonym part to the end of the Security Considerations 
section. (and clarified 'concurrently').

>     consider the OCB mode of operation." be "SHOULD"?

YEs.
I take advantage of this remark to also refer to WG item 
draft-ietf-mboned-ieee802-mcast-problems.

> an oui.txt file in the text.

I agree the MAC presence in IPv6 address as well as oui.txt constitute 
well-known information.  So I removed that part of text.  But indulged 
further clarification of Company ID exposure on public roads.

> would an implementer do when reading that sentence?

It's a MUST.  I added it.

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 17 Dec 2018 17:26:18 +0100

Hi Alex,

Thanks for your updates. I'm fine with them, so we have started a 1-
week WGLC to check that the WG is fine (as the content has chaged
significantly since the last WGLC). We have requested our AD to ask for
a new 6man review.

We'll keep you posted.

Thanks,

Carlos