capport - Wednesday, March 27, 2019

capport

capport@jabber.ietf.org

Wednesday, March 27, 2019< ^ >

dkg has set the subject to: IETF 102 - CAPPORT https://tools.ietf.org/wg/capport/agenda

Room Configuration

Room Occupants

GMT+0
[10:09:13] Meetecho joins the room
[10:10:24] VirtualQueue_Tpxa7nsJ joins the room
[10:15:10] Thomas Peterson joins the room
[10:15:11] Darshak Thakore joins the room
[10:15:15] John Border joins the room
[10:17:47] Martin Thomson joins the room
[10:18:23] Darshak Thakore leaves the room
[10:18:44] Darshak Thakore joins the room
[10:19:24] <Martin Thomson> I can relay comments for those who are remote.
[10:19:34] <Darshak Thakore> thanks
[10:21:06] Ted Lemon joins the room
[10:21:57] <Ted Lemon> Martin, if you want, I can do jabber scribe—I appear to be able to get onto the jabber using meetecho.
[10:25:03] Remi NGUYEN VAN joins the room
[10:25:09] <Ted Lemon> We are on the agenda bash slide
[10:27:43] <Ted Lemon> 7710bis changes slide
[10:30:07] <Ted Lemon> 7710bis questions slide
[10:31:11] <Ted Lemon> Tommy Pauly supports adoption and is willing to do a thorough review.
[10:31:26] <Ted Lemon> Mark Nottingham has agreed to do so as well.
[10:32:24] <Darshak Thakore> i'll review
[10:32:24] <Ted Lemon> Ted Lemon (me) agreed to review.
[10:32:59] <Ted Lemon> ietf-capport-architecture document slide
[10:33:51] <Ted Lemon> Tommy is presenting the Captive Portal API
[10:34:04] <Ted Lemon> Slide 2
[10:35:18] <Ted Lemon> Slide 3
[10:36:34] <Darshak Thakore> about 5 can be closed
[10:36:59] Zhongyi Shi joins the room
[10:37:02] <Ted Lemon> We are now looking at the github issue tracker
[10:37:41] <Ted Lemon> https://github.com/capport-wg/api/issues
[10:38:23] <Ted Lemon> We are now looking at issue 18
[10:38:37] <Ted Lemon> https://github.com/capport-wg/api/issues/18
[10:38:44] Zhongyi Shi leaves the room
[10:39:21] <Ted Lemon> Chris Seal
[10:39:46] <Ted Lemon> Control plane should not count, but purely what the user sees.
[10:40:12] <Ted Lemon> Tunneling overheads not counted as bytes remaining, because they are stripped
[10:40:38] <Ted Lemon> Tommy: so if the client counts up what they have sent, that should correspond to bytes remaining
[10:40:53] <Ted Lemon> Eric: what about packets to captive portal?
[10:41:02] <Ted Lemon> Tommy: should not count against the limits
[10:41:52] <Ted Lemon> Jean-Cheval?  If I know I have 100mb remaining, and want to do 90mb download, layer 2 bytes don't help.
[10:42:11] <Ted Lemon> Tommy: layer 3 bytes also don't help that much because that's the size of your donwload, not the amount of packets sent.
[10:42:22] <Ted Lemon> Based on feedback I think we want to do layer 3 bytes
[10:42:29] <Ted Lemon> Martin: ingress or egress?
[10:43:01] <Ted Lemon> Eric Kinnear: It's not going to make a huge difference and we can't assume the portal will whitelist
[10:43:14] <Ted Lemon> Tero: only layer 3 makes sense, we don't even know layer 2 e.g. for wifi
[10:43:44] <Ted Lemon> Tommy: ingress/egress, do we have any other feedback than just adding the total?
[10:44:20] <Ted Lemon> Tommy: discussion about vendor page URI will go to list.
[10:44:40] <Ted Lemon> Back to 7710bis questions
[10:44:52] <Ted Lemon> Does anybody think it's a bad idea to do this thing?
[10:46:24] <Ted Lemon> https://github.com/capport-wg/architecture/issues
[10:46:39] <Thomas Peterson> MIC: On the architecture diagram, is there any objections to including an annex on existing implementations (I am happy to attempt writing it), regarding the doh/capport discussion?
[10:46:48] <Thomas Peterson> s/diagram/document/
[10:46:55] <Ted Lemon> Sticking point slide
[10:47:29] <Thomas Peterson> I will have a crack at it this week.
[10:51:14] <Ted Lemon> ??? more comfortable with simple approach. don't have good information about why more info is necessary, and even if we did, is it essential to captive portal
[10:51:47] <Ted Lemon> The list of domain names that are permitted can be simply listed on the URL you are presenting already.   What else is necessary?
[10:53:01] <Ted Lemon> Tommy: I agree with the simple view, I agree that the outlook for this is that we can extend keys in the future, looking at the document we do not define a mechanism.  It's not an IANA registry that we are creating, doesn't specify anything about extensions, we can provide a way to extend it w/o registry or define a registry and a process, so that if a capport vendor wants to add something we can add it in.
[10:53:16] <Ted Lemon> Martin: if we believe extension is desirable we need an IANA registry.
[10:53:23] <Ted Lemon> Martin has filed an issue.
[10:54:05] <Ted Lemon> Martin: should we proceed or go back and more fully engage on this topic?
[10:54:53] <Darshak Thakore> humm
[10:55:19] <Ted Lemon> which did you him for?
[10:55:20] <Ted Lemon> sorry.
[10:55:22] <Darshak Thakore> first
[10:55:25] <Ted Lemon> ok.
[10:55:27] <Ted Lemon> :)
[10:55:30] <Darshak Thakore> proceed with simple
[10:57:12] Martin Thomson leaves the room
[10:57:37] Darshak Thakore leaves the room
[10:58:19] Ted Lemon leaves the room
[10:58:38] John Border leaves the room
[10:58:38] Remi NGUYEN VAN leaves the room
[10:58:39] Thomas Peterson leaves the room
[10:59:15] Meetecho leaves the room
[11:50:57] Martin Thomson joins the room
[12:23:55] Martin Thomson leaves the room
[12:29:48] Martin Thomson joins the room
[12:32:40] Martin Thomson leaves the room
[12:47:10] Martin Thomson joins the room
[13:58:15] Martin Thomson leaves the room
[14:04:12] Martin Thomson joins the room
[14:49:27] lt joins the room
[14:52:07] lt leaves the room
[15:06:39] Martin Thomson leaves the room
[15:18:10] Martin Thomson joins the room
[15:41:01] Martin Thomson leaves the room
[16:08:39] Martin Thomson joins the room
[16:10:24] Martin Thomson leaves the room
[16:18:22] Martin Thomson joins the room
[17:47:35] Martin Thomson leaves the room
[17:59:01] Martin Thomson joins the room
[18:08:26] Martin Thomson leaves the room
[18:09:15] Martin Thomson joins the room
[18:25:01] Martin Thomson leaves the room

Powered by ejabberd - robust, scalable and extensible XMPP server