[dispatch] Notes from the DISPATCH 94 session

["A. Jean Mahoney" <[e-mail]>]

Hi all,

Below are my notes for the meeting in Seoul. Things I missed are marked 
with ellipses (...)

Thanks,

Jean


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 [e-mail].

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.


------------------------------------------------------------------
10:55-11:00  AoB