Deadline Extended: Request for volunteers or nominations to 2018 ICANN NomCom

[IAB Executive Administrative Manager]

The nominations deadline for the IETF appointment to the ICANN NomCom 
has been extended by one week, to 22 August 2017. The edited 
announcement is below.

-

The IAB (on behalf of the IETF) has been asked to supply a member to the 
2018 ICANN Nominating Committee (NomCom). Tim Wicinski has filled this 
role for the IETF community for the past two years and cannot seek 
another term due to term limits; the IAB thanks him for his service. The 
IAB would therefore like to ask the community for volunteers to serve on 
the ICANN NomCom. The IAB will appoint one person for a one-year term 
(renewable for one additional one-year term).

If you are interested in serving on the ICANN NomCom, please send a 
short e-mail to iab-ch...@iab.org and ex...@iab.org with your motivation 
and information concerning your familiarity with the IETF and ICANN. 
Alternatively, if you know of someone who may be a good fit for this 
position, please send the name and email address by e-mail to iab-
ch...@iab.org and ex...@iab.org. The IAB is looking for a diverse pool 
of candidates. The deadline for nominations or volunteers is 22 August 
2017.

After asking for community input on the candidates, the IAB will select 
from the available candidates. The IAB shall take into account 
candidates' familiarity with ICANN and the IETF (including their roles 
and processes), though the selected candidate will serve on the ICANN 
NomCom on personal title.

The ICANN NomCom process itself is governed by the ICANN bylaws; the 
relevant articles can be found at .

In addition, each NomCom determines a number of its own operational 
procedures, including the role of the NomCom in recruiting and selecting 
candidates for ICANN leadership positions. Based on the experience of 
previous volunteers, the time commitment is significant. The selected 
person should be prepared to participate in the recruitment of potential 
candidates for ICANN leadership positions (a few hours per month 
November through April); a few hours on conference calls each month (and 
even more near selection); ten or more hours per month reviewing and 
assessing candidate qualifications in April, May, and June; and multiple 
days of face-to-face meetings of the full NomCom at each of the three 
ICANN meetings.

The ICANN NomCom typically meets in person at or around three 
consecutive ICANN meetings in various locations throughout the world. It 
will select a final slate of candidates by June 2018 for the ICANN 
Board, the ALAC, the ccNSO Council, the GNSO Council, and the Public 
Technical Identifiers (PTI) Board of Directors, which manages the IANA 
functions used by the IETF.

NOTE: ICANN covers travel and hotel costs for a pre-determined number of 
days at each of the 3 consecutive ICANN meetings under prevailing ICANN 
policies. For more details, please see the IAB Statement on Liaison 
Compensation https://www.iab.org/documents/correspondence-reports-
documents/2015-2/iab-statement-on-liaison-compensation/.

Candidates should be able to join monthly teleconferences, with the 
expectation that these teleconferences will be held weekly during the 
candidate assessment process in May and June.

For more information about the ICANN NomCom see: 
https://nomcom.icann.org/

On behalf of the IAB,
Cindy Morgan
IAB Executive Administrative Manager

Last Call: (Coupled congestion control for RTP media) to Experimental RFC

[The IESG]

The IESG has received a request from the RTP Media Congestion Avoidance
Techniques WG (rmcat) to consider the following document: - 'Coupled
congestion control for RTP media'
   as Experimental 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
i...@ietf.org mailing lists by 2017-08-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


   When multiple congestion controlled RTP sessions traverse the same
   network bottleneck, combining their controls can improve the total
   on-the-wire behavior in terms of delay, loss and fairness.  This
   document describes such a method for flows that have the same sender,
   in a way that is as flexible and simple as possible while minimizing
   the amount of changes needed to existing RTP applications.  It
   specifies how to apply the method for the NADA congestion control
   algorithm, and provides suggestions on how to apply it to other
   congestion control algorithms.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/ballot/


No IPR declarations have been submitted directly on this I-D.

Last Call: (Advertising Tunneling Capability in OSPF) to Proposed Standard

[The IESG]

The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document: - 'Advertising Tunneling
Capability in OSPF'
   as Proposed Standard

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
i...@ietf.org mailing lists by 2017-08-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


   Networks use tunnels for a variety of reasons.  A large variety of
   tunnel types are defined and the ingress needs to select a type of
   tunnel which is supported by the egress and itself.  This document
   defines how to advertise egress tunnel capabilities in OSPF Router
   Information Link State Advertisement (LSAs).





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
draft-ietf-idr-tunnel-encaps: The BGP Tunnel Encapsulation Attribute (None 
- IETF stream)