Minutes IETF104: capport
minutes-104-capport-00
Meeting Minutes | Captive Portal Interaction (capport) WG | |
---|---|---|
Date and time | 2019-03-27 10:20 | |
Title | Minutes IETF104: capport | |
State | Active | |
Other versions | plain text | |
Last updated | 2019-03-28 |
minutes-104-capport-00
(ietf 104 capport wed 11) - 20 (Materials) - https://github.com/capport-wg/wg-materials/tree/master/ietf104 Agenda Administrivia 5 Chairs - Agenda bash current AD adam roach announces barry will be capport responsible AD starting later today. Draft Status - 7710bis (update) 5 Erik https://tools.ietf.org/html/draft-ekwk-capport-rfc7710bis-02 question is whether there is wg consensus to adopt above (presentation) - https://github.com/capport-wg/wg-materials/blob/master/ietf104/chairs.pdf (mt) - is there a preference order (erik) - yes, but not within families 7710bis questions Does the conent negotion look reasonable? what more can be said about precedence during misconfiguration? other? (tommy pauly) - adopt it - looks reasonable. and will review (mnot) - please assign me an issue to review the content negotiation. (mt) - we need more reviewers. any volunteers? (ted lemon) - I will be reviewing this document (darshark) - I will be reviewing this document (mt) - does anyone think adopting this is a bad idea [no responses] (mt) - I will send email - Architecture (update) 5 Chairs https://tools.ietf.org/html/draft-ietf-capport-architecture-03 authors not available thomas peterson pledges to make a contribution this week - API (update) 10 Tommy&Darshak https://tools.ietf.org/html/draft-ietf-capport-api-02 (tommy's presentation) - https://github.com/capport-wg/wg-materials/blob/master/ietf104/api.pdf (mt) - you have about 8 open issues on github, but some are complete (tommy) - I will do a pass on that. [we do a pass in real time] 20 can be closed but a new issue can be opened 19 is done ..[crosstalk] several others done. about 4 are meaningfully open. discuss 18 - bytes remaining (tommy) - if we have insight into what capport does for blocking, do they have data limits or generally at which layer are they doing it. if we are unsure should we make that part of the name. (erik) - it must be something the device itself can count (as opposed to opaque tunnel overhead) (chris seal) - operators also apply counters in the case of prepaid. though control plane would not count in that case. tunnels and mobile signaling don't qualify. l3 matches (erik) - do bytes sent to the portal explicitly count? (tommy) - things that are whitelisted in the capport network don't count (erik) - client doesn't know what those things (tommy) - beyond the capport itself yes (jean-jacques?) - this isn't that useful in UI (tommy) - do l3 bytes and comment about whitelisted (mt) - ingress or egress? (all) - yes (both) (erik kinnear) - its better to overcount. whitelisted doesn't matter much (tero) - l3 makes sense (mt) - rough conensus on tommy's approach discuss 20 (tommy) - better served by author making a PR What does "done" look like for this group? Chairs (mt) - hope near wglc on api draft. architecture draft has a number of open issues (5) as well inclding doh. (#25) (presentation about 'sticking point' https) - //github.com/capport-wg/wg-materials/blob/master/ietf104/chairs.pdf (mt) - is wg comfortable with the boolean cap/nocap signal we've been doing so far rather than a richer state. does anyone have interest? we have json as an escape valve or do we need to block work on these questions. ((no badge)) - I am more comfortable with binary yes/no. lack use cases and may not be appropriate for capport to do the signal (mt) - the webpage also allows a lot of non-machine readable expression (tommy) - I agree with the simple view. we don't define the keys as the extension mechanism - we might onsider that (mt) - we need an iana registry if extension is desirable. an issue will be filed (mt) - chairs need a sense about should we just go forward with the issue list, or do we go back and more full engage with more state about the terms of confinement? (hum question) - should we proceed with the simple signal we currently have <strong> (hum question) - should we continue to engage with finding a solution to the richer state space <silence> (mt) - clear hum - will send it to the list. necessary changes are expected by ietf 105. adjourned 1156 AOB