From nobody Tue Dec 2 04:33:05 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D678B1A1B12 for ; Tue, 2 Dec 2014 04:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 vvK-ggafUC3i for ; Tue, 2 Dec 2014 04:28:25 -0800 (PST) Received: from out27-ams.mf.surf.net (out27-ams.mf.surf.net [145.0.1.27]) (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 3D1281A1B2E for ; Tue, 2 Dec 2014 04:28:24 -0800 (PST) Received: from smtps.utwente.nl (smtp-o1.utsp.utwente.nl [130.89.2.9]) by outgoing1-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id sB2CWr1u007484 for ; Tue, 2 Dec 2014 13:32:54 +0100 Received: from apple-imac2012.home.rickhofstede.nl (84-245-27-202.dsl.cambrium.nl [84.245.27.202]) by smtps.utwente.nl (8.13.8) with ESMTP id sB2CSMcF028693 for ; Tue, 2 Dec 2014 13:28:22 +0100 From: Rick Hofstede Content-Type: multipart/alternative; boundary="Apple-Mail=_F01EC2BB-8F75-4926-BA76-1A347A3EE350" Message-Id: <667BD772-FE38-44DF-A12C-7B3669C73FC9@utwente.nl> Date: Tue, 2 Dec 2014 13:28:17 +0100 To: nmrg@irtf.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.2.9; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0uNmAwSsC - 16088cd46805 - 20141202 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/8hGVRnr2CUOpvuGZTTpkA6oNFAI X-Mailman-Approved-At: Tue, 02 Dec 2014 04:33:00 -0800 Subject: [nmrg] =?utf-8?q?Deadline_Extension_-_Special_Issue_IJNM_=22Measu?= =?utf-8?q?re=2C_Detect_and_Mitigate_=E2=80=93_Challenges_and_Trends_in_Ne?= =?utf-8?q?twork_Security=22?= X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 12:28:29 -0000 --Apple-Mail=_F01EC2BB-8F75-4926-BA76-1A347A3EE350 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Apologies for receiving multiple copies] **The submission deadline has been extended to Dec 10, 2014** A PDF version of this call can be downloaded at: http://wwwhome.cs.utwente.nl/~sperottoa/cfp_ijnm_network_security.pdf = CALL FOR PAPERS Special Issue of the International Journal on Network Management (IJNM): = =20 "Measure, Detect and Mitigate =E2=80=93 Challenges and Trends in Network = Security" Submission Deadline: December 1, 2014 Publication: September, 2015 Scope of the Special Issue Cybercrime has developed rapidly within the last decade and in particular the last years have seen an unprecedented amount of attacks. Despite increased national as well as international effort against cybercrime and the global financial crisis, cybercrime still has double-digit annual growth rates. On the one hand, more and more services and systems migrate to the Internet and cloud storage systems. On the other hand, the commercial success of the Internet and the possibilities to carry out attacks from a relatively safe distance attracts criminals and made e-Crime to a multi-billion dollar market. In addition, recent trends have highlighted that not only end-hosts are the target of attacks, but also the Internet infrastructure itself, with attacks aiming at impeding the functioning of e.g., the Domain Name System (DNS) or Internet backbones.=20 The dramatic trends in attack evolution call upon innovative solutions. Nowadays, detection and mitigation of network attacks are more than ever a must. However, current solutions need to evolve fast in order to cope with new attack scenarios. The goal of this Special Issue is twofold. We encourage, on the one hand, contributions characterizing and measuring emerging network threats; on the other hand we welcome submissions presenting cutting-edge detection and mitigation techniques effective against network attacks and insider activities in today and future small-to-enterprise sized networks and in backbones. Areas of Interest Contributions in the following areas are of specific interest, but not limited to: * Identification and Classification of Attacks * Network Measurements to Understand Cyber-criminal activities * Network Attacks Characterization * Multi-Layer Network Detection * Inter-Domain and Cooperative Detection and Mitigation * Detection in Encrypted Networks * Supervised/Unsupervised Network Detection * Alert and Event Correlation * Visualization of Network Attacks and Alerts * Interaction of Detection Systems and Exchange Formats * Future Trends in Network Detection and Mitigation * Mitigation of Large-Scale Distributed Attacks * Novel Network Measurements and Data Analyses of Internet Malware Submission Guidelines Authors should submit their papers in PDF format only to http://mc.manuscriptcentral.com/nem = =20 Paper submissions should not exceed 20 pages (double-space). Author = instructions are available at = http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)1099-1190/homepage/Fo= rAuthors.html = and the respective LaTeX template can be found at = http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)1099-1190/homepage/la= tex_class_file.htm = Important Deadlines Submission Deadline: **December 10, 2014** Notification of Acceptance:March 1, 2015 =20 Final Version: June 15, 2015 =20 Publication: September 1,2015 Submissions to http://mc.manuscriptcentral.com/nem = in PDF only. Guest Editors: Gabi Dreo Rodosek - Universit=C3=A4t der Bundeswehr Munich, = Germany > =20 Anna Sperotto - University of Twente, The Netherlands = >=20 Corinna Schmitt - University of Zurich, Switzerland = >=20 Rick Hofstede - University of Twente, The Netherlands = >=20 Alberto Dainotti - CAIDA, University of California,San Diego, USA = >= --Apple-Mail=_F01EC2BB-8F75-4926-BA76-1A347A3EE350 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [Apologies for receiving multiple copies]

**The submission deadline has been extended to Dec 10, = 2014**

A    PDF =   version   of    this =   call    can   be =    downloaded   at:
http://wwwhome.cs.utwente.nl/~sperottoa/cfp_ijnm_network_securi= ty.pdf

CALL FOR PAPERS

Special Issue of the International Journal on Network = Management (IJNM):  
"Measure, Detect and Mitigate = =E2=80=93 Challenges and Trends in Network Security"

Submission Deadline: December 1, 2014 Publication: September, = 2015

Scope of the Special Issue

Cybercrime  has  developed =  rapidly  within  the last  decade  and =  in
particular  the  last  years =  have  seen an  unprecedented  amount  of
attacks. Despite  increased national  as well as =  international effort
against cybercrime  and = the global financial  crisis, cybercrime still
has = double-digit annual  growth rates. On the one  hand, more and = more
services  and  systems  migrate =  to  the Internet  and  cloud  storage
systems. On the other hand, the commercial success of the = Internet and
the possibilities to carry out attacks from a = relatively safe distance
attracts criminals and made =  e-Crime to a multi-billion dollar market.
In = addition,  recent trends have  highlighted that not  only = end-hosts
are  the  target of  attacks, =  but  also  the Internet  infrastructure
itself, with attacks  aiming at impeding the functioning =  of e.g., the
Domain Name System (DNS) or Internet = backbones. 

The  dramatic =   trends  in  attack  evolution =   call  upon  innovative
solutions. = Nowadays,  detection and mitigation of  network attacks are
more than ever a must.  However, current solutions need = to evolve fast
in order to  cope with new attack = scenarios. The  goal of this Special
Issue  is =  twofold.  We  encourage,  on the  one =  hand,  contributions
characterizing and =  measuring emerging  network threats; on  the other
hand  we  welcome submissions  presenting =  cutting-edge detection  and
mitigation =  techniques effective against  network attacks  and = insider
activities in today and  future = small-to-enterprise sized networks and
in backbones.

Areas of Interest

Contributions in the following areas are of specific = interest, but not
limited to:
* = Identification and Classification of Attacks
* Network = Measurements to Understand Cyber-criminal activities
* = Network Attacks Characterization
* Multi-Layer Network = Detection
* Inter-Domain and Cooperative Detection and = Mitigation
* Detection in Encrypted Networks
*= Supervised/Unsupervised Network Detection
* Alert and = Event Correlation
* Visualization of Network Attacks and = Alerts
* Interaction of Detection Systems and Exchange = Formats
* Future Trends in Network Detection and = Mitigation
* Mitigation of Large-Scale Distributed = Attacks
* Novel Network Measurements and Data Analyses of = Internet Malware

Submission Guidelines

Authors   should  submit =   their  papers   in  PDF =   format   only  to
http://mc.manuscriptcentral.com/nem   

Paper  submissions   should =  not exceed 20  pages (double-space). Author instructions =  are available at
http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)1099-1190/= homepage/ForAuthors.html
and    the =   respective    LaTeX =    template   can    be =   found    at
http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)1099-1190/= homepage/latex_class_file.htm

Important = Deadlines

Submission  Deadline: =  **December 10,  2014**
Notification of =  Acceptance:March 1, 2015  
Final Version: June = 15, 2015  
Publication: September 1,2015

Submissions to http://mc.manuscriptcentral.com/nem in PDF only.

Guest Editors:

Gabi=  Dreo  Rodosek  -  Universit=C3=A4t  der =  Bundeswehr  Munich,  Germany <gabi.dreo@unibw.de> =  
Anna  Sperotto   -  University =  of  Twente,  The Netherlands  <a.sperotto@utwente.nl> 
Corinna =  Schmitt -  University of Zurich, Switzerland <schmitt@ifi.uzh.ch> 
Rick Hofstede = - University of Twente, The  Netherlands <r.j.hofstede@utwente.nl> 
Alberto =  Dainotti - CAIDA, University of California,San Diego, USA <alberto@caida.org>= --Apple-Mail=_F01EC2BB-8F75-4926-BA76-1A347A3EE350-- From nobody Wed Dec 3 11:58:29 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1EA1A6FA9 for ; Wed, 3 Dec 2014 11:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2zRUJXtY0X7P for ; Wed, 3 Dec 2014 11:58:21 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD871A1BDA for ; Wed, 3 Dec 2014 11:58:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,509,1413237600"; d="scan'208,217";a="110957342" Received: from unknown (HELO [38.110.20.86]) ([38.110.20.86]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 03 Dec 2014 20:58:15 +0100 Message-ID: <547F6B55.2060207@inria.fr> Date: Wed, 03 Dec 2014 20:58:13 +0100 From: =?UTF-8?B?SsOpcsO0bWUgRnJhbsOnb2lz?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: nmrg@irtf.org Content-Type: multipart/alternative; boundary="------------090504050004020808020604" Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/4v313fgRrL1idDXIBMlIGodjJBE Subject: [nmrg] CFP: IFIP AIMS 2015 | June 22-26 2015, Ghent Belgium X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 19:58:26 -0000 This is a multi-part message in MIME format. --------------090504050004020808020604 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit We apologize for multiples copies. Please circulate this CFP among your colleagues and students. ********************************************************************** The 9th IFIP International Conference on Autonomous Infrastructure, Management and Security (AIMS 2015) June 22 - 26, 2015, Ghent, Belgium http://www.aims-conference.org/2015/ ********************************************************************** The AIMS international conference is a single-track event, including conference paper sessions, hands-ons and keynotes, which focuses on early research done by PhD students and young researchers in network and service management and security. The participants find here a dedicated place for getting a constructive feedback by senior scientists and they benefit from tutorials on transversal aspects of a research activity (e.g. publication strategies, paper reviewing, research presentation design). By taking part in a dedicated workshop, the PhD students are invited at an early stage to present and motivate their work as well as their research plans. Finally, by being involved in practical hands-on sessions, PhD students and young researchers will get an up-to-date knowledge combined with basic skills on emerging technologies. This way, AIMS acts as a complementary piece in the set of international conferences in the network and service management community. AIMS 2015 focuses on the management of infrastructures, services and content, as focal components of the Future Internet. New paradigms as well as autonomic and fully distributed algorithms, virtualization and monitoring techniques or self-organizing overlays have to be investigated to design scalable and resilient frameworks able to deal with dynamic and often domain-specific environments, and also to cope with big data to process and content to be delivered. The design, monitoring, configuration and protection of the next generation of networked systems in an efficient, secure, and autonomic manner are crucial to commercially viable and successful networks and services. Authors are invited to submit papers on the following topics, including related fields: Network and service management - Wireless networks (adhoc, mesh, sensor, vehicular, ...) - Internet of things - Smart cities - Smart grids - Cyber-physical networks - Overlay, grid and virtual networks - Big data Analytics - Software defined networks - Data centers and clouds (Iaas, Paas and SaaS) - Content delivery (P2P, CDN, ICN, ...) - Social networks - Future Internet Management functions - Intrusion detection - Protection of infrastructures and services - Security management - Configuration management - Accounting of systems, services and behaviors - Economic traffic management - Service provisioning - Resilience of management infrastructures and services - Privacy and management data - Quality of service and experience Techniques and Methodologies - Autonomic and self-management - Cognitive management - Distributed monitoring and correlation - Risk management - Knowledge plane design and deployment - P2P-based management - Modeling of management technologies and procedures - Flow based management - Scalability of management infrastructures - Experimental studies Conference Paper Submission: Only original, full papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English and will be limited to 12 pages, references excluded, in the LNCS paper format. Papers exceeding 12 pages, multiple submissions, and self-plagiarized papers will be rejected without further review. Paper submission is handled by the JEMS system, accessible from the AIMS 2015 web page. PhD Student Workshop Submission: The PhD student workshop is open to both junior PhD (max 2 years) and prospective PhD students. Authors are invited to submit short papers (4 pages excluding references, written in English and in LNCS format) describing the current state of their research. The paper should include a clear description of the research problem and the chosen approach, argue why the problem is hard and the approach novel, and it should outline the results achieved to date. Specific, low- level technical details should be avoided. Papers will be evaluated based on the proposed idea, methodology and foreseen impact. Authors of the papers should only be the student and his/her advisor(s). Accepted submissions will be published in the AIMS 2015 proceedings. Proceedings: The conference proceedings will be published in Springer's Lecture Notes of Computer Science (LNCS) series and will include the conference papers as well as the PhD student workshop papers. Important Dates: - January 16, 2015: Paper registration deadline - January 23, 2015: Paper submission deadline - March 11, 2015: Notification of acceptance - April 1, 2015: Camera-ready papers due - June 22 - 26, 2015: AIMS 2015 conference General Co-Chairs - Filip De Turck, Ghent University - iMinds, Belgium - Piet Demeester, Ghent University - iMinds, Belgium Technical Program Co-chairs - Steven Latré, University of Antwerp - iMinds, Belgium - Marinos Charalambides, University College London, United Kingdom Ph.D. Student Workshop Co-chairs - Corinna Schmitt, University of Zurich, Switzerland - Jérôme François, INRIA, France Publications Chair - Burkhard Stiller, University of Zurich, Switzerland Steering Committee - Ramin Sadre, Université Catholique de Louvain, Belgium - Guillaume Doyen, University of Technology Troyes, France - Anna Sperotto, University of Twente, Netherlands - Pavel Celeda, Masaryk University, Czech Republic - David Hausheer, Technical University Darmstadt, Germany - Aiko Pras, University of Twente, Netherlands - Burkhard Stiller, University of Zurich, Switzerland Technical Program Committee - Alessandro Finamore, Politecnico di Torino, Italy - Alex Galis, University College London, United Kingdom - Alexander Clemm, Cisco Systems, USA - Alexander Keller, IBM Global Technology Services, USA - Alva Couch, Tufts University, USA - Anandha Gopalan, Imperial College London, United Kingdom - Bertrand Mathieu, Orange Labs, France - Bruno Quoitin, Université de Mons, Belgium - Burkhard Stiller, University of Zurich, Switzerland - Danny Raz, Technion, Israel - David Hausheer, TU Darmstadt, Germany - Filip De Turck, Ghent University - iMinds, Belgium - Gabi Dreo Rodosek, University of Federal Armed Forces, Munich, Germany - Georgios Karagiannis, University of Twente, The Netherlands - Grégory Bonnet, University of Caen Lower Normandy, France - Isabelle Chrisment, TELECOM Nancy - Université de Lorraine, France - Jan Korenek, Brno University of Technology, Czech Republic - Jérôme François, University of Luxembourg, Luxembourg - Juergen Schoenwaelder, Jacobs University Bremen, Germany - Kurt Tutschku, Blekinge Institute of Technology, Sweden - Lisandro Zambenedetti Granville, UFRGS, Brasil - Martin Waldburger, WIK-Consult, Germany - Martin Zadnik, Brno University of Technology, Czech Republic - Mauro Tortonesi, University of Ferrara, Italy - Michelle Sibilla, Paul Sabatier University, France - Olivier Festor, INRIA Nancy - Grand Est, France - Philippe Owezarski, LAAS-CNRS, France - Piotr Cholda, AGH University of Science and Technology, Poland - Radu State, University of Luxembourg, Luxembourg - Ramin Sadre, Aalborg University, Denmark - Raouf Boutaba, University of Waterloo, Canada - Remi Badonnel, INRIA - TELECOM Nancy - University of Lorraine, France - Robert Szabo, Budapest University of Technology and Economics, Hungary - Thomas Bocek, University of Zurich, Switzerland - Vojtech Krmicek, Masaryk University, Czech Republic PhD Student Workshop Committee - Aiko Pras, University of Twente, The Netherlands - Alberto Schaeffer-Filho, Federal University of Rio Grande do Sul (UFRGS), Brazil - Bradley Simmons, York University, Canada - Clarissa Marquezan, Duisburg-Essen University, Germany - Desislava Dimitrova, University of Bern, Switzerland - Dimitrios Pezaros, University of Glasgow, United Kingdom - Eleni Patouni, University of Athens, Greece - Jan Vykopal, Masaryk University, Czech Republic - Jeroen Famaey, University of Antwerp - iMinds, Belgium - Joan Serrat, Universitat Politecnica de Catalunya, Spain - Kostas Tsagkaris, University of Piraeus, Greece - Lefteris Mamatas, University College London, United Kingdom - Maxwell Young, Drexel University, USA - Paulo Simoes, University of Coimbra, Portugal - Pavel Celeda , Masaryk University, Czech Republic - Steven Davy, Waterford Institute of Technology, Ireland - Stylianos Georgoulas, University of Surrey, United Kingdom - Sven van der Meer, Ericsson, Ireland - Thibault Cholez, LORIA / INRIA Nancy - Grand Est, France --------------090504050004020808020604 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

We  apologize for multiples  copies. Please  circulate this  CFP among

your colleagues and students.


**********************************************************************


            The 9th IFIP International Conference on

   Autonomous Infrastructure, Management and Security (AIMS 2015)


         June 22 - 26, 2015, Ghent, Belgium

             http://www.aims-conference.org/2015/

                          

**********************************************************************


The AIMS  international conference is a  single-track event, including

conference paper  sessions, hands-ons  and keynotes, which  focuses on

early research done  by PhD students and young  researchers in network

and  service management and  security.  The  participants find  here a

dedicated  place  for  getting   a  constructive  feedback  by  senior

scientists and they benefit from tutorials on transversal aspects of a

research  activity  (e.g.   publication strategies,  paper  reviewing,

research  presentation  design).   By   taking  part  in  a  dedicated

workshop, the  PhD students are invited  at an early  stage to present

and motivate their  work as well as their  research plans. Finally, by

being involved in practical  hands-on sessions, PhD students and young

researchers  will  get an  up-to-date  knowledge  combined with  basic

skills  on   emerging  technologies.   This   way,  AIMS  acts   as  a

complementary  piece in the  set of  international conferences  in the

network and service management community.


AIMS 2015  focuses on the management of  infrastructures, services and

content, as focal components of the Future Internet.  New paradigms as

well as autonomic and fully distributed algorithms, virtualization and

monitoring   techniques  or  self-organizing   overlays  have   to  be

investigated to design scalable  and resilient frameworks able to deal

with dynamic and often  domain-specific environments, and also to cope

with big  data to  process and content  to be delivered.   The design,

monitoring,  configuration and  protection of  the next  generation of

networked systems  in an efficient,  secure, and autonomic  manner are

crucial to commercially viable and successful networks and services.


Authors  are  invited  to  submit  papers  on  the  following  topics,

including related fields:


Network and service management

- Wireless networks (adhoc, mesh, sensor, vehicular, ...)

- Internet of things

- Smart cities

- Smart grids

- Cyber-physical networks

- Overlay, grid and virtual networks

- Big data Analytics

- Software defined networks

- Data centers and clouds  (Iaas, Paas and SaaS)

- Content delivery (P2P, CDN, ICN, ...)

- Social networks

- Future Internet


Management functions

- Intrusion detection

- Protection of infrastructures and services

- Security management

- Configuration management

- Accounting of systems, services and behaviors

- Economic traffic management

- Service provisioning

- Resilience of management infrastructures and services

- Privacy and management data

- Quality of service and experience


Techniques and Methodologies

- Autonomic and self-management

- Cognitive management

- Distributed monitoring and correlation

- Risk management

- Knowledge plane design and deployment

- P2P-based management

- Modeling of management technologies and procedures

- Flow based management

- Scalability of management infrastructures

- Experimental studies


Conference Paper Submission:


Only original, full  papers that have not been  published or submitted

for publication  elsewhere can be  submitted. Each submission  must be

written  in  English and  will  be  limited  to 12  pages,  references

excluded,  in  the LNCS  paper  format.   Papers  exceeding 12  pages,

multiple  submissions, and  self-plagiarized papers  will  be rejected

without  further  review. Paper  submission  is  handled  by the  JEMS

system, accessible from the AIMS 2015 web page.


PhD Student Workshop Submission:


The PhD  student  workshop  is open  to both junior  PhD (max 2 years)

and prospective  PhD  students. Authors  are invited  to submit  short

papers  (4 pages  excluding references, written in English and in LNCS

format) describing the  current state of  their  research.  The  paper

should include a  clear  description of  the research problem and  the

chosen approach, argue why the problem is hard and the approach novel,

and it should  outline  the results  achieved to  date. Specific, low-

level technical details should be  avoided. Papers  will be  evaluated

based on  the proposed  idea, methodology and foreseen impact. Authors

of the papers  should  only  be  the student  and his/her  advisor(s).

Accepted  submissions  will be published in the AIMS 2015 proceedings.


Proceedings:


The  conference proceedings  will be  published in  Springer's Lecture

Notes  of  Computer  Science   (LNCS)  series  and  will  include  the

conference papers as well as the PhD student workshop papers.


Important Dates:


- January 16, 2015: Paper registration deadline

- January 23, 2015: Paper submission deadline

- March 11, 2015: Notification of acceptance

- April 1, 2015: Camera-ready papers due

- June 22 - 26, 2015: AIMS 2015 conference


General Co-Chairs

- Filip De Turck, Ghent University - iMinds, Belgium

- Piet Demeester, Ghent University - iMinds, Belgium


Technical Program Co-chairs

- Steven Latré, University of Antwerp - iMinds, Belgium

- Marinos Charalambides, University College London, United Kingdom


Ph.D. Student Workshop Co-chairs

- Corinna Schmitt, University of Zurich, Switzerland

- Jérôme François, INRIA, France


Publications Chair

- Burkhard Stiller, University of Zurich, Switzerland


Steering Committee

- Ramin Sadre,  Université Catholique de Louvain, Belgium

- Guillaume Doyen, University of Technology Troyes, France

- Anna Sperotto, University of Twente, Netherlands

- Pavel Celeda, Masaryk University, Czech Republic

- David Hausheer, Technical University Darmstadt, Germany

- Aiko Pras, University of Twente, Netherlands

- Burkhard Stiller, University of Zurich, Switzerland


Technical Program Committee

- Alessandro Finamore, Politecnico di Torino, Italy

- Alex Galis, University College London, United Kingdom

- Alexander Clemm, Cisco Systems, USA

- Alexander Keller, IBM Global Technology Services, USA

- Alva Couch, Tufts University, USA

- Anandha Gopalan, Imperial College London, United Kingdom

- Bertrand Mathieu, Orange Labs, France

- Bruno Quoitin, Université de Mons, Belgium

- Burkhard Stiller, University of Zurich, Switzerland

- Danny Raz, Technion, Israel

- David Hausheer, TU Darmstadt, Germany

- Filip De Turck, Ghent University - iMinds, Belgium

- Gabi Dreo Rodosek, University of Federal Armed Forces, Munich, Germany

- Georgios Karagiannis, University of Twente, The Netherlands

- Grégory Bonnet, University of Caen Lower Normandy, France

- Isabelle Chrisment, TELECOM Nancy - Université de Lorraine, France

- Jan Korenek, Brno University of Technology, Czech Republic

- Jérôme François, University of Luxembourg, Luxembourg

- Juergen Schoenwaelder, Jacobs University Bremen, Germany

- Kurt Tutschku, Blekinge Institute of Technology, Sweden

- Lisandro Zambenedetti Granville, UFRGS, Brasil

- Martin Waldburger, WIK-Consult, Germany

- Martin Zadnik, Brno University of Technology, Czech Republic

- Mauro Tortonesi, University of Ferrara, Italy

- Michelle Sibilla, Paul Sabatier University, France

- Olivier Festor, INRIA Nancy - Grand Est, France

- Philippe Owezarski, LAAS-CNRS, France

- Piotr Cholda, AGH University of Science and Technology, Poland

- Radu State, University of Luxembourg, Luxembourg

- Ramin Sadre, Aalborg University, Denmark

- Raouf Boutaba, University of Waterloo, Canada

- Remi Badonnel, INRIA - TELECOM Nancy - University of Lorraine, France

- Robert Szabo, Budapest University of Technology and Economics, Hungary

- Thomas Bocek, University of Zurich, Switzerland

- Vojtech Krmicek, Masaryk University, Czech Republic


PhD Student Workshop Committee

- Aiko Pras, University of Twente, The Netherlands

- Alberto Schaeffer-Filho, Federal University of Rio Grande do Sul (UFRGS), Brazil

- Bradley Simmons, York University, Canada

- Clarissa Marquezan, Duisburg-Essen University, Germany

- Desislava Dimitrova, University of Bern, Switzerland

- Dimitrios Pezaros, University of Glasgow, United Kingdom

- Eleni Patouni, University of Athens, Greece

- Jan Vykopal, Masaryk University, Czech Republic

- Jeroen Famaey, University of Antwerp - iMinds, Belgium

- Joan Serrat, Universitat Politecnica de Catalunya, Spain

- Kostas Tsagkaris, University of Piraeus, Greece

- Lefteris Mamatas, University College London, United Kingdom

- Maxwell Young, Drexel University, USA

- Paulo Simoes, University of Coimbra, Portugal

- Pavel Celeda , Masaryk University, Czech Republic

- Steven Davy, Waterford Institute of Technology, Ireland

- Stylianos Georgoulas, University of Surrey, United Kingdom

- Sven van der Meer, Ericsson, Ireland

- Thibault Cholez, LORIA / INRIA Nancy - Grand Est, France


--------------090504050004020808020604-- From nobody Thu Dec 11 08:06:17 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66471A9128; Wed, 10 Dec 2014 14:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 6jJJzbsgNDC5; Wed, 10 Dec 2014 14:20:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E8C1A9105; Wed, 10 Dec 2014 14:20:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210222018.2541.61911.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 14:20:18 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/T2nebChBBkEtwlOphAJc9a0Jt6s X-Mailman-Approved-At: Thu, 11 Dec 2014 08:06:16 -0800 Cc: nmrg@irtf.org Subject: [nmrg] I-D Action: draft-irtf-nmrg-an-gap-analysis-03.txt X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 22:20:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Management Working Group of the IETF. Title : Gap Analysis for Autonomic Networking Authors : Sheng Jiang Brian Carpenter Michael H. Behringer Filename : draft-irtf-nmrg-an-gap-analysis-03.txt Pages : 17 Date : 2014-12-10 Abstract: This document provides a problem statement and gap analysis for an IP-based autonomic network that is mainly based on distributed network devices. The document provides a background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralisation and human administrators. Finally the document describes the general gaps between current network abilities and the ideal autonomic network concept. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-nmrg-an-gap-analysis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-irtf-nmrg-an-gap-analysis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-an-gap-analysis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 12 08:32:11 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9531A6FB0 for ; Fri, 12 Dec 2014 08:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.012 X-Spam-Level: X-Spam-Status: No, score=-12.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 I9acFcF4NV2F for ; Fri, 12 Dec 2014 08:32:03 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8C31A6FAC for ; Fri, 12 Dec 2014 08:32:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4879; q=dns/txt; s=iport; t=1418401923; x=1419611523; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=W/hak73KqtHnQRU15G04i/pYSWeIGzRugwJ3XI9Jepk=; b=QmDqy1s3Ojofew8x9Ni9K1i/KiMmwxuP3a7eSCDrQ/oZxJHc5+yLxcN3 3LFJKwp1Sx0xkTIfuRkZbXJfHhanRLyop40z+htsMk3FzF8CPj1HUS2ZE DEoTMmloWDUSrNQoxrNLHex64zl/OZYOlJVDCF0dARv23msSopdZ97Jrj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4LAM4Xi1StJssW/2dsb2JhbABZhzawMAEBAQEBAQUBd5Rngk0CgSsBAQEBAX2EDAEBAQMBIw8BBUYLCQIYAgIFIQICDwJGBgEMCAEBiCAIpRicXpZJAQEBAQEBAQMBAQEBAQEcgSGEX4kaClWCaIFBAQSMKopEgQuEbogGgzgigXw0gT09gTMCHgaBGgEBAQ X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="266997034" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 12 Dec 2014 16:32:00 +0000 Received: from [10.55.238.140] (ams-mbehring-88111.cisco.com [10.55.238.140]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBCGVvuU015360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 12 Dec 2014 16:31:59 GMT Message-ID: <548B187C.80508@cisco.com> Date: Fri, 12 Dec 2014 17:31:56 +0100 From: Michael Behringer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David R Oran , nmrg@irtf.org, draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org References: <31F12CB7-2694-44EB-97AA-11FB863C173A@netapp.com> <20C63FF7-971B-4FA1-A935-CD26A50D0972@orandom.net> In-Reply-To: <20C63FF7-971B-4FA1-A935-CD26A50D0972@orandom.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: mbehring Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/oeBqUjkuKYTUf6Q9GqGuhfdXnwU Subject: Re: [nmrg] IRSG Review of NMRG document draft-irtf-nmrg-autonomic-network-definitions-04.txt X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 16:32:09 -0000 Hi Dave, Thanks for your feedback. Finally I'm finding the time to work through all the feedback received. Sorry for the delay. Inline... On 17/11/2014 01:37, David R Oran wrote: > This document is overall in good shape and ready for publication. I have a few minor and editorial comment however that may improve the exposition. > > P2. > • you say "policy is by its nature derived from humans”. I think you mean "policy is by its nature derived and specified by humans” Yes, we mean that. Corrected. > • your say " "Automatic" refers to a pre-defined, linear process,” What makes an automatic procedure necessarily “linear”? Does that mean no branching? Perhaps just say pre-defined, or just forward reference to the more formal definition below, which is better Done. > P3 > • In the definition of “intent” you say " nodes with a specific role”, but then are silent on what you mean by a “role”. Is if a type of node, like a router versus host, or something more abstract, like whether it is a node with links to other networks, or nodes with particular functions, like a NAT? You may want to either just elucidate this somewhere, or formally define “roles” in the content of autonomic intents. Done. > • Under “autonomic domain” you say " instantiate the same intent”. Do you actually mean that to be singular (only one intent for a whole domain), is there just a missing plural? We mean it to be singular. > P4 > • You restrict the operation of autonomic networks to work by pari-wise protocols.negotiations. In particular, you say > • " peer-to-peer dialogues between the parties that make up the closed loop. Such dialogues > require two-way "discussion" or "negotiation" between each pair of peers involved in the loop, so they cannot readily use typical top-down command-response protocols.between the parties that make up the closed loop. Such dialogues require two-way "discussion" or "negotiation" between each pair peers involved in the loop, so they cannot readily use typical top down command-response protocols.” > • While you are quite explicit about this, I don’t see any fundamental reason why the protocols and negotiations could not be multi-party, or exploit consensus protocols like Paxos. It’s probably OK to go ahead and not address this, but since it occurred to me it might also occur to other readers well-versed in distributed algorithms. Very good point. Clarified that. > P5 > • You say " results in unlimited power of the human administrator”. A human administrator prima facia can’t have unlimited power. Perhaps instead say “results in the actions of a human administrator always being able to override the actions of other machinery”. Changed. Although you need to take me through this one day in more detail. Sounds philosophical to me ;-) > P6 > • Funny character substitution: " respected‎” Fixed. > P7 > • You say " The administrator should not even be exposed to the version of the IP protocol running in the network.” Either say “For example…” or generalize the statement to not needing to know “the exact configuration of protocols running on the network or their individual versions”. Done. > • On feedback, the example " provides high-level messages such as "the link between node X and Y is down” seems a bit peculiar. If it;s a link that is down, you really need to say which link it is, since there may be more than one link between two nodes. Abstraction does have some tradeoffs with ambiguity, but just saying this without admitting the nuances might be problematic. Alternatively, perhaps what you meant to say for the autonomic abstraction isn’t that a link was down, but rather “Node X cannot communicate directly with node Y” Added a note on a link identifier. > • Thee’s a similar tension in the example on energy efficiency, where you say " intent "optimize my network for energy efficiency", the network should provide aggregate information about the number of ports that were able to be shut down while validating current service levels are on aggregate still met.” Unless the administrator knows a lot of detail on the power consumed by a port, the feedback is of limited value. Should an autonomic network have enough introspection and access to fundamental characteristics that it can instead match the abstraction of the intent by reporting “I saved k watts while maintaining…” Changed this sentence accordingly. > P8 > • Where you say " IP is the layer that binds all those elements together; “ you might explicitly use the “Spanning-layer” terminology, i.e. " IP is the spanning layer that binds all those elements together” Done. Thanks for your review, Dave, very good feedback! Michael From nobody Fri Dec 12 08:32:43 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79801A6FB8 for ; Fri, 12 Dec 2014 08:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.612 X-Spam-Level: X-Spam-Status: No, score=-12.612 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 MyQgzaabo5n8 for ; Fri, 12 Dec 2014 08:32:38 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0151ACE96 for ; Fri, 12 Dec 2014 08:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18462; q=dns/txt; s=iport; t=1418401957; x=1419611557; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LAA6qhoZPnruu2hX+CpzbEWNFN8jKc4FlGekwjU6RXs=; b=lgW48uk7w1kmRxwINU+pPKeHea+v0P0I7pnxvYrXq8ZfMwGItTiDvpxs GHaprbb38fJxGrXhug/7m9GidcRpYSDNVAyIYkp31XU/RttOJZItnLTtP hvf+ECRtDyKLmSocN2cC7GO6levApSCN32QXYDWKOq1J/JlIe9alCH2M/ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsALABYYi1StJssW/2dsb2JhbABZt2YBAQEBAQEFAXeUZ4JNAoErAQEBAQF9hAwBAQEDATg6BgEFCwsOCgkWDwkDAgECAUUGAQwBBwEBEAWICwjYQgEBAQEBAQEBAQEBAQEBAQEBAQEZhgCECoUFFU4HhCkBBIUdkVGBC4JeghAhh2WDOCKBfIFxPYJzAQEB X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="scan'208";a="271728731" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 12 Dec 2014 16:32:35 +0000 Received: from [10.55.238.140] (ams-mbehring-88111.cisco.com [10.55.238.140]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBCGWXMr027264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 12 Dec 2014 16:32:34 GMT Message-ID: <548B18A1.9080102@cisco.com> Date: Fri, 12 Dec 2014 17:32:33 +0100 From: Michael Behringer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kostas Pentikousis , "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C7ADE14@SBS2008.eict.local> In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C7ADE14@SBS2008.eict.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: mbehring Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/C1iOTvDBB4CjAXN7QZmcPJwedGk Cc: "nmrg@irtf.org" Subject: Re: [nmrg] Review of draft-irtf-nmrg-autonomic-network-definitions-04 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 16:32:41 -0000 Kostas, First of all thanks for your very thorough review of the document, this is really appreciated. Sorry for the late reply, I'm working in "batches" on each draft. Inline more comments. On 27/10/2014 19:58, Kostas Pentikousis wrote: > Dear authors, all, > > I reviewed draft-irtf-nmrg-autonomic-network-definitions-04. Overall, the draft is easy-to-read, but it feels more like "original" work than the RG documents I'm familiar with. As I mentioned in the Toronto meeting and on the list, the draft lacks the appropriate list of "citations and references to relevant research publications". I personally do not consider sufficient the three references mentioned in passing ("There is a > large literature, including several useful overview papers (e.g., [Samaan], [Movahedi], and [Dobson])"). Further, several assumptions remain unstated (could be fixed by adding a new section) and certain inconsistencies persist in this revision (see below). We made a conscious choice to not go into the details of existing work, because 1) there is a vast range of papers on the subject, and it would blow the format of an IETF document to go through all of those, and 2) there are existing papers that compare and analyse the existing work already. Our intention is to cite those overview papers, but consciously not to repeat such work here. I'll address the inconsistencies of course, below. > In summary: If this draft is to become the reference RFC on Autonomic Networking, more work is needed in the RG. > > > General comments: > ----------------- > > The draft includes some normative-resembling language, which may be misleading to uninitiated readers: I'll look through those sentences in detail, but generally, a reader with MINIMAL knowledge of the IETF will understand that this is not normative, because 1) it's an informational draft, 2) it doesn't reference RFC2119, and 3) none of the "MUST" and other keywords is in uppercase. However, I agree we want to avoid misunderstandings, so I'll still look through those sentences. > * "For this reason we suggest here to NOT generally disable autonomic functions if they encounter unexpected conditions ..." > > * "Autonomic functions must be able to adapt their behavior ... " > > * "Intent must not be used to convey low-level commands or concepts ..." > > * "an autonomic function must understand the full life cycle of the device it runs on ... > > * "Warnings however should be issued if node specific overrides may conflict with autonomic behaviour." > > * "Information about the network should be collected and aggregated by the network itself, presented in consolidated fashion to the administrator." > > * "Autonomic network events should concern the autonomic network as a whole, not individual systems in isolation. ..." (and the rest of the paragraph) > > * "apply specific algorithms to determine what should be reported." Up to here, I do not see a possible misunderstanding, and I really don't see how this could be mistaken for normative language in an informational document. I also don't quite see what you would like us to do? Not use the words "should" and "must"? > * "All the components around the "autonomic service agents" should be common components, such that the autonomic service agents do not have to replicate common tasks individually." Doesn't this read like an implementation suggestion? The intention here is to explain why standardisation is actually necessary. There should be common components that take on tasks that many components will need to do. I don't see this as an implementation suggestion, but as an architectural consideration. How would you suggest to change it? > * "autonomic functions in the context of this framework should therefore operate at the IP layer." > > I guess it would be better to rephrase the above sentences to avoid future misunderstandings. > > Also, have we reached consensus in NMRG that "The goal of the work on autonomic networking in the IETF is therefore not just to create autonomic functions, but to define a common infrastructure that autonomic functions can use." And, why is an NMRG draft indicating what the IETF goal is? I believe this sentence reflects discussions we had in NMRG meetings and outside, and yes, this is sort of a statement of direction for the work in the IETF. I believe this is in fact what the IRTF aims to do: Recommend to the IETF how to handle topics that are mature in research but not yet in implementations. > Section-specific comments: > -------------------------- > > - Abstract: The sentence "This document applies the concepts of autonomic systems to a network, ..." does not reflect the draft contents. There is very little that is being _applied_ to, as no references to earlier work are given for the concepts defined in the draft (as per Sec. 2). As mentioned above, the text reads more like original work undertaken for this draft. Very good point, you are right, the abstract doesn't reflect the document content very well any more. I've changed it significantly to reflect the current content better. > - Section 1: The draft makes an implicit assumption which should become explicit. Namely, the draft adopts a node-centric approach ("Autonomic Networking aims at putting the intelligence of today's operations back into algorithms at the node level ...". This assumption should be stated explicitly. Mind you, not everyone in the research community may agree that AN should be defined at the node level, instead of at the system level. I'd would be interested in other folks' opinion/pointers in earlier literature on this. Note that "node" is defined in Sec. 2 by what it does (i.e. it "employs exclusively autonomic functions"). This is indeed a very important point, and I THOUGHT we had brought it out well, but obviously NOT. So thanks for raising this, this MUST be clear! So, I'll be clearer about this. I agree that you could define it either way (node level or system level). We just need to be clear what we're working on here. Personal opinion: The system level definition is perfectly acceptable, but probably doesn't require additional standardisation in the IETF. You could use existing protocols to implement feedback loops between central elements and network elements. Essentially, I would argue the SDN approach has the potential to go this way. In this work we want to concentrate on node level autonomy. This does NOT mean that it's the only correct way, it's just setting the scope. As said, I'd expect system level autonomy to come from other groups. But, you are right, this needs to be made clearer. Working on it. > The following sentence implies a certain dichotomy: "a mixed approach, where some functions are autonomic and others are centrally mangaged", which may be true if you have the node-centric assumption in mind. A RoutFlow-like network runs OSPF "centrally" but I would argue that it retains the autonomic properties of the protocol at the system level ("Autonomic Domain" in terms of this draft). This dichotomy appears later in the text as well, e.g. "which functions should be centralised or follow an autonomic approach." This is really a question of positioning though, isn't it? With your comments above I have clarified that This work specifically focuses on node level autonomic functions. It focuses on intelligence of algorithms at the node level, to minimize dependency on human administrators and central management systems. If I re-read the above text, to me that means that here we focus on node level autonomy a dn centrally managed is out of scope for this work. Then, the above makes sense I think. Would you agree? > Regarding related work, the text indicates that in "the present document we focus on concepts and definitions that seem sufficiently mature to become the basis for interoperable specifications in the near future." Since no references are given, _who_ has determined that the "concepts and definitions" in this draft are "mature". The authors? NMRG? ... Was there a workshop to tackle this point? Perhaps adding a reference would resolve this in a speedy manner. Ditto for the ending sentence of this section: "This document provides the definitions and design goals for Autonomic Networking." In which context? We have had quite a few discussions in NMRG meetings, and on the list about this point, and I believe the definitions and concepts in the doc represent a consensus. Can you be specific on where you believe we do not have consensus? All we're trying to say with this sentence: In academic research, autonomics goes much further, we're really trying to capture the fundamentals only. To your last question: Context is the work in the IETF and IRTF. (I'll add this to the text) Put bluntly: If a future document in the IETF agrees with these definitions, it may reference this document. If they want to make their own definitions, fine. Nobody is obliged to use this document. Needless to say, of course we hope it to be usefuls, and would be seriously concerned if it wasn't used in the future. > Another assumption is that the draft aims for a migration environment ("such specifications will need to co-exist with traditional methods of network configuration and management, rather than realising an exclusively autonomic system with all the properties that it would require."). A distinct section entitled "Assumptions" would serve the casual reader well. Hmmm... Somewhat sceptical about re-arranging the entire doc at this point. Let me think about this. > - Section 2: Since no references are provided, some text should be added to explicitly state that these definitions are specified by _this_ draft. Alternatively, of course, refs could be added. Well, if you use external references, you add them. If you don't add references, it's the definition of this draft. Isn't that obvious? Frankly, I think this is redundant. But, to avoid a lengthy discussion, I'll add "We make the following definitions:" OK? > It's not crystal clear what is the relationship between an Autonomic Network and a Autonomic Domain. Based on their current definitions, it appears to be the lack of (the same) intent. Please clarify. An autonomic network may have one or severals autonomic domains. Added, thanks. > The concept of an operating region for an autonomic node/network/domain is missing in the definitions. Can you explain what you mean by "operating region"? We don't use that term currently. > - Section 3: Do we have consensus in NMRG that "The original design goals of autonomic systems as described in [Kephart] also apply to Autonomic Networks" (as-is)? I heard different opinions, but I'm curious what others in the RG think. You're implying that they don't, without saying why. Rather than leaving us all guessing, can you please be explicit where you think we deviate? > In Sec. 3.1: > > "Functions do not require to be configured," -- by whom? Do you mean a network operator? We mean: "Functions do not require to be configured, neither by an administrator nor a management system." (changed) > "secure themselves against potential attacks." -- shouldn't this be a bit scoped? I see this as a high level design goal. Specifics shouldn't be in "design goals", but I do agree that when we get to the detailled specifications, we need to go into much more detail. For this section, I think we can leave this high level statement. Would you agree? > Proposed text: > > OLD: "determine ways to optimise their behaviour." > NEW: "determine ways to optimise their behavior against a set of well-defined goals". Changed. Thanks. > In Sec. 3.2: > > "Conflict resolution between autonomic default behaviour and intent on one side ..." -- This may be confusing. Why doesn't _autonomic default behavior_ include intent? Please clarify. > > Given the implicit (now after your comments more explicit ;-) > node-centric approach adopted in this draft (see above) the following sentence is a bit contradictory, and I think inconsistent with the rest of the text: "Generally, autonomic mechanisms define a network wide behaviour, whereas the alternative methods are typically on a node by node basis." I don't understand your point here. Let me give you an example to illustrate our thinking: - default behaviour: a network uses ULA to address itself. - intent overrides this with "use prefix x instead". Both are network wide. Between autonomic default (1st line) and intent (2nd line) clearly, intent overrides (maybe should make this explicit?) Both can be overridden locally by someone configuring (any) other address on a particular box. In which case that overrides any autonomic approach (above lines). In the light of such an example, what is not clear about the above text? Please help me understand where we're confusing. > Then, "Node based management concepts take a higher priority over autonomic methods." But don't we refer to Autonomic Nodes? The point is that in practice you can also configure a node, in which case you need to say what takes precedence. You need to help me out here, to me this is completely obvious. > As the draft indicates, network operations tend to be manual/configuration-oriented as opposed to adopting well-defined algorithms for steering operation. Is operating an atomic plant less critical or less complex than operating a network? Some retrospective/discussion on earlier efforts in the autonomic networking practice would be valuable here. Can you suggest some examples? My fear is: Yes, we could add a lot of history, examples, discussion. But the document would quickly grow to 50+ pages if we're not careful. Frankly, I'd prefer to stick to the essentials and keep the document to the point. > In sec. 3.4: does the following maxim "If a problem can be solved in a distributed manner, it should not be centralised." belong to this draft? I think so. It clarifies what we're up to with this draft. This doesn't mean you can't do system autonomic (SDN like) approaches, and they make perfect sense for many tasks. But this draft isn't written for that world. And I think we want to be clear about that. And I say that exactly BECAUSE I get drawn into these debates all the time: "But also a controller based system can be autonomic". True, but this is system level, and this doc is just not focusing on that. There is no value statement here, btw. Both work. We choose to describe here the distributed approach. (And I hope we're making that clear). > In Sec. 3.6: the goal "optimize my network for energy efficiency" is not well-defined. Abstraction may it be, but it has to be measurable somehow. See proposed text above. It's an example. We're not defining here how to do it, nor how to measure it. Reading your comment I was about to define it, but frankly, I think this is a rat hole - because as soon as you write "overall power consumption has to be minimised" then questions on redundancy and reduced availability will pop up, with related exceptions, optimisations, etc. Please: Let's leave it as an example, to avoid ratholing, ok? ;-) Alternatively: Do you have a better example? > Also, it's not clear how this sentence "The administrator should not even be exposed to the version of the IP protocol running in the network." is related with "energy optimization". It isn't :-) I split those into two paragraphs, thanks for calling this out! :-) > In Sec. 3.9: Please add a couple of references/examples to better document the sentence "For example, layer 2 switching today is already relatively autonomic in many environments; routing functions can be autonomic." Done. Thanks. > - Section 4: In general this section needs further editing. First, the opening sentence ("This section identifies various items that are explicitly not design goals for autonomic networks, ...") is quite vague. For whom is this _not_ a design goal? NMRG? IRTF? IETF? Researchers? Practitioners? Engineers? Network operators? Protocol designers/implementers? In general, it is not clear whose anxieties does this section address by explicitly declaring non-goals. Second, are the following sentences really needed? It's in the context of IETF/IRFT (added), and I added some text there to clarify "They address some commonly expressed concerns from network administrators and architects." > * "(They should become more like doctors than hospital orderlies.)" > * "Truck rolls will not be eliminated when faulty equipment needs to be replaced." > * "Senior management might fear loss of control of an autonomic network." > > In general, is Section 4 needed in the first place? Isn't it better to define the goals clearly so that listing an arbitrary set of non-goals becomes redundant? Well, to be honest, I see those concerns raised a lot, and I think it adds value to address them here. > - Section 5: wrt Fig. 1, it's not clear why the "Autonomic Control Plane" is outside the "Standard Operating System Functions". Such an illustration somehow indicates that ACP is an add-on, as opposed to being part and parcel of an autonomic node. That's a good point. Long term you're of course right. We should have said "Current standard OS functions". > Editorial/Nits: > ----- > > In the beginning of Sec. 2, a sentence such as "This document uses the following terms:" would be nice to add. Done. (Already from your previous comments ;-) > s/mangaged./managed. > > s/self- managing,/self-managing, > > s/take place."/take place. > > s/outside scope/outside the scope > > respected‎ ??? > > s/(Section 3.5,/ (Section 3.5) All done, thanks! > Finally, there's no text adhering to RFC 5743, Sec. 2.1. It would be good to add in the next draft revision. I believe that will get added once there is consensus in the RG. Thanks for your detailed review again, and sorry for taking a long time to work on it! Maybe, if we're still not in agreement on some issues, we should discuss on the phone - might be easier. Michael > > > Best regards, > > Kostas > > > . > From nobody Fri Dec 12 10:55:11 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357B91A7020 for ; Fri, 12 Dec 2014 10:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 HDRa-F-o6Asu for ; Fri, 12 Dec 2014 10:55:07 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878341A88C2 for ; Fri, 12 Dec 2014 10:55:07 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id fp1so7622601pdb.19 for ; Fri, 12 Dec 2014 10:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o6eG+eq8wfN9aDBoMMZINCpIQiMyJnqmtTf7fBYzPHA=; b=H6jICQgGrZoNkS2PmSfsP+gdJGUhOmazqJwxk3e331dJH39bD4DA1LRY94zkgxNh9l BAXBwq+5uYoqcHulEovPPkCyxQNetwjARt9TUc7HZhdl1PkII/dtcgJzpSLZ22F4uybX DijN5zLtflDp4ZunMHO9aPQDVe25E4Ps7UhI6hR7Yv3Bw6LSN7WUkXu7wH2UPtJZdqYw JJhUxcLOsDRKk4ryVcs0ajxaQa7eMe85xLUT51dgNj4H05NlorAkx886P1f2aTVMRNRw C21Aj9W1XDhfctVQXWrZjsJ7wR6/06QW+MmyK6ilGATjyoUavlRFU5Fe+tW90Nf1ywib Z5Tw== X-Received: by 10.66.219.70 with SMTP id pm6mr29248649pac.126.1418410506821; Fri, 12 Dec 2014 10:55:06 -0800 (PST) Received: from [192.168.178.26] (235.231.69.111.dynamic.snap.net.nz. [111.69.231.235]) by mx.google.com with ESMTPSA id lz6sm2152432pdb.88.2014.12.12.10.55.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 10:55:05 -0800 (PST) Message-ID: <548B3A0E.8080401@gmail.com> Date: Sat, 13 Dec 2014 07:55:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Behringer References: <31F12CB7-2694-44EB-97AA-11FB863C173A@netapp.com> <20C63FF7-971B-4FA1-A935-CD26A50D0972@orandom.net> <548B187C.80508@cisco.com> In-Reply-To: <548B187C.80508@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/hnDo3nhW7IocRdQHr51dzGSOBXc Cc: draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org, nmrg@irtf.org, David R Oran Subject: Re: [nmrg] IRSG Review of NMRG document draft-irtf-nmrg-autonomic-network-definitions-04.txt X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 18:55:09 -0000 On 13/12/2014 05:31, Michael Behringer wrote: =2E.. >> P4 >> =E2=80=A2 You restrict the operation of autonomic networks to work= by >> pari-wise protocols.negotiations. In particular, you say >> =E2=80=A2 " peer-to-peer dialogues between the parties that m= ake up >> the closed loop. Such dialogues >> require two-way "discussion" or "negotiation" between each pair of=20 >> peers involved in the loop, so they cannot readily use typical >> top-down command-response protocols.between the parties that make up >> the closed loop. Such dialogues require two-way "discussion" or >> "negotiation" between each pair peers involved in the loop, so they >> cannot readily use typical top down command-response protocols.=E2=80=9D= >> =E2=80=A2 While you are quite explicit about this, I don=E2=80=99t= see any >> fundamental reason why the protocols and negotiations could not be >> multi-party, or exploit consensus protocols like Paxos. It=E2=80=99s p= robably >> OK to go ahead and not address this, but since it occurred to me it >> might also occur to other readers well-versed in distributed algorithm= s. >=20 > Very good point. Clarified that. Just a comment: multi-party protocols get very complex and in particular, guaranteed consensus or consensus within a defined time becomes challenging. In the context of an IETF protocol that can be extended piecemeal by a large variety of designers, restricting ourselves to two-party negotiation seems wise. Brian From nobody Fri Dec 12 14:25:00 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2961A1A34 for ; Fri, 12 Dec 2014 14:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 yIrGWFhecrwL for ; Fri, 12 Dec 2014 14:24:55 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818241A1BB9 for ; Fri, 12 Dec 2014 14:24:55 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kq14so8010394pab.6 for ; Fri, 12 Dec 2014 14:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ut4hS/UccMtjVKjJ8/eXP2sr53l/TY3sFXwXgHWg9Vg=; b=FoLzjUPsy5YrgKvQkm0A38srKLamVkQMzxubsgbQe49Z97dKLgk+1Ow7eqOUjXBal+ 0u9Lu5RggYevbCQFhpUbGyVETJPWgjdyUtA1EY3XeFRN8eNE4DybVI36YWYhkxFczSte KKc7yPM4q0OO6wEwVEilzmBX/g4zu5d6+xddJujC/gxiagaNvGeb3I/41OaZZVOy51bG bAY/DGyuDbKfkYzZmsKSpTsk/QOKNf6CLzU3N1hXZp3H/pNVyYP12a0i1r7EsVPmT83I bo92L/DzFB9z9RXzezkCe4o6GwtUWx1owpP5sPxVy0OKiDO8IHgTxvwtxc5zONwW+Ma6 8gvw== X-Received: by 10.70.5.68 with SMTP id q4mr30865916pdq.116.1418423094651; Fri, 12 Dec 2014 14:24:54 -0800 (PST) Received: from [192.168.178.26] (235.231.69.111.dynamic.snap.net.nz. [111.69.231.235]) by mx.google.com with ESMTPSA id o10sm81253pdr.96.2014.12.12.14.24.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 14:24:53 -0800 (PST) Message-ID: <548B6B41.6070805@gmail.com> Date: Sat, 13 Dec 2014 11:25:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nmrg@irtf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/yOVGVTYVhzAP40O2E10AJu1oS_A Subject: [nmrg] [Fwd: Re: Fwd: [irsg] IRSG Review for draft-irtf-nmrg-an-gap-analysis] X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 22:24:58 -0000 Forwarded to the group with permission: -------- Original Message -------- Subject: Re: Fwd: [irsg] IRSG Review for draft-irtf-nmrg-an-gap-analysis Date: Thu, 11 Dec 2014 11:27:36 +1300 From: Brian E Carpenter Organization: University of Auckland To: Lisandro Zambenedetti Granville , draft-irtf-nmrg-an-gap-analysis.all@tools.ietf.org, Lars Eggert , Kevin Fall Hi Kevin, and colleagues, A new version is posted at http://tools.ietf.org/html/draft-irtf-nmrg-an-gap-analysis-03 . >>> Data: 2 de dezembro de 2014 21:18:01 BRST >>> De: Kevin Fall >>> Para: "Eggert, Lars" >>> Cc: "Internet Research Steering Group \(irsg@irtf.org\)" >>> Assunto: Re: [irsg] IRSG Review for draft-irtf-nmrg-an-gap-analysis >>> >>> Hi. >>> I believe this document needs some work. My comments are here: Thanks for the very useful review. Where we don't think we have fully answered your point and/or we significantly disagree, there are comments below. No comment means we think we have fixed the point. >>> In section 3.1.1: >>> >>> >>> "originally" evidently takes us to a time after >>> subnetting had been established. But really, when we first had >>> these IP addresses, there weren't even these subnets. >>> >>> I wouldn't really agree that it is "difficult to separate IP address >>> management from DNS management". The management of the DNS >>> hierarchy in operation (delegations, servers, records, etc) >>> covers a lot more than the address assignment aspects. More >>> appropriate may be to say something such as "DNS mappings typically >>> need to be appropriately synchronized with IP address assignments". >>> >>> For the "address management tools", examples would help. >>> Some "tools" keep the addresses and DNS information already synchronized. >>> Also to say, "These are... centralised and far from autonomic type of >>> solution" seems unnecessarily perjorative. Is something like dnsmasq >>> "far from autonomic"? We draw a distinction between 'automatic' and 'autonomic', but anyway we have rephrased this, and added a reference to avoid duplicating discussion that's in an existing RFC. >>> The comment "how this topic is to be handled in home networks is still >>> an open question" should have some sort of reference describing the >>> issue. >>> >>> I am surprised to see no reference to RFC2462. I think it needs to be >>> discussed. RFC3041 also should receive some attention. Earlier, we had a short discussion of this topic that we removed, but now we have put something back in again, with current citations. >>> I find the last paragraph of this section needing attention. >>> Why is this DDNS capability a "complication"? What makes it >>> an "autonomic approach"? (i.e. to what? and versus what alternative?) >>> What are the "coexistence issues"? >>> >>> Section 3.1.2 >>> >>> There already existed dynamic routing within ARPANET in 1969. >>> See IEEE Trans on Communications Dec 1978. I believe the >>> comment of "as soon as the network was large enough for manual >>> configuration of routing tables to become difficult" in not >>> what happened. That comment is true and applicable, however, for DNS. >>> >>> There is, of course, much more one can say about routing but it may >>> not really be needed here. Recall there are things like ICMP redirects >>> and router discovery and NHRP that provide various amounts of >>> "autonomic" operation. True, but it does seem too detailed for this document. >>> Section 3.1.3 >>> >>> Again there is mention of issues wrt >1 prefix on the same subnet. >>> Please provide a reference for this. >>> >>> Section 3.1.4 >>> >>> Once again "originally" dates to when? I believe the use of hosts >>> goes back to HOSTS.TXT (see RFC 608), and I'm not at all certain it >>> was from a Unix machine this was generated. (possibly TOPS or Tenex or >>> maybe even MULTICS) >>> >>> This section should probably mention mDNS. >>> >>> Section 3.1.5 >>> >>> "early 1990s" -> "the early 1990s" >>> >>> Section 3.1.6 >>> >>> I suspect there is much more to say here, for example the whole >>> area of IPS systems. >>> >>> Does privacy belong in this section? Is something like Tor autonomic? It's hard to say anything specific about privacy. One could imagine "Forbid Tor" or "Use Tor" as policy items. Anyway, we have slightly expanded this section. >>> Section 3.1.7 >>> >>> >>> "Without any overall controller being involved" seems unclear. >>> Given that time servers are involved, what is this trying to say precisely? >>> >>> The section title seems to broad. For example, distributed routing >>> is "merely" a type of "synchronization", right? Even parts of >>> routing (leader election) and failover (VRRP) do such things. >>> >>> Section 3.1.8 >>> >>> >>> This seems like a bit of a manifesto statement. I'm not sure why >>> it would be under the subsection titled "Miscellaneous". Correct. We moved the material to a later section. >>> Section 3.2.1 >>> >>> Please define 'Network establishment'. >>> Does 'architecture' here refer to deployment architecture? It doesn't >>> appear to mean protocol architecture. >>> >>> Section 3.2.2 >>> >>> Please include a reference to support the comment that "This is the >>> source of most network configuration errors." Couldn't exactly do that, but we have improved the logic. >>> The comment regarding SDN requires some justification or reference if >>> it stays in. >>> >>> Section 4.1 >>> >>> I think the assertion that all the existing/prior work on protocols >>> that support discovery, synchronization or negotiation are too specific >>> requires some support. This point has a whole section to itself in one of the Anima WG submissions, so it seemed better to simply remove it here. >>> Section 4.2 >>> >>> So what do you think of efforts like BEEP, TLS, SASL? How does these >>> fail to be what you are after? How about NHDP? Same comment - analysing existing protocols is a job for Anima. >>> Section 4.3 >>> >>> This seems to wander and isn't very specific. It basically seems >>> to say that you need to be secure. Is that all there is to it? Well, it also says that we need to identify the autonomic control plane in its own right. We tried to tighten up the language. >>> Section 4.4 >>> >>> The first paragraph makes a number of claims without reference. >>> Supporting reference or evidence should be mentioned. >>> >>> >>> Section 4.5 >>> >>> I don't understand this section. In particular, I do not see why >>> 'autonomic networking' has any different sort if trades than >>> normal networking with respect to testing and experimentation. >>> We use simulation and emulation and live testing already. What >>> is different here? "a configuration change could be tested out in the control plane without actually affecting the data plane." It's true that such a dry run mode could be implemented in a conventional network management model such as NETCONF, but in an autonomic setup it would be part of a closed loop, not involving the NMS or the operator. It's the closed loop that makes it different. >>> >>> Section 4.6 >>> >>> >>> Perhaps a philosophical point, but I do not agree with the statement: >>> "The more knowledge we have, the more intelligent we are." >>> (see, for example: >>> https://philosophynow.org/issues/98/Information_Knowledge_and_Intelligence) Rewritten a bit. Thanks again Brian, Michael, Sheng From nobody Tue Dec 16 00:08:00 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117081ACD49 for ; Tue, 16 Dec 2014 00:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 B3-HVjJMqVPa for ; Tue, 16 Dec 2014 00:07:56 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C93D1ACD47 for ; Tue, 16 Dec 2014 00:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3342; q=dns/txt; s=iport; t=1418717275; x=1419926875; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hhgyKUp+gfcgcF9CsyNVjXtSOXukHeyDDq2FqrpvJyo=; b=gn3CyFrRuMmlBy6zfH1kpyjRN5+XplXFwLa+wTKhAMqFInzAzzd80Wzj 7yrZD4N9q+2iQM8iYa64Y8EC9Q1arABYziwOhaKE2pD+V8hp5ZOQj/zGV Hqe3cYrRD41YRj1qdh2NkGibrx6fm6BAknnFuI8lqNQLyHgUNDbwC2HDG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAGADboj1StJssW/2dsb2JhbABag1hTBQSDAsBLgiWFcgIcgRQBAQEBAX2EDAEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCAGIIwgFvVyWdQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIY4gOAaCYi6BEwWOAoM+hjwwgi6NUCKBfDSBPG6BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,585,1413244800"; d="scan'208";a="271883895" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 16 Dec 2014 08:07:53 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBG87orq002233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Dec 2014 08:07:51 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.83]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 02:07:50 -0600 From: "Michael Behringer (mbehring)" To: "nmrg@irtf.org" Thread-Topic: New Version Notification for draft-irtf-nmrg-autonomic-network-definitions-05.txt Thread-Index: AQHQGQb8fb33euNgP0mA5tLCP1QVz5yR3C3g Date: Tue, 16 Dec 2014 08:07:49 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21D1D0D7@xmb-rcd-x14.cisco.com> References: <20141216080443.29279.27207.idtracker@ietfa.amsl.com> In-Reply-To: <20141216080443.29279.27207.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/NdeViB7q7vfqeIcE94iT770wMxs Subject: [nmrg] FW: New Version Notification for draft-irtf-nmrg-autonomic-network-definitions-05.txt X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 08:07:58 -0000 VGhpcyBpcyB0aGUgbmV3IHZlcnNpb24gb2YgdGhlIEF1dG9ub21pYyBOZXR3b3JraW5nIERlZmlu aXRpb25zIGRyYWZ0LiBJdCBjb250YWlucyBhIG51bWJlciBvZiBjbGFyaWZpY2F0aW9ucyBhbmQg ZWRpdG9yaWFsIGNoYW5nZXMuIFdlIGJlbGlldmUgaXQgYWRkcmVzc2VzIHRoZSBvdXRzdGFuZGlu ZyBpc3N1ZXMgcmFpc2VkIGR1cmluZyBJUkZUIGxhc3QgY2FsbC4gDQoNCk1pY2hhZWwNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IDE2IERlY2VtYmVy IDIwMTQgMDk6MDUNCj4gVG86IExhdXJlbnQgQ2lhdmFnbGlhOyBNYXggUHJpdGlraW4gKHByaXRp a2luKTsgTGF1cmVudCBDaWF2YWdsaWE7IEFsZXhhbmRlcg0KPiBDbGVtbSAoYWxleCk7IEJyaWFu IEUuIENhcnBlbnRlcjsgU2hlbmcgSmlhbmc7IFN0ZWludGhvciBCamFybmFzb24NCj4gKHNiamFy bmFzKTsgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsgTWF4IFByaXRpa2luIChwcml0aWtp bik7IFN0ZWludGhvcg0KPiBCamFybmFzb24gKHNiamFybmFzKTsgTWljaGFlbCBCZWhyaW5nZXIg KG1iZWhyaW5nKTsgQnJpYW4gQ2FycGVudGVyOw0KPiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpOyBT aGVuZyBKaWFuZw0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWlydGYtbm1yZy1hdXRvbm9taWMtbmV0d29yay0NCj4gZGVmaW5pdGlvbnMtMDUudHh0DQo+IA0K PiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlydGYtbm1yZy1hdXRvbm9taWMtbmV0 d29yay1kZWZpbml0aW9ucy0wNS50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBNaWNoYWVsIEJlaHJpbmdlciBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRv cnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmlu aXRpb25zDQo+IFJldmlzaW9uOgkwNQ0KPiBUaXRsZToJCUF1dG9ub21pYyBOZXR3b3JraW5nIC0g RGVmaW5pdGlvbnMgYW5kIERlc2lnbiBHb2Fscw0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTEyLTE2 DQo+IEdyb3VwOgkJbm1yZw0KPiBQYWdlczoJCTE2DQo+IFVSTDogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pcnRmLW5tcmctYXV0b25vbWljLQ0K PiBuZXR3b3JrLWRlZmluaXRpb25zLTA1LnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy0NCj4gbmV0 d29yay1kZWZpbml0aW9ucy8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlydGYtbm1yZy1hdXRvbm9taWMtbmV0d29yay0NCj4gZGVmaW5pdGlvbnMt MDUNCj4gRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlydGYtbm1yZy1hdXRvbm9taWMtDQo+IG5ldHdvcmstZGVmaW5pdGlvbnMtMDUNCj4gDQo+ IEFic3RyYWN0Og0KPiAgICBBdXRvbm9taWMgc3lzdGVtcyB3ZXJlIGZpcnN0IGRlc2NyaWJlZCBp biAyMDAxLiAgVGhlIGZ1bmRhbWVudGFsIGdvYWwNCj4gICAgaXMgc2VsZi1tYW5hZ2VtZW50LCBp bmNsdWRpbmcgc2VsZi1jb25maWd1cmF0aW9uLCBzZWxmLW9wdGltaXphdGlvbiwNCj4gICAgc2Vs Zi1oZWFsaW5nIGFuZCBzZWxmLXByb3RlY3Rpb24uICBUaGlzIGlzIGFjaGlldmVkIGJ5IGFuIGF1 dG9ub21pYw0KPiAgICBmdW5jdGlvbiBoYXZpbmcgbWluaW1hbCBkZXBlbmRlbmNpZXMgb24gaHVt YW4gYWRtaW5pc3RyYXRvcnMgb3INCj4gICAgY2VudHJhbGl6ZWQgbWFuYWdlbWVudCBzeXN0ZW1z LiAgSXQgdXN1YWxseSBpbXBsaWVzIGRpc3RyaWJ1dGlvbg0KPiAgICBhY3Jvc3MgbmV0d29yayBl bGVtZW50cy4NCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBjb21tb24gbGFuZ3VhZ2Us IGFuZCBvdXRsaW5lcyBkZXNpZ24gZ29hbHMgYW5kDQo+ICAgIG5vbi1kZXNpZ24gZ29hbHMgZm9y IGF1dG9ub21pYyBmdW5jdGlvbnMuICBBIGhpZ2ggbGV2ZWwgcmVmZXJlbmNlDQo+ICAgIG1vZGVs IGlsbHVzdHJhdGVzIGhvdyBmdW5jdGlvbmFsIGVsZW1lbnRzIGluIGFuIGF1dG9ub21pYyBuZXR3 b3JrDQo+ICAgIGludGVyYWN0Lg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Dec 16 16:34:51 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C691ACD50; Tue, 16 Dec 2014 00:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 2fa2ii_6rS3Q; Tue, 16 Dec 2014 00:04:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4591ACD47; Tue, 16 Dec 2014 00:04:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141216080443.29279.96949.idtracker@ietfa.amsl.com> Date: Tue, 16 Dec 2014 00:04:43 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/cnBaJYV057nGvRkY6qtU9DnNv4o X-Mailman-Approved-At: Tue, 16 Dec 2014 16:34:50 -0800 Cc: nmrg@irtf.org Subject: [nmrg] I-D Action: draft-irtf-nmrg-autonomic-network-definitions-05.txt X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 08:04:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Management Working Group of the IETF. Title : Autonomic Networking - Definitions and Design Goals Authors : Michael Behringer Max Pritikin Steinthor Bjarnason Alexander Clemm Brian Carpenter Sheng Jiang Laurent Ciavaglia Filename : draft-irtf-nmrg-autonomic-network-definitions-05.txt Pages : 16 Date : 2014-12-16 Abstract: Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements. This document defines common language, and outlines design goals and non-design goals for autonomic functions. A high level reference model illustrates how functional elements in an autonomic network interact. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definitions-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 17 20:36:03 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CC51A0195 for ; Wed, 17 Dec 2014 20:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.55 X-Spam-Level: ** X-Spam-Status: No, score=2.55 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=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 Z4XBeUxLH9T0 for ; Wed, 17 Dec 2014 20:35:59 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7BE1A0197 for ; Wed, 17 Dec 2014 20:35:59 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kq14so586288pab.6 for ; Wed, 17 Dec 2014 20:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=cZ1v3ruBMB5krJPjceDiWUkgUIw/48XxIjGEvDhklU8=; b=ONE/k0W3HVV1PROTqgHvDhP50wuSHTE0aT3dCcPEvsNJM881chaa6hYzAeTTLVmuIK jrP/F06e0DxPskoSN1OoFOeepV1AD4/OeTWF722xgl4rVOSYf5tCrAhuHNKp1Uzk4vJb B1b5K3a5jf+Ia7QqOn+bCQOkf7YtH1qSmrngvEav4baz8RLP4GK+dXMnjlJ/cb6AB5/k FDC+ENdZFkTk4vWOO8Gjff1xy0dAwCNFdrO2dBJYXvFjZMu7+RJeiur8EMtr2TNnhoMZ f1rDCksqvlkNfvKznGMa29ZYUYqHGGj9LMVG4lKCeiRB1flbE15WhDyMz4uM+wSztKWO wM/Q== X-Received: by 10.66.140.76 with SMTP id re12mr73989490pab.147.1418877358835; Wed, 17 Dec 2014 20:35:58 -0800 (PST) Received: from ChrisTHINK ([222.175.103.17]) by mx.google.com with ESMTPSA id nk6sm5295913pdb.89.2014.12.17.20.35.55 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Dec 2014 20:35:58 -0800 (PST) From: "Chris-Lei.Liu" To: Date: Thu, 18 Dec 2014 12:35:47 +0800 Message-ID: <00d301d01a7c$1fb1fe90$5f15fbb0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdAafBgUemWsMWqJSQ2mPjZ1DFSkUA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/H-ncj401-sG89jxL0vvispQwWz8 Subject: [nmrg] CFP: FCST2015, Dalian, China, August 26-28, 2015 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 04:36:02 -0000 Please accept our apologies if you receive multiple copies of this CFP. *********************** FCST 2015 CFP ************************* ============================================================== The 9th International Conference on Frontier of Computer Science and Technology (FCST 2015) http://ncc.dlut.edu.cn/~fcst2015/index.html Dalian, China, August 26-28, 2015 ============================================================= ----------------- Important Dates ----------------- Workshop proposal submission deadline: April 15th, 2015 Workshop proposal decision to organizers: May 15th, 2015 Paper submission deadline: April 15th, 2015 Paper decision to authors: June 15th, 2015 Camera ready deadline: June 30th, 2015 Registration deadline: June 30th, 2015 --------------------------------- Paper Submission and Publication --------------------------------- Submissions must include an abstract, keywords, the e-mail address of the corresponding author and should not exceed 8 pages for main conference, including tables and figures in IEEE CS format. The template files for LATEX or WORD can be downloaded from the follwing link: http://www.ieee.org/conferences_events/conferences/publishing/templates.html All paper submissions must represent original and unpublished work. Each submission will be peer reviewed by at least three program committee members. Submission of a paper should be regarded as an undertaking that, should the paper be accepted, at least one of the authors will register for the conference and present the work. Submit your paper(s) at the submission site: https://easychair.org/conferences/?conf=fcst20150 Around 30 accepted and presented papers will be published directly by SCI or EI journals, other accepted and presented papers will be published in conference proceedings. ============================================================== --------------------------------- Introduction --------------------------------- Frontier of computer science and technology is intended to facilitate effective communication and exchanges all of the world. It will not only reflect the significant advances that are currently being made in computer science and technology, but also represent a powerful and unique forum for discussing innovative, cutting-edge advances in all aspects of computer science and technology from researchers and practitioners in academia, government and corporate institutions around the globe. FCST2015 is an international forum for presenting and discussing emerging ideas and trends in the frontier of computer science and technology from both the research community as well as the industry. ------------------- Topics ------------------- Topics of particular interest include, but are not limited to: Track 1. Parallel and Distributed Computing - Parallel/Distributed Architectures - Heterogeneous and Multimedia Systems - Ubiquitous Computing Systems and Cloud/Grid Computing Systems - Real-Time Parallel and Distributed Systems - Multi-Core Programming and Software Tools - Agent Technologies - Parallel and Distributed Operating Systems and Middleware - Parallel Languages and Compilers - Parallel and Distributed Applications and Web Services - Parallel I/O Systems and Storage Systems - Tools and Environments for Parallel & Distributed Software Development - Software and Hardware Reliability, Testing, Verification and Validation - Analysis and Design of Parallel and Distributed Algorithms - Task Mapping and Job Scheduling - Distributed Data and Knowledge Based Systems - Distributed Graphics and VR/AR/MR System - Distributed AI and Soft/Natural Computing - Distributed Scheduling and Load Balancing - High-Performance Scientific Computing - Resource Allocation and Management - Network Routing and Communication Algorithms - Bioinformatics in Parallel Computing - Security in Parallel and Distributed Systems - Self-Healing, Self-Protecting, Reliability, and Fault-Tolerant Systems - Cluster Computing - Wireless Sensor Networks and Mobile Computing- Track 2. Trust, Security and Privacy - Trust Semantics, Metrics, and Models - Trusted Computing Platform - Risk and Reputation Management - Reliability, Dependability, and Fault Tolerance - Authentication, Authorization, and Accountability - Security Policy, Model, and Architecture - Access Control, Intrusion Detection, Firewalls, and Packet Filters - Applied Cryptography - Embedded Systems Security - Distributed Denial of Service, Malware, and Botnets - Secure Routing, Naming/Addressing, and Network Management - Privacy and Anonymity - Information Hiding - Security & Privacy in Database Systems - Security & Privacy in Parallel and Distributed Systems - Security & Privacy in Web Applications - Security & Privacy in Electronic Payments - Security & Privacy in Wired, Wireless, Mobile, Hybrid, Sesor, and Ad Hoc Networks - Trust, Security and Privacy in Cloud computing, Social Networks, and Internet of Things - Security and Trustworthy Computing- Track 3. Automation and Control Engineering - Automatic Control Systems - Control Theory and Control Engineering - Detection Technology and Automatic Equipment - E-commerce and e-Government - Electric Automation - Fuzzy Control and Fuzzy System - Factory Modeling and Simulation - Fault Diagnosis - Industrial Automation - Logistics and Supply Chain - Management Information System - Mechatronics and Robotics - Neuro Control - Office Automation - Process Control - Sensor and detection technology - System Modeling and Simulation Techniques - Transport Control Theory And Methodologies- Track 4. Pattern Recognition and Artificial Intelligence - Statistical and Structural Pattern Recognition - Machine Learning and Data Mining - Applications of Pattern Recognition - Computer Vision - Image Recognition, Analysis, Understanding, and Processing - Multimedia and Document Analysis, Processing and Retrieval - Biometrics and Human Computer Interaction - Pattern Recognition Theory and Methods - Evolutionary Computation - Multidisciplinary Artificial Intelligence - Intelligent Interfaces - Intelligent Robotics - Digital Signal Processing - Multidimensional Signal Processing - Statistical Signal Processing - Time-Frequency Signal Analysis - Mobile Signal Processing- Track 5. Multimedia Systems and Networks - Multimedia Fusion - Multimedia Data Management Systems and Applications - 3D Representation/Recognition/Retrieval - Digital Signal Processing Techniques and Applications - Multi-Core and Many-Core Architectures in Multimedia Systems - Integration of Content, Meta Data, and Social Networks - Computer Graphics - Networked GPUs, Graphics, and Virtual Environments - Networked Games/Real-Time Immersive Systems - Multimedia Network Architectures and Protocols - Network Security and Safety - QoS Issues in Multimedia Services and Applications - Cloud-Based Multimedia Delivery - Biomedical Signal Processing and Systems - Social Media as Sensors - Multimedia Applications on Mobile Devices - Digital Home Technology and Services - Web 2.0 Systems and Social Networks - Audio and Video-On-Demand - Video Processing and Communications - Pattern Recognition and Artificial Intelligence - Computer Graphics and Human-Computer Interaction- Track 6. Embedded Computing and Systems - Embedded System Architectures - Embedded Networks and Communication Systems - Embedded and Ubiquitous Computing - Embedded Applications - Embedded Real-Time Systems - Embedded System Software - Embedded Software Engineering - Embedded Database and Multimedia Systems - Embedded Hardware Platforms and Technologies - Embedded Hardware/Software Co-Design - Embedded Circuit and Multi-Core Technologies - Embedded Systems Security and Reliability - Embedded Low-Power Systems - Embedded Systems QoS Management - Embedded Systems Modeling and Analysis - Embedded Micro Internetworking Technology- Track 7. Emerging Software Techniques - Software Architecture and Software Engineering Models - Requirement Engineering and Requirement Elicitation - Software Components and Reuse - New Software Development Platform and Ecological Construction - New Software Development Languages - Software Testing, Analysis, and Verification - Software Configuration Management and Deployment - Agile Software Development Methodologies and Practices - Software Projects and Software Quality Management - Software Products and Process Improvement - Software Measurement and Metrics - Engineering Safety and Security in Critical Software - Software Optimization, Formal Methods, and Tools - Software Evolution Techniques - Intelligent Software Systems Design - Software Techniques for Mobile, Ubiquitous, and Cloud Computing Systems - Empirical Software Engineering - Evidence-Based Software Engineering- Track 8. Applications, Business and Social Issues - Business Ontologies and Models - Digital Goods and Services - Electronic Service Delivery - E-Marketing - Languages for Describing Goods and Services - Online Auctions and Technologies - Virtual Organizations and Teleworking- Track 9. CPS and Internet of things - Access Network Technologies - Network, Communication Systems and System Architectures - Risk, Security and privacy - Location, Searching and Discovery - Real-time Communication and Collaboration for Smart things - Sensor Networking Technologies (e.g., RFID, WSN) - Web of Things - CPS(Cyber, Physical and Social) Technologies - Modeling and Simulation tools and Technologies - Case Studies in Areas of Smart Grid, Healthcare, Agriculture, Logistics, Environmental - monitoring and Transport, etc - Emerging IoT Business Models and Process Changes - Social Networking and Computing --------------------- Organizing Committee --------------------- == General Chairs== Xiaohua Jia, City University of Hong Kong, Hong Kong Tharam Dillion, Latrobe University, Australia Kuan Ching Li, Providence University, Taiwan == Program Chairs == Nei Kato, Tohoku University, Japan Kui Wu, University of Victoria, Canada == Workshop Chairs == Tingting Yang, Dalian Maritime University, Dalian, China Mianxiong Dong, National Institute of Information and Communications Technology, Japan == Publicity Chairs == Al-Sakib Khan Pathan, International Islamic University of Malaysia, Malaysia Mohammad Mehedi Hassan, King Saud University, Saudi Arabia Lei Liu, Shandong University, China == Organizing Chair == Yong Zhang, Liaoning Normal University, Dalian, China == Finance Chair == Rui Kou, Dalian University of Technology, Dalian, China == Registration Chair == Kai Lin, Dalian University of Technology, Dalian, China == Web Chair == Pengfei Lu, Dalian University of Technology, Dalian, China == Program Committee == See FCST-2015 web site: http://ncc.dlut.edu.cn/~fcst2015/ -------------------- Contact Information -------------------- If you have any question about the CFP and paper submission, please email to fcst2015@gmail.com.