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

Hi Alex,

Apologies for my belated reply.

On Tue, 2018-12-04 at 15:55 +0100, Alexandre Petrescu wrote:
> Hi IPWAVErs,
> 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
> meeting.

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

> Alex
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its