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

[NABIL BENAMAR <[e-mail]>]

Thank you for comments Abdussalam!

Bravo on being able to comment on this draft under such circumstances!

On Fri, Apr 12, 2019, 10:06 Abdussalam Baryun <[e-mail]>
wrote:

> Hi Pascal and Alexandre,
>
> Thanks for your review and thanks to authors that made many changes from
> draft -34 to 38.
>
> I reply to both and sorry for the not able to always be on reply quickly
> because of sadly war in my city Tripoli. My comments/reply below.
>
> To: WG AD> I think any reviewer MUST read the IETF WG charter before
> reviewing any of their draft. I hope that can be a rule/best-practice in
> IETF in future.
>
>
> On Fri, Apr 12, 2019 at 1:28 AM Pascal Thubert (pthubert) <
> [e-mail]> wrote:
>
> > Sadly my comments are far from resolved, Alex.
> >
>
> I reply to your comments below on Draft-34 but please note that this draft
> is now draft-38, and authors did do many efforts. So it may need a new
> clarifications.
>
>
> >
> > You still refine a layer-2 portal (a fully IEEE concept) on your own
> terms
> > using BCP 14. I cannot agree with trying to publish something that will
> be
> > a direct conflict.
> >
> > You still have a definition of a subnet which is widely confused with
> that
> > of a link. You need to clarify for yourself what those concepts are and
> > then you can start writing text on how to apply them on OCB. Your
> question
> > on multiple interfaces shows there’s a long way to go.
> >
>
> Don't understand your point (where is confusion to be solved!), if it is
> not defined then please provide text to define the Link. In my opinion the
> Link is known by the Link layer IEEE802.11-OCB. So let us focus discussion
> on the IETF IPWAVE WG charter's first objective related to this link
> IEEE802.11-OCB and not IEEE802.11 other modes nor IEEE802.15 nor any other
> wireless Link (we are not doing per IETF-charter general wireless network
> we are doing only one Wireless Link IEEE802.11-OCB which is different than
> other IEEE802.11).
>
>
> > In that path you will need to learn about full mesh vs. NBMA, broadcast
> > domains, route over (routers) vs mesh under (L3 switches), connected
> > dominating sets and transitive properties.
>
>
> Also some IETF reviewers of our draft need to learn about IPWAVE.
> In my opinion in this IETF WG we are not doing Full Mesh, also not Routing,
> please look at the IETF IPWAVE WG charter, which does not mention that.
> Please note that this WG charter does mention Carefully that this WG is
> working on special Use Cases (ITS is a special case not like general work
> of broadcast domains and connected systems).
>
>
> > Once you get there you’ll realize that the number of interfaces doesn’t
> > matter long as you have at least one, that your text on subnet definition
> > doesn’t work and you may even recommend RFC 8505, who knows.
> >
>
> The number of interfaces does not matter as long as there is a connection.
> If the text does not work then please mention why,
>
> >
> > Also you’ll need to differentiate architecture and implementation so you
> > avoid spreading misconceptions like your issues on bridging .11 and .3.
> The
> > portal works from the architecture standpoint. The implementation you
> > played with may have difficulties.
> >
>
> You need to know the IP-WAVE architecture which I think you confuse about
> because you want to make a general wireless network architecture. This
> IPWAVE WG is not doing General wireless network architecture. Furthermore,
> that misconceptions you referred to is not misconception if you look deep
> in the use cases of IPWAVE. The bridging is important because in IPWAVE
> cases most important communications (out-board not in board as you want to
> include WPAN) is between RSU and Vehicle, which is important in this draft.
>
> more replays/comments below,
>
>
> > Cheers
> >
> > Pascal
> >
> >
> >
> > Regards,
> >
> > Pascal
> >
> > > Le 11 avr. 2019 à 22:00, Alexandre Petrescu <
> > [e-mail]> a écrit :
> > >
> > > Pascal,
> > >
> > > I believe all issues you raised are solved in version -38.
> >
>
> ok
>
>
> > >
> > > The editorial changes about text coherency are solved.
> >
> ok
>
>
> > >
> > > The ND text was modified, and an annex was added containing your own
> > text, but with removal of RECOMMENDED of your preferred RFC, replaced
> with
> > some lower case qualifiers instead.
> > >
> > > The fe80::/10 word was removed.
> > >
> > > Alex
> > >
> > >> Le 04/03/2019 à 12:24, Pascal Thubert a écrit :
> > >> 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 responded to that before, ietf can define in any rfc what is important to
> it in any architecture layer it likes. This WG is doing the IP-WAVE
> architecture.
>
>
> > The use of IPv6 ND requires a lot more
> > >> thoughts, recommendation to use 6LoWPAN ND.
>
>
> It was examined and used for WPAN not IPWAVE, in one other adopted draft in
> our WG ware recommending different ND also,
>
>
> > The definition of a subnet is
> > >> unclear.
>
>
> Ok, the subnet can be defined without discussing networking, we are
> considering IP communication between two nodes only, for more than two or
> multihop can be discussed in another draft.
>
>
> > It seems that RSUs would have prefixes but that is not discussed.
> >
> ok
>
> > >> 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.
> >
>
> We are not doing 802.11 it is different mode and different communication
> than OCB.
>
>
> > >> “
> > >> Is this doc scoped to OCB or 802.11 in general?
>
>
> Our IETF WG is Scoped to OCB, Please read about WG charter before review
> any draft for any WG in IETF.
>
>
> > 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?
>
>
> it is defined by IEEE, but we need to add our views and definition while
> doing IP over, any user would like to know what both IEEE and IETF say
> about such technology (I would always like to know as a user).
>
>
>
> > 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 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?
> >
>
> Yes it is defined by IEEE, they are different.
>
>
> > >> 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 ...'
> > >> different things? Why define both?
> > >> "   An 'adaptation' layer is inserted between a MAC layer and the
> > >>    Networking layer.  This is used to transform some parameters
> between
> > >>    their form expected by the IP stack and the form provided by the
> MAC
> > >>    layer.
> > >> "
> > >> Is this different from what an AP does when it bridges Wi-Fi to
> > Ethernet? Is
> > >> this IETF business?
> >
>
> You need to learn about IPWAVE. and Yes it is different, WiFi is different
> environment from IEEE802.11-OCB, we are doing High Speed Communication that
> WiFi cannot work and does not do, the Link data rate vs transmitted power
> of WiFi is not like IEEE802.11-OCB, and different service mode.
>
>
> > >> "
> > >>    The Receiver and Transmitter Address fields in the 802.11 header
> MUST
> > >>    contain the same values as the Destination and the Source Address
> > >>    fields in the Ethernet II Header, respectively.
> > >> "
> > >> Same,  this is IEEE game isn't it?
> > >> "
> > >> Solutions for these problems SHOULD
> > >>    consider the OCB mode of operation.
> > >> "
> > >> This is not specific enough to be actionable. I suggest to remove this
> > sentence.
> >
>
> Why? The most important issue is that IPWAVE is under this special mode OCB