- address-policy-wg - mailman.ripe.net

Call for Papers: The 2018 ACM Conference on Embedded Networked Sensor Systems (SenSys 2018)
by Shijia Pan 08 Mar '18

08 Mar '18

[Apologies if you got multiple copies of this email.] =================================================================== Call for Papers: The 2018 ACM Conference on Embedded Networked Sensor Systems (SenSys 2018) **** ACM SenSys 2018 **** Shenzhen, China November 4-7, 2018 http://sensys.acm.org/2018/ Dear Colleagues, The ACM Conference on Embedded Networked Sensor Systems (SenSys 2018) is the premier computer systems conference focused on the architecture, design, implementation, and performance of networked sensing systems, sensor-oriented data modeling, and analytics, in addition to sensor-enabled applications. ACM SenSys brings together academic, industry, and government professionals to a single-track, highly selective forum, that takes a broad view on the areas of computing that are relevant to the future of sensor systems. Topics of interests include, but are not limited to, the following: - New platforms and hardware designs for networked sensor systems - Systems software, including operating systems and network stacks - Low power operation, energy harvesting, and energy management - Applications, and deployment experiences (such as smart cities, wellness and healthcare sensing, and industrial process monitoring) - Resource-efficient machine learning for embedded and mobile platforms - Wireless media access control, network, and transport-layer protocol designs - New communication paradigms for ubiquitous connectivity - Innovations in learning algorithms and models for sensor perception and understanding - Mobile and pervasive systems, including personal wearable devices, drones, and robots - Sensing, actuation, and control - System services such as time and location estimation - Data management and analytics, including quality, integrity, and trustworthiness - Learning, adaptation, and autonomy in cyber-physical systems - Heterogeneous collaborative sensing, including human-robot sensor systems - Fault-tolerance, reliability, and verification - Security and privacy in sensor-enabled applications and systems We invite technical papers describing original ideas, ground-breaking results, and real-world experiences involving innovative sensor systems. Successful submissions will explain why the topic is relevant to a vision of the future of sensing systems. Submissions will be judged on originality, significance, clarity, relevance, and correctness. In addition to citing relevant, published work, authors must cite and relate their submissions to relevant prior publications of their own. Ethical approval for experiments with human subjects should be demonstrated as part of the submission. **** Important Dates **** - Paper Registration and Abstract: April 1, 2018, 11:59 PM GMT. - Paper Submission Deadline: April 8, 2018, 11:59 PM GMT. - Notification of Paper Acceptance: July 20, 2018, 11:59 PM GMT. - Paper Acceptance Notification: 20th July 2018 GMT. - Camera-Ready Deadline: 20th Sept 2018 GMT. Note: These are hard deadlines. No extension will be granted. For detailed information about the program and submission guideline, please visit http://sensys.acm.org/2018/. **************************************** General Chairs: Lin Zhang (Tsinghua-Berkeley Shenzhen Institute), Pei Zhang (Carnegie Mellon University) Program Chairs: Tian He (University of Minnesota), Nic Lane (University of Oxford) ****************************************

1 0

Call for Papers: The 2018 ACM Conference on Embedded Networked Sensor Systems (SenSys 2018)
by Shijia Pan 22 Feb '18

22 Feb '18

[Apologies if you got multiple copies of this email.] =================================================================== Call for Papers: The 2018 ACM Conference on Embedded Networked Sensor Systems (SenSys 2018) **** ACM SenSys 2018 **** Shenzhen, China November 4-7, 2018 http://sensys.acm.org/2018/ Dear Colleagues, The ACM Conference on Embedded Networked Sensor Systems (SenSys 2018) is the premier computer systems conference focused on the architecture, design, implementation, and performance of networked sensing systems, sensor-oriented data modeling, and analytics, in addition to sensor-enabled applications. ACM SenSys brings together academic, industry, and government professionals to a single-track, highly selective forum, that takes a broad view on the areas of computing that are relevant to the future of sensor systems. Topics of interests include, but are not limited to, the following: - New platforms and hardware designs for networked sensor systems - Systems software, including operating systems and network stacks - Low power operation, energy harvesting, and energy management - Applications, and deployment experiences (such as smart cities, wellness and healthcare sensing, and industrial process monitoring) - Resource-efficient machine learning for embedded and mobile platforms - Wireless media access control, network, and transport-layer protocol designs - New communication paradigms for ubiquitous connectivity - Innovations in learning algorithms and models for sensor perception and understanding - Mobile and pervasive systems, including personal wearable devices, drones, and robots - Sensing, actuation, and control - System services such as time and location estimation - Data management and analytics, including quality, integrity, and trustworthiness - Learning, adaptation, and autonomy in cyber-physical systems - Heterogeneous collaborative sensing, including human-robot sensor systems - Fault-tolerance, reliability, and verification - Security and privacy in sensor-enabled applications and systems We invite technical papers describing original ideas, ground-breaking results, and real-world experiences involving innovative sensor systems. Successful submissions will explain why the topic is relevant to a vision of the future of sensing systems. Submissions will be judged on originality, significance, clarity, relevance, and correctness. In addition to citing relevant, published work, authors must cite and relate their submissions to relevant prior publications of their own. Ethical approval for experiments with human subjects should be demonstrated as part of the submission. **** Important Dates **** - Paper Registration and Abstract: April 1, 2018, 11:59 PM GMT. - Paper Submission Deadline: April 8, 2018, 11:59 PM GMT. - Notification of Paper Acceptance: July 20, 2018, 11:59 PM GMT. - Paper Acceptance Notification: 20th July 2018 GMT. - Camera-Ready Deadline: 20th Sept 2018 GMT. Note: These are hard deadlines. No extension will be granted. For detailed information about the program and submission guideline, please visit http://sensys.acm.org/2018/. **************************************** General Chairs: Lin Zhang (Tsinghua-Berkeley Shenzhen Institute), Pei Zhang (Carnegie Mellon University) Program Chairs: Tian He (University of Minnesota), Nic Lane (University of Oxford) ****************************************

1 0

[CFP] 2nd Asia-Pacific Workshop on Networking (APNet 2018)
by ap net 22 Feb '18

22 Feb '18

************************************************************ ****************** CALL FOR PAPERS APNet 2018 The Second Asia-Pacific Workshop on Networking Beijing, China, August 2--3, 2018 *https://conferences.sigcomm.org/events/apnet2018/index.html <https://conferences.sigcomm.org/events/apnet2018/index.html>* ************************************************************ ****************** *Overview* The Second Asia-Pacific Workshop on Networking (APNet’18) aims to bring together the very best researchers in computer networking and systems across the Asia-Pacific region and the global community to a live forum discussing and debating innovative ideas at their early stages. The mission of APNet is that promising but not-yet-mature ideas can receive timely feedback from experienced researchers, shaping them into major conferences such as SIGCOMM, NSDI, SOSP, OSDI, MobiCom, CoNEXT and so on. *Program Committee* *General Chairs* Dan Li (Tsinghua University, China) K. K. Ramakrishnan (University of California, Riverside, USA) *PC Co-Chairs* Mosharaf Chowdhury (University of Michigan, USA) Kun Tan (Huawei, China) *Steering Committee* Suman Banerjee (University of Wisconsin, USA) Kai Chen (HKUST, Hong Kong SAR), Co-Chair Albert Greenberg (Microsoft, USA) Jitu Padhye (Microsoft, USA) KyoungSoo Park (KAIST, South Korea) Kun Tan (Huawei, China), Co-Chair Minlan Yu (Yale University, USA) Lin Zhong (Rice University, USA) ********************************************************** We invite submissions of short papers (up to 6 pages, including references) on a wide range of networking research, including, but not limited to: • Network architectures and algorithms • Cloud and wide-area networking systems & infrastructure • Networking support for applications • Operating system support for networking • Kernel-bypass and RDMA networking and applications • Enterprise, datacenter, and storage area networks • SDN, NFV, and network programming • Networking hardware design • Network measurement, monitoring, diagnosis, and operations • Formal methods and network verification • Network security and privacy, censorship, transparency • Network, transport, and application-layer protocols • Resource management, QoS, and signaling • Routing, traffic engineering, switching, and addressing • Wireless, mobile, and sensor networking The APNet Program Committee will select papers based on novelty, significance, and technical merit, rather than completeness. Innovative well-reasoned ideas with preliminary evaluations will suffice for APNet. Accepted papers will be published in the ACM Digital Library. We hope that the extension of APNet papers, when substantiated by solid implementation and experimentation, can be published at the aforementioned premier conferences. *Important Dates* Abstract registration: April 6, 2018 (11:59 GMT) Paper submission: April 13, 2018 (11:59 PM GMT) Notification of decision: June 11, 2018 Camera-ready date: June 25, 2018 ================================================ We apologize if you receive multiple copies of this CFPs. We appreciate your help to forward this CFPs to your friends & email lists. ================================================ __________________ *Publicity Co-Chair* Chen Qian Assistant Professor Department of Computer Engineering Jack Baskin School of Engineering University of California Santa Cruz

2 1

New on RIPE Labs: RIPE NCC Members and Resources in 2017
by Mirjam Kuehne 02 Feb '18

02 Feb '18

Dear colleagues, In this new article on RIPE Labs we're looking at membership developments over the previous year. How many new LIRs opened, and is this consistent with our earlier projections? How much longer will IPv4 last? And what about IPv6 uptake? https://labs.ripe.net/Members/wilhelm/ripe-ncc-members-and-resources-in-2017 Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: A Shrinking Pie? The IPv4 Transfer Market in 2017
by Mirjam Kuehne 30 Jan '18

30 Jan '18

Dear colleagues, A record number of IPv4 addresses were transferred between LIRs in the RIPE NCC service region in 2017. However, 16 of the largest transfers, amounting to 78% of the total transferred address space, were really about the administrative management of resources between related business units. In terms of buyers and sellers, this part of the IPv4 transfer market decreased in size last year. Please find a more detailed analysis on RIPE Labs: https://labs.ripe.net/Members/wilhelm/a-shrinking-pie-the-ipv4-transfer-mar… Kind regards, Mirjam Kühne RIPE NCC

1 0

2016-04 Review Phase (IPv6 Sub-assignment Clarification)
by Marco Schmidt 22 Jan '18

22 Jan '18

Dear colleagues, Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the Review Phase. The goal of this proposal is to re-define the term "sub-assignment" for IPv6. This proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - the scope is extended to all IPv6 assignments - it defines that the provision of separate IPv6 addresses is not considered a sub-assignment The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2016-04 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2016-04/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to <address-policy-wg(a)ripe.net> before 17 November 2017. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

24 103

inconsistency in 2016-04
by JORDI PALET MARTINEZ 19 Jan '18

19 Jan '18

(sorry Jim ! subject replaced) Hi Sander, Below in-line. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces(a)ripe.net> en nombre de Sander Steffann <sander(a)steffann.nl> Fecha: viernes, 19 de enero de 2018, 12:13 Para: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> CC: <address-policy-wg(a)ripe.net> Asunto: Re: [address-policy-wg] what does consensus mean Hi, > 1) Temporary always ? clearly not for point-to-point links, no-sense for data centers? Indeed, this is what I asked Marco. > 2) Single address (/128) for a single device (so the device can't use privacy? Utopia!), or do we allow if the devices get a single-prefix, it uses multiple addresses out of that prefix (so we allow VMs in the device also) The policy talks about single-address increments. It doesn't say "one address", it says "separate addresses" (plural), which allows for privacy extensions etc. Right, but 6) IA say: "... There are cases where a /64 is needed per customer to provide a separate address ..." and 8) IA say: "... by using single IPv6 addresses for End User devices and services ..." furthermore it say "... provided no prefixes will be provided to other entities ..." I think this can be sorted out replacing in the IA "provided no more than a single prefix will be provided to other entities." > 3) Can the device use any technology (such as prefix sharing, eg. RFC7278), to also use addresses from a single prefix for other devices (same user) Technology used is out of scope here. I used the technology as an example, what I'm referring is if the single prefix can be shared by other devices of the user of a hot-spot (example, the hotel gives me a single /64 in the WiFi, but I've several devices). The point here is, clarification 2 above will solve the problem for multiple addresses in a single prefix, 3) may solve the problem for multiple devices with the same prefix. For both of them we may need to clarify if Max "not prefixes" is meaning also a single prefix or "not multiple prefixes", which is I think the major contradiction with the IA or NCC interpretation according to mail exchange with Marco. Cheers, Sander ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

4 6

policy text or anything else?
by JORDI PALET MARTINEZ 19 Jan '18

19 Jan '18

Hi all, I've changed the subject, because I want to talk here in general about our policy process, not any specific policy. I've tried to find where in our process, states that in addition to the policy text itself, other inputs during the PDP matter. If there is such confirmation, could the NCC tell me how to find it? I understand that this may have been our "practice", but maybe we did wrong. Let me explain why I think is wrong, and consequently we need to correct it. Let's suppose I'm an organization asking for the first time IPv6 space, I will find the actual policy at https://www.ripe.net/publications/docs/ripe-684 I read across it, and I obviously will decide, based on my needs what choices I've to apply for. I've not followed the PDP since the first time we discussed an IPv6 policy, so I'm missing all the policy proposals text, arguments, rationales, impact analysis, etc. Because that, I'm applying with a different view from someone that has been for ages in the addressing policy list and following it, and possible not taking advantages of perspectives that are "in between lines" in the policy text, which may make a huge difference on my request vs a "follower" of the PDP. I would agree with that (using not only the policy text, but also all the PDP documents) IF when I go to the ripe-684 document, I've direct links in every section of the policy text, pointing to the PDP documents that have been used to modify that section. I hope everybody understand what I mean, not sure if is so easy to explain. Now, is that realistic? It will make our policy text so difficult to read ... and a very very very long (and always increasing) document. So, my conclusion: what it matters is only policy text, other documents are relevant to explain it, but not to add "modifications" to the reading of that text so not conflicts should be there (unless undiscovered). I agree that we are humans and we can make mistakes, and we may need to go to new rounds of PDP to correct that, new proposals, or whatever, but even if it takes some extra work, policy text must be refined if discrepancies are perceived. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces(a)ripe.net> en nombre de Marco Schmidt <mschmidt(a)ripe.net> Fecha: martes, 16 de enero de 2018, 16:05 Para: <address-policy-wg(a)ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Dear Max, On 2018-01-15 18:23:42 CET, Maximilian Wilhelm wrote: > As said before somewhere (I'm not sure wether on a RIPE meeting or > here on the list), the RS folks said, that they use the proposal text > as well as the summary/rationale as guidance what is allowed and what > isn't. > > Maybe Ingrid, Andrea, Marco, * from the NCC can comment on that? > Yes, this is correct. Whenever there is a question about the interpretation of RIPE Policies, we can refer to proposal summary as well to the impact analysis to ensure the correct understanding of the policy and its intent. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

1 0

Re: [address-policy-wg] inconsistency in 2016-04 (was: what does consensus mean)
by Sander Steffann 19 Jan '18

19 Jan '18

Hi Jim, > PLEASE put those comments in a different thread which makes it clear you're discussing detail about 2016-4 (or whatever). Thanks. > > This thread's supposed to be about an entirely different topic. Indeed, my apologies. There were so many things going on that I lost track as well :) Cheers, Sander

1 0

permanently % denied
by Patrick Schauer 10 Jan '18

10 Jan '18

Why your service blocked many of my customers? how can we delete your entries? Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0