Third (and final) NomCom 2021-2022 Call for Volunteers
Do you want to understand and influence how the IETF leadership is elected? Discuss with the candidates their visions for the different roles, and vote (yes, we vote) on those you believe will benefit the IETF and the Internet the most? Volunteer for the NomCom 2021-2022! This is the third and final call for volunteers for the 2021-2022 NomCom. We are only one week away from the end of the volunteer period. One click is all it takes to volunteer for NomCom 2021-2022: https://datatracker.ietf.org/nomcom/volunteer This "volunteer" page will let you volunteer for NomCom 2021-2022 or show you if you have already volunteered. It is also reachable via your profile page: https://datatracker.ietf.org/accounts/profile/ …where you will now see a button to volunteer (taking you to the "volunteer" page above) or a message letting you know if you have already volunteered. - Of course, you can volunteer by sending me a very short 3 line email (see below). - Thanks to everyone who has volunteered so far. However, we currently only have 83 volunteers. We need many more. So, please, please volunteer. The IETF NomCom appoints people to fill the open slots on the IETF LLC, IETF Trust, the IAB, and the IESG. Ten voting members for the NomCom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the NomCom can be found in BCP 10 (RFC 8713). RFC 3797 details the selection algorithm. Special for this year RFC 8989 (one-off update to RFC 8713 / BCP 10) tells us who is eligible to volunteer as anyone who satisfies any of the three following conditions: Path 1: The person has attended 3 out of the last 5 IETF meetings, including meetings held entirely online. For the 2021-2022 NomCom, the meetings concerned will be IETF 106, 107, 108, 109, and 110 Path 2: The person has been a Working Group Chair or Secretary within the 3 years prior to the day the first call for NomCom volunteers is sent to the community Path 3: The person has been a listed author or editor (on the front page) of at least two IETF Stream RFCs within the last 5 years prior to the day the call for NomCom volunteers is sent to the community. An Internet-Draft that has been approved by the IESG and is in the RFC Editor queue counts the same as a published RFC, with the relevant date being the date the draft was added to the RFC Editor queue. [Normative details are in RFC8989.] You can check your eligibility at: https://datatracker.ietf.org/accounts/profile/ …where you will now see a button to volunteer (taking you to the "volunteer" page above) or a message letting you know if you have already volunteered. If you qualify, please volunteer by clicking on the volunteer button. Alternatively, You can volunteer by sending me an email as explained below. However, please remember that anyone appointed to this NomCom will not be considered as a candidate for any of the positions that the 2021-2022 NomCom is responsible for filling. Details of Positions to Be Filled (some details to be finalized) An asterisk (*) next to a person's name indicates they do not intend to accept renomination. LLC Board (3-year term) • Jason Livingood IETF Trust (3-year term) • Kathleen Moriarty IAB (2-year term) • Ben Campbell • Cullen Jennings • Mirja Kühlewind • Jared Mauch • Tommy Pauly • Jiankang Yao IESG (2-year term) • Murray Kucherawy, ART AD • Erik Kline, INT AD • Robert Wilton, OPS AD • Martin Vigoureux, RTG AD • Benjamin Kaduk, SEC AD * • Martin Duke, TSV AD The primary activity for this NomCom will begin in July 2021 and should be completed by January 2022. The NomCom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a NomCom member does require some time commitment it is also a very rewarding experience. As a member of the NomCom it is very important that you be willing and able to attend meetings either remotely or in-person during IETF 112 (Madrid 6-12 November 2021) to conduct interviews. Remote attendance will be supported whether or not there are in-person meetings. Orientation and setting of the NomCom schedule will be done by videoconference during the week 26-30 July (exact time and date to be determined after NomCom membership is finalized on July 15), prior to IETF 111. Please volunteer by sending me an email before 23:59 UTC on Wednesday June 23, 2021, as follows: To: nomcom-chair-2...@ietf.org Subject: NomCom 2021-22 Volunteer Please include the following information in the email body:
Re: Last Call: (IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases) to Informational RFC
+1
I was going to write something similar to what Brian wrote. This document
says it is a problem statement, but then becomes a solution document. Might
be better to cut it down to only the problem statement part.
I also noted as Brian points out that the solution part appears to be dependent
on OMNI given the “must” language, but OMNI is an informational reference.
This seems like a disconnect.
Bob
> On Jun 14, 2021, at 8:25 PM, Brian E Carpenter
> wrote:
>
> Thanks for the heads-up, Erik.
>
> This text at
> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-20#page-9
>
>> Therefore, the existing IPv6 protocol can be
>> augmented through the addition of an Overlay Multilink Network (OMNI)
>> Interface [OMNI] and/or protocol changes in order to support both
>> wireless single-hop/multihop V2V communications and multiple radio
>> technologies in vehicular networks.
>
> is of concern regardless of the mention of OMNI. Does it mean "can be" or
> "needs to be"? This paragraph seems like a very short summary of a big
> problem area. At the end of page 13 there is some related discussion, which
> mentions RPL as part of the solution (good choice, IMHO) but again seems to
> depend on OMNI. I don't think the fix of simply removing references to OMNI
> works, because it would leave a gap. In an informational document, that is
> not a formal problem but as far as this draft describes architecture, I don't
> think that big a gap is reasonable. "OMNI" is mentioned more than 20 times in
> the document. There are also several references to AERO, which is strongly
> associated with OMNI.
>
> At this point I became confused about the purpose of the document. The
> Abstract says
>
>> This document discusses the problem statement and use cases of
>> IPv6-based vehicular networking
>
> In fact, most of section 4 seems to be a draft architecture of a solution.
>
>> 5. Problem Statement
>>
>> In order to specify protocols using the architecture mentioned in
>> Section 4.1, IPv6 core protocols have to be adapted to overcome
>> certain challenging aspects of vehicular networking.
>
> That's a big leap. But the rest of section 5 seems to get back to solution
> design.
>
> So I am left puzzled about what would happen next if this draft becomes an
> RFC. Do the authors expect 6man to work on the issues they've raised? I'm not
> sure they match 6man's limited charter ("not chartered to develop major
> changes or additions
> to the IPv6 specifications").
>
> Regards
> Brian Carpenter
>
> On 15-Jun-21 13:07, Erik Kline wrote:
>> +6man, since there are many statements about IPv6 work in this document.
>>
>> One thing of note: in the time after this document was WGLC'd, 6man
>> held an adoption call on OMNI that did not result in adoption [OMNI].
>> There are at two places where this text appears:
>>
>> "The existing IPv6 protocol must be augmented through the addition of
>> an OMNI interface..."
>>
>> These statements should probably be revised (or removed).
>>
>> -Erik
>>
>> [OMNI]
>> https://mailarchive.ietf.org/arch/msg/ipv6/s1S49EYPThX34Gowu4ExPgFb32k/
>>
>> On Mon, Jun 14, 2021 at 7:02 AM The IESG wrote:
>>>
>>>
>>> The IESG has received a request from the IP Wireless Access in Vehicular
>>> Environments WG (ipwave) to consider the following document: - 'IPv6
>>> Wireless
>>> Access in Vehicular Environments (IPWAVE): Problem
>>> Statement and Use Cases'
>>> as Informational RFC
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits final
>>> comments on this action. Please send substantive comments to the
>>> last-c...@ietf.org mailing lists by 2021-06-28. Exceptionally, comments may
>>> be sent to i...@ietf.org instead. In either case, please retain the
>>> beginning
>>> of the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>> This document discusses the problem statement and use cases of
>>> IPv6-based vehicular networking for Intelligent Transportation
>>> Systems (ITS). The main scenarios of vehicular communications are
>>> vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and
>>> vehicle-to-everything (V2X) communications. First, this document
>>> explains use cases using V2V, V2I, and V2X networking. Next, for
>>> IPv6-based vehicular networks, it makes a gap analysis of current
>>> IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management,
>>> and Security & Privacy), and then enumerates requirements for the
>>> extensions of those IPv6 protocols for IPv6-based vehicular
>>> networking.
>>>
>>>
>>>
>>>
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/
>>>
>>>
>>>
>>> No IPR declarations have been submitted directly on this I-D.
>>>
>>>
>>>
>>>
>>>
>>
>>
>> IETF IPv6 working group
