Subject: [ipwave] correction

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 18 Sep 2017 14:00:28 +0200

I know that some WG members already suggested that "IPv6 packets should not be sent on the channels reserved for safety".

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Sep 2017 13:44:33 +0200

So, should I remove this paragraph:

>    o  Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB,
>       as opposed to IPv6 not being prohibited on any channel on which
>       802.11a/b/g/n runs:
> 
>       *  Some channels are reserved for safety communications; the IPv6
>          packets should not be sent on these channels.
> 
>       *  At the time of writing, the prohibition is explicit at higher
>          layer protocols providing services to the application; these
>          higher layer protocols are specified in IEEE 1609 documents,
>          i.e. the "WAVE" stack.
> 
>       *  National or regional specifications and regulations specify the
>          use of different channels; these regulations must be followed.

Alex

Le 19/09/2017 à 00:06, Dick Roy a écrit :
> Alex et.al.,
> 
> The simple fact is that how physical resources are to be used (aka "what
> apps are allowed on which channels") is a topic/issue way outside the scope
> of the IETF's work.  I highly recommend you make no statements on such
> issues nor make any recommendations along those lines.  Stick to IPv6
> networking and the network (and transport) layer functions required to
> implement it.  Leave channel allocation issues to the appropriate entities
> ... the regulators and system integrators.
> 
> MTC ...
> 
> RR
> 
> -----Original Message-----
> From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Monday, September 18, 2017 5:00 AM
> To: [email-masked]
> Subject: [ipwave] correction
> 
> I know that some WG members already suggested that "IPv6 packets should not
> be sent on the channels reserved for safety".
> 
> Alex
> 
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Sep 2017 20:46:45 +0200

Le 19/09/2017 à 19:10, Dick Roy a écrit :
> Yes, by all means.  All of it is 1) subject to change, 2) way out of scope
> for the IETF, and 3) totally irrelevant to the planned effort.

Agreed.

Alex

> Sent: Tuesday, September 19, 2017 4:45 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [ipwave] correction
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 20 Sep 2017 18:04:39 +0200

Hi Alex and the authors of other emails included,

My comments and discussion below

>>          use of different channels; these regulations must be followed.

you can remove but not sure did WG agree on that,

>> of the IETF's work.
I don't agree with Dick Roy. The problem with the past IPv4 protocols is
just that approach, we are in the future of IPv6, we need to look into
future systems and protocols that use IPv6.

> I highly recommend you make no statements on such
>> issues nor make any recommendations along those lines.
>
>
I think that is clean idea for now, however, we may need to make few
conditions.

> Stick to IPv6
The problem is that our system is not always TCP/IP model layers that was
IPv4 systems. IMO  IPWAVE systems are more complicated and have cross
layers (I think we should not stick to one system layer model and separate
IPv6 networking).

>From your statement you want us to stick to old approach of system design,
but we need new for our protocols of IPv6. So I recommend we don't stick to
old IP networking because IPv6 is new and is future work. However, IMHO if
this WG takes your approach we may need in future to change our
specifications.

Nothing is wrong with channel allocation in IETF we should be able to do
that as well. We can regulate any of our protocols within any channel we
agree on (if not please tell me what restricts us or what RFC stops us from
such regulation) because the packet is our protocol. No one can own the
channel but we own the IPv6 specification, and we can say which is
recommended (usually for the best benefit of users not regulators).

> for the IETF, and 3) totally irrelevant to the planned effort.

1)  Yes everything can change in future when we need it
 2) I don't think channel allocation for IPWAVE is out of scope for IETF,
because we already have cooperations between IEEE and IETF, so now things
change regulators around the world are working together to find best
solutions for best systems and best utilizations. IMHO,  IPWAVE systems
including channels are not out of scope for IETF, we work together
(regulators because they don't own IPv6 protocols) with others without
layers or abstractions or separations.
3) No, I think it can be totally relevant if WG says so, but if WG don't
want to think out of the box then yes it is not relevant to WG effort.

Best Regards

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Sep 2017 06:39:58 +0200

Le 20/09/2017 à 18:04, Abdussalam Baryun a écrit :
> On Tue, Sep 19, 2017 at 1:44 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 

Well there were two indications in that direction, and I agree with it 
too.  You too say "you can".

>         Alex et.al <http://et.al/>.,
> 

In order to discuss with Dick Roy there are two possibilities: one is to 
approach him in private.  In public, it is hard to discuss, because 
there is an email problem.  I suggest you help Dick and IETF to fix that 
email problem.

> The problem is that our system is not always TCP/IP model layers that 
> was IPv4 systems.

Err... I disagree.   IPv6-over-OCB is still the TCP/IP model.

> IMO  IPWAVE systems are more complicated and have 
> cross layers (I think we should not stick to one system layer model and 
> separate IPv6 networking).

I agree with that, but how about solving it in a separate document?

> 
>  From your statement you want us to stick to old approach of system 
> design, but we need new for our protocols of IPv6. So I recommend we 
> don't stick to old IP networking because IPv6 is new and is future work. 
> However, IMHO if this WG takes your approach we may need in future to 
> change our specifications.

Err...

WE can discuss this separately in the intarea WG.  There is an IPv10 
proposal there, that I could contribute to.

But here let us do IPv6-over-OCB, with old system design.  Old system 
design gives us access to interoperability to very numerous existing old 
system designs.

> agree on (if not please tell me what restricts us or what RFC stops us 
> from such regulation) because the packet is our protocol. No one can own 
> the channel but we own the IPv6 specification, and we can say which is 

Well, I agree.  I also propose to stick together all the channels of the 
5.9GHz into just one, to get higher bandwidth, for _some_ environments.

But it is future work.  It needs to update the ath10k driver, which is 
hard to do.  Do you agree it is hard to do?

[...]

>   2) I don't think channel allocation for IPWAVE is out of scope for 
> IETF, because we already have cooperations between IEEE and IETF, so now 
> things change regulators around the world are working together to find 
> best solutions for best systems and best utilizations. IMHO,  IPWAVE 
> systems including channels are not out of scope for IETF, we work 
> together (regulators because they don't own IPv6 protocols) with others 
> without layers or abstractions or separations.

Let us propose something in a separate document.  Do you agree?

> want to think out of the box then yes it is not relevant to WG effort.

Thinking out of the box will come time for it.

In that sense, do you agree to pursue now in this direction with this draft?

Alex

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 21 Sep 2017 12:54:47 +0200

Hi Richard

My comments below [AB], sorry that I may not reply quickly on all comments,

On Thu, Sep 21, 2017 at 7:42 AM, Dick Roy <[email-masked]> wrote:

> Abdussalam,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *   Thanks for taking the time to respond.  I am sorry about the email
> reflector issue.  I hope it can be resolved soon.   In the meantime, some
> comments below … and feel free to contact me directly if you’d like to
> discuss in more detail.   Cheers, RR   ------------------------------ From:
> Abdussalam Baryun [mailto:[email-masked]
> <[email-masked]>] Sent: Wednesday, September 20, 2017 9:05 AM
> To: Alexandre Petrescu; [email-masked] <[email-masked]>; its
> Subject: Re: [ipwave] correction       Hi Alex and the authors of other
> emails included,   My comments and discussion below     On Tue, Sep 19,
> 2017 at 1:44 PM, Alexandre Petrescu <[email-masked]
> <[email-masked]>> wrote: So, should I remove this paragraph:
> 802.11a/b/g/n runs:       *  Some channels are reserved for safety
> communications; the IPv6          packets should not be sent on these
> channels.       *  At the time of writing, the prohibition is explicit at
> higher          layer protocols providing services to the application;
> these          higher layer protocols are specified in IEEE 1609 documents,
>          i.e. the "WAVE" stack.       *  National or regional
> specifications and regulations specify the          use of different
> channels; these regulations must be followed. Alex   you can remove but not
> sure did WG agree on that,   Le 19/09/2017 à 00:06, Dick Roy a écrit : Alex
> et.al <http://et.al/>., The simple fact is that how physical resources are
> to be used (aka "what apps are allowed on which channels") is a topic/issue
> way outside the scope of the IETF's work.    I don't agree with Dick Roy.
> [RR] Join the crowd! You are by no means alone. *
>

*[AB]  I don't follow ideas  without discussions. .......You never know
when the crowd change their mind, but it is good to discuss among different
ideas when designing, otherwise our ideas are the creation of one person or
one company and we don't relise that. I always like to join the crowd but
discuss more to get to the best solution. The crowd are not always right,
so be careful when you follow the crowd.  *

>
>
> * The problem with the past IPv4 protocols is just that approach, we are
> in the future of IPv6, we need to look into future systems and protocols
> that use IPv6. [RR] IPv6 is a set of protocols for communication between
> peer entities in the network layer (layer 3 of the OSI model).  They can be
> management entities (ND, ARP, etc.) and they can be data plane entities
> (NPDU processing entities).  The physical layers over which the NPDUs are
> exchanged is/should be irrelevant to the peers.  That’s the whole point of
> the layered model of communications. Yes, there are cross-layer
> optimizations that are possible, but that is beyond the scope of any IETF
> effort in this regard (making IPv6 work over rapidly varying network
> topologies).  If a regulator states that physical streams (physical layer
> communication strings of bits exchanged over communication media) on a
> particular RF channel can not use IPv6 as the layer 3 protocol, will that
> change in any way the work upon which the rest of the ITS world hopes the
> IETF will embark?  I sure as h__k hope not! I recommend people stop
> thinking about issues that are irrelevant to their work and over which they
> have no control.  It’s a waste of time and energy.  The IETF should
> concentrate on its job, not someone else’s. *
>
>
>

[AB] We now days need to cooperate with SDOs even if we work in separate
SDOs, before experts work alone but now we need to work together. However,
we are not discussing use case of rapidly varying network topology, we only
discussing IPWAVE, I think they are different cases.

[AB] You say physical layers should be irrelevant, but we know that it
affects the peer communications. For example using wired or wireless
channels for TCP applications has different results, so we have
recommendations for using such packets/protocol in such media, regarding
frequencies, different countries as Japan/USA/Germany/etc. may rule
for different PHY technology for ITS, but our system we design in IETF is
not for one country or two. However, yes countries/governments are
controlling channel allocation technologies use, but we travel among
different countries/systems with IPv6 technologies.

[AB]  IMHO, it is not waste (to discuss on list) of time to make our work
original and use all PHY-technologies with recommendation of such channel
allocations or media accesses. I will stop thinking when SDOs  make a
standard available for IPWAVE.

[AB] IMO, Our use-case user is a vehicle that can carry many/100 of
physical devices (Am I wrong?), a user may decide/allocate the best
regulated-channel/technology available to use in terms of reliability or
other purpose. The user owns the technologies and can use the best channel
of communication available (physically or virtually).

[AB] our charter states:

*The group will try to reuse relevant technologies for Internet ofThings
(IoT) and infrastructure mobility that have been developedin other IETF and
IRTF groups. The WG will pay particularattention to the privacy
characteristics of solution it developsin order to minimize unwanted
tracking opportunities. The groupwill closely coordinate with IEEE 802.11.
The IETF has alsoestablished a formal liason relationship with ISO/TC204
inconnection with the work to be performed by this workinggroup. The work
produced by this group may also be of interest toother SDOs such as ETSI TC
ITS, 3GPP, and governmentorganizations such as the NHTSA. No formal
co-ordination isanticipated with these groups at this point but work done
inthese SDOs may end up becoming relevant to the WG deliverables inthe
future. *

>
>
>
>
> * I highly recommend you make no statements on such issues nor make any
> recommendations along those lines.    I think that is clean idea for now,
> however, we may need to make few conditions.   Stick to IPv6 networking and
> the network (and transport) layer functions required to implement it.
> Leave channel allocation issues to the appropriate entities ... the
> regulators and system integrators.   The problem is that our system is not
> always TCP/IP model layers that was IPv4 systems. IMO  IPWAVE systems are
> more complicated and have cross layers (I think we should not stick to one
> system layer model and separate IPv6 networking). [RR] First, as you state,
> TCP/IP is simply a transport protocol on top of a network protocol, whether
> it’s IPv4 or IPv6, and while there is no such thing as an IPWAVE system
> (unless you defined one), the WAVE (1609.x) standards have gratuitous
> support for IPv6 in one small paragraph, and in a WRA (I know because I was
> part of the team that wrote it.).  That said, “WAVE systems” (really WAVE
> devices acting as nodes in the ITS communication system) are no more
> complicated than your laptop.  There are no “cross layer” issues other than
> those well-known ones which were found to be relevant over 20 years ago
> when the “management plane” was conceived.  *
>

[AB]  IMO, Define the IPWAVE system/application (as from the WG charter)
as that work on V2V and V2I use-cases where IP is
well-suited as a networking technology and will develop an IPv6
based solution to establish direct and secure connectivity
between a vehicle and other vehicles or stationary systems. These
vehicular networks are characterized by dynamically changing
network topologies and connectivity.

[AB] We in IETF are different than IEEE, they look into design down to up,
but we look from up to down, we look at our applications and services for
users and then look into physical, so we have an advantage above IEEE.
Furthermore, the Internet services is needed by all so the physical layer
experts needs to work harder to follow our IPWAVE applications. As you may
know that the mobile system is changing from many generations for best
internet service, there was a change in frequency allocation worldwide and
per countries just because they want higher/better internet services.
Systems/technologies within 2G, 3G, 4G are available with different
frequencies and different users

>
> *From your statement you want us to stick to old approach of system
> design,*
>
> *[RR] Absolutely not!  Read any (or all:^)) of the ISO TC204 WG16/18
> standards (many of which I worked on) and see if there is anything therein
> that would lead you to believe we are looking for yesterday’s technology!
> You will NOT find anything!*
>
> * but we need new for our protocols of IPv6. *
>
> *So I recommend we don't stick to old IP networking because IPv6 is new
> and is future work. However, IMHO if this WG takes your approach we may
> need in future to change our specifications.*
>
> *[RR] The ITS community is counting on the IETF to revise old standards
> and create new ones to address the challenges of implementing IPv6
> networking in ITS! That said, IPv4 will be around for quite a while and ITS
> needs to accommodate that fact. IPv6 is still in its infancy, and we are
> counting on it succeeding!  Let’s get the ball rolling, and now!*
>

[AB]  Yes I agree that we all need to standard for IPWAVE so IETF wants all
experts to participate, its open to all, but we do things right in IETF not
like others maybe. however, in our WG we need to into new standards of
other WGs that related to us as well for the future of IoT, which yes we
never say we will stop IPv4 availability for our users.

>
>
> *Nothing is wrong with channel allocation in IETF we should be able to do
> that as well. *
>
> *[RR] If I understand the IETF’s charter, the answer is, while you should
> be “able” to do it (remember we are talking about layer 1 physical
> channels, not layer 3 logical channels), you should not do it.  It is
> rarely if ever a good idea to step outside one’s area of expertise and make
> proclamations which, with probability one will, in the very near future,
> make them look like something less than knowledgeable let’s just say. There
> is NO upside to making such statements, only a downside.  If someone wants
> to transmit IPv6 packets using tin cans and strings, or smoke signals, they
> should be able to do so and the IETF should cheer loudly and admire their
> ingenuity! *
>
> *We can regulate any of our protocols within any channel we agree on (if
> not please tell me what restricts us or what RFC stops us from such
> regulation) *
>
> *[RR] Since the IETF has no authority to do so, and it has NO means of
> enforcement, any restrictions you put on physical layer communications in
> your RFC’s are vacuous.  *
>

[AB]  We should recommend what is best to be use per technology per
service. Our user can carry many technologies and is travelling within many
regulators areas, so there is in some points that you can use/connect
both/two/three channels when you become in boarders. The user is travelling
and owns the technologies which are regulated/available. As we do a section
for security considerations in RFCs the user may not use it but it is there
for best.

> *because the packet is our protocol. *
>
> *[RR] The layer 3 packet conforms to your protocol; the physical layer
> stream conforms to someone else’s protocol and that is, as the prophet
> said, “none of your business”.*
>

[AB]  It is the owner's business, he owns the transmitter and maybe the
receiver as well, this layering thinking/business is wrong. We have
business with IP users around the world, why we should not recommend what
is best in PHY layers including allocation of channels.

> *No one can own the channel*
>
> *[RR] That’s also not true, but I digress.*
>

[AB]  A physical wireless channel can be used by any one that owns a
transmitter and/or receiver that works on such channel,

> * but we own the IPv6 specification, *
>
> *[RR] No you don’t.  It’s in the public domain.  Just google IPv6
> specifications!*
>

[AB]  I mean owning it as we can change/amend  it when IETF decides so. The
author is the owner of the document even if it is in public.

> *and we can say which is recommended (usually for the best benefit of
> users not regulators).*
>
> *[RR] You can recommend whatever you like … and users can freely ignore it
> as they wish.  Who cares?  What makes you think that an expert in physical
> layer communications should listen to a network layer guru who has never
> held a soldering iron trying to tell him how to do his job?  Is there
> anyone so foolish??  I wonder ...*
>

[AB]  You can see how the developed the mobile cellular system and you will
know that both experts computing and engineering must listen/advise to each
other, otherwise no networking. Yes users may ignore but when a problem
occurs the user becomes the fool not the standard issuer.

best,
AB