Subject: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-18

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 21 Feb 2018 19:00:37 +0100

Hi,

I've reviewed the latest version of the draft (-18). I have the
following comments:

- Section 4.1:

   If IPv6 packets of size larger than
   the MTU are sent on an 802.11-OCB interface card then the IP stack
   MUST fragment.  In case there are IPv6 fragments, the subfield
   "Fragment number" within the field "Sequence control" of the 802.11
   Data header containing the IPv6 fragment is increased by the MAC
   layer.

I think this has to be removed. The first sentence is obvious (if a
packet is larger than the MTU, it has to be fragmented), and the second
we have had extensive discussion on it on the mailing list. I also
believe that this would be a layer violation.

- Section 4.1:

   Non-IP packets such as WAVE Short Message Protocol (WSMP) can be
   delivered on 802.11-OCB links.  Specifications of these packets are
   out of scope of this document, and do not impose any limit on the
MTU
   size, allowing an arbitrary number of 'containers'.  Non-IP packets
   such as ETSI GeoNetworking packets have an MTU of 1492 bytes.  The
   operation of IPv6 over GeoNetworking is specified at
   [ETSI-IPv6-GeoNetworking].

I think this text can be removed, as it is about non-IP packets and
this document is about IPv6-over-OCB. I tend to prefer to avoid
unnecessary text in normative documents.

- Section 4.2:

   1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1
      is the binary representation of the EtherType value 0x86DD.

Same comment as before. I think this has to be removed.

- Section 4.2.1:

   Additionally, the Ethernet Adaptation Layer performs operations in
   relation to IP fragmentation and MTU.  One of these operations is
   briefly described in Section 4.1.

Please, remove. The adaptation layer does not perform any fragmentation
related operation.

- Section 4.3:

Additionally, if stable identifiers are
   needed, it is recommended to follow the Recommendation on Stable
IPv6
   Interface Identifiers [RFC8064].

Do we want to make the "recommended" there normative?

- Section 4.4 and 4.4.1: I wonder if we want to change the writing so
it is actually normative. For example:

CURRENT: 

   For unicast as for multicast, there is no change from the unicast
and
   multicast address mapping format of Ethernet interfaces, as defined
   by sections 6 and 7 of [RFC2464].

PROPOSED:

   Unicast and multicast address mapping MUST follow the procedures
specified for Ethernet interfaces in sections 6 and 7 of [RFC2464].

- Section 4.6:

   An addressing model involves several types of addresses, like
   Globally-unique Addresses (GUA), Link-Local Addresses (LL) and
Unique
   Local Addresses (ULA).  The subnet structure in 'ad-hoc' networks
may
   have characteristics that lead to difficulty of using GUAs derived
   from a received prefix, but the LL addresses may be easier to use
   since the prefix is constant.

Please, remove, this text is not needed.

Thanks,

Carlos

---

From: Alexandre PETRESCU <[email-masked]>
Date: Thu, 22 Feb 2018 13:24:27 +0100

--
Alexandre Petrescu
[email-masked], tél 0169089223

> unnecessary text in normative documents.

Agreed.

> - Section 4.2:

Agreed.

> Please, remove. The adaptation layer does not perform any fragmentation

Agreed.

> Do we want to make the "recommended" there normative?

Yes, RECOMMENDED.

> specified for Ethernet interfaces in sections 6 and 7 of [RFC2464].

Agreed.

> Please, remove, this text is not needed.

Agreed.

Alex

---

From: Alexandre PETRESCU <[email-masked]>
Date: Thu, 22 Feb 2018 13:39:25 +0100

Agreed.

Agreed.

Agreed.

Yes, RECOMMENDED.

Agreed.

Agreed.

Alex