CAPtive PORTal interaction
charter-ietf-capport-01
Yes
(Barry Leiba)
(Ben Campbell)
(Stephen Farrell)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Brian Haberman)
(Deborah Brungard)
(Kathleen Moriarty)
(Martin Stiemerling)
(Terry Manderson)
Note: This ballot was opened for revision 00-03 and is now closed.
Ballot question: "Do we approve of this charter?"
Alissa Cooper Former IESG member
Yes
Yes
(2015-11-17 for -00-03)
Unknown
The phrase "satisfy the requirements" is pretty ambiguous. I would suggest either explaining what requirements are intended (e.g., "the network operator's requirements for obtaining network access" or something along those lines) or dropping the phrase altogether if the point is really just to provide the URL.
Barry Leiba Former IESG member
Yes
Yes
(for -00-03)
Unknown
Ben Campbell Former IESG member
Yes
Yes
(for -00-03)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2015-11-16 for -00-03)
Unknown
Warren responded nicely to my comment on the 00-01 version about "As endpoints become inherently more secure, existing interception techniques will become less effective or will fail entirely." and I understand that a previous version that attempted to say "inherently more secure because X mechanisms are being deployed" was problematic, but the current text still sounds like we're thinking happy thoughts, and I know you aren't. Would it be any less problematic to say "inherently more secure in response to X security threats"? Where X might be "pervasive surveillance", "DNS spoofing", etc? "No" might be a perfectly reasonable answer ...
Stephen Farrell Former IESG member
Yes
Yes
(for -00-03)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2015-11-19 for -00-03)
Unknown
What's the relationship with draft-wkumari-dhc-capport-16? Any value in mentioning it in the charter? "Building on/Integrating/Improving/... (*) draft-wkumari-dhc-capport-16 (RFC editor queue), the WG will ..." (*) depending on the answer to the first question
Brian Haberman Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2015-11-19 for -00-03)
Unknown
The phrase "unrestricted access" was not clear to me. Perhaps you meant "Internet access".
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-11-08 for -00-03)
Unknown
The CAPPORT Working Group will define secure mechanisms and protocols to - allow endpoints to discover that they are in this sort of limited environment, I'm not personally convinced that capport will necessarily be more successful then DHC in securing initial signaling which strongly implies to me that we should not constrain it in this way. that said I think further along in process (vending a webpage) other security mechanisms come into play and that seems highly likely.
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -00-03)
Unknown