Re: [dispatch] Notes from the DISPATCH 94 session

Edit:

DISPATCH 97 <sigh>

Please let me know if you catch anything else...

Thanks!

Jean

On 11/14/16 5:44 PM, A. Jean Mahoney wrote:
> 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 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.
>
>
> ------------------------------------------------------------------
> 10:55-11:00  AoB
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch