From nobody Mon Dec 1 20:05:42 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580CF1A00CA for ; Mon, 1 Dec 2014 20:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 xVsSiOzFtIS8 for ; Mon, 1 Dec 2014 20:05:36 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FDA1A00D8 for ; Mon, 1 Dec 2014 20:05:35 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so7710308wgh.36 for ; Mon, 01 Dec 2014 20:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mb5110dJCEvwuYfvBeaEPgRZ+QhSFFKZLEu5hMvlZ6g=; b=CWCw3tM6CRbalWK6ihRDUfVJXd2RkEJPLrvLnm1z2yKcHfJMNZ8UA9xPx/I2rr2YOD b3AFulxsw80tc5H8NNPwqE1eI70VXz8d/lhJ64l3J/9KKgV//Yl/Ey5pon2+GKBof0hY ih++lI1wFh/u8tThAJiLHpc2N7YgfQ8Ug4hEezY0cZAJwnDVnF4dHQ5eT5x2PlQ/fxOh IF6DKH6CpJHHWFjGN/fBvjRJIVz0I1JM0Be+uNLD36saDWR1vLK+8d0gsGGaBXSR+UbR aqVKvhZ13hriENFN8eSxdYO+/gaqnpe8lwMCPn/8bi4JMusP9FWtiHvaG7u/yGo5q5Bc gp1g== MIME-Version: 1.0 X-Received: by 10.194.108.162 with SMTP id hl2mr15189637wjb.102.1417493134737; Mon, 01 Dec 2014 20:05:34 -0800 (PST) Received: by 10.194.11.41 with HTTP; Mon, 1 Dec 2014 20:05:34 -0800 (PST) Date: Mon, 1 Dec 2014 20:05:34 -0800 Message-ID: From: Hazel Ann To: manet@ietf.org Content-Type: multipart/alternative; boundary=089e0102f212c486f2050933d6c3 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/C24vGbAABy144bbC-S2t_g52KbM Subject: [manet] Deadline Approaching::EBECEGC2015::Dubai, UAE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 04:05:40 -0000 --089e0102f212c486f2050933d6c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The International Conference on Electrical and Bio-medical Engineering, Clean Energy and Green Computing (EBECEGC2015) January 28-30, 2015 =C2=BB Dubai, UAE http://sdiwc.net/conferences/ebecegc2015/ ebecegc15@sdiwc.net All registered papers will be included in SDIWC Digital Library =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The conference aims to enable researchers build connections between different digital applications. The event will be held over three days, with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. RESEARCH TOPICS ARE NOT LIMITED TO: ***Electrical/ Bio-medical Engineering -Robotics and Atomization Engineering -Signal Integrity Design for High-Speed Digital Systems -Speech Recognition, Analysis and Synthesis -Mobile Communication Technology and Wireless Sensor Networks -Computer-Aided Surgery -Data Compression and Watermarking -Health Care Information Systems -Healthcare Information Systems, Telemedicine -Image Processing -Information Security and Cryptography -Expert Systems Internet and Web Solutions for Healthcare -Mobile Computing and Security -Modeling, Simulation, Systems and Control -Modulation, Coding, and Channel Analysis -Multimedia Signal Processing -Natural Language Processing -Neural Networks -Parallel Programming & Processing -Artificial Intelligence -Pattern Analysis for Biomedical applications -Neuroimaging -Biochemical Engineering and Applications -Bio-medical Electronics -Computer Aided and Automated Diagnosis -Brain-Computer Interfaces -Nanotechnology for Biomedical Applications -Bionics and Biological Cybernetics -Bioinformatics & Biomedical Imaging -Biomedical Signal Processing -Brain-Computer Interfacing and Human=E2=80=93Computer -Interfacing -Bioinstrumentation: Sensors, Micro, Nano and Wearable Technologies ***Clean Energy/Green Computing -Biofuel and Energy from Waste Materials -Bioinformatics and Scientific Computing -Climate and Eco System Monitoring -Data Modeling for Cloud-Based Networks -Efficient Energy generation and distribution -Electrical Vehicles and Smart Grid -Energy Efficiency -Energy Minimization in Cluster-Based Wireless Sensor Networks -Energy Usage of High Performance System -Energy and Environmental Sustainability in Information Systems and Network -Hydrogen and Energy Storage -Life Cycle Analysis of IT Equipment -Low-power Electronics and Systems -Memory Energy Optimizations in Smartphones -Power Efficient Hardware -Power and Energy Profiling and Metrics -Power-Aware Algorithms and Protocols -Power-Aware Software and Hardware -Reducing Energy Consumption in Wireless Sensor Network -Renewable Energy and Transport -Renewable Energy models and Prediction -Smart Grids and Micro Grids -Smart Transportation and Manufacturing -Smart Buildings and Urban Development -Solar Power Generation -Thermal-Aware Power Optimization Techniques for Servers and Data Centers -Using IT to reduce Carbon Emissions -Wind Power Generation -Wind, Wave, and Solar Energy -Zero Carbon Urban design Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Best selected papers will be published in one of the following special issues provided that the author do major improvements and extension within the time frame that will be set by the conference and his/her paper is approved by the chief editor: International Journal of New Computer Architectures and their Applications (IJNCAA) International Journal of Digital Information and Wireless Communications (IJDIWC) International Journal of Cyber-Security and Digital Forensics (IJCSDF) International Journal of E-Learning and Educational Technologies in the Digital Media (IJEETDM) PAPER SUBMISSION GUIDELINES: - Researchers are encouraged to submit their work electronically. Full paper must be submitted (Abstracts are not acceptable). - Submitted paper should not exceed 15 pages, including illustrations. All papers must be without page numbers. - Papers should be submitted electronically as pdf format without author(s) name. - Paper submission link: http://sdiwc.net/conferences/ebecegc2015/openconf/openconf.php IMPORTANT DATES: Submission Deadline The submission is open from now until Jan. 08, 2015 Notification of Acceptance 2-3 weeks from the submission date Camera Ready Submission Open from now until Jan. 18, 2015 Registration Deadline Open from now until Jan. 18, 2015 Conference Dates January 28-30, 2015 --089e0102f212c486f2050933d6c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The International Conference on Electrical and Bio= -medical Engineering,=20 Clean Energy and Green Computing (EBECEGC2015)

January 28-30, 2015 =C2=BB Dubai, UAE

http:/= /sdiwc.net/conferences/ebecegc2015/

ebecegc15@sdiwc.net

All registered papers will be included in SDIWC Digital Library
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The conference aims to enable researchers build connections between=20 different digital applications. The event will be held over three days,=20 with presentations delivered by researchers from the international=20 community, including presentations from keynote speakers and=20 state-of-the-art lectures.

RESEARCH TOPICS ARE NOT LIMITED TO:

***Electrical/ Bio-medical Engineering
-Robotics and Atomization Engineering
-Signal Integrity Design for High-Speed Digital Systems
-Speech Recognition, Analysis and Synthesis
-Mobile Communication Technology and Wireless Sensor Networks
-Computer-Aided Surgery
-Data Compression and Watermarking
-Health Care Information Systems
-Healthcare Information Systems, Telemedicine
-Image Processing
-Information Security and Cryptography
-Expert Systems=C2=A0=C2=A0=C2=A0 Internet and Web Solutions for Health= care
-Mobile Computing and Security
-Modeling, Simulation, Systems and Control
-Modulation, Coding, and Channel Analysis
-Multimedia Signal Processing
-Natural Language Processing
-Neural Networks
-Parallel Programming & Processing
-Artificial Intelligence
-Pattern Analysis for Biomedical applications
-Neuroimaging
-Biochemical Engineering and Applications
-Bio-medical Electronics
-Computer Aided and Automated Diagnosis
-Brain-Computer Interfaces
-Nanotechnology for Biomedical Applications
-Bionics and Biological Cybernetics
-Bioinformatics & Biomedical Imaging
-Biomedical Signal Processing
-Brain-Computer Interfacing and Human=E2=80=93Computer
-Interfacing
-Bioinstrumentation: Sensors, Micro, Nano and Wearable Technologies

***Clean Energy/Green Computing
-Biofuel and Energy from Waste Materials
-Bioinformatics and Scientific Computing
-Climate and Eco System Monitoring
-Data Modeling for Cloud-Based Networks
-Efficient Energy generation and distribution
-Electrical Vehicles and Smart Grid
-Energy Efficiency
-Energy Minimization in Cluster-Based Wireless Sensor Networks
-Energy Usage of High Performance System
-Energy and Environmental Sustainability in Information Systems and=20 Network
-Hydrogen and Energy Storage
-Life Cycle Analysis of IT Equipment
-Low-power Electronics and Systems
-Memory Energy Optimizations in Smartphones
-Power Efficient Hardware
-Power and Energy Profiling and Metrics
-Power-Aware Algorithms and Protocols
-Power-Aware Software and Hardware
-Reducing Energy Consumption in Wireless Sensor Network
-Renewable Energy and Transport
-Renewable Energy models and Prediction
-Smart Grids and Micro Grids
-Smart Transportation and Manufacturing
-Smart Buildings and Urban Development
-Solar Power Generation
-Thermal-Aware Power Optimization Techniques for Servers and Data=20 Centers
-Using IT to reduce Carbon Emissions
-Wind Power Generation
-Wind, Wave, and Solar Energy
-Zero Carbon Urban design

Researchers are encouraged to submit their work electronically. All=20 papers will be fully refereed by a minimum of two specialized referees.=20 Before final acceptance, all referees comments must be considered.

Best selected papers will be published in one of the following special
issues provided that the author do major improvements and extension=20 within
the time frame that will be set by the conference and his/her paper is
approved by the chief editor:

International Journal of New Computer Architectures and their=20 Applications (IJNCAA)
International Journal of Digital Information and Wireless Communication= s=20 (IJDIWC)
International Journal of Cyber-Security and Digital Forensics (IJCSDF)
International Journal of E-Learning and Educational Technologies in the= =20 Digital Media (IJEETDM)

PAPER SUBMISSION GUIDELINES:

- Researchers are encouraged to submit their work electronically. Full= =20 paper must be submitted (Abstracts are not acceptable).
- Submitted paper should not exceed 15 pages, including illustrations.= =20 All papers must be without page numbers.
- Papers should be submitted electronically as pdf format without=20 author(s) name.
- Paper submission link:=20 http://sdiwc.net/conferences/ebecegc2015/openconf/openconf.php

IMPORTANT DATES:

Submission Deadline=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The submi= ssion is open from now until Jan. 08, 2015
Notification of Acceptance=C2=A0=C2=A0=C2=A0 2-3 weeks from the submiss= ion date
Camera Ready Submission=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Open = from now until Jan. 18, 2015
Registration Deadline=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Open fr= om now until Jan. 18, 2015
Conference Dates=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 January 28-3= 0, 2015=C2=A0
--089e0102f212c486f2050933d6c3-- From nobody Tue Dec 2 12:13:02 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94CF1A7017 for ; Tue, 2 Dec 2014 12:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 r_-RdZK8HsDI for ; Tue, 2 Dec 2014 12:12:39 -0800 (PST) Received: from CERNMX13.cern.ch (cernmx13.cern.ch [188.184.36.46]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B46B1A1B19 for ; Tue, 2 Dec 2014 12:11:20 -0800 (PST) Received: from cernfe06.cern.ch (188.184.36.49) by cernmxgwlb4.cern.ch (188.184.36.46) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 2 Dec 2014 21:11:18 +0100 Received: from CERNXCHG74.cern.ch ([fe80::41a8:3197:d315:6bd3]) by CERNFE06.cern.ch ([fe80::64b8:95fa:42bc:1ef5%11]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 21:11:18 +0100 From: Ashiq Anjum To: "manet@ietf.org" Thread-Topic: Final Call for Participation: UCC 2014 London UK Thread-Index: AQHQDmpWIbMo7iUg1kuSDqEv40m2pZx8t/xhgAAAJGqAAABAXoAAACvagAAAONWAAAA1WYAAACdTgAAAXh6AAABGlYAAAFDkgAAARYc= Date: Tue, 2 Dec 2014 20:11:17 +0000 Message-ID: <38B80DE7DF51A943BD4434E10300831491A0028D@CERNXCHG74.cern.ch> References: <38B80DE7DF51A943BD4434E10300831491A000CF@CERNXCHG74.cern.ch>, <38B80DE7DF51A943BD4434E10300831491A000DC@CERNXCHG74.cern.ch>, <38B80DE7DF51A943BD4434E10300831491A00102@CERNXCHG74.cern.ch>, <38B80DE7DF51A943BD4434E10300831491A00127@CERNXCHG74.cern.ch>, <38B80DE7DF51A943BD4434E10300831491A0014B@CERNXCHG74.cern.ch>, <38B80DE7DF51A943BD4434E10300831491A00177@CERNXCHG74.cern.ch>, <38B80DE7DF51A943BD4434E10300831491A00184@CERNXCHG74.cern.ch>, <38B80DE7DF51A943BD4434E10300831491A001A9@CERNXCHG74.cern.ch>, <38B80DE7DF51A943BD4434E10300831491A001BA@CERNXCHG74.cern.ch>, <38B80DE7DF51A943BD4434E10300831491A001C7@CERNXCHG74.cern.ch>, <38B80DE7DF51A943BD4434E10300831491A0021E@CERNXCHG74.cern.ch> In-Reply-To: <38B80DE7DF51A943BD4434E10300831491A0021E@CERNXCHG74.cern.ch> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [195.194.178.2] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/eU06y37lRO6J-QkMIy1XMOnmO5Y Subject: [manet] Final Call for Participation: UCC 2014 London UK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 20:12:49 -0000 Dear All,=0A= =0A= The final conference programme for UCC 2014, being held in London from Dece= mber 8-11 2014, is available at:=0A= =0A= http://computing.derby.ac.uk/ucc2014/conference-programme/=0A= http://computing.derby.ac.uk/ucc2014/wp-content/uploads/2014/12/UCC-2014-Co= nference-Foldout-Programme.pdf=0A= =0A= We have some very interesting keynote speakers, tutorials and workshops thi= s year.=0A= =0A= The notable names and their talks include the following:=0A= =0A= 1. Enabling Cloud Computing at Hyper-Scale: Kenji Takeda, Microsoft=0A= 2. Cloud Native Cost Optimization: Adrian Cockcroft, Battery Ventures (prev= . Netflix, eBay, Sun)=0A= 3. A Few Control Issues in Warehouse-scale Computing: John Wilkes, Google= =0A= 4. Rack-Scale Computers and the Cloud: Ant Rowstron, Microsoft=0A= 5. Joe Baguley, Chief Technology Officer, EMEA, VMware=0A= 6. Professor Yike Guo, Imperial College London=0A= 7. Actors in the Cloud: Supporting Security, Scalability and Availability ,= Gul Agha, University of Illinois at Urbana-Champaign, USA=0A= 8. Clinical Intelligence & Integration: Tackling Large Data Analytics in Re= al-Time, Oliver Vettel and Andreas Koop, Roche Diagnostics=0A= =0A= Panel Discussion: How adaptive should our infrastructure (networks, data ce= ntres etc.) be to support next generation Clouds?=0A= =0A= Alan Sill; Open Grid Forum (OGF)=0A= Joe Baguley; VMWare=0A= John Wilken; Google=0A= Erik Elmroth; Ume=E5 University (UMU)=0A= Gul Agha; University of Illinois at Urbana-Champaign=0A= =0A= UCC 2014 Tutorials=0A= 1. Azure Machine Learning for Research, Kenji Takeda=0A= 2. Model-Driven Management of Multi-Cloud Applications, Danilo Ardagna=0A= 3. The Intercloud Architecture and Project, David R. Bernstein=0A= 4. Distributed Data Storage: From Dispersed Files to Stealth Databases, Jos= ef Spillner, Johannes M=FCller,=0A= 5. Software Development in Cloud: An Experiential Study with CMS, Chandra S= ekaran K,=0A= 6. Data Analysis with R, Shruti Kohli, Shruti Kohli=0A= 6. Microsoft Azure for Research, Kenji Takeda=0A= 7. Autonomic Clouds, Omer Rana and Manish Parashar, Omer F. Rana=0A= 8. Help Clinical Intelligence take the next step using state-of-the art in-= memory analytics, Oliver Vettel and Andreas Koop=0A= 9. CRISTAL : Designing Traceable Cloud-based Systems, Richard McClatchey, A= ndrew Branson=0A= =0A= UCC 2014 Workshops=0A= 1. International Symposium on Big Data Computing 2014 =96 BDC 2014=0A= 2. 6th Cloud Control Workshop =96 CloudControl6=0A= 3. Cloud Federation Management: Identity, Resources and Applications Worksh= op =96 CFM 2014=0A= 4. Workshops on Standards and Pre-Standards Topics in Clouds, Big Data and = Data Analytics =96 SCBDA 2014=0A= 5. ITaaU Network+ Symposium =96 ITaaU 2014=0A= 6. Clouds and eScience Applications Management Workshop =96 CloudAM 2014=0A= 7. Crowdsourcing and Gamification in the Cloud Workshop =96 CGCloud 2014=0A= 8. Re-computability in the Cloud Workshop =96 Re-computability 2014=0A= 9. Advances in CC Legislation, Accountability, Security and Privacy Worksho= p =96 CLASP 2014=0A= 10. Trust in Cloud Computing Workshop =96 IWTCC 2014=0A= 11. Green Cloud Computing Workshop =96 GCC 2014=0A= 12. Smart City Clouds: Technologies, Systems and Applications Workshop =96 = SCCTSA 2014=0A= 13. Cloud Automation, Intelligent Management and Scalability Workshop =96 C= AIMS 2014=0A= 14. Cyber-physical Cloud Computing Workshop =96 CPCC 2014=0A= 15. Network Virtualization and SDN for Cloud Data Centres Workshop=0A= 16. Big Data, Intelligence Management and Analytics Workshop =96 BDIMA=0A= 17. Big Data and Social Networking Management and Security Workshop=0A= 18. Education in the Cloud Workshop =96 EC 2014=0A= 19. EGI Federated Cloud Workshop=0A= 20. Plugfest: Cloud Interoperability Event=0A= =0A= UCC 2014 Registration=0A= =0A= To register please visit: http://www.derby.ac.uk/enterprisecentre/events/uc= c/book/=0A= =0A= Best regards=0A= Ashiq Anjum=0A= =0A= =0A= Organising Chair UCC 2014 -- http://computing.derby.ac.uk/ucc2014/=0A= =0A= Dr. Ashiq Anjum=0A= Reader in Distributed Computing=0A= Distributed and Intelligent Systems (DISYS) research centre=0A= School of Computing and Mathematics=0A= University of Derby=0A= Room E510=0A= Kedleston Road=0A= Derby, UK=0A= DE22 1GB=0A= ashiq.anjum@cern.ch & a.anjum@derby.ac.uk=0A= +44 (0) 1332 591881 & 44 (0) 772 4017071=0A= http://www.derby.ac.uk/staff/ashiq-anjum/=0A= =0A= From nobody Mon Dec 8 05:05:01 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771CA1A8A0C; Mon, 8 Dec 2014 05:04:55 -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 Cl40Jp2M_HKE; Mon, 8 Dec 2014 05:04:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2FA1A8A03; Mon, 8 Dec 2014 05:04:52 -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: <20141208130452.15777.25310.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 05:04:52 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/45mFM3aG6h7YKxiJ5VGUAe3vFuw Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-report-mib-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 13:04:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Definition of Managed Objects for Performance Reporting Authors : Robert G. Cole Joseph Macker Andy Bierman Filename : draft-ietf-manet-report-mib-04.txt Pages : 35 Date : 2014-12-07 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring autonomous report generation on any device that supports MIBs containing objects that resolve to type Integer32 (i.e., Integer32, Counter, Gauge, or TimeTicks). to be used for performance monitoring. This allows a management station to instruct a device to build off-line reports to be collected either through notifications to the management station or queried asynchronously by the management station. Hence, this capability allows network operators to reduce the SNMP polling traffic burden on Mobile Ad-Hoc and Disruption Tolerant Networks which is problematic of SNMP performance management applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-report-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-report-mib-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-report-mib-04 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 Mon Dec 8 21:24:57 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F491A1BA3 for ; Mon, 8 Dec 2014 21:24:55 -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 2A4CD55mKRM2 for ; Mon, 8 Dec 2014 21:24:53 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225201A1B98 for ; Mon, 8 Dec 2014 21:24:53 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id w8so4322867qac.37 for ; Mon, 08 Dec 2014 21:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3807jAyhoRJOzjuuxk0JmfXQsZr2/qzYC10WelnXq2g=; b=hzDmk5ft6UQs/2l/IpdmhN3sRiuQSQoK0WRgc5vazVpJPW4G+Oo5sBl+g3fzOjVO8I D+xtO84RDfS/4+2DhySS/zr1rQmOnFjLwF9vf8lDHvkXuAAENFSyIAUA5QjMfscQ0ocd IyHLlubN2VhO0QPrgMpVJ2NtUzb3Hu6UJDohc8WVYenJ/RjoOlS/4fii7mGBO9JHD717 uHwZ0mKQVXGcbW3m/bpMd0Bt614lqXhOQdrwj2AbYkzOtEWcp4DbKKBlDvFVoK63R942 CaHzMUIIBIZoYbfD2E2X+cSLoiCJFCe40faovnwrH/4XUGSpvT+hhNSG/NNeEDeG7M93 WqGA== MIME-Version: 1.0 X-Received: by 10.140.30.69 with SMTP id c63mr1887984qgc.13.1418102692006; Mon, 08 Dec 2014 21:24:52 -0800 (PST) Received: by 10.140.98.212 with HTTP; Mon, 8 Dec 2014 21:24:51 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Dec 2014 21:24:51 -0800 Message-ID: From: Abdussalam Baryun To: "Cole, Robert G CIV USARMY CERDEC (US)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ufcw1mhUtlNQyznDKqZLVKBG7H8 Cc: "manet-chairs@tools.ietf.org" , "manet-ads@tools.ietf.org" , manet , Andy Bierman , draft-ietf-manet-report-mib@tools.ietf.org Subject: Re: [manet] REPORT-MIB --- update? (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 05:24:55 -0000 Dear Authors, You updated the WG's draft without replying to my discussion. This is my last reminder of my questions that were not answered until now. Please help. Thanks. AB Participant from Africa On 9/4/14, Abdussalam Baryun wrote: > Hi Robert, > > I am trying to track the discussions for this draft (not easy to track them > in IETF WG). However, I want to ask about the reason for changing draft > direction. There were some questions not answered/discussed by WG in > IETF meeting 87. Comments below, > > On Tuesday, September 2, 2014, Cole, Robert G CIV USARMY CERDEC (US) wrote: > >> Classification: UNCLASSIFIED >> Caveats: NONE >> >> To all: >> >> I did not want to comment on the questions regarding the status of the >> REPORT-MIB definition until I had pretty much wrapped up the SMF-MIB >> (which >> I believe is close to publication). > > > Do you mean Thomas's questions [2, 3]? > > >> With the permission of the working group and the chairs, I would like to >> proceed with the design and development of the REPORT-MIB? > > > I support that. > > >> >> The hold up over the last year has been the appropriate architecture for >> the REPORT-MIB. It was initially designed following RMON II tables. >> Last >> year Andy suggested (based upon conversations with others involved with >> the >> DISMAN WG years ago) that we should base the REPORT-MIB on the DISMAN >> base >> of MIBs. > > > Why was that suggestion appropriate? I tried to find the suggestion input > in IETF, but failed to find Andy's input. What is wrong with it based > on RMON? > > >> I believe I now know how to accomplish this and I would like to rewrite >> the report-mib-04 within the context of the DISMAN MIBs, e.g., EVENT-MIB, >> EXPRESSION-MIB, etc. > > > I prefer we discuss it first because report-mob-03 is WG doc and not sure > of the answers of the questions you referred to (you may mean [1, 2, > 3]). So I Disagree to change our work context before a reason discussion (I > may missed the discussion but still looking for it). I hope we start with > one new version -04 with only additions then we discuss changes in next > versions. > > >> >> So if this is OK with the group, I need a few weeks to work up the 04 >> version of the REPORT-MIB draft and post by the end of September. > > > IMHO It is ok to add context not change/delete previous context if we have > not discussed. > > Thanks for your input. > AB > > > [1]. http://www.ietf.org/mail-archive/web/manet/current/msg15963.html > > [2]. http://www.ietf.org/mail-archive/web/manet/current/msg16503.html > > [3]. Minutes of IETF 87 MANET WG meeting, (chair section, MANET management > section). > From nobody Mon Dec 8 21:27:21 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EDB1A1B98 for ; Mon, 8 Dec 2014 21:27:19 -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 VuwyD9H_pOOQ for ; Mon, 8 Dec 2014 21:27:17 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041851A00F7 for ; Mon, 8 Dec 2014 21:27:17 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id s7so4356426qap.36 for ; Mon, 08 Dec 2014 21:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZAwwp1Mb8nBOCsvQbGSmmHm1QS2BXbDLAYAhLAGoCgw=; b=erxCYlGRGTaD+U26TXRWI2Rzc2iHbUfDinjUmN9Wjmr2y8IMvmbuOggT1hXcMWiyAK 0o3N0GyWyz4SyTkWN3snPgUBX9mDRkJSUAzj8BwHSvnFipZy+IqOTkp+NOwTzjIkzy0d VbdP5flixQXzxKh2nhO31H36Tb741680m10bBsKjMXflHXWh+bPf273UrpWXIaNa+5Vs HOA1vAx8QYI2Mlpf4SMZymzp4yOqFPaV15CazEKLJFNxgMpSGdyLqtmP47x2iHos6qnx cZKSmQSSi+TVFNo2wRIU/+DM0LI/4a8GaR23yMbIYgsl9OTDpOZAB4sAStnyU2Kt22sO gNwQ== MIME-Version: 1.0 X-Received: by 10.229.251.200 with SMTP id mt8mr2155477qcb.13.1418102836195; Mon, 08 Dec 2014 21:27:16 -0800 (PST) Received: by 10.140.98.212 with HTTP; Mon, 8 Dec 2014 21:27:16 -0800 (PST) In-Reply-To: <20141208130452.15777.25310.idtracker@ietfa.amsl.com> References: <20141208130452.15777.25310.idtracker@ietfa.amsl.com> Date: Mon, 8 Dec 2014 21:27:16 -0800 Message-ID: From: Abdussalam Baryun To: draft-ietf-manet-report-mib Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/99oqenDdLKc_M2VVQ3ZnnnGMWAo Cc: "manet-ads@tools.ietf.org" , manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-report-mib-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 05:27:19 -0000 Please discuss the changes with the WG. The authors should not update privately, without replying to participants. AB On 12/8/14, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. > > Title : Definition of Managed Objects for Performance > Reporting > Authors : Robert G. Cole > Joseph Macker > Andy Bierman > Filename : draft-ietf-manet-report-mib-04.txt > Pages : 35 > Date : 2014-12-07 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes objects for configuring autonomous report > generation on any device that supports MIBs containing objects that > resolve to type Integer32 (i.e., Integer32, Counter, Gauge, or > TimeTicks). to be used for performance monitoring. This allows a > management station to instruct a device to build off-line reports to > be collected either through notifications to the management station > or queried asynchronously by the management station. Hence, this > capability allows network operators to reduce the SNMP polling > traffic burden on Mobile Ad-Hoc and Disruption Tolerant Networks > which is problematic of SNMP performance management applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-report-mib/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-report-mib-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-report-mib-04 > > > 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/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Fri Dec 12 06:06:54 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C471A8706; Fri, 12 Dec 2014 06:06:52 -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 woIt6InBaV-r; Fri, 12 Dec 2014 06:06:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 515491A8856; Fri, 12 Dec 2014 06:06:48 -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: <20141212140648.6046.35259.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 06:06:48 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/BeYTt3lZoZ5WYr9N_UFkwknoO2A Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 14:06:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Packet Sequence Number based directional airtime metric for OLSRv2 Authors : Henning Rogge Emmanuel Baccelli Filename : draft-ietf-manet-olsrv2-dat-metric-04.txt Pages : 17 Date : 2014-12-12 Abstract: This document specifies an directional airtime link metric for usage in OLSRv2. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-dat-metric/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-dat-metric-04 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 Tue Dec 16 07:43:34 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B145D1A1B44 for ; Tue, 16 Dec 2014 07:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, 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 RdiEEuF5Xy08 for ; Tue, 16 Dec 2014 07:43:24 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E7C1A1B27 for ; Tue, 16 Dec 2014 07:43:23 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 16 Dec 2014 15:42:57 +0000 From: Rick Taylor To: manet IETF Thread-Topic: DLEP Vendor Extensions Thread-Index: AdAZRvZGMxZmPNThQGCgATXqm4sJsA== Date: Tue, 16 Dec 2014 15:42:56 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/sxGWaJYocpR4xonLJTdVbznoBdE Subject: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 15:43:26 -0000 All,=0A= =0A= In response to the silence concerning Vendor Extensions in DLEP, and =0A= after much deliberation amongst the authors, we have decided to drop the = =0A= concept from the protocol.=0A= =0A= Regards,=0A= =0A= Rick Taylor=0A= From nobody Tue Dec 16 08:32:59 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB3E1A1C00 for ; Tue, 16 Dec 2014 08:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 JI3o_qer7REE for ; Tue, 16 Dec 2014 08:32:55 -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 2296B1A1B05 for ; Tue, 16 Dec 2014 08:32:55 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id fp1so14086151pdb.5 for ; Tue, 16 Dec 2014 08:32:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TYoAJYS3gu8iIP0/c7ypBxasUOfrOFoPVEnoQpOIN5U=; b=tIAgT+KqGoT3EL4zOhUYIz7Byktl21lzyewVB0XPHnsFR3Fb1DpGbL0bzn0D27YhIw 5J8PxIX58uefMtbV1zmMg0woxUj0pVuSfokuJyHFUgvXcmVyVWEqomJX25Hv2te32/cX B1QvlJn1gIR59ofN6ZPbfU1ld7uiMaynJwdjsnKw9TeUhAgQTTomGDGniJiuIW6EOdXv r2URUEFeL6y1w7ty7WhJdnoPBVPzZFja8I2B9+X5U4Hx9W5U9hb4YClHzGLiYxJsVRUd MjrQa43UKjNdpojYwYvqyFNLa3AZRZ10g/ei5D44R4WZXvmNsN+fHacl5bqRmAmQA0eR ZJrA== MIME-Version: 1.0 X-Received: by 10.66.160.199 with SMTP id xm7mr61086587pab.58.1418747573862; Tue, 16 Dec 2014 08:32:53 -0800 (PST) Received: by 10.70.128.70 with HTTP; Tue, 16 Dec 2014 08:32:53 -0800 (PST) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> Date: Tue, 16 Dec 2014 11:32:53 -0500 Message-ID: From: Justin Dean To: Rick Taylor Content-Type: multipart/alternative; boundary=047d7b6d88382a8ae2050a57e9eb Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xxPQRGYPUJDmnivUdBu4tf0x340 Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:32:57 -0000 --047d7b6d88382a8ae2050a57e9eb Content-Type: text/plain; charset=UTF-8 This was the biggest point of contention (among the authors) holding DLEP back with the only other thing to be updated (mentioned in your presentation in HI) being text and readability. Are their any other (new) large issues among the author team at this time? The proposed schedule of a new draft in January with an eye towards last call in March looks like it's on track. I'll be reviewing the previous document now in anticipation of minor changes (exception of removal of vendor extensions) and would encourage all other wg members to do the same. Justin On Tue, Dec 16, 2014 at 10:42 AM, Rick Taylor < rick@tropicalstormsoftware.com> wrote: > > All, > > In response to the silence concerning Vendor Extensions in DLEP, and > after much deliberation amongst the authors, we have decided to drop the > concept from the protocol. > > Regards, > > Rick Taylor > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b6d88382a8ae2050a57e9eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This was the biggest point of contention (among the author= s) holding DLEP back with the only other thing to be updated (mentioned in = your presentation in HI) being text and readability.=C2=A0 Are their any ot= her (new) large issues among the author team at this time?=C2=A0 The propos= ed schedule of a new draft in January with an eye towards last call in Marc= h looks like it's on track.=C2=A0 I'll be reviewing the previous do= cument now in anticipation of minor changes (exception of removal of vendor= extensions) and would encourage all other wg members to do the same.
Justin

On Tue, Dec 16, 2014 at 10:42 AM, Rick Taylor <rick@tropical= stormsoftware.com> wrote:
All,<= br>
In response to the silence concerning Vendor Extensions in DLEP, and
after much deliberation amongst the authors, we have decided to drop the concept from the protocol.

Regards,

Rick Taylor

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--047d7b6d88382a8ae2050a57e9eb-- From nobody Tue Dec 16 08:53:00 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13EE1A1BEE for ; Tue, 16 Dec 2014 08:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 xp1uJj6d1ENi for ; Tue, 16 Dec 2014 08:52:53 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115DF1A6FD5 for ; Tue, 16 Dec 2014 08:52:53 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 16 Dec 2014 16:52:28 +0000 From: Rick Taylor To: Justin Dean Thread-Topic: [manet] DLEP Vendor Extensions Thread-Index: AQHQGU3vlti1NKjLRUurrGFWKMoQIA== Date: Tue, 16 Dec 2014 16:52:27 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hSEG6dYYNChc7S-mgAN1Knw3g2Y Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:52:58 -0000 Justin, All,=0A= =0A= As a heads up, there is some new functionality that MAY be added to a =0A= draft-08: Multiple devices at a destination.=0A= =0A= The authors understand that this addition must not impact the deadlines =0A= and we will be making a pragmatic evaluation of how much impact this =0A= will have on the workload before we commit to including it.=0A= =0A= In other words, we have some interesting ideas, but we are aware that =0A= DLEP needs to get done.=0A= =0A= Any feedback on the current draft is gratefully received (as ever) so we = =0A= can get some handle on how much text fiddling we need to do. As always, = =0A= we are possibly too close to the subject to spot all under-described =0A= sections.=0A= =0A= Cheers,=0A= =0A= Rick=0A= =0A= =0A= On 16/12/14 16:32, Justin Dean wrote:=0A= > This was the biggest point of contention (among the authors) holding=0A= > DLEP back with the only other thing to be updated (mentioned in your=0A= > presentation in HI) being text and readability. Are their any other=0A= > (new) large issues among the author team at this time? The proposed=0A= > schedule of a new draft in January with an eye towards last call in=0A= > March looks like it's on track. I'll be reviewing the previous document= =0A= > now in anticipation of minor changes (exception of removal of vendor=0A= > extensions) and would encourage all other wg members to do the same.=0A= >=0A= > Justin=0A= >=0A= > On Tue, Dec 16, 2014 at 10:42 AM, Rick Taylor=0A= > >= =0A= > wrote:=0A= >=0A= > All,=0A= >=0A= > In response to the silence concerning Vendor Extensions in DLEP, and= =0A= > after much deliberation amongst the authors, we have decided to drop = the=0A= > concept from the protocol.=0A= >=0A= > Regards,=0A= >=0A= > Rick Taylor=0A= >=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= =0A= From nobody Tue Dec 16 09:28:19 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2951A6FFD for ; Tue, 16 Dec 2014 09:28:14 -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 psuoc0WVgZJP for ; Tue, 16 Dec 2014 09:28:12 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469A61A6FD5 for ; Tue, 16 Dec 2014 09:28:12 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so18064054wgh.12 for ; Tue, 16 Dec 2014 09:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MDYoogLzf/y/0dYmPxIiFd11XTZ5jsTPR+ALl31h/kM=; b=drYKAi+IJJp6dww0hpvjn884f/KjeIbilHAKt8XVxPZODGf2EgsUiuxsFpil0m2/mp pnaKqQvLCCz2mX6klPI7ssILPKox/5ztL5VGlpSi9SoIJSn/Rl0kucHBgrQfL4Tz97H1 ucrB/E4NpBxVqxoghU1NEjy4aRNKRx9PraAmzyPvaCNZv2GlvBRJI/TsSCva5q06PHku aoVPOFhktCRhQ3UbOQVY/miUXZQVShQ//lhxvgG4d8Rxwr/PflTX0S3wfjAGURWRYxZO tc+twZVLoOqoN1Br8dSkvNyjV+8743DEO4yqc1GVO4u2d+iCzMcJh0NCAGJaJ/1pSjFo 7YdA== X-Received: by 10.180.73.206 with SMTP id n14mr6780016wiv.60.1418750890916; Tue, 16 Dec 2014 09:28:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Tue, 16 Dec 2014 09:27:50 -0800 (PST) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Tue, 16 Dec 2014 18:27:50 +0100 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Zu_PkC6mj2j8tSHcFPqncxzaGAo Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:28:14 -0000 On Tue, Dec 16, 2014 at 5:52 PM, Rick Taylor wrote: > Justin, All, > > As a heads up, there is some new functionality that MAY be added to a > draft-08: Multiple devices at a destination. You mean (as an example) radios with multiple interfaces? We have thought about this at our institute too but our best idea is to address each radio "line" over a pre-configured VLAN tag. Similar to the usecase where you want to connect multiple physical radios over a VLAN-capable switch to a single ethernet port of the router. Henning From nobody Tue Dec 16 14:11:21 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1881A0197 for ; Tue, 16 Dec 2014 14:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 QwqtFuFxl9YL for ; Tue, 16 Dec 2014 14:11:16 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527A21A000B for ; Tue, 16 Dec 2014 14:11:09 -0800 (PST) Received: by mail-qg0-f46.google.com with SMTP id q107so8775915qgd.19 for ; Tue, 16 Dec 2014 14:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PFAEWK31IzRhqiMykbPosiR2Tpuj0/BsD0f+w7aCXXI=; b=QaMvqaQH0OgyCP8z9jLyEnDQTe6GzrDrvvmBqrtT7+9MZcj67udfuykdWc72WDhDzO 6R+Jqj7riZkBCLhcuvMvAGUqZigFAsJIT130lp3kvfYcXAznVASujpR7PCVXBftbDY72 VwE0as07UqAIhSdDxkffTLI8rRP6A0SYJbk+0Gc3PX9ZIcPxmzmDBBji0uXKtZypcoFj fJWtSTzn3uz8WfakenpZvFCkCJyM8aWj6nvPebINYxpemrK+ubMq9h5XGWq/337s3qWA 4+p/cUoD/lT482CJw2i+ckegUIpV/5HNpEEwUAwRGp8BsP7VnicsC1/M3JHoXBzWMN0X pA6A== MIME-Version: 1.0 X-Received: by 10.224.3.137 with SMTP id 9mr8553362qan.64.1418767868161; Tue, 16 Dec 2014 14:11:08 -0800 (PST) Received: by 10.140.98.212 with HTTP; Tue, 16 Dec 2014 14:11:08 -0800 (PST) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> Date: Tue, 16 Dec 2014 14:11:08 -0800 Message-ID: From: Abdussalam Baryun To: Rick Taylor Content-Type: multipart/alternative; boundary=001a11c2480accf78d050a5ca2ec Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yJcJrvTBBVPf5YPRVynLH12gnUc Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 22:11:18 -0000 --001a11c2480accf78d050a5ca2ec Content-Type: text/plain; charset=UTF-8 Hi All, I did not know that the manet group agreed on new functions for DLEP. I hope that WG management follow up with authors that they don't add functions until we know them and agree on the list. First we had the DT discussions and now no clear directions. Why don't we discuss in our WG list about authors' ideas or did we decide not to discuss draft ideas but just reviewing? On Tuesday, December 16, 2014, Rick Taylor wrote: > Justin, All, > > As a heads up, there is some new functionality that MAY be added to a > draft-08: Multiple devices at a destination. Why not we discuss together before updates. I don't think authors are authorised to update any new functions. I object any such authority above WG controls subject to IETF procedures. > > The authors understand that this addition must not impact the deadlines > and we will be making a pragmatic evaluation of how much impact this > will have on the workload before we commit to including it. > > In other words, we have some interesting ideas, but we are aware that > DLEP needs to get done. Please specify and discuss those ideas on the list. I am interested more in discussing them than in updating draft and including things before agreements. > Any feedback on the current draft is gratefully received (as ever) so we > can get some handle on how much text fiddling we need to do. As always, > we are possibly too close to the subject to spot all under-described > sections. This message is my first feedback. Secondly, I remember we agreed for a minimal DLEP and any new functions for future update drafts. Thirdly, I will review the draft shortly. Regards AB > > Cheers, > > Rick > > > On 16/12/14 16:32, Justin Dean wrote: > > This was the biggest point of contention (among the authors) holding > > DLEP back with the only other thing to be updated (mentioned in your > > presentation in HI) being text and readability. Are their any other > > (new) large issues among the author team at this time? The authors don't control the draft, but they are editors. The WG must know before big updates (i.e. New ideas). The proposed > > schedule of a new draft in January with an eye towards last call in > > March looks like it's on track. Do You mean a new update -00 draft or you mean a new draft version -08. I need updates to be discussed before submitting them. In past DT were updating without WG agreement and now maybe a smaller group. I'll be reviewing the previous document > > now in anticipation of minor changes (exception of removal of vendor > > extensions) and would encourage all other wg members to do the same. > > > > Justin > > > > On Tue, Dec 16, 2014 at 10:42 AM, Rick Taylor > > rick@tropicalstormsoftware.com >> > > wrote: > > > > All, > > > > In response to the silence concerning Vendor Extensions in DLEP, and > > after much deliberation amongst the authors, we have decided to drop > the > > concept from the protocol. > > > > Regards, > > > > Rick Taylor > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > > https://www.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c2480accf78d050a5ca2ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All,

I did not know that the manet=C2=A0group=C2=A0ag= reed on new functions for DLEP. I hope that WG management follow up with au= thors that they don't add functions until we know them=C2=A0and agree o= n the list.=C2=A0First we had the DT discussions=C2=A0and now no clear dire= ctions. Why don't we discuss in our WG list about authors' ideas=C2= =A0or did we decide not to discuss draft ideas but=C2=A0just reviewing?


On Tuesday, December 16, 2014, Rick Taylor <rick@tropicalstormsoftware.= com> wrote:
Justin, All,

As a heads up, there is some new functionality that MAY be added to a
draft-08: Multiple devices at a destination.

Why not we discuss together before updates. I don't think authors are= authorised to update any new functions. I object any such authority above = WG controls subject to IETF procedures.=C2=A0
=C2=A0

The authors understand that this addition must not impact the deadlines
and we will be making a pragmatic evaluation of how much impact this
will have on the workload before we commit to including it.

In other words, we have some interesting ideas, but we are aware that
DLEP needs to get done.

Please specify and = discuss those=C2=A0ideas on the list. I am interested more in discussing th= em=C2=A0than in updating draft and=C2=A0including things=C2=A0before agreem= ents.=C2=A0


Any feedback on the current draft is gratefully received (as ever) so we can get some handle on how much text fiddling we need to do.=C2=A0 As alway= s,
we are possibly too close to the subject to spot all under-described
sections.

This message is my first feedback= . Secondly, I remember we agreed for a minimal DLEP and any new functions f= or future update drafts. Thirdly, I will review the draft shortly.=C2=A0

Regards

AB
=C2=A0=

Cheers,

Rick


On 16/12/14 16:32, Justin Dean wrote:
> This was the biggest point of contention (among the authors) holding > DLEP back with the only other thing to be updated (mentioned in your > presentation in HI) being text and readability.=C2=A0 Are their any ot= her
> (new) large issues among the author team at this time?=C2=A0=C2=A0

Th= e authors don't control the draft, but they are editors. The WG must kn= ow before big=C2=A0updates (i.e. New ideas).=C2=A0

The proposed
> schedule of a new draft in January with an eye towards last call in > March looks like it's on track.

Do=C2=A0You mean a new update -00= draft or you mean a new draft version -08. I need updates to be discussed = before submitting them. In past DT were updating without WG agreement and n= ow maybe a smaller group.=C2=A0


=C2=A0 I'll be reviewing the previous document > now in anticipation of minor changes (exception of removal of vendor > extensions) and would encourage all other wg members to do the same. >
> Justin
>
> On Tue, Dec 16, 2014 at 10:42 AM, Rick Taylor
> <rick@tropicalstormsoftware.com &= lt;mailto:rick@tropicalstormsoftware.com&= gt;>
> wrote:
>
>=C2=A0 =C2=A0 =C2=A0All,
>
>=C2=A0 =C2=A0 =C2=A0In response to the silence concerning Vendor Extens= ions in DLEP, and
>=C2=A0 =C2=A0 =C2=A0after much deliberation amongst the authors, we hav= e decided to drop the
>=C2=A0 =C2=A0 =C2=A0concept from the protocol.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>
>=C2=A0 =C2=A0 =C2=A0Rick Taylor
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0manet mailing list
>=C2=A0 =C2=A0 =C2=A0manet@ietf.org <mailto:manet@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/manet
>


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--001a11c2480accf78d050a5ca2ec-- From nobody Tue Dec 16 18:20:31 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1CF1A0171 for ; Tue, 16 Dec 2014 18:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 sH9OXlVVbF4A for ; Tue, 16 Dec 2014 18:20:27 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A361A008A for ; Tue, 16 Dec 2014 18:20:23 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id gd6so12506168lab.17 for ; Tue, 16 Dec 2014 18:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4z4aVitai2CCBxmfpp4LbDX34LMrbrP34pNKS4QQ9wg=; b=AsfrNhKyMV3zBguGoVn2BjPa10hEg0sLcaySiBdOMyJhaMJeNhLKNGZSQ5ePifwdGd eawOisAd4hLujfkDjhEJWFBjG1kKg8bChMP6aAKM0Z51mY39ZrdruWy9+cUMVQKJwhRR jxmZiaoeGapaax50gyQDsiFBDdH5sjFzHUwfKGS0n1i5sUXzZI2MyFvXuoiaG1cIy131 o5mqwSvLzuJBktqo/Pd4ZAD9q3QA6n+rnmUZalIfK3GL4pUWWwgFgJ72ihUkCm8aPM60 Csb4qLn8tOboYm1ICGUgrirfd+NLfDgd6cvgdcBIOhB+nZP48WMCvaU/6/GLs0/8lO4f WZ8Q== MIME-Version: 1.0 X-Received: by 10.112.198.233 with SMTP id jf9mr18417826lbc.9.1418782822279; Tue, 16 Dec 2014 18:20:22 -0800 (PST) Received: by 10.25.85.201 with HTTP; Tue, 16 Dec 2014 18:20:22 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> Date: Tue, 16 Dec 2014 21:20:22 -0500 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11c32cf422afe6050a601ec2 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Jja4QJd1SUZVIrt1lf_EcjiCRyY Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 02:20:29 -0000 --001a11c32cf422afe6050a601ec2 Content-Type: text/plain; charset=UTF-8 Henning, The co-authors have been having some discussions with regard to deployments that have multiple end-stations (for example, laptops, cameras, VoIP phones, sensors, etc), and not necessarily a router. In this type of deployment, some (though not all) radios may have a router for access "upstream" into a network (like, for example, a reach-back to some "home office", perhaps via satellite), but not necessarily all of the radios. Regards, Stan On Tue, Dec 16, 2014 at 12:27 PM, Henning Rogge wrote: > > On Tue, Dec 16, 2014 at 5:52 PM, Rick Taylor > wrote: > > Justin, All, > > > > As a heads up, there is some new functionality that MAY be added to a > > draft-08: Multiple devices at a destination. > > You mean (as an example) radios with multiple interfaces? > > We have thought about this at our institute too but our best idea is > to address each radio "line" over a pre-configured VLAN tag. Similar > to the usecase where you want to connect multiple physical radios over > a VLAN-capable switch to a single ethernet port of the router. > > Henning > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c32cf422afe6050a601ec2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Henning,=C2=A0

The co-authors have been= having some discussions with regard to deployments that have multiple end-= stations (for example, laptops, cameras, VoIP phones, sensors, etc), and no= t necessarily a router. In this type of deployment, some (though not all) r= adios may have a router for access "upstream" into a network (lik= e, for example, a reach-back to some "home office", perhaps via s= atellite), but not necessarily all of the radios.

= Regards,
Stan

On Tue, Dec 16, 2014 at 12:27 PM, Henning Rogge <hrogge@g= mail.com> wrote:
On Tue, Dec 16= , 2014 at 5:52 PM, Rick Taylor
<rick@tropicalstormsof= tware.com> wrote:
> Justin, All,
>
> As a heads up, there is some new functionality that MAY be added to a<= br> > draft-08: Multiple devices at a destination.

You mean (as an example) radios with multiple interfaces?

We have thought about this at our institute too but our best idea is
to address each radio "line" over a pre-configured VLAN tag. Simi= lar
to the usecase where you want to connect multiple physical radios over
a VLAN-capable switch to a single ethernet port of the router.

Henning

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--001a11c32cf422afe6050a601ec2-- From nobody Tue Dec 16 22:59:20 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6C71A1EFE for ; Tue, 16 Dec 2014 22:59:19 -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 7Cha-hoTtroH for ; Tue, 16 Dec 2014 22:59:08 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1311A1BED for ; Tue, 16 Dec 2014 22:59:08 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id l18so19442652wgh.16 for ; Tue, 16 Dec 2014 22:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2czxATMarx59x7kxKRK12zc/jioe6JhlOSfvA1I+GTY=; b=l+1mhit0dHHTo7oube9IXvJc0sElQOv2w9ShetJikt1mki23p9+IMVowjKntVK0Pnf NzI404qaPehcjPrQslWsuBvTfUdedlQjhN9cm33ITh75xClW/r1Mr/LtbylEKffQ4Xsx /GPs0Yn+fAYv7QaIzZfjt0MlyraiTzlsHXTJ4fx0zkBKA0fIIeXYZQHTnR7Lhb/E5/K1 nn8+hVYkbZ7FifZi2TwL6Ai/GiIlHRN2sSGJyKGrV4rTimg8h9Qg+T/gEubeJHFnerfd lLz0pIbguJBoc+ngcg9cIheO7ywmqqfzR5cvxhDURia5cfxnpm7Z6h8RPOPo9RfGNoPX 2xJQ== X-Received: by 10.180.210.236 with SMTP id mx12mr11576513wic.16.1418799547050; Tue, 16 Dec 2014 22:59:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Tue, 16 Dec 2014 22:58:46 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Wed, 17 Dec 2014 07:58:46 +0100 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_v_NeAvIwYK2YD3piYDh5dl5vGo Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 06:59:19 -0000 Hi Stan, maybe I missunderstood Rick and you can explain the "multiple destinations" a little bit better. I worry that the "bridging" on the radio will become much more complicated if there is more than a point-2-point connection over the ethernet to one other device (router). Henning On Wed, Dec 17, 2014 at 3:20 AM, Stan Ratliff wrote: > Henning, > > The co-authors have been having some discussions with regard to deployments > that have multiple end-stations (for example, laptops, cameras, VoIP phones, > sensors, etc), and not necessarily a router. In this type of deployment, > some (though not all) radios may have a router for access "upstream" into a > network (like, for example, a reach-back to some "home office", perhaps via > satellite), but not necessarily all of the radios. > > Regards, > Stan > > On Tue, Dec 16, 2014 at 12:27 PM, Henning Rogge wrote: >> >> On Tue, Dec 16, 2014 at 5:52 PM, Rick Taylor >> wrote: >> > Justin, All, >> > >> > As a heads up, there is some new functionality that MAY be added to a >> > draft-08: Multiple devices at a destination. >> >> You mean (as an example) radios with multiple interfaces? >> >> We have thought about this at our institute too but our best idea is >> to address each radio "line" over a pre-configured VLAN tag. Similar >> to the usecase where you want to connect multiple physical radios over >> a VLAN-capable switch to a single ethernet port of the router. >> >> Henning >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From nobody Wed Dec 17 01:02:25 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD651A1A33 for ; Wed, 17 Dec 2014 01:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sIS3cdtl3L5j for ; Wed, 17 Dec 2014 01:02:21 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ABD81A0366 for ; Wed, 17 Dec 2014 01:02:20 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so3441792wgh.15 for ; Wed, 17 Dec 2014 01:02:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=vQs7i0+HcxFaqa59vSOUDlbTbfErSL3OumlfEgQc56E=; b=fMXLHJ2+0V3onnUp3I4jUL4NSnb48qJQzL7tw9doXJg+RC3E+c7Ld22MururHUO7eT UabxFnkQT5VAbYHne/oL6HIifVCGrZqcAbKJICTzMSOuDpY2Hr3aAKnBKKIf70met82C UMgayYwWd3F1Nm1O0bpE+UPOycF9gla2YDQKxYo27XlMngq8HUojA1S6bvy9P+d5cH/R qdhnpbtLJ7i1LygQlw5YQgW7JuobORzSZq6i390beMbu/bVdD/LQ0ZeAdhFvSy3BELSF f70bNfIOZQOMs3dS371N+wIlJLLK+DEQPad7dVVN859U46/UGLTFvCBgc9XwtPt2QcJ4 TqJQ== X-Gm-Message-State: ALoCoQk7r3A8q0KoKnzjVzqSmnCXZGhcEHqM4ggH96Jwaf5l8GXHFvhVfuXK+hmUEpg/RvI8a2kT X-Received: by 10.194.58.180 with SMTP id s20mr70390838wjq.28.1418806938939; Wed, 17 Dec 2014 01:02:18 -0800 (PST) Received: from [192.168.43.109] ([188.207.89.112]) by mx.google.com with ESMTPSA id w10sm4262417wje.10.2014.12.17.01.02.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 01:02:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Teco Boot In-Reply-To: Date: Wed, 17 Dec 2014 10:02:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> To: Henning Rogge X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/T_hvJugyVgxYy8I7aCq6ee4hbFA Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 09:02:23 -0000 > Op 17 dec. 2014, om 07:58 heeft Henning Rogge het = volgende geschreven: >=20 > Hi Stan, >=20 > maybe I missunderstood Rick and you can explain the "multiple > destinations" a little bit better. >=20 > I worry that the "bridging" on the radio will become much more > complicated if there is more than a point-2-point connection over the > ethernet to one other device (router). This is an implementation detail. I have radio gear with multiple = ethernet interfaces, sharing same WAN interface. Using an ethernet hub or switch has same effect. Teco >=20 > Henning >=20 > On Wed, Dec 17, 2014 at 3:20 AM, Stan Ratliff = wrote: >> Henning, >>=20 >> The co-authors have been having some discussions with regard to = deployments >> that have multiple end-stations (for example, laptops, cameras, VoIP = phones, >> sensors, etc), and not necessarily a router. In this type of = deployment, >> some (though not all) radios may have a router for access "upstream" = into a >> network (like, for example, a reach-back to some "home office", = perhaps via >> satellite), but not necessarily all of the radios. >>=20 >> Regards, >> Stan >>=20 >> On Tue, Dec 16, 2014 at 12:27 PM, Henning Rogge = wrote: >>>=20 >>> On Tue, Dec 16, 2014 at 5:52 PM, Rick Taylor >>> wrote: >>>> Justin, All, >>>>=20 >>>> As a heads up, there is some new functionality that MAY be added to = a >>>> draft-08: Multiple devices at a destination. >>>=20 >>> You mean (as an example) radios with multiple interfaces? >>>=20 >>> We have thought about this at our institute too but our best idea is >>> to address each radio "line" over a pre-configured VLAN tag. Similar >>> to the usecase where you want to connect multiple physical radios = over >>> a VLAN-capable switch to a single ethernet port of the router. >>>=20 >>> Henning >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Dec 17 06:45:40 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F001A1AB1 for ; Wed, 17 Dec 2014 06:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 li7pZ8M1GCtn for ; Wed, 17 Dec 2014 06:45:36 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9EA1A871B for ; Wed, 17 Dec 2014 06:45:35 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id z12so12749243lbi.32 for ; Wed, 17 Dec 2014 06:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XQqdBQ4DXwe9pd05eLxJjFlLNlaBZHDyROhcYezvMrI=; b=H1HIbISmcVOaQfA3S6UV+lNJHsWOnPeSBSaiV/UIjJtSxXp+/Lwd4gaJ2tB840zuC2 kH7W187EjPEoQgpAGyYpZ4MfBmNCnumxT2grvXwOUrwUia3jLDOUeZz6PV0FE0dAKUGq jnxn3AGC9izqHxI9DYEOqZWf+msKfo1srQonB2zM70gNLMf7jMahCgqhMC7m1DuMqfBy nBhSSeg8uSo8YAAaOR/Hmiuzx3lG29ATQRf6w9w9oYidymoYFAc1NvEXQwmDDrC8w14b +lR5dL2uM3+zZEkkWZ6y9Xdh7j9IsyoVCyih9aUBD3fiHJ0iO0budFwScKbbF/g9uvS1 T9jw== MIME-Version: 1.0 X-Received: by 10.152.5.67 with SMTP id q3mr41339125laq.73.1418827534110; Wed, 17 Dec 2014 06:45:34 -0800 (PST) Received: by 10.25.85.201 with HTTP; Wed, 17 Dec 2014 06:45:34 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> Date: Wed, 17 Dec 2014 09:45:34 -0500 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=089e013d17342b12ac050a6a879e Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ybFyI2qTtMf4EBxQgZ8QG6lbqLk Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 14:45:39 -0000 --089e013d17342b12ac050a6a879e Content-Type: text/plain; charset=UTF-8 Henning, I'll give it a go. Let's assume a MANET deployment where some number ("N") of vehicles are deployed. Each of those vehicles has some number of laptops, a VoIP phone (or two), a video camera, and some other sensors - for a total of 12 devices. This setup with the radio and 12 devices is my "standard kit" - I put that standard kit into almost every vehicle I have in my fleet. Additionally, the deployment has a small number (let's say 3) of "VIP Vehicles" - those vehicles have multiple radios, satcom for reach-back, and most importantly, a router. So now, I take 100 vehicles with the "standard kit", plus my 3 " VIP Vehicles", and deploy them. I contend that with regard to the vehicles having the "standard kit", DLEP doesn't have an effect unless each and every device is declared as a DLEP "Destination" (via presentation of a 'Destination Up' order). You see, we've been concentrating on deployments where every radio has a *router* attached to it, and then all devices are attached "behind" the router. So from a DLEP perspective, there's just 1 DLEP "destination" per radio (that 'destination' being the router). I believe that works quite well. But in the case I've described, where a lot of the radios don't have a router installed, DLEP doesn't scale well - in my little example, the psuedo-Ethernet segment created by the radios will have 1,200+ MAC addresses on it (12 devices per vehicle, 100 vehicles - the classic "M*N" scalability problem). Each of those MAC addresses should be identified by a DLEP "Destination Up"; and they would also need their own "Destination Update" orders if/when the RF characteristics change - that gets unwieldy pretty fast. So, that's what we mean by the "multiple destinations" verbiage, and we've been discussing some ideas to reduce the DLEP overhead in those deployment scenarios. It's not really new functionality; more of things like: - Can a "Destination Up" order contain more than 1 MAC address TLV? (I believe the answer to that is 'yes') - If a "Destination Up" order contains more than 1 Mac Address TLV, then how are the associated IPv4 Address and IPv6 address TLVs processed? (I believe the answer to that is "positionally" e.g., the DLEP buffer looks something like MAC TLV 1/IPv4 Addr TLV 1/MAC TLV 2/IPv4 Addr TLV 2/IPv6 Addr TLV 2; but the document is not clear on that, and needs to be explicit in that area.). - Is there a reasonably straightforward way in DLEP to effectively say "The data rate *to the remote radio* is ", allowing a single "Destination Update" order to convey metrics for multiple MAC addresses across the RF link? (I believe the answer to that question is "Not in DLEP-07, but I think there is a straightforward "tweak" to the protocol to let us do that.") Now, the "is there a way to reference the remote radio itself, instead of all of its connected devices" issue also led us to reconsider the notion that has been described as "Layer 3 DLEP" - that being, radio devices having sufficient Layer 3 smarts to be able to receive a frame, and re-write the Layer 2 header for subsequent egress, based on an IP address lookup. Personally, I believe that once you've created a way to reference just the remote modem, doing this type of "gateway operation" *IN LIEU OF" the "transparent bridge mode" we all know and love (hate?) isn't a large step at all... Hopefully, that helps make things clearer. I'm *really* hoping I haven't muddied the waters... ;-) Regards, Stan On Wed, Dec 17, 2014 at 1:58 AM, Henning Rogge wrote: > > Hi Stan, > > maybe I missunderstood Rick and you can explain the "multiple > destinations" a little bit better. > > I worry that the "bridging" on the radio will become much more > complicated if there is more than a point-2-point connection over the > ethernet to one other device (router). > > Henning > > On Wed, Dec 17, 2014 at 3:20 AM, Stan Ratliff > wrote: > > Henning, > > > > The co-authors have been having some discussions with regard to > deployments > > that have multiple end-stations (for example, laptops, cameras, VoIP > phones, > > sensors, etc), and not necessarily a router. In this type of deployment, > > some (though not all) radios may have a router for access "upstream" > into a > > network (like, for example, a reach-back to some "home office", perhaps > via > > satellite), but not necessarily all of the radios. > > > > Regards, > > Stan > > > > On Tue, Dec 16, 2014 at 12:27 PM, Henning Rogge > wrote: > >> > >> On Tue, Dec 16, 2014 at 5:52 PM, Rick Taylor > >> wrote: > >> > Justin, All, > >> > > >> > As a heads up, there is some new functionality that MAY be added to a > >> > draft-08: Multiple devices at a destination. > >> > >> You mean (as an example) radios with multiple interfaces? > >> > >> We have thought about this at our institute too but our best idea is > >> to address each radio "line" over a pre-configured VLAN tag. Similar > >> to the usecase where you want to connect multiple physical radios over > >> a VLAN-capable switch to a single ethernet port of the router. > >> > >> Henning > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > --089e013d17342b12ac050a6a879e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Henning,
=C2=A0
I'll give it= a go. Let's assume a MANET deployment where some number ("N"= ) of vehicles are deployed. Each of those vehicles has some number of lapto= ps, a VoIP phone (or two), a video camera, and some other sensors -=C2=A0fo= r a total of 12 devices. This setup with the radio and 12 devices is my &qu= ot;standard kit" - I put that standard kit into almost every vehicle I= have in my fleet. Additionally, the deployment has=C2=A0a small number (le= t's say 3) of "VIP Vehicles" - those=C2=A0vehicles have=C2=A0= multiple radios, satcom for reach-back, and most importantly, a router.
=C2=A0
So now, I take 100 vehicles with the "standard= kit", plus my 3 "=C2=A0VIP Vehicles", and deploy them. I co= ntend that with regard to the vehicles having the "standard kit",= DLEP doesn't=C2=A0have an effect=C2=A0unless each and every device is = declared as a DLEP "Destination" (via presentation of a 'Dest= ination Up' order). You see, we've been concentrating on deployment= s where every radio has a *router* attached to it, and then all devices are= attached "behind" the router. So from a DLEP perspective, there&= #39;s just 1 DLEP "destination" per radio (that 'destination&= #39; being the router). I believe that works quite well. But in the case I&= #39;ve described, where a lot of the radios don't have a router install= ed, DLEP doesn't scale well - in my little example, the psuedo-Ethernet= segment=C2=A0created by the radios will have 1,200+ MAC addresses on it (1= 2 devices per vehicle, 100 vehicles - the classic "M*N" scalabili= ty problem). Each of those MAC addresses should be identified by a DLEP &qu= ot;Destination Up"; and they would also need their own "Destinati= on Update" orders if/when the RF characteristics change - that gets=C2= =A0unwieldy pretty fast.
=C2=A0
So, that's what we = mean by the "multiple destinations" verbiage, and we've been = discussing some ideas to reduce the DLEP overhead in those deployment scena= rios. It's not really new functionality; more=C2=A0of things like:=C2= =A0
- Can=C2=A0a "Destination Up" order contain more t= han 1 MAC address TLV? (I believe the answer to that is 'yes')=C2= =A0
- If a "Destination Up" order contains more than 1 = Mac Address TLV, then how are the associated IPv4 Address and IPv6 address = TLVs processed? (I believe the answer to that is "positionally" e= .g., the DLEP buffer looks something like MAC TLV 1/IPv4 Addr TLV 1/MAC TLV= 2/IPv4 Addr TLV 2/IPv6 Addr TLV 2; but the document is not clear on that, = and needs to be explicit in that area.).
-=C2=A0Is there a reason= ably straightforward way in DLEP to=C2=A0effectively say "The data rat= e *to the remote radio* is <blah>", allowing a single "Dest= ination Update" order to convey metrics for multiple MAC addresses acr= oss the RF link? (I believe the answer to that question is "Not in DLE= P-07, but I think there is a straightforward "tweak" to the proto= col to let us=C2=A0do that.")=C2=A0=C2=A0
=C2=A0
N= ow, the "is there a way to reference the remote radio itself, instead = of all of its connected devices" issue also led us to reconsider the n= otion that has been described as "Layer 3 DLEP" - that being, rad= io devices having sufficient Layer 3 smarts to be able to receive a frame, = and re-write the Layer 2 header for subsequent egress,=C2=A0based on an IP = address lookup. Personally, I believe that once you've created a way to= reference just the remote modem, doing this type of "gateway operatio= n" *IN LIEU OF" the "transparent bridge mode" we all kn= ow and love (hate?) isn't a large step at all...
=C2=A0
=
Hopefully, that helps make things clearer. I'm *really* hoping I h= aven't muddied the waters... ;-)
=C2=A0
Regards,
Stan

On Wed, Dec 17, 2014 at 1:58 AM, Henning Rogge <= ;hrogge@gmail.com= > wrote:
Hi Stan,

maybe I missunderstood Rick and you can explain the "multiple
destinations" a little bit better.

I worry that the "bridging" on the radio will become much more complicated if there is more than a point-2-point connection over the
ethernet to one other device (router).

Henning

On Wed, Dec 17, 2014 at 3:20 AM, Stan Ratliff <ratliffstan@gmail.com> wrote:
> Henning,
>
> The co-authors have been having some discussions with regard to deploy= ments
> that have multiple end-stations (for example, laptops, cameras, VoIP p= hones,
> sensors, etc), and not necessarily a router. In this type of deploymen= t,
> some (though not all) radios may have a router for access "upstre= am" into a
> network (like, for example, a reach-back to some "home office&quo= t;, perhaps via
> satellite), but not necessarily all of the radios.
>
> Regards,
> Stan
>
> On Tue, Dec 16, 2014 at 12:27 PM, Henning Rogge <hrogge@gmail.com> wrote:
>>
>> On Tue, Dec 16, 2014 at 5:52 PM, Rick Taylor
>> <rick@tropica= lstormsoftware.com> wrote:
>> > Justin, All,
>> >
>> > As a heads up, there is some new functionality that MAY be ad= ded to a
>> > draft-08: Multiple devices at a destination.
>>
>> You mean (as an example) radios with multiple interfaces?
>>
>> We have thought about this at our institute too but our best idea = is
>> to address each radio "line" over a pre-configured VLAN = tag. Similar
>> to the usecase where you want to connect multiple physical radios = over
>> a VLAN-capable switch to a single ethernet port of the router.
>>
>> Henning
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
--089e013d17342b12ac050a6a879e-- From nobody Wed Dec 17 09:04:28 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E627C1A8AF5 for ; Wed, 17 Dec 2014 09:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TVqG4XOgtItc for ; Wed, 17 Dec 2014 09:04:19 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640F51A1AB1 for ; Wed, 17 Dec 2014 09:04:18 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so16434347wid.15 for ; Wed, 17 Dec 2014 09:04:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=IC2vaP7o3pHZJYJgSf248P153VUaunsUzADVKAssaV4=; b=ISQbnbUChqdkqLVMyMHRzAk9smnszl3RsUMWYxDbw3ehcJBdCd6/QMErvy/vPCa7We xSDosQ+8DEoRn/Mp1LrLjigPz7XDRiQ291Ioqd86hGokuKMUzMb9TIPyIUCyz9f1xY7g jpY94c8ltVw6Hzz5AkH2tByIpQXBVB78WXSpvy7eLNNR9NvYZmdCrIogecHM48+CqM6X TxP4c57MN6tTq0xY/6a7sUUrNMdg/IXQ4tYY6CV3/QXyeuXmFMSpHCE5QzNalhbOF24X Q3UQ8Mo0Ews8+sGH6CnSBKYK+sZA+Gmu2rjpBiN6F8OoIsYGJsc6WTAx308/8xALgqXr qobg== X-Gm-Message-State: ALoCoQmmrYQPWvA+SnFYLvkY8nyMvHV6cBOUzdcvxVHAZqAeiI4JckgrOK07kzOjNu5NUFzUC2Cg X-Received: by 10.180.198.209 with SMTP id je17mr16170371wic.17.1418835857430; Wed, 17 Dec 2014 09:04:17 -0800 (PST) Received: from [192.168.43.109] ([188.207.71.198]) by mx.google.com with ESMTPSA id cg8sm3710882wjc.1.2014.12.17.09.04.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 09:04:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Teco Boot In-Reply-To: Date: Wed, 17 Dec 2014 18:04:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/pIyvnxlUip-BUmOEMgFCyKEsTuE Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:04:24 -0000 I=E2=80=99m not worried at al on DLEP overhead. It is local traffic and = mostly incremental updates. How the radio=E2=80=99s handle 1200+ MAC addresses: interesting topic, = but not related to DLEP. Teco > Op 17 dec. 2014, om 15:45 heeft Stan Ratliff = het volgende geschreven: >=20 > Henning, > =20 > I'll give it a go. Let's assume a MANET deployment where some number = ("N") of vehicles are deployed. Each of those vehicles has some number = of laptops, a VoIP phone (or two), a video camera, and some other = sensors - for a total of 12 devices. This setup with the radio and 12 = devices is my "standard kit" - I put that standard kit into almost every = vehicle I have in my fleet. Additionally, the deployment has a small = number (let's say 3) of "VIP Vehicles" - those vehicles have multiple = radios, satcom for reach-back, and most importantly, a router. > =20 > So now, I take 100 vehicles with the "standard kit", plus my 3 " VIP = Vehicles", and deploy them. I contend that with regard to the vehicles = having the "standard kit", DLEP doesn't have an effect unless each and = every device is declared as a DLEP "Destination" (via presentation of a = 'Destination Up' order). You see, we've been concentrating on = deployments where every radio has a *router* attached to it, and then = all devices are attached "behind" the router. So from a DLEP = perspective, there's just 1 DLEP "destination" per radio (that = 'destination' being the router). I believe that works quite well. But in = the case I've described, where a lot of the radios don't have a router = installed, DLEP doesn't scale well - in my little example, the = psuedo-Ethernet segment created by the radios will have 1,200+ MAC = addresses on it (12 devices per vehicle, 100 vehicles - the classic = "M*N" scalability problem). Each of those MAC addresses should be = identified by a DLEP "Destination Up"; and they would also need their = own "Destination Update" orders if/when the RF characteristics change - = that gets unwieldy pretty fast. > =20 > So, that's what we mean by the "multiple destinations" verbiage, and = we've been discussing some ideas to reduce the DLEP overhead in those = deployment scenarios. It's not really new functionality; more of things = like:=20 > - Can a "Destination Up" order contain more than 1 MAC address TLV? (I = believe the answer to that is 'yes')=20 > - If a "Destination Up" order contains more than 1 Mac Address TLV, = then how are the associated IPv4 Address and IPv6 address TLVs = processed? (I believe the answer to that is "positionally" e.g., the = DLEP buffer looks something like MAC TLV 1/IPv4 Addr TLV 1/MAC TLV = 2/IPv4 Addr TLV 2/IPv6 Addr TLV 2; but the document is not clear on = that, and needs to be explicit in that area.). > - Is there a reasonably straightforward way in DLEP to effectively say = "The data rate *to the remote radio* is ", allowing a single = "Destination Update" order to convey metrics for multiple MAC addresses = across the RF link? (I believe the answer to that question is "Not in = DLEP-07, but I think there is a straightforward "tweak" to the protocol = to let us do that.") =20 > =20 > Now, the "is there a way to reference the remote radio itself, instead = of all of its connected devices" issue also led us to reconsider the = notion that has been described as "Layer 3 DLEP" - that being, radio = devices having sufficient Layer 3 smarts to be able to receive a frame, = and re-write the Layer 2 header for subsequent egress, based on an IP = address lookup. Personally, I believe that once you've created a way to = reference just the remote modem, doing this type of "gateway operation" = *IN LIEU OF" the "transparent bridge mode" we all know and love (hate?) = isn't a large step at all... > =20 > Hopefully, that helps make things clearer. I'm *really* hoping I = haven't muddied the waters... ;-) > =20 > Regards, > Stan >=20 > On Wed, Dec 17, 2014 at 1:58 AM, Henning Rogge = wrote: > Hi Stan, >=20 > maybe I missunderstood Rick and you can explain the "multiple > destinations" a little bit better. >=20 > I worry that the "bridging" on the radio will become much more > complicated if there is more than a point-2-point connection over the > ethernet to one other device (router). >=20 > Henning >=20 > On Wed, Dec 17, 2014 at 3:20 AM, Stan Ratliff = wrote: > > Henning, > > > > The co-authors have been having some discussions with regard to = deployments > > that have multiple end-stations (for example, laptops, cameras, VoIP = phones, > > sensors, etc), and not necessarily a router. In this type of = deployment, > > some (though not all) radios may have a router for access "upstream" = into a > > network (like, for example, a reach-back to some "home office", = perhaps via > > satellite), but not necessarily all of the radios. > > > > Regards, > > Stan > > > > On Tue, Dec 16, 2014 at 12:27 PM, Henning Rogge = wrote: > >> > >> On Tue, Dec 16, 2014 at 5:52 PM, Rick Taylor > >> wrote: > >> > Justin, All, > >> > > >> > As a heads up, there is some new functionality that MAY be added = to a > >> > draft-08: Multiple devices at a destination. > >> > >> You mean (as an example) radios with multiple interfaces? > >> > >> We have thought about this at our institute too but our best idea = is > >> to address each radio "line" over a pre-configured VLAN tag. = Similar > >> to the usecase where you want to connect multiple physical radios = over > >> a VLAN-capable switch to a single ethernet port of the router. > >> > >> Henning > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Dec 17 09:27:50 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4781A3B9D for ; Wed, 17 Dec 2014 09:27:47 -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 Zprtp7idINby for ; Wed, 17 Dec 2014 09:27:46 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898771A1BD4 for ; Wed, 17 Dec 2014 09:27:44 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l2so20933319wgh.13 for ; Wed, 17 Dec 2014 09:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MhNiq06h/1s42nCbD5SwPwvg+oXvuOiNdzVsSQXj8/I=; b=A1u8y2ckVjewnlGu7srKM1DYckKXJqMRbW6kKLTiaYpBqQSpVKk5DcSS1/cbCllGba EIh5fccWFUlRMaTpLdXWZJ6LnAxDveFWaNq8MYyVp6hT8xbgPjSBxiwgTOp7xplRgTSu TLWK9ueLe11nFC71vAV8v1ts2ExeAsH8r42h7ryPlSxbiz3WkcIrphAgeEb6NqszwjXi X1F3a7sVrTC/upM6sfevFU4VJk09vFwUZgoiyrbi4VnBczi98HFqj8bSPly4//q5R9aX 2/fm865cFrs0X0+mIjOAXFO0U/HSMHopSo385PWfOriyFVrbz3uBH/RTpgu+cbI0jCOL a2ig== X-Received: by 10.194.83.98 with SMTP id p2mr30234078wjy.125.1418837263280; Wed, 17 Dec 2014 09:27:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Wed, 17 Dec 2014 09:27:23 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Wed, 17 Dec 2014 18:27:23 +0100 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/vDvFKKXw5z5HMF6zEZ2N72pn2as Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:27:47 -0000 On Wed, Dec 17, 2014 at 3:45 PM, Stan Ratliff wrote: > Henning, > > I'll give it a go. Let's assume a MANET deployment where some number ("N") ... > "Destination Update" orders if/when the RF characteristics change - that > gets unwieldy pretty fast. So we keep the DLEP assumption that the DLEP "radio" still forward everything (not DLEP/internal service) between radio interface and ethernet. Okay... > So, that's what we mean by the "multiple destinations" verbiage, and we've > been discussing some ideas to reduce the DLEP overhead in those deployment > scenarios. It's not really new functionality; more of things like: > - Can a "Destination Up" order contain more than 1 MAC address TLV? (I > believe the answer to that is 'yes') I think Rick was talking about an "radio neighbor identifier" to have an abstraction between mac address and radio neighbor identity. > - If a "Destination Up" order contains more than 1 Mac Address TLV, then how > are the associated IPv4 Address and IPv6 address TLVs processed? (I believe > the answer to that is "positionally" e.g., the DLEP buffer looks something > like MAC TLV 1/IPv4 Addr TLV 1/MAC TLV 2/IPv4 Addr TLV 2/IPv6 Addr TLV 2; > but the document is not clear on that, and needs to be explicit in that > area.). I don't like the "positional" thing... at the moment we don't have TLVs depending on each other (and the order of TLVs), but this could complicate things. If its a "one-to-one" mapping, we could introduce a combined "Mac-IP" TLV which contains both mac and TLV... thats easier to parse (but still ugly as a concept). As Teco said overhead is not that important for DLEP... its used on a fast local ethernet link. And if you always have 10 devices in your cars behind your radio, maybe one of them should just work as an IP router. Henning Rogge From nobody Wed Dec 17 09:30:10 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B881A1BD6 for ; Wed, 17 Dec 2014 09:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 UnleKf-MrreY for ; Wed, 17 Dec 2014 09:30:05 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6971A1EEB for ; Wed, 17 Dec 2014 09:30:04 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so12982878lbg.5 for ; Wed, 17 Dec 2014 09:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CsLFBplxh6wLauABnFHcxEJXv48mMZ0ZEJEK2lynUVY=; b=DLWSng5Z1PMlQZ2na9x3bVzB8VNpW78QeKAaeyOdZsvK+cfS8XIxEcZWVjeeaa4O/h dd2h5ksiAYrwmi6deOvVjIyTRVmq7gQH58VXGc4vt4pNSgPnpRJetGl+D8C2jetZ6oS6 ACAU4ygThZIc7B+qvwCWmvXJA5rFm4md4yPNIfr5JnB7zrl6Y8tkrsW0YFIs1JGgvW24 AD1Fn0OjX03/Ffg1oeUgNijjnrc4fxv10yoOpU98uDREfJOVtI88kNM6GXat1UdQ5UYH HRjcgx6llTj3PM5SeFveePjg7BrxK1Va7rVwifFVuo+rGh1/QgUX7y5zK8BKZxp1l9gg gtig== MIME-Version: 1.0 X-Received: by 10.112.170.36 with SMTP id aj4mr42113538lbc.3.1418837403007; Wed, 17 Dec 2014 09:30:03 -0800 (PST) Received: by 10.25.85.201 with HTTP; Wed, 17 Dec 2014 09:30:02 -0800 (PST) In-Reply-To: <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> Date: Wed, 17 Dec 2014 12:30:02 -0500 Message-ID: From: Stan Ratliff To: Teco Boot Content-Type: multipart/alternative; boundary=001a11c261fc668177050a6cd3d3 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/U2VtjfM2bO_gkF2K091J1eViEo0 Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:30:08 -0000 --001a11c261fc668177050a6cd3d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I respectfully disagree with you on both points. "I=E2=80=99m not worried at al on DLEP overhead. It is local traffic and mo= stly incremental updates." - As strictly defined, that is true. However, the presentation of (for example) Destination Update for metrics to some remote destination implies that *some sort* of OTA signaling has occurred to obtain those metrics in the first place. Especially in multi-hop mesh networks. "How the radio=E2=80=99s handle 1200+ MAC addresses: interesting topic, but= not related to DLEP." - Not if you are a radio vendor, are looking at supporting DLEP, and are concerned about winging that much state information across your precious RF network, in order to present the "Destination Up" and "Destination Update" orders to some small number of routers. Regards, Stan On Wed, Dec 17, 2014 at 12:04 PM, Teco Boot wrote: > > I=E2=80=99m not worried at al on DLEP overhead. It is local traffic and m= ostly > incremental updates. > > How the radio=E2=80=99s handle 1200+ MAC addresses: interesting topic, bu= t not > related to DLEP. > > Teco > > > > Op 17 dec. 2014, om 15:45 heeft Stan Ratliff > het volgende geschreven: > > > > Henning, > > > > I'll give it a go. Let's assume a MANET deployment where some number > ("N") of vehicles are deployed. Each of those vehicles has some number of > laptops, a VoIP phone (or two), a video camera, and some other sensors - > for a total of 12 devices. This setup with the radio and 12 devices is my > "standard kit" - I put that standard kit into almost every vehicle I have > in my fleet. Additionally, the deployment has a small number (let's say 3= ) > of "VIP Vehicles" - those vehicles have multiple radios, satcom for > reach-back, and most importantly, a router. > > > > So now, I take 100 vehicles with the "standard kit", plus my 3 " VIP > Vehicles", and deploy them. I contend that with regard to the vehicles > having the "standard kit", DLEP doesn't have an effect unless each and > every device is declared as a DLEP "Destination" (via presentation of a > 'Destination Up' order). You see, we've been concentrating on deployments > where every radio has a *router* attached to it, and then all devices are > attached "behind" the router. So from a DLEP perspective, there's just 1 > DLEP "destination" per radio (that 'destination' being the router). I > believe that works quite well. But in the case I've described, where a lo= t > of the radios don't have a router installed, DLEP doesn't scale well - in > my little example, the psuedo-Ethernet segment created by the radios will > have 1,200+ MAC addresses on it (12 devices per vehicle, 100 vehicles - t= he > classic "M*N" scalability problem). Each of those MAC addresses should be > identified by a DLEP "Destination Up"; and they would also need their own > "Destination Update" orders if/when the RF characteristics change - that > gets unwieldy pretty fast. > > > > So, that's what we mean by the "multiple destinations" verbiage, and > we've been discussing some ideas to reduce the DLEP overhead in those > deployment scenarios. It's not really new functionality; more of things > like: > > - Can a "Destination Up" order contain more than 1 MAC address TLV? (I > believe the answer to that is 'yes') > > - If a "Destination Up" order contains more than 1 Mac Address TLV, the= n > how are the associated IPv4 Address and IPv6 address TLVs processed? (I > believe the answer to that is "positionally" e.g., the DLEP buffer looks > something like MAC TLV 1/IPv4 Addr TLV 1/MAC TLV 2/IPv4 Addr TLV 2/IPv6 > Addr TLV 2; but the document is not clear on that, and needs to be explic= it > in that area.). > > - Is there a reasonably straightforward way in DLEP to effectively say > "The data rate *to the remote radio* is ", allowing a single > "Destination Update" order to convey metrics for multiple MAC addresses > across the RF link? (I believe the answer to that question is "Not in > DLEP-07, but I think there is a straightforward "tweak" to the protocol t= o > let us do that.") > > > > Now, the "is there a way to reference the remote radio itself, instead > of all of its connected devices" issue also led us to reconsider the noti= on > that has been described as "Layer 3 DLEP" - that being, radio devices > having sufficient Layer 3 smarts to be able to receive a frame, and > re-write the Layer 2 header for subsequent egress, based on an IP address > lookup. Personally, I believe that once you've created a way to reference > just the remote modem, doing this type of "gateway operation" *IN LIEU OF= " > the "transparent bridge mode" we all know and love (hate?) isn't a large > step at all... > > > > Hopefully, that helps make things clearer. I'm *really* hoping I haven'= t > muddied the waters... ;-) > > > > Regards, > > Stan > > > > On Wed, Dec 17, 2014 at 1:58 AM, Henning Rogge wrote= : > > Hi Stan, > > > > maybe I missunderstood Rick and you can explain the "multiple > > destinations" a little bit better. > > > > I worry that the "bridging" on the radio will become much more > > complicated if there is more than a point-2-point connection over the > > ethernet to one other device (router). > > > > Henning > > > > On Wed, Dec 17, 2014 at 3:20 AM, Stan Ratliff > wrote: > > > Henning, > > > > > > The co-authors have been having some discussions with regard to > deployments > > > that have multiple end-stations (for example, laptops, cameras, VoIP > phones, > > > sensors, etc), and not necessarily a router. In this type of > deployment, > > > some (though not all) radios may have a router for access "upstream" > into a > > > network (like, for example, a reach-back to some "home office", > perhaps via > > > satellite), but not necessarily all of the radios. > > > > > > Regards, > > > Stan > > > > > > On Tue, Dec 16, 2014 at 12:27 PM, Henning Rogge > wrote: > > >> > > >> On Tue, Dec 16, 2014 at 5:52 PM, Rick Taylor > > >> wrote: > > >> > Justin, All, > > >> > > > >> > As a heads up, there is some new functionality that MAY be added t= o > a > > >> > draft-08: Multiple devices at a destination. > > >> > > >> You mean (as an example) radios with multiple interfaces? > > >> > > >> We have thought about this at our institute too but our best idea is > > >> to address each radio "line" over a pre-configured VLAN tag. Similar > > >> to the usecase where you want to connect multiple physical radios ov= er > > >> a VLAN-capable switch to a single ethernet port of the router. > > >> > > >> Henning > > >> > > >> _______________________________________________ > > >> manet mailing list > > >> manet@ietf.org > > >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > --001a11c261fc668177050a6cd3d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I respectfully disagree with you on both points.
=C2=A0
"I=E2=80=99m not worried at al on DLEP overhea= d. It is local traffic and mostly incremental updates."
=C2= =A0- As strictly defined, that is true. However, the presentation of (for e= xample) Destination Update for metrics to some remote destination implies t= hat *some sort* of OTA signaling has occurred to obtain those metrics in th= e first place. Especially in multi-hop mesh networks.

"How the= radio=E2=80=99s handle 1200+ MAC addresses: interesting topic, but not rel= ated to DLEP."
- Not if you are a radio vendor, are looking = at supporting DLEP, and are concerned about winging that much state informa= tion across your precious RF network, in order to present the "Destina= tion Up" and "Destination Update" orders to some small numbe= r of routers.
=C2=A0
Regards,
Stan

On Wed, Dec 17, = 2014 at 12:04 PM, Teco Boot <teco@inf-net.nl> wrote:I=E2=80=99m not worried at al on DLEP overhead. It is = local traffic and mostly incremental updates.

How the radio=E2=80=99s handle 1200+ MAC addresses: interesting topic, but = not related to DLEP.

Teco


> Op 17 dec. 2014, om 15:45 heeft Stan Ratliff <ratliffstan@gmail.com> het volgende geschreven:<= br> >
> Henning,
>
> I'll give it a go. Let's assume a MANET deployment where some = number ("N") of vehicles are deployed. Each of those vehicles has= some number of laptops, a VoIP phone (or two), a video camera, and some ot= her sensors - for a total of 12 devices. This setup with the radio and 12 d= evices is my "standard kit" - I put that standard kit into almost= every vehicle I have in my fleet. Additionally, the deployment has a small= number (let's say 3) of "VIP Vehicles" - those vehicles have= multiple radios, satcom for reach-back, and most importantly, a router. >
> So now, I take 100 vehicles with the "standard kit", plus my= 3 " VIP Vehicles", and deploy them. I contend that with regard t= o the vehicles having the "standard kit", DLEP doesn't have a= n effect unless each and every device is declared as a DLEP "Destinati= on" (via presentation of a 'Destination Up' order). You see, w= e've been concentrating on deployments where every radio has a *router*= attached to it, and then all devices are attached "behind" the r= outer. So from a DLEP perspective, there's just 1 DLEP "destinatio= n" per radio (that 'destination' being the router). I believe = that works quite well. But in the case I've described, where a lot of t= he radios don't have a router installed, DLEP doesn't scale well - = in my little example, the psuedo-Ethernet segment created by the radios wil= l have 1,200+ MAC addresses on it (12 devices per vehicle, 100 vehicles - t= he classic "M*N" scalability problem). Each of those MAC addresse= s should be identified by a DLEP "Destination Up"; and they would= also need their own "Destination Update" orders if/when the RF c= haracteristics change - that gets unwieldy pretty fast.
>
> So, that's what we mean by the "multiple destinations" v= erbiage, and we've been discussing some ideas to reduce the DLEP overhe= ad in those deployment scenarios. It's not really new functionality; mo= re of things like:
> - Can a "Destination Up" order contain more than 1 MAC addre= ss TLV? (I believe the answer to that is 'yes')
> - If a "Destination Up" order contains more than 1 Mac Addre= ss TLV, then how are the associated IPv4 Address and IPv6 address TLVs proc= essed? (I believe the answer to that is "positionally" e.g., the = DLEP buffer looks something like MAC TLV 1/IPv4 Addr TLV 1/MAC TLV 2/IPv4 A= ddr TLV 2/IPv6 Addr TLV 2; but the document is not clear on that, and needs= to be explicit in that area.).
> - Is there a reasonably straightforward way in DLEP to effectively say= "The data rate *to the remote radio* is <blah>", allowing = a single "Destination Update" order to convey metrics for multipl= e MAC addresses across the RF link? (I believe the answer to that question = is "Not in DLEP-07, but I think there is a straightforward "tweak= " to the protocol to let us do that.")
>
> Now, the "is there a way to reference the remote radio itself, in= stead of all of its connected devices" issue also led us to reconsider= the notion that has been described as "Layer 3 DLEP" - that bein= g, radio devices having sufficient Layer 3 smarts to be able to receive a f= rame, and re-write the Layer 2 header for subsequent egress, based on an IP= address lookup. Personally, I believe that once you've created a way t= o reference just the remote modem, doing this type of "gateway operati= on" *IN LIEU OF" the "transparent bridge mode" we all k= now and love (hate?) isn't a large step at all...
>
> Hopefully, that helps make things clearer. I'm *really* hoping I h= aven't muddied the waters... ;-)
>
> Regards,
> Stan
>
> On Wed, Dec 17, 2014 at 1:58 AM, Henning Rogge <hrogge@gmail.com> wrote:
> Hi Stan,
>
> maybe I missunderstood Rick and you can explain the "multiple
> destinations" a little bit better.
>
> I worry that the "bridging" on the radio will become much mo= re
> complicated if there is more than a point-2-point connection over the<= br> > ethernet to one other device (router).
>
> Henning
>
> On Wed, Dec 17, 2014 at 3:20 AM, Stan Ratliff <ratliffstan@gmail.com> wrote:
> > Henning,
> >
> > The co-authors have been having some discussions with regard to d= eployments
> > that have multiple end-stations (for example, laptops, cameras, V= oIP phones,
> > sensors, etc), and not necessarily a router. In this type of depl= oyment,
> > some (though not all) radios may have a router for access "u= pstream" into a
> > network (like, for example, a reach-back to some "home offic= e", perhaps via
> > satellite), but not necessarily all of the radios.
> >
> > Regards,
> > Stan
> >
> > On Tue, Dec 16, 2014 at 12:27 PM, Henning Rogge <hrogge@gmail.com> wrote:
> >>
> >> On Tue, Dec 16, 2014 at 5:52 PM, Rick Taylor
> >> <rick@tr= opicalstormsoftware.com> wrote:
> >> > Justin, All,
> >> >
> >> > As a heads up, there is some new functionality that MAY = be added to a
> >> > draft-08: Multiple devices at a destination.
> >>
> >> You mean (as an example) radios with multiple interfaces?
> >>
> >> We have thought about this at our institute too but our best = idea is
> >> to address each radio "line" over a pre-configured = VLAN tag. Similar
> >> to the usecase where you want to connect multiple physical ra= dios over
> >> a VLAN-capable switch to a single ethernet port of the router= .
> >>
> >> Henning
> >>
> >> _______________________________________________
> >> manet mailing list
> >> manet@ietf.org
> >> https://www.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--001a11c261fc668177050a6cd3d3-- From nobody Wed Dec 17 09:38:12 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C741A6F01 for ; Wed, 17 Dec 2014 09:38:11 -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 EKadfNmAYXKG for ; Wed, 17 Dec 2014 09:38:10 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948B21A6F0A for ; Wed, 17 Dec 2014 09:38:06 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so16605598wiw.8 for ; Wed, 17 Dec 2014 09:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=kEcuYnlOdScMhLp1WPgTXz1VAahdkV+zdLWmXnehezw=; b=luDZjWs2m92H3B3dMNiMXM+NXT/MqHpZfV3ZDTFB8KSZon+Khq8UJ2jieC/6EEtHw+ L2/dQYor+J47Q8z+80D6NZKZDOgxRvKEugwVjnMtie/PqEZ0AcdKo/7hsZu+yq8a73G7 nBae0lwZ8gcJhqW3jvqM34x8LZblq0oxKlQ2lHvTIQtvRe3ViZf/s+f7B3+KX0bEVatw 47HkKB6EQd10uF2KZyz3pybcfy2rpw5AKkaYvxCwIyp8RP9qGCugyqRj9XskrMRcO46e 0OFhwsGOa2/RjhewcEOtd9mQPfqZzXmPFFD9ls8BYuMoqAFPwqgZ5Gn0anA2s1N9wovs 26xA== X-Received: by 10.194.8.34 with SMTP id o2mr75667546wja.129.1418837885273; Wed, 17 Dec 2014 09:38:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Wed, 17 Dec 2014 09:37:45 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> From: Henning Rogge Date: Wed, 17 Dec 2014 18:37:45 +0100 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ELStEhB0Xou6HUfn56gEa0l3GWI Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:38:11 -0000 On Wed, Dec 17, 2014 at 6:30 PM, Stan Ratliff wrote= : > I respectfully disagree with you on both points. > > "I=E2=80=99m not worried at al on DLEP overhead. It is local traffic and = mostly > incremental updates." > - As strictly defined, that is true. However, the presentation of (for > example) Destination Update for metrics to some remote destination implie= s > that *some sort* of OTA signaling has occurred to obtain those metrics in > the first place. Not necessarily... it could be just local measurement or settings, e.g. link speed to neighbor or signal strength. Only the optional "IP address" thing will definitely require a "magical" OTA component. And this OTA component is not part of DLEP. > "How the radio=E2=80=99s handle 1200+ MAC addresses: interesting topic, b= ut not > related to DLEP." > - Not if you are a radio vendor, are looking at supporting DLEP, and are > concerned about winging that much state information across your precious = RF > network, in order to present the "Destination Up" and "Destination Update= " > orders to some small number of routers. Sorry, that doesn't make sense Stan. the question "how does radio X knows where to send mac Y over the air" is not relevant for DLEP. DLEP is just for transmitting the local knowledge of the radio to the attached router (and some control in the opposite direction). The radios can do all kinds of tricks between each other to save airtime... the question is do we need this kind of thing for the local connection between radio and router. But... I think this "bundle X mac addresses together into a neighbor" might be relevant for queuing. It doesn't make much sense to allocate multiple queues for priorization and QoS for multiple mac addresses behind a single OTA link. So the knowledge "these 5 mac addresses are the same radio link" could still be useful. Henning From nobody Wed Dec 17 09:39:19 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287381A1BD9 for ; Wed, 17 Dec 2014 09:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 BlX2cAkyzd9E for ; Wed, 17 Dec 2014 09:39:07 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381F01A1A86 for ; Wed, 17 Dec 2014 09:39:07 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id 10so13235594lbg.29 for ; Wed, 17 Dec 2014 09:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6NRbUygNlMPNzxLNMKHQ7/bzFsB0RRyDaEne9kUcqGA=; b=VnLCPJswefO3d+Z1lU0XUU/QMF46Y0PS19S4ABhLv4cAorPqeuJZoddzp5Xr5fcpVW DaNzYWy3+9BfDxayKAk65LO7JkV1yFgLDd7jeHD5rcdgkYoBL+kk+eZZ0e2RzDzAAp+I 3Zcd0EsJtiSy5XxkGkU/jJVZ4DdgZXyhSj0DrIVzoGKD32108fqdM5H3Ea2dhNP7Y9mE X2d/XYbumehfdeEeqsUNmeqarX3Up5gZcjBQLgZgsW28HFa9qCLCQ3987oCDsPxGddp2 ikMld5+AtP2guPCdcOs1UO/vXKQSVnSc+UrF4gmQWROMokKkTa6+OgIHIHbK27NAKZdC 8teA== MIME-Version: 1.0 X-Received: by 10.112.198.233 with SMTP id jf9mr22260233lbc.9.1418837945707; Wed, 17 Dec 2014 09:39:05 -0800 (PST) Received: by 10.25.85.201 with HTTP; Wed, 17 Dec 2014 09:39:05 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> Date: Wed, 17 Dec 2014 12:39:05 -0500 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11c32cf4bf7193050a6cf380 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yxNqXoLUXHnp4HtqTzGkqhmHmo0 Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:39:12 -0000 --001a11c32cf4bf7193050a6cf380 Content-Type: text/plain; charset=UTF-8 "I don't like the "positional" thing... at the moment we don't have TLVs depending on each other (and the order of TLVs), but this could complicate things." Then we need to come to closure and consensus on this item, and quickly. IMO, this needs to be better documented than it is in DLEP-07, because, as I mentioned, an implementation *can* supply multiple MAC address TLVs. In that case, TLVs like the IPv4/IPv6 address TLVs MUST be correlated to the correct MAC address TLV. If you're not happy with positional correlation, do you have an alternative? I have concerns about the "combined MAC-IP" TLV you mention, as it does not comprehend the notion of running dual-stack (IPv4 and IPv6) implementations, nor does it comprehend that a device can have multiple IP addresses. As for Teco's response - presentation of (for example) "Destination Update" pretty much implies that some implementation-specific OTA signaling has indeed occurred. Otherwise, how would my local radio have the metrics in the first place, *especially* in a multi-hop mesh implentation? Same thing goes with number of directly-connected MAC addresses - some OTA signalling is implied. One way or another, we as a WG need to address these issues - either fix them (which I think we can), or state they are out of scope (which, I believe, will hamper radio adoption of the standard). Regards, Stan On Wed, Dec 17, 2014 at 12:27 PM, Henning Rogge wrote: > > On Wed, Dec 17, 2014 at 3:45 PM, Stan Ratliff > wrote: > > Henning, > > > > I'll give it a go. Let's assume a MANET deployment where some number > ("N") > ... > > "Destination Update" orders if/when the RF characteristics change - that > > gets unwieldy pretty fast. > > So we keep the DLEP assumption that the DLEP "radio" still forward > everything (not DLEP/internal service) between radio interface and > ethernet. Okay... > > > So, that's what we mean by the "multiple destinations" verbiage, and > we've > > been discussing some ideas to reduce the DLEP overhead in those > deployment > > scenarios. It's not really new functionality; more of things like: > > - Can a "Destination Up" order contain more than 1 MAC address TLV? (I > > believe the answer to that is 'yes') > > I think Rick was talking about an "radio neighbor identifier" to have > an abstraction between mac address and radio neighbor identity. > > > - If a "Destination Up" order contains more than 1 Mac Address TLV, then > how > > are the associated IPv4 Address and IPv6 address TLVs processed? (I > believe > > the answer to that is "positionally" e.g., the DLEP buffer looks > something > > like MAC TLV 1/IPv4 Addr TLV 1/MAC TLV 2/IPv4 Addr TLV 2/IPv6 Addr TLV 2; > > but the document is not clear on that, and needs to be explicit in that > > area.). > > I don't like the "positional" thing... at the moment we don't have > TLVs depending on each other (and the order of TLVs), but this could > complicate things. > If its a "one-to-one" mapping, we could introduce a combined "Mac-IP" > TLV which contains both mac and TLV... thats easier to parse (but > still ugly as a concept). > > As Teco said overhead is not that important for DLEP... its used on a > fast local ethernet link. > > And if you always have 10 devices in your cars behind your radio, > maybe one of them should just work as an IP router. > > Henning Rogge > --001a11c32cf4bf7193050a6cf380 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"I don't like the "positional" thi= ng... at the moment we don't have TLVs depending on each other (and the= order of TLVs), but this could complicate things."
=C2=A0
Then we need to come to closure and consensus on this item, and qu= ickly. IMO, this needs to be better documented than it is in DLEP-07, becau= se, as I mentioned, an implementation *can* supply multiple MAC address TLV= s. In that case,=C2=A0TLVs like the IPv4/IPv6 address TLVs MUST be correlat= ed to the correct MAC address TLV. If you're not happy with positional = correlation, do you have an alternative? I have concerns about the "co= mbined MAC-IP" TLV you mention, as it does not comprehend the notion o= f running dual-stack (IPv4 and IPv6) implementations, nor does it comprehen= d that a device can have multiple IP addresses.
=C2=A0
=C2=A0
=C2=A0
As for Teco's response - presentatio= n of (for example) "Destination Update" pretty much implies that = some implementation-specific OTA signaling has indeed occurred. Otherwise, = how would my local radio have the metrics in the first place, *especially* = in a multi-hop mesh implentation? Same thing goes with number of directly-c= onnected MAC addresses - some OTA signalling is implied.
=C2=A0<= /div>
One way or another, we as a WG need to address these issues - eit= her fix them (which I think we can), or state they are out of scope (which,= I believe, will hamper radio adoption of the standard).
=C2=A0<= /div>
Regards,
Stan

On Wed, Dec 17, 2014 at 12:27 PM, Henning Rogge <hrogg= e@gmail.com> wrote:
On Wed, Dec= 17, 2014 at 3:45 PM, Stan Ratliff <ratliffstan@gmail.com> wrote:
> Henning,
>
> I'll give it a go. Let's assume a MANET deployment where some = number ("N")
...
> "Destination Update" orders if/when the RF characteristics c= hange - that
> gets unwieldy pretty fast.

So we keep the DLEP assumption that the DLEP "radio" still forwar= d
everything (not DLEP/internal service) between radio interface and
ethernet. Okay...

> So, that's what we mean by the "multiple destinations" v= erbiage, and we've
> been discussing some ideas to reduce the DLEP overhead in those deploy= ment
> scenarios. It's not really new functionality; more of things like:=
> - Can a "Destination Up" order contain more than 1 MAC addre= ss TLV? (I
> believe the answer to that is 'yes')

I think Rick was talking about an "radio neighbor identifier" to = have
an abstraction between mac address and radio neighbor identity.

> - If a "Destination Up" order contains more than 1 Mac Addre= ss TLV, then how
> are the associated IPv4 Address and IPv6 address TLVs processed? (I be= lieve
> the answer to that is "positionally" e.g., the DLEP buffer l= ooks something
> like MAC TLV 1/IPv4 Addr TLV 1/MAC TLV 2/IPv4 Addr TLV 2/IPv6 Addr TLV= 2;
> but the document is not clear on that, and needs to be explicit in tha= t
> area.).

I don't like the "positional" thing... at the moment we don&#= 39;t have
TLVs depending on each other (and the order of TLVs), but this could
complicate things.
If its a "one-to-one" mapping, we could introduce a combined &quo= t;Mac-IP"
TLV which contains both mac and TLV... thats easier to parse (but
still ugly as a concept).

As Teco said overhead is not that important for DLEP... its used on a
fast local ethernet link.

And if you always have 10 devices in your cars behind your radio,
maybe one of them should just work as an IP router.

Henning Rogge
--001a11c32cf4bf7193050a6cf380-- From nobody Wed Dec 17 09:47:24 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CB51A6FC7 for ; Wed, 17 Dec 2014 09:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 43tGLXttxDt8 for ; Wed, 17 Dec 2014 09:47:20 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF651A6FB2 for ; Wed, 17 Dec 2014 09:47:20 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id u10so13391482lbd.34 for ; Wed, 17 Dec 2014 09:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bx5nr83sS0ikhEwiVhtcaMQwqNMAFEFVN71EKeiM5tE=; b=GE/gDNmTWO0DvEeRez4xgYpIs+TJW7oxJc7t5XAfh8bmKIEmkhOkA+DuOZkBilw069 8Rw+K9ECBwhtUiGnGwpXuZ2niG+u2SdGCdYf6uFsagm6F2jxIoiifbEvI+dmdgDL1lrT RU0rnS4xW+Hc4uTnvgl+uoUZdavGzjnrw5ED8S+EwpIjwCEaW60aNtJABG8lNfr6rSLo Ugeu4/yh6PtBgKpSLvu5mVtrMJVIjzfzwix2TyVwzhPP/a8b5Yx1z1fagRcDKUr1YpF/ 1QhNhv/92ZsnEgrpuHWsgQEPfNEfHsJDEQLjKeJvGhgji2bV9PQqbp5DUccJSIPDwe6e X0jQ== MIME-Version: 1.0 X-Received: by 10.152.26.201 with SMTP id n9mr36096111lag.50.1418838438537; Wed, 17 Dec 2014 09:47:18 -0800 (PST) Received: by 10.25.85.201 with HTTP; Wed, 17 Dec 2014 09:47:18 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> Date: Wed, 17 Dec 2014 12:47:18 -0500 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=089e0160a7061f6ddb050a6d11d6 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/lKb9jgdCg-ZCHSHa1cjZjnZHgGE Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:47:22 -0000 --089e0160a7061f6ddb050a6d11d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think we're going to have to combine the two active threads into one... that said, I'll address a couple of your comments here. "Not necessarily... it could be just local measurement or settings, e.g. link speed to neighbor or signal strength." Yes, and in your single-RF-hop, 802.11 implementation, that probably works well. But in a multi-hop mesh networking scenario, some OTA signaling will be required. "Sorry, that doesn't make sense Stan. the question "how does radio X knows where to send mac Y over the air" is not relevant for DLEP." Yes, that question is irrelevant. It's also NOT the question I'm addressing. In my new job, I now have concerns about implementing DLEP, based on the amount of state data that would need to be flung across the RF network in those types of deployments. It's not that "radio X knows *where* to send mac Y...", it's that radio X (DLEP-wise) has to know that MAC Y *exists*, *and* know metrics to Y. And in a 1,200 MAC deployment, that's a lot of state. Regards, Stan On Wed, Dec 17, 2014 at 12:37 PM, Henning Rogge wrote: > > On Wed, Dec 17, 2014 at 6:30 PM, Stan Ratliff > wrote: > > I respectfully disagree with you on both points. > > > > "I=E2=80=99m not worried at al on DLEP overhead. It is local traffic an= d mostly > > incremental updates." > > - As strictly defined, that is true. However, the presentation of (for > > example) Destination Update for metrics to some remote destination > implies > > that *some sort* of OTA signaling has occurred to obtain those metrics = in > > the first place. > > Not necessarily... it could be just local measurement or settings, > e.g. link speed to neighbor or signal strength. > > Only the optional "IP address" thing will definitely require a > "magical" OTA component. And this OTA component is not part of DLEP. > > > "How the radio=E2=80=99s handle 1200+ MAC addresses: interesting topic,= but not > > related to DLEP." > > - Not if you are a radio vendor, are looking at supporting DLEP, and ar= e > > concerned about winging that much state information across your preciou= s > RF > > network, in order to present the "Destination Up" and "Destination > Update" > > orders to some small number of routers. > > Sorry, that doesn't make sense Stan. > > the question "how does radio X knows where to send mac Y over the air" > is not relevant for DLEP. > > DLEP is just for transmitting the local knowledge of the radio to the > attached router (and some control in the opposite direction). > > The radios can do all kinds of tricks between each other to save > airtime... the question is do we need this kind of thing for the local > connection between radio and router. > > > But... > > I think this "bundle X mac addresses together into a neighbor" might > be relevant for queuing. It doesn't make much sense to allocate > multiple queues for priorization and QoS for multiple mac addresses > behind a single OTA link. So the knowledge "these 5 mac addresses are > the same radio link" could still be useful. > > Henning > --089e0160a7061f6ddb050a6d11d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think we're going to have to combine the two ac= tive threads into one... that said, I'll address a couple of your comme= nts here.
=C2=A0
"Not necessarily... it could be = just local measurement or settings, e.g. link speed to neighbor or signal s= trength."
Yes, and in your single-RF-hop, 802.11 implementat= ion, that probably works well. But in a multi-hop mesh networking scenario,= some OTA signaling will be required.
=C2=A0
"Sor= ry, that doesn't make sense Stan.

the question "how does ra= dio X knows where to send mac Y over the air"
is not relevant for D= LEP."
=C2=A0
Yes, that question is irrelevant. It&= #39;s also NOT the question I'm addressing. In my new job, I now have c= oncerns about implementing DLEP, based on the amount of state data that wou= ld need to be flung across the RF network in those types of deployments. It= 's not that "radio X knows *where* to send mac Y...", it'= s that radio X (DLEP-wise) has to know that MAC Y *exists*, *and* know metr= ics to Y. And in a 1,200 MAC deployment, that's a lot of state.
<= div>=C2=A0
Regards,
Stan


=C2=A0
=

On Wed, Dec= 17, 2014 at 12:37 PM, Henning Rogge <hrogge@gmail.com> wrote= :
On Wed, Dec 17, 2014 at 6:30 PM, Stan Ratli= ff <ratliffstan@gmail.com&g= t; wrote:
> I respectfully disagree with you on both points.
>
> "I=E2=80=99m not worried at al on DLEP overhead. It is local traf= fic and mostly
> incremental updates."
>=C2=A0 - As strictly defined, that is true. However, the presentation o= f (for
> example) Destination Update for metrics to some remote destination imp= lies
> that *some sort* of OTA signaling has occurred to obtain those metrics= in
> the first place.

Not necessarily... it could be just local measurement or settings,
e.g. link speed to neighbor or signal strength.

Only the optional "IP address" thing will definitely require a "magical" OTA component. And this OTA component is not part of DL= EP.

> "How the radio=E2=80=99s handle 1200+ MAC addresses: interesting = topic, but not
> related to DLEP."
> - Not if you are a radio vendor, are looking at supporting DLEP, and a= re
> concerned about winging that much state information across your precio= us RF
> network, in order to present the "Destination Up" and "= Destination Update"
> orders to some small number of routers.

Sorry, that doesn't make sense Stan.

the question "how does radio X knows where to send mac Y over the air&= quot;
is not relevant for DLEP.

DLEP is just for transmitting the local knowledge of the radio to the
attached router (and some control in the opposite direction).

The radios can do all kinds=C2=A0 of tricks between each other to save
airtime... the question is do we need this kind of thing for the local
connection between radio and router.


But...

I think this "bundle X mac addresses together into a neighbor" mi= ght
be relevant for queuing. It doesn't make much sense to allocate
multiple queues for priorization and QoS for multiple mac addresses
behind a single OTA link. So the knowledge "these 5 mac addresses are<= br> the same radio link" could still be useful.

Henning
--089e0160a7061f6ddb050a6d11d6-- From nobody Wed Dec 17 09:57:12 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FD31A6FD6 for ; Wed, 17 Dec 2014 09:57:11 -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 Q-a91MNOktCY for ; Wed, 17 Dec 2014 09:57:09 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4CCC1A6F17 for ; Wed, 17 Dec 2014 09:57:09 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so16588081wiv.17 for ; Wed, 17 Dec 2014 09:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pkJVLBd2vrhHV+91MtRwOKGyp3hsBnaM5zxcA42F3+A=; b=VqhpjFbUyosfsAk6SK3zxf35VIHN5lvxIiyjsAgM1X6xqWFPOiTrdrlQVTqdrLwrbx kOJmylOCCi942IATSqGcCA3ZHYK4rM3jBpPBmSZAW4GSGFk3l07WpCiVvEddK1QKCK66 9EYfvJPECjRD0spS4Jlw5EzRnbevgxvbkjRn6p+5s9O3C9FEuByec6RbX03meMcwfHct ylHYxjcIzCpWomjQ4RxhOtc26e1D87/fynx4Kri0ASnOPsPpnY0gHcKD89mF/6OHn5yw dNk67IcsArGMCs8Y5HeCOYqXRp8P0jVC01Bmx8TuWRL30qiq7lzo1wk6RGvgdioLgpQ2 x1TQ== X-Received: by 10.180.107.193 with SMTP id he1mr16441911wib.69.1418839028313; Wed, 17 Dec 2014 09:57:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Wed, 17 Dec 2014 09:56:48 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> From: Henning Rogge Date: Wed, 17 Dec 2014 18:56:48 +0100 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/q4c_hYd34BfkySdsgop1EEHPWXE Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:57:11 -0000 **combining threads/answers** On Wed, Dec 17, 2014 at 6:39 PM, Stan Ratliff wrote: > Then we need to come to closure and consensus on this item, and quickly. > IMO, this needs to be better documented than it is in DLEP-07, because, as I > mentioned, an implementation *can* supply multiple MAC address TLVs. In that > case, TLVs like the IPv4/IPv6 address TLVs MUST be correlated to the correct > MAC address TLV. If you're not happy with positional correlation, do you > have an alternative? We could move the "announce IP address for MAC" into a message of its own. If you want to attach IPs (one or many) to a MAC, you send a "Announce IP address" message which contains a single MAC with a list of IPs. A new message always overwrites the list of IPs for the single MAC it referrs to, so we can use the same message for adding, changing or removing IPs. This works both with an "link id" concept or without it. On Wed, Dec 17, 2014 at 6:47 PM, Stan Ratliff wrote: > "Not necessarily... it could be just local measurement or settings, e.g. > link speed to neighbor or signal strength." > Yes, and in your single-RF-hop, 802.11 implementation, that probably works > well. But in a multi-hop mesh networking scenario, some OTA signaling will > be required. So you are talking about the "layer-2 mesh" radio with DLEP. > Yes, that question is irrelevant. It's also NOT the question I'm addressing. > In my new job, I now have concerns about implementing DLEP, based on the > amount of state data that would need to be flung across the RF network in > those types of deployments. It's not that "radio X knows *where* to send mac > Y...", it's that radio X (DLEP-wise) has to know that MAC Y *exists*, *and* > know metrics to Y. And in a 1,200 MAC deployment, that's a lot of state. No, it does not. Okay, yes it needs to know, but not necessarily in an inefficient way. The radio could do the "mac address" and the "link id/metric" thing completely separate to be very efficient... a good example would be a slow radio that just use a 1-byte "radio id" on the air and use a small layer-2 protocol to announce the local mac address(es). But these optimizations for the radio link are completely orthogonal to the DLEP communication on the local ethernet. You want a very efficient protocol OTA to separate mac address gathering and link metrics/state calculation? Fine, do so... but why do we need to change DLEP for this? as I said above, the "link vs. multiple mac addresses" concept in DLEP might be relevant for flow control... but I don't see it necessary as optimization. DLEP is not transmitted over the air. Henning Rogge From nobody Wed Dec 17 10:20:59 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922A61A1BE0 for ; Wed, 17 Dec 2014 10:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 RtH_dAtqoC5S for ; Wed, 17 Dec 2014 10:20:53 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987A81A1BD9 for ; Wed, 17 Dec 2014 10:20:52 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id u10so13335375lbd.17 for ; Wed, 17 Dec 2014 10:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nopkiHcUFwCaC0tgy/I7HPmHGbFurXnBvW2ItzqBPSg=; b=gxp42XWWqzxH0QFS+y7TCIc3lcqVcVU6nzhlSNQ+mtg9Ff4oWS/Uqfjq57kzbV3n3I BBc9usXiqVrJKKQn7V4mFdIo3pk4/afQBFdhND7cUQDhM5Au8m7XaZVLX8oRDkCvQe9B J/vENrbufwAdVKzSnnXSArk8qz0oQVUv1BZqng44N1vy9p4/dSUn0L4wyCqBZfUmC8RJ AK8H0CYcnkphpKri+omw7jf2TMBxOD/3cOrW8iWgY7MaSlcwsImdtFEJGH0BAcwEhdZZ c3lVv5uJWanwJKtTuxkPwZM9RC59WEpogaLyiGmV1uZhDLNxKtYGvRRqLVJARubyYPGH YJiw== MIME-Version: 1.0 X-Received: by 10.112.41.168 with SMTP id g8mr42177000lbl.59.1418840451047; Wed, 17 Dec 2014 10:20:51 -0800 (PST) Received: by 10.25.85.201 with HTTP; Wed, 17 Dec 2014 10:20:50 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> Date: Wed, 17 Dec 2014 13:20:50 -0500 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11345d7613e66b050a6d8960 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/pzKDSLDUPPe61np4rNdJIyT_VqU Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 18:20:56 -0000 --001a11345d7613e66b050a6d8960 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 17, 2014 at 12:56 PM, Henning Rogge wrote: > > **combining threads/answers** > > On Wed, Dec 17, 2014 at 6:39 PM, Stan Ratliff > wrote: > > Then we need to come to closure and consensus on this item, and quickly. > > IMO, this needs to be better documented than it is in DLEP-07, because, > as I > > mentioned, an implementation *can* supply multiple MAC address TLVs. In > that > > case, TLVs like the IPv4/IPv6 address TLVs MUST be correlated to the > correct > > MAC address TLV. If you're not happy with positional correlation, do you > > have an alternative? > > We could move the "announce IP address for MAC" into a message of its own. > > If you want to attach IPs (one or many) to a MAC, you send a "Announce > IP address" message which contains a single MAC with a list of IPs. A > new message always overwrites the list of IPs for the single MAC it > referrs to, so we can use the same message for adding, changing or > removing IPs. > > This works both with an "link id" concept or without it. > Yes, that might work. But I would contend that adding a statement into the Destination Up/Destination Update/Destination Down descriptions saying "Implementations MUST insert one AND ONLY one MAC Address TLV into this order" accomplishes the same thing. I mentioned that in the email between co-authors and got a negative response on it. No need to invent additional protocol unless we need it. > > On Wed, Dec 17, 2014 at 6:47 PM, Stan Ratliff > wrote: > > "Not necessarily... it could be just local measurement or settings, e.g. > > link speed to neighbor or signal strength." > > Yes, and in your single-RF-hop, 802.11 implementation, that probably > works > > well. But in a multi-hop mesh networking scenario, some OTA signaling > will > > be required. > > So you are talking about the "layer-2 mesh" radio with DLEP. > > > Yes, that question is irrelevant. It's also NOT the question I'm > addressing. > > In my new job, I now have concerns about implementing DLEP, based on the > > amount of state data that would need to be flung across the RF network in > > those types of deployments. It's not that "radio X knows *where* to send > mac > > Y...", it's that radio X (DLEP-wise) has to know that MAC Y *exists*, > *and* > > know metrics to Y. And in a 1,200 MAC deployment, that's a lot of state. > > No, it does not. > > Okay, yes it needs to know, but not necessarily in an inefficient way. > :-) > > The radio could do the "mac address" and the "link id/metric" thing > completely separate to be very efficient... a good example would be a > slow radio that just use a 1-byte "radio id" on the air and use a > small layer-2 protocol to announce the local mac address(es). > > But these optimizations for the radio link are completely orthogonal > to the DLEP communication on the local ethernet. > Not exactly. Consider for a moment that we introduce the concept of a "Unique Link ID", and mandate that it be carried on all destination messages (e.g. Destination Up/Destination Update/Destination Down). Further, we mandate that this "Unique Link ID" be a searchable key on all DLEP destinations. Effectively, the "Unique Link ID" maps 1-to-1 to a remote modem. Then, we can allow implementations to issue Destination Update, with *just* the "Unique Link ID" and metrics specified. Those metrics would be applied to *all* destinations (e.g. MAC addresses) with the Unique Link ID. Same thing with "Destination Down" - if the Destination Down is received with *just* the Unique Link ID specified, then *all* destinations with that Unique Link ID are considered down. Note that this does NOT preclude an implementation from issueing Destination Up/Destination Update/Destination Down with *both* the Unique Link ID *and* a MAC Address TLV specified. In that case the receiver would process it as today - for example, a Destination Update with both the Unique Link ID and a MAC would apply the metrics ONLY to the specified MAC. Same thing with Destinatio Down - ONLY the specified MAC address would be brought down. This (relatively easy, IMO) extension removes most of the heartburn I've got with the deployment scenario I initially documented, since it allows metrics to be produced on a "REMOTE modem-wide" basis. Different than metrics in the Peer Update, which apply at a local (all sessions through *my* radio) level. Regards, Stan > > You want a very efficient protocol OTA to separate mac address > gathering and link metrics/state calculation? Fine, do so... but why > do we need to change DLEP for this? > > as I said above, the "link vs. multiple mac addresses" concept in DLEP > might be relevant for flow control... but I don't see it necessary as > optimization. DLEP is not transmitted over the air. > > Henning Rogge > --001a11345d7613e66b050a6d8960 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Dec 17, 2014 at 12:56 PM, Henning Rogge <hrogge@gmail.com> wrote:
**combining threads/answers**

On Wed, Dec 17, 2014 at 6:39 PM, Stan Ratliff <ratliffstan@gmail.com> wrote:
> Then we need to come to closure and consensus on this item, and quickl= y.
> IMO, this needs to be better documented than it is in DLEP-07, because= , as I
> mentioned, an implementation *can* supply multiple MAC address TLVs. I= n that
> case, TLVs like the IPv4/IPv6 address TLVs MUST be correlated to the c= orrect
> MAC address TLV. If you're not happy with positional correlation, = do you
> have an alternative?

We could move the "announce IP address for MAC" into a message of= its own.

If you want to attach IPs (one or many) to a MAC, you send a "Announce=
IP address" message which contains a single MAC with a list of IPs. A<= br> new message always overwrites the list of IPs for the single MAC it
referrs to, so we can use the same message for adding, changing or
removing IPs.

This works both with an "link id" concept or without it.
=C2=A0
Yes, that might work. But I would contend tha= t adding a statement into the Destination Up/Destination Update/Destination= Down descriptions saying "Implementations MUST insert one AND ONLY on= e MAC Address TLV into this order" accomplishes the same thing. I ment= ioned that in the email between co-authors and got a negative response on i= t. No need to invent additional protocol unless we need it.
=C2= =A0
=C2=A0

On Wed, Dec 17, 2014 at 6:47 PM, Stan Ratliff <ratliffstan@gmail.com> wrote:
> "Not necessarily... it could be just local measurement or setting= s, e.g.
> link speed to neighbor or signal strength."
> Yes, and in your single-RF-hop, 802.11 implementation, that probably w= orks
> well. But in a multi-hop mesh networking scenario, some OTA signaling = will
> be required.

So you are talking about the "layer-2 mesh" radio with DLEP.

> Yes, that question is irrelevant. It's also NOT the question I'= ;m addressing.
> In my new job, I now have concerns about implementing DLEP, based on t= he
> amount of state data that would need to be flung across the RF network= in
> those types of deployments. It's not that "radio X knows *whe= re* to send mac
> Y...", it's that radio X (DLEP-wise) has to know that MAC Y *= exists*, *and*
> know metrics to Y. And in a 1,200 MAC deployment, that's a lot of = state.

No, it does not.

Okay, yes it needs to know, but not necessarily in an inefficient way.
<= /blockquote>
=C2=A0
:-)
=C2=A0

The radio could do the "mac address" and the "link id/metric= " thing
completely separate to be very efficient... a good example would be a
slow radio that just use a 1-byte "radio id" on the air and use a=
small layer-2 protocol to announce the local mac address(es).

But these optimizations for the radio link are completely orthogonal
to the DLEP communication on the local ethernet.
=C2= =A0
Not exactly.=C2=A0Consider for a moment that we=C2=A0introduc= e the concept of a "Unique Link ID", and mandate that it be carri= ed on all destination messages (e.g. Destination Up/Destination Update/Dest= ination Down). Further, we=C2=A0mandate that this "Unique Link ID"= ; be a searchable key on all DLEP destinations. Effectively, the "Uniq= ue Link ID" maps 1-to-1 to a remote modem.
=C2=A0
Then, we can allow implementations to issue Destination Update, with *just= * the "Unique Link ID" and metrics specified. Those metrics would= be applied to *all* destinations (e.g. MAC addresses) with the Unique Link= ID. Same thing with "Destination Down" - if the Destination Down= is received with *just* the Unique Link ID specified, then *all* destinati= ons with that Unique Link ID are considered down.
=C2=A0
Note that this does NOT preclude an implementation from issueing Destina= tion Up/Destination Update/Destination Down with *both* the Unique Link ID = *and* a MAC Address TLV specified. In that case the receiver would process = it as today -=C2=A0for example, a Destination Update with both the Unique L= ink ID and a MAC would apply the metrics ONLY to the specified MAC.=C2=A0 S= ame thing with Destinatio Down - ONLY the specified MAC address would be br= ought down.
=C2=A0
This (relatively easy, IMO) extensi= on removes most of the heartburn I've got with the deployment scenario = I initially documented, since it allows metrics to be produced on a "R= EMOTE modem-wide" basis. Different than metrics in the Peer Update, wh= ich apply at a local (all sessions through *my* radio) level.
= =C2=A0
Regards,
Stan
=C2=A0
=C2=A0<= /div>

You want a very efficient protocol OTA to separate mac address
gathering and link metrics/state calculation? Fine, do so... but why
do we need to change DLEP for this?

as I said above, the "link vs. multiple mac addresses" concept in= DLEP
might be relevant for flow control... but I don't see it necessary as optimization. DLEP is not transmitted over the air.

Henning Rogge
--001a11345d7613e66b050a6d8960-- From nobody Wed Dec 17 10:41:50 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55ECB1A1BBE for ; Wed, 17 Dec 2014 10:41:49 -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 fwJch5P4exCQ for ; Wed, 17 Dec 2014 10:41:47 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E0A1A1B75 for ; Wed, 17 Dec 2014 10:41:47 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so17120041wiv.14 for ; Wed, 17 Dec 2014 10:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ksGC10j/4Y51TBHu9HDUKCo/lujBJT+dIi2qjnJFwlI=; b=G/0P/FHGSbs23JLpnhNqsDA5LnrayWq99TGVTifbrnTUbahYNa2wfJkp2KFLRWGn2J ZZ7e5aCntWDGS5u4+6svTIcyBlcCN6fY+e1MIs6/98Cpz8wvOqKZTAPTnEluSzXb8k7r y2oPTyiTSUzq8vp0hTb87plzkT5jHOB37YXMrAO3l7SV2p/Sge8J+cVKDU8Ezgvt4QdY vmX13F5K92GJPL/+C9Sp6pjOmfkOCF3Ad1VSxaK68Q9gRraCrVyO2eEG+kXPIWKPOYGB uMTi7halJcV9psY8HooL41P1L/N0RN5d2elz7im/XZDqe5GVGWwX9sNwwtqSakdJgnJc V/Iw== X-Received: by 10.194.191.227 with SMTP id hb3mr76246487wjc.79.1418841706207; Wed, 17 Dec 2014 10:41:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Wed, 17 Dec 2014 10:41:25 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> From: Henning Rogge Date: Wed, 17 Dec 2014 19:41:25 +0100 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CnCrUaMbcXrUetnLdUb4o-8uQU0 Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 18:41:49 -0000 On Wed, Dec 17, 2014 at 7:20 PM, Stan Ratliff wrote: > Yes, that might work. But I would contend that adding a statement into the > Destination Up/Destination Update/Destination Down descriptions saying > "Implementations MUST insert one AND ONLY one MAC Address TLV into this > order" accomplishes the same thing. I mentioned that in the email between > co-authors and got a negative response on it. No need to invent additional > protocol unless we need it. Using the position could turn quite funny if you have both MACs with a single IP, MACs with multiple IPs and MACs without IPs. Yes, you can solve it, but suddenly you have to sort your MACs based on the IPs they have. > Not exactly. Consider for a moment that we introduce the concept of a > "Unique Link ID", and mandate that it be carried on all destination messages > (e.g. Destination Up/Destination Update/Destination Down). Further, we > mandate that this "Unique Link ID" be a searchable key on all DLEP > destinations. Effectively, the "Unique Link ID" maps 1-to-1 to a remote > modem. > > Then, we can allow implementations to issue Destination Update, with *just* > the "Unique Link ID" and metrics specified. Those metrics would be applied > to *all* destinations (e.g. MAC addresses) with the Unique Link ID. Same > thing with "Destination Down" - if the Destination Down is received with > *just* the Unique Link ID specified, then *all* destinations with that > Unique Link ID are considered down. > > Note that this does NOT preclude an implementation from issueing Destination > Up/Destination Update/Destination Down with *both* the Unique Link ID *and* > a MAC Address TLV specified. In that case the receiver would process it as > today - for example, a Destination Update with both the Unique Link ID and a > MAC would apply the metrics ONLY to the specified MAC. Same thing with > Destinatio Down - ONLY the specified MAC address would be brought down. Do you really want a third hierarchy level for metrics? I see the use for "local radio" metrics... and the use for "remote radio" metrics... can you give a good example for "single mac behind a remote radio" metric? > This (relatively easy, IMO) extension removes most of the heartburn I've got > with the deployment scenario I initially documented, since it allows metrics > to be produced on a "REMOTE modem-wide" basis. Different than metrics in the > Peer Update, which apply at a local (all sessions through *my* radio) level. I see that this would be an additional feature for DLEP... but it will not save a single byte OTA... because the protocol is not used on the air interface. I still think the extension could be useful because it gives you a better knowledge about the radio topology. So I would be "+1" for adding a link-id to the Destination messages... but not because of some OTA efficiency concerns. Henning From nobody Wed Dec 17 11:28:15 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A326E1A8710 for ; Wed, 17 Dec 2014 11:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 XZ1FGNZTCwMr for ; Wed, 17 Dec 2014 11:28:10 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9550A1A8032 for ; Wed, 17 Dec 2014 11:28:09 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id hv19so13695740lab.0 for ; Wed, 17 Dec 2014 11:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vdOQUD0k2w/6+i4UIn2n7rM7aM6uecfiCr65r+KwDCs=; b=iCjCSlDSz3fwUlg0T0qm33ElFz8YdhO56hzUMYgMGg24cPqM9GCrszuj41Wl9wFrRO xW46JBg5ZAkqYAd7oVcwS+bsCJ0yayI001jtCUROzvc2TLaMn98BffD8rLADU0/2pk0N kJqmvg3T/smK0x2LdA1+LB5d4z6Tg47ieuxkeZRz26UG2jUh28XI1C90kDtMvF4eHBQZ 7rxntHDn1ofzAgaomgMliAgRWuK4E/6UqA93biT/Mn6rdfaZEcOefuYJFsSboS9qPNyA TerGGbcU6DgJkSU1JEo0T05hJ8Y1vfofpIIJOV6FEQhgzxxnyVMaInfqqa1zRJRMNi3W QTvg== MIME-Version: 1.0 X-Received: by 10.152.22.67 with SMTP id b3mr39706616laf.82.1418844488047; Wed, 17 Dec 2014 11:28:08 -0800 (PST) Received: by 10.25.85.201 with HTTP; Wed, 17 Dec 2014 11:28:07 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> Date: Wed, 17 Dec 2014 14:28:07 -0500 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=089e0158b86eb3a2e6050a6e79d5 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/GWPsAE62ymqxv3c_GpyLFurfwEg Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 19:28:12 -0000 --089e0158b86eb3a2e6050a6e79d5 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 17, 2014 at 1:41 PM, Henning Rogge wrote: > > On Wed, Dec 17, 2014 at 7:20 PM, Stan Ratliff > wrote: > > Yes, that might work. But I would contend that adding a statement into > the > > Destination Up/Destination Update/Destination Down descriptions saying > > "Implementations MUST insert one AND ONLY one MAC Address TLV into this > > order" accomplishes the same thing. I mentioned that in the email between > > co-authors and got a negative response on it. No need to invent > additional > > protocol unless we need it. > > Using the position could turn quite funny if you have both MACs with a > single IP, MACs with multiple IPs and MACs without IPs. > > Yes, you can solve it, but suddenly you have to sort your MACs based > on the IPs they have. > I'm a bit lost with this response. Seems to me that there are a couple of options on the table: 1. Implement an "Announce IP addresses for MAC" order, or 2. Limit Destination Up/Destination Update/Destination Down to AT MOST 1 MAC address TLV (the 0 MAC Address TLV would be the "Unique Link ID" case discussed below. Any other options? And which one is preferable (I vote for #2)?? > > > Not exactly. Consider for a moment that we introduce the concept of a > > "Unique Link ID", and mandate that it be carried on all destination > messages > > (e.g. Destination Up/Destination Update/Destination Down). Further, we > > mandate that this "Unique Link ID" be a searchable key on all DLEP > > destinations. Effectively, the "Unique Link ID" maps 1-to-1 to a remote > > modem. > > > > Then, we can allow implementations to issue Destination Update, with > *just* > > the "Unique Link ID" and metrics specified. Those metrics would be > applied > > to *all* destinations (e.g. MAC addresses) with the Unique Link ID. Same > > thing with "Destination Down" - if the Destination Down is received with > > *just* the Unique Link ID specified, then *all* destinations with that > > Unique Link ID are considered down. > > > > Note that this does NOT preclude an implementation from issueing > Destination > > Up/Destination Update/Destination Down with *both* the Unique Link ID > *and* > > a MAC Address TLV specified. In that case the receiver would process it > as > > today - for example, a Destination Update with both the Unique Link ID > and a > > MAC would apply the metrics ONLY to the specified MAC. Same thing with > > Destinatio Down - ONLY the specified MAC address would be brought down. > > Do you really want a third hierarchy level for metrics? > Not really, but you "get it for free"... > > I see the use for "local radio" metrics... and the use for "remote > radio" metrics... > > can you give a good example for "single mac behind a remote radio" metric? > A "good" example? That might be subjective... ;-) That said, I could see vendors implementing different metrics as a way of influencing flow-control. In order to get the flow control characteristics I want on the link, I'll tell you Device "A" has a 30Mbps link, while Device "B" only has 6Mbps. I don't mean to imply this is a "good" example, just one that people might employ. > > > This (relatively easy, IMO) extension removes most of the heartburn I've > got > > with the deployment scenario I initially documented, since it allows > metrics > > to be produced on a "REMOTE modem-wide" basis. Different than metrics in > the > > Peer Update, which apply at a local (all sessions through *my* radio) > level. > > I see that this would be an additional feature for DLEP... but it will > not save a single byte OTA... because the protocol is not used on the > air interface. > > I still think the extension could be useful because it gives you a > better knowledge about the radio topology. > > So I would be "+1" for adding a link-id to the Destination messages... > but not because of some OTA efficiency concerns. > Excuse me whilst I take your "+1" and run for the nearest exit.... ;-) ;-) ;-) ;-) Regards, Stan > > Henning > --089e0158b86eb3a2e6050a6e79d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 17, 2014 at 1:41 PM, Henning Rogge <hrogge@gmail.com>= ; wrote:
On Wed, Dec 17, 2014 at 7:20 = PM, Stan Ratliff <ratliffstan@g= mail.com> wrote:
> Yes, that might work. But I would contend that adding a statement into= the
> Destination Up/Destination Update/Destination Down descriptions saying=
> "Implementations MUST insert one AND ONLY one MAC Address TLV int= o this
> order" accomplishes the same thing. I mentioned that in the email= between
> co-authors and got a negative response on it. No need to invent additi= onal
> protocol unless we need it.

Using the position could turn quite funny if you have both MACs with a
single IP, MACs with multiple IPs and MACs without IPs.

Yes, you can solve it, but suddenly you have to sort your MACs based
on the IPs they have.

I'm a bit los= t with this response. Seems to me that there are a couple of options on the= table:=C2=A0
1. Implement an "Announce IP addresses for MAC= " order, or=C2=A0
2. Limit Destination Up/Destination Update= /Destination Down to AT MOST 1 MAC address TLV (the 0 MAC Address TLV would= be the "Unique Link ID" case discussed below.=C2=A0
An= y other options? And which one is preferable (I vote for #2)??
= =C2=A0

> Not exactly. Consider for a moment that we introduce the concept of a<= br> > "Unique Link ID", and mandate that it be carried on all dest= ination messages
> (e.g. Destination Up/Destination Update/Destination Down). Further, we=
> mandate that this "Unique Link ID" be a searchable key on al= l DLEP
> destinations. Effectively, the "Unique Link ID" maps 1-to-1 = to a remote
> modem.
>
> Then, we can allow implementations to issue Destination Update, with *= just*
> the "Unique Link ID" and metrics specified. Those metrics wo= uld be applied
> to *all* destinations (e.g. MAC addresses) with the Unique Link ID. Sa= me
> thing with "Destination Down" - if the Destination Down is r= eceived with
> *just* the Unique Link ID specified, then *all* destinations with that=
> Unique Link ID are considered down.
>
> Note that this does NOT preclude an implementation from issueing Desti= nation
> Up/Destination Update/Destination Down with *both* the Unique Link ID = *and*
> a MAC Address TLV specified. In that case the receiver would process i= t as
> today - for example, a Destination Update with both the Unique Link ID= and a
> MAC would apply the metrics ONLY to the specified MAC.=C2=A0 Same thin= g with
> Destinatio Down - ONLY the specified MAC address would be brought down= .

Do you really want a third hierarchy level for metrics?

Not really, but you "get it for free"...=C2=A0
=C2=A0

I see the use for "local radio" metrics... and the use for "= remote
radio" metrics...

can you give a good example for "single mac behind a remote radio"= ; metric?

A "good" example? T= hat might be subjective... ;-) =C2=A0That said, I could see vendors impleme= nting different metrics as a way of influencing flow-control. In order to g= et the flow control characteristics I want on the link, I'll tell you D= evice "A" has a 30Mbps link, while Device "B" only has = 6Mbps. I don't mean to imply this is a "good" example, just o= ne that people might employ.=C2=A0
=C2=A0

> This (relatively easy, IMO) extension removes most of the heartburn I&= #39;ve got
> with the deployment scenario I initially documented, since it allows m= etrics
> to be produced on a "REMOTE modem-wide" basis. Different tha= n metrics in the
> Peer Update, which apply at a local (all sessions through *my* radio) = level.

I see that this would be an additional feature for DLEP... but it will
not save a single byte OTA... because the protocol is not used on the
air interface.

I still think the extension could be useful because it gives you a
better knowledge about the radio topology.

So I would be "+1" for adding a link-id to the Destination messag= es...
but not because of some OTA efficiency concerns.

<= /div>
Excuse me whilst I take your "+1" and run for the neare= st exit.... ;-) ;-) ;-) ;-)=C2=A0

Regards,
Stan

=C2=A0

Henning
--089e0158b86eb3a2e6050a6e79d5-- From nobody Wed Dec 17 11:43:31 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA541A8033 for ; Wed, 17 Dec 2014 11:43:30 -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 VX6YDWxhmyEt for ; Wed, 17 Dec 2014 11:43:27 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BBE1A6FF0 for ; Wed, 17 Dec 2014 11:43:27 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so17281633wid.5 for ; Wed, 17 Dec 2014 11:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HnvDFrzSKoKo9p2sR8TFPv21/aaf3KiLWmWAgmlQYFI=; b=o7mIMXKbpMZgHONR6St7XcAH+8crtA6m31nfRmWFr5m9JGc2SLdlIf6GG581WK5v3z zI9hs/AYZz+4s/lVr13XsWTWmSP+Gz/MtYLmQoLD2HqaXADIOyObCyTk5NfWtFs662Fr aiglG4D0WHYUR+9JqSUC/thpvNRWjsYwB56zJAtjF2fkC2YbNUSxPn5wslqXZk42EyOj JNzd/46NqAtHPo+j462g5UcwD2tsPrTb3jff3MudyxtMHOAtDqIaU6fsT7tIz7R9Gz0o yz8XXkzeX0JWKZP/I2534RNnzJ2SsJ2nNSw9Yrvrh3i0/tx+5vZY/5k59zGD9ZORnNoU p4YA== X-Received: by 10.194.246.167 with SMTP id xx7mr75402723wjc.118.1418845405702; Wed, 17 Dec 2014 11:43:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Wed, 17 Dec 2014 11:43:05 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> From: Henning Rogge Date: Wed, 17 Dec 2014 20:43:05 +0100 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/U1CS3CJhycrtiyqMzFuIyWcgKS8 Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 19:43:30 -0000 On Wed, Dec 17, 2014 at 8:28 PM, Stan Ratliff wrote: >> > Yes, that might work. But I would contend that adding a statement into >> > the >> > Destination Up/Destination Update/Destination Down descriptions saying >> > "Implementations MUST insert one AND ONLY one MAC Address TLV into this >> > order" accomplishes the same thing. I mentioned that in the email >> > between >> > co-authors and got a negative response on it. No need to invent >> > additional >> > protocol unless we need it. >> >> Using the position could turn quite funny if you have both MACs with a >> single IP, MACs with multiple IPs and MACs without IPs. >> >> Yes, you can solve it, but suddenly you have to sort your MACs based >> on the IPs they have. > > > I'm a bit lost with this response. "Too much mails in the evening" error... yes, I thought we were still talking about the "multiple mac with each a single IP TLV" idea. Sorry. > Seems to me that there are a couple of > options on the table: > 1. Implement an "Announce IP addresses for MAC" order, or > 2. Limit Destination Up/Destination Update/Destination Down to AT MOST 1 MAC > address TLV (the 0 MAC Address TLV would be the "Unique Link ID" case > discussed below. > Any other options? And which one is preferable (I vote for #2)?? I am just curious, if "Destination Up" without MAC TLV is the "unique Link ID" case, how does the radio the MACs behind the link? > Not really, but you "get it for free"... As long as it is okay to ignore it... because the data structures that can store this "3-level hierarchy" data are not free. > Excuse me whilst I take your "+1" and run for the nearest exit.... ;-) ;-) > ;-) ;-) LOL... ;) Henning Rogge From nobody Wed Dec 17 11:51:35 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1654A1A8AD8 for ; Wed, 17 Dec 2014 11:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 zCko06WCB90U for ; Wed, 17 Dec 2014 11:51:22 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDA61A8AED for ; Wed, 17 Dec 2014 11:51:22 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id u10so13467927lbd.17 for ; Wed, 17 Dec 2014 11:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rZEfQtt+1xYBFeJWt9MmK9q9QhA3/AxSACHUPKV3miw=; b=rCvhI4BlxGXyscnhOXhwvLazzpOu3MKsVvORZ506zWp8LqDlsF307ikZhKnZ7hF1TW fgmt968bzLXQj8z4r11jQ8OTJQo+g0gqb1fm6lxjxsmn5Nmkmu9uykpC2oXgiK58oY7+ 2U/DXXP2t18yEG6gNB9DGIL8ECFhY8dR2+CYvrgjJsozBLe+/SgH4gpCU6EWNCpUBzRK l2smLRgwLYSkErih9OlaJtz8Vs6hT1ai+00qajFj0nH/ONZhPcm+NuAQ8M3zlpcVkrd2 wXkx3F2exdbOKCxkOFztY9u1aDd/2JpS/IaehCdsJ4oOM8xlXWq7LWfK4JVvrkqLoS8X CoHA== MIME-Version: 1.0 X-Received: by 10.112.41.168 with SMTP id g8mr42544317lbl.59.1418845880538; Wed, 17 Dec 2014 11:51:20 -0800 (PST) Received: by 10.25.85.201 with HTTP; Wed, 17 Dec 2014 11:51:20 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> Date: Wed, 17 Dec 2014 14:51:20 -0500 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11345d76b35c32050a6ecce7 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/A2NUFSw2Gr0Onv3GCMsgb88Nods Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 19:51:28 -0000 --001a11345d76b35c32050a6ecce7 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 17, 2014 at 2:43 PM, Henning Rogge wrote: > > On Wed, Dec 17, 2014 at 8:28 PM, Stan Ratliff > wrote: > >> > Yes, that might work. But I would contend that adding a statement into > >> > the > >> > Destination Up/Destination Update/Destination Down descriptions saying > >> > "Implementations MUST insert one AND ONLY one MAC Address TLV into > this > >> > order" accomplishes the same thing. I mentioned that in the email > >> > between > >> > co-authors and got a negative response on it. No need to invent > >> > additional > >> > protocol unless we need it. > >> > >> Using the position could turn quite funny if you have both MACs with a > >> single IP, MACs with multiple IPs and MACs without IPs. > >> > >> Yes, you can solve it, but suddenly you have to sort your MACs based > >> on the IPs they have. > > > > > > I'm a bit lost with this response. > > "Too much mails in the evening" error... > > yes, I thought we were still talking about the "multiple mac with each > a single IP TLV" idea. > > Sorry. > > > Seems to me that there are a couple of > > options on the table: > > 1. Implement an "Announce IP addresses for MAC" order, or > > 2. Limit Destination Up/Destination Update/Destination Down to AT MOST 1 > MAC > > address TLV (the 0 MAC Address TLV would be the "Unique Link ID" case > > discussed below. > > Any other options? And which one is preferable (I vote for #2)?? > > I am just curious, if "Destination Up" without MAC TLV is the "unique > Link ID" case, how does the radio the MACs behind the link? > Uhh, you got me there. ;-) I revise the statement: Option 2: - Destination Up MUST contain 1 AND ONLY 1 MAC Address TLV - Destination Update/Destination Down MUST contain AT MOST 1 MAC Address TLV. That said, we still need to come to consensus on option 1 or the amended 2 above. > > > Not really, but you "get it for free"... > > As long as it is okay to ignore it... because the data structures that > can store this "3-level hierarchy" data are not free. > At least in the implementation I'm familiar with, metrics are already stored on a "per-MAC basis". So, the "REMOTE modem-wide" case involves searching through your destinations, updating everyone with the matching key. No extra data structures, but some extra CPU cycles looping through your destinations. Regards, Stan > > > Excuse me whilst I take your "+1" and run for the nearest exit.... ;-) > ;-) > > ;-) ;-) > > LOL... ;) > > Henning Rogge > --001a11345d76b35c32050a6ecce7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 17, 2014 at 2:43 PM, Henning Rogge <hrogge@gmail.com>= ; wrote:
On Wed, Dec 17, 2014 at 8:28 = PM, Stan Ratliff <ratliffstan@g= mail.com> wrote:
>> > Yes, that might work. But I would contend that adding a state= ment into
>> > the
>> > Destination Up/Destination Update/Destination Down descriptio= ns saying
>> > "Implementations MUST insert one AND ONLY one MAC Addres= s TLV into this
>> > order" accomplishes the same thing. I mentioned that in = the email
>> > between
>> > co-authors and got a negative response on it. No need to inve= nt
>> > additional
>> > protocol unless we need it.
>>
>> Using the position could turn quite funny if you have both MACs wi= th a
>> single IP, MACs with multiple IPs and MACs without IPs.
>>
>> Yes, you can solve it, but suddenly you have to sort your MACs bas= ed
>> on the IPs they have.
>
>
> I'm a bit lost with this response.

"Too much mails in the evening" error...

yes, I thought we were still talking about the "multiple mac with each=
a single IP TLV" idea.

Sorry.

> Seems to me that there are a couple of
> options on the table:
> 1. Implement an "Announce IP addresses for MAC" order, or > 2. Limit Destination Up/Destination Update/Destination Down to AT MOST= 1 MAC
> address TLV (the 0 MAC Address TLV would be the "Unique Link ID&q= uot; case
> discussed below.
> Any other options? And which one is preferable (I vote for #2)??

I am just curious, if "Destination Up" without MAC TLV is the &qu= ot;unique
Link ID" case, how does the radio the MACs behind the link?

Uhh, you got me there. ;-) =C2=A0I revise the sta= tement:
Option 2:=C2=A0
=C2=A0- Destination Up MUST con= tain 1 AND ONLY 1 MAC Address TLV
=C2=A0- Destination Update/Dest= ination Down MUST contain AT MOST 1 MAC Address TLV.

That said, we still need to come to consensus on option 1 or the amended= 2 above.=C2=A0

=C2=A0

> Not really, but you "get it for free"...

As long as it is okay to ignore it... because the data structures that
can store this "3-level hierarchy" data are not free.

At least in the implementation I'm familiar wi= th, metrics are already stored on a "per-MAC basis". So, the &quo= t;REMOTE modem-wide" case involves searching through your destinations= , updating everyone with the matching key. No extra data structures, but so= me extra CPU cycles looping through your destinations.=C2=A0

=
Regards,
Stan
=C2=A0

> Excuse me whilst I take your "+1" and run for the nearest ex= it.... ;-) ;-)
> ;-) ;-)

LOL... ;)

Henning Rogge
--001a11345d76b35c32050a6ecce7-- From nobody Wed Dec 17 12:08:47 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271411A1EF2 for ; Wed, 17 Dec 2014 12:08:46 -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 pd2k-LevnZ4K for ; Wed, 17 Dec 2014 12:08:45 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52FE1A9004 for ; Wed, 17 Dec 2014 12:08:44 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so21481040wgh.9 for ; Wed, 17 Dec 2014 12:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8VCk/CzIbeQQjdFrXm9QopLAnLoqVrDk2PYipyxt7+g=; b=rqlOYh8rGgp/UEUbd7Fm5obfjmTb2xt1MrzqeoXaLV/Nzd5Eb415N08kIFgG1rjoe1 7NiS1x4tcez3oQwxwHFj5cv/eRMvhxjvl2mKH/H4m2nkyJg3srpzjVNyN+pEoDLN15Id nBNDx+I2tz++Pn/lnr4oBAlBPI/5ugSLqhVJ6WXcYiEavigcK4YukOnKARm8B5CCEaax kZs69yp2qXt3IOkcSkRnB1+9pKqLTfOzoZBgwUijwMl3Qw/c9s02sVK1k6z+WWfONrcr O55m8Zu1T4tml7AV2ZdAaikpJ0pYqYTy1EopgFu+/1YELyAWJ9G27M5h+820iBJGXn6w /ppg== X-Received: by 10.180.88.165 with SMTP id bh5mr17729054wib.77.1418846923308; Wed, 17 Dec 2014 12:08:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Wed, 17 Dec 2014 12:08:23 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> From: Henning Rogge Date: Wed, 17 Dec 2014 21:08:23 +0100 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PfAsfiQhqAzME9dj7KFuK04_klo Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 20:08:46 -0000 On Wed, Dec 17, 2014 at 8:51 PM, Stan Ratliff wrote: > Uhh, you got me there. ;-) I revise the statement: > Option 2: > - Destination Up MUST contain 1 AND ONLY 1 MAC Address TLV > - Destination Update/Destination Down MUST contain AT MOST 1 MAC Address > TLV. This is still strange. If "Destination Up" can only contain ONE MAC, the link-id is useless... which means Destination Update/Down should also ALWAYS contain a MAC address. Link-id makes only sense if you allow multiple MAC addresses. Otherwise we can use the MAC address as the link-id. > At least in the implementation I'm familiar with, metrics are already stored > on a "per-MAC basis". So, the "REMOTE modem-wide" case involves searching > through your destinations, updating everyone with the matching key. No extra > data structures, but some extra CPU cycles looping through your > destinations. I keep my data in a two level AVL-trees to make it easy to lookup data fast. Hmm... now that you mention it, I changed the data structure some time ago to a three level AVL tree. first level: local radios (with metrics and defaults for 2nd level metrics) second level: remote radios (with metrics) 3rd level: proxied mac addresses behind remote radios (currently no metrics) Henning From nobody Wed Dec 17 12:25:02 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B8A1A873C for ; Wed, 17 Dec 2014 12:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 2MNe2Tny74bV for ; Wed, 17 Dec 2014 12:24:59 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8761A7001 for ; Wed, 17 Dec 2014 12:24:59 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so13194096lbi.24 for ; Wed, 17 Dec 2014 12:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KX4bQfLYXSAlXnhBVmP6A5fU3LfQVDWYwlOu0tcuwy0=; b=acmARw484AQR0yfzgZipt6yOraHCp3JtU1rzGt50RW0bj31b7cJzUM94yPuqT3YqO6 oOd91yFjQ3zKBvriqJzMwFYSoyzebM0q5UoYJUqNiIXxq0jAh5I45wpTbhQIObSgMQHL j77LPA1IFI/xI8BrMlGxEVAng1DF1HTUrW6WnqOwHQWU7HiHFKubV0vLeNbpAoSrbNHl +hDNK170Lx4Axyd2kUqih863xjep/PCXJyK7I/TXnc3Pcu8dhSDhiDRDouEAZK6SJm7G riiVmEPYVxMNaC+pq8FTgcAxBLiqYbOx59ty8fBWQBOQbjnkAd8In13h1l5XLKOS+VKL 8fmA== MIME-Version: 1.0 X-Received: by 10.112.198.1 with SMTP id iy1mr42715366lbc.13.1418847896645; Wed, 17 Dec 2014 12:24:56 -0800 (PST) Received: by 10.25.85.201 with HTTP; Wed, 17 Dec 2014 12:24:56 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> Date: Wed, 17 Dec 2014 15:24:56 -0500 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11c341acdeb46c050a6f44bd Archived-At: http://mailarchive.ietf.org/arch/msg/manet/cEm3fddyNISQ5tLfh04yYwR4z8M Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 20:25:01 -0000 --001a11c341acdeb46c050a6f44bd Content-Type: text/plain; charset=UTF-8 On Wed, Dec 17, 2014 at 3:08 PM, Henning Rogge wrote: > > On Wed, Dec 17, 2014 at 8:51 PM, Stan Ratliff > wrote: > > Uhh, you got me there. ;-) I revise the statement: > > Option 2: > > - Destination Up MUST contain 1 AND ONLY 1 MAC Address TLV > > - Destination Update/Destination Down MUST contain AT MOST 1 MAC Address > > TLV. > > This is still strange. > > If "Destination Up" can only contain ONE MAC, the link-id is > useless... which means Destination Update/Down should also ALWAYS > contain a MAC address. > What about this use case: time 0 - Destination Up, Link ID "foo", MAC Address "1" time 1 - Destination Up, Link ID "foo", MAC Address "2" time 2 - Destination Up, Link ID "foo", MAC Address "3" . . . time "n" - Destination Update, Link ID "foo", CDRT=6mbps, CDRR=6mbps . . . time "n+something" - Destination Update, Link ID "foo", CDRT=30mbps, CDRR=30mbps . . . time "z" - Destination Down, Link ID "foo", MAC Address "2" (Device '2' powered off) . . . time "z+something" - Destination Down, Link ID "foo" (remote modem died or is dying) Regards, Stan > > Link-id makes only sense if you allow multiple MAC addresses. > Otherwise we can use the MAC address as the link-id. > > > At least in the implementation I'm familiar with, metrics are already > stored > > on a "per-MAC basis". So, the "REMOTE modem-wide" case involves searching > > through your destinations, updating everyone with the matching key. No > extra > > data structures, but some extra CPU cycles looping through your > > destinations. > > I keep my data in a two level AVL-trees to make it easy to lookup data > fast. > > Hmm... now that you mention it, I changed the data structure some time > ago to a three level AVL tree. > > first level: local radios (with metrics and defaults for 2nd level metrics) > second level: remote radios (with metrics) > 3rd level: proxied mac addresses behind remote radios (currently no > metrics) > > Henning > --001a11c341acdeb46c050a6f44bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Dec 17, 2014 at 3:08 PM, Henning Rogge <hrogge@gmail.com> wrote:
On Wed, Dec 17, 2014 at 8:51 PM, Stan Ratliff &= lt;ratliffstan@gmail.com> w= rote:
> Uhh, you got me there. ;-)=C2=A0 I revise the statement:
> Option 2:
>=C2=A0 - Destination Up MUST contain 1 AND ONLY 1 MAC Address TLV
>=C2=A0 - Destination Update/Destination Down MUST contain AT MOST 1 MAC= Address
> TLV.

This is still strange.

If "Destination Up" can only contain ONE MAC, the link-id is
useless... which means Destination Update/Down should also ALWAYS
contain a MAC address.
=C2=A0
What about thi= s use case:
=C2=A0
time 0=C2=A0=C2=A0 -=C2=A0 Destinat= ion Up, Link ID "foo", MAC Address "1"
time 1= =C2=A0=C2=A0 -=C2=A0 Destination Up, Link ID "foo", MAC Address &= quot;2"
time=C2=A02=C2=A0=C2=A0 -=C2=A0 Destination Up, Link= ID "foo", MAC Address "3"
.
.
.
time "n" - Destination Update, Link ID "fo= o", CDRT=3D6mbps, CDRR=3D6mbps
.
.
.
time "n+something"=C2=A0 -=C2=A0 Destination Update, Link = ID "foo", CDRT=3D30mbps, CDRR=3D30mbps
.
.
.
time "z"=C2=A0 -=C2=A0 Destination Down, Link= ID "foo", MAC Address "2"=C2=A0=C2=A0=C2=A0 (Device &#= 39;2' powered off)
.
.
.
time &= quot;z+something"=C2=A0 -=C2=A0 Destination Down, Link ID "foo&qu= ot;=C2=A0=C2=A0=C2=A0=C2=A0 (remote modem died or is dying)
=C2= =A0
Regards,
Stan
=C2=A0
=C2=A0

Link-id makes only sense if you allow multiple MAC addresses.
Otherwise we can use the MAC address as the link-id.

> At least in the implementation I'm familiar with, metrics are alre= ady stored
> on a "per-MAC basis". So, the "REMOTE modem-wide" = case involves searching
> through your destinations, updating everyone with the matching key. No= extra
> data structures, but some extra CPU cycles looping through your
> destinations.

I keep my data in a two level AVL-trees to make it easy to lookup data fast= .

Hmm... now that you mention it, I changed the data structure some time
ago to a three level AVL tree.

first level: local radios (with metrics and defaults for 2nd level metrics)=
second level: remote radios (with metrics)
3rd level: proxied mac addresses behind remote radios (currently no metrics= )

Henning
--001a11c341acdeb46c050a6f44bd-- From nobody Wed Dec 17 12:28:08 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5BA1A8F4E for ; Wed, 17 Dec 2014 12:28:02 -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 V7IvKERgjVui for ; Wed, 17 Dec 2014 12:28:01 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3881A8F3F for ; Wed, 17 Dec 2014 12:28:01 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so70078wiv.13 for ; Wed, 17 Dec 2014 12:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VA2aZaPpn1MuHOcs74HbQsiQBz3p2+3pHYr+jPKFAvw=; b=ov1s6PZo+uIoHIDo8wQmlF/yamiFisFLM+5VlRJIHSb2//g9iOiZzSFdP8qQxJtAAE w22dbg+LbUuWnENDsibivu3MIZinwAaG8cGemOJAHeWb327JuXj8hS8WiQnErIpjCC4X gNYjgysVKFdDcdOsPyhcwqnHDa3z8bs/fo2ek1weNyE9XbH1ZU9eUGQW+KfAJCZczD/q 04rjnNYsRURj8+s4mLjMN6KhgWgY0h1oG7MOxszgFEJko/bEG8O88ffdg2GzyT8EZAC0 rYHnrWilpv8Ycx3NuYEWeIThfSKHRdTF33cLFzt2gwJsxjRGga6RwewTsxf7cmODfLtf dQRw== X-Received: by 10.180.198.52 with SMTP id iz20mr18052620wic.60.1418848080054; Wed, 17 Dec 2014 12:28:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Wed, 17 Dec 2014 12:27:39 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> <55EE6488-DF1E-49B5-9CC3-8150776B6F69@inf-net.nl> From: Henning Rogge Date: Wed, 17 Dec 2014 21:27:39 +0100 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rP2Mk9CwSDcGW-E37Em0-xDQuuw Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 20:28:02 -0000 > What about this use case: > > time 0 - Destination Up, Link ID "foo", MAC Address "1" > time 1 - Destination Up, Link ID "foo", MAC Address "2" > time 2 - Destination Up, Link ID "foo", MAC Address "3" > . > . > . > time "n" - Destination Update, Link ID "foo", CDRT=6mbps, CDRR=6mbps > . > . > . > time "n+something" - Destination Update, Link ID "foo", CDRT=30mbps, > CDRR=30mbps > . > . > . > time "z" - Destination Down, Link ID "foo", MAC Address "2" (Device '2' > powered off) > . > . > . > time "z+something" - Destination Down, Link ID "foo" (remote modem > died or is dying) Okay, this explanation makes sense. Henning From nobody Wed Dec 17 12:36:43 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1DE1A8747 for ; Wed, 17 Dec 2014 12:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LRiC9MPMTZw2 for ; Wed, 17 Dec 2014 12:36:38 -0800 (PST) Received: from OTTMGC002.GDCAN.COM (smtp5.gdcanada.com [209.29.4.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10411A874C for ; Wed, 17 Dec 2014 12:36:38 -0800 (PST) X-IronPort-AV: E=McAfee;i="5600,1067,7655"; a="522776" Received: from unknown (HELO ottsvw100.gdcan.com) ([172.16.7.212]) by OTTMGC002.GDCAN.COM with ESMTP; 17 Dec 2014 15:36:33 -0500 Received: from CGYSVW100.gdcan.com ([172.31.27.212]) by ottsvw100.gdcan.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Dec 2014 15:36:33 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 17 Dec 2014 13:36:32 -0700 Message-ID: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] [DLEP] DLEP Vendor Extensions Thread-Index: AdAaN+wU/WgXwdWaRQy50/TLweyr1g== From: "Viberg, Neil" To: X-OriginalArrivalTime: 17 Dec 2014 20:36:33.0597 (UTC) FILETIME=[255BB6D0:01D01A39] Archived-At: http://mailarchive.ietf.org/arch/msg/manet/p_ovRWywCzose5qMJfyRNLdWOmQ Cc: manet@ietf.org Subject: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 20:36:41 -0000 Rick, I'm sorry to hear you're removing the vendor extension. I would have thought that no uproar would have been a positive signal. I had no problem implementing it when I moved our Draft 5 DLEP prototype to be compliant with Draft 6 and, more importantly, I found it useful for passing some needed information when we used a proxy DLEP modem for a radio without DLEP. I suppose it's not a huge deal. We'll just have to use an experimental TLV if it is taken out. Cheers, Neil=20 >Date: Tue, 16 Dec 2014 15:42:56 +0000 >From: Rick Taylor >To: manet IETF >Subject: [manet] DLEP Vendor Extensions >Message-ID: > <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalsto rmsoftware.com> >=09 >Content-Type: text/plain; charset=3D"us-ascii" > >All, > >In response to the silence concerning Vendor Extensions in DLEP, and after much deliberation amongst the authors, we have decided to >drop the concept from the protocol. > >Regards, > >Rick Taylor From nobody Wed Dec 17 12:50:24 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E00B1A879B for ; Wed, 17 Dec 2014 12:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IqRZNI1pQtXd for ; Wed, 17 Dec 2014 12:50:20 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470F61A8799 for ; Wed, 17 Dec 2014 12:50:20 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so151130wiv.7 for ; Wed, 17 Dec 2014 12:50:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=TvcIJCi7VDjRnlNIAYWRrJN2mOe6YcZkGvfZBvbOnt8=; b=Cdemd3s4SvytmQcEpPVrGBWf18C74LUnVkpPwrtLzDMcd1pLCqpgMIUVs3P/agmWHY yaY/zzLCxuMM6tmbK0YeKzTGLDq8h6c+FmKqLwbRTcdQv4wc7MQOvqJFjcifSIoI/JbV Eh2ZRx65hMjn96KmwV053BsLsLB13wmX0OrLP8F2fGM5xVaONUr6WAuJ2VNT3gTVxwhv 9pGZjdvotXSrzaEWT6ODSDIUmj9VwhxbZbWiSEn/h6sNbVe2HvuVKW5qOHu18L3VElw7 z7lMZkCv0yUx88o9760bFNcahvXX6I8da7ic5OxpyCwLdIN4qv3g56e3jg+GmD1haQC2 R3PA== X-Gm-Message-State: ALoCoQlS/c6R1QJW2XtkVB8K3K/ZLP7C6NxV0ax+jNn0ueZf7jHC0GCaVI0XhVCVKk0wsw1vX6Ol X-Received: by 10.194.90.10 with SMTP id bs10mr76810365wjb.43.1418849418989; Wed, 17 Dec 2014 12:50:18 -0800 (PST) Received: from [192.168.178.12] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPSA id gl5sm22195578wib.0.2014.12.17.12.50.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 12:50:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Teco Boot In-Reply-To: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> Date: Wed, 17 Dec 2014 21:50:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> To: "Viberg, Neil" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hA_zaWe_VfucbtuNsQiLPqK6_uo Cc: manet@ietf.org Subject: Re: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 20:50:23 -0000 I didn=E2=80=99t see any argument removing vendor extensions on the = mailing list. What did go wrong? Just procedural: it is not the authors which decide what gets in and out = a WG draft. Teco > Op 17 dec. 2014, om 21:36 heeft Viberg, Neil = het volgende geschreven: >=20 > Rick, >=20 > I'm sorry to hear you're removing the vendor extension. I would have > thought that no uproar would have been a positive signal. >=20 > I had no problem implementing it when I moved our Draft 5 DLEP = prototype > to be compliant with Draft 6 and, more importantly, I found it useful > for passing some needed information when we used a proxy DLEP modem = for > a radio without DLEP. >=20 > I suppose it's not a huge deal. We'll just have to use an experimental > TLV if it is taken out. >=20 > Cheers, > Neil=20 >=20 >> Date: Tue, 16 Dec 2014 15:42:56 +0000 >> From: Rick Taylor >> To: manet IETF >> Subject: [manet] DLEP Vendor Extensions >> Message-ID: >>=20 > = <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalsto > rmsoftware.com> >> =09 >> Content-Type: text/plain; charset=3D"us-ascii" >>=20 >> All, >>=20 >> In response to the silence concerning Vendor Extensions in DLEP, and > after much deliberation amongst the authors, we have decided to >drop > the concept from the protocol. >>=20 >> Regards, >>=20 >> Rick Taylor >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Dec 17 12:59:40 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FB71A8764 for ; Wed, 17 Dec 2014 12:59:38 -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 5VA7EWmPBCLJ for ; Wed, 17 Dec 2014 12:59:35 -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 7BF241A0121 for ; Wed, 17 Dec 2014 12:59:35 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kq14so17030795pab.6 for ; Wed, 17 Dec 2014 12:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=pkXdyoS6WfNJNToV8V/uai44Or2Wuh4HxQ6YPqL+FMs=; b=obyTWv4DeEDzQML+CUvrrHrwYCN9PNd7kXRZxkbITSKCMUyFOqTlT+zBpoTswJuHXu hBzbMjQBRx/ywVSnvXt5BrOuFbjpc39Y0OC1a1aD/zVvboC8j8+e367djrRnPW79jqCo Ih8c3EPw4ydCDcCq5VTYEIInSxt7EDjvOeGh2gE9boZyYA/Ov3Ogdy5nJFrKmXImcdqB g/EmYveWGvtvbpEeXz6mlFo7khABVws/jBHVR3gziSnHco+dDU2XUcdMYxmd2u+xe1SO FbhjHO2yz9UgDyNM87OFzM+sah5wPL5MwL9eGAr3MB+p1WaGGjHkLclv7w1aKnb2eipt dOOg== X-Received: by 10.66.124.227 with SMTP id ml3mr17880070pab.28.1418849974720; Wed, 17 Dec 2014 12:59:34 -0800 (PST) Received: from [192.168.1.106] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id o3sm4786717pdn.29.2014.12.17.12.59.33 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Wed, 17 Dec 2014 12:59:34 -0800 (PST) Message-ID: <1418849972.1901.20.camel@localhost.localdomain> From: Rex Buddenberg To: Stan Ratliff Date: Wed, 17 Dec 2014 12:59:32 -0800 In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980142A03727@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/5E0CHRGkiTbIAQF8gNO7p7jLb98 Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 20:59:38 -0000 illustration, abstract to concrete. On Wed, 2014-12-17 at 09:45 -0500, Stan Ratliff wrote: > Henning, > > I'll give it a go. Let's assume a MANET deployment where some number > ("N") of vehicles are deployed. Each of those vehicles has some number > of laptops, a VoIP phone (or two), a video camera, and some other > sensors - for a total of 12 devices. This setup with the radio and 12 > devices is my "standard kit" - I put that standard kit into almost > every vehicle I have in my fleet. Additionally, the deployment has a > small number (let's say 3) of "VIP Vehicles" - those vehicles have > multiple radios, satcom for reach-back, and most importantly, a > router. An excellent use case would be an instrumented ambulance. The primary purpose is to relay casualty status so the EMT in the ambulance and get a look over her shoulder by the ER doc. Secondary purpose is vehicle navigation through traffic -- look over the driver's shoulder by the 911 dispatcher ... you can think of several variants. And coincidentally, '12' is a number in the ballpark. Several vital signs sensors attached to a casualty, a VOIP rig for the EMT to talk to the ER doc, a VOIP rig for the driver to talk with dispatching, a radionav receiver to grab position (for the dispatcher)... the scale is about right. > > So now, I take 100 vehicles with the "standard kit", plus my 3 " VIP > Vehicles", and deploy them. I'll leave the impact on DLEP to others here far more capable than me: > I contend that with regard to the vehicles having the "standard kit", > DLEP doesn't have an effect unless each and every device is declared > as a DLEP "Destination" (via presentation of a 'Destination Up' > order). You see, we've been concentrating on deployments where every > radio has a *router* attached to it, and then all devices are attached > "behind" the router. So from a DLEP perspective, there's just 1 DLEP > "destination" per radio (that 'destination' being the router). I > believe that works quite well. But in the case I've described, where a > lot of the radios don't have a router installed, DLEP doesn't scale > well - in my little example, the psuedo-Ethernet segment created by > the radios will have 1,200+ MAC addresses on it (12 devices per > vehicle, 100 vehicles - the classic "M*N" scalability problem). Each > of those MAC addresses should be identified by a DLEP "Destination > Up"; and they would also need their own "Destination Update" orders > if/when the RF characteristics change - that gets unwieldy pretty > fast. There are lots of very good reasons for multiple WAN interfaces. High availability is the trumping one -- get that right and a lot of other reasons become lesser included offenses. For example, you might be able to use 4G cellphone in an urban area, along with opportunistic WiFi, but might need an 802.16 rig working in VHF for suburban areas and a satellite shot in a more rural one. And you might plug router into wired internet when the ambulance is in the garage. > > So, that's what we mean by the "multiple destinations" verbiage, and > we've been discussing some ideas to reduce the DLEP overhead in those > deployment scenarios. It's not really new functionality; more of > things like: > - Can a "Destination Up" order contain more than 1 MAC address TLV? (I > believe the answer to that is 'yes') > - If a "Destination Up" order contains more than 1 Mac Address TLV, > then how are the associated IPv4 Address and IPv6 address TLVs > processed? (I believe the answer to that is "positionally" e.g., the > DLEP buffer looks something like MAC TLV 1/IPv4 Addr TLV 1/MAC TLV > 2/IPv4 Addr TLV 2/IPv6 Addr TLV 2; but the document is not clear on > that, and needs to be explicit in that area.). > - Is there a reasonably straightforward way in DLEP to effectively say > "The data rate *to the remote radio* is ", allowing a single > "Destination Update" order to convey metrics for multiple MAC > addresses across the RF link? (I believe the answer to that question > is "Not in DLEP-07, but I think there is a straightforward "tweak" to > the protocol to let us do that.") The use case observation here is that the more you need the instrumented ambulance, the more expensive and bandwidth-limited the radio-WAN channel is likely to be. > > Now, the "is there a way to reference the remote radio itself, instead > of all of its connected devices" issue also led us to reconsider the > notion that has been described as "Layer 3 DLEP" - that being, radio > devices having sufficient Layer 3 smarts to be able to receive a > frame, and re-write the Layer 2 header for subsequent egress, based on > an IP address lookup. Personally, I believe that once you've created a > way to reference just the remote modem, doing this type of "gateway > operation" *IN LIEU OF" the "transparent bridge mode" we all know and > love (hate?) isn't a large step at all... > > Hopefully, that helps make things clearer. I'm *really* hoping I > haven't muddied the waters... ;-) > > Regards, > Stan > > On Wed, Dec 17, 2014 at 1:58 AM, Henning Rogge > wrote: > Hi Stan, > > maybe I missunderstood Rick and you can explain the "multiple > destinations" a little bit better. > > I worry that the "bridging" on the radio will become much more > complicated if there is more than a point-2-point connection > over the > ethernet to one other device (router). > > Henning > > On Wed, Dec 17, 2014 at 3:20 AM, Stan Ratliff > wrote: > > Henning, > > > > The co-authors have been having some discussions with regard > to deployments > > that have multiple end-stations (for example, laptops, > cameras, VoIP phones, > > sensors, etc), and not necessarily a router. In this type of > deployment, > > some (though not all) radios may have a router for access > "upstream" into a > > network (like, for example, a reach-back to some "home > office", perhaps via > > satellite), but not necessarily all of the radios. > > > > Regards, > > Stan > > > > On Tue, Dec 16, 2014 at 12:27 PM, Henning Rogge > wrote: > >> > >> On Tue, Dec 16, 2014 at 5:52 PM, Rick Taylor > >> wrote: > >> > Justin, All, > >> > > >> > As a heads up, there is some new functionality that MAY > be added to a > >> > draft-08: Multiple devices at a destination. > >> > >> You mean (as an example) radios with multiple interfaces? > >> > >> We have thought about this at our institute too but our > best idea is > >> to address each radio "line" over a pre-configured VLAN > tag. Similar > >> to the usecase where you want to connect multiple physical > radios over > >> a VLAN-capable switch to a single ethernet port of the > router. > >> > >> Henning > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Dec 17 13:07:27 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32C31A8790 for ; Wed, 17 Dec 2014 13:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 1WPVmtAt2tLc for ; Wed, 17 Dec 2014 13:07:24 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5C21A86E2 for ; Wed, 17 Dec 2014 13:07:23 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id b6so13099939lbj.22 for ; Wed, 17 Dec 2014 13:07:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UW1sApuhwFIKm63cCHrO/oXYScN7TASLnW12KA9WxwU=; b=aSyL80SSdfz0msXk7ApwUBA3UmR6A5jRSdoAYK+mnvP5BwnyuwsH7FZTP2y1evZXNu osaTDV39T70cX+Sf5NbTfnrGzA87aBtyHXN/sRfdxXTiYV6YTzEq/aHtN2GMLhw4JRqo X0+85FTIJ6N8pHFntEHkoi0hZF5cLyGWT3lDCEt2y8kEHKtU+73mA8IuAQbapogI1B3x UPxvw1xjVMARB4LbSmvMWdjMn7Tb8VXs7P2rK8+PyKZT9ryvB7RHY6Mcmf6upnotjWq5 6374Wmgy+rAbFkkp83eEY1quvK5hMn5ekFdarYN9KzRfkSRYX3bkmPTzI7FooaGSSGdD md8w== MIME-Version: 1.0 X-Received: by 10.152.5.67 with SMTP id q3mr42991276laq.73.1418850441876; Wed, 17 Dec 2014 13:07:21 -0800 (PST) Received: by 10.25.85.201 with HTTP; Wed, 17 Dec 2014 13:07:21 -0800 (PST) In-Reply-To: References: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> Date: Wed, 17 Dec 2014 16:07:21 -0500 Message-ID: From: Stan Ratliff To: Teco Boot Content-Type: multipart/alternative; boundary=089e013d173493db2c050a6fdce8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tIdoBuRfcMN8ycRoIzgCX2oIXN0 Cc: MANET IETF , "Viberg, Neil" Subject: Re: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 21:07:26 -0000 --089e013d173493db2c050a6fdce8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Teco, On Wed, Dec 17, 2014 at 3:50 PM, Teco Boot wrote: > > I didn=E2=80=99t see any argument removing vendor extensions on the maili= ng list. > What did go wrong? > > Just procedural: it is not the authors which decide what gets in and out = a > WG draft. > Perhaps the case is overstated a bit. Let me attempt to rephrase: There was (and still is) a point of contention (at least amongst the co-authors) about Vendor Extensions, and whether they should be allowed on Destination Update/Destination Down. The two points of view are: 1. Vendor Extensions are pretty much worthless unless/until they are allowed on Destination Update. 2. Vendor Extensions are an abomination, *especially* on Destination Update - at most, they should only be allowed on Destination Up. During the Honolulu IETF, the author team asked for WG opinions regarding those two points of view, and/or whether there might be options the co-authors had not considered. We did actually state that DLEP-07 reflects point-of-view #2 above; and that it (point-of-view #2) would be the "default option" going forward. But we asked for opinions on-list. Up to today, the silence has been deafening. The co-authors would *greatly* appreciate if other WG participants expressed an opinion on-list, so that we might guage WG consensus on this item. Regards, Stan > Teco > > > Op 17 dec. 2014, om 21:36 heeft Viberg, Neil > het volgende geschreven: > > > > Rick, > > > > I'm sorry to hear you're removing the vendor extension. I would have > > thought that no uproar would have been a positive signal. > > > > I had no problem implementing it when I moved our Draft 5 DLEP prototyp= e > > to be compliant with Draft 6 and, more importantly, I found it useful > > for passing some needed information when we used a proxy DLEP modem for > > a radio without DLEP. > > > > I suppose it's not a huge deal. We'll just have to use an experimental > > TLV if it is taken out. > > > > Cheers, > > Neil > > > >> Date: Tue, 16 Dec 2014 15:42:56 +0000 > >> From: Rick Taylor > >> To: manet IETF > >> Subject: [manet] DLEP Vendor Extensions > >> Message-ID: > >> > > <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalst= o > > rmsoftware.com> > >> > >> Content-Type: text/plain; charset=3D"us-ascii" > >> > >> All, > >> > >> In response to the silence concerning Vendor Extensions in DLEP, and > > after much deliberation amongst the authors, we have decided to >drop > > the concept from the protocol. > >> > >> Regards, > >> > >> Rick Taylor > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e013d173493db2c050a6fdce8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Teco,
On Wed, Dec 17, 2014 at 3:50 PM, Teco Boot <teco@inf-net.nl> wrote:
I didn=E2=80=99t see any argument removing vend= or extensions on the mailing list. What did go wrong?

Just procedural: it is not the authors which decide what gets in and out a = WG draft.
=C2=A0
Perhaps the=C2=A0case is ov= erstated a bit. Let me attempt to rephrase: There was (and still is) a poin= t of contention (at least amongst the co-authors) about Vendor Extensions, = and whether they should be allowed on Destination Update/Destination Down. = The two points of view are:
=C2=A0
1. Vendor Extension= s are pretty much worthless unless/until they are allowed on Destination Up= date.
=C2=A0
2. Vendor Extensions are an abomination, *= especially* on Destination Update - at most, they should only be allowed on= Destination Up.=C2=A0
=C2=A0
During the Honolulu IETF,= the author team asked for WG opinions regarding those two points of view, = and/or=C2=A0whether there might be options the co-authors had not considere= d. We did actually state that DLEP-07 reflects point-of-view=C2=A0#2 above;= =C2=A0and that it (point-of-view #2) would be the "default option"= ; going forward. But we asked for opinions on-list.
=C2=A0
=
Up to today, the silence has been deafening. The co-authors would *gre= atly* appreciate if other WG participants expressed an opinion on-list, so = that we might guage WG consensus on this item.
=C2=A0
= Regards,
Stan
=C2=A0
=C2=A0
=C2=A0<= /div>
=C2=A0
=C2=A0
Teco

> Op 17 dec. 2014, om 21:36 heeft Viberg, Neil <Neil.Viberg@gdcanada.com> het volgende geschr= even:
>
> Rick,
>
> I'm sorry to hear you're removing the vendor extension. I woul= d have
> thought that no uproar would have been a positive signal.
>
> I had no problem implementing it when I moved our Draft 5 DLEP prototy= pe
> to be compliant with Draft 6 and, more importantly, I found it useful<= br> > for passing some needed information when we used a proxy DLEP modem fo= r
> a radio without DLEP.
>
> I suppose it's not a huge deal. We'll just have to use an expe= rimental
> TLV if it is taken out.
>
> Cheers,
> Neil
>
>> Date: Tue, 16 Dec 2014 15:42:56 +0000
>> From: Rick Taylor <rick@tropicalstormsoftware.com>
>> To: manet IETF <manet@ietf.or= g>
>> Subject: [manet] DLEP Vendor Extensions
>> Message-ID:
>>
> <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropic= alsto
> rmsoftware.com= >
>>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> All,
>>
>> In response to the silence concerning Vendor Extensions in DLEP, a= nd
> after much deliberation amongst the authors, we have decided to >dr= op
> the concept from the protocol.
>>
>> Regards,
>>
>> Rick Taylor
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--089e013d173493db2c050a6fdce8-- From nobody Wed Dec 17 13:53:28 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303CD1A8779 for ; Wed, 17 Dec 2014 13:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 O-86vrrddlvb for ; Wed, 17 Dec 2014 13:53:22 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2201A86EC for ; Wed, 17 Dec 2014 13:53:22 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so21466929wgh.23 for ; Wed, 17 Dec 2014 13:53:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=OYj9w8LhC+yLVDfHFDS1JBr4UWtSSejD2tV3Gn8HVoI=; b=BPxcNxThpgo4VbsMmmyl11Xb5U+VidL4plCDRYEr6mq9PVcm+6Mc0T88CHLakAvUrx csxQ3WoVuf2oPBqYNPccKZC1Ud+IEiseH7KU4d4gudobFhV2G27ZC87RX/EMshckiR8g +Fe+Xj0G/VcZfQIxs5AYpfGH4uHfWg+xNOM+IyudDmJJZAxkZbWrwv2x92QF5UQpsLZ4 /HRhns70uyMByCQptqjJNUZz/LrQbvJ+RPVED3EYwOHYiI7UWSpff+Tba7GazUIpcbXQ 5lY6SOZT9ENnz5PNgd8w3V2nIjpMivC+lYQ1yMxqNhcJVRgSrPFQ3wCfSHhnDjLFZGH/ 5PWA== X-Gm-Message-State: ALoCoQn0eIojAp93ebD0JcRpYTqqhMJyJNUkTywMlYRCpK4PNdLawweaFmAlZJysAsCiIlgoxZ5A X-Received: by 10.180.103.38 with SMTP id ft6mr18529077wib.19.1418853201028; Wed, 17 Dec 2014 13:53:21 -0800 (PST) Received: from [192.168.178.12] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPSA id td6sm7641686wic.15.2014.12.17.13.53.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 13:53:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Teco Boot In-Reply-To: Date: Wed, 17 Dec 2014 22:53:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2oanw8_6Zcm3-5l4IslhUHfSxf8 Cc: MANET IETF , "Viberg, Neil" Subject: Re: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 21:53:26 -0000 I=E2=80=99ve provided my opinion in the meeting. I don=E2=80=99t see a = problem having vendor extensions in whatever signal. They are optional = items in the spec. Helpful in some cases. There is always the standards = based fallback. I cannot follow reasoning behind 2. Can someone explain? Now I=E2=80=99ll continue configuring DHCP option 43. Teco > Op 17 dec. 2014, om 22:07 heeft Stan Ratliff = het volgende geschreven: >=20 > Teco,=20 > On Wed, Dec 17, 2014 at 3:50 PM, Teco Boot wrote: > I didn=E2=80=99t see any argument removing vendor extensions on the = mailing list. What did go wrong? >=20 > Just procedural: it is not the authors which decide what gets in and = out a WG draft. > =20 > Perhaps the case is overstated a bit. Let me attempt to rephrase: = There was (and still is) a point of contention (at least amongst the = co-authors) about Vendor Extensions, and whether they should be allowed = on Destination Update/Destination Down. The two points of view are: > =20 > 1. Vendor Extensions are pretty much worthless unless/until they are = allowed on Destination Update. > =20 > 2. Vendor Extensions are an abomination, *especially* on Destination = Update - at most, they should only be allowed on Destination Up.=20 > =20 > During the Honolulu IETF, the author team asked for WG opinions = regarding those two points of view, and/or whether there might be = options the co-authors had not considered. We did actually state that = DLEP-07 reflects point-of-view #2 above; and that it (point-of-view #2) = would be the "default option" going forward. But we asked for opinions = on-list. > =20 > Up to today, the silence has been deafening. The co-authors would = *greatly* appreciate if other WG participants expressed an opinion = on-list, so that we might guage WG consensus on this item. > =20 > Regards, > Stan > =20 > =20 > =20 > =20 > =20 > Teco >=20 > > Op 17 dec. 2014, om 21:36 heeft Viberg, Neil = het volgende geschreven: > > > > Rick, > > > > I'm sorry to hear you're removing the vendor extension. I would have > > thought that no uproar would have been a positive signal. > > > > I had no problem implementing it when I moved our Draft 5 DLEP = prototype > > to be compliant with Draft 6 and, more importantly, I found it = useful > > for passing some needed information when we used a proxy DLEP modem = for > > a radio without DLEP. > > > > I suppose it's not a huge deal. We'll just have to use an = experimental > > TLV if it is taken out. > > > > Cheers, > > Neil > > > >> Date: Tue, 16 Dec 2014 15:42:56 +0000 > >> From: Rick Taylor > >> To: manet IETF > >> Subject: [manet] DLEP Vendor Extensions > >> Message-ID: > >> > > = <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalsto > > rmsoftware.com> > >> > >> Content-Type: text/plain; charset=3D"us-ascii" > >> > >> All, > >> > >> In response to the silence concerning Vendor Extensions in DLEP, = and > > after much deliberation amongst the authors, we have decided to = >drop > > the concept from the protocol. > >> > >> Regards, > >> > >> Rick Taylor > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Dec 17 14:56:07 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED6E1A001C for ; Wed, 17 Dec 2014 14:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 P0L9PPXST2xc for ; Wed, 17 Dec 2014 14:56:01 -0800 (PST) Received: from OTTMGC002.GDCAN.COM (smtp5.gdcanada.com [209.29.4.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664B01A000A for ; Wed, 17 Dec 2014 14:56:01 -0800 (PST) X-IronPort-AV: E=McAfee;i="5600,1067,7655"; a="523628" Received: from unknown (HELO ottsvw100.gdcan.com) ([172.16.7.212]) by OTTMGC002.GDCAN.COM with ESMTP; 17 Dec 2014 17:56:00 -0500 Received: from CGYSVW100.gdcan.com ([172.31.27.212]) by ottsvw100.gdcan.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Dec 2014 17:56:00 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 17 Dec 2014 15:55:58 -0700 Message-ID: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB98@CGYSVW100.gdcan.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] [DLEP] DLEP Vendor Extensions Thread-Index: AdAaOxMWcaEFBB+xR36Fr0GGAfn95gADz3bg References: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> From: "Viberg, Neil" To: "Teco Boot" X-OriginalArrivalTime: 17 Dec 2014 22:56:00.0081 (UTC) FILETIME=[A02BDC10:01D01A4C] Archived-At: http://mailarchive.ietf.org/arch/msg/manet/yIHFd2sAVbJ7jZ18h1KWYosoSHI Cc: manet@ietf.org Subject: Re: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:56:03 -0000 VGVjbywNCg0KSSBpbmNsdWRlZCBSaWNrJ3MgZW1haWwgYWJvdXQgcmVtb3ZpbmcgdGhlIHZlbmRv ciBleHRlbnNpb24gd2hpY2ggaXMgd2hhdCBJIHdhcyByZXNwb25kaW5nIHRvLiBJIGhhdmUgYmVl biBtb25pdG9yaW5nIHRoZSBtYW5ldCBtYWlsaW5nIGxpc3QgZm9yIG1vbnRocyBhbmQgSSBkb24n dCBiZWxpZXZlIHRoZXJlIHdhcyBhbnkgZGlzY3Vzc2lvbiBvZiBhZGRpbmcgYSB2ZW5kb3IgZXh0 ZW5zaW9uIHByaW9yIHRvIERyYWZ0IDcgYW5kIHRoZXJlIGhhcywgQUZBSUssIGJlZW4gbm8gZGlz Y3Vzc2lvbiBhYm91dCByZW1vdmluZyBpdC4NCg0KSWYgeW91IGRpZG4ndCBzZWUgdGhlIGVtYWls LCBpdCB3YXMgdGhlIHN0YXJ0IG9mIHRoaXMgbG9uZyBkaWFsb2d1ZSB3aGljaCBpcyBzdGlsbCBs YWJlbGVkICJETEVQIFZlbmRvciBFeHRlbnNpb25zIiBidXQgaGFzIG1vcnBoZWQgaW50byBhIGRp c2N1c3Npb24gYWJvdXQgYWRkaW5nIG11bHRpcGxlIGRlc3RpbmF0aW9ucy4gDQoNCk5laWwNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRlY28gQm9vdCBbbWFpbHRvOnRlY29A aW5mLW5ldC5ubF0gDQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDE3LCAyMDE0IDE6NTAgUE0N ClRvOiBWaWJlcmcsIE5laWwNCkNjOiByaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb207IG1h bmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSBbRExFUF0gRExFUCBWZW5kb3IgRXh0 ZW5zaW9ucw0KDQpJIGRpZG7igJl0IHNlZSBhbnkgYXJndW1lbnQgcmVtb3ZpbmcgdmVuZG9yIGV4 dGVuc2lvbnMgb24gdGhlIG1haWxpbmcgbGlzdC4gV2hhdCBkaWQgZ28gd3Jvbmc/DQoNCkp1c3Qg cHJvY2VkdXJhbDogaXQgaXMgbm90IHRoZSBhdXRob3JzIHdoaWNoIGRlY2lkZSB3aGF0IGdldHMg aW4gYW5kIG91dCBhIFdHIGRyYWZ0Lg0KDQpUZWNvDQoNCj4gT3AgMTcgZGVjLiAyMDE0LCBvbSAy MTozNiBoZWVmdCBWaWJlcmcsIE5laWwgPE5laWwuVmliZXJnQGdkY2FuYWRhLmNvbT4gaGV0IHZv bGdlbmRlIGdlc2NocmV2ZW46DQo+IA0KPiBSaWNrLA0KPiANCj4gSSdtIHNvcnJ5IHRvIGhlYXIg eW91J3JlIHJlbW92aW5nIHRoZSB2ZW5kb3IgZXh0ZW5zaW9uLiBJIHdvdWxkIGhhdmUgDQo+IHRo b3VnaHQgdGhhdCBubyB1cHJvYXIgd291bGQgaGF2ZSBiZWVuIGEgcG9zaXRpdmUgc2lnbmFsLg0K PiANCj4gSSBoYWQgbm8gcHJvYmxlbSBpbXBsZW1lbnRpbmcgaXQgd2hlbiBJIG1vdmVkIG91ciBE cmFmdCA1IERMRVAgDQo+IHByb3RvdHlwZSB0byBiZSBjb21wbGlhbnQgd2l0aCBEcmFmdCA2IGFu ZCwgbW9yZSBpbXBvcnRhbnRseSwgSSBmb3VuZCANCj4gaXQgdXNlZnVsIGZvciBwYXNzaW5nIHNv bWUgbmVlZGVkIGluZm9ybWF0aW9uIHdoZW4gd2UgdXNlZCBhIHByb3h5IA0KPiBETEVQIG1vZGVt IGZvciBhIHJhZGlvIHdpdGhvdXQgRExFUC4NCj4gDQo+IEkgc3VwcG9zZSBpdCdzIG5vdCBhIGh1 Z2UgZGVhbC4gV2UnbGwganVzdCBoYXZlIHRvIHVzZSBhbiBleHBlcmltZW50YWwgDQo+IFRMViBp ZiBpdCBpcyB0YWtlbiBvdXQuDQo+IA0KPiBDaGVlcnMsDQo+IE5laWwNCj4gDQo+PiBEYXRlOiBU dWUsIDE2IERlYyAyMDE0IDE1OjQyOjU2ICswMDAwDQo+PiBGcm9tOiBSaWNrIFRheWxvciA8cmlj a0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29tPg0KPj4gVG86IG1hbmV0IElFVEYgPG1hbmV0QGll dGYub3JnPg0KPj4gU3ViamVjdDogW21hbmV0XSBETEVQIFZlbmRvciBFeHRlbnNpb25zDQo+PiBN ZXNzYWdlLUlEOg0KPj4gDQo+IDwzOEE1NDc1REU4Mzk4NjQ5OUFFQUNEMkNGQUZDM0Y5ODAxNDJB MDM0M0RAdHNzLXNlcnZlcjEuaG9tZS50cm9waWNhbHMNCj4gdG8NCj4gcm1zb2Z0d2FyZS5jb20+ DQo+PiAJDQo+PiBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InVzLWFzY2lpIg0K Pj4gDQo+PiBBbGwsDQo+PiANCj4+IEluIHJlc3BvbnNlIHRvIHRoZSBzaWxlbmNlIGNvbmNlcm5p bmcgVmVuZG9yIEV4dGVuc2lvbnMgaW4gRExFUCwgYW5kDQo+IGFmdGVyIG11Y2ggZGVsaWJlcmF0 aW9uIGFtb25nc3QgdGhlIGF1dGhvcnMsIHdlIGhhdmUgZGVjaWRlZCB0byA+ZHJvcCANCj4gdGhl IGNvbmNlcHQgZnJvbSB0aGUgcHJvdG9jb2wuDQo+PiANCj4+IFJlZ2FyZHMsDQo+PiANCj4+IFJp Y2sgVGF5bG9yDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQo= From nobody Wed Dec 17 15:42:27 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECFD1A0045 for ; Wed, 17 Dec 2014 15:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Mi6OmPSggyna for ; Wed, 17 Dec 2014 15:42:24 -0800 (PST) Received: from OTTMGC001.GDCAN.COM (smtp4.gdcanada.com [209.29.4.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FBE1A001C for ; Wed, 17 Dec 2014 15:42:23 -0800 (PST) X-IronPort-AV: E=McAfee;i="5600,1067,7655"; a="566098" Received: from unknown (HELO ottsvw100.gdcan.com) ([172.16.7.212]) by OTTMGC001.GDCAN.COM with ESMTP; 17 Dec 2014 18:42:21 -0500 Received: from CGYSVW100.gdcan.com ([172.31.27.212]) by ottsvw100.gdcan.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Dec 2014 18:42:18 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 17 Dec 2014 16:42:16 -0700 Message-ID: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFBA0@CGYSVW100.gdcan.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP Vendor Extensions Thread-Index: AdAaTXUJ2yzAU4FcQP+WRuGwEali/A== From: "Viberg, Neil" To: X-OriginalArrivalTime: 17 Dec 2014 23:42:18.0441 (UTC) FILETIME=[1833F390:01D01A53] Archived-At: http://mailarchive.ietf.org/arch/msg/manet/j2V2dndW1HqDYgQSauFm-OjwSzE Cc: manet@ietf.org Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 23:42:26 -0000 Stan, I think the idea for adding multiple MAC addresses is either a case of creeping requirements or premature optimization or both. The acronym DLEP represents a "Dynamic Link Exchange Protocol". It's importance, at least to me, is about the link not about the destinations that the link leads to. I don't think that adding complexity to turn DLEP into a neighbour discovery mechanism for everything attached to all of the LANs connected to all of the modems is a good idea. It may make someone's system engineering job simpler or keep the total cost of a system down but it won't make for a simple useful protocol. I would apply the KISS principle at this point. My 2 bits. Neil -----Original Message----- >Date: Wed, 17 Dec 2014 09:45:34 -0500 >From: Stan Ratliff >To: Henning Rogge >Cc: manet IETF >Subject: Re: [manet] DLEP Vendor Extensions >Message-ID: > >Content-Type: text/plain; charset=3D"utf-8" > >Henning, > >I'll give it a go. Let's assume a MANET deployment where some number ("N") of vehicles are deployed. Each of those vehicles has some >number of laptops, a VoIP phone (or two), a video camera, and some other sensors >- for a total of 12 devices. This setup with the radio and 12 devices is my "standard kit" - I put that standard kit into almost every vehicle I >have in my fleet. Additionally, the deployment has a small number (let's say 3) of "VIP Vehicles" - those vehicles have multiple radios, >satcom for reach-back, and most importantly, a router. > >So now, I take 100 vehicles with the "standard kit", plus my 3 " VIP Vehicles", and deploy them. I contend that with regard to the vehicles >having the "standard kit", DLEP doesn't have an effect unless each and every device is declared as a DLEP "Destination" (via presentation >of a 'Destination Up' order). You see, we've been concentrating on deployments where every radio has a *router* attached to it, and >then all devices are attached "behind" the router. So from a DLEP perspective, there's just 1 DLEP "destination" per radio (that >'destination' being the router). I believe that works quite well. But in the case I've described, where a lot of the radios don't have a router installed, DLEP doesn't scale well - in my little example, the psuedo-Ethernet segment created by the radios will have 1,200+ MAC addresses on it (12 devices per vehicle, 100 vehicles - the classic "M*N" scalability problem). Each of those MAC addresses should be identified by a DLEP "Destination Up"; and they would also need their own "Destination Update" orders if/when the RF characteristics change - that gets unwieldy pretty fast. So, that's what we mean by the "multiple destinations" verbiage, and we've been discussing some ideas to reduce the DLEP overhead in those deployment scenarios. It's not really new functionality; more of things like: - Can a "Destination Up" order contain more than 1 MAC address TLV? (I believe the answer to that is 'yes') - If a "Destination Up" order contains more than 1 Mac Address TLV, then how are the associated IPv4 Address and IPv6 address TLVs processed? (I believe the answer to that is "positionally" e.g., the DLEP buffer looks something like MAC TLV 1/IPv4 Addr TLV 1/MAC TLV 2/IPv4 Addr TLV 2/IPv6 Addr TLV 2; but the document is not clear on that, and needs to be explicit in that area.). - Is there a reasonably straightforward way in DLEP to effectively say "The data rate *to the remote radio* is ", allowing a single "Destination Update" order to convey metrics for multiple MAC addresses across the RF link? (I believe the answer to that question is "Not in DLEP-07, but I think there is a straightforward "tweak" to the protocol to let us do that.") Now, the "is there a way to reference the remote radio itself, instead of all of its connected devices" issue also led us to reconsider the notion that has been described as "Layer 3 DLEP" - that being, radio devices having sufficient Layer 3 smarts to be able to receive a frame, and re-write the Layer 2 header for subsequent egress, based on an IP address lookup. Personally, I believe that once you've created a way to reference just the remote modem, doing this type of "gateway operation" *IN LIEU OF" the "transparent bridge mode" we all know and love (hate?) isn't a large step at all... Hopefully, that helps make things clearer. I'm *really* hoping I haven't muddied the waters... ;-) Regards, Stan From nobody Wed Dec 17 16:15:05 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEAD1A000F for ; Wed, 17 Dec 2014 16:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 R2FVj1SDY0iA for ; Wed, 17 Dec 2014 16:14:59 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAECF1A0029 for ; Wed, 17 Dec 2014 16:14:58 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id b6so112245lbj.8 for ; Wed, 17 Dec 2014 16:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WebT/duasYjRzLmM/Y0szOVxpLrrDgIT6nGuum53rWY=; b=ORLePM6DOUULRPhR+8JffyQk23rz4rtvzYzfc2iezx8p92q3ESn7luYUfowxRh+TLF bBnoXBvBrxM3iAQUPymzlolNSFrGjOxB3EKy7OSJYv00thSPn5plUjj5xTOJLxeebnDw +AimuqWblbNULKf9LDoQs5z1SgNP+Q8mzU5XM24WNJaXxMIlN0PIP2ZYBGruIbiiy2zZ S1BAm1jIQ9Dph2eNBsh7dENmT6lmnx2h8LLlXzyKJi9woK/qBtQxiCj+tXape28i9C73 wl4abZr54YhQ9KWTtnjbNPNUSChHrHwN3BI2QzZEhZYP3ebzV2VYAvUxSfgMMb/rqys6 Odug== MIME-Version: 1.0 X-Received: by 10.112.198.233 with SMTP id jf9mr23700614lbc.9.1418861697067; Wed, 17 Dec 2014 16:14:57 -0800 (PST) Received: by 10.25.85.201 with HTTP; Wed, 17 Dec 2014 16:14:57 -0800 (PST) In-Reply-To: References: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> Date: Wed, 17 Dec 2014 19:14:57 -0500 Message-ID: From: Stan Ratliff To: Teco Boot Content-Type: multipart/alternative; boundary=001a11c32cf47071b5050a727bd7 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MKJef5kqJd829r8Ki8_LdIG-H3Y Cc: MANET IETF , "Viberg, Neil" Subject: Re: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 00:15:03 -0000 --001a11c32cf47071b5050a727bd7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 17, 2014 at 4:53 PM, Teco Boot wrote: > > I=E2=80=99ve provided my opinion in the meeting. I don=E2=80=99t see a pr= oblem having > vendor extensions in whatever signal. They are optional items in the spec= . > Helpful in some cases. There is always the standards based fallback. > > I cannot follow reasoning behind 2. Can someone explain? > The explanation behind point-of-view #2 is: How can we define a *standards-track* protocol with a TLV in it that says "Put any arbitrary, proprietary information you desire right here."?? Just exactly what makes "Do whatever you want to do, Mr. Radio Vendor" a "standard"? If allowed for Destination Update, specifically with regard to metrics, how does the approach help us normalize/standardize *ANYTHING* ??? This was the group of people that AGONIZED for MONTHS over the precise definition of "Latency", and whether "Latency" should be specified in milliseconds or microseconds... And now we're actually talking about sticking something like this into Destination Update for unknown, proprietary, (potentially arbitrary) metrics?!?!?!?!? If that is the case, why did the Design Team even attempt to look at metrics in the first place? Stan > > Now I=E2=80=99ll continue configuring DHCP option 43. > > Teco > > > > > > Op 17 dec. 2014, om 22:07 heeft Stan Ratliff > het volgende geschreven: > > > > Teco, > > On Wed, Dec 17, 2014 at 3:50 PM, Teco Boot wrote: > > I didn=E2=80=99t see any argument removing vendor extensions on the mai= ling > list. What did go wrong? > > > > Just procedural: it is not the authors which decide what gets in and ou= t > a WG draft. > > > > Perhaps the case is overstated a bit. Let me attempt to rephrase: There > was (and still is) a point of contention (at least amongst the co-authors= ) > about Vendor Extensions, and whether they should be allowed on Destinatio= n > Update/Destination Down. The two points of view are: > > > > 1. Vendor Extensions are pretty much worthless unless/until they are > allowed on Destination Update. > > > > 2. Vendor Extensions are an abomination, *especially* on Destination > Update - at most, they should only be allowed on Destination Up. > > > > During the Honolulu IETF, the author team asked for WG opinions > regarding those two points of view, and/or whether there might be options > the co-authors had not considered. We did actually state that DLEP-07 > reflects point-of-view #2 above; and that it (point-of-view #2) would be > the "default option" going forward. But we asked for opinions on-list. > > > > Up to today, the silence has been deafening. The co-authors would > *greatly* appreciate if other WG participants expressed an opinion on-lis= t, > so that we might guage WG consensus on this item. > > > > Regards, > > Stan > > > > > > > > > > > > Teco > > > > > Op 17 dec. 2014, om 21:36 heeft Viberg, Neil > het volgende geschreven: > > > > > > Rick, > > > > > > I'm sorry to hear you're removing the vendor extension. I would have > > > thought that no uproar would have been a positive signal. > > > > > > I had no problem implementing it when I moved our Draft 5 DLEP > prototype > > > to be compliant with Draft 6 and, more importantly, I found it useful > > > for passing some needed information when we used a proxy DLEP modem f= or > > > a radio without DLEP. > > > > > > I suppose it's not a huge deal. We'll just have to use an experimenta= l > > > TLV if it is taken out. > > > > > > Cheers, > > > Neil > > > > > >> Date: Tue, 16 Dec 2014 15:42:56 +0000 > > >> From: Rick Taylor > > >> To: manet IETF > > >> Subject: [manet] DLEP Vendor Extensions > > >> Message-ID: > > >> > > > > <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalsto > > > rmsoftware.com> > > >> > > >> Content-Type: text/plain; charset=3D"us-ascii" > > >> > > >> All, > > >> > > >> In response to the silence concerning Vendor Extensions in DLEP, and > > > after much deliberation amongst the authors, we have decided to >drop > > > the concept from the protocol. > > >> > > >> Regards, > > >> > > >> Rick Taylor > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > --001a11c32cf47071b5050a727bd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 17, 2014 at 4:53 PM, Teco Boot <teco@inf-net.nl> wrote:
I=E2=80=99ve provided my opinion in= the meeting. I don=E2=80=99t see a problem having vendor extensions in wha= tever signal. They are optional items in the spec. Helpful in some cases. T= here is always the standards based fallback.

I cannot follow reasoning behind 2. Can someone explain?


The explanation behind point-of-view #2 is= :=C2=A0
=C2=A0
How can we define a *standards-track* pr= otocol with a TLV in it that says "Put any arbitrary, proprietary info= rmation you desire right here."?? Just exactly what makes "Do wha= tever you want to do, Mr. Radio Vendor" a "standard"? If all= owed for Destination Update, specifically with regard to metrics, how does = the approach help us normalize/standardize *ANYTHING* ??? This was the grou= p of people that AGONIZED for MONTHS over the precise definition of "L= atency", and whether "Latency" should be specified in millis= econds or microseconds... And now we're actually talking about sticking= something like this into Destination Update for unknown, proprietary, (pot= entially arbitrary) metrics?!?!?!?!? If that is the case, why did the Desig= n Team even attempt to look at metrics in the first place?

Stan


=C2=A0

Now I=E2=80=99ll continue configuring DHCP option 43.

Teco




> Op 17 dec. 2014, om 22:07 heeft Stan Ratliff <ratliffstan@gmail.com> het volgende geschreven:<= br> >
> Teco,
> On Wed, Dec 17, 2014 at 3:50 PM, Teco Boot <teco@inf-net.nl> wrote:
> I didn=E2=80=99t see any argument removing vendor extensions on the ma= iling list. What did go wrong?
>
> Just procedural: it is not the authors which decide what gets in and o= ut a WG draft.
>
> Perhaps the case is overstated a bit. Let me attempt to rephrase: Ther= e was (and still is) a point of contention (at least amongst the co-authors= ) about Vendor Extensions, and whether they should be allowed on Destinatio= n Update/Destination Down. The two points of view are:
>
> 1. Vendor Extensions are pretty much worthless unless/until they are a= llowed on Destination Update.
>
> 2. Vendor Extensions are an abomination, *especially* on Destination U= pdate - at most, they should only be allowed on Destination Up.
>
> During the Honolulu IETF, the author team asked for WG opinions regard= ing those two points of view, and/or whether there might be options the co-= authors had not considered. We did actually state that DLEP-07 reflects poi= nt-of-view #2 above; and that it (point-of-view #2) would be the "defa= ult option" going forward. But we asked for opinions on-list.
>
> Up to today, the silence has been deafening. The co-authors would *gre= atly* appreciate if other WG participants expressed an opinion on-list, so = that we might guage WG consensus on this item.
>
> Regards,
> Stan
>
>
>
>
>
> Teco
>
> > Op 17 dec. 2014, om 21:36 heeft Viberg, Neil <Neil.Viberg@gdcanada.com> het volgende g= eschreven:
> >
> > Rick,
> >
> > I'm sorry to hear you're removing the vendor extension. I= would have
> > thought that no uproar would have been a positive signal.
> >
> > I had no problem implementing it when I moved our Draft 5 DLEP pr= ototype
> > to be compliant with Draft 6 and, more importantly, I found it us= eful
> > for passing some needed information when we used a proxy DLEP mod= em for
> > a radio without DLEP.
> >
> > I suppose it's not a huge deal. We'll just have to use an= experimental
> > TLV if it is taken out.
> >
> > Cheers,
> > Neil
> >
> >> Date: Tue, 16 Dec 2014 15:42:56 +0000
> >> From: Rick Taylor <rick@tropicalstormsoftware.com>
> >> To: manet IETF <manet@ie= tf.org>
> >> Subject: [manet] DLEP Vendor Extensions
> >> Message-ID:
> >>
> > <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.t= ropicalsto
> > rmsoftware.co= m>
> >>
> >> Content-Type: text/plain; charset=3D"us-ascii"
> >>
> >> All,
> >>
> >> In response to the silence concerning Vendor Extensions in DL= EP, and
> > after much deliberation amongst the authors, we have decided to &= gt;drop
> > the concept from the protocol.
> >>
> >> Regards,
> >>
> >> Rick Taylor
> >
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www.ietf.org/mailman/listinfo/manet
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--001a11c32cf47071b5050a727bd7-- From nobody Wed Dec 17 16:20:34 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1CD1A00B1 for ; Wed, 17 Dec 2014 16:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 sYngiwU6PArQ for ; Wed, 17 Dec 2014 16:20:31 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8DA1A00A9 for ; Wed, 17 Dec 2014 16:20:31 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id l18so211607wgh.2 for ; Wed, 17 Dec 2014 16:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=Lo49AhKIE3bCYqXywrJqy7JxqWOcKytHhfrgC/xM0MU=; b=LCjMmf98mA5DWbynRNlk7xmEELuba9YGaFVhSsBU0GOVM5F5l36X+k9CDm6Z4KAgro AQ67tXn0y8X2rbKYSwVWCSKaZpdpjUk8FFNaiuRqvT3Mj2cBiubhtdMZm0riX9cTqESF fc+HbDBHI0ymza5kBIBk/9IYn1EIaMSqwuGhY7iyL+45LmkEgxBtruFCDv33Qo8H9dA9 YIX6btsuJ4sOML1xpoNlqNerNvNBzvKdHbVsSUUds/dLsrDgYbVgA9565/nFz0tfHJVP afs2Y3zgLnCtTbBbYlsNBqmxX+rcW/0ejyUMWmo5hafjjJIw2m7JG0sx8Ua9dYvmVVmv tL5A== X-Received: by 10.180.109.46 with SMTP id hp14mr19357398wib.54.1418862030122; Wed, 17 Dec 2014 16:20:30 -0800 (PST) Received: from [192.168.254.2] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id hz9sm6961168wjb.17.2014.12.17.16.20.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 16:20:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_96EE00B1-6F0D-494B-9B31-84ED6D69BFA8" From: Christopher Dearlove In-Reply-To: Date: Thu, 18 Dec 2014 00:20:26 +0000 Message-Id: <63094407-78D8-4C75-BF18-0A606002CC7C@gmail.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-GU0ZSuThw6Dc2W76LNT2tvVpIQ Cc: "Viberg, Neil" , MANET IETF Subject: Re: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 00:20:33 -0000 --Apple-Mail=_96EE00B1-6F0D-494B-9B31-84ED6D69BFA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 18 Dec 2014, at 00:14, Stan Ratliff wrote: > On Wed, Dec 17, 2014 at 4:53 PM, Teco Boot wrote: > I=92ve provided my opinion in the meeting. I don=92t see a problem = having vendor extensions in whatever signal. They are optional items in = the spec. Helpful in some cases. There is always the standards based = fallback. >=20 > I cannot follow reasoning behind 2. Can someone explain? >=20 >=20 > The explanation behind point-of-view #2 is:=20 > =20 > How can we define a *standards-track* protocol with a TLV in it that = says "Put any arbitrary, proprietary information you desire right = here."?? Just exactly what makes "Do whatever you want to do, Mr. Radio = Vendor" a "standard"? If allowed for Destination Update, specifically = with regard to metrics, how does the approach help us = normalize/standardize *ANYTHING* ??? This was the group of people that = AGONIZED for MONTHS over the precise definition of "Latency", and = whether "Latency" should be specified in milliseconds or microseconds... = And now we're actually talking about sticking something like this into = Destination Update for unknown, proprietary, (potentially arbitrary) = metrics?!?!?!?!? If that is the case, why did the Design Team even = attempt to look at metrics in the first place? LDP has an allocation for vendor specific TLVs, so it wouldn't be a = first. Mind you, there's at least one (other) thing about LDP I wouldn't want = to adopt, so that's not a definitive argument. --Apple-Mail=_96EE00B1-6F0D-494B-9B31-84ED6D69BFA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Wed, Dec 17, 2014 at = 4:53 PM, Teco Boot <teco@inf-net.nl> wrote:
I=92ve provided my opinion in the meeting. I = don=92t see a problem having vendor extensions in whatever signal. They = are optional items in the spec. Helpful in some cases. There is always = the standards based fallback.

I cannot follow reasoning behind 2. Can someone = explain?


The = explanation behind point-of-view #2 = is: 
 
How can we define a = *standards-track* protocol with a TLV in it that says "Put any = arbitrary, proprietary information you desire right here."?? Just = exactly what makes "Do whatever you want to do, Mr. Radio Vendor" a = "standard"? If allowed for Destination Update, specifically with regard = to metrics, how does the approach help us normalize/standardize = *ANYTHING* ??? This was the group of people that AGONIZED for MONTHS = over the precise definition of "Latency", and whether "Latency" should = be specified in milliseconds or microseconds... And now we're actually = talking about sticking something like this into Destination Update for = unknown, proprietary, (potentially arbitrary) metrics?!?!?!?!? If that = is the case, why did the Design Team even attempt to look at metrics in = the first = place?

LDP has = an allocation for vendor specific TLVs, so it wouldn't be a = first.

Mind you, there's at least one (other) = thing about LDP I wouldn't want to adopt, so that's not a definitive = argument.

= --Apple-Mail=_96EE00B1-6F0D-494B-9B31-84ED6D69BFA8-- From nobody Wed Dec 17 16:57:11 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CB81A00FA for ; Wed, 17 Dec 2014 16:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_RED=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 GlQsdmwl5n2B for ; Wed, 17 Dec 2014 16:57:07 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 430901A00E7 for ; Wed, 17 Dec 2014 16:57:07 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Thu, 18 Dec 2014 00:56:38 +0000 From: Rick Taylor To: "Viberg, Neil" Thread-Topic: [manet] [DLEP] DLEP Vendor Extensions Thread-Index: AdAaN+wU/WgXwdWaRQy50/TLweyr1g== Date: Thu, 18 Dec 2014 00:56:36 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F980142A05E5A@tss-server1.home.tropicalstormsoftware.com> References: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/SvT3xwtByMfxUtaanwHSEMaK6K4 Cc: "manet@ietf.org" Subject: Re: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 00:57:09 -0000 Neil, All,=0A= =0A= Sorry, they are such an attractive concept, but we just can't seem to=0A= make them usable.=0A= =0A= I (as the original proponent of Vendor Extensions) have worked really=0A= hard with the other authors to find a way to add some flexibility to the=0A= DLEP metrics set, as it is so simple to outline a use-case for it.=0A= =0A= But, it has proved impossible within the deadlines set by the WG and ADs=0A= to find a solution that is not a 'free for all' where vendors can report=0A= what they like and the routers have no point of reference for=0A= implementation (when anyone can report anything, there is no real=0A= standard anymore).=0A= =0A= Alternative solutions such as reserving a set of TLVs in a system-scoped=0A= block - sort of like the experimental TLVs - were also proposed, but=0A= under close analysis, without explicit value-encoding metadata, there is=0A= still nothing a router can do with what are effectively opaque blobs of=0A= data.=0A= =0A= For a proxy, using the experimental TLV space is the best way to go, as=0A= you are proxying and therefore have full control of both ends. When you=0A= only have control of one end, or are trying to write a standard, such=0A= wildcard metrics become useless very quickly.=0A= =0A= The design team imagined later DLEP standards track documents describing=0A= extra standard metrics for various classes of modem: satcom, mesh,=0A= etc... and I am now convinced that is the best way to go.=0A= =0A= Regards,=0A= =0A= Rick=0A= =0A= =0A= On 17/12/14 20:36, Viberg, Neil wrote:=0A= > Rick,=0A= >=0A= > I'm sorry to hear you're removing the vendor extension. I would have=0A= > thought that no uproar would have been a positive signal.=0A= >=0A= > I had no problem implementing it when I moved our Draft 5 DLEP prototype= =0A= > to be compliant with Draft 6 and, more importantly, I found it useful=0A= > for passing some needed information when we used a proxy DLEP modem for= =0A= > a radio without DLEP.=0A= >=0A= > I suppose it's not a huge deal. We'll just have to use an experimental=0A= > TLV if it is taken out.=0A= >=0A= > Cheers,=0A= > Neil =0A= >=0A= >> Date: Tue, 16 Dec 2014 15:42:56 +0000=0A= >> From: Rick Taylor =0A= >> To: manet IETF =0A= >> Subject: [manet] DLEP Vendor Extensions=0A= >> Message-ID:=0A= >>=0A= > <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalsto= =0A= > rmsoftware.com>=0A= >> =0A= >> Content-Type: text/plain; charset=3D"us-ascii"=0A= >>=0A= >> All,=0A= >>=0A= >> In response to the silence concerning Vendor Extensions in DLEP, and=0A= > after much deliberation amongst the authors, we have decided to >drop=0A= > the concept from the protocol.=0A= >> Regards,=0A= >>=0A= >> Rick Taylor=0A= >=0A= =0A= From nobody Wed Dec 17 22:04:53 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB281A038D for ; Wed, 17 Dec 2014 22:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_RED=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 G8N7MmTpXF_Q for ; Wed, 17 Dec 2014 22:04:48 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0081A01A9 for ; Wed, 17 Dec 2014 22:04:47 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id b13so674576wgh.3 for ; Wed, 17 Dec 2014 22:04:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=8f7RUVHULPs1oijRSnXBenPVUQQrE3dvUuIMa3I2UqE=; b=feRhA+y2+XrSiPkmSqesvcLluiUDx7oM40hUMppUiVXfgmRRPm1MwtmXmKSnKcZB1m Gs5apgTw49wDoUP9pfuHNPMgib4mjkqmZZE6YZmnO5sR/tYwHTycITot/sStW29zISQS C1PNm+YQ334WT4G0ebzIayRy3UPWSIJkUKk35jWkkwMKIaAXLNdq7/joQqWwTtu1Yfhu i88dLzzl2BcpLIDd7lkL4+w8dj2suZstWt9W2/aY+mrSz7oJ3abetOOkUES/GyI2uz+h 2rKacLRw7rMTXxeFd2IQI+2yVO6bVDyJM2j+pogNonhyvVgf+obz9nyFqJ9BPjxzhisT sWZQ== X-Gm-Message-State: ALoCoQmle1Y1ZJfwGhZD3R2x4rS40f/HiaMjnfLZRtU9OSkL3LDOUT/D7clt3OTvYASRLRhPJr2x X-Received: by 10.180.86.38 with SMTP id m6mr1641854wiz.65.1418882685963; Wed, 17 Dec 2014 22:04:45 -0800 (PST) Received: from [192.168.43.109] ([92.69.229.18]) by mx.google.com with ESMTPSA id dp8sm23414905wib.20.2014.12.17.22.04.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 22:04:44 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Teco Boot In-Reply-To: Date: Thu, 18 Dec 2014 07:04:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <43F86C63-94C4-4CA5-8211-2CC87A799D37@inf-net.nl> References: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_Ll7aKtgLYtAVVmWRBSnI4pgJDw Cc: MANET IETF , "Viberg, Neil" Subject: Re: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 06:04:51 -0000 > Op 18 dec. 2014, om 01:14 heeft Stan Ratliff = het volgende geschreven: >=20 >=20 >=20 > On Wed, Dec 17, 2014 at 4:53 PM, Teco Boot wrote: > I=E2=80=99ve provided my opinion in the meeting. I don=E2=80=99t see a = problem having vendor extensions in whatever signal. They are optional = items in the spec. Helpful in some cases. There is always the standards = based fallback. >=20 > I cannot follow reasoning behind 2. Can someone explain? >=20 >=20 > The explanation behind point-of-view #2 is:=20 > =20 > How can we define a *standards-track* protocol with a TLV in it that = says "Put any arbitrary, proprietary information you desire right = here."?? Just exactly what makes "Do whatever you want to do, Mr. Radio = Vendor" a "standard"? If allowed for Destination Update, specifically = with regard to metrics, how does the approach help us = normalize/standardize *ANYTHING* ??? This was the group of people that = AGONIZED for MONTHS over the precise definition of "Latency", and = whether "Latency" should be specified in milliseconds or microseconds... = And now we're actually talking about sticking something like this into = Destination Update for unknown, proprietary, (potentially arbitrary) = metrics?!?!?!?!? If that is the case, why did the Design Team even = attempt to look at metrics in the first place? Sorry, I cannot take these arguments as serious. Protocols that cannot = be extended are short-lived. There is a long list of examples where IETF = STD protocols carry vendor extensions. Teco >=20 > Stan >=20 >=20 > =20 >=20 > Now I=E2=80=99ll continue configuring DHCP option 43. >=20 > Teco >=20 >=20 >=20 >=20 > > Op 17 dec. 2014, om 22:07 heeft Stan Ratliff = het volgende geschreven: > > > > Teco, > > On Wed, Dec 17, 2014 at 3:50 PM, Teco Boot wrote: > > I didn=E2=80=99t see any argument removing vendor extensions on the = mailing list. What did go wrong? > > > > Just procedural: it is not the authors which decide what gets in and = out a WG draft. > > > > Perhaps the case is overstated a bit. Let me attempt to rephrase: = There was (and still is) a point of contention (at least amongst the = co-authors) about Vendor Extensions, and whether they should be allowed = on Destination Update/Destination Down. The two points of view are: > > > > 1. Vendor Extensions are pretty much worthless unless/until they are = allowed on Destination Update. > > > > 2. Vendor Extensions are an abomination, *especially* on Destination = Update - at most, they should only be allowed on Destination Up. > > > > During the Honolulu IETF, the author team asked for WG opinions = regarding those two points of view, and/or whether there might be = options the co-authors had not considered. We did actually state that = DLEP-07 reflects point-of-view #2 above; and that it (point-of-view #2) = would be the "default option" going forward. But we asked for opinions = on-list. > > > > Up to today, the silence has been deafening. The co-authors would = *greatly* appreciate if other WG participants expressed an opinion = on-list, so that we might guage WG consensus on this item. > > > > Regards, > > Stan > > > > > > > > > > > > Teco > > > > > Op 17 dec. 2014, om 21:36 heeft Viberg, Neil = het volgende geschreven: > > > > > > Rick, > > > > > > I'm sorry to hear you're removing the vendor extension. I would = have > > > thought that no uproar would have been a positive signal. > > > > > > I had no problem implementing it when I moved our Draft 5 DLEP = prototype > > > to be compliant with Draft 6 and, more importantly, I found it = useful > > > for passing some needed information when we used a proxy DLEP = modem for > > > a radio without DLEP. > > > > > > I suppose it's not a huge deal. We'll just have to use an = experimental > > > TLV if it is taken out. > > > > > > Cheers, > > > Neil > > > > > >> Date: Tue, 16 Dec 2014 15:42:56 +0000 > > >> From: Rick Taylor > > >> To: manet IETF > > >> Subject: [manet] DLEP Vendor Extensions > > >> Message-ID: > > >> > > > = <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalsto > > > rmsoftware.com> > > >> > > >> Content-Type: text/plain; charset=3D"us-ascii" > > >> > > >> All, > > >> > > >> In response to the silence concerning Vendor Extensions in DLEP, = and > > > after much deliberation amongst the authors, we have decided to = >drop > > > the concept from the protocol. > > >> > > >> Regards, > > >> > > >> Rick Taylor > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet >=20 From nobody Wed Dec 17 23:42:48 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E571A03A3 for ; Wed, 17 Dec 2014 23:42:47 -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 dkhm4re3tBW4 for ; Wed, 17 Dec 2014 23:42:46 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08BF1A038A for ; Wed, 17 Dec 2014 23:42:45 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so840250wgh.1 for ; Wed, 17 Dec 2014 23:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=3rHEWQvMBpG86KkzBCdX/IJsIGtjlqGdxN/zsLNwMz0=; b=ofJ99RXshxKHDyuqgKdLJYQu6OHak8GxaZ6gsNDssQoBRyMiG0BHFsZ29+UatUDlLF /aAtCVuCCs9fcpRi1DhSUfqE2hgGdvoSB4nP04/u09rELJV+5N3xI1OrMHpjLM04tai5 XPy01JXOLcK66cGypFDj/xobXnqj0r47PMbiGL4O178YZYQ9c/b/Q/LJb34MTW5rEuRL R3OCMvK/6P1RUftMz3pwkz27rVOIKOeeiPWb73PwoRa3arK0oAuuKA0EEM3YXDS+0Rlk Uj712oBXIOSaVDcNVTtSICu/EE6gEj0a9WGUq7/xC360mtQdJDC8oYB3AoBCehXAWgau 62ZA== X-Received: by 10.194.184.171 with SMTP id ev11mr1246497wjc.119.1418888564745; Wed, 17 Dec 2014 23:42:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Wed, 17 Dec 2014 23:42:23 -0800 (PST) In-Reply-To: <43F86C63-94C4-4CA5-8211-2CC87A799D37@inf-net.nl> References: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> <43F86C63-94C4-4CA5-8211-2CC87A799D37@inf-net.nl> From: Henning Rogge Date: Thu, 18 Dec 2014 08:42:23 +0100 Message-ID: To: Teco Boot Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/DlAjAoPdNWZCjibMrX_o5fdehPE Cc: "Viberg, Neil" , MANET IETF Subject: Re: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 07:42:47 -0000 On Thu, Dec 18, 2014 at 7:04 AM, Teco Boot wrote: >> The explanation behind point-of-view #2 is: >> >> How can we define a *standards-track* protocol with a TLV in it that say= s "Put any arbitrary, proprietary information you desire right here."?? Jus= t exactly what makes "Do whatever you want to do, Mr. Radio Vendor" a "stan= dard"? If allowed for Destination Update, specifically with regard to metri= cs, how does the approach help us normalize/standardize *ANYTHING* ??? This= was the group of people that AGONIZED for MONTHS over the precise definiti= on of "Latency", and whether "Latency" should be specified in milliseconds = or microseconds... And now we're actually talking about sticking something = like this into Destination Update for unknown, proprietary, (potentially ar= bitrary) metrics?!?!?!?!? If that is the case, why did the Design Team even= attempt to look at metrics in the first place? > > Sorry, I cannot take these arguments as serious. Protocols that cannot be= extended are short-lived. There is a long list of examples where IETF STD = protocols carry vendor extensions. I would like Vendors coming to this group and helping to make their vendor extensions available for everyone by putting them into a RFC. Henning Rogge From nobody Thu Dec 18 04:50:29 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713B01A8890 for ; Thu, 18 Dec 2014 04:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_RED=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 kONgfayd3Cp8 for ; Thu, 18 Dec 2014 04:50:24 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CDD1A8879 for ; Thu, 18 Dec 2014 04:50:24 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so1638295wiv.11 for ; Thu, 18 Dec 2014 04:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5gte+3Bpk2w7GQGFBaXmXfxLHrYo0f4XmiXO7ZCnIYY=; b=VyQSpl5TudbYC9rplagCh5y/xzyLSk6l00v0KUJbh6y4rOnfS9sbEgixtU0IMg8Ymd HIDGw80hPRsqO0+X5j9ouH5LGGuQcXiSIsa5zg725OVW7TOIogIUVVJTRZxkx6BxQpDk n/V1GnTLdhivYSrg6fcZOxEJI3IXI6qVP+ewH3uYaoZaTooxRyxj5CNwDp7avRcKrthO vBBfx8EyhT4hlFYi2h1hmHTAgxNuBtm3h9k2NfFKnuOsWxeCvVTZjzJusdArvtmJ4V21 X0nlwXgy3meTn340oHeiEjYk3r0+DM2x8+EwTpdbZNrle0cYgyhe1spIAAe72vhImf7j v+qg== X-Received: by 10.194.94.227 with SMTP id df3mr4362349wjb.34.1418907023060; Thu, 18 Dec 2014 04:50:23 -0800 (PST) Received: from [10.0.4.178] ([217.158.48.187]) by mx.google.com with ESMTPSA id cp4sm8849961wjb.16.2014.12.18.04.50.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Dec 2014 04:50:22 -0800 (PST) Message-ID: <5492CD8D.8000607@gmail.com> Date: Thu, 18 Dec 2014 12:50:21 +0000 From: John Dowdell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: manet@ietf.org References: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> <38A5475DE83986499AEACD2CFAFC3F980142A05E5A@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980142A05E5A@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NYr4dBzJnUCmJ6JVbfXmRly3vFE Subject: Re: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 12:50:26 -0000 Just to add my view ... having sat across the desk from Rick and had many, many conversations with Rick and Stan on this topic over very many months, the real problem as I see it is when you take a concept (however good) and actually have to write it down in terms that the IESG will accept. The author team could not make that last step, despite no shortage of trying, so in the interests of cleaning up and moving on to the fast approaching brick wall deadline, out this goes. I fully support the author team on this one. John On 18/12/14 00:56, Rick Taylor wrote: > Neil, All, > > Sorry, they are such an attractive concept, but we just can't seem to > make them usable. > > I (as the original proponent of Vendor Extensions) have worked really > hard with the other authors to find a way to add some flexibility to the > DLEP metrics set, as it is so simple to outline a use-case for it. > > But, it has proved impossible within the deadlines set by the WG and ADs > to find a solution that is not a 'free for all' where vendors can report > what they like and the routers have no point of reference for > implementation (when anyone can report anything, there is no real > standard anymore). > > Alternative solutions such as reserving a set of TLVs in a system-scoped > block - sort of like the experimental TLVs - were also proposed, but > under close analysis, without explicit value-encoding metadata, there is > still nothing a router can do with what are effectively opaque blobs of > data. > > For a proxy, using the experimental TLV space is the best way to go, as > you are proxying and therefore have full control of both ends. When you > only have control of one end, or are trying to write a standard, such > wildcard metrics become useless very quickly. > > The design team imagined later DLEP standards track documents describing > extra standard metrics for various classes of modem: satcom, mesh, > etc... and I am now convinced that is the best way to go. > > Regards, > > Rick > > > On 17/12/14 20:36, Viberg, Neil wrote: >> Rick, >> >> I'm sorry to hear you're removing the vendor extension. I would have >> thought that no uproar would have been a positive signal. >> >> I had no problem implementing it when I moved our Draft 5 DLEP prototype >> to be compliant with Draft 6 and, more importantly, I found it useful >> for passing some needed information when we used a proxy DLEP modem for >> a radio without DLEP. >> >> I suppose it's not a huge deal. We'll just have to use an experimental >> TLV if it is taken out. >> >> Cheers, >> Neil >> >>> Date: Tue, 16 Dec 2014 15:42:56 +0000 >>> From: Rick Taylor >>> To: manet IETF >>> Subject: [manet] DLEP Vendor Extensions >>> Message-ID: >>> >> <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalsto >> rmsoftware.com> >>> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> All, >>> >>> In response to the silence concerning Vendor Extensions in DLEP, and >> after much deliberation amongst the authors, we have decided to >drop >> the concept from the protocol. >>> Regards, >>> >>> Rick Taylor > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Dec 18 07:00:23 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2D41A00FE for ; Thu, 18 Dec 2014 07:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_RED=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 zj-4KMZgxI_k for ; Thu, 18 Dec 2014 07:00:04 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138781A8983 for ; Thu, 18 Dec 2014 07:00:04 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id gf13so1127789lab.7 for ; Thu, 18 Dec 2014 07:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YM6x2V5tDfAsav7DxfjspKjTsXeDLA/6kCWUT2ylBDg=; b=ExCWT/Qv1EysrVOiFuC44Ht4iLJIGVLwYw3nKkmp2HfLGLL/9BzQ/Yl0wPiSopFd0M KRTFcqiiiKIdjvjOQ/krUZbyLWHC9LJ8vHZpAyDRNY+kjui1zfa2S4lleME+7/7s1mml NbGrMowoLU5/ZP4etCtqFwIcxh6Yc7QD+/OfGtKj7eYkKBZ/f2yMxm+FxnYPLl1r+4S/ kbOveD7W/jXHfrLqTBDNC2DZs8U44H4GaYPI3XBlpAbYCMmb7gKPsQNjV0k3S0aYuZ+X fx5Tvy8G9CTgUKCWdQn0pQgR72dnv/8SzAHiYBkVM7MUgqmbQT8GZozzwUffD/jvRJ2r NvNQ== MIME-Version: 1.0 X-Received: by 10.152.26.201 with SMTP id n9mr2780391lag.50.1418914802489; Thu, 18 Dec 2014 07:00:02 -0800 (PST) Received: by 10.25.85.201 with HTTP; Thu, 18 Dec 2014 07:00:02 -0800 (PST) In-Reply-To: <43F86C63-94C4-4CA5-8211-2CC87A799D37@inf-net.nl> References: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> <43F86C63-94C4-4CA5-8211-2CC87A799D37@inf-net.nl> Date: Thu, 18 Dec 2014 10:00:02 -0500 Message-ID: From: Stan Ratliff To: Teco Boot Content-Type: multipart/alternative; boundary=089e0160a706c4dd7b050a7ed834 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/KjNnmiXzOCjt5jVEINSTvnPFZ18 Cc: MANET IETF , "Viberg, Neil" Subject: Re: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 15:00:12 -0000 --089e0160a706c4dd7b050a7ed834 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 18, 2014 at 1:04 AM, Teco Boot wrote: > > > > Op 18 dec. 2014, om 01:14 heeft Stan Ratliff > het volgende geschreven: > > > > > > > > On Wed, Dec 17, 2014 at 4:53 PM, Teco Boot wrote: > > I=E2=80=99ve provided my opinion in the meeting. I don=E2=80=99t see a = problem having > vendor extensions in whatever signal. They are optional items in the spec= . > Helpful in some cases. There is always the standards based fallback. > > > > I cannot follow reasoning behind 2. Can someone explain? > > > > > > The explanation behind point-of-view #2 is: > > > > How can we define a *standards-track* protocol with a TLV in it that > says "Put any arbitrary, proprietary information you desire right here."?= ? > Just exactly what makes "Do whatever you want to do, Mr. Radio Vendor" a > "standard"? If allowed for Destination Update, specifically with regard t= o > metrics, how does the approach help us normalize/standardize *ANYTHING* ?= ?? > This was the group of people that AGONIZED for MONTHS over the precise > definition of "Latency", and whether "Latency" should be specified in > milliseconds or microseconds... And now we're actually talking about > sticking something like this into Destination Update for unknown, > proprietary, (potentially arbitrary) metrics?!?!?!?!? If that is the case= , > why did the Design Team even attempt to look at metrics in the first plac= e? > > Sorry, I cannot take these arguments as serious. This type of statement is unhelpful. It does not advance the discussion. Attempting to dismiss an opinion does nothing to *change* said opinion. I'm serious. Very serious. So help me see the error of my ways; but please refrain from this type of statement, which IMO borders on ad hominem. > Protocols that cannot be extended are short-lived. I believe that TLV-based protocols such as DLEP *can* easily be extended, in an open, well-documented, interoperable manner. Therefore, I believe this statement is self-evident, but does not apply to the issue at hand. > There is a long list of examples where IETF STD protocols carry vendor > extensions. > Carrying vendor extensions for ancillary functionality is one thing. One of the stated reasons behind making Vendor Extensions available in the Destination Update was to allow for additional metrics. Metrics, and the ability to share them in a well-understood, interoperable manner are, IMO, *the core* of the DLEP specification. Allowing the addition of a "vendor-specific glop of goo" into the *core* of the protocol is not "standard", and by definition it is not "interoperable". You can't even successfully decode it with Wireshark (unless, of course, you posses the vendor-supplied 'secret-sauce' that goes with it). At this point, as an editor of the DLEP specification and as a chair, I do *NOT* believe the WG has reached consensus wrt Vendor Extensions. Therefore, the plan announced in Honolulu is still operative - that is, Vendor Extensions are allowed *only* on the Peer Initialization/Peer Update orders (IIRC), but are not allowed on any of the 'Destination' orders - or more specifically (and correctly), I should state that the Vendor Extension functionality in DLEP-07 will be carried forward without modification. Further, just so that we're clear - *If* working group consensus forms around the notion that Vendor Extensions should be allowed in Destination Update for metrics, then: 1. As an editor, I will dutifully modify the document to reflect the WG consensus, and 2. As an author, editor, co-chair, and IETF participant, I will use all the persuasive ability I have at the AD/IESG level to make sure the specification *NEVER* gets published at IETF. Unless, of course, someone actually decides to help me see the error of my position, or offers an alternative... Stan > > Teco > > > > > > Stan > > > > > > > > > > Now I=E2=80=99ll continue configuring DHCP option 43. > > > > Teco > > > > > > > > > > > Op 17 dec. 2014, om 22:07 heeft Stan Ratliff > het volgende geschreven: > > > > > > Teco, > > > On Wed, Dec 17, 2014 at 3:50 PM, Teco Boot wrote: > > > I didn=E2=80=99t see any argument removing vendor extensions on the m= ailing > list. What did go wrong? > > > > > > Just procedural: it is not the authors which decide what gets in and > out a WG draft. > > > > > > Perhaps the case is overstated a bit. Let me attempt to rephrase: > There was (and still is) a point of contention (at least amongst the > co-authors) about Vendor Extensions, and whether they should be allowed o= n > Destination Update/Destination Down. The two points of view are: > > > > > > 1. Vendor Extensions are pretty much worthless unless/until they are > allowed on Destination Update. > > > > > > 2. Vendor Extensions are an abomination, *especially* on Destination > Update - at most, they should only be allowed on Destination Up. > > > > > > During the Honolulu IETF, the author team asked for WG opinions > regarding those two points of view, and/or whether there might be options > the co-authors had not considered. We did actually state that DLEP-07 > reflects point-of-view #2 above; and that it (point-of-view #2) would be > the "default option" going forward. But we asked for opinions on-list. > > > > > > Up to today, the silence has been deafening. The co-authors would > *greatly* appreciate if other WG participants expressed an opinion on-lis= t, > so that we might guage WG consensus on this item. > > > > > > Regards, > > > Stan > > > > > > > > > > > > > > > > > > Teco > > > > > > > Op 17 dec. 2014, om 21:36 heeft Viberg, Neil < > Neil.Viberg@gdcanada.com> het volgende geschreven: > > > > > > > > Rick, > > > > > > > > I'm sorry to hear you're removing the vendor extension. I would hav= e > > > > thought that no uproar would have been a positive signal. > > > > > > > > I had no problem implementing it when I moved our Draft 5 DLEP > prototype > > > > to be compliant with Draft 6 and, more importantly, I found it usef= ul > > > > for passing some needed information when we used a proxy DLEP modem > for > > > > a radio without DLEP. > > > > > > > > I suppose it's not a huge deal. We'll just have to use an > experimental > > > > TLV if it is taken out. > > > > > > > > Cheers, > > > > Neil > > > > > > > >> Date: Tue, 16 Dec 2014 15:42:56 +0000 > > > >> From: Rick Taylor > > > >> To: manet IETF > > > >> Subject: [manet] DLEP Vendor Extensions > > > >> Message-ID: > > > >> > > > > > <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalsto > > > > rmsoftware.com> > > > >> > > > >> Content-Type: text/plain; charset=3D"us-ascii" > > > >> > > > >> All, > > > >> > > > >> In response to the silence concerning Vendor Extensions in DLEP, a= nd > > > > after much deliberation amongst the authors, we have decided to >dr= op > > > > the concept from the protocol. > > > >> > > > >> Regards, > > > >> > > > >> Rick Taylor > > > > > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org > > > > https://www.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www.ietf.org/mailman/listinfo/manet > > > > --089e0160a706c4dd7b050a7ed834 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Dec 18, 2014 at 1:04 AM, Teco Boot <teco@inf-net.nl> w= rote:

> Op 18 dec. 2014, om 01:14 heeft Stan Ratliff <ratliffstan@gmail.com> het volgende geschreven:<= br> >
>
>
> On Wed, Dec 17, 2014 at 4:53 PM, Teco Boot <teco@inf-net.nl> wrote:
> I=E2=80=99ve provided my opinion in the meeting. I don=E2=80=99t see a= problem having vendor extensions in whatever signal. They are optional ite= ms in the spec. Helpful in some cases. There is always the standards based = fallback.
>
> I cannot follow reasoning behind 2. Can someone explain?
>
>
> The explanation behind point-of-view #2 is:
>
> How can we define a *standards-track* protocol with a TLV in it that s= ays "Put any arbitrary, proprietary information you desire right here.= "?? Just exactly what makes "Do whatever you want to do, Mr. Radi= o Vendor" a "standard"? If allowed for Destination Update, s= pecifically with regard to metrics, how does the approach help us normalize= /standardize *ANYTHING* ??? This was the group of people that AGONIZED for = MONTHS over the precise definition of "Latency", and whether &quo= t;Latency" should be specified in milliseconds or microseconds... And = now we're actually talking about sticking something like this into Dest= ination Update for unknown, proprietary, (potentially arbitrary) metrics?!?= !?!?!? If that is the case, why did the Design Team even attempt to look at= metrics in the first place?

Sorry, I cannot take these arguments as serious.
=C2=A0
This type of statement is unhelpful. It does not advance the discu= ssion. Attempting to dismiss an opinion does nothing to *change* said opini= on. I'm serious. Very serious. So help me see the error of my ways; but= please refrain from this type of statement, which IMO borders on ad homine= m.
=C2=A0
=C2=A0
Protocols that c= annot be extended are short-lived.
=C2=A0
I bel= ieve that TLV-based protocols such as DLEP *can* easily be extended, in an = open, well-documented, interoperable manner. Therefore, I believe this stat= ement is self-evident, but does not=C2=A0apply to=C2=A0the issue at hand. <= /div>
=C2=A0
=C2=A0
There is a long lis= t of examples where IETF STD protocols carry vendor extensions.
=C2=A0
Carrying vendor extensions for ancillary functio= nality is one thing. One of the stated reasons behind making Vendor Extensi= ons available in the Destination Update was to allow for additional metrics= . Metrics, and the ability to share them in a well-understood, interoperabl= e manner are, IMO, *the core* of the DLEP specification. Allowing the addit= ion of a "vendor-specific glop of goo" into the *core* of the pro= tocol is not "standard", and by definition it is not "intero= perable". You can't even successfully decode it with Wireshark (un= less, of course, you posses the vendor-supplied 'secret-sauce' that= goes with it).
=C2=A0
At this point, as an editor of = the DLEP specification and as a chair, I do *NOT* believe the WG has reache= d consensus wrt Vendor Extensions. Therefore, the plan announced in Honolul= u is still operative - that is, Vendor Extensions are allowed *only* on the= Peer Initialization/Peer Update orders (IIRC), but are not allowed on any = of the 'Destination' orders - or more specifically (and correctly),= I should=C2=A0state that the Vendor Extension functionality in DLEP-07 wil= l be carried forward without modification.
=C2=A0
Furt= her, just so that we're clear - *If* working group consensus forms arou= nd the notion that Vendor Extensions should be allowed in Destination Updat= e for metrics, then:
1. As an editor, I will dutifully modify the= document to reflect the WG consensus, and
2. As an author, edito= r, co-chair, and IETF participant, I will use=C2=A0all the=C2=A0persuasive = ability I have at the AD/IESG level to make sure the specification *NEVER* = gets published at IETF.
=C2=A0
Unless, of course, someo= ne actually decides to help me see the error of my position, or offers an a= lternative...
=C2=A0
Stan
=C2=A0
= =C2=A0
=C2=A0

Teco


>
> Stan
>
>
>
>
> Now I=E2=80=99ll continue configuring DHCP option 43.
>
> Teco
>
>
>
>
> > Op 17 dec. 2014, om 22:07 heeft Stan Ratliff <ratliffstan@gmail.com> het volgende geschre= ven:
> >
> > Teco,
> > On Wed, Dec 17, 2014 at 3:50 PM, Teco Boot <teco@inf-net.nl> wrote:
> > I didn=E2=80=99t see any argument removing vendor extensions on t= he mailing list. What did go wrong?
> >
> > Just procedural: it is not the authors which decide what gets in = and out a WG draft.
> >
> > Perhaps the case is overstated a bit. Let me attempt to rephrase:= There was (and still is) a point of contention (at least amongst the co-au= thors) about Vendor Extensions, and whether they should be allowed on Desti= nation Update/Destination Down. The two points of view are:
> >
> > 1. Vendor Extensions are pretty much worthless unless/until they = are allowed on Destination Update.
> >
> > 2. Vendor Extensions are an abomination, *especially* on Destinat= ion Update - at most, they should only be allowed on Destination Up.
> >
> > During the Honolulu IETF, the author team asked for WG opinions r= egarding those two points of view, and/or whether there might be options th= e co-authors had not considered. We did actually state that DLEP-07 reflect= s point-of-view #2 above; and that it (point-of-view #2) would be the "= ;default option" going forward. But we asked for opinions on-list.
> >
> > Up to today, the silence has been deafening. The co-authors would= *greatly* appreciate if other WG participants expressed an opinion on-list= , so that we might guage WG consensus on this item.
> >
> > Regards,
> > Stan
> >
> >
> >
> >
> >
> > Teco
> >
> > > Op 17 dec. 2014, om 21:36 heeft Viberg, Neil <Neil.Viberg@gdcanada.com> het volge= nde geschreven:
> > >
> > > Rick,
> > >
> > > I'm sorry to hear you're removing the vendor extensi= on. I would have
> > > thought that no uproar would have been a positive signal. > > >
> > > I had no problem implementing it when I moved our Draft 5 DL= EP prototype
> > > to be compliant with Draft 6 and, more importantly, I found = it useful
> > > for passing some needed information when we used a proxy DLE= P modem for
> > > a radio without DLEP.
> > >
> > > I suppose it's not a huge deal. We'll just have to u= se an experimental
> > > TLV if it is taken out.
> > >
> > > Cheers,
> > > Neil
> > >
> > >> Date: Tue, 16 Dec 2014 15:42:56 +0000
> > >> From: Rick Taylor <rick@tropicalstormsoftware.com>
> > >> To: manet IETF <man= et@ietf.org>
> > >> Subject: [manet] DLEP Vendor Extensions
> > >> Message-ID:
> > >>
> > > <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.h= ome.tropicalsto
> > > rmsoftwa= re.com>
> > >>
> > >> Content-Type: text/plain; charset=3D"us-ascii"=
> > >>
> > >> All,
> > >>
> > >> In response to the silence concerning Vendor Extensions = in DLEP, and
> > > after much deliberation amongst the authors, we have decided= to >drop
> > > the concept from the protocol.
> > >>
> > >> Regards,
> > >>
> > >> Rick Taylor
> > >
> > > _______________________________________________
> > > manet mailing list
> > > manet@ietf.org
> > > https://www.ietf.org/mailman/listinfo/manet
> >
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www.ietf.org/mailman/listinfo/manet
>

--089e0160a706c4dd7b050a7ed834-- From nobody Thu Dec 18 07:42:31 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A601A9075 for ; Thu, 18 Dec 2014 07:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_RED=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 M_5bcluTsO9V for ; Thu, 18 Dec 2014 07:42:17 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405A11A1B42 for ; Thu, 18 Dec 2014 07:42:12 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so2259406wiv.7 for ; Thu, 18 Dec 2014 07:42:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=U6x8cmDEYtf0R0XtET1ITqoZF9m/0hw2IgYHlcEuPeo=; b=LDPI1V8iGiFMdMXFFxbMIhsJQBFHK22vex3gHoLwKPXcPYUqULchOsflvonkaFrx/S nnXd7Rdtf2zm9BFxVxJW5RqYRvnVpJVn5zOs/Za8f78U1CtXMYsSX/wKBLBmjUkr1IoR v/5+31QTH5/j1Qy5pGodQYwXkN6E71KBXLIwUAVwS2VR7GPoakQw6bLkrkc3/mzLfMxl OrKasbajx3U6jy5zVjGZZKt4qq2+L71tkZT/BTotnl3iU2r8FWwp9LmyLKQ36155IVpd Z9r9KQaUwqlkHHEO5jst/JzpQMxP99cv04fJAZFQvbw2XXSraGvLRkNpsp3gEjqoQej5 g4lA== X-Gm-Message-State: ALoCoQkPtllq077USlAYs0CF6PErFLCF1y6nOqvSUn4PYpUEOesAZvxSVLpxiitYE+ukmz14q0Vy X-Received: by 10.180.77.79 with SMTP id q15mr25289430wiw.8.1418917331646; Thu, 18 Dec 2014 07:42:11 -0800 (PST) Received: from [192.168.43.109] ([188.207.79.73]) by mx.google.com with ESMTPSA id wx3sm9368411wjc.19.2014.12.18.07.42.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 07:42:10 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Teco Boot In-Reply-To: Date: Thu, 18 Dec 2014 16:42:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2142BCFA1F7F0D468F8EE6C8DE719E68078AFB4C@CGYSVW100.gdcan.com> <43F86C63-94C4-4CA5-8211-2CC87A799D37@inf-net.nl> To: Stan Ratliff X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/gGf7fvMWgp9re4BgPxjtMXo2UGI Cc: MANET IETF , "Viberg, Neil" Subject: Re: [manet] [DLEP] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 15:42:24 -0000 You miss the point. Of course vendor extension metrics are not part of = the *core* DLEP spec. The core spec is about encoding the extensions on = a standard way. Teco > Op 18 dec. 2014, om 16:00 heeft Stan Ratliff = het volgende geschreven: >=20 >=20 > On Thu, Dec 18, 2014 at 1:04 AM, Teco Boot wrote: >=20 > > Op 18 dec. 2014, om 01:14 heeft Stan Ratliff = het volgende geschreven: > > > > > > > > On Wed, Dec 17, 2014 at 4:53 PM, Teco Boot wrote: > > I=E2=80=99ve provided my opinion in the meeting. I don=E2=80=99t see = a problem having vendor extensions in whatever signal. They are optional = items in the spec. Helpful in some cases. There is always the standards = based fallback. > > > > I cannot follow reasoning behind 2. Can someone explain? > > > > > > The explanation behind point-of-view #2 is: > > > > How can we define a *standards-track* protocol with a TLV in it that = says "Put any arbitrary, proprietary information you desire right = here."?? Just exactly what makes "Do whatever you want to do, Mr. Radio = Vendor" a "standard"? If allowed for Destination Update, specifically = with regard to metrics, how does the approach help us = normalize/standardize *ANYTHING* ??? This was the group of people that = AGONIZED for MONTHS over the precise definition of "Latency", and = whether "Latency" should be specified in milliseconds or microseconds... = And now we're actually talking about sticking something like this into = Destination Update for unknown, proprietary, (potentially arbitrary) = metrics?!?!?!?!? If that is the case, why did the Design Team even = attempt to look at metrics in the first place? >=20 > Sorry, I cannot take these arguments as serious. > =20 > This type of statement is unhelpful. It does not advance the = discussion. Attempting to dismiss an opinion does nothing to *change* = said opinion. I'm serious. Very serious. So help me see the error of my = ways; but please refrain from this type of statement, which IMO borders = on ad hominem. > =20 > =20 > Protocols that cannot be extended are short-lived. > =20 > I believe that TLV-based protocols such as DLEP *can* easily be = extended, in an open, well-documented, interoperable manner. Therefore, = I believe this statement is self-evident, but does not apply to the = issue at hand. > =20 > =20 > There is a long list of examples where IETF STD protocols carry vendor = extensions. > =20 > Carrying vendor extensions for ancillary functionality is one thing. = One of the stated reasons behind making Vendor Extensions available in = the Destination Update was to allow for additional metrics. Metrics, and = the ability to share them in a well-understood, interoperable manner = are, IMO, *the core* of the DLEP specification. Allowing the addition of = a "vendor-specific glop of goo" into the *core* of the protocol is not = "standard", and by definition it is not "interoperable". You can't even = successfully decode it with Wireshark (unless, of course, you posses the = vendor-supplied 'secret-sauce' that goes with it). > =20 > At this point, as an editor of the DLEP specification and as a chair, = I do *NOT* believe the WG has reached consensus wrt Vendor Extensions. = Therefore, the plan announced in Honolulu is still operative - that is, = Vendor Extensions are allowed *only* on the Peer Initialization/Peer = Update orders (IIRC), but are not allowed on any of the 'Destination' = orders - or more specifically (and correctly), I should state that the = Vendor Extension functionality in DLEP-07 will be carried forward = without modification. > =20 > Further, just so that we're clear - *If* working group consensus forms = around the notion that Vendor Extensions should be allowed in = Destination Update for metrics, then: > 1. As an editor, I will dutifully modify the document to reflect the = WG consensus, and > 2. As an author, editor, co-chair, and IETF participant, I will use = all the persuasive ability I have at the AD/IESG level to make sure the = specification *NEVER* gets published at IETF. > =20 > Unless, of course, someone actually decides to help me see the error = of my position, or offers an alternative... > =20 > Stan > =20 > =20 > =20 >=20 > Teco >=20 >=20 > > > > Stan > > > > > > > > > > Now I=E2=80=99ll continue configuring DHCP option 43. > > > > Teco > > > > > > > > > > > Op 17 dec. 2014, om 22:07 heeft Stan Ratliff = het volgende geschreven: > > > > > > Teco, > > > On Wed, Dec 17, 2014 at 3:50 PM, Teco Boot = wrote: > > > I didn=E2=80=99t see any argument removing vendor extensions on = the mailing list. What did go wrong? > > > > > > Just procedural: it is not the authors which decide what gets in = and out a WG draft. > > > > > > Perhaps the case is overstated a bit. Let me attempt to rephrase: = There was (and still is) a point of contention (at least amongst the = co-authors) about Vendor Extensions, and whether they should be allowed = on Destination Update/Destination Down. The two points of view are: > > > > > > 1. Vendor Extensions are pretty much worthless unless/until they = are allowed on Destination Update. > > > > > > 2. Vendor Extensions are an abomination, *especially* on = Destination Update - at most, they should only be allowed on Destination = Up. > > > > > > During the Honolulu IETF, the author team asked for WG opinions = regarding those two points of view, and/or whether there might be = options the co-authors had not considered. We did actually state that = DLEP-07 reflects point-of-view #2 above; and that it (point-of-view #2) = would be the "default option" going forward. But we asked for opinions = on-list. > > > > > > Up to today, the silence has been deafening. The co-authors would = *greatly* appreciate if other WG participants expressed an opinion = on-list, so that we might guage WG consensus on this item. > > > > > > Regards, > > > Stan > > > > > > > > > > > > > > > > > > Teco > > > > > > > Op 17 dec. 2014, om 21:36 heeft Viberg, Neil = het volgende geschreven: > > > > > > > > Rick, > > > > > > > > I'm sorry to hear you're removing the vendor extension. I would = have > > > > thought that no uproar would have been a positive signal. > > > > > > > > I had no problem implementing it when I moved our Draft 5 DLEP = prototype > > > > to be compliant with Draft 6 and, more importantly, I found it = useful > > > > for passing some needed information when we used a proxy DLEP = modem for > > > > a radio without DLEP. > > > > > > > > I suppose it's not a huge deal. We'll just have to use an = experimental > > > > TLV if it is taken out. > > > > > > > > Cheers, > > > > Neil > > > > > > > >> Date: Tue, 16 Dec 2014 15:42:56 +0000 > > > >> From: Rick Taylor > > > >> To: manet IETF > > > >> Subject: [manet] DLEP Vendor Extensions > > > >> Message-ID: > > > >> > > > > = <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalsto > > > > rmsoftware.com> > > > >> > > > >> Content-Type: text/plain; charset=3D"us-ascii" > > > >> > > > >> All, > > > >> > > > >> In response to the silence concerning Vendor Extensions in = DLEP, and > > > > after much deliberation amongst the authors, we have decided to = >drop > > > > the concept from the protocol. > > > >> > > > >> Regards, > > > >> > > > >> Rick Taylor > > > > > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org > > > > https://www.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www.ietf.org/mailman/listinfo/manet > > >=20 From nobody Thu Dec 18 07:46:41 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4CA1A90E5 for ; Thu, 18 Dec 2014 07:46:40 -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 Hb1kTVa5iPZP for ; Thu, 18 Dec 2014 07:46:39 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED1B1A9087 for ; Thu, 18 Dec 2014 07:46:31 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id x12so1964275wgg.24 for ; Thu, 18 Dec 2014 07:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VJMkqEiom9/TeHWMCc+L7+pcFrERmY7GLUP9CilVj6g=; b=KKZ+USjTBLQF99Zb5loIm/DfmJ7yYkpFevPmehorSOfg72hKEa1uW1rgju3kgDfxCU iY/9qu2iM1LC5ZOpcNECWfagT9vh8Ta4F79+PhCMjQNbH8tbbiFtK+0JDv71v1z2Xkna R/LUAzeu1reFXhaEBgHyqYMcC76L0aRa4LFGuKvtuAJwdDn+tbUwyA9dtD2CMRAwFK6A bu/uL58mPG/znLgRKnFcb4TAi5zJbC2PjEnI/MbuITCCWVpU19Gv6at9W3AQz7CQpCDm yfG1RhO2fXwv21QeBUPOL45vgvOSxNZrgwKw/Xp309ZDmHqQ2BU0GlHAxp4AMbwaAkEn SSTQ== X-Received: by 10.180.75.237 with SMTP id f13mr6196972wiw.69.1418917589777; Thu, 18 Dec 2014 07:46:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Thu, 18 Dec 2014 07:46:09 -0800 (PST) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Thu, 18 Dec 2014 16:46:09 +0100 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/SHpeiwvgfM7OEPDu8e7L9sk34UA Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 15:46:40 -0000 Hi, after having some discussion with Stan, I have a compromise that might replace the Vendor-TLV thing with a simpler concept. I suggest we replace the complicated "vendor-extension" TLV with a single "vendor-id" TLV. The vendor-ID TLV can be (optional) put into the Session negotiation and gives you the "context" of the experimental range for both messages and TLVs in all later messages. This means whenever you plan to use a TLV or message with an ID from the "experimental range", you put in an ID into the Session negotiation to tell the other side who you are, so it can check if it can understand you experimental IDs. This makes vendor extensions possible, but it is still limited (you cannot mix the extensions of two vendors in the same session) and will hopefully push vendors to the IETF to get IDs from the standard range. What do you think? Henning Rogge On Tue, Dec 16, 2014 at 4:42 PM, Rick Taylor wrote: > All, > > In response to the silence concerning Vendor Extensions in DLEP, and > after much deliberation amongst the authors, we have decided to drop the > concept from the protocol. > > Regards, > > Rick Taylor > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Dec 18 08:03:40 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CCB1A8A7B for ; Thu, 18 Dec 2014 08:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 AoKjD4XAkrf6 for ; Thu, 18 Dec 2014 08:03:33 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5CE1A8AA8 for ; Thu, 18 Dec 2014 08:03:32 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id hv19so1268183lab.0 for ; Thu, 18 Dec 2014 08:03:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1jvKCK4syBFSl7eolYdXguHQGsVSB3trnIJC3AGNRro=; b=wP3QAcz1YxJJVzs+beZyz7yOAPBW4oN5WVyaYaDpwzEgoZ3eQPYQmQPPtymbpyHLfU 1oyQhq3H8mwrz0aiUL8ub4VRY3IINjAXzSW+NwH1E9Hz5OGFgUh0XbywMeLQ7SbY6fTh UXPDSJ/9sTik5XMVih/kyHDZccWU0FMHxeHPc88dRpOeXe26I9Dj3BjCS4hq6Ze4d1al uQHYBK2tCG06qbR19P2YsJ2M+8vODGSQ91RTyVlD64KJtTsB8C4eFDZZiX4kZrffsACr ybZAy9GZxKOdSoXQlp16lyfN04e32yEP1jiB9KTan0nYrmVjPCQ7PKuAGcq++r5yCtsT P9zw== MIME-Version: 1.0 X-Received: by 10.152.22.67 with SMTP id b3mr3097278laf.82.1418918611104; Thu, 18 Dec 2014 08:03:31 -0800 (PST) Received: by 10.25.85.201 with HTTP; Thu, 18 Dec 2014 08:03:30 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> Date: Thu, 18 Dec 2014 11:03:30 -0500 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=089e0158b86ec7baa4050a7fbb01 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2Bf6NAiPZ31EjOgr5CV1SpskktI Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 16:03:37 -0000 --089e0158b86ec7baa4050a7fbb01 Content-Type: text/plain; charset=UTF-8 I think this is a good compromise - it even closes off the concern I had about allowing Vendor Extensions at the Peer level. +1 from me. ;-) Regards, Stan On Thu, Dec 18, 2014 at 10:46 AM, Henning Rogge wrote: > > Hi, > > after having some discussion with Stan, I have a compromise that might > replace the Vendor-TLV thing with a simpler concept. > > I suggest we replace the complicated "vendor-extension" TLV with a > single "vendor-id" TLV. > > The vendor-ID TLV can be (optional) put into the Session negotiation > and gives you the "context" of the experimental range for both > messages and TLVs in all later messages. > > This means whenever you plan to use a TLV or message with an ID from > the "experimental range", you put in an ID into the Session > negotiation to tell the other side who you are, so it can check if it > can understand you experimental IDs. > > This makes vendor extensions possible, but it is still limited (you > cannot mix the extensions of two vendors in the same session) and will > hopefully push vendors to the IETF to get IDs from the standard range. > > What do you think? > > Henning Rogge > > > On Tue, Dec 16, 2014 at 4:42 PM, Rick Taylor > wrote: > > All, > > > > In response to the silence concerning Vendor Extensions in DLEP, and > > after much deliberation amongst the authors, we have decided to drop the > > concept from the protocol. > > > > Regards, > > > > Rick Taylor > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e0158b86ec7baa4050a7fbb01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this is a good compromise - it even closes of= f the concern I had about allowing Vendor Extensions at the Peer level.
=C2=A0
+1 from me. ;-)
=C2=A0
Regards= ,
Stan
=C2=A0
On Thu, Dec 18, 2014 at 10:46 AM, Henning Rogge= <hrogge@gmail.com> wrote:
Hi,<= br>
after having some discussion with Stan, I have a compromise that might
replace the Vendor-TLV thing with a simpler concept.

I suggest we replace the complicated "vendor-extension" TLV with = a
single "vendor-id" TLV.

The vendor-ID TLV can be (optional) put into the Session negotiation
and gives you the "context" of the experimental range for both messages and TLVs in all later messages.

This means whenever you plan to use a TLV or message with an ID from
the "experimental range", you put in an ID into the Session
negotiation to tell the other side who you are, so it can check if it
can understand you experimental IDs.

This makes vendor extensions possible, but it is still limited (you
cannot mix the extensions of two vendors in the same session) and will
hopefully push vendors to the IETF to get IDs from the standard range.

What do you think?

Henning Rogge


On Tue, Dec 16, 2014 at 4:42 PM, Rick Taylor
<rick@tropicalstormsof= tware.com> wrote:
> All,
>
> In response to the silence concerning Vendor Extensions in DLEP, and > after much deliberation amongst the authors, we have decided to drop t= he
> concept from the protocol.
>
> Regards,
>
> Rick Taylor
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--089e0158b86ec7baa4050a7fbb01-- From nobody Thu Dec 18 08:28:14 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B501A9167 for ; Thu, 18 Dec 2014 08:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, 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 9bFMJzgP4q83 for ; Thu, 18 Dec 2014 08:27:57 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C421A911E for ; Thu, 18 Dec 2014 08:26:08 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so2096560wgg.28 for ; Thu, 18 Dec 2014 08:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=PpUse8iCbKDJJCHZcNu0HtgKl3TWAevdC5pyBth4AOw=; b=Ej+cgFEFO4CO+E6gFuTMIXv3EtZdOBNwmRBkxks6Lf3TDeOKPtJO7SBY4frwDFqAmc c2B/Q0wdE1pg6CIFHyAZ2frbX9s+nVYMlT8ygkQlYGiBvFSMd2ZgiuwfxH2GyKXTjU85 d586igQ9eRaMo1djbnhZJ9hnjDy48NO9MH3dpX1rYrc4XDZS6viw01rcV2mZ3ODgvxeV UDzaEJwQlaA7txcC/enSvD2KEeDqxFeH60Kb85Jrv1DYqJhtI+lW6szYdG7on+D17fPO S0sg40lSvaUGy3rRfcRCYStGjWxZ1qUpbPjKklevjFKuk6opa84vdwp9AT7Gd21h4Kn+ dzqw== X-Received: by 10.180.109.45 with SMTP id hp13mr6689424wib.4.1418919966816; Thu, 18 Dec 2014 08:26:06 -0800 (PST) Received: from [10.0.4.178] ([217.158.48.187]) by mx.google.com with ESMTPSA id h8sm10519594wiy.17.2014.12.18.08.26.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Dec 2014 08:26:06 -0800 (PST) Message-ID: <5493001D.5050604@gmail.com> Date: Thu, 18 Dec 2014 16:26:05 +0000 From: John Dowdell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: manet@ietf.org References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090307080500010705070102" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/SSJgLhyfZLod9C1yiNE5_p7tk8Q Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 16:27:58 -0000 This is a multi-part message in MIME format. --------------090307080500010705070102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Very interesting compromise. Hopefully we will see vendors taking advantage of the experimental messages in this context. Any modem vendors care to comment? John On 18/12/14 16:03, Stan Ratliff wrote: > I think this is a good compromise - it even closes off the concern I > had about allowing Vendor Extensions at the Peer level. > +1 from me. ;-) > Regards, > Stan > > On Thu, Dec 18, 2014 at 10:46 AM, Henning Rogge > wrote: > > Hi, > > after having some discussion with Stan, I have a compromise that might > replace the Vendor-TLV thing with a simpler concept. > > I suggest we replace the complicated "vendor-extension" TLV with a > single "vendor-id" TLV. > > The vendor-ID TLV can be (optional) put into the Session negotiation > and gives you the "context" of the experimental range for both > messages and TLVs in all later messages. > > This means whenever you plan to use a TLV or message with an ID from > the "experimental range", you put in an ID into the Session > negotiation to tell the other side who you are, so it can check if it > can understand you experimental IDs. > > This makes vendor extensions possible, but it is still limited (you > cannot mix the extensions of two vendors in the same session) and will > hopefully push vendors to the IETF to get IDs from the standard range. > > What do you think? > > Henning Rogge > > > On Tue, Dec 16, 2014 at 4:42 PM, Rick Taylor > > wrote: > > All, > > > > In response to the silence concerning Vendor Extensions in DLEP, and > > after much deliberation amongst the authors, we have decided to > drop the > > concept from the protocol. > > > > Regards, > > > > Rick Taylor > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --------------090307080500010705070102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Very interesting compromise. Hopefully we will see vendors taking advantage of the experimental messages in this context.

Any modem vendors care to comment?

John

On 18/12/14 16:03, Stan Ratliff wrote:
I think this is a good compromise - it even closes off the concern I had about allowing Vendor Extensions at the Peer level.
 
+1 from me. ;-)
 
Regards,
Stan
 

On Thu, Dec 18, 2014 at 10:46 AM, Henning Rogge <hrogge@gmail.com> wrote:
Hi,

after having some discussion with Stan, I have a compromise that might
replace the Vendor-TLV thing with a simpler concept.

I suggest we replace the complicated "vendor-extension" TLV with a
single "vendor-id" TLV.

The vendor-ID TLV can be (optional) put into the Session negotiation
and gives you the "context" of the experimental range for both
messages and TLVs in all later messages.

This means whenever you plan to use a TLV or message with an ID from
the "experimental range", you put in an ID into the Session
negotiation to tell the other side who you are, so it can check if it
can understand you experimental IDs.

This makes vendor extensions possible, but it is still limited (you
cannot mix the extensions of two vendors in the same session) and will
hopefully push vendors to the IETF to get IDs from the standard range.

What do you think?

Henning Rogge


On Tue, Dec 16, 2014 at 4:42 PM, Rick Taylor
<rick@tropicalstormsoftware.com> wrote:
> All,
>
> In response to the silence concerning Vendor Extensions in DLEP, and
> after much deliberation amongst the authors, we have decided to drop the
> concept from the protocol.
>
> Regards,
>
> Rick Taylor
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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


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

--------------090307080500010705070102-- From nobody Thu Dec 18 08:47:11 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4FF1A8AAA for ; Thu, 18 Dec 2014 08:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 do8fsNvTwg0O for ; Thu, 18 Dec 2014 08:47:00 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34131A8AA6 for ; Thu, 18 Dec 2014 08:46:59 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Thu, 18 Dec 2014 16:46:35 +0000 From: Rick Taylor To: John Dowdell , "manet@ietf.org" Thread-Topic: [manet] DLEP Vendor Extensions Thread-Index: AQHQGtnGwY4jW6qu0EGIBS0KwM5cT5yVgqEAgAAGT4CAAAW62A== Date: Thu, 18 Dec 2014 16:46:34 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F980142AC2D41@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F980142AC2D41tssserver1hom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/aaKVb4SK5olkUjGC8oNSbNUM0p4 Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 16:47:03 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F980142AC2D41tssserver1hom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a tentative +1 from me. I need to think it through clearly but it s= eems like a nice solution. Rick Sent from my HTC ----- Reply message ----- From: "John Dowdell" To: "manet@ietf.org" Subject: [manet] DLEP Vendor Extensions Date: Thu, Dec 18, 2014 16:32 Very interesting compromise. Hopefully we will see vendors taking advantage= of the experimental messages in this context. Any modem vendors care to comment? John On 18/12/14 16:03, Stan Ratliff wrote: I think this is a good compromise - it even closes off the concern I had ab= out allowing Vendor Extensions at the Peer level. +1 from me. ;-) Regards, Stan On Thu, Dec 18, 2014 at 10:46 AM, Henning Rogge > wrote: Hi, after having some discussion with Stan, I have a compromise that might replace the Vendor-TLV thing with a simpler concept. I suggest we replace the complicated "vendor-extension" TLV with a single "vendor-id" TLV. The vendor-ID TLV can be (optional) put into the Session negotiation and gives you the "context" of the experimental range for both messages and TLVs in all later messages. This means whenever you plan to use a TLV or message with an ID from the "experimental range", you put in an ID into the Session negotiation to tell the other side who you are, so it can check if it can understand you experimental IDs. This makes vendor extensions possible, but it is still limited (you cannot mix the extensions of two vendors in the same session) and will hopefully push vendors to the IETF to get IDs from the standard range. What do you think? Henning Rogge On Tue, Dec 16, 2014 at 4:42 PM, Rick Taylor > wro= te: > All, > > In response to the silence concerning Vendor Extensions in DLEP, and > after much deliberation amongst the authors, we have decided to drop the > concept from the protocol. > > Regards, > > Rick Taylor > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_38A5475DE83986499AEACD2CFAFC3F980142AC2D41tssserver1hom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
This is a tentative +1 from me. I need to think it through clearly= but it seems like a nice solution. 

Rick

Sent from my HTC

----- Reply message -----
From: "John Dowdell" <john.dowdell.ietf@gmail.com>
To: "manet@ietf.org" <manet@ietf.org>
Subject: [manet] DLEP Vendor Extensions
Date: Thu, Dec 18, 2014 16:32

Very interesting compromise. Hopefully we will see vendors taking adva= ntage of the experimental messages in this context.

Any modem vendors care to comment?

John

On 18/12/14 16:03, Stan Ratliff wrote:
I think this is a good compromise - it even closes off the concern I h= ad about allowing Vendor Extensions at the Peer level.
 
+1 from me. ;-)
 
Regards,
Stan
 

On Thu, Dec 18, 2014 at 10:46 AM, Henning Rogge = <hrogge@gmail.com<= /a>> wrote:
Hi,

after having some discussion with Stan, I have a compromise that might
replace the Vendor-TLV thing with a simpler concept.

I suggest we replace the complicated "vendor-extension" TLV with = a
single "vendor-id" TLV.

The vendor-ID TLV can be (optional) put into the Session negotiation
and gives you the "context" of the experimental range for both messages and TLVs in all later messages.

This means whenever you plan to use a TLV or message with an ID from
the "experimental range", you put in an ID into the Session
negotiation to tell the other side who you are, so it can check if it
can understand you experimental IDs.

This makes vendor extensions possible, but it is still limited (you
cannot mix the extensions of two vendors in the same session) and will
hopefully push vendors to the IETF to get IDs from the standard range.

What do you think?

Henning Rogge


On Tue, Dec 16, 2014 at 4:42 PM, Rick Taylor
<rick@tropicalstormsof= tware.com> wrote:
> All,
>
> In response to the silence concerning Vendor Extensions in DLEP, and > after much deliberation amongst the authors, we have decided to drop t= he
> concept from the protocol.
>
> Regards,
>
> Rick Taylor
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


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

--_000_38A5475DE83986499AEACD2CFAFC3F980142AC2D41tssserver1hom_-- From nobody Thu Dec 18 09:12:59 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED73E1A9077 for ; Thu, 18 Dec 2014 09:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 B1BdWvgL4V_6 for ; Thu, 18 Dec 2014 09:12:46 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7181A8AE0 for ; Thu, 18 Dec 2014 09:12:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,601,1413241200"; d="scan'208";a="429147061" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 18 Dec 2014 17:12:33 +0000 X-IronPort-AV: E=Sophos;i="5.07,601,1413241200"; d="scan'208";a="84844394" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 18 Dec 2014 17:12:32 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.118]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Thu, 18 Dec 2014 17:12:32 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Rick Taylor Thread-Topic: [manet] DLEP Vendor Extensions Thread-Index: AdAZRvZGMxZmPNThQGCgATXqm4sJsABkseiAAALVXGA= Date: Thu, 18 Dec 2014 17:12:31 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tca1PVBfzRAPLMGigbdmBKMhSEA Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 17:12:50 -0000 Henning > I suggest we replace the complicated "vendor-extension" TLV with a single= "vendor-id" TLV. Format (of the value)? I see two (and a half) possibilities: - Free text, which makes it unlikely that there will be a clash, but is ine= fficient if you are counting bytes. (I'm not suggesting you are or aren't, = just pointing out the interaction.) - Setting up an IANA-managed registry for vendors. How many bytes to alloca= te? If a fixed number then at least two. - (Option 2b) Alternatively a variable length integer (as in RFC something = or other) that can be one while still less than 128 vendors. But I'm not su= re how that manages an experimental range. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From nobody Thu Dec 18 09:18:40 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147031A1B8C for ; Thu, 18 Dec 2014 09:18:37 -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 p8NIUQ7SpDEH for ; Thu, 18 Dec 2014 09:18:35 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C981A1B7A for ; Thu, 18 Dec 2014 09:18:35 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so2506948wib.10 for ; Thu, 18 Dec 2014 09:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AaNg4eEB8SknG6cs3/8LlUxzRxU8VV2rS/X2YypG8LI=; b=qxlsOVQ2tz1QM9tWSnMXbT/IZg77lubJHsf3PPhq9VBK7N3d9WPVIkglhQ9jWEkaSj Gn/C7PfJMDifBlwcgPv8T6CoFMLnJUQo+gEYABRg3h+cAShs65FWLvchHw3SSHdUitOf HSERVpfF12ACrlR5KupTp25OAzCoaQKLyfHLVnkiTybFtozs0WPvFm0LFvbEkZJXHrqk zpexAT86n4SCfWRVp/OTsmw2msd7EvZF4naP+4lNxpdkt/d+7Rv/ZFdwBbYWTBugKiHn tkacA65cHVyLiXLblLmjeVBRnKsajaQIrp1DiSLPptYIFD7OYCW/q7NOjY3m0HcSuy9G FOtg== X-Received: by 10.194.157.4 with SMTP id wi4mr6486999wjb.54.1418923113953; Thu, 18 Dec 2014 09:18:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Thu, 18 Dec 2014 09:18:13 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Thu, 18 Dec 2014 18:18:13 +0100 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/stKqLi6YnoTCwP375kSsgT98WA8 Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 17:18:37 -0000 On Thu, Dec 18, 2014 at 6:12 PM, Dearlove, Christopher (UK) wrote: > Henning >> I suggest we replace the complicated "vendor-extension" TLV with a single "vendor-id" TLV. > > Format (of the value)? I would suggest 8 bytes (octets). the first six bytes can be a MAC address (or the beginning of a MAC block owned by the company followed by 000000) to give you an unique worldwide ID, the last two bytes can be used without the same organization to signal different experiments. If you write an implementation that understands a certain Vendors experimental extension, you should check the full content of the "vendor-id" TLV before activating the extension. Each extension can use all TLV (or message) IDs that have been assigned as experimental by IANA. Henning Rogge From nobody Thu Dec 18 09:46:25 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00FD1A9109 for ; Thu, 18 Dec 2014 09:46:10 -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 rF9GT7g8qXXL for ; Thu, 18 Dec 2014 09:46:06 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548211A9076 for ; Thu, 18 Dec 2014 09:46:05 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so2675143wiv.1 for ; Thu, 18 Dec 2014 09:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=uBK/UPxOeQzxV7ZclxRGXAieJ+Ypr24hkHm0M6f8Ka0=; b=NT6CXezfz825njsPSLhJwcGbdM+B1mxBM3HJNd77+C1G0NBjJXOJfsfObYFowRzExO QklTr4UB0vds/PxLcGrfWC5Q2wQnWOWXs9J/cH2KkADwg+i6di26ZrVgF5TDketHXTV9 7cFU+HzVlFy76BqjI3wpE34R6ihqzjdAWw1fFuY8on5tLq9ns5AzyLu5JYLS17k08BBA LI5VQ4c6gXchJaD0QghMOpMCgQzXk0kMzxrvifMLG7109wQ+POLxgHndYR+WS1Be+xVY z7abEuDrI+CUqs61GbZPcqu9C2oRszv4xlsw5HZ/jLCpMmoG/tYuM938FSPSxpEdRFTm iwnA== X-Received: by 10.180.218.133 with SMTP id pg5mr26563200wic.70.1418924764119; Thu, 18 Dec 2014 09:46:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Thu, 18 Dec 2014 09:45:42 -0800 (PST) From: Henning Rogge Date: Thu, 18 Dec 2014 18:45:42 +0100 Message-ID: To: MANET IETF Content-Type: multipart/mixed; boundary=001a1135eac287755d050a812a58 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ToyiaeUKz_QZSERBx2Yh6pFw2X8 Subject: [manet] GPG key transition X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 17:46:11 -0000 --001a1135eac287755d050a812a58 Content-Type: text/plain; charset=UTF-8 Hi, I have moved to a new GPG key over the last weeks because the old one was not supported by my new smartcard. The two keys are crosssigned and uploaded onto the sks-keyservers system. I will only use the new key in the future to sign olsr releases. I have attached the new public key to this message. Both keys, a key transition statement and the revocation certificate are also available at http://www.hrogge.de/gpg Henning Rogge --001a1135eac287755d050a812a58 Content-Type: text/plain; charset=US-ASCII; name="86875CD9.asc" Content-Disposition: attachment; filename="86875CD9.asc" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i3uf51q50 LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tClZlcnNpb246IEdudVBHIHYxCgpt UUlOQkZSNXNxTUJFQURNZVhHUXYySUlvMDZzYW9XdjdvUVM1N0lVNHBMbEpQK0xNN1N2VTMyRmQ5 WW5Zeno4CmJ6dE05VSsrdFZNRkVqWjZGZjRkQnN1SUIrdFQ1UTc1ZFFqVmVFOFQxVjNTZlhoc0xw UVBhMDdCRWlhdGhqeUoKc0ZEeE90N29LNGtka3dYbVFKRVhNSzVHYkQwa2FHYjViZFp3OGF0R2tI cEVKOUwwUXAvSExOeUNvR1JZZjJtUApGZEZjYXorNUE5eDNTYjZVeUdzU0FBWE9ZTzdyVjgyY2gz b1Y2S3BzenFZNEMrNHhvNkp0QkM2OGl6Ynd1MFU5CklTM2ljcE5IL1BNYjJDaWRsNk5rdXNDdzJs TFFmQjR6cHdOVWcrcmQ5dDNibnI1alA2dHNvL2lqREs4K1R6ZW0KUGtXM00xa1RiQ1lQTE40a2Yy TGJTTDAxYVE5K2FkdkRPTFBjUkxMQk96VkdteTQycGI3d2dsWVM1WVNnUjQvcwpkeEYyK25tVmIr T0hJNTJqOURkd2lvNjhOWGlXUWROTFN2cmpFNnRjMHVzVDR1bGkrSXNwS2xBd01LT2taRlh3Ck9Y emNYYlUzbjNIYjBCQVZnaGpqNmUxbDc0TUVMZUZjbTc4OW1EclZMbW9uZTR4cy8ydTNMZk5hSlhj b2xGTHUKSEhiejBId1R0UkhGZDNhL3hyTjg2Q2lLWXEwckU1bDRXVWF6SjRzT3h5VDdWN1hrdDRR cHF3WTA2ZC9nY3BEUApnM0h4ZU1INXJlY3pGWHMrUWVlTnpzcWhFK2VUQzVzWjl5YW1CSVdETnJ4 T2dIb01HbWxkT3ZOZUdaSlcwZVI0CkM1RHNESFhDTXhuemJxeVJpRUw1TVM2Yk1QaEQrSk9MemFp NGdodFUweDUyaUVSY1BLZkxwMWxtRXdBUkFRQUIKdENCSVpXNXVhVzVuSUZKdloyZGxJRHhvY205 bloyVkFaMjFoYVd3dVkyOXRQb2tDUFFRVEFRb0FKd0liQXdVSgpBOEpuQUFnTENRZ0hEUXdMQ2dV VkNna0lDd0llQVFJWGdBVUNWSG0wMUFJWkFRQUtDUkNsclhmbWhvZGMyZnVpCkQvOXlJNklZdFlG Vk9NbGwxR1FxMXlLMzVlRGUwNWdLWHlaRUE3UzZQRHVhZXVibzlzaTMrT0plZ1RpZGlCWTgKNG1K OHFHMlJ0T05zdHExTWtSTHdWclBPT3lPUGY5SWxvL24xK0pMNnlFSHN3NHFWSUZVcnRoNmxzN2hO bTEzLwowSVFBeXJtMVRXZk5Ga0Jla1J4L08wZ0lYMEhZQTBxajA1R1RVbmo3OTRGZU9CT1hNUThn RGxoVXQrQ3BWQ0JnCk16RkpFTUNmajRIYmdwZGczU2R4SWYyT00zcW9udjhKY2R2cXVadVZ0N0Vr NWV0MlVpeVdwR014SEduTFdUUFoKak9XaGM3VDNZbjBlM1MxWmZnRnFqMUYyWUlyek5Ia0Q2NVNC azJHNlQxR3g0VVM2a2gxKzhOeVh2M3N3MndkdQpIVXJsQUVaSGdVSTlHRm44RFFyNmlvOXk3dVp4 d001RFJ2d1JOclB1ZXJ3UWkrSmRtQjV0NFE3a2hTQ3MvdStyCnVONUt2ejR0Vm1wVm5vK1hycFJK R3poaUMyZ2Y5RlBRYldDVlJuV0VLWU15bE9pTXdNR25ZT3Jwc1BPSXI5T2UKSjVHRDZORC9rNGgy RWFDcHVWSXFXQlAzektkMStTUHA5enNHMGRoaUZ1eE9hL3AraXk0eGxwd3pieWUvK0NZUAovRzhP L203dGQrVFJudXJvUmhyMDhQajlmTDJnVDVrU2w1eU5NSjVLNU5La29lWEtocTBrZXlvc2ZJdEFn VU8yCklGTklKNlZRWko0T2VoSmJzb2N2eDB4MEp2UndhWm5aeHJBQVJvL1dMTlJWSi8yTVljY0c3 UU1lTFhCcThTdlkKSHdRRmRSS0hJRVphTnNBeUdSM3J3dXV1QjJmTk1IdVhsbmRrekdSeE9UUnhk WWhHQkJBUkNnQUdCUUpVZWpNbwpBQW9KRUhIcDczTUFIQjFuNU44QW4wMnozOE54Q1FESHVOcE9J NFlIczc4eGZVVnVBSjlRYU1XbVlISE5DYUhRCjdDVWxYVG9tREJnV3c0aEdCQkFSQWdBR0JRSlVm S1FnQUFvSkVNajlVbWhVaFhqUGhjd0FualNEd3d1ZTQ1VWgKc0sveDhJNE4rQk1iM3B0WkFKOXRz bVo5eVdkOUJ2RWVTL2QwbzBWdGk2NFhpSWhHQkJNUkFnQUdCUUpVZktWRQpBQW9KRUJRQitvNW9j cCt2ckhVQW9LWHVickFoUlFvRFVVWWl1QXlXMlU2VTc5RExBS0NRSHRxc0RzNnpCYncvClE0Y1ox UWYrYXF1bWZZa0JIQVFUQVFJQUJnVUNWSDg4eEFBS0NSQi9rMjZSWmxSbkx6ZjBDQURGejVlZUwx U3gKVGp3clZwd1pZV0ovbUZXL1VNNDNQRzYrc0ZDODN2L0pHSW42VTNHTno1KzFzNGdva011bm81 Zkp2aUY5NzhWWgorWXNuaTI4MzhhVWlNVHJqSnFjRTZDUEViQ1hmSEw3V0JFR2NNbzBreXhNS0tD MDkrdmlPdVV5NWhyV2J3ak1KCkw3QjZnWFV1cmhMN0VSNFBvNHF4ZkdFdSt6ZS81MFdjWHgxaWth QnMwRjBuZEQ3a3JPd1VRMC9GZEl4YUtyZkQKNjRIRTg3cnlUQ0lEMXlxSURTRVlKNlJpUUpaU3ln clNHSU1FRVZrbmpoU2VXTWxVd3Z2bXZNcHl5enJZUy96RwpjZUtveTVRL0g5NnhES3MwbkNVVHJR K3JpTi9NNzZtRlNHak0xVWZQc0JDR05uR25aZHh2ajNPT28wN3JSNVByClR0ZjlTRWdrY3c5ZmlF WUVFQkVDQUFZRkFsU0sxZk1BQ2drUXhQNnR6ZUhRU1AzWit3Q2ZVd3VlMGN1YlNqR2sKNmg3QlNv RnV0emJFNEE4QW13ZHhMMHp3OHBYRlBiS1dTTVJZMDRrRUZXUnVpUUVjQkJBQkFnQUdCUUpVanRC OApBQW9KRUFtdGxkWmtoWnh6bUxjSC9SZ05LT0REOEJmSFVIa1dVSndMcm9BOGpnN0phQUROejlH M2JqWSt4emdGClQ2QnpBbjR1MSt4NHZSN2VhamJrUDZjaDc4NFM1dlBzTU9aclVlK216VUlkZjVl bGFOMzk2Y0sxREtSQmNHNjcKblBBelVzY3JhS1FzdTU5aWE1QXAyMld6WjhKN3ByMWpSd0RsNDdr TWdHU1pjMHpYbzcySWFid2d3alFMYU1sMQprSkRueVZMdHlVOU0vRzh6Yk12QzBZR1Y0Z3o5dFRN WW9SSmljUHpyZkMvNDlyK2tKMHpFUkZGK2kvMndiTTI2CnZ6QUM3b3djb1E0OXBtaUFLRm43VVlv d05aVndkRTdMTzJyNStGeEdIK21oMmZ3b3V6MHovNHBxOTlLeUxhV2IKdEVuZ0tkYXdVSmIwZXdx dENrQlA3V3BhMlBSL050elF1ZlF6RG5DMDc3Q0pBaHdFRUFFQ0FBWUZBbFNPMFJjQQpDZ2tRSHdE VzlWK2VONU5lQncvK0xrVnpoS3BWb2FXcVRwWERmMjUwV3owMVVsdjBjRGd3VXJkYmdWbm9yVUQz CkkxUG5JRDRhdU9FL0ZmWUJWVzZoSUF6UWN2ZWc2TW11MVlGYmc3NG5sQ0RHQWZxcEprUnROWmFY VHhvazJ6TnIKTEM5VG1NeS9VQi82QkJqQXlUSmJwSStFRGVzNEVwMnUxdkZSU1FmQlZJdVFpZDcy T2NMdUh0YlB5VUszRnNXNwp5ekticnRvZGpHa20zNmhKbUhMOFBhRWhleTdVdUZoK0NBM2hqd2tv eEs3N0h5SThMYUNOblMrcmZBUlpJOGFpCjRVZnJ4S3Blc2FDYTB3Y2k4K25jVEJNWENYc1owRXRU ZnY1ZGZKK0NISlJkMkVtcVU2R2FHTy9DT1A4NnFuancKb2JNZXBYL2h4OVAxbUViS0hoMGVQRkt2 VTRrem94d28zUW9aeWszRjQ3OUdpMWNXbUFOT2lWYVVnRzBrQk1uSgppUFJ0QmNuT2Z3eTVZZ29z MjNPbEdxQWwrSkw5ZmNldzdFK3Rac1k0V1dqTEZBeVFyV3ZBemQyOGJxTk9reEg0Ck8rYjhEYjBS aDlWWVc1SWZILzg5cjFKaHhwT1B6SU5ndXZzNXNQenVrS3ZpTFQ2TmxqSlFmZXFPMm9ndnRnVGUK UDBWekR6a2E2UXBtR2NTdmo1ak1PMGJYdnVLeHFGcEx4WTNTWjZZSWJhTktqZGk5cEd5bVlualNP Q05FTzFWSQptRllqZFRtQjFTUjhFWlppQUZaajZHaXBrZHAzTXdZY2NtbktiRER3TU5UYTFINXVt aExRU3hSVXZ6VlJZN0dzCnQ0V2QzbmJ4L3RpVnlYRnZOTmFSV0tLenNoTitTeG40WFROOENxY3lo OHpHVUpZL3FDTzM2cDYzeG85MFVUR0kKUmdRUUVRZ0FCZ1VDVkpMQjhRQUtDUkF0ZXBsNnphNU50 dmw5QUo5Y2RWTFhSVnRyci9LVXBwbWs3ejVReW9DdApDZ0NnaGRwbU04MFBmZWNJMDhNMzNreHhW anA2dmdpSkFod0VFQUVJQUFZRkFsU1N3aVVBQ2drUUd1MkxaeTNVCnliSGh1QS8rTnJsZHFXeHlq UkNmZS90NUhtQW5iczJyYm1lWW9COFJXSU9YQXhQOVNncmtjQ0l2YTdNUlQyUmMKTDk3WlJ4QVBV djBvSTY5OTZmYVExWFRRcXgxUjJoakgzTDJVZWgwVGFYZWxCajRZd2gxcWFDenQ1b0JnMUVqaAo5 c0xjOW44RVFoRDRUbDdTc2pkWnFXUldIZE5IcDVmeC9VWnFoTnZ2a1pGRGYxNzNwUzZxenNlMmZo TnV5c2N4Ckw5SDFnYW5DcXptMUxzeUYwS05LdGk2T0RyRFBzRkpCL2ZPNEUvNGdiS0RXZ2k1SWgx TFRJTW9xME5ERmVOMHUKLzJFcmlRNkI0cjFXZ1RPQ044R1U3c2EwTjZLNTlldFllblhUQ1lzL084 R1djcmovcW5BaHJjbGYxTjRZWWZOQgpYVXdTYzJ4ZWt3Y29meW1XeGNNRVpja3BpUHZKbDhMRUhy R3owRTJTK0tJWEd0VWFGM0ZKR3JWOEdlYWRlelVDCnFZZmpJRDFLU3lIcGNNTXlHTE9Qa3V5QWs1 cGE2QnpiazNDVW40ZitYRkU3dWhCZjlpcENtMFRQSnZQTC8waUkKeUFmN3FtVlVYbEVqaUhhVFg1 WHNzVTJYNE9iR2dsYUM3ZXN4V2lDTGNmQmZpL0VsMERTNWlqeS9Sbm9pSW1rWQpvelBvSDkrWG84 L29TOTFlZlBiaUg0d3B5ODZkMi9iREgzcTJVSC8zd0RJU09TdytvZno3UHdDeEVhTzdwdnpDCm80 dmx0TCtHbm9OR1FvakczQWI4QzJQczRobmJuajlpK1loNCthRzRQLzFWTDVuUUNXVXl6aGJZVys0 T0IydmgKcTNiYys0aGJ2SkhPTDNLU29FY3VBT0Yxb1FNNlZ0aDNZZXhtdVhoYzM1K0E1aXRpei9q UnpFWE1Rd0VRQUFFQgpBQUFBQUFBQUFBQUFBQUFBLzlqLzRBQVFTa1pKUmdBQkFRRUFTQUJJQUFE LzJ3QkRBQWdHQmdjR0JRZ0hCd2NKCkNRZ0tEQlFOREFzTERCa1NFdzhVSFJvZkhoMGFIQndnSkM0 bklDSXNJeHdjS0RjcExEQXhORFEwSHljNVBUZ3kKUEM0ek5ETC8yd0JEQVFrSkNRd0xEQmdORFJn eUlSd2hNakl5TWpJeU1qSXlNakl5TWpJeU1qSXlNakl5TWpJeQpNakl5TWpJeU1qSXlNakl5TWpJ eU1qSXlNakl5TWpJeU1qTC93Z0FSQ0FCNEFIZ0RBU0lBQWhFQkF4RUIvOFFBCkd3QUFBUVVCQVFB QUFBQUFBQUFBQUFBQUFBRURCQVVHQWdmL3hBQVlBUUFEQVFFQUFBQUFBQUFBQUFBQUFBQUEKQWdN QkJQL2FBQXdEQVFBQ0VBTVFBQUFCMUNnb0JGTmsxbVRpSzJta1pwY2JjdllpM1pOQWlMdUp6M3lI QW9ZKwpvRzg0VFU0RE5XeU5jdElyV2k3VjZEUDdtQm0wbXA4OTI5SVN1ZXVXVkFBa25RR1lwZEht MWJiVHErZE96eWNEClkxWHphcFh5K214dTZwenplZWtaZVJRSm84QkU4NzlPd0N0S2NjbHBhUTFL NnhzakkxTWZWeFd6cDd4bGVSZVgKaWdBWFIwYm5PVTF0WGpRNWxiTmoweDBxMnROTEdSckN0dllG aFNDSUl5QWdGNkEyQUlHZVo1U1Z1SGVsV2pQTQpqUGFqT3RxWHVubnRVNFdUQWhoZmtlbG90bm5l V0tybnJHS3hLbWxHZVkxclp6TnIwUjZWM2k4WEpEVVpHbmtVCmc2TkIwejZZQUsraUJHdTN3NTZ5 M2c2NFBnQTEwRzRvQ3QvL3hBQW5FQUFDQWdJQkF3TUVBd0FBQUFBQUFBQUMKQXdFRUFCRVNFeUFo QlJBaUZDTXdNVEl6US8vYUFBZ0JBUUFCQlFMc21kWXk4b01uMVRBdndXQXlEL0U5d29XNgo0MTVS NXdWYnlRaU1YWmFuRTM0TElubEhkTTZpN1o2cm9uRWh5SVZSTWZTeEpUVkhWaXRLc28yOUYzWDI5 S3JyCnpXcUUrVVV1R1FxSXpoR0ZHTUhZc0hwTXJNNnRmdDlaMzBhcUFaaW9nUmozTEhUcUxzL1Aw MmQwZTMxWU9WV2kKZUpuWXhtODNoSEVZOHhuTGs2ZFREaFQ3V0xoaTZZeU5oYjNsbjFUaE5McE9i TERIQzFFeUtXRGFEbFpybjFFKworczFtc0ZjcXZGV21TVFNXR2FFVG4rZlRpWTZJZ1JoenRxalMv ZldheldYVjhiYTU4WiszTThFTStHejQvd0JZCmpROTFxdVRwVjR6bGpGbEx1bExTV1doWitxeGhQ NFdqMDdCd1VpSFV3eFppbHpHUFBpS2xFVmhaYzE5L3FOeFUKU0I4aGlJeVlqT1hHSE42amdEZUtL RmpCUVhheTBzQ2M5cjh0YUVVTm5YV3pyWlpzbVdWSzBDdmZNQUl1UW5FUgp5ajJZMFZ3NTdXREJh TlpmRzhtWVhUTGNSclVqdkJUeExpRHAzem1mMUo2WVgyaStZeVp5d2pDUkU0TFUvd0JaCmdUQ2JN SXNwdHBLRHVJSFBKWUFocEpzYTNmSnd4cG9NK014eGovL0VBQjBSQUFFRkFRRUJBUUFBQUFBQUFB QUEKQUFFQUFoQVJJQkl4SVVILzJnQUlBUU1CQVQ4QmdCY29qSVFFRUlqRGZZcUhlNGJod29YaGhv eDByVDNmbVdPdApXaVYxOW0xYVlZZVlCWFVoZEZlNC84UUFJQkVBQVFRQ0FRVUFBQUFBQUFBQUFB QUFBUUFRRVNBQ0F4SVRJU0l4ClFmL2FBQWdCQWdFQlB3RnBVcWJFdEtGRFFVTkFhRU5EQVZ5RU1B dW40dU1TVU1JV3dOcngrc2NPU09zdm1PeTQKaGo3YVYvL0VBQ3dRQUFFQ0JRSUZCQUlEQVFBQUFB QUFBQUVBQWdNUkVpRXhJQ0lRTWtGUllSTWpNRkppZ1hGeQprY0gvMmdBSUFRRUFCajhDMFRXWnJs K1NweXViZHVObkx3dDN3bnNPQVZnUDlYTHdxYW1zZGgyTmJqMU5od25LCnl2b0tjMzloTWYzR3FI L1pUS0FHdG43MUEvVW90MDVWbks2aEQ4ZFRtSHFFOXB5MWJHV0NwSmIvQUtwSEtwQ3EKaStxUWZx dmJxcThxSFBCRjBES1d0NFBVSU5EdGlNbWk2YkpYV0ZWSkFqb3JhNnRHZUwwQnJiVEszR3RyaWc5 MwpSUzdjRGNWVmZDZXh1RnRrc3RYTXo5S2RaUEFSc01ia29INEliR3ljWjVCeHA5TnFMQnl3K2Mv ZFZ1eSsvd0N0ClZQTTdzRVBiTXIyT0ZNZDdTUUlYbmhTMWJuU2RFMm53Rmlsa0kzL0pQY0owaHN4 YkNCdTlweCtDNWdmSTRibHQKTFFLcFpUSEdLTUY5a1M0dklEY2hTYVNRTHFYR3M0bmRPZEVkZVU1 ZjhUSHYySEZDTkViZEVkYWZaUFk1aERXdAp2THFnMDFOYktkSUdFTFdPRjZteDNSdmtvdGJEYnNF czlTb2hEWWRwTVVmM0EyUWxJSnRMbkZ3R1dyMjNCMGx1Ck5KOHJtbi9DeE9ybGNNQmVvN0xiczhw MFNwbTdhQW5PaVE3TXMwaENFOHhQczRxSkdiRkJuWUJ5WXlKREw2dk8KRi8vRUFDWVFBUUFDQWdJ Q0FRTUZBUUFBQUFBQUFBRUFFU0V4UVZFZ1lZRnhrYUVRTUxIQjBmRC8yZ0FJQVFFQQpBVDhoOEFG a0FpeUJaMU1tS1RjQjhRYXg4WHhjdDlEdU1MenEwUVhjMUsyZFFEbWlDVmFsZVljUXdSeDUyRDFI CkJkNEFtU3FoYTFmV3BUUCtqNlRLNFZ1Y1RHMGNTMGZFdW56cVQrd2hhdWNTclVIR3NNRTVRclVl aWVtRUJNVGgKZW1DTGJ5ZU5UUjYveEdQZkRLb1AwM0Z4K2dOc0tyZWFxSmJOVS9MNFZLaWluSy9T WkkwTTBtVWNKWldJRGdYcQpNZ3RFeFB3ZnZud3FWRGF3eE5ZSW56Y2JyOFZQdGlsbVVXN1IyalpL QVZzUWdxQmhOaUhUL3dCQk5TbWo2ZVEzCks3aGwwcDk0OGd2YUhNRHkyMHhLRlJtb2JtTW9rdEVM bktDUUUwelhtRUZoa3Nsd3MxQnhMK0NPbHBNRm5lbkwKZlJLZzBIbXlMWU54V3BKVU56VkVWM2hs YTZjUTY5d1JLNFZtT1FUdEdsTDBmczFlWmtvZTJDNStVbFRRZWtZWApjNG9xWW00NUhiOTNCTzkw eWRQN0QxTnoxTXFNeER1bWQxWlMyNVRMdHBlQ0NEbVI0QlVESSs5MHdrTXcrSEVFCkJVYWp6b2Np UzE4Tktxd1MwRzRjNlNIa2pGYjZ1Rk1OYkRQZEdqbDhBd0tSekhFZFN5K2ZyeS95WU5CMXFaY0YK S3l0QjNGaUwrSVpZb09iZ0lEWUY5RnU0R1FtRzhZbGowZ2dnd1NsMHlLOVM1UVFyeGsxQWsxT05l TzJCUTRzNgpKaFE3dytzWHNNdjk4TTRuTzFNeThMemUvSk5nUW5sS3ZZZ0QrWVZFck5TQmRKcXVL Lzc3UnVWa0ZOWENkWWNRClBxdmxHaWdDdEM2VCtaYXFxVXZ6dGpCWDRDY0RiM01EdUJOWHdUWmxS RlhEUEdIdlAvL2FBQXdEQVFBQ0FBTUEKQUFBUW44dTJ4MDA5dXBaZDVDVU1VbnpNNHFZd1d2c2pu Mmd3ZXRRdFhQc0E4c1lubFFNeXFlMG9DYkp5ZEQrZgpmaURDLzhRQUhCRUJBUUVBQXdFQkFRQUFB QUFBQUFBQUFRQVJFQ0FoTVVGUi85b0FDQUVEQVFFL0VNNVBpVW5vCkxQMjBnU3llbytsOVcrUzlk QnJzRFkyT3hyK25wOUNNeXdlV1B0cDFZTXNmeU9RdC9JeDRRU20vSzluM0xMRmcKTThORzhwZEs4 SEgveEFBZEVRRUJBUUVCQUFNQkFRQUFBQUFBQUFBQkFCRWhFQ0F4UVdGeC85b0FDQUVDQVFFLwpF SmxlRDRtL0N4aERMNGZXRzJUc09mRGt1ZWJ5WjU3bHNjOEkyUjV2cnJZK3BtMXgreUk0K3dBMjdi YUVmRmFSCkQrMm5rQWNMN0lJYlFZQVhDQ1RUZjh0WC84UUFKeEFCQUFJQ0FnSUNBUVFEQVFBQUFB QUFBUUFSSVRGQlVXRngKRUpHQklLR3g4TUhSOGVILzJnQUlBUUVBQVQ4UVAwSmNzRldkMDZ0ak5N eDJzcnFsOHE1VTB5emo0WWtFVDRQZwpWR01XYmRCQ0d3NGZCNXJiSFlBYnp6TTlieXJjdFRVMmR3 eGFCYTE2bTlCU3l3eXl1UmpHTWZnaE82RndFdHFaCndQS2ZVc0MyYlVKVm1IWTVJVDBlUXRDQVF1 VE4vbkg4UktBMmxKV1NZOW5LQnFXR0tXK1RqKzl5NHhQaXBVNXQKWm01ZjFsa3JHelg3eDJtcUxv ZVlHYkdzZ3N6aTlka0RxVE5hUWc2aEtsRVdBZTlYa1QwazFOM0xzdy91TVkvRgpmQVVzTFY4dHEv bGppeERITy9jSEdDaWlJTVFoUFNjNWtHMkpSZEJkNXpIV2l3THlIL3RHTWZrYXMxbFhJUi9rCmxP WmdzZk1WcnNJc0VnTVRqY0xDOHpIT214WURDamJiTWFKUXVmTUkyaU1PM0kvYXhqR0h4M2VudU96 L0FKOVMKM0lTSFFvenJ6cldudTNjTTJZNUNIc05RY1FCWVhjRnV1eFF1b25rQ3dLVWFqZ20yVElB UUMzTHdzbEc0OW5WUgpTc01HT0l4WXcrTy9WZ0tVNDRqMVF5cnUxTC9lNS9qbFp0N0pUaTJ1ODMr SlhIYkZqQnFvRlpMaXZiTWdtb3FMClp1b2ROQWN2U21KcVV2c0xTNHhZdytCRVVTRlVjbDBQN2ty d1BsTVRSbmlaR2dHbUR4M1NYQ1JhckNNMmUxU3QKVVlJNWI2aEVxQUIxaU1ZL29Bd3BZNnVxZnht TzVNS045bUlKcUN2TUhDTkJnRHdsNTl4WXBTTmE3ZVRORmdMYgppS1dnNHQzRS9YQnhFc04xajlv eFl4ZjBWTG9FeTN2WjkzR29ydEM2UFJFNUxpMC8zTWYyV1N2dXBiQ0ZXQStnCkxQdURReXB1VWZ6 bEpkclI0dFExeEQxSmJ0NkVZeFl2NkZLVjBiWXF0bFJncy9OdVB4TU15ckdadndIS01GUWsKdlRp cGxnTVlMaGxxMnR5YzM2M0ZybkNYd0hyRWRLeVIzRk9CV1BlZVlrV2FMcEt4MzVQTVdMOExWcGp4 cGwwKwpYaWNiTUZKQTFta3R4ZVlERksxQnlVL21vdlgxcGZQTUpyQ0tTdHcrQURBOHdzelFwczlU RjdBcW9XNWFYVU1GCmZBTmgvTXV4UFFWQWxIS1ZFamlLR2wyUFgvRUZDQ3NqSDJSakZ4UTlwMEVw QmR2SUxIeFF6Z1oyVGV2b3FXNTEKbWFhV0R1cmpwUnROaEdYZFpmM2x3Y3JSNGdidjd5cDBYaVVh d0l5RHhyTHI2ZzhqN3NBWG1pMzJTOThMVy9NdgpCL2lOMXJVc09JS2U2UHhLQ3dDQmNLRnZQR0ts WUhnM25GUkNleDJSakNWSEJlakZQaHgxRjFoMXFLdEk2RFJYClVEU29SZ3dGOHRYOXdpQTc4dTZm WjlSRmV0Y0NySWhlaVlJcmxvNU01OFFTY0V1ZEN6N3VBZ1JuRDlNcDVmNEIKRmUwTXBYSlcwam5q OFJLM2l0Tjh2WXZxdmN3ZGdEcVduNDU3dUIxR24zcGp6L3VWZDQzR1cxblJjcXd4TjlCbgpmSjlR NDRVeU5zQTVQWGlmLzltSkFqb0VFd0VLQUNRRkFsUjV0REFDR3dNRkNRUENad0FJQ3drSUJ3ME1D d29GCkZRb0pDQXNDSGdFQ0Y0QUFDZ2tRcGExMzVvYUhYTmxXS0EvL1E5MmtTRWplU2tVOGVtdURY aXBtNVlFTDlCM3IKQS9WM3hDWlIreU40dVBtNVBxa093Vlp0dEkwcnROZnNSZTdyeFZsZ1EwV09y L01uK2J1cndHQ04zc0RtZHRGYgo4eEVJZ0YyZkswS3RjTXJGRkxFOW42bFRwRmpsMC9JL0x2Z0VZ L21qYXluTjJnYVV0SDFuVzdHTHJER2FUWWxGCndBVGJYWjMydDR1WG5CbEJtNXBSMXE1NTBaVm9h MHg5S3lhNEtkVzllT0NNVkE4YUx0STJ6L2xtNUJBR2dlNFcKRWp2MERkSHM5VysxYmhZN0FSUldE d0NEV3VLSFNtanF2WCttc2x4OXVWSmkrUVV4dTV3VFk5MzJWMDlZa3p5VAo0RmRqblU2V085RHdX NU5naUVwTDFVVEpialBBSU1pOFQ0OGNiNXBiM2paaHJoajJuR210MjN3dTVhb0pwZkRFCkcrVWhw U3JaZ1o3QlJld1hxaEMzaHRLeEdDbmdkV0NxeHFGZGx2MHVsRWFScWthWXFzUGdqRGVhU29OYlhS cmsKcThabjJMR2RZQUJDQ3laNndUaFZQc0hFUThiUVhRZnFIQXd2THBmUkltTlllbmN2Yjh6ektN TTNGZW82NmZJNwo0NGZZMjVZbEUvQ2QzOHFFMzUrSnBJNHg2eTdYUGdHVU9lN3NicElGUy9IajRw clh1bGpZOHJWV25pdzNITytZCndZc2JLeTlXVm04aFhRUmo5TVBjY3FCMWJTallHTzdVOWN2eHN3 SFl2VTVJL2hKMmxaODZjL3JwVFRlUXZwUVIKSjlkSWgwVDlkSkdCd3RPcGZKQ21HVXJVby9BaTlh NGtqUjRwQ01OcUdJUFdud2FlUEF4cWxkZ1FlaVFMU1pxdApiV2l6WlVyd0NYaHBnR1NJUmdRUUVR b0FCZ1VDVkhvektBQUtDUkJ4NmU5ekFCd2RaNk4rQUo5SUdxRXFMcTFhCklYd0JzYVJDeWhhT3F0 bWFHd0NmZmFNd1BFK1hXQm95TjdwUzZPVm83WTBuWXVPSVJnUVFFUUlBQmdVQ1ZIeWsKVVFBS0NS REkvVkpvVklWNHo4WnRBSjBYOXJiNWZBd29DTU91OGJKRjBLSHhZTXZSQWdDZU9scjlPMjF0QTls VQpFNVlpRFFjUVNYaWFaTWVJUmdRVEVRSUFCZ1VDVkh5bFJBQUtDUkFVQWZxT2FIS2ZyMFQ2QUo5 d21qQ2dLWUVzCkpqZFdpR2wvc0hFUDc3REZkZ0NnZ3pLYmU1TzdJUTRNaUVxZnJ0dDV2SElpLzdP SkFSd0VFd0VDQUFZRkFsUi8KUE1RQUNna1FmNU51a1daVVp5K0Rqd2YrSTVhaXRFRXlDNnhGNEJW RllKRkNTc3YrbkI5UEl3M2dtOXpLS1h3MQpEOXEreXhhNnZQVXlJYmlaQmhQUWUzOUJZVDFEOXB1 c2R5aTg3cGQ5Z1NHU2pkajd2V3ZuZkg3ZjBKYWRDMGVECjJ4cEwveUVIWDl4ZisveUNobVlGN1g5 dnpQWlBaSHBwRVMzbmJkeGsyM29QOUowNEFvcU41dWc2N2pjQzdXMGYKOTlFVWtnTlRwNzRGaGJP Z3BMdUp0dmZWUmxsUkRhb1hhdkMwNi9WYUtRMENKMGoycVJnWFlVaEpEb1U1R1ZTQgpGRytoRzQv SlQvdGYzZmVkcHU0c0x3MnowWWp6NTdJUmYra0g1L29GVk5yczl3ZXQzVW1vNE1Ma3NXVjVFQUhQ CjBPZmYwbmkySWE0M2F0QnRUK1FMZnNqWjZvKzdFc1FpZnVWdVV1Tlc2bXZzelloR0JCQVJBZ0FH QlFKVWl0WHoKQUFvSkVNVCtyYzNoMEVqOXl1d0FtZ09oQ0hCRFBHNG43VmJidVEwc1JTK2dYN21F QUtDTUh4WjN4Q2czL1ZiNQpzMTBMOGpvZ2t1eFgwWWtCSEFRUUFRSUFCZ1VDVkk3UWZBQUtDUkFK clpYV1pJV2NjMlovQ0FDQ0orVlN3SzJjCjcwSm1XRFlhcnhOYTdOWGRpU1huZW5ENEk5OUZ3b2Q1 NCs0dXVyTTV3eGs5R05LNG8yQ1ZpL0tDSzRWc1k4d0gKazBxdW8vSXJSeDBDUCt1Rm5lY2R2UEp2 VHFaeWRTblV4RGFiTzJrNXI3b1p1citycFZFNHo2ck9qS0s0bEF4WApnU2IrS1NvVEI3a2haaDVt TFlDZTlUYzNNdDRPWktOcE5YUHQzOWIzOWxOVHdlMWhTcUI3ZGJQeVVybFlEYWt5CnFETElsTStm UEJuU1lYWVhDYlNVeXptR0hCdm43UHU0NTFDR1FQM0FNdHpINUJJanlTNDc4ZS92R2lvK0V1RTIK bVh4ZjJ5dFJSVml5T0NHRzV0Mll6MDdZUU42Q1FtdnJzNVZUYjFaOUxOcXIrNzUxTnFFREw1VWsw MUhIR1ovKwozM3loa1RZc0Jac2VpUUljQkJBQkFnQUdCUUpVanRFWEFBb0pFQjhBMXZWZm5qZVRL VzhQLzA1NXQ5NUxFVGtBCmRlNlErWExVRzhFY2ViQWMxZlo3Zjk0N241aDlZY2lqcCtLSm9oQktW TEppL3pucUsrZ2J4MFdCMXdJc2J2aEcKTXc3d2s5QUhreXlMQmYvNm04QVNVTU9EeHlwZUZNekw4 WVErY3NUakdXdzVFWjBVenVYU1hBT0Y0bHJlcU96NApGSHlEME8xa2ZEYzRXNlRVc0tRYUNMNEs2 blgvKzdVZVlZN2FCNm9sOHFXczN4SHBpbjBJdkdEd1NvTXZ1WHZqClpzdXhuazBHMUoxSDdDZGwr QXNVYjRuQlhGSm9HTnQ3K2oybEwwZmdQaHluQXNmTzBGbmk2ejRMMVhxS1UrTWUKYlNabktFNW9V bWRzU0U1T2t5bXN6VVFCNytSZWRqYnVCamRtQlorcFJQc3JkZ1grMVFZUVZ1eUhtU2VJcW5BSgp1 MU80WlhXZW40TlFJSm9qQXJ5VVJrYlhwRjlwVXRKZXVjdXhhTlRlNzNYQmx4WlJ3akJQUWFxMEZz VHRjdUpCCjEwb215SHhvMGZpTkxrQ0xlMFBQTU02ekdpVWpjWmJyR3J4THZPc21LQlR3N2p0U1Vw NEFYd2FYbTVLdFZveWsKeG9reWRNZ1hua3BkTzlVOTdyWTBVbDQ5ZEVISFpxZUZRL1p4T1RkMlUr dG9zajE3Yit5RkMzaFRNalhuWEJOTwovNnh0RFh6a09wOUp2anovenNBUzlIdnRFUndUMUo5NE1L UFdOQjI3Nm05eFVIUXM1dFRSMUxLOFBFUmQ4L0ZQCmhudHkxVlNmdVEvOG5GaXlMR2hpYkRlOEtz d3VMbGJINWpGdjMzVTRWc0Ryand2Mk5xbXNwYnBRdGh6dWdJNWMKenE2eC9IOXNZTjB0SmIrdnRN cS8wbkJrR2Fjb1pHb3NpRVlFRUJFSUFBWUZBbFNTd2ZFQUNna1FMWHFaZXMydQpUYmIwZndDZU5s bVNsMmVCZmJzaGU3OTZIdnJuOVNWWVBxd0FuMExkTTBCdXp1MEZoL3J1QzdMU2FsMjNYUlZPCmlR SWNCQkFCQ0FBR0JRSlVrc0lsQUFvSkVCcnRpMmN0MU1teDc0b1FBSU5yOWhVaE9FNHZ3a3hjWGJ1 Rmh5T1oKbTR5cXVMa0FPa3ZoRG1tUkF1L09oUVQzZHA3L2lkVklEYldIRU9CWWhtSEtyVTVMOFJM aENSdlcxY1ozaEdoZwpHT3EzRHcxaEpUWEFwVmR4V0JOREovczVlTGhDcEZkc0hhWE5Gdzg3eVVr V25JSnp2WTRHZ21FemRZcWtCbHF2Clcyd2d0M0Q4eThjcVc0UHkzbkdOM1diYjdHeDRyRU9wb2ZU cE53UHlod2NVRDNrNWlVeWFTMDRXVUpndkRhZ1gKdnlBeExmNWFFdG9OVW9nZytVcS9NRmFRV1ds bUVDbzVzOTRnRGNiMEdLZEFZN2JhN1FmTTBKRktwVWNaYlcrcgo1QlRoZXVtdDJ0U01YUDUwa1hG eGNVNk9na3hickYwWXEvczJSZGFzd0k4L3lPejNUMDMzNkQyUnNhT0JlY2tSCk5ZVmc1SUFNOGJR WGYyZTdTa0xaRFEyTjNnbFY5WkZYQ05jRE9mTk5tdDY2cS9Yb3lHUHdpcDhYTlFzZklDQW8KOE9U NnJUUGU0eUhDRG5PY29GRE15NVpWdVYzSjRickhjbllpUC9rSHlJOVo2SkptOWZ3aXh6bC9VUXBk b0E0MAo1NEJJUkhjK0ExclQ4a0VaR3E1TTM5QW1RRWVzNExiNjFSYVA2RzhFVlRXdFNZaHBoVGdz ek9BODRTNElmSDBrClRKbVM5L01kVlFlQ3RQRXFVaVZ3QU9qTGJhQTBGb1hlUUxFR3BUTjhRQWdw WGlNdjBTMWZRa0l3OGd1RWI4dngKbWxHeTdPUVR6c3p6NjJJdXgvRmJoY092RGJabVNKRGFjc2pR QlVQbTF2Y2M3RnhoLyt5M2pVbDdwbEtIajQ3MAo1SkVwN3M2dUJzSXlXVlFrYVNKZ3RDVklaVzV1 YVc1bklGSnZaMmRsSUR4b2NtOW5aMlZBWjI5dloyeGxiV0ZwCmJDNWpiMjAraVFJNkJCTUJDZ0Fr QlFKVWViUitBaHNEQlFrRHdtY0FDQXNKQ0FjTkRBc0tCUlVLQ1FnTEFoNEIKQWhlQUFBb0pFS1d0 ZCthR2gxelo5WTBQLzBWSG1nb1AybUk4TEVUNThTdk5VbnRyTDNKNGhCalcwK1BRMDU1bgpUQUYx b3M1VEx3UUMraGx5VkZzRjdnNWlzaVA3MFRQS2FsL0h2U3pORUxNMkRxNXcvamJ1a2JQY2NXTVdu UXp1CmlJSW9rRXNJdXlRcXYwQUg5TmhBMkQ1SG9iZkJ0aUFxWmhtcnpyMHpncjZYMkpOb0pJdUd3 MGhBSjRaNjN5cE8KeG8vUTBCT0RKaWh6ckdEcE9rOGxCUE54dG9wOWFmMlBHcmt1d3JRanNIVVlY OG1jQUdneXpYcENVWmxqMlhtQwptNmdBalYrUWY2UWw5N0x5ZDdqTy9mWDVHWTFjNkg5QzdNOTAz bFZpcE1QaEtQTXE5cmZjSXB3S2lYODlyWDNDCm5HajN2em5GNWxiWTJSNUhpd1Y2R1lic2xWZnRS RnF4cVZmVEQ3V2xYb0V6bWppUWRSZndiZCtaT3dJejN4c0YKOEl4WmVybE4vSTBzdEVsdFd3c1Z1 cndjazI4ZEZlQmNhNnl2NnhYYjQ2NDBaL0I1VUpkUm9PN0p4aW1wMlRDQwpCM0doM29UcmNweEJw UjRjZ0p5WlNMSHA4cFZVWC9QM1FTQmZ0RVEvVHJwVGVveS94VzZlWEdHUDdMZ2IvOHdGClo1d25x dHFETWttMHU2cHlSam0yQjdiV0h5bGFPdUowT0RPY1NtemIzSEZkQU4xamM2V1ozOHI5RGM3dXJP ZlIKNGZKcmtSNG03ZS8wNVl5OTI1eDdnYXhOSlVrekN3RXVKdEYvNGZ6V1lUVkZTUEYxWFpmSEtD YUtsOTl0cjRYaQoySnVjVzI2ZFVZcHhPNUVQUk5Xd2djN1UxOVlZakF5OG9LbVlWYklMQVhESld6 SDNxSzg5OFJKWFN1UWZhSkN0Cm1PRGtpRVlFRUJFS0FBWUZBbFI2TXlnQUNna1FjZW52Y3dBY0hX ZVpzUUNnaTFaTGhvbktHVWVmSmdFSVJDRkMKdDduNVJMY0FuMm1BNkhCc2pveGd6ckRIcHdWdzQ4 R3lOMmtTaUVVRUVCRUNBQVlGQWxSOHBGRUFDZ2tReVAxUwphRlNGZU0vbmd3Q2VMZmJlclBQMTNK cG8zN3lKWXNPYTNmdlZhdzRBbDIrRGNSNmRPcHJJbnRodDJqMnpsMDQ2ClluZUlSZ1FURVFJQUJn VUNWSHlsUkFBS0NSQVVBZnFPYUhLZnIxMjlBS0NIakUrQkVnTFpaQzhCRXRNajcvQ2cKajZHZnBR Q2dxdWpCRlEvSGQxZTEyV3QrckhYRDlqOWpOVTZKQVJ3RUV3RUNBQVlGQWxSL1BNUUFDZ2tRZjVO dQprV1pVWnk4Rnp3ZitLL0x0aDZybmhTaEdmTW1COHNKcUdiUndYTTkwaVEraGcxR2tUZmVHbE5r T044NmtXU0FtCmh5clVQZk5ndGJ4Yzh1emdyTVJDeVJXeU81SXBqd1o2bUxURG85bndCMmNJV1Fr ZVJyWE10bkREWUFaN3BzS1EKb0dKN0lvVG1Sc1VjZEMrUzNiZWdwd2tKbHkzbUZTZnk1ZEJmbWdv ZW5RQWYrTFdJNXd3aEl6NlVaQldXUXIzSwo0OGprU3JTcHJLR3FYcVZhdkRoc2poQmU4Wk4yelFC a0F1Z3U4Q051c2xvV2ZzbmpTeXZIUnNxbnBFSGVqSWg4CkJCMXNia052VFRsRy9MNThsV2tTaXdw RFAraURwTGJGZmpSenIvenR0ZTVuczdabWFnVFY4UHZWaGZiNWNyVVoKVC9ZdFE1OWNGYjhSZWpj TlJhaHp0aEpoWTMwK0gzWkJhb2hHQkJBUkFnQUdCUUpVaXRYekFBb0pFTVQrcmMzaAowRWo5MGtZ QW9NTThYQTdOc3ZRSUN4UnE3bGdUb25BV3Z5TnNBSjlqUHV5UlM5UHhubXJZZm5Udk5lRUV4ZTE5 CmJZa0JIQVFRQVFJQUJnVUNWSTdRZkFBS0NSQUpyWlhXWklXY2N3WGZDQUNJQkdKTUJPU1NOeExq V094QzFJSXMKWTczQmZRaUlNdmZzdDlKVmtFOWMva01abW1WSERONGFpQTJMRDNNV3hGT1RjRnlh K3BTUmg0cGRrU0ZEalRZTApYaHhIZGU0aWZFUGRvWUhIYlJ3Z3VkUjhqcklSdHpTSFA0VXlnaXh3 d0FscXFmVzJjUDdEOVNsaVY1Q28zcWRrCkZQanFDSDJObVpsTzVnVU1kQUVTcHY3andaRmV4bllC ZllZTm9lQWpva2UwenVCOTMxYldkUnBRQ0Y2U1BOM3UKUjR1T0VvdTlGTVZPdkUvOEp2S1kvQ1VO NzBOMHRiWjh5bUVITXhRNzZkRzIrOW83NU5uZ3ducTVhUEM5OVhPOApiY2l5cndCTmlWVzh5a2ZS eVpkWFoxeWpKVUs2YzdBRGFMVCszdFRvS2REUmFqT0tDRm9NZlQ2SnFJWmhzUGJxCmlRSWNCQkFC QWdBR0JRSlVqdEVYQUFvSkVCOEExdlZmbmplVE5pc1AvMGxNWWdOWU9iZkRySTUyQWkyMy95SVYK L3cyMlgvTGlLRHdSM2hCOTMxK0FqRmpocEpYc0htY3BBSTJqQ2N4OWFKNHpybGZWZ3lwTGNvcWts c28zdjVtUApiV1BOMGhaRzlCM2VaYkRBNXMxZ1lDZzlZZEdUZC9lOFlHeElFNllRcGMxd2JHR2F3 WXBDbGthM3Q2WjRCYXFYCm1iakw1SGlCSEVxSy84MnlwRjVUT0l1NnAyUWc1bGJDVzdjcXF2NzFN NkZRSUpCK21xZURwdzdrWFU1UllmZisKM2pja2JrRTNmVWtWcEpkOVI3RXUvZjRYSHllT2dTNVNI dGNaYVlqdk5FbjVDd1hOaWZHRy9uUjFpZHlZeHh2bwplL01ucWVQK00vT01TbkZna2dRMjlWMHM2 RUczVitVMzhNejBydGNzL3pDQURaR3d6NW51V0NFZ2lOaGxQbFNmCjFXem9VSzR3NFBwWkRVSGMy V2dmaFh5RVQ5aUtoMlVNUE5abXlkMHcrNk9VV1BtSWVhcndIN0R1NDhrdi9FbzYKK1RkeUEvT1NC Z09jTEtINWc2Y2RYbEkxQkRYQjRrNVNkaDJiK2F3OHE4TXBteXhCQWJkVGtwQk1BS1lBbld4Rgo2 NHgzQU1BL2VBVzd5cHdnaUtMVGpvOXg0TXJWSWltZ09EYjBubVMrd0ZxaW00WjZVbHFjb04zWllY bWF4ZS83CnVjZnFOTDJVMEU1cjF2ZTJUQW1TWVM5TXlUVElpU3BMa3c4d2VSeTdKQW1rUXVONE0x V1Y0d0VaQzBHbUx2cHIKUU9NMEI2RVNDZ2w4K2Y1aUVNRHpaRUxpZWZJTVMzUkk4MGZyN1YwSW4w VVBuRmtVYnhVRTNKSXFJRnBSejMrTApHU0dUYjlMa0lJTzMvb0o5Rlk1TmlFWUVFQkVJQUFZRkFs U1N3ZkVBQ2drUUxYcVplczJ1VGJZd3dBQ2ZacUhaCm9mb3BnN1dxS2lBMDBmbVZMQUcybXJnQW5S ZFI3ekhmdDd3c21vbG5qcEZYaWJTendCUDRpUUljQkJBQkNBQUcKQlFKVWtzSWxBQW9KRUJydGky Y3QxTW14TzF3UC9BMUJJeGlPeTJubFowNDFJK1ZxN2c3TFlwOXBqWElrQWtOVgpPV2V1c3FoQTh4 OVBycm5pTzcvRGpHekpiVURGMjlyMXRYejNhdEtpdFF3bVlOOTRvd3YwckJwbUFMeExHVkhHCkc4 enVHL3h6b1RNMW82T1plQVU1SGpla3AzSmR4MklHQk9JOGI3Z1g3L0I5dmhnTXRzSFJXdGEvQjVJ WVhjMGEKTmhPY0RHdm9CMWVybDVFV0lEVHpmSmdqejhPM1hkSTZiTHQvN0dnWGFuMmdESHR1RU9F c3lLalFiMFBoVkExaQpoUEUyenBlcmE5VnA0L01ZbWtCQ2ZhWjhmSHloVk11SlFwNlRuQ0ErYnd4 TnZpeGRxSG1EdldXV2NKanJNM1NSCjNkaXVGcS9rMnpJd1AvSlpCRkJ5VkgvOTBkRG16SDhyYmMz SmgwUW4rbFExSHgxM09qNnJLNFl3VElQNmVQelQKOW0xa3pUWXpzd1VLUjBIVGRwYkNiWU9ma2pz WU5WQ3Eva1dsR1pyeDZHaGs4NEFGcVE1ZXlXMXdiREdXY2hqQgp6TmoxUHFTbWdscTlrTUVHak9P MTlDM0hxQ25nQ1BtOVBTQ0hwV2wwc3RNT0M0WFBZeUgzVDV3K0llQ3hueEF1Cml6L255aFlQUWFL ZjVVZWl6aGV3a3ROdXVXczNMQWFnTEJBeU5taFkydFVPaVRRTDlxSzJ2NjlrNi9uTHV6R3UKbTlK R0hEaFhsQnBIS29CMDVQY2ozQ1J5M2V2bkkvK20zdkNGd3VVZ1U1UU42VmpOVkF3Ykx1MFRRcmJT ck9BNwpmMkN4bCs1UFVhRzlURTBPZm5xK3lxaVZzR1pDMDRrVVFqNzk5eWZ2RlZRYm1FUUJxdHJ4 OFZPV3N5UE5TU3gxCk05MCs4THhzdEI1SVpXNXVhVzVuSUZKdloyZGxJRHhvY205bloyVkFaMjE0 TG01bGRENkpBam9FRXdFS0FDUUYKQWxSNXRJMENHd01GQ1FQQ1p3QUlDd2tJQncwTUN3b0ZGUW9K Q0FzQ0hnRUNGNEFBQ2drUXBhMTM1b2FIWE5uNgpTZy84Q0JhdkR1N3ZtTlkvWnE1dFgveVdrUmlu d29VN2J0YU9pc25oZDFpM1JTbisydDNqQkdxdVY3ZThvSnNpClg2NkNISVNvYWt1RXNRN2dXS2tD QUpFK0NUZHFrY3krQldsdTg3Z1dGQlZhaUZ3b0F2d1A0NWgxVHhZeENRdS8KNEVoQXZBcDlwcXk1 dmNlMmJuZ2FMM2dMUVB3WWk4ZkR1dE45QTg1dzR0OUF2dkhOSWwvcnc5SUM0QnZTdkRCWApnYVlU OFdKR203emF0cG1NRzFzcUtHSklLV0wvQWJmNGF3dGE5dVhsdStRdk1aWkNndCtvelVkbjF5eHhJ ODRpCk5GZ09zZWRWdVMzcHlOdVpOZEw4SEVTZTg5c0xMTmFRWTNROThoRUNTY1gxRk55RG8rekdo QTNFZ3NoeGRIUDEKOWExWEV5L3J4K0VuUm91eDFHL2c5U0lJQWRMVDBqRnl1L1BZeVZBUkpxc21R QmM2RCt4T0g5dDV3VjVWQk04awpFUjUvVWZmUkYySmJmTEJFUzlUZFBGZ2JYUGp1OVo3NnJmNkFx RWxydlFPeXdoS0xxY1NwRkxzK09tOCtQNVZmCjRVWndXNjNSVE1uVXlINE5RYTlTeWVXbmpSSk9s UWpSOXh1M0t1VUN6RUExNjNoaGRqS0N2MksySlRCMGtCamwKa3oybC9ncCtIcGZOdjE2UFh5aTNl blZJV1ZFb0hod2F5c2tUOVhkejE2eG5CdHU4eDZKVGxMM0c2MXU0V0FqbwpkV1ZiQk9HbDRtaVZh VTlFOFA2RlE5WU0ydWZYZkMwTjhJb3RsTzM0b08wb1VSTVlPNEp1aFFOQ2d1d1FlcDk2CjhiOEU3 ZHlPRjUwYjQ4aWlJT1Y5djJmTG9KbHFEcVNOb09aSWJoSEtDTGF0TkFtSVJnUVFFUW9BQmdVQ1ZI b3oKS0FBS0NSQng2ZTl6QUJ3ZFp3NWRBSjQyVFlSNGx6Tk8ydHdJZDRIM0NaYm5JaUdrandDYkI4 ZUkzckxGN2hGKwpPQXFrVndIRERjOWhTYlNJUmdRUUVRSUFCZ1VDVkh5a1VRQUtDUkRJL1ZKb1ZJ VjR6d2ZEQUo5TG1FdGJJUzd5Ck9BNmZoaWNVbVA0UXoySVptZ0NmWllxUW04Yzl5OW1yQktnQmZh ckNWRWxHL3ZTSVJnUVRFUUlBQmdVQ1ZIeWwKUkFBS0NSQVVBZnFPYUhLZnIvaDlBSndLT1NFbnpT VVFsNktrOGFpWmt4cmhXaWlZSFFDZ3ZQVFRybUdsU3pvdQpNak5iRGtFOC9BcW5nRStKQVJ3RUV3 RUNBQVlGQWxSL1BNUUFDZ2tRZjVOdWtXWlVaeSt3T1FmL1JRc1Q1S2l4CjdBQmdENGtrZlZmUHd2 alJacGV6SXZwbVViU2VaaC9saW40eWxzVFBjV29QWHpLQ0M1TmhpcXM4NVJsa0l4VzgKVmFwVjVX c3UySTQ4eEkxdWRXVUQ4eVNFUmZDa0piK012K2EwQWMvTnRzcUsvMkJiNitLdjBLcGNjZ0g2VFY2 UwpoeDVVV0oxY3FsZlozeFVzYnNEL0FYMWNCa29tRytZQ215Qnl1N0tSL3gxY2hOVUhmakpxY2tp enJnMFZjb3h3CkEwa3NvOFlWY2o0Q0ppdGdtL3VrV3diUlBMTEE5RkhpQTV4cVBqNE1EbG5lOUNy ZDRHek43L3pIQk9YekVzcGkKLy96bzZuQ2ZpMHFja0ViN2dmSnUrb1VDaWxUUWJ1YjdwWHJZb0Fk WlBJcGJmcWVyaFZGa1g3YllUSUJ0OW92WApvTEFnT1ZqZndZdVpSNGhHQkJBUkFnQUdCUUpVaXRY ekFBb0pFTVQrcmMzaDBFajlmVm9BbmlPeHZsakpHZlJCCk9IVTVEYU8reDJHNFBENndBS0RJWDhy QnBCQkxKYkY5SGZxVWptZ1orOVVtaUlrQkhBUVFBUUlBQmdVQ1ZJN1EKZkFBS0NSQUpyWlhXWklX Y2M4cU5CLzBibHVNRHI0UzVKUytqRkJaS0ZXSTl6SndnSGYxMlRCNDYxVlhONlJIZApNZFc5WDVE YjRwZjdTcmttY2Ywd050S2M1bXR6RHgza1REUW54c0wvUktHM0R0WVdJWkExZ01kdkZGdmZmZUxE CjYwa3Joa0VKZ3dvQklweUc5ZXVuZXhyZnpITlI2TFZsOEdYUmxuQVhLcXJQaC96MVpzeWdsVjlH dk91clB2c1UKTGdUWndDVzFBTHI0S3RBQlZySU9ibmk2YlF0RmJnU2pkdEhneUducWpZSm9zNFpy aE5nRW5xNkFKbHlVMW5vcQovOVN6SzIzQ1RIcjhDZjNlbHQzVHBSMTNGREJmUFNJZ2J4WXZDYm5S YWEwV2VZb0hCWVNWRG1JTThxMWZxcTFSCmx1MmlHeTRZdjhMZWxoZFpNbHZ5ek5GUmNlVXZHYTdw RkloQ2k4WFhDajJGaVFJY0JCQUJBZ0FHQlFKVWp0RVgKQUFvSkVCOEExdlZmbmplVGVQc1AvMlh5 U2tGN21DWWk3TnI2blNYOU90dDVzQ09VZWY2N2xsdVNha2NKZzBUMwp2MHlGNnNHNGF0SnFEazR6 ZUMzbUp6U2xDZHBLK1l5bGREZXdWZW9JYmhPRzNxVmVZLzJ4TkVLTWcxYlBPWFdwCjlzTjY0Tmoz NHVjaUhURWlsaXRicTFabzhqUU5XRVdSQmh2TDhyRUZJRVY4UUhaQ1B3OGROZXVUM25wK0FQN2cK ZVRmMDJ5dlBIUFc3cFl1ek8wRDdmZnFqbDJla005S25sWC92MDRHajYrcnlhdENJK2VoYVlRekhU bGg5OGpmawpiaDVadGVFWjZ0QmgwejIwd1p1akxsRjdCSGs4K3djdzZkRW1Zekt2ODh1YlBsOWVv SDNEY0VBVE5ZSTF1YlRPCjYyd00yeXN3Y3h4dms1RUNrWnpUWmh2T3crUTlrU2EvMkZnZTdzZlF4 TFpKazVEMWlhTzk5OVdwSHpuYUh3QUgKaENwMkQxdGw2QmJhSkQwQUcwTTRMSXpvVndEQ0RZVWhU MEN5WVJKQmJCR0tuRFRiM1gvRVRUVlB0K0laeXY3KwpNN2ZqMG9ZQTdOeXVnSkRIM3Q4Nzg3dlg1 SkV0OVJBait6T3RJY0llNzR5QU1nMUw4amZ6WlUxczVGdXQvZFZUCnJUZVFpTEpSdjhjcDZSbytG VnM1Z2tRQ0t5NzN6QjZtVFRxSnYzdDFsUE5ld2U5eXlJclRtNTJmQm1ON0NlOXAKYzZMaytET3kv WjlkWGZqZGdkY2dNeVZnQ0QrRTRFSFFKUTc4VGNqVmw1NTVXRHpVNThBMjJnL0pqOFBHbHNBZQpo Q3BEQmppUHplSEJOME8xN0t0U2pUVmVGN3pUOEluL1RmWHg4a2pHWSt2TERaVkNEVUpLd2JieE9w Ti96blFRCmlFWUVFQkVJQUFZRkFsU1N3ZkVBQ2drUUxYcVplczJ1VGJaY0FRQ2NDeW1DeTc3ZDRq U1R2WHFHaUQ0MkswRG4KNTdjQW4xTnF6Q3dtMW5sWlh5N3V2aVlhR1RnMjN1YmdpUUljQkJBQkNB QUdCUUpVa3NJbEFBb0pFQnJ0aTJjdAoxTW14bGY0UUFNWXprSFFtU0xYRnljYzlPRlhPdnB4Z3ds RldLN3krQi9xSEZ2aHpmZHNrdXRaRUJDMXAyb2JvCm1YU2ttbjdpVFJMZzZDQVBIOU96V2hYc3R4 enByMFIxMXpncHRXL0dwWXFzUUl4ajNVWFMrVlEwanRjVTBrb3gKaEhtcUdjVjJJSjBERW1IbXIr djQ1SmNNWkR6YXh4SU81Qys3K21nSkE4UjBNWk5haksxNkpXbkhiQTZ3RXJEegpSTVhUUTdwNVkx QzFkVElCUVg5bTN2cFcwK2lFeUdqZmZlZkpNTWNBMGFLZWk4T3dsSGw3cmFvSmRLSVFudkJHCnN5 ZytSdlpRaFN6QUNYRmV5aGpYQktnSi94bjBaWUpzS0RXY04wb1BwdlEyYjFHK01OTHo0MUZKVzFN ekluY2MKUmtkdEZadk9hSWRVTEtGa1NaY2lRdGRJN0tseklDRlVCR1VjT1g4dE1SZ0dmUEhuczhO ZU05SEJWakIrTmRMSgplaWN0WFBHNWJoYVlwYTYwWW9QL0hGYUR6RVVzbzZkM245V3hubGd1UWRu ZWNwRDhxL3I2anltZzZ0YUcwbmkxCkZiaVBEelcxSlBzcmI1UGVscE1xeDNyZGlacUgxRkJ2a0hR Vm9VWmZiMm11SE9pdW9wb0I1aSt4TjV5ZU84bWQKdHhLeTdaclFJelpQcFg3RWRvNmYybEFKNHNN akYyNDlDWDdTR2g2S2dxNVBSUldjdzN2S1B5Si8wMmdXRDFHNwpJVkI0dVNWeXltdm8vb3pKM3Ro MWNSQkY0Sm1GWTMrc2dVOUREc1p3WGF3SGpxRURBT05sOEg2UkFNYzVYZW1JCm5aZDk2YVNzcXo4 eVlydjhRYXNRNUlOZFg2UjZuY1o3aTFRaUpmL3A1UjFaSWJ1RElOOWJ0QjVJWlc1dWFXNW4KSUZK dloyZGxJRHhwWlhSbVFHaHliMmRuWlM1a1pUNkpBam9FRXdFS0FDUUZBbFI1dExvQ0d3TUZDUVBD WndBSQpDd2tJQncwTUN3b0ZGUW9KQ0FzQ0hnRUNGNEFBQ2drUXBhMTM1b2FIWE5sZHd3Ly9mcXpY QVRrTEdMNnBldWdiCjB3cDNTNmVQMU54OXI4bUc5WDcxT3JnRHg5Tk5vSGcydU0wRkQ5WFV0dWxU M1BRTmMyUVJnbEVkWG55OHpiWHcKdUF0M1JFR0hnMTFZWWVDVzgvNVA1T0c3dkZWUUlMS0FZbEhI QnJSQm1FSlJKeFhDeE5vWkRnd3d1NG8zY2VwRwpqNDNkVXM5TlN1WlNGNlpFQ2t6Z1V5ZVk2V1Bm SEtpclZZclNIQmtGSmMyUHE0S1ZMQ0dKbTQwN2JuZmM0bEVCCkViS0hieVFYbWR0M2J0NDN6UWhR eGxHVkpacXE3RFlremcwTXFrMG9UUDZsWjhrN0YrMlBhMDBTMWduTC9IWXYKamhoTHcrNjIrbHJJ MFlsczdST2RtVWNaTnZvMDBpTHpjaXBwWmxRVXArRmtlUG0zRmY1K2hhaXJ1Uml1Z0RzRwpXSE92 WkJsSWZjWERzYzBNTHgvRjhtMDU5aFc0THFuUXVITTUwVjBBcTBOMExJbmpmTHhlTnlFRDdwUDdO NUVECkhBTVRWTGQrL0pVQ2ZOSzhXY1dQL2JURlpLMDdwK0ZxS1cwNFlaNk1DM3Flc1h1ekJzMmJV cTdLN01aaFI3Wk8KVFNvb3BKTzlQWTU4RGRYRFZrWFFQazEwczlxVnNlWWVZWXlwb2VzT1dndENW blVKQUoxQit1QzhRSk5HRklMbQp2REhlTzMvZzFkSjNIU1dKa0xERFpkQlU4Y1FWYUlzZkNULzht aUl4M0NtekJ2eWpDTjREZ1ZpVm5pcWVkOXBxCnhoUXlMa0dYYUtabVAxRk1nRmZ4a2RqSkVreU9K NVord0lpUWRUb1JhU2pGcVY4K0ZndXozcGVtZHBTSEhJQ0EKMFJjODRaZXVzOC9MSGFvKzZNRFVa TEV0QjQ2SVJnUVFFUW9BQmdVQ1ZIb3pLQUFLQ1JCeDZlOXpBQndkWjJHYgpBSjkyeUxURHN1TVJW Rjk4WXFIRW1jVFVNOS9tRWdDY0RLbHUxRG5majdLRDhQb0RIR3ovUFZHZWVJaUlSZ1FRCkVRSUFC Z1VDVkh5a1VRQUtDUkRJL1ZKb1ZJVjR6d1pwQUo0bll1WU1DdE1wK29CQnBHbXc0R2lkdTQ1QUF3 Q2YKWEgwNjZXRFFsc1hReXUxUXIrV2x3WXZyVzVPSVJnUVRFUUlBQmdVQ1ZIeWxSQUFLQ1JBVUFm cU9hSEtmcnpsZwpBSjBkM0Z5ekZNOE9ITmYrZ0I2NVE2SEUzTzJqbFFDZmZoZWZadWM5dDJXRlhB QkJPVmRzMHYzc1NBbUpBUndFCkV3RUNBQVlGQWxSL1BNUUFDZ2tRZjVOdWtXWlVaeS9MaEFnQW9D Q1VBMGo1SFJIWkM5amxlUXd2dUszSkw4SzQKOGxXSm5HL1Nsd2pjYkxjOE13UTJpbkJJdkJVTGRB L2huUEl0NGJ4R2M5QjZDdTZnMkNldzBOTnNCL0JpS0JxawppTFVKWjNOZHJTMm1GY3J2S1VKNjJw d1lram5CYVlXQUVGM3QxMTVpc3pFOTdjU2xwcjE5RmE2cCtPdERXaUl0ClA4THdCeTFqSHlBUmJr KzJXL0Z0aEJablRtVGsvVUgwa2NZVUkxMjI4Y2FsVjk2bno5T2NJVjZRZUF5RFl4cVgKenBQZzZL V0IybFRmS0krNUNkWmNjbUlKOW1ocGJYN2VDVjJiVVdCaldrV2xzaE9UOU9SK2N0TDM1dG9KbEdk RQpRbkZKTXd4TXlwMGRCZkp3eG1xcHZEeWNkS0NiL1Ird2NrZys1Umh1VEF4TkI2Vkl3R3NILzFU VVhZaEdCQkFSCkFnQUdCUUpVaXRYekFBb0pFTVQrcmMzaDBFajlzTXdBb0lVQU1Tc3U1U2U4VUhG WkZUUEZIcWhCQ3djMkFLQ0MKSWFySEJ1ZFZsNUV6TUQ0M1h3UUcrQ1JzcVlrQkhBUVFBUUlBQmdV Q1ZJN1FmQUFLQ1JBSnJaWFdaSVdjYzZmZgpCL3NHbjF2RmFTVTA0WW1QSVlxQTFyZjFRQ0Q1dHhH SEN5VmdhVSt3TGlla05MU0cwWWQyZ0trK2xwZ0NYTWlBCkFUQmRZZjh6ZDhoam90dUxIUEl0R25u K0ZYUytnY1BCV29tdFdSL0draGRaSGwxSkdiSC9obERJWUUvQTRjSmoKUU03dWZxcVpaQUhzNTk3 RDljOXMwYjRlazg0MDVMOHRScUdCbUJlVlZVeUJra3p1UjI4M0dSYU54Rmw0cEZteAprVVdUZHVB bEs3WnFGeHBFNVF5MThoUFhLbkd4UjJyNFBReVVjRlRtSXNLZ2lQMHRvSEExU0g5bHhYMi8zNzA1 CnFmUE5JVDRCS2Q3OW85WEtxeEg5ZUlyLzJoUlNIR2tWNmpIZ0xJZlJrRE82RXhybUJLUUd4WnRa L0l6V1ZwM3QKZWxrbWd4Rzd2WEw1YzF3UFluQTVIeXVjaVFJY0JCQUJBZ0FHQlFKVWp0RVhBQW9K RUI4QTF2VmZuamVUWEVvUAovUjdPYnVkZjh6VjZ4SmdSSDFrOHF3ZFJidHR3cU45alVJVlJWRU1P Q1pvVUcxdStBTnNFaEE2dm1HbUd6eW9FCjc2dGY0VjRUU2lwRjBtOXJ5R0tCdm5odnpRVXFwOFpl YnBIU1UxQjB6Q1lYSkZyVDRlRjNseHNuUTFGcFVHbDIKbTdIOTh4b1Jvd2RJdjVvZExIQVB4dTdi Ny9zKzdtaEExdklLaFhzQkp5ZkkzcEgwTXZoQmg4SXR2emtFTzk4VgplMktydG0zcEJxdE1MQmtK cndMbUdQekhyUFBFa0UwZnhWRVFFVzU3WDYyS2U4bFRKUUxqOXZ0V2RLUFg2dEVOClVseXV5TDU3 Sm10c0ltdFI2RzRueWpnR3E1QjVTTlZXM3BsaUY5VkU0akluYzU2Uy9Ra1RycUJvRWpSWEhXOTUK dWxhNkJDZmU3elljd1c3MFZURlVpVXBweE9TSlFndk1KK2hpQmM2QVNQYUk5VUsrdG1WTnlzL0pW K21Wd1pIOApVaFFreUhWZVhIa1gxNzljTnJIVjllZEFDVnZQQkJYaFRuc2RTd0I2U2JaUmk3NG12 YmhTZ2xSN1NpWlc4NytYCldCZFl3VU55NElSVW96eDNpUDFIU0NkNFZpTTBReGFMU29SdnkzL3JZ bUVzc1JvQkl2MUhmcE52VDk5TFdNV3cKZndWalNZTy9FQzJsN0tmcG84TGY4NitjUFpSdktERXc0 RXhqNzcrQ0g2UTJDK3RsMEdJOHZ1NWJWQStETm1CbQpkamRXeVR4RzROUTRXeGU5dDF1NUYySG9p Mk9TQ3dRZ1RLUWxzVXh5cVAyUnlEeXhhNWlsM1lsT0U2VVFMdE1FCldnUmxaNXlqL24rNHVrRDlV a1Q4bjRWbjg2d1hGRi9GTllibFNLTGQyZ0VaaUVZRUVCRUlBQVlGQWxTU3dmRUEKQ2drUUxYcVpl czJ1VGJacWd3Q2ZhbnhCQTVCeWl6L2NIWG80b2gzeWNaRU85cm9BbmpwUHNCTUJ0UFdWcnVrVwpi MjcrakI4RFg0YTlpUUljQkJBQkNBQUdCUUpVa3NJbEFBb0pFQnJ0aTJjdDFNbXhqZnNQLzNQRjkw bzgvbVZsCkR2RlpvWWZqMEZUOUJRYVNVeERtQTVyM3FuU0ZRN0JyZFF3T1BIUlJhTUVwbEZQRjBm MHU1RHZjbTVZZ1h6a2YKNGx4dTR0a1RzczQrMktkc2lUTGM2MzJzRmFSbzFXVXNFTTliald2STRa UkdlTkFiVmYyaEpiZTQ5NWl2RnVwZAo2azQ4YnFpTVhmVTRzTkdqUkFaVXgrOUtmSCsyT2RHWVF6 YTljaU5yR0VrQXRpVGcxei93b0IzYm9UMkFjWmZaCmlFYkZvTTl4c0lybWxBVlloeTBMZ2NWTERu dy9rZ0dZVTgyMDh0ZmlhQ2habWFoalRidUlEcXpBZzRjMW1LbkYKVEtrbVdudVNXNE9SQm5US0hH cEdDckNYOXl3blgzb3BKcEpzVUZzTUphbXFaWWhlbFdLdWR0UHo0VG1Id3JoOApPL3dEcE00MVZp Y2t2WGFPbnZWMkMxbkp3KzVWWk9xRHh4S2JtMG9PZDVIdDZaTTlpSUxFT211Si9zdWpzbHI1CnpF bEpySlg2Lzluekg5STRUaW9PbTYzNll6SUxVYWdRYVNBakNBMTl5N1gzQWNXNWJKbHRLV1JldFg0 c3ZMNW4KRXZIMzhXSE05dnRLNFp5SWZsN1R3eVZYRzg3Skgwck1EYitDSGxHaUdCUkdhWEVuSWdI dkhXVEpsK3RuMS9KQwpIRkpRM1Qzbk9wNjIwTWs3TFM5NlhCZFdWVFBWblNuNXRzUlUvVi84eTE3 Vkh6QStSNGtIdVo5UCtMYko5Tm43CkpwbE92VG5QOGh3QWNqcDVsV1JkOWRBMUg1dk5POG9aSWZ1 Z0JtT1o1aUlmUVNHdWNiZU5nQTlvS2Ivc280bzAKREVQc1JpM0ZIMzFaSDl1bXRuRGozeVRSUzIz TGdvU3J1UUVOQkZSNXRiZ0JDQURGUnJ5Mkk5RVkvWWVyNGdPZwpzY2NucXFNMW1aVDM3Z1d4N09N ZTluVDFYcFJKbWNlbnBwRm9sN1VqYUY4Z3IxZFhpMlRYSGE0d0tGVjNxUy8wCmhXNSs2dVBWcGkv cmcwZ2FiUlBLRWV4V2R3WnhkU2g0a1ArUXBBS09NU2JGVjdERUdNS2ZlS2RtOEo2UWdPZmsKNno4 OEdrbDBWdmFjTG5uVW5CQXdHL0hKOHphbjJZK0ttM1RjK1VXVS8yUnMxNUJHMDdVOEJiSW9UUExL TnpoVAp3TEYwVUx5d28zQUtiOThyVEs5TmVJRkxJTHZkQ3cyZlRIcFBldDU2bTN3MzNXTkt5ZklB RU9VZWNkalM3aFBFCndkWHVydkhTYTZCS25CWDRBck85dUxyelFEU0lIN1p0Q3NyQU1samF4K3BO TU9Vb2diSlNEanZrRzlaSXJSTTYKVXZPakFCRUJBQUdKQTBRRUdBRUtBQThGQWxSNXRiZ0NHd0lG Q1FIaE00QUJLUWtRcGExMzVvYUhYTm5BWFNBRQpHUUVLQUFZRkFsUjV0YmdBQ2drUWdsejdURWI1 cWp5QmNBZitPSEs3b2Z1YjZkakwxaVhDWkY3QWF6ZEdKSkRwCnM0cjFzS2V1aWR4OEFXcG51V2l0 N2RWK2lEUzIvWFBkVjh6b0IvMUVkWjBRVnNsWlREaWJzUFNYNDRIZElYZ0MKZFVuc3IxV0pFa25Y ZnV2ZkdtZ1dwZjZoa1FsekI0eGp3eFlvYllZdGVFK3hnZ2NQR1FkeFcvSjZ5MURnWU9uYwpnS0JG RXVmSVJ2Y1FKZ0g3bGszRWx6L1gwM0U0blJCckdzMzFDZlhZbVhJNmRoS3RoTnFKZ3FpK0V6dThp MTZYCkwwWktLTmFpOWZjbW93WHE2LzBqeHZvbTdoUWFvUk94T3E4NFFJVDl1a0pmT0N5WGI5LzNW RGtKeFVReVZNWU4KUWJleUFOZ0p3Wm54WWZBSDl4RWpPRjJ2YjlNRjFEWU11alFDVGpYcjhHODZ0 TUo0ZmJPdDdKMCtyS3c1RC93Tgp1aGtDeXptZWdKWEt1d3R3bTJRNUJnMFlBczBUWFBIRmtqakFJ STEzd2NRNFdNMjlwTmpMSFZyeEM5NjlmaXJnCldPR0ZWZWVySFk0d3VLOStnR09iamVPc3BheXBI UEllK3YrRFM4bktpaFJ2ZU1Qd0RxZ1l2THBKQ3g4YVpORXcKWXZSNVVqY3dPTnQxalpmMDAyQUow MW5JTkhrd2JEdGJKTVN2TXVZVERiaW5nUFpjWmNRN0c2RlBLU0sxNGs3bQpCdVBNM2VrSUc4YmN5 Y1ZGN0RHQ1BJQWVscXRLVkFiNDRkSEp3MjhCa2Y1VW1CRkJTd1NqOEpMR2xTQUFYU0puCkRxVHAx S1BDbGZmZFR2Q1JzcVlTZElMNnFKdGk1Q0tnaFN6SXJFcnJidkVtaEczcFVETzIvVlJUSU9iS1Rs NlAKMEdUYjJRYXNIbTRRZ2FiNk16aDJ4VEE1NzNHazVpRVA1T3AzOEFveWJLeVpkRGdMWDdLKzdW aG9Qc3RSVjhzUwp1bHorUlJ3QVB3MTREM2xjaVQvS09ZWlBsRFRvWDZ4VFVmZ0VkcVhWZzJ0ZHln YyszMTRYRi9UT2NjTkVxdUsvCmN5SjF0ZjZPYkxVNXFFbkluK0R1Y0NRTnBGUS9BVmhNaGdDdjZw c2lrME11ZTBZVURueWNyYXVmbzFlUkkwbVgKRXpTeWIyQkJWZXMySjR4QmxmTnJ3bzEwM1lnNlAr UEFpUjBxMzhFUjlTeFNnYzJ2cjZQSm1rQTJqUDU3blhDagpSeHY5a3JybTQ4SmJMT0xraW5DaDE3 aUQ5WEQ4bzZCNDBFbG1ZcjNhODNaQXRaa0d1ays3N1FjdTQ2VVdXeXAxCkwwQVBIMmlqd1Rra2xL ZkFDcEJqcW00MFRFWXk1SytQUWJyeWptdDZBYmtCRFFSVWViWmdBUWdBekZSa2FCRFoKOHg4ak5O bXpFdjc5bFVPYWpOajZ4cVp2NnhYTjlMdThNcGw1akQ2RUZvQkNGbnNVdE1HaW45VkxmdDc1dzUr NgphVk5Gd1lNaEE0QVM0VVNhYlJIYUc4cGNFUWRiV0xuQVpuV3gwN2t0aFpPeTZYTzdTdlNUS214 MzZUMGpYUjFLCmNaY2N0eXdUNmo4cGtkVlFqTnA1OTRma0hoTnNPdGhTSDN2WHE0MEtaUXFEeU54 elM0eVJLaUdFOE56Ny9JUHMKWWtiNG83eHc0eGl1RkhzZHdaVnVzZjNWN2REZ1hLZ0dMTGZDc2dL Y2JJNDYwYVRJTDVLVVpXd29QVmxJTXNuWQoyN04za2VDSVR1cWI5QXBaR2lUT3hVaEhveS9pK2pJ d1BZOFBhdXVQZDZyWmNCbnFhakgxeHBVZ3NRdVdZMjhmCjI3TXlWZytSTkJoSTZRQVJBUUFCaVFJ bEJCZ0JDZ0FQQlFKVWViWmdBaHNNQlFrQjRUT0FBQW9KRUtXdGQrYUcKaDF6WklzUVArd1ZnblFo WUZ4S21ycUhHUEFIczR6YVBrLzJOOEp5UXJjSWhGNVlwMmJ3N0loVmxpTDgrWC9CVApBTjlwRU5N RnRvcnZxeVBmaGIxTUphQXVLMzVmMDlSUDZWbGtxcVZRK2ptcDlyLzNyL25BcUhmb0ZWS1lEaW1S CkFGZEVMWStURlpVeDBHejBMQkVlUW9YUFpCelNSUmtIVWJ3UlpCQmhsLzY4ZFVaMjZxS29kS2dV UVNiQmxVcHkKK2F2TXh5WVZnQ0VVL1RWOFBqNUN4WDZGV0d4V0I4b2t6cFQ1T3VDQWx0WHBhTjJw R0xNdzZwd0xsM0kxS2lVVwpjQytFdHpQMlZjRGlQeTZXNGlJMElRa3ZsUWgvYm96eW5PWmNHZDRY RzJiSm91YXZNU0l1QThBT1R1STBkSGw1CisrQitNWm1ib2liZUhDdEMzMjNENDljZEtHR3FoWTFZ Uk9DMjNwQUJmTmIxTkYrK2NaK2ZhUzZBTUpnSnRiOHYKOUczeG9EUUZaOHRuTFJEZFhMQXEwU2s3 WUJ6eVF2NnhPUlZIMnpnSkw5ZkNzUFBGT21YdFpjUlZoeThLclFtVwptUmd5MC83SWRobzJTTXlV NjdNVktoV295SXZ1cVNTZnNub2VXNmtBVWJDaDFyazYrQjlFdFFEcERUVTJXSENxCndUakFydlI0 NlpXNUdwYnIxbXJHcDVMTlQxM1AxTTZwVHI3VDhGYmw4VDd0MTJLaEt5L1BkVFhsUVFPVnVBK2kK MzFybHQ3aW43SUNUTklCNzMvRDA3aG80WUFkMHd5bFZQcTBTbU14VkxJRWxBcWcrR1g0MmtBdHBa TWIxQjNrNwpLVEszQXc4TUo4d0hTNTdBdXBXa2FGdVk1VWprOVlFeUgyZXVHckJtQk02VGhiaDNY cmNtdVFFTkJGUjV0eHdCCkNBRGZOYzlSK0VEcHo1djNOYW5JcFZpUmltSDdnYzA0YWpSOHQ0K1pq cFVrMXdKNVFhVzRkOUMvR2xzN1E1TnAKV3d6WWQrdWZHMThraThBalFHa0JKVndjeGVPWmRhbWNY a3lCRk9mWjJlWWZ5S2w3RkVjaGVRNUdBRUxMUTNidQpSeTB6TlJtTnlCdkpiM0wrRTYwYjV0ZE5y RTBqRXZXUzZTT041bkc4bjd1WGJtMk4rK3BZaXVHZnk3cCt2bm1sCjVVcy9oMkVGNnJ6d2QyNUZE b0VFYVdnZlJCb0tEV2VKd2pIdEg3YkNhMHBpekY2REtkTmN5RmNCT3FzVmNHU2wKT0JhU1VCU0dC akFENjhGajByWEVsekkzSmxUZ3dCVCs4MDhlcnJ5RWhvNE40NzZrVUR2OWxIV1JveUtLU3lNTgpK SHpXQ29KamNJS2RTUzRzdm5vV0RpWlJBQkVCQUFHSkFpVUVHQUVLQUE4RkFsUjV0eHdDR3lBRkNR SGhNNEFBCkNna1FwYTEzNW9hSFhOazBHZy8vY2ZTWG10blNSVytqZzV3cEpidSthYmcrTTlDNlBZ LzFtdjNuR2dtMFVrakwKaXhBa1hmcUxsKzRzNk1FR3N5RUp2YU8vaFNsQndvNVZvSlN5L01pS0Ra S1g0LzNqRTVsMTBCQXdrL0hXeVlGMApWTXVXWTR3R1N0NzF4U0kvM3MyNUFpLzZPTFNwZ2hUbElB Y2lENEgvTk1WY3E1eDY5MXpyTjlROGw2UFhtN2p1CmxJSnA0ZzV4SWgzY2dYaWJFblVOOXBMTUJP cW9tSWpBTzBwbUF5UVRCWjRlNXlQV0FpQm9nR093aHZTQlZuUncKc3MxNS9ZbkowLzFoWUUrSGZj Rnl4Q3p6d04rR010ZlNZTllqOVE3UlU0OE4weUNoMW1JcUgrTGZKSzB5TkZuMgpzaVJTSVoxT2RW K2xLS0dvVFNQc0dXeXFEcTBlbkxTK1NuLzR0WFZVaks3TGlWSTExbHErYUxCYTJYYUIzYnBoCkxM Tm85ZlBxWlJkUk9YcDIreGpvWWVNTEZVTWZWREJZblYzcjJLaXE2SGZUbXk0SU85VXd0KzcyZzRw NkJqL0kKSUdqc3pmK1k3ZFMyZzNTRTBqZEpBOWphNkFDVkhuZ3JwS3Y2U2RNNmhsOWpUYkltazI3 ZUJYTFVYQzNKNmJNTQpaY1JJOVNnMVJtbGxnVm4zMTM2cG1XcTVHRjc5UVlkcTRHMng2aEZBdVZp azZBSkxsR0k0c3htSHVGNkpWRW9aCjgxUngvTzFkVXU4N29NWHFUN3F5a0hJb3ZLQ01DcHRxeWNY KzJkRDR5OHJrNWpnVkJVbjIwQVZCTTZlQitiZGMKVXlCb0tWUjFJb21CV2g1UkZ4MDUvMnBRd0Rm Y09lL1ZXbW9oSXJsTEZ3Ry9tQmlmc2NaSWNxa3RTclozNTRnPQo9ZmZWZQotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== --001a1135eac287755d050a812a58-- From nobody Thu Dec 18 10:00:44 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3587F1A6EED for ; Thu, 18 Dec 2014 10:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NGDpRrRIm-L2 for ; Thu, 18 Dec 2014 10:00:40 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1846E1A6EEC for ; Thu, 18 Dec 2014 10:00:40 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id x12so2295946wgg.38 for ; Thu, 18 Dec 2014 10:00:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=yAzWcdiUb/x+zNPbOOys1txF96Kf6WwtaWUatKSR52k=; b=KUQpDENix/85Xy+yrnwIYCC2v0dmfGOt7RFXG5/GhDLx/c56BjXezOJ5MPZx0Mr9MW K6beNMredlQPBX7UuUHs0SwUBFaG3o+FYPSzgSbHD3JP0G7gCkPAWBjFEy6OrGqW6odA +DREZzvpUeclzgvJZf2Qn7mIRfT6Uv5A/rKBwyddbxs6leYPWkERyzmTfLN3LiB96tWL THcNbyeUb+MCNvZHbvvso8oPUiy7/VBRe15vfNkuGKco6cA6atM4feKO4AGHcsslU7M/ /19+IjRViP160mYyRCyyCgbbg4SSfBY7km19vsbzkPMB9IzfE1XSleD0UYgnC9EBG6bg eU5w== X-Gm-Message-State: ALoCoQmwTa7QFr8r8KZIXoH5rc4YLB2wDu2O5FIf2MV7l4nWhSHirhjNNMq1KdQRPMIvyNUNzrRe X-Received: by 10.180.205.177 with SMTP id lh17mr7234445wic.75.1418925638625; Thu, 18 Dec 2014 10:00:38 -0800 (PST) Received: from [192.168.178.12] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPSA id wa5sm9799340wjc.8.2014.12.18.10.00.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 10:00:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Teco Boot In-Reply-To: Date: Thu, 18 Dec 2014 19:00:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> To: Henning Rogge X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/T_gaS-XBCetrfmtYB-8DALjhNDE Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 18:00:42 -0000 Clarification questions:=20 Does this proposal block a session where products from Vendor_A and = Vendor_B exchange publicly available and implemented vendor extension? Is it allowed that a product from Vendor_A uses Vendor_C extensions? Teco > Op 18 dec. 2014, om 16:46 heeft Henning Rogge het = volgende geschreven: >=20 > Hi, >=20 > after having some discussion with Stan, I have a compromise that might > replace the Vendor-TLV thing with a simpler concept. >=20 > I suggest we replace the complicated "vendor-extension" TLV with a > single "vendor-id" TLV. >=20 > The vendor-ID TLV can be (optional) put into the Session negotiation > and gives you the "context" of the experimental range for both > messages and TLVs in all later messages. >=20 > This means whenever you plan to use a TLV or message with an ID from > the "experimental range", you put in an ID into the Session > negotiation to tell the other side who you are, so it can check if it > can understand you experimental IDs. >=20 > This makes vendor extensions possible, but it is still limited (you > cannot mix the extensions of two vendors in the same session) and will > hopefully push vendors to the IETF to get IDs from the standard range. >=20 > What do you think? >=20 > Henning Rogge >=20 >=20 > On Tue, Dec 16, 2014 at 4:42 PM, Rick Taylor > wrote: >> All, >>=20 >> In response to the silence concerning Vendor Extensions in DLEP, and >> after much deliberation amongst the authors, we have decided to drop = the >> concept from the protocol. >>=20 >> Regards, >>=20 >> Rick Taylor >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Dec 18 10:05:39 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A631A1B7F for ; Thu, 18 Dec 2014 10:05:37 -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 owirRynY7yhQ for ; Thu, 18 Dec 2014 10:05:35 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1431A1B79 for ; Thu, 18 Dec 2014 10:05:34 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so2361684wgg.0 for ; Thu, 18 Dec 2014 10:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IzLn0w0EJpcCqgjDJ2lpm//Af43ZGQrAu1COMTnPq/E=; b=pHim66PH086/veYu5MVkoZ9IvYxzMv71s5CyquvPBSMor3x12rnJ0/bMiqUCFmNAKA 7OzZdVVv6HWvFBntpSeE+xtGAmltQ867cZuWKEKu7Op+c8hpbogeRHu48SoUL0ZR+gTe lxRZggxTdKc8wOjgN1ra6keYqUqEWCjpVJbSZEwm7G4eZcm+WkvbnvxFUH2teoU+M0cS vBSrD22M1gO5KCmWKTu0EKZ1hcToKH8GnFITLwijxR4ZiPwHVbbMEEh1oh7Y6w02f94H S72Z4sFemDInAEtQaa4kEm0Tz4WKiR6kiQWl7ULcEAlBEAEW5yVmMFD6KHpBOtAn3f8c QwAw== X-Received: by 10.180.36.226 with SMTP id t2mr19723111wij.16.1418925932297; Thu, 18 Dec 2014 10:05:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Thu, 18 Dec 2014 10:05:12 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Thu, 18 Dec 2014 19:05:12 +0100 Message-ID: To: Teco Boot Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ElAhkYAVKVupvXBjbBDlogn8pPs Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 18:05:37 -0000 I think both sides can announce their Vendor-id... and then both sides can decide to a) process the incoming extension TLVs b) ignore the extension TLVs and fall back to standard DLEP c) drop the session My suggestion is mostly about testing an extension and maybe pushing it into the first generation of your products. If you think this extension will be interesting to the IETF, you should come here and write a draft about it. You just announce a "vendor-id" which matches how you use the experimental id range... if you use them as a different vendor defined, you should use their vendor-id. Henning Rogge On Thu, Dec 18, 2014 at 7:00 PM, Teco Boot wrote: > Clarification questions: > Does this proposal block a session where products from Vendor_A and Vendor_B exchange publicly available and implemented vendor extension? > Is it allowed that a product from Vendor_A uses Vendor_C extensions? > > Teco > > >> Op 18 dec. 2014, om 16:46 heeft Henning Rogge het volgende geschreven: >> >> Hi, >> >> after having some discussion with Stan, I have a compromise that might >> replace the Vendor-TLV thing with a simpler concept. >> >> I suggest we replace the complicated "vendor-extension" TLV with a >> single "vendor-id" TLV. >> >> The vendor-ID TLV can be (optional) put into the Session negotiation >> and gives you the "context" of the experimental range for both >> messages and TLVs in all later messages. >> >> This means whenever you plan to use a TLV or message with an ID from >> the "experimental range", you put in an ID into the Session >> negotiation to tell the other side who you are, so it can check if it >> can understand you experimental IDs. >> >> This makes vendor extensions possible, but it is still limited (you >> cannot mix the extensions of two vendors in the same session) and will >> hopefully push vendors to the IETF to get IDs from the standard range. >> >> What do you think? >> >> Henning Rogge >> >> >> On Tue, Dec 16, 2014 at 4:42 PM, Rick Taylor >> wrote: >>> All, >>> >>> In response to the silence concerning Vendor Extensions in DLEP, and >>> after much deliberation amongst the authors, we have decided to drop the >>> concept from the protocol. >>> >>> Regards, >>> >>> Rick Taylor >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From nobody Thu Dec 18 10:25:29 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F237D1A1B80 for ; Thu, 18 Dec 2014 10:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 84Yd2xyBQk1p for ; Thu, 18 Dec 2014 10:25:23 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411211A1B57 for ; Thu, 18 Dec 2014 10:25:22 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so2702775wid.9 for ; Thu, 18 Dec 2014 10:25:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1q7OSbCIvhsjFSq9vgp85ffbZc2YoAtIqaej79e+fM8=; b=NHvXKdoG9meUppgpTDi0nBMcLd31w5t3wJ4kKAq/RjWNkPV24P/bWFP3f29Vr/Z76Z sU0NKwxROhq/5buVlhHas18h1szw1BFyYAhbPqmlGtyBw/467EiF5UdVfpU2a3btdNMs Z38Rkar6meCBmoh4ZaDMZQonKx00WoTYZMD1aSeSX+tJFmYROkKt9WmflBCxsbqMxBfr wZrSn5sqXysAf0dLxFzHS+VtasnvAfgDs8K9Z13V3xL7AMfEbCXtRZGy1MVYytcde9TW bd0YRRLBEIdJsSEdGAdpvfRwP5bJ1Hls7RlwfdLYb5Jjlfru8KjNIWGciSuf+ZyWmPdL ofbg== X-Gm-Message-State: ALoCoQlEM5yjfdCz80rE8+digNVUgLgE1m+1QSb4K7yCvDwDQK/I+0cz8C4s44/iosK8H+EHtJsI X-Received: by 10.180.211.34 with SMTP id mz2mr7589632wic.56.1418927121382; Thu, 18 Dec 2014 10:25:21 -0800 (PST) Received: from [192.168.178.12] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPSA id ei5sm25695078wid.2.2014.12.18.10.25.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 10:25:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Teco Boot In-Reply-To: Date: Thu, 18 Dec 2014 19:25:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48C3CDF0-A369-44A6-B9F8-08B6FAF2D0A1@inf-net.nl> References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> To: Henning Rogge X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/4DntTmHBJy5HYPNc3m8Uzpenkfc Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 18:25:26 -0000 I=E2=80=99m concerned on c)(drop session). Extensions are optional and = b) (ignore) is the logical choice. =20 However, when within a session, some form of extension handshake took = place, invalid messages could be detected (violations on vendor = specified sub-protocol) and yes, a sessions could be dropped. This = doesn=E2=80=99t need to be specified in the core spec. I don=E2=80=99t = like such handshakes either. I=E2=80=99m looking forward to an adjusted 10.24 section. Teco =20 > Op 18 dec. 2014, om 19:05 heeft Henning Rogge het = volgende geschreven: >=20 > I think both sides can announce their Vendor-id... >=20 > and then both sides can decide to > a) process the incoming extension TLVs > b) ignore the extension TLVs and fall back to standard DLEP > c) drop the session >=20 > My suggestion is mostly about testing an extension and maybe pushing > it into the first generation of your products. If you think this > extension will be interesting to the IETF, you should come here and > write a draft about it. >=20 > You just announce a "vendor-id" which matches how you use the > experimental id range... if you use them as a different vendor > defined, you should use their vendor-id. >=20 > Henning Rogge >=20 > On Thu, Dec 18, 2014 at 7:00 PM, Teco Boot wrote: >> Clarification questions: >> Does this proposal block a session where products from Vendor_A and = Vendor_B exchange publicly available and implemented vendor extension? >> Is it allowed that a product from Vendor_A uses Vendor_C extensions? >>=20 >> Teco >>=20 >>=20 >>> Op 18 dec. 2014, om 16:46 heeft Henning Rogge het = volgende geschreven: >>>=20 >>> Hi, >>>=20 >>> after having some discussion with Stan, I have a compromise that = might >>> replace the Vendor-TLV thing with a simpler concept. >>>=20 >>> I suggest we replace the complicated "vendor-extension" TLV with a >>> single "vendor-id" TLV. >>>=20 >>> The vendor-ID TLV can be (optional) put into the Session negotiation >>> and gives you the "context" of the experimental range for both >>> messages and TLVs in all later messages. >>>=20 >>> This means whenever you plan to use a TLV or message with an ID from >>> the "experimental range", you put in an ID into the Session >>> negotiation to tell the other side who you are, so it can check if = it >>> can understand you experimental IDs. >>>=20 >>> This makes vendor extensions possible, but it is still limited (you >>> cannot mix the extensions of two vendors in the same session) and = will >>> hopefully push vendors to the IETF to get IDs from the standard = range. >>>=20 >>> What do you think? >>>=20 >>> Henning Rogge >>>=20 >>>=20 >>> On Tue, Dec 16, 2014 at 4:42 PM, Rick Taylor >>> wrote: >>>> All, >>>>=20 >>>> In response to the silence concerning Vendor Extensions in DLEP, = and >>>> after much deliberation amongst the authors, we have decided to = drop the >>>> concept from the protocol. >>>>=20 >>>> Regards, >>>>=20 >>>> Rick Taylor >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 From nobody Thu Dec 18 11:37:54 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0445B1AC3B7 for ; Thu, 18 Dec 2014 11:37:51 -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 ei-MUykc8dWa for ; Thu, 18 Dec 2014 11:37:49 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B44A1AC3AB for ; Thu, 18 Dec 2014 11:37:49 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so2547322wgg.19 for ; Thu, 18 Dec 2014 11:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=SZ2wdiS1baZZTGtpMKHs27G+j4CILe8Sr3twXIUUb1o=; b=cFqVqKObEVBzZF7HG17veNZ6/kPH7F2VYhR6YpWMORKWpAf+NiWW1plnmaf2CiqUGG eesNri57EyiKdIXUaLyLxFlqzOvh941K4rui/33QOrQm3SGiQuUQdaAVPgI+Oubha1TO Jeq+z3HO7c7ZsJISaLMHDyumAdMNGz0MDuZlCN8LKX7JkZLbMqjw7dnoOKqvtbDGuZXk gVpDzN8jptbOGBuP8G9N+R2SmpvZPNwSG4Z0cRIe9fh5MyNkMWzHS4Ew1Imqk7BABGhI C7ZLqW/D8ka7gNuDchyWDP+7o93WnVtkLNES8fe0hBusNpltcRvGUUJ2T/Jda0m7VxBb x1LQ== X-Received: by 10.180.207.211 with SMTP id ly19mr9411211wic.73.1418931467884; Thu, 18 Dec 2014 11:37:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Thu, 18 Dec 2014 11:37:26 -0800 (PST) In-Reply-To: <48C3CDF0-A369-44A6-B9F8-08B6FAF2D0A1@inf-net.nl> References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <48C3CDF0-A369-44A6-B9F8-08B6FAF2D0A1@inf-net.nl> From: Henning Rogge Date: Thu, 18 Dec 2014 20:37:26 +0100 Message-ID: To: Teco Boot Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/IKBHSCQnrzJdeEATY-LHiObv9Sg Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:37:51 -0000 On Thu, Dec 18, 2014 at 7:25 PM, Teco Boot wrote: > I=E2=80=99m concerned on c)(drop session). Extensions are optional and b)= (ignore) is the logical choice. Drop session might be a configuration thing. If I tell my router "XYZ is mandatory" as a configuration, I expect it to drop the session if something bad happens. Normally you should just ignore the extension TLVs (in my opinion). > However, when within a session, some form of extension handshake took pla= ce, invalid messages could be detected (violations on vendor specified sub-= protocol) and yes, a sessions could be dropped. This doesn=E2=80=99t need t= o be specified in the core spec. I don=E2=80=99t like such handshakes eithe= r. Could be similar to the announcement of used TLVs/Messages... if you see something you don't like, you can either ignore it or you can drop the session. If you don't drop it during session initialization, you have given your "approval" that you will accept the incoming data and not drop the session later because of it. Henning From nobody Thu Dec 18 19:22:57 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B2B1A90F2 for ; Thu, 18 Dec 2014 19:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5LLMbZzpz0QJ for ; Thu, 18 Dec 2014 19:22:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE5B1A8772 for ; Thu, 18 Dec 2014 19:22:54 -0800 (PST) Received: from localhost ([::1]:36163 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y1o9O-0000n1-Sa; Thu, 18 Dec 2014 19:22:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-manet-aodvv2@tools.ietf.org, charliep@computer.org X-Trac-Project: manet Date: Fri, 19 Dec 2014 03:22:46 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/58 Message-ID: <061.66674244bcbb8d93f58696341885fee1@trac.tools.ietf.org> X-Trac-Ticket-ID: 58 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-manet-aodvv2@tools.ietf.org, charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: charliep@computer.org, charles.perkins@earthlink.net, john.dowdell@cassidian.com, sratliff@cisco.com Archived-At: http://mailarchive.ietf.org/arch/msg/manet/QeqWVHFIDqKbC3Dc8-qCS2utqcs Cc: manet@ietf.org Subject: [manet] #58 (aodvv2): Definitions of OrigNode and TargNode (Submitted for Justin Dean) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 03:22:57 -0000 #58: Definitions of OrigNode and TargNode (Submitted for Justin Dean) The definition of Originating Node (!OrigNode) (and !TargNode) are self referencing and incomplete. They should at least reference AODVv2 Router. Also the terms !OrigNode and !TargNode are later used as what seems like addresses in an AODVv2 message. I suggest separating the definition of a node (an AODVv2 Router?) from an address of that node/router (suggest !OrigNodeAddr) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-manet- charliep@computer.org | aodvv2@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG | Keywords: terminology Document | -------------------------+------------------------------------------------- Ticket URL: manet From nobody Thu Dec 18 19:24:43 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5A31A0053 for ; Thu, 18 Dec 2014 19:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mtmDBNk2fhG4 for ; Thu, 18 Dec 2014 19:24:40 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CA11A00FF for ; Thu, 18 Dec 2014 19:24:39 -0800 (PST) Received: from localhost ([::1]:36268 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y1oBD-0007iF-NS; Thu, 18 Dec 2014 19:24:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Fri, 19 Dec 2014 03:24:39 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/59 Message-ID: <061.63893d9c85ffbaa3a8568c816f69579a@trac.tools.ietf.org> X-Trac-Ticket-ID: 59 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/uhBfSWFPtnKxintl6pvpmp2unns Cc: manet@ietf.org Subject: [manet] #59 (aodvv2): Use of the term "invalid" (Submitted for Justin Dean) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 03:24:41 -0000 #59: Use of the term "invalid" (Submitted for Justin Dean) The term "invalid" is used a few times when a more specific reference to the defined term "broken" and/or "expired" should be used. -- -----------------------------------+----------------------------- Reporter: charliep@computer.org | Owner: Charles Perkins Type: enhancement | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Keywords: terminology -----------------------------------+----------------------------- Ticket URL: manet From nobody Thu Dec 18 19:27:39 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6E71A8AEE for ; Thu, 18 Dec 2014 19:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9CtkDmhsb3ZE for ; Thu, 18 Dec 2014 19:27:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6201A0053 for ; Thu, 18 Dec 2014 19:27:35 -0800 (PST) Received: from localhost ([::1]:36401 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y1oE3-00060o-Bz; Thu, 18 Dec 2014 19:27:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Fri, 19 Dec 2014 03:27:35 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/60 Message-ID: <061.722206bae2439674b46415d6706ed5e0@trac.tools.ietf.org> X-Trac-Ticket-ID: 60 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3garVI7nFKXfwkVnjCAxSVBEswc Cc: manet@ietf.org Subject: [manet] #60 (aodvv2): Should OrigNode be included in the message header? (Submitted for Justin Dean) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 03:27:38 -0000 #60: Should OrigNode be included in the message header? (Submitted for Justin Dean) In the "!RteMsg Structure" section the list says that the !OrigNode should be included in the message header, the packet diagram doesn't include this information as it doesn't expand the message header. This would be fine but then the !OrigNode is then included again the address block which is confusing. Later it's described that !OrigNode should indeed be included in the address block but it happens after the diagram. Also, is there a reason the !OrigNode is included twice? -- -----------------------------------+--------------------------------- Reporter: charliep@computer.org | Owner: Charles Perkins Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Keywords: OrigNode data field -----------------------------------+--------------------------------- Ticket URL: manet From nobody Thu Dec 18 19:29:14 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F7E1A004C for ; Thu, 18 Dec 2014 19:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qu86ebsPwWEU for ; Thu, 18 Dec 2014 19:29:12 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719F81A006F for ; Thu, 18 Dec 2014 19:29:12 -0800 (PST) Received: from localhost ([::1]:36453 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y1oFc-0003um-6f; Thu, 18 Dec 2014 19:29:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Fri, 19 Dec 2014 03:29:12 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/61 Message-ID: <061.3640038b6f50299e699682a26ff45c54@trac.tools.ietf.org> X-Trac-Ticket-ID: 61 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xJcIg8lwePrxYoOeD4gVrjnKKkA Cc: manet@ietf.org Subject: [manet] #61 (aodvv2): Difference between "broken" and "expired" (Submitted for Justin Dean) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 03:29:14 -0000 #61: Difference between "broken" and "expired" (Submitted for Justin Dean) It's not clear to me the difference between the states "broken" and "expired" (other than how they reached that state) They are both invalid states and regardless of how the state was obtained the routes shouldn't be used. The only difference I could find is that "expired" routes MAY be expunged while there is no such text regarding "broken" routes. Broken is also used in reference to broken link and later !BrokenRoute without the terms being defined in the document definitions. It may make sense to unify these states regardless of how they are obtained into a single term and reduce the number of states a route can have (unless there is something operationally different that should be done that I'm missing) -- -----------------------------------+----------------------------- Reporter: charliep@computer.org | Owner: Charles Perkins Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Keywords: broken, expired -----------------------------------+----------------------------- Ticket URL: manet From nobody Thu Dec 18 19:31:26 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0811D1A9150 for ; Thu, 18 Dec 2014 19:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mI3n52fUExn5 for ; Thu, 18 Dec 2014 19:31:16 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE711A914E for ; Thu, 18 Dec 2014 19:31:15 -0800 (PST) Received: from localhost ([::1]:36562 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y1oHb-0004w2-L6; Thu, 18 Dec 2014 19:31:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Fri, 19 Dec 2014 03:31:15 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/62 Message-ID: <061.36cb0a118e2c05855eab02054f3200ff@trac.tools.ietf.org> X-Trac-Ticket-ID: 62 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Pztxg4AKd669cU1DHP6MgjdibOk Cc: manet@ietf.org Subject: [manet] #62 (aodvv2): Inconsistency surrounding the "timed" state (Submitted for Justin Dean) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 03:31:18 -0000 #62: Inconsistency surrounding the "timed" state (Submitted for Justin Dean) The addition of the "timed" state requires updating in a few other places in the document when route state is referenced. The "Route Table Entry Timeouts" section for example may need to be updated. -- -----------------------------------+----------------------------- Reporter: charliep@computer.org | Owner: Charles Perkins Type: enhancement | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Keywords: timed route -----------------------------------+----------------------------- Ticket URL: manet From nobody Fri Dec 19 02:26:47 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1E81A1B88 for ; Fri, 19 Dec 2014 02:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 sWYmSAI5XRrI for ; Fri, 19 Dec 2014 02:26:41 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A611A86FC for ; Fri, 19 Dec 2014 02:26:39 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 19 Dec 2014 11:26:36 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 19 Dec 2014 11:26:36 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Dec 2014 11:26:35 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Dec 2014 11:26:35 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0387.000; Fri, 19 Dec 2014 10:26:34 +0000 From: "Taylor, Rick" To: Henning Rogge Thread-Topic: [manet] DLEP Vendor Extensions negotiation Thread-Index: AdAbdRlyEG1EsDqcSAaR30uGBxIQKw== Date: Fri, 19 Dec 2014 10:26:33 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.22.128] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2014 10:26:35.0769 (UTC) FILETIME=[442DD690:01D01B76] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-7.500.1017-21186.006 X-TM-AS-Result: No--7.900700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Archived-At: http://mailarchive.ietf.org/arch/msg/manet/2IYZ1k9s5sIlQgKVJ3OqD2pHl9s Cc: manet IETF Subject: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 10:26:43 -0000 SGVubmluZywgQWxsLA0KDQpJIGhhdmUgYmVlbiB0cnlpbmcgdG8gY2F0Y2ggdXAgb24gdGhpcyBk aXNjdXNzaW9uIGhhdmluZyBiZWVuIG91dCBvZiB0aGUgb2ZmaWNlIGZvciB0aGUgbGFzdCB0d28g ZGF5cy4gIENhbiBJIHN1bW1hcmlzZSB3aGF0IEkgdGhpbmsgeW91IGFyZSBwcm9wb3NpbmcgZm9y IFZlbmRvciBFeHRlbnNpb25zLCBhbmQgYXNrIGZvciBzb21lIGZlZWRiYWNrPw0KDQpZb3UgcHJv cG9zZSB0aGF0IERMRVAgcGVlcnMgTUFZIGltcGxlbWVudCBtZXRyaWMgc2V0cyBvdXRzaWRlIG9m IHRoZSBjb3JlIERMRVAgc3BlY2lmaWNhdGlvbiwgYW5kIGFkdmVydGlzZSB0aGUgZmFjdCBieSBw bGFjaW5nIGEgVmVuZG9yX0V4dGVuc2lvbiBEYXRhIEl0ZW0gaW4gdGhlIHNlc3Npb24gaW5pdGlh bGl6YXRpb24gc2lnbmFscyAoUGVlcl9Jbml0L1BlZXJfSW5pdF9BY2spLiAgSWdub3JpbmcgdGhl IGRldGFpbHMgb2YgZW5jb2RpbmcsIHRoZSBWZW5kb3IgRXh0ZW5zaW9uICBEYXRhIEl0ZW0gdW5p cXVlbHkgaWRlbnRpZmllcyBhbiAnZXh0ZW5zaW9uJywgd2hpY2ggaXMgYSBzZXQgb2YgbWV0cmlj cyAoZGVmaW5lZCBlbHNld2hlcmUpIHVzaW5nIHNvbWUgVExWIHR5cGUgY29kZXMgZnJvbSB0aGUg ZXhwZXJpbWVudGFsIHJhbmdlLiAgRWl0aGVyIFBlZXIgbWF5IHJlamVjdCB0aGUgcHJlc2VuY2Ug b2YgYSAgVmVuZG9yIEV4dGVuc2lvbiBEYXRhIEl0ZW0gdGhyb3VnaCB0aGUgbWVjaGFuaXNtcyBh bHJlYWR5IGRlZmluZWQgaW4gRExFUC0wNyBmb3IgT3B0aW9uYWwgU2lnbmFsL0RhdGEgSXRlbXMg c3VwcG9ydGVkLg0KDQpJbiBwcmluY2lwbGUgSSBsaWtlIHRoaXMgcHJvcG9zYWwsIGl0IHRpZXMg aW4gd2VsbCB3aXRoIHNvbWUgb2YgdGhlIGlkZWFzIEkgaGF2ZSBiZWVuIHB1c2hpbmcgYXJvdW5k LCBhbmQgSSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHM6DQoNCjEpIFRoZSBWZW5kb3IgRXh0 ZW5zaW9uIFRMViBjYW4gZm9sbG93IHRoZSBzYW1lIGZvcm1hdCBhcyB0aGUgZXhpc3RpbmcgZHJh ZnQtMDcgVmVuZG9yIEV4dGVuc2lvbiBUTFYsIGkuZS4gVXNlIGFuIElFRUUgT1VJIGFzIHlvdSBt ZW50aW9uZWQsIGJ1dCB3aXRob3V0IHRoZSBzdWItdHlwZSBhbmQgcGF5bG9hZC4NCg0KMikgVGhl cmUgYXJlIHZlcnkgZmV3IGV4cGVyaW1lbnRhbCBUTFYgdmFsdWVzIHJlc2VydmVkLiAgSSB3b25k ZXIgd2hldGhlciBhIHNlcGFyYXRlIGJhbmsgb2YgVExWIHR5cGUgY29kZXMgZm9yIHZlbmRvciBl eHRlbnNpb25zIHNob3VsZCBiZSByZXNlcnZlZCBhbmQgdGhlIFZlbmRvciBFeHRlbnNpb24gZGF0 YSBpdGVtIGRlY2xhcmUgaG93IG1hbnkgZnJvbSB0aGF0IGJhbmsgaXQgdXNlcywgZS5nLiAoaW4g SlNPTikgICJ2ZW5kb3JfZXh0ZW5zaW9uIiA6IHsgIk9VSSIgOiAiMTE6MjI6MzMiLCAiU3RhcnQt dHlwZSIgOiAxMjgsICJUeXBlLWNvdW50IiA6IDUgfS4gIE9yLCBkbyB3ZSBzcGxpdCBUTFYgdHlw ZXMgaW50byBhIHR1cGxlIG9mIHtUeXBlLFN1Yi10eXBlfSBhbmQgdXNlIFR5cGUgMCBmb3IgY29y ZSBETEVQIGFuZCBhbGxvdyB2ZW5kb3IgZXh0ZW5zaW9ucyB0byBncmFiIGEgd2hvbGUgVHlwZSBm b3IgdGhlbXNlbHZlcz8gIChJIGtub3cgU3RhbiBoYXRlcyBUeXBlL1N1Yi10eXBlcyBhcyB0aGV5 IGNhbiBiZSBzZWVuIGFzIG92ZXItZW5naW5lZXJpbmcuKQ0KDQozKSBIb3cgZG9lcyB0aGlzIHdv cmsgd2l0aCB0aGUgT3B0aW9uYWwgRGF0YSBJdGVtcyBzdXBwb3J0ZWQgVExWPyAgQXJlIHRoZXNl IHR3byBkaWZmZXJlbnQgYXBwcm9hY2hlcyB0byBzb2x2ZSB0aGUgc2FtZSBwcm9ibGVtPyBPciBp cyB0aGUgT0RJUyBUTFYgdXNlZCB0byBzcGVjaWZ5IHdoaWNoIHBhcnRzIG9mIHRoZSBWZW5kb3Ig RXh0ZW5zaW9uIGlzIHN1cHBvcnRlZCwgb3IgaXMgdGhpcyBtYWRuZXNzPw0KDQo0KSBIb3cgZG9l cyBhIERMRVAgcGVlciBhZHZlcnRpc2Ugc3VwcG9ydCBmb3IgbXVsdGlwbGUgZXh0ZW5zaW9ucz8g IFRoZXNlIG1pZ2h0IG5vdCBiZSAndmVuZG9yJyBleHRlbnNpb25zLCBidXQgcGVyaGFwcyBhIHRl Y2hub2xvZ3kgc3BlY2lmaWMgZXh0ZW5zaW9uIHN1Y2ggYXMgJ1NhdGNvbScgb3IgJ0xURScuDQoN CkkgbGlrZSB5b3VyIHByb3Bvc2FsLCB3aGljaCBJIHN1bW1hcmlzZSBhczogIlVzZSBhIFRMViBh dCBzZXNzaW9uIGluaXRpYWxpemF0aW9uIHRvIG5lZ290aWF0ZSB0aGUgdXNlIG9mIGEgcHJvZmls ZSBvZiBleHRyYSBtZXRyaWNzIi4gIEkganVzdCBoYXZlIHNvbWUgcXVlc3Rpb25zIG92ZXIgaG93 IHRvIGRvIGl0Lg0KDQpSZWdhcmRzLA0KDQpSaWNrDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IHdpdGhpbiB0aGlzIGUtbWFpbCBhbmQgYW55IGZpbGVzIGF0dGFjaGVkIHRvIHRoaXMgZS1tYWls IGlzIHByaXZhdGUgYW5kIGluIGFkZGl0aW9uIG1heSBpbmNsdWRlIGNvbW1lcmNpYWxseSBzZW5z aXRpdmUgaW5mb3JtYXRpb24uIFRoZSBjb250ZW50cyBvZiB0aGlzIGUtbWFpbCBhcmUgZm9yIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgb25seSBhbmQgdGhlcmVmb3JlIGlmIHlvdSB3aXNoIHRvIGRp c2Nsb3NlIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgd2l0aGluIHRoaXMgZS1tYWlsIG9yIGF0 dGFjaGVkIGZpbGVzLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIHByaW9yIHRvIGFueSBzdWNo IGRpc2Nsb3N1cmUuDQoNCklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBpcyBwcm9oaWJpdGVkLiBQbGVh c2UgYWxzbyBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGluZm9ybSB0aGVtIG9mIHRoZSBlcnJvciBh bmQgZGVsZXRlIHRoZSBlLW1haWwsIGluY2x1ZGluZyBhbnkgYXR0YWNoZWQgZmlsZXMgZnJvbSB5 b3VyIHN5c3RlbS4NCg0KRW1haWxzIHRvIEFpcmJ1cyBEUyBMaW1pdGVkIG1heSBiZSBwcm9jZXNz ZWQsIHJlY29yZGVkIGFuZCBtb25pdG9yZWQgYW55d2hlcmUgaW4gdGhlIEV1cm9wZWFuIENvbW11 bml0eS4NCg0KDQpBaXJidXMgRFMgTGltaXRlZA0KDQpSZWdpc3RlcmVkIE9mZmljZTogUXVhZHJh bnQgSG91c2UsIENlbHRpYyBTcHJpbmdzLCBDb2Vka2VybmV3LCBOZXdwb3J0ICwgTlAxMCA4Rlou DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzIHVuZGVyIGNvbXBhbnkgbnVtYmVyIDA0 MTkxMDM2DQo= From nobody Fri Dec 19 02:51:36 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784541A8A0E for ; Fri, 19 Dec 2014 02:51:31 -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 hwbN6288IA9i for ; Fri, 19 Dec 2014 02:51:29 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3511A882F for ; Fri, 19 Dec 2014 02:51:29 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so1295825wid.17 for ; Fri, 19 Dec 2014 02:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=WjEqz75S9hhqBQbMCCLahd1wH+YiYkdmRtGJvuFHPBc=; b=vM34HFbl1nsh3Oc//ZaiKrN64A1dKVjjZb1zm1MxPHtFeUjZgDo1iKfYRi9U2TAbWS Sv61Rxvw+0sl8TBRIMY2hrXux22JMu0QNWbRoc7dl8/ge0iLl7HApet52r3A8iNnCw3E xOCX2Oh4LC9IsUOIWEydA0pPaRfihX0Wgefu7qL8yqWHmk9JK0jgsH97WIPiGIfYw62w GKTQZSPUcJdPfMpxMp+sQjgXi6bbjkb44E1d3ywwfrMSv2C0ZgfiKeM7SW+SNnZS4Af9 5TVnohZvLc4r9rYlpjJBVqJZs9wO6pwFPhX5f/CDHAPVX5w35ZWBjhlOfOU9yctJIAfQ DamQ== X-Received: by 10.194.2.75 with SMTP id 11mr13932561wjs.78.1418986288226; Fri, 19 Dec 2014 02:51:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Fri, 19 Dec 2014 02:51:07 -0800 (PST) In-Reply-To: References: From: Henning Rogge Date: Fri, 19 Dec 2014 11:51:07 +0100 Message-ID: To: "Taylor, Rick" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/83Oo8vxUILm3kdNmHGH6Tv2YNJE Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 10:51:31 -0000 On Fri, Dec 19, 2014 at 11:26 AM, Taylor, Rick wrote: > Henning, All, > > I have been trying to catch up on this discussion having been out of the = office for the last two days. Can I summarise what I think you are proposi= ng for Vendor Extensions, and ask for some feedback? I think this email is a proof that you can ask... ;) > You propose that DLEP peers MAY implement metric sets outside of the core= DLEP specification, and advertise the fact by placing a Vendor_Extension D= ata Item in the session initialization signals (Peer_Init/Peer_Init_Ack). = Ignoring the details of encoding, the Vendor Extension Data Item uniquely = identifies an 'extension', which is a set of metrics (defined elsewhere) us= ing some TLV type codes from the experimental range. Either Peer may rejec= t the presence of a Vendor Extension Data Item through the mechanisms alre= ady defined in DLEP-07 for Optional Signal/Data Items supported. > > In principle I like this proposal, it ties in well with some of the ideas= I have been pushing around, and I have the following comments: > > 1) The Vendor Extension TLV can follow the same format as the existing dr= aft-07 Vendor Extension TLV, i.e. Use an IEEE OUI as you mentioned, but wit= hout the sub-type and payload. I would go for a full MAC address instead of just the OUI... because it allows to get a well-defined and unique identifier even for organizations and persons who don't own a MAC block (e.g. universities). You just put the MAC address of a device you own into the Vendor-ID. > 2) There are very few experimental TLV values reserved. I wonder whether= a separate bank of TLV type codes for vendor extensions should be reserved= and the Vendor Extension data item declare how many from that bank it uses= , e.g. (in JSON) "vendor_extension" : { "OUI" : "11:22:33", "Start-type" := 128, "Type-count" : 5 }. Or, do we split TLV types into a tuple of {Type,= Sub-type} and use Type 0 for core DLEP and allow vendor extensions to grab = a whole Type for themselves? (I know Stan hates Type/Sub-types as they can= be seen as over-engineering.) Maybe we can add a few more IDs for experimental usage? If we allocate the TLV and message-IDs 224-255 for experimental usage, a vendor has 32 messages and 32 TLVs for his extension. Would you say that is enough? > 3) How does this work with the Optional Data Items supported TLV? Are th= ese two different approaches to solve the same problem? Or is the ODIS TLV = used to specify which parts of the Vendor Extension is supported, or is thi= s madness? I think we can just use the normal rules we already defined for optional data items. Of course an implementation which plans to accept and process the experimental ID range should also check if Vendor-ID TLV content. > 4) How does a DLEP peer advertise support for multiple extensions? These= might not be 'vendor' extensions, but perhaps a technology specific extens= ion such as 'Satcom' or 'LTE'. I would say that each DLEP implementation "sends" ONE vendor extension... but its parser might understand multiple of them. This way we don't need any negotiation, similar to the TLVs/messages the session participants tell the other side what they transmit and then decide if they keep the session open or not. If a Vendor extension shows to be useful beyond a special radio and might even be used by other vendors, it might be time to come to the IETF and get normal (non-experimental) IANA IDs by writing a DLEP extension draft. Henning Rogge From nobody Fri Dec 19 02:58:47 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2533F1A3BA6 for ; Fri, 19 Dec 2014 02:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nMfiH5ONqA8G for ; Fri, 19 Dec 2014 02:58:41 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D691A212A for ; Fri, 19 Dec 2014 02:58:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,606,1413241200"; d="scan'208";a="508346095" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 19 Dec 2014 10:58:40 +0000 X-IronPort-AV: E=Sophos;i="5.07,606,1413241200"; d="scan'208";a="76349875" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 19 Dec 2014 10:58:39 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.118]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Fri, 19 Dec 2014 10:58:38 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Teco Boot Thread-Topic: [manet] DLEP Vendor Extensions Thread-Index: AdAZRvZGMxZmPNThQGCgATXqm4sJsABkseiAAASx7YAAAClHAAAAs9uAAAKExgAAH8l8QA== Date: Fri, 19 Dec 2014 10:58:38 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <48C3CDF0-A369-44A6-B9F8-08B6FAF2D0A1@inf-net.nl> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/UOfB2Y2y5xseB_vOtwRbRgAQlqg Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 10:58:43 -0000 SGVubmluZzoNCj4gTm9ybWFsbHkgeW91IHNob3VsZCBqdXN0IGlnbm9yZSB0aGUgZXh0ZW5zaW9u IFRMVnMgKGluIG15IG9waW5pb24pLg0KDQpUaGF0J3MgdGhlIGFwcHJvYWNoIHdlJ3ZlIHRha2Vu IGluIG91ciBwcm90b2NvbHMgdXNpbmcgNTQ0NCAod2l0aCBpdHMgb3duIFRMViBzdHJ1Y3R1cmUp IGJ1dCBoYXZlIHRha2VuIGl0IGZ1cnRoZXIgYnkgcmVxdWlyaW5nIGEgcG9zaXRpdmUgVExWIGlu IG9yZGVyIHRvIHVzZSBhbiBhZGRyZXNzICh3aGF0IGluIHRoZSA1NDQ0IGNhc2UgYSBUTFYgaXMg YXNzb2NpYXRlZCB3aXRoLCBidXQgdGhhdCdzIHNwZWNpZmljIHRvIHRoYXQpLg0KDQpBbiBhbHRl cm5hdGl2ZSAod2hpY2ggZGlkbid0IGhhcHBlbiBmb3IgNTQ0NCBhcyB0aGVyZSBuZXZlciB3YXMg YSBjb2hlcmVudCBwcm9wb3NhbCAtIHRob3NlIGNvbmNlbnRyYXRlZCBtb3JlIG9uIGZvcndhcmRp bmcsIHdoaWNoIHR1cm5lZCBvdXQgdG8gYmUgYSBuYXN0eSBjYW4gb3Igd29ybXMsIHJhdGhlciB0 aGFuIHVzZSkgaXMgdG8gZmxhZyBUTFZzLiBPbmUgY2FzZSBJIHNhdyBpbiBhIHByb3RvY29sIEkg bG9va2VkIGF0IHJlY2VudGx5IChJIGRvbid0IHJlY2FsbCB3aGljaCBvbmUgcmlnaHQgbm93KSB1 c2VkIGJpdHMgdG8gY29udHJvbCB3aGF0IHRvIGRvIGlmIHlvdSBkaWRuJ3QgcmVjb2duaXNlIGl0 LiBOb3QgZXhhY3RseSB3aGF0IGl0IGRpZCwgYnV0IGNsb3NlLCB3b3VsZCBiZSB0byBkbyB0cmlh Z2U6IGlmIHlvdSBkb24ndCByZWNvZ25pc2UgdGhpcyBUTFYgdGhlbiAoYSkgaWdub3JlIHRoZSB3 aG9sZSBtZXNzYWdlIGl0IGlzIGluLCAoYikgaWdub3JlIGV2ZXJ5dGhpbmcgaW4gdGhpcyBtZXNz YWdlIGFzc29jaWF0ZWQgd2l0aCB0aGlzIFRMViwgKGMpIGp1c3QgaWdub3JlIHRoaXMgVExWLiBZ b3UgY291bGQgc3BsaXQgKGEpIGJ5IHJlcG9ydCBlcnJvci9kbyBub3QgcmVwb3J0IGVycm9yLg0K DQpJJ20gbm90IHByb3Bvc2luZyBleGFjdGx5IHRoYXQgKGluIHBhcnQgYmVjYXVzZSBJJ20gbm90 IHVwIHRvIGRhdGUgb24gYWxsIHRoZSBkZXRhaWxzKSBidXQgaXQgbWF5IGJlIHdvcnRoIGNvbnNp ZGVyaW5nIHNvbWV0aGluZyBsaWtlIHRoaXMuIChDb3VsZCBvZiBjb3Vyc2UganVzdCBiZSB0d28g b3B0aW9ucyAtIGNhcnJ5IG9uL2Rvbid0IGNhcnJ5IG9uLikNCg0KKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKVGhpcyBl bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVk CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5k IG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqCg== From nobody Fri Dec 19 03:00:32 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09DD1A3BA6 for ; Fri, 19 Dec 2014 03:00:28 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 2HQiSqPmkYex for ; Fri, 19 Dec 2014 03:00:21 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4E71A8F4C for ; Fri, 19 Dec 2014 03:00:18 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 19 Dec 2014 12:00:10 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 19 Dec 2014 12:00:08 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Dec 2014 12:00:08 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Dec 2014 12:00:08 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0387.000; Fri, 19 Dec 2014 11:00:07 +0000 From: "Taylor, Rick" To: Henning Rogge Thread-Topic: [manet] DLEP Vendor Extensions negotiation Thread-Index: AdAbdRlyEG1EsDqcSAaR30uGBxIQKwABJemAAAAhyOA= Date: Fri, 19 Dec 2014 11:00:06 +0000 Message-ID: References: <06077761-e100-43b4-b00c-aa39d93542ff@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <06077761-e100-43b4-b00c-aa39d93542ff@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.22.128] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2014 11:00:08.0342 (UTC) FILETIME=[F3C41B60:01D01B7A] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-7.500.1017-21186.006 X-TM-AS-Result: No--27.804900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Archived-At: http://mailarchive.ietf.org/arch/msg/manet/IwHXU4P99AEfcOHhRXgGElSVyXQ Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 11:00:28 -0000 Q29tbWVudHMgaW5saW5lLi4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogSGVubmluZyBSb2dnZSBbbWFpbHRvOmhyb2dnZUBnbWFpbC5jb21dDQo+IFNlbnQ6IDE5IERl Y2VtYmVyIDIwMTQgMTA6NTENCj4gVG86IFRheWxvciwgUmljaw0KPiBDYzogbWFuZXQgSUVURg0K PiBTdWJqZWN0OiBSZTogW21hbmV0XSBETEVQIFZlbmRvciBFeHRlbnNpb25zIG5lZ290aWF0aW9u DQo+DQo+IE9uIEZyaSwgRGVjIDE5LCAyMDE0IGF0IDExOjI2IEFNLCBUYXlsb3IsIFJpY2sgPFJp Y2suVGF5bG9yQGNhc3NpZGlhbi5jb20+DQo+IHdyb3RlOg0KPiA+IEhlbm5pbmcsIEFsbCwNCj4g Pg0KPiA+IEkgaGF2ZSBiZWVuIHRyeWluZyB0byBjYXRjaCB1cCBvbiB0aGlzIGRpc2N1c3Npb24g aGF2aW5nIGJlZW4gb3V0IG9mIHRoZQ0KPiBvZmZpY2UgZm9yIHRoZSBsYXN0IHR3byBkYXlzLiAg Q2FuIEkgc3VtbWFyaXNlIHdoYXQgSSB0aGluayB5b3UgYXJlIHByb3Bvc2luZw0KPiBmb3IgVmVu ZG9yIEV4dGVuc2lvbnMsIGFuZCBhc2sgZm9yIHNvbWUgZmVlZGJhY2s/DQo+DQo+IEkgdGhpbmsg dGhpcyBlbWFpbCBpcyBhIHByb29mIHRoYXQgeW91IGNhbiBhc2suLi4gOykNCj4NCj4gPiBZb3Ug cHJvcG9zZSB0aGF0IERMRVAgcGVlcnMgTUFZIGltcGxlbWVudCBtZXRyaWMgc2V0cyBvdXRzaWRl IG9mIHRoZQ0KPiBjb3JlIERMRVAgc3BlY2lmaWNhdGlvbiwgYW5kIGFkdmVydGlzZSB0aGUgZmFj dCBieSBwbGFjaW5nIGEgVmVuZG9yX0V4dGVuc2lvbg0KPiBEYXRhIEl0ZW0gaW4gdGhlIHNlc3Np b24gaW5pdGlhbGl6YXRpb24gc2lnbmFscyAoUGVlcl9Jbml0L1BlZXJfSW5pdF9BY2spLg0KPiBJ Z25vcmluZyB0aGUgZGV0YWlscyBvZiBlbmNvZGluZywgdGhlIFZlbmRvciBFeHRlbnNpb24gIERh dGEgSXRlbSB1bmlxdWVseQ0KPiBpZGVudGlmaWVzIGFuICdleHRlbnNpb24nLCB3aGljaCBpcyBh IHNldCBvZiBtZXRyaWNzIChkZWZpbmVkIGVsc2V3aGVyZSkgdXNpbmcNCj4gc29tZSBUTFYgdHlw ZSBjb2RlcyBmcm9tIHRoZSBleHBlcmltZW50YWwgcmFuZ2UuICBFaXRoZXIgUGVlciBtYXkgcmVq ZWN0DQo+IHRoZSBwcmVzZW5jZSBvZiBhICBWZW5kb3IgRXh0ZW5zaW9uIERhdGEgSXRlbSB0aHJv dWdoIHRoZSBtZWNoYW5pc21zDQo+IGFscmVhZHkgZGVmaW5lZCBpbiBETEVQLTA3IGZvciBPcHRp b25hbCBTaWduYWwvRGF0YSBJdGVtcyBzdXBwb3J0ZWQuDQo+ID4NCj4gPiBJbiBwcmluY2lwbGUg SSBsaWtlIHRoaXMgcHJvcG9zYWwsIGl0IHRpZXMgaW4gd2VsbCB3aXRoIHNvbWUgb2YgdGhlIGlk ZWFzIEkgaGF2ZQ0KPiBiZWVuIHB1c2hpbmcgYXJvdW5kLCBhbmQgSSBoYXZlIHRoZSBmb2xsb3dp bmcgY29tbWVudHM6DQo+ID4NCj4gPiAxKSBUaGUgVmVuZG9yIEV4dGVuc2lvbiBUTFYgY2FuIGZv bGxvdyB0aGUgc2FtZSBmb3JtYXQgYXMgdGhlIGV4aXN0aW5nDQo+IGRyYWZ0LTA3IFZlbmRvciBF eHRlbnNpb24gVExWLCBpLmUuIFVzZSBhbiBJRUVFIE9VSSBhcyB5b3UgbWVudGlvbmVkLCBidXQN Cj4gd2l0aG91dCB0aGUgc3ViLXR5cGUgYW5kIHBheWxvYWQuDQo+DQo+IEkgd291bGQgZ28gZm9y IGEgZnVsbCBNQUMgYWRkcmVzcyBpbnN0ZWFkIG9mIGp1c3QgdGhlIE9VSS4uLiBiZWNhdXNlIGl0 IGFsbG93cw0KPiB0byBnZXQgYSB3ZWxsLWRlZmluZWQgYW5kIHVuaXF1ZSBpZGVudGlmaWVyIGV2 ZW4gZm9yIG9yZ2FuaXphdGlvbnMgYW5kDQo+IHBlcnNvbnMgd2hvIGRvbid0IG93biBhIE1BQyBi bG9jayAoZS5nLg0KPiB1bml2ZXJzaXRpZXMpLiBZb3UganVzdCBwdXQgdGhlIE1BQyBhZGRyZXNz IG9mIGEgZGV2aWNlIHlvdSBvd24gaW50byB0aGUNCj4gVmVuZG9yLUlELg0KDQorMSwgc2VlbXMg cmVhc29uYWJsZSwgdmVuZG9ycyBjYW4gYWx3YXlzIHBhZCB3aXRoIDBzLg0KDQo+DQo+ID4gMikg VGhlcmUgYXJlIHZlcnkgZmV3IGV4cGVyaW1lbnRhbCBUTFYgdmFsdWVzIHJlc2VydmVkLiAgSSB3 b25kZXINCj4gPiB3aGV0aGVyIGEgc2VwYXJhdGUgYmFuayBvZiBUTFYgdHlwZSBjb2RlcyBmb3Ig dmVuZG9yIGV4dGVuc2lvbnMgc2hvdWxkDQo+ID4gYmUgcmVzZXJ2ZWQgYW5kIHRoZSBWZW5kb3Ig RXh0ZW5zaW9uIGRhdGEgaXRlbSBkZWNsYXJlIGhvdyBtYW55IGZyb20NCj4gPiB0aGF0IGJhbmsg aXQgdXNlcywgZS5nLiAoaW4gSlNPTikgICJ2ZW5kb3JfZXh0ZW5zaW9uIiA6IHsgIk9VSSIgOg0K PiA+ICIxMToyMjozMyIsICJTdGFydC10eXBlIiA6IDEyOCwgIlR5cGUtY291bnQiIDogNSB9LiAg T3IsIGRvIHdlIHNwbGl0DQo+ID4gVExWIHR5cGVzIGludG8gYSB0dXBsZSBvZiB7VHlwZSxTdWIt dHlwZX0gYW5kIHVzZSBUeXBlIDAgZm9yIGNvcmUgRExFUA0KPiA+IGFuZCBhbGxvdyB2ZW5kb3Ig ZXh0ZW5zaW9ucyB0byBncmFiIGEgd2hvbGUgVHlwZSBmb3IgdGhlbXNlbHZlcz8gIChJDQo+ID4g a25vdyBTdGFuIGhhdGVzIFR5cGUvU3ViLXR5cGVzIGFzIHRoZXkgY2FuIGJlIHNlZW4gYXMNCj4g PiBvdmVyLWVuZ2luZWVyaW5nLikNCj4NCj4gTWF5YmUgd2UgY2FuIGFkZCBhIGZldyBtb3JlIElE cyBmb3IgZXhwZXJpbWVudGFsIHVzYWdlPyBJZiB3ZSBhbGxvY2F0ZSB0aGUNCj4gVExWIGFuZCBt ZXNzYWdlLUlEcyAyMjQtMjU1IGZvciBleHBlcmltZW50YWwgdXNhZ2UsIGEgdmVuZG9yIGhhcw0K PiAzMiBtZXNzYWdlcyBhbmQgMzIgVExWcyBmb3IgaGlzIGV4dGVuc2lvbi4gV291bGQgeW91IHNh eSB0aGF0IGlzIGVub3VnaD8NCg0KSSBoYXZlIGJlZW4gbGVkIHRvIGJlbGlldmUgdGhhdCBJRVNH IGRvbid0IGxpa2UgYmlnIGJsb2NrcyBvZiBleHBlcmltZW50YWwgVExWcyBhcyBpdCBpcyBvcGVu IHRvIGFidXNlLiAgSSB3YXMgdGhpbmtpbmcgdGhhdCBhIG1vcmUgZm9ybWFsIGJsb2NrIHdpdGgg cnVsZXMgZm9yIGl0cyB1c2UgbWlnaHQgaGF2ZSBhIGJldHRlciBjaGFuY2Ugb2YgcGFzc2luZyB0 aGVpciByZXZpZXcuICBDb21tZW50cyBmcm9tIHRob3NlIHdpdGggbW9yZSBleHBlcmllbmNlIHBs ZWFzZT8NCg0KPg0KPiA+IDMpIEhvdyBkb2VzIHRoaXMgd29yayB3aXRoIHRoZSBPcHRpb25hbCBE YXRhIEl0ZW1zIHN1cHBvcnRlZCBUTFY/ICBBcmUNCj4gdGhlc2UgdHdvIGRpZmZlcmVudCBhcHBy b2FjaGVzIHRvIHNvbHZlIHRoZSBzYW1lIHByb2JsZW0/IE9yIGlzIHRoZSBPRElTDQo+IFRMViB1 c2VkIHRvIHNwZWNpZnkgd2hpY2ggcGFydHMgb2YgdGhlIFZlbmRvciBFeHRlbnNpb24gaXMgc3Vw cG9ydGVkLCBvciBpcw0KPiB0aGlzIG1hZG5lc3M/DQo+DQo+IEkgdGhpbmsgd2UgY2FuIGp1c3Qg dXNlIHRoZSBub3JtYWwgcnVsZXMgd2UgYWxyZWFkeSBkZWZpbmVkIGZvciBvcHRpb25hbCBkYXRh DQo+IGl0ZW1zLiBPZiBjb3Vyc2UgYW4gaW1wbGVtZW50YXRpb24gd2hpY2ggcGxhbnMgdG8gYWNj ZXB0IGFuZCBwcm9jZXNzIHRoZQ0KPiBleHBlcmltZW50YWwgSUQgcmFuZ2Ugc2hvdWxkIGFsc28g Y2hlY2sgaWYgVmVuZG9yLUlEIFRMViBjb250ZW50Lg0KDQpPa2F5LCB0aGF0IHNlZW1zIHRvIGtl ZXAgZXZlcnl0aGluZyBjb25zaXN0ZW50Lg0KDQo+DQo+ID4gNCkgSG93IGRvZXMgYSBETEVQIHBl ZXIgYWR2ZXJ0aXNlIHN1cHBvcnQgZm9yIG11bHRpcGxlIGV4dGVuc2lvbnM/ICBUaGVzZQ0KPiBt aWdodCBub3QgYmUgJ3ZlbmRvcicgZXh0ZW5zaW9ucywgYnV0IHBlcmhhcHMgYSB0ZWNobm9sb2d5 IHNwZWNpZmljDQo+IGV4dGVuc2lvbiBzdWNoIGFzICdTYXRjb20nIG9yICdMVEUnLg0KPg0KPiBJ IHdvdWxkIHNheSB0aGF0IGVhY2ggRExFUCBpbXBsZW1lbnRhdGlvbiAic2VuZHMiIE9ORSB2ZW5k b3IgZXh0ZW5zaW9uLi4uDQo+IGJ1dCBpdHMgcGFyc2VyIG1pZ2h0IHVuZGVyc3RhbmQgbXVsdGlw bGUgb2YgdGhlbS4NCj4NCj4gVGhpcyB3YXkgd2UgZG9uJ3QgbmVlZCBhbnkgbmVnb3RpYXRpb24s IHNpbWlsYXIgdG8gdGhlIFRMVnMvbWVzc2FnZXMgdGhlDQo+IHNlc3Npb24gcGFydGljaXBhbnRz IHRlbGwgdGhlIG90aGVyIHNpZGUgd2hhdCB0aGV5IHRyYW5zbWl0IGFuZCB0aGVuIGRlY2lkZSBp Zg0KPiB0aGV5IGtlZXAgdGhlIHNlc3Npb24gb3BlbiBvciBub3QuDQo+DQo+IElmIGEgVmVuZG9y IGV4dGVuc2lvbiBzaG93cyB0byBiZSB1c2VmdWwgYmV5b25kIGEgc3BlY2lhbCByYWRpbyBhbmQg bWlnaHQNCj4gZXZlbiBiZSB1c2VkIGJ5IG90aGVyIHZlbmRvcnMsIGl0IG1pZ2h0IGJlIHRpbWUg dG8gY29tZSB0byB0aGUgSUVURiBhbmQgZ2V0DQo+IG5vcm1hbCAobm9uLWV4cGVyaW1lbnRhbCkg SUFOQSBJRHMgYnkgd3JpdGluZyBhIERMRVAgZXh0ZW5zaW9uIGRyYWZ0Lg0KDQpJc24ndCB0aGF0 IGp1c3QgcHVzaGluZyB0aGUgbmVnb3RpYXRpb24gYmFjayB0byB0aGUgT3B0aW9uYWwgRGF0YSBJ dGVtcyBTdXBwb3J0ZWQgVExWICh3aGljaCBtaWdodCBnZXQgcmVhbGx5IGJpZykuICBJIGltYWdp bmUgdGhhdCBvbmUgZGF5IHRoZXJlIG1pZ2h0IGJlIHNldmVyYWwgSUVURiBzdGFuZGFyZHMgZm9y IERMRVAgbWV0cmljcyBmb3IgZGlmZmVyZW50IGNsYXNzZXMgb2YgbW9kZW0sIGFuZCB0aGVyZSBz dGlsbCBuZWVkcyB0byBiZSBuZWdvdGlhdGlvbi4gIEFyZSBwZW9wbGUgaGFwcHkgdG8ganVzdCBy ZWx5IG9uIE9ESVMgVExWcyBvciBkbyB3ZSB3YW50IHRvIGV4cGxvcmUgdXNpbmcgdGhlIFZlbmRv ciBFeHRlbnNpb24gbWVjaGFuaXNtIGFzIGEga2luZCBvZiBnZW5lcmFsIHB1cnBvc2UgRXh0ZW5z aW9uIG1lY2hhbmlzbT8NCg0KQ2hlZXJzLA0KDQpSaWNrDQpUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIHdpdGhpbiB0aGlzIGUtbWFpbCBhbmQgYW55IGZpbGVzIGF0dGFjaGVkIHRvIHRoaXMgZS1t YWlsIGlzIHByaXZhdGUgYW5kIGluIGFkZGl0aW9uIG1heSBpbmNsdWRlIGNvbW1lcmNpYWxseSBz ZW5zaXRpdmUgaW5mb3JtYXRpb24uIFRoZSBjb250ZW50cyBvZiB0aGlzIGUtbWFpbCBhcmUgZm9y IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb25seSBhbmQgdGhlcmVmb3JlIGlmIHlvdSB3aXNoIHRv IGRpc2Nsb3NlIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgd2l0aGluIHRoaXMgZS1tYWlsIG9y IGF0dGFjaGVkIGZpbGVzLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIHByaW9yIHRvIGFueSBz dWNoIGRpc2Nsb3N1cmUuDQoNCklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBpcyBwcm9oaWJpdGVkLiBQ bGVhc2UgYWxzbyBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGluZm9ybSB0aGVtIG9mIHRoZSBlcnJv ciBhbmQgZGVsZXRlIHRoZSBlLW1haWwsIGluY2x1ZGluZyBhbnkgYXR0YWNoZWQgZmlsZXMgZnJv bSB5b3VyIHN5c3RlbS4NCg0KRW1haWxzIHRvIEFpcmJ1cyBEUyBMaW1pdGVkIG1heSBiZSBwcm9j ZXNzZWQsIHJlY29yZGVkIGFuZCBtb25pdG9yZWQgYW55d2hlcmUgaW4gdGhlIEV1cm9wZWFuIENv bW11bml0eS4NCg0KDQpBaXJidXMgRFMgTGltaXRlZA0KDQpSZWdpc3RlcmVkIE9mZmljZTogUXVh ZHJhbnQgSG91c2UsIENlbHRpYyBTcHJpbmdzLCBDb2Vka2VybmV3LCBOZXdwb3J0ICwgTlAxMCA4 RlouDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzIHVuZGVyIGNvbXBhbnkgbnVtYmVy IDA0MTkxMDM2DQo= From nobody Fri Dec 19 03:03:10 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACAC1A9069 for ; Fri, 19 Dec 2014 03:03:07 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 lGXO39yXVysQ for ; Fri, 19 Dec 2014 03:03:06 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB011A902E for ; Fri, 19 Dec 2014 03:03:04 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 19 Dec 2014 12:03:03 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 19 Dec 2014 12:03:02 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Dec 2014 12:03:01 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Dec 2014 12:03:01 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0387.000; Fri, 19 Dec 2014 11:03:00 +0000 From: "Taylor, Rick" To: "Dearlove, Christopher (UK)" , "Henning Rogge" , Teco Boot Thread-Topic: [manet] DLEP Vendor Extensions Thread-Index: AdAZRvZGNL2Xhsuitk+5aiNN62tcuQBkseiAAASx7YAAAClHAAAAs9uAAAKExgAAH8l8QAAAd+sA Date: Fri, 19 Dec 2014 11:02:59 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <48C3CDF0-A369-44A6-B9F8-08B6FAF2D0A1@inf-net.nl> <8952e178-2e40-4706-b677-eea407f64fdc@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <8952e178-2e40-4706-b677-eea407f64fdc@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.22.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2014 11:03:01.0594 (UTC) FILETIME=[5B0843A0:01D01B7B] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-7.500.1017-21186.006 X-TM-AS-Result: No--21.338300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3Cqch3XREi4l38yHEEXwZHNQJ2I Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 11:03:07 -0000 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Dearlove, > Christopher (UK) > Sent: 19 December 2014 10:59 > To: Henning Rogge; Teco Boot > Cc: manet IETF > Subject: Re: [manet] DLEP Vendor Extensions > > Henning: > > Normally you should just ignore the extension TLVs (in my opinion). We have ignore rules for this in DLEP already, which I'm loathe to change. > > That's the approach we've taken in our protocols using 5444 (with its own= TLV > structure) but have taken it further by requiring a positive TLV in order= to use > an address (what in the 5444 case a TLV is associated with, but that's sp= ecific > to that). > > An alternative (which didn't happen for 5444 as there never was a coheren= t > proposal - those concentrated more on forwarding, which turned out to be = a > nasty can or worms, rather than use) is to flag TLVs. One case I saw in a > protocol I looked at recently (I don't recall which one right now) used b= its to > control what to do if you didn't recognise it. Not exactly what it did, b= ut close, > would be to do triage: if you don't recognise this TLV then (a) ignore th= e > whole message it is in, (b) ignore everything in this message associated = with > this TLV, (c) just ignore this TLV. You could split (a) by report error/d= o not > report error. This sounds a lot like SCTP to me. It works, but it can be viewed as fiddl= y. Personally I like it, I know Stan doesn't. > > I'm not proposing exactly that (in part because I'm not up to date on all= the > details) but it may be worth considering something like this. (Could of c= ourse > just be two options - carry on/don't carry on.) Thanks for the useful input Chris, Rick The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or distribut= ion is prohibited. Please also contact the sender and inform them of the er= ror and delete the e-mail, including any attached files from your system. Emails to Airbus DS Limited may be processed, recorded and monitored anywhe= re in the European Community. Airbus DS Limited Registered Office: Quadrant House, Celtic Springs, Coedkernew, Newport , NP= 10 8FZ. Registered in England and Wales under company number 04191036 From nobody Fri Dec 19 03:07:02 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCD91A9069 for ; Fri, 19 Dec 2014 03:06:59 -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 VmX-SYTxSRsh for ; Fri, 19 Dec 2014 03:06:57 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF81B1A90CA for ; Fri, 19 Dec 2014 03:06:56 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so995472wgg.21 for ; Fri, 19 Dec 2014 03:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=TGY+T3xrpsyq7/Xi/1knzt/SZJYceeoSyxMMNp0k/y0=; b=J7O14Ab74GHXRBFWAoDEjF4oP3CajXOBIOvqMkAL/Izd4OyJvKWhzZL8WJ7ygpWye8 gaC3IG+M355ynbVvL3QzawTcpIZUbSlL3JV6TDaoY9KJB8+kpNu+UqJ3e3kE7lFheFqM QPKmQKj9ZcZ02zbW4y+wVJtJ2dKfYOjN1lMPb0bab3Xzc6NUSQLKFD7pKMTYxwNSit71 B4lDJcXJeFbEF6PT3Q+dVvebfGSEKxZ7qKKHav6oRmhNpOGEoW2bWNKY7F5aCfvozsoo 9Fet9kC4mlkjTtxCeufQhJQH9P5uOLWQOoflCgLMf+GyGMnXEPJtMsyffODg49hL4KS7 xFrg== X-Received: by 10.180.108.167 with SMTP id hl7mr4650876wib.68.1418987215596; Fri, 19 Dec 2014 03:06:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Fri, 19 Dec 2014 03:06:35 -0800 (PST) In-Reply-To: References: <06077761-e100-43b4-b00c-aa39d93542ff@SUCNPTEXC01.COM.AD.UK.DS.CORP> From: Henning Rogge Date: Fri, 19 Dec 2014 12:06:35 +0100 Message-ID: To: "Taylor, Rick" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/61SwzQyqBsbQoZsLNcHkjnTF_iA Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 11:06:59 -0000 >> Maybe we can add a few more IDs for experimental usage? If we allocate t= he >> TLV and message-IDs 224-255 for experimental usage, a vendor has >> 32 messages and 32 TLVs for his extension. Would you say that is enough? > > I have been led to believe that IESG don't like big blocks of experimenta= l TLVs as it is open to abuse. I was thinking that a more formal block wit= h rules for its use might have a better chance of passing their review. Co= mments from those with more experience please? Whats about this? 220 - 251 Vendor-Specific TLVs 252 - 255 Experimental TLVs If we need the range for "vendor-specific" stuff, just call it this way. We could add a line that if you use the Vendor-Specific block, you MUST add the Vendor-ID. And maybe say a bit more about the idea behind the block and the reason why you should go for "IETF RFC" with your extensions if they seem to be useful. > Isn't that just pushing the negotiation back to the Optional Data Items S= upported TLV (which might get really big). I imagine that one day there mi= ght be several IETF standards for DLEP metrics for different classes of mod= em, and there still needs to be negotiation. Are people happy to just rely= on ODIS TLVs or do we want to explore using the Vendor Extension mechanism= as a kind of general purpose Extension mechanism? Not sure you can really call it "negotiation" if both sides announce what they will transmit and then the other side can parse the data (or a subset of it) or just drop the connection. Henning Rogge From nobody Fri Dec 19 03:12:51 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58BF1A8779 for ; Fri, 19 Dec 2014 03:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1BGSfjsEaIuX for ; Fri, 19 Dec 2014 03:12:38 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911741A8869 for ; Fri, 19 Dec 2014 03:12:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,606,1413241200"; d="scan'208";a="508354138" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 19 Dec 2014 11:12:36 +0000 X-IronPort-AV: E=Sophos;i="5.07,606,1413241200"; d="scan'208";a="76352004" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 19 Dec 2014 11:12:36 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.118]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Fri, 19 Dec 2014 11:12:36 +0000 From: "Dearlove, Christopher (UK)" To: "Taylor, Rick" , Henning Rogge , Teco Boot Thread-Topic: [manet] DLEP Vendor Extensions Thread-Index: AdAZRvZGMxZmPNThQGCgATXqm4sJsABkseiAAASx7YAAAClHAAAAs9uAAAKExgAAH8l8QAAAd+sAAAAYTLA= Date: Fri, 19 Dec 2014 11:12:35 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <48C3CDF0-A369-44A6-B9F8-08B6FAF2D0A1@inf-net.nl> <8952e178-2e40-4706-b677-eea407f64fdc@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_w1f36wGa7QqpENfq59eTqahrCM Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 11:12:42 -0000 Rick: > This sounds a lot like SCTP to me. It works, but it can be viewed as fid= dly. Personally I like it, I know Stan doesn't. No, not SCTP. But as I said I don't recall which protocol. What is clear is= that this is a frequently reinvented wheel. (That's a bit unfair, requirem= ents differ.) Not DLEP, but may be of interest, digging into my memory the issue that was= the killer for trying to put something like this into 5444 was the expecta= tion that messages would be forwarded. Then we run into cases such as when = we have A - B - C where A and C support whatever it is that the TLV indicat= es, but B does not. In some cases that's fine, in others it's a killer. Whi= ch would mean trying to manage whether B forwards the message. But what is = forwarding? It could be blind forwarding. It could be something like MPR fo= rwarding. It could be regenerating a new message from that message. We even= tually threw up our hands and gave up, things were taking too long already. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From nobody Fri Dec 19 03:21:41 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E59B1A8AE0 for ; Fri, 19 Dec 2014 03:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RRQGrruvoVcU for ; Fri, 19 Dec 2014 03:21:36 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31A71A6F91 for ; Fri, 19 Dec 2014 03:21:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,606,1413241200"; d="scan'208";a="508359005" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 19 Dec 2014 11:21:34 +0000 X-IronPort-AV: E=Sophos;i="5.07,606,1413241200"; d="scan'208";a="76353451" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 19 Dec 2014 11:21:34 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.118]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Fri, 19 Dec 2014 11:21:33 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "Taylor, Rick" Thread-Topic: [manet] DLEP Vendor Extensions negotiation Thread-Index: AQHQG3sN5qDupLm4z06lmxmoLCcJv5yWwL6AgAAB9aA= Date: Fri, 19 Dec 2014 11:21:33 +0000 Message-ID: References: <06077761-e100-43b4-b00c-aa39d93542ff@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/01H4G72X-omPp3lJ4lX8_bG2GTw Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 11:21:39 -0000 An unimportant nit, I'd start the vendor specific block at 224, it's a roun= der number (D0) if doing it that way. (Our earlier drafts use 224 to 255 fo= r that reason, later on we got limited to 252 to 255.) But that's not a big range (32 or 28) for a vendor specific block if the id= ea is successful. You could instead define a single vendor specific TLV, an= d then require that the first N octets (you suggested 8) of the value indic= ate which vendor. (If it weren't, as Rick indicates, trampling on an alread= y made decision, I'd suggest or than one, maybe two, with the distinction b= eing vendor specific, you can just ignore TLV, and vendor specific, you nee= d to ignore message, for not recognised cases.) -- = Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 19 December 2014 11:07 To: Taylor, Rick Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions negotiation ----------------------! WARNING ! ---------------------- This message origi= nates from outside our organisation, either from an external partner or fro= m the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. -------------------------------------------------------- >> Maybe we can add a few more IDs for experimental usage? If we = >> allocate the TLV and message-IDs 224-255 for experimental usage, a = >> vendor has >> 32 messages and 32 TLVs for his extension. Would you say that is enough? > > I have been led to believe that IESG don't like big blocks of experimenta= l TLVs as it is open to abuse. I was thinking that a more formal block wit= h rules for its use might have a better chance of passing their review. Co= mments from those with more experience please? Whats about this? 220 - 251 Vendor-Specific TLVs 252 - 255 Experimental TLVs If we need the range for "vendor-specific" stuff, just call it this way. We could add a line that if you use the Vendor-Specific block, you MUST add= the Vendor-ID. And maybe say a bit more about the idea behind the block an= d the reason why you should go for "IETF RFC" with your extensions if they = seem to be useful. > Isn't that just pushing the negotiation back to the Optional Data Items S= upported TLV (which might get really big). I imagine that one day there mi= ght be several IETF standards for DLEP metrics for different classes of mod= em, and there still needs to be negotiation. Are people happy to just rely= on ODIS TLVs or do we want to explore using the Vendor Extension mechanism= as a kind of general purpose Extension mechanism? Not sure you can really call it "negotiation" if both sides announce what t= hey will transmit and then the other side can parse the data (or a subset o= f it) or just drop the connection. Henning Rogge _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From nobody Fri Dec 19 03:24:32 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CB91A6F91 for ; Fri, 19 Dec 2014 03:24:30 -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 yk1T64SNsYnR for ; Fri, 19 Dec 2014 03:24:29 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02641A2119 for ; Fri, 19 Dec 2014 03:24:28 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so1546369wib.16 for ; Fri, 19 Dec 2014 03:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/HNt5imJh6KgFhnsBsHFxxImdvsGhAnXDDxST/pCap8=; b=G0T4jHR0BJ094dFhoygfxPLw5WHKEbO9+H7+2Vez+VSyozJbIYu6z8xsQij2Qq2w6I IggUVPtnuAJYQ6BqJrt0SAmCYu7NyTx4uQmLiSYJdYWfGiFvIpaQ++Sp6iwj6jrTufMQ UqLMO/V8+piB68xVDeX+5eXFaV3YQALu/qdHlod7hghELHohxFCQPt5y9seJbVCqteRA RdFb32TLbcIfuZ2EgHzlWx7l3vpKqTiV828I5tJrLey/N3DJW64tiN9ZEsOrr2pagpAU MKze8cVDf1vUV57T/aBU/mwrZwE0SFt0Zd/rzQF8eTssj5Qsl+qsYik3CqT+aC3EIH7W 0Bag== X-Received: by 10.180.21.178 with SMTP id w18mr4767098wie.78.1418988267607; Fri, 19 Dec 2014 03:24:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Fri, 19 Dec 2014 03:24:07 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <48C3CDF0-A369-44A6-B9F8-08B6FAF2D0A1@inf-net.nl> <8952e178-2e40-4706-b677-eea407f64fdc@SUCNPTEXC01.COM.AD.UK.DS.CORP> From: Henning Rogge Date: Fri, 19 Dec 2014 12:24:07 +0100 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/gAL_YHAfeBSvQDF71UHzcPMcBXI Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 11:24:30 -0000 On Fri, Dec 19, 2014 at 12:12 PM, Dearlove, Christopher (UK) wrote: > No, not SCTP. But as I said I don't recall which protocol. What is clear = is that this is a frequently reinvented wheel. (That's a bit unfair, requir= ements differ.) > > Not DLEP, but may be of interest, digging into my memory the issue that w= as the killer for trying to put something like this into 5444 was the expec= tation that messages would be forwarded. Then we run into cases such as whe= n we have A - B - C where A and C support whatever it is that the TLV indic= ates, but B does not. In some cases that's fine, in others it's a killer. W= hich would mean trying to manage whether B forwards the message. But what i= s forwarding? It could be blind forwarding. It could be something like MPR = forwarding. It could be regenerating a new message from that message. We ev= entually threw up our hands and gave up, things were taking too long alread= y. The good thing with DLEP is that its a direct point to point connection between two different partners. If you are the radio you are always talking to a single router... you just announce the radio vendor-extension you transmit (if any at all). You also have to check if you understand the Vendor-extension of the router. If there is a "Radio Vendor extension X" that requires a "Router Vendor extension Y" then you can check the presence of this extension during session buildup. Of course if a Vendor starts to build multiple extensions (and some extensions that are just multiple extensions combined), things get complicated... but I see no problem here, this problems go away when you come to the IETF to standardize new TLVs. Henning Rogge From nobody Fri Dec 19 04:55:23 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751A61A9108 for ; Fri, 19 Dec 2014 04:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 O8TSbNrZwaaI for ; Fri, 19 Dec 2014 04:55:20 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687081A9130 for ; Fri, 19 Dec 2014 04:55:20 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id ft15so1155169pdb.22 for ; Fri, 19 Dec 2014 04:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xf1zv2ZKJmfLTFHXAQkq9XavgoZXEO7bvKtdIDcyFm0=; b=dw9V5LBAY66kvJb1z3+DbGsoNDoVrkdDxvpHhZ9Z5peFS9Q+6MqFHrjERVJXl7RTtq lf3ZNLfGXOYWqatlyThVNgGbG2EJXIpRZPPzABFbq4JeJOp5WJw0zo687NZ9WqiyMkXY nUKaQMkSdbPwPe8jKj5EiR4OTlSVA2YruK7AWY7CxMK8dHiBEQhGlgliXhHlji0LWWB1 Zn9a8XVdwrUX4x0JdeO0aVPY5d3crlobeeeOeCNoTGlCxaRh8/BFnDvKpD29hLrvpOvt VJM0/pD1trl4SNgaFrZvNBYosju8q1K1OpnOzYI4bnD6EtrhnZNxKtH/Osp8/iDA6r1P f11A== MIME-Version: 1.0 X-Received: by 10.66.66.231 with SMTP id i7mr12127167pat.143.1418993719648; Fri, 19 Dec 2014 04:55:19 -0800 (PST) Received: by 10.70.128.70 with HTTP; Fri, 19 Dec 2014 04:55:19 -0800 (PST) Received: by 10.70.128.70 with HTTP; Fri, 19 Dec 2014 04:55:19 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <48C3CDF0-A369-44A6-B9F8-08B6FAF2D0A1@inf-net.nl> <8952e178-2e40-4706-b677-eea407f64fdc@SUCNPTEXC01.COM.AD.UK.DS.CORP> Date: Fri, 19 Dec 2014 07:55:19 -0500 Message-ID: From: Justin Dean To: Henning Rogge Content-Type: multipart/alternative; boundary=001a1134af86992786050a9138ce Archived-At: http://mailarchive.ietf.org/arch/msg/manet/5_td7Nji5KcCbYyCWCSB0RV7JuE Cc: Christopher Dearlove , manet@ietf.org Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 12:55:22 -0000 --001a1134af86992786050a9138ce Content-Type: text/plain; charset=UTF-8 It doesn't forward but there are limitations when only having one approach for dealing with unknown extensions. (Drop connection vs ignore extensions). But as you point out limitations with vendor extentions isn't really a bad thing as it encourages standardization. I like the approach. Justin On Dec 19, 2014 6:24 AM, "Henning Rogge" wrote: > > On Fri, Dec 19, 2014 at 12:12 PM, Dearlove, Christopher (UK) > wrote: > > No, not SCTP. But as I said I don't recall which protocol. What is clear is that this is a frequently reinvented wheel. (That's a bit unfair, requirements differ.) > > > > Not DLEP, but may be of interest, digging into my memory the issue that was the killer for trying to put something like this into 5444 was the expectation that messages would be forwarded. Then we run into cases such as when we have A - B - C where A and C support whatever it is that the TLV indicates, but B does not. In some cases that's fine, in others it's a killer. Which would mean trying to manage whether B forwards the message. But what is forwarding? It could be blind forwarding. It could be something like MPR forwarding. It could be regenerating a new message from that message. We eventually threw up our hands and gave up, things were taking too long already. > > The good thing with DLEP is that its a direct point to point > connection between two different partners. > > If you are the radio you are always talking to a single router... you > just announce the radio vendor-extension you transmit (if any at all). > You also have to check if you understand the Vendor-extension of the > router. > > If there is a "Radio Vendor extension X" that requires a "Router > Vendor extension Y" then you can check the presence of this extension > during session buildup. > > Of course if a Vendor starts to build multiple extensions (and some > extensions that are just multiple extensions combined), things get > complicated... but I see no problem here, this problems go away when > you come to the IETF to standardize new TLVs. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --001a1134af86992786050a9138ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It doesn't forward but there are limitations when only h= aving one approach for dealing with unknown extensions. (Drop connection vs= ignore extensions). But as you point out limitations with vendor extention= s isn't really a bad thing as it encourages standardization. I like the= approach.

Justin

On Dec 19, 2014 6:24 AM, "Henning Rogge" <hrogge@gmail.com> wrote:
>
> On Fri, Dec 19, 2014 at 12:12 PM, Dearlove, Christopher (UK)
> <chris.dearlove@ba= esystems.com> wrote:
> > No, not SCTP. But as I said I don't recall which protocol. Wh= at is clear is that this is a frequently reinvented wheel. (That's a bi= t unfair, requirements differ.)
> >
> > Not DLEP, but may be of interest, digging into my memory the issu= e that was the killer for trying to put something like this into 5444 was t= he expectation that messages would be forwarded. Then we run into cases suc= h as when we have A - B - C where A and C support whatever it is that the T= LV indicates, but B does not. In some cases that's fine, in others it&#= 39;s a killer. Which would mean trying to manage whether B forwards the mes= sage. But what is forwarding? It could be blind forwarding. It could be som= ething like MPR forwarding. It could be regenerating a new message from tha= t message. We eventually threw up our hands and gave up, things were taking= too long already.
>
> The good thing with DLEP is that its a direct point to point
> connection between two different partners.
>
> If you are the radio you are always talking to a single router... you<= br> > just announce the radio vendor-extension you transmit (if any at all).=
> You also have to check if you understand the Vendor-extension of the > router.
>
> If there is a "Radio Vendor extension X" that requires a &qu= ot;Router
> Vendor extension Y" then you can check the presence of this exten= sion
> during session buildup.
>
> Of course if a Vendor starts to build multiple extensions (and some > extensions that are just multiple extensions combined), things get
> complicated... but I see no problem here, this problems go away when > you come to the IETF to standardize new TLVs.
>
> Henning Rogge
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ie= tf.org/mailman/listinfo/manet

--001a1134af86992786050a9138ce-- From nobody Fri Dec 19 06:31:37 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38CC1A00E2 for ; Fri, 19 Dec 2014 06:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 fshLzOqI6wwq for ; Fri, 19 Dec 2014 06:31:31 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B2B1A00D8 for ; Fri, 19 Dec 2014 06:31:24 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 19 Dec 2014 15:31:18 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 19 Dec 2014 15:31:17 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Dec 2014 15:31:17 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Dec 2014 15:31:17 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0387.000; Fri, 19 Dec 2014 14:31:15 +0000 From: "Taylor, Rick" To: Justin Dean , Henning Rogge Thread-Topic: [manet] DLEP Vendor Extensions Thread-Index: AdAZRvZGNL2Xhsuitk+5aiNN62tcuQBkseiAAASx7YAAAClHAAAAs9uAAAKExgAAH8l8QAAAd+sAAAQJUQIAAz2wAA== Date: Fri, 19 Dec 2014 14:31:15 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <48C3CDF0-A369-44A6-B9F8-08B6FAF2D0A1@inf-net.nl> <8952e178-2e40-4706-b677-eea407f64fdc@SUCNPTEXC01.COM.AD.UK.DS.CORP> <7e398a91-2500-4852-b554-27439eeb9709@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <7e398a91-2500-4852-b554-27439eeb9709@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.22.128] Content-Type: multipart/alternative; boundary="_000_B177F831FB91F242972D0C35F6A073314ECE94EDSUCNPTEXM02coma_" MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2014 14:31:17.0270 (UTC) FILETIME=[73091B60:01D01B98] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-7.500.1017-21186.006 X-TM-AS-Result: No--41.043500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Archived-At: http://mailarchive.ietf.org/arch/msg/manet/JCOvK0iNfLLp9ceL3ejnqYKQKcw Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 14:31:33 -0000 --_000_B177F831FB91F242972D0C35F6A073314ECE94EDSUCNPTEXM02coma_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCB0byBjbGFyaWZ5IHRoZSDigJhEcm9wIENvbm5lY3Rpb25z4oCZIHN0YXRlbWVudC4gIERM RVAgYXMgaXQgY3VycmVudGx5IHN0YW5kcyBoYXMgYSBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIHBo YXNlIHdpdGggZ3JhY2VmdWwgcmVmdXNhbCBhcyBwYXJ0IG9mIHRoZSBzZXNzaW9uIGluaXRpYWxp emF0aW9uLiAgVGhlIGRyb3AgY29ubmVjdGlvbiBiZWhhdmlvdXIgaGFwcGVucyBvbmx5IGlmIGFu IGltcGxlbWVudGF0aW9uIHJlbmVnZXMgb24gd2hhdCBoYXMgcHJldmlvdXNseSBiZWVuIG5lZ290 aWF0ZWQuDQoNClJpY2sNCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIERlYW4NClNlbnQ6IDE5IERlY2VtYmVyIDIwMTQgMTI6 NTUNClRvOiBIZW5uaW5nIFJvZ2dlDQpDYzogQ2hyaXN0b3BoZXIgRGVhcmxvdmU7IG1hbmV0QGll dGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSBETEVQIFZlbmRvciBFeHRlbnNpb25zDQoNCg0K SXQgZG9lc24ndCBmb3J3YXJkIGJ1dCB0aGVyZSBhcmUgbGltaXRhdGlvbnMgd2hlbiBvbmx5IGhh dmluZyBvbmUgYXBwcm9hY2ggZm9yIGRlYWxpbmcgd2l0aCB1bmtub3duIGV4dGVuc2lvbnMuIChE cm9wIGNvbm5lY3Rpb24gdnMgaWdub3JlIGV4dGVuc2lvbnMpLiBCdXQgYXMgeW91IHBvaW50IG91 dCBsaW1pdGF0aW9ucyB3aXRoIHZlbmRvciBleHRlbnRpb25zIGlzbid0IHJlYWxseSBhIGJhZCB0 aGluZyBhcyBpdCBlbmNvdXJhZ2VzIHN0YW5kYXJkaXphdGlvbi4gSSBsaWtlIHRoZSBhcHByb2Fj aC4NCg0KSnVzdGluDQoNCk9uIERlYyAxOSwgMjAxNCA2OjI0IEFNLCAiSGVubmluZyBSb2dnZSIg PGhyb2dnZUBnbWFpbC5jb208bWFpbHRvOmhyb2dnZUBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4g T24gRnJpLCBEZWMgMTksIDIwMTQgYXQgMTI6MTIgUE0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAo VUspDQo+IDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToNCj4gPiBObywgbm90IFNDVFAuIEJ1dCBhcyBJIHNh aWQgSSBkb24ndCByZWNhbGwgd2hpY2ggcHJvdG9jb2wuIFdoYXQgaXMgY2xlYXIgaXMgdGhhdCB0 aGlzIGlzIGEgZnJlcXVlbnRseSByZWludmVudGVkIHdoZWVsLiAoVGhhdCdzIGEgYml0IHVuZmFp ciwgcmVxdWlyZW1lbnRzIGRpZmZlci4pDQo+ID4NCj4gPiBOb3QgRExFUCwgYnV0IG1heSBiZSBv ZiBpbnRlcmVzdCwgZGlnZ2luZyBpbnRvIG15IG1lbW9yeSB0aGUgaXNzdWUgdGhhdCB3YXMgdGhl IGtpbGxlciBmb3IgdHJ5aW5nIHRvIHB1dCBzb21ldGhpbmcgbGlrZSB0aGlzIGludG8gNTQ0NCB3 YXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQgbWVzc2FnZXMgd291bGQgYmUgZm9yd2FyZGVkLiBUaGVu IHdlIHJ1biBpbnRvIGNhc2VzIHN1Y2ggYXMgd2hlbiB3ZSBoYXZlIEEgLSBCIC0gQyB3aGVyZSBB IGFuZCBDIHN1cHBvcnQgd2hhdGV2ZXIgaXQgaXMgdGhhdCB0aGUgVExWIGluZGljYXRlcywgYnV0 IEIgZG9lcyBub3QuIEluIHNvbWUgY2FzZXMgdGhhdCdzIGZpbmUsIGluIG90aGVycyBpdCdzIGEg a2lsbGVyLiBXaGljaCB3b3VsZCBtZWFuIHRyeWluZyB0byBtYW5hZ2Ugd2hldGhlciBCIGZvcndh cmRzIHRoZSBtZXNzYWdlLiBCdXQgd2hhdCBpcyBmb3J3YXJkaW5nPyBJdCBjb3VsZCBiZSBibGlu ZCBmb3J3YXJkaW5nLiBJdCBjb3VsZCBiZSBzb21ldGhpbmcgbGlrZSBNUFIgZm9yd2FyZGluZy4g SXQgY291bGQgYmUgcmVnZW5lcmF0aW5nIGEgbmV3IG1lc3NhZ2UgZnJvbSB0aGF0IG1lc3NhZ2Uu IFdlIGV2ZW50dWFsbHkgdGhyZXcgdXAgb3VyIGhhbmRzIGFuZCBnYXZlIHVwLCB0aGluZ3Mgd2Vy ZSB0YWtpbmcgdG9vIGxvbmcgYWxyZWFkeS4NCj4NCj4gVGhlIGdvb2QgdGhpbmcgd2l0aCBETEVQ IGlzIHRoYXQgaXRzIGEgZGlyZWN0IHBvaW50IHRvIHBvaW50DQo+IGNvbm5lY3Rpb24gYmV0d2Vl biB0d28gZGlmZmVyZW50IHBhcnRuZXJzLg0KPg0KPiBJZiB5b3UgYXJlIHRoZSByYWRpbyB5b3Ug YXJlIGFsd2F5cyB0YWxraW5nIHRvIGEgc2luZ2xlIHJvdXRlci4uLiB5b3UNCj4ganVzdCBhbm5v dW5jZSB0aGUgcmFkaW8gdmVuZG9yLWV4dGVuc2lvbiB5b3UgdHJhbnNtaXQgKGlmIGFueSBhdCBh bGwpLg0KPiBZb3UgYWxzbyBoYXZlIHRvIGNoZWNrIGlmIHlvdSB1bmRlcnN0YW5kIHRoZSBWZW5k b3ItZXh0ZW5zaW9uIG9mIHRoZQ0KPiByb3V0ZXIuDQo+DQo+IElmIHRoZXJlIGlzIGEgIlJhZGlv IFZlbmRvciBleHRlbnNpb24gWCIgdGhhdCByZXF1aXJlcyBhICJSb3V0ZXINCj4gVmVuZG9yIGV4 dGVuc2lvbiBZIiB0aGVuIHlvdSBjYW4gY2hlY2sgdGhlIHByZXNlbmNlIG9mIHRoaXMgZXh0ZW5z aW9uDQo+IGR1cmluZyBzZXNzaW9uIGJ1aWxkdXAuDQo+DQo+IE9mIGNvdXJzZSBpZiBhIFZlbmRv ciBzdGFydHMgdG8gYnVpbGQgbXVsdGlwbGUgZXh0ZW5zaW9ucyAoYW5kIHNvbWUNCj4gZXh0ZW5z aW9ucyB0aGF0IGFyZSBqdXN0IG11bHRpcGxlIGV4dGVuc2lvbnMgY29tYmluZWQpLCB0aGluZ3Mg Z2V0DQo+IGNvbXBsaWNhdGVkLi4uIGJ1dCBJIHNlZSBubyBwcm9ibGVtIGhlcmUsIHRoaXMgcHJv YmxlbXMgZ28gYXdheSB3aGVuDQo+IHlvdSBjb21lIHRvIHRoZSBJRVRGIHRvIHN0YW5kYXJkaXpl IG5ldyBUTFZzLg0KPg0KPiBIZW5uaW5nIFJvZ2dlDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiBtYW5l dEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCB3aXRo aW4gdGhpcyBlLW1haWwgYW5kIGFueSBmaWxlcyBhdHRhY2hlZCB0byB0aGlzIGUtbWFpbCBpcyBw cml2YXRlIGFuZCBpbiBhZGRpdGlvbiBtYXkgaW5jbHVkZSBjb21tZXJjaWFsbHkgc2Vuc2l0aXZl IGluZm9ybWF0aW9uLiBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWwgYXJlIGZvciB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IG9ubHkgYW5kIHRoZXJlZm9yZSBpZiB5b3Ugd2lzaCB0byBkaXNjbG9z ZSB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIHdpdGhpbiB0aGlzIGUtbWFpbCBvciBhdHRhY2hl ZCBmaWxlcywgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBwcmlvciB0byBhbnkgc3VjaCBkaXNj bG9zdXJlLg0KDQpJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlz Y2xvc3VyZSwgY29weWluZyBvciBkaXN0cmlidXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIGFs c28gY29udGFjdCB0aGUgc2VuZGVyIGFuZCBpbmZvcm0gdGhlbSBvZiB0aGUgZXJyb3IgYW5kIGRl bGV0ZSB0aGUgZS1tYWlsLCBpbmNsdWRpbmcgYW55IGF0dGFjaGVkIGZpbGVzIGZyb20geW91ciBz eXN0ZW0uDQoNCkVtYWlscyB0byBBaXJidXMgRFMgTGltaXRlZCBtYXkgYmUgcHJvY2Vzc2VkLCBy ZWNvcmRlZCBhbmQgbW9uaXRvcmVkIGFueXdoZXJlIGluIHRoZSBFdXJvcGVhbiBDb21tdW5pdHku DQoNCg0KQWlyYnVzIERTIExpbWl0ZWQNCg0KUmVnaXN0ZXJlZCBPZmZpY2U6IFF1YWRyYW50IEhv dXNlLCBDZWx0aWMgU3ByaW5ncywgQ29lZGtlcm5ldywgTmV3cG9ydCAsIE5QMTAgOEZaLg0KUmVn aXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcyB1bmRlciBjb21wYW55IG51bWJlciAwNDE5MTAz Ng0K --_000_B177F831FB91F242972D0C35F6A073314ECE94EDSUCNPTEXM02coma_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hfQ0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiJ9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZX0NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZX0NCnANCgl7bWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tbGVmdDowY207DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEfQ0KLk1zb0NocERlZmF1bHQNCgl7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIn0NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXttYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXt9DQotLT4NCjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+SnVzdCB0byBjbGFyaWZ5IHRo ZSDigJhEcm9wIENvbm5lY3Rpb25z4oCZIHN0YXRlbWVudC4mbmJzcDsgRExFUCBhcyBpdCBjdXJy ZW50bHkgc3RhbmRzIGhhcyBhIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gcGhhc2Ugd2l0aCBncmFj ZWZ1bCByZWZ1c2FsIGFzIHBhcnQgb2YgdGhlIHNlc3Npb24NCiBpbml0aWFsaXphdGlvbi4gJm5i c3A7VGhlIGRyb3AgY29ubmVjdGlvbiBiZWhhdmlvdXIgaGFwcGVucyBvbmx5IGlmIGFuIGltcGxl bWVudGF0aW9uIHJlbmVnZXMgb24gd2hhdCBoYXMgcHJldmlvdXNseSBiZWVuIG5lZ290aWF0ZWQu PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj5SaWNrPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTsgYm9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDsgcGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDsgcGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1h bmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ SnVzdGluIERlYW48YnI+DQo8Yj5TZW50OjwvYj4gMTkgRGVjZW1iZXIgMjAxNCAxMjo1NTxicj4N CjxiPlRvOjwvYj4gSGVubmluZyBSb2dnZTxicj4NCjxiPkNjOjwvYj4gQ2hyaXN0b3BoZXIgRGVh cmxvdmU7IG1hbmV0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIERM RVAgVmVuZG9yIEV4dGVuc2lvbnM8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwPkl0IGRvZXNuJ3QgZm9yd2FyZCBidXQgdGhlcmUg YXJlIGxpbWl0YXRpb25zIHdoZW4gb25seSBoYXZpbmcgb25lIGFwcHJvYWNoIGZvciBkZWFsaW5n IHdpdGggdW5rbm93biBleHRlbnNpb25zLiAoRHJvcCBjb25uZWN0aW9uIHZzIGlnbm9yZSBleHRl bnNpb25zKS4gQnV0IGFzIHlvdSBwb2ludCBvdXQgbGltaXRhdGlvbnMgd2l0aCB2ZW5kb3IgZXh0 ZW50aW9ucyBpc24ndCByZWFsbHkgYSBiYWQgdGhpbmcgYXMgaXQgZW5jb3VyYWdlcyBzdGFuZGFy ZGl6YXRpb24uDQogSSBsaWtlIHRoZSBhcHByb2FjaC48L3A+DQo8cD5KdXN0aW4gPC9wPg0KPHA+ T24gRGVjIDE5LCAyMDE0IDY6MjQgQU0sICZxdW90O0hlbm5pbmcgUm9nZ2UmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpocm9nZ2VAZ21haWwuY29tIj5ocm9nZ2VAZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gRnJpLCBEZWMgMTksIDIwMTQgYXQgMTI6MTIg UE0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyBObywgbm90IFNDVFAuIEJ1dCBh cyBJIHNhaWQgSSBkb24ndCByZWNhbGwgd2hpY2ggcHJvdG9jb2wuIFdoYXQgaXMgY2xlYXIgaXMg dGhhdCB0aGlzIGlzIGEgZnJlcXVlbnRseSByZWludmVudGVkIHdoZWVsLiAoVGhhdCdzIGEgYml0 IHVuZmFpciwgcmVxdWlyZW1lbnRzIGRpZmZlci4pPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IE5vdCBETEVQLCBidXQgbWF5IGJlIG9mIGludGVyZXN0LCBkaWdnaW5nIGludG8gbXkgbWVt b3J5IHRoZSBpc3N1ZSB0aGF0IHdhcyB0aGUga2lsbGVyIGZvciB0cnlpbmcgdG8gcHV0IHNvbWV0 aGluZyBsaWtlIHRoaXMgaW50byA1NDQ0IHdhcyB0aGUgZXhwZWN0YXRpb24gdGhhdCBtZXNzYWdl cyB3b3VsZCBiZSBmb3J3YXJkZWQuIFRoZW4gd2UgcnVuIGludG8gY2FzZXMgc3VjaCBhcyB3aGVu IHdlIGhhdmUgQSAtIEIgLSBDIHdoZXJlIEEgYW5kDQogQyBzdXBwb3J0IHdoYXRldmVyIGl0IGlz IHRoYXQgdGhlIFRMViBpbmRpY2F0ZXMsIGJ1dCBCIGRvZXMgbm90LiBJbiBzb21lIGNhc2VzIHRo YXQncyBmaW5lLCBpbiBvdGhlcnMgaXQncyBhIGtpbGxlci4gV2hpY2ggd291bGQgbWVhbiB0cnlp bmcgdG8gbWFuYWdlIHdoZXRoZXIgQiBmb3J3YXJkcyB0aGUgbWVzc2FnZS4gQnV0IHdoYXQgaXMg Zm9yd2FyZGluZz8gSXQgY291bGQgYmUgYmxpbmQgZm9yd2FyZGluZy4gSXQgY291bGQgYmUgc29t ZXRoaW5nDQogbGlrZSBNUFIgZm9yd2FyZGluZy4gSXQgY291bGQgYmUgcmVnZW5lcmF0aW5nIGEg bmV3IG1lc3NhZ2UgZnJvbSB0aGF0IG1lc3NhZ2UuIFdlIGV2ZW50dWFsbHkgdGhyZXcgdXAgb3Vy IGhhbmRzIGFuZCBnYXZlIHVwLCB0aGluZ3Mgd2VyZSB0YWtpbmcgdG9vIGxvbmcgYWxyZWFkeS48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZ29vZCB0aGluZyB3aXRoIERMRVAgaXMgdGhhdCBpdHMg YSBkaXJlY3QgcG9pbnQgdG8gcG9pbnQ8YnI+DQomZ3Q7IGNvbm5lY3Rpb24gYmV0d2VlbiB0d28g ZGlmZmVyZW50IHBhcnRuZXJzLjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHlvdSBhcmUgdGhlIHJh ZGlvIHlvdSBhcmUgYWx3YXlzIHRhbGtpbmcgdG8gYSBzaW5nbGUgcm91dGVyLi4uIHlvdTxicj4N CiZndDsganVzdCBhbm5vdW5jZSB0aGUgcmFkaW8gdmVuZG9yLWV4dGVuc2lvbiB5b3UgdHJhbnNt aXQgKGlmIGFueSBhdCBhbGwpLjxicj4NCiZndDsgWW91IGFsc28gaGF2ZSB0byBjaGVjayBpZiB5 b3UgdW5kZXJzdGFuZCB0aGUgVmVuZG9yLWV4dGVuc2lvbiBvZiB0aGU8YnI+DQomZ3Q7IHJvdXRl ci48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJZiB0aGVyZSBpcyBhICZxdW90O1JhZGlvIFZlbmRvciBl eHRlbnNpb24gWCZxdW90OyB0aGF0IHJlcXVpcmVzIGEgJnF1b3Q7Um91dGVyPGJyPg0KJmd0OyBW ZW5kb3IgZXh0ZW5zaW9uIFkmcXVvdDsgdGhlbiB5b3UgY2FuIGNoZWNrIHRoZSBwcmVzZW5jZSBv ZiB0aGlzIGV4dGVuc2lvbjxicj4NCiZndDsgZHVyaW5nIHNlc3Npb24gYnVpbGR1cC48YnI+DQom Z3Q7PGJyPg0KJmd0OyBPZiBjb3Vyc2UgaWYgYSBWZW5kb3Igc3RhcnRzIHRvIGJ1aWxkIG11bHRp cGxlIGV4dGVuc2lvbnMgKGFuZCBzb21lPGJyPg0KJmd0OyBleHRlbnNpb25zIHRoYXQgYXJlIGp1 c3QgbXVsdGlwbGUgZXh0ZW5zaW9ucyBjb21iaW5lZCksIHRoaW5ncyBnZXQ8YnI+DQomZ3Q7IGNv bXBsaWNhdGVkLi4uIGJ1dCBJIHNlZSBubyBwcm9ibGVtIGhlcmUsIHRoaXMgcHJvYmxlbXMgZ28g YXdheSB3aGVuPGJyPg0KJmd0OyB5b3UgY29tZSB0byB0aGUgSUVURiB0byBzdGFuZGFyZGl6ZSBu ZXcgVExWcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBIZW5uaW5nIFJvZ2dlPGJyPg0KJmd0Ozxicj4N CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7IG1hbmV0IG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm1hbmV0 QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NClRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgd2l0aGluIHRoaXMgZS1tYWlsIGFuZCBhbnkgZmlsZXMgYXR0YWNo ZWQgdG8gdGhpcyBlLW1haWwgaXMgcHJpdmF0ZSBhbmQgaW4gYWRkaXRpb24gbWF5IGluY2x1ZGUg Y29tbWVyY2lhbGx5IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZS1tYWlsIGFyZSBmb3IgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvbmx5IGFuZCB0aGVyZWZvcmUg aWYgeW91IHdpc2ggdG8gZGlzY2xvc2UNCiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIHdpdGhp biB0aGlzIGUtbWFpbCBvciBhdHRhY2hlZCBmaWxlcywgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRl ciBwcmlvciB0byBhbnkgc3VjaCBkaXNjbG9zdXJlLg0KPGJyPg0KPGJyPg0KSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcgb3IgZGlz dHJpYnV0aW9uIGlzIHByb2hpYml0ZWQuIFBsZWFzZSBhbHNvIGNvbnRhY3QgdGhlIHNlbmRlciBh bmQgaW5mb3JtIHRoZW0gb2YgdGhlIGVycm9yIGFuZCBkZWxldGUgdGhlIGUtbWFpbCwgaW5jbHVk aW5nIGFueSBhdHRhY2hlZCBmaWxlcyBmcm9tIHlvdXIgc3lzdGVtLg0KPGJyPg0KPGJyPg0KRW1h aWxzIHRvIEFpcmJ1cyBEUyBMaW1pdGVkIG1heSBiZSBwcm9jZXNzZWQsIHJlY29yZGVkIGFuZCBt b25pdG9yZWQgYW55d2hlcmUgaW4gdGhlIEV1cm9wZWFuIENvbW11bml0eS4NCjxicj4NCjxicj4N Cjxicj4NCkFpcmJ1cyBEUyBMaW1pdGVkIDxicj4NCjxicj4NClJlZ2lzdGVyZWQgT2ZmaWNlOiBR dWFkcmFudCBIb3VzZSwgQ2VsdGljIFNwcmluZ3MsIENvZWRrZXJuZXcsIE5ld3BvcnQgLCBOUDEw IDhGWi4NCjxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMgdW5kZXIgY29tcGFu eSBudW1iZXIgMDQxOTEwMzYNCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B177F831FB91F242972D0C35F6A073314ECE94EDSUCNPTEXM02coma_-- From nobody Fri Dec 19 06:34:39 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E881A1A99 for ; Fri, 19 Dec 2014 06:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oUBebP_GntT6 for ; Fri, 19 Dec 2014 06:34:29 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9936F1A00E2 for ; Fri, 19 Dec 2014 06:34:29 -0800 (PST) Received: from localhost ([::1]:45815 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y1ydQ-00031T-WD; Fri, 19 Dec 2014 06:34:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Fri, 19 Dec 2014 14:34:28 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/63 Message-ID: <061.e3db09aae4d7bc0098bdcc4762b98a5d@trac.tools.ietf.org> X-Trac-Ticket-ID: 63 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/eHTAJwyjpb_z3FATxQ4yk9nkvEc Cc: manet@ietf.org Subject: [manet] #63 (aodvv2): {Orig,Targ}.Tail should be {Orig,Targ}.Mid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 14:34:31 -0000 #63: {Orig,Targ}.Tail should be {Orig,Targ}.Mid Orig.Tail and Targ.Tail should be Orig.Mid and Targ.Mid as the Tail term is used for common bits of an address among the addresses listed. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charles Perkins Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Keywords: rfc5444 mid tail -----------------------------------+------------------------------ Ticket URL: manet From nobody Fri Dec 19 06:42:02 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFFF1A88D3 for ; Fri, 19 Dec 2014 06:42:00 -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 Erbv4x-BlTdL for ; Fri, 19 Dec 2014 06:41:59 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3441A88C6 for ; Fri, 19 Dec 2014 06:41:58 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so2130643wiv.6 for ; Fri, 19 Dec 2014 06:41:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=OEbkx1aVWjnzUOTQmvPKf9ykywIW5S7JVwnW4vSsgEk=; b=MljqP/aM9zOnS6c3MJ2x8MJGr74PyXe54zJy1FZELhORQ3dKiA9y8O68rd9d9tLjrx djA1TyEzK9PAXaI/64M0FmEeAQ+AYAFIBx42V2m1oH09v4O55HhLqyy+4izbxO6wQ4+a oBxu4kfEbvgXQhVX1v59d22K0ZRCY2SNi+N8aThlxPpBnXqNKkCK1EmvvypBy3gHiBW5 QAaGT7+ZYJSz19B4WEOvdILR+pUFiZHqz2uAKbKFhbDKwBOomVn9nIlKLHl5IeoScDOr Xy32F1pAVF9dtZaaLFwQtUzjnnj1hJDfNPwzvnsK8xu/0fg4DcGGLYtoZQRV8rVFxbz0 a23w== X-Received: by 10.180.75.42 with SMTP id z10mr6481950wiv.70.1419000117761; Fri, 19 Dec 2014 06:41:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Fri, 19 Dec 2014 06:41:36 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <48C3CDF0-A369-44A6-B9F8-08B6FAF2D0A1@inf-net.nl> <8952e178-2e40-4706-b677-eea407f64fdc@SUCNPTEXC01.COM.AD.UK.DS.CORP> <7e398a91-2500-4852-b554-27439eeb9709@SUCNPTEXC01.COM.AD.UK.DS.CORP> From: Henning Rogge Date: Fri, 19 Dec 2014 15:41:36 +0100 Message-ID: To: "Taylor, Rick" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3NJyd9qEhhds8YSzs0zukasB9oE Cc: "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 14:42:00 -0000 On Fri, Dec 19, 2014 at 3:31 PM, Taylor, Rick w= rote: > Just to clarify the =E2=80=98Drop Connections=E2=80=99 statement. DLEP a= s it currently > stands has a capability negotiation phase with graceful refusal as part o= f > the session initialization. The drop connection behaviour happens only i= f > an implementation reneges on what has previously been negotiated. Yes, "drop connection" was maybe a bit too hard... I meant "decide to refuse the session" after receiving the session information of the other side. Henning Rogge From nobody Fri Dec 19 09:06:01 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993251A8A5F for ; Fri, 19 Dec 2014 09:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 KcXg-WR-q-d3 for ; Fri, 19 Dec 2014 09:05:55 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8301A8938 for ; Fri, 19 Dec 2014 09:05:03 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id hs14so1172759lab.39 for ; Fri, 19 Dec 2014 09:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dP66IVHYD5ExAPhb+RlGqet3IUC8n1AjPy1NREG83As=; b=QVKgBUCKRWukIRiQYXrEZOx/jRH1HdRNmHNUBfay34Pj4SCgM+p7h5uWIB5SY+m8C8 /izuHUAEcRX62oxGcsQrvlRJIIxqLnVgPzSvZ+4s1zQFMNFxGrReOvUBbG5WUxS08aOm 57fCUfYkNcyVhc0ao1et/6D1j+zSlThq3bi+IdQDhih1KEwOw8+SsilMeOsLK/V3EPW2 zCmxHDdjKLW2yIdEN4c44GFdsm9hdSu1SBgw47KFnWAU1VnZ4rgxV1/ZweJAhg6AoqcW YjFdRtcpg7lSFf/Go2nQOm/pzWcwE7MYxaQPW9e7UbNmoFeR5wPA0+xPNHanehswqNhu 7VFg== MIME-Version: 1.0 X-Received: by 10.112.63.133 with SMTP id g5mr8832291lbs.33.1419008701567; Fri, 19 Dec 2014 09:05:01 -0800 (PST) Received: by 10.25.85.201 with HTTP; Fri, 19 Dec 2014 09:05:01 -0800 (PST) In-Reply-To: References: <06077761-e100-43b4-b00c-aa39d93542ff@SUCNPTEXC01.COM.AD.UK.DS.CORP> Date: Fri, 19 Dec 2014 12:05:01 -0500 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11c3d8309719df050a94b5b4 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Qxu0-O_43r0cl2ekurV_kHvuHhs Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 17:05:59 -0000 --001a11c3d8309719df050a94b5b4 Content-Type: text/plain; charset=UTF-8 OK, it might look like I'm jumping into the middle of the thread here, but I promise, I've read the whole thing... ;-) On Fri, Dec 19, 2014 at 6:06 AM, Henning Rogge wrote: > > >> Maybe we can add a few more IDs for experimental usage? If we allocate > the > >> TLV and message-IDs 224-255 for experimental usage, a vendor has > >> 32 messages and 32 TLVs for his extension. Would you say that is enough? > > > > I have been led to believe that IESG don't like big blocks of > experimental TLVs as it is open to abuse. I was thinking that a more > formal block with rules for its use might have a better chance of passing > their review. Comments from those with more experience please? > My experience, FWIW, is that the IESG doesn't like large blocks of experimental TLVs. IIRC, that's one of the reasons that 5444 got limited down to just a few. I'll also say that in this case (and I note the case has gone quickly to *METRICS*, which is a hot button for me), I'm opposed to handing a vendor more than just a few Experimental TLVs. If they can't express some device-specific metric in just one or two TLVs, then we need to *drastically* re-think the core spec we currently have. IIRC, some of the proposals floated contain almost as many Experimental TLVs as what is documented in the entirety of DLEP. So, I'm ok with with "3-to-5" range, but not any more than that. Now, as to the option that Chris brought up - that of flagging the TLVs (saying in effect, 'If the receiver does not understand this TLV, here are the processing options'.). I'm not completely opposed, but as I understand the implementation proposed, I think we've already covered the problem. As I understand it, this would start out with a "Vendor ID" or "Vendor Extension" tlv in the Peer exchange. This TLV really boils down to "I'm going to use experimental TLV space, and I hope you're capable of understanding what I'm getting ready to tell you." The receiving peer has (or should have) the capability right then and there to respond with "I don't understand (support) your extension, therefore, I will ignore them."). Or, to support the maximum flexibility, verbiage can be added that says implementations MAY (not SHOULD or MUST) choose to close the socket, dropping session with the peer. Regards, Stan > > Whats about this? > > 220 - 251 Vendor-Specific TLVs > 252 - 255 Experimental TLVs > > If we need the range for "vendor-specific" stuff, just call it this way. > > We could add a line that if you use the Vendor-Specific block, you > MUST add the Vendor-ID. And maybe say a bit more about the idea behind > the block and the reason why you should go for "IETF RFC" with your > extensions if they seem to be useful. > > > Isn't that just pushing the negotiation back to the Optional Data Items > Supported TLV (which might get really big). I imagine that one day there > might be several IETF standards for DLEP metrics for different classes of > modem, and there still needs to be negotiation. Are people happy to just > rely on ODIS TLVs or do we want to explore using the Vendor Extension > mechanism as a kind of general purpose Extension mechanism? > > Not sure you can really call it "negotiation" if both sides announce > what they will transmit and then the other side can parse the data (or > a subset of it) or just drop the connection. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c3d8309719df050a94b5b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, it might look like I'm = jumping into the middle of the thread here, but I promise, I've read th= e whole thing... ;-)

=C2=A0
On Fri, Dec 19, 2014 at 6:06 AM, Henning Rogge <hrogge= @gmail.com> wrote:
>> Maybe we can add = a few more IDs for experimental usage? If we allocate the
>> TLV and message-IDs 224-255 for experimental usage, a vendor has >> 32 messages and 32 TLVs for his extension. Would you say that is e= nough?
>
> I have been led to believe that IESG don't like big blocks of expe= rimental TLVs as it is open to abuse.=C2=A0 I was thinking that a more form= al block with rules for its use might have a better chance of passing their= review.=C2=A0 Comments from those with more experience please?
My experience, FWIW, is that the IESG doesn't like large bloc= ks of experimental TLVs. IIRC, that's one of the reasons that 5444 got = limited down to just a few.
=C2=A0
I'll also say t= hat in this case (and I note the case has gone quickly to *METRICS*, which = is a hot button for me), I'm opposed to handing a vendor=C2=A0more than= =C2=A0just a few Experimental TLVs.=C2=A0 If they can't=C2=A0express so= me device-specific metric in just one or two TLVs, then we need to *drastic= ally* re-think the core spec we currently have. IIRC, some of the proposals= floated contain almost as many Experimental TLVs as what is documented in = the entirety of DLEP.=C2=A0So, I'm ok with with "3-to-5" rang= e, but not any more than that. =C2=A0=C2=A0
=C2=A0
Now,= as to the option that Chris brought up - that of flagging the TLVs (saying= in effect, 'If the receiver does not understand this TLV, here are the= processing options'.). I'm not completely opposed, but as I unders= tand the implementation proposed, I think we've already covered the pro= blem. As I understand it, this would start out with a "Vendor ID"= or "Vendor Extension" tlv in the Peer exchange. This TLV really = boils down to "I'm going to use experimental TLV space, and I hope= you're capable of understanding what I'm getting ready to tell you= ." The receiving peer has (or should have) the capability right then a= nd there to respond with "I don't understand (support) your extens= ion, therefore, I will ignore them."). Or, to support the maximum flex= ibility, verbiage=C2=A0can be=C2=A0added that says implementations MAY (not= SHOULD or MUST) choose to close the socket, dropping session with the peer= .
=C2=A0
Regards,
Stan
=C2=A0
=C2=A0
=C2=A0

Whats about this?

220 - 251 Vendor-Specific TLVs
252 - 255 Experimental TLVs

If we need the range for "vendor-specific" stuff, just call it th= is way.

We could add a line that if you use the Vendor-Specific block, you
MUST add the Vendor-ID. And maybe say a bit more about the idea behind
the block and the reason why you should go for "IETF RFC" with yo= ur
extensions if they seem to be useful.

> Isn't that just pushing the negotiation back to the Optional Data = Items Supported TLV (which might get really big).=C2=A0 I imagine that one = day there might be several IETF standards for DLEP metrics for different cl= asses of modem, and there still needs to be negotiation.=C2=A0 Are people h= appy to just rely on ODIS TLVs or do we want to explore using the Vendor Ex= tension mechanism as a kind of general purpose Extension mechanism?

Not sure you can really call it "negotiation" if both sides annou= nce
what they will transmit and then the other side can parse the data (or
a subset of it) or just drop the connection.

Henning Rogge

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--001a11c3d8309719df050a94b5b4-- From nobody Fri Dec 19 09:10:28 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807A11A8954 for ; Fri, 19 Dec 2014 09:10:26 -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 luoAVi-qEf2e for ; Fri, 19 Dec 2014 09:10:25 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180711A886E for ; Fri, 19 Dec 2014 09:10:25 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id b13so1886258wgh.3 for ; Fri, 19 Dec 2014 09:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ebcHIehn8RauFFMdK7G1yp6/cAhBd6QmniyqdWHLdaw=; b=nMlUOKGKhs8ZnHKCydETLgNAJw/LuI/wX2MgKf7AeYAVpxojDTNEswkzyw8mu+9nir WETxoC3AOZmlPsCA6fM5D3nElolFXq44gaX+KO98USmzhqTSYXHIf9azLZov59bus84u Qe9adCBWMe9/SSEyKlOenUs6NGus/W/DUrrvuF7AI3FVJsZVYGCeifQXJNbdJwsCzNI8 QfiWkqy2dkZXvAuSVabVTuh5o6YzyvpynSXocAvEU9XDs15qPtMgcPfCjevNAF20H9jS uT6QDWtvGz/MPKaN3k6NzsGksinXjdWZyNje5CjxDVXAxZPOwe8dZZRX0ILI0gvCfwAh mAlQ== X-Received: by 10.194.110.69 with SMTP id hy5mr16829476wjb.121.1419009023784; Fri, 19 Dec 2014 09:10:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Fri, 19 Dec 2014 09:10:03 -0800 (PST) In-Reply-To: References: <06077761-e100-43b4-b00c-aa39d93542ff@SUCNPTEXC01.COM.AD.UK.DS.CORP> From: Henning Rogge Date: Fri, 19 Dec 2014 18:10:03 +0100 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_arOj-jfIg9XaqQ8AORvpI9LzaE Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 17:10:26 -0000 On Fri, Dec 19, 2014 at 6:05 PM, Stan Ratliff wrote: > Now, as to the option that Chris brought up - that of flagging the TLVs > (saying in effect, 'If the receiver does not understand this TLV, here are > the processing options'.). I'm not completely opposed, but as I understand > the implementation proposed, I think we've already covered the problem. As I > understand it, this would start out with a "Vendor ID" or "Vendor Extension" > tlv in the Peer exchange. This TLV really boils down to "I'm going to use > experimental TLV space, and I hope you're capable of understanding what I'm > getting ready to tell you." The receiving peer has (or should have) the > capability right then and there to respond with "I don't understand > (support) your extension, therefore, I will ignore them."). Or, to support > the maximum flexibility, verbiage can be added that says implementations MAY > (not SHOULD or MUST) choose to close the socket, dropping session with the > peer. We could solve this by splitting the "Optional TLVs" TLV in half... by adding an "Additional Mandatory TLVs" TLV. This way we could say "if you don't understand one of these, please drop the session". No need to do this in the TLVs itself, we can do it in session setup. Henning From nobody Fri Dec 19 09:15:19 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E111A8A7E for ; Fri, 19 Dec 2014 09:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 JsJ319_0MZXt for ; Fri, 19 Dec 2014 09:15:05 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C297E1A8A4C for ; Fri, 19 Dec 2014 09:15:04 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gm9so1169714lab.40 for ; Fri, 19 Dec 2014 09:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HEDTyNyioc1wdjAQ81As8FRz3zh8zgVsMmGrrjC9dr8=; b=NAICubLVKMYboHkEoU3i/Xmmc1sG3T0GqfEboPc8J1jBmDcpRD5bHDnUMnKdhBWzBY IwMey3TEdxQqO+gCjkHcewiTE4J2j4VqHfb7BR0jkLlg3H974WyK2FGf7dwpmcus6En+ uRdgKygTtUJcgK24CUi7zKEti95kzFCv1PTTxEc6qy9pYjy6Xk3Ewq16ijfWoEmz55yN 4ZuDHRQ3F0DBQl+4NTxMQTo5N5RHmHfdgEU1GwcX7nXeqyetPQ993ly+BU2Ayob2M6Cy jDeJrNzGEyL/GnTOUUCBqL4F8zLLtGOTtVyGm2n9rxKccFP/IjPRnAjGnH6dvpuAJ88C SFsw== MIME-Version: 1.0 X-Received: by 10.112.198.233 with SMTP id jf9mr9080877lbc.9.1419009303321; Fri, 19 Dec 2014 09:15:03 -0800 (PST) Received: by 10.25.85.201 with HTTP; Fri, 19 Dec 2014 09:15:03 -0800 (PST) In-Reply-To: References: <06077761-e100-43b4-b00c-aa39d93542ff@SUCNPTEXC01.COM.AD.UK.DS.CORP> Date: Fri, 19 Dec 2014 12:15:03 -0500 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11c32cf47525cd050a94d9f6 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/j1QkbpWkt_d8fYzoDxY_XWnUyQg Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 17:15:09 -0000 --001a11c32cf47525cd050a94d9f6 Content-Type: text/plain; charset=UTF-8 Henning, Yeah, that was my point - it's already done via the "Optional TLVs Supported" mechanism. Regards, Stan On Fri, Dec 19, 2014 at 12:10 PM, Henning Rogge wrote: > > On Fri, Dec 19, 2014 at 6:05 PM, Stan Ratliff > wrote: > > Now, as to the option that Chris brought up - that of flagging the TLVs > > (saying in effect, 'If the receiver does not understand this TLV, here > are > > the processing options'.). I'm not completely opposed, but as I > understand > > the implementation proposed, I think we've already covered the problem. > As I > > understand it, this would start out with a "Vendor ID" or "Vendor > Extension" > > tlv in the Peer exchange. This TLV really boils down to "I'm going to use > > experimental TLV space, and I hope you're capable of understanding what > I'm > > getting ready to tell you." The receiving peer has (or should have) the > > capability right then and there to respond with "I don't understand > > (support) your extension, therefore, I will ignore them."). Or, to > support > > the maximum flexibility, verbiage can be added that says implementations > MAY > > (not SHOULD or MUST) choose to close the socket, dropping session with > the > > peer. > > We could solve this by splitting the "Optional TLVs" TLV in half... > > by adding an "Additional Mandatory TLVs" TLV. This way we could say > "if you don't understand one of these, please drop the session". > > No need to do this in the TLVs itself, we can do it in session setup. > > Henning > --001a11c32cf47525cd050a94d9f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Henning,
=C2=A0
Yeah, that was m= y point - it's already done via the "Optional TLVs Supported"= mechanism.
=C2=A0
Regards,
Stan
=C2=A0

On Fri,= Dec 19, 2014 at 12:10 PM, Henning Rogge <hrogge@gmail.com> w= rote:
On Fri, Dec 19, 2014 at 6:05 PM, Stan R= atliff <ratliffstan@gmail.com> wrote:
> Now, as to the option that Chris brought up - that of flagging the TLV= s
> (saying in effect, 'If the receiver does not understand this TLV, = here are
> the processing options'.). I'm not completely opposed, but as = I understand
> the implementation proposed, I think we've already covered the pro= blem. As I
> understand it, this would start out with a "Vendor ID" or &q= uot;Vendor Extension"
> tlv in the Peer exchange. This TLV really boils down to "I'm = going to use
> experimental TLV space, and I hope you're capable of understanding= what I'm
> getting ready to tell you." The receiving peer has (or should hav= e) the
> capability right then and there to respond with "I don't unde= rstand
> (support) your extension, therefore, I will ignore them."). Or, t= o support
> the maximum flexibility, verbiage can be added that says implementatio= ns MAY
> (not SHOULD or MUST) choose to close the socket, dropping session with= the
> peer.

We could solve this by splitting the "Optional TLVs" TLV in half.= ..

by adding an "Additional Mandatory TLVs" TLV. This way we could s= ay
"if you don't understand one of these, please drop the session&quo= t;.

No need to do this in the TLVs itself, we can do it in session setup.

Henning
--001a11c32cf47525cd050a94d9f6-- From nobody Fri Dec 19 09:28:21 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848391A8FD2 for ; Fri, 19 Dec 2014 09:28:19 -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 m8c2fhImZ2yt for ; Fri, 19 Dec 2014 09:28:18 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077751A8F3D for ; Fri, 19 Dec 2014 09:28:18 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id b13so1927065wgh.3 for ; Fri, 19 Dec 2014 09:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IWvNTmzXHrN7fgTp1XqH/Dm/J6ciphQRzRLAkbi09mE=; b=T0nu6ogjHYgx7yoqSDKa1BDJKHGN5PDHhE3phUnupVa9R/rrWeAr9iCWabPP6E0H7r IxhSOFVnoS6H4iTyEkssr7ATbwwvC9HYKrCJzVLeVzbW7c8uw+L/tznG9FgxeWHF6hyA rKvFjDanlBT85QgBttAf1G9tg8Gc4Z11vhtU98EG1SKsZinw7Mk9BxB0lE9GYV0b4Z3L 61n52+RgRquAoDJSAWqrcDRUrfETdSwBDBFkrtfI3p29ZeOVEiOsD7FbOrmijYPp/zo9 SaPLS33XwWdcJJkdkUjxGGMPWLQkv/WIOiWo8ZUOtNm8LgvAQ+M6502EI7/vk+PpvzCj 6qOg== X-Received: by 10.180.208.69 with SMTP id mc5mr7922226wic.25.1419010096773; Fri, 19 Dec 2014 09:28:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Fri, 19 Dec 2014 09:27:56 -0800 (PST) In-Reply-To: References: <06077761-e100-43b4-b00c-aa39d93542ff@SUCNPTEXC01.COM.AD.UK.DS.CORP> From: Henning Rogge Date: Fri, 19 Dec 2014 18:27:56 +0100 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/S7aqlKZ-P9gTSRq3YYCwUh2UfIU Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 17:28:19 -0000 On Fri, Dec 19, 2014 at 6:15 PM, Stan Ratliff wrote: > Henning, > > Yeah, that was my point - it's already done via the "Optional TLVs > Supported" mechanism. Damned, you are right... I somehow had the "direction" of the announcement the other way around in my head. Each side announces which TLVs it understands... if something mandatory is missing the other side can drop the session. So it is a non-issue. Henning Rogge From nobody Fri Dec 19 10:05:48 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562101ACCEB for ; Fri, 19 Dec 2014 10:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 Z2kfr_FR5u86 for ; Fri, 19 Dec 2014 10:05:44 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6931ACCF5 for ; Fri, 19 Dec 2014 10:05:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,607,1413237600"; d="scan'208";a="5866806" Received: from exc-cashub03.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 19 Dec 2014 19:05:43 +0100 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB03.tsn.tno.nl ([fe80::6d39:f277:173e:a926%13]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 19:05:43 +0100 From: "Velt, R. (Ronald) in 't" To: "Dearlove, Christopher (UK)" , "Taylor, Rick" , Henning Rogge , "Teco Boot" Thread-Topic: [manet] DLEP Vendor Extensions Thread-Index: AdAZRvZGMxZmPNThQGCgATXqm4sJsABkseiAAASx7YAAAClHAAAAs9uAAAKExgAAH8l8QAAAd+sAAAAYTLAADoxTgA== Date: Fri, 19 Dec 2014 18:05:42 +0000 Message-ID: <72FB622921C13746AD6349E70A8D9F307DD9F457@EXC-MBX03.tsn.tno.nl> References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <48C3CDF0-A369-44A6-B9F8-08B6FAF2D0A1@inf-net.nl> <8952e178-2e40-4706-b677-eea407f64fdc@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/7Fq1CxG8RrkNwFJbzID651v2PO4 Cc: manet IETF Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 18:05:46 -0000 Christopher, >-----Original Message----- >From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Dearlove, >Christopher (UK) >Sent: vrijdag 19 december 2014 12:13 >To: Taylor, Rick; Henning Rogge; Teco Boot >Cc: manet IETF >Subject: Re: [manet] DLEP Vendor Extensions > >Rick: >> This sounds a lot like SCTP to me. It works, but it can be viewed as fi= ddly. >Personally I like it, I know Stan doesn't. > >No, not SCTP. But as I said I don't recall which protocol. What is clear i= s that this >is a frequently reinvented wheel. (That's a bit unfair, requirements diffe= r.) > Perhaps http://tools.ietf.org/html/rfc5050#section-4.3, in conjunction with= http://tools.ietf.org/html/rfc5050#section-4.6 ? Regards, Ronald = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From nobody Fri Dec 19 10:25:27 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72591ACD30 for ; Fri, 19 Dec 2014 10:25:24 -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 NYOpckJhb652 for ; Fri, 19 Dec 2014 10:25:22 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4650B1ACD27 for ; Fri, 19 Dec 2014 10:25:22 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so2056441wgg.0 for ; Fri, 19 Dec 2014 10:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=PVCVoQwPO9H5aeiGo9YKSUQzTCPzctj8yDzzsAc0tug=; b=0Dsj9vNDsby9zv2xD5x9fwfiAxP6pPNQpFAYYRfYCbShD3FpYg6nZB5V18EHkYnSCG 3Wzr+cy5XdFXV/MiLdYlq/Co+K8aYj6/Mht1S+Gk6gKedEmnajOQiPemqdWQ3kU7u+Kg DTC7wbC5x5HoZnJMbA6mFVTNgok+iDDgJPGJSMeAfX+/IxmUfXtcsAYIxuowFZm1KDFb JyWlIjgt9vi+9zsdlu7fYObRgh35iSVoxhfBkH9p5tpB/jPHQKsfB5gvzfIQ38YyghIr 5GHgh9uSgHfsWPs6QMmImPOw2DlRtRq6FfyjzvzvturgFZ4qkX/kgyfEK/wtazLBVim5 DjpA== X-Received: by 10.180.198.211 with SMTP id je19mr8098880wic.27.1419013520715; Fri, 19 Dec 2014 10:25:20 -0800 (PST) Received: from [192.168.254.1] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id eu8sm3224075wib.21.2014.12.19.10.25.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 10:25:18 -0800 (PST) References: <38A5475DE83986499AEACD2CFAFC3F980142A0343D@tss-server1.home.tropicalstormsoftware.com> <48C3CDF0-A369-44A6-B9F8-08B6FAF2D0A1@inf-net.nl> <8952e178-2e40-4706-b677-eea407f64fdc@SUCNPTEXC01.COM.AD.UK.DS.CORP> <72FB622921C13746AD6349E70A8D9F307DD9F457@EXC-MBX03.tsn.tno.nl> Mime-Version: 1.0 (1.0) In-Reply-To: <72FB622921C13746AD6349E70A8D9F307DD9F457@EXC-MBX03.tsn.tno.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <99BAA589-EF46-480F-A619-0B483B791004@gmail.com> X-Mailer: iPhone Mail (12B440) From: Christopher Dearlove Date: Fri, 19 Dec 2014 18:25:17 +0000 To: "Velt, R. (Ronald) in 't" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ktZZUnSsh6yoMr4sKdM8OrqCAKI Cc: manet IETF , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] DLEP Vendor Extensions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 18:25:25 -0000 No, not that either. Clearly a common issue. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 19 Dec 2014, at 18:05, Velt, R. (Ronald) in 't w= rote: >=20 > Christopher, >=20 >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Dearlove, >> Christopher (UK) >> Sent: vrijdag 19 december 2014 12:13 >> To: Taylor, Rick; Henning Rogge; Teco Boot >> Cc: manet IETF >> Subject: Re: [manet] DLEP Vendor Extensions >>=20 >> Rick: >>> This sounds a lot like SCTP to me. It works, but it can be viewed as fi= ddly. >> Personally I like it, I know Stan doesn't. >>=20 >> No, not SCTP. But as I said I don't recall which protocol. What is clear i= s that this >> is a frequently reinvented wheel. (That's a bit unfair, requirements diff= er.) >=20 > Perhaps http://tools.ietf.org/html/rfc5050#section-4.3, in conjunction wit= h http://tools.ietf.org/html/rfc5050#section-4.6 ? >=20 > Regards, > Ronald >=20 > This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are r= equested to inform the sender and delete the message. TNO accepts no liabili= ty for the content of this e-mail, for the manner in which you use it and fo= r damage of any kind resulting from the risks inherent to the electronic tra= nsmission of messages. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Dec 23 04:02:12 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6CE1ACDA9 for ; Tue, 23 Dec 2014 04:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 JGEroQgJKQbX for ; Tue, 23 Dec 2014 04:02:06 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA741ACD6F for ; Tue, 23 Dec 2014 04:02:05 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 23 Dec 2014 12:01:35 +0000 From: Rick Taylor To: Henning Rogge , Stan Ratliff Thread-Topic: [manet] DLEP Vendor Extensions negotiation Thread-Index: AQHQG3sGGM2XRsoOSUK/b+cgKRH6V5yWwL6AgABkJYCAAAFogIAAAWaAgAADmQCABe4knQ== Date: Tue, 23 Dec 2014 12:01:34 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F980142ACCD01@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F980142ACCD01tssserver1hom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/QvUz2vMXvVo0dq7yhop0Ji6hD2E Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 12:02:10 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F980142ACCD01tssserver1hom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I'm just running through some updated ideas for extensions in my head and t= hought I would jot down some ideas. If tlvs are split in to type and subtype (0 for command and control tlvs, 1= for core metrics, 2 to 64 for future standards, 65 to 128 for vendor exten= sions and some experimental space) then extensions supported can be negotia= ted at session initialization by stating a list of extensions supported wit= h the usual behaviour for not supported etc. This might allow a clean method for future extensions to be negotiated and = allow vendors some private space as well on a per session basis. The disadvantage is that two registries would have to be maintained by IANA= . Before I go too far down this line of thought does anyone have any points I= may have missed? Rick Sent from my HTC ----- Reply message ----- From: "Henning Rogge" To: "Stan Ratliff" Cc: "manet IETF" Subject: [manet] DLEP Vendor Extensions negotiation Date: Fri, Dec 19, 2014 17:28 On Fri, Dec 19, 2014 at 6:15 PM, Stan Ratliff wrote= : > Henning, > > Yeah, that was my point - it's already done via the "Optional TLVs > Supported" mechanism. Damned, you are right... I somehow had the "direction" of the announcement the other way around in my head. Each side announces which TLVs it understands... if something mandatory is missing the other side can drop the session. So it is a non-issue. Henning Rogge _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_38A5475DE83986499AEACD2CFAFC3F980142ACCD01tssserver1hom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
=
All,

I'm just running through some updated id= eas for extensions in my head and thought I would jot down some ideas.

If tlvs are split in to type and subtype (0 for comman= d and control tlvs, 1 for core metrics, 2 to 64 for future standards, 65 to= 128 for vendor extensions and some experimental space) then extensions sup= ported can be negotiated at session initialization by stating a list of ext= ensions supported with the usual behaviour for not supported etc.

This might allow a clean method for future extensions to be= negotiated and allow vendors some private space as well on a per session b= asis. 

The disadvantage is that two registrie= s would have to be maintained by IANA. 

Befor= e I go too far down this line of thought does anyone have any points I may = have missed?

Rick

Sent fr= om my HTC

----- Reply message -----
Fr= om: "Henning Rogge" <hrogge@gmail.com>
To: "Stan Ra= tliff" <ratliffstan@gmail.com>
Cc: "manet IETF" <= ;manet@ietf.org>
Subject: [manet] DLEP Vendor Extensions negotiation<= br>Date: Fri, Dec 19, 2014 17:28

O= n Fri, Dec 19, 2014 at 6:15 PM, Stan Ratliff <ratliffstan@gmail.com> = wrote:
> Henning,
>
> Yeah, that was my point - it's already done via the "Optional TLV= s
> Supported" mechanism.

Damned, you are right...

I somehow had the "direction" of the announcement the other way a= round
in my head.

Each side announces which TLVs it understands... if something
mandatory is missing the other side can drop the session.

So it is a non-issue.

Henning Rogge

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet
 --_000_38A5475DE83986499AEACD2CFAFC3F980142ACCD01tssserver1hom_-- From nobody Tue Dec 23 05:20:57 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D411A8A89 for ; Tue, 23 Dec 2014 05:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 rbqqR11bxI9o for ; Tue, 23 Dec 2014 05:20:52 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454E51A8A86 for ; Tue, 23 Dec 2014 05:20:51 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so8979972wgh.22 for ; Tue, 23 Dec 2014 05:20:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=K8SuyHZMsGhNgWpnX37l/qSsOtjjezkhff8aDWlgpys=; b=UNWqLsu7qaxyAp0BeroTrFkfvlHtCMsV/k/UzW0i4U/vb7mkKGyXDccoZ04FgxL8Ha QTIevcFB9QiUWfQLihDsxIHQ6VPqi5eSwabV40PgVIanic+kL6wKiFx7QHa6GcB1Koql E7TUM2QCJ4dfyL3anes8ZRup+CSUTrEUx0xvhQzNFBA3GGPl85nnkStfRPeA1bz9pMKK 7XyGRg6JaZRfQiAg84OFNzq//8PHbrZLVYUgdK0jSGTaMsO1tzhw8fdnQFrpsVv8btdJ hjPaQBnbC48t4homR/b8rW1WcamVHJbXbIFqXLn3SK1CqCQ69qB6bn2s3jrnsFmsUINh vzgw== X-Gm-Message-State: ALoCoQlUOq2lfdtpKIqf+S8F0+nCSd1iGiVrgA7v1Itl2eiJt3Zrgz2h4MwM3R2DBPZQu7tt/0MS X-Received: by 10.180.97.196 with SMTP id ec4mr40717773wib.71.1419340850504; Tue, 23 Dec 2014 05:20:50 -0800 (PST) Received: from [192.168.178.95] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPSA id l9sm17241744wic.21.2014.12.23.05.20.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Dec 2014 05:20:49 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C47BEBBD-F270-40CF-B19C-762CD845230F" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Teco Boot In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980142ACCD01@tss-server1.home.tropicalstormsoftware.com> Date: Tue, 23 Dec 2014 14:20:47 +0100 Message-Id: References: <38A5475DE83986499AEACD2CFAFC3F980142ACCD01@tss-server1.home.tropicalstormsoftware.com> To: Rick Taylor X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/X3myV8-6TYxiNSs11rsQi1-CjeM Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 13:20:55 -0000 --Apple-Mail=_C47BEBBD-F270-40CF-B19C-762CD845230F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Why would IANA keep track of vendor extensions?=20 We only need one type codepoint for vendor extensions. The TLV format = has a mandatory UOI (which are somewhat easy to get). Each vendor shall = set up its own subtype registry and publish. This brings the = housekeeping for proprietary stuff where it belongs: outside IETF and = IANA. If vendors want their stuff standardized, which they should, they = shall bring it to IETF. Teco > Op 23 dec. 2014, om 13:01 heeft Rick Taylor = het volgende geschreven: >=20 > All, >=20 > I'm just running through some updated ideas for extensions in my head = and thought I would jot down some ideas. >=20 > If tlvs are split in to type and subtype (0 for command and control = tlvs, 1 for core metrics, 2 to 64 for future standards, 65 to 128 for = vendor extensions and some experimental space) then extensions supported = can be negotiated at session initialization by stating a list of = extensions supported with the usual behaviour for not supported etc. >=20 > This might allow a clean method for future extensions to be negotiated = and allow vendors some private space as well on a per session basis.=20 >=20 > The disadvantage is that two registries would have to be maintained by = IANA.=20 >=20 > Before I go too far down this line of thought does anyone have any = points I may have missed? >=20 > Rick >=20 > Sent from my HTC >=20 > ----- Reply message ----- > From: "Henning Rogge" > > To: "Stan Ratliff" > > Cc: "manet IETF" > > Subject: [manet] DLEP Vendor Extensions negotiation > Date: Fri, Dec 19, 2014 17:28 >=20 > On Fri, Dec 19, 2014 at 6:15 PM, Stan Ratliff > wrote: > > Henning, > > > > Yeah, that was my point - it's already done via the "Optional TLVs > > Supported" mechanism. >=20 > Damned, you are right... >=20 > I somehow had the "direction" of the announcement the other way around > in my head. >=20 > Each side announces which TLVs it understands... if something > mandatory is missing the other side can drop the session. >=20 > So it is a non-issue. >=20 > Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet = > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet = --Apple-Mail=_C47BEBBD-F270-40CF-B19C-762CD845230F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Why would IANA keep track of vendor extensions? 
We only need one type codepoint for vendor extensions. The = TLV format has a mandatory UOI (which are somewhat easy to get). =  Each vendor shall set up its own subtype registry and publish. = This brings the housekeeping for proprietary stuff where it belongs: = outside IETF and IANA. If vendors want their stuff standardized, which = they should, they shall bring it to IETF.

Teco


Op = 23 dec. 2014, om 13:01 heeft Rick Taylor <rick@tropicalstormsoftware.com> het volgende = geschreven:

All,

I'm just running through some updated = ideas for extensions in my head and thought I would jot down some = ideas.

If tlvs = are split in to type and subtype (0 for command and control tlvs, 1 for = core metrics, 2 to 64 for future standards, 65 to 128 for vendor = extensions and some experimental space) then extensions supported can be = negotiated at session initialization by stating a list of extensions = supported with the usual behaviour for not supported etc.

This might allow a clean = method for future extensions to be negotiated and allow vendors some = private space as well on a per session basis. 

The disadvantage is that = two registries would have to be maintained by IANA. 

Before I go too far down = this line of thought does anyone have any points I may have = missed?

Rick

Sent from my HTC

----- Reply message -----
From: "Henning Rogge" = <hrogge@gmail.com>
To: "Stan Ratliff" = <ratliffstan@gmail.com>
Cc: "manet IETF" = <manet@ietf.org>Subject: [manet] DLEP Vendor Extensions negotiation
Date: Fri, Dec 19, 2014 17:28

On Fri, Dec 19, 2014 at 6:15 PM, Stan Ratliff <ratliffstan@gmail.com> wrote:
> = Henning,
>
> Yeah, that was my point - = it's already done via the "Optional TLVs
> Supported" = mechanism.

Damned, you are right...

I somehow had the "direction" of the = announcement the other way around
in my head.

Each side announces which TLVs it = understands... if something
mandatory is missing the other = side can drop the session.

So it is a = non-issue.

Henning Rogge

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

= --Apple-Mail=_C47BEBBD-F270-40CF-B19C-762CD845230F-- From nobody Tue Dec 23 12:27:33 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FAE1A3B9B for ; Tue, 23 Dec 2014 12:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kvaheApUhFrO for ; Tue, 23 Dec 2014 12:27:30 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC441A1EF7 for ; Tue, 23 Dec 2014 12:27:30 -0800 (PST) Received: from localhost ([::1]:37669 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3W3E-0006RF-5q; Tue, 23 Dec 2014 12:27:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com, charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 20:27:28 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/1#comment:3 Message-ID: <076.bf0c759fbcada75e4dbc854102212fd5@trac.tools.ietf.org> References: <061.72177d73cfafe05daea3d2d786e8793b@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <061.72177d73cfafe05daea3d2d786e8793b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Q_ck4CuIpdZtMLlNqLKQ9AC0cyc Cc: manet@ietf.org Subject: Re: [manet] #1 (dymo): Discussion about naming for the IETF reactive protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 20:27:31 -0000 #1: Discussion about naming for the IETF reactive protocol Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: task | Status: closed Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: fixed Keywords: reactive naming | -----------------------------------+------------------------------ Ticket URL: manet From nobody Tue Dec 23 12:43:01 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D5B1A6F04 for ; Tue, 23 Dec 2014 12:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DnCtW-SJJb2p for ; Tue, 23 Dec 2014 12:42:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B811A6F13 for ; Tue, 23 Dec 2014 12:42:56 -0800 (PST) Received: from localhost ([::1]:38637 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3WIC-0001NU-4I; Tue, 23 Dec 2014 12:42:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 20:42:56 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/3#comment:2 Message-ID: <076.b189883df21af388ed663545a22467ef@trac.tools.ietf.org> References: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-GXBGbM0lLXy4vkirJhPvElqwLw Cc: manet@ietf.org Subject: Re: [manet] #3 (dymo): Use msg-hop-count in RFC 5444 header to limit # of hops X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 20:43:01 -0000 #3: Use msg-hop-count in RFC 5444 header to limit # of hops Changes (by charliep@computer.org): * status: new => closed * resolution: => invalid Comment: On 6/12/2013 5:09 PM, Charles E. Perkins wrote: > Hello folks, > > I have collected the previous discussion about issue #3 and > posted the the technical parts of the discussion to the issue tracker, > as reproduced before. If I have missed any points of the discussion, > please let me know and I will similarly post those points also to > the issue tracker. > > While the technical matters involved with issue #3 may still be of > interest and open to discussion, I think that the discussion is no > longer relevant to the working group document, because there isn't > much motivation to make the necessary protocol changes to > utilize the idea. For this reason, I propose to close the issue without > making any changes to the document. > > Regards, > Charlie P. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: enhancement | Status: closed Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: invalid Keywords: hop count, hop limit | -----------------------------------+------------------------------ Ticket URL: manet From nobody Tue Dec 23 12:45:07 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DDE1A6F27 for ; Tue, 23 Dec 2014 12:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1icAe808ReVR for ; Tue, 23 Dec 2014 12:45:04 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCF81A6F1E for ; Tue, 23 Dec 2014 12:45:04 -0800 (PST) Received: from localhost ([::1]:38787 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3WKG-0001lD-MN; Tue, 23 Dec 2014 12:45:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 20:45:04 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/4#comment:1 Message-ID: <076.66980452f622577b59540b716a6d4c6b@trac.tools.ietf.org> References: <061.9fd5709d256b2f4a875556dafc06bb3b@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <061.9fd5709d256b2f4a875556dafc06bb3b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/mJwGo7Ba1ScXS50ax1rtaBkF0cc Cc: manet@ietf.org Subject: Re: [manet] #4 (dymo): Change to handling of Route.Dist for AdditionalNode routing information X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 20:45:06 -0000 #4: Change to handling of Route.Dist for AdditionalNode routing information Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 6/13/2013 1:36 PM, Charles E. Perkins wrote: > This change has been superceded in the specification without noticeable > loss of function or any disagreement. It does not seem to have any bad > interaction with the way the specification deals with alternative metrics. > > I think the issue can be safely closed, unless there is anyone with more > relevant discussion points. -- -------------------------------------+--------------------- Reporter: charliep@computer.org | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: fixed Keywords: route metric, hop count | -------------------------------------+--------------------- Ticket URL: manet From nobody Tue Dec 23 12:46:27 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B111A6F3B for ; Tue, 23 Dec 2014 12:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hhsQ4gFUkX7q for ; Tue, 23 Dec 2014 12:46:25 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9801A6F2D for ; Tue, 23 Dec 2014 12:46:25 -0800 (PST) Received: from localhost ([::1]:38941 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3WLZ-0002bz-2S; Tue, 23 Dec 2014 12:46:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 20:46:25 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/5#comment:2 Message-ID: <076.c5ba8ce534632cc3644662d67eb89a3c@trac.tools.ietf.org> References: <061.db3c48158682d65cd854a9d5c40c741f@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <061.db3c48158682d65cd854a9d5c40c741f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hH45fmSJFaeGQDjTUCNeFnv6-ys Cc: manet@ietf.org Subject: Re: [manet] #5 (dymo): Reorganizing the route table entry timeout management X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 20:46:26 -0000 #5: Reorganizing the route table entry timeout management Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 2/8/2013 3:22 PM, Charles E. Perkins wrote: > The route table timeout issue and proposed resolution has been incorporated > in the most recent revisions for the AODVv2 specification. If the new timeout > structure and definitions are satisfactory, the AODVv2 editing team will > consider closing issue #5. Please let us know if there is any objection to > closing the issue. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: defect | Status: closed Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: fixed Keywords: route timeouts | -----------------------------------+------------------------------ Ticket URL: manet From nobody Tue Dec 23 12:48:00 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA941A6F27 for ; Tue, 23 Dec 2014 12:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 oOGQnHl5EuKH for ; Tue, 23 Dec 2014 12:47:47 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7A21A6F0B for ; Tue, 23 Dec 2014 12:47:46 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gq15so6082289lab.4 for ; Tue, 23 Dec 2014 12:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1K9+v5I74UDbfsbt12jnY22hiOLhHEJc3ktQ39wI62k=; b=FXM4mgvq/RFs53klGiYKX1dOdu8Y+pRogU8ERVpLKI55Wntr77aYq2caiTDyioWCI0 Fe9pzJzKGdO35+0WuTeF+vhonC+tGMh4R5rMwnxHvUGhQ9GIYbkaQzrTztMt8Mqx4iBn xFOa1ukyIEOez5/v/hQjdUKRvqBYn1p3B24hJxQYiqt5uroG2chYq7teiV4dSUt+j48x jfGqh/SQHhWk0nw5dYCL0ISMvQYtwZNfD8mm9gfnRmbXx699b8FfrEg6ZXsYmmWIN2jQ F39Ax90j6/gVKkpW+wwYn3/g6UDkKqNWva4CP+tj/hgQrP1vPhnggaUwg33kZWs4lQfx VzDw== MIME-Version: 1.0 X-Received: by 10.112.198.233 with SMTP id jf9mr31050324lbc.9.1419367665362; Tue, 23 Dec 2014 12:47:45 -0800 (PST) Received: by 10.25.85.201 with HTTP; Tue, 23 Dec 2014 12:47:45 -0800 (PST) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980142ACCD01@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F980142ACCD01@tss-server1.home.tropicalstormsoftware.com> Date: Tue, 23 Dec 2014 15:47:45 -0500 Message-ID: From: Stan Ratliff To: Rick Taylor Content-Type: multipart/alternative; boundary=001a11c32cf47febb0050ae8499a Archived-At: http://mailarchive.ietf.org/arch/msg/manet/lZr01KFGgqCbC-ll_6_0ZhTJQ3k Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 20:47:52 -0000 --001a11c32cf47febb0050ae8499a Content-Type: text/plain; charset=UTF-8 I'll note - the schedule discussed and agreed on in Honolulu had this item (Vendor Extensions) scheduled for resolution by Dec 19.... Advice from the ADs is that we're out of time extensions. We CANNOT continue to cycle on this issue. We MUST come to consensus and move on. Regards, Stan On Tue, Dec 23, 2014 at 7:01 AM, Rick Taylor wrote: > All, > > I'm just running through some updated ideas for extensions in my head and > thought I would jot down some ideas. > > If tlvs are split in to type and subtype (0 for command and control tlvs, > 1 for core metrics, 2 to 64 for future standards, 65 to 128 for vendor > extensions and some experimental space) then extensions supported can be > negotiated at session initialization by stating a list of extensions > supported with the usual behaviour for not supported etc. > > This might allow a clean method for future extensions to be negotiated and > allow vendors some private space as well on a per session basis. > > The disadvantage is that two registries would have to be maintained by > IANA. > > Before I go too far down this line of thought does anyone have any points > I may have missed? > > Rick > > Sent from my HTC > > ----- Reply message ----- > From: "Henning Rogge" > To: "Stan Ratliff" > Cc: "manet IETF" > Subject: [manet] DLEP Vendor Extensions negotiation > Date: Fri, Dec 19, 2014 17:28 > > On Fri, Dec 19, 2014 at 6:15 PM, Stan Ratliff > wrote: > > Henning, > > > > Yeah, that was my point - it's already done via the "Optional TLVs > > Supported" mechanism. > > Damned, you are right... > > I somehow had the "direction" of the announcement the other way around > in my head. > > Each side announces which TLVs it understands... if something > mandatory is missing the other side can drop the session. > > So it is a non-issue. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c32cf47febb0050ae8499a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll note - the schedule discussed and agreed on in Ho= nolulu had this item (Vendor Extensions) scheduled for resolution by Dec 19= .... Advice from the ADs is that we're out of time extensions.=C2=A0
We CANNOT continue to cycle on this issue. We MUST come to= consensus and move on.=C2=A0

Regards,
S= tan


On Tue, Dec 23, 2014 at 7:01 AM, Rick Taylor <ri= ck@tropicalstormsoftware.com> wrote:
All,=

I'm just running through some updated ideas f= or extensions in my head and thought I would jot down some ideas.

If tlvs are split in to type and subtype (0 for command and= control tlvs, 1 for core metrics, 2 to 64 for future standards, 65 to 128 = for vendor extensions and some experimental space) then extensions supporte= d can be negotiated at session initialization by stating a list of extensio= ns supported with the usual behaviour for not supported etc.

=
This might allow a clean method for future extensions to be nego= tiated and allow vendors some private space as well on a per session basis.= =C2=A0

The disadvantage is that two registries wou= ld have to be maintained by IANA.=C2=A0

Before I g= o too far down this line of thought does anyone have any points I may have = missed?

Rick

Sent from my= HTC

----- Reply message -----
From: "Henning Rogge&q= uot; <hrogge@gmail= .com>
To: "Stan Ratliff" <ratliffstan@gmail.com>
Cc: "= ;manet IETF" <m= anet@ietf.org>
Subject: [manet] DLEP Vendor Extensions negotiatio= n
Date: Fri, Dec 19, 2014 17:28

On Fri, Dec 19, 2014 at 6:15 PM, = Stan Ratliff <ratliffstan@gmail.com> wrote:
> Henning,
>
> Yeah, that was my point - it's already done via the "Optional= TLVs
> Supported" mechanism.

Damned, you are right...

I somehow had the "direction" of the announcement the other way a= round
in my head.

Each side announces which TLVs it understands... if something
mandatory is missing the other side can drop the session.

So it is a non-issue.

Henning Rogge

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--001a11c32cf47febb0050ae8499a-- From nobody Tue Dec 23 12:52:32 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F322E1A6F7D for ; Tue, 23 Dec 2014 12:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 UUwBUXMND_dK for ; Tue, 23 Dec 2014 12:52:29 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B46F1A6F71 for ; Tue, 23 Dec 2014 12:52:24 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id u10so5997529lbd.17 for ; Tue, 23 Dec 2014 12:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jwgF6Mr3Cnf5hjy8ej2UyyNeQz/EL4RL/HSROvNiSVI=; b=FrHk1+RWF74vZHzFh7qKabrVav+MkRbcU/k50zd7nIqfvqv3OU42dTAVUwekaHI1ti tgfd5XeQFQNhmys5NVpRuWm+jBh7SGisO2vthIMaUj+ptZamFGpBiJiKXxz/3hZAiiIK En7XePvf0e/gLBbDG/HZzIcfXkuW7D+xy/rj4N0fw5nYbYQgdt7XvdmRHHeytwyCdeMo jgFiCNeKKdW2hCt7Sk2TJd+FxYcI9MvmEvJoQXEJu2a01ek+m7uJG0ulPwe4SdakiLYT NaH9FQHq6PigzZbIOjVEppuPM12Payt+jSv2gJIVpIYoJKHMM3/F/wBVWa1ukAhUjbaR ltRw== MIME-Version: 1.0 X-Received: by 10.152.6.8 with SMTP id w8mr30853351law.41.1419367942819; Tue, 23 Dec 2014 12:52:22 -0800 (PST) Received: by 10.25.85.201 with HTTP; Tue, 23 Dec 2014 12:52:22 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142ACCD01@tss-server1.home.tropicalstormsoftware.com> Date: Tue, 23 Dec 2014 15:52:22 -0500 Message-ID: From: Stan Ratliff To: Teco Boot Content-Type: multipart/alternative; boundary=089e01494328099463050ae85a0e Archived-At: http://mailarchive.ietf.org/arch/msg/manet/tmOAVasmTq6AEtqs_TKX9w7-g6Y Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 20:52:31 -0000 --089e01494328099463050ae85a0e Content-Type: text/plain; charset=UTF-8 As I understood the thread with Henning et. al. on this topic: Presentation of the Vendor Extensions TLV will stay in the Peer-level exchange. However, presentation of the Vendor Extension TLV implicitly "announces" formats for codepoints in the Experimental space. This let's the vendors utilize the Experimental TLVs to... well... experiment with potential additional, modem-specific metrics. It also provides an impetus for follow-on drafts, if the aforementioned modem-specific metrics gain broad acceptance. Regards, Stan On Tue, Dec 23, 2014 at 8:20 AM, Teco Boot wrote: > Why would IANA keep track of vendor extensions? > We only need one type codepoint for vendor extensions. The TLV format has > a mandatory UOI (which are somewhat easy to get). Each vendor shall set up > its own subtype registry and publish. This brings the housekeeping for > proprietary stuff where it belongs: outside IETF and IANA. If vendors want > their stuff standardized, which they should, they shall bring it to IETF. > > Teco > > > Op 23 dec. 2014, om 13:01 heeft Rick Taylor < > rick@tropicalstormsoftware.com> het volgende geschreven: > > All, > > I'm just running through some updated ideas for extensions in my head and > thought I would jot down some ideas. > > If tlvs are split in to type and subtype (0 for command and control tlvs, > 1 for core metrics, 2 to 64 for future standards, 65 to 128 for vendor > extensions and some experimental space) then extensions supported can be > negotiated at session initialization by stating a list of extensions > supported with the usual behaviour for not supported etc. > > This might allow a clean method for future extensions to be negotiated and > allow vendors some private space as well on a per session basis. > > The disadvantage is that two registries would have to be maintained by > IANA. > > Before I go too far down this line of thought does anyone have any points > I may have missed? > > Rick > > Sent from my HTC > > ----- Reply message ----- > From: "Henning Rogge" > To: "Stan Ratliff" > Cc: "manet IETF" > Subject: [manet] DLEP Vendor Extensions negotiation > Date: Fri, Dec 19, 2014 17:28 > > On Fri, Dec 19, 2014 at 6:15 PM, Stan Ratliff > wrote: > > Henning, > > > > Yeah, that was my point - it's already done via the "Optional TLVs > > Supported" mechanism. > > Damned, you are right... > > I somehow had the "direction" of the announcement the other way around > in my head. > > Each side announces which TLVs it understands... if something > mandatory is missing the other side can drop the session. > > So it is a non-issue. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --089e01494328099463050ae85a0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I understood the thread with Henning et. al. on this to= pic:=C2=A0

Presentation of the Vendor Extensions TLV wil= l stay in the Peer-level exchange. However, presentation of the Vendor Exte= nsion TLV implicitly "announces" formats for codepoints in the Ex= perimental space. This let's the vendors utilize the Experimental TLVs = to... well... experiment with potential additional, modem-specific metrics.= It also provides an impetus for follow-on drafts, if the aforementioned mo= dem-specific metrics gain broad acceptance.=C2=A0

= Regards,
Stan


On Tue, Dec 23, 2014 at 8:20 AM, Teco Boot= <teco@inf-net.nl> wrote:
Why would IANA keep track of vendor exten= sions?=C2=A0
We only need one type codepoint for vendor extensions. The= TLV format has a mandatory UOI (which are somewhat easy to get).=C2=A0 Eac= h vendor shall set up its own subtype registry and publish. This brings the= housekeeping for proprietary stuff where it belongs: outside IETF and IANA= . If vendors want their stuff standardized, which they should, they shall b= ring it to IETF.

Teco


Op 23 dec. 2014, om 13:01 heeft R= ick Taylor <rick@tropicalstormsoftware.com> het volgende geschreven:
All,

I'm just running through = some updated ideas for extensions in my head and thought I would jot down s= ome ideas.

If tlvs are split in to type and subtyp= e (0 for command and control tlvs, 1 for core metrics, 2 to 64 for future s= tandards, 65 to 128 for vendor extensions and some experimental space) then= extensions supported can be negotiated at session initialization by statin= g a list of extensions supported with the usual behaviour for not supported= etc.

This might allow a clean method for future e= xtensions to be negotiated and allow vendors some private space as well on = a per session basis.=C2=A0

The disadvantage is tha= t two registries would have to be maintained by IANA.=C2=A0

<= /div>
Before I go too far down this line of thought does anyone have an= y points I may have missed?

Rick

Sent from my HTC

----- Reply message -----
From: &= quot;Henning Rogge" <hrogge@gmail.com>
To: "Stan Ratliff" <ratliffstan@gmail.com<= /a>>
Cc: "manet IETF" <manet@ietf.org>
Subject: [manet] DLEP Vendor E= xtensions negotiation
Date: Fri, Dec 19, 2014 17:28

On Fri, Dec 19, 2014 at 6:15 PM, Stan = Ratliff <ratl= iffstan@gmail.com> wrote:
> Henning,
>
> Yeah, tha= t was my point - it's already done via the "Optional TLVs
> = Supported" mechanism.

Damned, you are right...

I somehow= had the "direction" of the announcement the other way around
= in my head.

Each side announces which TLVs it understands... if some= thing
mandatory is missing the other side can drop the session.

S= o it is a non-issue.

Henning Rogge

__________________________= _____________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/l= istinfo/manet
= _______________________________________________
manet mailing list
manet@ie= tf.org
https://www.ietf.org/mailman/listinfo/manet<= /a>


--089e01494328099463050ae85a0e-- From nobody Tue Dec 23 12:58:44 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106F81A6FBB for ; Tue, 23 Dec 2014 12:58:42 -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 5zD_yAHXt5ID for ; Tue, 23 Dec 2014 12:58:41 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9945A1A6F8C for ; Tue, 23 Dec 2014 12:58:40 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so11940771wid.15 for ; Tue, 23 Dec 2014 12:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QDCK39MXhF8nBVPMnbQuPWt7W1xMZf6xtpIr9TKmdwA=; b=w6vRF1mzbbSG6FNWB48lbeujFuNm8Y9F3CU95OwZ9eKWZ3N6IHb+uq4i0uW+Xzxx5Y NJGQnlG2FYEPh2hRWkPWhL6j5Eb3gf0OQVqJqhzWyY/4fG4ZG3kzb4UzXBwgj3FwBihw 99UBbdNGnEODs0x86cD9t1AQjd26n5utfVkAwB/AZP8oV4rWW7PRgCpFJ4Dv1CqWTNuv VMY08Gibq+c0Ca4jDZWfirQxVF/2s057Mr1WGhgqsazUAD/CRm47c5PchTEGMvo5vF9p ZFj2kudnEEkZTJoYCNatNmAdSdKKDppGNgPcbZwZZNyJDN1uU8hq/OXNVG7mmCLK/wU9 cxAQ== X-Received: by 10.181.13.75 with SMTP id ew11mr44225917wid.69.1419368315906; Tue, 23 Dec 2014 12:58:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Tue, 23 Dec 2014 12:58:15 -0800 (PST) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F980142ACCD01@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Tue, 23 Dec 2014 21:58:15 +0100 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/vkfydaMRJhtQycl3Ky1N3W4-jss Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Vendor Extensions negotiation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 20:58:42 -0000 On Tue, Dec 23, 2014 at 9:52 PM, Stan Ratliff wrote: > As I understood the thread with Henning et. al. on this topic: > > Presentation of the Vendor Extensions TLV will stay in the Peer-level > exchange. However, presentation of the Vendor Extension TLV implicitly > "announces" formats for codepoints in the Experimental space. This let's the > vendors utilize the Experimental TLVs to... well... experiment with > potential additional, modem-specific metrics. It also provides an impetus > for follow-on drafts, if the aforementioned modem-specific metrics gain > broad acceptance. Yes... instead of giving Vendors each a space where they can build stuff AND keep it there, we give them a space to quickly test and roll out stuff... but in the end you want normal IANA codepoints. Henning From nobody Tue Dec 23 13:10:42 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7B81A883C for ; Tue, 23 Dec 2014 13:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pmUd3wG-_khJ for ; Tue, 23 Dec 2014 13:10:37 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2441A9131 for ; Tue, 23 Dec 2014 13:10:10 -0800 (PST) Received: from localhost ([::1]:40210 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3WiX-0008Vd-Ng; Tue, 23 Dec 2014 13:10:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 21:10:09 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/6#comment:1 Message-ID: <076.79b241e51632e4fba1e7488716e6bf83@trac.tools.ietf.org> References: <061.132760a1d00e99fedcf3e89100775c1a@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <061.132760a1d00e99fedcf3e89100775c1a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/HUpojUCqLi7YYzM1BNpFhUutifc Cc: manet@ietf.org Subject: Re: [manet] #6 (dymo): sequence number incrementation mandate X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 21:10:39 -0000 #6: sequence number incrementation mandate Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 6/24/2013 4:59 PM, Charles E. Perkins wrote: > The stronger mandate has been specified in recent revisions of the document. > Doing so has, as expected, simplified numerous parts of the overall > specification, and no objections have been expressed for this proposed > resolution of the issue. > > For this reason, I believe it is reasonable to close the issue, unless > there are use cases suggested to the mailing list for reducing the strength > of the mandate back to its previous status of "SHOULD". -- ----------------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: enhancement | Status: closed Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: fixed Keywords: Sequence number management | ----------------------------------------+------------------------------ Ticket URL: manet From nobody Tue Dec 23 13:12:16 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF171A9147 for ; Tue, 23 Dec 2014 13:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0rtcsOHd7xqc for ; Tue, 23 Dec 2014 13:12:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC351A8725 for ; Tue, 23 Dec 2014 13:11:25 -0800 (PST) Received: from localhost ([::1]:40276 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3Wjl-0000OC-FH; Tue, 23 Dec 2014 13:11:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 21:11:25 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/7#comment:1 Message-ID: <076.0ebe2cb9d33f1fc82f4e890552306b8a@trac.tools.ietf.org> References: <061.f6d9e0fa28b46c77085c2605af4906fb@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <061.f6d9e0fa28b46c77085c2605af4906fb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/KeTeG_uqoC9HO-4yZizAIArVkEI Cc: manet@ietf.org Subject: Re: [manet] #7 (dymo): Top level document organization X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 21:12:09 -0000 #7: Top level document organization Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 11/6/2012 3:35 AM, Abdussalam Baryun wrote: > Thanks, I agree with the proposal, > > AB ============================================================================ On 6/24/2013 5:14 PM, Charles E. Perkins wrote: > This has been done, and has not caused any presentation difficulties > or organizational inconvenience in recent versions of the specification. > Therefore, unless there are any objections or suggestions for further > improvement, I think we can safely close this issue. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: enhancement | Status: closed Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+------------------------------ Ticket URL: manet From nobody Tue Dec 23 13:21:48 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895B41A9166 for ; Tue, 23 Dec 2014 13:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IQuoE8HazXcP for ; Tue, 23 Dec 2014 13:21:43 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A113F1A913D for ; Tue, 23 Dec 2014 13:21:43 -0800 (PST) Received: from localhost ([::1]:41318 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3Wtj-0007Zm-0q; Tue, 23 Dec 2014 13:21:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 21:21:42 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/8#comment:2 Message-ID: <076.f66c86854834a11c99071393ac42df8f@trac.tools.ietf.org> References: <061.01e84a8c55d727234bea54462c8094cf@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <061.01e84a8c55d727234bea54462c8094cf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/WoZywUfP7GVGXDDjZ3yw5NTPh68 Cc: manet@ietf.org Subject: Re: [manet] #8 (dymo): HopCount and alternate metrics in AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 21:21:45 -0000 #8: HopCount and alternate metrics in AODVv2 Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 11/30/2012 11:58 AM, Charles E. Perkins wrote: > As mentioned in previous email, enabling alternate metrics has been > a topic often discussed in the MANET working group. There seems to > be wide recognition of the insufficiency of using !HopCount. However, > the selection of "best" route can be tricky, because that depends > on the application. Also, some considerations from > "draft-ietf-manet-olsrv2-metrics-rationale-01.txt" apply. > > If it is agreed that AODVv2 needs to enable specification for the > use of alternate routing metrics, there is a relatively straightforward > way to do it, as long as the purpose of doing so is also agreed as > above. > In the AODVv2 document, the main changes required are: > - include the following new section > - change discussion about !HopCount to instead refer to "Cost()" > - refer to a table of Metric Types (e.g., as in RFC 6551) > - use abstract functions "Cost()" and "!LoopFree()" > - allow for storage of multiple routes to the same destination > but which allow the metric type to identify different next hops. On 11/30/2012 6:21 PM, Abdussalam Baryun wrote: > Regarding the suggested main changes required, as one was for possible > of having multi-next-hop per dest, I am thinking to add another > requirement; > > - All intermediate routers in the path to destination should have same > metric type while forwarding packets to their nexthop, otherwise an > error reported. -- -------------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: enhancement | Status: closed Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: fixed Keywords: route metric, hop count | -------------------------------------+------------------------------ Ticket URL: manet From nobody Tue Dec 23 13:29:31 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE44C1AC3A6 for ; Tue, 23 Dec 2014 13:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OUrkkl-QVe0x for ; Tue, 23 Dec 2014 13:29:28 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684C31AC39E for ; Tue, 23 Dec 2014 13:29:28 -0800 (PST) Received: from localhost ([::1]:41685 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3X1C-0006dT-44; Tue, 23 Dec 2014 13:29:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com, charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 21:29:26 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/9#comment:2 Message-ID: <076.12f682f4f8c59bc18ab48ece53e171a5@trac.tools.ietf.org> References: <061.a0055255c275fede343be9cc794f90e9@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <061.a0055255c275fede343be9cc794f90e9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hqmiWfKDdjTt8a5Mjnr6hM4Gucc Cc: manet@ietf.org Subject: Re: [manet] #9 (dymo): Reserved value for AODVv2 SeqNum -- is it necessary X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 21:29:29 -0000 #9: Reserved value for AODVv2 SeqNum -- is it necessary Changes (by charliep@computer.org): * status: new => closed * resolution: => wontfix Comment: On 6/24/2013 6:47 PM, Charles E. Perkins wrote: > This issue is trickier than most. It turns out that specifying the operation > of intermediate RREP is easier if there is a reserved value for the AODVv2 > Sequence Number field. Other than making the code shorter by maybe > a dozen lines, and the inherent preferability of reducing the number of > special cases, I didn't see a strong push for deleting the specification for > the reserved value. > > There are some other peripherally related discussion points on the > mailing list, but which were not keyed directly to issue #9. I will > try to find them and post any new insights to the issue tracker. If there > aren't any objections, I think it would be expedient and appropriate to > keep the existing specification of the reserved !SeqNum value (0). > > If I understand the point below: >> It will be not necessary but may be used by router's processing checks, > > I think it does not materially affect the outcome of the issue > resolution, but a more complete explanation would be interesting. -- ----------------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: defect | Status: closed Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: wontfix Keywords: Sequence number management | ----------------------------------------+------------------------------ Ticket URL: manet From nobody Tue Dec 23 13:35:01 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7851A7020 for ; Tue, 23 Dec 2014 13:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 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_NONE=-0.0001, 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 0hQ9tzuuXfBK for ; Tue, 23 Dec 2014 13:34:58 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id C341B1AC3B3 for ; Tue, 23 Dec 2014 13:34:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rws5mGgPNHh87HxR7aqWI7uOfvfEye1Hx5tfgfeNGJ2DEXOY5nPUEjm2tivx0eR6; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.235] (helo=[192.168.1.68]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Y3X6W-0000DE-8M for manet@ietf.org; Tue, 23 Dec 2014 16:34:56 -0500 Message-ID: <5499DFFC.1090501@earthlink.net> Date: Tue, 23 Dec 2014 13:34:52 -0800 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mobile Ad Hoc Networks mailing list Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac792e5d9ae003f36ed1a46a9346c2b98e5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.235 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MN_i-ijZV6E93RSJvS9RBNXd2qw Subject: [manet] Updating and closing old issues X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 21:35:00 -0000 Hello folks, Many, or most, old issues on the AODVv2 issue tracker may be considered to be closed. A good number of important issues remain open (for instance, about security). Some time ago, the issue tracker crashed and lost some of the posted discussion about some issues. On the other hand, other issues seem to have been restored. I am currently restoring the discussion about some of the other issues, and along the way I am marking some issues as closed based on the last relevant discussion. The goal is to focus on the issues that are not already resolved. I don't think there is a way for me to restore discussion to the issues, or change their status to "closed", without having email to the mailing list to be generated by the issue tracker. Please excuse the barrage of emails generated by the issue tracker. If some issues are marked as closed, but need more discussion, please do not hesitate to suggest re-opening the issues as may be needed. Regards, Charlie P. From nobody Tue Dec 23 13:47:15 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175821AC3BA for ; Tue, 23 Dec 2014 13:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7TTDwdioot9c for ; Tue, 23 Dec 2014 13:47:05 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BEB41ABD8F for ; Tue, 23 Dec 2014 13:47:05 -0800 (PST) Received: from localhost ([::1]:42480 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3XIF-00031i-0e; Tue, 23 Dec 2014 13:47:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com, charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 21:47:02 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/11#comment:3 Message-ID: <076.c26f6ca89f69e09d1827294ef8702d22@trac.tools.ietf.org> References: <061.56c0faacefe8cd4335a20edf5d6cc53a@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <061.56c0faacefe8cd4335a20edf5d6cc53a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/7x4FhV4apMZDJzAxMjVVQCAPhLQ Cc: manet@ietf.org Subject: Re: [manet] #11 (dymo): Error: failure of delivery to single host can invalidate route to an entire network X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 21:47:07 -0000 #11: Error: failure of delivery to single host can invalidate route to an entire network Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: During the 18 months since the introduction of this correction to the specification, no other related issues have surfaced. Therefore it is proposed that the issue be closed. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: defect | Status: closed Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: fixed Keywords: RERR, subnet route | -----------------------------------+------------------------------ Ticket URL: manet From nobody Tue Dec 23 13:49:41 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC961A6FFB for ; Tue, 23 Dec 2014 13:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HTkg4DhgJfac for ; Tue, 23 Dec 2014 13:49:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453111A6FE3 for ; Tue, 23 Dec 2014 13:49:39 -0800 (PST) Received: from localhost ([::1]:42595 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3XKk-0007QZ-U2; Tue, 23 Dec 2014 13:49:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 21:49:38 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/12#comment:1 Message-ID: <076.bde22b004b1adddeefd97d1f2a06327f@trac.tools.ietf.org> References: <061.c0c6fb135fcc7bb4ca27b05c03dc55ba@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <061.c0c6fb135fcc7bb4ca27b05c03dc55ba@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MBKnGRMVJgqukYWcaKOeURpnyoo Cc: manet@ietf.org Subject: Re: [manet] #12 (dymo): INVALID_PREFIX_LENGTH -- is it useful? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 21:49:40 -0000 #12: INVALID_PREFIX_LENGTH -- is it useful? Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 6/24/2013 8:05 PM, Charles E. Perkins wrote: > INVALID_PREFIX_LENGTH has been written out of the specification > without any inconvenient side effects. Unless there is any objection, > I think this issue can safely be closed. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: defect | Status: closed Priority: trivial | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: fixed Keywords: INVALID_PREFIX_LENGTH | -----------------------------------+------------------------------ Ticket URL: manet From nobody Tue Dec 23 13:51:22 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA3D1A8034 for ; Tue, 23 Dec 2014 13:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YT_QCkAAIHik for ; Tue, 23 Dec 2014 13:51:20 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49471A802A for ; Tue, 23 Dec 2014 13:51:20 -0800 (PST) Received: from localhost ([::1]:42714 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3XMO-0002Xy-Mw; Tue, 23 Dec 2014 13:51:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 21:51:20 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/13#comment:3 Message-ID: <076.a218f57461c8d1c4a09b3fc7bd8f9198@trac.tools.ietf.org> References: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kQSHP8DN2G_vcytV8nWv0nXqfRQ Cc: manet@ietf.org Subject: Re: [manet] #13 (dymo): Supporting monotonically nondecreasing but non-additive metrics X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 21:51:22 -0000 #13: Supporting monotonically nondecreasing but non-additive metrics Changes (by charliep@computer.org): * status: new => closed * resolution: => invalid Comment: On 6/24/2013 9:03 PM, Charles E. Perkins wrote: > In the absence of a convincing use case for enabling nondecreasing metrics, > and in view of the problems to insure loop freedom, I think it is safe to > close this issue without enabling the feature. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: enhancement | Status: closed Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: invalid Keywords: nondecreasing metrics | -----------------------------------+------------------------------ Ticket URL: manet From nobody Tue Dec 23 13:59:59 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708511A8708 for ; Tue, 23 Dec 2014 13:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Jlq2Vb70ok8M for ; Tue, 23 Dec 2014 13:59:55 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0AF71A86FE for ; Tue, 23 Dec 2014 13:59:55 -0800 (PST) Received: from localhost ([::1]:43208 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3XUh-0004vI-Hi; Tue, 23 Dec 2014 13:59:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 21:59:55 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/19#comment:1 Message-ID: <076.cab0be1456f84ae2cf17e3689ecc363e@trac.tools.ietf.org> References: <061.041f85b1a5a5f5cb4aab0f33174bca16@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <061.041f85b1a5a5f5cb4aab0f33174bca16@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/UbuJTE8xWcMPHDXxY0S1qZBm8Yg Cc: manet@ietf.org Subject: Re: [manet] #19 (aodvv2): Use of square brackets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 21:59:57 -0000 #19: Use of square brackets Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 4/11/2014 6:11 PM, Charles E. Perkins wrote: > Hello folks, > > Looking through other RFCs, I find three typical uses for square > brackets (among others): > > - Bibliographic citations (e.g, [RFC791]) > - Array indices (e.g, rfcs[790]) > - Ranges (e.g, [1..791]) > > I will make sure that the uses in the AODVv2 specification conform to the > above guidelines. Please let me know if there are places where it is not > clear whether or not square brackets enclose a citation cross-reference. > The range notation does not appear in the current document. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: task | Status: closed Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: notation | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Dec 23 14:02:21 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8302C1A8715 for ; Tue, 23 Dec 2014 14:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0UQ5FHeu0TJl for ; Tue, 23 Dec 2014 14:02:17 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9401A8714 for ; Tue, 23 Dec 2014 14:02:17 -0800 (PST) Received: from localhost ([::1]:43326 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3XWz-0005TS-L1; Tue, 23 Dec 2014 14:02:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 22:02:17 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/20#comment:1 Message-ID: <076.05f3e711f90e5f6641c1ea9409f11eaf@trac.tools.ietf.org> References: <061.38a7788f3dfe934d4b40ca8d7fd57c11@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <061.38a7788f3dfe934d4b40ca8d7fd57c11@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/i-5W9KCK_CYICM8FHr8P-_615ao Cc: manet@ietf.org Subject: Re: [manet] #20 (aodvv2): Idle routes must be marked as active after re-use X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:02:19 -0000 #20: Idle routes must be marked as active after re-use Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 4/11/2014 6:21 PM, Charles E. Perkins wrote: > Here is some proposed text to resolve this issue: ... > Proposal: after the text: >> When a route is no longer Active, it >> becomes an Idle route. > > The proposed text: >> If an Idle route is used to forward a packet, it becomes >> an Active route once again. > > > However, there may be a better solution which requires more extensive changes. > While the distinction between an active route and an idle route is interesting > to consider, the main difference between them is that an idle route is > preferred for deletion whenever space needs to be reclaimed. The same effect > can be had by specifying that route table memory space be reclaimed by > deleting the oldest routes first. I think this will produce some > simplification to the text without any real loss of clarity. ============================================================================ On 4/30/2014 2:44 AM, Martin Heusse wrote: > > Does this really belong to the protocol specification? To me, if a node runs > out of memory space, it's a local decision to remove a route or the other. > The protocol will still operate properly. Granted, it's more efficient if > everyone follows pretty much the same policy :-) > > Now, removing the oldest route may not be the best idea: it's not unlikely > that the first route a "node" creates is the most important! > > Maybe a statement like: "routers should discard routes in order of least > recent usage" could be enough? > (And then, you don't have to care about idle/inactive/active route status. > This information is not exchanged between nodes, anyway.) ============================================================================ On 5/28/2014 10:29 AM, Charles E. Perkins wrote: > > Hello Martin, > > Your points are well taken. However, the "active status" of a route > is important when determining whether or not to report it as > broken. Routes that are inactive don't need to be included in an > RERR message even if the next hop link is broken. The way that > AODVv2 determines whether a route is active or not, is by > keeping track of how recently it has been used. > > Less important, but still with some value, is the distinction > between idle routes and expired routes. An idle route can be > used to forward packets, and an expired route cannot. However, > even an expired route contains one valuable field, namely the > latest known sequence number. If there is no penalty, it can > be useful to keep that information in case there are some old > RREQ packets still being retransmitted (say, because of really > full queues at some nodes in the network). This situation is > rare, but Murphy's law demands that it happen sometimes. > I don't believe there is any significant penalty for trying to > prevent it. > > Finally, there comes a time when even the sequence number > is potentially harmful. This happens when it is so old that it > might have been duplicated by the node after rebooting. > It was shown some years ago that sequence numbers have to > be expunged after a time equal to the hold-down time for nodes > after reboot (MAX_SEQNUM_LIFETIME). ==================================================================== No further problems have been identified with this solution, so it is proposed to close the issue. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: closed Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: idle route | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Dec 23 14:25:43 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F3B1A8739 for ; Tue, 23 Dec 2014 14:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 j3wDhALMonjF for ; Tue, 23 Dec 2014 14:25:40 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA1A1A8033 for ; Tue, 23 Dec 2014 14:25:40 -0800 (PST) Received: from localhost ([::1]:44923 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3Xtb-0007hP-Kr; Tue, 23 Dec 2014 14:25:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 22:25:39 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/21#comment:2 Message-ID: <076.2428706820d2016b648d2cb6c3edb531@trac.tools.ietf.org> References: <061.815c8cc5567c8816898ef0373d66e50b@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <061.815c8cc5567c8816898ef0373d66e50b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rGkI-YiGQgDHC7_eOCWXlFnnnWo Cc: manet@ietf.org Subject: Re: [manet] #21 (aodvv2): Document hard to read X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:25:41 -0000 #21: Document hard to read Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 4/3/2014 4:46 PM, Abdussalam Baryun wrote: > I agree that that terminology can add aodvv2 packet definition but not needed. > The draft to use IP packet and aodvv2 packet if needed. My understanding is > that all packets in the draft are RFC5444 packets or aodvv2 packets, and > only if said IP packet. I think this was the method done in olsrv2 draft too. ============================================================================ On 4/3/2014 10:57 PM, Henning Rogge wrote: > On Fri, Apr 4, 2014 at 1:46 AM, Abdussalam Baryun > wrote: >> I agree that that terminology can add aodvv2 packet definition but not >> needed. The draft to use IP packet and aodvv2 packet if needed. My >> understanding is that all packets in the draft are RFC5444 packets or aodvv2 >> packets, and only if said IP packet. I think this was the method done in >> olsrv2 draft too. > > If you take the protocol multiplexing capabilities of RFC5444 serious > there is no such thing as a "AODVv2 packet"... there are "AODVv2 > messages" and "RFC5444 packets", which may contain messages from > multiple protocols (e.g. AODVv2 and NHDP messages in the same packet). ============================================================================ On 4/4/2014 12:10 AM, Abdussalam Baryun wrote: > > > On Friday, April 4, 2014, Henning Rogge wrote: > .... > > If you take the protocol multiplexing capabilities of RFC5444 serious > there is no such thing as a "AODVv2 packet"... > > The RFC5444 as I understood when I read it before that it was not mentioning > the way it was implemented or way of filling its formats. There was a > discussion in one WG meeting between Teco and Thomas before submitting > packetbb draft, mentioning the missing issue, which the WG chair mentioned > that some one should volunteer to do that work. So IMO there may be no > thing agreed on in the WG about the general RFC5444 packet multiplexing. > > there are "AODVv2 > messages" and "RFC5444 packets", which may contain messages from > multiple protocols (e.g. AODVv2 and NHDP messages in the same packet). > > So I understand you suggest only one packet for all protocols and not having > AODVv2 packet. ============================================================================ On 4/4/2014 12:53 AM, Ulrich Herberg wrote: > I think that what Henning describes is fairly well understood in the WG. > I have never heard anyone else having an issue with it. As Henning said > correctly, there are no AODVv2 packets, only RFC5444 packets that may > contain AODVv2 (and other) messages. ============================================================================ On 4/4/2014 1:07 AM, Henning Rogge wrote: > There is also Appendix A of RFC5444 that explains the multiplexing part. ============================================================================ On 4/4/2014 1:46 AM, Dearlove, Christopher (UK) wrote: > And RFC 5498 mandates its use on the manet port/protocol. So it is a > must get right. ============================================================================ On 4/4/2014 1:10 PM, Abdussalam Baryun wrote: > In RFC5444 it mentions that each protocol defines its format. The RFC5444 > is a general format for packets and messages. ============================================================================ On 4/11/2014 4:40 PM, Charles E. Perkins wrote: > I will adjust the text to use "AODVv2 message" instead of "AODVv2 packet" > whenever feasible, or use some other wording if "message" does not fit. =========================================================================== While readability issues may remain, the particular problem discussed in this issue has been resolved and further difficulties have not be observed. Additional readability issues should be identified as part of new issues, and it is proposed that this issue be closed. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: closed Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Dec 23 14:28:02 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509FF1A877F for ; Tue, 23 Dec 2014 14:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xaETXNHz36hC for ; Tue, 23 Dec 2014 14:27:59 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4CA1A8764 for ; Tue, 23 Dec 2014 14:27:59 -0800 (PST) Received: from localhost ([::1]:44994 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3Xvr-0000P4-Ft; Tue, 23 Dec 2014 14:27:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 22:27:59 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/22#comment:2 Message-ID: <076.13edd42c39804fba61f5eb7e59d039ea@trac.tools.ietf.org> References: <061.04d6856ca1d9c40a9ad288f003eeb91f@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <061.04d6856ca1d9c40a9ad288f003eeb91f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/65ju5DLnewEHCk0fDpE7AKcZr9k Cc: manet@ietf.org Subject: Re: [manet] #22 (aodvv2): Multiple terms for same concept X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:28:01 -0000 #22: Multiple terms for same concept Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 4/4/2014 1:32 PM, Abdussalam Baryun wrote: > IMHO, MANET has more concepts depending on the network use and status. Therefore it is good that this work considers many use cases. > > On Thursday, April 3, 2014, manet issue tracker wrote: > > #22: Multiple terms for same concept > > (Thomas Clausen) While we are on that, I notice that "active source" is > used; I am not sure what that is vs a "source" and vs a !PktSource. > > It is clear in MANET that active node means there is sleep period within that node, so when the node is out of that period it is active. > > A > source is someone who generates data traffic, I would suspect ... so an > active source is....what? Or, is a source someone who can, but doesn't, > generate data traffic? > > The source is a node that generates data. The active node is a node that generates data for some determined period of times, and does not receive/generate within sleeping periods. > > > if so, what is the significance of that wrt. > routing protocol operation? And, wrt a /reactive/ routing protocol, which > I would assume constructs routes only for active source-destination pairs? > > I don't think that is correct. In MANET we say it MAY have LLN nodes so it is good AODVv2 considers LLNs scenarios. The ROLL WG have done a terminology RFC, I will try to continue the Manet terminology draft. The routing in LLNs and MANETs does construct routes not only for active source-destination pairs, but routes that have multihops with sleep periods as well. ============================================================================ On 4/5/2014 5:46 AM, Thomas Clausen wrote: > On 04 Apr 2014, at 22:32, Abdussalam Baryun wrote: >> IMHO, MANET has more concepts depending on the network use and status. Therefore it is good that this work considers many use cases. >> >> On Thursday, April 3, 2014, manet issue tracker wrote: >> >> #22: Multiple terms for same concept >> >> (Thomas Clausen) While we are on that, I notice that "active source" is >> used; I am not sure what that is vs a "source" and vs a !PktSource. >> >> It is clear in MANET that active node means there is sleep period within that node, so when the node is out of that period it is active. > That is not clear to me. Where is that described in more details? How does it work in a reactive protocol, what if a router is "sleeping" when it receives a RREQ? Does it require global coordination of duty cycles in the network? If not, why not? >> >> A >> source is someone who generates data traffic, I would suspect ... so an >> active source is....what? Or, is a source someone who can, but doesn't, >> generate data traffic? >> >> The source is a node that generates data. The active node is a node that generates data for some determined period of times, and does not receive/generate within sleeping periods. >> >> >> if so, what is the significance of that wrt. >> routing protocol operation? And, wrt a /reactive/ routing protocol, which >> I would assume constructs routes only for active source- destination pairs? >> >> I don't think that is correct. > You do not think that it is correct, that a reactive protocol constructs routes only for active source-destination pairs? >> In MANET we say it MAY have LLN nodes so it is good AODVv2 considers LLNs scenarios. The ROLL WG have done a terminology RFC, I will try to continue the Manet terminology draft. The routing in LLNs and MANETs does construct routes not only for active source-destination pairs, but routes that have multihops with sleep periods as well. > I am at a loss, what does that mean? ============================================================================ On 4/11/2014 4:34 PM, Charles E. Perkins wrote: > PktSource means the source of the packet that triggered > the RERR. It could be renamed to be "RERR_Dest", since the > RERR is being sent to the source of the packet that triggered > the RERR. > > "active sources" are those actively sending data. I will make > a new definition for this. ============================================================================ On 5/28/2014 11:09 AM, Charlie Perkins wrote: > It turns out to be quite straightforward to revise the text > so that the term "active source" is not needed. So, I don't > need to make a definition for this term. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: closed Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Dec 23 14:29:11 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F0C1A9145 for ; Tue, 23 Dec 2014 14:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rkD-WpwwMwkl for ; Tue, 23 Dec 2014 14:29:08 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54481A877F for ; Tue, 23 Dec 2014 14:29:08 -0800 (PST) Received: from localhost ([::1]:45037 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3Xwy-00055S-PB; Tue, 23 Dec 2014 14:29:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 22:29:08 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/23#comment:2 Message-ID: <076.e30d64dbf8c521aa090b451fc52dc7ab@trac.tools.ietf.org> References: <061.e1f82be4db481380244914bbd13719fc@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <061.e1f82be4db481380244914bbd13719fc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Qg9oJI4zIzduLqL6UM8A-TmY_Nw Cc: manet@ietf.org Subject: Re: [manet] #23 (aodvv2): Format of processing algorithms X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:29:10 -0000 #23: Format of processing algorithms Comment (by charliep@computer.org): On 4/3/2014 5:00 PM, Abdussalam Baryun wrote: > That method of describing conditions are not similar way followed in RFC3561. The below uses more lines in the draft, but not sure what is problem with the current method used. ============================================================================ On 4/3/2014 11:13 PM, Henning Rogge wrote: > On 04/04/2014 02:00 AM, Abdussalam Baryun wrote: >> That method of describing conditions are not similar way followed >> in RFC3561. The below uses more lines in the draft, but not sure what is >> problem with the current method used. > > Algorithmic descriptions as large text blocks (instead of bullet lists > with short statements) are more easy to interpret in different ways, > which opens the door for incompatible implementations. ============================================================================ On 4/4/2014 4:39 PM, Abdussalam Baryun wrote: > I went through this discussion before on the IETF list and the answer was no, it is more better to use a simple text, and not use simple bullet points. ============================================================================ On 4/7/2014 12:27 PM, Abdussalam Baryun wrote: > http://www.ietf.org/mail-archive/web/ietf/current/msg76625.html > That reference may not get the same understanding I got. But I understood from that thread discussion and others the reason why specification drafts go better for sentence text than go for sequence points. ============================================================================ On 4/11/2014 4:23 PM, Charles E. Perkins wrote: > The point of the specification is to enable interoperable implementations,. > Some people prefer a short stepwise description of the algorithm, and some > people prefer to read (unambiguous) text describing each step in more > detail. I don't see why the specification cannot satisfy both groups. > I will develop the formulation with short statements as requested. ============================================================================ On 6/17/2014 5:51 AM, Lotte Steenbrink wrote: > I am aware of that. My point is: while I appreciate your hard work to move > the spec to another level, unfortunately I don't understand the purpose of > your pseudocode efforts. The only explanation I was able to come up with > was that the pseudocode was a reaction to the remark by Thomas Heide Clausen > that you put into the issue tracker, in which case, I'd say I'd interpret > it differently... -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Dec 23 14:30:15 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2121A8774 for ; Tue, 23 Dec 2014 14:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 h7CvtBvOsuqQ for ; Tue, 23 Dec 2014 14:30:13 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025961A8773 for ; Tue, 23 Dec 2014 14:30:13 -0800 (PST) Received: from localhost ([::1]:45089 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3Xy0-0006il-N2; Tue, 23 Dec 2014 14:30:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 22:30:12 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/24#comment:2 Message-ID: <076.980e238e2d650e5a2337175ca598651b@trac.tools.ietf.org> References: <061.0f44444abc85a02d639ffe2f7780652e@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <061.0f44444abc85a02d639ffe2f7780652e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Qv87RVpnSiSO-uFWjoBj0YsAtcY Cc: manet@ietf.org Subject: Re: [manet] #24 (aodvv2): Ordering of processing instructions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:30:14 -0000 #24: Ordering of processing instructions Comment (by charliep@computer.org): On 4/13/2014 11:43 AM, Abdussalam Baryun wrote: > > > On Thursday, April 3, 2014, manet issue tracker wrote: > > #24: Ordering of processing instructions > > if I was to implement the processing of an incoming RREQ message, which > section should I implement? > > Usually the way I do it is to implement all sections that include the > handling of RREQ. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Dec 23 14:31:51 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1891A8777 for ; Tue, 23 Dec 2014 14:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QSePEhkH40sS for ; Tue, 23 Dec 2014 14:31:49 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36701A878B for ; Tue, 23 Dec 2014 14:31:48 -0800 (PST) Received: from localhost ([::1]:45162 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3XzY-00070u-IR; Tue, 23 Dec 2014 14:31:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 22:31:48 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/25#comment:2 Message-ID: <076.b3c499065b5509265e2bbe2ad646dbce@trac.tools.ietf.org> References: <061.79acdb18cee1af055ed1783b3a78c335@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <061.79acdb18cee1af055ed1783b3a78c335@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/4D6Ebsn386VsWq5ZLw542zuAhrI Cc: manet@ietf.org Subject: Re: [manet] #25 (aodvv2): Meaning of "suppose" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:31:50 -0000 #25: Meaning of "suppose" Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 4/3/2014 5:07 PM, Abdussalam Baryun wrote: > My understanding is that suppose means *IF*. So may be we suggest to > replace suppose to if. ============================================================================ On 4/11/2014 4:21 PM, Charles E. Perkins wrote: > The word only appears twice in the specification. It won't be hard to replace > with an equivalent meaning. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: closed Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Dec 23 14:35:15 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CD81A701D for ; Tue, 23 Dec 2014 14:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qMHwtXmHw4my for ; Tue, 23 Dec 2014 14:35:11 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9431A8798 for ; Tue, 23 Dec 2014 14:35:11 -0800 (PST) Received: from localhost ([::1]:45294 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3Y2p-0007oh-0f; Tue, 23 Dec 2014 14:35:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 22:35:10 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/28#comment:2 Message-ID: <076.933c039488e0b0d08ed2b2e72c493136@trac.tools.ietf.org> References: <061.41eddfaea8f2746f1b4be31a039eeeae@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <061.41eddfaea8f2746f1b4be31a039eeeae@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/oDLf_DkDKL3NKgn-ti5hibj04F0 Cc: manet@ietf.org Subject: Re: [manet] #28 (aodvv2): Routers with multiple interfaces X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:35:12 -0000 #28: Routers with multiple interfaces Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 4/18/2014 4:48 PM, Charles E. Perkins wrote: > Hello folks, > > AODVv2 does support multiple interfaces. Multi-homing is a separate > issue from supporting multiple interfaces. >> #28: Routers with multiple interfaces >> >> (Thomas Clausen) It seems that the protocol does not support routers with >> multiple interfaces. ... > > .... >> Multi-homing is difficult unless the sequence number is >> expanded to include the AODVv2 router's IP address as well as Seqnum. >> Otherwise, comparing sequence numbers would not work to evaluate >> freshness. Even when the IP address is included, there isn't a good >> way to compare sequence numbers from different IP addresses, but at >> least a handling node can determine whether the two given sequence >> numbers are comparable. If the route table can store multiple routes >> for the same destination, then multi-homing can work with sequence >> numbers augmented by IP addresses. > > The paragraph preceding this one in the draft provides context > for this, making clear that this paragraph's discussion specifies > that AODVv2 does not provide multi-homing for subnets. I will > move the discussion about what is needed for multi-homing into > an appendix (not normative), for the purpose of assisting future > designers of derivative reactive protocols. This should eliminate > the confusion. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: closed Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Dec 23 14:38:32 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BCD1A87A3 for ; Tue, 23 Dec 2014 14:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qhxiiYT2pOCt for ; Tue, 23 Dec 2014 14:38:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2941A87A0 for ; Tue, 23 Dec 2014 14:38:26 -0800 (PST) Received: from localhost ([::1]:45417 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y3Y5x-0008La-RL; Tue, 23 Dec 2014 14:38:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 23 Dec 2014 22:38:25 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/29#comment:2 Message-ID: <076.a45f06071b1cec71d556211b45deb62e@trac.tools.ietf.org> References: <061.235f8637e3c7cb9456d361d8404ef4c1@trac.tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <061.235f8637e3c7cb9456d361d8404ef4c1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Ds-YM_qXTz4WMHGyFfoL3XMNqGQ Cc: manet@ietf.org Subject: Re: [manet] #29 (aodvv2): Choice of IP address X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:38:29 -0000 #29: Choice of IP address Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 4/24/2014 9:24 AM, Charles E. Perkins wrote: > On 4/3/2014 2:19 PM, manet issue tracker wrote: >> #29: Choice of IP address >> >> (Thomas Clausen) In a great many places, it is stated "IP address of the >> (node, Adjacent Node, Adjacent Router) sending the message". If a router >> has multiple interfaces, and/or if these interfaces have multiple >> addresses, which of these (any? one matching the interface over which the >> message is sent?) should be used or assumed here? The relationship >> node/interface/address is, at best, unclear. It seems to me that this >> specification is written with the assumption that each router has >> *exactly* one interface participating in the routing protocol, with >> *exactly* one IP address - and that that router *never* use anything but >> that IP Address for anything. > > When an application launches and has to send packets to a > destination, the application selects a source IP address. > > That IP address is used by AODVv2 to indicate the originating > node, when initiating the Route Discovery operation (in the > case that a route to the intended destination is not found in > the route table). > > When intermediate routers disseminate AODVv2 control > messages, they can use any IP address that is convenient > for the interface transmitting the message, as long as that > address is unique from the standpoint of the receiver(s). > Since the nodes are mobile, link-local addresses should be > excluded from use for this purpose. I will clarify that in the > draft. If, somehow outside the scope of the draft, it is > known that link-local addresses are unique for all time > for all ad hoc nodes that may enter the ad hoc network, > then perhaps that restriction could be disregarded, but > uniqueness is tough to guarantee for arbitrary mobile > nodes that might come into contact. > > I will re-read the draft to see how to prevent the inference > that an interface can only have one IP address. >> >> If that is correct, then it should be written clearly in the applicability >> statement that multiple interfaces and multiple addresses are *NOT* >> supported, and that this protocol MUST NOT be used in deployments where >> any router can have more than one interface or more than one IP Address. >> >> If that's not true, then a major rework of the protocol and the >> specification is required. > > As far as I can tell, there is not really a problem here. ============================================================================ On 4/24/2014 10:05 AM, Thomas Heide Clausen wrote: > On 24 Apr 2014, at 18:24 , Charles E. Perkins wrote: >> On 4/3/2014 2:19 PM, manet issue tracker wrote: >>> #29: Choice of IP address >>> >>> (Thomas Clausen) In a great many places, it is stated "IP address of the >>> (node, Adjacent Node, Adjacent Router) sending the message". If a router >>> has multiple interfaces, and/or if these interfaces have multiple >>> addresses, which of these (any? one matching the interface over which the >>> message is sent?) should be used or assumed here? The relationship >>> node/interface/address is, at best, unclear. It seems to me that this >>> specification is written with the assumption that each router has >>> *exactly* one interface participating in the routing protocol, with >>> *exactly* one IP address - and that that router *never* use anything but >>> that IP Address for anything. > Just reflecting on what is quoted here, and without looking back at the I-D, > talking about "the IP address of the adjacent node/router" very clearly > indicates that the "adjacent node/router" has exactly one IP address (or, > at least, uses exactly one IP address when participating in this routing > domain). >> When an application launches and has to send packets to a >> destination, the application selects a source IP address. > User applications run on hosts, not on routers. So, that with which we are > concerned should be exclusively "when a router receives an IP Datagram, > with a given source and destination address".... >> That IP address is used by AODVv2 to indicate the originating >> node, when initiating the Route Discovery operation (in the >> case that a route to the intended destination is not found in >> the route table). > So, this routing protocol precludes the presence of hosts in the network? > Or, requires that all hosts also run (parts of) this routing protocol? Or > the router with an attached host is expected to generate RREQs with the > source address of the host as "source address" (i.e., IP spoofing)? In the > latter case, are RREP/RERRs sent "to" the IP Address (i.e., with that as > destination address) of the host (outside the routing domain)? >> When intermediate routers disseminate AODVv2 control >> messages, they can use any IP address that is convenient >> for the interface transmitting the message, as long as that >> address is unique from the standpoint of the receiver(s). > Just so that it is clear, that "convenient" IP address is used for what? > The source IP address for the datagram that carries an RFC5444 packet? Or, > something else.... > Also, what happens in the case where A and B both have two interfaces > (a1, a2) and (b1, b2) and all 4 interfaces can communicate with each other > (so a1-b1, a1-b2, a2-b1, a2-b2)? > Any way for A to identify that b1 and b2 is, in fact, the same router? Are > the consequences, if the answer is "there is no way" thought completely > through? >> Since the nodes are mobile, > s/node/router ============================================================================ On 4/25/2014 7:54 AM, Teco Boot wrote: > > Op 24 apr. 2014, om 19:05 heeft Thomas Heide Clausen > het volgende geschreven: ......... >> On 24 Apr 2014, at 18:24 , Charles E. Perkins wrote: ......... >>> When an application launches and has to send packets to a >>> destination, the application selects a source IP address. >> User applications run on hosts, not on routers. > > ??? > > Teco > > (sent from router :-)) ============================================================================ On 4/27/2014 3:29 PM, Jiazi YI wrote: > > > On Fri, Apr 25, 2014 at 4:54 PM, Teco Boot wrote: > > > Op 24 apr. 2014, om 19:05 heeft Thomas Heide Clausen > het volgende geschreven: > > User applications run on hosts, not on routers. > ??? > > Teco > > (sent from router :-)) > > Or, I would rather say, a machine that runs as a host (when you are sending > the mail above). The same machine may connect several networks and forward > packets for others - and it plays as a router :) ============================================================================ On 4/27/2014 10:01 PM, Teco Boot wrote: > > Op 28 apr. 2014, om 00:29 heeft Jiazi YI > het volgende geschreven: >> Or, I would rather say, a machine that runs as a host (when you are sending >> the mail above). The same machine may connect several networks and forward >> packets for others - and it plays as a router :) > The node is a router. It doesn’t run as a host. > > Teco ============================================================================ On 4/28/2014 12:10 AM, Thomas Heide Clausen wrote: > Teco, don't read something from my mail, which I didn't write.. > > As I think I have said repeatedly, "host" implies that certain relatively > well defined characteristics (interface configuration, connectivity > properties, etc.) are presented to applications. > > Some applications -- possibly, your email client -- can also function when > presented with other characteristics. Good for them, but that doesn't make > it true for all. > > Some routers - possibly the one you have at hand - are facing characteristics > that are identical to those of a "host". Good for them, also, but that also > doesn't make it true for all. ============================================================================ On 4/28/2014 12:53 AM, Teco Boot wrote: > Can you refer to a document that describes "certain relatively well defined > characteristics� > > Are you aware of applications that doesn’t run wel on routers? What are the > problems? > > Teco ============================================================================ On 4/28/2014 2:39 AM, Teco Boot wrote: > > Op 28 apr. 2014, om 09:59 heeft Thomas Heide Clausen > het volgende geschreven: > >> >>> On 28 avr. 2014, at 09:53, Teco Boot wrote: >>> >>> Can you refer to a document that describes "certain relatively well >>> defined characteristics� >> >> Sadly, I do not think that a single such document exists - remember the >> debacles in this area in [autoconf]? > > Then, use RFC 1122. Defines multi-homed hosts and strong and weak host model. > >> >>> Are you aware of applications that doesn’t run wel on routers? What are >>> the problems? >> >> I can think of applications that doesn't run well on interfaces, common in >> routers -- such as those we see in MANETS (lacking transitivity, for example). > > I think you mix up things. Apps can run on host and routers. Routers forward > packets, hosts do not. Thats all. ========================================================================== Recent revisions of the specification should make this clear. The distinction between hosts and routers may be determined to properly belong as a separate issue if further discussion is needed. Therefore it is proposed to close this issue. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: closed Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Wed Dec 24 07:56:35 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E97D1A8A85 for ; Wed, 24 Dec 2014 07:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 huJJoLJiVFq2 for ; Wed, 24 Dec 2014 07:56:31 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9312C1A8A7F for ; Wed, 24 Dec 2014 07:56:31 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id sBOFuUC6012723 for ; Wed, 24 Dec 2014 10:56:30 -0500 From: "Cheng, Bow-Nan - 0665 - MITLL" To: "manet@ietf.org" Thread-Topic: DLEP Draft 7 Router Initiate Peer Discovery Thread-Index: AQHQH5IuAEDY3MrTNUSkA9FBU2kXRw== Date: Wed, 24 Dec 2014 15:56:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [172.26.144.54] Content-Type: multipart/alternative; boundary="_000_D0C04C6A13C00bchengllmitedu_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-24_04:2014-12-24,2014-12-24,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412240161 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/J4qYp9gfSSlAu7NSw8ZNL0Lh4No Subject: [manet] DLEP Draft 7 Router Initiate Peer Discovery X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 15:56:33 -0000 --_000_D0C04C6A13C00bchengllmitedu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I=92ve been a little out of the loop on DLEP recently and looked at Draft 7= . One thing I was confused about was the change from Modem initiated peer d= iscovery to Router initiated peer discovery and was wondering what the rati= onal was for the change? In the past when we=92ve operated DLEP, we always had the assumption that 1= DLEP Router/server process could support multiple DLEP modem/client connec= tions off the same Ethernet VLAN (or bridged interface as we were operating= it). In this case, it made sense for the modem to initiate the peer discov= ery because at any time, another modem/radio could be =93turned on=94 and = =93discover=94 the DLEP router and initiate a new connection. How would thi= s work with the router initiating the peer discovery? Would the router need= to periodically initiate peer discovery so modems that =93turn on=94 can f= ind it? Would this mess up normal DLEP session flow? Is the implicit assumption now that 1 DLEP router/server process will conne= ct to only 1 DLEP modem/client process? So then, each modem/router would es= sentially need to be on its own interface or subnet and you would need some= sort of virtual interface to gang them all up to the router. In this case,= I can understand having the router initiate peer discovery. Maybe I=92m mi= ssing something. Any clarification would be of great help. Thanks!! -Bow-Nan --_000_D0C04C6A13C00bchengllmitedu_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi all,

I=92ve been a little out of the loop on DLEP recently and looked at Dr= aft 7. One thing I was confused about was the change from Modem initiated p= eer discovery to Router initiated peer discovery and was wondering what the= rational was for the change? 

In the past when we=92ve operated DLEP, we always had the assumption t= hat 1 DLEP Router/server process could support multiple DLEP modem/client c= onnections off the same Ethernet VLAN (or bridged interface as we were oper= ating it). In this case, it made sense for the modem to initiate the peer discovery because at any time, another = modem/radio could be =93turned on=94 and =93discover=94 the DLEP router and= initiate a new connection. How would this work with the router initiating = the peer discovery? Would the router need to periodically initiate peer discovery so modems that =93turn on=94 can f= ind it? Would this mess up normal DLEP session flow?

Is the implicit assumption now that 1 DLEP router/server process will = connect to only 1 DLEP modem/client process? So then, each modem/router wou= ld essentially need to be on its own interface or subnet and you would need= some sort of virtual interface to gang them all up to the router. In this case, I can understand having t= he router initiate peer discovery. Maybe I=92m missing something.

Any clarification would be of great help. Thanks!!

-Bow-Nan

--_000_D0C04C6A13C00bchengllmitedu_-- From nobody Thu Dec 25 13:04:43 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274561A8865 for ; Thu, 25 Dec 2014 13:04:41 -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 jvoSFNxzskB2 for ; Thu, 25 Dec 2014 13:04:39 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92BA1A1AAA for ; Thu, 25 Dec 2014 13:04:38 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so16001616wiw.10 for ; Thu, 25 Dec 2014 13:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=32gYwLxsVhAiecttHXzsZqxgCuFcYZjBpmNtivDe00Q=; b=a5zTDqjcX0sDhlDtBYBKWhiSS1DAzmgjWPb6bpY0ft02KT1ox7nf7TxicKoDVjKvJQ NafLyldYkomi3FzpN/DcOa+Iaz4qtUvSAhI1Y7rXvb9K3usp8JYLRYPhhNY2oCi+XF+c b1OvJhiy2F+LOOf4MM9y+WMe3rpijB9fvW5fcTT6EfnUMcZ1+nhoEL0b/OKxxLVhB7QZ bY7dYE2hHolHR68d8gr4Xl75MlNMhPvunqIcThLlrkFLg9drRmDzQ4ehaZOoEMQnOpLz PSBK/t6asQ/53ufKaiH5uRFJretnDzAvUzuPzGtLs2qkEDwOnSjruOId/ZzS1bRC5lZl mBuA== X-Received: by 10.180.210.236 with SMTP id mx12mr64000561wic.16.1419541477564; Thu, 25 Dec 2014 13:04:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.10.66 with HTTP; Thu, 25 Dec 2014 13:04:17 -0800 (PST) In-Reply-To: References: From: Henning Rogge Date: Thu, 25 Dec 2014 22:04:17 +0100 Message-ID: To: "Cheng, Bow-Nan - 0665 - MITLL" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/e2txYJvXyKoA77K82j8VCwCneio Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Draft 7 Router Initiate Peer Discovery X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 21:04:41 -0000 On Wed, Dec 24, 2014 at 4:56 PM, Cheng, Bow-Nan - 0665 - MITLL wrote: > Hi all, > > I=E2=80=99ve been a little out of the loop on DLEP recently and looked at= Draft 7. > One thing I was confused about was the change from Modem initiated peer > discovery to Router initiated peer discovery and was wondering what the > rational was for the change? It was a compromise between the authors/design-team in London... both variants could work, lets not reopen this discussion unless its absolutely necessary. > In the past when we=E2=80=99ve operated DLEP, we always had the assumptio= n that 1 > DLEP Router/server process could support multiple DLEP modem/client > connections off the same Ethernet VLAN (or bridged interface as we were > operating it). In this case, it made sense for the modem to initiate the > peer discovery because at any time, another modem/radio could be =E2=80= =9Cturned on=E2=80=9D > and =E2=80=9Cdiscover=E2=80=9D the DLEP router and initiate a new connect= ion. How would this > work with the router initiating the peer discovery? Would the router need= to > periodically initiate peer discovery so modems that =E2=80=9Cturn on=E2= =80=9D can find it? > Would this mess up normal DLEP session flow? You could just keep sending discovery UDP multicasts by the router, even if you got a session. No, it would not mess up the session flow because the radios that are already in session would ignore the incoming multicast. > Is the implicit assumption now that 1 DLEP router/server process will > connect to only 1 DLEP modem/client process? My implementation (as an example) can connect to one DLEP radio per interface its connected to... > So then, each modem/router > would essentially need to be on its own interface or subnet and you would > need some sort of virtual interface to gang them all up to the router. In > this case, I can understand having the router initiate peer discovery. Ma= ybe > I=E2=80=99m missing something. If you use VLANs to bundle multiple radios to a single router ethernet port, each of the VLANs would have its own virtual interface in the router. Henning Rogge From nobody Thu Dec 25 15:02:17 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E0D1A1AE0 for ; Thu, 25 Dec 2014 15:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 HQMfLh6RjW9e for ; Thu, 25 Dec 2014 15:02:14 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id D4C851A1ADF for ; Thu, 25 Dec 2014 15:02:13 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id sBPN2B9L029116; Thu, 25 Dec 2014 18:02:11 -0500 From: "Cheng, Bow-Nan - 0665 - MITLL" To: Henning Rogge Thread-Topic: [manet] DLEP Draft 7 Router Initiate Peer Discovery Thread-Index: AQHQH5IuAEDY3MrTNUSkA9FBU2kXR5yhIV2A///NMoA= Date: Thu, 25 Dec 2014 23:02:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [172.26.147.190] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1464CDFF7231494A9C3260689117F92E@ll.mit.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-25_06:2014-12-24,2014-12-25,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412250250 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-8rKNaooQPIynGqprc65qoy-5wQ Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Draft 7 Router Initiate Peer Discovery X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 23:02:16 -0000 Thanks Henning, Regarding re-opening the discussion on router initiated peer discovery. It sounds counter-intuitive to me, but I=B9m not hard opposed to it.. I was just wondering the rational behind it was. I suspect that more people may be confused by this change and was hoping it could be captured somewhere on the list to point at. -Bow-Nan On 12/25/14, 4:04 PM, "Henning Rogge" wrote: >On Wed, Dec 24, 2014 at 4:56 PM, Cheng, Bow-Nan - 0665 - MITLL > wrote: >> Hi all, >> >> I=B9ve been a little out of the loop on DLEP recently and looked at Draf= t >>7. >> One thing I was confused about was the change from Modem initiated peer >> discovery to Router initiated peer discovery and was wondering what the >> rational was for the change? > >It was a compromise between the authors/design-team in London... both >variants could work, lets not reopen this discussion unless its >absolutely necessary. > >> In the past when we=B9ve operated DLEP, we always had the assumption tha= t >>1 >> DLEP Router/server process could support multiple DLEP modem/client >> connections off the same Ethernet VLAN (or bridged interface as we were >> operating it). In this case, it made sense for the modem to initiate the >> peer discovery because at any time, another modem/radio could be >>=B3turned on=B2 >> and =B3discover=B2 the DLEP router and initiate a new connection. How wo= uld >>this >> work with the router initiating the peer discovery? Would the router >>need to >> periodically initiate peer discovery so modems that =B3turn on=B2 can fi= nd >>it? >> Would this mess up normal DLEP session flow? > >You could just keep sending discovery UDP multicasts by the router, >even if you got a session. > >No, it would not mess up the session flow because the radios that are >already in session would ignore the incoming multicast. > >> Is the implicit assumption now that 1 DLEP router/server process will >> connect to only 1 DLEP modem/client process? > >My implementation (as an example) can connect to one DLEP radio per >interface its connected to... > >> So then, each modem/router >> would essentially need to be on its own interface or subnet and you >>would >> need some sort of virtual interface to gang them all up to the router. >>In >> this case, I can understand having the router initiate peer discovery. >>Maybe >> I=B9m missing something. > >If you use VLANs to bundle multiple radios to a single router ethernet >port, each of the VLANs would have its own virtual interface in the >router. > >Henning Rogge From nobody Tue Dec 30 13:43:17 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C801A1BB7 for ; Tue, 30 Dec 2014 13:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 wmR5DSx44L21 for ; Tue, 30 Dec 2014 13:43:14 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14981A1BB5 for ; Tue, 30 Dec 2014 13:43:14 -0800 (PST) Received: from localhost ([::1]:40237 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y64ZN-000123-Ua; Tue, 30 Dec 2014 13:43:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 30 Dec 2014 21:43:13 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/39#comment:2 Message-ID: <084.254267546260e7b1bcfcfe9769eb9845@trac.tools.ietf.org> References: <069.68e0b0b941aac1c81466bb9638f9ccca@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <069.68e0b0b941aac1c81466bb9638f9ccca@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/MBMCJEgnGQtLKCXLKUN19EnUUb4 Cc: manet@ietf.org Subject: Re: [manet] #39 (aodvv2): Route.Broken flag redundant X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 21:43:15 -0000 #39: Route.Broken flag redundant Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 4/11/2014 4:24 PM, Charlie Perkins wrote: > This is a good point. The terminology of a "broken flag" seems to be a holdover > from a long time ago, and would indicate that the route table entry is in a > "broken" state. I'll eliminate the "broken flag" terminology. The flag has been eliminated, and it seems the issue can be safely closed. -- -------------------------------------------+------------------------------- Reporter: lotte.steenbrink@fu-berlin.de | Owner: Type: defect | charliep@computer.org Priority: minor | Status: closed Component: aodvv2 | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: fixed -------------------------------------------+------------------------------- Ticket URL: manet From nobody Tue Dec 30 14:05:43 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93541A8777 for ; Tue, 30 Dec 2014 14:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 eYJ4dqFRk9gD for ; Tue, 30 Dec 2014 14:05:10 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB2A1A8773 for ; Tue, 30 Dec 2014 14:05:10 -0800 (PST) Received: from localhost ([::1]:41320 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y64ub-0006vy-ES; Tue, 30 Dec 2014 14:05:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 30 Dec 2014 22:05:09 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/48#comment:1 Message-ID: <076.9663e4324dee7dd2fcc9f96b251edf2a@trac.tools.ietf.org> References: <061.3cfbf986721b12801014840c19f319a2@trac.tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <061.3cfbf986721b12801014840c19f319a2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/oJxH6MJITiXDfjCcOY7zchYzmrI Cc: manet@ietf.org Subject: Re: [manet] #48 (aodvv2): Single address per interface per router (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 22:05:26 -0000 #48: Single address per interface per router (submitted for Chris Dearlove) Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 7/20/2014 9:45 PM, Charles E. Perkins wrote: > AODVv2 does not impose this restriction. It has, for a long time, > enabled multiple router addresses per interface. I will look again, > but as of now I do not see where any such restriction has been > imposed. If you have identified where this restriction is implied > or stated directly, please let me know as soon as possible. > > Unnumbered interfaces have never been suggested as appropriate > for inclusion of the feature set for any reactive protocol that was > under consideration within [manet], all the way since the very > initiation of the working group. At least not within my memory. ----------------------------------------------------------------------- On 7/22/2014 6:22 AM, Henning Rogge wrote: > On 07/22/2014 03:18 PM, Thomas Heide Clausen wrote: >> >>> On 22 Jul 2014, at 14:39 , Dearlove, Christopher (UK) >>> > >>> wrote: >>> >>> In at least one place in the draft (sorry, I don't have the time to >>> find it again now) it explicitly says one address per interface. >>> >> >> Not sure if this is the place that Chris is thinking of, but in my >> review I encountered things such as: >> >> Blacklist.Node >> The IP address of the node that did not verify bidirectional >> connectivity. >> >> >> Which looks like it is assumed that a “node†(I assume that this means >> “router†and will be fixed in a coming version, as has been requested >> multiple times) has a single IP address (that’s what the use of the >> definite article implies, is it not?) >> >> Also: >> >> AODVv2 supports routers with >> multiple interfaces, as long as each interface has its own (unicast >> routeable) IP address >> >> >> “address†- singular, not plural. >> >> There were other instances of such, these were just the first I saw when >> glancing over my review. > > Just a thought, > > does this mean we cannot run AODVv2 with IPv6 linklocal addresses? In > the presence of VLAN interfaces these addresses can be the same for > multiple interfaces of the same node. ------------------------------------------------------------------------- On 7/22/2014 9:14 AM, Charles E. Perkins wrote: > OLSRv2 is much more demanding regarding the determination of which > IP addresses belong to which routers. Basically, AODVv2 does not care. > DSR did not care either. In fact, I am not aware of any reactive protocol > for which this was ever an issue. What matters is the establishment of > a routing path from source to destination. > > I will fix the wording about handling blacklisted addresses as suggested. > If you have other instances, please do not hesitate to point them out. > On 7/22/2014 6:50 AM, Dearlove, Christopher (UK) wrote: >> >> The second of these was the point I had in mind. The first is an associated issue. >> >> >> >> There are various complexities in OLSRv2 that relate to addressing of interfaces (not shared between routers, but possibly shared between interfaces) and gateways (can overlap and share). We think we got them right (though without a formal proof, so it’s possible we missed something – I think we caught one right at the last post-IESG point). But some took some work. --------------------------------------------------------------------------- The draft has been modified to resolve the ambiguities mentioned above as well as others with similar sentence structures. There are not currently any known such ambiguities, and so it seems reasonable to close this issue. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: closed Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: Router addressability | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Dec 30 14:17:36 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB311A877D for ; Tue, 30 Dec 2014 14:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ftuv2o1bd3Zv for ; Tue, 30 Dec 2014 14:17:31 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57F01A877B for ; Tue, 30 Dec 2014 14:17:31 -0800 (PST) Received: from localhost ([::1]:42211 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y656Z-0005RL-QH; Tue, 30 Dec 2014 14:17:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Tue, 30 Dec 2014 22:17:31 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/33#comment:2 Message-ID: <076.300f0f95b66f5791b1c02fa74fa15a3b@trac.tools.ietf.org> References: <061.a5ce40aa1d210c527317773533e6c828@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <061.a5ce40aa1d210c527317773533e6c828@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/krekiY8zEDhxBzRZ1GdUrCK-t3M Cc: manet@ietf.org Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 22:17:34 -0000 #33: RFC 5444 processing constraint Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 5/28/2014 3:26 PM, Charles E. Perkins wrote: > I did not find the specification within RFC5444 mandating the > limitation as stated below. In fact, RFC 5444 has the following text: > > ============================================================= > o field, if present, contains the number of hops on > which the packet is allowed to travel before being discarded by a > MANET router. .... > > o field, if present, contains the number of hops on > which the packet has traveled across the MANET. .... > ============================================================== > > which many people would interpret to indicate that a packet might > traverse multiple hops. > > Anyway, I will do the following: > a) make it clear that AODV multicast packets traverse only a single > hop and > b) remove the unnecessary passages from the relevant text cited below > in section 5.4. > > > On 4/3/2014 2:31 PM, manet issue tracker wrote: >> #33: RFC 5444 processing constraint >> >> (Thomas Clausen) >> I have a general concern about how this protocol imposes constraints >> on RFC5444 usage, which precludes co-existence with other RFC5444 >> protocols running on the same device. >> >> Let me give an example hereof, from Section 5.4: >> >> >> {{{ >> When multiple messages are aggregated into a single packet >> according to RFC 5444 formatting, and the aggregation of >> messages is also authenticated (e.g., with IPsec), and the >> IP destination is multiple hops away, it becomes >> infeasible >> to delete individual messages. In such cases, instead of >> deleting individual messages, they are maintained in the >> aggregation of messages, but simply ignored for further >> processing. In such cases where individual messages >> cannot >> be deleted, in this document "disregarded" means >> "ignored". >> Otherwise, any such "disregarded" AODVv2 messages SHOULD >> be >> deleted from the aggregated messages in the RFC 5444 >> packet. >> }}} >> >> An RFC5444 packet is *never* to be sent more than one hop. >> ... A router receives an RFC5444 packet, decapsulates >> it, process each message (if appropriate), the owner process of each >> message identifies which messages are to be forwarded (if appropriate), >> hands those off to the appropriate "message multiplexing engine" which >> packs those messages up in a new RFC5444 packet, and transmits that >> new RFC5444 packet. > > Check. >> >> Also, in RFC5444 messages, addresses are contained in address blocks. >> There is no semantics associated with an address being in one address >> block, or in another (in fact, (re-)organising addresses into address >> blocks is one of the tricks to use to obtain more compact messages). >> Likewise, there is no semantics associated with an address being first, >> last, or in any other position in an address block: the ordering of >> addresses in an address block carries no semantics. >> >> Therefore, writing something like this: >> >> >> {{{ >> RteMsg.Address[i] denotes the [i]th address in an RFC 5444 >> AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes the >> associated prefix length for RteMsg.Address[i], and >> RteMsg.{field} denotes the corresponding value in the >> named >> AddrTLV block associated with RteMsg.Address[i]. >> }}} >> >> >> makes no sense whatsoever (aside from the fact that I do not understand >> the notation !RteMsg.{field} - that would indicate a "field" in a >> message, not in an attribute associated with an address). > > I don't think this is still an issue in the current draft. However, it > is notable that certain ordering constraints must be associated with > addresses and associated TLVs. For instance, the [i]th element of an > array of values in a TLV must be associated with the [i]th address. >> >> Let me give one more example, from section 9: >> >> >> {{{ >> If a message with an unknown type is received, the message is >> disregarded. >> }}} >> >> >> An implementation of this specification will (according to RFC5444) >> "own", and therefore get messages that this protocol has gotten >> assigned by IANA, say, RREQ/RREP/RERR/RREP_ACK. Messages of any >> other Message Types will not (again, according to RFC5444) be >> delivered to an implementation of this protocol. >> >> Therefore, this protocol >> specify discarding any message types other than those than it "owns". > > Well, O.K. if we are going to agree that it's impossible for AODVv2 > to receive a message of an unknown type, the text is redundant and > can be removed. It boils down to having RFC 5444 enforce the type > checking instead of AODVv2. Sounds less than robust to me. ------------------------------------------------------------------------------ On 5/28/2014 4:41 PM, Christopher Dearlove wrote: > Charlie > > Thanks for pointing that out. That is text in a non-normative appendix and is an error. The normative text in Section 5.2 refers to messages, and so should this appendix. I will put in an erratum to correct that. > > But your (a) is incorrect. There are no such things as AODV packets. Packets are owned by the 5444/5498 multiplexing process. Only messages are owned by AODVv2. --------------------------------------------------------------------------------------- The description of AODV protocol elements has been changed to use the term "message" instead of "packet" where applicable. The other suggested changes have also been made, and so this issue can reasonably be considered as closed. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: closed Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Tue Dec 30 14:48:16 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7991A8939; Tue, 30 Dec 2014 14:48:13 -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 efJwXSJOrhbF; Tue, 30 Dec 2014 14:48:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DB71A8949; Tue, 30 Dec 2014 14:48:08 -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.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141230224808.7277.84623.idtracker@ietfa.amsl.com> Date: Tue, 30 Dec 2014 14:48:08 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/RKnX0-NTokgZO2EWREgTs6gawO0 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 22:48:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Dynamic MANET On-demand (AODVv2) Routing Authors : Charles E. Perkins Stan Ratliff John Dowdell Lotte Steenbrink Filename : draft-ietf-manet-aodvv2-06.txt Pages : 69 Date : 2014-12-30 Abstract: The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering rapid convergence in dynamic topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-aodvv2-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-06 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 Tue Dec 30 19:12:36 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7811A8A4F for ; Tue, 30 Dec 2014 19:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FLcxdaFM_tfi for ; Tue, 30 Dec 2014 19:12:30 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5020E1A8A40 for ; Tue, 30 Dec 2014 19:12:30 -0800 (PST) Received: from localhost ([::1]:54464 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y69hu-0005hd-An; Tue, 30 Dec 2014 19:12:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-manet-aodvv2@tools.ietf.org, charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 03:12:22 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/58#comment:1 Message-ID: <076.f0e9fe2cb2b33c2aade6c202dbc9d864@trac.tools.ietf.org> References: <061.66674244bcbb8d93f58696341885fee1@trac.tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <061.66674244bcbb8d93f58696341885fee1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-manet-aodvv2@tools.ietf.org, charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: charliep@computer.org, charles.perkins@earthlink.net, john.dowdell486@gmail.com, lotte.steenbrink@haw-hamburg.de, ratliffstan@gmail.com Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qJM05xpCClHsvY1PUyqR_6TIPGk Cc: manet@ietf.org Subject: Re: [manet] #58 (aodvv2): Definitions of OrigNode and TargNode (Submitted for Justin Dean) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 03:12:35 -0000 #58: Definitions of OrigNode and TargNode (Submitted for Justin Dean) Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 11/12/2014 7:37 PM, Charlie Perkins wrote: > Here are some answers to your questions... > On 11/10/2014 12:24 PM, Justin Dean wrote: >> The definition of Originating Node (!OrigNode) (and !TargNode) are self referencing and incomplete. They should at least reference AODVv2 Router. Also the terms !OrigNode and !TargNode are later used as what seems like addresses in an AODVv2 message. I suggest separating the definition of a node (an AODVv2 Router?) from an address of that node/router (suggest !OrigNodeAddr) > > A node can be a host or a router, and is a fundamental > networking object that can be used to define other > objects. There are many instances where the two terms > !OrigNode and !TargNode are used, and I am sure that you > are right that !OrigNodeAddr and !TargNodeAddr is more > accurate. Maybe, for brevity, should we use !OrigAddr and > !TargAddr? We have tried as much as possible to avoid > using names that are too long and distracting. If this is O.K. > we will make new terminology definitions, and review > whether !OrigNode and !TargNode are still needed. ---------------------------------------------------------------- Draft revision ...-06 includes many changes from !OrigNode to !OrigAddr and similarly for !TargAddr and !UnreachableAddr. With the new terminology, it seems reasonable to close this issue. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-manet- charliep@computer.org | aodvv2@tools.ietf.org Type: enhancement | Status: closed Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG | Resolution: fixed Document | Keywords: terminology | -------------------------+------------------------------------------------- Ticket URL: manet From nobody Tue Dec 30 19:23:27 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888B01A8A40 for ; Tue, 30 Dec 2014 19:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 py1SMkk9QH4B for ; Tue, 30 Dec 2014 19:23:18 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05801A8A52 for ; Tue, 30 Dec 2014 19:22:24 -0800 (PST) Received: from localhost ([::1]:55671 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y69rc-0002qo-5N; Tue, 30 Dec 2014 19:22:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 03:22:24 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/62#comment:1 Message-ID: <076.ab16df92dd0ea7e0fff220ad1abee2f0@trac.tools.ietf.org> References: <061.36cb0a118e2c05855eab02054f3200ff@trac.tools.ietf.org> X-Trac-Ticket-ID: 62 In-Reply-To: <061.36cb0a118e2c05855eab02054f3200ff@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/R4TFy1YmPhvWJUJS2AOexdt00RE Cc: manet@ietf.org Subject: Re: [manet] #62 (aodvv2): Inconsistency surrounding the "timed" state (Submitted for Justin Dean) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 03:23:23 -0000 #62: Inconsistency surrounding the "timed" state (Submitted for Justin Dean) Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: On 12/16/2014 12:47 PM, Charlie Perkins wrote: > If a route is explicitly Timed, there should be a separate flag for the route. The route would stay in the Active state until the configured Expiration time, and then it would be marked as Expired without ever going into the Idle state. > > Without this modification, routes could be in the Active state as well as the Timed state simultaneously, which is hard to explain and somewhat contradictory to the way "route state" is used in the document. This modification has been included in the latest revision of the draft, and it resolves the issue. With this change, it seems reasonable to mark the issue as closed. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charles Perkins Type: enhancement | Status: closed Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: timed route | -----------------------------------+------------------------------ Ticket URL: manet From nobody Tue Dec 30 20:55:09 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49621A8A7B for ; Tue, 30 Dec 2014 20:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ISizRI4kAZv5 for ; Tue, 30 Dec 2014 20:55:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48FB1A8A79 for ; Tue, 30 Dec 2014 20:55:07 -0800 (PST) Received: from localhost ([::1]:59952 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6BJK-0007Fe-AV; Tue, 30 Dec 2014 20:55:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 04:55:06 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/63#comment:1 Message-ID: <076.43bb7ed786dae96d6624b59f6731e44b@trac.tools.ietf.org> References: <061.e3db09aae4d7bc0098bdcc4762b98a5d@trac.tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <061.e3db09aae4d7bc0098bdcc4762b98a5d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/EcfP0wOCea8-iEC81aCi5jLw_n0 Cc: manet@ietf.org Subject: Re: [manet] #63 (aodvv2): {Orig, Targ}.Tail should be {Orig, Targ}.Mid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 04:55:09 -0000 #63: {Orig,Targ}.Tail should be {Orig,Targ}.Mid Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: This change has been made and so the issue can be closed. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charles Perkins Type: defect | Status: closed Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: rfc5444 mid tail | -----------------------------------+------------------------------ Ticket URL: manet From nobody Wed Dec 31 06:27:46 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DFE1A8AEE for ; Wed, 31 Dec 2014 06:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 m21NdWwQYWB1 for ; Wed, 31 Dec 2014 06:27:43 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E601A00BD for ; Wed, 31 Dec 2014 06:27:42 -0800 (PST) Received: from localhost ([::1]:33499 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6KFR-0003Ud-QC; Wed, 31 Dec 2014 06:27:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 14:27:41 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/46#comment:2 Message-ID: <076.37a716eb81d56b0e789eaf9c3a8b88e7@trac.tools.ietf.org> References: <061.89377601617f43ae76e225162010f923@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <061.89377601617f43ae76e225162010f923@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/lGxsvEgOE27bwCeuzyRVpA1D_YM Cc: manet@ietf.org Subject: Re: [manet] #46 (aodvv2): What is needed from IP and ICMP (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 14:27:44 -0000 #46: What is needed from IP and ICMP (submitted for Chris Dearlove) Comment (by charliep@computer.org): On 9/8/2014 10:45 AM, Christopher Dearlove wrote: > > This needs specifying .... And also because people who want to implement it know what capabilities they need. If they need queueing in the IP stack they need to be told they need queuing in the IP stack. And that makes it clear this needs to be more than a routing protocol if that capability is not available as standard, which I think you just agreed it's not. Knowledge in the ad hoc routing community isn't enough. > On 8 Sep 2014, at 18:20, Charles E. Perkins wrote: >> On 9/7/2014 3:01 PM, Abdussalam Baryun wrote: >>> I think you may misunderstand MANET reactive routing. I don't see your reply answers the editor question of examples of AODVv2 needs from IP or ICMP. You mention that the protocol needs to see ICMP, what is the problem with that as RFC3561 already has similar issue and already accepted by WG. >>> On Tuesday, July 22, 2014, Dearlove, Christopher (UK) wrote: >>> >>> Just for a start you also need to know that IP routes are requested, that packets are flowing, and to have the ability to queue packets. >>> >> On Tuesday, July 22, 2014, Dearlove, Christopher (UK) wrote something that Charlie interprets as follows: >>> AODVv2 needs the following: >>> - information that IP routes are requested >>> - information that packets are flowing >>> - the ability to queue packets. >> >> Tautologically, a reactive protocol reacts when a route is needed. >> One might say that a route is requested when an application tries to >> send a packet. The fundamental concept of reactive routing is to >> avoid creating routes that are not needed, and the way that has been >> used to know whether a route is needed is when an application tries >> to send a packet. >> >> If an application tries to send a packet, and the route is available, the >> packet has to wait until the route is available. So, yes, queuing a >> packet is needed. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: IP/ICMP interaction | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Wed Dec 31 06:45:01 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8541A8F33 for ; Wed, 31 Dec 2014 06:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Nig2gydrqcc0 for ; Wed, 31 Dec 2014 06:44:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB02C1A8EA9 for ; Wed, 31 Dec 2014 06:44:57 -0800 (PST) Received: from localhost ([::1]:35103 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6KW9-00034B-9I; Wed, 31 Dec 2014 06:44:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 14:44:57 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/15#comment:2 Message-ID: <081.076aebab68aed8223d8267876152092c@trac.tools.ietf.org> References: <066.51de40fe9c0e229a90ae823d91b65254@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <066.51de40fe9c0e229a90ae823d91b65254@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/aOhIiyJFw4zaSQBpO7a-6aIhvLA Cc: manet@ietf.org Subject: Re: [manet] #15 (dymo): Reactive Design Approach X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 14:44:59 -0000 #15: Reactive Design Approach Changes (by charliep@computer.org): * status: new => closed * resolution: => wontfix Comment: The following relevant comment preceded the preceding comment, but is relevant. On 2/20/2013 9:45 AM, Charles E. Perkins wrote: > I also agree that the hybrid approach may offer many benefits. When we're > done with the reactive approach, I hope we can get into developing a hybrid > solution. As I understand it, this was among the initial motivations for > RFC 5444 -- enabling a common message "platform" for ad hoc network > nodes to interpret both reactive and proactive signaling. > > It seems to me that you are not specifically requesting any changes to > the AODVv2 document for this purpose. If you do have changes in mind, > please let me know which sections and if possible some suggested text > for the changes. ----------------------------------------------------------------------- No changes to the document were proposed for this issue, and given the discussion it seems reasonable to close the issue. -- ----------------------------------------+-------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun Type: enhancement | Status: closed Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: wontfix Keywords: Design Approach | ----------------------------------------+-------------------------------- Ticket URL: manet From nobody Wed Dec 31 06:55:06 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779CD1A8F4A for ; Wed, 31 Dec 2014 06:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z1vY__hr0lNk for ; Wed, 31 Dec 2014 06:55:03 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644601A8BB3 for ; Wed, 31 Dec 2014 06:55:03 -0800 (PST) Received: from localhost ([::1]:35605 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6Kft-0005s6-8L; Wed, 31 Dec 2014 06:55:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org, abdussalambaryun@gmail.com X-Trac-Project: manet Date: Wed, 31 Dec 2014 14:55:01 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/17#comment:4 Message-ID: <081.72bfdb01eb4fa74b4ba33bce9692b650@trac.tools.ietf.org> References: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, abdussalambaryun@gmail.com, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/7EZ22euyoqAQWiNOczeGjM4_Di8 Cc: manet@ietf.org Subject: Re: [manet] #17 (dymo): Proposed Reactive Protocols' Alternative Message Formats X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 14:55:04 -0000 #17: Proposed Reactive Protocols' Alternative Message Formats Changes (by charliep@computer.org): * status: assigned => closed * resolution: => fixed Comment: On 6/24/2013 9:20 PM, Charles E. Perkins wrote: > The changes have been made without any undue difficulty, and > no complaints have been brought to the attention of the mailing > list. I think this issue can safely be closed now. -- ----------------------------------------+---------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Type: enhancement | charliep@computer.org Priority: major | Status: closed Component: dymo | Milestone: milestone1 Severity: Active WG Document | Version: Keywords: RFC5444, Address TLVs | Resolution: fixed ----------------------------------------+---------------------------------- Ticket URL: manet From nobody Wed Dec 31 07:02:15 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0442D1A901C for ; Wed, 31 Dec 2014 07:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vB6T4WoHbzgA for ; Wed, 31 Dec 2014 07:02:13 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE03B1A900A for ; Wed, 31 Dec 2014 07:02:12 -0800 (PST) Received: from localhost ([::1]:36054 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6Kmq-0007mZ-G5; Wed, 31 Dec 2014 07:02:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 15:02:12 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/2#comment:1 Message-ID: <076.edbca7b78d3c36be3eddd187f1167823@trac.tools.ietf.org> References: <061.9ade0aa6aa05287725babd1e29bd3153@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <061.9ade0aa6aa05287725babd1e29bd3153@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Z6NPbul3cyMbUh9W7Qvwt9l-334 Cc: manet@ietf.org Subject: Re: [manet] #2 (dymo): Terminology for reactive protocol document X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:02:14 -0000 #2: Terminology for reactive protocol document Comment (by charliep@computer.org): On 11/1/2012 12:43 PM, Abdussalam Baryun wrote: > I always supported that terminology documents SHOULD be considered in all IETF WGs, and also I noted in my input the reasons for unclear issues, because of terms and some detail information which I got to understand after DYMO authors reply. However, I do encourge using similar terms within all MANET WG documents, however, terms definitions should relate to such specifications. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: enhancement | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: Keywords: terminology clarity | -----------------------------------+------------------------------ Ticket URL: manet From nobody Wed Dec 31 07:09:28 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09941A9032 for ; Wed, 31 Dec 2014 07:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MyHyKNHpGGpw for ; Wed, 31 Dec 2014 07:09:23 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA961A903A for ; Wed, 31 Dec 2014 07:09:05 -0800 (PST) Received: from localhost ([::1]:36298 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6KtV-0000mh-BX; Wed, 31 Dec 2014 07:09:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 15:09:05 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/16#comment:2 Message-ID: <081.9ffddfc362f25050c3e720b8aee2f595@trac.tools.ietf.org> References: <066.02811072057e3e608e2532e3a9c56d6d@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <066.02811072057e3e608e2532e3a9c56d6d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qcUCPOl8cfJueU7ewRRBopJCAus Cc: manet@ietf.org Subject: Re: [manet] #16 (dymo): The Reactive Protocol Duplicate Suppression Table X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:09:26 -0000 #16: The Reactive Protocol Duplicate Suppression Table Comment (by charliep@computer.org): On 2/20/2013 4:10 PM, Abdussalam Baryun wrote: > I agree, but why there is not much attention in the WG for unidirectional links? > Regarding RREP it can be optional, but I prefer one table for duplicate RteMsg, > On 2/20/13, Charles E. Perkins wrote: >> There was a revision of AODVv2 that included RREPs in the duplicate >> suppression table. It did have the effect of making the description more >> difficult to understand without additional benefit in the typical case >> where RREPs are unicast. For multicast RREP, there would be quite a >> bit more benefit, but the use case for multicast RREP involves networks >> with unidirectional links, which have not seen much attention lately in >> the working group. Moreover, the duplicate suppression table itself >> would need to distinguish between RREQ and RREP messages if they >> were combined in the same table, so logically speaking the table could >> still be viewed as two separate tables. >> >> If there is interest, handling multicast RREPs in a similar table could >> be more explicitly specified in the document. -- ----------------------------------------+-------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun Type: enhancement | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: Keywords: Message suppression | ----------------------------------------+-------------------------------- Ticket URL: manet From nobody Wed Dec 31 07:20:08 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93E91A904A for ; Wed, 31 Dec 2014 07:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Sfd4J-41CuXs for ; Wed, 31 Dec 2014 07:19:43 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008241A904E for ; Wed, 31 Dec 2014 07:19:36 -0800 (PST) Received: from localhost ([::1]:37181 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6L3g-0007OC-RY; Wed, 31 Dec 2014 07:19:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 15:19:36 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/manet/trac/ticket/27#comment:2 Message-ID: <076.e5a1380719041a6fe2128e0c100e7fff@trac.tools.ietf.org> References: <061.cc69d0d59c5db291a9ef255a1650fad8@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <061.cc69d0d59c5db291a9ef255a1650fad8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/GZtz5jM3WDuMW7kU1ZazIdKEgSU Cc: manet@ietf.org Subject: Re: [manet] #27 (aodvv2): Processing AckReq X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:19:50 -0000 X-List-Received-Date: Wed, 31 Dec 2014 15:19:50 -0000 #27: Processing AckReq Comment (by charliep@computer.org): Recent drafts have included the requested clarification. > To avoid repeated failure of Route Discovery, an AODVv2 router > (!HandlingRtr) handling a RREP message MUST attempt to verify > connectivity towards RREQ_Gen. This MAY be done by including the > Acknowledgement Request (!AckReq) data element in the RREP. In reply > to an !AckReq, an RREP_ACK message message MUST be sent. With this clarification, the issue may reasonably be considered to be resolved. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Wed Dec 31 07:27:16 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B58B1A9079 for ; Wed, 31 Dec 2014 07:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, T_RP_MATCHES_RCVD=-0.01] 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 sCI0C9ShX_0K for ; Wed, 31 Dec 2014 07:27:13 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EEB91A9046 for ; Wed, 31 Dec 2014 07:27:13 -0800 (PST) Received: from localhost ([::1]:37456 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6LB3-0000GE-16; Wed, 31 Dec 2014 07:27:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 15:27:13 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/32#comment:2 Message-ID: <076.d1c7f89b6e908469f2136062d891597e@trac.tools.ietf.org> References: <061.6938ca142d915a879b2e5bc46f790232@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <061.6938ca142d915a879b2e5bc46f790232@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/AinRF4sY_XdUtiv_ni-1sw4Ws0o Cc: manet@ietf.org Subject: Re: [manet] #32 (aodvv2): Multicast transmission X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:27:14 -0000 #32: Multicast transmission Comment (by charliep@computer.org): On 9/8/2014 5:47 AM, Abdussalam Baryun wrote: > On 4/3/14, manet issue tracker wrote: >> #32: Multicast transmission >> >> (Thomas Clausen) >> >> Section 5.4: >> >> {{{ >> In order to reduce multicast overhead, retransmitting >> multicast packets in MANETs SHOULD be done according to >> methods specified in [RFC6621] >> }}} >> >> >> What happens if that "SHOULD" is not done? Does it break interoperability? > > The draft guides to RFC6621 as reducing overhead option. There is no > break from my understandning. If you have break example or analysis > please provide for progress. > > That multicast-overhead is a multicast protocol problem not this > draft problem. Reactive multicast can be done in future after > finishing this. I know that multicast in reactive protocol is > important that is why I suggested before to the WG that we postpone > any reactive multicast work until we finish this work (I argued with > Thomas this issue). Do you mean RFC6621 did not consider reactive > protocol use of it, if that is the meaning then we should update > RFC6621 to consider that. > >> Also, RFC6621 is not std.track, so this is a downref that requires special >> handling. I note that SHOULD is a fairly strong normative statement, but >> the RFC6621 is cited as an informational reference. This does not appear >> appropriate. > > I am not sure about that normative issues. But I see there is a > condition as if you want to reduce overhead then go for RFC6621. I > don't mind that we edit that "SHOULD" into "should". > >> >> And finally, RFC6621 specifies a number of different algorithms and modes >> of operation, some of which require additional signalling. For >> interoperable implementations to result, this is insufficient. > > I suggest we add that the draft does not go into details of RFC6621 > modes, I suggest that to be done in another draft. -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Wed Dec 31 07:30:49 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3495E1A908D for ; Wed, 31 Dec 2014 07:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6vV5g0LC-EyB for ; Wed, 31 Dec 2014 07:30:41 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDDD1A908A for ; Wed, 31 Dec 2014 07:30:41 -0800 (PST) Received: from localhost ([::1]:37573 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6LEP-0008K3-EV; Wed, 31 Dec 2014 07:30:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 15:30:41 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/34#comment:2 Message-ID: <076.eff65f13de64bc8b6e8b58de3300527d@trac.tools.ietf.org> References: <061.1b44a2845a63141c8adc66505db6419a@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <061.1b44a2845a63141c8adc66505db6419a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/zT9uVHhHcEDAD1ogfO2GzaIQ3X0 Cc: manet@ietf.org Subject: Re: [manet] #34 (aodvv2): Section 13 must be removed X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:30:43 -0000 #34: Section 13 must be removed Comment (by charliep@computer.org): On 9/10/2014 6:13 AM, Abdussalam Baryun wrote: > I disagree with this proposed ticket or bug-issue. > > On Thursday, April 3, 2014, manet issue tracker wrote: > > #34: Section 13 must be removed > > (Thomas Clausen) > The whole of section 13 must be removed, with the exception of section > 13.6 which is already covered by RFC5444. > > RFC5444 is just format, has no functions and it does not specifying any protocol. This section 13.6 is part of protocol. > > All the other optional > mechanisms are either underspecified, with known problems in common > deployment topologies, or both. Further, they are clearly indicated > as "not needed" so why are they included? > > They are not normative for protocol. What are problems you refer to, I don't understand you. However, I don't find the indication "not needed". -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Wed Dec 31 07:37:17 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05551A909C for ; Wed, 31 Dec 2014 07:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1Zx0EDwPqk6R for ; Wed, 31 Dec 2014 07:37:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19B71A90B2 for ; Wed, 31 Dec 2014 07:36:39 -0800 (PST) Received: from localhost ([::1]:37798 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6LKB-00015Z-FP; Wed, 31 Dec 2014 07:36:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 15:36:39 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/30#comment:2 Message-ID: <076.c7bfb9311a6b9f8a588a51296659eabc@trac.tools.ietf.org> References: <061.9544556e01d71f4a3bc37047a820e1cd@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <061.9544556e01d71f4a3bc37047a820e1cd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/4tTj1HFW38mflex2RgI1fjFYXZ8 Cc: manet@ietf.org Subject: Re: [manet] #30 (aodvv2): Use of word "node" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:37:09 -0000 #30: Use of word "node" Comment (by charliep@computer.org): On 4/4/2014 7:11 PM, Joe Macker wrote: > right chris I was not responding to your comments just confirming that 2501 did not claim to mandate any terminology definition of node. > > I prefer router myself when I talk about something that does routing > but I do occassionally like to use node when I talk about graph theory ;-) > > On Apr 4, 2014, at 9:58 PM, Christopher Dearlove wrote: > >> Well I brought up 2501, but just to point out it used the term node differently, so the claim that the term was universally agreed wasn't so. 3626 also provided a data point there. So it's best not to use the term undefined. But I didn't make the other points Joe suggests either. >> >> -- >> Christopher Dearlove >> christopher.dearlove@gmail.com (iPhone) >> chris@mnemosyne.demon.co.uk (home) >> >>> On 5 Apr 2014, at 01:23, Joe Macker wrote: >>> >>> I didnt think you did. >>> I was commenting on another part of the thread but misclicked in reply. >>> >>> -joe >>> >>>> On Apr 4, 2014, at 6:29 PM, Thomas Heide Clausen wrote: >>>> >>>> I don't think that I claimed that 2501 did any of those things, Joe. >>>> >>>> >>>> -- >>>> Thomas Heide Clausen >>>> http://www.thomasclausen.org >>>> >>>> "Today's scientists have substituted mathematics for >>>> experiments, and they wander off through equation >>>> after equation, and eventually build a structure >>>> which has no relation to reality." >>>> - Nikola Tesla, >>>> Modern Mechanics and Inventions, July, 1934 >>>> >>>>> On 5 avr. 2014, at 00:23, Joe Macker wrote: >>>>> >>>>> RFC 2501 was not mandating terminology nor did it claim to. >>>>> >>>>> It was an informational document to raise issues and design considerations relating to a particular problem space. >>>>> >>>>> And certainly there are always more issues to consider than it raised at the time. >>>>> >>>>> -joe >>>>> >>>>> "To everything there is a season. A time to weep, and a time to laugh; a time to model using a graph" >>>>> >>>>>> On Apr 3, 2014, at 7:42 PM, Thomas Heide Clausen wrote: >>>>>> >>>>>> 3561 did it wrong. >>>>>> >>>>>> What is the definition of "node"? >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>>> On 4 avr. 2014, at 01:20, Abdussalam Baryun wrote: >>>>>>> >>>>>>> I think draft uses node and router the same way it is used in the RFC3561 which is good. The AODVv2 is protocol between nodes. >>>>>>> >>>>>>> AB >>>>>>> >>>>>>> On Thursday, April 3, 2014, manet issue tracker wrote: >>>>>>> #30: Use of word "node" >>>>>>> >>>>>>> (Thomas Clausen) I find the use of "node" unfortunate. I would much prefer >>>>>>> "router", as this is a protocol running between routers. This applies both >>>>>>> in the text and in the "terminology mnemonics". I note that the text >>>>>>> sometimes uses "router" and sometimes "node", and it is not clear that/if >>>>>>> there is a difference, or if there should be a difference. The word >>>>>>> "Router Client" is also used (albeit inconsistently capitalized) as is >>>>>>> "client". >>>>>>> >>>>>>> An application running on a host has very, very specific expectations as >>>>>>> to how the underlying IP link behaves. Applications "Expect an IP Link >>>>>>> that looks like an Ethernet". I believe that it was Dave Thaler that once >>>>>>> said something like "don't expect Microsoft to rewrite their IP stack..." >>>>>>> Applications expect what they expect. Even, a protocol such as NDP, which >>>>>>> an IPv6-host uses to (among other things) configure its interfaces has >>>>>>> this expectation. Therefore, unless the goal is to explicitly not support >>>>>>> general applications and general IP stacks, an appropriate link model must >>>>>>> be presented to hosts. >>>>>>> >>>>>>> Yes, links between MANET routers are not "looking like an Ethernet". >>>>>>> That's quite alright, as long as the *only* application seeing these >>>>>>> "MANET links" is the routing application. Expose the weirdness of "a >>>>>>> MANET link" to an off-the-shelf app or protocol (such as NDP, mDNS, ...), >>>>>>> and unpredictable behaviour ensures. >>>>>>> >>>>>>> The way that other MANET routing protocols have taken is, to provide an IP >>>>>>> hop isolation of the hosts (which run "off the shelf applications") from >>>>>>> the "MANET links": in other words, a "regular IP link" ties the "host" to >>>>>>> the "router" and the "router" then has one or more interfaces towards the >>>>>>> "MANET links". -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Wed Dec 31 07:45:59 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881601A9094 for ; Wed, 31 Dec 2014 07:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1QI3SHaE8gEE for ; Wed, 31 Dec 2014 07:45:56 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2D81A9066 for ; Wed, 31 Dec 2014 07:45:54 -0800 (PST) Received: from localhost ([::1]:38167 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6LT8-0003V9-9I; Wed, 31 Dec 2014 07:45:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 15:45:54 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/35#comment:2 Message-ID: <076.e6e85c50475be55817ebe0984bca63ed@trac.tools.ietf.org> References: <061.64df908508777a0117e43e7ed153e409@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <061.64df908508777a0117e43e7ed153e409@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/G-UYxzatCym0wtaJmWnN77jWOhU Cc: manet@ietf.org Subject: Re: [manet] #35 (aodvv2): A constant is constant X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:45:58 -0000 #35: A constant is constant Comment (by charliep@computer.org): On 5/29/2014 8:06 PM, John Mullen wrote: > Hi All, > I've been a lurker for some time, but as a mathematician and engineer, I've always interpreted "constant" as a value that is unchanging in the current analysis, not necessarily a constant in the sense of Euler's constant. So my interpretation is that these are values that are not to be modified dynamically, but may be modified in certain situations and possibly due to some yet-unknown technology by the people setting up the network. It is also my experience that people who do this use the default values unless something comes up that warrants adjustment. So, I think the language is clear enough. ---------------------------------------------------- > From: ... Charles E. Perkins [charliep@computer.org] > Sent: Wednesday, May 28, 2014 12:51 PM > I'm not quite sure what to do about this. Contrary to the assertion, > the term "Protocol Constant" is pretty well understood and has been > used with the same meaning in numerous existing RFCs. I think that > it would be interesting to explore the results of using different constants, > but the intention is clearly that implementations should use the numbers > as provided. > > If desired, I can try to fashion some text to suggest the results of > using different numbers (e.g., for use in atypical situations). > On 4/3/2014 2:34 PM, manet issue tracker wrote: >> #35: A constant is constant >> >> (Thomas Clausen) >> Section 14.2 "Protocol Constants" contains a semantically null >> sentence AODVv2 protocol constants typically do not require changes >> >> A constant is constant, therefore it doesn't change. Even for very >> loose definitions of constant. With that being said, the interesting >> part here is actually not that bit...but rather, what happens *if* >> these are not set to the values that are indicated? Or, if different >> implementations use different values for these? The same holds for >> 14.2, btw: is a network able to operate with different routers setting >> different values? Will it break? Degrade gracefully? Just work? -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Wed Dec 31 07:51:43 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312E01A0081 for ; Wed, 31 Dec 2014 07:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yG2JBTLCu-uw for ; Wed, 31 Dec 2014 07:51:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93FAE1A00E9 for ; Wed, 31 Dec 2014 07:51:39 -0800 (PST) Received: from localhost ([::1]:38418 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6LYh-0004Pp-6s; Wed, 31 Dec 2014 07:51:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 15:51:38 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/35#comment:3 Message-ID: <076.8f689b3be199da2b9882745d57f44286@trac.tools.ietf.org> References: <061.64df908508777a0117e43e7ed153e409@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <061.64df908508777a0117e43e7ed153e409@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/lauSM13_w-07F_9zXUrS1Aux6-E Cc: manet@ietf.org Subject: Re: [manet] #35 (aodvv2): A constant is constant X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:51:41 -0000 #35: A constant is constant Comment (by charliep@computer.org): On 5/30/2014 9:43 AM, Abdussalam Baryun wrote: > This draft purpose is implementation, so the understandning target > should be targeting implementers (which they not needed to be > engineers or mathematics). IMHO, within any protocol > specification/program-language, its constants are not variable and its > variables are not constant. > > IMHO, this ticket #35 mostly points to a sentence, therefore it > means: Remove the sentence "AODVv2 protocol constants typically do not > require changes". or Replace to: " AODVv2 protocol constants' values > are typically default values". > > I do not disagree with the ticket (i.e. it maybe did not recommend > edit sentence), because that sentence may cause confusion to the > implementers that know that constants cannot change. If editors don't > want to remove/replace then we may add more words to clarify in a > better way for all understandings. Please advise, -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Wed Dec 31 08:41:42 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC1F1A020B for ; Wed, 31 Dec 2014 08:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 R_PcpDPAV69E for ; Wed, 31 Dec 2014 08:41:38 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7441A020A for ; Wed, 31 Dec 2014 08:41:38 -0800 (PST) Received: from localhost ([::1]:40399 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6ML4-0001tQ-7P; Wed, 31 Dec 2014 08:41:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 16:41:38 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/60#comment:1 Message-ID: <076.58218e8370365074c795dfdd9b36ce89@trac.tools.ietf.org> References: <061.722206bae2439674b46415d6706ed5e0@trac.tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <061.722206bae2439674b46415d6706ed5e0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/6hONz6x2GfoAH0FBB9xXyUBVGYY Cc: manet@ietf.org Subject: Re: [manet] #60 (aodvv2): Should OrigNode be included in the message header? (Submitted for Justin Dean) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 16:41:40 -0000 #60: Should OrigNode be included in the message header? (Submitted for Justin Dean) Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: That mistake has been there a very long time (since the time when it was not a mistake, in fact). That's the only instance of the term in the draft, and once the requirement was placed to include OrigNode (now, OrigAddr) in the !AddrBlk, it no longer needed to be put in as the . With this resolution, the issue can reasonably be closed. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charles Perkins Type: defect | Status: closed Priority: major | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: OrigNode data field | -----------------------------------+------------------------------ Ticket URL: manet From nobody Wed Dec 31 09:35:01 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA8E1AC436 for ; Wed, 31 Dec 2014 09:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aP7fETWyhDkJ for ; Wed, 31 Dec 2014 09:34:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC631AC443 for ; Wed, 31 Dec 2014 09:34:57 -0800 (PST) Received: from localhost ([::1]:43338 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6NAf-0007Sb-EN; Wed, 31 Dec 2014 09:34:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 17:34:57 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/59#comment:1 Message-ID: <076.a2361f730090c43595de6e7267b6d1c8@trac.tools.ietf.org> References: <061.63893d9c85ffbaa3a8568c816f69579a@trac.tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <061.63893d9c85ffbaa3a8568c816f69579a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rFUf1EhCRvVnciJEID9F9LNtk-4 Cc: manet@ietf.org Subject: Re: [manet] #59 (aodvv2): Use of the term "invalid" (Submitted for Justin Dean) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 17:34:59 -0000 #59: Use of the term "invalid" (Submitted for Justin Dean) Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed Comment: Uses of the term "invalid" have been reviewed and replaced with "broken" or "expired" as suggested. It seems that this issue can safely be closed. Further discussion about "broken" or "expired" may be found as part of the discussion for issue #61. -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charles Perkins Type: enhancement | Status: closed Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: terminology | -----------------------------------+------------------------------ Ticket URL: manet From nobody Wed Dec 31 09:36:32 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363ED1AC43B for ; Wed, 31 Dec 2014 09:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6MlgfaHY_hJp for ; Wed, 31 Dec 2014 09:36:30 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3761A02BE for ; Wed, 31 Dec 2014 09:36:30 -0800 (PST) Received: from localhost ([::1]:43426 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6NCA-0007wA-2s; Wed, 31 Dec 2014 09:36:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 17:36:30 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/46#comment:3 Message-ID: <076.253e13968f43c3e9156cf01e69ac431a@trac.tools.ietf.org> References: <061.89377601617f43ae76e225162010f923@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <061.89377601617f43ae76e225162010f923@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/pxf0HjoEqO-EUXp7JBrg4t-Sg_Y Cc: manet@ietf.org Subject: Re: [manet] #46 (aodvv2): What is needed from IP and ICMP (submitted for Chris Dearlove) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 17:36:31 -0000 #46: What is needed from IP and ICMP (submitted for Chris Dearlove) Changes (by charliep@computer.org): * status: new => assigned -- -----------------------------------+------------------------------------ Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: assigned Priority: minor | Milestone: Component: aodvv2 | Version: Severity: Active WG Document | Resolution: Keywords: IP/ICMP interaction | -----------------------------------+------------------------------------ Ticket URL: manet From nobody Wed Dec 31 09:41:50 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71BE1ACC7F for ; Wed, 31 Dec 2014 09:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7w5-1u7kDquq for ; Wed, 31 Dec 2014 09:41:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0A71ACC72 for ; Wed, 31 Dec 2014 09:41:45 -0800 (PST) Received: from localhost ([::1]:43616 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y6NHE-0000oa-U3; Wed, 31 Dec 2014 09:41:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org X-Trac-Project: manet Date: Wed, 31 Dec 2014 17:41:44 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/41#comment:2 Message-ID: <084.62ea1039281141c1137c7cc9e628f301@trac.tools.ietf.org> References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/manet/fWVPi3mC88L1qX8PWcU9Tvo7OxU Cc: manet@ietf.org Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 17:41:50 -0000 #41: AckReq vs RREP_ACK Changes (by charliep@computer.org): * status: new => closed * resolution: => invalid Comment: This issue is a duplicate of issue #40, and so is being closed to avoid duplicate discussion. -- -------------------------------------------+------------------------------- Reporter: lotte.steenbrink@fu-berlin.de | Owner: Type: defect | charliep@computer.org Priority: minor | Status: closed Component: aodvv2 | Milestone: Severity: Active WG Document | Version: Keywords: | Resolution: invalid -------------------------------------------+------------------------------- Ticket URL: manet From nobody Wed Dec 31 11:46:04 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6871A1A4E for ; Wed, 31 Dec 2014 11:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 HnLTXcoQ1pZR for ; Wed, 31 Dec 2014 11:46:00 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FC21A1A4D for ; Wed, 31 Dec 2014 11:46:00 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id q1so14464793lam.33 for ; Wed, 31 Dec 2014 11:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8zgwyCp7ts+CnO47IfcCd9biPuPWGtDxaVJKjpgcfWg=; b=DFa02N7l+D7BHk7qjt9sdbdntC7t4ZYOqbNI1yb4YPAQ70vb2sbpiDWWYJSE9R/1PA alfejtYnXleDDcfgMWZpGKRSmjd5wxwgVYywrHSp0zgYaw6lULowgZocwPW1pLOTfp9P 6l1fY6mxI1FM1qEOb7u7sIx1RCpH+ODCrLaCXjtfBnXSI6CHHUYBpUZxDvaFA+ITtbD7 YbDv6O2demTC0W5Epg32LbE3+ssrsJvJZuqpTJKiXkI8zxTrLI/reNZyMzXOTXNKHtk+ itXELK12ATXDhneFLc2gvopnPbNRTkjuKi5tG+PdEc8ylyhh6jEDrs0sDfoBvNS6ywNm GpGg== MIME-Version: 1.0 X-Received: by 10.112.167.68 with SMTP id zm4mr12687017lbb.93.1420055158634; Wed, 31 Dec 2014 11:45:58 -0800 (PST) Received: by 10.25.85.201 with HTTP; Wed, 31 Dec 2014 11:45:58 -0800 (PST) In-Reply-To: <008901d02532$0f196760$2d4c3620$@olddog.co.uk> References: <008901d02532$0f196760$2d4c3620$@olddog.co.uk> Date: Wed, 31 Dec 2014 14:45:58 -0500 Message-ID: From: Stan Ratliff To: MANET IETF Content-Type: multipart/alternative; boundary=001a11c2623e4abe71050b885b33 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/krYCk_VlvSXcTdY1RXkVooxsWhw Subject: [manet] Fwd: [Roll] Two IETF last calls of interest to you X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 19:46:02 -0000 --001a11c2623e4abe71050b885b33 Content-Type: text/plain; charset=UTF-8 MANET WG, Adrian forwarded this to Roll. It might be of interest here as well. If you are on both lists, and therefore have received multiple copies, my apologies. regards, Stan ---------- Forwarded message ---------- From: Adrian Farrel Date: Wed, Dec 31, 2014 at 2:43 PM Subject: [Roll] Two IETF last calls of interest to you To: roll@ietf.org Hi, Please be aware that of two IETF last calls running until 14th January. Send any comments to the main IETF list. - 'Management of Networks with Constrained Devices: Problem Statement and Requirements' as Informational RFC - 'Management of Networks with Constrained Devices: Use Cases' as Informational RFC Regards, Adrian _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --001a11c2623e4abe71050b885b33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
MANET WG,=C2=A0

Adrian forwarded this t= o Roll. It might be of interest here as well. If you are on both lists, and= therefore have received multiple copies, my apologies.=C2=A0
regards,
Stan


---------- Forwarded message ----------
From: Adrian Farrel <adrian@olddog.co.uk>
Date: Wed, = Dec 31, 2014 at 2:43 PM
Subject: [Roll] Two IETF last calls of interest = to you
To: roll@ietf.org

Hi,

Please be aware that of two IETF last calls running until 14th January.
Send any comments to the main IETF list.

- 'Management of Networks with Constrained Devices: Problem Statement a= nd
=C2=A0 =C2=A0Requirements'
=C2=A0 <draft-ietf-opsawg-coman-probstate-reqs-03.txt> as Information= al RFC

- 'Management of Networks with Constrained Devices: Use Cases'
=C2=A0 <draft-ietf-opsawg-coman-use-cases-03.txt> as Informational RF= C

Regards,
Adrian


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--001a11c2623e4abe71050b885b33--