Skip to main content

CAPtive PORTal interaction
charter-ietf-capport-01

Yes

(Barry Leiba)
(Ben Campbell)
(Stephen Farrell)

No Objection

Alvaro Retana
(Alia Atlas)
(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?"

Alvaro Retana No Objection

(Alissa Cooper; former steering group member) Yes

Yes (2015-11-17 for -00-03)
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 steering group member) Yes

Yes (for -00-03)

                            

(Ben Campbell; former steering group member) Yes

Yes (for -00-03)

                            

(Spencer Dawkins; former steering group member) Yes

Yes (2015-11-16 for -00-03)
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 steering group member) Yes

Yes (for -00-03)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -00-03)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (2015-11-19 for -00-03)
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 steering group member) No Objection

No Objection (for -00-03)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -00-03)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2015-11-19 for -00-03)
The phrase "unrestricted access" was not clear to me. Perhaps you meant "Internet access".

(Joel Jaeggli; former steering group member) No Objection

No Objection (2015-11-08 for -00-03)
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 steering group member) No Objection

No Objection (for -00-03)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -00-03)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -00-03)