IP Security Maintenance and Extensions
charter-ietf-ipsecme-13
Yes
(Alexey Melnikov)
(Kathleen Moriarty)
No Objection
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Suresh Krishnan)
(Terry Manderson)
- Ready for external review (06-00)
- Ready for external review (07-00)
- Approve (07-02)
- Ready for external review (08-01)
- Ready for external review (09-01)
- Ready for external review (10-00)
- Approve (10-02)
- Ready for external review (11-01)
- Approve (11-05)
- Ready for external review (12-00)
- Approve (12-01)
Note: This ballot was opened for revision 10-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
Alexey Melnikov Former IESG member
Yes
Yes
(for -10-01)
Unknown
Kathleen Moriarty Former IESG member
Yes
Yes
(for -10-00)
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(2016-08-30 for -10-00)
Unknown
There are some typos (s/MIT/MTI) and bits of English that need to be tidied up. I have a suggestion about this bit of work: "IKEv1 using shared secret authentication was partially resistance to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify IKEv2 to have similar quantum resistant properties than IKEv1 had." My suggestion is twofold: 1) - s/will add/will consider adding/ and to add to the end: 2) "In doing this work the WG will consider ongoing work on quantum-resistance in the CFRG, and whether it is better to re-instate the same level of resistance that was present in IKEv1 or to wait for more recent work (e.g. in CFRG) to mature." The reason I suggest this is that it's possible the WG might conclude that it's better to wait for some newer QR stuff from CFRG. The current wording seems to commit the WG to firing ahead anyway, and we might overall be better if there are fewer QR mechanisms proposed, rather than adding some now when it might be better to wait a while longer.
Alissa Cooper Former IESG member
No Objection
No Objection
(2016-08-31 for -10-00)
Unknown
This seems like a lot of documents for a 16-month window based on this group's past publication rate. Good to be ambitious, but I'm just wondering how realistic this is.
Alvaro Retana Former IESG member
No Objection
No Objection
(2016-08-31 for -10-00)
Unknown
I find the last paragraph artificial and unnecessary: This charter will expire in December 2017. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. I understand that this type of text in a charter may help the WG maintain momentum, so I'm not going to stand in the way of making progress.
Ben Campbell Former IESG member
No Objection
No Objection
(2016-08-31 for -10-01)
Unknown
I share Alissa's concern about the number of documents for the time window.
Benoît Claise Former IESG member
No Objection
No Objection
(2016-09-01 for -10-01)
Unknown
Please provide some milestones along with dates, as guidance so that all documents are finished by Dec 2017. Otherwise this text below becomes a blanket statement, not paid attention to. This charter will expire in December 2017. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Hint: the current charter says This charter will expire in December 2015 (a year from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -10-00)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -10-01)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -10-01)
Unknown
Mirja Kühlewind Former IESG member
(was Block)
No Objection
No Objection
(2016-09-01 for -10-01)
Unknown
Thanks for changing the text on TCP!
Spencer Dawkins Former IESG member
No Objection
No Objection
(2016-08-29 for -10-00)
Unknown
This sentence doesn't parse for me - or maybe I just need more security clue? "IKEv1 using shared secret authentication was partially resistance to quantum computers." I don't object to this text "There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE packets need to be encapsulated in a TCP tunnel. The group will define a mechanism to tunnel IKE and IPsec over a TCP-based connection. This method is intended to be used as a fallback when IKE cannot be negotiated over UDP. The group will create a method where IKEv2 and IPsec packets can be encapsulated in the TCP connection." going for external review, but I'd love to understand better what the resulting protocol stack looks like. I get the part about encapsulating IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a general-purpose "IP over TCP" mechanism?
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -10-01)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -10-00)
Unknown