Skip to main content

IP Security Maintenance and Extensions
charter-ietf-ipsecme-13

Yes

(Jari Arkko)
(Kathleen Moriarty)
(Stephen Farrell)

No Objection

(Alexey Melnikov)
(Alia Atlas)
(Alvaro Retana)
(Benoît Claise)
(Mirja Kühlewind)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 10-02 and is now closed.

Ballot question: "Do we approve of this charter?"

Jari Arkko Former IESG member
Yes
Yes (for -10-02) Unknown

                            
Kathleen Moriarty Former IESG member
Yes
Yes (for -10-02) Unknown

                            
Stephen Farrell Former IESG member
Yes
Yes (for -10-02) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -10-02) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -10-02) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -10-02) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2016-09-14 for -10-02) Unknown
The milestones are all in the past. Should 2016 be 2017? Also, I notice the milestone list does not cover the full set of current goals--is that the intent? (I'm okay if it is; just checking.)
Benoît Claise Former IESG member
No Objection
No Objection (for -10-02) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -10-02) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2016-09-14 for -10-02) Unknown
Not for IPSECME, but for the IESG ...

I don't object to this work:

"There have been middle boxes blocking IKE negotiation over UDP. To
make IKE work in these environments, IKE and ESP packets need to be
transmitted over TCP. Therefore the group will define a mechanism to
use IKE and IPsec over TCP. The group will also provide guidance on 
how to detect when IKE cannot be negotiated over UDP, and TCP should 
be used as a fallback"

because what's described is going from UDP to TCP, which avoids a lot of challenges that going from TCP to UDP gives you, but it would be good for us to talk about all the ways that people are detecting poor performance, and even complete failures, in one protocol and switching to another protocol in response.  I note that Ian Swett reported in Berlin that Google sees QUIC affected by UDP impairments, including blocking, about five percent of the time, and they also fall back to TCP, so this is a current problem affecting work in multiple areas. 

Perhaps this is a a good topic for an upcoming informal telechat.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -10-02) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -10-02) Unknown