DISPATCH WG - IETF 97 Korea, November 2016 Monday, November 14, 9:30-11:00 Grand Ballroom 2 ------------------------------------------------------------------ 09:30-09:40 Agenda and Status Presenters: Mary Barnes, Cullen Jennings and Murray Kucherawy Presentation: https://www.ietf.org/proceedings/97/slides/slides-97-dispatch-master-slide-deck-00.pdf slide 1: Title slide 2: Note Well slide 3: Note well in other words slide 4: Administrivia Note taker: Jean Jabber scribe: Jonathan Lennox slide 5: Deadlines for IETF 98 slide 6: Understanding deadlines Cullen - early submitters get priority. Note that deadlines don't line up with full bof deadlines. slide 7: A reminder about mailing lists Typo on the slides - the ML should be art@ietf.org. Alissa Cooper - Please correct the slide. We're trying to reduce confusion. slide 8: Outstanding DISPATCH items draft-holmberg-dispatch-received-realm - IETF LC - done Need revision based on Worley's feedback for Mohali draft slide 9: Outstanding APPSAWG items The WG is done when docs are published, then the WG will close. ------------------------------------------------------------------ 09:40-10:10 VoIP Spam Presenter: Henning Schulzrinne Presentation: https://www.ietf.org/proceedings/97/slides/slides-97-dispatch-voip-spam-00.pptx Documents: https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam/ https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwanted/ slide 1: Title Henning - This is followup work from STIR. slide 2: Background Henning - Who has not been following STIR? [A few hands] Explanation of unwanted calls. STIR is solving the spoofing problem. slide 3: STIR + SHAKEN SHAKEN is an ADDIS effort. STIR is an ingredient for filtering. slide 4: Architecture Carriers may decide to delegate the decision to filter to a downstream entity due to legal considerations (charities, political calls). End user doesn't want to spend more than a few seconds rejecting a call. slide 5: Motivations and assumptions slide 6: draft-schulzrinne-dispatch-callinfo-spam The spam parameter is not meant to be precise. Carriers will have different scales. slide 7: Call categories Broad categories, some spam some not. slide 8: Call categories spam - if you don't know anything else. trusted is a catch-all category. slide 9: SIP Global Feature-Capability Indicator Is this the right label and registry? Henning found label description confusing. slide 10: Non-editorial changes made for -01 slide 11: draft-schulzrinne-dispatch-status-unwanted Draft does not prescribe behavior. Behaves like email spam buttons. slide 12: Non-editorial changes made for -01 Jon Peterson - I like this - good draft. If it's signed ... We could define a passport type that signs it. The only source of info you can trust is the registrar. I would like to have the property of trusting other entities on the path. Can do it with a passport extension. Henning - Is there anything special to do for that? Or can the draft just say look at this draft? Jon Peterson - There's 2 drafts in STIR. It would be a passport extension. Here's what you would sign. Henning - I could copy into my draft. There are 2 entities that could work - local PBX and your local carrier. I agree. Mark Nottingham - I've received a call from a debt collector. I was confused and unintentionally revealed info. If my phone had said that this was a legit debt collector, it would have made me even more confused. Bad actors will work to be classified in certain ways, putting the burden on carrier. Henning - There's a tradeoff and no carrier has to do it. A well-run carrier will be very careful on assigning labels. No one wants to get sued by someone labeled a spammer. In all cases for these labels, there are reasonably good indicators. If you are legitimate debt collector in the US, you have to be registered in the state where you do business. This is a concern. (something about Dunn and Bradstreet). Mark - It would be a country-by-country thing. Henning - there's some countries that don't have registration for debt collectors. But the spam score of this entity will go way up. Mark - web PKI - the green bar and ev certs. There's a lot of controversy about what it means. Henning - It does not label you as a particular entity. Anyone can get an ev cert with a Delaware dropbox. Pete Resnick - making a list of entities is fraught. A registry seems like a good plan. Unless you are willing to define the categories tightly. Why not 606? It's sufficient. A separate code for block or mark for spam. Mush semantics response codes is a bad plan. Dave Crocker - What is the line "similar to email with SMTP level mail redirection" on slide 11 referring to? Henning - .forwards Dave Crocker - That's not SMTP. Needs to be precise. And sip.call-info.spam - ... Henning - I've registered with the carrier. Dave - There's 40 years' experience with call categories. Hasn't been useful. Lot of work. Confusion. Legal concerns. Needs precise design and enforcement. On slide 6 "reason: source of data", and "source: domain of entity inserting data" is confusing. Henning - The reason parameter contains what was used in the spam calculation - keywords, spam list, FTC list, for example. It's not standardized, it's free text. Data in this parameter is useful for troubleshooting. If a call is mislabeled or you want to know why are you on a blacklist. Dave - displaying info to users. We have 20 years of experience. Users don't differentiate with reliability. Doesn't work on email and web. Henning - disagree - filter on call id. John Levine - is anyone implementing it yet? Henning - the draft was submitted in late Sept. It's an outflow of a cross industry strike force - major carriers and vendors in US. Martin Dolly - next 3GPP meeting - veristat is agreed to. These will be included 24.229. John Levine - forking is only used to game the system. Henning - this is SIP forking. John Levine - I agree that people do filter on caller id. Adding more info to the call id display won't be helpful. Henning - you have 15 characters that you can display and the CNAM field (typically displayed) is not useful. Adam Roach - I agree that it needs tighter semantics. Define - I never want to hear from this caller again. Most times I don't find out that I didn't want the call until after I pick it up. Cullen, as chair - where do we take this next? There appears to be a lot of interest on this topic. Let's talk about the status code, seems to fit into sipcore. Sipcore chairs? Adam - I want to talk to STIR chairs first, and the recharter isn't done yet. But this is a small change that would fall under the new charter. Cullen - Anyone have issues with sending it to sipcore if the charter works out? [Room silent] Cullen - we'll proceed with that plan. ------------------------------------------------------------------
10:10-10:25 Regular Expressions for Internet Mail Presenter: Sean Leonard Presentation: https://www.ietf.org/proceedings/97/slides/slides-97-dispatch-regular-expressions-for-internet-mail-00.pptx Document: https://tools.ietf.org/html/draft-lilley-font-toplevel-00 slide 1: Title slide 2: Overview slide 3: Progress Modern - strictly complies that with 5321 5322 slide 4: Deliverable email address most commercially important. Restrictions on domain names using back references. slide 5: Modern email address once you know how to read, straight-forward. slide 6: Modern message ID pretty easy. slide 7: Key observations slide 8: Discussion time + hums if you want to search for email addresses in corpus of text. Any UTF8 character beyond ascii, you will be finding non-us ascii text that will not be an email address. Adam - I think a huge majority of use will be webpages. Javascript should be priority one. Barry Lieba - I feel very strongly that you need to deal with IDNA and AEIs Sean Turner - agree Dave Crocker - do you know about the ICANN universal acceptance effort? This is the issue that Barry raised. Talk to that group. I don't fully understanding the use cases. The document needs to make the use cases clearer. The 4th bullet - you need to implement in a programming language and the regex gives you a portable implementation. It's note worthy that it ... John Klensin - I want to reinforce and extend on Barry's comment. Whether it's a good idea is a separate question. More important - if it messes with internationalization issues. We reopen the internationalization specs (precis or something else) rather than assuming that we can make ... with regular expressions. If we get it wrong, ... don't backdoor our way in. Joe Hildebrand - I don't think anyone wants to change syntax, just want to make it consumable in various programming environments. If you search for these sorts of things on programming assistance websites, you find a consistent set of horrible answers to solving the problem. We want to see if we can create a starting point for the programmers. For validating email addresses. It's nascent work, need regular expressions that we can test. There's use here. Sean - I want to touch on performance. The ones that are in the first draft. They're verifiable against the ABNF. Can't say they are performant. With JavaScript that doesn't have subroutine calls, can't use it. Martin Thomson - this may be a engineering project that's not in the purview of IETF. Put stuff on Github. Do performance analysis. Why is IETF the right forum? Sean - It doesn't have IETF consensus. Martin - does it need it? We could create consensus around something that is different from other consensus. It's great to raise awareness though. Joe Hildebrand - Need to get feedback from room. Anyone working on this will get it wrong. Eric Rescorla - Creating a RFC that will be buggy. This is a program which is difficult reading. What is it you want? Sean - I want a doc that's not wrong. If we take as a premise that 5321 and 5322 are not wrong. We want to be at least wrong as possible. Cullen - do you wanting a WG? do we form a Github repository? Sean - if there's enough work for a WG. Or AD sponsorship. Alexey Melnikov - The AD is scared to sponsor it. Dave Crocker - glad people raised process issues. Getting input, getting an imprimatur and getting an RFC publication are three different things. Getting IETF input is a good idea. Better to keep it as a malleable form. maybe independent stream. Set up an email implementation list. You get the input and circulation, but you don't incur process. Cullen - we're not done with this conversation. I want a read of the room. People think it's worth doing, but whether it should be done in a mini WG? Concern - we can't undermine other work. Author says that's not the intent. Should the IETF be in the work of publishing regular expressions? Anyone want to talk about it? [Room silent] ??? - implementers cut and paste from RFCs into software. Cullen - is this reasonable work? [lots of hums in the room] Cullen - Don't think we should be doing it? [Only one hum against] RESULTS of hum: Very strong consensus in favor of doing work in IETF. Chairs will discuss further. ------------------------------------------------------------------ 10:25-10:40 Area Directors’ Status: updating SIPCORE WG charter, state of the new ART area Presenters: Alissa Cooper, Ben Campbell, Alexey Melnikov Presentation: https://www.ietf.org/proceedings/97/slides/slides-97-dispatch-area-director-update-00.pdf slide 1: ART area feedback slide 2: Informal feedback Alissa - The ADs solicited feedback. chatted offline with people. slide 3: informal feedback Alissa - The feedback was a universal shrug. People were not super thrilled, but don't really care. Barry - I do care, I have a broader community and I like it. Mary (from floor) - I like having the Monday morning meeting. There's 41 working groups, but now I can sort by AD - it's easier. slide 4: Informal feedback Ted Hardie - On the bullet "Ability to get work done across areas", you listed RTCweb - Have you sensed a change in the WG? I have not. Alissa - this is what people have told us. slide 5: Discussion Alexey - you can talk to us later. Jonathan Lennox - We didn't have to fight about what area Cellar is in. Pete Resnick - this is a partial shrug - I've found having additional people discussing stuff is good. I wish more people would read all of dispatch. Ben - today, I saw 4 people with real email experience talk about realtime stuff. slide 6: Potential Actions SIPcore recharter. Ben - sipcore had a very strict charter. There's not a good place for Henning's draft right now. We're wanting to change charter. I've seen positive feedback mostly. Any other feedback? [Room silence.] Ben - We'll discuss the avtcore/avtext merge in the avtcore/avtext mtg. Adam - This is the first time in a long time that I have not had to come to the mic to say our charter won't less do that. ------------------------------------------------------------------ 10:40-10:55 Bofs and New WG updates (Bof/WG chairs) ----------------------- SECEVENT Yoav? - new working group ----------------------- GGIE - Glass to Glass Internet Ecosystem Presenter: Glenn Deen Presentation: https://www.ietf.org/proceedings/97/slides/slides-97-dispatch-ggie-update-00.pdf slide 1: title slide 2: GGIE Since IETF 96 in Berlin Glenn - updated the draft and 2 new drafts - use cases. Will demo in Chicago. slide 3: new GGIE Internet Drafts ----------------------- CBOR - Concise Binary Object Representation Presenter: Joe Hildebrand Presentation: https://www.ietf.org/proceedings/97/slides/slides-97-dispatch-cbor-00.pdf slide 1: Proposed CBOR working group slide 2: CBOR refresher slide 3: Needed work Cullen - Send comments to the list on the charter. ----------------------- ABNF Drafts Presenter: Sean Leonard Presentation: https://www.ietf.org/proceedings/97/slides/slides-97-dispatch-revising-abnf-00.pdf slide 1: ABNF Drafts (October 2016) Sean - looking to extend ABNF.