Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

[Abdussalam Baryun <[e-mail]>]

On Mon, Mar 4, 2019 at 1:25 PM Pascal Thubert <[e-mail]> wrote:

> Reviewer: Pascal Thubert
> Review result: Not Ready
>
> Reviewer: Pascal Thubert
> Review result: Not ready. Need to clarify IEEE relationship, IOW which SDO
> defines the use of L2 fields, what this spec enforces vs. recognizes as
> being
> used that way based on IEEE work.


I think the IETF/IEEE already knows there relationships/business, this
issue is not related to the draft objectives. When the ITS is using
Internet then YES this WG in IETF is to define such technology for
Internet. IEEE is not doing definitions for Internet but we are, and we
tell the world what should be in L2 and even L1 if we need, also IEEE can
define what is in any layer if needed by their business.


> The use of IPv6 ND requires a lot more
> thoughts, recommendation to use 6LoWPAN ND.


Why you recommend that ? I think it is not needed but can be in separate
draft.


> The definition of a subnet is
> unclear.


the subnet is 80211ocb it is clear.

It seems that RSUs would have prefixes but that is not discussed.
>
> I am an assigned INT and IOT directorates reviewer for <
> draft-ietf-ipwave-ipv6-over-80211ocb-34 >. These comments were written
> primarily for the benefit of the Internet Area Directors. Document editors
> and
> shepherd(s) should treat these comments just like they would treat comments
> from any other IETF contributors and resolve them along with any other Last
> Call comments that have been received. For more details on the INT
> Directorate,
> see https://datatracker.ietf.org/group/intdir/about/
>
> Majors issues
> -----------------
>
> “
>
> o  Exceptions due to different operation of IPv6 network layer on
>       802.11 than on Ethernet.
>
> “
> Is this doc scoped to OCB or 802.11 in general?


scoped for 802.11p which we are doing 80211ocb

Is there an expectation that an
> implementer of IPv6 over Wi-Fi refers to this doc? Spelled as above, it
> seems
> that you are defining the LLC. Figure 1 shows the proposed adaptation
> layer as
> IEEE LLC work. Who defines those fields, IETF or IEEE, or mixed? Who
> defines
> their use? If this spec defines a new LLC header (vs. how to use an IEEE
> field)
>  then it should be very clear, and the newly defined fields should be
> isolated
> from IEEE fields.
>

The definition is always both define, we are different Organisations/WGs,
so no doubt that both define, and this document agrees to use the IEEE
definition, but in future if we need to change definitions for some
reason we can amend this work (with mentioning our reasons for best
practice on Internet use) and the IEEE can amend and follow. Now we used
IEEE definitions and work in LLC.


>
> "
>    The IPv6 packet transmitted on 802.11-OCB MUST be immediately
>    preceded by a Logical Link Control (LLC) header and an 802.11 header.
>
> "
> Is there anything new or specific to OCB vs. classical 802.11 operations?
> If/when this is echoing the IEEE specs then this text should not use
> uppercase
> but say something like: 'Per IEEE Std 802.11, the IPv6 packet transmitted
> on
> 802.11-OCB is immediately  preceded by a Logical Link Control (LLC) header
> and
> an 802.11 header ...'
>

I don't support to use Per IEEE Std (did any WG use such in RFCs?), even if
we may be echoing, why we don't use what we believe is right in our
organisation and we can change in future when we need?

AB