From nobody Fri Nov 4 11:40:36 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2D21295EE for ; Fri, 4 Nov 2016 11:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwnlFYlLIDDP for ; Fri, 4 Nov 2016 11:40:32 -0700 (PDT) Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F78129626 for ; Fri, 4 Nov 2016 11:40:31 -0700 (PDT) Received: from pps.filterd (m0048276.ppops.net [127.0.0.1]) by m0048276.ppops.net-00176a04. (8.16.0.17/8.16.0.17) with SMTP id uA4IbsZc020348 for ; Fri, 4 Nov 2016 14:40:31 -0400 Received: from usaoamgip002.mail.tfayd.com ([173.213.212.136]) by m0048276.ppops.net-00176a04. with ESMTP id 26gg20f93p-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 04 Nov 2016 14:40:31 -0400 Received: from unknown (HELO USUSHECWP008.mail.tfayd.com) ([10.40.78.204]) by usaoamgip002.mail.tfayd.com with ESMTP; 04 Nov 2016 14:40:29 -0400 Received: from USUSHEMWP012.mail.tfayd.com ([169.254.4.191]) by USUSHECWP008.mail.tfayd.com ([3.156.41.62]) with mapi id 14.03.0266.001; Fri, 4 Nov 2016 11:40:28 -0700 From: "Deen, Glenn (NBCUniversal)" To: "dispatch@ietf.org" Thread-Topic: GGIE - Two new GGIE I-D's & GGIE Introduction Updated Thread-Index: AQHSNsrp7J6A8MFzhkeJGTTT9KmfCQ== Date: Fri, 4 Nov 2016 18:40:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [10.23.204.83] x-exclaimer-md-config: 47edc00f-f2d6-45ef-be83-8a353bd47e45 Content-Type: multipart/alternative; boundary="_000_D442242BB3B38glenndeennbcunicom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-04_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611040347 Archived-At: Subject: [dispatch] GGIE - Two new GGIE I-D's & GGIE Introduction Updated X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:40:34 -0000 --_000_D442242BB3B38glenndeennbcunicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, Just a quick update on recent GGIE activity before IETF7. There are two new I-Ds covering Use Cases, and a draft on GGIE URI and S-NA= PTR for locating MARS servers. The GGIE Intro document has also been updated with Security and Privacy con= cerns. Details=85. GGIE Internet Video Use Cases Abstract: This document describes the sets of Use Cases for the GGIE Glass to Glas= s Internet Ecosystem. URL: https://tools.ietf.org/html/draft-rose-deen-ggie-use-cases-00.txt htmlized: https://tools.ietf.org/html/draft-rose-deen-ggie-use-cases-00 Status: https://datatracker.ietf.org/doc/draft-rose-deen-ggie-use-cases/ Glass to Glass Internet Ecosystem URI and S-NAPTR Use Abstract: This document defines the URI scheme "median" for "media networks" as defined in the Glass to Glass Internet Ecosystem work, as well as the necessary components to resolve median URIs using the S-NAPTR system. URL: https://www.ietf.org/internet-drafts/draft-daigle-deen-ggie= -uri-snaptr-00.txt Htmlized: https://tools.ietf.org/html/draft-daigle-deen-ggie-uri-snap= tr-00 Status: https://datatracker.ietf.org/doc/draft-daigle-deen-ggie-uri= -snaptr/ Updated Introduction to GGIE with material added on Security and Privacy Glass to Glass Internet Ecosystem Introduction Abstract: This document introduces the Glass to Glass Internet Ecosystem (GGIE). GGIE's purpose is to improve how the Internet is used create and consume video, both amateur and professional, reflecting that the line between amateur and professional video technology is increasingly blurred. Glass to Glass refers to the entire video ecosystem, from the camera lens to the viewing screen. As the name implies, GGIE's scope is the entire video ecosystem from capture, through the steps of editing, packaging, distributed and searching, and finally viewing. GGIE is not a complete end to end architecture or solution, it provides foundational elements that can serve as building blocks for new Internet video innovation. URL: https://www.ietf.org/internet-drafts/draft-deen-daigle-ggie= -02.txt Status: https://datatracker.ietf.org/doc/draft-deen-daigle-ggie/ Htmlized: https://tools.ietf.org/html/draft-deen-daigle-ggie-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-deen-daigle-ggie-= 02 regards Glenn Deen --_000_D442242BB3B38glenndeennbcunicom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <293859749A7C814EB36EEDBFC8F76E8F@NBCUNI.COM> Content-Transfer-Encoding: quoted-printable
Hi All,

Just a quick update on recent GGIE act= ivity before IETF7.

There are two new I-Ds covering Use Ca= ses, and a draft on GGIE URI and S-NAPTR for locating MARS servers. 
 
The GGIE Intro document has also been = updated with Security and Privacy concerns.

Details=85.

GGIE Internet Video Use Cases 
Abstract:
   This document describes t= he sets of Use Cases for the GGIE Glass to Glass Internet Ecosystem.




Glass to Glass Internet Ecosystem URI = and S-NAPTR Use
Abstract:
  This document defines the URI scheme "median" for &qu= ot;media networks" as
  defined in the Glass to Glass Internet Ecosystem work, as well = as the
  necessary components to resolve median URIs using the S-NAPTR s= ystem.

URL:            https://www.ietf.org/internet-drafts/draft-daigle-deen-ggie-uri-= snaptr-00.txt
Htmlized:     &nbs= p; https://tools.ietf.org/html/draft-daigle-deen-ggie-uri-snaptr-00<= /a>
Status:         https://datatr= acker.ietf.org/doc/draft-daigle-deen-ggie-uri-snaptr/



Updated Introduction to GGIE with material added on Security and Privacy

Glass to Glass Internet Ecosystem Introduction

Abstract:
  This document introduces the Glass to Glass Internet Ecosystem<= br>   (GGIE).  GGIE's purpose is to improve how the Internet is = used create
  and consume video, both amateur and professional, reflecting th= at the
  line between amateur and professional video technology is
  increasingly blurred.  Glass to Glass refers to the entire= video
  ecosystem, from the camera lens to the viewing screen.  As= the name
  implies, GGIE's scope is the entire video ecosystem from captur= e,
  through the steps of editing, packaging, distributed and search= ing,
  and finally viewing.  GGIE is not a complete end to end ar= chitecture
  or solution, it provides foundational elements that can serve a= s
  building blocks for new Internet video innovation.


regards
Glenn Deen
--_000_D442242BB3B38glenndeennbcunicom_-- From nobody Fri Nov 4 14:28:10 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE1812969B; Fri, 4 Nov 2016 14:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z9ozB9f9exm; Fri, 4 Nov 2016 14:28:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B841294AA; Fri, 4 Nov 2016 14:28:04 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA4LS1DF029191 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 4 Nov 2016 16:28:03 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "'SIPCORE'" , "dispatch@ietf.org" From: Adam Roach Message-ID: Date: Fri, 4 Nov 2016 16:28:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A1B50B280F4E72838B2CB70C" Archived-At: Cc: "art-ads@ietf.org" Subject: [dispatch] SIPCORE Rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 'SIPCORE' List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 21:28:08 -0000 This is a multi-part message in MIME format. --------------A1B50B280F4E72838B2CB70C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [as SIPCORE chair] Back when we transitioned from the SIPPING/SIP working group structure to SIPCORE, we put relatively tight limits on the SIPCORE charter. This was a recognition of the fact that the volume of SIP-related work at the time was too large for any one working group to reasonably handle. Instead, the intention was that the DISPATCH model of creating small, short-lived working groups for specific topics would be a better way to manage the relatively heavy workload. Fast forward seven years to today. SIP is a much more mature protocol, and the inflow of new work is significantly smaller than it was back then. At the same time, we have had several small, self-contained work items show up in DISPATCH that were deemed too small to create a new working group for, but precluded from being dispatched to SIPCORE by its charter. This has led to unnecessary delays as we determined the best disposition for these items. We, the SIPCORE chairs and area director, seek to fix that. We would like to amend the SIPCORE charter to allow it to take on small, self-contained protocol extensions in addition to changes to the core SIP protocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and adds back in two of the architectural principles from the SIP charter which are applicable only to protocol extensions. Please provide feedback on the proposed charter by sending email to the SIPCORE mailing list. We will also discuss this briefly during the DISPATCH session in Seoul. The proposed charter text follows. > The Session Initiation Protocol Core (SIPCore) working group is > chartered to maintain and continue the development of the SIP protocol, > currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and > 6665. > > The SIPCore working group will concentrate on specifications that update > or replace the core SIP specifications named above as well as > specifications pertaining to small, self-contained SIP protocol > extensions. The process and requirements for new SIP extensions are > documented in RFC5727, "Change Process for the Session Initiation > Protocol". > > Throughout its work, the group will strive to maintain the basic model > and architecture defined by SIP. In particular: > > 1. Services and features are provided end-to-end whenever possible. > > 2. Reuse of existing Internet protocols and architectures and > integrating with other Internet applications is crucial. > > 3. Standards-track extensions and new features must be generally > applicable, and not applicable only to a specific set of session > types. > > 4. Simpler solutions that solve a given problem should be favored > over more complex solutions. > > The primary source of change requirements to the core SIP specifications > (enumerated above) will be a) interoperability problems that stem from > ambiguous, or under-defined specification, and b) requirements from > other working groups in the ART Area. The primary source of new protocol > extensions is the DISPATCH working group, which will generally make the > determination regarding whether new SIP-related work warrants a new > working group or belongs in an existing one. For ease of reference, the existing SIPCORE charter is at https://datatracker.ietf.org/doc/charter-ietf-sipcore/ Thanks! /a --------------A1B50B280F4E72838B2CB70C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

[as SIPCORE chair]

Back when we transitioned from the SIPPING/SIP working group structure to SIPCORE, we put relatively tight limits on the SIPCORE charter. This was a recognition of the fact that the volume of SIP-related work at the time was too large for any one working group to reasonably handle. Instead, the intention was that the DISPATCH model of creating small, short-lived working groups for specific topics would be a better way to manage the relatively heavy workload.

Fast forward seven years to today. SIP is a much more mature protocol, and the inflow of new work is significantly smaller than it was back then. At the same time, we have had several small, self-contained work items show up in DISPATCH that were deemed too small to create a new working group for, but precluded from being dispatched to SIPCORE by its charter. This has led to unnecessary delays as we determined the best disposition for these items.

We, the SIPCORE chairs and area director, seek to fix that. We would like to amend the SIPCORE charter to allow it to take on small, self-contained protocol extensions in addition to changes to the core SIP protocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and adds back in two of the architectural principles from the SIP charter which are applicable only to protocol extensions.

Please provide feedback on the proposed charter by sending email to the SIPCORE mailing list. We will also discuss this briefly during the DISPATCH session in Seoul.

The proposed charter text follows.


The Session Initiation Protocol Core (SIPCore) working group is
chartered to maintain and continue the development of the SIP protocol,
currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and
6665.

The SIPCore working group will concentrate on specifications that update
or replace the core SIP specifications named above as well as
specifications pertaining to small, self-contained SIP protocol
extensions.  The process and requirements for new SIP extensions are
documented in RFC5727, "Change Process for the Session Initiation
Protocol".

Throughout its work, the group will strive to maintain the basic model
and architecture defined by SIP. In particular:

1. Services and features are provided end-to-end whenever possible.

2. Reuse of existing Internet protocols and architectures and
   integrating with other Internet applications is crucial.

3. Standards-track extensions and new features must be generally
   applicable, and not applicable only to a specific set of session
   types.

4. Simpler solutions that solve a given problem should be favored
    over more complex solutions.

The primary source of change requirements to the core SIP specifications
(enumerated above) will be a) interoperability problems that stem from
ambiguous, or under-defined specification, and b) requirements from
other working groups in the ART Area. The primary source of new protocol
extensions is the DISPATCH working group, which will generally make the
determination regarding whether new SIP-related work warrants a new
working group or belongs in an existing one.


For ease of reference, the existing SIPCORE charter is at https://datatracker.ietf.org/doc/charter-ietf-sipcore/

Thanks!

/a

--------------A1B50B280F4E72838B2CB70C-- From nobody Fri Nov 4 18:47:44 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFD01294B3 for ; Fri, 4 Nov 2016 18:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvlGUYSgSGHP for ; Fri, 4 Nov 2016 18:47:42 -0700 (PDT) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2157B126FDC for ; Fri, 4 Nov 2016 18:47:41 -0700 (PDT) X-AuditID: 12074414-89bff700000009b1-7b-581d3a3cb152 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 80.1F.02481.C3A3D185; Fri, 4 Nov 2016 21:47:40 -0400 (EDT) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id uA51ld70003838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 4 Nov 2016 21:47:40 -0400 To: dispatch@ietf.org References: From: Paul Kyzivat Message-ID: Date: Fri, 4 Nov 2016 21:47:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixO6iqGtjJRth8G+llsXSSQtYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseZ1I2PBbdmKAyvfMTcwtkt0MXJySAiYSKxt/sTexcjFISRw mVGi58NVKOcdk8SBGe1sXYwcHMICOhJHfhiDNIgIiErMX7GIHcQWErCT+Puslw3EZhPQkphz 6D8LiM0rYC+xaeJdZhCbRUBF4tT964wgtqhAmsT2dbuZIWoEJU7OfAJWzwlUP+HufrA5zAK2 EnfmQtQwC8hLbH87h3kCI98sJC2zkJTNQlK2gJF5FaNcYk5prm5uYmZOcWqybnFyYl5eapGu hV5uZoleakrpJkZIkInsYDxyUu4QowAHoxIPb8IUmQgh1sSy4srcQ4ySHExKorzPNgCF+JLy UyozEosz4otKc1KLDzFKcDArifCyGctGCPGmJFZWpRblw6SkOViUxHm/LVb3ExJITyxJzU5N LUgtgsnKcHAoSfByWgI1ChalpqdWpGXmlCCkmTg4QYbzAA03AanhLS5IzC3OTIfIn2JUlBLn lQFJCIAkMkrz4HphSeAVozjQK8K83iBVPMAEAtf9CmgwE9BgtxAZkMEliQgpqQZGk4aCVL25 u837s2bNYIhR1nYUjnQ4G85evyD43LJDu1dy1Jy8UXHdmVU28fdbLpmtWaEC7AmzYq2PLLq5 N2RWUKuC5z7xF4bJ9Zqak9MWzXQvSggr37zm+evZFw991DkWbWZfWHyIKerK/6S45Y5Nd0Ik eP/r+29icMx5dqB9y1udtRGL34QpsRRnJBpqMRcVJwIAlEv8M90CAAA= Archived-At: Subject: Re: [dispatch] SIPCORE Rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 01:47:44 -0000 I think this will be a helpful change. Thanks, Paul On 11/4/16 5:28 PM, Adam Roach wrote: > [as SIPCORE chair] > > Back when we transitioned from the SIPPING/SIP working group structure > to SIPCORE, we put relatively tight limits on the SIPCORE charter. This > was a recognition of the fact that the volume of SIP-related work at the > time was too large for any one working group to reasonably handle. > Instead, the intention was that the DISPATCH model of creating small, > short-lived working groups for specific topics would be a better way to > manage the relatively heavy workload. > > Fast forward seven years to today. SIP is a much more mature protocol, > and the inflow of new work is significantly smaller than it was back > then. At the same time, we have had several small, self-contained work > items show up in DISPATCH that were deemed too small to create a new > working group for, but precluded from being dispatched to SIPCORE by its > charter. This has led to unnecessary delays as we determined the best > disposition for these items. > > We, the SIPCORE chairs and area director, seek to fix that. We would > like to amend the SIPCORE charter to allow it to take on small, > self-contained protocol extensions in addition to changes to the core > SIP protocol. This is a relatively minor update to the existing charter, > which expands the scope as described above, and adds back in two of the > architectural principles from the SIP charter which are applicable only > to protocol extensions. > > Please provide feedback on the proposed charter by sending email to the > SIPCORE mailing list. We will also discuss this briefly during the > DISPATCH session in Seoul. > > The proposed charter text follows. > > >> The Session Initiation Protocol Core (SIPCore) working group is >> chartered to maintain and continue the development of the SIP protocol, >> currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and >> 6665. >> >> The SIPCore working group will concentrate on specifications that update >> or replace the core SIP specifications named above as well as >> specifications pertaining to small, self-contained SIP protocol >> extensions. The process and requirements for new SIP extensions are >> documented in RFC5727, "Change Process for the Session Initiation >> Protocol". >> >> Throughout its work, the group will strive to maintain the basic model >> and architecture defined by SIP. In particular: >> >> 1. Services and features are provided end-to-end whenever possible. >> >> 2. Reuse of existing Internet protocols and architectures and >> integrating with other Internet applications is crucial. >> >> 3. Standards-track extensions and new features must be generally >> applicable, and not applicable only to a specific set of session >> types. >> >> 4. Simpler solutions that solve a given problem should be favored >> over more complex solutions. >> >> The primary source of change requirements to the core SIP specifications >> (enumerated above) will be a) interoperability problems that stem from >> ambiguous, or under-defined specification, and b) requirements from >> other working groups in the ART Area. The primary source of new protocol >> extensions is the DISPATCH working group, which will generally make the >> determination regarding whether new SIP-related work warrants a new >> working group or belongs in an existing one. > > > For ease of reference, the existing SIPCORE charter is at > https://datatracker.ietf.org/doc/charter-ietf-sipcore/ > > Thanks! > > /a > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Sun Nov 6 05:48:09 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BE6129898; Sun, 6 Nov 2016 05:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.891 X-Spam-Level: X-Spam-Status: No, score=-6.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvNXxvS-GiSS; Sun, 6 Nov 2016 05:47:46 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A510912988F; Sun, 6 Nov 2016 05:47:45 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id C1DFC5EE21A14; Sun, 6 Nov 2016 13:47:40 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA6DlgUC009705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 Nov 2016 13:47:43 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uA6Dlgin025252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 6 Nov 2016 14:47:42 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.214]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Sun, 6 Nov 2016 14:47:42 +0100 From: "Drage, Keith (Nokia - GB)" To: "'SIPCORE'" , "dispatch@ietf.org" Thread-Topic: [dispatch] SIPCORE Rechartering Thread-Index: AQHSNuJbof3GUTb0uE6yIgkvbI355qDL81hQ Date: Sun, 6 Nov 2016 13:47:41 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADFA846B@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADFA846BFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "art-ads@ietf.org" Subject: Re: [dispatch] SIPCORE Rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 13:47:50 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADFA846BFR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyaGFwcyB5b3UgY291aWxkIGVsYWJvcmF0ZSBvbiBob3cgeW91IG5vdyBzZWUgdGhlIHJlbGF0 aW9uc2hpcCBiZXR3ZWVuIFNJUENPUkUgYW5kIERJU1BBVENILiBJdCBpcyBub3QgY2xlYXIgdG8g bWUgd2hhdCB0aGUgY3JpdGVyaWEgYXJlIGZvciBzdWJtaXR0aW5nIHNvbWV0aGluZyBuZXcgdG8g RElTUEFUQ0gsIHZlcnN1cyBTSVBDT1JFIGRpcmVjdGx5Lg0KDQpXb3VsZCBldmVyeXRoaW5nIGdv IHRvIERJU1BBVENIIGZpcnN0IGFuZCB0aGUgY2hhbmdlIGhlcmUgaXMgdG8gYWxsb3cgU0lQQ09S RSB0byB0YWtlIG9uIHdvcmsgdGhhdCBoYXMgYmVlbiBkaXNwYXRjaGVkLCBvciB3b3VsZCBTSVBD T1JFIGJlIHRoZSBmaXJzdCBwb2ludCBvZiBlbnRyeSBmb3IgbWF0ZXJpYWwsIGFuZCBpZiBzbywg dG8gd2hhdCBzY29wZS4NCg0KRmluYWxseSwgc29tZSBzdHVmZiBmcm9tIERJU1BBVENIIGhhcyBn b25lIGRpcmVjdCB0byBBRCBzcG9uc29yZWQg4oCTIHdvdWxkIHlvdSBub3cgc2VlIHRob3NlIGJl Y29taW5nIFdHIGl0ZW1zIG9mIFNJUENPUkUsIG9yIHdvdWxkIHRoYXQgcm91dGUgc3RpbGwgYmUg ZW52aXNhZ2VkLCBhbmQgaWYgc28sIHdvdWxkIHRoZSDigJxkaXNwYXRjaOKAnSBvY2N1ciBmcm9t IERJU1BBVENIIG9yIFNJUENPUkUuDQoNCk1heWJlIHlvdSBjb3VsZCB1c2Ugc29tZSByZWNlbnQg ZHJhZnRzIGFuZCBSRkNzIGFzIGV4YW1wbGVzIG9mIHdoZXJlIHlvdSB0aGluayB0aGluZ3Mgd2ls bCBjaGFuZ2UuDQoNCktlaXRoDQoNCkZyb206IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2gNClNlbnQ6IDA0IE5vdmVtYmVy IDIwMTYgMjE6MjgNClRvOiAnU0lQQ09SRSc7IGRpc3BhdGNoQGlldGYub3JnDQpDYzogYXJ0LWFk c0BpZXRmLm9yZw0KU3ViamVjdDogW2Rpc3BhdGNoXSBTSVBDT1JFIFJlY2hhcnRlcmluZw0KDQoN ClthcyBTSVBDT1JFIGNoYWlyXQ0KDQpCYWNrIHdoZW4gd2UgdHJhbnNpdGlvbmVkIGZyb20gdGhl IFNJUFBJTkcvU0lQIHdvcmtpbmcgZ3JvdXAgc3RydWN0dXJlIHRvIFNJUENPUkUsIHdlIHB1dCBy ZWxhdGl2ZWx5IHRpZ2h0IGxpbWl0cyBvbiB0aGUgU0lQQ09SRSBjaGFydGVyLiBUaGlzIHdhcyBh IHJlY29nbml0aW9uIG9mIHRoZSBmYWN0IHRoYXQgdGhlIHZvbHVtZSBvZiBTSVAtcmVsYXRlZCB3 b3JrIGF0IHRoZSB0aW1lIHdhcyB0b28gbGFyZ2UgZm9yIGFueSBvbmUgd29ya2luZyBncm91cCB0 byByZWFzb25hYmx5IGhhbmRsZS4gSW5zdGVhZCwgdGhlIGludGVudGlvbiB3YXMgdGhhdCB0aGUg RElTUEFUQ0ggbW9kZWwgb2YgY3JlYXRpbmcgc21hbGwsIHNob3J0LWxpdmVkIHdvcmtpbmcgZ3Jv dXBzIGZvciBzcGVjaWZpYyB0b3BpY3Mgd291bGQgYmUgYSBiZXR0ZXIgd2F5IHRvIG1hbmFnZSB0 aGUgcmVsYXRpdmVseSBoZWF2eSB3b3JrbG9hZC4NCg0KRmFzdCBmb3J3YXJkIHNldmVuIHllYXJz IHRvIHRvZGF5LiBTSVAgaXMgYSBtdWNoIG1vcmUgbWF0dXJlIHByb3RvY29sLCBhbmQgdGhlIGlu ZmxvdyBvZiBuZXcgd29yayBpcyBzaWduaWZpY2FudGx5IHNtYWxsZXIgdGhhbiBpdCB3YXMgYmFj ayB0aGVuLiBBdCB0aGUgc2FtZSB0aW1lLCB3ZSBoYXZlIGhhZCBzZXZlcmFsIHNtYWxsLCBzZWxm LWNvbnRhaW5lZCB3b3JrIGl0ZW1zIHNob3cgdXAgaW4gRElTUEFUQ0ggdGhhdCB3ZXJlIGRlZW1l ZCB0b28gc21hbGwgdG8gY3JlYXRlIGEgbmV3IHdvcmtpbmcgZ3JvdXAgZm9yLCBidXQgcHJlY2x1 ZGVkIGZyb20gYmVpbmcgZGlzcGF0Y2hlZCB0byBTSVBDT1JFIGJ5IGl0cyBjaGFydGVyLiBUaGlz IGhhcyBsZWQgdG8gdW5uZWNlc3NhcnkgZGVsYXlzIGFzIHdlIGRldGVybWluZWQgdGhlIGJlc3Qg ZGlzcG9zaXRpb24gZm9yIHRoZXNlIGl0ZW1zLg0KDQpXZSwgdGhlIFNJUENPUkUgY2hhaXJzIGFu ZCBhcmVhIGRpcmVjdG9yLCBzZWVrIHRvIGZpeCB0aGF0LiBXZSB3b3VsZCBsaWtlIHRvIGFtZW5k IHRoZSBTSVBDT1JFIGNoYXJ0ZXIgdG8gYWxsb3cgaXQgdG8gdGFrZSBvbiBzbWFsbCwgc2VsZi1j b250YWluZWQgcHJvdG9jb2wgZXh0ZW5zaW9ucyBpbiBhZGRpdGlvbiB0byBjaGFuZ2VzIHRvIHRo ZSBjb3JlIFNJUCBwcm90b2NvbC4gVGhpcyBpcyBhIHJlbGF0aXZlbHkgbWlub3IgdXBkYXRlIHRv IHRoZSBleGlzdGluZyBjaGFydGVyLCB3aGljaCBleHBhbmRzIHRoZSBzY29wZSBhcyBkZXNjcmli ZWQgYWJvdmUsIGFuZCBhZGRzIGJhY2sgaW4gdHdvIG9mIHRoZSBhcmNoaXRlY3R1cmFsIHByaW5j aXBsZXMgZnJvbSB0aGUgU0lQIGNoYXJ0ZXIgd2hpY2ggYXJlIGFwcGxpY2FibGUgb25seSB0byBw cm90b2NvbCBleHRlbnNpb25zLg0KDQpQbGVhc2UgcHJvdmlkZSBmZWVkYmFjayBvbiB0aGUgcHJv cG9zZWQgY2hhcnRlciBieSBzZW5kaW5nIGVtYWlsIHRvIHRoZSBTSVBDT1JFIG1haWxpbmcgbGlz dC4gV2Ugd2lsbCBhbHNvIGRpc2N1c3MgdGhpcyBicmllZmx5IGR1cmluZyB0aGUgRElTUEFUQ0gg c2Vzc2lvbiBpbiBTZW91bC4NCg0KVGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBmb2xsb3dzLg0K DQoNClRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgQ29yZSAoU0lQQ29yZSkgd29ya2lu ZyBncm91cCBpcw0KY2hhcnRlcmVkIHRvIG1haW50YWluIGFuZCBjb250aW51ZSB0aGUgZGV2ZWxv cG1lbnQgb2YgdGhlIFNJUCBwcm90b2NvbCwNCmN1cnJlbnRseSBkZWZpbmVkIGFzIHByb3Bvc2Vk IHN0YW5kYXJkIFJGQ3MgMzI2MSwgMzI2MiwgMzI2MywgMzI2NCwgYW5kDQo2NjY1Lg0KDQpUaGUg U0lQQ29yZSB3b3JraW5nIGdyb3VwIHdpbGwgY29uY2VudHJhdGUgb24gc3BlY2lmaWNhdGlvbnMg dGhhdCB1cGRhdGUNCm9yIHJlcGxhY2UgdGhlIGNvcmUgU0lQIHNwZWNpZmljYXRpb25zIG5hbWVk IGFib3ZlIGFzIHdlbGwgYXMNCnNwZWNpZmljYXRpb25zIHBlcnRhaW5pbmcgdG8gc21hbGwsIHNl bGYtY29udGFpbmVkIFNJUCBwcm90b2NvbA0KZXh0ZW5zaW9ucy4gIFRoZSBwcm9jZXNzIGFuZCBy ZXF1aXJlbWVudHMgZm9yIG5ldyBTSVAgZXh0ZW5zaW9ucyBhcmUNCmRvY3VtZW50ZWQgaW4gUkZD NTcyNywgIkNoYW5nZSBQcm9jZXNzIGZvciB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uDQpQcm90b2Nv bCIuDQoNClRocm91Z2hvdXQgaXRzIHdvcmssIHRoZSBncm91cCB3aWxsIHN0cml2ZSB0byBtYWlu dGFpbiB0aGUgYmFzaWMgbW9kZWwNCmFuZCBhcmNoaXRlY3R1cmUgZGVmaW5lZCBieSBTSVAuIElu IHBhcnRpY3VsYXI6DQoNCjEuIFNlcnZpY2VzIGFuZCBmZWF0dXJlcyBhcmUgcHJvdmlkZWQgZW5k LXRvLWVuZCB3aGVuZXZlciBwb3NzaWJsZS4NCg0KMi4gUmV1c2Ugb2YgZXhpc3RpbmcgSW50ZXJu ZXQgcHJvdG9jb2xzIGFuZCBhcmNoaXRlY3R1cmVzIGFuZA0KICAgaW50ZWdyYXRpbmcgd2l0aCBv dGhlciBJbnRlcm5ldCBhcHBsaWNhdGlvbnMgaXMgY3J1Y2lhbC4NCg0KMy4gU3RhbmRhcmRzLXRy YWNrIGV4dGVuc2lvbnMgYW5kIG5ldyBmZWF0dXJlcyBtdXN0IGJlIGdlbmVyYWxseQ0KICAgYXBw bGljYWJsZSwgYW5kIG5vdCBhcHBsaWNhYmxlIG9ubHkgdG8gYSBzcGVjaWZpYyBzZXQgb2Ygc2Vz c2lvbg0KICAgdHlwZXMuDQoNCjQuIFNpbXBsZXIgc29sdXRpb25zIHRoYXQgc29sdmUgYSBnaXZl biBwcm9ibGVtIHNob3VsZCBiZSBmYXZvcmVkDQogICAgb3ZlciBtb3JlIGNvbXBsZXggc29sdXRp b25zLg0KDQpUaGUgcHJpbWFyeSBzb3VyY2Ugb2YgY2hhbmdlIHJlcXVpcmVtZW50cyB0byB0aGUg Y29yZSBTSVAgc3BlY2lmaWNhdGlvbnMNCihlbnVtZXJhdGVkIGFib3ZlKSB3aWxsIGJlIGEpIGlu dGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgdGhhdCBzdGVtIGZyb20NCmFtYmlndW91cywgb3IgdW5k ZXItZGVmaW5lZCBzcGVjaWZpY2F0aW9uLCBhbmQgYikgcmVxdWlyZW1lbnRzIGZyb20NCm90aGVy IHdvcmtpbmcgZ3JvdXBzIGluIHRoZSBBUlQgQXJlYS4gVGhlIHByaW1hcnkgc291cmNlIG9mIG5l dyBwcm90b2NvbA0KZXh0ZW5zaW9ucyBpcyB0aGUgRElTUEFUQ0ggd29ya2luZyBncm91cCwgd2hp Y2ggd2lsbCBnZW5lcmFsbHkgbWFrZSB0aGUNCmRldGVybWluYXRpb24gcmVnYXJkaW5nIHdoZXRo ZXIgbmV3IFNJUC1yZWxhdGVkIHdvcmsgd2FycmFudHMgYSBuZXcNCndvcmtpbmcgZ3JvdXAgb3Ig YmVsb25ncyBpbiBhbiBleGlzdGluZyBvbmUuDQoNCg0KDQpGb3IgZWFzZSBvZiByZWZlcmVuY2Us IHRoZSBleGlzdGluZyBTSVBDT1JFIGNoYXJ0ZXIgaXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLXNpcGNvcmUvDQoNClRoYW5rcyENCg0KL2ENCg== --_000_949EF20990823C4C85C18D59AA11AD8BADFA846BFR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLmF1dGhvci1hLWx6 NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6DQoJe21zby1zdHlsZS1uYW1lOmF1 dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6O30NCnNwYW4uYXV0 aG9yLWEtbHo3Nnp6NzJ6ejY4eno3Nnpmbno4MHppY2RmcGx6ODJ6ejg0eg0KCXttc28tc3R5bGUt bmFtZTphdXRob3ItYS1sejc2eno3Mnp6Njh6ejc2emZuejgwemljZGZwbHo4Mnp6ODR6O30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UGVyaGFwcyB5b3UgY291aWxkIGVsYWJvcmF0ZSBvbiBob3cgeW91IG5vdyBz ZWUgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIFNJUENPUkUgYW5kIERJU1BBVENILiBJdCBpcyBu b3QgY2xlYXIgdG8gbWUgd2hhdCB0aGUgY3JpdGVyaWEgYXJlIGZvciBzdWJtaXR0aW5nIHNvbWV0 aGluZw0KIG5ldyB0byBESVNQQVRDSCwgdmVyc3VzIFNJUENPUkUgZGlyZWN0bHkuIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+V291bGQgZXZlcnl0aGluZyBnbyB0byBESVNQQVRDSCBmaXJzdCBhbmQgdGhlIGNoYW5nZSBo ZXJlIGlzIHRvIGFsbG93IFNJUENPUkUgdG8gdGFrZSBvbiB3b3JrIHRoYXQgaGFzIGJlZW4gZGlz cGF0Y2hlZCwgb3Igd291bGQgU0lQQ09SRSBiZSB0aGUgZmlyc3QgcG9pbnQNCiBvZiBlbnRyeSBm b3IgbWF0ZXJpYWwsIGFuZCBpZiBzbywgdG8gd2hhdCBzY29wZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZpbmFsbHks IHNvbWUgc3R1ZmYgZnJvbSBESVNQQVRDSCBoYXMgZ29uZSBkaXJlY3QgdG8gQUQgc3BvbnNvcmVk IOKAkyB3b3VsZCB5b3Ugbm93IHNlZSB0aG9zZSBiZWNvbWluZyBXRyBpdGVtcyBvZiBTSVBDT1JF LCBvciB3b3VsZCB0aGF0IHJvdXRlIHN0aWxsIGJlIGVudmlzYWdlZCwNCiBhbmQgaWYgc28sIHdv dWxkIHRoZSDigJxkaXNwYXRjaOKAnSBvY2N1ciBmcm9tIERJU1BBVENIIG9yIFNJUENPUkUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5NYXliZSB5b3UgY291bGQgdXNlIHNvbWUgcmVjZW50IGRyYWZ0cyBhbmQgUkZDcyBh cyBleGFtcGxlcyBvZiB3aGVyZSB5b3UgdGhpbmsgdGhpbmdzIHdpbGwgY2hhbmdlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+S2VpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0 ZXh0Ij4gZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5BZGFtIFJvYWNoPGJyPg0KPGI+U2VudDo8L2I+IDA0IE5vdmVtYmVyIDIw MTYgMjE6Mjg8YnI+DQo8Yj5Ubzo8L2I+ICdTSVBDT1JFJzsgZGlzcGF0Y2hAaWV0Zi5vcmc8YnI+ DQo8Yj5DYzo8L2I+IGFydC1hZHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2Rpc3Bh dGNoXSBTSVBDT1JFIFJlY2hhcnRlcmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPlth cyBTSVBDT1JFIGNoYWlyXTxvOnA+PC9vOnA+PC9wPg0KPHA+QmFjayB3aGVuIHdlIHRyYW5zaXRp b25lZCBmcm9tIHRoZSBTSVBQSU5HL1NJUCB3b3JraW5nIGdyb3VwIHN0cnVjdHVyZSB0byBTSVBD T1JFLCB3ZSBwdXQgcmVsYXRpdmVseSB0aWdodCBsaW1pdHMgb24gdGhlIFNJUENPUkUgY2hhcnRl ci4gVGhpcyB3YXMgYSByZWNvZ25pdGlvbiBvZiB0aGUgZmFjdCB0aGF0IHRoZSB2b2x1bWUgb2Yg U0lQLXJlbGF0ZWQgd29yayBhdCB0aGUgdGltZSB3YXMgdG9vIGxhcmdlIGZvciBhbnkgb25lIHdv cmtpbmcNCiBncm91cCB0byByZWFzb25hYmx5IGhhbmRsZS4gSW5zdGVhZCwgdGhlIGludGVudGlv biB3YXMgdGhhdCB0aGUgRElTUEFUQ0ggbW9kZWwgb2YgY3JlYXRpbmcgc21hbGwsIHNob3J0LWxp dmVkIHdvcmtpbmcgZ3JvdXBzIGZvciBzcGVjaWZpYyB0b3BpY3Mgd291bGQgYmUgYSBiZXR0ZXIg d2F5IHRvIG1hbmFnZSB0aGUgcmVsYXRpdmVseSBoZWF2eSB3b3JrbG9hZC48bzpwPjwvbzpwPjwv cD4NCjxwPkZhc3QgZm9yd2FyZCBzZXZlbiB5ZWFycyB0byB0b2RheS4gU0lQIGlzIGEgbXVjaCBt b3JlIG1hdHVyZSBwcm90b2NvbCwgYW5kIHRoZSBpbmZsb3cgb2YgbmV3IHdvcmsgaXMgc2lnbmlm aWNhbnRseSBzbWFsbGVyIHRoYW4gaXQgd2FzIGJhY2sgdGhlbi4gQXQgdGhlIHNhbWUgdGltZSwg d2UgaGF2ZSBoYWQgc2V2ZXJhbCBzbWFsbCwgc2VsZi1jb250YWluZWQgd29yayBpdGVtcyBzaG93 IHVwIGluIERJU1BBVENIIHRoYXQgd2VyZSBkZWVtZWQNCiB0b28gc21hbGwgdG8gY3JlYXRlIGEg bmV3IHdvcmtpbmcgZ3JvdXAgZm9yLCBidXQgcHJlY2x1ZGVkIGZyb20gYmVpbmcgZGlzcGF0Y2hl ZCB0byBTSVBDT1JFIGJ5IGl0cyBjaGFydGVyLiBUaGlzIGhhcyBsZWQgdG8gdW5uZWNlc3Nhcnkg ZGVsYXlzIGFzIHdlIGRldGVybWluZWQgdGhlIGJlc3QgZGlzcG9zaXRpb24gZm9yIHRoZXNlIGl0 ZW1zLjxvOnA+PC9vOnA+PC9wPg0KPHA+V2UsIHRoZSBTSVBDT1JFIGNoYWlycyBhbmQgYXJlYSBk aXJlY3Rvciwgc2VlayB0byBmaXggdGhhdC4gV2Ugd291bGQgbGlrZSB0byBhbWVuZCB0aGUgU0lQ Q09SRSBjaGFydGVyIHRvIGFsbG93IGl0IHRvIHRha2Ugb24gc21hbGwsIHNlbGYtY29udGFpbmVk IHByb3RvY29sIGV4dGVuc2lvbnMgaW4gYWRkaXRpb24gdG8gY2hhbmdlcyB0byB0aGUgY29yZSBT SVAgcHJvdG9jb2wuIFRoaXMgaXMgYSByZWxhdGl2ZWx5IG1pbm9yIHVwZGF0ZSB0bw0KIHRoZSBl eGlzdGluZyBjaGFydGVyLCB3aGljaCBleHBhbmRzIHRoZSBzY29wZSBhcyBkZXNjcmliZWQgYWJv dmUsIGFuZCBhZGRzIGJhY2sgaW4gdHdvIG9mIHRoZSBhcmNoaXRlY3R1cmFsIHByaW5jaXBsZXMg ZnJvbSB0aGUgU0lQIGNoYXJ0ZXIgd2hpY2ggYXJlIGFwcGxpY2FibGUgb25seSB0byBwcm90b2Nv bCBleHRlbnNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHA+UGxlYXNlIHByb3ZpZGUgZmVlZGJhY2sg b24gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYnkgc2VuZGluZyBlbWFpbCB0byB0aGUgU0lQQ09SRSBt YWlsaW5nIGxpc3QuIFdlIHdpbGwgYWxzbyBkaXNjdXNzIHRoaXMgYnJpZWZseSBkdXJpbmcgdGhl IERJU1BBVENIIHNlc3Npb24gaW4gU2VvdWwuPG86cD48L286cD48L3A+DQo8cD5UaGUgcHJvcG9z ZWQgY2hhcnRlciB0ZXh0IGZvbGxvd3MuPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdiBpZD0ibWFnaWNkb21pZDIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enox MjJ6Ij5UaGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUgKFNJUENvcmUpIHdvcmtp bmcgZ3JvdXAgaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2lj ZG9taWQzIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcw eno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+Y2hhcnRlcmVkIHRvIG1haW50YWlu IGFuZCBjb250aW51ZSB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIFNJUCBwcm90b2NvbCw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQ0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtp c216Njd6OXo4NXp6MTIyeiI+Y3VycmVudGx5IGRlZmluZWQgYXMgcHJvcG9zZWQgc3RhbmRhcmQg UkZDcyAzMjYxLCAzMjYyLCAzMjYzLCAzMjY0LCBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQ1Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+ NjY2NS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQ2 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJtYWdpY2RvbWlkNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0i YXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPlRoZSBTSVBD b3JlIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb25jZW50cmF0ZSBvbiBzcGVjaWZpY2F0aW9ucyB0aGF0 IHVwZGF0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21p ZDgiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejcz enR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6Ij5vciByZXBsYWNlIHRoZSBjb3JlIFNJUCBz cGVjaWZpY2F0aW9ucyBuYW1lZCBhYm92ZSBhcyB3ZWxsIGFzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkOSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEy MnoiPnNwZWNpZmljYXRpb25zIHBlcnRhaW5pbmcgdG8gc21hbGwsIHNlbGYtY29udGFpbmVkIFNJ UCBwcm90b2NvbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNk b21pZDEwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcw eno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+ZXh0ZW5zaW9ucy4mbmJzcDsgVGhl IHByb2Nlc3MgYW5kIHJlcXVpcmVtZW50cyBmb3IgbmV3IFNJUCBleHRlbnNpb25zIGFyZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDExIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHpl ZGtpc216Njd6OXo4NXp6MTIyeiI+ZG9jdW1lbnRlZCBpbiBSRkM1NzI3LCAmcXVvdDtDaGFuZ2Ug UHJvY2VzcyBmb3IgdGhlIFNlc3Npb24gSW5pdGlhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDEyIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIy eiI+UHJvdG9jb2wmcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJtYWdpY2RvbWlkMTMiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxNCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6 ejEyMnoiPlRocm91Z2hvdXQgaXRzIHdvcmssIHRoZSBncm91cCB3aWxsIHN0cml2ZSB0byBtYWlu dGFpbiB0aGUgYmFzaWMgbW9kZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9Im1hZ2ljZG9taWQxNSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0 aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPmFuZCBhcmNoaXRl Y3R1cmUgZGVmaW5lZCBieSBTSVAuIEluIHBhcnRpY3VsYXI6PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMTYiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxNyI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6 NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPjEuIFNlcnZpY2VzIGFuZCBmZWF0dXJlcyBhcmUgcHJv dmlkZWQgZW5kLXRvLWVuZCB3aGVuZXZlciBwb3NzaWJsZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxOCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDE5Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3 NHplZGtpc216Njd6OXo4NXp6MTIyeiI+Mi4gUmV1c2Ugb2YgZXhpc3RpbmcgSW50ZXJuZXQgcHJv dG9jb2xzIGFuZCBhcmNoaXRlY3R1cmVzIGFuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDIwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+Jm5i c3A7Jm5ic3A7IGludGVncmF0aW5nIHdpdGggb3RoZXIgSW50ZXJuZXQgYXBwbGljYXRpb25zIGlz IGNydWNpYWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2Rv bWlkMjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyMiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBj bGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPjMu IFN0YW5kYXJkcy10cmFjayBleHRlbnNpb25zIGFuZCBuZXcgZmVhdHVyZXMgbXVzdCBiZSBnZW5l cmFsbHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQy MyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6 dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPiZuYnNwOyZuYnNwOyBhcHBsaWNhYmxlLCBh bmQgbm90IGFwcGxpY2FibGUgb25seSB0byBhIHNwZWNpZmljIHNldCBvZiBzZXNzaW9uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMjQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVk a2lzbXo2N3o5ejg1enoxMjJ6Ij4mbmJzcDsmbmJzcDsgdHlwZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMjUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyNiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3Nnp6NzJ6ejY4 eno3Nnpmbno4MHppY2RmcGx6ODJ6ejg0eiI+NC4gU2ltcGxlciBzb2x1dGlvbnMgdGhhdCBzb2x2 ZSBhIGdpdmVuIHByb2JsZW0gc2hvdWxkIGJlIGZhdm9yZWQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3Nnp6NzJ6ejY4eno3Nnpmbno4MHppY2RmcGx6ODJ6ejg0 eiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG92ZXIgbW9yZSBjb21wbGV4IHNvbHV0aW9ucy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyOCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFn aWNkb21pZDI5Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1s ejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+VGhlIHByaW1hcnkgc291cmNl IG9mIGNoYW5nZSByZXF1aXJlbWVudHMgdG8gdGhlIGNvcmUgU0lQIHNwZWNpZmljYXRpb25zPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzAiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0 emVka2lzbXo2N3o5ejg1enoxMjJ6Ij4oZW51bWVyYXRlZCBhYm92ZSkgd2lsbCBiZSBhKSBpbnRl cm9wZXJhYmlsaXR5IHByb2JsZW1zIHRoYXQgc3RlbSBmcm9tPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enox MjJ6Ij5hbWJpZ3VvdXMsIG9yIHVuZGVyLWRlZmluZWQgc3BlY2lmaWNhdGlvbiwgYW5kIGIpIHJl cXVpcmVtZW50cyBmcm9tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt YWdpY2RvbWlkMzIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1h LWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6Ij5vdGhlciB3b3JraW5nIGdy b3VwcyBpbiB0aGUgQVJUIEFyZWEuIFRoZSBwcmltYXJ5IHNvdXJjZSBvZiBuZXcgcHJvdG9jb2w8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQzMyI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6 NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPmV4dGVuc2lvbnMgaXMgdGhlIERJU1BBVENIIHdvcmtp bmcgZ3JvdXAsIHdoaWNoIHdpbGwgZ2VuZXJhbGx5IG1ha2UgdGhlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1 enoxMjJ6Ij5kZXRlcm1pbmF0aW9uIHJlZ2FyZGluZyB3aGV0aGVyIG5ldyBTSVAtcmVsYXRlZCB3 b3JrIHdhcnJhbnRzIGEgbmV3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJtYWdpY2RvbWlkMzUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhv ci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6Ij53b3JraW5nIGdyb3Vw IG9yIGJlbG9uZ3MgaW4gYW4gZXhpc3Rpbmcgb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5Gb3IgZWFz ZSBvZiByZWZlcmVuY2UsIHRoZSBleGlzdGluZyBTSVBDT1JFIGNoYXJ0ZXIgaXMgYXQgPGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLXNpcGNvcmUv Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1zaXBjb3Jl LzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjxwPi9hPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_949EF20990823C4C85C18D59AA11AD8BADFA846BFR712WXCHMBA11z_-- From nobody Mon Nov 7 01:02:48 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5BC129B1E for ; Mon, 7 Nov 2016 01:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb5Ukm97KbA8 for ; Mon, 7 Nov 2016 01:02:41 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94D7129B6C for ; Mon, 7 Nov 2016 01:02:40 -0800 (PST) Received: from [10.100.100.215] (unknown [195.149.146.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 652895390; Mon, 7 Nov 2016 10:02:32 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 7 Nov 2016 10:02:26 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1C514B8A-AC4C-4105-AC61-0F9D08542DB8@edvina.net> References: To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] SIPCORE Rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 09:02:45 -0000 > On 05 Nov 2016, at 02:47, Paul Kyzivat wrote: > > I think this will be a helpful change. Fully agree. This is a change that I like. /O > > Thanks, > Paul > > On 11/4/16 5:28 PM, Adam Roach wrote: >> [as SIPCORE chair] >> >> Back when we transitioned from the SIPPING/SIP working group structure >> to SIPCORE, we put relatively tight limits on the SIPCORE charter. This >> was a recognition of the fact that the volume of SIP-related work at the >> time was too large for any one working group to reasonably handle. >> Instead, the intention was that the DISPATCH model of creating small, >> short-lived working groups for specific topics would be a better way to >> manage the relatively heavy workload. >> >> Fast forward seven years to today. SIP is a much more mature protocol, >> and the inflow of new work is significantly smaller than it was back >> then. At the same time, we have had several small, self-contained work >> items show up in DISPATCH that were deemed too small to create a new >> working group for, but precluded from being dispatched to SIPCORE by its >> charter. This has led to unnecessary delays as we determined the best >> disposition for these items. >> >> We, the SIPCORE chairs and area director, seek to fix that. We would >> like to amend the SIPCORE charter to allow it to take on small, >> self-contained protocol extensions in addition to changes to the core >> SIP protocol. This is a relatively minor update to the existing charter, >> which expands the scope as described above, and adds back in two of the >> architectural principles from the SIP charter which are applicable only >> to protocol extensions. >> >> Please provide feedback on the proposed charter by sending email to the >> SIPCORE mailing list. We will also discuss this briefly during the >> DISPATCH session in Seoul. >> >> The proposed charter text follows. >> >> >>> The Session Initiation Protocol Core (SIPCore) working group is >>> chartered to maintain and continue the development of the SIP protocol, >>> currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and >>> 6665. >>> >>> The SIPCore working group will concentrate on specifications that update >>> or replace the core SIP specifications named above as well as >>> specifications pertaining to small, self-contained SIP protocol >>> extensions. The process and requirements for new SIP extensions are >>> documented in RFC5727, "Change Process for the Session Initiation >>> Protocol". >>> >>> Throughout its work, the group will strive to maintain the basic model >>> and architecture defined by SIP. In particular: >>> >>> 1. Services and features are provided end-to-end whenever possible. >>> >>> 2. Reuse of existing Internet protocols and architectures and >>> integrating with other Internet applications is crucial. >>> >>> 3. Standards-track extensions and new features must be generally >>> applicable, and not applicable only to a specific set of session >>> types. >>> >>> 4. Simpler solutions that solve a given problem should be favored >>> over more complex solutions. >>> >>> The primary source of change requirements to the core SIP specifications >>> (enumerated above) will be a) interoperability problems that stem from >>> ambiguous, or under-defined specification, and b) requirements from >>> other working groups in the ART Area. The primary source of new protocol >>> extensions is the DISPATCH working group, which will generally make the >>> determination regarding whether new SIP-related work warrants a new >>> working group or belongs in an existing one. >> >> >> For ease of reference, the existing SIPCORE charter is at >> https://datatracker.ietf.org/doc/charter-ietf-sipcore/ >> >> Thanks! >> >> /a >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Nov 7 09:18:04 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D70129559 for ; Mon, 7 Nov 2016 09:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=qOfjRkf2; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=sXs/iYSV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifVytljFMlq0 for ; Mon, 7 Nov 2016 09:18:00 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DEE12952E for ; Mon, 7 Nov 2016 09:18:00 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 20BF32091C; Mon, 7 Nov 2016 12:18:00 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute1.internal (MEProxy); Mon, 07 Nov 2016 12:18:00 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= mesmtp; bh=kwbZRESn+Te7UnA0dyK50gSKUnU=; b=qOfjRkf2DQ0E7HTWDO1F9 MlAPV1HM3CnfwwIKlhcytpSirotsPhLBp+1tSAdlvhduAjrGLK9tRMpt2U4eJ1b3 BYrgfUtj4UYXxDfhBcZyZU9+q8a/LK/bvB2QXMjrUDFWMq7r7x+0AGgj1iNcH6MJ pgqchCiZoElrOUo99qmddE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=smtpout; bh=kwbZRESn+Te7UnA0dyK50gSKU nU=; b=sXs/iYSVWr5XeCR+oqsow7LBHgx/qzjHlzKAGeVK4qekkA1JwyaYKjv7V L7i6a3UBy5AOf/I+SZ52O41v+nKW1TiIeHy6Czl6v3UtES7wxaoL9UJkyTeCs9LW 7qf8LRcXhwxTUNE8Bh7b0OfySUztcOSyo9+2F6NgV+F7OvyI5M= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id EBD095A67B; Mon, 7 Nov 2016 12:17:59 -0500 (EST) Message-Id: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> From: Alexey Melnikov To: DISPATCH MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-b3d08dd0 Date: Mon, 07 Nov 2016 17:17:59 +0000 Archived-At: Subject: [dispatch] Request to form a new WG: JMAP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 17:18:02 -0000 Hi, I have received a request to form a new WG: JSON Mail Access Protocol (JMAP). Draft charter is included below. Please send your comments in reply to this email or directly to me. I am also looking for possible chairs for this work, so if you are interested, please contact me off-list. Thank you, Alexey ------------------------------------ Name: JSON Mail Access Protocol Acronym: jmap Area: Applications and Real-Time Area (art) Charter for Working Group Many companies and projects are developing their own JSON based representations of email which are proprietary, non-standard, and incompatible with each other. These protocols are proliferating due to existing standards being insufficient or poorly suited to the environments they are operating in, particularly mobile and webmail. The JMAP working group will specify an mechanism to allow clients to both view and send email from a server over a single stateless HTTPS channel with minimal round trips. The protocol will support out-of-band signaling of changes, and will give mobile clients significant benefits in terms of battery life and network usage. The use of multiple protocols to perform actions within a single application creates significant support challenges, as users may get a variety of partial failure modes (for example, can receive email, but can not send new messages). This is further exacerbated if the different protocols are authenticated separately. The work of this group is limited to developing a protocol for a client synchronising data with a server. Any server-to-server issues or end-to-end encryption of messages are out of scope for this working group. The working group will coordinate with the Security Area on credential management and authentication. Input to working group discussions shall include: - Internet Message Format [RFC 5322] - CONDSTORE and QRESYNC [RFC 7162] - Collection Synchronisation for WebDav [RFC 6578] - LEMONADE and experiences from adoption of its output [https://datatracker.ietf.org/wg/lemonade/charter/] - SMTP SUBMISSION [RFC 4409] - SMTP BURL [RFC 4468] The working group will deliver the following: - A problem statement detailing the deployment environment and situations that motivate work on a new protocol for client to server email synchronisation. The working group may choose not to publish this as an RFC. - A document describing an extensible protocol and data structures which supports stateless use, flood control and batched operations. - A document describing how to use the extensible protocol over HTTPS with the data structures expressed as JSON. - A document describing a data model for email viewing, management, searching, and submission on top of the extensible protocol. - An executable test suite and documented test cases to assist developers of JMAP servers to ensure they conform to the specifications. From nobody Mon Nov 7 09:42:46 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22BE1294E7 for ; Mon, 7 Nov 2016 09:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3yjYEt-mOO5 for ; Mon, 7 Nov 2016 09:42:38 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297511294A7 for ; Mon, 7 Nov 2016 09:42:38 -0800 (PST) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA7Hgb2d024176 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Mon, 7 Nov 2016 11:42:37 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: dispatch@ietf.org References: <949EF20990823C4C85C18D59AA11AD8BADFA846B@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Robert Sparks Message-ID: <89722e58-8bfe-1d07-b5ef-7e1640182b70@nostrum.com> Date: Mon, 7 Nov 2016 11:42:37 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADFA846B@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------7649D0E44672DF337F0AA05B" Archived-At: Subject: Re: [dispatch] SIPCORE Rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 17:42:44 -0000 This is a multi-part message in MIME format. --------------7649D0E44672DF337F0AA05B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit The dispatch process has always allowed new work to go directly to a working group without going through dispatch if the work fit clearly in that working group's charter. On 11/6/16 7:47 AM, Drage, Keith (Nokia - GB) wrote: > > Perhaps you couild elaborate on how you now see the relationship > between SIPCORE and DISPATCH. It is not clear to me what the criteria > are for submitting something new to DISPATCH, versus SIPCORE directly. > > Would everything go to DISPATCH first and the change here is to allow > SIPCORE to take on work that has been dispatched, or would SIPCORE be > the first point of entry for material, and if so, to what scope. > > Finally, some stuff from DISPATCH has gone direct to AD sponsored > would you now see those becoming WG items of SIPCORE, or would that > route still be envisaged, and if so, would the dispatch occur from > DISPATCH or SIPCORE. > > Maybe you could use some recent drafts and RFCs as examples of where > you think things will change. > > Keith > > *From:*dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Adam > Roach > *Sent:* 04 November 2016 21:28 > *To:* 'SIPCORE'; dispatch@ietf.org > *Cc:* art-ads@ietf.org > *Subject:* [dispatch] SIPCORE Rechartering > > [as SIPCORE chair] > > Back when we transitioned from the SIPPING/SIP working group structure > to SIPCORE, we put relatively tight limits on the SIPCORE charter. > This was a recognition of the fact that the volume of SIP-related work > at the time was too large for any one working group to reasonably > handle. Instead, the intention was that the DISPATCH model of creating > small, short-lived working groups for specific topics would be a > better way to manage the relatively heavy workload. > > Fast forward seven years to today. SIP is a much more mature protocol, > and the inflow of new work is significantly smaller than it was back > then. At the same time, we have had several small, self-contained work > items show up in DISPATCH that were deemed too small to create a new > working group for, but precluded from being dispatched to SIPCORE by > its charter. This has led to unnecessary delays as we determined the > best disposition for these items. > > We, the SIPCORE chairs and area director, seek to fix that. We would > like to amend the SIPCORE charter to allow it to take on small, > self-contained protocol extensions in addition to changes to the core > SIP protocol. This is a relatively minor update to the existing > charter, which expands the scope as described above, and adds back in > two of the architectural principles from the SIP charter which are > applicable only to protocol extensions. > > Please provide feedback on the proposed charter by sending email to > the SIPCORE mailing list. We will also discuss this briefly during the > DISPATCH session in Seoul. > > The proposed charter text follows. > > The Session Initiation Protocol Core (SIPCore) working group is > > chartered to maintain and continue the development of the SIP > protocol, > > currently defined as proposed standard RFCs 3261, 3262, 3263, > 3264, and > > 6665. > > The SIPCore working group will concentrate on specifications that > update > > or replace the core SIP specifications named above as well as > > specifications pertaining to small, self-contained SIP protocol > > extensions. The process and requirements for new SIP extensions are > > documented in RFC5727, "Change Process for the Session Initiation > > Protocol". > > Throughout its work, the group will strive to maintain the basic model > > and architecture defined by SIP. In particular: > > 1. Services and features are provided end-to-end whenever possible. > > 2. Reuse of existing Internet protocols and architectures and > > integrating with other Internet applications is crucial. > > 3. Standards-track extensions and new features must be generally > > applicable, and not applicable only to a specific set of session > > types. > > 4. Simpler solutions that solve a given problem should be favored > > over more complex solutions. > > The primary source of change requirements to the core SIP > specifications > > (enumerated above) will be a) interoperability problems that stem from > > ambiguous, or under-defined specification, and b) requirements from > > other working groups in the ART Area. The primary source of new > protocol > > extensions is the DISPATCH working group, which will generally > make the > > determination regarding whether new SIP-related work warrants a new > > working group or belongs in an existing one. > > For ease of reference, the existing SIPCORE charter is at > https://datatracker.ietf.org/doc/charter-ietf-sipcore/ > > > Thanks! > > /a > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------7649D0E44672DF337F0AA05B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

The dispatch process has always allowed new work to go directly to a working group without going through dispatch if the work fit clearly in that working group's charter.

On 11/6/16 7:47 AM, Drage, Keith (Nokia - GB) wrote:

Perhaps you couild elaborate on how you now see the relationship between SIPCORE and DISPATCH. It is not clear to me what the criteria are for submitting something new to DISPATCH, versus SIPCORE directly.

Would everything go to DISPATCH first and the change here is to allow SIPCORE to take on work that has been dispatched, or would SIPCORE be the first point of entry for material, and if so, to what scope.

Finally, some stuff from DISPATCH has gone direct to AD sponsored would you now see those becoming WG items of SIPCORE, or would that route still be envisaged, and if so, would the dispatch occur from DISPATCH or SIPCORE.

Maybe you could use some recent drafts and RFCs as examples of where you think things will change.

Keith

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 04 November 2016 21:28
To: 'SIPCORE'; dispatch@ietf.org
Cc: art-ads@ietf.org
Subject: [dispatch] SIPCORE Rechartering

[as SIPCORE chair]

Back when we transitioned from the SIPPING/SIP working group structure to SIPCORE, we put relatively tight limits on the SIPCORE charter. This was a recognition of the fact that the volume of SIP-related work at the time was too large for any one working group to reasonably handle. Instead, the intention was that the DISPATCH model of creating small, short-lived working groups for specific topics would be a better way to manage the relatively heavy workload.

Fast forward seven years to today. SIP is a much more mature protocol, and the inflow of new work is significantly smaller than it was back then. At the same time, we have had several small, self-contained work items show up in DISPATCH that were deemed too small to create a new working group for, but precluded from being dispatched to SIPCORE by its charter. This has led to unnecessary delays as we determined the best disposition for these items.

We, the SIPCORE chairs and area director, seek to fix that. We would like to amend the SIPCORE charter to allow it to take on small, self-contained protocol extensions in addition to changes to the core SIP protocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and adds back in two of the architectural principles from the SIP charter which are applicable only to protocol extensions.

Please provide feedback on the proposed charter by sending email to the SIPCORE mailing list. We will also discuss this briefly during the DISPATCH session in Seoul.

The proposed charter text follows.

The Session Initiation Protocol Core (SIPCore) working group is

chartered to maintain and continue the development of the SIP protocol,

currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and

6665.

The SIPCore working group will concentrate on specifications that update

or replace the core SIP specifications named above as well as

specifications pertaining to small, self-contained SIP protocol

extensions. The process and requirements for new SIP extensions are

documented in RFC5727, "Change Process for the Session Initiation

Protocol".

Throughout its work, the group will strive to maintain the basic model

and architecture defined by SIP. In particular:

1. Services and features are provided end-to-end whenever possible.

2. Reuse of existing Internet protocols and architectures and

integrating with other Internet applications is crucial.

3. Standards-track extensions and new features must be generally

applicable, and not applicable only to a specific set of session

types.

4. Simpler solutions that solve a given problem should be favored

over more complex solutions.

The primary source of change requirements to the core SIP specifications

(enumerated above) will be a) interoperability problems that stem from

ambiguous, or under-defined specification, and b) requirements from

other working groups in the ART Area. The primary source of new protocol

extensions is the DISPATCH working group, which will generally make the

determination regarding whether new SIP-related work warrants a new

working group or belongs in an existing one.

For ease of reference, the existing SIPCORE charter is at https://datatracker.ietf.org/doc/charter-ietf-sipcore/

Thanks!

/a



_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--------------7649D0E44672DF337F0AA05B-- From nobody Mon Nov 7 09:59:44 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544F812952E; Mon, 7 Nov 2016 09:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkz-xtX9EtSl; Mon, 7 Nov 2016 09:59:30 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8044C12956F; Mon, 7 Nov 2016 09:59:27 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 97682B770BE13; Mon, 7 Nov 2016 17:59:24 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id uA7HxPZE020681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2016 17:59:26 GMT Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id uA7HxPfi001120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Nov 2016 17:59:25 GMT Received: from [135.185.238.154] (shoonya.ih.lucent.com [135.185.238.154]) by umail.lucent.com (8.13.8/TPES) with ESMTP id uA7HxOsp004302; Mon, 7 Nov 2016 11:59:24 -0600 (CST) To: "'SIPCORE'" , "dispatch@ietf.org" References: From: "Vijay K.Gurbani" Message-ID: <6ef992f5-c559-4b51-2597-daeb54de412a@nokia-bell-labs.com> Date: Mon, 7 Nov 2016 11:59:24 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "art-ads@ietf.org" Subject: Re: [dispatch] SIPCORE Rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 17:59:43 -0000 On 11/04/2016 04:28 PM, Adam Roach wrote: > Please provide feedback on the proposed charter by sending email to the > SIPCORE mailing list. We will also discuss this briefly during the > DISPATCH session in Seoul. The change to the charter sounds reasonable. Having been a beneficiary of one of the first mini-WGs to be dispatch'ed (sipclf), the model of dispatch'ing has worked. However, in its trajectory, as Adam states, SIP is now a more mature protocol and I suspect the itches that need to be scratched have more to do with operational issues with SIP than core modifications to the protocol itself. Seems reasonable to perform such tweaks in sipcore. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@bell-labs.com / vijay.gurbani@nokia-bell-labs.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Mon Nov 7 14:03:43 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296001299B2 for ; Mon, 7 Nov 2016 14:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zBcP2YOw3nP for ; Mon, 7 Nov 2016 14:03:41 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by ietfa.amsl.com (Postfix) with ESMTP id B3316129699 for ; Mon, 7 Nov 2016 14:03:40 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d52 with ME id 59w81u00S17Lgi4039w930; Mon, 07 Nov 2016 22:56:10 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Mon, 07 Nov 2016 22:56:10 +0100 X-ME-IP: 92.170.5.52 To: ietf-smtp@ietf.org, "'imapext@ietf.org'" , dispatch@ietf.org References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <56DA516EAC53C07E3F453BA6@JcK-HP8200> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: Date: Mon, 7 Nov 2016 22:56:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <56DA516EAC53C07E3F453BA6@JcK-HP8200> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Request to form a new WG: JMAP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 22:03:42 -0000 Hi all, > (2) Some of us believe, at least on some days, that a key reason > why SMTP, the message formats that started with RFC 822, POP3, > and IMAP have survived against a large number of proprietary and > other SDO alternatives have been precisely because they operate > in plain text, with all but IMAP using very simple > command-argument or name:value syntax. Are we ready to give > that up? Do we really need interoperability between a server > and a captive Webmail interface? Arguably, standards of that > type are part of the province of the IETF only if someone is > contemplating generic webmail clients that can interact with the > servers of more than one organization. My two cents here: someone proposed 2 years ago a similar model for NNTP. It was named... JNTP (Json News Transfer Protocol). Here is its current "specification" (in French): http://www.nemoweb.net/?page_id=75 with even an RFC-like format: http://www.nemoweb.net/?p=1295 And, as John hinted at, people get then stuck in exchanges between an NNTP server and a captive webnews interface like: http://news.nemoweb.net/ Since 2014, no much move for JNTP, which is still used only by his creator. Like SMTP and IMAP, NNTP operates in plain text. A great advantage over other alternatives. > Again, just questions, but questions I think we need to ask > carefully before standardizing yet another alternative way to do > much the same thing. +1 -- Julien LIE Vous ramassez des champignons sans les connatre ? Et alors ? Ce n'est pas pour les manger mais pour les vendre. From nobody Mon Nov 7 14:36:51 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105791299C5 for ; Mon, 7 Nov 2016 14:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXg9eXkDy1pu for ; Mon, 7 Nov 2016 14:36:45 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60334129A3E for ; Mon, 7 Nov 2016 14:36:43 -0800 (PST) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA7MagWG049611 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 7 Nov 2016 16:36:42 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Robert Sparks" Date: Mon, 07 Nov 2016 16:36:41 -0600 Message-ID: <65A526AD-EF4B-47C3-94EE-2D9803A2C0F7@nostrum.com> In-Reply-To: <89722e58-8bfe-1d07-b5ef-7e1640182b70@nostrum.com> References: <949EF20990823C4C85C18D59AA11AD8BADFA846B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <89722e58-8bfe-1d07-b5ef-7e1640182b70@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B179D68D-AD39-49DE-A77D-69892EDB1EF4_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[889, 16569], "plain":[383, 5081], "uuid":"D788A00B-2E7E-47B1-A970-94A510FA432C"}] X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] SIPCORE Rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 22:36:49 -0000 --=_MailMate_B179D68D-AD39-49DE-A77D-69892EDB1EF4_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit What Robert said. Additionally, new work still requires working group consensus and AD agreement, so there's a lot of backstops to avoid getting this horribly wrong. Do people read the "Primary source of requirements" language to prevent that? I read "primary" to suggest that there may be non-enumerated "secondary" sources. Ben. On 7 Nov 2016, at 11:42, Robert Sparks wrote: > The dispatch process has always allowed new work to go directly to a > working group without going through dispatch if the work fit clearly > in that working group's charter. > > On 11/6/16 7:47 AM, Drage, Keith (Nokia - GB) wrote: >> >> Perhaps you couild elaborate on how you now see the relationship >> between SIPCORE and DISPATCH. It is not clear to me what the criteria >> are for submitting something new to DISPATCH, versus SIPCORE >> directly. >> >> Would everything go to DISPATCH first and the change here is to allow >> SIPCORE to take on work that has been dispatched, or would SIPCORE be >> the first point of entry for material, and if so, to what scope. >> >> Finally, some stuff from DISPATCH has gone direct to AD sponsored – >> would you now see those becoming WG items of SIPCORE, or would that >> route still be envisaged, and if so, would the “dispatch” occur >> from DISPATCH or SIPCORE. >> >> Maybe you could use some recent drafts and RFCs as examples of where >> you think things will change. >> >> Keith >> >> *From:*dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of >> *Adam Roach >> *Sent:* 04 November 2016 21:28 >> *To:* 'SIPCORE'; dispatch@ietf.org >> *Cc:* art-ads@ietf.org >> *Subject:* [dispatch] SIPCORE Rechartering >> >> [as SIPCORE chair] >> >> Back when we transitioned from the SIPPING/SIP working group >> structure to SIPCORE, we put relatively tight limits on the SIPCORE >> charter. This was a recognition of the fact that the volume of >> SIP-related work at the time was too large for any one working group >> to reasonably handle. Instead, the intention was that the DISPATCH >> model of creating small, short-lived working groups for specific >> topics would be a better way to manage the relatively heavy workload. >> >> Fast forward seven years to today. SIP is a much more mature >> protocol, and the inflow of new work is significantly smaller than it >> was back then. At the same time, we have had several small, >> self-contained work items show up in DISPATCH that were deemed too >> small to create a new working group for, but precluded from being >> dispatched to SIPCORE by its charter. This has led to unnecessary >> delays as we determined the best disposition for these items. >> >> We, the SIPCORE chairs and area director, seek to fix that. We would >> like to amend the SIPCORE charter to allow it to take on small, >> self-contained protocol extensions in addition to changes to the core >> SIP protocol. This is a relatively minor update to the existing >> charter, which expands the scope as described above, and adds back in >> two of the architectural principles from the SIP charter which are >> applicable only to protocol extensions. >> >> Please provide feedback on the proposed charter by sending email to >> the SIPCORE mailing list. We will also discuss this briefly during >> the DISPATCH session in Seoul. >> >> The proposed charter text follows. >> >> The Session Initiation Protocol Core (SIPCore) working group is >> >> chartered to maintain and continue the development of the SIP >> protocol, >> >> currently defined as proposed standard RFCs 3261, 3262, 3263, >> 3264, and >> >> 6665. >> >> The SIPCore working group will concentrate on specifications that >> update >> >> or replace the core SIP specifications named above as well as >> >> specifications pertaining to small, self-contained SIP protocol >> >> extensions. The process and requirements for new SIP extensions >> are >> >> documented in RFC5727, "Change Process for the Session Initiation >> >> Protocol". >> >> Throughout its work, the group will strive to maintain the basic >> model >> >> and architecture defined by SIP. In particular: >> >> 1. Services and features are provided end-to-end whenever >> possible. >> >> 2. Reuse of existing Internet protocols and architectures and >> >> integrating with other Internet applications is crucial. >> >> 3. Standards-track extensions and new features must be generally >> >> applicable, and not applicable only to a specific set of session >> >> types. >> >> 4. Simpler solutions that solve a given problem should be favored >> >> over more complex solutions. >> >> The primary source of change requirements to the core SIP >> specifications >> >> (enumerated above) will be a) interoperability problems that stem >> from >> >> ambiguous, or under-defined specification, and b) requirements >> from >> >> other working groups in the ART Area. The primary source of new >> protocol >> >> extensions is the DISPATCH working group, which will generally >> make the >> >> determination regarding whether new SIP-related work warrants a >> new >> >> working group or belongs in an existing one. >> >> For ease of reference, the existing SIPCORE charter is at >> https://datatracker.ietf.org/doc/charter-ietf-sipcore/ >> >> >> Thanks! >> >> /a >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=_MailMate_B179D68D-AD39-49DE-A77D-69892EDB1EF4_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
What Robert said. Additionally, new work still require= s working group consensus and AD agreement, so there's a lot of backstops= to avoid getting this horribly wrong.
Do people read the "Primary source of requirement= s" language to prevent that? I read "primary" to suggest that there may b= e non-enumerated "secondary" sources.
Ben.
On 7 Nov 2016, at 11:42, Robert Sparks wrote:

The dispatch process has always allowed new work to go directly to a working group without going through dispatch if the work fit clearly in that working group's charter.

On 11/6/16 7:47 AM, Drage, Keith (Noki= a - GB) wrote:

Perhaps you couild elaborate on how you now see the relationship between SIPCORE and DISPATCH. It is not clear to me what the criteria are for submitting something new to DISPATCH, versus SIPCORE directly.

=C2=A0

Would everything go to DISPATCH first and the change here is to allow SIPCORE to take on work that has been dispatched, or would SIPCORE be the first point of entry for material, and if so, to what scope.

=C2=A0

Finally, some stuff from DISPATCH has gone direct to AD sponsored =E2=80= =93 would you now see those becoming WG items of SIPCORE, or would that route still be envisaged, and if so, would the =E2=80=9Cdispatch=E2=80=9D occur from DISPATCH or SIPCORE.

=C2=A0

Maybe you could use some recent drafts and RFCs as examples of where you think things will change.

=C2=A0

Keith

=C2=A0

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 04 November 2016 21:28
To: 'SIPCORE'; dispatch@ietf.org
Cc: art-ads@ietf.org
Subject: [dispatch] SIPCORE Rechartering

=C2=A0

[as SIPCORE chair]

Back when we transitioned from the SIPPING/SIP working group structure to SIPCORE, we put relatively tight limits on the SIPCORE charter. This was a recognition of the fact that the volume of SIP-related work at the time was too large for any one working group to reasonably handle. Instead, the intention was that the DISPATCH model of creating small, short-lived working groups for specific topics would be a better way to manage the relatively heavy workload.

Fast forward seven years to today. SIP is a much more mature protocol, and the inflow of new work is significantly smaller than it was back then. At the same time, we have had several small, self-contained work items show up in DISPATCH that were deemed too small to create a new working group for, but precluded from being dispatched to SIPCORE by its charter. This has led to unnecessary delays as we determined the best disposition for these items.

We, the SIPCORE chairs and area director, seek to fix that. We would like to amend the SIPCORE charter to allow it to take on small, self-contained protocol extensions in addition to changes to the core SIP protocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and adds back in two of the architectural principles from the SIP charter which are applicable only to protocol extensions.

Please provide feedback on the proposed charter by sending email to the SIPCORE mailing list. We will also discuss this briefly during the DISPATCH session in Seoul.

The proposed charter text follows.

=C2=A0

The Session Initiation Protocol Core (SIPCore) working group is

chartered to maintain and continue the development of the SIP protocol,

currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and

6665.

=C2=A0

The SIPCore working group will concentrate on specifications that update

or replace the core SIP specifications named above as well as

specifications pertaining to small, self-contained SIP protocol

extensions.=C2=A0 The process and requirements for new SIP extensions are

documented in RFC5727, "Change Process for the Session Initiation

Protocol".

=C2=A0

Throughout its work, the group will strive to maintain the basic model

and architecture defined by SIP. In particular:

=C2=A0

1. Services and features are provided end-to-end whenever possible.

=C2=A0

2. Reuse of existing Internet protocols and architectures and

=C2=A0=C2=A0 integrating with other Internet applications is crucial.<= /span>

=C2=A0

3. Standards-track extensions and new features must be generally

=C2=A0=C2=A0 applicable, and not applicable only to a specific set of session

=C2=A0=C2=A0 types.

=C2=A0

= 4. Simpler solutions that solve a given problem should be favored

= =C2=A0=C2=A0=C2=A0 over more complex solutions.

=C2=A0

The primary source of change requirements to the core SIP specifications

(enumerated above) will be a) interoperability problems that stem from

ambiguous, or under-defined specification, and b) requirements from<= /span>

other working groups in the ART Area. The primary source of new protocol

extensions is the DISPATCH working group, which will generally make the

determination regarding whether new SIP-related work warrants a new

working group or belongs in an existing one.

=C2=A0

For ease of reference, the existing SIPCORE charter is at https://datatracker.ietf.org/doc/charter-ietf-sipcore/

Thanks!

/a



_______________________________________________
dispatch mailing list
d=
ispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

___________________________= ____________________
dispatch mailing list
dispatch@ietf.org
--=_MailMate_B179D68D-AD39-49DE-A77D-69892EDB1EF4_=-- From nobody Mon Nov 7 14:45:41 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D391C1296B1 for ; Mon, 7 Nov 2016 14:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqxM0ua17LHh for ; Mon, 7 Nov 2016 14:45:38 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3501299F3 for ; Mon, 7 Nov 2016 14:45:38 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1CAE822E1FA; Mon, 7 Nov 2016 17:45:26 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Mark Nottingham In-Reply-To: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> Date: Tue, 8 Nov 2016 09:45:22 +1100 Content-Transfer-Encoding: 7bit Message-Id: <335136F0-0C6F-4A59-B3F1-6504CCC7AF00@mnot.net> References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3251) Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Request to form a new WG: JMAP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 22:45:40 -0000 > On 8 Nov. 2016, at 4:17 am, Alexey Melnikov wrote: > > Many companies and projects are developing their own JSON based > representations of email which are proprietary, non-standard, and > incompatible with each other. These protocols are proliferating It would be helpful to see some examples of this. -- Mark Nottingham https://www.mnot.net/ From nobody Mon Nov 7 15:05:20 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A249F129B85; Mon, 7 Nov 2016 15:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7ulwVC76Cka; Mon, 7 Nov 2016 15:05:16 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F12129BAF; Mon, 7 Nov 2016 15:05:08 -0800 (PST) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA7N56Wa051923 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 7 Nov 2016 17:05:07 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: SIPCORE Date: Mon, 07 Nov 2016 17:05:06 -0600 Message-ID: <2581BBD3-557C-4BD2-B6A7-CC472FB06038@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_D0419DDD-97D5-4FFF-92FD-557E0D4BDDB2_=" Embedded-HTML: [{"HTML":[870, 8196], "plain":[273, 3405], "uuid":"1600C0CA-5C8A-43AB-B0D1-5C23687E04E7"}] X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: "art-ads@ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] SIPCORE Rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 23:05:19 -0000 --=_MailMate_D0419DDD-97D5-4FFF-92FD-557E0D4BDDB2_= Content-Type: text/plain; format=flowed The proposed new SIPCORE charter text is now available at https://datatracker.ietf.org/doc/charter-ietf-sipcore/ . It's identical to the text from Adam's email, other than some potential formatting differences. Thanks! Ben. On 4 Nov 2016, at 16:28, Adam Roach wrote: > [as SIPCORE chair] > > Back when we transitioned from the SIPPING/SIP working group structure > to SIPCORE, we put relatively tight limits on the SIPCORE charter. > This was a recognition of the fact that the volume of SIP-related work > at the time was too large for any one working group to reasonably > handle. Instead, the intention was that the DISPATCH model of creating > small, short-lived working groups for specific topics would be a > better way to manage the relatively heavy workload. > > Fast forward seven years to today. SIP is a much more mature protocol, > and the inflow of new work is significantly smaller than it was back > then. At the same time, we have had several small, self-contained work > items show up in DISPATCH that were deemed too small to create a new > working group for, but precluded from being dispatched to SIPCORE by > its charter. This has led to unnecessary delays as we determined the > best disposition for these items. > > We, the SIPCORE chairs and area director, seek to fix that. We would > like to amend the SIPCORE charter to allow it to take on small, > self-contained protocol extensions in addition to changes to the core > SIP protocol. This is a relatively minor update to the existing > charter, which expands the scope as described above, and adds back in > two of the architectural principles from the SIP charter which are > applicable only to protocol extensions. > > Please provide feedback on the proposed charter by sending email to > the SIPCORE mailing list. We will also discuss this briefly during the > DISPATCH session in Seoul. > > The proposed charter text follows. > >> The Session Initiation Protocol Core (SIPCore) working group is >> chartered to maintain and continue the development of the SIP >> protocol, >> currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, >> and >> 6665. >> >> The SIPCore working group will concentrate on specifications that >> update >> or replace the core SIP specifications named above as well as >> specifications pertaining to small, self-contained SIP protocol >> extensions. The process and requirements for new SIP extensions are >> documented in RFC5727, "Change Process for the Session Initiation >> Protocol". >> >> Throughout its work, the group will strive to maintain the basic >> model >> and architecture defined by SIP. In particular: >> >> 1. Services and features are provided end-to-end whenever possible. >> >> 2. Reuse of existing Internet protocols and architectures and >> integrating with other Internet applications is crucial. >> >> 3. Standards-track extensions and new features must be generally >> applicable, and not applicable only to a specific set of session >> types. >> >> 4. Simpler solutions that solve a given problem should be favored >> over more complex solutions. >> >> The primary source of change requirements to the core SIP >> specifications >> (enumerated above) will be a) interoperability problems that stem >> from >> ambiguous, or under-defined specification, and b) requirements from >> other working groups in the ART Area. The primary source of new >> protocol >> extensions is the DISPATCH working group, which will generally make >> the >> determination regarding whether new SIP-related work warrants a new >> working group or belongs in an existing one. > > For ease of reference, the existing SIPCORE charter is at > https://datatracker.ietf.org/doc/charter-ietf-sipcore/ > > Thanks! > > /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=_MailMate_D0419DDD-97D5-4FFF-92FD-557E0D4BDDB2_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The proposed new SIPCORE charter text is now available= at https://datatracker.ietf.org/doc/charter-ietf-sipco= re/ . It's identical to the text from Adam's email, other than some p= otential formatting differences.
Thanks!
Ben.
On 4 Nov 2016, at 16:28, Adam Roach wrote:

[as SIPCORE chair]

Back when we transitioned from the SIPPING/SIP working group structure to SIPCORE, we put relatively tight limits on the SIPCORE charter. This was a recognition of the fact that the volume of SIP-related work at the time was too large for any one working group to reasonably handle. Instead, the intention was that the DISPATCH model of creating small, short-lived working groups for specific topics would be a better way to manage the relatively heavy workload.

Fast forward seven years to today. SIP is a much more mature protocol, and the inflow of new work is significantly smaller than it was back then. At the same time, we have had several small, self-contained work items show up in DISPATCH that were deemed too small to create a new working group for, but precluded from being dispatched to SIPCORE by its charter. This has led to unnecessary delays as we determined the best disposition for these items.

We, the SIPCORE chairs and area director, seek to fix that. We would like to amend the SIPCORE charter to allow it to take on small, self-contained protocol extensions in addition to changes to the core SIP protocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and adds back in two of the architectural principles from the SIP charter which are applicable only to protocol extensions.

Please provide feedback on the proposed charter by sending email to the SIPCORE mailing list. We will also discuss this briefly during the DISPATCH session in Seoul.

The proposed charter text follows.


The= Session Initiation Protocol Core (SIPCore) working group is
cha= rtered to maintain and continue the development of the SIP protocol,
cur= rently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and
666= 5.

The= SIPCore working group will concentrate on specifications that update
or replace the core SIP specifications named above as well as
spe= cifications pertaining to small, self-contained SIP protocol
=
ext= ensions.=C2=A0 The process and requirements for new SIP extensions are
doc= umented in RFC5727, "Change Process for the Session Initiation=
Pro= tocol".

Thr= oughout its work, the group will strive to maintain the basic model
and= architecture defined by SIP. In particular:

1. Services and features are provided end-to-end whenever possible.

2. Reuse of existing Internet protocols and architectures and
=C2= =A0=C2=A0 integrating with other Internet applications is crucial.

3. Standards-track extensions and new features must be generally
=C2= =A0=C2=A0 applicable, and not applicable only to a specific set of session
=C2= =A0=C2=A0 types.

4. Simpler solutions that solve a given problem should be favored
=C2=A0= =C2=A0=C2=A0 over more complex solutions.

The= primary source of change requirements to the core SIP specifications
(en= umerated above) will be a) interoperability problems that stem from
amb= iguous, or under-defined specification, and b) requirements from
oth= er working groups in the ART Area. The primary source of new protocol
ext= ensions is the DISPATCH working group, which will generally make the<= /span>
det= ermination regarding whether new SIP-related work warrants a new<= /div>
wor= king group or belongs in an existing one.


For ease of reference, the existing SIPCORE charter is at https://datatracker.ietf.org/doc/charte= r-ietf-sipcore/

Thanks!

/a

___________________________= ____________________
dispatch mailing list
dispatch@ietf.org
--=_MailMate_D0419DDD-97D5-4FFF-92FD-557E0D4BDDB2_=-- From nobody Mon Nov 7 16:34:50 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B73129522 for ; Mon, 7 Nov 2016 16:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.891 X-Spam-Level: X-Spam-Status: No, score=-6.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIq46FHsrFvJ for ; Mon, 7 Nov 2016 16:34:46 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC845129538 for ; Mon, 7 Nov 2016 16:34:45 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 4FFF9E89DADAA; Tue, 8 Nov 2016 00:34:39 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA80YgIS014126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Nov 2016 00:34:43 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA80Yfhw010080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Nov 2016 01:34:42 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.214]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Tue, 8 Nov 2016 01:34:41 +0100 From: "Drage, Keith (Nokia - GB)" To: Ben Campbell , Robert Sparks Thread-Topic: [dispatch] SIPCORE Rechartering Thread-Index: AQHSNuJbof3GUTb0uE6yIgkvbI355qDL81hQgAHKx4CAAFIqgIAAIEBA Date: Tue, 8 Nov 2016 00:34:41 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADFA91B2@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADFA846B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <89722e58-8bfe-1d07-b5ef-7e1640182b70@nostrum.com> <65A526AD-EF4B-47C3-94EE-2D9803A2C0F7@nostrum.com> In-Reply-To: <65A526AD-EF4B-47C3-94EE-2D9803A2C0F7@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADFA91B2FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPCORE Rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 00:34:49 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADFA91B2FR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHRoaW5rIFJvYmVydCBoYXMgYW5zd2VyZWQgdGhlIHF1ZXN0aW9ucyBJIGFza2Vk Lg0KDQpBbmQgSSBhbSBhbHNvIG5vdCBwYXJ0aWN1bGFybHkgd29ycmllZCBhYm91dCB0aGUgYmFj a3N0b3BzLg0KDQpJIGFtIHdvcnJpZWQgYWJvdXQgdGhlIG51bWJlciBvZiBjeWNsZXMgaXQgZ2V0 cyB0byBnZXQgc29tZXRoaW5nIGRpc2N1c3NlZCBpbiB3aGF0IHRoZSByZWNpcGllbnRzIGNvbnNp ZGVyIHRvIGJlIHRoZSByaWdodCB3b3JraW5nIGdyb3VwLCBzbyBJIGFtIGludGVyZXN0ZWQgaW4g d2hldGhlciB0aGUgZGlzdGluY3Rpb24gaW4gd2hhdCBnb2VzIHRvIERJU1BBVENIIHZlcnN1cyB3 aGF0IGdvZXMgdG8gU0lQQ09SRSBpcyBhYnNvbHV0ZWx5IGNsZWFyLldlIGRvIG5vdCBuZWVkIGRv Y3VtZW50cyBnb2luZyB0byBESVNQQVRDSCBhbmQgYmVpbmcgYm91bmNlZCB0byBTSVBDT1JFIGFu ZCB2aWNlLXZlcnNhLCBwYXJ0aWN1bGFybHkgaWYgdGhhdCB0YWtlcyB0d28gb3IgdGhyZWUgbWVl dGluZyBjeWNsZXMgdG8gZ28gcm91bmQgdGhhdCBsb29wLg0KDQpGdXJ0aGVyIGRvZXMgdGhlIGNy aXRlcmlhIG9mIHdoYXQgbWlnaHQgYmUgQUQgc3BvbnNvcmVkIG5vdyBjaGFuZ2UgYmVjYXVzZSB0 aGlzIGV4dHJhIHJvdXRlIGhhcyBub3cgYmVlbiBjcmVhdGVkIC8gZW1waGFzaXNlZD8gQW5kIGRv ZXMgU0lQQ09SRSBoYXZlIHRoZSBtYW5kYXRlIHRvIGFzayBhbiBBRCB0byBkbyB0aGlzIGZvciBh biBpbnB1dCBkcmFmdCBpbiB0aGUgc2FtZSB3YXkgYXMgRElTUEFUQ0ggbWlnaHQgaGF2ZSBkb25l Pw0KDQpLZWl0aA0KDQpGcm9tOiBkaXNwYXRjaCBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW4gQ2FtcGJlbGwNClNlbnQ6IDA3IE5vdmVtYmVyIDIwMTYg MjI6MzcNClRvOiBSb2JlcnQgU3BhcmtzDQpDYzogZGlzcGF0Y2hAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbZGlzcGF0Y2hdIFNJUENPUkUgUmVjaGFydGVyaW5nDQoNCldoYXQgUm9iZXJ0IHNhaWQu IEFkZGl0aW9uYWxseSwgbmV3IHdvcmsgc3RpbGwgcmVxdWlyZXMgd29ya2luZyBncm91cCBjb25z ZW5zdXMgYW5kIEFEIGFncmVlbWVudCwgc28gdGhlcmUncyBhIGxvdCBvZiBiYWNrc3RvcHMgdG8g YXZvaWQgZ2V0dGluZyB0aGlzIGhvcnJpYmx5IHdyb25nLg0KRG8gcGVvcGxlIHJlYWQgdGhlICJQ cmltYXJ5IHNvdXJjZSBvZiByZXF1aXJlbWVudHMiIGxhbmd1YWdlIHRvIHByZXZlbnQgdGhhdD8g SSByZWFkICJwcmltYXJ5IiB0byBzdWdnZXN0IHRoYXQgdGhlcmUgbWF5IGJlIG5vbi1lbnVtZXJh dGVkICJzZWNvbmRhcnkiIHNvdXJjZXMuDQpCZW4uDQpPbiA3IE5vdiAyMDE2LCBhdCAxMTo0Miwg Um9iZXJ0IFNwYXJrcyB3cm90ZToNCg0KVGhlIGRpc3BhdGNoIHByb2Nlc3MgaGFzIGFsd2F5cyBh bGxvd2VkIG5ldyB3b3JrIHRvIGdvIGRpcmVjdGx5IHRvIGEgd29ya2luZyBncm91cCB3aXRob3V0 IGdvaW5nIHRocm91Z2ggZGlzcGF0Y2ggaWYgdGhlIHdvcmsgZml0IGNsZWFybHkgaW4gdGhhdCB3 b3JraW5nIGdyb3VwJ3MgY2hhcnRlci4NCk9uIDExLzYvMTYgNzo0NyBBTSwgRHJhZ2UsIEtlaXRo IChOb2tpYSAtIEdCKSB3cm90ZToNClBlcmhhcHMgeW91IGNvdWlsZCBlbGFib3JhdGUgb24gaG93 IHlvdSBub3cgc2VlIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBTSVBDT1JFIGFuZCBESVNQQVRD SC4gSXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoYXQgdGhlIGNyaXRlcmlhIGFyZSBmb3Igc3VibWl0 dGluZyBzb21ldGhpbmcgbmV3IHRvIERJU1BBVENILCB2ZXJzdXMgU0lQQ09SRSBkaXJlY3RseS4N Cg0KV291bGQgZXZlcnl0aGluZyBnbyB0byBESVNQQVRDSCBmaXJzdCBhbmQgdGhlIGNoYW5nZSBo ZXJlIGlzIHRvIGFsbG93IFNJUENPUkUgdG8gdGFrZSBvbiB3b3JrIHRoYXQgaGFzIGJlZW4gZGlz cGF0Y2hlZCwgb3Igd291bGQgU0lQQ09SRSBiZSB0aGUgZmlyc3QgcG9pbnQgb2YgZW50cnkgZm9y IG1hdGVyaWFsLCBhbmQgaWYgc28sIHRvIHdoYXQgc2NvcGUuDQoNCkZpbmFsbHksIHNvbWUgc3R1 ZmYgZnJvbSBESVNQQVRDSCBoYXMgZ29uZSBkaXJlY3QgdG8gQUQgc3BvbnNvcmVkIOKAkyB3b3Vs ZCB5b3Ugbm93IHNlZSB0aG9zZSBiZWNvbWluZyBXRyBpdGVtcyBvZiBTSVBDT1JFLCBvciB3b3Vs ZCB0aGF0IHJvdXRlIHN0aWxsIGJlIGVudmlzYWdlZCwgYW5kIGlmIHNvLCB3b3VsZCB0aGUg4oCc ZGlzcGF0Y2jigJ0gb2NjdXIgZnJvbSBESVNQQVRDSCBvciBTSVBDT1JFLg0KDQpNYXliZSB5b3Ug Y291bGQgdXNlIHNvbWUgcmVjZW50IGRyYWZ0cyBhbmQgUkZDcyBhcyBleGFtcGxlcyBvZiB3aGVy ZSB5b3UgdGhpbmsgdGhpbmdzIHdpbGwgY2hhbmdlLg0KDQpLZWl0aA0KDQpGcm9tOiBkaXNwYXRj aCBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZGFtIFJv YWNoDQpTZW50OiAwNCBOb3ZlbWJlciAyMDE2IDIxOjI4DQpUbzogJ1NJUENPUkUnOyBkaXNwYXRj aEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+DQpDYzogYXJ0LWFkc0BpZXRmLm9y ZzxtYWlsdG86YXJ0LWFkc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtkaXNwYXRjaF0gU0lQQ09SRSBS ZWNoYXJ0ZXJpbmcNCg0KDQpbYXMgU0lQQ09SRSBjaGFpcl0NCg0KQmFjayB3aGVuIHdlIHRyYW5z aXRpb25lZCBmcm9tIHRoZSBTSVBQSU5HL1NJUCB3b3JraW5nIGdyb3VwIHN0cnVjdHVyZSB0byBT SVBDT1JFLCB3ZSBwdXQgcmVsYXRpdmVseSB0aWdodCBsaW1pdHMgb24gdGhlIFNJUENPUkUgY2hh cnRlci4gVGhpcyB3YXMgYSByZWNvZ25pdGlvbiBvZiB0aGUgZmFjdCB0aGF0IHRoZSB2b2x1bWUg b2YgU0lQLXJlbGF0ZWQgd29yayBhdCB0aGUgdGltZSB3YXMgdG9vIGxhcmdlIGZvciBhbnkgb25l IHdvcmtpbmcgZ3JvdXAgdG8gcmVhc29uYWJseSBoYW5kbGUuIEluc3RlYWQsIHRoZSBpbnRlbnRp b24gd2FzIHRoYXQgdGhlIERJU1BBVENIIG1vZGVsIG9mIGNyZWF0aW5nIHNtYWxsLCBzaG9ydC1s aXZlZCB3b3JraW5nIGdyb3VwcyBmb3Igc3BlY2lmaWMgdG9waWNzIHdvdWxkIGJlIGEgYmV0dGVy IHdheSB0byBtYW5hZ2UgdGhlIHJlbGF0aXZlbHkgaGVhdnkgd29ya2xvYWQuDQoNCkZhc3QgZm9y d2FyZCBzZXZlbiB5ZWFycyB0byB0b2RheS4gU0lQIGlzIGEgbXVjaCBtb3JlIG1hdHVyZSBwcm90 b2NvbCwgYW5kIHRoZSBpbmZsb3cgb2YgbmV3IHdvcmsgaXMgc2lnbmlmaWNhbnRseSBzbWFsbGVy IHRoYW4gaXQgd2FzIGJhY2sgdGhlbi4gQXQgdGhlIHNhbWUgdGltZSwgd2UgaGF2ZSBoYWQgc2V2 ZXJhbCBzbWFsbCwgc2VsZi1jb250YWluZWQgd29yayBpdGVtcyBzaG93IHVwIGluIERJU1BBVENI IHRoYXQgd2VyZSBkZWVtZWQgdG9vIHNtYWxsIHRvIGNyZWF0ZSBhIG5ldyB3b3JraW5nIGdyb3Vw IGZvciwgYnV0IHByZWNsdWRlZCBmcm9tIGJlaW5nIGRpc3BhdGNoZWQgdG8gU0lQQ09SRSBieSBp dHMgY2hhcnRlci4gVGhpcyBoYXMgbGVkIHRvIHVubmVjZXNzYXJ5IGRlbGF5cyBhcyB3ZSBkZXRl cm1pbmVkIHRoZSBiZXN0IGRpc3Bvc2l0aW9uIGZvciB0aGVzZSBpdGVtcy4NCg0KV2UsIHRoZSBT SVBDT1JFIGNoYWlycyBhbmQgYXJlYSBkaXJlY3Rvciwgc2VlayB0byBmaXggdGhhdC4gV2Ugd291 bGQgbGlrZSB0byBhbWVuZCB0aGUgU0lQQ09SRSBjaGFydGVyIHRvIGFsbG93IGl0IHRvIHRha2Ug b24gc21hbGwsIHNlbGYtY29udGFpbmVkIHByb3RvY29sIGV4dGVuc2lvbnMgaW4gYWRkaXRpb24g dG8gY2hhbmdlcyB0byB0aGUgY29yZSBTSVAgcHJvdG9jb2wuIFRoaXMgaXMgYSByZWxhdGl2ZWx5 IG1pbm9yIHVwZGF0ZSB0byB0aGUgZXhpc3RpbmcgY2hhcnRlciwgd2hpY2ggZXhwYW5kcyB0aGUg c2NvcGUgYXMgZGVzY3JpYmVkIGFib3ZlLCBhbmQgYWRkcyBiYWNrIGluIHR3byBvZiB0aGUgYXJj aGl0ZWN0dXJhbCBwcmluY2lwbGVzIGZyb20gdGhlIFNJUCBjaGFydGVyIHdoaWNoIGFyZSBhcHBs aWNhYmxlIG9ubHkgdG8gcHJvdG9jb2wgZXh0ZW5zaW9ucy4NCg0KUGxlYXNlIHByb3ZpZGUgZmVl ZGJhY2sgb24gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYnkgc2VuZGluZyBlbWFpbCB0byB0aGUgU0lQ Q09SRSBtYWlsaW5nIGxpc3QuIFdlIHdpbGwgYWxzbyBkaXNjdXNzIHRoaXMgYnJpZWZseSBkdXJp bmcgdGhlIERJU1BBVENIIHNlc3Npb24gaW4gU2VvdWwuDQoNClRoZSBwcm9wb3NlZCBjaGFydGVy IHRleHQgZm9sbG93cy4NCg0KDQpUaGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUg KFNJUENvcmUpIHdvcmtpbmcgZ3JvdXAgaXMNCmNoYXJ0ZXJlZCB0byBtYWludGFpbiBhbmQgY29u dGludWUgdGhlIGRldmVsb3BtZW50IG9mIHRoZSBTSVAgcHJvdG9jb2wsDQpjdXJyZW50bHkgZGVm aW5lZCBhcyBwcm9wb3NlZCBzdGFuZGFyZCBSRkNzIDMyNjEsIDMyNjIsIDMyNjMsIDMyNjQsIGFu ZA0KNjY2NS4NCg0KVGhlIFNJUENvcmUgd29ya2luZyBncm91cCB3aWxsIGNvbmNlbnRyYXRlIG9u IHNwZWNpZmljYXRpb25zIHRoYXQgdXBkYXRlDQpvciByZXBsYWNlIHRoZSBjb3JlIFNJUCBzcGVj aWZpY2F0aW9ucyBuYW1lZCBhYm92ZSBhcyB3ZWxsIGFzDQpzcGVjaWZpY2F0aW9ucyBwZXJ0YWlu aW5nIHRvIHNtYWxsLCBzZWxmLWNvbnRhaW5lZCBTSVAgcHJvdG9jb2wNCmV4dGVuc2lvbnMuICBU aGUgcHJvY2VzcyBhbmQgcmVxdWlyZW1lbnRzIGZvciBuZXcgU0lQIGV4dGVuc2lvbnMgYXJlDQpk b2N1bWVudGVkIGluIFJGQzU3MjcsICJDaGFuZ2UgUHJvY2VzcyBmb3IgdGhlIFNlc3Npb24gSW5p dGlhdGlvbg0KUHJvdG9jb2wiLg0KDQpUaHJvdWdob3V0IGl0cyB3b3JrLCB0aGUgZ3JvdXAgd2ls bCBzdHJpdmUgdG8gbWFpbnRhaW4gdGhlIGJhc2ljIG1vZGVsDQphbmQgYXJjaGl0ZWN0dXJlIGRl ZmluZWQgYnkgU0lQLiBJbiBwYXJ0aWN1bGFyOg0KDQoxLiBTZXJ2aWNlcyBhbmQgZmVhdHVyZXMg YXJlIHByb3ZpZGVkIGVuZC10by1lbmQgd2hlbmV2ZXIgcG9zc2libGUuDQoNCjIuIFJldXNlIG9m IGV4aXN0aW5nIEludGVybmV0IHByb3RvY29scyBhbmQgYXJjaGl0ZWN0dXJlcyBhbmQNCiAgIGlu dGVncmF0aW5nIHdpdGggb3RoZXIgSW50ZXJuZXQgYXBwbGljYXRpb25zIGlzIGNydWNpYWwuDQoN CjMuIFN0YW5kYXJkcy10cmFjayBleHRlbnNpb25zIGFuZCBuZXcgZmVhdHVyZXMgbXVzdCBiZSBn ZW5lcmFsbHkNCiAgIGFwcGxpY2FibGUsIGFuZCBub3QgYXBwbGljYWJsZSBvbmx5IHRvIGEgc3Bl Y2lmaWMgc2V0IG9mIHNlc3Npb24NCiAgIHR5cGVzLg0KDQo0LiBTaW1wbGVyIHNvbHV0aW9ucyB0 aGF0IHNvbHZlIGEgZ2l2ZW4gcHJvYmxlbSBzaG91bGQgYmUgZmF2b3JlZA0KICAgIG92ZXIgbW9y ZSBjb21wbGV4IHNvbHV0aW9ucy4NCg0KVGhlIHByaW1hcnkgc291cmNlIG9mIGNoYW5nZSByZXF1 aXJlbWVudHMgdG8gdGhlIGNvcmUgU0lQIHNwZWNpZmljYXRpb25zDQooZW51bWVyYXRlZCBhYm92 ZSkgd2lsbCBiZSBhKSBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zIHRoYXQgc3RlbSBmcm9tDQph bWJpZ3VvdXMsIG9yIHVuZGVyLWRlZmluZWQgc3BlY2lmaWNhdGlvbiwgYW5kIGIpIHJlcXVpcmVt ZW50cyBmcm9tDQpvdGhlciB3b3JraW5nIGdyb3VwcyBpbiB0aGUgQVJUIEFyZWEuIFRoZSBwcmlt YXJ5IHNvdXJjZSBvZiBuZXcgcHJvdG9jb2wNCmV4dGVuc2lvbnMgaXMgdGhlIERJU1BBVENIIHdv cmtpbmcgZ3JvdXAsIHdoaWNoIHdpbGwgZ2VuZXJhbGx5IG1ha2UgdGhlDQpkZXRlcm1pbmF0aW9u IHJlZ2FyZGluZyB3aGV0aGVyIG5ldyBTSVAtcmVsYXRlZCB3b3JrIHdhcnJhbnRzIGEgbmV3DQp3 b3JraW5nIGdyb3VwIG9yIGJlbG9uZ3MgaW4gYW4gZXhpc3Rpbmcgb25lLg0KDQoNCg0KRm9yIGVh c2Ugb2YgcmVmZXJlbmNlLCB0aGUgZXhpc3RpbmcgU0lQQ09SRSBjaGFydGVyIGlzIGF0IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1zaXBjb3JlLw0KDQpUaGFu a3MhDQoNCi9hDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KDQpkaXNwYXRjaEBpZXRmLm9yZzxt YWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGlzcGF0Y2gNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmc8bWFp bHRvOmRpc3BhdGNoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kaXNwYXRjaA0K --_000_949EF20990823C4C85C18D59AA11AD8BADFA91B2FR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnBy ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9 DQpzcGFuLmF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6DQoJ e21zby1zdHlsZS1uYW1lOmF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1 enoxMjJ6O30NCnNwYW4uYXV0aG9yLWEtbHo3Nnp6NzJ6ejY4eno3Nnpmbno4MHppY2RmcGx6ODJ6 ejg0eg0KCXttc28tc3R5bGUtbmFtZTphdXRob3ItYS1sejc2eno3Mnp6Njh6ejc2emZuejgwemlj ZGZwbHo4Mnp6ODR6O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpi bGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgZG9u4oCZdCB0aGluayBSb2JlcnQgaGFzIGFuc3dlcmVkIHRoZSBxdWVzdGlvbnMg SSBhc2tlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCBJIGFtIGFsc28gbm90IHBhcnRpY3VsYXJseSB3b3JyaWVk IGFib3V0IHRoZSBiYWNrc3RvcHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIHdvcnJpZWQgYWJvdXQgdGhlIG51 bWJlciBvZiBjeWNsZXMgaXQgZ2V0cyB0byBnZXQgc29tZXRoaW5nIGRpc2N1c3NlZCBpbiB3aGF0 IHRoZSByZWNpcGllbnRzIGNvbnNpZGVyIHRvIGJlIHRoZSByaWdodCB3b3JraW5nIGdyb3VwLCBz byBJIGFtIGludGVyZXN0ZWQNCiBpbiB3aGV0aGVyIHRoZSBkaXN0aW5jdGlvbiBpbiB3aGF0IGdv ZXMgdG8gRElTUEFUQ0ggdmVyc3VzIHdoYXQgZ29lcyB0byBTSVBDT1JFIGlzIGFic29sdXRlbHkg Y2xlYXIuV2UgZG8gbm90IG5lZWQgZG9jdW1lbnRzIGdvaW5nIHRvIERJU1BBVENIIGFuZCBiZWlu ZyBib3VuY2VkIHRvIFNJUENPUkUgYW5kIHZpY2UtdmVyc2EsIHBhcnRpY3VsYXJseSBpZiB0aGF0 IHRha2VzIHR3byBvciB0aHJlZSBtZWV0aW5nIGN5Y2xlcyB0byBnbyByb3VuZCB0aGF0DQogbG9v cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkZ1cnRoZXIgZG9lcyB0aGUgY3JpdGVyaWEgb2Ygd2hhdCBtaWdodCBiZSBB RCBzcG9uc29yZWQgbm93IGNoYW5nZSBiZWNhdXNlIHRoaXMgZXh0cmEgcm91dGUgaGFzIG5vdyBi ZWVuIGNyZWF0ZWQgLyBlbXBoYXNpc2VkPyBBbmQgZG9lcyBTSVBDT1JFIGhhdmUgdGhlIG1hbmRh dGUNCiB0byBhc2sgYW4gQUQgdG8gZG8gdGhpcyBmb3IgYW4gaW5wdXQgZHJhZnQgaW4gdGhlIHNh bWUgd2F5IGFzIERJU1BBVENIIG1pZ2h0IGhhdmUgZG9uZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPktlaXRoPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IGRpc3BhdGNo IFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ QmVuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IDA3IE5vdmVtYmVyIDIwMTYgMjI6Mzc8YnI+ DQo8Yj5Ubzo8L2I+IFJvYmVydCBTcGFya3M8YnI+DQo8Yj5DYzo8L2I+IGRpc3BhdGNoQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZGlzcGF0Y2hdIFNJUENPUkUgUmVjaGFydGVy aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldoYXQgUm9iZXJ0IHNhaWQuIEFkZGl0aW9uYWxseSwg bmV3IHdvcmsgc3RpbGwgcmVxdWlyZXMgd29ya2luZyBncm91cCBjb25zZW5zdXMgYW5kIEFEIGFn cmVlbWVudCwgc28gdGhlcmUncyBhIGxvdCBvZiBiYWNrc3RvcHMgdG8gYXZvaWQgZ2V0dGluZyB0 aGlzIGhvcnJpYmx5IHdyb25nLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRvIHBlb3BsZSByZWFkIHRoZSAmcXVv dDtQcmltYXJ5IHNvdXJjZSBvZiByZXF1aXJlbWVudHMmcXVvdDsgbGFuZ3VhZ2UgdG8gcHJldmVu dCB0aGF0PyBJIHJlYWQgJnF1b3Q7cHJpbWFyeSZxdW90OyB0byBzdWdnZXN0IHRoYXQgdGhlcmUg bWF5IGJlIG5vbi1lbnVtZXJhdGVkICZxdW90O3NlY29uZGFyeSZxdW90OyBzb3VyY2VzLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkJlbi4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIDcgTm92IDIwMTYsIGF0IDExOjQyLCBSb2Jl cnQgU3BhcmtzIHdyb3RlOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjNzc3Nzc3 IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbTozLjc1cHQiPg0KPGRpdiBpZD0iRDc4OEEwMEItMkU3RS00 N0IxLUE5NzAtOTRBNTEwRkE0MzJDIj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNzc3Nzc3 Ij5UaGUgZGlzcGF0Y2ggcHJvY2VzcyBoYXMgYWx3YXlzIGFsbG93ZWQgbmV3IHdvcmsgdG8gZ28g ZGlyZWN0bHkgdG8gYSB3b3JraW5nIGdyb3VwIHdpdGhvdXQgZ29pbmcgdGhyb3VnaCBkaXNwYXRj aCBpZiB0aGUgd29yayBmaXQgY2xlYXJseSBpbiB0aGF0IHdvcmtpbmcgZ3JvdXAncyBjaGFydGVy LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNzc3Nzc3Ij5PbiAxMS82LzE2IDc6NDcgQU0sIERyYWdlLCBLZWl0aCAoTm9r aWEgLSBHQikgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Q ZXJoYXBzIHlvdSBjb3VpbGQgZWxhYm9yYXRlIG9uIGhvdyB5b3Ugbm93IHNlZSB0aGUgcmVsYXRp b25zaGlwIGJldHdlZW4gU0lQQ09SRSBhbmQgRElTUEFUQ0guIEl0IGlzIG5vdCBjbGVhciB0byBt ZSB3aGF0IHRoZSBjcml0ZXJpYSBhcmUgZm9yIHN1Ym1pdHRpbmcgc29tZXRoaW5nDQogbmV3IHRv IERJU1BBVENILCB2ZXJzdXMgU0lQQ09SRSBkaXJlY3RseS4gPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Xb3VsZCBldmVy eXRoaW5nIGdvIHRvIERJU1BBVENIIGZpcnN0IGFuZCB0aGUgY2hhbmdlIGhlcmUgaXMgdG8gYWxs b3cgU0lQQ09SRSB0byB0YWtlIG9uIHdvcmsgdGhhdCBoYXMgYmVlbiBkaXNwYXRjaGVkLCBvciB3 b3VsZCBTSVBDT1JFIGJlIHRoZSBmaXJzdCBwb2ludA0KIG9mIGVudHJ5IGZvciBtYXRlcmlhbCwg YW5kIGlmIHNvLCB0byB3aGF0IHNjb3BlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RmluYWxseSwgc29tZSBzdHVmZiBm cm9tIERJU1BBVENIIGhhcyBnb25lIGRpcmVjdCB0byBBRCBzcG9uc29yZWQg4oCTIHdvdWxkIHlv dSBub3cgc2VlIHRob3NlIGJlY29taW5nIFdHIGl0ZW1zIG9mIFNJUENPUkUsIG9yIHdvdWxkIHRo YXQgcm91dGUgc3RpbGwgYmUgZW52aXNhZ2VkLA0KIGFuZCBpZiBzbywgd291bGQgdGhlIOKAnGRp c3BhdGNo4oCdIG9jY3VyIGZyb20gRElTUEFUQ0ggb3IgU0lQQ09SRS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1heWJl IHlvdSBjb3VsZCB1c2Ugc29tZSByZWNlbnQgZHJhZnRzIGFuZCBSRkNzIGFzIGV4YW1wbGVzIG9m IHdoZXJlIHlvdSB0aGluayB0aGluZ3Mgd2lsbCBjaGFuZ2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5LZWl0aDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBkaXNwYXRj aCBbPGEgaHJlZj0ibWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaXNw YXRjaC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWRhbSBSb2Fj aDxicj4NCjxiPlNlbnQ6PC9iPiAwNCBOb3ZlbWJlciAyMDE2IDIxOjI4PGJyPg0KPGI+VG86PC9i PiAnU0lQQ09SRSc7IDxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZyI+ZGlzcGF0Y2hA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86YXJ0LWFkc0BpZXRm Lm9yZyI+YXJ0LWFkc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2Rpc3BhdGNo XSBTSVBDT1JFIFJlY2hhcnRlcmluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlthcyBT SVBDT1JFIGNoYWlyXTxvOnA+PC9vOnA+PC9wPg0KPHA+QmFjayB3aGVuIHdlIHRyYW5zaXRpb25l ZCBmcm9tIHRoZSBTSVBQSU5HL1NJUCB3b3JraW5nIGdyb3VwIHN0cnVjdHVyZSB0byBTSVBDT1JF LCB3ZSBwdXQgcmVsYXRpdmVseSB0aWdodCBsaW1pdHMgb24gdGhlIFNJUENPUkUgY2hhcnRlci4g VGhpcyB3YXMgYSByZWNvZ25pdGlvbiBvZiB0aGUgZmFjdCB0aGF0IHRoZSB2b2x1bWUgb2YgU0lQ LXJlbGF0ZWQgd29yayBhdCB0aGUgdGltZSB3YXMgdG9vIGxhcmdlIGZvciBhbnkgb25lIHdvcmtp bmcNCiBncm91cCB0byByZWFzb25hYmx5IGhhbmRsZS4gSW5zdGVhZCwgdGhlIGludGVudGlvbiB3 YXMgdGhhdCB0aGUgRElTUEFUQ0ggbW9kZWwgb2YgY3JlYXRpbmcgc21hbGwsIHNob3J0LWxpdmVk IHdvcmtpbmcgZ3JvdXBzIGZvciBzcGVjaWZpYyB0b3BpY3Mgd291bGQgYmUgYSBiZXR0ZXIgd2F5 IHRvIG1hbmFnZSB0aGUgcmVsYXRpdmVseSBoZWF2eSB3b3JrbG9hZC48bzpwPjwvbzpwPjwvcD4N CjxwPkZhc3QgZm9yd2FyZCBzZXZlbiB5ZWFycyB0byB0b2RheS4gU0lQIGlzIGEgbXVjaCBtb3Jl IG1hdHVyZSBwcm90b2NvbCwgYW5kIHRoZSBpbmZsb3cgb2YgbmV3IHdvcmsgaXMgc2lnbmlmaWNh bnRseSBzbWFsbGVyIHRoYW4gaXQgd2FzIGJhY2sgdGhlbi4gQXQgdGhlIHNhbWUgdGltZSwgd2Ug aGF2ZSBoYWQgc2V2ZXJhbCBzbWFsbCwgc2VsZi1jb250YWluZWQgd29yayBpdGVtcyBzaG93IHVw IGluIERJU1BBVENIIHRoYXQgd2VyZSBkZWVtZWQNCiB0b28gc21hbGwgdG8gY3JlYXRlIGEgbmV3 IHdvcmtpbmcgZ3JvdXAgZm9yLCBidXQgcHJlY2x1ZGVkIGZyb20gYmVpbmcgZGlzcGF0Y2hlZCB0 byBTSVBDT1JFIGJ5IGl0cyBjaGFydGVyLiBUaGlzIGhhcyBsZWQgdG8gdW5uZWNlc3NhcnkgZGVs YXlzIGFzIHdlIGRldGVybWluZWQgdGhlIGJlc3QgZGlzcG9zaXRpb24gZm9yIHRoZXNlIGl0ZW1z LjxvOnA+PC9vOnA+PC9wPg0KPHA+V2UsIHRoZSBTSVBDT1JFIGNoYWlycyBhbmQgYXJlYSBkaXJl Y3Rvciwgc2VlayB0byBmaXggdGhhdC4gV2Ugd291bGQgbGlrZSB0byBhbWVuZCB0aGUgU0lQQ09S RSBjaGFydGVyIHRvIGFsbG93IGl0IHRvIHRha2Ugb24gc21hbGwsIHNlbGYtY29udGFpbmVkIHBy b3RvY29sIGV4dGVuc2lvbnMgaW4gYWRkaXRpb24gdG8gY2hhbmdlcyB0byB0aGUgY29yZSBTSVAg cHJvdG9jb2wuIFRoaXMgaXMgYSByZWxhdGl2ZWx5IG1pbm9yIHVwZGF0ZSB0bw0KIHRoZSBleGlz dGluZyBjaGFydGVyLCB3aGljaCBleHBhbmRzIHRoZSBzY29wZSBhcyBkZXNjcmliZWQgYWJvdmUs IGFuZCBhZGRzIGJhY2sgaW4gdHdvIG9mIHRoZSBhcmNoaXRlY3R1cmFsIHByaW5jaXBsZXMgZnJv bSB0aGUgU0lQIGNoYXJ0ZXIgd2hpY2ggYXJlIGFwcGxpY2FibGUgb25seSB0byBwcm90b2NvbCBl eHRlbnNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHA+UGxlYXNlIHByb3ZpZGUgZmVlZGJhY2sgb24g dGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYnkgc2VuZGluZyBlbWFpbCB0byB0aGUgU0lQQ09SRSBtYWls aW5nIGxpc3QuIFdlIHdpbGwgYWxzbyBkaXNjdXNzIHRoaXMgYnJpZWZseSBkdXJpbmcgdGhlIERJ U1BBVENIIHNlc3Npb24gaW4gU2VvdWwuPG86cD48L286cD48L3A+DQo8cD5UaGUgcHJvcG9zZWQg Y2hhcnRlciB0ZXh0IGZvbGxvd3MuPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdiBpZD0ibWFnaWNkb21pZDIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6 Ij5UaGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUgKFNJUENvcmUpIHdvcmtpbmcg Z3JvdXAgaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9t aWQzIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3 M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+Y2hhcnRlcmVkIHRvIG1haW50YWluIGFu ZCBjb250aW51ZSB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIFNJUCBwcm90b2NvbCw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQ0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216 Njd6OXo4NXp6MTIyeiI+Y3VycmVudGx5IGRlZmluZWQgYXMgcHJvcG9zZWQgc3RhbmRhcmQgUkZD cyAzMjYxLCAzMjYyLCAzMjYzLCAzMjY0LCBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQ1Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+NjY2 NS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQ2Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJtYWdpY2RvbWlkNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0 aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPlRoZSBTSVBDb3Jl IHdvcmtpbmcgZ3JvdXAgd2lsbCBjb25jZW50cmF0ZSBvbiBzcGVjaWZpY2F0aW9ucyB0aGF0IHVw ZGF0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDgi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6 NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6Ij5vciByZXBsYWNlIHRoZSBjb3JlIFNJUCBzcGVj aWZpY2F0aW9ucyBuYW1lZCBhYm92ZSBhcyB3ZWxsIGFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkOSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoi PnNwZWNpZmljYXRpb25zIHBlcnRhaW5pbmcgdG8gc21hbGwsIHNlbGYtY29udGFpbmVkIFNJUCBw cm90b2NvbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21p ZDEwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3 M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+ZXh0ZW5zaW9ucy4mbmJzcDsgVGhlIHBy b2Nlc3MgYW5kIHJlcXVpcmVtZW50cyBmb3IgbmV3IFNJUCBleHRlbnNpb25zIGFyZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDExIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtp c216Njd6OXo4NXp6MTIyeiI+ZG9jdW1lbnRlZCBpbiBSRkM1NzI3LCAmcXVvdDtDaGFuZ2UgUHJv Y2VzcyBmb3IgdGhlIFNlc3Npb24gSW5pdGlhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDEyIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+ UHJvdG9jb2wmcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt YWdpY2RvbWlkMTMiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxNCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEy MnoiPlRocm91Z2hvdXQgaXRzIHdvcmssIHRoZSBncm91cCB3aWxsIHN0cml2ZSB0byBtYWludGFp biB0aGUgYmFzaWMgbW9kZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 Im1hZ2ljZG9taWQxNSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9y LWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPmFuZCBhcmNoaXRlY3R1 cmUgZGVmaW5lZCBieSBTSVAuIEluIHBhcnRpY3VsYXI6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMTYiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxNyI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6 ZWRraXNtejY3ejl6ODV6ejEyMnoiPjEuIFNlcnZpY2VzIGFuZCBmZWF0dXJlcyBhcmUgcHJvdmlk ZWQgZW5kLXRvLWVuZCB3aGVuZXZlciBwb3NzaWJsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxOCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDE5Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHpl ZGtpc216Njd6OXo4NXp6MTIyeiI+Mi4gUmV1c2Ugb2YgZXhpc3RpbmcgSW50ZXJuZXQgcHJvdG9j b2xzIGFuZCBhcmNoaXRlY3R1cmVzIGFuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0ibWFnaWNkb21pZDIwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNz PSJhdXRob3ItYS1sejcweno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+Jm5ic3A7 Jm5ic3A7IGludGVncmF0aW5nIHdpdGggb3RoZXIgSW50ZXJuZXQgYXBwbGljYXRpb25zIGlzIGNy dWNpYWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlk MjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9Im1hZ2ljZG9taWQyMiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFz cz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPjMuIFN0 YW5kYXJkcy10cmFjayBleHRlbnNpb25zIGFuZCBuZXcgZmVhdHVyZXMgbXVzdCBiZSBnZW5lcmFs bHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyMyI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3 M3p6NzR6ZWRraXNtejY3ejl6ODV6ejEyMnoiPiZuYnNwOyZuYnNwOyBhcHBsaWNhYmxlLCBhbmQg bm90IGFwcGxpY2FibGUgb25seSB0byBhIHNwZWNpZmljIHNldCBvZiBzZXNzaW9uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMjQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lz bXo2N3o5ejg1enoxMjJ6Ij4mbmJzcDsmbmJzcDsgdHlwZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMjUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyNiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3Nnp6NzJ6ejY4eno3 Nnpmbno4MHppY2RmcGx6ODJ6ejg0eiI+NC4gU2ltcGxlciBzb2x1dGlvbnMgdGhhdCBzb2x2ZSBh IGdpdmVuIHByb2JsZW0gc2hvdWxkIGJlIGZhdm9yZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iYXV0aG9yLWEtbHo3Nnp6NzJ6ejY4eno3Nnpmbno4MHppY2RmcGx6ODJ6ejg0eiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IG92ZXIgbW9yZSBjb21wbGV4IHNvbHV0aW9ucy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyOCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNk b21pZDI5Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejcw eno3M3p0ejczeno3NHplZGtpc216Njd6OXo4NXp6MTIyeiI+VGhlIHByaW1hcnkgc291cmNlIG9m IGNoYW5nZSByZXF1aXJlbWVudHMgdG8gdGhlIGNvcmUgU0lQIHNwZWNpZmljYXRpb25zPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzAiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVk a2lzbXo2N3o5ejg1enoxMjJ6Ij4oZW51bWVyYXRlZCBhYm92ZSkgd2lsbCBiZSBhKSBpbnRlcm9w ZXJhYmlsaXR5IHByb2JsZW1zIHRoYXQgc3RlbSBmcm9tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6 Ij5hbWJpZ3VvdXMsIG9yIHVuZGVyLWRlZmluZWQgc3BlY2lmaWNhdGlvbiwgYW5kIGIpIHJlcXVp cmVtZW50cyBmcm9tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdp Y2RvbWlkMzIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6 NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6Ij5vdGhlciB3b3JraW5nIGdyb3Vw cyBpbiB0aGUgQVJUIEFyZWEuIFRoZSBwcmltYXJ5IHNvdXJjZSBvZiBuZXcgcHJvdG9jb2w8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQzMyI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo3MHp6NzN6dHo3M3p6NzR6 ZWRraXNtejY3ejl6ODV6ejEyMnoiPmV4dGVuc2lvbnMgaXMgdGhlIERJU1BBVENIIHdvcmtpbmcg Z3JvdXAsIHdoaWNoIHdpbGwgZ2VuZXJhbGx5IG1ha2UgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enox MjJ6Ij5kZXRlcm1pbmF0aW9uIHJlZ2FyZGluZyB3aGV0aGVyIG5ldyBTSVAtcmVsYXRlZCB3b3Jr IHdhcnJhbnRzIGEgbmV3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt YWdpY2RvbWlkMzUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1h LWx6NzB6ejczenR6NzN6ejc0emVka2lzbXo2N3o5ejg1enoxMjJ6Ij53b3JraW5nIGdyb3VwIG9y IGJlbG9uZ3MgaW4gYW4gZXhpc3Rpbmcgb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5Gb3IgZWFzZSBv ZiByZWZlcmVuY2UsIHRoZSBleGlzdGluZyBTSVBDT1JFIGNoYXJ0ZXIgaXMgYXQgPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLXNpcGNvcmUvIj4N Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1zaXBjb3JlLzwv YT48bzpwPjwvbzpwPjwvcD4NCjxwPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjxwPi9hPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNzc3Nzc3Ij48 YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjojNzc3Nzc3Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 Izc3Nzc3NyI+ZGlzcGF0Y2ggbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hA aWV0Zi5vcmciPmRpc3BhdGNoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaXNwYXRjaDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3Nzc3NzciPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICM3Nzc3NzcgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDowY207 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjMuNzVwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izc3Nzc3NyI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3Nzc3NzciPmRp c3BhdGNoIG1haWxpbmcgbGlzdA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izc3Nzc3NyI+PGEgaHJlZj0i bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnIj5kaXNwYXRjaEBpZXRmLm9yZzwvYT4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM3Nzc3NzciPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGlzcGF0Y2giPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPC9zcGFuPjwvYT4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_949EF20990823C4C85C18D59AA11AD8BADFA91B2FR712WXCHMBA11z_-- From nobody Mon Nov 7 18:19:51 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1508D1295A1 for ; Mon, 7 Nov 2016 18:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Qo6hliHcOKS for ; Mon, 7 Nov 2016 18:19:47 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED59B12960A for ; Mon, 7 Nov 2016 18:19:46 -0800 (PST) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA82JjpC068139 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 7 Nov 2016 20:19:46 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Drage, Keith" Date: Mon, 07 Nov 2016 20:19:45 -0600 Message-ID: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADFA91B2@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADFA846B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <89722e58-8bfe-1d07-b5ef-7e1640182b70@nostrum.com> <65A526AD-EF4B-47C3-94EE-2D9803A2C0F7@nostrum.com> <949EF20990823C4C85C18D59AA11AD8BADFA91B2@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPCORE Rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 02:19:50 -0000 On 7 Nov 2016, at 18:34, Drage, Keith (Nokia - GB) wrote: > I don’t think Robert has answered the questions I asked. > > And I am also not particularly worried about the backstops. > > I am worried about the number of cycles it gets to get something > discussed in what the recipients consider to be the right working > group, so I am interested in whether the distinction in what goes to > DISPATCH versus what goes to SIPCORE is absolutely clear.We do not > need documents going to DISPATCH and being bounced to SIPCORE and > vice-versa, particularly if that takes two or three meeting cycles to > go round that loop. I don't think we can make bright lines here. The best we can do is give guidance. But In general, I expect things that are entirely SIP, relatively small and self-contained, and don't propose or imply material changes to the SIP architecture would go to SIPCORE. Work where this is not the case, or where it's simply not clear if it's the case, would go to DISPATCH. If someone takes work to DISPATCH that could have simply gone to SIPCORE, I expect that the participants (and chairs and ADs) will be quick to recommend the work be moved over with minimal red-tape. The kind of work that can take several meeting cycles (and we should remember that DISPATCH, like any other WG, has a mailing list and need not wait for meetings) is usually the sort of thing that either does not have sufficient interest, spans multiple technologies, or is otherwise not obvious how to address. That sort of thing shouldn't start out in sipcore. > > Further does the criteria of what might be AD sponsored now change > because this extra route has now been created / emphasised? And does > SIPCORE have the mandate to ask an AD to do this for an input draft in > the same way as DISPATCH might have done? The criteria for AD sponsored is that an AD agrees to sponsor it. That being said, any working group can suggest that a piece of work be AD sponsored. Will this impact what ADs agree to sponsor? I think it might in a few cases. Speaking only for myself, I have sponsored a few drafts that I probably would have suggested go to SIPCORE if the proposed charter had been in effect. For a recent example (not intending to pick on Christer): draft-holmberg-dispatch-received-realm. > > Keith > > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben > Campbell > Sent: 07 November 2016 22:37 > To: Robert Sparks > Cc: dispatch@ietf.org > Subject: Re: [dispatch] SIPCORE Rechartering > > What Robert said. Additionally, new work still requires working group > consensus and AD agreement, so there's a lot of backstops to avoid > getting this horribly wrong. > Do people read the "Primary source of requirements" language to > prevent that? I read "primary" to suggest that there may be > non-enumerated "secondary" sources. > Ben. > On 7 Nov 2016, at 11:42, Robert Sparks wrote: > > The dispatch process has always allowed new work to go directly to a > working group without going through dispatch if the work fit clearly > in that working group's charter. > On 11/6/16 7:47 AM, Drage, Keith (Nokia - GB) wrote: > Perhaps you couild elaborate on how you now see the relationship > between SIPCORE and DISPATCH. It is not clear to me what the criteria > are for submitting something new to DISPATCH, versus SIPCORE directly. > > Would everything go to DISPATCH first and the change here is to allow > SIPCORE to take on work that has been dispatched, or would SIPCORE be > the first point of entry for material, and if so, to what scope. > > Finally, some stuff from DISPATCH has gone direct to AD sponsored – > would you now see those becoming WG items of SIPCORE, or would that > route still be envisaged, and if so, would the “dispatch” occur > from DISPATCH or SIPCORE. > > Maybe you could use some recent drafts and RFCs as examples of where > you think things will change. > > Keith > > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam > Roach > Sent: 04 November 2016 21:28 > To: 'SIPCORE'; dispatch@ietf.org > Cc: art-ads@ietf.org > Subject: [dispatch] SIPCORE Rechartering > > [as SIPCORE chair] > > Back when we transitioned from the SIPPING/SIP working group structure > to SIPCORE, we put relatively tight limits on the SIPCORE charter. > This was a recognition of the fact that the volume of SIP-related work > at the time was too large for any one working group to reasonably > handle. Instead, the intention was that the DISPATCH model of creating > small, short-lived working groups for specific topics would be a > better way to manage the relatively heavy workload. > > Fast forward seven years to today. SIP is a much more mature protocol, > and the inflow of new work is significantly smaller than it was back > then. At the same time, we have had several small, self-contained work > items show up in DISPATCH that were deemed too small to create a new > working group for, but precluded from being dispatched to SIPCORE by > its charter. This has led to unnecessary delays as we determined the > best disposition for these items. > > We, the SIPCORE chairs and area director, seek to fix that. We would > like to amend the SIPCORE charter to allow it to take on small, > self-contained protocol extensions in addition to changes to the core > SIP protocol. This is a relatively minor update to the existing > charter, which expands the scope as described above, and adds back in > two of the architectural principles from the SIP charter which are > applicable only to protocol extensions. > > Please provide feedback on the proposed charter by sending email to > the SIPCORE mailing list. We will also discuss this briefly during the > DISPATCH session in Seoul. > > The proposed charter text follows. > > The Session Initiation Protocol Core (SIPCore) working group is > chartered to maintain and continue the development of the SIP > protocol, > currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, > and > 6665. > > The SIPCore working group will concentrate on specifications that > update > or replace the core SIP specifications named above as well as > specifications pertaining to small, self-contained SIP protocol > extensions. The process and requirements for new SIP extensions are > documented in RFC5727, "Change Process for the Session Initiation > Protocol". > > Throughout its work, the group will strive to maintain the basic model > and architecture defined by SIP. In particular: > > 1. Services and features are provided end-to-end whenever possible. > > 2. Reuse of existing Internet protocols and architectures and > integrating with other Internet applications is crucial. > > 3. Standards-track extensions and new features must be generally > applicable, and not applicable only to a specific set of session > types. > > 4. Simpler solutions that solve a given problem should be favored > over more complex solutions. > > The primary source of change requirements to the core SIP > specifications > (enumerated above) will be a) interoperability problems that stem from > ambiguous, or under-defined specification, and b) requirements from > other working groups in the ART Area. The primary source of new > protocol > extensions is the DISPATCH working group, which will generally make > the > determination regarding whether new SIP-related work warrants a new > working group or belongs in an existing one. > > For ease of reference, the existing SIPCORE charter is at > https://datatracker.ietf.org/doc/charter-ietf-sipcore/ > > Thanks! > > /a > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Nov 8 00:25:32 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957BB129625 for ; Tue, 8 Nov 2016 00:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opendkim.org header.b=ZsKO6B8M; dkim=pass (1024-bit key) header.d=elandsys.com header.b=0ZuequV/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2yjtCI_3eQx for ; Tue, 8 Nov 2016 00:25:28 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 829C71295C1 for ; Tue, 8 Nov 2016 00:25:28 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.227.86.223]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id uA88PBsu024878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Nov 2016 00:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1478593527; x=1478679927; bh=xRU1MlhdIKwS3VoRxVVPUuQFytNAgJ7xk5qp057VhHA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZsKO6B8MADOmlq4WbkjXPPsnsnrP+gUiv9gsUbIYLhxLMXTfhIS3MwniUzQ8f2ksP RRgFWt0HP0N3pC1v6DeopPFLMYiEmNpYtOKB2BxK+zuf+VazTT+XcAoX/k5s04iaVc njPZd3jvDtprXdEmqCEtRrbGXENbZOSno3TaGKTs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1478593527; x=1478679927; i=@elandsys.com; bh=xRU1MlhdIKwS3VoRxVVPUuQFytNAgJ7xk5qp057VhHA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0ZuequV/z6E1L600IyFM62tsho4+i75ZP/UCjz62wBRMBzZmmjJ00TJU1pUu0gs76 yzlcM+w4prFTYs81oiHWbclXbVruw5AGo4whaLl8mIEzBBR+/5tEAtXfWRQ3cZ6Xvk 5i6RJ8bdKYEdxOFXX9BuRchynlfvVoBcPFiuIX2w= Message-Id: <6.2.5.6.2.20161108001509.0dad36f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 08 Nov 2016 00:24:46 -0800 To: Alexey Melnikov From: S Moonesamy In-Reply-To: References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Request to form a new WG: JMAP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 08:25:29 -0000 Hi Alexey, At 09:31 07-11-2016, Alexey Melnikov wrote: >Please post your comments/questions to dispatch@ietf.org or directly to me. I dropped the other two mailing lists from the Cc. >I have received a request to form a new WG: JSON Mail Access Protocol >(JMAP). Draft charter is included below. Please send your comments in >reply to this email or directly to me. > >I am also looking for possible chairs for this work, so if you are >interested, please contact me off-list. > >Thank you, >Alexey > >------------------------------------ > >Name: JSON Mail Access Protocol >Acronym: jmap >Area: Applications and Real-Time Area (art) > >Charter for Working Group > >Many companies and projects are developing their own JSON based >representations of email which are proprietary, non-standard, and >incompatible with each other. These protocols are proliferating due >to existing standards being insufficient or poorly suited to the >environments they are operating in, particularly mobile and webmail. I did a quick search and I could not find the "many companies and projects". Could you or someone else please provide URIs so that the first sentence in the proposed charter can be verified? Regards, S. Moonesamy From nobody Wed Nov 9 21:49:56 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBA8129A23 for ; Wed, 9 Nov 2016 21:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCerwuq-oOUv for ; Wed, 9 Nov 2016 21:49:52 -0800 (PST) Received: from forward6p.cmail.yandex.net (forward6p.cmail.yandex.net [87.250.241.191]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B0C12948F for ; Wed, 9 Nov 2016 21:49:52 -0800 (PST) Received: from mxback8h.mail.yandex.net (mxback8h.mail.yandex.net [84.201.186.17]) by forward6p.cmail.yandex.net (Yandex) with ESMTP id 7760D2272D for ; Thu, 10 Nov 2016 08:49:49 +0300 (MSK) Received: from web28h.yandex.ru (web28h.yandex.ru [84.201.187.162]) by mxback8h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id mxaQ3jbspK-nmXekNBq; Thu, 10 Nov 2016 08:49:48 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1478756988; bh=z9JCXxRIsDBiqhH7vIlSPOXfE+pjUcZwLXP57f2sRC8=; h=From:To:Subject:Message-Id:Date; b=IoyAHbyJam7fvriyBP6txuOLqITNSrNExU5zEnPKl1kHYdJwP/EGTt5icJhLmuS3L 8V+9f9GQOjzFfmoQDOzHdoKCxF+8HieL5tW8IERdiSjy0MroSbutlPDx8bzR7Vk83J 0NDbUFrHcrzo+GnWh1IrPX1De8HTd5qcNxotKGMk= Authentication-Results: mxback8h.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web28h.yandex.ru with HTTP; Thu, 10 Nov 2016 08:49:48 +0300 From: Anton Tveretin To: DISPATCH list MIME-Version: 1.0 Message-Id: <1279441478756988@web28h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 10 Nov 2016 10:49:48 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Subject: Re: [dispatch] SIPCORE rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 05:49:55 -0000 So, a specific question: should I re-post my I-D to the SIPCORE instead of DISPATCH, if I believe that my I-D belongs to the core? From nobody Wed Nov 9 22:49:58 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7C9129A28 for ; Wed, 9 Nov 2016 22:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wmy001kjHAL for ; Wed, 9 Nov 2016 22:49:56 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2111129416 for ; Wed, 9 Nov 2016 22:49:55 -0800 (PST) Received: from Orochi.local (118-163-10-190.HINET-IP.hinet.net [118.163.10.190]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAA6nrNX083522 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Nov 2016 00:49:54 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 118-163-10-190.HINET-IP.hinet.net [118.163.10.190] claimed to be Orochi.local To: Anton Tveretin , DISPATCH list References: <1279441478756988@web28h.yandex.ru> From: Adam Roach Message-ID: Date: Thu, 10 Nov 2016 14:49:47 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1279441478756988@web28h.yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] SIPCORE rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 06:49:57 -0000 At the moment, we're just discussing changing the charter; no actual change has been approved yet. Unless you're proposing something that changes the core protocol, submitting to SIPCORE prior to the charter change wouldn't be helpful. Once the charter changes, if you're pretty certain that your document fits under the revised charter, bringing it directly to SIPCORE would be appropriate. If you're unsure, bringing it to DISPATCH is always okay. Keep in mind that DISPATCH is intended to *help* onboard new work when it's not clear where it should go. The use of DISPATCH is not mandated by any process. I'd be happy to offer my personal opinion about whether a document belongs in SIPCORE under the current and/or proposed charter if you send a pointer to the specific document. /a On 11/10/16 13:49, Anton Tveretin wrote: > So, a specific question: should I re-post my I-D to the SIPCORE instead of DISPATCH, if I believe that my I-D belongs to the core? > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Nov 10 11:59:14 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724161294A7; Thu, 10 Nov 2016 11:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwPNTU3sYWnY; Thu, 10 Nov 2016 11:59:10 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1C1129438; Thu, 10 Nov 2016 11:59:10 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id d2so151680109pfd.0; Thu, 10 Nov 2016 11:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:reply-to:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wvV7e4rfD+Q+IwGTPsCsvYh8wb0rcIkvZbsRZbnDEkY=; b=qDzvPUdkMhz+k0o7zK+vOooTMaYsggepiGxreOUCg6KSiMyFtvp2dJcFG6mZKMIPFQ KGxbUIAtEaUftuI27pXNOw1kJnugUv1aBWDGRZSxVlcF3E9Vlymr5D60nrs1+sn17mSi 5uY591HsRDzv0a5nzX4z6Zxt56VqMLnhijO938qy8WEEfJEX2o7Q8DnC0t1o9ZjTarTW sfRlw2J1rhn2LvRZpnirEnlRU6IfChn1vNLTCeAqlExMjSHsyTrs3XpBtFTev3P6PJ9d feUcsorqKfkdQu+1khaI6YQIYKxJBfQ46wVfW8WQs9Uz+zkjjoIqjtX1YaZXZ13n8/AQ +4Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:reply-to:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=wvV7e4rfD+Q+IwGTPsCsvYh8wb0rcIkvZbsRZbnDEkY=; b=YVXcDZKvtLralN+Ka246NcYIuZCG8nCnVRhhX7hbfaK72s3c2KMmoxXL8TswZHeVq6 akn7ACZ+eiQoVT7X8R9ZDRTlCKUCdFgLdVYOYREk5yViZsHyStmt/fWlePcWE4CKFcC8 l6C+rFBESyJdhlfxgy00hmjtEVYM3+mOAwizUk5GwnhlBJ5renPoSBB/U2X1MAPs9grR P9MPKaL+MnrweEyoeWdfViPJlCKgHc6uupv5IBO8iz8C9DHLC8AYnuaDf/nvWJ+cVgQ2 cXiKlBXZEKQF7/ez4huJT/KfwL/Nt8QuM2s/gQPVjOh52LR5+XRCFDbNNQodtzVz7PIC Q15Q== X-Gm-Message-State: ABUngvcxAgBaud29/NLaWRjLEAAymOJKEoWlO96MTut6drpZX2gjY7E2zwRDoRxQ4Xpi3w== X-Received: by 10.99.139.199 with SMTP id j190mr38343274pge.115.1478807949744; Thu, 10 Nov 2016 11:59:09 -0800 (PST) Received: from [172.30.1.57] ([175.193.196.5]) by smtp.gmail.com with ESMTPSA id r1sm9197228pfg.56.2016.11.10.11.59.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Nov 2016 11:59:09 -0800 (PST) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Alexey Melnikov , DISPATCH , SMTP Discuss References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> Organization: Brandenburg InternetWorking Message-ID: <1b4788c1-ca21-9dec-5f57-c73b05811117@dcrocker.net> Date: Fri, 11 Nov 2016 04:58:55 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Request to form a new WG: JMAP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 19:59:12 -0000 (I hadn't seen the draft charter text until now, due to some unfortunately behavior in my email filters.) As with others, I think the draft charter has a number of very basic problems. I think there are several real issues and that some efforts to respond to them could be useful, but that we need far more clarity about needs and associated responses, and we need far more narrow sequencing of those efforts to respond. In its current form, this draft charter is, IMO, far too scatter-shot and complex, and has far too little justifying foundation. > Many companies and projects are developing their own JSON based > representations of email which are proprietary, non-standard, and > incompatible with each other. These protocols are proliferating due > to existing standards being insufficient or poorly suited to the > environments they are operating in, particularly mobile and webmail. As with others, I take 'representations' to mean formats. And given what JSON is[0] that seems an appropriate interpretation even without that word. So I take this asserted need as having a form of email data format that is an alternative to RFC 5322/MIME. Prior to chartering, we should document just how extensive the current problem of multiple JSON email formats is, to establish the practical benefit of unifying it. The theoretical benefit should be obvious, but that's not enough to justify the cost of a working group. We should establish real market need. Having spent quite a bit of my early career on email gatewaying, I'll comment that getting a common interchange format is especially powerful. The active protocols aren't irrelevant, but stabilizing the message object itself is, IMO, far more important. I'm more than a little biased about this strategic approach: It provided the unifying base for email, during the Internet's early growth into commercial markets. And it happens that focusing on this narrow requirement permits end-to-end -- and I mean the real kind: author to recipient, not just originating operator to receiving operator -- benefits without having to change the infrastructure, other than insertion of gateways. Working groups need task serialization. So I'll suggest that having an effort to standardize an JSON representation of an RFC5322/MIME object would be the highest-leverage first task. And not a trivial effort... As for the remaining effort(s)... > The JMAP working group will specify an mechanism to allow clients to > both view and send email from a server over a single stateless HTTPS > channel with minimal round trips. There is no justification given for this approach. For each activity, there needs to be a clear and solid need documented, based on actual industry activities or at least industry statements. Besides clarifying /what/ needs doing, it should serve to indicate likely industry uptake after the work is done. > The protocol will support > out-of-band signaling of changes, and will give mobile clients > significant benefits in terms of battery life and network usage. So, that sounds like some sort of need, but it isn't clear to me what it means. > The use of multiple protocols to perform actions within a single > application creates significant support challenges, as users may get a > variety of partial failure modes (for example, can receive email, but > can not send new messages). This is further exacerbated if the > different protocols are authenticated separately Ditto. Worse, any claim that an alternative would be better needs to be justified both in terms of its considerable effort and its purported improvement. Unification efforts have a habit of re-creating complexity and providing little actual benefit. Note, for example, that the IETF email community debated whether submission should be independent of IMAP or integrated into it. It was a one-year debate and, IMO, was conducted in a highly informed, diligent and constructive fashion. That the result was to maintain separation should not be ignored... > The working group will deliver the following: > > - A problem statement detailing the deployment environment and > situations that motivate work on a new protocol for client to > server email synchronisation. The working group may choose > not to publish this as an RFC. > > - A document describing an extensible protocol and data structures which > supports stateless use, flood control and batched operations. Since client/server email access typically benefits from having the server retain state about the client's activities, I can't tell whether this actually means stateless lower-level transport or whether it really does mean a stateless email protocol. So this needs to be made much more clear, as to the what and the why, as well as to the benefit that will accrue. > - A document describing how to use the extensible protocol over HTTPS > with the data structures expressed as JSON. Given the considerable complexity of HTTP, I continue to fail to see why making it be a universal, lower-layer transport is so popular. Again, the need and the benefit need to be documented. > - A document describing a data model for email viewing, management, > searching, and submission on top of the extensible protocol. > > - An executable test suite and documented test cases to assist > developers of JMAP servers to ensure they conform to the > specifications. This last is useful, but I think it's not typically an IETF work product? A charter is more than a work statement. It is a marketing tool for recruiting industry support. Hence the need for explanatory text that makes needs and benefits clear, as well as specification of deliverables. d/ [0] http://www.json.org/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Nov 11 07:32:52 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412AE129490 for ; Fri, 11 Nov 2016 07:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oCposipmEUL for ; Fri, 11 Nov 2016 07:32:49 -0800 (PST) Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319CB129AFF for ; Fri, 11 Nov 2016 07:32:49 -0800 (PST) Received: from smtp3.hushmail.com (localhost [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 859DBE0542 for ; Fri, 11 Nov 2016 15:32:48 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=5o14lzDz7shuIqQKgk2rBdm46fDO/OIA/+vDxz6ISFI=; b=E/gViT35ex3vzhsISNFMk9c7TaNNQ/7Xf7spqTqB16hkthIFnTgxLiwsqWb60mba2utKjRyEV/w93UYPnNUxbe7+gm+wvX1ZKIgnUsEpCzx9gCdTv3eP+nUT0kDVWnj/QgTeKtlaQszk2YuiC9uteNf3zWiowDRFWHgY6d8zUj5UHymkVEn361YDQuMX9ltd7CGTMw8dCKQuhMg897a1FoFiXSIR4fBQIXhzdSOyciDXOJ6Twi+wqWqsrs+57qapVvUG3dqUleVbmoo9yvm9FBu/DRUYbNiLKxdUE2Mf0iE3gV0q1ujx6Ok1fNnF9IcXdZ+MDlofBBAun7y3TiWBjQ== Received: from smtp.hushmail.com (w6.hushmail.com [65.39.178.92]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.hushmail.com (Postfix) with ESMTPS; Fri, 11 Nov 2016 15:32:47 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 75AEB200D0; Fri, 11 Nov 2016 15:32:47 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 11 Nov 2016 10:32:46 -0500 To: pkyzivat@alum.mit.edu, tasveren@sonusnet.com, henning.schulzrinne@fcc.gov From: "Samir Srivastava" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20161111153247.75AEB200D0@smtp.hushmail.com> Archived-At: Cc: srivant.samir@redifmail.com, dispatch@ietf.org, vinoosrivastava@gmail.com Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 15:32:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 IMPORTANT: This is open communication from the owner of trialobama.net as per the remembered IETF policies by me. If I recollect there was draft submitted by me and NEC folks for indicating presence of SPAM. There was IPR filed by me when I was working at Nortel. Is the work is not related to it. Can someone explain this to me. Thanks Samir On Wed, 12 Oct 2016 14:34:24 -0500 "Henning Schulzrinne" wrote: >There are two scenarios, as you state: > >* Pre-call: For example, the Call-Info header in my other draft or >CNAM ("Cardholder Serv") lead the called party to hit the "spam" >button before picking up. This yields a 666 response to the >INVITE. > >* Mid-call: The called party picks up, listens for 10 seconds, >decides they don't need "Microsoft" technical support, and hits >the same spam button. Signaled via BYE with Reason 666. > >Just like for email spam, the effect is two-fold, as noted: > >(1) I don't want this particular caller to reach me again. >(2) Increment the bad reputation score for the caller. > >I don't see this response affecting a whole category of calls. For >example, I may decide that I really don't like the Police >Benevolence Association call I just received, but that does not >necessarily mean that I'd like to block the American Heart >Association. I think category-based blocking is going to be set up >via a more sophisticated web mechanism that allows finer grained >controls ("No charities after 6 pm; only charities with a Charity >Navigator rating of A"). Same for political calls - I may want to >receive the town hall calls from the politician I like and never >again hear from the one I don't. > >Spoofing obviously makes call blocking of any sort more >problematic, but much spoofing is from numbers that would never >call me. For example, blocking the "IRS" doesn't prevent the real >IRS from calling me - they don't use the 800# (800-TAX-1040) for >outbound calls. > >For now, many robocallers don't spoof since they want you to call >back, given that many people let unknown callers go to voicemail. > >But we've had versions of this discussion in STIR for several >years. > >Henning > >-----Original Message----- >From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Wednesday, October 12, 2016 3:18 PM >To: Asveren, Tolga >Cc: dispatch@ietf.org >Subject: Re: [dispatch] Two new VoIP spam drafts > >On 10/12/16 9:59 AM, Asveren, Tolga wrote: >> Overall, I am in favor of keeping the utility/scope limited to >"spam". Just to list a few points along those lines: >> >> i- "666" would indicate that the user considers the call as >spam/robocall/annoyance; bottomline being that the user would >prefer not to receive calls originating from the same identity. > >While this seems reasonable, how will it work in practice? IOW, >when will I know to use it? > >If I use it before I answer the call, then on what basis am I >doing so? >Is it because I recognize the number? Or is it based on the >classification assigned by the provider that has been displayed to >me? > >Will I have an option to use it after I have answered the call? >(As an alternative to normal hangup.) If so, and if I do so then >based on the content of the call, is the meaning "would prefer not >to receive calls originating from the same identity"? I suspect it >is really more "would prefer not to receive calls of this type", >regardless of the callerid. >(Especially when spam often comes from forged IDs.) > >These are two different semantics. Perhaps they can share the same >code, since they can be distinguished because they are signaled in >different ways. But it would be cleaner if they were different >codes. > >> ii- "666" is not intended to be used for the user to blacklist >his mother-in-law. That -already- could be done by other means. >> iii- "666" does not automatically blacklists the >number/originating identity. It is an input for a spam-blocker >service, which possibly can be provided by a SP. It also would be >an input for a centralized robocall/spam logic, which possibly is >used by multiple SPs and maybe administrated by a national >authority. >> iv- Actual blacklisting rules/service is something to be >decided/provided by the SP. This, for example, may include other >components like a web-interface accessible by users. SP may also >provide "likely to be spam" (and similar) indicators for calls >depending on existing analysis. > >I agree these seem like wise policies. > >> v- Consider the above points, I think a 6xx response is the >right choice and no 4xx response needs to be added/used. > >I'm neutral on this. > >> vi- SP/Central Authority may perform further analysis for a >call, which has been rejected with "666", e.g. based on CDRs, >logs, existing peering relationships etc... > >And statistics. > >If the same calling number has been flagged by many users *after* >they have answered the call, then we can infer that there is a >consistent behavior of bad behavior from this ID. That is worth >investigating. > >If the same number has been flagged by many users *before* they >have answered the call, but not corroborated by others flagging it >after answering, then the situation is unclear. Perhaps this >number carries a calling name that leads people to reject it? Or >perhaps it is a number that is special enough to be recognized by >a lot of people. I think this would need to be investigated >carefully to understand what is going on. > > Thanks, > Paul > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch -----BEGIN PGP SIGNATURE----- Charset: UTF8 Version: Hush 3.0 Note: This signature can be verified at https://www.hushtools.com/verify wpwEAQMCAAYFAlgl5J8ACgkQvdot3LfSFCRgAwP8DUwkdWY3PsvqcfRz19oFBUFuc20e /YLcLxE56qcz8yZa6moQh8W0/iJlNzRBCCovh3+Q2Qg+ukcVvvIFF5dpG6xvOt+vIw4w eN1HAOKI7i7wF0uGC8E/MIMaoSRtxFjxFUjByjIPskrbzVuRGBXRxs9uaKdKaKsc8u8h tsIVP9U= =qg6j -----END PGP SIGNATURE----- From nobody Fri Nov 11 08:30:16 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC95129784 for ; Fri, 11 Nov 2016 08:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYwkNfYyz-0f for ; Fri, 11 Nov 2016 08:30:12 -0800 (PST) Received: from smtp1.hushmail.com (smtp1.hushmail.com [65.39.178.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AD5129762 for ; Fri, 11 Nov 2016 08:30:11 -0800 (PST) Received: from smtp1.hushmail.com (localhost [127.0.0.1]) by smtp1.hushmail.com (Postfix) with SMTP id 3DA58403B2 for ; Fri, 11 Nov 2016 16:30:11 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=b9ccNp/RgkUIrmn8jdI4DomVD6KBwhdstxWkfcqgCNo=; b=c3zswdFSxb4gS1jp1lQ34d0zk98yuswaHLHXOehna9G3pXrOic0geZKohhNZJxPu7An+7Q9LnFDabVVTpxjAIqoCh0Cxcn7NCBcQrpLvJYrNzsW7+VGZ/JQf3dAjnmYfUuPSD9jhp8KYegnKguZPofu/xeOLk+0PI8IQi9EnMWcFVZRyKt2pJiNthJemcVx+jxUP9ExBgXvBLLWIAVT5arLXZJXeifwYl5rcsOizMnvrMdsSnqgJP2uF68riM9oaKztUQxgROis7fYtOu64Jp5fHjqsbS3tezQOsjrjI/B+28Ld+9Lcq+9ptAstVyMIgcaMRtvD3gs3L22Wwal6ygQ== Received: from smtp.hushmail.com (w6.hushmail.com [65.39.178.92]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.hushmail.com (Postfix) with ESMTPS; Fri, 11 Nov 2016 16:30:09 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 81213200D0; Fri, 11 Nov 2016 16:30:09 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 11 Nov 2016 11:30:08 -0500 To: pkyzivat@alum.mit.edu, tasveren@sonusnet.com, henning.schulzrinne@fcc.gov From: "Samir Srivastava" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20161111163009.81213200D0@smtp.hushmail.com> Archived-At: Cc: srivant.samir@redifmail.com, dispatch@ietf.org, vinoosrivastava@gmail.com Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 16:30:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I forgot to put remebered Logo of mine Vashudhev Kutumbakam Sanskrit Language world Whole World is our family On Fri, 11 Nov 2016 10:32:57 -0500 "Samir Srivastava" wrote: >IMPORTANT: This is open communication from the owner of >trialobama.net >as per the remembered IETF policies by me. > >If I recollect there was draft submitted by me and NEC folks for >indicating presence of SPAM. There was IPR filed by me when I was >working at Nortel. > > > Is the work is not related to it. Can someone explain this to me. > >Thanks >Samir > >On Wed, 12 Oct 2016 14:34:24 -0500 "Henning Schulzrinne" > wrote: >>There are two scenarios, as you state: >> >>* Pre-call: For example, the Call-Info header in my other draft >or >>CNAM ("Cardholder Serv") lead the called party to hit the "spam" >>button before picking up. This yields a 666 response to the >>INVITE. >> >>* Mid-call: The called party picks up, listens for 10 seconds, >>decides they don't need "Microsoft" technical support, and hits >>the same spam button. Signaled via BYE with Reason 666. >> >>Just like for email spam, the effect is two-fold, as noted: >> >>(1) I don't want this particular caller to reach me again. >>(2) Increment the bad reputation score for the caller. >> >>I don't see this response affecting a whole category of calls. >For >>example, I may decide that I really don't like the Police >>Benevolence Association call I just received, but that does not >>necessarily mean that I'd like to block the American Heart >>Association. I think category-based blocking is going to be set >up >>via a more sophisticated web mechanism that allows finer grained >>controls ("No charities after 6 pm; only charities with a Charity >>Navigator rating of A"). Same for political calls - I may want to >>receive the town hall calls from the politician I like and never >>again hear from the one I don't. >> >>Spoofing obviously makes call blocking of any sort more >>problematic, but much spoofing is from numbers that would never >>call me. For example, blocking the "IRS" doesn't prevent the real >>IRS from calling me - they don't use the 800# (800-TAX-1040) for >>outbound calls. >> >>For now, many robocallers don't spoof since they want you to call >>back, given that many people let unknown callers go to voicemail. >> >>But we've had versions of this discussion in STIR for several >>years. >> >>Henning >> >>-----Original Message----- >>From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of >>Paul Kyzivat >>Sent: Wednesday, October 12, 2016 3:18 PM >>To: Asveren, Tolga >>Cc: dispatch@ietf.org >>Subject: Re: [dispatch] Two new VoIP spam drafts >> >>On 10/12/16 9:59 AM, Asveren, Tolga wrote: >>> Overall, I am in favor of keeping the utility/scope limited to >>"spam". Just to list a few points along those lines: >>> >>> i- "666" would indicate that the user considers the call as >>spam/robocall/annoyance; bottomline being that the user would >>prefer not to receive calls originating from the same identity. >> >>While this seems reasonable, how will it work in practice? IOW, >>when will I know to use it? >> >>If I use it before I answer the call, then on what basis am I >>doing so? >>Is it because I recognize the number? Or is it based on the >>classification assigned by the provider that has been displayed >to >>me? >> >>Will I have an option to use it after I have answered the call? >>(As an alternative to normal hangup.) If so, and if I do so then >>based on the content of the call, is the meaning "would prefer >not >>to receive calls originating from the same identity"? I suspect >it >>is really more "would prefer not to receive calls of this type", >>regardless of the callerid. >>(Especially when spam often comes from forged IDs.) >> >>These are two different semantics. Perhaps they can share the >same >>code, since they can be distinguished because they are signaled >in >>different ways. But it would be cleaner if they were different >>codes. >> >>> ii- "666" is not intended to be used for the user to blacklist >>his mother-in-law. That -already- could be done by other means. >>> iii- "666" does not automatically blacklists the >>number/originating identity. It is an input for a spam-blocker >>service, which possibly can be provided by a SP. It also would be >>an input for a centralized robocall/spam logic, which possibly is >>used by multiple SPs and maybe administrated by a national >>authority. >>> iv- Actual blacklisting rules/service is something to be >>decided/provided by the SP. This, for example, may include other >>components like a web-interface accessible by users. SP may also >>provide "likely to be spam" (and similar) indicators for calls >>depending on existing analysis. >> >>I agree these seem like wise policies. >> >>> v- Consider the above points, I think a 6xx response is the >>right choice and no 4xx response needs to be added/used. >> >>I'm neutral on this. >> >>> vi- SP/Central Authority may perform further analysis for a >>call, which has been rejected with "666", e.g. based on CDRs, >>logs, existing peering relationships etc... >> >>And statistics. >> >>If the same calling number has been flagged by many users *after* >>they have answered the call, then we can infer that there is a >>consistent behavior of bad behavior from this ID. That is worth >>investigating. >> >>If the same number has been flagged by many users *before* they >>have answered the call, but not corroborated by others flagging >it >>after answering, then the situation is unclear. Perhaps this >>number carries a calling name that leads people to reject it? Or >>perhaps it is a number that is special enough to be recognized by >>a lot of people. I think this would need to be investigated >>carefully to understand what is going on. >> >> Thanks, >> Paul >> >> >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch -----BEGIN PGP SIGNATURE----- Charset: UTF8 Version: Hush 3.0 Note: This signature can be verified at https://www.hushtools.com/verify wpwEAQMCAAYFAlgl8hEACgkQvdot3LfSFCT4dgP+Jhb6ghw+Ps9txTdh+cBGcpB+n+1U dBeRHqnIXq7QtVphEU/F9rw9TBg1RokQUxTBVm9432srDwUqqQMdURN0UfCWD4zJ/9Gt Q+GdqdUMYCMrFJBFGP9ptI4G+IU9vv9wn5iFvMTDjDlEPdpognhC8DneU3JmtiaJU1Ho MJoG9Ik= =YJGR -----END PGP SIGNATURE----- From nobody Sun Nov 13 03:03:30 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A861296F9; Sun, 13 Nov 2016 03:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeA9YkYthWMr; Sun, 13 Nov 2016 03:03:26 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26E91296EA; Sun, 13 Nov 2016 03:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hHpz9aiUgCXitNkzHFCQ8/BafAPTumNscEBC2VeZ0hA=; b=ARLq2ow0Fx59rl3IWT0l/LWhphv5pxOv7mpEwFqdztHp7bH86b1aRlWKc62PIgG5IafexeFmt5RSWGaVHqnPKQjA4MHWM0VMyLkCYfa1YnLi8LPbPXoann/vITmmuMr3O7pcJuHnfiG2vYXp/MCNZLrAHiLcWHQseRlToG7Culk= From: Henning Schulzrinne To: Alex Bobotek , "stir@ietf.org" , "dispatch@ietf.org" Thread-Topic: FYI only: Two new VoIP spam drafts Thread-Index: AQHSG4AHdXDxA/hrj06MJ4pEMbL5u6CUpQ4ggEJcrr4= Date: Sun, 13 Nov 2016 11:03:21 +0000 Message-ID: References: , <4B1956260CD29F4A9622F00322FE053101290E491F5A@BOBO1A.bobotek.net> In-Reply-To: <4B1956260CD29F4A9622F00322FE053101290E491F5A@BOBO1A.bobotek.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:z77W+e6iNZeeL3JX2GfapjbVDDlM36veCFILWuQ6Qs7RImi0zaRRLXCx5XvU02iRmUg6bvmcqCQDN1PBwcCxCCWs1bb6dpXqrWQRbM3clz6whlHPySkvYDrY8gxvlyuEbPkXJJ42nvy/ZCAhrMdKY6hpeufNrCk0FwzjWtUyK2VlnFKGHlO7EsZvzCn6P7HP/AMB0PzSrVANjiSpqn5WSZsr7OHl6MOHRyazntdV1hWumi+EeZ9uMicpkC4m062AH43q6vTCAZ9TuLKqrjxJ/Q3phThT9Ow8ANWA4lNW768DAXfOQb579AxO7m8eG1jaFOM/i19r9PejTr1ziaUrEre2qZ4KhDoRZpJYj6vbBQg= x-ms-office365-filtering-correlation-id: eaefbbd3-7ceb-4110-fdd4-08d40bb4ae76 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0635; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(231250463719595); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(336003)(377454003)(189002)(69234005)(199003)(92566002)(33656002)(8676002)(77096005)(229853002)(2501003)(19627405001)(66066001)(15187005004)(2201001)(50986999)(76176999)(2900100001)(8936002)(54356999)(7696004)(86362001)(2950100002)(76576001)(101416001)(81156014)(81166006)(10126002)(107886002)(6606003)(87936001)(586003)(105586002)(106356001)(99286002)(5001770100001)(106116001)(74316002)(189998001)(6116002)(2906002)(3846002)(68736007)(102836003)(7846002)(9686002)(5660300001)(122556002)(7906003)(3660700001)(7736002)(97736004)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634FC71E04DE7796429FB25EABD0CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 11:03:21.3163 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [dispatch] FYI only: Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 11:03:29 -0000 --_000_CY1PR09MB0634FC71E04DE7796429FB25EABD0CY1PR09MB0634namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Catching up on comments. Please see inline. ________________________________ From: stir on behalf of Alex Bobotek Sent: Sunday, October 2, 2016 2:01:50 AM To: Henning Schulzrinne; stir@ietf.org Subject: Re: [stir] FYI only: Two new VoIP spam drafts It=92s good to see the docs. I=92m very pleased to see the facilitation of= end-user feedback, information crucial to abuse mitigation. Comments on draft-schulzrinne-dispatch-status-unwanted: 1. The status code could, conceivably, be returned by automata or by = human-triggered action (e.g., user click on the =91report spam=92 button). = Consider whether the status code could reflect action by someone or someth= ing other than the typically-human called party and at points before the te= rminating device. IMHO, it should permit such indications from automata as= well as human-initiated actions. >> Definitely both. 2. The recommendation that the response code not be used in creating = call filters unless the call has been authenticated via 4474bis is too stro= ng. There are many cases where I want such non-authenticated information t= o be used to filter my calls. Just about everybody using the more popular = call blocking solutions available today benefit from blacklisting based on = feedback of unauthenticated caller IDs, and this practice should not be ter= minated capriciously. Additionally, 4474bis is only one of many methods of= auth and may instead be more of a statement of service provider originati= on than of calling address authority or authentication. I suggest toning t= his down to a statement that the possibility of spoofing or unauthorized us= e should be taken into consideration in constructing call filters. >> Good point. 3. The draft should include normative text that specifies when a SIP = entity MAY/SHOULD/SHALL return the status code. It only specifies what a r= ecipient of the code MAY do. For example, add to section 4: =93A SIP entity MAY reply to a SIP request with the =91Unwanted=92 response= code if there is a user-initiated or other indication that the request is = unwanted. =93 >> I'm not sure how to write this. I don't see a SHOULD/MUST here since the= UAS would never have to return this at all, even if it is spam. 4. Consider allowing SIP entities handling the response to substitute= a different code in any forwarded responses. A called party may not wish = to convey rejection as unwanted all the way back to the calling party. I d= on=92t know the right answer, and I hope others=92 opinions will be express= ed. There are times when a message instructing a caller to =91place me on = your organization=92s DNC=92 is desired, and times when a more silent appro= ach is preferred. >> With SBCs, this is common, so I see no harm. 5. The introductory paragraph discusses the need to express that a ca= ll is unwanted. Section 3 discusses the need to indicate that a caller=92s= calls are unwanted. These are different assertions. The most basic asse= rtion is =91this call is unwanted=92. Perhaps an additional =91no calls fr= om that address are wanted=92 assertion should also be supported. >> I'm not sure how expressing displeasure only about the call itself is he= lpful. The typical call spam button also doesn't just drop the message into= the spam folder (unless it's a stand-alone client); it flags the message s= ender, typically, for enhanced scrutiny. Regards, Alex From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, September 30, 2016 6:08 PM To: stir@ietf.org Subject: [stir] FYI only: Two new VoIP spam drafts [Please address comments to the DISPATCH list; this copy is FYI only since = I forgot to bcc the list.] In collaboration with members of the Robocall Strike Force (https://www.fcc= .gov/news-events/events/2016/08/first-meeting-industry-led-robocall-strike-= force), I have submitted two I-D's: https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwanted= / https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam/ that fill in operational needs for dealing with SIP spam. The first defines= a new status code (666) that users can use to mark unwanted calls, either = as a response code to an INVITE or in a Reason header in a BYE response. (T= his will likely be supplemented in practice by API-based mechanisms for pos= t-call spam reports.) The second defines a set of Call-Info parameters that allow the carrier or = other UE-trusted SIP entity in the path to indicate the spam probability, t= ype of call and other related information that will allow the UE and user t= o make better call handling decisions. This complements the 'verstat' work being submitted to 3GPP (by others), fo= r indicating the level of trust in the From/PAI tel URI. Henning --_000_CY1PR09MB0634FC71E04DE7796429FB25EABD0CY1PR09MB0634namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Catching up on comments. Please see inline.

From: stir <stir-bounces= @ietf.org> on behalf of Alex Bobotek <alex@bobotek.net>
Sent: Sunday, October 2, 2016 2:01:50 AM
To: Henning Schulzrinne; stir@ietf.org
Subject: Re: [stir] FYI only: Two new VoIP spam drafts
 

It=92s good to see the docs.  I=92m very pleased to see= the facilitation of end-user feedback, information crucial to abuse mitiga= tion. 

 

Comments on draft-schulzrinne-dispatch-status-unwanted:

 

1.       The status code could, co= nceivably, be returned by automata or by human-triggered action (e.g., user= click on the =91report spam=92 button).  Consider whether the status code could reflect action by someone or something other= than the typically-human called party and at points before the terminating= device.  IMHO, it should permit such indications from automata as wel= l as human-initiated actions.


>> Definitely both.=


2.       The recommendation that t= he response code not be used in creating call filters unless the call has b= een authenticated via 4474bis is too strong.  There are many cases where I want such non-authenticated information to be= used to filter my calls.  Just about everybody using the more popular= call blocking solutions available today benefit from blacklisting based on= feedback of unauthenticated caller IDs, and this practice should not be terminated capriciously.  Additionall= y, 4474bis is only one of many methods of auth and may instead be more of&n= bsp; a statement of service provider origination than of calling address au= thority or authentication.  I suggest toning this down to a statement that the possibility of spoofing or unauthorized = use should be taken into consideration in constructing call filters. 


>> Good point.


3.       The draft should include = normative text that specifies when a SIP entity MAY/SHOULD/SHALL return the= status code.  It only specifies what a recipient of the code MAY do.  For example, add to section 4:=

=93A SIP entity MAY reply to a SIP request with the =91Unwan= ted=92 response code if there is a user-initiated or other indication that = the request is unwanted. =93


>> I'm not sure how to w= rite this. I don't see a SHOULD/MUST here since the UAS would never have to= return this at all, even if it is spam.


4.       Consider allowing SIP ent= ities handling the response to substitute a different code in any forwarded= responses.  A called party may not wish to convey rejection as unwanted all the way back to the calling party.  = I don=92t know the right answer, and I hope others=92 opinions will be expr= essed.  There are times when a message instructing a caller to =91plac= e me on your organization=92s DNC=92 is desired, and times when a more silent approach is preferred.


>> With SBCs, this is common, so I see no= harm.



5.       The introductory paragrap= h discusses the need to express that a call is unwanted.  Section 3 di= scusses the need to indicate that a caller=92s calls are unwanted.   These are different assertions.  The most b= asic assertion is =91this call is unwanted=92.  Perhaps an additional = =91no calls from that address are wanted=92 assertion should also be suppor= ted. 


>> I'm not sure how expr= essing displeasure only about the call itself is helpful. The typical = call spam button also doesn't just drop the message into the spam folder (u= nless it's a stand-alone client); it flags the message sender, typically, for enhanced scrutiny.

 

 

Regards,

 

Alex

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Friday, September 30, 2016 6:08 PM
To: stir@ietf.org
Subject: [stir] FYI only: Two new VoIP spam drafts=

 

[= Please address comments to the DISPATCH list; this copy is FYI only since I= forgot to bcc the list.]

<= o:p> 

I= n collaboration with members of the Robocall Strike Force (https://www.fcc.gov/n= ews-events/events/2016/08/first-meeting-industry-led-robocall-strike-force<= /a>), I have submitted two I-D's:

<= o:p> 

<= a href=3D"https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-statu= s-unwanted/" target=3D"_blank" id=3D"LPlnk889361" style=3D"color: blue; tex= t-decoration: underline;" previewremoved=3D"true">https://datatracker.ietf.= org/doc/draft-schulzrinne-dispatch-status-unwanted/

<= a href=3D"https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-calli= nfo-spam/" target=3D"_blank" id=3D"LPlnk520780" style=3D"color: blue; text-= decoration: underline;" previewremoved=3D"true">https://datatracker.ietf.or= g/doc/draft-schulzrinne-dispatch-callinfo-spam/

<= o:p> 

t= hat fill in operational needs for dealing with SIP spam. The first defines = a new status code (666) that users can use to mark unwanted calls, either a= s a response code to an INVITE or in a Reason header in a BYE response. (This will likely be supplemented in practice by= API-based mechanisms for post-call spam reports.)

<= o:p> 

T= he second defines a set of Call-Info parameters that allow the carrier or o= ther UE-trusted SIP entity in the path to indicate the spam probability, ty= pe of call and other related information that will allow the UE and user to make better call handling decisions.

<= o:p> 

T= his complements the 'verstat' work being submitted to 3GPP (by others), for= indicating the level of trust in the From/PAI tel URI.

<= o:p> 

H= enning

 

--_000_CY1PR09MB0634FC71E04DE7796429FB25EABD0CY1PR09MB0634namp_-- From nobody Sun Nov 13 03:21:42 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599621296FF for ; Sun, 13 Nov 2016 03:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9aAPm4XNQKs for ; Sun, 13 Nov 2016 03:21:38 -0800 (PST) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E89E129639 for ; Sun, 13 Nov 2016 03:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bzDopHQ/lUO9eqdAa6uNkpUXG9n0HRtaADfoxZwcpBs=; b=qG97TtyS21t8SKgMUt4BIkpw/U6n9KVIrvVydFXY41cTMRGqQyphUHRiQwmeyiyd2SvQywIl0LslBE1fhwmY1uXkZ+l35YGM2/aYsbE0t7+BEazE9FCfdai03OcKxzEz0Ai/zT3LrN9PE8NQ/utj7b/oi6tXj1i0ecGaQ1NGS8M= From: Henning Schulzrinne To: "DOLLY, MARTIN C" , Paul Kyzivat , "Asveren, Tolga" Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWijqIJi1PJIEa3EccQvSjRiaCdbouAgAAB3oeAAAfCAIAAAOj2gAALawCAATkyAIAABDwAgAA/vgCAAOXTgIAB57qAgAMROoCAAFjTAIAAAKkQgAALWYCAAQ+DgIAwqH+T Date: Sun, 13 Nov 2016 11:21:32 +0000 Message-ID: References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> <18576a53-1491-6847-a324-82f8cacf1863@alum.mit.edu> <59f4ffb9-1ad6-95da-d75a-b6b8721712ee@alum.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:txOI8gtzB7OPZdvQ+BD0zg5g5lwAD318gLTYJSUPrjD/vlCzv2K8uNA8iCbMinttJjbAZcBqdMj59dJZahBEOHo3tKg8Nxp79YrB+S0yt0kU0fOvG3obkZlMNIeMInpvH+QWE7PUKanmEuuceLDyBVfXUOqgnoIKo0Py5jX1Qg9lF0X8igz63XUbplxLy3bEvDMRjCP8ecJM+T6gXkS16mAPrAU7zeb/cqJHjM99U8GVmuQjjAYERwvp+RWJg1M+B5gZ88JdD67UDKSyLOwRDYMVqr0OqoysaEss3J5hw0PPXvOdPzueUzCEmGHkCKb9j9UI3vNwTsJ+FtDOkmLTdlMdPswR7iOCLemwKcPXPOU= x-ms-office365-filtering-correlation-id: cf24f400-4917-42cd-b092-08d40bb73903 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0635; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(97927398514766)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(336003)(199003)(189002)(377454003)(13464003)(24454002)(5001770100001)(74316002)(106116001)(189998001)(4326007)(31430400001)(99286002)(586003)(105586002)(87936001)(106356001)(3660700001)(7736002)(7906003)(97736004)(3280700002)(7846002)(6116002)(2906002)(3846002)(102836003)(68736007)(2171001)(122556002)(9686002)(5660300001)(66066001)(8936002)(54356999)(2900100001)(50986999)(76176999)(77096005)(92566002)(33656002)(8676002)(229853002)(81156014)(81166006)(86362001)(2950100002)(93886004)(76576001)(7696004)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634A8FE308807AC835BD027EABD0CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 11:21:32.7304 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-OriginatorOrg: fcc.gov Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 11:21:40 -0000 --_000_CY1PR09MB0634A8FE308807AC835BD027EABD0CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will note that treatment of pre-call and mid-call 666 can differ, without= going into details what the different might be. Given that pre-call reject= ion is likely based on recognizing the caller ID (e.g., from a previous cal= l using the same one), I could imagine similar treatment, particularly if t= here is no personal blacklist. ("The same robocaller again; let me punch th= e spam button so that it finally gets filtered.") ________________________________ From: DOLLY, MARTIN C Sent: Thursday, October 13, 2016 8:12:17 AM To: Paul Kyzivat; Henning Schulzrinne; Asveren, Tolga Cc: dispatch@ietf.org Subject: RE: [dispatch] Two new VoIP spam drafts I would see the treatment in the network to be slightly different between r= eceiving a pre versus mid call 666 response. Both would be fed into data analytics. Pre 666 would be used for the individual profile (possibly adding number to= a blacklist), and used in the data analytics for further analysis with oth= er calls to other users. Post 666 would initiate the reporting and traceback processes. Regards, Martin -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, October 12, 2016 4:01 PM To: Henning Schulzrinne ; Asveren, Tolga Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts Henning, I mostly agree, with some qualifications, inline. On 10/12/16 3:34 PM, Henning Schulzrinne wrote: > There are two scenarios, as you state: > > * Pre-call: For example, the Call-Info header in my other draft or CNAM (= "Cardholder Serv") lead the called party to hit the "spam" button before pi= cking up. This yields a 666 response to the INVITE. > > * Mid-call: The called party picks up, listens for 10 seconds, decides th= ey don't need "Microsoft" technical support, and hits the same spam button.= Signaled via BYE with Reason 666. > > Just like for email spam, the effect is two-fold, as noted: > > (1) I don't want this particular caller to reach me again. > (2) Increment the bad reputation score for the caller. Trying to use the same signal to trigger both of these effects presents som= e issues. And I think they differ for Pre-call and mid-call? (1) seems appropriate for pre-call. It is clear that I am making a judgemen= t based on the identity of the caller. Not so clear for mid-call. I definit= ely don't like the content, but that may or may not correlate to the caller= identity. Risky to block the caller based on just this. (2) This action might be appropriate for both pre-call and mid-call, but th= e two types should probably be tallied separately and evaluated differently= . For mid-call I am objecting to the content and the tally is used to see i= f the number has a history of bad content. For pre-call we really don't kno= w what the callee is objecting to. Still worth tracking, but not as strong = a measure. Of course we aren't standardizing this behavior, so discussing it is just f= or context. My bottom line here is just that it is hard to characterize the meaning of = the code in a phrase. So I suggest using something quite vague, like "Objec= tionable" without qualification as to whether it is the calling id, calling= name, content, or whatever that it applies to. The text description can go= into more detail. But ultimately the meaning will be determined by others = so we should be vague enough to cover whatever they decide to do. Thanks, Paul > I don't see this response affecting a whole category of calls. For exampl= e, I may decide that I really don't like the Police Benevolence Association= call I just received, but that does not necessarily mean that I'd like to = block the American Heart Association. I think category-based blocking is go= ing to be set up via a more sophisticated web mechanism that allows finer g= rained controls ("No charities after 6 pm; only charities with a Charity Na= vigator rating of A"). Same for political calls - I may want to receive the= town hall calls from the politician I like and never again hear from the o= ne I don't. > > Spoofing obviously makes call blocking of any sort more problematic, but = much spoofing is from numbers that would never call me. For example, blocki= ng the "IRS" doesn't prevent the real IRS from calling me - they don't use = the 800# (800-TAX-1040) for outbound calls. > > For now, many robocallers don't spoof since they want you to call back, g= iven that many people let unknown callers go to voicemail. > > But we've had versions of this discussion in STIR for several years. > > Henning > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: Wednesday, October 12, 2016 3:18 PM > To: Asveren, Tolga > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Two new VoIP spam drafts > > On 10/12/16 9:59 AM, Asveren, Tolga wrote: >> Overall, I am in favor of keeping the utility/scope limited to "spam". J= ust to list a few points along those lines: >> >> i- "666" would indicate that the user considers the call as spam/robocal= l/annoyance; bottomline being that the user would prefer not to receive cal= ls originating from the same identity. > > While this seems reasonable, how will it work in practice? IOW, when will= I know to use it? > > If I use it before I answer the call, then on what basis am I doing so? > Is it because I recognize the number? Or is it based on the classificatio= n assigned by the provider that has been displayed to me? > > Will I have an option to use it after I have answered the call? (As an al= ternative to normal hangup.) If so, and if I do so then based on the conten= t of the call, is the meaning "would prefer not to receive calls originatin= g from the same identity"? I suspect it is really more "would prefer not to= receive calls of this type", regardless of the callerid. > (Especially when spam often comes from forged IDs.) > > These are two different semantics. Perhaps they can share the same code, = since they can be distinguished because they are signaled in different ways= . But it would be cleaner if they were different codes. > >> ii- "666" is not intended to be used for the user to blacklist his mothe= r-in-law. That -already- could be done by other means. >> iii- "666" does not automatically blacklists the number/originating iden= tity. It is an input for a spam-blocker service, which possibly can be prov= ided by a SP. It also would be an input for a centralized robocall/spam log= ic, which possibly is used by multiple SPs and maybe administrated by a nat= ional authority. >> iv- Actual blacklisting rules/service is something to be decided/provide= d by the SP. This, for example, may include other components like a web-int= erface accessible by users. SP may also provide "likely to be spam" (and si= milar) indicators for calls depending on existing analysis. > > I agree these seem like wise policies. > >> v- Consider the above points, I think a 6xx response is the right choice= and no 4xx response needs to be added/used. > > I'm neutral on this. > >> vi- SP/Central Authority may perform further analysis for a call, which = has been rejected with "666", e.g. based on CDRs, logs, existing peering re= lationships etc... > > And statistics. > > If the same calling number has been flagged by many users *after* they ha= ve answered the call, then we can infer that there is a consistent behavior= of bad behavior from this ID. That is worth investigating. > > If the same number has been flagged by many users *before* they have answ= ered the call, but not corroborated by others flagging it after answering, = then the situation is unclear. Perhaps this number carries a calling name t= hat leads people to reject it? Or perhaps it is a number that is special en= ough to be recognized by a lot of people. I think this would need to be inv= estigated carefully to understand what is going on. > > Thanks, > Paul > > > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_CY1PR09MB0634A8FE308807AC835BD027EABD0CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I will note that treatment of pre-call and mid-call 666 can differ, with= out going into details what the different might be. Given that pre-call rej= ection is likely based on recognizing the caller ID (e.g., from a previous = call using the same one), I could imagine similar treatment, particularly if there is no personal blacklist.= ("The same robocaller again; let me punch the spam button so that it = finally gets filtered.")

From: DOLLY, MARTIN C <= ;md3135@att.com>
Sent: Thursday, October 13, 2016 8:12:17 AM
To: Paul Kyzivat; Henning Schulzrinne; Asveren, Tolga
Cc: dispatch@ietf.org
Subject: RE: [dispatch] Two new VoIP spam drafts
 
I would see the treatment in the network to be sli= ghtly different between receiving a pre versus mid call 666 response.

Both would be fed into data analytics.
Pre 666 would be used for the individual profile (possibly adding number to= a blacklist), and used in the data analytics for further analysis with oth= er calls to other users.
Post 666 would initiate the reporting and traceback processes.

Regards,

Martin

-----Original Message-----
From: dispatch [mailto:dispatc= h-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Wednesday, October 12, 2016 4:01 PM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; Asveren, Tolga= <tasveren@sonusnet.com>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Two new VoIP spam drafts

Henning,

I mostly agree, with some qualifications, inline.

On 10/12/16 3:34 PM, Henning Schulzrinne wrote:
> There are two scenarios, as you state:
>
> * Pre-call: For example, the Call-Info header in my other draft or CNA= M ("Cardholder Serv") lead the called party to hit the "spam= " button before picking up. This yields a 666 response to the INVITE.<= br> >
> * Mid-call: The called party picks up, listens for 10 seconds, decides= they don't need "Microsoft" technical support, and hits the same= spam button.  Signaled via BYE with Reason 666.
>
> Just like for email spam, the effect is two-fold, as noted:
>
> (1) I don't want this particular caller to reach me again.
> (2) Increment the bad reputation score for the caller.

Trying to use the same signal to trigger both of these effects presents som= e issues. And I think they differ for Pre-call and mid-call?

(1) seems appropriate for pre-call. It is clear that I am making a judgemen= t based on the identity of the caller. Not so clear for mid-call. I definit= ely don't like the content, but that may or may not correlate to the caller= identity. Risky to block the caller based on just this.

(2) This action might be appropriate for both pre-call and mid-call, but th= e two types should probably be tallied separately and evaluated differently= . For mid-call I am objecting to the content and the tally is used to see i= f the number has a history of bad content. For pre-call we really don't know what the callee is objecting to= . Still worth tracking, but not as strong a measure.

Of course we aren't standardizing this behavior, so discussing it is just f= or context.

My bottom line here is just that it is hard to characterize the meaning of = the code in a phrase. So I suggest using something quite vague, like "= Objectionable" without qualification as to whether it is the calling i= d, calling name, content, or whatever that it applies to. The text description can go into more detail. But ultimatel= y the meaning will be determined by others so we should be vague enough to = cover whatever they decide to do.

        Thanks,
        Paul

> I don't see this response affecting a whole category of calls. For exa= mple, I may decide that I really don't like the Police Benevolence Associat= ion call I just received, but that does not necessarily mean that I'd like = to block the American Heart Association. I think category-based blocking is going to be set up via a more sophistic= ated web mechanism that allows finer grained controls ("No charities a= fter 6 pm; only charities with a Charity Navigator rating of A"). Same= for political calls - I may want to receive the town hall calls from the politician I like and never again hear from t= he one I don't.
>
> Spoofing obviously makes call blocking of any sort more problematic, b= ut much spoofing is from numbers that would never call me. For example, blo= cking the "IRS" doesn't prevent the real IRS from calling me - th= ey don't use the 800# (800-TAX-1040) for outbound calls.
>
> For now, many robocallers don't spoof since they want you to call back= , given that many people let unknown callers go to voicemail.
>
> But we've had versions of this discussion in STIR for several years. >
> Henning
>
> -----Original Message-----
> From: dispatch [mailto:di= spatch-bounces@ietf.org] On Behalf Of Paul
> Kyzivat
> Sent: Wednesday, October 12, 2016 3:18 PM
> To: Asveren, Tolga <tasveren@sonusnet.com>
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] Two new VoIP spam drafts
>
> On 10/12/16 9:59 AM, Asveren, Tolga wrote:
>> Overall, I am in favor of keeping the utility/scope limited to &qu= ot;spam". Just to list a few points along those lines:
>>
>> i- "666" would indicate that the user considers the call= as spam/robocall/annoyance; bottomline being that the user would prefer no= t to receive calls originating from the same identity.
>
> While this seems reasonable, how will it work in practice? IOW, when w= ill I know to use it?
>
> If I use it before I answer the call, then on what basis am I doing so= ?
> Is it because I recognize the number? Or is it based on the classifica= tion assigned by the provider that has been displayed to me?
>
> Will I have an option to use it after I have answered the call? (As an= alternative to normal hangup.) If so, and if I do so then based on the con= tent of the call, is the meaning "would prefer not to receive calls or= iginating from the same identity"? I suspect it is really more "would prefer not to receive calls of this type&quo= t;, regardless of the callerid.
> (Especially when spam often comes from forged IDs.)
>
> These are two different semantics. Perhaps they can share the same cod= e, since they can be distinguished because they are signaled in different w= ays. But it would be cleaner if they were different codes.
>
>> ii- "666" is not intended to be used for the user to bla= cklist his mother-in-law. That -already- could be done by other means.
>> iii- "666" does not automatically blacklists the number/= originating identity. It is an input for a spam-blocker service, which poss= ibly can be provided by a SP. It also would be an input for a centralized r= obocall/spam logic, which possibly is used by multiple SPs and maybe administrated by a national authority.
>> iv- Actual blacklisting rules/service is something to be decided/p= rovided by the SP. This, for example, may include other components like a w= eb-interface accessible by users. SP may also provide "likely to be sp= am" (and similar) indicators for calls depending on existing analysis.
>
> I agree these seem like wise policies.
>
>> v- Consider the above points, I think a 6xx response is the right = choice and no 4xx response needs to be added/used.
>
> I'm neutral on this.
>
>> vi- SP/Central Authority may perform further analysis for a call, = which has been rejected with "666", e.g. based on CDRs, logs, exi= sting peering relationships etc...
>
> And statistics.
>
> If the same calling number has been flagged by many users *after* they= have answered the call, then we can infer that there is a consistent behav= ior of bad behavior from this ID. That is worth investigating.
>
> If the same number has been flagged by many users *before* they have a= nswered the call, but not corroborated by others flagging it after answerin= g, then the situation is unclear. Perhaps this number carries a calling nam= e that leads people to reject it? Or perhaps it is a number that is special enough to be recognized by a lot of= people. I think this would need to be investigated carefully to understand= what is going on.
>
>        Thanks,
>        Paul
>
>
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

 --_000_CY1PR09MB0634A8FE308807AC835BD027EABD0CY1PR09MB0634namp_-- From nobody Sun Nov 13 03:45:08 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731C612970F for ; Sun, 13 Nov 2016 03:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8-qHbiQFpO2 for ; Sun, 13 Nov 2016 03:45:05 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB3D129518 for ; Sun, 13 Nov 2016 03:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FNH/UMgMYGR3O7CNUS/U996iAMv9OAlfzBcftgBMErk=; b=J7JmBusKxtMcky1ahZYctFXCBtCQy1uhVD6NH0UEBDXhD8JyA/hxv9fHHN7ULAcb2K0F8Z4moNAN0qnNYhOgTYUEMn5aDeoVhjD1BgL/CssKrNKHS4A6k/GtnWtFuUWugd8ABOrzlBmiK2FYu9z//mx/iUCeX3ct7eqcNErh+Hs= From: Henning Schulzrinne To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSG4y2GZvJepLQu06G9vFQbuxMyaCS4uS1gAAMvYCARB9BHA== Date: Sun, 13 Nov 2016 11:45:00 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:kFmqemkzlB709k9yJR05lDAk7nSwrFJ4PQHTtR0KtKrYvPqyEJl1NuqAbFYF0/0zvte6bU1Wm/v9DHYtvmSnrOcNPHIKacrNIqyXLweTZZUGAjum6wfIdZrbymAfTwkfSXKb0BWRszuZ3bh+y1HZTWxdJdQ/vJbF8a83Tq6NLsyVvtLw3rRsZkmfqMyPMJh43yZwYF7eQ+hpTj5eoumb6LMlCYVsKWUI/6qoxzSTcSkxW926/QeCOA5duss1A7/ix+8cj8042Vx2y4tjMip+6fj3LIF/PIf8TNCamHseOkObzvAi/xYb0kyaqnn9l7RT1Gym++eT8uKw2nvSjVVl7Pkm6hjaVooi49ZZxWqkw6w= x-ms-office365-filtering-correlation-id: 5e96f7f2-6940-4377-72ec-08d40bba7ff7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0635; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(336003)(199003)(189002)(377454003)(24454002)(74316002)(106116001)(5001770100001)(189998001)(586003)(105586002)(87936001)(99286002)(106356001)(3660700001)(7736002)(7906003)(97736004)(3280700002)(7846002)(6116002)(2906002)(3846002)(68736007)(102836003)(2171001)(122556002)(9686002)(5660300001)(107886002)(66066001)(8936002)(54356999)(230783001)(2900100001)(50986999)(76176999)(77096005)(33656002)(92566002)(8676002)(229853002)(2501003)(81156014)(81166006)(86362001)(2950100002)(93886004)(76576001)(7696004)(101416001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634367CFFD7C4718BB2F688EABD0CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 11:45:00.3317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [dispatch] draft-schulzrinne-dispatch-status-unwanted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 11:45:07 -0000 --_000_CY1PR09MB0634367CFFD7C4718BB2F688EABD0CY1PR09MB0634namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is getting into deep editorial matters of taste, but "objectionable" i= sn't quite right, given common usage that this refers to content that is un= suitable for minors or in poor taste. (See, locally, https://www.fcc.gov/co= nsumers/guides/protecting-children-objectionable-content-wireless-devices).= Or, from the dictionary definition: "offending good taste, manners, etiqu= ette, propriety, etc.; offensive:" ________________________________ From: Paul Kyzivat Sent: Friday, September 30, 2016 11:24:49 PM To: Henning Schulzrinne; dispatch@ietf.org Subject: Re: [dispatch] draft-schulzrinne-dispatch-status-unwanted On 9/30/16 10:51 PM, Henning Schulzrinne wrote: > Yes, this is meant to indicate that the calls from that caller are > unwanted. Given that numbers get re-assigned and that sometimes people > hit the wrong button (such as hitting the "spam" button in gmail when I > meant delete), this should presumably be treated more as a statistical > indicator. I didn't want to be too prescriptive here; for example, it is > possible that such calls, if they are not yet on a global blacklist, end > up in the equivalent of the email spam folder, i.e., voicemail, or that, > again mimicking email, you get a text message indicating calls that got > this treatment, just in case this was a mistake. > > > I'll add a sentence about the caller being unwanted. > > > I had considered adding Call-Info "type" information to allow the called > party to provide more information, but I doubt that most users will want > to make in-depth selections of the nature of the badness when they just > want to get rid of the call. More detailed feedback seems more > appropriate for a post-call app-style response (and existing robocall > filtering apps seem to allow this type of labeling). > > > Call-Info can't be used in a BYE, so that method doesn't quite work. > > > My inclination is to keep it simple for now, and consider adding more > structured information as a parameter separately and later if there's nee= d. I just want to ensure that all the users of this are on the same page regarding its meaning. How it is institutionalized is more important than what the exact wording is in this document. Users are going to push a button on their phone to reject the call. (Probably the same one that is there now.) What they mean and how that is used had better be in agreement. Thanks, Paul > Henning > ------------------------------------------------------------------------ > *From:* dispatch on behalf of Paul Kyzivat > > *Sent:* Friday, September 30, 2016 10:36 PM > *To:* dispatch@ietf.org > *Subject:* Re: [dispatch] draft-schulzrinne-dispatch-status-unwanted > > Audacious move choosing 666! > > I want to verify that it is crystal clear that the meaning of this > response is that requests (often calls) from this caller are unwanted, > rather than simply that this *call* is unwanted. > > At the time of call initiation there is of course little else that the > callee has to go on to reject the call this way. But I guess I could > imagine a UA that is intended only for originating calls, that considers > *all* incoming calls to be undesirable, regardless of caller. In that > case it would be bad to use 666 if that then put the caller on a list as > an undesirable caller. > > And of course this code can be used with Reason to signify displeasure > with a call after it has been answered. At that point there may be a > wider range of reasons to object to the call. E.g., the subject matter > is objectionable, the caller is identifiable and objectionable even > though coming from a usually unobjectionable number, etc. > > It isn't necessary to boil the ocean here covering all the cases. I just > want to make certain the all those using this code have a common > understanding of the semantics. > > Thanks, > Paul > > --_000_CY1PR09MB0634367CFFD7C4718BB2F688EABD0CY1PR09MB0634namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

This is getting into deep editorial matters of taste, but "objectio= nable" isn't quite right, given common usage that this refers to conte= nt that is unsuitable for minors or in poor taste. (See, locally, http= s://www.fcc.gov/consumers/guides/protecting-children-objectionable-content-= wireless-devices). Or, from the dictionary definition:  "offending&n= bsp;good taste, manners,=  etiquette, propriety= , etc.; offensive:&qu= ot;


From: Paul Kyzivat <pk= yzivat@alum.mit.edu>
Sent: Friday, September 30, 2016 11:24:49 PM
To: Henning Schulzrinne; dispatch@ietf.org
Subject: Re: [dispatch] draft-schulzrinne-dispatch-status-unwanted
 
On 9/30/16 10:51 PM, Henning Schulzrinne wrote: > Yes, this is meant to indicate that the calls from that caller are
> unwanted. Given that numbers get re-assigned and that sometimes people=
> hit the wrong button (such as hitting the "spam" button in g= mail when I
> meant delete), this should presumably be treated more as a statistical=
> indicator. I didn't want to be too prescriptive here; for example, it = is
> possible that such calls, if they are not yet on a global blacklist, e= nd
> up in the equivalent of the email spam folder, i.e., voicemail, or tha= t,
> again mimicking email, you get a text message indicating calls that go= t
> this treatment, just in case this was a mistake.
>
>
> I'll add a sentence about the caller being unwanted.
>
>
> I had considered adding Call-Info "type" information to allo= w the called
> party to provide more information, but I doubt that most users will wa= nt
> to make in-depth selections of the nature of the badness when they jus= t
> want to get rid of the call. More detailed feedback seems more
> appropriate for a post-call app-style response (and existing robocall<= br> > filtering apps seem to allow this type of labeling).
>
>
> Call-Info can't be used in a BYE, so that method doesn't quite work. >
>
> My inclination is to keep it simple for now, and consider adding more<= br> > structured information as a parameter separately and later if there's = need.

I just want to ensure that all the users of this are on the same page
regarding its meaning. How it is institutionalized is more important
than what the exact wording is in this document. Users are going to push a button on their phone to reject the call. (Probably the same one that is there now.) What they mean and how that is used had better be in
agreement.

        Thanks,
        Paul

> Henning
> ----------------------------------------------------------------------= --
> *From:* dispatch <dispatch-bounces@ietf.org> on behalf of Paul K= yzivat
> <pkyzivat@alum.mit.edu>
> *Sent:* Friday, September 30, 2016 10:36 PM
> *To:* dispatch@ietf.org
> *Subject:* Re: [dispatch] draft-schulzrinne-dispatch-status-unwanted >
> Audacious move choosing 666!
>
> I want to verify that it is crystal clear that the meaning of this
> response is that requests (often calls) from this caller are unwanted,=
> rather than simply that this *call* is unwanted.
>
> At the time of call initiation there is of course little else that the=
> callee has to go on to reject the call this way. But I guess I could > imagine a UA that is intended only for originating calls, that conside= rs
> *all* incoming calls to be undesirable, regardless of caller. In that<= br> > case it would be bad to use 666 if that then put the caller on a list = as
> an undesirable caller.
>
> And of course this code can be used with Reason to signify displeasure=
> with a call after it has been answered. At that point there may be a > wider range of reasons to object to the call. E.g., the subject matter=
> is objectionable, the caller is identifiable and objectionable even > though coming from a usually unobjectionable number, etc.
>
> It isn't necessary to boil the ocean here covering all the cases. I ju= st
> want to make certain the all those using this code have a common
> understanding of the semantics.
>
>         Thanks,
>         Paul
>
>


 --_000_CY1PR09MB0634367CFFD7C4718BB2F688EABD0CY1PR09MB0634namp_-- From nobody Sun Nov 13 21:38:14 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBFD129543; Sun, 13 Nov 2016 21:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFEjQnJX9LP4; Sun, 13 Nov 2016 21:38:11 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC99127077; Sun, 13 Nov 2016 21:38:11 -0800 (PST) Received: from [31.133.137.110] (dhcp-896e.meeting.ietf.org [31.133.137.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAE5c8Lw025714 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 13 Nov 2016 23:38:09 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-896e.meeting.ietf.org [31.133.137.110] claimed to be [31.133.137.110] From: "Ben Campbell" To: SIPCORE Date: Mon, 14 Nov 2016 14:38:07 +0900 Message-ID: <85FA1C39-E71D-4225-AC56-6BD6B6465206@nostrum.com> In-Reply-To: <2581BBD3-557C-4BD2-B6A7-CC472FB06038@nostrum.com> References: <2581BBD3-557C-4BD2-B6A7-CC472FB06038@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_500C35E0-72AC-40F0-BB2C-4C325947C2D5_=" Embedded-HTML: [{"HTML":[782, 9452], "plain":[232, 3889], "uuid":"07E4E0D5-73EC-47BF-84B4-3EABD719FFF2"}] X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: "art-ads@ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] [sipcore] SIPCORE Rechartering X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 05:38:13 -0000 --=_MailMate_500C35E0-72AC-40F0-BB2C-4C325947C2D5_= Content-Type: text/plain; format=flowed Hi, The proposed charter (at the link below) will be reviewed by the IESG at the Dec 1 Telechat. If people have further comments, please make them as soon as possible. Thanks! Ben. On 8 Nov 2016, at 8:05, Ben Campbell wrote: > The proposed new SIPCORE charter text is now available at > https://datatracker.ietf.org/doc/charter-ietf-sipcore/ . It's > identical to the text from Adam's email, other than some potential > formatting differences. > > Thanks! > > Ben. > > On 4 Nov 2016, at 16:28, Adam Roach wrote: > >> [as SIPCORE chair] >> >> Back when we transitioned from the SIPPING/SIP working group >> structure to SIPCORE, we put relatively tight limits on the SIPCORE >> charter. This was a recognition of the fact that the volume of >> SIP-related work at the time was too large for any one working group >> to reasonably handle. Instead, the intention was that the DISPATCH >> model of creating small, short-lived working groups for specific >> topics would be a better way to manage the relatively heavy workload. >> >> Fast forward seven years to today. SIP is a much more mature >> protocol, and the inflow of new work is significantly smaller than it >> was back then. At the same time, we have had several small, >> self-contained work items show up in DISPATCH that were deemed too >> small to create a new working group for, but precluded from being >> dispatched to SIPCORE by its charter. This has led to unnecessary >> delays as we determined the best disposition for these items. >> >> We, the SIPCORE chairs and area director, seek to fix that. We would >> like to amend the SIPCORE charter to allow it to take on small, >> self-contained protocol extensions in addition to changes to the core >> SIP protocol. This is a relatively minor update to the existing >> charter, which expands the scope as described above, and adds back in >> two of the architectural principles from the SIP charter which are >> applicable only to protocol extensions. >> >> Please provide feedback on the proposed charter by sending email to >> the SIPCORE mailing list. We will also discuss this briefly during >> the DISPATCH session in Seoul. >> >> The proposed charter text follows. >> >>> The Session Initiation Protocol Core (SIPCore) working group is >>> chartered to maintain and continue the development of the SIP >>> protocol, >>> currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, >>> and >>> 6665. >>> >>> The SIPCore working group will concentrate on specifications that >>> update >>> or replace the core SIP specifications named above as well as >>> specifications pertaining to small, self-contained SIP protocol >>> extensions. The process and requirements for new SIP extensions are >>> documented in RFC5727, "Change Process for the Session Initiation >>> Protocol". >>> >>> Throughout its work, the group will strive to maintain the basic >>> model >>> and architecture defined by SIP. In particular: >>> >>> 1. Services and features are provided end-to-end whenever possible. >>> >>> 2. Reuse of existing Internet protocols and architectures and >>> integrating with other Internet applications is crucial. >>> >>> 3. Standards-track extensions and new features must be generally >>> applicable, and not applicable only to a specific set of session >>> types. >>> >>> 4. Simpler solutions that solve a given problem should be favored >>> over more complex solutions. >>> >>> The primary source of change requirements to the core SIP >>> specifications >>> (enumerated above) will be a) interoperability problems that stem >>> from >>> ambiguous, or under-defined specification, and b) requirements from >>> other working groups in the ART Area. The primary source of new >>> protocol >>> extensions is the DISPATCH working group, which will generally make >>> the >>> determination regarding whether new SIP-related work warrants a new >>> working group or belongs in an existing one. >> >> For ease of reference, the existing SIPCORE charter is at >> https://datatracker.ietf.org/doc/charter-ietf-sipcore/ >> >> Thanks! >> >> /a > >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --=_MailMate_500C35E0-72AC-40F0-BB2C-4C325947C2D5_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,
The proposed charter (at the link below) will be = reviewed by the IESG at the Dec 1 Telechat. If people have further commen= ts, please make them as soon as possible.
Thanks!
Ben.
On 8 Nov 2016, at 8:05, Ben Campbell wrote:
The proposed new SIPCORE charter text is now available= at https://datatracker.ietf.org/doc/charter-ietf-sipco= re/ . It's identical to the text from Adam's email, other than some p= otential formatting differences.
Thanks!
Ben.
On 4 Nov 2016, at 16:28, Adam Roach wrote:

[as SIPCORE chair]

Back when we transitioned from the SIPPING/SIP working group structure to SIPCORE, we put relatively tight limits on the SIPCORE charter. This was a recognition of the fact that the volume of SIP-related work at the time was too large for any one working group to reasonably handle. Instead, the intention was that the DISPATCH model of creating small, short-lived working groups for specific topics would be a better way to manage the relatively heavy workload.

Fast forward seven years to today. SIP is a much more mature protocol, and the inflow of new work is significantly smaller than it was back then. At the same time, we have had several small, self-contained work items show up in DISPATCH that were deemed too small to create a new working group for, but precluded from being dispatched to SIPCORE by its charter. This has led to unnecessary delays as we determined the best disposition for these items.

We, the SIPCORE chairs and area director, seek to fix that. We would like to amend the SIPCORE charter to allow it to take on small, self-contained protocol extensions in addition to changes to the core SIP protocol. This is a relatively minor update to the existing charter, which expands the scope as described above, and adds back in two of the architectural principles from the SIP charter which are applicable only to protocol extensions.

Please provide feedback on the proposed charter by sending email to the SIPCORE mailing list. We will also discuss this briefly during the DISPATCH session in Seoul.

The proposed charter text follows.


The= Session Initiation Protocol Core (SIPCore) working group is
cha= rtered to maintain and continue the development of the SIP protocol,
cur= rently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and
666= 5.

The= SIPCore working group will concentrate on specifications that update
or replace the core SIP specifications named above as well as
spe= cifications pertaining to small, self-contained SIP protocol
=
ext= ensions.=C2=A0 The process and requirements for new SIP extensions are
doc= umented in RFC5727, "Change Process for the Session Initiation=
Pro= tocol".

Thr= oughout its work, the group will strive to maintain the basic model
and= architecture defined by SIP. In particular:

1. Services and features are provided end-to-end whenever possible.

2. Reuse of existing Internet protocols and architectures and
=C2= =A0=C2=A0 integrating with other Internet applications is crucial.

3. Standards-track extensions and new features must be generally
=C2= =A0=C2=A0 applicable, and not applicable only to a specific set of session
=C2= =A0=C2=A0 types.

4. Simpler solutions that solve a given problem should be favored
=C2=A0= =C2=A0=C2=A0 over more complex solutions.

The= primary source of change requirements to the core SIP specifications
(en= umerated above) will be a) interoperability problems that stem from
amb= iguous, or under-defined specification, and b) requirements from
oth= er working groups in the ART Area. The primary source of new protocol
ext= ensions is the DISPATCH working group, which will generally make the<= /span>
det= ermination regarding whether new SIP-related work warrants a new<= /div>
wor= king group or belongs in an existing one.


For ease of reference, the existing SIPCORE charter is at https://datatracker.ietf.org/doc/charte= r-ietf-sipcore/

Thanks!

/a

___________________________= ____________________
dispatch mailing list
dispatch@ietf.org
___________________________= ____________________
sipcore mailing list
sipcore@ietf.org
--=_MailMate_500C35E0-72AC-40F0-BB2C-4C325947C2D5_=-- From nobody Sun Nov 13 22:21:29 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D81B129459 for ; Sun, 13 Nov 2016 22:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Au_0_kPwe7Cu for ; Sun, 13 Nov 2016 22:21:26 -0800 (PST) Received: from forward7j.cmail.yandex.net (forward7j.cmail.yandex.net [5.255.227.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082DE127077 for ; Sun, 13 Nov 2016 22:21:26 -0800 (PST) Received: from mxback1j.mail.yandex.net (mxback1j.mail.yandex.net [5.45.198.15]) by forward7j.cmail.yandex.net (Yandex) with ESMTP id E164421819 for ; Mon, 14 Nov 2016 09:21:23 +0300 (MSK) Received: from web15j.yandex.ru (web15j.yandex.ru [5.45.198.56]) by mxback1j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 0hcwKTSDwv-LNGikwfS; Mon, 14 Nov 2016 09:21:23 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1479104483; bh=hnBy8p+/CQOxb6iy8t319kC8FdGhO8tTWGjdPwKN3yQ=; h=From:To:Subject:Message-Id:Date; b=XogtKxGza0IME+dbf/nh1K1Gts037nUGlKgzWdo1F6AxWn86chQuRT5OlXag0cssW RUQ9GdYTxRLwkUXbYzzGugWHpKvZqs1Kl/DU/Mh+lih9CJ2wuFixL2lzHhssuGvG6S hKNe6HhQEMxV6MVAzJgfq8izT8zQlE2kmo3L5drY= Authentication-Results: mxback1j.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web15j.yandex.ru with HTTP; Mon, 14 Nov 2016 09:21:23 +0300 From: Anton Tveretin To: DISPATCH list MIME-Version: 1.0 Message-Id: <2312001479104483@web15j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 14 Nov 2016 11:21:23 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 06:21:28 -0000 I assume: 603 = This call is unwanted for me 603 with Expires: = This caller is unwanted for me 666 with or without Expires: = This caller is unwanted for me, and probably for other users I am unsure: 403 = This call is unwanted, but the operator may forward it. From nobody Sun Nov 13 23:53:31 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEB91296CE for ; Sun, 13 Nov 2016 23:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_t9R2xOvzMl for ; Sun, 13 Nov 2016 23:53:28 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD571296C1 for ; Sun, 13 Nov 2016 23:53:28 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id uAE6ivI0021371; Mon, 14 Nov 2016 01:54:27 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 26prshqw3t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Nov 2016 01:54:27 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uAE6sQMq009254; Mon, 14 Nov 2016 01:54:26 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uAE6sIDX009175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Nov 2016 01:54:20 -0500 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 14 Nov 2016 06:53:58 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.99]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0319.002; Mon, 14 Nov 2016 01:53:58 -0500 From: "DOLLY, MARTIN C" To: Anton Tveretin , DISPATCH list Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSPj9brLEKIQE8L0mjQFEovjCUt6DYCFyg Date: Mon, 14 Nov 2016 06:53:57 +0000 Message-ID: References: <2312001479104483@web15j.yandex.ru> In-Reply-To: <2312001479104483@web15j.yandex.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.5.177] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-14_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611140133 Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 07:53:30 -0000 The user interface needs to be simple, therefore a single button resulting = in the 666 being sent to the network. The 666 is passed to the data analytics data base, where the appropriate ac= tions are taken depending on: 1) was the 666 pre- or post-answer; 2) subscriber's profile; 3) reputation associated of the Calling Number Actions to be taken can vary from one to all of the following: 1) block that Calling Number on future calls 2) update reputation of that Calling Number 3) initiate traceback procedures 4) issue scam/fraud report to FCC/FTC Note, the action(s) taken would likely vary over time taking into account c= hanges in the subscribers profile and changes in the attack vector Regards, Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Anton Tveret= in Sent: Monday, November 14, 2016 1:21 AM To: DISPATCH list Subject: Re: [dispatch] Two new VoIP spam drafts I assume: 603 =3D This call is unwanted for me 603 with Expires: =3D This caller is unwanted for me 666 with or without Expires: =3D This caller is unwanted for me, and probab= ly for other users I am unsure: 403 =3D This call is unwanted, but the operator may forward it. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Nov 14 00:03:17 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289E6129789 for ; Mon, 14 Nov 2016 00:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_g_2g_BDQ0V for ; Mon, 14 Nov 2016 00:03:12 -0800 (PST) Received: from forward15j.cmail.yandex.net (forward15j.cmail.yandex.net [IPv6:2a02:6b8:0:1630::b5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772B1129537 for ; Mon, 14 Nov 2016 00:03:12 -0800 (PST) Received: from mxback9j.mail.yandex.net (mxback9j.mail.yandex.net [5.45.198.23]) by forward15j.cmail.yandex.net (Yandex) with ESMTP id C372F2129D; Mon, 14 Nov 2016 11:03:09 +0300 (MSK) Received: from web38j.yandex.ru (web38j.yandex.ru [5.45.198.141]) by mxback9j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 1JZtt6x95Y-39i8xep9; Mon, 14 Nov 2016 11:03:09 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1479110589; bh=La3K5Q2S/szsO+u39wl2yHZUgKUnqKyPhi+b7FFvrls=; h=From:To:Cc:Subject:Message-Id:Date; b=Zp0o1GnU1MI5aaLzuRDvz1IFXB23rAxti/BpGBZpYcg/u9ZZmDHsunVKKfGvceMlU D1sv9hzccDOS485VdOLUOvhvlgqtefaqGHATkt9F7VGqxRz4Oib5UQNp3MwMd7eujb qVuyF3ad+GF4Z0Ei1cd7ZWeH3NAaALrArVUrdL60= Authentication-Results: mxback9j.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web38j.yandex.ru with HTTP; Mon, 14 Nov 2016 11:03:09 +0300 From: Anton Tveretin To: Alexey Melnikov MIME-Version: 1.0 Message-Id: <6492861479110589@web38j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 14 Nov 2016 13:03:09 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] Request to form a new WG: JMAP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 08:03:15 -0000 Hello, Would this protocol be UNI only? So, forwarding would be SMTP? In that case, there will be interworking. Did anyone consider experience with GSM MMS? The message is submitted and retrieved with WAP (binary form of HTTP, to be simple), but inter-domain transmission is with SMTP. Or, is the intent to have one more closed (private) system? Regards, Anton. From nobody Mon Nov 14 00:24:10 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4A4129537 for ; Mon, 14 Nov 2016 00:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7kXcZO-WYPi for ; Mon, 14 Nov 2016 00:24:07 -0800 (PST) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9B1129400 for ; Mon, 14 Nov 2016 00:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/wtmds8eLVP9b+aGKUh+cDtZinWyyuOX16Dh7cyLMPA=; b=OdLJHr4fblkPZ9u9vfTCob758ahszukmnZ6U53txTOVOlzAnqFvjSYUX+jJ6QwtSUr4R2SCf4+2BxpkZ+qdGQkgxwfoRL9zyg5O3x3CZJmZ8/VeQRrxY2AV9S+gX8txvEX8bHquXLz7Nx1GTd8OIcHPDCSc4bjsWGgv6qeBMRMY= From: Henning Schulzrinne To: "DOLLY, MARTIN C" , Anton Tveretin , DISPATCH list Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSPj9SjqIJi1PJIEa3EccQvSjRiaDYCz+AgAAXnzI= Date: Mon, 14 Nov 2016 08:24:00 +0000 Message-ID: References: <2312001479104483@web15j.yandex.ru>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-microsoft-exchange-diagnostics: 1; BY1PR09MB0629; 7:OEcS1MOKguJcN1Bia7htuyyYTFoi7J7mHtQS9/c4sAqv5cSrL02LFZXNuBxnVksBA/xJJfqx75dZRidBKkLt/1shZj+ix77dL5kDGGaBjzm09o5wEy97bt15/RlI8vrig9vPWUkTf/+2ED2TepDLkIu/X5VGLDPBbK/AKv+hd6yTN2IBJoNKr6BT6KD3clgIBQ5H+ZxfPa7rkLYJqcLuodK8m3sV/0QCp4QntSEH/ThfEVv0eq8qhtPqX/1iuw7BnMkAqR7ZUlZJQzRvotmIhilWVlLlAOkxmfdE9VsGE86NVtxY01s+jBsjskBCmzEphqp4OQn99LCSuvM95EGEIs2f7lBrxHtOCR1q0OrygvM= x-ms-office365-filtering-correlation-id: 4695d771-8b28-4ac8-74d4-08d40c679670 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY1PR09MB0629; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(97927398514766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060325)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6061320); SRVR:BY1PR09MB0629; BCL:0; PCL:0; RULEID:; SRVR:BY1PR09MB0629; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(336003)(189002)(199003)(13464003)(252514010)(377454003)(99286002)(7736002)(33656002)(50986999)(76176999)(54356999)(2900100001)(3280700002)(9686002)(2950100002)(101416001)(7696004)(68736007)(189998001)(66066001)(92566002)(86362001)(2906002)(107886002)(77096005)(74316002)(5660300001)(7906003)(8676002)(81166006)(76576001)(81156014)(3660700001)(7846002)(5001770100001)(325944008)(106116001)(229853002)(105586002)(586003)(106356001)(87936001)(3846002)(102836003)(6116002)(8936002)(122556002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR09MB0629; H:BY1PR09MB0631.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY1PR09MB06311E040C2D874557EBE508EABC0BY1PR09MB0631namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2016 08:24:00.7957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR09MB0629 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 08:24:09 -0000 --_000_BY1PR09MB06311E040C2D874557EBE508EABC0BY1PR09MB0631namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree - there is no evidence that users will want to deal with more compl= exity, or remember the differences between different actions. I'm not aware= of any email client that has more than a basic "junk" or "spam" button. Th= e only mail-specific variation is that gmail pops up a modal window for mes= sages that have List-* headers, to allow unsubscribing instead of or in add= ition to marking it as spam. You could imagine some version of that for pho= ne calls, to be used by legitimate entities that want to make it easy for p= eople to get off their phone list, but that seems like a longer-term proble= m. ________________________________ From: dispatch on behalf of DOLLY, MARTIN C Sent: Monday, November 14, 2016 1:53:57 AM To: Anton Tveretin; DISPATCH list Subject: Re: [dispatch] Two new VoIP spam drafts The user interface needs to be simple, therefore a single button resulting = in the 666 being sent to the network. The 666 is passed to the data analytics data base, where the appropriate ac= tions are taken depending on: 1) was the 666 pre- or post-answer; 2) subscriber's profile; 3) reputation associated of the Calling Number Actions to be taken can vary from one to all of the following: 1) block that Calling Number on future calls 2) update reputation of that Calling Number 3) initiate traceback procedures 4) issue scam/fraud report to FCC/FTC Note, the action(s) taken would likely vary over time taking into account c= hanges in the subscribers profile and changes in the attack vector Regards, Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Anton Tveret= in Sent: Monday, November 14, 2016 1:21 AM To: DISPATCH list Subject: Re: [dispatch] Two new VoIP spam drafts I assume: 603 =3D This call is unwanted for me 603 with Expires: =3D This caller is unwanted for me 666 with or without Expires: =3D This caller is unwanted for me, and probab= ly for other users I am unsure: 403 =3D This call is unwanted, but the operator may forward it. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_BY1PR09MB06311E040C2D874557EBE508EABC0BY1PR09MB0631namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree - there is no evidence that users will want to deal with more co= mplexity, or remember the differences between different actions. I'm not aw= are of any email client that has more than a basic "junk" or &quo= t;spam" button. The only mail-specific variation is that gmail pops up a modal window for messages that have List-* headers= , to allow unsubscribing instead of or in addition to marking it as spam. Y= ou could imagine some version of that for phone calls, to be used by legiti= mate entities that want to make it easy for people to get off their phone list, but that seems like a long= er-term problem.

From: dispatch <dispat= ch-bounces@ietf.org> on behalf of DOLLY, MARTIN C <md3135@att.com>=
Sent: Monday, November 14, 2016 1:53:57 AM
To: Anton Tveretin; DISPATCH list
Subject: Re: [dispatch] Two new VoIP spam drafts
 
The user interface needs to be simple, therefore a= single button resulting in the 666 being sent to the network.

The 666 is passed to the data analytics data base, where the appropriate ac= tions are taken depending on:
1) was the 666 pre- or post-answer;
2) subscriber's profile;
3) reputation associated of the Calling Number

Actions to be taken can vary from one to all of the following:
1) block that Calling Number on future calls
2) update reputation of that Calling Number
3) initiate traceback procedures
4) issue scam/fraud report to FCC/FTC

Note, the action(s) taken would likely vary over time taking into account c= hanges in the subscribers profile and changes in the attack vector

Regards,

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360
Email: md3135@att.com



-----Original Message-----
From: dispatch [mailto:dispatc= h-bounces@ietf.org] On Behalf Of Anton Tveretin
Sent: Monday, November 14, 2016 1:21 AM
To: DISPATCH list <dispatch@ietf.org>
Subject: Re: [dispatch] Two new VoIP spam drafts

I assume:
603 =3D This call is unwanted for me
603 with Expires: =3D This caller is unwanted for me
666 with or without Expires: =3D This caller is unwanted for me, and probab= ly for other users I am unsure:
403 =3D This call is unwanted, but the operator may forward it.

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

 --_000_BY1PR09MB06311E040C2D874557EBE508EABC0BY1PR09MB0631namp_-- From nobody Mon Nov 14 00:44:50 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB877129524 for ; Mon, 14 Nov 2016 00:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbOuluPFrn41 for ; Mon, 14 Nov 2016 00:44:45 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8F81293E3 for ; Mon, 14 Nov 2016 00:44:45 -0800 (PST) Received: from dhcp-9436.meeting.ietf.org (t2001067c03700144348f8c76160f4ab8.hotel-wired.v6.meeting.ietf.org [IPv6:2001:67c:370:144:348f:8c76:160f:4ab8]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAE8igQx042134 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 14 Nov 2016 02:44:44 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host t2001067c03700144348f8c76160f4ab8.hotel-wired.v6.meeting.ietf.org [IPv6:2001:67c:370:144:348f:8c76:160f:4ab8] claimed to be dhcp-9436.meeting.ietf.org To: DISPATCH list From: "A. Jean Mahoney" Message-ID: <43215b1f-da2e-bc5d-8ee5-bba58c9bce72@nostrum.com> Date: Mon, 14 Nov 2016 17:44:41 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [dispatch] Notes from the DISPATCH 94 session X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 08:44:48 -0000 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 From nobody Mon Nov 14 01:00:53 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF71129609 for ; Mon, 14 Nov 2016 01:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJ_JSgC_Ct04 for ; Mon, 14 Nov 2016 01:00:51 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4971295C4 for ; Mon, 14 Nov 2016 01:00:50 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id t125so51285484ywc.1 for ; Mon, 14 Nov 2016 01:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=HXyuR7BgBjAUFUYUcZJwrxqQkzvqjjjCXOWXWdWSKvs=; b=m+gw8MmKbcj9olusDAzDIkKl0cflV6Kw4E/5olg1c6Zlt8Ua8kXMpViGwGVQVuAnuJ I2KxRFwz4gnJMDefYXav/YfjDWBrpogZFTwlGEDriXB7vLEbZpwdph9jbWmbiv+OMmkt mV3k57weLupMF5/8xNYuXTtn/0eEP18FAcRTNXKIWX13Eci82++cziviqfhAYbPSxW26 ZOvhyDKZAaVHHEdyUzPCTnDXp6PNfnehg3iAJZ62ak4R7K0c3RNGJvTUg5SjYM0vSOI4 gd8MiFcxjjyiPecAw6nBRpxGD2Buh1Ai8kIpL+yunjdga5kXped4RjpyD4z+N+s20k1a Jj1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HXyuR7BgBjAUFUYUcZJwrxqQkzvqjjjCXOWXWdWSKvs=; b=hhSV6IyRrA8MrD85rfaE/Ryd62cQjuIgwjzcqzkUyuuVN9OZmQjJ+vwTItIO/xWrro CUEk495ACcYH+yyxpxzIdTElUtrzLfI+GNXXCyFhWj9BzZGx+nIa/Olqu5bLbOh24pJG eSMEZQfnyzF8VciLboysdPTtlkWvCf9Z9eTJfxMJlowhT8DofWeIlEpiqlof+a8i3E3o ZsNy5KGXGqNficHFq5Ckp3skfGXgPV+1axPUGxlBQotQqTT0njyHw1Qloo2kG+t+8t2P zMiCFslvfah02fVgu3d2Z0EaRgALG/WPo2R7dFebDFOJEma4Yukb3vOVmvvPMn+0hiaf +ZZg== X-Gm-Message-State: ABUngvekrExUUYgMFlVUlddHJL1+8tKfDk1JGJ5W+ZLNIBKc+N4pOK92PDpOk4E+7Af6nndHbNiQvSwYwxSBIg== X-Received: by 10.129.99.132 with SMTP id x126mr15342579ywb.313.1479114049616; Mon, 14 Nov 2016 01:00:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.111.130 with HTTP; Mon, 14 Nov 2016 01:00:49 -0800 (PST) From: "Murray S. Kucherawy" Date: Mon, 14 Nov 2016 18:00:49 +0900 Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=001a1141cd3e8287fb05413f132a Archived-At: Subject: [dispatch] IETF 98 Important DISPATCH Dates X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 09:00:53 -0000 --001a1141cd3e8287fb05413f132a Content-Type: text/plain; charset=UTF-8 Emphasizing what was announced in today's meeting in Seoul, here are the DISPATCH process cutoff dates for IETF 98 in Chicago: * February 10, 2017: Cutoff date for BoF submissions * February 19, 2017: Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal * February 26, 2017: Cutoff for charter proposals for topics * March 5, 2017: Announcement of topics that have been dispatched for IETF 98 * March 19, 2017: Draft submission deadline -MSK, for DISPATCH --001a1141cd3e8287fb05413f132a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Emphasizing what was announced in today's meeting= in Seoul, here are the DISPATCH process cutoff dates for IETF 98 in Chicag= o:

* February 10, 2017: Cutoff date for BoF submissions
* Februar= y 19, 2017: Cutoff date to notify the chairs/DISPATCH WG of plans to submit= a proposal
* February 26, 2017: Cutoff for charter proposals for topics=
* March 5, 2017: Announcement of topics that have been dispatched for I= ETF 98
* March 19, 2017: Draft submission deadline

-MSK, fo= r DISPATCH

--001a1141cd3e8287fb05413f132a-- From nobody Mon Nov 14 08:12:49 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56954129857 for ; Mon, 14 Nov 2016 08:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLyUrfDTfAs3 for ; Mon, 14 Nov 2016 08:12:46 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC44C129469 for ; Mon, 14 Nov 2016 08:12:46 -0800 (PST) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-09v.sys.comcast.net with SMTP id 6JrvcED8b1XXB6JsEcwGmy; Mon, 14 Nov 2016 16:12:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1479139966; bh=o0qDYB0oe8irXBwAGJUfhjnHxTAtXqHutwpYlUcKfy4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=VRMCrPoX4Ae2AzGyoxKH86udY9ub+RikT1mVkVAGOkCGvA3kID/AMYHG+AtDcVswK 1m6xojlXwVuNWnVDsz3xqbD/vUIlgp8QqQ0LD02kL7dfVxTZdN2y9NGfEtMmz3I42Q qUPs8PlG3HVO1QEXbqsUH1VRw3u4k8H81AZeMHN0YykZFhIXZbWIJGX19EjETg/ei6 PyI4pl2dT4sej8rM5apWEDmZyM+mFP+je65An1YKQ74syIH+QJUa5+69sxrWCFgmuH N3ElpG4mYjykSluMGLJDt2Q8LPVXuSPwugHbFk6ShajG2o2QtOVjCSAPFdn5zLw3bw j9JYTocR+kX/w== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-04v.sys.comcast.net with SMTP id 6JsDclw5C5RRt6JsDciu2H; Mon, 14 Nov 2016 16:12:46 +0000 To: dispatch@ietf.org References: <2312001479104483@web15j.yandex.ru> From: Paul Kyzivat Message-ID: <7579c9e8-2cd2-1f41-dad3-5ad6ee5862e2@comcast.net> Date: Mon, 14 Nov 2016 11:12:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNl9VXb4MeQXmQ+vR1yeSasO3YajKAf0KNlvrMKvQkT/EGNBaxKU3ii2tl6+hUjSRrPgq/RfRTiy5ft6WPUSNa5YyQ7FK5c5dwXDIZKJThq42Uni87iZ DFe0YReO0bMtgwEbyoi5AuD2nCzRYQJ1JXY89Z4TjoDgtVQU4JZlMO+F6lkOj7Gx3Etar1vC5TJwpA== Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 16:12:48 -0000 On 11/14/16 3:24 AM, Henning Schulzrinne wrote: > I agree - there is no evidence that users will want to deal with more > complexity, or remember the differences between different actions. I'm > not aware of any email client that has more than a basic "junk" or > "spam" button. The only mail-specific variation is that gmail pops up a > modal window for messages that have List-* headers, to allow > unsubscribing instead of or in addition to marking it as spam. You could > imagine some version of that for phone calls, to be used by legitimate > entities that want to make it easy for people to get off their phone > list, but that seems like a longer-term problem. I agree with this argument for simplicity - one button. But I think it is important to make it clear to end users what that button means, so it is used appropriately, and that the provider actions are consistent with what the users are told. As Martin spelled it out there are a number of possible actions that could result. If all providers do more or less the same thing, and that is consistent with what callers are led to believe, that all will be good. OTOH, if providers use significantly different logic, then their customers may have a different understanding of what the button means. That can lead to a mess. Then the question becomes whether the definition of the response code should be the same as the definition of the presumed button. Thanks, Paul > ------------------------------------------------------------------------ > *From:* dispatch on behalf of DOLLY, MARTIN > C > *Sent:* Monday, November 14, 2016 1:53:57 AM > *To:* Anton Tveretin; DISPATCH list > *Subject:* Re: [dispatch] Two new VoIP spam drafts > > The user interface needs to be simple, therefore a single button > resulting in the 666 being sent to the network. > > The 666 is passed to the data analytics data base, where the appropriate > actions are taken depending on: > 1) was the 666 pre- or post-answer; > 2) subscriber's profile; > 3) reputation associated of the Calling Number > > Actions to be taken can vary from one to all of the following: > 1) block that Calling Number on future calls > 2) update reputation of that Calling Number > 3) initiate traceback procedures > 4) issue scam/fraud report to FCC/FTC > > Note, the action(s) taken would likely vary over time taking into > account changes in the subscribers profile and changes in the attack vector > > Regards, > > Martin C. Dolly > Lead Member of Technical Staff > Core & Government/Regulatory Standards > AT&T > Cell: +1.609.903.3360 > Email: md3135@att.com > > > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Anton > Tveretin > Sent: Monday, November 14, 2016 1:21 AM > To: DISPATCH list > Subject: Re: [dispatch] Two new VoIP spam drafts > > I assume: > 603 = This call is unwanted for me > 603 with Expires: = This caller is unwanted for me > 666 with or without Expires: = This caller is unwanted for me, and > probably for other users I am unsure: > 403 = This call is unwanted, but the operator may forward it. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Mon Nov 14 12:58:15 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237701294CC for ; Mon, 14 Nov 2016 12:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFL4OVPAyl1D for ; Mon, 14 Nov 2016 12:58:12 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A250D12946B for ; Mon, 14 Nov 2016 12:58:11 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id uAEJZAFw004271; Mon, 14 Nov 2016 14:42:38 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 26qkba8t68-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Nov 2016 14:42:37 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uAEJgapZ017393; Mon, 14 Nov 2016 14:42:36 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uAEJgVdK017311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Nov 2016 14:42:32 -0500 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 14 Nov 2016 19:42:19 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.99]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0319.002; Mon, 14 Nov 2016 14:42:19 -0500 From: "DOLLY, MARTIN C" To: Paul Kyzivat Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSPj9brLEKIQE8L0mjQFEovjCUt6DYCFyggABv3QCAAIL2AP//5r1Y Date: Mon, 14 Nov 2016 19:42:18 +0000 Message-ID: References: <2312001479104483@web15j.yandex.ru> , <7579c9e8-2cd2-1f41-dad3-5ad6ee5862e2@comcast.net> In-Reply-To: <7579c9e8-2cd2-1f41-dad3-5ad6ee5862e2@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_BC3CDE9CC20D4407B3CF62307F37F2BDattcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-14_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611140384 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 20:58:14 -0000 --_000_BC3CDE9CC20D4407B3CF62307F37F2BDattcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul We are defining Best Practices in the IPNNI Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Nov 15, 2016, at 1:12 AM, Paul Kyzivat > wrote: On 11/14/16 3:24 AM, Henning Schulzrinne wrote: I agree - there is no evidence that users will want to deal with more complexity, or remember the differences between different actions. I'm not aware of any email client that has more than a basic "junk" or "spam" button. The only mail-specific variation is that gmail pops up a modal window for messages that have List-* headers, to allow unsubscribing instead of or in addition to marking it as spam. You could imagine some version of that for phone calls, to be used by legitimate entities that want to make it easy for people to get off their phone list, but that seems like a longer-term problem. I agree with this argument for simplicity - one button. But I think it is important to make it clear to end users what that button = means, so it is used appropriately, and that the provider actions are consi= stent with what the users are told. As Martin spelled it out there are a number of possible actions that could = result. If all providers do more or less the same thing, and that is consis= tent with what callers are led to believe, that all will be good. OTOH, if = providers use significantly different logic, then their customers may have = a different understanding of what the button means. That can lead to a mess= . Then the question becomes whether the definition of the response code shoul= d be the same as the definition of the presumed button. Thanks, Paul ------------------------------------------------------------------------ *From:* dispatch > on behalf of DOLLY, MARTIN C > *Sent:* Monday, November 14, 2016 1:53:57 AM *To:* Anton Tveretin; DISPATCH list *Subject:* Re: [dispatch] Two new VoIP spam drafts The user interface needs to be simple, therefore a single button resulting in the 666 being sent to the network. The 666 is passed to the data analytics data base, where the appropriate actions are taken depending on: 1) was the 666 pre- or post-answer; 2) subscriber's profile; 3) reputation associated of the Calling Number Actions to be taken can vary from one to all of the following: 1) block that Calling Number on future calls 2) update reputation of that Calling Number 3) initiate traceback procedures 4) issue scam/fraud report to FCC/FTC Note, the action(s) taken would likely vary over time taking into account changes in the subscribers profile and changes in the attack vector Regards, Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Anton Tveretin Sent: Monday, November 14, 2016 1:21 AM To: DISPATCH list > Subject: Re: [dispatch] Two new VoIP spam drafts I assume: 603 =3D This call is unwanted for me 603 with Expires: =3D This caller is unwanted for me 666 with or without Expires: =3D This caller is unwanted for me, and probably for other users I am unsure: 403 =3D This call is unwanted, but the operator may forward it. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_BC3CDE9CC20D4407B3CF62307F37F2BDattcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Paul

We are defining Best Practices in the IPNNI<= br>

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Nov 15, 2016, at 1:12 AM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:

On 11/14/16 3:24 AM, Henning Schulzrinne wrote:
I agree - there is no evidence that users w= ill want to deal with more
complexity, or remember the differences bet= ween different actions. I'm
not aware of any email client that has more= than a basic "junk" or
"spam" button. The only mail-spec= ific variation is that gmail pops up a
modal window for messages that have List-* = headers, to allow
unsubscribing instead of or in addition to = marking it as spam. You could
imagine some version of that for phone call= s, to be used by legitimate
entities that want to make it easy for peop= le to get off their phone
list, but that seems like a longer-term pro= blem.

I agree with this argument for simplicity - one button.

But I think it is important to make it clear to end users what that b= utton means, so it is used appropriately, and that the provider actions are= consistent with what the users are told.

As Martin spelled it out there are a number of possible actions that = could result. If all providers do more or less the same thing, and that is = consistent with what callers are led to believe, that all will be good. OTO= H, if providers use significantly different logic, then their customers may have a different understanding o= f what the button means. That can lead to a mess.

Then the question becomes whether the definition of the response code= should be the same as the definition of the presumed button.

   Thanks,
   Paul

-------------------------------------------= -----------------------------
*From:* dispatch <dispatch-bounces@ietf.org> on behalf of DOLLY= , MARTIN
C <md3= 135@att.com>
*Sent:* Monday, November 14, 2016 1:53:57 A= M
*To:* Anton Tveretin; DISPATCH list<= br>
*Subject:* Re: [dispatch] Two new VoIP spam= drafts

The user interface needs to be simple, ther= efore a single button
resulting in the 666 being sent to the netw= ork.

The 666 is passed to the data analytics dat= a base, where the appropriate
actions are taken depending on:
1) was the 666 pre- or post-answer;<= br>
2) subscriber's profile;
3) reputation associated of the Calling Num= ber

Actions to be taken can vary from one to al= l of the following:
1) block that Calling Number on future call= s
2) update reputation of that Calling Number=
3) initiate traceback procedures
4) issue scam/fraud report to FCC/FTC

Note, the action(s) taken would likely vary= over time taking into
account changes in the subscribers profile = and changes in the attack vector

Regards,

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards<= /span>
AT&T
Cell: +1.609.903.3360
Email: md= 3135@att.com



-----Original Message-----
From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Anton<= /span>
Tveretin
Sent: Monday, November 14, 2016 1:21 AM
To: DISPATCH list <dispatch@ietf.org>
Subject: Re: [dispatch] Two new VoIP spam d= rafts

I assume:
603 =3D This call is unwanted for me=
603 with Expires: =3D This caller is unwant= ed for me
666 with or without Expires: =3D This calle= r is unwanted for me, and
probably for other users I am unsure:
403 =3D This call is unwanted, but the oper= ator may forward it.

___________________________________________= ____
dispatch mailing list
dispat= ch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

___________________________________________= ____
dispatch mailing list
dispat= ch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



___________________________________________= ____
dispatch mailing list
dispat= ch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dispatch
--_000_BC3CDE9CC20D4407B3CF62307F37F2BDattcom_-- From nobody Mon Nov 14 13:36:22 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD34F1293FF for ; Mon, 14 Nov 2016 13:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4RCA-zL7QiD for ; Mon, 14 Nov 2016 13:36:19 -0800 (PST) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C44129496 for ; Mon, 14 Nov 2016 13:36:18 -0800 (PST) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-10v.sys.comcast.net with SMTP id 6OuZcyaqyHqol6OvJcqL8S; Mon, 14 Nov 2016 21:36:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1479159377; bh=CRsZKtHhln6papED6IyeoeLJle9MNUD60CzFNLeBz6A=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Cxzwji+u4guFOjp0WLCVlA16rxpzZTIghdQm9HNVtBpQLBRTolIuUKTChonbwhuxe jCccOMcoazET3xu05BNfVQunwK8MMrGF1FkNGHSbqEcGLSjHXBwRD3DfFSA8p5HOff QHx5qcCxL2R9y5NmEQn7lb1wDaWdIDuz3tGlVHUJYqykpduVHbZm19eUZtIQt9Czmm QFn4ot2WT9A/uRGiDX7Toyhf9dUXB1W5euDijCOK5sRRvI5hl4Ff3xyUDSBhWnVpxQ AwJ70M3iAmFZA0tHb2FkyJuKRakapI8Tc5VFQawY2p1LYJONun6bdKw5PkNU+/nJiT Qs/IVZpskHWWQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-04v.sys.comcast.net with SMTP id 6OvIcNQb0872E6OvJcCMFV; Mon, 14 Nov 2016 21:36:17 +0000 To: "DOLLY, MARTIN C" References: <2312001479104483@web15j.yandex.ru> <7579c9e8-2cd2-1f41-dad3-5ad6ee5862e2@comcast.net> From: Paul Kyzivat Message-ID: <84d3aa4f-5d30-b05f-d1db-081a95411c17@comcast.net> Date: Mon, 14 Nov 2016 16:36:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNG0kUbvFd7RxCcvNKMw4mYRbGHLvh7+Zgog5gNwYtYGeAct06AQRm6Sc6nwMi0PyNk5K3jnNUZckQ7fjM4UFugunV5kuvYpM6p5BH6U6JmkubvGYlnM wCi4Spg9M+3w97UFUSXevTBOocBKiEyt4+/l1rPp6KMeUIwdY1h+WBWTZWJJEwuSQUvJ5xN45nEPPPrtHu9gCLpxM8u/GTbL4h4= Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 21:36:21 -0000 Martin, On 11/14/16 2:42 PM, DOLLY, MARTIN C wrote: > Paul > > We are defining Best Practices in the IPNNI Does this mean that all the providers will be acting reasonably consistently, to the extent that a user can use the same criteria for deciding whether or not to mark a call as spam regardless of what carrier he is using? E.g., presumably it will be proper to mark a call as spam if it claims to be from a Nigerian prince asking for my help in getting money out of his country. But is it also proper for a call from a spouse asking for overdue alimony? Of course users can't be prevented from marking any particular call. But over time they will hopefully which cases "do the right thing" and which do not, for the carrier they are using. One would hope those learnings will carry over between carriers. Thanks, Paul > *Martin C. Dolly* > > Lead Member of Technical Staff > > Core & Government/Regulatory Standards > > AT&T > > Cell: +1.609.903.3360 > > Email: _md3135@att.com _ > > > > > On Nov 15, 2016, at 1:12 AM, Paul Kyzivat > wrote: > >> On 11/14/16 3:24 AM, Henning Schulzrinne wrote: >>> I agree - there is no evidence that users will want to deal with more >>> complexity, or remember the differences between different actions. I'm >>> not aware of any email client that has more than a basic "junk" or >>> "spam" button. The only mail-specific variation is that gmail pops up a >>> modal window for messages that have List-* headers, to allow >>> unsubscribing instead of or in addition to marking it as spam. You could >>> imagine some version of that for phone calls, to be used by legitimate >>> entities that want to make it easy for people to get off their phone >>> list, but that seems like a longer-term problem. >> >> I agree with this argument for simplicity - one button. >> >> But I think it is important to make it clear to end users what that >> button means, so it is used appropriately, and that the provider >> actions are consistent with what the users are told. >> >> As Martin spelled it out there are a number of possible actions that >> could result. If all providers do more or less the same thing, and >> that is consistent with what callers are led to believe, that all will >> be good. OTOH, if providers use significantly different logic, then >> their customers may have a different understanding of what the button >> means. That can lead to a mess. >> >> Then the question becomes whether the definition of the response code >> should be the same as the definition of the presumed button. >> >> Thanks, >> Paul >> >>> ------------------------------------------------------------------------ >>> *From:* dispatch >> > on behalf of DOLLY, MARTIN >>> C > >>> *Sent:* Monday, November 14, 2016 1:53:57 AM >>> *To:* Anton Tveretin; DISPATCH list >>> *Subject:* Re: [dispatch] Two new VoIP spam drafts >>> >>> The user interface needs to be simple, therefore a single button >>> resulting in the 666 being sent to the network. >>> >>> The 666 is passed to the data analytics data base, where the appropriate >>> actions are taken depending on: >>> 1) was the 666 pre- or post-answer; >>> 2) subscriber's profile; >>> 3) reputation associated of the Calling Number >>> >>> Actions to be taken can vary from one to all of the following: >>> 1) block that Calling Number on future calls >>> 2) update reputation of that Calling Number >>> 3) initiate traceback procedures >>> 4) issue scam/fraud report to FCC/FTC >>> >>> Note, the action(s) taken would likely vary over time taking into >>> account changes in the subscribers profile and changes in the attack >>> vector >>> >>> Regards, >>> >>> Martin C. Dolly >>> Lead Member of Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T >>> Cell: +1.609.903.3360 >>> Email: md3135@att.com >>> >>> >>> >>> -----Original Message----- >>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Anton >>> Tveretin >>> Sent: Monday, November 14, 2016 1:21 AM >>> To: DISPATCH list > >>> Subject: Re: [dispatch] Two new VoIP spam drafts >>> >>> I assume: >>> 603 = This call is unwanted for me >>> 603 with Expires: = This caller is unwanted for me >>> 666 with or without Expires: = This caller is unwanted for me, and >>> probably for other users I am unsure: >>> 403 = This call is unwanted, but the operator may forward it. >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Nov 14 13:58:24 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B10126579 for ; Mon, 14 Nov 2016 13:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v13DZxAtmDj for ; Mon, 14 Nov 2016 13:58:20 -0800 (PST) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6C46512941A for ; Mon, 14 Nov 2016 13:58:20 -0800 (PST) X-AuditID: 1207440d-4ddff700000009a7-77-582a337a384c Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id C3.B6.02471.A733A285; Mon, 14 Nov 2016 16:58:19 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id uAELwHx4004853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Nov 2016 16:58:18 -0500 To: "DOLLY, MARTIN C" References: <2312001479104483@web15j.yandex.ru> <7579c9e8-2cd2-1f41-dad3-5ad6ee5862e2@comcast.net> <84d3aa4f-5d30-b05f-d1db-081a95411c17@comcast.net> From: Paul Kyzivat Message-ID: <186d0df9-2b11-15e6-a210-2bf485ed4850@alum.mit.edu> Date: Mon, 14 Nov 2016 16:58:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <84d3aa4f-5d30-b05f-d1db-081a95411c17@comcast.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixO6iqFttrBVhsGC1isXSSQtYLQ49eMru wOTxsn8Oo8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJmzLrIWtBmVHH/3kvWBsYHGl2MnBwSAiYS Nza/Zexi5OIQErjMKHHvyCc2COc6k0Rb/0wmkCphAQOJJ1M2soDYIgJqEs0rm6E63jJJPD75 DyzBLKAtcWn2VrAGNgEtiTmH/oPFeQXsJWbs6AKzWQRUJQ6damcDsUUF0iS2r9vNDFEjKHFy 5hOwGk6g+u0z7zNBzLSVuDMXooZZQF5i+9s5zBMY+WchaZmFpGwWkrIFjMyrGOUSc0pzdXMT M3OKU5N1i5MT8/JSi3SN9HIzS/RSU0o3MUKCkncH4/91MocYBTgYlXh4dxzVjBBiTSwrrsw9 xCjJwaQkyqugqhUhxJeUn1KZkVicEV9UmpNafIhRgoNZSYQ32gAox5uSWFmVWpQPk5LmYFES 51Vbou4nJJCeWJKanZpakFoEk5Xh4FCS4P1kCNQoWJSanlqRlplTgpBm4uAEGc4DNDzMCGR4 cUFibnFmOkT+FKOilDhvlAZQQgAkkVGaB9cLSxqvGMWBXhHm3QrSzgNMOHDdr4AGMwEN3mWu ATK4JBEhJdXAyLrDIII1QMJjat+qi4bbpJb7O/OF371e9+Owo/DZpZG/d12o1zz32WDJlaX7 Tz2SmpG06IPJmsm6h7qPLbdUuv9Qps5j5oFpu3fwLrhR4Taf0+aV/I9ru7S+rzu2ZIa/U8yC jg+teiqFbCouyjPVfomtX/Wg7NIxjaDYS3+Kz5sz/9P++2Qlh4QSS3FGoqEWc1FxIgDXbjs7 9QIAAA== Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 21:58:23 -0000 Martin, I forgot one important thing: I realize that all of this "usage" stuff is out of scope for us. The part that *is* in scope is the response code, or codes, used to signal the pressing of "the button". When somebody new is implementing SIP they will find that code and wonder how it is to be used. If definition is done by IPNNI, then how will they know to look for it? This could be an issue for somebody implementing a PBX. So the key is finding the right words to say in the definition of the response code. Perhaps it can *reference* the IPNNI best practices, or say something that tells the reader to go looking. Thanks, Paul On 11/14/16 4:36 PM, Paul Kyzivat wrote: > Martin, > > On 11/14/16 2:42 PM, DOLLY, MARTIN C wrote: >> Paul >> >> We are defining Best Practices in the IPNNI > > Does this mean that all the providers will be acting reasonably > consistently, to the extent that a user can use the same criteria for > deciding whether or not to mark a call as spam regardless of what > carrier he is using? > > E.g., presumably it will be proper to mark a call as spam if it claims > to be from a Nigerian prince asking for my help in getting money out of > his country. But is it also proper for a call from a spouse asking for > overdue alimony? > > Of course users can't be prevented from marking any particular call. But > over time they will hopefully which cases "do the right thing" and which > do not, for the carrier they are using. One would hope those learnings > will carry over between carriers. > > Thanks, > Paul > >> *Martin C. Dolly* >> >> Lead Member of Technical Staff >> >> Core & Government/Regulatory Standards >> >> AT&T >> >> Cell: +1.609.903.3360 >> >> Email: _md3135@att.com _ >> >> >> >> >> On Nov 15, 2016, at 1:12 AM, Paul Kyzivat > > wrote: >> >>> On 11/14/16 3:24 AM, Henning Schulzrinne wrote: >>>> I agree - there is no evidence that users will want to deal with more >>>> complexity, or remember the differences between different actions. I'm >>>> not aware of any email client that has more than a basic "junk" or >>>> "spam" button. The only mail-specific variation is that gmail pops up a >>>> modal window for messages that have List-* headers, to allow >>>> unsubscribing instead of or in addition to marking it as spam. You >>>> could >>>> imagine some version of that for phone calls, to be used by legitimate >>>> entities that want to make it easy for people to get off their phone >>>> list, but that seems like a longer-term problem. >>> >>> I agree with this argument for simplicity - one button. >>> >>> But I think it is important to make it clear to end users what that >>> button means, so it is used appropriately, and that the provider >>> actions are consistent with what the users are told. >>> >>> As Martin spelled it out there are a number of possible actions that >>> could result. If all providers do more or less the same thing, and >>> that is consistent with what callers are led to believe, that all will >>> be good. OTOH, if providers use significantly different logic, then >>> their customers may have a different understanding of what the button >>> means. That can lead to a mess. >>> >>> Then the question becomes whether the definition of the response code >>> should be the same as the definition of the presumed button. >>> >>> Thanks, >>> Paul >>> >>>> ------------------------------------------------------------------------ >>>> >>>> *From:* dispatch >>> > on behalf of DOLLY, MARTIN >>>> C > >>>> *Sent:* Monday, November 14, 2016 1:53:57 AM >>>> *To:* Anton Tveretin; DISPATCH list >>>> *Subject:* Re: [dispatch] Two new VoIP spam drafts >>>> >>>> The user interface needs to be simple, therefore a single button >>>> resulting in the 666 being sent to the network. >>>> >>>> The 666 is passed to the data analytics data base, where the >>>> appropriate >>>> actions are taken depending on: >>>> 1) was the 666 pre- or post-answer; >>>> 2) subscriber's profile; >>>> 3) reputation associated of the Calling Number >>>> >>>> Actions to be taken can vary from one to all of the following: >>>> 1) block that Calling Number on future calls >>>> 2) update reputation of that Calling Number >>>> 3) initiate traceback procedures >>>> 4) issue scam/fraud report to FCC/FTC >>>> >>>> Note, the action(s) taken would likely vary over time taking into >>>> account changes in the subscribers profile and changes in the attack >>>> vector >>>> >>>> Regards, >>>> >>>> Martin C. Dolly >>>> Lead Member of Technical Staff >>>> Core & Government/Regulatory Standards >>>> AT&T >>>> Cell: +1.609.903.3360 >>>> Email: md3135@att.com >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Anton >>>> Tveretin >>>> Sent: Monday, November 14, 2016 1:21 AM >>>> To: DISPATCH list > >>>> Subject: Re: [dispatch] Two new VoIP spam drafts >>>> >>>> I assume: >>>> 603 = This call is unwanted for me >>>> 603 with Expires: = This caller is unwanted for me >>>> 666 with or without Expires: = This caller is unwanted for me, and >>>> probably for other users I am unsure: >>>> 403 = This call is unwanted, but the operator may forward it. >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch > From nobody Mon Nov 14 14:09:04 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E293129619 for ; Mon, 14 Nov 2016 14:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV66eu38c6Le for ; Mon, 14 Nov 2016 14:09:01 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9022712941A for ; Mon, 14 Nov 2016 14:09:01 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id uAEM56dr013123; Mon, 14 Nov 2016 17:08:58 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 26qmn0j5fw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Nov 2016 17:08:58 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uAEM8vjp019269; Mon, 14 Nov 2016 17:08:57 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uAEM8qDH019200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Nov 2016 17:08:54 -0500 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 14 Nov 2016 22:08:41 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.99]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0319.002; Mon, 14 Nov 2016 17:08:40 -0500 From: "DOLLY, MARTIN C" To: Paul Kyzivat Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSPj9brLEKIQE8L0mjQFEovjCUt6DYCFyggABv3QCAAIL2AP//5r1YgABzqAD//7R4UA== Date: Mon, 14 Nov 2016 22:08:40 +0000 Message-ID: References: <2312001479104483@web15j.yandex.ru> <7579c9e8-2cd2-1f41-dad3-5ad6ee5862e2@comcast.net> <84d3aa4f-5d30-b05f-d1db-081a95411c17@comcast.net> In-Reply-To: <84d3aa4f-5d30-b05f-d1db-081a95411c17@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.59.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611140422 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 22:09:03 -0000 Paul, That is correct. The goal is for the user to have a common experience indep= endent of device type or carrier, to the extent possible. There is a need for consumer education, and yes there will be an ongoing le= arning period for the carriers. Regards, Martin -----Original Message----- From: Paul Kyzivat [mailto:paul.kyzivat@comcast.net]=20 Sent: Monday, November 14, 2016 4:36 PM To: DOLLY, MARTIN C Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts Martin, On 11/14/16 2:42 PM, DOLLY, MARTIN C wrote: > Paul > > We are defining Best Practices in the IPNNI Does this mean that all the providers will be acting reasonably consistentl= y, to the extent that a user can use the same criteria for deciding whether= or not to mark a call as spam regardless of what carrier he is using? E.g., presumably it will be proper to mark a call as spam if it claims to b= e from a Nigerian prince asking for my help in getting money out of his cou= ntry. But is it also proper for a call from a spouse asking for overdue ali= mony? Of course users can't be prevented from marking any particular call. But ov= er time they will hopefully which cases "do the right thing" and which do n= ot, for the carrier they are using. One would hope those learnings will car= ry over between carriers. Thanks, Paul > *Martin C. Dolly* > > Lead Member of Technical Staff > > Core & Government/Regulatory Standards > > AT&T > > Cell: +1.609.903.3360 > > Email: _md3135@att.com _ > > > > > On Nov 15, 2016, at 1:12 AM, Paul Kyzivat > wrote: > >> On 11/14/16 3:24 AM, Henning Schulzrinne wrote: >>> I agree - there is no evidence that users will want to deal with=20 >>> more complexity, or remember the differences between different=20 >>> actions. I'm not aware of any email client that has more than a=20 >>> basic "junk" or "spam" button. The only mail-specific variation is=20 >>> that gmail pops up a modal window for messages that have List-*=20 >>> headers, to allow unsubscribing instead of or in addition to marking=20 >>> it as spam. You could imagine some version of that for phone calls,=20 >>> to be used by legitimate entities that want to make it easy for=20 >>> people to get off their phone list, but that seems like a longer-term p= roblem. >> >> I agree with this argument for simplicity - one button. >> >> But I think it is important to make it clear to end users what that=20 >> button means, so it is used appropriately, and that the provider=20 >> actions are consistent with what the users are told. >> >> As Martin spelled it out there are a number of possible actions that=20 >> could result. If all providers do more or less the same thing, and=20 >> that is consistent with what callers are led to believe, that all=20 >> will be good. OTOH, if providers use significantly different logic,=20 >> then their customers may have a different understanding of what the=20 >> button means. That can lead to a mess. >> >> Then the question becomes whether the definition of the response code=20 >> should be the same as the definition of the presumed button. >> >> Thanks, >> Paul >> >>> -------------------------------------------------------------------- >>> ---- >>> *From:* dispatch >> > on behalf of DOLLY, MARTIN C=20 >>> > >>> *Sent:* Monday, November 14, 2016 1:53:57 AM >>> *To:* Anton Tveretin; DISPATCH list >>> *Subject:* Re: [dispatch] Two new VoIP spam drafts >>> >>> The user interface needs to be simple, therefore a single button=20 >>> resulting in the 666 being sent to the network. >>> >>> The 666 is passed to the data analytics data base, where the=20 >>> appropriate actions are taken depending on: >>> 1) was the 666 pre- or post-answer; >>> 2) subscriber's profile; >>> 3) reputation associated of the Calling Number >>> >>> Actions to be taken can vary from one to all of the following: >>> 1) block that Calling Number on future calls >>> 2) update reputation of that Calling Number >>> 3) initiate traceback procedures >>> 4) issue scam/fraud report to FCC/FTC >>> >>> Note, the action(s) taken would likely vary over time taking into=20 >>> account changes in the subscribers profile and changes in the attack=20 >>> vector >>> >>> Regards, >>> >>> Martin C. Dolly >>> Lead Member of Technical Staff >>> Core & Government/Regulatory Standards AT&T >>> Cell: +1.609.903.3360 >>> Email: md3135@att.com >>> >>> >>> >>> -----Original Message----- >>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Anton >>> Tveretin >>> Sent: Monday, November 14, 2016 1:21 AM >>> To: DISPATCH list > >>> Subject: Re: [dispatch] Two new VoIP spam drafts >>> >>> I assume: >>> 603 =3D This call is unwanted for me >>> 603 with Expires: =3D This caller is unwanted for me >>> 666 with or without Expires: =3D This caller is unwanted for me, and >>> probably for other users I am unsure: >>> 403 =3D This call is unwanted, but the operator may forward it. >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Nov 14 14:21:35 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3471B129619 for ; Mon, 14 Nov 2016 14:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (768-bit key) reason="fail (body has been altered)" header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkAHuu9eWLEj for ; Mon, 14 Nov 2016 14:21:31 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id ACAF312941A for ; Mon, 14 Nov 2016 14:21:31 -0800 (PST) Received: (qmail 17563 invoked by uid 0); 14 Nov 2016 22:21:28 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 14 Nov 2016 22:21:28 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id 7yGP1u00w1MNPNq01yGSUL; Mon, 14 Nov 2016 15:16:27 -0700 X-Authority-Analysis: v=2.1 cv=YNIMl32x c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=L24OOQBejmoA:10 a=ZZnuYtJkoWoA:10 a=48vgC7mUAAAA:8 a=C_IRinGWAAAA:8 a=zQP7CpKOAAAA:8 a=_Lolmeyex5M7nk81lVcA:9 a=La_ho7n-88XPqilX:21 a=RdHZJt6cjkt_sgZs:21 a=QEXdDO2ut3YA:10 a=qM39cor4HRgA:10 a=K2lU_Ab98eoA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=VOW5rJRXBamZ5z19bD7L:22 a=obGFCI3_7AGB19sD6zJV:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=EvS3U5lWdlmKKz8Yyzm5L8FY0Kj7RKWb03mzGA7DaP8=; b=RS/Y5KpOAPJP/8TNyA11d+Bjbe Yp2BNGMclCtJULInYcQSbeQV+xIng0LsOWN5+kjCXpboatxo/7t2O+YhRcuqEku2UwH/mIaUWa87s +rHsMVTl1g4qXyIWwn9jZrvTP; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:61737 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1c6PY9-0003RM-2R; Mon, 14 Nov 2016 15:16:25 -0700 User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Mon, 14 Nov 2016 17:16:22 -0500 From: Richard Shockey To: Paul Kyzivat , Message-ID: <3B81E7AC-C358-4918-8296-17426567A50D@shockey.us> Thread-Topic: [dispatch] Two new VoIP spam drafts References: <2312001479104483@web15j.yandex.ru> <7579c9e8-2cd2-1f41-dad3-5ad6ee5862e2@comcast.net> <84d3aa4f-5d30-b05f-d1db-081a95411c17@comcast.net> In-Reply-To: <84d3aa4f-5d30-b05f-d1db-081a95411c17@comcast.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1c6PY9-0003RM-2R X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:61737 X-Source-Auth: richard+shockey.us X-Email-Count: 2 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 22:21:34 -0000 Martin is correct here the concept of a BCP here would be some industry wide agreement on behaivors, especially as it might relate to successful Validation Display perhaps industry agreement on a single graphic logo. We are going to try and apply consistant data analyitics as well at termination. That also may involve some data sharing as well but that will have to be worked out with the regulators. Its early but these are good points for all of us to consider. What we are all agreed on is that this needs to be pretty darn simple. On 11/14/16, 4:36 PM, "dispatch on behalf of Paul Kyzivat" wrote: Martin, On 11/14/16 2:42 PM, DOLLY, MARTIN C wrote: > Paul > > We are defining Best Practices in the IPNNI Does this mean that all the providers will be acting reasonably consistently, to the extent that a user can use the same criteria for deciding whether or not to mark a call as spam regardless of what carrier he is using? E.g., presumably it will be proper to mark a call as spam if it claims to be from a Nigerian prince asking for my help in getting money out of his country. But is it also proper for a call from a spouse asking for overdue alimony? Of course users can't be prevented from marking any particular call. But over time they will hopefully which cases "do the right thing" and which do not, for the carrier they are using. One would hope those learnings will carry over between carriers. Thanks, Paul > *Martin C. Dolly* > > Lead Member of Technical Staff > > Core & Government/Regulatory Standards > > AT&T > > Cell: +1.609.903.3360 > > Email: _md3135@att.com _ > > > > > On Nov 15, 2016, at 1:12 AM, Paul Kyzivat > wrote: > >> On 11/14/16 3:24 AM, Henning Schulzrinne wrote: >>> I agree - there is no evidence that users will want to deal with more >>> complexity, or remember the differences between different actions. I'm >>> not aware of any email client that has more than a basic "junk" or >>> "spam" button. The only mail-specific variation is that gmail pops up a >>> modal window for messages that have List-* headers, to allow >>> unsubscribing instead of or in addition to marking it as spam. You could >>> imagine some version of that for phone calls, to be used by legitimate >>> entities that want to make it easy for people to get off their phone >>> list, but that seems like a longer-term problem. >> >> I agree with this argument for simplicity - one button. >> >> But I think it is important to make it clear to end users what that >> button means, so it is used appropriately, and that the provider >> actions are consistent with what the users are told. >> >> As Martin spelled it out there are a number of possible actions that >> could result. If all providers do more or less the same thing, and >> that is consistent with what callers are led to believe, that all will >> be good. OTOH, if providers use significantly different logic, then >> their customers may have a different understanding of what the button >> means. That can lead to a mess. >> >> Then the question becomes whether the definition of the response code >> should be the same as the definition of the presumed button. >> >> Thanks, >> Paul >> >>> ------------------------------------------------------------------------ >>> *From:* dispatch >> > on behalf of DOLLY, MARTIN >>> C > >>> *Sent:* Monday, November 14, 2016 1:53:57 AM >>> *To:* Anton Tveretin; DISPATCH list >>> *Subject:* Re: [dispatch] Two new VoIP spam drafts >>> >>> The user interface needs to be simple, therefore a single button >>> resulting in the 666 being sent to the network. >>> >>> The 666 is passed to the data analytics data base, where the appropriate >>> actions are taken depending on: >>> 1) was the 666 pre- or post-answer; >>> 2) subscriber's profile; >>> 3) reputation associated of the Calling Number >>> >>> Actions to be taken can vary from one to all of the following: >>> 1) block that Calling Number on future calls >>> 2) update reputation of that Calling Number >>> 3) initiate traceback procedures >>> 4) issue scam/fraud report to FCC/FTC >>> >>> Note, the action(s) taken would likely vary over time taking into >>> account changes in the subscribers profile and changes in the attack >>> vector >>> >>> Regards, >>> >>> Martin C. Dolly >>> Lead Member of Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T >>> Cell: +1.609.903.3360 >>> Email: md3135@att.com >>> >>> >>> >>> -----Original Message----- >>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Anton >>> Tveretin >>> Sent: Monday, November 14, 2016 1:21 AM >>> To: DISPATCH list > >>> Subject: Re: [dispatch] Two new VoIP spam drafts >>> >>> I assume: >>> 603 = This call is unwanted for me >>> 603 with Expires: = This caller is unwanted for me >>> 666 with or without Expires: = This caller is unwanted for me, and >>> probably for other users I am unsure: >>> 403 = This call is unwanted, but the operator may forward it. >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Nov 14 14:30:16 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABD912941A for ; Mon, 14 Nov 2016 14:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRiRhxd2HpxX for ; Mon, 14 Nov 2016 14:30:13 -0800 (PST) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 47663129421 for ; Mon, 14 Nov 2016 14:30:13 -0800 (PST) Received: (qmail 24774 invoked by uid 0); 14 Nov 2016 22:30:13 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy1.mail.unifiedlayer.com with SMTP; 14 Nov 2016 22:30:13 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id 7yR91u0151MNPNq01yRCoU; Mon, 14 Nov 2016 15:25:13 -0700 X-Authority-Analysis: v=2.1 cv=Zpp+dbLG c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=L24OOQBejmoA:10 a=ZZnuYtJkoWoA:10 a=NvC-MaXgAAAA:8 a=HeG67adPAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=C_IRinGWAAAA:8 a=eU3qJzSJT18Eal8L2gMA:9 a=j_O80r-Pos42YNrX:21 a=im_l0bklLIXPzkxa:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=qM39cor4HRgA:10 a=K2lU_Ab98eoA:10 a=biW16iZ0_V8A:10 a=UKfiNL491nEA:10 a=lCKLaNiBY0u9urARF_50:22 a=jlXKPczUY4Vio7-9iMRd:22 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=obGFCI3_7AGB19sD6zJV:22 a=VOW5rJRXBamZ5z19bD7L:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date; bh=NaHKb5WHH58kyFh99o9DsRyBNynG7DRbbAS8TUjgLfs=; b=o2sCNHhbSsZJKocV+Hdjhkd8LD Kua6olrZEhOB2leDP84SQJX1WH1ASOJeh3hjahkZbpqkijyC89Y1wXWlKYBxtkfyCsiM2hvpR12WL DUMGVCv5BytgUm6X6HgPm0RMA; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:61854 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1c6Pgb-0003pp-CQ; Mon, 14 Nov 2016 15:25:09 -0700 User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Mon, 14 Nov 2016 17:25:06 -0500 From: Richard Shockey To: "DOLLY, MARTIN C" , Paul Kyzivat Message-ID: Thread-Topic: [dispatch] Two new VoIP spam drafts References: <2312001479104483@web15j.yandex.ru> <7579c9e8-2cd2-1f41-dad3-5ad6ee5862e2@comcast.net> <84d3aa4f-5d30-b05f-d1db-081a95411c17@comcast.net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1c6Pgb-0003pp-CQ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:61854 X-Source-Auth: richard+shockey.us X-Email-Count: 4 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 22:30:15 -0000 +1 and one other thing this is not a US specific initiative. =20 The CRTC in Ottawa acted last week to spin up activity among the Canadian C= arriers. The actual CRTC order. http://www.crtc.gc.ca/eng/archive/2016/2016-442.htm The Canadian Interconnection Steering Group has been empowered to be their = strikeforce. http://www.crtc.gc.ca/eng/cisc-cdci.htm I just got back from London and the NICC General Meeting ( its sort of thei= r ATIS ) and this was topic #1. http://www.niccstandards.org.uk/meetings/forum-2016.cfm It would be a fair bet there will be HMG action as well in 2017. =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 On 11/14/16, 5:08 PM, "dispatch on behalf of DOLLY, MARTIN C" wrote: Paul, =20 That is correct. The goal is for the user to have a common experience i= ndependent of device type or carrier, to the extent possible. =20 There is a need for consumer education, and yes there will be an ongoin= g learning period for the carriers. =20 Regards, =20 Martin =20 -----Original Message----- From: Paul Kyzivat [mailto:paul.kyzivat@comcast.net]=20 Sent: Monday, November 14, 2016 4:36 PM To: DOLLY, MARTIN C Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts =20 Martin, =20 On 11/14/16 2:42 PM, DOLLY, MARTIN C wrote: > Paul > > We are defining Best Practices in the IPNNI =20 Does this mean that all the providers will be acting reasonably consist= ently, to the extent that a user can use the same criteria for deciding whet= her or not to mark a call as spam regardless of what carrier he is using? =20 E.g., presumably it will be proper to mark a call as spam if it claims = to be from a Nigerian prince asking for my help in getting money out of his = country. But is it also proper for a call from a spouse asking for overdue a= limony? =20 Of course users can't be prevented from marking any particular call. Bu= t over time they will hopefully which cases "do the right thing" and which d= o not, for the carrier they are using. One would hope those learnings will c= arry over between carriers. =20 Thanks, Paul =20 > *Martin C. Dolly* > > Lead Member of Technical Staff > > Core & Government/Regulatory Standards > > AT&T > > Cell: +1.609.903.3360 > > Email: _md3135@att.com _ > > > > > On Nov 15, 2016, at 1:12 AM, Paul Kyzivat > wrote: > >> On 11/14/16 3:24 AM, Henning Schulzrinne wrote: >>> I agree - there is no evidence that users will want to deal with=20 >>> more complexity, or remember the differences between different=20 >>> actions. I'm not aware of any email client that has more than a=20 >>> basic "junk" or "spam" button. The only mail-specific variation is=20 >>> that gmail pops up a modal window for messages that have List-*=20 >>> headers, to allow unsubscribing instead of or in addition to markin= g=20 >>> it as spam. You could imagine some version of that for phone calls,= =20 >>> to be used by legitimate entities that want to make it easy for=20 >>> people to get off their phone list, but that seems like a longer-te= rm problem. >> >> I agree with this argument for simplicity - one button. >> >> But I think it is important to make it clear to end users what that=20 >> button means, so it is used appropriately, and that the provider=20 >> actions are consistent with what the users are told. >> >> As Martin spelled it out there are a number of possible actions that= =20 >> could result. If all providers do more or less the same thing, and=20 >> that is consistent with what callers are led to believe, that all=20 >> will be good. OTOH, if providers use significantly different logic,=20 >> then their customers may have a different understanding of what the=20 >> button means. That can lead to a mess. >> >> Then the question becomes whether the definition of the response cod= e=20 >> should be the same as the definition of the presumed button. >> >> Thanks, >> Paul >> >>> -------------------------------------------------------------------= - >>> ---- >>> *From:* dispatch >> > on behalf of DOLLY, MARTIN C=20 >>> > >>> *Sent:* Monday, November 14, 2016 1:53:57 AM >>> *To:* Anton Tveretin; DISPATCH list >>> *Subject:* Re: [dispatch] Two new VoIP spam drafts >>> >>> The user interface needs to be simple, therefore a single button=20 >>> resulting in the 666 being sent to the network. >>> >>> The 666 is passed to the data analytics data base, where the=20 >>> appropriate actions are taken depending on: >>> 1) was the 666 pre- or post-answer; >>> 2) subscriber's profile; >>> 3) reputation associated of the Calling Number >>> >>> Actions to be taken can vary from one to all of the following: >>> 1) block that Calling Number on future calls >>> 2) update reputation of that Calling Number >>> 3) initiate traceback procedures >>> 4) issue scam/fraud report to FCC/FTC >>> >>> Note, the action(s) taken would likely vary over time taking into=20 >>> account changes in the subscribers profile and changes in the attac= k=20 >>> vector >>> >>> Regards, >>> >>> Martin C. Dolly >>> Lead Member of Technical Staff >>> Core & Government/Regulatory Standards AT&T >>> Cell: +1.609.903.3360 >>> Email: md3135@att.com >>> >>> >>> >>> -----Original Message----- >>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Anto= n >>> Tveretin >>> Sent: Monday, November 14, 2016 1:21 AM >>> To: DISPATCH list > >>> Subject: Re: [dispatch] Two new VoIP spam drafts >>> >>> I assume: >>> 603 =3D This call is unwanted for me >>> 603 with Expires: =3D This caller is unwanted for me >>> 666 with or without Expires: =3D This caller is unwanted for me, and >>> probably for other users I am unsure: >>> 403 =3D This call is unwanted, but the operator may forward it. >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch =20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 From nobody Mon Nov 14 23:26:18 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F489129A14 for ; Mon, 14 Nov 2016 23:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF1C7dF1GzRb for ; Mon, 14 Nov 2016 23:26:14 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42B812956B for ; Mon, 14 Nov 2016 23:26:14 -0800 (PST) Received: from dhcp-8915.meeting.ietf.org (t2001067c03700128fdd5b8a857fbe985.v6.meeting.ietf.org [IPv6:2001:67c:370:128:fdd5:b8a8:57fb:e985]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAF7QBvw079810 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 15 Nov 2016 01:26:13 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host t2001067c03700128fdd5b8a857fbe985.v6.meeting.ietf.org [IPv6:2001:67c:370:128:fdd5:b8a8:57fb:e985] claimed to be dhcp-8915.meeting.ietf.org To: DISPATCH list References: <43215b1f-da2e-bc5d-8ee5-bba58c9bce72@nostrum.com> From: "A. Jean Mahoney" Message-ID: Date: Tue, 15 Nov 2016 16:26:10 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <43215b1f-da2e-bc5d-8ee5-bba58c9bce72@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Notes from the DISPATCH 94 session X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 07:26:17 -0000 Edit: DISPATCH 97 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 From nobody Thu Nov 17 00:27:10 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D5C1296A2; Thu, 17 Nov 2016 00:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM34JkTe-etA; Thu, 17 Nov 2016 00:27:06 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3D212941A; Thu, 17 Nov 2016 00:27:06 -0800 (PST) Received: from dhcp-978a.meeting.ietf.org (dhcp-978a.meeting.ietf.org [31.133.151.138]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAH8R2Z4048601 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Nov 2016 02:27:04 -0600 (CST) (envelope-from adam@nostrum.com) To: Brian Rosen , IETF STIR Mail List References: From: Adam Roach Message-ID: Date: Thu, 17 Nov 2016 17:27:01 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "dispatch@ietf.org" , 'SIPCORE' Subject: [dispatch] Discussion venue for 666 (was SHAKEN but not STIRred means 666 can cause collateral damage) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 'SIPCORE' List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:27:08 -0000 [as SIPCORE chair] On 11/17/16 10:14, Brian Rosen wrote: > I’ve sent this to stir, even though it has not been decided where the 666 draft will land My understanding coming out of DISPATCH is that 666 is appropriate for SIPCORE, assuming the new charter is approved by the IESG. I expect the proposed charter changes to be uncontroversial. Based on the foregoing, we (the SIPCORE chairs) think it would be appropriate to hold general discussion of both of the draft-schulzrinne-dispatch-callinfo-spam and draft-schulzrinne-dispatch-status-unwanted documents on the SIPCORE list. I've copied DISPATCH and SIPCORE on this message, and set followups to SIPCORE. /a From nobody Thu Nov 17 00:51:58 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDEB1295EA for ; Thu, 17 Nov 2016 00:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnqepH-gJxr3 for ; Thu, 17 Nov 2016 00:51:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7945B1294F7 for ; Thu, 17 Nov 2016 00:51:54 -0800 (PST) Received: from dhcp-9744.meeting.ietf.org (dhcp-9744.meeting.ietf.org [31.133.151.68]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAH8pqZf050850 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 17 Nov 2016 02:51:53 -0600 (CST) (envelope-from rjsparks@nostrum.com) To: dispatch@ietf.org References: From: Robert Sparks Message-ID: Date: Thu, 17 Nov 2016 17:51:52 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Discussion venue for 666 (was SHAKEN but not STIRred means 666 can cause collateral damage) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:51:56 -0000 [as a STIR co-chair] I agree with this. Later in the discussion, I expect we will recommend splitting the passport extension work out and running that through STIR, but that doesn't need to happen immediately. If we discover that there's frequent unnatural tension in needing to talk about stir things while figuring out the SIP mechanics in these drafts, we can revisit. RjS On 11/17/16 5:27 PM, Adam Roach wrote: > [as SIPCORE chair] > > On 11/17/16 10:14, Brian Rosen wrote: >> I’ve sent this to stir, even though it has not been decided where the >> 666 draft will land > > My understanding coming out of DISPATCH is that 666 is appropriate for > SIPCORE, assuming the new charter is approved by the IESG. I expect > the proposed charter changes to be uncontroversial. > > Based on the foregoing, we (the SIPCORE chairs) think it would be > appropriate to hold general discussion of both of the > draft-schulzrinne-dispatch-callinfo-spam and > draft-schulzrinne-dispatch-status-unwanted documents on the SIPCORE list. > > I've copied DISPATCH and SIPCORE on this message, and set followups to > SIPCORE. > > /a > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Nov 17 01:13:21 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02831127077 for ; Thu, 17 Nov 2016 01:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4svedSl5B4C for ; Thu, 17 Nov 2016 01:13:18 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB88129632 for ; Thu, 17 Nov 2016 01:13:17 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id w33so125519458qtc.3 for ; Thu, 17 Nov 2016 01:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=fQDXWilV/xUMVWMvh3+kA6IUmck0GyOItm9AcmYt9Tg=; b=T0yNT8A1xviVZg+ANeKiccTY7bhKKCm21BJdQE4ioKzJ/yK9q05iDEfO0rOqdqhK94 KzEAyXJXhKJd7KMDBARchgSDh7vVVP9XhPLTw/4UdOrut8185lb3m1CPnqQ2Qc5V/mtH 5PzmeHNiLDlzgDt1jgte+/olDzv5oqtBLXFhimLIjY/+JbrSD/jEGwhoeWDwvWQ9o5a+ 2aCY1t7XbZ6TFt/4meBJ+ObbpRXNHGgcpgKqcB6Xwpit858O2/XPFHTdMd+GGKrAmqNB 9gyYkwVkKdk+ivvJY/lJ3XY0GdbBLXq0XMZ59Utc782c/0vppN0rsqw2XkGyvXghjsPT Jalw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fQDXWilV/xUMVWMvh3+kA6IUmck0GyOItm9AcmYt9Tg=; b=ANFxOhR69Px1Y6aGsfhhAMIDxFJoNUq06B7TmszNxokimnq0sJuT1Q3tsAEK6FaU+e q+aaKwle77q2M+7CCnPCqyRKo7peDSJOmJryeuR9Cdc38yi0TmanRDr3jNGhS6KmDsbh hQJ7d+zaZi/0r5LXPcAg2oqiEr+tSNZW1GXHI7DjWQrNo3Cw9es0LCpETx6CRJ0ao+J1 xW7jDjvfYvtmrHVpK3vohbWjU6mzLvhN9Tv9/CSgMxmM1OQuRdo+Ch5H3T2N3DuthOAQ BOh2i3rRKGhHfxfi4TpDl6v0XhyXSkVt+juRW0+h+L9VZA+6RlptfChzM7VztT+R+kpd tVMQ== X-Gm-Message-State: AKaTC02dxPgEkBmL0DaPK2LnR6A5jWFMUSRq16iKUVKHHYF6xphGQgE4fj3UTRVU/Wa9yPOkN1km5YRxLGtZXw== X-Received: by 10.237.44.161 with SMTP id g30mr1177734qtd.144.1479373997052; Thu, 17 Nov 2016 01:13:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 17 Nov 2016 01:13:16 -0800 (PST) Received: by 10.140.85.7 with HTTP; Thu, 17 Nov 2016 01:13:16 -0800 (PST) From: Martin Thomson Date: Thu, 17 Nov 2016 18:13:16 +0900 Message-ID: To: DISPATCH Content-Type: multipart/alternative; boundary=94eb2c125848959c2105417b9915 Archived-At: Subject: [dispatch] Please dispatch draft-thomson-avtcore-sdp-uks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 09:13:20 -0000 --94eb2c125848959c2105417b9915 Content-Type: text/plain; charset=UTF-8 We had a pretty constructive discussion about this in avtmumble today and the conclusion was that this was something we should look at. The general sense there was that this belonged with RFC 4572 (not part of the update, don't panic) in MMUSIC, but I observed that there are zero SDP changes in the document. Maybe this group can help. For those not present this morning, we described an extremely narrow attack on the use of RFC 4572. The draft explains the attack; and defines mitigations. --94eb2c125848959c2105417b9915 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

We had a pretty constructive discussion about this in avtmum= ble today and the conclusion was that this was something we should look at.= =C2=A0 The general sense there was that this belonged with RFC 4572 (not pa= rt of the update, don't panic) in MMUSIC, but I observed that there are= zero SDP changes in the document.=C2=A0 Maybe this group can help.

For those not present this morning, we described an extremel= y narrow attack on the use of RFC 4572.=C2=A0 The draft explains the attack= ; and defines mitigations.

--94eb2c125848959c2105417b9915-- From nobody Mon Nov 21 09:49:06 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75684129A9D for ; Mon, 21 Nov 2016 09:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OxbJHNAMOKY for ; Mon, 21 Nov 2016 09:49:02 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id B01BC1295C6 for ; Mon, 21 Nov 2016 09:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1479750542; d=isode.com; s=june2016; i=@isode.com; bh=FuaQOR1zuBE1fW4dEmGf/JsUcgP+X+uhKlmo2TWUEEo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=bPXYcg7fZrCeaNcD3QdEZWTdphwkSeZAMBtJuGBwyY7j2mYn7jJWHoEqX3O240ThN8h8RB tqtjucy7NYmUUvuUtF9wQfvDdzUVumWdjiNN2IBjeBFnNmwkSsZmqBmSTigGcihd2xylqY QraG4r0KCUZyAqWJ9QvvTUWaDJSiP4A=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 21 Nov 2016 17:49:01 +0000 From: Alexey Melnikov To: dispatch@ietf.org References: <1478836665.322873.784300457.3FB705B7@webmail.messagingengine.com> Message-ID: <5a692534-72f4-8f67-b9c6-d3934922935c@isode.com> Date: Mon, 21 Nov 2016 17:48:58 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <1478836665.322873.784300457.3FB705B7@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F646898540CCD8D2F48CA774" Archived-At: Subject: [dispatch] Fwd: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 17:49:05 -0000 This is a multi-part message in MIME format. --------------F646898540CCD8D2F48CA774 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To answer some questions that were asked on this mailing list. Begin forwarded message: > *From:* Neil Jenkins > > *Date:* 11 November 2016 at 12:57:45 GMT+9 > *To:* imapext@ietf.org > *Subject:* *Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP* > > # Draft proposals and implementations > > As Arnt pointed out, "rough consensus and running code" are key here, > and the current draft of the JMAP spec is being implemented in Cyrus > IMAPd and Dovecot (the two largest open-source IMAP servers), as well as > other open source projects like Apache James and Linagora. Roundcube > have stated they plan to build their next-generation client on JMAP. > > On the proprietary side, Atmail have a JMAP proxy and webmail client > they are releasing to production very soon, and we at FastMail have a > version of our client that talks JMAP too. > > There is interest among other large mailbox providers/mail client > authors, but they don't tend to be early adopters as much. > > The current specification drafts can be found at: > > https://datatracker.ietf.org/doc/draft-jenkins-jmap/ (The generic JMAP > protocol) > https://datatracker.ietf.org/doc/draft-jenkins-jmapmail/ (Mail over > JMAP) > > We have also developed an open-source JMAP proxy, which you can connect > to an IMAP server to try out the protocol and see what happens over the > wire. There's a hosted version at http://proxy.jmap.io/, or you can grab > the code from https://github.com/jmapio/jmap-perl --------------F646898540CCD8D2F48CA774 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
To answer some questions that were asked on this mailing list.

Begin forwarded message:

From: Neil Jenkins <neilj@fastmail.com>
Date: 11 November 2016 at 12:57:45 GMT+9
To: imapext@ietf.org
Subject: Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP

# Draft proposals and implementations

As Arnt pointed out, "rough consensus and running code" are key here,
and the current draft of the JMAP spec is being implemented in Cyrus
IMAPd and Dovecot (the two largest open-source IMAP servers), as well as
other open source projects like Apache James and Linagora. Roundcube
have stated they plan to build their next-generation client on JMAP.

On the proprietary side, Atmail have a JMAP proxy and webmail client
they are releasing to production very soon, and we at FastMail have a
version of our client that talks JMAP too.

There is interest among other large mailbox providers/mail client
authors, but they don't tend to be early adopters as much.

The current specification drafts can be found at:

https://datatracker.ietf.org/doc/draft-jenkins-jmap/ (The generic JMAP
protocol)
https://datatracker.ietf.org/doc/draft-jenkins-jmapmail/ (Mail over
JMAP)

We have also developed an open-source JMAP proxy, which you can connect
to an IMAP server to try out the protocol and see what happens over the
wire. There's a hosted version at http://proxy.jmap.io/, or you can grab
the code from https://github.com/jmapio/jmap-perl
--------------F646898540CCD8D2F48CA774-- From nobody Mon Nov 21 09:51:18 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE56129651 for ; Mon, 21 Nov 2016 09:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a1Lp10a9RQA for ; Mon, 21 Nov 2016 09:51:16 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDE41295C6 for ; Mon, 21 Nov 2016 09:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1479750675; d=isode.com; s=june2016; i=@isode.com; bh=/C7tbFVUbzru+2ad53n4eyUpZYNIEZZDVmBbbXrBc4o=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=OLcltGEhtLWhMgrlPUbGXCPMwuCmGfiAArTajwqAz8jzZW3IHFSSWDb0ODCbWFI1417hbf tak+YnxRvJA1imWrk4874W8AHSKsx9s/Ow7VFHcxBw81SY8Shk6Rz0KPsWBMv7Vnm0gdYr i28MCbHBeTHUZ34NMTcHEEhVGbU/FpU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 21 Nov 2016 17:51:15 +0000 From: Alexey Melnikov To: Anton Tveretin References: <6492861479110589@web38j.yandex.ru> Message-ID: <538a7100-6cf8-80cd-0282-b4341af9170f@isode.com> Date: Mon, 21 Nov 2016 17:51:12 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <6492861479110589@web38j.yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] Request to form a new WG: JMAP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 17:51:17 -0000 Hi Anton, > On 14 Nov 2016, at 17:03, Anton Tveretin wrote: > > Hello, > Would this protocol be UNI only? I don't understand the question. Can you elaborate? > So, forwarding would be SMTP? In that case, there will be interworking. > Did anyone consider experience with GSM MMS? The message is submitted and retrieved with WAP (binary form of HTTP, to be simple), but inter-domain transmission is with SMTP. > Or, is the intent to have one more closed (private) system? The intent is still to use SMTP for message relaying. Best Regards, Alexey From nobody Mon Nov 21 09:55:12 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD19312965D for ; Mon, 21 Nov 2016 09:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFUJbnD2c0EG for ; Mon, 21 Nov 2016 09:55:10 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id DF36C129651 for ; Mon, 21 Nov 2016 09:55:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1479750909; d=isode.com; s=june2016; i=@isode.com; bh=wWIFJN1uv51/93Rs6x9cCb1enCt0VRPNZlGoZTAevfc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=rNrg3R2IQalR69kc5JN3bd9lKsCgwHe9W8tVznu27BMDORdvT7kHG16n/m8oBMdF5tgNSv DwrMJZOflZeNz1beWcpmYMAU7CLf3IR6HoNgdvYdkeLqUfZi1ZKArmYEGPxBzPEkipkQu1 4IoGDbfqylpewGIgJlZXR7VB/91I2ZQ=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 21 Nov 2016 17:55:09 +0000 To: dispatch@ietf.org References: <1478836665.322873.784300457.3FB705B7@webmail.messagingengine.com> <5a692534-72f4-8f67-b9c6-d3934922935c@isode.com> From: Alexey Melnikov Message-ID: Date: Mon, 21 Nov 2016 17:55:06 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <5a692534-72f4-8f67-b9c6-d3934922935c@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] Followup on proposed JMAP charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 17:55:11 -0000 There was some followup discussion about charter on imapext@ietf.org and ietf-smtp@ietf.org mailing lists. I created a new mailing list for JMAP and JMAP chartering discussion: jmap@ietf.org. Please subscribe to that mailing list, if you are interested in JMAP or proposed JMAP WG chartering. From nobody Fri Nov 25 07:50:03 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693F0129736 for ; Fri, 25 Nov 2016 07:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkAXXoOouKSw for ; Fri, 25 Nov 2016 07:49:58 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE04129623 for ; Fri, 25 Nov 2016 07:44:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1480088682; d=isode.com; s=june2016; i=@isode.com; bh=TcOBApyG4pVNy/oXwLCYmt6gdUYNk5mynBOR4IKgiyI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=LxvW48GvoR//8WQ0w8gh9wQ/5HYiA2gx0c14euOLuIUDzG5MgfBONIxorwrUKmFORo215K 0tz9QZA6r0WcAVFXME97neFORjQlGZi4IMNh+yOhaFQ+md96/aiIS1XJ0/dnh6npCKds8f Kc5aCj08SF1ayatqj0SuAi0AbeaKfIE=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 25 Nov 2016 15:44:42 +0000 To: Cullen Jennings References: <2a40ff7a-090f-848f-b35a-aa0944d26294@isode.com> <0CED4006-9029-47D7-8CB1-E0A62B723226@iii.ca> From: Alexey Melnikov Message-ID: Date: Fri, 25 Nov 2016 15:43:37 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <0CED4006-9029-47D7-8CB1-E0A62B723226@iii.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0ECF4CFAB0C0A5C1537B7A0A" Archived-At: Cc: Joe Hildebrand , DISPATCH Subject: Re: [dispatch] Proposed CBOR / CDDL WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 15:50:02 -0000 --------------0ECF4CFAB0C0A5C1537B7A0A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Cullen, On 24/10/2016 03:25, Cullen Jennings wrote: > >> On Oct 18, 2016, at 8:58 AM, Alexey Melnikov >> > wrote: >> >> >> In parallel to the work on CDDL, the WG will examine the >> Internet-Drafts draft-jroatch-cbor-tags and >> draft-bormann-cbor-tags-oid that >> use CBOR's extensibility mechanisms to provide additional data types >> as used in certain applications. Where these proposals are deemed >> useful and do not require significant new >> development, the CBOR WG might complete these specifications as well. > > Would it be possible to write this up in a way that said what the WG > would accomplish vs which drafts it would adopt ? > Ok, I suggest changing the above paragraph to read something like this: In parallel to the work on CDDL, the WG will examine the CBOR extension for tagging of Typed Arrays (based on draft-jroatch-cbor-tags) and the CBOR extension for tagging of Object Identifiers and UUIDs (based on draft-bormann-cbor-tags-oid) that use CBOR's extensibility mechanisms to provide additional data types as used in certain applications. Where these proposals are deemed useful and do not require significant new development, the CBOR WG will complete these specifications as well. Is this better? Best Regards, Alexey --------------0ECF4CFAB0C0A5C1537B7A0A Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

Hi Cullen,


On 24/10/2016 03:25, Cullen Jennings wrote:

On Oct 18, 2016, at 8:58 AM, Alexey Melnikov <alexey.me= lnikov@isode.com> wrote:


In parallel to the work on CDDL, the WG will examine the
Internet-Drafts draft-jroatch-cbor-tags and draft-bormann-cbor-tags-oid that
use CBOR's extensibility mechanisms to provide additional data types as used in certain applications. =A0Where these proposals are deemed useful and do not require significant new
development, the CBOR WG might complete these specifications as well.

Would it be possible to write this up in a way that said what the WG would accomplish vs which drafts it would adopt ?

Ok, I suggest changing the above paragraph to read something like this:

=A0 In parallel to the work on CDDL, the WG will examine the
=A0 CBOR extension for tagging of Typed Arrays (based on draft-jroatch-cbor-tags)
=A0 and the CBOR extension for tagging of Object Identifiers and UUIDs =A0 (based on draft-bormann-cbor-tags-oid) that use CBOR's extensibility
=A0 mechanisms to provide additional data types as used in certain applications.
=A0 Where these proposals are deemed useful and do not require significant new
=A0 development, the CBOR WG will complete these specifications as well.

Is this better?

Best Regards,
Alexey

--------------0ECF4CFAB0C0A5C1537B7A0A-- From nobody Mon Nov 28 08:54:50 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2785B129EA2 for ; Mon, 28 Nov 2016 08:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oM37Pk7BdEZz for ; Mon, 28 Nov 2016 08:54:47 -0800 (PST) Received: from smtp64.ord1c.emailsrvr.com (smtp64.ord1c.emailsrvr.com [108.166.43.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CEA129E9A for ; Mon, 28 Nov 2016 08:54:47 -0800 (PST) Received: from smtp1.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4C0422035F; Mon, 28 Nov 2016 11:54:47 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id EC52E20545; Mon, 28 Nov 2016 11:54:46 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.253] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 28 Nov 2016 11:54:47 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Cullen Jennings In-Reply-To: Date: Mon, 28 Nov 2016 09:54:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2a40ff7a-090f-848f-b35a-aa0944d26294@isode.com> <0CED4006-9029-47D7-8CB1-E0A62B723226@iii.ca> To: Alexey Melnikov X-Mailer: Apple Mail (2.3226) Archived-At: Cc: Joe Hildebrand , DISPATCH Subject: Re: [dispatch] Proposed CBOR / CDDL WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 16:54:49 -0000 > On Nov 25, 2016, at 8:43 AM, Alexey Melnikov = wrote: >=20 > Hi Cullen, >=20 > On 24/10/2016 03:25, Cullen Jennings wrote: >>=20 >>> On Oct 18, 2016, at 8:58 AM, Alexey Melnikov = wrote: >>>=20 >>>=20 >>> In parallel to the work on CDDL, the WG will examine the >>> Internet-Drafts draft-jroatch-cbor-tags and = draft-bormann-cbor-tags-oid that >>> use CBOR's extensibility mechanisms to provide additional data types = as used in certain applications. Where these proposals are deemed = useful and do not require significant new >>> development, the CBOR WG might complete these specifications as = well. >>=20 >> Would it be possible to write this up in a way that said what the WG = would accomplish vs which drafts it would adopt ? >>=20 > Ok, I suggest changing the above paragraph to read something like = this: >=20 > In parallel to the work on CDDL, the WG will examine the > CBOR extension for tagging of Typed Arrays (based on = draft-jroatch-cbor-tags) > and the CBOR extension for tagging of Object Identifiers and UUIDs > (based on draft-bormann-cbor-tags-oid) that use CBOR's extensibility > mechanisms to provide additional data types as used in certain = applications. > Where these proposals are deemed useful and do not require = significant new > development, the CBOR WG will complete these specifications as well. >=20 > Is this better? Looks good to me. Thanks From nobody Tue Nov 29 15:39:33 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFEA129CD1 for ; Tue, 29 Nov 2016 15:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDiksTiVHURS for ; Tue, 29 Nov 2016 15:39:30 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E71D1293DB for ; Tue, 29 Nov 2016 15:39:28 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id b126so210333396oia.2 for ; Tue, 29 Nov 2016 15:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CW4IFSDWQXagFiKWHRmYrvlsU9Esz3YDCwJ/Yc0jGAU=; b=BtqYw/iiFk3rzg4eOiScpYZxVZBFAFYDF+dwxM5CjlJGkOqTb95ceR1kZQ8y2oJF7z LkrV64G2jQrzLIDepdWaclCeiDGkCmUA8UP/6mmLGlK9UMqJo8LYT9rCVJH8TZltDPLt bshLfcPDaimuChS4t5+UuT8rV0oactHcwODZs+J0MmAT3x/nC7Ph7LEIj3f6LT+H/Km9 fr+KQb2GO2JtACwTwht87Vdbz1ccYOr0ezUD9fgCoONntaR32p8kRpCQF4So6n7cGclW LmXtTpraSMaoqhddurHNxC7VP+tyXMh29H0n7bnHnknCA2VfSOsaom+3YlFE99FMcE6D FKqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CW4IFSDWQXagFiKWHRmYrvlsU9Esz3YDCwJ/Yc0jGAU=; b=j5fh+OGc+Tu8scssNLwdRlQt72aIw3pdxUqhwxnoBNMZhvdrKCFz15mC21+z9OvMqF 7QTu//E0eWOqSoy3r397bRkIa1moq48J2YFrZX+AqBTVRPhTyd4RFF3UBilbn6c/FOym bJKiNBufn3sn61mzPYGd95FONKruylOldVm9wRaoJLlGM9yUVUsBqF/lnETXMjV8xS2y SNyrLCuu5imJIfz7O6wlWUv5fMEeSL0QAyP8Fr8SFX/ik/TPD3rZ/36Vdu2wrF+ibRK2 Q7bFxMkWmr5b3DIHsj9Cfs/fjMQAvXMOqw88xlTXmrbRMs5eAly3zWgl4tsuzpccV/E9 zFDQ== X-Gm-Message-State: AKaTC02ypNRBWh6W76LA/v/Azc6QlSmDDxilqAo9a3pX5omUHmxA6mkESLhoo7L8yBdzcZVLg2KWS7ClKPw/5Ts/ X-Received: by 10.157.51.83 with SMTP id u19mr18047502otd.96.1480462767864; Tue, 29 Nov 2016 15:39:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.17.106 with HTTP; Tue, 29 Nov 2016 15:39:25 -0800 (PST) In-Reply-To: <20160803212433.59799.qmail@ary.lan> References: <20160803212433.59799.qmail@ary.lan> From: Wei Chuang Date: Tue, 29 Nov 2016 15:39:25 -0800 Message-ID: To: John Levine Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113b17b8654f06054279199c" Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 23:39:32 -0000 --001a113b17b8654f06054279199c Content-Type: multipart/alternative; boundary=001a113b17b86213720542791945 --001a113b17b86213720542791945 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Wed, Aug 3, 2016 at 2:24 PM, John Levine wrote: > In article > you write: > > >> People at gmail said they're interested in this, so I can ask if > they've thought about it in the context of > >> a very large public mail system. > > > >Can we get some of those people directly involved in the conversation > here. Obviously I'd be very keen on > >doing something that ended up deployed at multiple major providers. > > Good thought. I'll try and loop them in. > > R's, > John > > > Apologies that this is late. While I don't speak for the large email/search provider that employees me, I'm interested in working with this draft. I would like to see draft-bhjl-x509-srv-02 dispatched. -Wei --001a113b17b86213720542791945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Wed, Aug 3, 2016 at 2:24 PM, John Levine <johnl@taugh.com> wrote:
In article <alpine.OSX.2.11.1607221253020.13624@dhcp-b1bb.meeting.ietf.org> you write:

>>  People at gmail said they're interested in this, so I can ask if they've thought about it in the context of
>> a very large public mail system.
>
>Can we get some of those people directly involved in the conversation here. Obviously I'd be very keen on
>doing something that ended up deployed at multiple major providers.

Good thought.  I'll try and loop them in.

R's,
John



Apologies that this is late.  While I don't speak for the large email/search provider that employees me, I'm interested in working with this draft.  I would like to see draft-bhjl-x509-srv-02 dispatched.

-Wei

--001a113b17b86213720542791945-- --001a113b17b8654f06054279199c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBp4Frl6pOfqKrgup/8g4BJ +1rmODNsLpvVnBx0knqDxDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjExMjkyMzM5MjhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEA4I0hk6AaqOYXBVq3F1+XWh4yD/5Ty8rtTQtThkpz Jo++q5AL+3SKxf2rbqantKrQAi7fv1F6DQ4gzi+wMup0caMNjgXHOj61Otv9/77QAJt4kYiwek1/ OJ3xca3DMUBBLf6QLQYcWbbghlBocz+C6pkjl6F1CWyNZXAqZYCHizU0u+cxRnow+Q3j0pPmrt3w vRHhNO9ModeZYWaPxnwidQQgD7ANBsBmvjXA501lqoeu8s9nqeS5dYZbNl8ZpHl11UZTfr/PFL1d T3JIV6yFT5fGuYxJgzH2mhIModI4mZ9P2pfFPAy892sV91TS0pIV4CzIBlWSng2GXAbMZgGcaQ== --001a113b17b8654f06054279199c-- From nobody Tue Nov 29 16:18:58 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C221129CE7 for ; Tue, 29 Nov 2016 16:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49qlBG1v9p5W for ; Tue, 29 Nov 2016 16:18:55 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DE1129509 for ; Tue, 29 Nov 2016 16:18:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 49A87BE6F; Wed, 30 Nov 2016 00:18:52 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4YRdeYyM8Tf; Wed, 30 Nov 2016 00:18:51 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 79249BE5B; Wed, 30 Nov 2016 00:18:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1480465130; bh=wukza0lLApDnkxbm2SaTPDzBxNIXgoaWXzrL3JAjOKg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=K3sQRXt2D+dyQMA43r0juqtiYtnzQOhnSAZYwCB1Ic/LmyCmZOSKIxfM/zB+i0htz 1LOMEuWq5Gkw/EwFGWtO1NAESPIo5kW1vJKT9/unpNdzwPV4faMDQ2RmCxoC5mEUBZ XbwRsmtUqnA2Gs0mfMHGnK9+Fvl/phi0wN8N5XLQ= To: John R Levine , Dispatch WG References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 30 Nov 2016 00:18:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030301040100020901070000" Archived-At: Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 00:18:57 -0000 This is a cryptographically signed message in MIME format. --------------ms030301040100020901070000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, There are two DANE WG documents (related to PGP [1] and smime [2]) that do similar things to this draft. As John I'm sure recalls, part of the extended discussion of those drafts revolved around the intended status for them. In the end we arrived at a (rough) consensus that [1,2] ought aim to be experimental RFCs. I think it'd be good if discussion of this draft considered possible relationships with [1,2] and e.g. whether or not they all ought aim for the same level of RFC if say one considered them all somehow part of what's really one experiment. Thanks, S. PS: I'm not expressing any opinion myself on this, other than asking that these relationships be considered. [1] https://tools.ietf.org/html/rfc7929 [2] https://tools.ietf.org/html/draft-ietf-dane-smime-13 --------------ms030301040100020901070000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMzAw MDE4NTBaMC8GCSqGSIb3DQEJBDEiBCBNmS5tbZ6RgMAks1e2wks/1J1wd69u1nPWUVpZm5Kz yTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBZMihSHOChsvmWmaOExFHPaus8i6H8lQvFpBGYtTsuyvFr8peQfPW3 mNCMn63jZL3AvMyHdV5TCl6qbaKYIY3ZeO6s5+H1jFl+rmnIakKxpZFaOo9VG5kJD2gmj4E6 HozWnkIMcpwPa9KjPnZeYT0rcY14PGAuPMdbmKc3IZelW0347MDFikHwTxL4Zkzr/RhBMlwy 9BjEzoowYVqZfLF4bQTH2HE4ML4gVLf9FuzNBYQ4hOgZkhd69UVRgtdaFNj5OkGGkJO+oqtR NMBZuEUc5kHVjjHOyz/JrBv77E0qna2xv57biBQm5EyY3CinkepNxUnQVgv46YU0pR0A75nF AAAAAAAA --------------ms030301040100020901070000-- From nobody Tue Nov 29 17:50:58 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB50B129D19 for ; Tue, 29 Nov 2016 17:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=DCIJ094B; dkim=pass (1536-bit key) header.d=taugh.com header.b=6ivNkbLj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGB1HtHS0HUd for ; Tue, 29 Nov 2016 17:50:54 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA54C129D1A for ; Tue, 29 Nov 2016 17:50:41 -0800 (PST) Received: (qmail 6679 invoked from network); 30 Nov 2016 01:50:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1a16.583e3074.k1611; bh=xF8QTO6DW8edOhxQkg3Aa6Wk8kt5xV1MkGthjXWt3NE=; b=DCIJ094BEJ5QMKpWgUtju0z0jmF8xy0exQZjKv4kNBfBbrdOeApS8LH6i1I7lZBuktbUzCmWnyqIp58ixDXvwqhYqR2E2C2vdFF+EPtwkseoSGLZg7RfB+Csios9dr/lgklB7E0X3KodYYjTE1ABb2SaF6bTaIIJO8Q75aUNeURjY5mRCovoGCmwRxn651OErfxmJB9V9iGIClNcgLEQdaAdh6s8lvFPbuHB744SoV6TDnSI3Zegr9c8u8n2iwzd DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1a16.583e3074.k1611; bh=xF8QTO6DW8edOhxQkg3Aa6Wk8kt5xV1MkGthjXWt3NE=; b=6ivNkbLjiYMKyUT11RmUpjUt4l9X/UTW6ZsGLZIaYBKMnKj6IvVkY9OwuBTzKP3RHAaV705myESZMPOqpcMzH1Cu0s69Fjenff/Y0HrSawaFFm1IzMGwxXShMQHDPwPVVcw7884zB7QbfSRQG/7jIFTPWmQa+div9r2Q+R72iBiFMEdFh+Z+J6pLewfBJHxhicwEUlB1Lq2WO4pHS30jDq/DpWWwtqUecOzzvEU/CwWchWTkfJvSJK+TSlcb4jGN Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 30 Nov 2016 01:50:44 -0000 Date: 29 Nov 2016 20:50:39 -0500 Message-ID: From: "John R Levine" To: "Stephen Farrell" In-Reply-To: References: User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Dispatch WG Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 01:50:57 -0000 > I think it'd be good if discussion of this draft considered > possible relationships with [1,2] and e.g. whether or not > they all ought aim for the same level of RFC if say one > considered them all somehow part of what's really one > experiment. I don't see why. The two DANE drafts are experimental because there are multiple serious technical risks in what they propose. Brian and I wrote this draft to be as simple as we could make it, and to invent as little as we could. While it's certainly possible that people will decide not to use it, if they do use it, there's no question that it'd work and it'd scale because it's built on top of SRV records and http which we know scale just fine. So please leave it as proposed standard. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Nov 29 22:56:56 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715791295AF for ; Tue, 29 Nov 2016 22:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andreasschulze.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahMeRFvAjEIO for ; Tue, 29 Nov 2016 22:56:47 -0800 (PST) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:a60:f0b4:e503:2cdb:beff:feaa:880b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC842129451 for ; Tue, 29 Nov 2016 22:56:32 -0800 (PST) Received: from andreasschulze.de (andreasschulze.de [IPv6:2001:a60:f0b4:e503:d86e:8dce:a73e:2fec]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sca@andreasschulze.de) by mail.somaf.de (Postfix) with ESMTPSA id 3tTB646flszDvQ for ; Wed, 30 Nov 2016 07:56:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=ybz; t=1480488989; bh=VcpjruXN06SOlOh9hp13vzm0Kvq+XiMTSzzavuz/vVw=; h=Date:From:To:Subject:References:In-Reply-To; b=eysIsxh77W/kQBXEl+dJ5G4bmA7ZqSbIxKuHN9XO8SmDQyfpMm7xduXfepWvTmo0G kcC7AIaEemVHIixbE+bBC0X4xsZZAUPvV4a25K4mPEabiO7PBiLMC3rtROvmoQY8kw YJy+5dJxazAJGxED3PNXxSkbIPfG9ylo+uaiGIzZrSI7/fzCzl14+dJE21E7jqZTGT GbX7ACNiNjrYP/XWdE16MQSrZmmcS66FPfB8VPsmV5NwdHh/ZDgJQP0fcyacwDchx7 5hSHKHTPcsTgrtVtVOKdsqkxKEw9xMcQaFOFBPPrgrSIKXVZu1XNtFH6UFSZZTqpx6 1lhw28+0PNQMQ== Received: from prx18.datevnet.de (prx18.datevnet.de [2a00:e50:f155:b:59aa:d137:8293:9f91]) by andreasschulze.de (Horde Framework) with HTTPS; Wed, 30 Nov 2016 07:56:27 +0100 Date: Wed, 30 Nov 2016 07:56:27 +0100 Message-ID: <20161130075627.Horde.g0-okJX4KW-RFKiecKkF_7e@andreasschulze.de> From: "A. Schulze" To: dispatch@ietf.org References: <20160803212433.59799.qmail@ary.lan> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 06:56:51 -0000 Wei Chuang: > I would like to see draft-bhjl-x509-srv-02 dispatched. I also support that draft. Andreas From nobody Wed Nov 30 19:46:20 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2159F129441 for ; Wed, 30 Nov 2016 19:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=rolandturner.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmHBm3MsCd7X for ; Wed, 30 Nov 2016 19:46:17 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC91129428 for ; Wed, 30 Nov 2016 19:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=0.rolandturner.com; h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=wLlRT6/tog9ZwAOspFGXj6DAzMbUNqmjC6w20GQiFPI=; b=B2Jhe6+iAluT+t/ZeX2oRCXaG8NIsK8pfHon+Hrb8mfC0zLA6Q7KWwNX3T5RMr7SLE+JdDIzMwAL67weObrFi9CZ/CqB9tzBAEWDfEKjzNFu/Pf0ADAQQxSQ9yt9HxUJJpFCTLAfIlMF1xoPXxl7BxfFi6fDfRS8quGpKuPhDow=; Received: from [116.12.149.133] (port=59168 helo=[10.100.1.141]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1cCIK7-00083K-Nb for dispatch@ietf.org; Thu, 01 Dec 2016 03:46:15 +0000 To: dispatch@ietf.org From: Roland Turner Message-ID: <724a13e5-e422-b55c-2b36-ba3e63620e48@rolandturner.com> Date: Thu, 1 Dec 2016 11:46:15 +0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A3CDEF25135CFC817E3E6ED0" Archived-At: Subject: [dispatch] draft-levine-herkula-oneclick, additional security consideration X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 03:46:19 -0000 This is a multi-part message in MIME format. --------------A3CDEF25135CFC817E3E6ED0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit The Security Considerations section mentions potential use of the mechanism to test whether an email address is valid, but does not address the probing of spam filters. This may well be a moot point given the widespread use of seed boxes by both legitimate senders and spammers, however I recall that when Gmail first introduced an unsubscribe button (in the dialogue box that could pop up if the user clicked This is Spam), they established three criteria: * that a List-Unsubscribe: header was present * that the message authenticated, and * that the sender was in good standing in terms of its complaint rate. It may be argued, with some strength, that the third item really makes no difference, but it would appear to be a relevant consideration to address in Security Considerations, and perhaps an option to suggest. - Roland --------------A3CDEF25135CFC817E3E6ED0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit The Security Considerations section mentions potential use of the mechanism to test whether an email address is valid, but does not address the probing of spam filters. This may well be a moot point given the widespread use of seed boxes by both legitimate senders and spammers, however I recall that when Gmail first introduced an unsubscribe button (in the dialogue box that could pop up if the user clicked This is Spam), they established three criteria:
  • that a List-Unsubscribe: header was present
  • that the message authenticated, and
  • that the sender was in good standing in terms of its complaint rate.

It may be argued, with some strength, that the third item really makes no difference, but it would appear to be a relevant consideration to address in Security Considerations, and perhaps an option to suggest.

- Roland


--------------A3CDEF25135CFC817E3E6ED0--