IP Wireless Access in Vehicular Environments
charter-ietf-ipwave-01

[Ballot comment]

It strikes me that this bit of the charter

"This group will work on an informational document
that will explain the state of the art in the field and describe
the use cases that will use IPv6 in order to focus the work of
the group. The group will also work on informational document
that describes the problem statement and the associated security
and privacy considerations. The working group will decide at a
future point whether these informational documents need to be
published separately as RFCs or if they maybe combined."

... could lead to lots of wasted time unless the chairs are on
top of things fairly well.  So I hope they  will be:-)

[Ballot comment]
Nit: s/network topologies(connectivity)/network topologies (connectivity)./

Comment: Time line of the milestones look slightly strange because the problem statement draft is adopted at the same time when the protocol spec is published. Does that make sense?

[Ballot comment]
Thanks for the significant rework resulting in 00-02. I'm happy to ballot Yes on the result.

The following might not have been clear in my previous BLOCK on 00-01, so let me try again :-)

As the responsible AD for DTN, I am very interested in any thoughts the IPWAVE community has about the suitability of DTN's chartered work in the IPWAVE space, and welcome that conversation. My concern in my previous BLOCK was that the IPWAVE community might have already looked at DTN's chartered work and found it unsuited for deployments that will be based on IPWAVE. If that's happened, I'd love to hear more. If it hasn't happened, my apologies for misunderstanding.

[Ballot comment]
Supportive of the work though as others mentioned, the
description is quite vague. Agree with Alvaro, prefer future
work not to be mentioned at this time as seems more
appropriate for routing.

The first paragraph was difficult to parse as appropriate
for a charter (too commercial), the second paragraph
seems to be a better start.

From the first paragraph, "safety applications using
bidirectional data flows" seems to fit better with the
later text on safety-related messages to describe
what is needed.

[Ballot comment]

I think the charter ought also recognise the privacy sensitivity of
potentially tracking people and their vehicles. So I'd suggest
adding something like:

"The WG will pay particular attention to the privacy characteristics
of protocols it develops (or re-uses) in order to as far as possible
ensure that IP in vehicles does not offer unwanted tracking
opportunities."

[Ballot block]
"This group will work on V2V and V2I use-cases where IP is well-suited
as a networking technology, supporting also applications that involve
exchanges of safety-related messages between vehicles and
infrastructure if necessary."

If by "safety related messages", we are talking about use cases where life or property may be lost in failure cases, then I think this needs more clarity about the scope of such cases. I don't think "if necessary" is appropriate here; do we not already know what's necessary?

[Ballot comment]
I share the concerns others have mentioned regarding clarity of expected work items.

- "This group will develop IP-based protocols to establish direct and
secure connectivity between a vehicle, which is often comprised of
moving networks..."

s/comprised of/comprises

- Does the group really expect to leverage technologies developed in t2trg?

- Is the last paragraph needed? Any group can be rechartered.

[Ballot block]
My objection to this charter is not about the chartered work (as others have mentioned, and I agree with), but about the mention of potential future items:

"If the group is successful in accomplishing its first goals, then it can be rechartered to work on other things (examples include but are not limited to: a 1-hop mechanism of IP prefix exchange between moving networks, an n-hop extension, naming for moving networks; generalization for trains, air, unmanned and space use-cases)."


The mentioned "a 1-hop mechanism of IP prefix exchange between moving networks" and "an n-hop extension" sound too much like routing to me.  A set of 1-hop connections can easily become n-hops...  I understand the potential constraints in connection times that may exist in the applications, but other IETF work have similar constraints, also address moving network and general applicability such as “trains, air…”.  For example, the manet WG also deals with applications that have similar requirements/constrains and applications.

I would prefer if the expectation of future work is not part of this initial charter, and we deal with future items when/if the time comes.  At that point we can figure if existing protocols or WGs meet the proper requirements or not. 

To be clear: I'm not objecting to the future work, but to setting the expectation without taking into account existing work and WGs.

[Ballot block]
My objection to this charter is not about the chartered work (as others have mentioned, and I agree with), but about the potential future items:

"If the group is successful in accomplishing its first goals, then it can be rechartered to work on other things (examples include but are not limited to: a 1-hop mechanism of IP prefix exchange between moving networks, an n-hop extension, naming for moving networks; generalization for trains, air, unmanned and space use-cases)."


The mentioned "a 1-hop mechanism of IP prefix exchange between moving networks" and "an n-hop extension" sound too much like routing to me.  A set of 1-hop connections can easily become n-hops...  I understand the potential constraints in connection times that may exist in the applications, but other IETF work have similar constraints, also address moving network and general applicability such as “trains, air…”.  For example, the manet WG also deals with applications that have similar requirements/constrains and applications.

I would prefer if the expectation of future work is not part of this initial charter, and we deal with future items when/if the time comes.

[Ballot block]
Further to Mirja, Kathleen, and Benoit's comments, I think this charter needs to more explicitly declare what work is in scope for the WG before the charter goes for external review. If I recall correctly the narrowing of the scope down to v6-over-802.11-OCB (as the initial deliverable) took several rounds of BoFs to achieve, and yet it still isn't clear from the charter if that is the only standards track deliverable expected from this WG before re-chartering, or if there is some wider space of standards track specs that fall within the current charter.

[Ballot comment]
What is a "general problem area"? Does this group really need both a problem area and a problem statement? Do they really both need to be RFCs, or will one or both serve their purpose as discussion documents for the WG that can be bookmarked in the I-D repository once the WG comes to consensus on them?

[Ballot block]
I was intrigued by

"Without re-chartering, this group will not work on Delay-Tolerant Networking nor on Information-Centric Networking."

For DTN - I wouldn't be a bit surprised to see IPWAVE *using* the DTN protocols, but do the IPWAVE people have a sense that what DTN is doing now is potentially useful, but not usable in its current form, so that IPWAVE would need to "work on" the protocols DTN is producing? If part of IPWAVE is a DTN application, that could be a good thing, but if DTN is producing a "close but not close enough for IPWAVE" protocol set, that would be great to know.

For ICN - this is still in ICNRG, isn't it? But even if it comes to the IETF, I'd think ICN would be out of scope for IPWAVE to "work on", although (as with DTN) I could see IPWAVE *using* ICN protocols as they are standardized.

Are you seeing people who want to work on these topics in the IPWAVE space now? If so, we should definitely talk! Maybe that conversation should happen during External Review, or maybe we should chat about it now?

[Ballot comment]
I agree with Benoit and Mirja, I had to read the charter a few times to get an idea of what this group might work on, but the milestones seem like high-level goals, so I think that is okay.  From the text, the development of a protocol is not clear to me and I think it's because of the following two sentences:

However, IPv6 on 802.11-OCB is not yet defined.

The group will work only on IPv6 solutions.

Then, you see that development of a draft for IPv6 on 802.11-OCB is a milestone.  Could this be made more clear in the charter text?

[Ballot comment]
To forward the feedback I sent previously:

"Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I, not to be mistaken with V2Internet) communications are still being developed."
I read the charter multiple times, and I'm still not sure what the infrastructure is in V2I.
A sentence or two with background would be useful.

"Other SDOs interested in this work include ISO/TC204, ETSI TC ITS, 3GPP, and NHTSA."
Sure, it's interesting to know but what is the message for the ipwave group? Liaison, coordination, something else?

[Ballot comment]
To be honest, to me it's more clear  from the charter what the wg will not do than what the will do, however that's okay.

One question though: the charter says

"This group will develop IP-based protocols...".

Is it right to use the plural here? Will they work on multipe protocols or just one?