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 <abdussalambaryun@xxxxxxxxx> 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) <
pthubert@xxxxxxxxx> 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 <
> alexandre.petrescu@xxxxxxxxx> 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
