From nobody Sat Apr 13 06:41:11 2019 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C311C120013 for ; Sat, 13 Apr 2019 06:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mi7rmsxSMq8X for ; Sat, 13 Apr 2019 06:41:07 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) (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 79049120189 for ; Sat, 13 Apr 2019 06:41:06 -0700 (PDT) Received: from [192.168.56.1] ([77.21.39.17]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MsJXG-1h0FpK0tOU-00tnYY for ; Sat, 13 Apr 2019 15:41:04 +0200 From: "Dirk Kutscher" To: din@irtf.org Date: Sat, 13 Apr 2019 15:41:02 +0200 X-Mailer: MailMate (1.12.4r5594) Message-ID: <29D5FAF3-877F-4124-9EE6-564DBA77A9D0@dkutscher.net> References: <7fe7b482-62c6-f998-e3de-034b0d7bcd90@iab.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_3656300C-36C3-4979-A897-12EB9E6944C7_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[2260, 17156], "plain":[264, 4598], "uuid":"36E84334-6C89-4497-836A-CE71BE92866C"}] X-Provags-ID: V03:K1:/rmXjDQaloK+Db4CTtlUUlkYkiN0Kzh5qN+qX0UULqjAuFWf7AD PgLYhkMuc9Mlw9OQXUvptUXBl4irxgn5kCqnEOcBVGvhPnAhenngv6cF6AC/aOmcAmRY8rP FwfAMfozw/Ukrr8841m0qcwzAa+5RyT5ovniOJb3DAqilUD83Skmv+4DhWGxkDiHLSTXjHR OjD2lLRIft0DI1nkh8mLg== X-UI-Out-Filterresults: notjunk:1;V03:K0:NvEKe6RXK0g=:ecZvnrrnQA5O1yMbiEw9Ie ruvcqblVcZLOrgP1N//7qoG2XVG9pOdIr3IBv8ssKeo3VW2m2dE8XyrFc/VmAo1AknhN7XtBK cEFrL0l2HOcDaAdU1XlKfbcuy684/s+bUrKickTD8QuTqCTSIhCJ5BZS8ayoxmuoVrvZrXtIs CFZfA7kfhUVAmpUAag25a0ALRLcgd6tD5lFmQgpZ7xE5FbggSgSoH9nZVxgn23zePVcn86pqO u3TcH5P0wOsie8fDhrJj2fK5Hi68zq70/W8m5fRzN81O/ytfLmuyu2XK/EK7Fl2Y0mHXcia0W Jqiy8Mu/0p6DuflQ/+tYEDveAsPVhA5lTpaRT9mjZjKhw2d367Ltyi1U2QV6chQyzrhE/PRw6 M6ePOHBxn/vT+t+JyeeyLw5VYIBVJWbHTKLaMyCR9bbz/+uJU8FYWkqDgBDvqcGr2N+Y/IUHT 0GHTB6lvF6BQPQu2Ed6Q9TBe6h9eSBQ9aBOGURrVNDyqSooGrtVIuy+VSoXIQs/S252k5u4pm hJ044UlwydsP+0urqeXLMdi+XSDGw47bq7A1oxfy30b4rRVkw19Ss2jweXxq3hG6dO8PLb8W4 PDw08oAdk1W5Q7KMG/cVm0IPAEHKSLNGsE3EC4DdO4SXE1yKHhXINCUoAbFZk/yPMT2CD2wz+ NLlGp/72zvb3Vdcr/ugZiHhHlGZzIQHM2S1nG5UgwqzgjXV2/5QpXAX/RlqjRiU0lAeztJxpM NDOMDyQr7aQjNDrWQ6sGhOE+08wPGowiOHDDzsYM3/0NAdcKlbgK3dPZC54= Archived-At: Subject: [Din] Fwd: IAB Workshop Call for Papers: Design Expectations vs. Deployment Reality X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 13:41:10 -0000 --=_MailMate_3656300C-36C3-4979-A897-12EB9E6944C7_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit FYI, DINRG. Dirk Forwarded message: > From: IAB Chair > To: ietf@ietf.org, ietf-announce@ietf.org, execd@iab.org > Subject: IAB Workshop Call for Papers: Design Expectations vs. > Deployment Reality > Date: Fri, 12 Apr 2019 11:28:40 -0700 > > Design Expectations vs. Deployment Reality in Protocol Development > > > A number of protocols have presumed specific deployment models during > the development or early elaboration of the protocol.  Actual > deployments have sometimes run contrary to these early expectations > when economies of scale, DDoS resilience, market consolidation, or > other factors have come into play. These factors can result in the > deployed reality being highly concentrated. > > > This is a serious issue for the Internet, as concentrated, centralized > deployment models present risks to user choice, privacy, and future > protocol evolution. > > > On occasion, the differences to expectations were almost immediate, > but they also occur after a significant time has passed from the > protocol’s initial development. > > > Examples include: > > > Email standards, which presumed many providers running in a largely > uncoordinated fashion, but which has seen both significant market > consolidation and a need for coordination to defend against spam and > other attacks. The coordination and centralized defense mechanisms > scale better for large entities, which has fueled additional > consolidation. > > > The DNS, which presumed deep hierarchies but has often been deployed > in large, flat zones, leading to the nameservers for those zones > becoming critical infrastructure. Future developments in DNS may see > concentration through the use of globally available common resolver > services, which evolve rapidly and can offer better security. > Paradoxically, concentration of these queries into few services > creates new security and privacy concerns. > > > The Web, which is built on a fundamentally decentralized design, but > which is now often delivered with the aid of Content Delivery > Networks.  Their services provide scaling, distribution, and Denial > of Service prevention in ways that new entrants and smaller systems > operators would find difficult to replicate.  While truly small > services and truly large ones may operate using only their own > infrastructure, many others are left with the only practical choice > being the use of a globally available commercial service. > > > Similar developments may happen with future technologies and services. > For instance, the growing use of Machine Learning technology presents > challenges for distributing effective implementation of a service > throughout a pool of many different providers. > > > In RFC 5218 the IAB tackled what > made for a successful protocol.  In RFC 8170 > , the IAB described how to handle > protocol transitions.  This workshop will explore cases where the > initial system design assumptions turned out to be wrong, looking for > patterns in what caused those assumptions to fail (e.g., concentration > due to DDoS resilience) and in how those failures impact the security, > privacy, and manageability of the resulting deployments. > > > While the eventual goals might include proposing common remediations > for specific cases of confounded protocol expectations, the IAB is > currently inviting papers which: > > > * > > Describe specific cases where systems assumptions during protocol > development were confounded by later deployment conditions. > > * > > Survey a set of cases to identify common factors in these > confounded > expectations. > > * > > Explore remediations which foster user privacy, security and > provider diversity in the face of these changes. > > > Important Dates > > > The workshop will be held June 4-5 in Helsinki, Finland. > > > Position papers must be submitted by May 3rd at the latest. The > program committee will review submitted position papers and send an > invitation to the workshop to one of the paper authors. Invitations > will be distributed by May 9 at the latest. > > > Position Paper Requirements > > > Interested parties must submit a brief document of one to four pages, > formatted as HTML, PDF, or plain text. We welcome papers that describe > existing work, answers to the questions listed above, new questions, > write-ups of deployment experience, lessons-learned from successful or > failed attempts, and ideally a vision towards taking deployment > considerations better in account when designing new Internet > technology. Re-submissions from work presented elsewhere are allowed. > > > Program Committee > > > The following persons are IAB contacts for this workshop: > > > Jari Arkko > > Stephen Farrell > > Ted Hardie > > Christian Huitema > > Melinda Shore > > Brian Trammell > > > Position papers should be sent by email to dedr-pc@iab.org. --=_MailMate_3656300C-36C3-4979-A897-12EB9E6944C7_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

FYI, DINRG.

Dirk

Forwarded message:

From: IAB Chair <iab-ch= air@iab.org>
To: ietf@ietf.org, ietf-announce@ietf.org, execd@iab.org
Subject: IAB Workshop Call for Papers: Design Expectations vs. Deployment= Reality
Date: Fri, 12 Apr 2019 11:28:40 -0700

Design Expectations vs. Deployment Reality in Proto= col Development


A number of protocols have presumed specific deployment models during= the development or early elaboration of the protocol. =C2=A0Actual deplo= yments have sometimes run contrary to these early expectations when econo= mies of scale, DDoS resilience, market consolidation, or other factors ha= ve come into play. These factors can result in the deployed reality being= highly concentrated.


This is a serious issue for the Internet, as concentrated, centralize= d deployment models present risks to user choice, privacy, and future pro= tocol evolution.


On occasion, the differences to expectations were almost immediate, b= ut they also occur after a significant time has passed from the protocol=E2= =80=99s initial development.


Examples include:


Email standards, which presumed many providers running in a largely u= ncoordinated fashion, but which has seen both significant market consolid= ation and a need for coordination to defend against spam and other attack= s. The coordination and centralized defense mechanisms scale better for l= arge entities, which has fueled additional consolidation.


The DNS, which presumed deep hierarchies but has often been deployed = in large, flat zones, leading to the nameservers for those zones becoming= critical infrastructure. Future developments in DNS may see concentratio= n through the use of globally available common resolver services, which e= volve rapidly and can offer better security. Paradoxically, concentration= of these queries into few services creates new security and privacy conc= erns.


The Web, which is built on a fundamentally decentralized design, but = which is now often delivered with the aid of Content Delivery Networks. =C2= =A0Their services provide scaling, distribution, and Denial of Service pr= evention in ways that new entrants and smaller systems operators would fi= nd difficult to replicate. =C2=A0While truly small services and truly lar= ge ones may operate using only their own infrastructure, many others are = left with the only practical choice being the use of a globally available= commercial service.


Similar developments may happen with future technologies and services= =2E For instance, the growing use of Machine Learning technology presents= challenges for distributing effective implementation of a service throug= hout a pool of many different providers.


In RFC 5218 the IAB tackled what made for a successful protocol. =C2=A0In <= a href=3D"https://tools.ietf.org/html/rfc8170" style=3D"text-decoration:none;">RFC 8170, the IAB described how to handle protocol transitions. =C2=A0This work= shop will explore cases where the initial system design assumptions turne= d out to be wrong, looking for patterns in what caused those assumptions = to fail (e.g., concentration due to DDoS resilience) and in how those fai= lures impact the security, privacy, and manageability of the resulting de= ployments.


While the eventual goals might include proposing common remediations = for specific cases of confounded protocol expectations, the IAB is curren= tly inviting papers which:


  • Describe specific cases where syst= ems assumptions during protocol development were confounded by later depl= oyment conditions.

  • Survey a set of cases to identify = common factors in these confounded expectations.

  • Explore remediations which foster = user privacy, security and provider diversity in the face of these change= s.


Important Dates


The workshop will be held June 4-5 in Helsinki, Finland.


Position papers must be submitted by May 3rd at the latest. The progr= am committee will review submitted position papers and send an invitation= to the workshop to one of the paper authors. Invitations will be distrib= uted by May 9 at the latest.


Position Paper Requirements


Interested parties must submit a brief document of one to four pages,= formatted as HTML, PDF, or plain text. We welcome papers that describe e= xisting work, answers to the questions listed above, new questions, write= -ups of deployment experience, lessons-learned from successful or failed = attempts, and ideally a vision towards taking deployment considerations b= etter in account when designing new Internet technology. Re-submissions f= rom work presented elsewhere are allowed.


Program Committee


The following persons are IAB contacts for this workshop:


=C2=A0=C2=A0=C2=A0 Jari Arkko

=C2=A0=C2=A0=C2=A0 Stephen Farrell

=C2=A0=C2=A0=C2=A0 Ted Hardie

=C2=A0=C2=A0=C2=A0 Christian Huitema

=C2=A0=C2=A0=C2=A0 Melinda Shore

=C2=A0=C2=A0=C2=A0 Brian Trammell


Position papers should be sent by email to dedr-pc@iab.org.

--=_MailMate_3656300C-36C3-4979-A897-12EB9E6944C7_=-- From nobody Wed Apr 17 21:00:24 2019 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FFF120020 for ; Wed, 17 Apr 2019 21:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_GREY=0.424, URIBL_RHS_DOB=1.514] 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 glUR9iGm9Qvy for ; Wed, 17 Apr 2019 21:00:15 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 B815C1200FB for ; Wed, 17 Apr 2019 21:00:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,364,1549926000"; d="scan'208,217";a="379122426" Received: from static-138-207-175-245.mdde.cpe.atlanticbb.net (HELO [10.11.6.97]) ([138.207.175.245]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 18 Apr 2019 05:59:53 +0200 From: =?UTF-8?B?SsOpcsO0bWUgRnJhbsOnb2lz?= To: din@irtf.org Message-ID: <654ea261-375b-c74a-7857-7b617fb5c0e2@inria.fr> Date: Thu, 18 Apr 2019 05:58:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------8A520D80956B631366249ABB" Content-Language: fr Archived-At: Subject: [Din] [Ifip-tc11] Register by April 19 at special rates for the 1st IEEE International Conference on Blockchain and Cryptocurrency (ICBC 2019)! X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 04:00:18 -0000 This is a multi-part message in MIME format. --------------8A520D80956B631366249ABB Content-Type: multipart/alternative; boundary="------------52721C37DDAF826C6761DE0B" --------------52721C37DDAF826C6761DE0B Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit http://icbc2019.ieee-icbc.org/ 2019 IEEE International Conference on Blockchain and Cryptocurrency (ICBC 2019) will be held in beautiful and vibrant Seoul, Korea on May 14-17, 2019. ICBC 2019 is the first IEEE Communications Society (ComSoc) sponsored conference on Blockchain and Cryptocurrency. It will feature keynotes, tutorials, technical paper presentations, posters, demos, exhibitions from world-leading service providers, solution vendors, research institutes, open source projects, and academia. ICBC 2019 will be the primary forum for technical exchange of the latest research and innovation, regulations, policies, standards, and applications in this exciting and challenging area. Special rates are available until April 19, 2019.**Register today **to learn from the experts at ICBC 2019! http://icbc2019.ieee-icbc.org/program/keynotes/ Program http://icbc2019.ieee-icbc.org/program/ *Tutorials* 1. Blockchain and Smart Contracts – From Theory to Practice 2. Enterprise Blockchain Solutions for Financial Services: Techniques and Challenges 3. Lightning network: off­-chain transactions and the future of decentralised value transfer 4. Interledger: theory and practice 5. Blockchain for Cyberphysical Systems: Applications, Opportunities and Challenges. Register Now *http://icbc2019.ieee-icbc.org/registration/ * *IMPORTANT DATES* Advance Registration Due Date: April 19, 2019 Conference Dates: May 14-17, 2019 *GENERAL CHAIR* James Won-Ki Hong, POSTECH, Korea *TPC CO-CHAIRS * Raouf Boutaba, University of Waterloo, Canada Burkhard Stiller, University of Zurich, Switzerland Hongtaek Ju, KMU, Korea --------------52721C37DDAF826C6761DE0B Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

2019 IEEE International Conference on Blockchain and Cryptocurrency (ICBC 2019) will be held in beautiful and vibrant Seoul, Korea on May 14-17, 2019. ICBC 2019 is the first IEEE Communications Society (ComSoc) sponsored conference on Blockchain and Cryptocurrency. It will feature keynotes, tutorials, technical paper presentations, posters, demos, exhibitions from world-leading service providers, solution vendors, research institutes, open source projects, and academia. ICBC 2019 will be the primary forum for technical exchange of the latest research and innovation, regulations, policies, standards, and applications in this exciting and challenging area. Special rates are available until April 19, 2019. Register today to learn from the experts at ICBC 2019!
Program
Tutorials      
1. Blockchain and Smart Contracts – From Theory to Practice
2. Enterprise Blockchain Solutions for Financial Services: Techniques and Challenges
3. Lightning network: off­-chain transactions and the future of decentralised value transfer
4. Interledger: theory and practice
5. Blockchain for Cyberphysical Systems: Applications, Opportunities and Challenges.
Register Now
IMPORTANT DATES
Advance Registration Due Date: April 19, 2019
Conference Dates: May 14-17, 2019
GENERAL CHAIR
James Won-Ki Hong, POSTECH, Korea
 
TPC CO-CHAIRS
Raouf Boutaba, University of Waterloo, Canada
Burkhard Stiller, University of Zurich, Switzerland
Hongtaek Ju, KMU, Korea


--------------52721C37DDAF826C6761DE0B-- --------------8A520D80956B631366249ABB Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSWZpcC10 YzExIG1haWxpbmcgbGlzdApJZmlwLXRjMTFAZGxpc3Quc2VydmVyLnVuaS1mcmFua2Z1cnQu ZGUKaHR0cHM6Ly9kbGlzdC5zZXJ2ZXIudW5pLWZyYW5rZnVydC5kZS9tYWlsbWFuL2xpc3Rp bmZvL2lmaXAtdGMxMQo= --------------8A520D80956B631366249ABB--