From nobody Mon Jun 1 03:28:41 2015 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 A69A41ABD35 for ; Mon, 1 Jun 2015 03:28:40 -0700 (PDT) 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 RjicMR-3iMBJ for ; Mon, 1 Jun 2015 03:28:38 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311EA1ABC10 for ; Mon, 1 Jun 2015 03:28:38 -0700 (PDT) Received: by wizo1 with SMTP id o1so98739253wiz.1 for ; Mon, 01 Jun 2015 03:28:37 -0700 (PDT) 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=mK5Fo30OVKYP2BfFGEkmOXNjaKbae0YGZeNTvjC/la0=; b=DFIH8QsOm7Imv6ScD3N+Mom3xiF1Z1ENud1kgSBQNB3VhrKkVkKcoM6XwtN7NsN2HQ kjBbXP5Z8SKxSACfU3Ejv4BF2EPlmp2sM1WY0o+1b+ZFyQLUXIL61ShDHic675bqlM6V /YVA5PuPIorXQOpwzPr2vi02fOcJehN7I+0iO8kg7usgAYpNx/4qv6kpIJHQpX9MRs9u LzBp+/EIPkL7pv8KMgNugxEpESzb4GWCUgx7fuZhEvSJgn9oV9xdrCKJY8ocCB8TuJlt L8En4hiebEclspGR6tmdMyLb+TpgmpHeA7F1AEHpVlAOTQL6/G5vp8s5PX/1SyvlIh4e s4+A== X-Received: by 10.180.91.40 with SMTP id cb8mr19328592wib.64.1433154516953; Mon, 01 Jun 2015 03:28:36 -0700 (PDT) Received: from [10.0.4.178] ([217.158.48.187]) by mx.google.com with ESMTPSA id hn7sm21209731wjc.16.2015.06.01.03.28.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2015 03:28:36 -0700 (PDT) Message-ID: <556C33D3.5090309@gmail.com> Date: Mon, 01 Jun 2015 11:28:35 +0100 From: John Dowdell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: manet@ietf.org References: <20150528081235.4501.97727.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040406060800010209040601" Archived-At: Subject: Re: [manet] Fwd: New Version Notification for draft-clausen-manet-rfc5444-usage-00.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: Mon, 01 Jun 2015 10:28:40 -0000 This is a multi-part message in MIME format. --------------040406060800010209040601 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Ulrich and team Many thanks for producing this. The AODVv2 team will be taking a close look, and I for one will be supporting WG adoption. Best regards John On 31/05/15 12:33, Ulrich Herberg wrote: > As we announced previously, we have been working on a document > specifying rules for how to use RFC5444 in MANET protocols. Well, here > it is (at least in a -00 version). > We'd appreciate reviews and will soon ask for WG adoption. > > Best regards > Ulrich > > Begin forwarded message: > >> *From:* internet-drafts@ietf.org >> *Date:* May 28, 2015 at 11:12:35 GMT+3 >> *To:* "Christopher Dearlove" > >, "Henning Rogge" >> > >, "Thomas Clausen" >> >, "Henning >> Rogge" > >, "Ulrich Herberg" >> >, "Thomas H. >> Clausen" >, >> "Christopher Dearlove" > >, "Ulrich Herberg" >> > >> *Subject:* *New Version Notification for >> draft-clausen-manet-rfc5444-usage-00.txt* >> >> >> A new version of I-D, draft-clausen-manet-rfc5444-usage-00.txt >> has been successfully submitted by Thomas Clausen and posted to the >> IETF repository. >> >> Name: draft-clausen-manet-rfc5444-usage >> Revision: 00 >> Title: Rules For Designing Protocols Using the RFC5444 >> Generalized Packet/ Message Format >> Document date: 2015-05-28 >> Group: Individual Submission >> Pages: 17 >> URL: >> https://www.ietf.org/internet-drafts/draft-clausen-manet-rfc5444-usage-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-clausen-manet-rfc5444-usage/ >> Htmlized: >> https://tools.ietf.org/html/draft-clausen-manet-rfc5444-usage-00 >> >> >> Abstract: >> This document updates the generalized MANET packet/message format, >> specified in RFC5444, by providing prescriptive guidelines for how >> protocols can use that packet/message format. In particular, these >> mandatory guidelines prohibit a number of uses of RFC5444 that have >> been suggested in various proposals, and which would have lead to >> interoperability problems, to impediment of protocol extension >> development, and to inability to use generic RFC5444 parsers. >> >> >> >> >> 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 >> . >> >> The IETF Secretariat >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --------------040406060800010209040601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Ulrich and team

Many thanks for producing this. The AODVv2 team will be taking a close look, and I for one will be supporting WG adoption.

Best regards
John

On 31/05/15 12:33, Ulrich Herberg wrote:
As we announced previously, we have been working on a document specifying rules for how to use RFC5444 in MANET protocols. Well, here it is (at least in a -00 version). 
We'd appreciate reviews and will soon ask for WG adoption.

Best regards
Ulrich 

Begin forwarded message:

From: internet-drafts@ietf.org
Date: May 28, 2015 at 11:12:35 GMT+3
To: "Christopher Dearlove" <chris.dearlove@baesystems.com>, "Henning Rogge" <henning.rogge@fkie.fraunhofer.de>, "Thomas Clausen" <t.clausen@computer.org>, "Henning Rogge" <henning.rogge@fkie.fraunhofer.de>, "Ulrich Herberg" <ulrich@herberg.name>, "Thomas H. Clausen" <T.Clausen@computer.org>, "Christopher Dearlove" <chris.dearlove@baesystems.com>, "Ulrich Herberg" <ulrich@herberg.name>
Subject: New Version Notification for draft-clausen-manet-rfc5444-usage-00.txt


A new version of I-D, draft-clausen-manet-rfc5444-usage-00.txt
has been successfully submitted by Thomas Clausen and posted to the
IETF repository.

Name:        draft-clausen-manet-rfc5444-usage
Revision:    00
Title:        Rules For Designing Protocols Using the RFC5444 Generalized Packet/ Message Format
Document date:    2015-05-28
Group:        Individual Submission
Pages:        17
URL:            https://www.ietf.org/internet-drafts/draft-clausen-manet-rfc5444-usage-00.txt
Status:         https://datatracker.ietf.org/doc/draft-clausen-manet-rfc5444-usage/
Htmlized:       https://tools.ietf.org/html/draft-clausen-manet-rfc5444-usage-00


Abstract:
  This document updates the generalized MANET packet/message format,
  specified in RFC5444, by providing prescriptive guidelines for how
  protocols can use that packet/message format.  In particular, these
  mandatory guidelines prohibit a number of uses of RFC5444 that have
  been suggested in various proposals, and which would have lead to
  interoperability problems, to impediment of protocol extension
  development, and to inability to use generic RFC5444 parsers.




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.

The IETF Secretariat



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

--------------040406060800010209040601-- From nobody Mon Jun 1 08:04:22 2015 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 D1E6E1AD0B9; Mon, 1 Jun 2015 08:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 Px3xDp1IH0n1; Mon, 1 Jun 2015 08:04:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DFD1AD1A6; Mon, 1 Jun 2015 08:04:11 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150601150411.30662.13632.idtracker@ietfa.amsl.com> Date: Mon, 01 Jun 2015 08:04:11 -0700 Archived-At: Cc: manet chair , manet mailing list , RFC Editor Subject: [manet] Protocol Action: 'TLV Naming in the MANET Generalized Packet/Message Format' to Proposed Standard (draft-ietf-manet-tlv-naming-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, 01 Jun 2015 15:04:21 -0000 The IESG has approved the following document: - 'TLV Naming in the MANET Generalized Packet/Message Format' (draft-ietf-manet-tlv-naming-04.txt) as Proposed Standard This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-tlv-naming/ Technical Summary This document renames and makes minor changes to some IANA registries that derive from RFC 5444. During progress of another draft (draft-ietf-manet-olsrv2-multitopology) issues with current registry naming practices were illustrated; specifically having different names for different TLV type extensions was not allowed. If this naming was enforced certain TLV types would share a "name" but otherwise be completely divergent in meaning. This draft reorganizes the registry naming rules and does not change any protocol functionality. Working Group Summary This work was regarded as a technical change, requested by the AD (Adrian Farrel). There was no particular interest in the draft (for or against), beyond cleaning up the registry and being necessary to progress draft (draft-ietf-manet-olsrv2-multitopology). Document Quality The document clearly states it's purpose, to change naming of IANA registries for future assignments and to provide new versions of IANA registries to reflect these rules. It does this clearly and with detail. Personnel Justin Dean (jdean@itd.nrl.navy.mil) is the document shepherd. Alvaro Retana (aretana@cisco.com) is the responsible AD. Joe Macker and Stan Ratliff are the designated experts for the affected registries. From nobody Mon Jun 8 15:13:46 2015 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 B98DB1B31FD for ; Mon, 8 Jun 2015 12:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 I4jA6kZX9oD4 for ; Mon, 8 Jun 2015 12:10:50 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 692221B31D0 for ; Mon, 8 Jun 2015 12:10:50 -0700 (PDT) Received: (qmail 19082 invoked by uid 0); 8 Jun 2015 19:10:46 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 8 Jun 2015 19:10:46 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id e13Y1q00T2SSUrH0113bB7; Mon, 08 Jun 2015 19:03:35 -0600 X-Authority-Analysis: v=2.1 cv=D8zUdJhj c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=aOXZMo6RmXiBLQdBjFkA:9 a=fif6Ex7A5J9UADwv:21 a=cEyT-Dv40lqbAPGa:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=6XLJMrE9/BJau1WVdsA6VdWqLplsWZKVM3+dU690yVU=; b=kndQGHPI0yd3J+aM/gsJItYnJ43nyoAMwJJoVJEhFXfcTFfYhrSaAXcaOOVCVIAzcLE2OxySXN8q5s3SGw1OM+Las676i/paSMo1/W4UT6CxJ38uRQtuZvHb0WLj1KQc; Received: from box313.bluehost.com ([69.89.31.113]:57194 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z22RX-0003KD-9C; Mon, 08 Jun 2015 13:10:43 -0600 Message-ID: <5575E8A7.6030508@labn.net> Date: Mon, 08 Jun 2015 15:10:31 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: manet-chairs@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: X-Mailman-Approved-At: Mon, 08 Jun 2015 15:13:44 -0700 Cc: manet-ads@ietf.org, "rtg-dir@ietf.org" , manet@ietf.org, draft-ietf-manet-dlep.all@ietf.org Subject: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 08 Jun 2015 19:10:52 -0000 [Note this is a WG LC related review, not IETF LC.] Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request -- or WG Last call as was the case here . The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the (chairs and) Routing ADs, it would be helpful if you could consider them along with any other Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-manet-dlep-14 Reviewer: Lou Berger Review Date: June 8 (later than requested due to scope of comments -- sorry) WG LC End Date: unknown Intended Status: Standards track Summary: While I think the document is pretty decent for the scope of the work, I do have concerns about this document and recommend that the WG Chairs/Routing ADs discuss these issues further with the authors. I'm also available as/if needed to discuss. Comments: I think the document shows significant good work and looks to be a useful protocol, although I'm not overly familiar in this space. That said, I have a number of serious concerns about the document, and its contents from a few of perspectives. These include basic protocol issues, underspecified details (which could lead to interoperability issues), and specification/editorial issues. I think the document / protocol can be modified to address the issues I raise below. Of course, it is up to the WG, chairs, and ADs to decide which comments to address and which to ignore. I don't expect that all comments will result in changes. Major Issues: - The length field of the generic data item (i.e., TLV) is only 8 bits. While 255 bytes (assuming that this is the unit of measure, which BTW isn't specified) is big enough today, allowing for larger will greatly simplify things when 255 isn't enough. -- We've run into this in RSVP and it's a real pain. - Version number is currently defined as a data item. This means a signal (i.e., message) needs to be potentially fully parsed to discover what version is being used. This precludes basic format changes to the protocol. Perhaps the Discovery and Init Signals should be special cased to include version in their formats. (And shorten version to 8 bits from 32, as mentioned below). - The document references, but does not define, 'in-session' and 'discovery' states. These either need to be formally defined or removed. BTW we had exactly the same issue with LMP (RFC4204) and ended up adding section 11 (FSMs) at a pretty late stage of the process. - TCP session management is not defined, nor is the relationship with TCP and DLEP sessions fully defined. For example: o Closing the TCP session is only mentioned in one place and in a way that is inconsistent with the expected protocol behavior (close TCP before ACK is received). o What happens when a DLEP session is terminated, can the TCP session be reused or must it be closed too? - There is no transaction model defined. For example, it's completely unclear if only one unacknowledged Signal allowed at a time, or perhaps just one per signal type is allowed, or perhaps there are no restrictions. This needs to be explicit. - What is the purpose of retries and timeouts over TCP? Retries aren't needed over TCPs and it's unclear whey they are being used. - The higher level implications of ACKs, over TCP, isn't really clear. It seems ACKs are defined for multiple purposes: reliable transport, transaction acknowledgment and transaction results. Of course the first isn't needed, and implications of the others should be clear. For example, in section 7.10, why would there be a retry when receiving a Destination Up ACK signal indicating an error? - There is no discussion on scaling considerations. Are there really none? For example, how often might be appropriate to issue/limit Peer Updates based to changes in link quality, or how to handle the case where a large number (all or most) of destinations go down. - There are 13 places where the protocol allows implementation to define their own 'heuristics'. Some of these seem unnecessary due to the TCP point raised above, but any that remain in the protocol should be fully specified to ensure predictable/consistent behavior from implementations. - Data Items are defined for "Extensions" and "Experimental Definition" (Sections 8.7 and 8.8). Both seem to support for optional mechanisms, but the former uses assigned numeric values, why the latter uses UTF-8 strings. o What, if any, is the intended distinction/relationship between these? o How does an "Experimental Definition" become standardized? - Sections 8.19 and 8.20 define "Resources" related Data Items. The definition related to these basically says a resources is "An 8-bit integer percentage, 0-100, representing the amount of resources allocated to receiving|transmitting data.". If I were implementing this protocol, I'd have no idea how to produce, update or use this information. I think there is some missing informative and normative (RFC 2119) text related to these formats. - Sections 8.21 and 8.22 (Relative Link Quality) have a similar problem of being under described, in particular it's unclear if there's a meaningful, non-proprietary definition for link quality that an implementation is to act on or if the passed value is just passed for as monitoring information. Either way, this needs to be clarified. - Section 9 defines a "credit-windowing scheme analogous to the one documented in [RFC5578]". It describes how credits are exchanged, but it provides zero definition on the implications or use of credits relative to the data plane. - Multiple ways to implement the same function are allowed, e.g., optional presence of Status, Interval and TCP port. Generally allowing such complicates testing and leads to interoperability issues. The document should pick one way and require it. - The document doesn't state if there are any ordering requirements on data items. It should be explicit on this, e.g., there are no ordering requirements on the placement of Data Items within Signals. - The required and optional data items that are permitted on a signal isn't always clear. For example are 0/1/N copies of a particular Data Item required/allowed. Using something like ABNF would really help formalize and clarify this. - The document doesn't clearly delineate from informative/narrative text, normative / required processing procedures, and message formats. This by itself is not necessarily a major issue, it just makes it harder to (write,) review and implement the protocol. What is a major issue is that this approach allows for duplicate (and sometimes contradictory) normative procedures and for omissions in procedures (particularly related to exception/error processing). Specific examples are included above and below. It would be best to ensure that each required processing behavior is defined just once and in a consistent way. - The security consideration section is inadequate. This section should address the security of the DLEP protocol, not user traffic. It should include an analysis of risks/threats/possible exploits and how these are mitigated by the protocol. rfc6952, and the protocols it references can serve as examples. Minor Issues: - The data and signal type fields are both 8 bits. This seems pretty small, particularly the data type field. Given this is a control protocol, I think a larger (at least data type) field would provide better "future proofing". - 2^32 versions are currently allowed (section 8.1). This seems a bit excessive. I'd opt for max of 8 bits here myself. - It's probably too late, but it probably would be cleaner to have a generic ack signal rather than a per signal type ack. I mention this here as this may come up again when clarifying the transaction model (as mentioned above.) - Section 2: Assumptions This section includes informative and normative text so is more than just Assumptions. Personally, I'd remove all normative text from the section. - There are no specific rules related to UDP header formation. - Sections 8.10->8.17. Isn't add/drop indicator needed for subnets in destination update signals? - The IANA Considerations sections must follow​ RFC2360. - New registries must include initial values, which are defined in the document. (The document currently has many TBDs that should be replaced.) - New registries need an allocation policy, e.g.: The registry should be established with registration policies of "Standards Action" (for Standards Track documents) and “Specification Required" (for other documents). The designated expert is any current WG chair. Nits: - The document introduces the terms "signals" and "data items" for what is commonly called "messages" and "TLVs" (or objects) in other protocols. It's probably too late to change this, but I think the introduction of unique terminology is counter productive. - Use of RFC 2119 conformance language is a bit rough, and there are words in all caps that are not defined in RFC2119. Take a look at http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuideline for some suggestions. - Internal socket operation is mentioned a couple of times. It really shouldn't be, the spec should define behavior on the wire. - The Length fields are missing unit of measure (presumably octets) - The Mnemonics are used basically once and don't really add value, suggest dropping them. - How/when is the "Unknown Signal" Status Code sent? - Section 8.7: Extension List should be shown as a variable length field. - Section 8.8: Experiment List should be shown as a variable length field. That's it -- for now -- hopefully I didn't miss anything. Look forward to hearing response to the above (and how I got things hopelessly wrong ;-) Lou From nobody Tue Jun 9 07:26:15 2015 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 EEE1E1B2CF6 for ; Tue, 9 Jun 2015 07:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 45rg_lktKHHV for ; Tue, 9 Jun 2015 07:26:09 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5898D1A879F for ; Tue, 9 Jun 2015 07:26:09 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1Z2KTd-003GP9-HT>; Tue, 09 Jun 2015 16:26:05 +0200 Received: from [141.22.28.170] (helo=frankenbook-pro.cpt.haw-hamburg.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1Z2KTd-0030xz-EX>; Tue, 09 Jun 2015 16:26:05 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_F8C30C70-45E9-4B10-A8BC-DE7667741D0E" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lotte Steenbrink In-Reply-To: Date: Tue, 9 Jun 2015 16:26:04 +0200 Message-Id: References: <20150528081235.4501.97727.idtracker@ietfa.amsl.com> To: manet@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: 141.22.28.170 X-ZEDAT-Hint: A Archived-At: Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] New Version Notification for draft-clausen-manet-rfc5444-usage-00.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 Jun 2015 14:26:14 -0000 --Apple-Mail=_F8C30C70-45E9-4B10-A8BC-DE7667741D0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ulrich, Thomas, Chris and Henning, Am 31.05.2015 um 13:33 schrieb Ulrich Herberg : > As we announced previously, we have been working on a document = specifying rules for how to use RFC5444 in MANET protocols. Well, here = it is (at least in a -00 version).=20 > We'd appreciate reviews and will soon ask for WG adoption. first of all, thank you so much for publishing this much-needed draft. = I'm also in favor of WG adoption. While reading through the document, I = wrote down some nitpicks and suggestions that I'd like to share. (Just in case my writing sounds harsh, I fear that's due to = language/cultural differences. I'm really happy about this document and = would like to see it flourish.) =3D=3D General notes =3D=3D - If I didn=92t misunderstand it, the document addresses two groups of = people: Those who want to design RFC5444 messages for their protocol, = and those wo want to implement a RCF 5444 builder/parser. Imo, The = former group needs more of an outside view (i.e. what can/should I put = where), while the latter needs the inside view (i.e. how do I arrange = and process everything efficiently). To my mind, these are two very = different goals, but while reading the document, it wasn=92t always = instantly clear to me which bit addresses which group=85 I realize the = two can=92t always be separated completely, but would it be possible to = make it more clear which group is addressed currently? Maybe the = document could be organized into two big sections (one for each group), = or there could be a recurring pattern of =93first outside then inside = view=94 for each (sub)section? - A lot of the examples are very NHDP/OLSR-specific. While I think it=92s = great to have pointers to where a certain technique has already been = used, from an outsider=92s perspective, the examples don=92t always help = me understand the technique that=92s being illustrated, since I have to = familiarize myself with the details referenced first=85 I=92m wondering = if it would be possible to keep the examples which illustrate a point = more generic, and then briefly point to existing instances of this = situation in case the reader wants to follow up on that? =3D=3D Section by section =3D=3D Section 1.2., Page 4: =93A packet is designed to as travel [=85]=94 I think the =93as=94 = doesn=92t belong here. Section 4.2., Page 8: =93Outgoing messages MAY be created by owning protocol=94 I think = there=92s a =93the=94 missing. Section 4.3., Page 8: If I understand it correctly, the last paragraph on this page is = talking about multi-value TLVs without actually saying =93multi-value = TLV=94. Maybe that could be stated explicitly for clarity and in case = somebody=92s searching for advice by this keyword? Section 4.4., Page 9/10: The last paragraph on page and the first two on page 10, more = specifically these parts: =20 Such an example already exists (but within the basic = specification, rather =20 than as an extension) in the use of LOST values in the = LINK_STATUS =20 and OTHER_NEIGHB TLVs to report that an address is of a router = known =20 not to be a neighbor. A future example might be to list an = address =20 to be added to a "blacklist" of addresses not to be used. =20 This example can be taken further. NHDP must also not reject = a HELLO =20 message because it contains an unrecognized TLV. This also = applies to unrecognized TLV values, where a TLV supports only a = limited set of values. were a bit hard to read for me. Imho, the example is very specific = and contains details which aren=92t necessary to understand the issue at = hand (such as the fact that this extension is technically not a = completely independent extension, or possible future other extensions). = It took me about 4 re-reads to really grasp what=92s going on there... Also, I would=92ve expected the last paragraph of this section to = clearly state that relying on address order *will* break your messages = if you don=92t have control over all 5444 builders that are used to = implement your protocol ever. Section 4.5.: I'm assuming that this is the response to our (the AODVv2 Author = team and possibly others) complaints that RFC5444 lacks a clear "API" = which tells it what we can and cannot set manually in an RFC 5444 = packet, and that there's no (at the risk of sounding really pretentious = now) "visual language" to describe the contents of a 5444 message and = their relationship to each other. To be honest, I'm a bit puzzled by = this section.... The mapping that is presented is a bit vague and = introduced very promptly. And while I strongly agree with the statement = that writing down an actual API is too language- and = implementation-specific to belong in a document like this, it would be = really helpful to have a comprehensive "these are the things that your = protocol can set in a RFC5444 message. Your packet builder/parser will = figure out the rest." List in this section rather than some examples. Along with this list, it would be great to have a clear specification on = how to specify which Addresses and TLVs a specific message has, and how = their relationship to each other are. (i.e. how to make clear which = address TLVs are associated with which addresses). I don=92t care if = this ends up being a very visual approach (like the debugging output of = Henning=92s oonf API [1]), or the tables that OLSRv2 uses, or something = completely different, but it would be helpful to be able to read and = write messages down in a way that is clear to everyone. Section 4.6: =93[=85] and MUST NOT remove such TLVs or values=94 A question I=92ve been wanting to ask for a while now: Does this = rule also apply for message regeneration? AODVv2 regenerates all = messages per hop. Should implementations keep track which unknown TLVs = of a message are associated with which addresses, and put them back in = their place when regenerating the message? Section 6.1.: (I=92m not terribly familiar with compression, so my questions are = probably very naive, but maybe they can help clear things up) Would this very straightforward to implement compression algorithm = still produce interoperable messages? The rest of the section reads as = if the =93compression algorithm=94 mentioned in the introduction is = mainly a way to cleverly arrange addresses so that they are still = understood by all parsers, but take up a minimal amount of space. I = think that=92s a very good tip in itself, but is that really all there = is to compression? Would it make sense to say =93Here=92s how you should = arrange addresses cleverly, you can also implement a more elaborate = compression algorithm, but that=92s out of the scope of this document=94? Also, any mention of the word =93straightforward=94 makes me very = suspicious, but that might just be me. Section 6.1.: =93RECOMMNDED=94 in the first paragraph is missing an E. Regards, Lotte [1] Random one pulled out of my logfiles for illustration: ,------------------ | PACKET |------------------ | * Packet version: 0 | * Packet flags: 0x0 | ,------------------- | | MESSAGE | |------------------- | | * Message type: 11 | | * Message flags: 0x40 | | * Address length: 16 | | * Hop limit: 20 | | ,------------------- | | | Address: fe80::ff:fe00:1719 | | | | - TLV | | | | Flags =3D 0x50 | | | | Type =3D 0 | | | | Value length: 2 | | | | 0000: 0100 | | `------------------- | | ,------------------- | | | Address: fe80::ff:fe00:16fe | | | | - TLV | | | | Flags =3D 0x50 | | | | Type =3D 1 | | | | Value length: 2 | | | | 0000: 0100 | | | | - TLV | | | | Flags =3D 0xd0 | | | | Type =3D 3; Type ext. =3D 3 | | | | Value length: 1 | | | | 0000: 00 | | `------------------- | `------------------- `------------------ >=20 > Best regards > Ulrich=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: May 28, 2015 at 11:12:35 GMT+3 >> To: "Christopher Dearlove" , "Henning = Rogge" , "Thomas Clausen" = , "Henning Rogge" = , "Ulrich Herberg" = , "Thomas H. Clausen" , = "Christopher Dearlove" , "Ulrich Herberg" = >> Subject: New Version Notification for = draft-clausen-manet-rfc5444-usage-00.txt >>=20 >>=20 >> A new version of I-D, draft-clausen-manet-rfc5444-usage-00.txt >> has been successfully submitted by Thomas Clausen and posted to the >> IETF repository. >>=20 >> Name: draft-clausen-manet-rfc5444-usage >> Revision: 00 >> Title: Rules For Designing Protocols Using the RFC5444 = Generalized Packet/ Message Format >> Document date: 2015-05-28 >> Group: Individual Submission >> Pages: 17 >> URL: = https://www.ietf.org/internet-drafts/draft-clausen-manet-rfc5444-usage-00.= txt >> Status: = https://datatracker.ietf.org/doc/draft-clausen-manet-rfc5444-usage/ >> Htmlized: = https://tools.ietf.org/html/draft-clausen-manet-rfc5444-usage-00 >>=20 >>=20 >> Abstract: >> This document updates the generalized MANET packet/message format, >> specified in RFC5444, by providing prescriptive guidelines for how >> protocols can use that packet/message format. In particular, these >> mandatory guidelines prohibit a number of uses of RFC5444 that have >> been suggested in various proposals, and which would have lead to >> interoperability problems, to impediment of protocol extension >> development, and to inability to use generic RFC5444 parsers. >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> The IETF Secretariat >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_F8C30C70-45E9-4B10-A8BC-DE7667741D0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Ulrich, Thomas, Chris and Henning,

Am 31.05.2015 um = 13:33 schrieb Ulrich Herberg <ulrich@herberg.name>:

As we announced previously, we have been working on a = document specifying rules for how to use RFC5444 in MANET protocols. = Well, here it is (at least in a -00 version). 
We'd = appreciate reviews and will soon ask for WG = adoption.

first of all, = thank you so much for publishing this much-needed draft. I'm also in = favor of WG adoption. While reading through the document, I wrote down = some nitpicks and suggestions that I'd like to share.
(Just = in case my writing sounds harsh, I fear that's due to language/cultural = differences. I'm really happy about this document and would like to see = it flourish.)

=3D=3D General notes = =3D=3D
- If I didn=92t misunderstand it, the = document addresses two groups of people: Those who want to = design RFC5444 messages for their protocol, and those wo want to = implement a RCF 5444 builder/parser. Imo, The former group needs = more of an outside view (i.e. what can/should I put where), while the = latter needs the inside view (i.e. how do I arrange and process = everything efficiently). To my mind, these are two very different goals, = but while reading the document, it wasn=92t always instantly = clear to me which bit addresses which group=85 I realize the = two can=92t always be separated completely, but would it be possible to = make it more clear which group is addressed currently? = Maybe the document could be organized into two big = sections (one for each group), or there could be a recurring pattern of = =93first outside then inside view=94 for each = (sub)section?

- A lot of the examples are very = NHDP/OLSR-specific. While I think it=92s great to have pointers to where = a certain technique has already been used, from an outsider=92s = perspective, the examples don=92t always help me understand the = technique that=92s being illustrated, since I have to familiarize = myself with the details referenced first=85 I=92m wondering if it would = be possible to keep the examples which illustrate a point more generic, = and then briefly point to existing instances of this situation in case = the reader wants to follow up on that?

=3D=3D = Section by section =3D=3D
Section 1.2., Page = 4:
     =93A packet is designed to as = travel [=85]=94 I think the =93as=94 doesn=92t belong = here.

Section 4.2., Page = 8:
     =93Outgoing messages MAY be created by = owning protocol=94 I think there=92s a =93the=94 = missing.

Section 4.3., Page = 8:
     If I understand it correctly, the last = paragraph on this page is talking about multi-value TLVs without = actually saying =93multi-value TLV=94. Maybe that could be stated = explicitly for clarity and in case somebody=92s searching for advice by = this keyword?

Section 4.4., Page = 9/10:
     The last paragraph on page and the = first two on page 10, more specifically these = parts:
     
     =      Such an example already exists (but within = the basic specification, rather  
     =      than as an extension) in the use of LOST = values in the LINK_STATUS  
     =      and OTHER_NEIGHB TLVs to report that an = address is of a router known  
     =      not to be a neighbor.  A future = example might be to list an address  
     =      to be added to a "blacklist" of addresses = not to be used.
     
          This example = can be taken further.  NHDP must also not reject a HELLO =  
  =         message because it contains = an unrecognized TLV. This also applies
     =      to unrecognized TLV values, where a TLV = supports only a limited set
          of = values.

     were a bit = hard to read for me. Imho, the example is very specific and = contains details which aren=92t necessary to understand the issue at = hand (such as the fact that this extension is technically not = a completely independent extension, or possible future other = extensions). It took me about 4 re-reads to really grasp what=92s going = on there...

     Also, I = would=92ve expected the last paragraph of this section to clearly = state that relying on address order *will* break your messages if you = don=92t have control over all 5444 builders that are used to = implement your protocol ever.

Section = 4.5.:
     I'm assuming that this is = the response to our (the AODVv2 Author team and possibly others) = complaints that RFC5444 lacks a clear "API" which tells it what we can = and cannot set manually in an RFC 5444 packet, and that there's no (at = the risk of sounding really pretentious now) "visual language" to = describe the contents of a 5444 message and their relationship to each = other. To be honest, I'm a bit puzzled by this section.... The mapping = that is presented is a bit vague and introduced very promptly. And while = I strongly agree with the statement that writing down an actual API is = too language- and implementation-specific to belong in a document like = this, it would be really helpful to have a comprehensive "these are the = things that your protocol can set in a RFC5444 message. Your packet = builder/parser will figure out the rest." List in this section rather = than some examples.
Along with this list, it would be great to = have a clear specification on how to specify which Addresses and TLVs a = specific message has, and how their relationship to each other are. = (i.e. how to make clear which address TLVs are associated with which = addresses). I don=92t care if this ends up being a very visual = approach (like the debugging output of Henning=92s oonf API [1]), or the = tables that OLSRv2 uses, or something completely different, but = it would be helpful to be able to read and write messages down in a = way that is clear to everyone.

Section = 4.6:
     =93[=85] and MUST NOT remove such = TLVs or values=94
     A question I=92ve been = wanting to ask for a while now: Does this rule also apply for message = regeneration? AODVv2 regenerates all messages per hop. Should = implementations keep track which unknown TLVs of a message are = associated with which addresses, and put them back in their place when = regenerating the message?

Section = 6.1.:
     (I=92m not terribly familiar with = compression, so my questions are probably very naive, but maybe they can = help clear things up)
     Would this very = straightforward to implement compression algorithm still produce = interoperable messages? The rest of the section reads as if the = =93compression algorithm=94 mentioned in the introduction is mainly a = way to cleverly arrange addresses so that they are still understood by = all parsers, but take up a minimal amount of space. I think that=92s a = very good tip in itself, but is that really all there is to compression? = Would it make sense to say =93Here=92s how you should arrange addresses = cleverly, you can also implement a more elaborate compression algorithm, = but that=92s out of the scope of this document=94?
Also, any = mention of the word =93straightforward=94 makes me very suspicious, but = that might just be me.

Section = 6.1.:
     =93RECOMMNDED=94 in the first = paragraph is missing an = E.

Regards,
Lotte

<= div>
[1] Random one pulled out of my logfiles for = illustration:

     ,------------------
     |  = PACKET
     = |------------------
     | * Packet version:    = 0
     | * Packet = flags:      0x0
     = |    ,-------------------
     = |    |  MESSAGE
     = |    |-------------------
     = |    | * Message = type:       11
     = |    | * Message flags:      = 0x40
     |    | * Address = length:     16
     = |    | * Hop = limit:          = 20
     |    |    = ,-------------------
     |    |    = |  Address: fe80::ff:fe00:1719
     = |    |    |    | - = TLV
     |    |    = |    |     Flags =3D = 0x50
     |    |    = |    |     Type =3D = 0
     |    |    = |    |     Value length: = 2
     |    |    = |    |       0000: = 0100
     |    |    = `-------------------
     |    |    = ,-------------------
     |    |    = |  Address: fe80::ff:fe00:16fe
     = |    |    |    | - = TLV
     |    |    = |    |     Flags =3D = 0x50
     |    |    = |    |     Type =3D = 1
     |    |    = |    |     Value length: = 2
     |    |    = |    |       0000: = 0100
     |    |    = |    | - TLV
     |    |    = |    |     Flags =3D = 0xd0
     |    |    = |    |     Type =3D 3; Type ext. =3D = 3
     |    |    = |    |     Value length: = 1
     |    |    = |    |       0000: = 00
     |    |    = `-------------------
     |    = `-------------------
     = `------------------


Best = regards
Ulrich 

Begin forwarded = message:

From: internet-drafts@ietf.org
<= b>Date: May 28, 2015 at 11:12:35 GMT+3
To: "Christopher = Dearlove" <chris.dearlove@baesystems.co= m>, "Henning Rogge" <henning.rogge@fkie.fraunh= ofer.de>, "Thomas Clausen" <t.clausen@computer.org>, = "Henning Rogge" <henning.rogge@fkie.fraunh= ofer.de>, "Ulrich Herberg" <ulrich@herberg.name>, "Thomas = H. Clausen" <T.Clausen@computer.org>, = "Christopher Dearlove" <chris.dearlove@baesystems.co= m>, "Ulrich Herberg" <ulrich@herberg.name>
Subj= ect: New Version Notification for = draft-clausen-manet-rfc5444-usage-00.txt


A new version of I-D, = draft-clausen-manet-rfc5444-usage-00.txt
has been = successfully submitted by Thomas Clausen and posted to = the
IETF = repository.

Name:       =  draft-clausen-manet-rfc5444-usage
Revision:   =  00
Title:        Rules For = Designing Protocols Using the RFC5444 Generalized Packet/ Message = Format
Document date:   =  2015-05-28
Group:       =  Individual Submission
Pages:       =  17
URL: =            https://www.ietf.org/internet-drafts/draft-clausen-manet-rfc5= 444-usage-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-clausen-manet-rfc5444-usage/=
Htmlized:       = https://tools.ietf.org/html/draft-clausen-manet-rfc5444-usage-00


Abstract:
=   This document updates the generalized MANET packet/message = format,
  specified in RFC5444, by providing = prescriptive guidelines for how
  protocols = can use that packet/message format.  In particular, = these
  mandatory guidelines prohibit a = number of uses of RFC5444 that have
  been = suggested in various proposals, and which would have lead = to
  interoperability problems, to impediment = of protocol extension
  development, and to = inability to use generic RFC5444 = parsers.




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.

The IETF = Secretariat

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

= --Apple-Mail=_F8C30C70-45E9-4B10-A8BC-DE7667741D0E-- From nobody Tue Jun 9 07:50:17 2015 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 EE9F11A883F for ; Tue, 9 Jun 2015 07:50:15 -0700 (PDT) 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, TVD_SPACE_RATIO=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 VRo3DiKV0A_6 for ; Tue, 9 Jun 2015 07:50:12 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E191A8835 for ; Tue, 9 Jun 2015 07:50:11 -0700 (PDT) Received: by wibut5 with SMTP id ut5so21091567wib.1 for ; Tue, 09 Jun 2015 07:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=YNjp8thdzHfqtDedKdksSURuVg/BR7buUNDNhTIpD+d9PC01fKwlrefHe5jNFlAB3i nkBGTVc92ogV6eQIkSerXjKDI67qVLQlsa3VCxc3fwkXoOzDavP9zxhluKkKzV+jYOoa xn4N9os4o4rO69Q1CQX3DrsYhEkCLdK6wu7flAp+x+9aDm/VkTDPnV/bsTZ5e/BJoANd v55YIRygsOc3xjpeQ8k89NQYiw2lTg4jhAJ3E0bAGjUFJXJvc9ZR8EMLnuEbEkB6aG/M r9T+5p3Mb4ZL60wczljxcAgy+sJVbZ2NHntF12CnzTP+BNCdRLYXPT+5D5Xax1aECZWy BgSA== X-Received: by 10.194.172.72 with SMTP id ba8mr42810998wjc.136.1433861410457; Tue, 09 Jun 2015 07:50:10 -0700 (PDT) Received: from [192.168.1.2] (79-67-246-57.dynamic.dsl.as9105.com. [79.67.246.57]) by mx.google.com with ESMTPSA id lu5sm9794058wjb.9.2015.06.09.07.50.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jun 2015 07:50:09 -0700 (PDT) From: Christopher Dearlove X-Google-Original-From: Christopher Dearlove Content-Type: text/plain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) In-Reply-To: Date: Tue, 9 Jun 2015 15:50:07 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20150528081235.4501.97727.idtracker@ietfa.amsl.com> To: Lotte Steenbrink X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] New Version Notification for draft-clausen-manet-rfc5444-usage-00.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 Jun 2015 14:50:16 -0000 From nobody Tue Jun 9 08:00:48 2015 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 799ED1A8851 for ; Tue, 9 Jun 2015 08:00:47 -0700 (PDT) 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 WmK3SDLn3vYI for ; Tue, 9 Jun 2015 08:00:45 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71811A882E for ; Tue, 9 Jun 2015 08:00:44 -0700 (PDT) Received: by wgv5 with SMTP id 5so15850786wgv.1 for ; Tue, 09 Jun 2015 08:00:43 -0700 (PDT) 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=UqetVOEb2NeicNkNVl8Wkf0JzLtP5oUu/EaTqd5yHIQ=; b=Sww3x9I2T/XNisiPl+SSmRHLixE01qKsUtmKqyYYNBsK7tf3BXrfDY4WGbsHeTl0Ac 7geGSgpjHg5IKEZ8siBQZF/SRr5bCnygkWCXjfh7anAY8JrcPPYl8hGIjqLFNQ9ALi2m NU1wdpIJanSWJMTrguxkmT+nY/NNRUKphP8fFU5wVktiMrVsCoTduAsCKiXiC49Wg46h RYKGEP+vok8LdOJwMklkVTIhPhuC6y2TCG4M4ahfPaMvqhH/OdS7g93CqNWzCE8ev9Kl NfE9BvV2x2cNnDrTC2ISjqiY8WvOZKgjOwDyizWFWenlZZXHgutKbk91fiadE0HfutTc 5PhA== X-Received: by 10.180.98.103 with SMTP id eh7mr33017316wib.75.1433862043641; Tue, 09 Jun 2015 08:00:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.86 with HTTP; Tue, 9 Jun 2015 08:00:23 -0700 (PDT) In-Reply-To: References: <20150528081235.4501.97727.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Tue, 9 Jun 2015 17:00:23 +0200 Message-ID: To: Lotte Steenbrink Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Dearlove, Christopher \(UK\)" , MANET IETF Subject: Re: [manet] New Version Notification for draft-clausen-manet-rfc5444-usage-00.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 Jun 2015 15:00:47 -0000 On Tue, Jun 9, 2015 at 4:26 PM, Lotte Steenbrink wrote: > Hi Ulrich, Thomas, Chris and Henning, > > Section 6.1.: > (I=E2=80=99m not terribly familiar with compression, so my questions= are > probably very naive, but maybe they can help clear things up) > Would this very straightforward to implement compression algorithm > still produce interoperable messages? The rest of the section reads as if > the =E2=80=9Ccompression algorithm=E2=80=9D mentioned in the introduction= is mainly a way to > cleverly arrange addresses so that they are still understood by all parse= rs, > but take up a minimal amount of space. I think that=E2=80=99s a very good= tip in > itself, but is that really all there is to compression? Would it make sen= se > to say =E2=80=9CHere=E2=80=99s how you should arrange addresses cleverly,= you can also > implement a more elaborate compression algorithm, but that=E2=80=99s out = of the > scope of this document=E2=80=9D? > Also, any mention of the word =E2=80=9Cstraightforward=E2=80=9D makes me = very suspicious, > but that might just be me. Every parser for RFC5444 should be able to parse everything decribed in RFC5444. So you are free to implement any kind of address compression strategy... Address compression can be split into only two questions: - what is the best order for the addresses for compression - how do you split them into address blocks The combination of these two choices will force the distribution of addressblock-tlvs, because you have to keep the same mapping between addresses and the attached TLV and their values. That is (among other things) why demanding a special order of addresses (or a special split of address blocks) is a BAD idea for a protocol. It might prevent you from doing a good address compression. Henning Rogge From nobody Tue Jun 9 08:42:14 2015 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 6F1A01A8902 for ; Tue, 9 Jun 2015 08:42:13 -0700 (PDT) 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 xXj2-qADbCce for ; Tue, 9 Jun 2015 08:42:11 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9149A1A8925 for ; Tue, 9 Jun 2015 08:42:11 -0700 (PDT) Received: by wiwd19 with SMTP id d19so22819245wiw.0 for ; Tue, 09 Jun 2015 08:42:10 -0700 (PDT) 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=I6sTnDkhtwWg9gRS3bhi65MGxtmCWzg63cAzxzXM49s=; b=LmJLt+GyMxvMj6MlchKSAjihdhEXhzpKC+SQZEvl27VaLv49zX17hZNHsCs3KQSZ6+ ShINpEg8b8oNPnwhRf7GLnt7QsaIB7ybGtbdiTWIG12SUOjdLXRXIOnZ9rLXKW2y8+gj vqYSBKUbDWhB4KaRTRW0SIAyG9tJqzxLF1wYKyKZgR5WXbIiBw/9HZVSfLyEp+qzNqiq XPmFEjcPOoG9CsAFwW3fQ62cFBouC3fg2G8p86rLEGOEOeTmF7HPMdo8yoVJ0XnfmIUC yiPcIDBv3ZOlNjnmRn+cmZhgSkDo5d8LCq2ONIxhSc0EcG7IZzeC/8ewWZwLTybrB1TQ 82yg== X-Received: by 10.180.109.111 with SMTP id hr15mr34010209wib.53.1433864530353; Tue, 09 Jun 2015 08:42:10 -0700 (PDT) Received: from [192.168.1.5] (79-67-246-57.dynamic.dsl.as9105.com. [79.67.246.57]) by mx.google.com with ESMTPSA id g15sm3431236wiv.22.2015.06.09.08.42.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jun 2015 08:42:09 -0700 (PDT) References: <20150528081235.4501.97727.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3E8298D7-286E-4F89-AF4F-B82EC9025E79@gmail.com> X-Mailer: iPhone Mail (12F70) From: Christopher Dearlove Date: Tue, 9 Jun 2015 16:42:07 +0100 To: Christopher Dearlove Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "" Subject: Re: [manet] New Version Notification for draft-clausen-manet-rfc5444-usage-00.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 Jun 2015 15:42:13 -0000 Not sure what went wrong there. I was saying I just saw constructive critici= sm, always appropriate, but as I'm recuperating from (successful, relatively= minor) surgery I'll let my co-authors address this first. (Except examples are as they are as it's much better/easier to base on RFCs t= han IDs.) -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 9 Jun 2015, at 15:50, Christopher Dearlove wrote: >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Jun 9 16:54:03 2015 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 A07A51A8AC8 for ; Tue, 9 Jun 2015 16:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, 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 8wIpqXy_88J1 for ; Tue, 9 Jun 2015 16:53:51 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id E91D11A8AC1 for ; Tue, 9 Jun 2015 16:53:50 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.203 as permitted sender) identity=mailfrom; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,584,1427774400"; d="ics'?scan'208,217";a="17620041" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.203]) by ironport.idirect.net with ESMTP; 09 Jun 2015 19:53:50 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM3.idirect.net (10.250.250.203) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 9 Jun 2015 19:53:49 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.1076.000; Tue, 9 Jun 2015 19:53:49 -0400 From: "Ratliff, Stanley" To: "manet@ietf.org" Thread-Topic: MANET Working Group Interim Thread-Index: AdCjDwqXv76fr3a6SVCE4tyV5nXdMw== Date: Tue, 9 Jun 2015 23:53:48 +0000 Message-ID: <5730851c291840e593f76d4767848fc4@VAUSDITCHM2.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: multipart/mixed; boundary="_004_5730851c291840e593f76d4767848fc4VAUSDITCHM2idirectnet_" MIME-Version: 1.0 Archived-At: Subject: [manet] MANET Working Group Interim 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 Jun 2015 23:53:53 -0000 --_004_5730851c291840e593f76d4767848fc4VAUSDITCHM2idirectnet_ Content-Type: multipart/alternative; boundary="_000_5730851c291840e593f76d4767848fc4VAUSDITCHM2idirectnet_" --_000_5730851c291840e593f76d4767848fc4VAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 V0cgcGFydGljaXBhbnRzIOKAkw0KDQpGaXJzdCB1cCwgbXkgYXBvbG9naWVzIGZvciBub3Qgc2V0 dGluZyB1cCB0aGlzIFdlYkV4IHNvb25lci4gSG93ZXZlciwgdGhlIHNlY29uZCBNQU5FVCBXRyBJ bnRlcmltIG1lZXRpbmcgaXMgdXBvbiB1czsgcGxlYXNlIGxldCB1cyBoZWFyIGZyb20geW91IHRv bW9ycm93Lg0KDQpUZW50YXRpdmUgYWdlbmRhIGlzOg0KQWdlbmRhIEJhc2hpbmcgICAgICAgICAg ICAgLSAgICAgNSBtaW4uDQpSZXBvcnQgb24gRExFUCBzdGF0dXMgLSAgIDEwIG1pbnV0ZXMuDQpS ZXBvcnQgb24gQU9EVnYyIHN0YXR1cyDigJMgMjAgbWludXRlcw0KV29ya2luZyBHcm91cCBjaGFy dGVyIGRpc2N1c3Npb24g4oCTIFJlbWFpbmRlciBvZiB0aW1lDQoNCg0KSG9wZSB0byBoZWFyIGZy b20geW91IHRvbW9ycm93LCBhbmQgcGxlYXNlIFBMRUFTRSBjb21lIHdpdGggaWRlYXMgZm9yIHdo YXTigJlzIG5leHQgZm9yIHRoZSBXRy4gU2hvdWxkIHdlIHJlLWNoYXJ0ZXIsIG9yIGNsb3NlIG91 dCB0aGUgd29ya2luZyBncm91cD8gV2XigJlyZSBsb29raW5nIGZvciB5b3VyIGlucHV0Lg0KDQpS ZWdhcmRzLg0KU3Rhbg0KDQoNCkZyb206IE1vYmlsZSBBZC1ob2MgTmV0d29ya3MgV29ya2luZyBH cm91cCBbbWFpbHRvOm1lc3NlbmdlckB3ZWJleC5jb21dDQpTZW50OiBUdWVzZGF5LCBKdW5lIDA5 LCAyMDE1IDc6NTAgUE0NClRvOiBtYW5ldC1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IChGb3J3 YXJkIHRvIG90aGVycykgV2ViRXggbWVldGluZyBpbnZpdGF0aW9uOiBNQU5FVCBXb3JraW5nIEdy b3VwIEludGVyaW0NCg0KWW91IGNhbiBmb3J3YXJkIHRoaXMgaW52aXRhdGlvbiB0byBvdGhlcnMu DQoNCg0KSGVsbG8sDQoNCk1vYmlsZSBBZC1ob2MgTmV0d29ya3MgV29ya2luZyBHcm91cCBpbnZp dGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4NCg0KDQoNCg0KDQpNQU5FVCBXb3Jr aW5nIEdyb3VwIEludGVyaW0NCg0KV2VkbmVzZGF5LCBKdW5lIDEwLCAyMDE1DQoNCjExOjAwIGFt ICB8ICBFYXN0ZXJuIERheWxpZ2h0IFRpbWUgKE5ldyBZb3JrLCBHTVQtMDQ6MDApICB8ICAyIGhy cw0KDQoNCg0KDQoNCkpvaW4gV2ViRXggbWVldGluZyA8aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bTIwNjM1NzAzOTBjYWJkMWM4MDU0YmRhODgyZjY3YmNiPg0KDQoNCk1l ZXRpbmcgbnVtYmVyOg0KDQo2NDcgMDI5IDkxMQ0KDQpNZWV0aW5nIHBhc3N3b3JkOg0KDQoxMjM0 DQoNCg0KDQoNCg0KSm9pbiBieSBwaG9uZQ0KDQoxLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwg ZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkNCg0KMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51 bWJlciAoVVMvQ2FuYWRhKQ0KDQpBY2Nlc3MgY29kZTogNjQ3IDAyOSA5MTENCg0KVG9sbC1mcmVl IGNhbGxpbmcgcmVzdHJpY3Rpb25zPGh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9y ZXN0cmljdGlvbnMucGRmPg0KDQoNCg0KDQoNCkFkZCB0aGlzIG1lZXRpbmc8aHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWNiNTY3Yzg3NWFiMTM4Y2I3NTlmMWFmZGI1MGNj MmEyPiB0byB5b3VyIGNhbGVuZGFyLg0KDQoNCg0KDQoNCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/ IENvbnRhY3Qgc3VwcG9ydC48aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jPg0KDQoNCg0K DQoNCklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNl IGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Np b24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBt YXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50 IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29y ZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0 aGUgc2Vzc2lvbi4NCg0KDQoNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGFuZCBhbnkgZmlsZXMg dHJhbnNtaXR0ZWQgd2l0aCBpdCBjb250YWlucwppbmZvcm1hdGlvbiBmcm9tIGlEaXJlY3QsIHdo aWNoIG1heSBiZSBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeQphbmQvb3IgY29uZmlkZW50aWFsLiBJ dCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwKb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgb3JpZ2lu YWwKcmVjaXBpZW50IG9yIHRoZSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdGhl IGVtYWlsIHRvIHRoZQppbnRlbmRlZCByZWNpcGllbnQsIGJlIGFkdmlzZWQgdGhhdCB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsCmluIGVycm9yLCBhbmQgdGhhdCBhbnkgdXNlLCBkaXNzZW1p bmF0aW9uLCBmb3J3YXJkaW5nLCBwcmludGluZywgb3IKY29weWluZyBvZiB0aGlzIGVtYWlsIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzIGVtYWlsCmluIGVycm9y LCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlci4KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K --_000_5730851c291840e593f76d4767848fc4VAUSDITCHM2idirectnet_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglm b250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzY2NjY2NjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNl cmlmOw0KCWNvbG9yOiM2NjY2NjY7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiM2 NjY2NjYiIHZsaW5rPSIjNjY2NjY2Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V0cgcGFydGlj aXBhbnRzIOKAkw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5G aXJzdCB1cCwgbXkgYXBvbG9naWVzIGZvciBub3Qgc2V0dGluZyB1cCB0aGlzIFdlYkV4IHNvb25l ci4gSG93ZXZlciwgdGhlIHNlY29uZCBNQU5FVCBXRyBJbnRlcmltIG1lZXRpbmcgaXMgdXBvbiB1 czsgcGxlYXNlIGxldCB1cyBoZWFyIGZyb20geW91IHRvbW9ycm93Lg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UZW50YXRpdmUgYWdlbmRhIGlzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5BZ2VuZGEgQmFzaGluZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDUgbWluLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlcG9ydCBvbiBETEVQIHN0YXR1 cyAtJm5ic3A7ICZuYnNwOzEwIG1pbnV0ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlcG9ydCBvbiBB T0RWdjIgc3RhdHVzIOKAkyAyMCBtaW51dGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldvcmtpbmcgR3Jv dXAgY2hhcnRlciBkaXNjdXNzaW9uIOKAkyBSZW1haW5kZXIgb2YgdGltZQ0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SG9wZSB0byBoZWFyIGZyb20geW91IHRvbW9ycm93LCBhbmQgcGxlYXNlIFBMRUFTRSBjb21lIHdp dGggaWRlYXMgZm9yIHdoYXTigJlzIG5leHQgZm9yIHRoZSBXRy4gU2hvdWxkIHdlIHJlLWNoYXJ0 ZXIsIG9yIGNsb3NlIG91dCB0aGUgd29ya2luZyBncm91cD8gV2XigJlyZSBsb29raW5nDQogZm9y IHlvdXIgaW5wdXQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ UmVnYXJkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U3RhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBNb2JpbGUgQWQtaG9jIE5ldHdvcmtzIFdvcmtpbmcgR3JvdXAgW21haWx0bzpt ZXNzZW5nZXJAd2ViZXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMDks IDIwMTUgNzo1MCBQTTxicj4NCjxiPlRvOjwvYj4gbWFuZXQtY2hhaXJzQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IChGb3J3YXJkIHRvIG90aGVycykgV2ViRXggbWVldGluZyBpbnZpdGF0 aW9uOiBNQU5FVCBXb3JraW5nIEdyb3VwIEludGVyaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIw IiBhbGlnbj0ibGVmdCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5 Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjMuNzVwdCAwaW4gMGluIDBpbiI+DQo8dGFibGUg Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0i bGVmdCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0O21hcmdpbi1sZWZ0OjMuNzVw dCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAw aW4gMGluIDBpbiI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNl bGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+ DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM2NjY2NjYiPllvdSBjYW4gZm9yd2FyZCB0aGlzIGludml0YXRpb24gdG8gb3RoZXJzLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFw OmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50 LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxw YWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0K PHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1l bGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNEQ0RDREIj5IZWxsbywNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjcuNXB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM0RDRENEQiPk1vYmlsZSBBZC1ob2MgTmV0d29ya3MgV29ya2luZyBHcm91cCBpbnZpdGVz IHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZy YW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2 O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNz PSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIg c3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBw dCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDoxNS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlz cGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1z b05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5 bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGlu IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNEQ0RDREIj5NQU5FVCBXb3JraW5nIEdyb3VwIEludGVyaW08L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM0RDRENEQiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM2NjY2NjYiPldlZG5lc2RheSwgSnVuZSAxMCwgMjAxNQ0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNv LWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVu dC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1l bGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjExOjAwIGFtJm5ic3A7Jm5ic3A7fCZuYnNw OyZuYnNwO0Vhc3Rlcm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkmbmJzcDsm bmJzcDt8Jm5ic3A7Jm5ic3A7MiBocnMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRp Y2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhl aWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6 bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9Indp ZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQg c3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTtt c28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21z by1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhv cml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25l Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRh YmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBp bjt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRp bmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDBBRkY5Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvai5waHA/TVRJRD1tMjA2MzU3MDM5MGNhYmQxYzgwNTRiZGE4ODJmNjdiY2IiPjxi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlvbjpub25lIj5Kb2luIFdl YkV4IG1lZXRpbmc8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVj b3JhdGlvbjpub25lIj4NCjwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N CjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxh eTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9Indp ZHRoOjBpbjt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGluIDMuNzVwdCAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPk1l ZXRpbmcgbnVtYmVyOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0i cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3Bh Y2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0 aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+NjQ3IDAy OSA5MTENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBpbiAzLjc1cHQgMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZy YW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2 Ij5NZWV0aW5nIHBhc3N3b3JkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjEy MzQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxl bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdy YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2Vs bHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+ DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4g MGluIDBpbjtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDph cm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1h bmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFk ZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0 cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPkpvaW4g YnkgcGhvbmU8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDph cm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1h bmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4xLTg3Ny02NjgtNDQ5Mzwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVT L0NhbmFkYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBz dHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFt ZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hv ci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1u O21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2 NiI+MS02NTAtNDc5LTMyMDg8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+ Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1l bGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5BY2Nlc3MgY29kZTombmJzcDs2NDcgMDI5IDkx MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRp Y2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhl aWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48YSBocmVm PSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246 bm9uZSI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9zcGFuPjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTtt c28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21z by1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhv cml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9 ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtoZWln aHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4w cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28t ZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBo O21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhh Y3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1l bGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lk dGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHls ZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1o c3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12 ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21z by1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+PGEg aHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWNiNTY3Yzg3NWFi MTM4Y2I3NTlmMWFmZGI1MGNjMmEyIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRl Y29yYXRpb246bm9uZSI+QWRkIHRoaXMgbWVldGluZzwvc3Bhbj48L2E+IHRvIHlvdXIgY2FsZW5k YXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVs ZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13 cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVt ZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNl bGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5 Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGlu IDBpbiAwaW47aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRp Y2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhl aWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBh ZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVs ZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxl bWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9u dGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM2NjY2NjYiPkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/DQo8YSBocmVmPSJodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvbWMiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3Jh dGlvbjpub25lIj5Db250YWN0IHN1cHBvcnQuPC9zcGFuPjwvYT4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVt ZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxl IGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9 IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0 OjcuNXB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0OjcuNXB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjcuNXB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0EwQTBBMCI+SU1QT1JU QU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1 ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSBy ZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkg am9pbmluZw0KIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNo IHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlz Y3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Np b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJv ZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPEJSPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwMzM2Nic+Cl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiAKVGhpcyBlbGVjdHJv bmljIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zPEJS PgppbmZvcm1hdGlvbiBmcm9tIGlEaXJlY3QsIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkLCBwcm9w cmlldGFyeTxCUj4KYW5kL29yIGNvbmZpZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsPEJSPgpvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFy ZSBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBvcmlnaW5hbDxCUj4KcmVjaXBpZW50IG9y IHRoZSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdGhlIGVtYWlsIHRvIHRoZTxC Uj4gaW50ZW5kZWQgcmVjaXBpZW50LCBiZSBhZHZpc2VkIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbDxCUj4KaW4gZXJyb3IsIGFuZCB0aGF0IGFueSB1c2UsIGRpc3NlbWluYXRpb24s IGZvcndhcmRpbmcsIHByaW50aW5nLCBvcjxCUj4gY29weWluZyBvZiB0aGlzIGVtYWlsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzIGVtYWlsPEJSPgppbiBlcnJv ciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIuPEJS PgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyAK PC9TUEFOPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5730851c291840e593f76d4767848fc4VAUSDITCHM2idirectnet_-- --_004_5730851c291840e593f76d4767848fc4VAUSDITCHM2idirectnet_ Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=3870; creation-date="Tue, 09 Jun 2015 23:49:49 GMT"; modification-date="Tue, 09 Jun 2015 23:49:49 GMT" Content-ID: <8A624A77A21BB54BAD4509B319326314@idirect.net> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJNb2JpbGUgQWQtaG9j IE5ldHdvcmtzIFdvcmtpbmcgR3JvdXAiO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9VFJVRTpN QUlMVE86bWFuZXQtY2hhaXJzQGlldGYub3JnCk9SR0FOSVpFUjtDTj0iTW9iaWxlIEFkLWhvYyBO ZXR3b3JrcyBXb3JraW5nIEdyb3VwIjpNQUlMVE86bWFuZXQtY2hhaXJzQGlldGYub3JnCkRUU1RB UlQ7VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE1MDYxMFQxMTAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVy biBUaW1lIjoyMDE1MDYxMFQxMzAwMDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MTQzMzg5Mzc3NgpVSUQ6Y2U4MjVhZGUtZWQyYi00 Y2M5LTk3NmYtYTY3MTg0N2IwM2JhCkRUU1RBTVA6MjAxNTA2MTBUMTUwMDAwWgpERVNDUklQVElP TjpcblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW04N2ZhN2MwMTE1MWY4NDA4OTRmMmM5ZjdlODQwYTE3ZVxuTWVldGluZyBudW1i ZXI6IDY0NyAwMjkgOTExXG5NZWV0aW5nIHBhc3N3b3JkOiAxMjM0XG5cblxuSk9JTiBCWSBQSE9O RVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIFxu MS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuQWNjZXNzIGNv ZGU6IDY0NyAwMjkgOTExXG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogXG5odHRw Oi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5cblxuQ2Fu J3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYu d2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0 IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNl bnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292 ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1 dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29u c2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhv c3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRUWVBFPXRleHQv aHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZPTlQgU0laRT0i NCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9NVElEPW04N2ZhN2MwMTE1MWY4NDA4OTRmMmM5ZjdlODQwYTE3ZSI+PEZPTlQgU0la RT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1lZXRpbmc8L0ZP TlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05UPgkJCQkJPC90 ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPjY0NyAwMjkgOTExPC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0 YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+ TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+MTIzNDwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4JCTwvRk9O VD48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+ PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTg3Ny02NjgtNDQ5Mzwv c3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4m bmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0 cm9uZz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVT L0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPkFjY2VzcyBjb2RlOiA2NDcgMDI5IDkxMTwvRk9OVD4mbmJzcDsgPEJSPjxh IGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRm Ij48Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPlRvbGwtZnJlZSBj YWxsaW5nIHJlc3RyaWN0aW9uczwvRk9OVD48L2E+ICZuYnNwOyA8QlI+PC9GT05UPjxCUj48QlI+ CSZuYnNwOzxCUj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj4J CQkJQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz88L0ZPTlQ+CTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9tYyI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJB cmlhbCI+Q29udGFjdCBzdXBwb3J0LjwvRk9OVD48L2E+CSZuYnNwOzxCUj4mbmJzcDs8QlI+PEZP TlQgQ09MT1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQgTk9USUNF OiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90 aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3 aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRo aXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3Mu IElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNv bmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPC9GT05UPjwv Rk9OVD4KU1VNTUFSWTpNQU5FVCBXb3JraW5nIEdyb3VwIEludGVyaW0KUFJJT1JJVFk6NQpDTEFT UzpQVUJMSUMKQkVHSU46VkFMQVJNClRSSUdHRVI6LVBUNU0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJ UFRJT046UmVtaW5kZXIKRU5EOlZBTEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK --_004_5730851c291840e593f76d4767848fc4VAUSDITCHM2idirectnet_-- From nobody Tue Jun 9 17:00:10 2015 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 241FF1A8AA6 for ; Tue, 9 Jun 2015 16:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 KnN-yYwTUKl4 for ; Tue, 9 Jun 2015 16:49:36 -0700 (PDT) Received: from sjmda16.webex.com (sjmda16.webex.com [64.68.124.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9CB1A8AA1 for ; Tue, 9 Jun 2015 16:49:36 -0700 (PDT) Received: from jva2tc216.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-4.webex.com [64.68.121.239]) by sjmda16.webex.com (Postfix) with ESMTP id 836BCA29C4 for ; Tue, 9 Jun 2015 23:49:36 +0000 (GMT) Received: from jva2tc216.webex.com (localhost [127.0.0.1]) by jva2tc216.webex.com (Postfix) with ESMTP id 443D6A00B5 for ; Tue, 9 Jun 2015 23:49:36 +0000 (GMT) Date: Tue, 9 Jun 2015 23:49:36 +0000 (GMT) From: Mobile Ad-hoc Networks Working Group To: manet@ietf.org Message-ID: <1720099292.8217.1433893776277.JavaMail.nobody@jva2tc216.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_8215_2066841473.1433893776276" X-Priority: 3 Importance: normal Archived-At: X-Mailman-Approved-At: Tue, 09 Jun 2015 17:00:04 -0700 Subject: [manet] WebEx meeting invitation: MANET Working Group Interim X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: manet-chairs@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 23:49:38 -0000 ------=_Part_8215_2066841473.1433893776276 Content-Type: multipart/Alternative; boundary="----=_Part_8216_1856646486.1433893776276" ------=_Part_8216_1856646486.1433893776276 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTW9iaWxlIEFkLWhvYyBOZXR3b3JrcyBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91 IHRvIGpvaW4gdGhpcyBXZWJFeCBtZWV0aW5nLgoKCk1BTkVUIFdvcmtpbmcgR3JvdXAgSW50ZXJp bQpXZWRuZXNkYXksIEp1bmUgMTAsIDIwMTUKMTE6MDAgYW0gIHwgIEVhc3Rlcm4gRGF5bGlnaHQg VGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkgIHwgIDIgaHJzCgoKSk9JTiBXRUJFWCBNRUVUSU5H Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0yODkxNmEzYTUwNTk3ZTg2 YzMzODY2NTYwZjc4NDkxMwpNZWV0aW5nIG51bWJlcjogNjQ3IDAyOSA5MTEKTWVldGluZyBwYXNz d29yZDogMTIzNAoKDQpKT0lOIEJZIFBIT05FDQoxLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwg ZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkgCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSkKQWNjZXNzIGNvZGU6IDY0NyAwMjkgOTExCgpUb2xsLWZyZWUgZGlhbGlu ZyByZXN0cmljdGlvbnM6IApodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJp Y3Rpb25zLnBkZg0KDQoKQWRkIHRoaXMgbWVldGluZyB0byB5b3VyIGNhbGVuZGFyOgpodHRwczov L2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMDQ2N2JiNmQwOWI2MjVlMzRlNDk2MmM3 ZWQ3MzMyZTUNCg0KCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJl OgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMKCgpJTVBPUlRBTlQgTk9USUNFOiBQbGVh c2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGlu Zm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBt YXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vz c2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlv dSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5z IHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uCg== ------=_Part_8216_1856646486.1433893776276 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBNb2Jp bGUgQWQtaG9jIE5ldHdvcmtzIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlz IFdlYkV4IG1lZXRpbmcuCiAgICAgICAgICAgICAgICAJICAgICAgICAgICA8L3RkPgogICAgICA8 L3RyPgo8L3RhYmxlPgoKCgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48 dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRh YmxlICB3aWR0aD0iMTAwJSI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJmb250LXNp emU6MTZweDsgY29sb3I6IzRENEQ0RCI+CgkJCQkJCQkJCTxiPk1BTkVUIFdvcmtpbmcgR3JvdXAg SW50ZXJpbTwvYj4KCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJCTx0ciBzdHlsZT0i bWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPldlZG5lc2RheSwgSnVuZSAxMCwgMjAxNQoJCQkJCQkJ CTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJ CQk8dGQ+MTE6MDAgYW0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7RWFzdGVybiBEYXlsaWdodCBU aW1lIChOZXcgWW9yaywgR01ULTA0OjAwKSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsyIGhycwoJ CQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoKPHRhYmxlPjx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRv IWltcG9ydGFudCI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJjb2xvcjojMDBBRkY5 O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJCQkJCQkJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTI4OTE2YTNhNTA1OTdlODZjMzM4NjY1NjBmNzg0OTEzIgoJCQkJ CQkJCQkJc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNnB4O2NvbG9yOiMw MEFGRjkiPgoJCQkJCQkJCQkJPGI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9iPgoJCQkJCQkJCQk8L2E+ CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFibGU+CgkJCQkJCTx0YWJsZSBz dHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRyIHN0eWxl PSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVweDsiPgoJ CQkJCQkJCQlNZWV0aW5nIG51bWJlcjoKCQkJCQkJCQk8L3RkPgoJCQkJCQkJCTx0ZD42NDcgMDI5 IDkxMQoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBz dHlsZT0icGFkZGluZy1yaWdodDogNXB4OyI+TWVldGluZyBwYXNzd29yZDo8L3RkPgoJCQkJCQkJ CTx0ZD4xMjM0PC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFibGU+CgoKCgkKCgk8dGFibGU+ PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJz cDs8L3RkPjwvdHI+PC90YWJsZT48dGFibGU+PHRyPjx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHgi PjxiPkpvaW4gYnkgcGhvbmU8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRk PjxiPjEtODc3LTY2OC00NDkzPC9iPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMv Q2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTY1MC00Nzkt MzIwODwvYj4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC90ZD48L3RyPjx0 ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPkFjY2VzcyBjb2RlOiZuYnNwOzY0NyAwMjkgOTExPC90 ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPjxhIGhyZWY9Imh0dHA6Ly93d3cud2Vi ZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7Y29sb3I6IzAwQUZGOTsiPlRvbGwtZnJlZSBjYWxsaW5n IHJlc3RyaWN0aW9uczwvYT48L3RkPjwvdHI+PC90YWJsZT4KCgkJCQkJPHRhYmxlPjx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxM3B4Ij48YSBocmVm PSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMDQ2N2JiNmQwOWI2MjVl MzRlNDk2MmM3ZWQ3MzMyZTUiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBB RkY5OyBmb250LXNpemU6MTNweCI+QWRkIHRoaXMgbWVldGluZzwvYT4gdG8geW91ciBjYWxlbmRh ci48L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7 Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxl PgogICAgPHRyPgogICAgICAgPHRkIHN0eWxlPSJmb250LXNpemU6IDEzcHg7Zm9udC1mYW1pbHk6 IEFyaWFsO2NvbG9yOiAjNjY2NjY2OyI+CiAgICAgICAgQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8K ICAgICAJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIiBzdHlsZT0idGV4 dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 IzAwQUZGOTtmb250LWNvbG9yOiMwMEFGRjk7Ij4KICAgICAgICAJQ29udGFjdCBzdXBwb3J0Ljwv YT4KCQk8L3RkPgogICAgPC90cj4KPC90YWJsZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWln aHQ6IDEwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoxMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJs ZT4KCQkJCQkJPHRhYmxlPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXpl OjEycHg7Y29sb3I6ICNBMEEwQTA7Ij4KCQkJCQkJCQkJSU1QT1JUQU5UIE5PVElDRTogUGxlYXNl IG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZv cm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5 IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Np b24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3Ug ZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3 aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLjwvdGQ+CgkJCQkJCQk8L3Ry PgoJCQkJCQk8L3RhYmxlPgoJCQkJPC90ZD4KCQkJPC90cj4KCQk8L3RhYmxlPgoJPC90ZD4KICAg PC90cj4KPC90YWJsZT4KCjwvYm9keT4= ------=_Part_8216_1856646486.1433893776276-- ------=_Part_8215_2066841473.1433893776276 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86bWFuZXRAaWV0Zi5vcmcKT1JHQU5JWkVSO0NOPSJN b2JpbGUgQWQtaG9jIE5ldHdvcmtzIFdvcmtpbmcgR3JvdXAiOk1BSUxUTzptYW5ldC1jaGFpcnNA aWV0Zi5vcmcKRFRTVEFSVDtUWklEPSJFYXN0ZXJuIFRpbWUiOjIwMTUwNjEwVDExMDAwMApEVEVO RDtUWklEPSJFYXN0ZXJuIFRpbWUiOjIwMTUwNjEwVDEzMDAwMApMT0NBVElPTjpodHRwczovL2ll dGYud2ViZXguY29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNDMzODkzNzc2ClVJRDpj ZTgyNWFkZS1lZDJiLTRjYzktOTc2Zi1hNjcxODQ3YjAzYmEKRFRTVEFNUDoyMDE1MDYxMFQxNTAw MDBaCkRFU0NSSVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTIwNjM1NzAzOTBjYWJkMWM4MDU0YmRhODgyZjY3YmNi XG5NZWV0aW5nIG51bWJlcjogNjQ3IDAyOSA5MTFcbk1lZXRpbmcgcGFzc3dvcmQ6IDEyMzRcblxu XG5KT0lOIEJZIFBIT05FXG4xLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIg KFVTL0NhbmFkYSkgXG4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5h ZGEpXG5BY2Nlc3MgY29kZTogNjQ3IDAyOSA5MTFcblxuVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJp Y3Rpb25zOiBcbmh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMu cGRmXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZTpc bmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tY1xuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIg aW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNo IG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBz ZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYg eW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2Vy bnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbgpYLUFMVC1ERVND O0ZNVFRZUEU9dGV4dC9odG1sOgk8Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJS PiA8Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+CQk8YQkJCQkJaHJlZj0iaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTIwNjM1NzAzOTBjYWJkMWM4MDU0YmRhODgyZjY3 YmNiIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iQXJpYWwiPkpvaW4gV2Vi RXggbWVldGluZzwvRk9OVD48L2E+CQkJPHRhYmxlPgkJCQk8dHI+CQkJCQk8dGQ+CQkJCQkJPEZP TlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlcjo8 L0ZPTlQ+CQkJCQk8L3RkPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+NjQ3IDAyOSA5MTE8L0ZPTlQ+CQkJCQk8L3RkPgkJCQk8L3RyPgkJ CTwvdGFibGU+CQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpF PSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj4xMjM0PC9GT05UPjwvdGQ+PC90cj48 L3RhYmxlPgkJPC9GT05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5i c3A7PEJSPjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPjEt ODc3LTY2OC00NDkzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9D YW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZB Q0U9ImFyaWFsIj48c3Ryb25nPjEtNjUwLTQ3OS0zMjA4PC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0 b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+QWNjZXNzIGNvZGU6IDY0NyAwMjkgOTExPC9GT05U PiZuYnNwOyA8QlI+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jl c3RyaWN0aW9ucy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlh bCI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxCUj48 L0ZPTlQ+PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJlZj0i aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMw MEFGRjkiIEZBQ0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJS PiZuYnNwOzxCUj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklN UE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93 cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8g YmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIu IEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1 Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBk aXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vz c2lvbi48L0ZPTlQ+PC9GT05UPgpTVU1NQVJZOk1BTkVUIFdvcmtpbmcgR3JvdXAgSW50ZXJpbQpQ UklPUklUWTo1CkNMQVNTOlBVQkxJQwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQ1TQpBQ1RJT046 RElTUExBWQpERVNDUklQVElPTjpSZW1pbmRlcgpFTkQ6VkFMQVJNCkVORDpWRVZFTlQKRU5EOlZD QUxFTkRBUgo= ------=_Part_8215_2066841473.1433893776276-- From nobody Tue Jun 9 22:51:51 2015 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 262381AC3BC for ; Tue, 9 Jun 2015 22:51:49 -0700 (PDT) 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 skjBiq_ia9Uu for ; Tue, 9 Jun 2015 22:51:47 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 6D5611AC3BA for ; Tue, 9 Jun 2015 22:51:47 -0700 (PDT) Received: by wiwd19 with SMTP id d19so36798360wiw.0 for ; Tue, 09 Jun 2015 22:51:46 -0700 (PDT) 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=utr0X0kh25d7KWydYqARkm8UwxGdCr2AkHmLhJ8c2w8=; b=bDZFKR9qAqkBADDiDKOIVXU1p1gSDEgVE0BQk/NK5LzYgV4xLrbcuPuBo2uNY3G9Cl P7q4HV/+metmLgld7pjSrNyJpEgxOKTUHz3vD8XHfE+MDOTct2VlSUzeCgefTo+iLATP XaLYTn0kaRUWwt4zS/eOrGAC+x470GDOyK5S/c1ln4MJ5WrijN9STLBAOP0wNSggRoce tXxBBdCjLGbWeDGLh+p3eJ3fJEI2tWnycwsG0E5MpNmf56YwWk0XuX3yhYCnb1Y434mr XtY4PkHnIlA6IIhbYX+tr7yxNXEIIkP05OqntraGpHr06wEWbIgugzVYBOnuz5bPCuin 5iZA== X-Received: by 10.180.189.10 with SMTP id ge10mr15519989wic.85.1433915506113; Tue, 09 Jun 2015 22:51:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.86 with HTTP; Tue, 9 Jun 2015 22:51:25 -0700 (PDT) In-Reply-To: References: <20150528081235.4501.97727.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Wed, 10 Jun 2015 07:51:25 +0200 Message-ID: To: Lotte Steenbrink Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Dearlove, Christopher \(UK\)" , MANET IETF Subject: Re: [manet] New Version Notification for draft-clausen-manet-rfc5444-usage-00.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: Wed, 10 Jun 2015 05:51:49 -0000 On Tue, Jun 9, 2015 at 5:00 PM, Henning Rogge wrote: > On Tue, Jun 9, 2015 at 4:26 PM, Lotte Steenbrink > wrote: >> Hi Ulrich, Thomas, Chris and Henning, >> >> Section 6.1.: >> (I=E2=80=99m not terribly familiar with compression, so my question= s are >> probably very naive, but maybe they can help clear things up) >> Would this very straightforward to implement compression algorithm >> still produce interoperable messages? The rest of the section reads as i= f >> the =E2=80=9Ccompression algorithm=E2=80=9D mentioned in the introductio= n is mainly a way to >> cleverly arrange addresses so that they are still understood by all pars= ers, >> but take up a minimal amount of space. I think that=E2=80=99s a very goo= d tip in >> itself, but is that really all there is to compression? Would it make se= nse >> to say =E2=80=9CHere=E2=80=99s how you should arrange addresses cleverly= , you can also >> implement a more elaborate compression algorithm, but that=E2=80=99s out= of the >> scope of this document=E2=80=9D? >> Also, any mention of the word =E2=80=9Cstraightforward=E2=80=9D makes me= very suspicious, >> but that might just be me. > > Every parser for RFC5444 should be able to parse everything decribed > in RFC5444. So you are free to implement any kind of address > compression strategy... > > Address compression can be split into only two questions: > - what is the best order for the addresses for compression > - how do you split them into address blocks > > The combination of these two choices will force the distribution of > addressblock-tlvs, because you have to keep the same mapping between > addresses and the attached TLV and their values. > > That is (among other things) why demanding a special order of > addresses (or a special split of address blocks) is a BAD idea for a > protocol. It might prevent you from doing a good address compression. But I will have a look at the address compression section, I think we can still improve it. Henning Rogge From nobody Wed Jun 10 00:09:43 2015 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 426E01A8A0F for ; Wed, 10 Jun 2015 00:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.214 X-Spam-Level: **** X-Spam-Status: No, score=4.214 tagged_above=-999 required=5 tests=[BAYES_95=3, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_DKIM_INVALID=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 OxxzBY1fMLUm for ; Wed, 10 Jun 2015 00:09:40 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id A729A1A89B5 for ; Wed, 10 Jun 2015 00:09:40 -0700 (PDT) Received: (qmail 29091 invoked by uid 0); 10 Jun 2015 07:09:38 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 10 Jun 2015 07:09:38 -0000 Received: from box817.bluehost.com ([66.147.244.117]) by cmgw2 with id eWhz1q00d2Yhrsa01Wi2mt; Wed, 10 Jun 2015 00:42:03 -0600 X-Authority-Analysis: v=2.1 cv=cooIzTIi c=1 sm=1 tr=0 a=1ZWhLoquM75l/9xp6o4QLQ==:117 a=1ZWhLoquM75l/9xp6o4QLQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=x9HPBuXWPrAA:10 a=wPDyFdB5xvgA:10 a=KWLd9SN1AAAA:8 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=6U2dO19vvw8A:10 a=JMHYQVG13d8A:10 a=XAFQembCKUMA:10 a=N1z6yVdWAAAA:8 a=FqezvDcJUJLdiv9o4ssA:9 a=OP3iMzCqpaEA:10 a=aQ2Jpg5CcirEIsy52H4A:9 a=u4pdpKw8slbMiTZF:21 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sdiwc.info; s=default; h=Message-ID:Subject:To:From:Date:Content-Type:MIME-Version; bh=aZi3dKiwJSgIOyAAVs6DD5erIl54gemh1yleB35dK6g=; b=FZOFCfAE2Sy/LshdzYquIclW4BVYcILAS+JughV3vUZS8X9ut4SvzeDfd8jX7+PSi8BSBvYmISaZW7F8O2JPDG7LvN38RfoCc46mXhCBjMuZB7F8rcHydmqK3IAH+5am; Received: from localhost ([127.0.0.1]:36957 helo=box817.bluehost.com) by box817.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z2ZpP-0002PS-Kr for manet@ietf.org; Wed, 10 Jun 2015 00:49:35 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_582da434d3ff397e678df9520e6a79fb" Date: Wed, 10 Jun 2015 00:49:33 -0600 From: Jackie Blanco To: manet@ietf.org Message-ID: X-Sender: jackie@sdiwc.info User-Agent: Roundcube Webmail/1.0.1 X-Identified-User: {1337:box817.bluehost.com:sdiwcnet:sdiwc.info} {sentby:smtp auth 127.0.0.1 authed with jackie@sdiwc.info} Archived-At: Subject: [manet] CallForPapers: Fourth World Congress - SEMCMI2015 - Malaysia 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, 10 Jun 2015 07:09:42 -0000 --=_582da434d3ff397e678df9520e6a79fb Content-Transfer-Encoding: 7bit Content-Type: text/plain THE INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, MOBILE COMPUTING AND MEDIA INFORMATICS (SEMCMI2015) _Part of The Fourth World Congress on Computing, Engineering and Technology (WCET)_ Asia Pacific University of Technology and Innovation (APU) Kuala Lumpur, Malaysia September 8-10, 2015 http://sdiwc.net/conferences/semcmi2015/ [1] ALL REGISTERED PAPERS WILL BE INCLUDED IN SDIWC DIGITAL LIBRARY. ================================================================ The conference welcomes papers on the following (but not limited to) research topics: *Software Engineering Advanced Database Systems Advanced Human-Computer Interaction Artificial Intelligence Data Mining Economics of Innovation & Entrepreneurship Information Security Operating Systems Architecture Signals, Systems & Control Systems Engineering Systems Thinking for Sustainability Web Information Systems *Mobile Computing Access Control Application Service Providers Bluetooth Broadband Wireless Networks Enhanced Messaging Service Ethernet Cable Fixed-mobile Convergence Data Migration Document Management Voice Communications Software Security Managers Wireless Application Services Providers Wireless Computing Wireless Hardware Wireless Infrared Communications *Media Informatics Computer Graphics/Animation/Visualisation Data Communication Digital Interactive Media Game Design Knowledge Management Management of Information Security and Cryptography Virtual and Augmented Reality 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. Important Dates ============== Submission Deadline : August 08, 2015 NOTIFICATION OF ACCEPTANCE: AUGUST 18, 2015 OR 4 WEEKS FROM THE SUBMISSION DATE CAMERA READY DEADLINE : AUGUST 29, 2015 REGISTRATION DEADLINE : AUGUST 29, 2015 Conference Dates : September 8-10, 2015 Links: ------ [1] http://sdiwc.net/conferences/semcmi2015/ --=_582da434d3ff397e678df9520e6a79fb Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 
The International Conference on Software Engineering, Mobile C=
omputing and Media Informatics (SEMCMI2015)
Part of The Fourth World Congress on Computing, Engineering and Technol=
ogy (WCET)

Asia Pacific University of Technology and Innovation (APU)
Kuala Lumpur, Malaysia
September 8-10, 2015
http://sdiwc.net/confe=
rences/semcmi2015/

All registered papers will be inclu=
ded 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=3D=3D
The conference welcomes papers on the following (but not limited to) resear=
ch topics:

*Software Engineering
Advanced Database Systems
Advanced Human-Computer Interaction
Artificial Intelligence
Data Mining
Economics of Innovation & Entrepreneurship
Information Security
Operating Systems Architecture
Signals, Systems & Control
Systems Engineering
Systems Thinking for Sustainability
Web Information Systems

*Mobile Computing
Access Control
Application Service Providers
Bluetooth
Broadband Wireless Networks
Enhanced Messaging Service
Ethernet Cable
Fixed-mobile Convergence
Data Migration
Document Management
Voice Communications Software
Security Managers
Wireless Application Services Providers
Wireless Computing
Wireless Hardware
Wireless Infrared Communications

*Media Informatics
Computer Graphics/Animation/Visualisation
Data Communication
Digital Interactive Media
Game Design
Knowledge Management
Management of Information
Security and Cryptography
Virtual and Augmented Reality

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

Important Dates
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Submission Deadline    : August 08, 2015
Notification of Acceptance: August 18, 2015 or 4 weeks from the submissi=
on date
Camera Ready Deadline    : Aug=
ust 29, 2015
Registration Deadline    =
: August 29, 2015
Conference Dates    =
: September 8-10, 2015
--=_582da434d3ff397e678df9520e6a79fb-- From nobody Wed Jun 10 08:46:21 2015 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 708C31B2CBE for ; Wed, 10 Jun 2015 08:46:20 -0700 (PDT) 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 ETqYS3-usMH2 for ; Wed, 10 Jun 2015 08:46:19 -0700 (PDT) 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 A83421B2CBD for ; Wed, 10 Jun 2015 08:46:18 -0700 (PDT) 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; Wed, 10 Jun 2015 16:45:51 +0100 From: Rick Taylor To: manet IETF Thread-Topic: DLEP sample router Thread-Index: AdCjlIV0WgZL0PGJTwid2ae88IoeJQ== Date: Wed, 10 Jun 2015 15:45:48 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C26FCA9@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: Subject: [manet] DLEP sample router 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, 10 Jun 2015 15:46:20 -0000 All,=0A= =0A= For those who are interested, I have just pushed an updated version of =0A= my dlep_router with draft-14 support.=0A= =0A= Its at: https://github.com/ricktaylor/dlep_router=0A= =0A= It definitely needs some testing, and any feedback gratefully received.=0A= =0A= Rick Taylor=0A= From nobody Wed Jun 10 12:47:33 2015 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 832971A8885 for ; Wed, 10 Jun 2015 12:47:31 -0700 (PDT) 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, 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 meaZFqYcu-0k for ; Wed, 10 Jun 2015 12:47:29 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id D7BD61A8889 for ; Wed, 10 Jun 2015 12:47:28 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.201; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.201 as permitted sender) identity=mailfrom; client-ip=10.250.250.201; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.201; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,588,1427774400"; d="jpg'145?scan'145,208,217,145";a="17628753" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.201]) by ironport.idirect.net with ESMTP; 10 Jun 2015 15:47:28 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM1.idirect.net (10.250.250.201) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 10 Jun 2015 15:47:27 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.1076.000; Wed, 10 Jun 2015 15:47:27 -0400 From: "Ratliff, Stanley" To: "manet@ietf.org" Thread-Topic: AODVv2 Thread-Index: AdCjtaczcuzFBqOgTBmmhAghVIt7vQ== Date: Wed, 10 Jun 2015 19:47:26 +0000 Message-ID: <1ae8d256bcd34104ae6e2083b04b200e@VAUSDITCHM2.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: multipart/related; boundary="_004_1ae8d256bcd34104ae6e2083b04b200eVAUSDITCHM2idirectnet_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [manet] AODVv2 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, 10 Jun 2015 19:47:31 -0000 --_004_1ae8d256bcd34104ae6e2083b04b200eVAUSDITCHM2idirectnet_ Content-Type: multipart/alternative; boundary="_000_1ae8d256bcd34104ae6e2083b04b200eVAUSDITCHM2idirectnet_" --_000_1ae8d256bcd34104ae6e2083b04b200eVAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello, WG - Coming out of today's MANET interim meeting, I got an action item to ping t= he list, asking for reviews and comments on AODVv2. Specifically, we are lo= oking for what are considered severe technical defects - "showstoppers", if= you will. If you know of any, please respond and list them now. The items = we are actively working on are: 1. RFC 5444 compilance. There have been discussions on this topic wit= hin the AODVv2 editorial team; expect a change to the spec to address this = issue soon. 2. Gateway functionality. We are actively working on the gateway sect= ion of the draft, and are in discussion with Justin on this issue. Additionally, Justin mentioned an issue with bi-directionality that he was = not completely comfortable with. We will work with him to resolve that as w= ell. If there are any other issues, please let us know. Regards, Stan ________________________________ Stan Ratliff | Architect, Applied Research VT iDirect | 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, USA T: +1 703 544-8520 | F: +1 222 123-4567 sratliff@idirect.net | www.idirect.net Connect with iDirect: Twitter.com/iDirect | = Facebook.com/iDirect [cid:image001.jpg@01D0A394.BEBED890] Advancing a Connected World _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ --_000_1ae8d256bcd34104ae6e2083b04b200eVAUSDITCHM2idirectnet_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hello, WG –

 

Coming out of today’s MANET interim meeting, I= got an action item to ping the list, asking for reviews and comments on AO= DVv2. Specifically, we are looking for what are considered severe technical= defects – “showstoppers”, if you will. If you know of any, please respond and list them now. The items we are act= ively working on are:

 

1.     &= nbsp; RFC 5444 compilance. There have been discussions on= this topic within the AODVv2 editorial team; expect a change to the spec t= o address this issue soon.

2.     &= nbsp; Gateway functionality. We are actively working on t= he gateway section of the draft, and are in discussion with Justin on this = issue.

 

Additionally, Justin mentioned an issue with bi-dire= ctionality that he was not completely comfortable with. We will work with h= im to resolve that as well.

 

If there are any other issues, please let us know. <= o:p>

 

Regards,
Stan

Stan Ratliff  |  Architect, Applied Research<= /span>

VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Hernd= on, VA 20171, USA

T: +1 703 544-8520  |  F: +1 222 123-4567

sratliff@i= direct.net  |  www.idirect.net

Connect with iDirect: Twitter.com/iDi= rect  |  Facebook.com/i= Direct

 

<= /p>

Advancing a Connected World

 <= /span>

 


_____________________________________________________
= This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
int= ended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
cop= ying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________ = --_000_1ae8d256bcd34104ae6e2083b04b200eVAUSDITCHM2idirectnet_-- --_004_1ae8d256bcd34104ae6e2083b04b200eVAUSDITCHM2idirectnet_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3003; creation-date="Wed, 10 Jun 2015 19:47:25 GMT"; modification-date="Wed, 10 Jun 2015 19:47:25 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --_004_1ae8d256bcd34104ae6e2083b04b200eVAUSDITCHM2idirectnet_-- From nobody Wed Jun 10 12:50:20 2015 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 E4CD61A88BC for ; Wed, 10 Jun 2015 12:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.189 X-Spam-Level: X-Spam-Status: No, score=-99.189 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_DOS_OUTLOOK_TO_MX_IMAGE=0.01, USER_IN_WHITELIST=-100] 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 wFXNB99rXeU6 for ; Wed, 10 Jun 2015 12:50:15 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BA7181A88B2 for ; Wed, 10 Jun 2015 12:50:14 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.25.239; From: "Susan Hares" To: "'Ratliff, Stanley'" , References: <1ae8d256bcd34104ae6e2083b04b200e@VAUSDITCHM2.idirect.net> In-Reply-To: <1ae8d256bcd34104ae6e2083b04b200e@VAUSDITCHM2.idirect.net> Date: Wed, 10 Jun 2015 15:49:56 -0400 Message-ID: <002401d0a3b6$a14ba910$e3e2fb30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0025_01D0A395.1A3D1650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHV1ZAA3gVyEWQPaC19TYwpY2wWZp2bwX6Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [manet] AODVv2 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, 10 Jun 2015 19:50:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0025_01D0A395.1A3D1650 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0026_01D0A395.1A3D1650" ------=_NextPart_001_0026_01D0A395.1A3D1650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stan: I apologize I could not attend today's MANET meeting. I will be glad to send in a review of ADOVv2 and my view of pros/cons of the OLSR-v2 and MT-OSLRv2. There is a place for both. I'm really over-the-top busy until early next week. Will that be soon enough? I hope that you will work with these protocols a bit longer as the deployments of some of the Wifi technologies are getting deployed. Sue From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ratliff, Stanley Sent: Wednesday, June 10, 2015 3:47 PM To: manet@ietf.org Subject: [manet] AODVv2 Hello, WG - Coming out of today's MANET interim meeting, I got an action item to ping the list, asking for reviews and comments on AODVv2. Specifically, we are looking for what are considered severe technical defects - "showstoppers", if you will. If you know of any, please respond and list them now. The items we are actively working on are: 1. RFC 5444 compilance. There have been discussions on this topic within the AODVv2 editorial team; expect a change to the spec to address this issue soon. 2. Gateway functionality. We are actively working on the gateway section of the draft, and are in discussion with Justin on this issue. Additionally, Justin mentioned an issue with bi-directionality that he was not completely comfortable with. We will work with him to resolve that as well. If there are any other issues, please let us know. Regards, Stan _____ Stan Ratliff | Architect, Applied Research VT iDirect | 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, USA T: +1 703 544-8520 | F: +1 222 123-4567 sratliff@idirect.net | www.idirect.net Connect with iDirect: Twitter.com/iDirect | Facebook.com/iDirect Advancing a Connected World _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ ------=_NextPart_001_0026_01D0A395.1A3D1650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stan: =

 

I apologize I could not = attend today’s MANET meeting.  I will be glad to send in a = review of ADOVv2 and my view of pros/cons of the OLSR-v2 and = MT-OSLRv2.  There is a place for both.  I’m really = over-the-top busy until early next week.  Will that be soon enough? =

 

I hope that you will = work with these protocols a bit longer as the deployments of some of the = Wifi technologies are getting deployed.

 

Sue =

 

 

From:= = manet [mailto:manet-bounces@ietf.org] On Behalf Of Ratliff, = Stanley
Sent: Wednesday, June 10, 2015 3:47 PM
To: = manet@ietf.org
Subject: [manet] = AODVv2

 

Hello, WG = –

 

Coming out of today’s MANET interim meeting, I = got an action item to ping the list, asking for reviews and comments on = AODVv2. Specifically, we are looking for what are considered severe = technical defects – “showstoppers”, if you will. If = you know of any, please respond and list them now. The items we are = actively working on are:

 

1.       RFC 5444 = compilance. There have been discussions on this topic within the AODVv2 = editorial team; expect a change to the spec to address this issue soon. =

2.       Gateway = functionality. We are actively working on the gateway section of the = draft, and are in discussion with Justin on this issue. =

 

Additionally, Justin mentioned an issue with = bi-directionality that he was not completely comfortable with. We will = work with him to resolve that as well.

 

If there are = any other issues, please let us know.

 

Regards,
Stan

= Stan Ratliff  = |  Architect, Applied Research

= VT iDirect  = |  13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, = USA

= T: +1 703 544-8520  |  F: +1 222 = 123-4567

sratliff@idirect.net  |  www= .idirect.net

= Connect with iDirect: Twi= tter.com/iDirect&nb= sp; = |  Fac= ebook.com/iDirect=

 

=

= Advancing a Connected World

 

 


= _____________________________________________________
This electronic = message and any files transmitted with it contains
information from = iDirect, which may be privileged, proprietary
and/or confidential. It = is intended solely for the use of the individual
or entity to whom = they are addressed. If you are not the original
recipient or the = person responsible for delivering the email to the
intended = recipient, be advised that you have received this email
in error, and = that any use, dissemination, forwarding, printing, or
copying of this = email is strictly prohibited. If you received this email
in error, = please delete it and immediately notify the = sender.
_____________________________________________________ =

------=_NextPart_001_0026_01D0A395.1A3D1650-- ------=_NextPart_000_0025_01D0A395.1A3D1650 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z ------=_NextPart_000_0025_01D0A395.1A3D1650-- From nobody Wed Jun 10 12:52:53 2015 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 DA08D1A8948 for ; Wed, 10 Jun 2015 12:52:50 -0700 (PDT) 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 iPwC4d4tlVPx for ; Wed, 10 Jun 2015 12:52:45 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id BFF541A88FC for ; Wed, 10 Jun 2015 12:52:44 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,589,1427774400"; d="jpg'145?scan'145,208,217,145";a="7890312" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport2.idirect.net with ESMTP; 10 Jun 2015 15:52:44 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 10 Jun 2015 15:52:43 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.1076.000; Wed, 10 Jun 2015 15:52:43 -0400 From: "Ratliff, Stanley" To: "manet@ietf.org" Thread-Topic: Poll for consensus on WG adoption of draft-clausen-manet-rfc5444-usage-00 Thread-Index: AdCjtqA5qzKzvIPhTcCWdPXTNAtF/g== Date: Wed, 10 Jun 2015 19:52:42 +0000 Message-ID: <6cd5b052f8a3474099a5ef239dae5bf1@VAUSDITCHM2.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: multipart/related; boundary="_004_6cd5b052f8a3474099a5ef239dae5bf1VAUSDITCHM2idirectnet_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [manet] Poll for consensus on WG adoption of draft-clausen-manet-rfc5444-usage-00 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, 10 Jun 2015 19:52:51 -0000 --_004_6cd5b052f8a3474099a5ef239dae5bf1VAUSDITCHM2idirectnet_ Content-Type: multipart/alternative; boundary="_000_6cd5b052f8a3474099a5ef239dae5bf1VAUSDITCHM2idirectnet_" --_000_6cd5b052f8a3474099a5ef239dae5bf1VAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello working group, At today's MANET interim meeting, there was a call for WG adoption of draft= -clausen-manet-rfc5444-usage-00. Unless significant resistance is posted to the list by June 17, the documen= t will be accepted as a WG doc (silence is assumed to be acceptance). Regards, Stan ________________________________ Stan Ratliff | Architect, Applied Research VT iDirect | 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, USA T: +1 703 544-8520 | F: +1 222 123-4567 sratliff@idirect.net | www.idirect.net Connect with iDirect: Twitter.com/iDirect | = Facebook.com/iDirect [cid:image001.jpg@01D0A395.7C12DD10] Advancing a Connected World _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ --_000_6cd5b052f8a3474099a5ef239dae5bf1VAUSDITCHM2idirectnet_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hello working group,

 

At today’s MANET interim meeting, there was a = call for WG adoption of draft-clausen-manet-rfc5444-usage-00.

 

Unless significant resistance is posted to the list = by June 17, the document will be accepted as a WG doc (silence is assumed t= o be acceptance).

 

Regards,
Stan

Stan Ratliff  |  Architect, Applied Research<= /span>

VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Hernd= on, VA 20171, USA

T: +1 703 544-8520  |  F: +1 222 123-4567

sratliff@i= direct.net  |  www.idirect.net

Connect with iDirect: Twitter.com/iDi= rect  |  Facebook.com/i= Direct

 

<= /p>

Advancing a Connected World

 <= /span>

 


_____________________________________________________
= This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
int= ended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
cop= ying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________ = --_000_6cd5b052f8a3474099a5ef239dae5bf1VAUSDITCHM2idirectnet_-- --_004_6cd5b052f8a3474099a5ef239dae5bf1VAUSDITCHM2idirectnet_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3003; creation-date="Wed, 10 Jun 2015 19:52:42 GMT"; modification-date="Wed, 10 Jun 2015 19:52:42 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --_004_6cd5b052f8a3474099a5ef239dae5bf1VAUSDITCHM2idirectnet_-- From nobody Wed Jun 10 13:04:12 2015 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 B75D31A8AAC for ; Wed, 10 Jun 2015 13:04:10 -0700 (PDT) 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 BePsaFTAEJzL for ; Wed, 10 Jun 2015 13:04:09 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (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 460621A8AA9 for ; Wed, 10 Jun 2015 13:04:09 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so41555436ieb.0 for ; Wed, 10 Jun 2015 13:04:08 -0700 (PDT) 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=/SoSAeB6BJVa9By/OyjooXoEN6uaXcVkCkCF4jCh9uU=; b=fiSSacUn502sC6freXk95dLsS5m89Fcz5RwU5p4t54ECOQXmfSGuJHKy1pPS2iDfKg huqW+N4TJIT8DBeRiYr9OZY/J1mtezAqhSFa2h05r4vegD1SU0jpdVz3Fbo94556amLq lbAq2Fh+VcvK1EbKftKk/mEF82nPjlxuezgbnmk4xXJ/1H8PA9Zm9T9Uu+b4BXwbERpU DdyNs3o4+YMRB6P1DC72IXbGP6paBytZNz3l9Q0cFfyA2eoMwPWbaQAvdTswGsUmLUlB 07c093Xl3quRQOEiHD+lZhTWchUiAd7Dh3sWs1nrz7oOqUgSEYtAljsgcOUCIqg6kYml UbWw== X-Received: by 10.50.136.134 with SMTP id qa6mr30052980igb.26.1433966648629; Wed, 10 Jun 2015 13:04:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.122.101 with HTTP; Wed, 10 Jun 2015 13:03:48 -0700 (PDT) In-Reply-To: <6cd5b052f8a3474099a5ef239dae5bf1@VAUSDITCHM2.idirect.net> References: <6cd5b052f8a3474099a5ef239dae5bf1@VAUSDITCHM2.idirect.net> From: Henning Rogge Date: Wed, 10 Jun 2015 22:03:48 +0200 Message-ID: To: "Ratliff, Stanley" Content-Type: multipart/alternative; boundary=089e0141a8dcb6210605182f60f2 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Poll for consensus on WG adoption of draft-clausen-manet-rfc5444-usage-00 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, 10 Jun 2015 20:04:10 -0000 --089e0141a8dcb6210605182f60f2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 10, 2015 at 9:52 PM, Ratliff, Stanley wrote: > Hello working group, > > > > At today=E2=80=99s MANET interim meeting, there was a call for WG adoptio= n of > draft-clausen-manet-rfc5444-usage-00. > > > > Unless significant resistance is posted to the list by June 17, the > document will be accepted as a WG doc (silence is assumed to be acceptanc= e). > I might be a bit biased, but I think this draft/rfc will become very useful both for Manet protocol designers AND implementers. +1 by me. Henning --089e0141a8dcb6210605182f60f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 10, 2015 at 9:52 PM, Ratliff, Stanley <sratliff@idirect.net= > wrote:

Hello working group,

=C2=A0

At today=E2=80=99s MANET interim meeting, there was = a call for WG adoption of draft-clausen-manet-rfc5444-usage-00.

=C2=A0

Unless significant resistance is posted to the list = by June 17, the document will be accepted as a WG doc (silence is assumed t= o be acceptance).


I might b= e a bit biased, but I think this draft/rfc will become very useful both for= Manet protocol designers AND implementers.

+1 by = me.

Henning
--089e0141a8dcb6210605182f60f2-- From nobody Wed Jun 10 13:38:10 2015 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 F14AE1ACD87 for ; Wed, 10 Jun 2015 13:38:08 -0700 (PDT) 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 9tLPQG2192ke for ; Wed, 10 Jun 2015 13:38:07 -0700 (PDT) Received: from mail-yk0-x243.google.com (mail-yk0-x243.google.com [IPv6:2607:f8b0:4002:c07::243]) (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 C6FB71ACDDB for ; Wed, 10 Jun 2015 13:38:05 -0700 (PDT) Received: by ykp9 with SMTP id 9so597215ykp.0 for ; Wed, 10 Jun 2015 13:38:05 -0700 (PDT) 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=Q54wV5Qlma1tfE6+Zz7gPITAUiIYCVRvmLNcPuiQsm0=; b=sFy4cE/3DgldQnHFyiDvi2zxgWmzD2Wz+aydfHKaNYQaImrpVtnCUrmJbHrSMOIoMj ePWSO8b7INQqYmQg6aBp7EG3s/JL5Q8JCCR374WmI5bayo5k/0sCpRPpIc3mKnbGu+t5 Wa9jfcziAnfwVq9qSk+jnyK5E0crjlOTaMt28gWZ3NodMHKrwIVFEyViha79nHv8oge0 3KAozMXFw9QrgMrcBWTwX3iBL94Ei+T7bihKyy3eSYIm5OcaRfvkIoGbfdcXH5OQ3WtE 5GUQD8pIn3LXrJjqgsRRehIxmHZuKcQMkVoWYEcDeW+z3Aund0YMk8qbcsnrKV7BrA+S iGgw== MIME-Version: 1.0 X-Received: by 10.170.139.132 with SMTP id g126mr6762261ykc.98.1433968685188; Wed, 10 Jun 2015 13:38:05 -0700 (PDT) Received: by 10.129.146.210 with HTTP; Wed, 10 Jun 2015 13:38:05 -0700 (PDT) In-Reply-To: References: <6cd5b052f8a3474099a5ef239dae5bf1@VAUSDITCHM2.idirect.net> Date: Wed, 10 Jun 2015 16:38:05 -0400 Message-ID: From: James Nguyen To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11397cae198ad405182fda9b Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Poll for consensus on WG adoption of draft-clausen-manet-rfc5444-usage-00 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, 10 Jun 2015 20:38:09 -0000 --001a11397cae198ad405182fda9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 I've been looking for this for a long time. James On Wed, Jun 10, 2015 at 4:03 PM, Henning Rogge wrote: > On Wed, Jun 10, 2015 at 9:52 PM, Ratliff, Stanley > wrote: > >> Hello working group, >> >> >> >> At today=E2=80=99s MANET interim meeting, there was a call for WG adopti= on of >> draft-clausen-manet-rfc5444-usage-00. >> >> >> >> Unless significant resistance is posted to the list by June 17, the >> document will be accepted as a WG doc (silence is assumed to be acceptan= ce). >> > > I might be a bit biased, but I think this draft/rfc will become very > useful both for Manet protocol designers AND implementers. > > +1 by me. > > Henning > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --=20 James Nguyen Email: james.huy.nguyen@gmail.com --001a11397cae198ad405182fda9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

I've been looking for this = for a long time.=C2=A0

James

On Wed, Jun 10, 2015 at 4:03 PM, Henning= Rogge <hrogge@gmail.com> wrote:
On Wed, Jun 10, 2015 at 9:52 PM, Ratliff, Stanley <s= ratliff@idirect.net> wrote:

Hello working group,

=C2=A0

At today=E2=80=99s MANET interim meeting, there was = a call for WG adoption of draft-clausen-manet-rfc5444-usage-00.

=C2=A0

Unless significant resistance is posted to the list = by June 17, the document will be accepted as a WG doc (silence is assumed t= o be acceptance).


I = might be a bit biased, but I think this draft/rfc will become very useful b= oth for Manet protocol designers AND implementers.

+1 by me.

Henning

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




--
James Nguyen
Email: james.huy.nguyen@gmail.com
--001a11397cae198ad405182fda9b-- From nobody Fri Jun 12 06:43:19 2015 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 201671AC3B9 for ; Fri, 12 Jun 2015 06:43:18 -0700 (PDT) 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 xqSJetID6V-A for ; Fri, 12 Jun 2015 06:43:16 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (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 EF5231AC3B5 for ; Fri, 12 Jun 2015 06:43:15 -0700 (PDT) Received: by wgez8 with SMTP id z8so25355892wge.0 for ; Fri, 12 Jun 2015 06:43:14 -0700 (PDT) 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=oLKAQAhLrJToJwGgV/zOncR4Bl2XLwTvzNjgs8X1+mI=; b=bFkyhhJeWyqx9JJEvIE0d2cDrKiMkqCuay7PQOTT/9RCbBpDvmZW+uKNw4cd6Io6Rq uumIay9aNC4G5o9MnlpTJR6T2MR3J6ZzjZcOvaS9KHsgsbIddRs+cq2BdXsctsyVh82z eZdTk3XkDbbUX7WcAXzm6ZEbytKprdwpQZHhrWgovRSdcrMQrPS8TqN9KFyzaQdzqsW9 reDZbDK2HtmKURsHQv7vki7LvDs6Rid7u6dLZ5jvjQfOF2r07iCRd/w3SWZFC2uO2IiY u3HN9WZaHt4WGkjRiCZhiG/c8RU5p4yfwgKdW62d8MYzfV9vwdpuprCVd044PFBoQUL9 9kow== X-Received: by 10.180.100.101 with SMTP id ex5mr7265926wib.13.1434116594690; Fri, 12 Jun 2015 06:43:14 -0700 (PDT) Received: from [10.0.4.178] ([217.158.48.187]) by mx.google.com with ESMTPSA id cd9sm5921727wjc.34.2015.06.12.06.43.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2015 06:43:14 -0700 (PDT) Message-ID: <557AE1F0.9010106@gmail.com> Date: Fri, 12 Jun 2015 14:43:12 +0100 From: John Dowdell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: manet@ietf.org References: <6cd5b052f8a3474099a5ef239dae5bf1@VAUSDITCHM2.idirect.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030304090906020108070603" Archived-At: Subject: Re: [manet] Poll for consensus on WG adoption of draft-clausen-manet-rfc5444-usage-00 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, 12 Jun 2015 13:43:18 -0000 This is a multi-part message in MIME format. --------------030304090906020108070603 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit +1 from me too. I am looking forwards to reading the definitive guidance. John On 10/06/15 21:38, James Nguyen wrote: > +1 > > I've been looking for this for a long time. > > James > > On Wed, Jun 10, 2015 at 4:03 PM, Henning Rogge > wrote: > > On Wed, Jun 10, 2015 at 9:52 PM, Ratliff, Stanley > > wrote: > > Hello working group, > > At today’s MANET interim meeting, there was a call for WG > adoption of draft-clausen-manet-rfc5444-usage-00. > > Unless significant resistance is posted to the list by June > 17, the document will be accepted as a WG doc (silence is > assumed to be acceptance). > > > I might be a bit biased, but I think this draft/rfc will become > very useful both for Manet protocol designers AND implementers. > > +1 by me. > > Henning > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > -- > James Nguyen > Email: james.huy.nguyen@gmail.com > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --------------030304090906020108070603 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit +1 from me too. I am looking forwards to reading the definitive guidance.

John

On 10/06/15 21:38, James Nguyen wrote:
+1

I've been looking for this for a long time. 

James

On Wed, Jun 10, 2015 at 4:03 PM, Henning Rogge <hrogge@gmail.com> wrote:
On Wed, Jun 10, 2015 at 9:52 PM, Ratliff, Stanley <sratliff@idirect.net> wrote:

Hello working group,

 

At today’s MANET interim meeting, there was a call for WG adoption of draft-clausen-manet-rfc5444-usage-00.

 

Unless significant resistance is posted to the list by June 17, the document will be accepted as a WG doc (silence is assumed to be acceptance).
I might be a bit biased, but I think this draft/rfc will become very useful both for Manet protocol designers AND implementers.

+1 by me.

Henning

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




--
James Nguyen
Email: james.huy.nguyen@gmail.com


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

--------------030304090906020108070603-- From nobody Fri Jun 12 07:12:50 2015 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 4ED981AC430 for ; Fri, 12 Jun 2015 07:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 hKlumRewqj3V for ; Fri, 12 Jun 2015 07:12:46 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 8B9C11A9234 for ; Fri, 12 Jun 2015 07:12:46 -0700 (PDT) Received: by wiwd19 with SMTP id d19so20101121wiw.0 for ; Fri, 12 Jun 2015 07:12:45 -0700 (PDT) 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=zxz9m7ybLKCt9L+T1ig0XWrKUlTEaiDZUHPhYkaD26Y=; b=Cx+TdEZNGl/fcIAJ416G72RvrABrcKMIHQauX2lzXwfiCkHTnS0KmPdvmHTubHaMo0 o8MTFtGZSNgC7nGaEriUkwa44eREDmE4gQ5w+DI2UT9Mcj9DDebH/AAPupAepR9mwLUS c+275EhInGLzXJJo8jxosDAasLBCMYoh2Qhfm9L6zw4ut+LBSb5doi6E2+56GJCLQ2Aj LSdZix96rsIsTuF1jxgyOCddyaOZEQRPaCzrnVRrO5u4wgrlBiI8be7AOEJy/kFhIiGk 7BLKDeJVqKIhsmyEKD4bTRGtZHgubu9MDllSHx6iQ1P3rfcxa6fuukI8IXODdXsj6wwa N0+w== X-Received: by 10.180.76.228 with SMTP id n4mr7277042wiw.44.1434118365342; Fri, 12 Jun 2015 07:12:45 -0700 (PDT) Received: from [10.128.195.7] ([188.164.13.74]) by mx.google.com with ESMTPSA id fb3sm2937820wib.21.2015.06.12.07.12.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jun 2015 07:12:44 -0700 (PDT) References: <6cd5b052f8a3474099a5ef239dae5bf1@VAUSDITCHM2.idirect.net> <557AE1F0.9010106@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <557AE1F0.9010106@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2B19B6C5-68DB-4AAB-AEF3-EA99D9BBC43D Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12F70) From: Christopher Dearlove Date: Fri, 12 Jun 2015 15:12:33 +0100 To: John Dowdell Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Poll for consensus on WG adoption of draft-clausen-manet-rfc5444-usage-00 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, 12 Jun 2015 14:12:48 -0000 --Apple-Mail-2B19B6C5-68DB-4AAB-AEF3-EA99D9BBC43D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It probably doesn't need me to say I'm in favour of adoption, but for the re= cord I am. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 12 Jun 2015, at 14:43, John Dowdell wrote= : >=20 > +1 from me too. I am looking forwards to reading the definitive guidance. >=20 > John >=20 >> On 10/06/15 21:38, James Nguyen wrote: >> +1=20 >>=20 >> I've been looking for this for a long time. =20 >>=20 >> James >>=20 >>> On Wed, Jun 10, 2015 at 4:03 PM, Henning Rogge wrote:= >>>> On Wed, Jun 10, 2015 at 9:52 PM, Ratliff, Stanley wrote: >>>> Hello working group, >>>>=20 >>>> =20 >>>>=20 >>>> At today=E2=80=99s MANET interim meeting, there was a call for WG adopt= ion of draft-clausen-manet-rfc5444-usage-00. >>>>=20 >>>> =20 >>>>=20 >>>> Unless significant resistance is posted to the list by June 17, the doc= ument will be accepted as a WG doc (silence is assumed to be acceptance). >>>>=20 >>>=20 >>> I might be a bit biased, but I think this draft/rfc will become very use= ful both for Manet protocol designers AND implementers. >>>=20 >>> +1 by me. >>>=20 >>> Henning >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> --=20 >> James Nguyen >> Email: james.huy.nguyen@gmail.com >>=20 >>=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 --Apple-Mail-2B19B6C5-68DB-4AAB-AEF3-EA99D9BBC43D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It probably doesn't need me to say I'm= in favour of adoption, but for the record I am.

--  Christopher Dearlove
<= /div>

On 12 Jun 2015, at 14:43, John Dowdell <john.dowdell.ietf@gmail.com> wrote:
=20 =20 =20 +1 from me too. I am looking forwards to reading the definitive guidance.

John

On 10/06/15 21:38, James Nguyen wrote:
+1

I've been looking for this for a long time. 

James

On Wed, Jun 10, 2015 at 4:03 PM, Henning Rogge <hrogge@gmail.com> wrote:
On Wed, Jun 10, 2015 at 9:52 PM, Ratliff, Stanley <= sratliff@idirect.net> wrote:

Hello working group,

 

At today=E2=80=99s MANET in= terim meeting, there was a call for WG adoption of draft-clausen-manet-rfc5444-usage-00.

 

Unless significant resistance is posted to the list by June 17, the document will be accepted as a WG doc (silence is assumed to be acceptance).
I might be a bit biased, but I think this draft/rfc will become very useful both for Manet protocol designers AND implementers.

+1 by me.

Henning

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




--
James Nguyen
Email: james.huy.nguyen@gmail.com


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

=20
____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-2B19B6C5-68DB-4AAB-AEF3-EA99D9BBC43D-- From nobody Fri Jun 12 07:39:56 2015 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 473431ACCF3 for ; Fri, 12 Jun 2015 07:39:55 -0700 (PDT) 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 MvK6lm3I8YNb for ; Fri, 12 Jun 2015 07:39:53 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 470D91ACCF0 for ; Fri, 12 Jun 2015 07:39:53 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.203 as permitted sender) identity=mailfrom; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,602,1427774400"; d="scan'208";a="7947747" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.203]) by ironport2.idirect.net with ESMTP; 12 Jun 2015 10:39:52 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM3.idirect.net (10.250.250.203) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 12 Jun 2015 10:39:52 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.1076.000; Fri, 12 Jun 2015 10:39:52 -0400 From: "Ratliff, Stanley" To: "manet@ietf.org" Thread-Topic: IESG Statement on Internet Draft Authorship Thread-Index: AQHQpHTsyIh8cSLL7kauXzFccmqjw52o8KuggAABnlA= Date: Fri, 12 Jun 2015 14:39:51 +0000 Message-ID: <4e8e8476f9a74a189535cfd8a82a1a61@VAUSDITCHM2.idirect.net> References: <20150611183132.19747.75036.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: [manet] FW: IESG Statement on Internet Draft Authorship 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, 12 Jun 2015 14:39:55 -0000 V0csIA0KDQpGWUkuDQoNClJlZ2FyZHMsDQpTdGFuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBCUlVOR0FSRCwgREVCT1JBSCBBIFttYWlsdG86ZGIzNTQ2QGF0dC5j b21dDQo+IFNlbnQ6IEZyaWRheSwgSnVuZSAxMiwgMjAxNSAxMDozNiBBTQ0KPiBUbzogcnRnLWNo YWlyc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBGVzogSUVTRyBTdGF0ZW1lbnQgb24gSW50ZXJuZXQg RHJhZnQgQXV0aG9yc2hpcA0KPiANCj4gTm90IGV2ZXJ5b25lIHBheXMgYXR0ZW50aW9uIHRvIHRo ZSBpZXRmLWxpc3QsIHlvdSBtYXkgd2FudCB0byBkaXN0cmlidXRlIG9uDQo+IHlvdXIgd2cgbGlz dHMtDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSUVURi1B bm5vdW5jZSBbbWFpbHRvOmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mDQo+IFRoZSBJRVNHDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDExLCAyMDE1IDI6MzIgUE0N Cj4gVG86IElFVEYgQW5ub3VuY2VtZW50IExpc3QNCj4gU3ViamVjdDogSUVTRyBTdGF0ZW1lbnQg b24gSW50ZXJuZXQgRHJhZnQgQXV0aG9yc2hpcA0KPiANCj4gVGhlIElFU0cgaGFzIHJlY2VpdmVk IHNvbWUgcmVwb3J0cyBvZiBJRVRGIHBhcnRpY2lwYW50cyBoYXZpbmcgYmVlbiBsaXN0ZWQgYXMN Cj4gZG9jdW1lbnQgYXV0aG9ycyBvbiBkcmFmdHMgd2l0aG91dCB0aGVpciBjb25zZW50ICgic3Vy cHJpc2VkIGF1dGhvcnNoaXAiKS4NCj4gSW4gc29tZSBjYXNlcywgdGhlIHN1cnByaXNlZCBhdXRo b3JzIGhhZCBuZXZlciBzZWVuIHRoZSBkcmFmdCB0aGF0IHN1cnByaXNlZA0KPiB0aGVtLiBJdCBh cHBlYXJzIHRoYXQgc29tZSBkcmFmdCBhdXRob3JzIHRoaW5rIHRoYXQgaW5jbHVkaW5nIG90aGVy DQo+IHBhcnRpY2lwYW50cyBhcyBhdXRob3JzIGlzIGEgd2F5IHRvIHNob3cgc3VwcG9ydCBmb3Ig dGhlIGNvbmNlcHRzIGluIHRoZQ0KPiBkb2N1bWVudCBhbmQgZ2FpbiBhY2NlcHRhbmNlIGZvciB0 aG9zZSBjb25jZXB0cy4gVGhpcyBtYXkgYmUgdGhvdWdodCBvZiBhcw0KPiBlc3BlY2lhbGx5IHVz ZWZ1bCBpZiB0aGUgYWRkaXRpb25hbCBhdXRob3JzIGFyZSBlc3RhYmxpc2hlZCBJRVRGIHBhcnRp Y2lwYW50cy4NCj4gDQo+IEFkZGluZyBuYW1lcyBvZiBJRVRGIHBhcnRpY2lwYW50cyB3aG8gZGlk IG5vdCBhY3R1YWxseSB3b3JrIG9uIGEgcHJvcG9zYWwNCj4gbWlnaHQgc2VlbSB0byBiZSBhIGxv dy1yaXNrIHdheSBvZiBkZW1vbnN0cmF0aW5nICJzdXBwb3J0IiwgYnV0IHRoaXMgaXMgdmVyeQ0K PiBjbGVhcmx5IG5vdCBhbiBhY2NlcHRhYmxlIHByYWN0aWNlOiBubyBvbmUgc2hvdWxkIGV2ZXIg YmUgYWRkZWQgdG8gdGhlIGxpc3Qgb2YNCj4gYXV0aG9ycyBvbiBhIGRyYWZ0IHVubGVzcyB0aGF0 IHBlcnNvbiBoYXMgY29uc2VudGVkIHRvIGl0IGFuZCBoYXMgY29udHJpYnV0ZWQNCj4gc2lnbmlm aWNhbnRseSB0byB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIGRyYWZ0Lg0KPiANCj4gVGhlIHByYWN0 aWNlIG9mIGFkZGluZyBzdXJwcmlzZWQgYXV0aG9ycyBpcw0KPiANCj4gICAtIG5vdCBpbiBsaW5l IHdpdGggdGhlIElFVEYgY3VsdHVyZSwgd2hlcmUgaXQncyB0aGUgdGVjaG5pY2FsIGlzc3Vlcw0K PiAgICAgdGhhdCBtYXR0ZXIsIG5vdCB3aG8gdGhlIGF1dGhvcnMgb3Igc3VwcG9ydGVycyBhcmU7 DQo+ICAgLSB1bmV0aGljYWwsIGFzIGl0IGlzIHdyb25nIHRvIGNsYWltIHN1cHBvcnQgZnJvbSBz b21lb25lIHdobyBoYXMgbm90DQo+ICAgICBjb25zZW50ZWQgdG8gaXQ7DQo+ICAgLSBtaXNsZWFk aW5nIGluIHRlcm1zIG9mIHN1cHBvcnQ7IGFuZA0KPiAgIC0gcHJvYmxlbWF0aWMgaW4gdGVybXMg b2YgSVBSIGRpc2Nsb3N1cmVzIChCQ1BzIDc4IGFuZCA3OSkuDQo+IA0KPiBUbyBlbXBoYXNpemUg dGhpcyBsYXN0IHBvaW50LCB0aGUgcGVyc29uIHN1Ym1pdHRpbmcgYW4gSW50ZXJuZXQtRHJhZnQg aXMNCj4gYXNzZXJ0aW5nIHRoYXQgIlRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGlu IGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUNCj4gcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJD UCA3OSIuIEEgc3VibWl0dGVyIHdobyBoYXMgbm90IGRpc2N1c3NlZCB0aGlzDQo+IHdpdGggYWxs IHRoZSBsaXN0ZWQgYXV0aG9ycyBjYW5ub3QgbWFrZSB0aGF0IGNsYWltLCBhbmQgdGhpcyBjYW4g Y2F1c2UNCj4gcHJvY2VkdXJhbCBhbmQgbGVnYWwgcHJvYmxlbXMgbGF0ZXIuDQo+IA0KPiBBbGwg YXV0aG9ycyBuZWVkIHRvIGJlIGF3YXJlIG9mIHRoZSDigItSRkMgRWRpdG9yJ3Mgc3RhdGVtZW50 IG9uIGF1dGhvcnNoaXAgWzFdLA0KPiBlc3BlY2lhbGx5IGFzIGl0IHJlbGF0ZXMgdG8gcmVzcG9u c2liaWxpdHkgZm9yIHRoZSBkb2N1bWVudCdzIGNvbnRlbnRzLiBUaGUgSUVTRw0KPiBzdHJvbmds eSByZWNvbW1lbmRzIHRoYXQgYWxsIGRyYWZ0cyBoYXZlIGV4cGxpY2l0IHBlcm1pc3Npb24gZnJv bSBhbGwgYXV0aG9ycw0KPiB0byBoYXZlIHRoZWlyIG5hbWVzIGxpc3RlZCBiZWZvcmUgdGhlIGRy YWZ0IGlzIHN1Ym1pdHRlZC4NCj4gDQo+IElmIHlvdSBmZWVsIHRoYXQgeW91IGFyZSBpbXBhY3Rl ZCBieSB0aGUgYWJvdmUgaXNzdWVzLCBwbGVhc2UgdGFsayB0byB5b3VyDQo+IEFyZWEgRGlyZWN0 b3Igb3IgY29udGFjdCB0aGUgSUVTRyBieSDigItzZW5kaW5nIGVtYWlsIHRvIDxpZXNnQGlldGYu b3JnPi4gQXMgdGhlDQo+IGFkbWluaXN0cmF0b3Igb2YgdGhlIEktRCByZXBvc2l0b3J5IChyZWdh cmRsZXNzIG9mIHRoZSBzb3VyY2Ugb3IgaW50ZW5kZWQNCj4gc3RyZWFtIGZvciB0aGUgZHJhZnQp LCB0aGUgSUVTRyB3aWxsIGhhbmRsZSBlYWNoIGNhc2Ugb2YgZGlzcHV0ZWQgYXV0aG9yc2hpcA0K PiBvbiBhIGNhc2UtYnktYmFzZSBiYXNpcy4gQWxsIHJlcG9ydHMgd2lsbCBiZSBpbnZlc3RpZ2F0 ZWQsIGFuZCBzdWJzdGFudGlhdGVkDQo+IGNsYWltcyB3aWxsIGJlIG1ldCB3aXRoIGNvcnJlY3Rp dmUgYWN0aW9ucy4NCj4gDQo+IFRoZSBkZWZhdWx0IGNvcnJlY3RpdmUgYWN0aW9uIHdpbGwgYmUg dGhlIHJlcGxhY2VtZW50IG9mIHRoZSBvZmZlbmRpbmcgZHJhZnQNCj4gd2l0aCBhICJkaXNwdXRl ZCBhdXRob3JzaGlwIiB0b21ic3RvbmUuIFN1Y2ggYSB0b21ic3RvbmUgd291bGQ6DQo+IA0KPiAg IC0gQmUgcHVibGlzaGVkIGFzIGEgc3VjY2Vzc29yIHRvIHRoZSBvZmZlbmRpbmcgZHJhZnQsDQo+ ICAgLSBIYXZlIHRoZSBvZmZlbmRlZCBJRVRGIHBhcnRpY2lwYW50IGxpc3RlZCBhcyB0aGUgb25s eSBhdXRob3IsDQo+ICAgLSBXaWxsIHN0YXRlICJUaGUgYXV0aG9yIGxpc3RlZCBvbiB0aGlzIHRv bWJzdG9uZSBJbnRlcm5ldC1EcmFmdCBoYXMNCj4gICAgIHN0YXRlZCB0aGF0IGhlL3NoZSBzaG91 bGQgbm90IGhhdmUgYmVlbiBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9uIHRoZQ0KPiAgICAgcHJldmlv dXMgdmVyc2lvbi4gVGhlIElFVEYgY29uc2lkZXJzIGJlaW5nIGFkZGVkIGFzIGFuIGF1dGhvcg0K PiAgICAgd2l0aG91dCBvbmUncyBwZXJtaXNzaW9uIGFzIHVuZXRoaWNhbC4gVGhlIGRlZmF1bHQg YmVoYXZpb3VyIG9mIHRoZQ0KPiAgICAgSUVTRyBpbiBzdWNoIGNhc2VzIGlzIHRvIGFwcHJvdmUg cmVwbGFjZW1lbnQgb2YgdGhlIG9mZmVuZGluZyBkcmFmdA0KPiAgICAgd2l0aCB0aGlzIHRvbWJz dG9uZS4gUGxlYXNlIGRpcmVjdCBhbnkgcXVlcmllcyB0byB0aGUgYXV0aG9yIGxpc3RlZA0KPiAg ICAgaGVyZS4iDQo+IA0KPiBbMV0gaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9waXBlcm1haWwv cmZjLWludGVyZXN0LzIwMTUtTWF5LzAwODg2OS5odG1sDQoNCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpUaGlzIGVsZWN0cm9uaWMgbWVzc2Fn ZSBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgY29udGFpbnMKaW5mb3JtYXRpb24g ZnJvbSBpRGlyZWN0LCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnkKYW5kL29y IGNvbmZpZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsCm9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGFy ZSBub3QgdGhlIG9yaWdpbmFsCnJlY2lwaWVudCBvciB0aGUgcGVyc29uIHJlc3BvbnNpYmxlIGZv ciBkZWxpdmVyaW5nIHRoZSBlbWFpbCB0byB0aGUKaW50ZW5kZWQgcmVjaXBpZW50LCBiZSBhZHZp c2VkIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbAppbiBlcnJvciwgYW5kIHRoYXQg YW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgZm9yd2FyZGluZywgcHJpbnRpbmcsIG9yCmNvcHlpbmcg b2YgdGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhp cyBlbWFpbAppbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgaW1tZWRpYXRlbHkgbm90aWZ5 IHRoZSBzZW5kZXIuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCg== From nobody Fri Jun 12 09:10:29 2015 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 3A6DC1A1B34 for ; Fri, 12 Jun 2015 09:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 xKlpaxfLRAqM for ; Fri, 12 Jun 2015 09:10:25 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB791A1B3D for ; Fri, 12 Jun 2015 09:10:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SfG7WTK2rx5qn62g0mgx9x4SdXSp+5JxCbzBBul3DOUC4YQzZvPOKlTD72uyuKI0; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [107.1.141.74] (helo=[192.168.255.153]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Z3RXD-0002lO-8T for manet@ietf.org; Fri, 12 Jun 2015 12:10:23 -0400 Message-ID: <557B046C.3090704@earthlink.net> Date: Fri, 12 Jun 2015 09:10:20 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "manet@ietf.org" References: <6cd5b052f8a3474099a5ef239dae5bf1@VAUSDITCHM2.idirect.net> In-Reply-To: <6cd5b052f8a3474099a5ef239dae5bf1@VAUSDITCHM2.idirect.net> Content-Type: multipart/alternative; boundary="------------040202010004010606010500" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac76a5987849f64cb2b40e826af777ca848350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: Subject: Re: [manet] Poll for consensus on WG adoption of draft-clausen-manet-rfc5444-usage-00 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, 12 Jun 2015 16:10:27 -0000 This is a multi-part message in MIME format. --------------040202010004010606010500 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello folks, There have been many disagreements about how to use RFC 5444. A document to explain what's in that RFC might be useful. But it definitely should not be used as a vehicle for inserting new mandates that were not present in RFC 5444. Regards, Charlie P. On 6/10/2015 12:52 PM, Ratliff, Stanley wrote: > > Hello working group, > > At today’s MANET interim meeting, there was a call for WG adoption of > draft-clausen-manet-rfc5444-usage-00. > > Unless significant resistance is posted to the list by June 17, the > document will be accepted as a WG doc (silence is assumed to be > acceptance). > > Regards, > Stan > > ------------------------------------------------------------------------ > > *Stan Ratliff *| Architect, Applied Research > > *VT iDirect *| 13861 Sunrise Valley Drive, Suite 300, Herndon, VA > 20171, USA > > T: +1 703 544-8520 | F: +1 222 123-4567 > > sratliff@idirect.net __| www.idirect.net > > > *Connect with iDirect: *Twitter.com/iDirect > __| Facebook.com/iDirect > ** > > ** > > ** > > *Advancing a Connected World* > > > _____________________________________________________ > This electronic message and any files transmitted with it contains > information from iDirect, which may be privileged, proprietary > and/or confidential. It is intended solely for the use of the individual > or entity to whom they are addressed. If you are not the original > recipient or the person responsible for delivering the email to the > intended recipient, be advised that you have received this email > in error, and that any use, dissemination, forwarding, printing, or > copying of this email is strictly prohibited. If you received this email > in error, please delete it and immediately notify the sender. > _____________________________________________________ > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --------------040202010004010606010500 Content-Type: multipart/related; boundary="------------010201010404050907090705" --------------010201010404050907090705 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hello folks,

There have been many disagreements about how to use RFC 5444.  A document to explain
what's in that RFC might be useful.

But it definitely should not be used as a vehicle for inserting new mandates that were not
present in RFC 5444.

Regards,
Charlie P.


On 6/10/2015 12:52 PM, Ratliff, Stanley wrote:

Hello working group,

 

At today’s MANET interim meeting, there was a call for WG adoption of draft-clausen-manet-rfc5444-usage-00.

 

Unless significant resistance is posted to the list by June 17, the document will be accepted as a WG doc (silence is assumed to be acceptance).

 

Regards,
Stan

Stan Ratliff  |  Architect, Applied Research

VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, USA

T: +1 703 544-8520  |  F: +1 222 123-4567

sratliff@idirect.net  |  www.idirect.net

Connect with iDirect: Twitter.com/iDirect  |  Facebook.com/iDirect

 

Advancing a Connected World

 

 


_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________ 

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

--------------010201010404050907090705 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYH BwcGBwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcI DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAAR CAAaAIMDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8AgpJ+2j8YvgF8cfCug+CfD76X4daa G4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeIP24PijYfEbQNH1G2tte0PS4p 4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/EJfBfytqDeJl0NNNjUMD lhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmvAoYf69zSqN8rafK1 a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4k+FP2vtD0D4e +ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbySKryRMQTG SASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtjLhz9 7zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh 0G98M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C 9LOoSTxa99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl +EWQBrSRmPAwIpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBG f+Wdewfma2Fu/wDgr18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+A HxE8SfFH4ZafrPirwfdeA9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9 R/1B7/8Az+NfoeIEH8PU559aTA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNd AyRiJTGNio/3m+9jtmvl3wB/wWR8f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVV jhQfun61uf8ABOP4s+K/G37dn7Qmja34m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBw BXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfD ss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q/C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhV fzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2khie2kW1vyjxsuCrLtQgg5BANUNf /aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37ygwvyk44pcoH6sfak3Yz3x+NAu VLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeHYPsUszQ2oJKhnPlqX2qW xk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk3rHGDtYbmXAyORzT 5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALMyqB1LEAAkgH4 A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn9595Rhav8A 7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRygfeX w+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP 7Dluls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3 D+WLq4lXVJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E /ma8jFYC0nOlNxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi 9rn7Zfh/XPh54wutJ8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SST zGCgFyAGYgYycADnrwBVe3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8 kWopSavvJ7yfT9NXf56/4KB/sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lN u3ceXjBzx2H7HP7MVv8Ask/s9aH4Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVa K7eZnzZ83+I/2CLrxB/wUK0L46DxZDbwaLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4K RGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7u e9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq 5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6tJNNPAYRIYlKqFRTxGCMgfe5NeZ6r /wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ1MhGB0zX2lRSuB4P+0V+wnpH 7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcqDXGfCL/gnN4h0z45+G/H 3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4Hx/49/4Je65F8WPH fiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4JteHdO/Yd1T4JW+ vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gLSvDHh/8A aI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --------------010201010404050907090705-- --------------040202010004010606010500-- From nobody Fri Jun 12 09:24:45 2015 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 B1B261A87B3 for ; Fri, 12 Jun 2015 09:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622] 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 zx3FXc3H6Jm3 for ; Fri, 12 Jun 2015 09:24:43 -0700 (PDT) Received: from mail-vn0-x22d.google.com (mail-vn0-x22d.google.com [IPv6:2607:f8b0:400c:c0f::22d]) (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 08D3E1A8730 for ; Fri, 12 Jun 2015 09:24:43 -0700 (PDT) Received: by vnbg129 with SMTP id g129so6816609vnb.9 for ; Fri, 12 Jun 2015 09:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1FqhigG20ihKD2ciKVErHirMt9eILBOM0gTB3v4t97A=; b=bQcOU57SviVvSofPBsFYegwf1arbrRSbs/DGtdSLQn+InkxTsS74WQN3b3MAZ4uhNV EOOLzM+2Hr95TuxBraS8eoZVpE8sxnWB3OJahE0RSzOYSZ+M/msHo/SqXAzwG65vWq1P 838bbLeP98FW9pv25pXKkax6rRg4Mp4MZ/NlY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1FqhigG20ihKD2ciKVErHirMt9eILBOM0gTB3v4t97A=; b=HEikZzLzfbBDS+Ixc4X00WdXDJcSFje+dJY8RTUd1ut0jqxoZz0XOvdaaGI0BCtSQ9 Xsf+jFiJ/VZvOXpF8PkRonZlJ/pf1z+wWchbYKnCmpmBToQ/OHWSDy5k5O5MVSSE5Xr2 bIdt3OZ0kWn+Kq9OA8gcjbPqplvUgtlLx6/og7tR9+tOQtHFj0uRzsO4X7/pDcnEASxY KLtR+qIcJxdwO7RgRYdEUY2xjk1IiCDky8y4kG2ZZGyirMRWtN8+gIo4Kh4QBQD2S1gQ 2akBapMX2LffGf5eVYRapnabCuVGfxeaYjyZj/ogJJLvX9pELKPuXfrKo7AjX4HvEsgT GLZg== X-Gm-Message-State: ALoCoQldwRV31AuCp3SoVIfpIlVk7g+WUV87UooYlI8gKJO1DojWyXaaNyU8VutoWifzuseKXScj MIME-Version: 1.0 X-Received: by 10.52.190.131 with SMTP id gq3mr5548738vdc.70.1434126282081; Fri, 12 Jun 2015 09:24:42 -0700 (PDT) Received: by 10.31.97.3 with HTTP; Fri, 12 Jun 2015 09:24:42 -0700 (PDT) In-Reply-To: References: <6cd5b052f8a3474099a5ef239dae5bf1@VAUSDITCHM2.idirect.net> <557AE1F0.9010106@gmail.com> Date: Fri, 12 Jun 2015 09:24:42 -0700 Message-ID: From: Ulrich Herberg To: Christopher Dearlove Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Poll for consensus on WG adoption of draft-clausen-manet-rfc5444-usage-00 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, 12 Jun 2015 16:24:44 -0000 Same here, I am in favor of adoption (not un-biased, but still) Regards Ulrich On Fri, Jun 12, 2015 at 7:12 AM, Christopher Dearlove wrote: > It probably doesn't need me to say I'm in favour of adoption, but for the > record I am. > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 12 Jun 2015, at 14:43, John Dowdell wrot= e: > > +1 from me too. I am looking forwards to reading the definitive guidance. > > John > > On 10/06/15 21:38, James Nguyen wrote: > > +1 > > I've been looking for this for a long time. > > James > > On Wed, Jun 10, 2015 at 4:03 PM, Henning Rogge wrote: >> >> On Wed, Jun 10, 2015 at 9:52 PM, Ratliff, Stanley >> wrote: >>> >>> Hello working group, >>> >>> >>> >>> At today=E2=80=99s MANET interim meeting, there was a call for WG adopt= ion of >>> draft-clausen-manet-rfc5444-usage-00. >>> >>> >>> >>> Unless significant resistance is posted to the list by June 17, the >>> document will be accepted as a WG doc (silence is assumed to be accepta= nce). >> >> >> I might be a bit biased, but I think this draft/rfc will become very >> useful both for Manet protocol designers AND implementers. >> >> +1 by me. >> >> Henning >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > > -- > James Nguyen > Email: james.huy.nguyen@gmail.com > > > _______________________________________________ > 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 > From nobody Mon Jun 15 00:28:37 2015 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 4FB2D1B2B3E for ; Mon, 15 Jun 2015 00:28:36 -0700 (PDT) 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 VtDdi0ELcBWp for ; Mon, 15 Jun 2015 00:28:35 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 AA1CA1A89FE for ; Mon, 15 Jun 2015 00:28:34 -0700 (PDT) Received: by wigg3 with SMTP id g3so67611002wig.1 for ; Mon, 15 Jun 2015 00:28:33 -0700 (PDT) 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=pLpY5DGsdPBk+wI1/0qddpePeBVr8wjRZMU9eAyNWsc=; b=pyNS+Wo8t+tXJKm6T013uqysRzQdm1rur73TenHCfr8QKaeMjyv4OlzMXmLqGLDw1I 3bIZ46V+jb9GxLYQKHITAbXteiTNib7lmDzAgOATjZ9g8Rli0evzl4qmSPzY6DW/2hr1 GiwFMk4L/8WKRtIOJDlPNuVQHG2uOOEMZ4+M25eeflgDjKSGLelvYiqKzmtrWjB4QxkI deBxpJrMflqGow5i1WqVFfWfwurRprOUd/RUkYiCgFABaj5IGRjR/yM4j1L4vp/dxqS2 3dSA5wOxnfITpTyPudGlyuuB6o2HUFOKfUpJthd5ZpW6UxSF/bdbtCaG8VhhDR6+Jz+C 98DA== X-Received: by 10.180.98.103 with SMTP id eh7mr28827875wib.75.1434353313444; Mon, 15 Jun 2015 00:28:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Mon, 15 Jun 2015 00:28:12 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C26FCA9@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016C26FCA9@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 15 Jun 2015 09:28:12 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: manet IETF Subject: Re: [manet] DLEP sample router 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: Mon, 15 Jun 2015 07:28:36 -0000 Hello everyone, after a few fixes on both sides my dlep_radio implementation is now exchanging data with Ricks dlep_router. Henning On Wed, Jun 10, 2015 at 5:45 PM, Rick Taylor wrote: > All, > > For those who are interested, I have just pushed an updated version of > my dlep_router with draft-14 support. > > Its at: https://github.com/ricktaylor/dlep_router > > It definitely needs some testing, and any feedback gratefully received. > > Rick Taylor > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Mon Jun 15 03:36:44 2015 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 DC6CA1B3583 for ; Mon, 15 Jun 2015 03:36:43 -0700 (PDT) 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 XzzgpH0FG54b for ; Mon, 15 Jun 2015 03:36:42 -0700 (PDT) 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 4562E1B3580 for ; Mon, 15 Jun 2015 03:36:42 -0700 (PDT) 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; Mon, 15 Jun 2015 11:36:16 +0100 From: Rick Taylor To: Henning Rogge Thread-Topic: [manet] DLEP sample router Thread-Index: AQHQpzziqT/B1BodVEyjerfe2tVIVQ== Date: Mon, 15 Jun 2015 10:36:15 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2976CD@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016C26FCA9@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: Cc: manet IETF Subject: Re: [manet] DLEP sample router 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: Mon, 15 Jun 2015 10:36:44 -0000 For those who are interested...=0A= =0A= I have updated dlep_router with some of the fixes from Henning. I =0A= suggest a pull from github.=0A= =0A= Great to here we have some basic interop happening with DLEP-14!=0A= =0A= Cheers,=0A= =0A= Rick=0A= =0A= =0A= On 15/06/15 08:28, Henning Rogge wrote:=0A= > Hello everyone,=0A= >=0A= > after a few fixes on both sides my dlep_radio implementation is now=0A= > exchanging data with Ricks dlep_router.=0A= >=0A= > Henning=0A= >=0A= > On Wed, Jun 10, 2015 at 5:45 PM, Rick Taylor=0A= > wrote:=0A= >> All,=0A= >>=0A= >> For those who are interested, I have just pushed an updated version of= =0A= >> my dlep_router with draft-14 support.=0A= >>=0A= >> Its at: https://github.com/ricktaylor/dlep_router=0A= >>=0A= >> It definitely needs some testing, and any feedback gratefully received.= =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 Mon Jun 15 04:15:54 2015 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 E824A1ACD77; Mon, 15 Jun 2015 04:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] 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 do77uGRDagU6; Mon, 15 Jun 2015 04:15:50 -0700 (PDT) Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F631AC3F9; Mon, 15 Jun 2015 04:15:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,618,1427756400"; d="scan'208";a="68035" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta2.baesystems.com with ESMTP; 15 Jun 2015 12:15:47 +0100 X-IronPort-AV: E=Sophos;i="5.13,618,1427756400"; d="scan'208";a="101517290" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 15 Jun 2015 12:15:46 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.56]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0224.002; Mon, 15 Jun 2015 12:15:46 +0100 From: "Dearlove, Christopher (UK)" To: Lou Berger , "manet-chairs@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojiIwK+stmbvhUWtFDx9P52N9Z2tc6hQ Date: Mon, 15 Jun 2015 11:15:45 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> In-Reply-To: <5575E8A7.6030508@labn.net> 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: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , "manet@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 15 Jun 2015 11:15:54 -0000 SSBoYXZlbid0IHNlZW4gYW55IGRpc2N1c3Npb24gb2YgdGhpcy4gSXQgbG9va3MgdG8gbWUgbGlr ZSByZXF1aXJpbmcgYW5vdGhlciBkcmFmdCBmb3IgdGhlIFdHIHRvIHNlZS4gSXQgZG9lcyAoYnkg bXkgcmFwaWQgY291bnQpIGhhdmUgMTcgbWFqb3IgaXNzdWVzLg0KDQotLSANCkNocmlzdG9waGVy IERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogwqArNDQgKDApMTI0NSAyNDIx OTQgwqB8IMKgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMg QXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBC YWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWkN CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4g RW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBS ZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBMb3UgQmVyZ2VyDQpTZW50OiAwOCBKdW5lIDIwMTUgMjA6MTENClRv OiBtYW5ldC1jaGFpcnNAaWV0Zi5vcmcNCkNjOiBtYW5ldC1hZHNAaWV0Zi5vcmc7IHJ0Zy1kaXJA aWV0Zi5vcmc7IG1hbmV0QGlldGYub3JnOyBkcmFmdC1pZXRmLW1hbmV0LWRsZXAuYWxsQGlldGYu b3JnDQpTdWJqZWN0OiBbbWFuZXRdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbWFuZXQtZGxl cC0xNA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNh dGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5l dC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxp bmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBT dXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24g cmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpbTm90ZSB0aGlzIGlzIGEg V0cgTEMgcmVsYXRlZCByZXZpZXcsIG5vdCBJRVRGIExDLl0NCg0KSGVsbG8sDQoNCkkgaGF2ZSBi ZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlz IGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRp bmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxh c3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0 IC0tIG9yIFdHIExhc3QgY2FsbCBhcyB3YXMgdGhlIGNhc2UgaGVyZSAuIFRoZSBwdXJwb3NlIG9m IHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4g Rm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFz ZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0 Z0Rpcg0KDQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNl IG9mIHRoZSAoY2hhaXJzIGFuZCkgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYg eW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgTGFzdCBDYWxsIGNv bW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91 Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQoNCkRvY3VtZW50OiBkcmFm dC1pZXRmLW1hbmV0LWRsZXAtMTQNClJldmlld2VyOiBMb3UgQmVyZ2VyDQpSZXZpZXcgRGF0ZTog SnVuZSA4IChsYXRlciB0aGFuIHJlcXVlc3RlZCBkdWUgdG8gc2NvcGUgb2YgY29tbWVudHMgLS0g c29ycnkpIFdHIExDIEVuZCBEYXRlOiB1bmtub3duIEludGVuZGVkIFN0YXR1czogU3RhbmRhcmRz IHRyYWNrDQoNClN1bW1hcnk6DQoNCiAgICBXaGlsZSBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyBw cmV0dHkgZGVjZW50IGZvciB0aGUgc2NvcGUgb2YgdGhlDQogICAgd29yaywgSSBkbyBoYXZlIGNv bmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgYW5kIHJlY29tbWVuZCB0aGF0IHRoZQ0KICAgIFdH IENoYWlycy9Sb3V0aW5nIEFEcyBkaXNjdXNzIHRoZXNlIGlzc3VlcyBmdXJ0aGVyIHdpdGggdGhl IGF1dGhvcnMuDQogICAgSSdtIGFsc28gYXZhaWxhYmxlIGFzL2lmIG5lZWRlZCB0byBkaXNjdXNz Lg0KDQpDb21tZW50czoNCg0KICAgIEkgdGhpbmsgdGhlIGRvY3VtZW50IHNob3dzIHNpZ25pZmlj YW50IGdvb2Qgd29yayBhbmQgbG9va3MgdG8gYmUgYQ0KICAgIHVzZWZ1bCBwcm90b2NvbCwgYWx0 aG91Z2ggSSdtIG5vdCBvdmVybHkgZmFtaWxpYXIgaW4gdGhpcyBzcGFjZS4NCiAgICBUaGF0IHNh aWQsIEkgaGF2ZSBhIG51bWJlciBvZiBzZXJpb3VzIGNvbmNlcm5zIGFib3V0IHRoZSBkb2N1bWVu dCwNCiAgICBhbmQgaXRzIGNvbnRlbnRzIGZyb20gYSBmZXcgb2YgcGVyc3BlY3RpdmVzLiAgVGhl c2UgaW5jbHVkZSBiYXNpYw0KICAgIHByb3RvY29sIGlzc3VlcywgdW5kZXJzcGVjaWZpZWQgZGV0 YWlscyAgKHdoaWNoIGNvdWxkIGxlYWQgdG8NCiAgICBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcyks IGFuZCBzcGVjaWZpY2F0aW9uL2VkaXRvcmlhbCBpc3N1ZXMuIEkNCiAgICB0aGluayB0aGUgZG9j dW1lbnQgLyBwcm90b2NvbCBjYW4gYmUgbW9kaWZpZWQgdG8gYWRkcmVzcyB0aGUgaXNzdWVzDQog ICAgSSByYWlzZSBiZWxvdy4gIE9mIGNvdXJzZSwgaXQgaXMgdXAgdG8gdGhlIFdHLCBjaGFpcnMs IGFuZCBBRHMgdG8NCiAgICBkZWNpZGUgd2hpY2ggY29tbWVudHMgdG8gYWRkcmVzcyBhbmQgd2hp Y2ggdG8gIGlnbm9yZS4gDQogICAgSSBkb24ndCBleHBlY3QgdGhhdCBhbGwgY29tbWVudHMgd2ls bCByZXN1bHQgaW4gY2hhbmdlcy4NCg0KTWFqb3IgSXNzdWVzOg0KDQogICAgLSBUaGUgbGVuZ3Ro IGZpZWxkIG9mIHRoZSBnZW5lcmljIGRhdGEgaXRlbSAoaS5lLiwgVExWKSBpcyBvbmx5IDgNCiAg ICAgIGJpdHMuICBXaGlsZSAyNTUgYnl0ZXMgKGFzc3VtaW5nIHRoYXQgdGhpcyBpcyB0aGUgdW5p dCBvZiBtZWFzdXJlLA0KICAgICAgd2hpY2ggQlRXIGlzbid0IHNwZWNpZmllZCkgaXMgYmlnIGVu b3VnaCB0b2RheSwgYWxsb3dpbmcgZm9yDQogICAgICBsYXJnZXIgd2lsbCBncmVhdGx5IHNpbXBs aWZ5IHRoaW5ncyB3aGVuIDI1NSBpc24ndCBlbm91Z2guIC0tDQogICAgICBXZSd2ZSBydW4gaW50 byB0aGlzIGluIFJTVlAgYW5kIGl0J3MgYSByZWFsIHBhaW4uDQoNCiAgICAtIFZlcnNpb24gbnVt YmVyIGlzIGN1cnJlbnRseSBkZWZpbmVkIGFzIGEgZGF0YSBpdGVtLiAgVGhpcyBtZWFucyBhDQog ICAgICBzaWduYWwgKGkuZS4sIG1lc3NhZ2UpIG5lZWRzIHRvIGJlIHBvdGVudGlhbGx5IGZ1bGx5 IHBhcnNlZCB0bw0KICAgICAgZGlzY292ZXIgd2hhdCB2ZXJzaW9uIGlzIGJlaW5nIHVzZWQuICBU aGlzIHByZWNsdWRlcyBiYXNpYyBmb3JtYXQNCiAgICAgIGNoYW5nZXMgdG8gdGhlIHByb3RvY29s LiAgUGVyaGFwcyB0aGUgRGlzY292ZXJ5IGFuZCBJbml0IFNpZ25hbHMNCiAgICAgIHNob3VsZCBi ZSBzcGVjaWFsIGNhc2VkIHRvIGluY2x1ZGUgdmVyc2lvbiBpbiB0aGVpciBmb3JtYXRzLiAgKEFu ZA0KICAgICAgc2hvcnRlbiB2ZXJzaW9uIHRvIDggYml0cyBmcm9tIDMyLCBhcyBtZW50aW9uZWQg YmVsb3cpLg0KDQogICAgLSBUaGUgZG9jdW1lbnQgcmVmZXJlbmNlcywgYnV0IGRvZXMgbm90IGRl ZmluZSwgJ2luLXNlc3Npb24nIGFuZA0KICAgICAgJ2Rpc2NvdmVyeScgc3RhdGVzLiAgVGhlc2Ug ZWl0aGVyIG5lZWQgdG8gYmUgZm9ybWFsbHkgZGVmaW5lZCBvcg0KICAgICAgcmVtb3ZlZC4gIEJU VyB3ZSBoYWQgZXhhY3RseSB0aGUgc2FtZSBpc3N1ZSB3aXRoIExNUCAoUkZDNDIwNCkgYW5kDQog ICAgICBlbmRlZCB1cCBhZGRpbmcgc2VjdGlvbiAxMSAoRlNNcykgYXQgYSBwcmV0dHkgbGF0ZSBz dGFnZSBvZiB0aGUNCiAgICAgIHByb2Nlc3MuDQoNCiAgICAtIFRDUCBzZXNzaW9uIG1hbmFnZW1l bnQgaXMgbm90IGRlZmluZWQsIG5vciBpcyB0aGUgcmVsYXRpb25zaGlwDQogICAgICB3aXRoIFRD UCBhbmQgRExFUCBzZXNzaW9ucyBmdWxseSBkZWZpbmVkLiAgRm9yIGV4YW1wbGU6DQoNCiAgICAg IG8gQ2xvc2luZyB0aGUgVENQIHNlc3Npb24gaXMgb25seSBtZW50aW9uZWQgaW4gb25lIHBsYWNl IGFuZCBpbiBhDQogICAgICAgIHdheSB0aGF0IGlzIGluY29uc2lzdGVudCB3aXRoIHRoZSBleHBl Y3RlZCBwcm90b2NvbCBiZWhhdmlvcg0KICAgICAgICAoY2xvc2UgVENQIGJlZm9yZSBBQ0sgaXMg cmVjZWl2ZWQpLg0KDQogICAgICBvIFdoYXQgaGFwcGVucyB3aGVuIGEgRExFUCBzZXNzaW9uIGlz IHRlcm1pbmF0ZWQsIGNhbiB0aGUgVENQDQogICAgICAgIHNlc3Npb24gYmUgcmV1c2VkIG9yIG11 c3QgaXQgYmUgY2xvc2VkIHRvbz8NCg0KICAgIC0gVGhlcmUgaXMgbm8gdHJhbnNhY3Rpb24gbW9k ZWwgZGVmaW5lZC4gIEZvciBleGFtcGxlLCBpdCdzDQogICAgICBjb21wbGV0ZWx5IHVuY2xlYXIg aWYgb25seSBvbmUgdW5hY2tub3dsZWRnZWQgU2lnbmFsIGFsbG93ZWQgYXQgYQ0KICAgICAgdGlt ZSwgb3IgcGVyaGFwcyBqdXN0IG9uZSBwZXIgc2lnbmFsIHR5cGUgaXMgYWxsb3dlZCwgb3IgcGVy aGFwcw0KICAgICAgdGhlcmUgYXJlIG5vIHJlc3RyaWN0aW9ucy4gIFRoaXMgbmVlZHMgdG8gYmUg ZXhwbGljaXQuICANCg0KICAgIC0gV2hhdCBpcyB0aGUgcHVycG9zZSBvZiByZXRyaWVzIGFuZCB0 aW1lb3V0cyBvdmVyIFRDUD8gIFJldHJpZXMNCiAgICAgIGFyZW4ndCBuZWVkZWQgb3ZlciBUQ1Bz IGFuZCBpdCdzIHVuY2xlYXIgd2hleSB0aGV5IGFyZSBiZWluZyB1c2VkLg0KDQogICAgLSBUaGUg aGlnaGVyIGxldmVsIGltcGxpY2F0aW9ucyBvZiBBQ0tzLCBvdmVyIFRDUCwgaXNuJ3QgcmVhbGx5 DQogICAgICBjbGVhci4gIEl0IHNlZW1zIEFDS3MgYXJlIGRlZmluZWQgZm9yIG11bHRpcGxlIHB1 cnBvc2VzOiByZWxpYWJsZQ0KICAgICAgdHJhbnNwb3J0LCB0cmFuc2FjdGlvbiBhY2tub3dsZWRn bWVudCBhbmQgdHJhbnNhY3Rpb24gcmVzdWx0cy4gT2YNCiAgICAgIGNvdXJzZSB0aGUgZmlyc3Qg aXNuJ3QgbmVlZGVkLCBhbmQgaW1wbGljYXRpb25zIG9mIHRoZSBvdGhlcnMNCiAgICAgIHNob3Vs ZCBiZSBjbGVhci4gIEZvciBleGFtcGxlLCBpbiBzZWN0aW9uIDcuMTAsIHdoeSB3b3VsZCB0aGVy ZSBiZQ0KICAgICAgYSByZXRyeSB3aGVuIHJlY2VpdmluZyBhIERlc3RpbmF0aW9uIFVwIEFDSyBz aWduYWwgaW5kaWNhdGluZyBhbg0KICAgICAgZXJyb3I/DQoNCiAgICAtIFRoZXJlIGlzIG5vIGRp c2N1c3Npb24gb24gc2NhbGluZyBjb25zaWRlcmF0aW9ucy4gQXJlIHRoZXJlIHJlYWxseQ0KICAg ICAgbm9uZT8gIEZvciBleGFtcGxlLCBob3cgb2Z0ZW4gbWlnaHQgYmUgYXBwcm9wcmlhdGUgdG8g aXNzdWUvbGltaXQNCiAgICAgIFBlZXIgVXBkYXRlcyBiYXNlZCB0byBjaGFuZ2VzIGluIGxpbmsg cXVhbGl0eSwgb3IgaG93IHRvIGhhbmRsZQ0KICAgICAgdGhlIGNhc2Ugd2hlcmUgYSBsYXJnZSBu dW1iZXIgKGFsbCBvciBtb3N0KSBvZiBkZXN0aW5hdGlvbnMgZ28NCiAgICAgIGRvd24uDQoNCiAg ICAtIFRoZXJlIGFyZSAxMyBwbGFjZXMgd2hlcmUgdGhlIHByb3RvY29sIGFsbG93cyBpbXBsZW1l bnRhdGlvbiB0bw0KICAgICAgZGVmaW5lIHRoZWlyIG93biAnaGV1cmlzdGljcycuICBTb21lIG9m IHRoZXNlIHNlZW0gdW5uZWNlc3NhcnkgZHVlDQogICAgICB0byB0aGUgVENQIHBvaW50IHJhaXNl ZCBhYm92ZSwgYnV0IGFueSB0aGF0IHJlbWFpbiBpbiB0aGUgcHJvdG9jb2wNCiAgICAgIHNob3Vs ZCBiZSBmdWxseSBzcGVjaWZpZWQgdG8gZW5zdXJlIHByZWRpY3RhYmxlL2NvbnNpc3RlbnQNCiAg ICAgIGJlaGF2aW9yIGZyb20gaW1wbGVtZW50YXRpb25zLg0KDQogICAgLSBEYXRhIEl0ZW1zIGFy ZSBkZWZpbmVkIGZvciAiRXh0ZW5zaW9ucyIgYW5kICJFeHBlcmltZW50YWwNCiAgICAgIERlZmlu aXRpb24iIChTZWN0aW9ucyA4LjcgYW5kIDguOCkuICBCb3RoIHNlZW0gdG8gc3VwcG9ydCBmb3IN CiAgICAgIG9wdGlvbmFsIG1lY2hhbmlzbXMsIGJ1dCB0aGUgZm9ybWVyIHVzZXMgYXNzaWduZWQg bnVtZXJpYyB2YWx1ZXMsDQogICAgICB3aHkgdGhlIGxhdHRlciB1c2VzIFVURi04IHN0cmluZ3Mu DQogICAgICBvIFdoYXQsIGlmIGFueSwgaXMgdGhlIGludGVuZGVkIGRpc3RpbmN0aW9uL3JlbGF0 aW9uc2hpcCBiZXR3ZWVuDQogICAgICAgIHRoZXNlPw0KICAgICAgbyBIb3cgZG9lcyBhbiAiRXhw ZXJpbWVudGFsIERlZmluaXRpb24iIGJlY29tZSBzdGFuZGFyZGl6ZWQ/DQoNCiAgICAtIFNlY3Rp b25zIDguMTkgYW5kIDguMjAgZGVmaW5lICJSZXNvdXJjZXMiIHJlbGF0ZWQgRGF0YSBJdGVtcy4g IFRoZQ0KICAgICAgZGVmaW5pdGlvbiByZWxhdGVkIHRvIHRoZXNlIGJhc2ljYWxseSBzYXlzIGEg cmVzb3VyY2VzIGlzICJBbg0KICAgICAgOC1iaXQgaW50ZWdlciBwZXJjZW50YWdlLCAwLTEwMCwg cmVwcmVzZW50aW5nIHRoZSBhbW91bnQgb2YNCiAgICAgIHJlc291cmNlcyBhbGxvY2F0ZWQgdG8g cmVjZWl2aW5nfHRyYW5zbWl0dGluZyBkYXRhLiIuICBJZiBJIHdlcmUNCiAgICAgIGltcGxlbWVu dGluZyB0aGlzIHByb3RvY29sLCBJJ2QgaGF2ZSBubyBpZGVhIGhvdyB0byBwcm9kdWNlLA0KICAg ICAgdXBkYXRlIG9yIHVzZSB0aGlzIGluZm9ybWF0aW9uLiAgSSB0aGluayB0aGVyZSBpcyBzb21l IG1pc3NpbmcNCiAgICAgIGluZm9ybWF0aXZlIGFuZCBub3JtYXRpdmUgKFJGQyAyMTE5KSB0ZXh0 IHJlbGF0ZWQgdG8gdGhlc2UNCiAgICAgIGZvcm1hdHMuDQoNCiAgICAtIFNlY3Rpb25zIDguMjEg YW5kIDguMjIgKFJlbGF0aXZlIExpbmsgUXVhbGl0eSkgaGF2ZSBhIHNpbWlsYXINCiAgICAgIHBy b2JsZW0gb2YgYmVpbmcgdW5kZXIgZGVzY3JpYmVkLCBpbiBwYXJ0aWN1bGFyIGl0J3MgdW5jbGVh ciBpZg0KICAgICAgdGhlcmUncyBhIG1lYW5pbmdmdWwsIG5vbi1wcm9wcmlldGFyeSBkZWZpbml0 aW9uIGZvciBsaW5rIHF1YWxpdHkNCiAgICAgIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gaXMgdG8g YWN0IG9uIG9yIGlmIHRoZSBwYXNzZWQgdmFsdWUgaXMganVzdA0KICAgICAgcGFzc2VkIGZvciBh cyBtb25pdG9yaW5nIGluZm9ybWF0aW9uLiAgRWl0aGVyIHdheSwgdGhpcyBuZWVkcyB0bw0KICAg ICAgYmUgY2xhcmlmaWVkLg0KDQogICAgLSBTZWN0aW9uIDkgZGVmaW5lcyBhICJjcmVkaXQtd2lu ZG93aW5nIHNjaGVtZSBhbmFsb2dvdXMgdG8gdGhlIG9uZQ0KICAgICAgZG9jdW1lbnRlZCBpbiBb UkZDNTU3OF0iLiBJdCBkZXNjcmliZXMgaG93IGNyZWRpdHMgYXJlIGV4Y2hhbmdlZCwNCiAgICAg IGJ1dCBpdCBwcm92aWRlcyB6ZXJvIGRlZmluaXRpb24gb24gdGhlIGltcGxpY2F0aW9ucyBvciB1 c2Ugb2YNCiAgICAgIGNyZWRpdHMgcmVsYXRpdmUgdG8gdGhlIGRhdGEgcGxhbmUuICAgDQoNCiAg ICAtIE11bHRpcGxlIHdheXMgdG8gaW1wbGVtZW50IHRoZSBzYW1lIGZ1bmN0aW9uIGFyZSBhbGxv d2VkLCBlLmcuLA0KICAgICAgb3B0aW9uYWwgcHJlc2VuY2Ugb2YgU3RhdHVzLCBJbnRlcnZhbCBh bmQgVENQIHBvcnQuICBHZW5lcmFsbHkNCiAgICAgIGFsbG93aW5nIHN1Y2ggY29tcGxpY2F0ZXMg dGVzdGluZyBhbmQgbGVhZHMgdG8gaW50ZXJvcGVyYWJpbGl0eQ0KICAgICAgaXNzdWVzLiAgVGhl IGRvY3VtZW50IHNob3VsZCBwaWNrIG9uZSB3YXkgYW5kIHJlcXVpcmUgaXQuDQoNCiAgICAtIFRo ZSBkb2N1bWVudCBkb2Vzbid0IHN0YXRlIGlmIHRoZXJlIGFyZSBhbnkgb3JkZXJpbmcgcmVxdWly ZW1lbnRzDQogICAgICBvbiBkYXRhIGl0ZW1zLiBJdCBzaG91bGQgYmUgZXhwbGljaXQgb24gdGhp cywgZS5nLiwgdGhlcmUgYXJlIG5vDQogICAgICBvcmRlcmluZyByZXF1aXJlbWVudHMgb24gdGhl IHBsYWNlbWVudCBvZiBEYXRhIEl0ZW1zIHdpdGhpbg0KICAgICAgU2lnbmFscy4NCg0KICAgIC0g VGhlIHJlcXVpcmVkIGFuZCBvcHRpb25hbCBkYXRhIGl0ZW1zIHRoYXQgYXJlIHBlcm1pdHRlZCBv biBhDQogICAgICBzaWduYWwgaXNuJ3QgYWx3YXlzIGNsZWFyLiAgRm9yIGV4YW1wbGUgYXJlIDAv MS9OIGNvcGllcyBvZiBhDQogICAgICBwYXJ0aWN1bGFyIERhdGEgSXRlbSByZXF1aXJlZC9hbGxv d2VkLiAgVXNpbmcgc29tZXRoaW5nIGxpa2UgQUJORg0KICAgICAgd291bGQgcmVhbGx5IGhlbHAg Zm9ybWFsaXplIGFuZCBjbGFyaWZ5IHRoaXMuDQoNCiAgICAtIFRoZSBkb2N1bWVudCBkb2Vzbid0 IGNsZWFybHkgZGVsaW5lYXRlIGZyb20gaW5mb3JtYXRpdmUvbmFycmF0aXZlDQogICAgICB0ZXh0 LCBub3JtYXRpdmUgLyByZXF1aXJlZCBwcm9jZXNzaW5nIHByb2NlZHVyZXMsIGFuZCBtZXNzYWdl DQogICAgICBmb3JtYXRzLiBUaGlzIGJ5IGl0c2VsZiBpcyBub3QgbmVjZXNzYXJpbHkgYSBtYWpv ciBpc3N1ZSwgaXQganVzdA0KICAgICAgbWFrZXMgaXQgaGFyZGVyIHRvICh3cml0ZSwpIHJldmll dyBhbmQgaW1wbGVtZW50IHRoZSBwcm90b2NvbC4NCiAgICAgIFdoYXQgaXMgYSBtYWpvciBpc3N1 ZSBpcyB0aGF0IHRoaXMgYXBwcm9hY2ggYWxsb3dzIGZvciBkdXBsaWNhdGUNCiAgICAgIChhbmQg c29tZXRpbWVzIGNvbnRyYWRpY3RvcnkpIG5vcm1hdGl2ZSBwcm9jZWR1cmVzIGFuZCBmb3INCiAg ICAgIG9taXNzaW9ucyBpbiBwcm9jZWR1cmVzIChwYXJ0aWN1bGFybHkgcmVsYXRlZCB0byBleGNl cHRpb24vZXJyb3INCiAgICAgIHByb2Nlc3NpbmcpLiAgU3BlY2lmaWMgZXhhbXBsZXMgYXJlIGlu Y2x1ZGVkIGFib3ZlIGFuZCBiZWxvdy4gIEl0DQogICAgICB3b3VsZCBiZSBiZXN0IHRvIGVuc3Vy ZSB0aGF0IGVhY2ggcmVxdWlyZWQgcHJvY2Vzc2luZyBiZWhhdmlvciBpcw0KICAgICAgZGVmaW5l ZCBqdXN0IG9uY2UgYW5kIGluIGEgY29uc2lzdGVudCB3YXkuDQoNCiAgICAtIFRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24gaXMgaW5hZGVxdWF0ZS4gIFRoaXMgc2VjdGlvbg0KICAg ICAgc2hvdWxkIGFkZHJlc3MgdGhlIHNlY3VyaXR5IG9mIHRoZSBETEVQIHByb3RvY29sLCBub3Qg dXNlcg0KICAgICAgdHJhZmZpYy4gIEl0IHNob3VsZCBpbmNsdWRlIGFuIGFuYWx5c2lzIG9mIHJp c2tzL3RocmVhdHMvcG9zc2libGUNCiAgICAgIGV4cGxvaXRzIGFuZCBob3cgdGhlc2UgYXJlIG1p dGlnYXRlZCBieSB0aGUgcHJvdG9jb2wuICByZmM2OTUyLA0KICAgICAgYW5kIHRoZSBwcm90b2Nv bHMgaXQgcmVmZXJlbmNlcyBjYW4gc2VydmUgYXMgZXhhbXBsZXMuDQoNCk1pbm9yIElzc3VlczoN Cg0KICAgIC0gVGhlIGRhdGEgYW5kIHNpZ25hbCB0eXBlIGZpZWxkcyBhcmUgYm90aCA4IGJpdHMu ICBUaGlzIHNlZW1zDQogICAgICBwcmV0dHkgc21hbGwsIHBhcnRpY3VsYXJseSB0aGUgZGF0YSB0 eXBlIGZpZWxkLiAgR2l2ZW4gdGhpcyBpcyBhDQogICAgICBjb250cm9sIHByb3RvY29sLCBJIHRo aW5rIGEgbGFyZ2VyIChhdCBsZWFzdCBkYXRhIHR5cGUpIGZpZWxkDQogICAgICB3b3VsZCBwcm92 aWRlIGJldHRlciAiZnV0dXJlIHByb29maW5nIi4NCg0KICAgIC0gMl4zMiB2ZXJzaW9ucyBhcmUg Y3VycmVudGx5IGFsbG93ZWQgKHNlY3Rpb24gOC4xKS4gIFRoaXMgc2VlbXMgYQ0KICAgICAgYml0 IGV4Y2Vzc2l2ZS4gIEknZCBvcHQgZm9yIG1heCBvZiA4IGJpdHMgaGVyZSBteXNlbGYuDQoNCiAg ICAtIEl0J3MgcHJvYmFibHkgdG9vIGxhdGUsIGJ1dCBpdCBwcm9iYWJseSB3b3VsZCBiZSBjbGVh bmVyIHRvIGhhdmUgYQ0KICAgICAgZ2VuZXJpYyBhY2sgc2lnbmFsIHJhdGhlciB0aGFuIGEgcGVy IHNpZ25hbCB0eXBlIGFjay4gSSBtZW50aW9uDQogICAgICB0aGlzIGhlcmUgYXMgdGhpcyBtYXkg Y29tZSB1cCBhZ2FpbiB3aGVuIGNsYXJpZnlpbmcgdGhlDQogICAgICB0cmFuc2FjdGlvbiBtb2Rl bCAoYXMgbWVudGlvbmVkIGFib3ZlLikNCg0KICAgIC0gU2VjdGlvbiAyOiBBc3N1bXB0aW9ucw0K ICAgICAgVGhpcyBzZWN0aW9uIGluY2x1ZGVzIGluZm9ybWF0aXZlIGFuZCBub3JtYXRpdmUgdGV4 dCBzbyBpcyBtb3JlDQogICAgICB0aGFuIGp1c3QgQXNzdW1wdGlvbnMuICBQZXJzb25hbGx5LCBJ J2QgcmVtb3ZlIGFsbCBub3JtYXRpdmUgdGV4dA0KICAgICAgZnJvbSB0aGUgc2VjdGlvbi4NCg0K ICAgIC0gVGhlcmUgYXJlIG5vIHNwZWNpZmljIHJ1bGVzIHJlbGF0ZWQgdG8gVURQIGhlYWRlciBm b3JtYXRpb24uDQoNCiAgICAtIFNlY3Rpb25zIDguMTAtPjguMTcuICBJc24ndCBhZGQvZHJvcCBp bmRpY2F0b3IgbmVlZGVkIGZvciBzdWJuZXRzDQogICAgICBpbiBkZXN0aW5hdGlvbiB1cGRhdGUg c2lnbmFscz8NCg0KICAgIC0gVGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbnMgbXVzdCBm b2xsb3figIsgUkZDMjM2MC4NCg0KICAgIC0gTmV3IHJlZ2lzdHJpZXMgbXVzdCBpbmNsdWRlIGlu aXRpYWwgdmFsdWVzLCB3aGljaCBhcmUgZGVmaW5lZCBpbg0KICAgICAgdGhlIGRvY3VtZW50LiAg KFRoZSBkb2N1bWVudCBjdXJyZW50bHkgaGFzIG1hbnkgVEJEcyB0aGF0IHNob3VsZA0KICAgICAg YmUgcmVwbGFjZWQuKQ0KDQogICAgLSBOZXcgcmVnaXN0cmllcyBuZWVkIGFuIGFsbG9jYXRpb24g cG9saWN5LCBlLmcuOg0KICAgIFRoZSByZWdpc3RyeSBzaG91bGQgYmUgZXN0YWJsaXNoZWQgd2l0 aCByZWdpc3RyYXRpb24gcG9saWNpZXMgb2YNCiAgICAiU3RhbmRhcmRzIEFjdGlvbiIgKGZvciBT dGFuZGFyZHMgVHJhY2sgZG9jdW1lbnRzKSBhbmQNCiAgICDigJxTcGVjaWZpY2F0aW9uIFJlcXVp cmVkIiAoZm9yIG90aGVyIGRvY3VtZW50cykuIFRoZSBkZXNpZ25hdGVkDQogICAgZXhwZXJ0IGlz IGFueSBjdXJyZW50IDxmaWxsLWluPiBXRyBjaGFpci4NCg0KTml0czoNCg0KICAgIC0gVGhlIGRv Y3VtZW50IGludHJvZHVjZXMgdGhlIHRlcm1zICJzaWduYWxzIiBhbmQgImRhdGEgaXRlbXMiIGZv cg0KICAgICAgd2hhdCBpcyBjb21tb25seSBjYWxsZWQgIm1lc3NhZ2VzIiBhbmQgIlRMVnMiIChv ciBvYmplY3RzKSBpbg0KICAgICAgb3RoZXIgcHJvdG9jb2xzLiAgSXQncyBwcm9iYWJseSB0b28g bGF0ZSB0byBjaGFuZ2UgdGhpcywgYnV0IEkNCiAgICAgIHRoaW5rIHRoZSBpbnRyb2R1Y3Rpb24g b2YgdW5pcXVlIHRlcm1pbm9sb2d5IGlzIGNvdW50ZXINCiAgICAgIHByb2R1Y3RpdmUuDQoNCiAg ICAtIFVzZSBvZiBSRkMgMjExOSBjb25mb3JtYW5jZSBsYW5ndWFnZSBpcyBhIGJpdCByb3VnaCwg YW5kIHRoZXJlIGFyZQ0KICAgICAgd29yZHMgaW4gYWxsIGNhcHMgdGhhdCBhcmUgbm90IGRlZmlu ZWQgaW4gUkZDMjExOS4gVGFrZSBhIGxvb2sgYXQNCiAgICAgIGh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL3dnL3RlYXMvdHJhYy93aWtpL1BTR3VpZGVsaW5lIGZvciBzb21lDQogICAgICBzdWdn ZXN0aW9ucy4NCg0KICAgIC0gSW50ZXJuYWwgc29ja2V0IG9wZXJhdGlvbiBpcyBtZW50aW9uZWQg YSBjb3VwbGUgb2YgdGltZXMuICBJdA0KICAgICAgcmVhbGx5IHNob3VsZG4ndCBiZSwgdGhlIHNw ZWMgc2hvdWxkIGRlZmluZSBiZWhhdmlvciBvbiB0aGUgd2lyZS4NCg0KICAgIC0gVGhlIExlbmd0 aCBmaWVsZHMgYXJlIG1pc3NpbmcgdW5pdCBvZiBtZWFzdXJlIChwcmVzdW1hYmx5IG9jdGV0cykN Cg0KICAgIC0gVGhlIE1uZW1vbmljcyBhcmUgdXNlZCBiYXNpY2FsbHkgb25jZSBhbmQgZG9uJ3Qg cmVhbGx5IGFkZCB2YWx1ZSwNCiAgICAgIHN1Z2dlc3QgZHJvcHBpbmcgdGhlbS4NCg0KICAgIC0g SG93L3doZW4gaXMgdGhlICJVbmtub3duIFNpZ25hbCIgU3RhdHVzIENvZGUgc2VudD8NCg0KICAg IC0gU2VjdGlvbiA4Ljc6IEV4dGVuc2lvbiBMaXN0IHNob3VsZCBiZSBzaG93biBhcyBhIHZhcmlh YmxlIGxlbmd0aA0KICAgICAgZmllbGQuDQoNCiAgICAtIFNlY3Rpb24gOC44OiBFeHBlcmltZW50 IExpc3Qgc2hvdWxkIGJlIHNob3duIGFzIGEgdmFyaWFibGUgbGVuZ3RoDQogICAgICBmaWVsZC4N Cg0KVGhhdCdzIGl0IC0tIGZvciBub3cgLS0gaG9wZWZ1bGx5IEkgZGlkbid0IG1pc3MgYW55dGhp bmcuICBMb29rIGZvcndhcmQgdG8gaGVhcmluZyByZXNwb25zZSB0byB0aGUgYWJvdmUgKGFuZCBo b3cgSSBnb3QgdGhpbmdzIGhvcGVsZXNzbHkgd3JvbmcgOy0pDQoNCkxvdQ0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcg bGlzdA0KbWFuZXRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbWFuZXQNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUg Y29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRl bGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3Vs ZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpk aXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= From nobody Mon Jun 15 06:08:42 2015 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 7EA9C1B35FE for ; Mon, 15 Jun 2015 06:08:41 -0700 (PDT) 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 Nae-2vgzq40B for ; Mon, 15 Jun 2015 06:08:39 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC381B3612 for ; Mon, 15 Jun 2015 06:08:39 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,618,1427774400"; d="scan'208";a="7994300" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport2.idirect.net with ESMTP; 15 Jun 2015 09:08:36 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 15 Jun 2015 09:08:34 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.1076.000; Mon, 15 Jun 2015 09:08:34 -0400 From: "Ratliff, Stanley" To: Henning Rogge , Rick Taylor Thread-Topic: [manet] DLEP sample router Thread-Index: AdCjlIV0WgZL0PGJTwid2ae88IoeJQDyddgAAAN0ddA= Date: Mon, 15 Jun 2015 13:08:33 +0000 Message-ID: <2178b3fa58ef432fb54d3553c6c336e2@VAUSDITCHM2.idirect.net> References: <38A5475DE83986499AEACD2CFAFC3F98016C26FCA9@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: manet IETF Subject: Re: [manet] DLEP sample router 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: Mon, 15 Jun 2015 13:08:41 -0000 Gentlemen, = Fantastic news! Congratulations to you both. = Beers. We MUST (proper RFC terminology here) share Beers in Prague over thi= s. :-) Regards, Stan > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge > Sent: Monday, June 15, 2015 3:28 AM > To: Rick Taylor > Cc: manet IETF > Subject: Re: [manet] DLEP sample router > = > Hello everyone, > = > after a few fixes on both sides my dlep_radio implementation is now > exchanging data with Ricks dlep_router. > = > Henning > = > On Wed, Jun 10, 2015 at 5:45 PM, Rick Taylor > wrote: > > All, > > > > For those who are interested, I have just pushed an updated version of > > my dlep_router with draft-14 support. > > > > Its at: https://github.com/ricktaylor/dlep_router > > > > It definitely needs some testing, and any feedback gratefully received. > > > > 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 _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Mon Jun 15 06:32:14 2015 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 369CA1B2D37 for ; Mon, 15 Jun 2015 06:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 97iqN1Km9kbH for ; Mon, 15 Jun 2015 06:32:12 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (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 D237A1B2D32 for ; Mon, 15 Jun 2015 06:32:11 -0700 (PDT) Received: by wgv5 with SMTP id 5so68950986wgv.1 for ; Mon, 15 Jun 2015 06:32:10 -0700 (PDT) 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=Ra1EiOMbd53Oi3yn34mOTq0ag/0MzSB8xM1VNrtQMlA=; b=Q0CYGBRPrfM/tCLxYjqDTJ1scyN0uN6nxbBBLVuv9B9GWHqN56xYwZo41wOcbVgU/V m+bn3tS5r8Dq1LbbD7XZMFw0+OmkOUDBNTE2kMcSUcodJH8/1GsZ8eaf2WVEcML2tZQk VIF/0GW1r6oe6N//2CrIMwY07bsGzjb0zcv7TTQB1LA3IzQqTb4lLJVRQ0aeRYOIWUhU XtusNLdTb/pbrwrCtonYYW4Aeyb94O8/FKIgBcvi8UYiQB+CwGmKo+jDlUH9tcayYU2Q hZgVAmV9qD8nQIN7vBw/3v5w2m16L163pXzXZM+pwxh/XwVGJHA645sqnh/KMBQsJXYM oPzQ== X-Received: by 10.180.103.227 with SMTP id fz3mr31833718wib.45.1434375130599; Mon, 15 Jun 2015 06:32:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Mon, 15 Jun 2015 06:31:50 -0700 (PDT) In-Reply-To: <2178b3fa58ef432fb54d3553c6c336e2@VAUSDITCHM2.idirect.net> References: <38A5475DE83986499AEACD2CFAFC3F98016C26FCA9@tss-server1.home.tropicalstormsoftware.com> <2178b3fa58ef432fb54d3553c6c336e2@VAUSDITCHM2.idirect.net> From: Henning Rogge Date: Mon, 15 Jun 2015 15:31:50 +0200 Message-ID: To: "Ratliff, Stanley" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: manet IETF Subject: Re: [manet] DLEP sample router 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: Mon, 15 Jun 2015 13:32:13 -0000 On Mon, Jun 15, 2015 at 3:08 PM, Ratliff, Stanley wrote: > Gentlemen, > > Fantastic news! Congratulations to you both. > > Beers. We MUST (proper RFC terminology here) share Beers in Prague over this. :-) I think first we have to work out the large review DLEP got... Henning From nobody Mon Jun 15 12:03:40 2015 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 5B7271A700D; Mon, 15 Jun 2015 12:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGfpA0PRfnaL; Mon, 15 Jun 2015 12:03:32 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E691A701D; Mon, 15 Jun 2015 12:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4727; q=dns/txt; s=iport; t=1434394965; x=1435604565; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OZKXw/lUaLH9yDKTQaVI053XAIgaCLiZWdrYhHlwQt0=; b=QJ8IV1kvi1DNYQRJOpci6uFhig4fqabtqZkgJJx7TN/RPogD7dJhYozB DvRrII2htX4lmKMAZ+JvjWUREIIWN0TRt86ce3ka8gMqvIdQ5apSQZgAL QXJPblnd9+qe9yDMG7DufrPtVkWKbNvAtsqzAjzeJ9Mm7f0b+Zijdz6KK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJBQALIX9V/4UNJK1bgxCBMwa5OoQ0h1kCgTw6EgEBAQEBAQGBCoQjAQEEaw4QAgEIRjIlAgQBDQWIL8wJAQEBAQEBAQEBAQEBAQEBAQEBARmLRIRTMweELQEEhnqKDYJUAYckhB2BM45hh3wmY4FZgT1vgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,620,1427760000"; d="scan'208";a="159537693" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 15 Jun 2015 19:02:44 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t5FJ2iMM002676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jun 2015 19:02:44 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.106]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Mon, 15 Jun 2015 14:02:43 -0500 From: "Alvaro Retana (aretana)" To: "Benoit Claise (bclaise)" , Susan Hares Thread-Topic: Benoit Claise's Discuss on draft-ietf-manet-olsrv2-multitopology-05: (with DISCUSS) Thread-Index: AQHQmUnuajLfhADH00edYzbRKWlUcJ2uKqWA Date: Mon, 15 Jun 2015 19:02:43 +0000 Message-ID: References: <20150528132630.13861.80616.idtracker@ietfa.amsl.com> In-Reply-To: <20150528132630.13861.80616.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0E1C3332220C924B8B22083520375334@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-manet-olsrv2-multitopology@ietf.org" , "ops-dir@ietf.org" , "manet@ietf.org" , The IESG , "manet-chairs@ietf.org" Subject: Re: [manet] Benoit Claise's Discuss on draft-ietf-manet-olsrv2-multitopology-05: (with DISCUSS) 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: Mon, 15 Jun 2015 19:03:34 -0000 On 5/28/15, 9:26 AM, "Benoit Claise (bclaise)" wrote: [Because the authors didn=B9t have time to review the ops-dir comments before the telechat, or before they became a DISCUSS, I=B9m explicitly cc=B9ing it here as well as Sue.] Benoit: Hi! Sorry it took me a while to get to this.. >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >The multiple points, brought up by Sue part of her OPS-DIR review, >deserve a DISCUSS. Let's engage in the discussion. . . . >Summary of Comments: > >My comments have 6 major issues, and a set of editorial changes. Five of >my major points have to do with adding more details to the draft to judge >the experiment valuable. One way to resolve these comments is to create >document providing details on the test that will be run. A second way to >resolve these comments on experiment is to provide additional high-level >guidance in this document. Note that section 1.1 (Motivation and Experimentation) already provides high-level guidance of the type of information to be evaluated. While general experiences with this protocol extension, including interoperability of implementations, are encouraged, specific information would be particularly appreciated on the following areas: o Operation in a network that contains both routers implementing this extension, and routers implementing only [RFC7181], in particular are there any unexpected interactions that can break the network? o Operation in realistic deployments, and details thereof, including in particular indicating how many concurrent topologies were required. A broader issue that applies to unextended [RFC7181] as well as this extension (and potentially to other MANET routing protocols) is which link metric types are useful in a MANET, and how to establish the metrics to associate with a given link. While this issue is not only related to this extension, the ability for an OLSRv2 network to maintain different concurrent link metrics may facilitate both experiments with different link metric types, ways to measure them, etc. and may also allow experimentation with link metric types that are not compromises to handle multiple traffic types. Clearly the focus is on =B3running code=B2: operation in real deployments a= nd mixed environments. The suggestions for tests made in the Ops-Dir review are great! However, I don=B9t believe that such detail belongs in this document, where the main purpose is to document the extension. In fact, I think the suggestions belong more as part of a test plan (used by implementors =8B similar maybe to the work done in bmwg, for example), which seems to be in line with the comments: (Sue wrote) =B3The recommended tests in major concern 1-4 could b= e created in a separate draft.=B2 It is not in the manet WGs charter to produce test plans. In order to not loose Sue=B9s valuable input, I suggest we keep them in the WG=B9s wiki =8B which will allow for other test cases to be added, details included, results reflected, etc. . . . >Major concern 5: Experiments should drive to create operational >guidelines for deployment, configuration knobs, and use cases (ADOV-2, >OLSR-v2, MT-OLSR-v2) Completely agree! Implementation and operational experience (not just experiments) should in fact result in that type of guidelines. Again, the details are not within the scope of this document..and guidance is already given in 1.1 about the use in real networks. Note that this comment mentions not just the extensions proposed, but the base protocol and even AODVv2. All these guidelines are important from an operations point of view, but shouldn=B9t be tied to this document. Aside: the MANET WG is in process of rechartering. This type of suggestions should be presented for discussion. . . . >Major 6: The IANA section does not answer all the IANA questions. > >It has most of the information, but I think it is not up to the latest >IANA format and information. Barry Leiba and others have noted that the >RFC 7181 and RFC7188 do not match this IANA section. Rather than repeat >these comments, I will simple state the data needs to be consistent and >the format match IANA=B9s comments. Barry=B9s comment has been solved and will be reflected in an update. The authors have been talking to IANA directly. We are now waiting for review from the MANET registry experts (which is the one open item with IANA). Thanks! Alvaro. From nobody Tue Jun 16 02:01:09 2015 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 47B371A8A44; Tue, 16 Jun 2015 02:01:07 -0700 (PDT) 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 8BT78N_M55rh; Tue, 16 Jun 2015 02:01:04 -0700 (PDT) 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 4FBDF1A8A28; Tue, 16 Jun 2015 02:01:03 -0700 (PDT) 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 Jun 2015 10:00:37 +0100 From: Rick Taylor To: "Dearlove, Christopher (UK)" , Lou Berger , "manet-chairs@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Tue, 16 Jun 2015 09:00:35 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C29B371@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , "manet@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 09:01:07 -0000 QWxsLAoKU3RhbiBhbmQgSSBhcmUgY3VycmVudGx5IGRpc2N1c3NpbmcgdGhlIHJldmlldy4gIFdl IHdpbGwgY29tZSBiYWNrIHRvIAp0aGUgbGlzdCB3aXRoIGEgcHJvcG9zZWQgc2V0IG9mIGFjdGlv bnMgd2hlbiB3ZSBoYXZlIGEgcGxhbi4KClNvcnJ5IGZvciB0aGUgZGVsYXksCgpSaWNrCgoKT24g MTUvMDYvMTUgMTI6MTYsIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIHdyb3RlOgo+IEkgaGF2 ZW4ndCBzZWVuIGFueSBkaXNjdXNzaW9uIG9mIHRoaXMuIEl0IGxvb2tzIHRvIG1lIGxpa2UgcmVx dWlyaW5nIGFub3RoZXIgZHJhZnQgZm9yIHRoZSBXRyB0byBzZWUuIEl0IGRvZXMgKGJ5IG15IHJh cGlkIGNvdW50KSBoYXZlIDE3IG1ham9yIGlzc3Vlcy4KPgo+IC0tCj4gQ2hyaXN0b3BoZXIgRGVh cmxvdmUKPiBTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyCj4gQkFFIFN5c3RlbXMgQXBwbGllZCBJ bnRlbGxpZ2VuY2UKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Cj4gVDogICs0NCAoMCkxMjQ1IDI0MjE5 NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20KPgo+IEJBRSBTeXN0ZW1zIEFw cGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFk ZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLgo+IHd3dy5iYWVzeXN0ZW1zLmNvbS9haQo+ IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQKPiBSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTEKPiBSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5 IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQCj4KPgo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgTG91IEJlcmdlcgo+IFNlbnQ6IDA4IEp1bmUgMjAxNSAyMDox MQo+IFRvOiBtYW5ldC1jaGFpcnNAaWV0Zi5vcmcKPiBDYzogbWFuZXQtYWRzQGlldGYub3JnOyBy dGctZGlyQGlldGYub3JnOyBtYW5ldEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLmFs bEBpZXRmLm9yZwo+IFN1YmplY3Q6IFttYW5ldF0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1t YW5ldC1kbGVwLTE0Cj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3Vy IG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRo ZSBpbnRlcm5ldC4KPiBDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNr IG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuCj4gRm9sbG93IHRo ZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3Ry dWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj4gW05v dGUgdGhpcyBpcyBhIFdHIExDIHJlbGF0ZWQgcmV2aWV3LCBub3QgSUVURiBMQy5dCj4KPiBIZWxs bywKPgo+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJl dmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byBy ZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3Mg dGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24g c3BlY2lhbCByZXF1ZXN0IC0tIG9yIFdHIExhc3QgY2FsbCBhcyB3YXMgdGhlIGNhc2UgaGVyZSAu IFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRo ZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGly ZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9y dGcvdHJhYy93aWtpL1J0Z0Rpcgo+Cj4gQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1h cmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgKGNoYWlycyBhbmQpIFJvdXRpbmcgQURzLCBpdCB3b3Vs ZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90 aGVyIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJl c29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lgo+ Cj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC0xNAo+IFJldmlld2VyOiBMb3UgQmVy Z2VyCj4gUmV2aWV3IERhdGU6IEp1bmUgOCAobGF0ZXIgdGhhbiByZXF1ZXN0ZWQgZHVlIHRvIHNj b3BlIG9mIGNvbW1lbnRzIC0tIHNvcnJ5KSBXRyBMQyBFbmQgRGF0ZTogdW5rbm93biBJbnRlbmRl ZCBTdGF0dXM6IFN0YW5kYXJkcyB0cmFjawo+Cj4gU3VtbWFyeToKPgo+ICAgICAgV2hpbGUgSSB0 aGluayB0aGUgZG9jdW1lbnQgaXMgcHJldHR5IGRlY2VudCBmb3IgdGhlIHNjb3BlIG9mIHRoZQo+ ICAgICAgd29yaywgSSBkbyBoYXZlIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgYW5kIHJl Y29tbWVuZCB0aGF0IHRoZQo+ICAgICAgV0cgQ2hhaXJzL1JvdXRpbmcgQURzIGRpc2N1c3MgdGhl c2UgaXNzdWVzIGZ1cnRoZXIgd2l0aCB0aGUgYXV0aG9ycy4KPiAgICAgIEknbSBhbHNvIGF2YWls YWJsZSBhcy9pZiBuZWVkZWQgdG8gZGlzY3Vzcy4KPgo+IENvbW1lbnRzOgo+Cj4gICAgICBJIHRo aW5rIHRoZSBkb2N1bWVudCBzaG93cyBzaWduaWZpY2FudCBnb29kIHdvcmsgYW5kIGxvb2tzIHRv IGJlIGEKPiAgICAgIHVzZWZ1bCBwcm90b2NvbCwgYWx0aG91Z2ggSSdtIG5vdCBvdmVybHkgZmFt aWxpYXIgaW4gdGhpcyBzcGFjZS4KPiAgICAgIFRoYXQgc2FpZCwgSSBoYXZlIGEgbnVtYmVyIG9m IHNlcmlvdXMgY29uY2VybnMgYWJvdXQgdGhlIGRvY3VtZW50LAo+ICAgICAgYW5kIGl0cyBjb250 ZW50cyBmcm9tIGEgZmV3IG9mIHBlcnNwZWN0aXZlcy4gIFRoZXNlIGluY2x1ZGUgYmFzaWMKPiAg ICAgIHByb3RvY29sIGlzc3VlcywgdW5kZXJzcGVjaWZpZWQgZGV0YWlscyAgKHdoaWNoIGNvdWxk IGxlYWQgdG8KPiAgICAgIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzKSwgYW5kIHNwZWNpZmljYXRp b24vZWRpdG9yaWFsIGlzc3Vlcy4gSQo+ICAgICAgdGhpbmsgdGhlIGRvY3VtZW50IC8gcHJvdG9j b2wgY2FuIGJlIG1vZGlmaWVkIHRvIGFkZHJlc3MgdGhlIGlzc3Vlcwo+ICAgICAgSSByYWlzZSBi ZWxvdy4gIE9mIGNvdXJzZSwgaXQgaXMgdXAgdG8gdGhlIFdHLCBjaGFpcnMsIGFuZCBBRHMgdG8K PiAgICAgIGRlY2lkZSB3aGljaCBjb21tZW50cyB0byBhZGRyZXNzIGFuZCB3aGljaCB0byAgaWdu b3JlLgo+ICAgICAgSSBkb24ndCBleHBlY3QgdGhhdCBhbGwgY29tbWVudHMgd2lsbCByZXN1bHQg aW4gY2hhbmdlcy4KPgo+IE1ham9yIElzc3VlczoKPgo+ICAgICAgLSBUaGUgbGVuZ3RoIGZpZWxk IG9mIHRoZSBnZW5lcmljIGRhdGEgaXRlbSAoaS5lLiwgVExWKSBpcyBvbmx5IDgKPiAgICAgICAg Yml0cy4gIFdoaWxlIDI1NSBieXRlcyAoYXNzdW1pbmcgdGhhdCB0aGlzIGlzIHRoZSB1bml0IG9m IG1lYXN1cmUsCj4gICAgICAgIHdoaWNoIEJUVyBpc24ndCBzcGVjaWZpZWQpIGlzIGJpZyBlbm91 Z2ggdG9kYXksIGFsbG93aW5nIGZvcgo+ICAgICAgICBsYXJnZXIgd2lsbCBncmVhdGx5IHNpbXBs aWZ5IHRoaW5ncyB3aGVuIDI1NSBpc24ndCBlbm91Z2guIC0tCj4gICAgICAgIFdlJ3ZlIHJ1biBp bnRvIHRoaXMgaW4gUlNWUCBhbmQgaXQncyBhIHJlYWwgcGFpbi4KPgo+ICAgICAgLSBWZXJzaW9u IG51bWJlciBpcyBjdXJyZW50bHkgZGVmaW5lZCBhcyBhIGRhdGEgaXRlbS4gIFRoaXMgbWVhbnMg YQo+ICAgICAgICBzaWduYWwgKGkuZS4sIG1lc3NhZ2UpIG5lZWRzIHRvIGJlIHBvdGVudGlhbGx5 IGZ1bGx5IHBhcnNlZCB0bwo+ICAgICAgICBkaXNjb3ZlciB3aGF0IHZlcnNpb24gaXMgYmVpbmcg dXNlZC4gIFRoaXMgcHJlY2x1ZGVzIGJhc2ljIGZvcm1hdAo+ICAgICAgICBjaGFuZ2VzIHRvIHRo ZSBwcm90b2NvbC4gIFBlcmhhcHMgdGhlIERpc2NvdmVyeSBhbmQgSW5pdCBTaWduYWxzCj4gICAg ICAgIHNob3VsZCBiZSBzcGVjaWFsIGNhc2VkIHRvIGluY2x1ZGUgdmVyc2lvbiBpbiB0aGVpciBm b3JtYXRzLiAgKEFuZAo+ICAgICAgICBzaG9ydGVuIHZlcnNpb24gdG8gOCBiaXRzIGZyb20gMzIs IGFzIG1lbnRpb25lZCBiZWxvdykuCj4KPiAgICAgIC0gVGhlIGRvY3VtZW50IHJlZmVyZW5jZXMs IGJ1dCBkb2VzIG5vdCBkZWZpbmUsICdpbi1zZXNzaW9uJyBhbmQKPiAgICAgICAgJ2Rpc2NvdmVy eScgc3RhdGVzLiAgVGhlc2UgZWl0aGVyIG5lZWQgdG8gYmUgZm9ybWFsbHkgZGVmaW5lZCBvcgo+ ICAgICAgICByZW1vdmVkLiAgQlRXIHdlIGhhZCBleGFjdGx5IHRoZSBzYW1lIGlzc3VlIHdpdGgg TE1QIChSRkM0MjA0KSBhbmQKPiAgICAgICAgZW5kZWQgdXAgYWRkaW5nIHNlY3Rpb24gMTEgKEZT TXMpIGF0IGEgcHJldHR5IGxhdGUgc3RhZ2Ugb2YgdGhlCj4gICAgICAgIHByb2Nlc3MuCj4KPiAg ICAgIC0gVENQIHNlc3Npb24gbWFuYWdlbWVudCBpcyBub3QgZGVmaW5lZCwgbm9yIGlzIHRoZSBy ZWxhdGlvbnNoaXAKPiAgICAgICAgd2l0aCBUQ1AgYW5kIERMRVAgc2Vzc2lvbnMgZnVsbHkgZGVm aW5lZC4gIEZvciBleGFtcGxlOgo+Cj4gICAgICAgIG8gQ2xvc2luZyB0aGUgVENQIHNlc3Npb24g aXMgb25seSBtZW50aW9uZWQgaW4gb25lIHBsYWNlIGFuZCBpbiBhCj4gICAgICAgICAgd2F5IHRo YXQgaXMgaW5jb25zaXN0ZW50IHdpdGggdGhlIGV4cGVjdGVkIHByb3RvY29sIGJlaGF2aW9yCj4g ICAgICAgICAgKGNsb3NlIFRDUCBiZWZvcmUgQUNLIGlzIHJlY2VpdmVkKS4KPgo+ICAgICAgICBv IFdoYXQgaGFwcGVucyB3aGVuIGEgRExFUCBzZXNzaW9uIGlzIHRlcm1pbmF0ZWQsIGNhbiB0aGUg VENQCj4gICAgICAgICAgc2Vzc2lvbiBiZSByZXVzZWQgb3IgbXVzdCBpdCBiZSBjbG9zZWQgdG9v Pwo+Cj4gICAgICAtIFRoZXJlIGlzIG5vIHRyYW5zYWN0aW9uIG1vZGVsIGRlZmluZWQuICBGb3Ig ZXhhbXBsZSwgaXQncwo+ICAgICAgICBjb21wbGV0ZWx5IHVuY2xlYXIgaWYgb25seSBvbmUgdW5h Y2tub3dsZWRnZWQgU2lnbmFsIGFsbG93ZWQgYXQgYQo+ICAgICAgICB0aW1lLCBvciBwZXJoYXBz IGp1c3Qgb25lIHBlciBzaWduYWwgdHlwZSBpcyBhbGxvd2VkLCBvciBwZXJoYXBzCj4gICAgICAg IHRoZXJlIGFyZSBubyByZXN0cmljdGlvbnMuICBUaGlzIG5lZWRzIHRvIGJlIGV4cGxpY2l0Lgo+ Cj4gICAgICAtIFdoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgcmV0cmllcyBhbmQgdGltZW91dHMgb3Zl ciBUQ1A/ICBSZXRyaWVzCj4gICAgICAgIGFyZW4ndCBuZWVkZWQgb3ZlciBUQ1BzIGFuZCBpdCdz IHVuY2xlYXIgd2hleSB0aGV5IGFyZSBiZWluZyB1c2VkLgo+Cj4gICAgICAtIFRoZSBoaWdoZXIg bGV2ZWwgaW1wbGljYXRpb25zIG9mIEFDS3MsIG92ZXIgVENQLCBpc24ndCByZWFsbHkKPiAgICAg ICAgY2xlYXIuICBJdCBzZWVtcyBBQ0tzIGFyZSBkZWZpbmVkIGZvciBtdWx0aXBsZSBwdXJwb3Nl czogcmVsaWFibGUKPiAgICAgICAgdHJhbnNwb3J0LCB0cmFuc2FjdGlvbiBhY2tub3dsZWRnbWVu dCBhbmQgdHJhbnNhY3Rpb24gcmVzdWx0cy4gT2YKPiAgICAgICAgY291cnNlIHRoZSBmaXJzdCBp c24ndCBuZWVkZWQsIGFuZCBpbXBsaWNhdGlvbnMgb2YgdGhlIG90aGVycwo+ICAgICAgICBzaG91 bGQgYmUgY2xlYXIuICBGb3IgZXhhbXBsZSwgaW4gc2VjdGlvbiA3LjEwLCB3aHkgd291bGQgdGhl cmUgYmUKPiAgICAgICAgYSByZXRyeSB3aGVuIHJlY2VpdmluZyBhIERlc3RpbmF0aW9uIFVwIEFD SyBzaWduYWwgaW5kaWNhdGluZyBhbgo+ICAgICAgICBlcnJvcj8KPgo+ICAgICAgLSBUaGVyZSBp cyBubyBkaXNjdXNzaW9uIG9uIHNjYWxpbmcgY29uc2lkZXJhdGlvbnMuIEFyZSB0aGVyZSByZWFs bHkKPiAgICAgICAgbm9uZT8gIEZvciBleGFtcGxlLCBob3cgb2Z0ZW4gbWlnaHQgYmUgYXBwcm9w cmlhdGUgdG8gaXNzdWUvbGltaXQKPiAgICAgICAgUGVlciBVcGRhdGVzIGJhc2VkIHRvIGNoYW5n ZXMgaW4gbGluayBxdWFsaXR5LCBvciBob3cgdG8gaGFuZGxlCj4gICAgICAgIHRoZSBjYXNlIHdo ZXJlIGEgbGFyZ2UgbnVtYmVyIChhbGwgb3IgbW9zdCkgb2YgZGVzdGluYXRpb25zIGdvCj4gICAg ICAgIGRvd24uCj4KPiAgICAgIC0gVGhlcmUgYXJlIDEzIHBsYWNlcyB3aGVyZSB0aGUgcHJvdG9j b2wgYWxsb3dzIGltcGxlbWVudGF0aW9uIHRvCj4gICAgICAgIGRlZmluZSB0aGVpciBvd24gJ2hl dXJpc3RpY3MnLiAgU29tZSBvZiB0aGVzZSBzZWVtIHVubmVjZXNzYXJ5IGR1ZQo+ICAgICAgICB0 byB0aGUgVENQIHBvaW50IHJhaXNlZCBhYm92ZSwgYnV0IGFueSB0aGF0IHJlbWFpbiBpbiB0aGUg cHJvdG9jb2wKPiAgICAgICAgc2hvdWxkIGJlIGZ1bGx5IHNwZWNpZmllZCB0byBlbnN1cmUgcHJl ZGljdGFibGUvY29uc2lzdGVudAo+ICAgICAgICBiZWhhdmlvciBmcm9tIGltcGxlbWVudGF0aW9u cy4KPgo+ICAgICAgLSBEYXRhIEl0ZW1zIGFyZSBkZWZpbmVkIGZvciAiRXh0ZW5zaW9ucyIgYW5k ICJFeHBlcmltZW50YWwKPiAgICAgICAgRGVmaW5pdGlvbiIgKFNlY3Rpb25zIDguNyBhbmQgOC44 KS4gIEJvdGggc2VlbSB0byBzdXBwb3J0IGZvcgo+ICAgICAgICBvcHRpb25hbCBtZWNoYW5pc21z LCBidXQgdGhlIGZvcm1lciB1c2VzIGFzc2lnbmVkIG51bWVyaWMgdmFsdWVzLAo+ICAgICAgICB3 aHkgdGhlIGxhdHRlciB1c2VzIFVURi04IHN0cmluZ3MuCj4gICAgICAgIG8gV2hhdCwgaWYgYW55 LCBpcyB0aGUgaW50ZW5kZWQgZGlzdGluY3Rpb24vcmVsYXRpb25zaGlwIGJldHdlZW4KPiAgICAg ICAgICB0aGVzZT8KPiAgICAgICAgbyBIb3cgZG9lcyBhbiAiRXhwZXJpbWVudGFsIERlZmluaXRp b24iIGJlY29tZSBzdGFuZGFyZGl6ZWQ/Cj4KPiAgICAgIC0gU2VjdGlvbnMgOC4xOSBhbmQgOC4y MCBkZWZpbmUgIlJlc291cmNlcyIgcmVsYXRlZCBEYXRhIEl0ZW1zLiAgVGhlCj4gICAgICAgIGRl ZmluaXRpb24gcmVsYXRlZCB0byB0aGVzZSBiYXNpY2FsbHkgc2F5cyBhIHJlc291cmNlcyBpcyAi QW4KPiAgICAgICAgOC1iaXQgaW50ZWdlciBwZXJjZW50YWdlLCAwLTEwMCwgcmVwcmVzZW50aW5n IHRoZSBhbW91bnQgb2YKPiAgICAgICAgcmVzb3VyY2VzIGFsbG9jYXRlZCB0byByZWNlaXZpbmd8 dHJhbnNtaXR0aW5nIGRhdGEuIi4gIElmIEkgd2VyZQo+ICAgICAgICBpbXBsZW1lbnRpbmcgdGhp cyBwcm90b2NvbCwgSSdkIGhhdmUgbm8gaWRlYSBob3cgdG8gcHJvZHVjZSwKPiAgICAgICAgdXBk YXRlIG9yIHVzZSB0aGlzIGluZm9ybWF0aW9uLiAgSSB0aGluayB0aGVyZSBpcyBzb21lIG1pc3Np bmcKPiAgICAgICAgaW5mb3JtYXRpdmUgYW5kIG5vcm1hdGl2ZSAoUkZDIDIxMTkpIHRleHQgcmVs YXRlZCB0byB0aGVzZQo+ICAgICAgICBmb3JtYXRzLgo+Cj4gICAgICAtIFNlY3Rpb25zIDguMjEg YW5kIDguMjIgKFJlbGF0aXZlIExpbmsgUXVhbGl0eSkgaGF2ZSBhIHNpbWlsYXIKPiAgICAgICAg cHJvYmxlbSBvZiBiZWluZyB1bmRlciBkZXNjcmliZWQsIGluIHBhcnRpY3VsYXIgaXQncyB1bmNs ZWFyIGlmCj4gICAgICAgIHRoZXJlJ3MgYSBtZWFuaW5nZnVsLCBub24tcHJvcHJpZXRhcnkgZGVm aW5pdGlvbiBmb3IgbGluayBxdWFsaXR5Cj4gICAgICAgIHRoYXQgYW4gaW1wbGVtZW50YXRpb24g aXMgdG8gYWN0IG9uIG9yIGlmIHRoZSBwYXNzZWQgdmFsdWUgaXMganVzdAo+ICAgICAgICBwYXNz ZWQgZm9yIGFzIG1vbml0b3JpbmcgaW5mb3JtYXRpb24uICBFaXRoZXIgd2F5LCB0aGlzIG5lZWRz IHRvCj4gICAgICAgIGJlIGNsYXJpZmllZC4KPgo+ICAgICAgLSBTZWN0aW9uIDkgZGVmaW5lcyBh ICJjcmVkaXQtd2luZG93aW5nIHNjaGVtZSBhbmFsb2dvdXMgdG8gdGhlIG9uZQo+ICAgICAgICBk b2N1bWVudGVkIGluIFtSRkM1NTc4XSIuIEl0IGRlc2NyaWJlcyBob3cgY3JlZGl0cyBhcmUgZXhj aGFuZ2VkLAo+ICAgICAgICBidXQgaXQgcHJvdmlkZXMgemVybyBkZWZpbml0aW9uIG9uIHRoZSBp bXBsaWNhdGlvbnMgb3IgdXNlIG9mCj4gICAgICAgIGNyZWRpdHMgcmVsYXRpdmUgdG8gdGhlIGRh dGEgcGxhbmUuCj4KPiAgICAgIC0gTXVsdGlwbGUgd2F5cyB0byBpbXBsZW1lbnQgdGhlIHNhbWUg ZnVuY3Rpb24gYXJlIGFsbG93ZWQsIGUuZy4sCj4gICAgICAgIG9wdGlvbmFsIHByZXNlbmNlIG9m IFN0YXR1cywgSW50ZXJ2YWwgYW5kIFRDUCBwb3J0LiAgR2VuZXJhbGx5Cj4gICAgICAgIGFsbG93 aW5nIHN1Y2ggY29tcGxpY2F0ZXMgdGVzdGluZyBhbmQgbGVhZHMgdG8gaW50ZXJvcGVyYWJpbGl0 eQo+ICAgICAgICBpc3N1ZXMuICBUaGUgZG9jdW1lbnQgc2hvdWxkIHBpY2sgb25lIHdheSBhbmQg cmVxdWlyZSBpdC4KPgo+ICAgICAgLSBUaGUgZG9jdW1lbnQgZG9lc24ndCBzdGF0ZSBpZiB0aGVy ZSBhcmUgYW55IG9yZGVyaW5nIHJlcXVpcmVtZW50cwo+ICAgICAgICBvbiBkYXRhIGl0ZW1zLiBJ dCBzaG91bGQgYmUgZXhwbGljaXQgb24gdGhpcywgZS5nLiwgdGhlcmUgYXJlIG5vCj4gICAgICAg IG9yZGVyaW5nIHJlcXVpcmVtZW50cyBvbiB0aGUgcGxhY2VtZW50IG9mIERhdGEgSXRlbXMgd2l0 aGluCj4gICAgICAgIFNpZ25hbHMuCj4KPiAgICAgIC0gVGhlIHJlcXVpcmVkIGFuZCBvcHRpb25h bCBkYXRhIGl0ZW1zIHRoYXQgYXJlIHBlcm1pdHRlZCBvbiBhCj4gICAgICAgIHNpZ25hbCBpc24n dCBhbHdheXMgY2xlYXIuICBGb3IgZXhhbXBsZSBhcmUgMC8xL04gY29waWVzIG9mIGEKPiAgICAg ICAgcGFydGljdWxhciBEYXRhIEl0ZW0gcmVxdWlyZWQvYWxsb3dlZC4gIFVzaW5nIHNvbWV0aGlu ZyBsaWtlIEFCTkYKPiAgICAgICAgd291bGQgcmVhbGx5IGhlbHAgZm9ybWFsaXplIGFuZCBjbGFy aWZ5IHRoaXMuCj4KPiAgICAgIC0gVGhlIGRvY3VtZW50IGRvZXNuJ3QgY2xlYXJseSBkZWxpbmVh dGUgZnJvbSBpbmZvcm1hdGl2ZS9uYXJyYXRpdmUKPiAgICAgICAgdGV4dCwgbm9ybWF0aXZlIC8g cmVxdWlyZWQgcHJvY2Vzc2luZyBwcm9jZWR1cmVzLCBhbmQgbWVzc2FnZQo+ICAgICAgICBmb3Jt YXRzLiBUaGlzIGJ5IGl0c2VsZiBpcyBub3QgbmVjZXNzYXJpbHkgYSBtYWpvciBpc3N1ZSwgaXQg anVzdAo+ICAgICAgICBtYWtlcyBpdCBoYXJkZXIgdG8gKHdyaXRlLCkgcmV2aWV3IGFuZCBpbXBs ZW1lbnQgdGhlIHByb3RvY29sLgo+ICAgICAgICBXaGF0IGlzIGEgbWFqb3IgaXNzdWUgaXMgdGhh dCB0aGlzIGFwcHJvYWNoIGFsbG93cyBmb3IgZHVwbGljYXRlCj4gICAgICAgIChhbmQgc29tZXRp bWVzIGNvbnRyYWRpY3RvcnkpIG5vcm1hdGl2ZSBwcm9jZWR1cmVzIGFuZCBmb3IKPiAgICAgICAg b21pc3Npb25zIGluIHByb2NlZHVyZXMgKHBhcnRpY3VsYXJseSByZWxhdGVkIHRvIGV4Y2VwdGlv bi9lcnJvcgo+ICAgICAgICBwcm9jZXNzaW5nKS4gIFNwZWNpZmljIGV4YW1wbGVzIGFyZSBpbmNs dWRlZCBhYm92ZSBhbmQgYmVsb3cuICBJdAo+ICAgICAgICB3b3VsZCBiZSBiZXN0IHRvIGVuc3Vy ZSB0aGF0IGVhY2ggcmVxdWlyZWQgcHJvY2Vzc2luZyBiZWhhdmlvciBpcwo+ICAgICAgICBkZWZp bmVkIGp1c3Qgb25jZSBhbmQgaW4gYSBjb25zaXN0ZW50IHdheS4KPgo+ICAgICAgLSBUaGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGlzIGluYWRlcXVhdGUuICBUaGlzIHNlY3Rpb24K PiAgICAgICAgc2hvdWxkIGFkZHJlc3MgdGhlIHNlY3VyaXR5IG9mIHRoZSBETEVQIHByb3RvY29s LCBub3QgdXNlcgo+ICAgICAgICB0cmFmZmljLiAgSXQgc2hvdWxkIGluY2x1ZGUgYW4gYW5hbHlz aXMgb2Ygcmlza3MvdGhyZWF0cy9wb3NzaWJsZQo+ICAgICAgICBleHBsb2l0cyBhbmQgaG93IHRo ZXNlIGFyZSBtaXRpZ2F0ZWQgYnkgdGhlIHByb3RvY29sLiAgcmZjNjk1MiwKPiAgICAgICAgYW5k IHRoZSBwcm90b2NvbHMgaXQgcmVmZXJlbmNlcyBjYW4gc2VydmUgYXMgZXhhbXBsZXMuCj4KPiBN aW5vciBJc3N1ZXM6Cj4KPiAgICAgIC0gVGhlIGRhdGEgYW5kIHNpZ25hbCB0eXBlIGZpZWxkcyBh cmUgYm90aCA4IGJpdHMuICBUaGlzIHNlZW1zCj4gICAgICAgIHByZXR0eSBzbWFsbCwgcGFydGlj dWxhcmx5IHRoZSBkYXRhIHR5cGUgZmllbGQuICBHaXZlbiB0aGlzIGlzIGEKPiAgICAgICAgY29u dHJvbCBwcm90b2NvbCwgSSB0aGluayBhIGxhcmdlciAoYXQgbGVhc3QgZGF0YSB0eXBlKSBmaWVs ZAo+ICAgICAgICB3b3VsZCBwcm92aWRlIGJldHRlciAiZnV0dXJlIHByb29maW5nIi4KPgo+ICAg ICAgLSAyXjMyIHZlcnNpb25zIGFyZSBjdXJyZW50bHkgYWxsb3dlZCAoc2VjdGlvbiA4LjEpLiAg VGhpcyBzZWVtcyBhCj4gICAgICAgIGJpdCBleGNlc3NpdmUuICBJJ2Qgb3B0IGZvciBtYXggb2Yg OCBiaXRzIGhlcmUgbXlzZWxmLgo+Cj4gICAgICAtIEl0J3MgcHJvYmFibHkgdG9vIGxhdGUsIGJ1 dCBpdCBwcm9iYWJseSB3b3VsZCBiZSBjbGVhbmVyIHRvIGhhdmUgYQo+ICAgICAgICBnZW5lcmlj IGFjayBzaWduYWwgcmF0aGVyIHRoYW4gYSBwZXIgc2lnbmFsIHR5cGUgYWNrLiBJIG1lbnRpb24K PiAgICAgICAgdGhpcyBoZXJlIGFzIHRoaXMgbWF5IGNvbWUgdXAgYWdhaW4gd2hlbiBjbGFyaWZ5 aW5nIHRoZQo+ICAgICAgICB0cmFuc2FjdGlvbiBtb2RlbCAoYXMgbWVudGlvbmVkIGFib3ZlLikK Pgo+ICAgICAgLSBTZWN0aW9uIDI6IEFzc3VtcHRpb25zCj4gICAgICAgIFRoaXMgc2VjdGlvbiBp bmNsdWRlcyBpbmZvcm1hdGl2ZSBhbmQgbm9ybWF0aXZlIHRleHQgc28gaXMgbW9yZQo+ICAgICAg ICB0aGFuIGp1c3QgQXNzdW1wdGlvbnMuICBQZXJzb25hbGx5LCBJJ2QgcmVtb3ZlIGFsbCBub3Jt YXRpdmUgdGV4dAo+ICAgICAgICBmcm9tIHRoZSBzZWN0aW9uLgo+Cj4gICAgICAtIFRoZXJlIGFy ZSBubyBzcGVjaWZpYyBydWxlcyByZWxhdGVkIHRvIFVEUCBoZWFkZXIgZm9ybWF0aW9uLgo+Cj4g ICAgICAtIFNlY3Rpb25zIDguMTAtPjguMTcuICBJc24ndCBhZGQvZHJvcCBpbmRpY2F0b3IgbmVl ZGVkIGZvciBzdWJuZXRzCj4gICAgICAgIGluIGRlc3RpbmF0aW9uIHVwZGF0ZSBzaWduYWxzPwo+ Cj4gICAgICAtIFRoZSBJQU5BIENvbnNpZGVyYXRpb25zIHNlY3Rpb25zIG11c3QgZm9sbG934oCL IFJGQzIzNjAuCj4KPiAgICAgIC0gTmV3IHJlZ2lzdHJpZXMgbXVzdCBpbmNsdWRlIGluaXRpYWwg dmFsdWVzLCB3aGljaCBhcmUgZGVmaW5lZCBpbgo+ICAgICAgICB0aGUgZG9jdW1lbnQuICAoVGhl IGRvY3VtZW50IGN1cnJlbnRseSBoYXMgbWFueSBUQkRzIHRoYXQgc2hvdWxkCj4gICAgICAgIGJl IHJlcGxhY2VkLikKPgo+ICAgICAgLSBOZXcgcmVnaXN0cmllcyBuZWVkIGFuIGFsbG9jYXRpb24g cG9saWN5LCBlLmcuOgo+ICAgICAgVGhlIHJlZ2lzdHJ5IHNob3VsZCBiZSBlc3RhYmxpc2hlZCB3 aXRoIHJlZ2lzdHJhdGlvbiBwb2xpY2llcyBvZgo+ICAgICAgIlN0YW5kYXJkcyBBY3Rpb24iIChm b3IgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50cykgYW5kCj4gICAgICDigJxTcGVjaWZpY2F0aW9u IFJlcXVpcmVkIiAoZm9yIG90aGVyIGRvY3VtZW50cykuIFRoZSBkZXNpZ25hdGVkCj4gICAgICBl eHBlcnQgaXMgYW55IGN1cnJlbnQgPGZpbGwtaW4+IFdHIGNoYWlyLgo+Cj4gTml0czoKPgo+ICAg ICAgLSBUaGUgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgdGVybXMgInNpZ25hbHMiIGFuZCAiZGF0 YSBpdGVtcyIgZm9yCj4gICAgICAgIHdoYXQgaXMgY29tbW9ubHkgY2FsbGVkICJtZXNzYWdlcyIg YW5kICJUTFZzIiAob3Igb2JqZWN0cykgaW4KPiAgICAgICAgb3RoZXIgcHJvdG9jb2xzLiAgSXQn cyBwcm9iYWJseSB0b28gbGF0ZSB0byBjaGFuZ2UgdGhpcywgYnV0IEkKPiAgICAgICAgdGhpbmsg dGhlIGludHJvZHVjdGlvbiBvZiB1bmlxdWUgdGVybWlub2xvZ3kgaXMgY291bnRlcgo+ICAgICAg ICBwcm9kdWN0aXZlLgo+Cj4gICAgICAtIFVzZSBvZiBSRkMgMjExOSBjb25mb3JtYW5jZSBsYW5n dWFnZSBpcyBhIGJpdCByb3VnaCwgYW5kIHRoZXJlIGFyZQo+ICAgICAgICB3b3JkcyBpbiBhbGwg Y2FwcyB0aGF0IGFyZSBub3QgZGVmaW5lZCBpbiBSRkMyMTE5LiBUYWtlIGEgbG9vayBhdAo+ICAg ICAgICBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy90ZWFzL3RyYWMvd2lraS9QU0d1aWRl bGluZSBmb3Igc29tZQo+ICAgICAgICBzdWdnZXN0aW9ucy4KPgo+ICAgICAgLSBJbnRlcm5hbCBz b2NrZXQgb3BlcmF0aW9uIGlzIG1lbnRpb25lZCBhIGNvdXBsZSBvZiB0aW1lcy4gIEl0Cj4gICAg ICAgIHJlYWxseSBzaG91bGRuJ3QgYmUsIHRoZSBzcGVjIHNob3VsZCBkZWZpbmUgYmVoYXZpb3Ig b24gdGhlIHdpcmUuCj4KPiAgICAgIC0gVGhlIExlbmd0aCBmaWVsZHMgYXJlIG1pc3NpbmcgdW5p dCBvZiBtZWFzdXJlIChwcmVzdW1hYmx5IG9jdGV0cykKPgo+ICAgICAgLSBUaGUgTW5lbW9uaWNz IGFyZSB1c2VkIGJhc2ljYWxseSBvbmNlIGFuZCBkb24ndCByZWFsbHkgYWRkIHZhbHVlLAo+ICAg ICAgICBzdWdnZXN0IGRyb3BwaW5nIHRoZW0uCj4KPiAgICAgIC0gSG93L3doZW4gaXMgdGhlICJV bmtub3duIFNpZ25hbCIgU3RhdHVzIENvZGUgc2VudD8KPgo+ICAgICAgLSBTZWN0aW9uIDguNzog RXh0ZW5zaW9uIExpc3Qgc2hvdWxkIGJlIHNob3duIGFzIGEgdmFyaWFibGUgbGVuZ3RoCj4gICAg ICAgIGZpZWxkLgo+Cj4gICAgICAtIFNlY3Rpb24gOC44OiBFeHBlcmltZW50IExpc3Qgc2hvdWxk IGJlIHNob3duIGFzIGEgdmFyaWFibGUgbGVuZ3RoCj4gICAgICAgIGZpZWxkLgo+Cj4gVGhhdCdz IGl0IC0tIGZvciBub3cgLS0gaG9wZWZ1bGx5IEkgZGlkbid0IG1pc3MgYW55dGhpbmcuICBMb29r IGZvcndhcmQgdG8gaGVhcmluZyByZXNwb25zZSB0byB0aGUgYWJvdmUgKGFuZCBob3cgSSBnb3Qg dGhpbmdzIGhvcGVsZXNzbHkgd3JvbmcgOy0pCj4KPiBMb3UKPgo+Cj4KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG1hbmV0IG1haWxpbmcgbGlzdAo+ IG1hbmV0QGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t YW5ldAo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqCj4gVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCj4gcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKPiByZWNpcGllbnQgcGxlYXNl IGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KPiBZb3Ug c2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3Nl IG9yCj4gZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4KPiAqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4gbWFuZXQgbWFpbGluZyBsaXN0Cj4gbWFuZXRAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0Cj4KCg== From nobody Tue Jun 16 04:26:00 2015 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 3AE381B325C; Tue, 16 Jun 2015 04:25:58 -0700 (PDT) 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, HTML_NONELEMENT_30_40=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 pZC1aDzXUMLp; Tue, 16 Jun 2015 04:25:52 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (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 A70021B32A1; Tue, 16 Jun 2015 04:25:14 -0700 (PDT) Received: by yhan67 with SMTP id n67so8858183yha.3; Tue, 16 Jun 2015 04:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:importance:from:to:cc:mime-version :content-type; bh=Jt970shOvuOy8H1PXnoQ8DuDcIC5Du84uVy+8kaNH0A=; b=A4atTkZHEj8AMW5GXT//RL4BBzgYp2xEh3lg+3qUfAkGZ9vXIx3ZuxVIt757hIKJEQ QCK7cjfl1dlrseRuaelKyXQNytLfJ273/JD0xJJFhSse48CHs87QeV8oS26BYUlvgAyN Ub2Z055mjaExVF8vaUlKq08yZoYhWsqQX8mKcgA3+hhz8Ol/QovVSa1tf4aGj61gqV0I 2VxGWfjOPutcwcs8XBN6ygfJn0f1hBt5jAgY5yQadSkad6cFNtZKu1NGeqTi3+3X5wYS OOabMqvrXP/sbgo9zOKVxq7c2d3CrA+3AvGQAR5mriH3df9QzjwF2cxMkFOfiINV053w jH9w== X-Received: by 10.129.107.194 with SMTP id g185mr40105377ywc.101.1434453913892; Tue, 16 Jun 2015 04:25:13 -0700 (PDT) Received: from [192.168.1.8] (pool-108-31-103-54.washdc.fios.verizon.net. [108.31.103.54]) by mx.google.com with ESMTPSA id t66sm451523ywa.9.2015.06.16.04.25.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jun 2015 04:25:12 -0700 (PDT) Date: Tue, 16 Jun 2015 07:25:10 -0400 Message-ID: Importance: normal From: bebemaster To: Rick Taylor , "Dearlove, Christopher (UK)" , Lou Berger , "manet-chairs@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_828683350181360" Archived-At: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , "manet@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 11:25:58 -0000 ----_com.android.email_828683350181360 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SXQgd291bGQgYmUgYXBwcm9wcmlhdGUgdG8gaGF2ZSBzb21lIG9mIHRoYXQgZGlzY3Vzc2lvbiBv biB0aGUgbGlzdC4gVGhlcmUgaXMgcXVpdGUgYSBsb3Qgb2YgaW50ZXJlc3QgaW4gdGhpcyBkcmFm dCB3aXRoaW4gdGhlIHdnIGFuZCBnZXR0aW5nIGlucHV0IG9uIGJlc3Qgd2F5cyBmb3J3YXJkIG9u IHRoZSB2YXJpb3VzIGZpeGVzIGJlZm9yZSB0aGV5IGFyZSB3cml0dGVuIHVwIHNob3VsZCBlbmQg dXAgc2F2aW5nIHRpbWUuCgpKdXN0aW4KCjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAt LS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogUmljayBUYXlsb3IgPHJpY2tAdHJvcGljYWxzdG9ybXNv ZnR3YXJlLmNvbT4gPC9kaXY+PGRpdj5EYXRlOjA2LzE2LzIwMTUgIDU6MDAgQU0gIChHTVQtMDU6 MDApIDwvZGl2PjxkaXY+VG86ICJEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSIgPGNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tPiwgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4sIG1h bmV0LWNoYWlyc0BpZXRmLm9yZyA8L2Rpdj48ZGl2PkNjOiBtYW5ldC1hZHNAaWV0Zi5vcmcsIHJ0 Zy1kaXJAaWV0Zi5vcmcsIG1hbmV0QGlldGYub3JnLCBkcmFmdC1pZXRmLW1hbmV0LWRsZXAuYWxs QGlldGYub3JnIDwvZGl2PjxkaXY+U3ViamVjdDogUmU6IFttYW5ldF0gUnRnRGlyIHJldmlldzog ZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLTE0IDwvZGl2PjxkaXY+CjwvZGl2PkFsbCwKClN0YW4gYW5k IEkgYXJlIGN1cnJlbnRseSBkaXNjdXNzaW5nIHRoZSByZXZpZXcuICBXZSB3aWxsIGNvbWUgYmFj ayB0byAKdGhlIGxpc3Qgd2l0aCBhIHByb3Bvc2VkIHNldCBvZiBhY3Rpb25zIHdoZW4gd2UgaGF2 ZSBhIHBsYW4uCgpTb3JyeSBmb3IgdGhlIGRlbGF5LAoKUmljawoKCk9uIDE1LzA2LzE1IDEyOjE2 LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSB3cm90ZToKPiBJIGhhdmVuJ3Qgc2VlbiBhbnkg ZGlzY3Vzc2lvbiBvZiB0aGlzLiBJdCBsb29rcyB0byBtZSBsaWtlIHJlcXVpcmluZyBhbm90aGVy IGRyYWZ0IGZvciB0aGUgV0cgdG8gc2VlLiBJdCBkb2VzIChieSBteSByYXBpZCBjb3VudCkgaGF2 ZSAxNyBtYWpvciBpc3N1ZXMuCj4KPiAtLQo+IENocmlzdG9waGVyIERlYXJsb3ZlCj4gU2VuaW9y IFByaW5jaXBhbCBFbmdpbmVlcgo+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPgo+IFQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlz LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tCj4KPiBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9y ZCwgRXNzZXggQ00yIDhITi4KPiB3d3cuYmFlc3lzdGVtcy5jb20vYWkKPiBCQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkCj4gUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2Fs ZXMgTm86IDAxMzM3NDUxCj4gUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJr LCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUAo+Cj4KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQo+IEZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIExvdSBCZXJnZXIKPiBTZW50OiAwOCBKdW5lIDIwMTUgMjA6MTEKPiBUbzogbWFuZXQt Y2hhaXJzQGlldGYub3JnCj4gQ2M6IG1hbmV0LWFkc0BpZXRmLm9yZzsgcnRnLWRpckBpZXRmLm9y ZzsgbWFuZXRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC5hbGxAaWV0Zi5vcmcKPiBT dWJqZWN0OiBbbWFuZXRdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC0xNAo+ Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24s IGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuCj4g Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3Ms IG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lgo+IEZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNw aWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVw b3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+IFtOb3RlIHRoaXMgaXMgYSBX RyBMQyByZWxhdGVkIHJldmlldywgbm90IElFVEYgTEMuXQo+Cj4gSGVsbG8sCj4KPiBJIGhhdmUg YmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhp cyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0 aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBs YXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVz dCAtLSBvciBXRyBMYXN0IGNhbGwgYXMgd2FzIHRoZSBjYXNlIGhlcmUgLiBUaGUgcHVycG9zZSBv ZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMu IEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVh c2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9S dGdEaXIKPgo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIChjaGFpcnMgYW5kKSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBp ZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwg Y29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhy b3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4KPgo+IERvY3VtZW50OiBk cmFmdC1pZXRmLW1hbmV0LWRsZXAtMTQKPiBSZXZpZXdlcjogTG91IEJlcmdlcgo+IFJldmlldyBE YXRlOiBKdW5lIDggKGxhdGVyIHRoYW4gcmVxdWVzdGVkIGR1ZSB0byBzY29wZSBvZiBjb21tZW50 cyAtLSBzb3JyeSkgV0cgTEMgRW5kIERhdGU6IHVua25vd24gSW50ZW5kZWQgU3RhdHVzOiBTdGFu ZGFyZHMgdHJhY2sKPgo+IFN1bW1hcnk6Cj4KPiAgICAgIFdoaWxlIEkgdGhpbmsgdGhlIGRvY3Vt ZW50IGlzIHByZXR0eSBkZWNlbnQgZm9yIHRoZSBzY29wZSBvZiB0aGUKPiAgICAgIHdvcmssIEkg ZG8gaGF2ZSBjb25jZXJucyBhYm91dCB0aGlzIGRvY3VtZW50IGFuZCByZWNvbW1lbmQgdGhhdCB0 aGUKPiAgICAgIFdHIENoYWlycy9Sb3V0aW5nIEFEcyBkaXNjdXNzIHRoZXNlIGlzc3VlcyBmdXJ0 aGVyIHdpdGggdGhlIGF1dGhvcnMuCj4gICAgICBJJ20gYWxzbyBhdmFpbGFibGUgYXMvaWYgbmVl ZGVkIHRvIGRpc2N1c3MuCj4KPiBDb21tZW50czoKPgo+ICAgICAgSSB0aGluayB0aGUgZG9jdW1l bnQgc2hvd3Mgc2lnbmlmaWNhbnQgZ29vZCB3b3JrIGFuZCBsb29rcyB0byBiZSBhCj4gICAgICB1 c2VmdWwgcHJvdG9jb2wsIGFsdGhvdWdoIEknbSBub3Qgb3Zlcmx5IGZhbWlsaWFyIGluIHRoaXMg c3BhY2UuCj4gICAgICBUaGF0IHNhaWQsIEkgaGF2ZSBhIG51bWJlciBvZiBzZXJpb3VzIGNvbmNl cm5zIGFib3V0IHRoZSBkb2N1bWVudCwKPiAgICAgIGFuZCBpdHMgY29udGVudHMgZnJvbSBhIGZl dyBvZiBwZXJzcGVjdGl2ZXMuICBUaGVzZSBpbmNsdWRlIGJhc2ljCj4gICAgICBwcm90b2NvbCBp c3N1ZXMsIHVuZGVyc3BlY2lmaWVkIGRldGFpbHMgICh3aGljaCBjb3VsZCBsZWFkIHRvCj4gICAg ICBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyksIGFuZCBzcGVjaWZpY2F0aW9uL2VkaXRvcmlhbCBp c3N1ZXMuIEkKPiAgICAgIHRoaW5rIHRoZSBkb2N1bWVudCAvIHByb3RvY29sIGNhbiBiZSBtb2Rp ZmllZCB0byBhZGRyZXNzIHRoZSBpc3N1ZXMKPiAgICAgIEkgcmFpc2UgYmVsb3cuICBPZiBjb3Vy c2UsIGl0IGlzIHVwIHRvIHRoZSBXRywgY2hhaXJzLCBhbmQgQURzIHRvCj4gICAgICBkZWNpZGUg d2hpY2ggY29tbWVudHMgdG8gYWRkcmVzcyBhbmQgd2hpY2ggdG8gIGlnbm9yZS4KPiAgICAgIEkg ZG9uJ3QgZXhwZWN0IHRoYXQgYWxsIGNvbW1lbnRzIHdpbGwgcmVzdWx0IGluIGNoYW5nZXMuCj4K PiBNYWpvciBJc3N1ZXM6Cj4KPiAgICAgIC0gVGhlIGxlbmd0aCBmaWVsZCBvZiB0aGUgZ2VuZXJp YyBkYXRhIGl0ZW0gKGkuZS4sIFRMVikgaXMgb25seSA4Cj4gICAgICAgIGJpdHMuICBXaGlsZSAy NTUgYnl0ZXMgKGFzc3VtaW5nIHRoYXQgdGhpcyBpcyB0aGUgdW5pdCBvZiBtZWFzdXJlLAo+ICAg ICAgICB3aGljaCBCVFcgaXNuJ3Qgc3BlY2lmaWVkKSBpcyBiaWcgZW5vdWdoIHRvZGF5LCBhbGxv d2luZyBmb3IKPiAgICAgICAgbGFyZ2VyIHdpbGwgZ3JlYXRseSBzaW1wbGlmeSB0aGluZ3Mgd2hl biAyNTUgaXNuJ3QgZW5vdWdoLiAtLQo+ICAgICAgICBXZSd2ZSBydW4gaW50byB0aGlzIGluIFJT VlAgYW5kIGl0J3MgYSByZWFsIHBhaW4uCj4KPiAgICAgIC0gVmVyc2lvbiBudW1iZXIgaXMgY3Vy cmVudGx5IGRlZmluZWQgYXMgYSBkYXRhIGl0ZW0uICBUaGlzIG1lYW5zIGEKPiAgICAgICAgc2ln bmFsIChpLmUuLCBtZXNzYWdlKSBuZWVkcyB0byBiZSBwb3RlbnRpYWxseSBmdWxseSBwYXJzZWQg dG8KPiAgICAgICAgZGlzY292ZXIgd2hhdCB2ZXJzaW9uIGlzIGJlaW5nIHVzZWQuICBUaGlzIHBy ZWNsdWRlcyBiYXNpYyBmb3JtYXQKPiAgICAgICAgY2hhbmdlcyB0byB0aGUgcHJvdG9jb2wuICBQ ZXJoYXBzIHRoZSBEaXNjb3ZlcnkgYW5kIEluaXQgU2lnbmFscwo+ICAgICAgICBzaG91bGQgYmUg c3BlY2lhbCBjYXNlZCB0byBpbmNsdWRlIHZlcnNpb24gaW4gdGhlaXIgZm9ybWF0cy4gIChBbmQK PiAgICAgICAgc2hvcnRlbiB2ZXJzaW9uIHRvIDggYml0cyBmcm9tIDMyLCBhcyBtZW50aW9uZWQg YmVsb3cpLgo+Cj4gICAgICAtIFRoZSBkb2N1bWVudCByZWZlcmVuY2VzLCBidXQgZG9lcyBub3Qg ZGVmaW5lLCAnaW4tc2Vzc2lvbicgYW5kCj4gICAgICAgICdkaXNjb3ZlcnknIHN0YXRlcy4gIFRo ZXNlIGVpdGhlciBuZWVkIHRvIGJlIGZvcm1hbGx5IGRlZmluZWQgb3IKPiAgICAgICAgcmVtb3Zl ZC4gIEJUVyB3ZSBoYWQgZXhhY3RseSB0aGUgc2FtZSBpc3N1ZSB3aXRoIExNUCAoUkZDNDIwNCkg YW5kCj4gICAgICAgIGVuZGVkIHVwIGFkZGluZyBzZWN0aW9uIDExIChGU01zKSBhdCBhIHByZXR0 eSBsYXRlIHN0YWdlIG9mIHRoZQo+ICAgICAgICBwcm9jZXNzLgo+Cj4gICAgICAtIFRDUCBzZXNz aW9uIG1hbmFnZW1lbnQgaXMgbm90IGRlZmluZWQsIG5vciBpcyB0aGUgcmVsYXRpb25zaGlwCj4g ICAgICAgIHdpdGggVENQIGFuZCBETEVQIHNlc3Npb25zIGZ1bGx5IGRlZmluZWQuICBGb3IgZXhh bXBsZToKPgo+ICAgICAgICBvIENsb3NpbmcgdGhlIFRDUCBzZXNzaW9uIGlzIG9ubHkgbWVudGlv bmVkIGluIG9uZSBwbGFjZSBhbmQgaW4gYQo+ICAgICAgICAgIHdheSB0aGF0IGlzIGluY29uc2lz dGVudCB3aXRoIHRoZSBleHBlY3RlZCBwcm90b2NvbCBiZWhhdmlvcgo+ICAgICAgICAgIChjbG9z ZSBUQ1AgYmVmb3JlIEFDSyBpcyByZWNlaXZlZCkuCj4KPiAgICAgICAgbyBXaGF0IGhhcHBlbnMg d2hlbiBhIERMRVAgc2Vzc2lvbiBpcyB0ZXJtaW5hdGVkLCBjYW4gdGhlIFRDUAo+ICAgICAgICAg IHNlc3Npb24gYmUgcmV1c2VkIG9yIG11c3QgaXQgYmUgY2xvc2VkIHRvbz8KPgo+ICAgICAgLSBU aGVyZSBpcyBubyB0cmFuc2FjdGlvbiBtb2RlbCBkZWZpbmVkLiAgRm9yIGV4YW1wbGUsIGl0J3MK PiAgICAgICAgY29tcGxldGVseSB1bmNsZWFyIGlmIG9ubHkgb25lIHVuYWNrbm93bGVkZ2VkIFNp Z25hbCBhbGxvd2VkIGF0IGEKPiAgICAgICAgdGltZSwgb3IgcGVyaGFwcyBqdXN0IG9uZSBwZXIg c2lnbmFsIHR5cGUgaXMgYWxsb3dlZCwgb3IgcGVyaGFwcwo+ICAgICAgICB0aGVyZSBhcmUgbm8g cmVzdHJpY3Rpb25zLiAgVGhpcyBuZWVkcyB0byBiZSBleHBsaWNpdC4KPgo+ICAgICAgLSBXaGF0 IGlzIHRoZSBwdXJwb3NlIG9mIHJldHJpZXMgYW5kIHRpbWVvdXRzIG92ZXIgVENQPyAgUmV0cmll cwo+ICAgICAgICBhcmVuJ3QgbmVlZGVkIG92ZXIgVENQcyBhbmQgaXQncyB1bmNsZWFyIHdoZXkg dGhleSBhcmUgYmVpbmcgdXNlZC4KPgo+ICAgICAgLSBUaGUgaGlnaGVyIGxldmVsIGltcGxpY2F0 aW9ucyBvZiBBQ0tzLCBvdmVyIFRDUCwgaXNuJ3QgcmVhbGx5Cj4gICAgICAgIGNsZWFyLiAgSXQg c2VlbXMgQUNLcyBhcmUgZGVmaW5lZCBmb3IgbXVsdGlwbGUgcHVycG9zZXM6IHJlbGlhYmxlCj4g ICAgICAgIHRyYW5zcG9ydCwgdHJhbnNhY3Rpb24gYWNrbm93bGVkZ21lbnQgYW5kIHRyYW5zYWN0 aW9uIHJlc3VsdHMuIE9mCj4gICAgICAgIGNvdXJzZSB0aGUgZmlyc3QgaXNuJ3QgbmVlZGVkLCBh bmQgaW1wbGljYXRpb25zIG9mIHRoZSBvdGhlcnMKPiAgICAgICAgc2hvdWxkIGJlIGNsZWFyLiAg Rm9yIGV4YW1wbGUsIGluIHNlY3Rpb24gNy4xMCwgd2h5IHdvdWxkIHRoZXJlIGJlCj4gICAgICAg IGEgcmV0cnkgd2hlbiByZWNlaXZpbmcgYSBEZXN0aW5hdGlvbiBVcCBBQ0sgc2lnbmFsIGluZGlj YXRpbmcgYW4KPiAgICAgICAgZXJyb3I/Cj4KPiAgICAgIC0gVGhlcmUgaXMgbm8gZGlzY3Vzc2lv biBvbiBzY2FsaW5nIGNvbnNpZGVyYXRpb25zLiBBcmUgdGhlcmUgcmVhbGx5Cj4gICAgICAgIG5v bmU/ICBGb3IgZXhhbXBsZSwgaG93IG9mdGVuIG1pZ2h0IGJlIGFwcHJvcHJpYXRlIHRvIGlzc3Vl L2xpbWl0Cj4gICAgICAgIFBlZXIgVXBkYXRlcyBiYXNlZCB0byBjaGFuZ2VzIGluIGxpbmsgcXVh bGl0eSwgb3IgaG93IHRvIGhhbmRsZQo+ICAgICAgICB0aGUgY2FzZSB3aGVyZSBhIGxhcmdlIG51 bWJlciAoYWxsIG9yIG1vc3QpIG9mIGRlc3RpbmF0aW9ucyBnbwo+ICAgICAgICBkb3duLgo+Cj4g ICAgICAtIFRoZXJlIGFyZSAxMyBwbGFjZXMgd2hlcmUgdGhlIHByb3RvY29sIGFsbG93cyBpbXBs ZW1lbnRhdGlvbiB0bwo+ICAgICAgICBkZWZpbmUgdGhlaXIgb3duICdoZXVyaXN0aWNzJy4gIFNv bWUgb2YgdGhlc2Ugc2VlbSB1bm5lY2Vzc2FyeSBkdWUKPiAgICAgICAgdG8gdGhlIFRDUCBwb2lu dCByYWlzZWQgYWJvdmUsIGJ1dCBhbnkgdGhhdCByZW1haW4gaW4gdGhlIHByb3RvY29sCj4gICAg ICAgIHNob3VsZCBiZSBmdWxseSBzcGVjaWZpZWQgdG8gZW5zdXJlIHByZWRpY3RhYmxlL2NvbnNp c3RlbnQKPiAgICAgICAgYmVoYXZpb3IgZnJvbSBpbXBsZW1lbnRhdGlvbnMuCj4KPiAgICAgIC0g RGF0YSBJdGVtcyBhcmUgZGVmaW5lZCBmb3IgIkV4dGVuc2lvbnMiIGFuZCAiRXhwZXJpbWVudGFs Cj4gICAgICAgIERlZmluaXRpb24iIChTZWN0aW9ucyA4LjcgYW5kIDguOCkuICBCb3RoIHNlZW0g dG8gc3VwcG9ydCBmb3IKPiAgICAgICAgb3B0aW9uYWwgbWVjaGFuaXNtcywgYnV0IHRoZSBmb3Jt ZXIgdXNlcyBhc3NpZ25lZCBudW1lcmljIHZhbHVlcywKPiAgICAgICAgd2h5IHRoZSBsYXR0ZXIg dXNlcyBVVEYtOCBzdHJpbmdzLgo+ICAgICAgICBvIFdoYXQsIGlmIGFueSwgaXMgdGhlIGludGVu ZGVkIGRpc3RpbmN0aW9uL3JlbGF0aW9uc2hpcCBiZXR3ZWVuCj4gICAgICAgICAgdGhlc2U/Cj4g ICAgICAgIG8gSG93IGRvZXMgYW4gIkV4cGVyaW1lbnRhbCBEZWZpbml0aW9uIiBiZWNvbWUgc3Rh bmRhcmRpemVkPwo+Cj4gICAgICAtIFNlY3Rpb25zIDguMTkgYW5kIDguMjAgZGVmaW5lICJSZXNv dXJjZXMiIHJlbGF0ZWQgRGF0YSBJdGVtcy4gIFRoZQo+ICAgICAgICBkZWZpbml0aW9uIHJlbGF0 ZWQgdG8gdGhlc2UgYmFzaWNhbGx5IHNheXMgYSByZXNvdXJjZXMgaXMgIkFuCj4gICAgICAgIDgt Yml0IGludGVnZXIgcGVyY2VudGFnZSwgMC0xMDAsIHJlcHJlc2VudGluZyB0aGUgYW1vdW50IG9m Cj4gICAgICAgIHJlc291cmNlcyBhbGxvY2F0ZWQgdG8gcmVjZWl2aW5nfHRyYW5zbWl0dGluZyBk YXRhLiIuICBJZiBJIHdlcmUKPiAgICAgICAgaW1wbGVtZW50aW5nIHRoaXMgcHJvdG9jb2wsIEkn ZCBoYXZlIG5vIGlkZWEgaG93IHRvIHByb2R1Y2UsCj4gICAgICAgIHVwZGF0ZSBvciB1c2UgdGhp cyBpbmZvcm1hdGlvbi4gIEkgdGhpbmsgdGhlcmUgaXMgc29tZSBtaXNzaW5nCj4gICAgICAgIGlu Zm9ybWF0aXZlIGFuZCBub3JtYXRpdmUgKFJGQyAyMTE5KSB0ZXh0IHJlbGF0ZWQgdG8gdGhlc2UK PiAgICAgICAgZm9ybWF0cy4KPgo+ICAgICAgLSBTZWN0aW9ucyA4LjIxIGFuZCA4LjIyIChSZWxh dGl2ZSBMaW5rIFF1YWxpdHkpIGhhdmUgYSBzaW1pbGFyCj4gICAgICAgIHByb2JsZW0gb2YgYmVp bmcgdW5kZXIgZGVzY3JpYmVkLCBpbiBwYXJ0aWN1bGFyIGl0J3MgdW5jbGVhciBpZgo+ICAgICAg ICB0aGVyZSdzIGEgbWVhbmluZ2Z1bCwgbm9uLXByb3ByaWV0YXJ5IGRlZmluaXRpb24gZm9yIGxp bmsgcXVhbGl0eQo+ICAgICAgICB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGlzIHRvIGFjdCBvbiBv ciBpZiB0aGUgcGFzc2VkIHZhbHVlIGlzIGp1c3QKPiAgICAgICAgcGFzc2VkIGZvciBhcyBtb25p dG9yaW5nIGluZm9ybWF0aW9uLiAgRWl0aGVyIHdheSwgdGhpcyBuZWVkcyB0bwo+ICAgICAgICBi ZSBjbGFyaWZpZWQuCj4KPiAgICAgIC0gU2VjdGlvbiA5IGRlZmluZXMgYSAiY3JlZGl0LXdpbmRv d2luZyBzY2hlbWUgYW5hbG9nb3VzIHRvIHRoZSBvbmUKPiAgICAgICAgZG9jdW1lbnRlZCBpbiBb UkZDNTU3OF0iLiBJdCBkZXNjcmliZXMgaG93IGNyZWRpdHMgYXJlIGV4Y2hhbmdlZCwKPiAgICAg ICAgYnV0IGl0IHByb3ZpZGVzIHplcm8gZGVmaW5pdGlvbiBvbiB0aGUgaW1wbGljYXRpb25zIG9y IHVzZSBvZgo+ICAgICAgICBjcmVkaXRzIHJlbGF0aXZlIHRvIHRoZSBkYXRhIHBsYW5lLgo+Cj4g ICAgICAtIE11bHRpcGxlIHdheXMgdG8gaW1wbGVtZW50IHRoZSBzYW1lIGZ1bmN0aW9uIGFyZSBh bGxvd2VkLCBlLmcuLAo+ICAgICAgICBvcHRpb25hbCBwcmVzZW5jZSBvZiBTdGF0dXMsIEludGVy dmFsIGFuZCBUQ1AgcG9ydC4gIEdlbmVyYWxseQo+ICAgICAgICBhbGxvd2luZyBzdWNoIGNvbXBs aWNhdGVzIHRlc3RpbmcgYW5kIGxlYWRzIHRvIGludGVyb3BlcmFiaWxpdHkKPiAgICAgICAgaXNz dWVzLiAgVGhlIGRvY3VtZW50IHNob3VsZCBwaWNrIG9uZSB3YXkgYW5kIHJlcXVpcmUgaXQuCj4K PiAgICAgIC0gVGhlIGRvY3VtZW50IGRvZXNuJ3Qgc3RhdGUgaWYgdGhlcmUgYXJlIGFueSBvcmRl cmluZyByZXF1aXJlbWVudHMKPiAgICAgICAgb24gZGF0YSBpdGVtcy4gSXQgc2hvdWxkIGJlIGV4 cGxpY2l0IG9uIHRoaXMsIGUuZy4sIHRoZXJlIGFyZSBubwo+ICAgICAgICBvcmRlcmluZyByZXF1 aXJlbWVudHMgb24gdGhlIHBsYWNlbWVudCBvZiBEYXRhIEl0ZW1zIHdpdGhpbgo+ICAgICAgICBT aWduYWxzLgo+Cj4gICAgICAtIFRoZSByZXF1aXJlZCBhbmQgb3B0aW9uYWwgZGF0YSBpdGVtcyB0 aGF0IGFyZSBwZXJtaXR0ZWQgb24gYQo+ICAgICAgICBzaWduYWwgaXNuJ3QgYWx3YXlzIGNsZWFy LiAgRm9yIGV4YW1wbGUgYXJlIDAvMS9OIGNvcGllcyBvZiBhCj4gICAgICAgIHBhcnRpY3VsYXIg RGF0YSBJdGVtIHJlcXVpcmVkL2FsbG93ZWQuICBVc2luZyBzb21ldGhpbmcgbGlrZSBBQk5GCj4g ICAgICAgIHdvdWxkIHJlYWxseSBoZWxwIGZvcm1hbGl6ZSBhbmQgY2xhcmlmeSB0aGlzLgo+Cj4g ICAgICAtIFRoZSBkb2N1bWVudCBkb2Vzbid0IGNsZWFybHkgZGVsaW5lYXRlIGZyb20gaW5mb3Jt YXRpdmUvbmFycmF0aXZlCj4gICAgICAgIHRleHQsIG5vcm1hdGl2ZSAvIHJlcXVpcmVkIHByb2Nl c3NpbmcgcHJvY2VkdXJlcywgYW5kIG1lc3NhZ2UKPiAgICAgICAgZm9ybWF0cy4gVGhpcyBieSBp dHNlbGYgaXMgbm90IG5lY2Vzc2FyaWx5IGEgbWFqb3IgaXNzdWUsIGl0IGp1c3QKPiAgICAgICAg bWFrZXMgaXQgaGFyZGVyIHRvICh3cml0ZSwpIHJldmlldyBhbmQgaW1wbGVtZW50IHRoZSBwcm90 b2NvbC4KPiAgICAgICAgV2hhdCBpcyBhIG1ham9yIGlzc3VlIGlzIHRoYXQgdGhpcyBhcHByb2Fj aCBhbGxvd3MgZm9yIGR1cGxpY2F0ZQo+ICAgICAgICAoYW5kIHNvbWV0aW1lcyBjb250cmFkaWN0 b3J5KSBub3JtYXRpdmUgcHJvY2VkdXJlcyBhbmQgZm9yCj4gICAgICAgIG9taXNzaW9ucyBpbiBw cm9jZWR1cmVzIChwYXJ0aWN1bGFybHkgcmVsYXRlZCB0byBleGNlcHRpb24vZXJyb3IKPiAgICAg ICAgcHJvY2Vzc2luZykuICBTcGVjaWZpYyBleGFtcGxlcyBhcmUgaW5jbHVkZWQgYWJvdmUgYW5k IGJlbG93LiAgSXQKPiAgICAgICAgd291bGQgYmUgYmVzdCB0byBlbnN1cmUgdGhhdCBlYWNoIHJl cXVpcmVkIHByb2Nlc3NpbmcgYmVoYXZpb3IgaXMKPiAgICAgICAgZGVmaW5lZCBqdXN0IG9uY2Ug YW5kIGluIGEgY29uc2lzdGVudCB3YXkuCj4KPiAgICAgIC0gVGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb24gc2VjdGlvbiBpcyBpbmFkZXF1YXRlLiAgVGhpcyBzZWN0aW9uCj4gICAgICAgIHNob3Vs ZCBhZGRyZXNzIHRoZSBzZWN1cml0eSBvZiB0aGUgRExFUCBwcm90b2NvbCwgbm90IHVzZXIKPiAg ICAgICAgdHJhZmZpYy4gIEl0IHNob3VsZCBpbmNsdWRlIGFuIGFuYWx5c2lzIG9mIHJpc2tzL3Ro cmVhdHMvcG9zc2libGUKPiAgICAgICAgZXhwbG9pdHMgYW5kIGhvdyB0aGVzZSBhcmUgbWl0aWdh dGVkIGJ5IHRoZSBwcm90b2NvbC4gIHJmYzY5NTIsCj4gICAgICAgIGFuZCB0aGUgcHJvdG9jb2xz IGl0IHJlZmVyZW5jZXMgY2FuIHNlcnZlIGFzIGV4YW1wbGVzLgo+Cj4gTWlub3IgSXNzdWVzOgo+ Cj4gICAgICAtIFRoZSBkYXRhIGFuZCBzaWduYWwgdHlwZSBmaWVsZHMgYXJlIGJvdGggOCBiaXRz LiAgVGhpcyBzZWVtcwo+ICAgICAgICBwcmV0dHkgc21hbGwsIHBhcnRpY3VsYXJseSB0aGUgZGF0 YSB0eXBlIGZpZWxkLiAgR2l2ZW4gdGhpcyBpcyBhCj4gICAgICAgIGNvbnRyb2wgcHJvdG9jb2ws IEkgdGhpbmsgYSBsYXJnZXIgKGF0IGxlYXN0IGRhdGEgdHlwZSkgZmllbGQKPiAgICAgICAgd291 bGQgcHJvdmlkZSBiZXR0ZXIgImZ1dHVyZSBwcm9vZmluZyIuCj4KPiAgICAgIC0gMl4zMiB2ZXJz aW9ucyBhcmUgY3VycmVudGx5IGFsbG93ZWQgKHNlY3Rpb24gOC4xKS4gIFRoaXMgc2VlbXMgYQo+ ICAgICAgICBiaXQgZXhjZXNzaXZlLiAgSSdkIG9wdCBmb3IgbWF4IG9mIDggYml0cyBoZXJlIG15 c2VsZi4KPgo+ICAgICAgLSBJdCdzIHByb2JhYmx5IHRvbyBsYXRlLCBidXQgaXQgcHJvYmFibHkg d291bGQgYmUgY2xlYW5lciB0byBoYXZlIGEKPiAgICAgICAgZ2VuZXJpYyBhY2sgc2lnbmFsIHJh dGhlciB0aGFuIGEgcGVyIHNpZ25hbCB0eXBlIGFjay4gSSBtZW50aW9uCj4gICAgICAgIHRoaXMg aGVyZSBhcyB0aGlzIG1heSBjb21lIHVwIGFnYWluIHdoZW4gY2xhcmlmeWluZyB0aGUKPiAgICAg ICAgdHJhbnNhY3Rpb24gbW9kZWwgKGFzIG1lbnRpb25lZCBhYm92ZS4pCj4KPiAgICAgIC0gU2Vj dGlvbiAyOiBBc3N1bXB0aW9ucwo+ICAgICAgICBUaGlzIHNlY3Rpb24gaW5jbHVkZXMgaW5mb3Jt YXRpdmUgYW5kIG5vcm1hdGl2ZSB0ZXh0IHNvIGlzIG1vcmUKPiAgICAgICAgdGhhbiBqdXN0IEFz c3VtcHRpb25zLiAgUGVyc29uYWxseSwgSSdkIHJlbW92ZSBhbGwgbm9ybWF0aXZlIHRleHQKPiAg ICAgICAgZnJvbSB0aGUgc2VjdGlvbi4KPgo+ICAgICAgLSBUaGVyZSBhcmUgbm8gc3BlY2lmaWMg cnVsZXMgcmVsYXRlZCB0byBVRFAgaGVhZGVyIGZvcm1hdGlvbi4KPgo+ICAgICAgLSBTZWN0aW9u cyA4LjEwLT44LjE3LiAgSXNuJ3QgYWRkL2Ryb3AgaW5kaWNhdG9yIG5lZWRlZCBmb3Igc3VibmV0 cwo+ICAgICAgICBpbiBkZXN0aW5hdGlvbiB1cGRhdGUgc2lnbmFscz8KPgo+ICAgICAgLSBUaGUg SUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9ucyBtdXN0IGZvbGxvd+KAiyBSRkMyMzYwLgo+Cj4g ICAgICAtIE5ldyByZWdpc3RyaWVzIG11c3QgaW5jbHVkZSBpbml0aWFsIHZhbHVlcywgd2hpY2gg YXJlIGRlZmluZWQgaW4KPiAgICAgICAgdGhlIGRvY3VtZW50LiAgKFRoZSBkb2N1bWVudCBjdXJy ZW50bHkgaGFzIG1hbnkgVEJEcyB0aGF0IHNob3VsZAo+ICAgICAgICBiZSByZXBsYWNlZC4pCj4K PiAgICAgIC0gTmV3IHJlZ2lzdHJpZXMgbmVlZCBhbiBhbGxvY2F0aW9uIHBvbGljeSwgZS5nLjoK PiAgICAgIFRoZSByZWdpc3RyeSBzaG91bGQgYmUgZXN0YWJsaXNoZWQgd2l0aCByZWdpc3RyYXRp b24gcG9saWNpZXMgb2YKPiAgICAgICJTdGFuZGFyZHMgQWN0aW9uIiAoZm9yIFN0YW5kYXJkcyBU cmFjayBkb2N1bWVudHMpIGFuZAo+ICAgICAg4oCcU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCIgKGZv ciBvdGhlciBkb2N1bWVudHMpLiBUaGUgZGVzaWduYXRlZAo+ICAgICAgZXhwZXJ0IGlzIGFueSBj dXJyZW50IDxmaWxsLWluPiBXRyBjaGFpci4KPgo+IE5pdHM6Cj4KPiAgICAgIC0gVGhlIGRvY3Vt ZW50IGludHJvZHVjZXMgdGhlIHRlcm1zICJzaWduYWxzIiBhbmQgImRhdGEgaXRlbXMiIGZvcgo+ ICAgICAgICB3aGF0IGlzIGNvbW1vbmx5IGNhbGxlZCAibWVzc2FnZXMiIGFuZCAiVExWcyIgKG9y IG9iamVjdHMpIGluCj4gICAgICAgIG90aGVyIHByb3RvY29scy4gIEl0J3MgcHJvYmFibHkgdG9v IGxhdGUgdG8gY2hhbmdlIHRoaXMsIGJ1dCBJCj4gICAgICAgIHRoaW5rIHRoZSBpbnRyb2R1Y3Rp b24gb2YgdW5pcXVlIHRlcm1pbm9sb2d5IGlzIGNvdW50ZXIKPiAgICAgICAgcHJvZHVjdGl2ZS4K Pgo+ICAgICAgLSBVc2Ugb2YgUkZDIDIxMTkgY29uZm9ybWFuY2UgbGFuZ3VhZ2UgaXMgYSBiaXQg cm91Z2gsIGFuZCB0aGVyZSBhcmUKPiAgICAgICAgd29yZHMgaW4gYWxsIGNhcHMgdGhhdCBhcmUg bm90IGRlZmluZWQgaW4gUkZDMjExOS4gVGFrZSBhIGxvb2sgYXQKPiAgICAgICAgaHR0cDovL3Ry YWMudG9vbHMuaWV0Zi5vcmcvd2cvdGVhcy90cmFjL3dpa2kvUFNHdWlkZWxpbmUgZm9yIHNvbWUK PiAgICAgICAgc3VnZ2VzdGlvbnMuCj4KPiAgICAgIC0gSW50ZXJuYWwgc29ja2V0IG9wZXJhdGlv biBpcyBtZW50aW9uZWQgYSBjb3VwbGUgb2YgdGltZXMuICBJdAo+ICAgICAgICByZWFsbHkgc2hv dWxkbid0IGJlLCB0aGUgc3BlYyBzaG91bGQgZGVmaW5lIGJlaGF2aW9yIG9uIHRoZSB3aXJlLgo+ Cj4gICAgICAtIFRoZSBMZW5ndGggZmllbGRzIGFyZSBtaXNzaW5nIHVuaXQgb2YgbWVhc3VyZSAo cHJlc3VtYWJseSBvY3RldHMpCj4KPiAgICAgIC0gVGhlIE1uZW1vbmljcyBhcmUgdXNlZCBiYXNp Y2FsbHkgb25jZSBhbmQgZG9uJ3QgcmVhbGx5IGFkZCB2YWx1ZSwKPiAgICAgICAgc3VnZ2VzdCBk cm9wcGluZyB0aGVtLgo+Cj4gICAgICAtIEhvdy93aGVuIGlzIHRoZSAiVW5rbm93biBTaWduYWwi IFN0YXR1cyBDb2RlIHNlbnQ/Cj4KPiAgICAgIC0gU2VjdGlvbiA4Ljc6IEV4dGVuc2lvbiBMaXN0 IHNob3VsZCBiZSBzaG93biBhcyBhIHZhcmlhYmxlIGxlbmd0aAo+ICAgICAgICBmaWVsZC4KPgo+ ICAgICAgLSBTZWN0aW9uIDguODogRXhwZXJpbWVudCBMaXN0IHNob3VsZCBiZSBzaG93biBhcyBh IHZhcmlhYmxlIGxlbmd0aAo+ICAgICAgICBmaWVsZC4KPgo+IFRoYXQncyBpdCAtLSBmb3Igbm93 IC0tIGhvcGVmdWxseSBJIGRpZG4ndCBtaXNzIGFueXRoaW5nLiAgTG9vayBmb3J3YXJkIHRvIGhl YXJpbmcgcmVzcG9uc2UgdG8gdGhlIGFib3ZlIChhbmQgaG93IEkgZ290IHRoaW5ncyBob3BlbGVz c2x5IHdyb25nIDstKQo+Cj4gTG91Cj4KPgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPiBtYW5ldCBtYWlsaW5nIGxpc3QKPiBtYW5ldEBpZXRmLm9y Zwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQKPiAqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKgo+IFRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRv IHRoZSBpbnRlbmRlZAo+IHJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkCj4gcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJv bSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCj4gWW91IHNob3VsZCBub3QgY29w eSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgo+IGRpc3RyaWJ1 dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCj4gKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IG1hbmV0IG1haWxp bmcgbGlzdAo+IG1hbmV0QGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tYW5ldAo+Cgo= ----_com.android.email_828683350181360 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5JdCB3b3VsZCBiZSBhcHBy b3ByaWF0ZSB0byBoYXZlIHNvbWUgb2YgdGhhdCBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0LiBUaGVy ZSBpcyBxdWl0ZSBhIGxvdCBvZiBpbnRlcmVzdCBpbiB0aGlzIGRyYWZ0IHdpdGhpbiB0aGUgd2cg YW5kIGdldHRpbmcgaW5wdXQgb24gYmVzdCB3YXlzIGZvcndhcmQgb24gdGhlIHZhcmlvdXMgZml4 ZXMgYmVmb3JlIHRoZXkgYXJlIHdyaXR0ZW4gdXAgc2hvdWxkIGVuZCB1cCBzYXZpbmcgdGltZS48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pkp1c3RpbjwvZGl2Pjxicj48YnI+PGRpdj4tLS0tLS0t LSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBSaWNrIFRheWxvciA8 cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29tPiA8L2Rpdj48ZGl2PkRhdGU6MDYvMTYvMjAx NSAgNTowMCBBTSAgKEdNVC0wNTowMCkgPC9kaXY+PGRpdj5UbzogIkRlYXJsb3ZlLCBDaHJpc3Rv cGhlciAoVUspIiA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+LCBMb3UgQmVyZ2VyIDxs YmVyZ2VyQGxhYm4ubmV0PiwgbWFuZXQtY2hhaXJzQGlldGYub3JnIDwvZGl2PjxkaXY+Q2M6IG1h bmV0LWFkc0BpZXRmLm9yZywgcnRnLWRpckBpZXRmLm9yZywgbWFuZXRAaWV0Zi5vcmcsIGRyYWZ0 LWlldGYtbWFuZXQtZGxlcC5hbGxAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogW21h bmV0XSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLW1hbmV0LWRsZXAtMTQgPC9kaXY+PGRpdj48 YnI+PC9kaXY+QWxsLDxicj48YnI+U3RhbiBhbmQgSSBhcmUgY3VycmVudGx5IGRpc2N1c3Npbmcg dGhlIHJldmlldy4mbmJzcDsgV2Ugd2lsbCBjb21lIGJhY2sgdG8gPGJyPnRoZSBsaXN0IHdpdGgg YSBwcm9wb3NlZCBzZXQgb2YgYWN0aW9ucyB3aGVuIHdlIGhhdmUgYSBwbGFuLjxicj48YnI+U29y cnkgZm9yIHRoZSBkZWxheSw8YnI+PGJyPlJpY2s8YnI+PGJyPjxicj5PbiAxNS8wNi8xNSAxMjox NiwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgd3JvdGU6PGJyPiZndDsgSSBoYXZlbid0IHNl ZW4gYW55IGRpc2N1c3Npb24gb2YgdGhpcy4gSXQgbG9va3MgdG8gbWUgbGlrZSByZXF1aXJpbmcg YW5vdGhlciBkcmFmdCBmb3IgdGhlIFdHIHRvIHNlZS4gSXQgZG9lcyAoYnkgbXkgcmFwaWQgY291 bnQpIGhhdmUgMTcgbWFqb3IgaXNzdWVzLjxicj4mZ3Q7PGJyPiZndDsgLS08YnI+Jmd0OyBDaHJp c3RvcGhlciBEZWFybG92ZTxicj4mZ3Q7IFNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+Jmd0 OyBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZTxicj4mZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPiZndDs8YnI+Jmd0OyBUOiZuYnNwOyArNDQgKDApMTI0NSAyNDIxOTQmbmJzcDsgfCZu YnNwOyBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxicj4mZ3Q7PGJyPiZndDsgQkFF IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJr LCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPiZndDsgd3d3LmJh ZXN5c3RlbXMuY29tL2FpPGJyPiZndDsgQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2Ug TGltaXRlZDxicj4mZ3Q7IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEz Mzc0NTE8YnI+Jmd0OyBSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1 aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsgRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTG91IEJlcmdlcjxicj4mZ3Q7IFNlbnQ6IDA4IEp1 bmUgMjAxNSAyMDoxMTxicj4mZ3Q7IFRvOiBtYW5ldC1jaGFpcnNAaWV0Zi5vcmc8YnI+Jmd0OyBD YzogbWFuZXQtYWRzQGlldGYub3JnOyBydGctZGlyQGlldGYub3JnOyBtYW5ldEBpZXRmLm9yZzsg ZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLmFsbEBpZXRmLm9yZzxicj4mZ3Q7IFN1YmplY3Q6IFttYW5l dF0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLTE0PGJyPiZndDs8YnI+Jmd0 OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwg ZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC48YnI+ Jmd0OyBDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBs aW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPGJyPiZndDsgRm9sbG93IHRoZSAn UmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0 aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy48YnI+Jmd0OyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4m Z3Q7PGJyPiZndDsgW05vdGUgdGhpcyBpcyBhIFdHIExDIHJlbGF0ZWQgcmV2aWV3LCBub3QgSUVU RiBMQy5dPGJyPiZndDs8YnI+Jmd0OyBIZWxsbyw8YnI+Jmd0Ozxicj4mZ3Q7IEkgaGF2ZSBiZWVu IHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRy YWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcg b3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3Qg Y2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0IC0t IG9yIFdHIExhc3QgY2FsbCBhcyB3YXMgdGhlIGNhc2UgaGVyZSAuIFRoZSBwdXJwb3NlIG9mIHRo ZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9y IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBz ZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rp cjxicj4mZ3Q7PGJyPiZndDsgQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBm b3IgdGhlIHVzZSBvZiB0aGUgKGNoYWlycyBhbmQpIFJvdXRpbmcgQURzLCBpdCB3b3VsZCBiZSBo ZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIExh c3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUg dGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Ljxicj4mZ3Q7 PGJyPiZndDsgRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC0xNDxicj4mZ3Q7IFJldmll d2VyOiBMb3UgQmVyZ2VyPGJyPiZndDsgUmV2aWV3IERhdGU6IEp1bmUgOCAobGF0ZXIgdGhhbiBy ZXF1ZXN0ZWQgZHVlIHRvIHNjb3BlIG9mIGNvbW1lbnRzIC0tIHNvcnJ5KSBXRyBMQyBFbmQgRGF0 ZTogdW5rbm93biBJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyB0cmFjazxicj4mZ3Q7PGJyPiZn dDsgU3VtbWFyeTo8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFdoaWxlIEkgdGhpbmsgdGhlIGRvY3VtZW50IGlzIHByZXR0eSBkZWNlbnQgZm9yIHRoZSBzY29w ZSBvZiB0aGU8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3b3JrLCBJIGRv IGhhdmUgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCBhbmQgcmVjb21tZW5kIHRoYXQgdGhl PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV0cgQ2hhaXJzL1JvdXRpbmcg QURzIGRpc2N1c3MgdGhlc2UgaXNzdWVzIGZ1cnRoZXIgd2l0aCB0aGUgYXV0aG9ycy48YnI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJJ20gYWxzbyBhdmFpbGFibGUgYXMvaWYg bmVlZGVkIHRvIGRpc2N1c3MuPGJyPiZndDs8YnI+Jmd0OyBDb21tZW50czo8YnI+Jmd0Ozxicj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgdGhpbmsgdGhlIGRvY3VtZW50IHNo b3dzIHNpZ25pZmljYW50IGdvb2Qgd29yayBhbmQgbG9va3MgdG8gYmUgYTxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZWZ1bCBwcm90b2NvbCwgYWx0aG91Z2ggSSdtIG5v dCBvdmVybHkgZmFtaWxpYXIgaW4gdGhpcyBzcGFjZS48YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUaGF0IHNhaWQsIEkgaGF2ZSBhIG51bWJlciBvZiBzZXJpb3VzIGNvbmNl cm5zIGFib3V0IHRoZSBkb2N1bWVudCw8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBhbmQgaXRzIGNvbnRlbnRzIGZyb20gYSBmZXcgb2YgcGVyc3BlY3RpdmVzLiZuYnNwOyBU aGVzZSBpbmNsdWRlIGJhc2ljPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg cHJvdG9jb2wgaXNzdWVzLCB1bmRlcnNwZWNpZmllZCBkZXRhaWxzJm5ic3A7ICh3aGljaCBjb3Vs ZCBsZWFkIHRvPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50ZXJvcGVy YWJpbGl0eSBpc3N1ZXMpLCBhbmQgc3BlY2lmaWNhdGlvbi9lZGl0b3JpYWwgaXNzdWVzLiBJPGJy PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhpbmsgdGhlIGRvY3VtZW50IC8g cHJvdG9jb2wgY2FuIGJlIG1vZGlmaWVkIHRvIGFkZHJlc3MgdGhlIGlzc3Vlczxicj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgcmFpc2UgYmVsb3cuJm5ic3A7IE9mIGNvdXJz ZSwgaXQgaXMgdXAgdG8gdGhlIFdHLCBjaGFpcnMsIGFuZCBBRHMgdG88YnI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWNpZGUgd2hpY2ggY29tbWVudHMgdG8gYWRkcmVzcyBh bmQgd2hpY2ggdG8mbmJzcDsgaWdub3JlLjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEkgZG9uJ3QgZXhwZWN0IHRoYXQgYWxsIGNvbW1lbnRzIHdpbGwgcmVzdWx0IGluIGNo YW5nZXMuPGJyPiZndDs8YnI+Jmd0OyBNYWpvciBJc3N1ZXM6PGJyPiZndDs8YnI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRoZSBsZW5ndGggZmllbGQgb2YgdGhlIGdlbmVy aWMgZGF0YSBpdGVtIChpLmUuLCBUTFYpIGlzIG9ubHkgODxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJpdHMuJm5ic3A7IFdoaWxlIDI1NSBieXRlcyAo YXNzdW1pbmcgdGhhdCB0aGlzIGlzIHRoZSB1bml0IG9mIG1lYXN1cmUsPGJyPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hpY2ggQlRXIGlzbid0IHNwZWNp ZmllZCkgaXMgYmlnIGVub3VnaCB0b2RheSwgYWxsb3dpbmcgZm9yPGJyPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGFyZ2VyIHdpbGwgZ3JlYXRseSBzaW1w bGlmeSB0aGluZ3Mgd2hlbiAyNTUgaXNuJ3QgZW5vdWdoLiAtLTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdlJ3ZlIHJ1biBpbnRvIHRoaXMgaW4gUlNW UCBhbmQgaXQncyBhIHJlYWwgcGFpbi48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0gVmVyc2lvbiBudW1iZXIgaXMgY3VycmVudGx5IGRlZmluZWQgYXMgYSBk YXRhIGl0ZW0uJm5ic3A7IFRoaXMgbWVhbnMgYTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNpZ25hbCAoaS5lLiwgbWVzc2FnZSkgbmVlZHMgdG8gYmUg cG90ZW50aWFsbHkgZnVsbHkgcGFyc2VkIHRvPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZGlzY292ZXIgd2hhdCB2ZXJzaW9uIGlzIGJlaW5nIHVzZWQu Jm5ic3A7IFRoaXMgcHJlY2x1ZGVzIGJhc2ljIGZvcm1hdDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNoYW5nZXMgdG8gdGhlIHByb3RvY29sLiZuYnNw OyBQZXJoYXBzIHRoZSBEaXNjb3ZlcnkgYW5kIEluaXQgU2lnbmFsczxicj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNob3VsZCBiZSBzcGVjaWFsIGNhc2Vk IHRvIGluY2x1ZGUgdmVyc2lvbiBpbiB0aGVpciBmb3JtYXRzLiZuYnNwOyAoQW5kPGJyPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2hvcnRlbiB2ZXJzaW9u IHRvIDggYml0cyBmcm9tIDMyLCBhcyBtZW50aW9uZWQgYmVsb3cpLjxicj4mZ3Q7PGJyPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBUaGUgZG9jdW1lbnQgcmVmZXJlbmNlcywg YnV0IGRvZXMgbm90IGRlZmluZSwgJ2luLXNlc3Npb24nIGFuZDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICdkaXNjb3ZlcnknIHN0YXRlcy4mbmJzcDsg VGhlc2UgZWl0aGVyIG5lZWQgdG8gYmUgZm9ybWFsbHkgZGVmaW5lZCBvcjxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlbW92ZWQuJm5ic3A7IEJUVyB3 ZSBoYWQgZXhhY3RseSB0aGUgc2FtZSBpc3N1ZSB3aXRoIExNUCAoUkZDNDIwNCkgYW5kPGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5kZWQgdXAgYWRk aW5nIHNlY3Rpb24gMTEgKEZTTXMpIGF0IGEgcHJldHR5IGxhdGUgc3RhZ2Ugb2YgdGhlPGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvY2Vzcy48YnI+ Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gVENQIHNlc3Npb24g bWFuYWdlbWVudCBpcyBub3QgZGVmaW5lZCwgbm9yIGlzIHRoZSByZWxhdGlvbnNoaXA8YnI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aXRoIFRDUCBhbmQg RExFUCBzZXNzaW9ucyBmdWxseSBkZWZpbmVkLiZuYnNwOyBGb3IgZXhhbXBsZTo8YnI+Jmd0Ozxi cj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8gQ2xvc2lu ZyB0aGUgVENQIHNlc3Npb24gaXMgb25seSBtZW50aW9uZWQgaW4gb25lIHBsYWNlIGFuZCBpbiBh PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgd2F5IHRoYXQgaXMgaW5jb25zaXN0ZW50IHdpdGggdGhlIGV4cGVjdGVkIHByb3RvY29s IGJlaGF2aW9yPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgKGNsb3NlIFRDUCBiZWZvcmUgQUNLIGlzIHJlY2VpdmVkKS48YnI+Jmd0 Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8gV2hh dCBoYXBwZW5zIHdoZW4gYSBETEVQIHNlc3Npb24gaXMgdGVybWluYXRlZCwgY2FuIHRoZSBUQ1A8 YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBzZXNzaW9uIGJlIHJldXNlZCBvciBtdXN0IGl0IGJlIGNsb3NlZCB0b28/PGJyPiZndDs8 YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRoZXJlIGlzIG5vIHRyYW5z YWN0aW9uIG1vZGVsIGRlZmluZWQuJm5ic3A7IEZvciBleGFtcGxlLCBpdCdzPGJyPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29tcGxldGVseSB1bmNsZWFy IGlmIG9ubHkgb25lIHVuYWNrbm93bGVkZ2VkIFNpZ25hbCBhbGxvd2VkIGF0IGE8YnI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aW1lLCBvciBwZXJoYXBz IGp1c3Qgb25lIHBlciBzaWduYWwgdHlwZSBpcyBhbGxvd2VkLCBvciBwZXJoYXBzPGJyPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlcmUgYXJlIG5vIHJl c3RyaWN0aW9ucy4mbmJzcDsgVGhpcyBuZWVkcyB0byBiZSBleHBsaWNpdC48YnI+Jmd0Ozxicj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gV2hhdCBpcyB0aGUgcHVycG9zZSBv ZiByZXRyaWVzIGFuZCB0aW1lb3V0cyBvdmVyIFRDUD8mbmJzcDsgUmV0cmllczxicj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZW4ndCBuZWVkZWQgb3Zl ciBUQ1BzIGFuZCBpdCdzIHVuY2xlYXIgd2hleSB0aGV5IGFyZSBiZWluZyB1c2VkLjxicj4mZ3Q7 PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBUaGUgaGlnaGVyIGxldmVs IGltcGxpY2F0aW9ucyBvZiBBQ0tzLCBvdmVyIFRDUCwgaXNuJ3QgcmVhbGx5PGJyPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2xlYXIuJm5ic3A7IEl0IHNl ZW1zIEFDS3MgYXJlIGRlZmluZWQgZm9yIG11bHRpcGxlIHB1cnBvc2VzOiByZWxpYWJsZTxicj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRyYW5zcG9ydCwg dHJhbnNhY3Rpb24gYWNrbm93bGVkZ21lbnQgYW5kIHRyYW5zYWN0aW9uIHJlc3VsdHMuIE9mPGJy PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY291cnNlIHRo ZSBmaXJzdCBpc24ndCBuZWVkZWQsIGFuZCBpbXBsaWNhdGlvbnMgb2YgdGhlIG90aGVyczxicj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNob3VsZCBiZSBj bGVhci4mbmJzcDsgRm9yIGV4YW1wbGUsIGluIHNlY3Rpb24gNy4xMCwgd2h5IHdvdWxkIHRoZXJl IGJlPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBy ZXRyeSB3aGVuIHJlY2VpdmluZyBhIERlc3RpbmF0aW9uIFVwIEFDSyBzaWduYWwgaW5kaWNhdGlu ZyBhbjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVy cm9yPzxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBUaGVy ZSBpcyBubyBkaXNjdXNzaW9uIG9uIHNjYWxpbmcgY29uc2lkZXJhdGlvbnMuIEFyZSB0aGVyZSBy ZWFsbHk8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBu b25lPyZuYnNwOyBGb3IgZXhhbXBsZSwgaG93IG9mdGVuIG1pZ2h0IGJlIGFwcHJvcHJpYXRlIHRv IGlzc3VlL2xpbWl0PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUGVlciBVcGRhdGVzIGJhc2VkIHRvIGNoYW5nZXMgaW4gbGluayBxdWFsaXR5LCBvciBo b3cgdG8gaGFuZGxlPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdGhlIGNhc2Ugd2hlcmUgYSBsYXJnZSBudW1iZXIgKGFsbCBvciBtb3N0KSBvZiBkZXN0 aW5hdGlvbnMgZ288YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBkb3duLjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LSBUaGVyZSBhcmUgMTMgcGxhY2VzIHdoZXJlIHRoZSBwcm90b2NvbCBhbGxvd3MgaW1wbGVtZW50 YXRpb24gdG88YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBkZWZpbmUgdGhlaXIgb3duICdoZXVyaXN0aWNzJy4mbmJzcDsgU29tZSBvZiB0aGVzZSBzZWVt IHVubmVjZXNzYXJ5IGR1ZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRvIHRoZSBUQ1AgcG9pbnQgcmFpc2VkIGFib3ZlLCBidXQgYW55IHRoYXQgcmVt YWluIGluIHRoZSBwcm90b2NvbDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHNob3VsZCBiZSBmdWxseSBzcGVjaWZpZWQgdG8gZW5zdXJlIHByZWRpY3Rh YmxlL2NvbnNpc3RlbnQ8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBiZWhhdmlvciBmcm9tIGltcGxlbWVudGF0aW9ucy48YnI+Jmd0Ozxicj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gRGF0YSBJdGVtcyBhcmUgZGVmaW5lZCBmb3Ig IkV4dGVuc2lvbnMiIGFuZCAiRXhwZXJpbWVudGFsPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGVmaW5pdGlvbiIgKFNlY3Rpb25zIDguNyBhbmQgOC44 KS4mbmJzcDsgQm90aCBzZWVtIHRvIHN1cHBvcnQgZm9yPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3B0aW9uYWwgbWVjaGFuaXNtcywgYnV0IHRoZSBm b3JtZXIgdXNlcyBhc3NpZ25lZCBudW1lcmljIHZhbHVlcyw8YnI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aHkgdGhlIGxhdHRlciB1c2VzIFVURi04IHN0 cmluZ3MuPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg byBXaGF0LCBpZiBhbnksIGlzIHRoZSBpbnRlbmRlZCBkaXN0aW5jdGlvbi9yZWxhdGlvbnNoaXAg YmV0d2Vlbjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHRoZXNlPzxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG8gSG93IGRvZXMgYW4gIkV4cGVyaW1lbnRhbCBEZWZpbml0aW9uIiBiZWNv bWUgc3RhbmRhcmRpemVkPzxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLSBTZWN0aW9ucyA4LjE5IGFuZCA4LjIwIGRlZmluZSAiUmVzb3VyY2VzIiByZWxhdGVk IERhdGEgSXRlbXMuJm5ic3A7IFRoZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGRlZmluaXRpb24gcmVsYXRlZCB0byB0aGVzZSBiYXNpY2FsbHkgc2F5 cyBhIHJlc291cmNlcyBpcyAiQW48YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA4LWJpdCBpbnRlZ2VyIHBlcmNlbnRhZ2UsIDAtMTAwLCByZXByZXNlbnRp bmcgdGhlIGFtb3VudCBvZjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHJlc291cmNlcyBhbGxvY2F0ZWQgdG8gcmVjZWl2aW5nfHRyYW5zbWl0dGluZyBk YXRhLiIuJm5ic3A7IElmIEkgd2VyZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGltcGxlbWVudGluZyB0aGlzIHByb3RvY29sLCBJJ2QgaGF2ZSBubyBp ZGVhIGhvdyB0byBwcm9kdWNlLDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHVwZGF0ZSBvciB1c2UgdGhpcyBpbmZvcm1hdGlvbi4mbmJzcDsgSSB0aGlu ayB0aGVyZSBpcyBzb21lIG1pc3Npbmc8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBpbmZvcm1hdGl2ZSBhbmQgbm9ybWF0aXZlIChSRkMgMjExOSkgdGV4 dCByZWxhdGVkIHRvIHRoZXNlPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgZm9ybWF0cy48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0gU2VjdGlvbnMgOC4yMSBhbmQgOC4yMiAoUmVsYXRpdmUgTGluayBRdWFsaXR5 KSBoYXZlIGEgc2ltaWxhcjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHByb2JsZW0gb2YgYmVpbmcgdW5kZXIgZGVzY3JpYmVkLCBpbiBwYXJ0aWN1bGFy IGl0J3MgdW5jbGVhciBpZjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRoZXJlJ3MgYSBtZWFuaW5nZnVsLCBub24tcHJvcHJpZXRhcnkgZGVmaW5pdGlv biBmb3IgbGluayBxdWFsaXR5PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBpcyB0byBhY3Qgb24gb3IgaWYgdGhl IHBhc3NlZCB2YWx1ZSBpcyBqdXN0PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgcGFzc2VkIGZvciBhcyBtb25pdG9yaW5nIGluZm9ybWF0aW9uLiZuYnNw OyBFaXRoZXIgd2F5LCB0aGlzIG5lZWRzIHRvPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUgY2xhcmlmaWVkLjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBTZWN0aW9uIDkgZGVmaW5lcyBhICJjcmVkaXQtd2lu ZG93aW5nIHNjaGVtZSBhbmFsb2dvdXMgdG8gdGhlIG9uZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRvY3VtZW50ZWQgaW4gW1JGQzU1NzhdIi4gSXQg ZGVzY3JpYmVzIGhvdyBjcmVkaXRzIGFyZSBleGNoYW5nZWQsPGJyPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnV0IGl0IHByb3ZpZGVzIHplcm8gZGVmaW5p dGlvbiBvbiB0aGUgaW1wbGljYXRpb25zIG9yIHVzZSBvZjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNyZWRpdHMgcmVsYXRpdmUgdG8gdGhlIGRhdGEg cGxhbmUuPGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIE11 bHRpcGxlIHdheXMgdG8gaW1wbGVtZW50IHRoZSBzYW1lIGZ1bmN0aW9uIGFyZSBhbGxvd2VkLCBl LmcuLDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9w dGlvbmFsIHByZXNlbmNlIG9mIFN0YXR1cywgSW50ZXJ2YWwgYW5kIFRDUCBwb3J0LiZuYnNwOyBH ZW5lcmFsbHk8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBhbGxvd2luZyBzdWNoIGNvbXBsaWNhdGVzIHRlc3RpbmcgYW5kIGxlYWRzIHRvIGludGVyb3Bl cmFiaWxpdHk8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBpc3N1ZXMuJm5ic3A7IFRoZSBkb2N1bWVudCBzaG91bGQgcGljayBvbmUgd2F5IGFuZCByZXF1 aXJlIGl0Ljxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBU aGUgZG9jdW1lbnQgZG9lc24ndCBzdGF0ZSBpZiB0aGVyZSBhcmUgYW55IG9yZGVyaW5nIHJlcXVp cmVtZW50czxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG9uIGRhdGEgaXRlbXMuIEl0IHNob3VsZCBiZSBleHBsaWNpdCBvbiB0aGlzLCBlLmcuLCB0aGVy ZSBhcmUgbm88YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBvcmRlcmluZyByZXF1aXJlbWVudHMgb24gdGhlIHBsYWNlbWVudCBvZiBEYXRhIEl0ZW1zIHdp dGhpbjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNp Z25hbHMuPGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRo ZSByZXF1aXJlZCBhbmQgb3B0aW9uYWwgZGF0YSBpdGVtcyB0aGF0IGFyZSBwZXJtaXR0ZWQgb24g YTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNpZ25h bCBpc24ndCBhbHdheXMgY2xlYXIuJm5ic3A7IEZvciBleGFtcGxlIGFyZSAwLzEvTiBjb3BpZXMg b2YgYTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBh cnRpY3VsYXIgRGF0YSBJdGVtIHJlcXVpcmVkL2FsbG93ZWQuJm5ic3A7IFVzaW5nIHNvbWV0aGlu ZyBsaWtlIEFCTkY8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB3b3VsZCByZWFsbHkgaGVscCBmb3JtYWxpemUgYW5kIGNsYXJpZnkgdGhpcy48YnI+Jmd0 Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gVGhlIGRvY3VtZW50IGRv ZXNuJ3QgY2xlYXJseSBkZWxpbmVhdGUgZnJvbSBpbmZvcm1hdGl2ZS9uYXJyYXRpdmU8YnI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0ZXh0LCBub3JtYXRp dmUgLyByZXF1aXJlZCBwcm9jZXNzaW5nIHByb2NlZHVyZXMsIGFuZCBtZXNzYWdlPGJyPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9ybWF0cy4gVGhpcyBi eSBpdHNlbGYgaXMgbm90IG5lY2Vzc2FyaWx5IGEgbWFqb3IgaXNzdWUsIGl0IGp1c3Q8YnI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYWtlcyBpdCBoYXJk ZXIgdG8gKHdyaXRlLCkgcmV2aWV3IGFuZCBpbXBsZW1lbnQgdGhlIHByb3RvY29sLjxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoYXQgaXMgYSBtYWpv ciBpc3N1ZSBpcyB0aGF0IHRoaXMgYXBwcm9hY2ggYWxsb3dzIGZvciBkdXBsaWNhdGU8YnI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoYW5kIHNvbWV0aW1l cyBjb250cmFkaWN0b3J5KSBub3JtYXRpdmUgcHJvY2VkdXJlcyBhbmQgZm9yPGJyPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb21pc3Npb25zIGluIHByb2Nl ZHVyZXMgKHBhcnRpY3VsYXJseSByZWxhdGVkIHRvIGV4Y2VwdGlvbi9lcnJvcjxicj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb2Nlc3NpbmcpLiZuYnNw OyBTcGVjaWZpYyBleGFtcGxlcyBhcmUgaW5jbHVkZWQgYWJvdmUgYW5kIGJlbG93LiZuYnNwOyBJ dDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdvdWxk IGJlIGJlc3QgdG8gZW5zdXJlIHRoYXQgZWFjaCByZXF1aXJlZCBwcm9jZXNzaW5nIGJlaGF2aW9y IGlzPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVm aW5lZCBqdXN0IG9uY2UgYW5kIGluIGEgY29uc2lzdGVudCB3YXkuPGJyPiZndDs8YnI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u IHNlY3Rpb24gaXMgaW5hZGVxdWF0ZS4mbmJzcDsgVGhpcyBzZWN0aW9uPGJyPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2hvdWxkIGFkZHJlc3MgdGhlIHNl Y3VyaXR5IG9mIHRoZSBETEVQIHByb3RvY29sLCBub3QgdXNlcjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRyYWZmaWMuJm5ic3A7IEl0IHNob3VsZCBp bmNsdWRlIGFuIGFuYWx5c2lzIG9mIHJpc2tzL3RocmVhdHMvcG9zc2libGU8YnI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBleHBsb2l0cyBhbmQgaG93IHRo ZXNlIGFyZSBtaXRpZ2F0ZWQgYnkgdGhlIHByb3RvY29sLiZuYnNwOyByZmM2OTUyLDxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCB0aGUgcHJvdG9j b2xzIGl0IHJlZmVyZW5jZXMgY2FuIHNlcnZlIGFzIGV4YW1wbGVzLjxicj4mZ3Q7PGJyPiZndDsg TWlub3IgSXNzdWVzOjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLSBUaGUgZGF0YSBhbmQgc2lnbmFsIHR5cGUgZmllbGRzIGFyZSBib3RoIDggYml0cy4mbmJz cDsgVGhpcyBzZWVtczxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHByZXR0eSBzbWFsbCwgcGFydGljdWxhcmx5IHRoZSBkYXRhIHR5cGUgZmllbGQuJm5i c3A7IEdpdmVuIHRoaXMgaXMgYTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGNvbnRyb2wgcHJvdG9jb2wsIEkgdGhpbmsgYSBsYXJnZXIgKGF0IGxlYXN0 IGRhdGEgdHlwZSkgZmllbGQ8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB3b3VsZCBwcm92aWRlIGJldHRlciAiZnV0dXJlIHByb29maW5nIi48YnI+Jmd0 Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gMl4zMiB2ZXJzaW9ucyBh cmUgY3VycmVudGx5IGFsbG93ZWQgKHNlY3Rpb24gOC4xKS4mbmJzcDsgVGhpcyBzZWVtcyBhPGJy PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYml0IGV4Y2Vz c2l2ZS4mbmJzcDsgSSdkIG9wdCBmb3IgbWF4IG9mIDggYml0cyBoZXJlIG15c2VsZi48YnI+Jmd0 Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gSXQncyBwcm9iYWJseSB0 b28gbGF0ZSwgYnV0IGl0IHByb2JhYmx5IHdvdWxkIGJlIGNsZWFuZXIgdG8gaGF2ZSBhPGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ2VuZXJpYyBhY2sg c2lnbmFsIHJhdGhlciB0aGFuIGEgcGVyIHNpZ25hbCB0eXBlIGFjay4gSSBtZW50aW9uPGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhpcyBoZXJlIGFz IHRoaXMgbWF5IGNvbWUgdXAgYWdhaW4gd2hlbiBjbGFyaWZ5aW5nIHRoZTxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRyYW5zYWN0aW9uIG1vZGVsIChh cyBtZW50aW9uZWQgYWJvdmUuKTxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLSBTZWN0aW9uIDI6IEFzc3VtcHRpb25zPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBzZWN0aW9uIGluY2x1ZGVzIGluZm9ybWF0 aXZlIGFuZCBub3JtYXRpdmUgdGV4dCBzbyBpcyBtb3JlPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhhbiBqdXN0IEFzc3VtcHRpb25zLiZuYnNwOyBQ ZXJzb25hbGx5LCBJJ2QgcmVtb3ZlIGFsbCBub3JtYXRpdmUgdGV4dDxicj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZyb20gdGhlIHNlY3Rpb24uPGJyPiZn dDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRoZXJlIGFyZSBubyBz cGVjaWZpYyBydWxlcyByZWxhdGVkIHRvIFVEUCBoZWFkZXIgZm9ybWF0aW9uLjxicj4mZ3Q7PGJy PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBTZWN0aW9ucyA4LjEwLSZndDs4 LjE3LiZuYnNwOyBJc24ndCBhZGQvZHJvcCBpbmRpY2F0b3IgbmVlZGVkIGZvciBzdWJuZXRzPGJy PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW4gZGVzdGlu YXRpb24gdXBkYXRlIHNpZ25hbHM/PGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtIFRoZSBJQU5BIENvbnNpZGVyYXRpb25zIHNlY3Rpb25zIG11c3QgZm9sbG93 4oCLIFJGQzIzNjAuPGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtIE5ldyByZWdpc3RyaWVzIG11c3QgaW5jbHVkZSBpbml0aWFsIHZhbHVlcywgd2hpY2ggYXJl IGRlZmluZWQgaW48YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0aGUgZG9jdW1lbnQuJm5ic3A7IChUaGUgZG9jdW1lbnQgY3VycmVudGx5IGhhcyBtYW55 IFRCRHMgdGhhdCBzaG91bGQ8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBiZSByZXBsYWNlZC4pPGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtIE5ldyByZWdpc3RyaWVzIG5lZWQgYW4gYWxsb2NhdGlvbiBwb2xpY3ks IGUuZy46PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHJlZ2lzdHJ5 IHNob3VsZCBiZSBlc3RhYmxpc2hlZCB3aXRoIHJlZ2lzdHJhdGlvbiBwb2xpY2llcyBvZjxicj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJTdGFuZGFyZHMgQWN0aW9uIiAoZm9y IFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudHMpIGFuZDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IOKAnFNwZWNpZmljYXRpb24gUmVxdWlyZWQiIChmb3Igb3RoZXIgZG9jdW1l bnRzKS4gVGhlIGRlc2lnbmF0ZWQ8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBleHBlcnQgaXMgYW55IGN1cnJlbnQgJmx0O2ZpbGwtaW4mZ3Q7IFdHIGNoYWlyLjxicj4mZ3Q7 PGJyPiZndDsgTml0czo8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0gVGhlIGRvY3VtZW50IGludHJvZHVjZXMgdGhlIHRlcm1zICJzaWduYWxzIiBhbmQgImRh dGEgaXRlbXMiIGZvcjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHdoYXQgaXMgY29tbW9ubHkgY2FsbGVkICJtZXNzYWdlcyIgYW5kICJUTFZzIiAob3Ig b2JqZWN0cykgaW48YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBvdGhlciBwcm90b2NvbHMuJm5ic3A7IEl0J3MgcHJvYmFibHkgdG9vIGxhdGUgdG8gY2hh bmdlIHRoaXMsIGJ1dCBJPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgdGhpbmsgdGhlIGludHJvZHVjdGlvbiBvZiB1bmlxdWUgdGVybWlub2xvZ3kgaXMg Y291bnRlcjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHByb2R1Y3RpdmUuPGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtIFVzZSBvZiBSRkMgMjExOSBjb25mb3JtYW5jZSBsYW5ndWFnZSBpcyBhIGJpdCByb3VnaCwg YW5kIHRoZXJlIGFyZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHdvcmRzIGluIGFsbCBjYXBzIHRoYXQgYXJlIG5vdCBkZWZpbmVkIGluIFJGQzIxMTku IFRha2UgYSBsb29rIGF0PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvdGVhcy90cmFjL3dpa2kvUFNH dWlkZWxpbmUgZm9yIHNvbWU8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBzdWdnZXN0aW9ucy48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0gSW50ZXJuYWwgc29ja2V0IG9wZXJhdGlvbiBpcyBtZW50aW9uZWQgYSBj b3VwbGUgb2YgdGltZXMuJm5ic3A7IEl0PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgcmVhbGx5IHNob3VsZG4ndCBiZSwgdGhlIHNwZWMgc2hvdWxkIGRl ZmluZSBiZWhhdmlvciBvbiB0aGUgd2lyZS48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gVGhlIExlbmd0aCBmaWVsZHMgYXJlIG1pc3NpbmcgdW5pdCBvZiBt ZWFzdXJlIChwcmVzdW1hYmx5IG9jdGV0cyk8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gVGhlIE1uZW1vbmljcyBhcmUgdXNlZCBiYXNpY2FsbHkgb25jZSBh bmQgZG9uJ3QgcmVhbGx5IGFkZCB2YWx1ZSw8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBzdWdnZXN0IGRyb3BwaW5nIHRoZW0uPGJyPiZndDs8YnI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIEhvdy93aGVuIGlzIHRoZSAiVW5rbm93 biBTaWduYWwiIFN0YXR1cyBDb2RlIHNlbnQ/PGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtIFNlY3Rpb24gOC43OiBFeHRlbnNpb24gTGlzdCBzaG91bGQgYmUg c2hvd24gYXMgYSB2YXJpYWJsZSBsZW5ndGg8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBmaWVsZC48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gU2VjdGlvbiA4Ljg6IEV4cGVyaW1lbnQgTGlzdCBzaG91bGQgYmUg c2hvd24gYXMgYSB2YXJpYWJsZSBsZW5ndGg8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBmaWVsZC48YnI+Jmd0Ozxicj4mZ3Q7IFRoYXQncyBpdCAtLSBm b3Igbm93IC0tIGhvcGVmdWxseSBJIGRpZG4ndCBtaXNzIGFueXRoaW5nLiZuYnNwOyBMb29rIGZv cndhcmQgdG8gaGVhcmluZyByZXNwb25zZSB0byB0aGUgYWJvdmUgKGFuZCBob3cgSSBnb3QgdGhp bmdzIGhvcGVsZXNzbHkgd3JvbmcgOy0pPGJyPiZndDs8YnI+Jmd0OyBMb3U8YnI+Jmd0Ozxicj4m Z3Q7PGJyPiZndDs8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4mZ3Q7IG1hbmV0IG1haWxpbmcgbGlzdDxicj4mZ3Q7IG1hbmV0QGlldGYu b3JnPGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDxi cj4mZ3Q7ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqPGJyPiZndDsgVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPiZndDsgcmVjaXBpZW50IGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+Jmd0 OyByZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkg dGhlIHNlbmRlci48YnI+Jmd0OyBZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPiZndDsgZGlzdHJpYnV0ZSBpdHMgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+Jmd0OyAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4mZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgbWFuZXQg bWFpbGluZyBsaXN0PGJyPiZndDsgbWFuZXRAaWV0Zi5vcmc8YnI+Jmd0OyBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PGJyPiZndDs8YnI+PGJyPjwvYm9keT4= ----_com.android.email_828683350181360-- From nobody Tue Jun 16 04:58:44 2015 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 5318A1ACDED; Tue, 16 Jun 2015 04:58:42 -0700 (PDT) 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 0YFh2ZUZvMpd; Tue, 16 Jun 2015 04:58:35 -0700 (PDT) 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 5810E1ACDDB; Tue, 16 Jun 2015 04:58:34 -0700 (PDT) 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 Jun 2015 12:58:09 +0100 From: Rick Taylor To: bebemaster , "Dearlove, Christopher (UK)" , Lou Berger , "manet-chairs@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqCca3v1bQ2j6/kOycfKuSsomuQ== Date: Tue, 16 Jun 2015 11:58:07 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C29BB99@tss-server1.home.tropicalstormsoftware.com> References: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , "manet@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 11:58:42 -0000 VGhhdCdzIGlzIGVudGlyZWx5IHVuZGVyc3Rvb2QgSnVzdGluLCBJIGp1c3QgYmVsaWV2ZSB0aGF0 IGl0IHdvdWxkIGJlDQpiZXR0ZXIgaWYgdGhlIHR3byBvZiB1cyBoYWQgYSBjb25zaXN0ZW50IHNl dCBvZiBzdWdnZXN0aW9ucyBmb3IgdGhlIGNoYW5nZXMuDQoNClJpY2sNCg0KT24gMTYvMDYvMTUg MTI6MjUsIGJlYmVtYXN0ZXIgd3JvdGU6DQo+IEl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRvIGhh dmUgc29tZSBvZiB0aGF0IGRpc2N1c3Npb24gb24gdGhlIGxpc3QuDQo+IFRoZXJlIGlzIHF1aXRl IGEgbG90IG9mIGludGVyZXN0IGluIHRoaXMgZHJhZnQgd2l0aGluIHRoZSB3ZyBhbmQgZ2V0dGlu Zw0KPiBpbnB1dCBvbiBiZXN0IHdheXMgZm9yd2FyZCBvbiB0aGUgdmFyaW91cyBmaXhlcyBiZWZv cmUgdGhleSBhcmUgd3JpdHRlbg0KPiB1cCBzaG91bGQgZW5kIHVwIHNhdmluZyB0aW1lLg0KPg0K PiBKdXN0aW4NCj4NCj4NCj4gLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KPiBG cm9tOiBSaWNrIFRheWxvcg0KPiBEYXRlOjA2LzE2LzIwMTUgNTowMCBBTSAoR01ULTA1OjAwKQ0K PiBUbzogIkRlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIiAsIExvdSBCZXJnZXIgLCBtYW5ldC1j aGFpcnNAaWV0Zi5vcmcNCj4gQ2M6IG1hbmV0LWFkc0BpZXRmLm9yZywgcnRnLWRpckBpZXRmLm9y ZywgbWFuZXRAaWV0Zi5vcmcsDQo+IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC5hbGxAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFttYW5ldF0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tYW5ldC1k bGVwLTE0DQo+DQo+IEFsbCwNCj4NCj4gU3RhbiBhbmQgSSBhcmUgY3VycmVudGx5IGRpc2N1c3Np bmcgdGhlIHJldmlldy4gIFdlIHdpbGwgY29tZSBiYWNrIHRvDQo+IHRoZSBsaXN0IHdpdGggYSBw cm9wb3NlZCBzZXQgb2YgYWN0aW9ucyB3aGVuIHdlIGhhdmUgYSBwbGFuLg0KPg0KPiBTb3JyeSBm b3IgdGhlIGRlbGF5LA0KPg0KPiBSaWNrDQo+DQo+DQo+IE9uIDE1LzA2LzE1IDEyOjE2LCBEZWFy bG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSB3cm90ZToNCj4gID4gSSBoYXZlbid0IHNlZW4gYW55IGRp c2N1c3Npb24gb2YgdGhpcy4gSXQgbG9va3MgdG8gbWUgbGlrZSByZXF1aXJpbmcNCj4gYW5vdGhl ciBkcmFmdCBmb3IgdGhlIFdHIHRvIHNlZS4gSXQgZG9lcyAoYnkgbXkgcmFwaWQgY291bnQpIGhh dmUgMTcNCj4gbWFqb3IgaXNzdWVzLg0KPiAgPg0KPiAgPiAtLQ0KPiAgPiBDaHJpc3RvcGhlciBE ZWFybG92ZQ0KPiAgPiBTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQo+ICA+IEJBRSBTeXN0ZW1z IEFwcGxpZWQgSW50ZWxsaWdlbmNlDQo+ICA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICA+DQo+ ICA+IFQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tDQo+ICA+DQo+ICA+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVs bXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQNCj4gQmFkZG93LCBDaGVsbXNmb3JkLCBFc3Nl eCBDTTIgOEhOLg0KPiAgPiB3d3cuYmFlc3lzdGVtcy5jb20vYWkNCj4gID4gQkFFIFN5c3RlbXMg QXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KPiAgPiBSZWdpc3RlcmVkIGluIEVuZ2xhbmQg JiBXYWxlcyBObzogMDEzMzc0NTENCj4gID4gUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNl YXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KPiAgPg0KPiAgPg0KPiAgPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAgPiBGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0 LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb3UgQmVyZ2VyDQo+ICA+IFNlbnQ6IDA4 IEp1bmUgMjAxNSAyMDoxMQ0KPiAgPiBUbzogbWFuZXQtY2hhaXJzQGlldGYub3JnDQo+ICA+IENj OiBtYW5ldC1hZHNAaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmc7IG1hbmV0QGlldGYub3JnOw0K PiBkcmFmdC1pZXRmLW1hbmV0LWRsZXAuYWxsQGlldGYub3JnDQo+ICA+IFN1YmplY3Q6IFttYW5l dF0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLTE0DQo+ICA+DQo+ICA+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRo aXMgbWVzc2FnZQ0KPiBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBl aXRoZXIgZnJvbSBhbiBleHRlcm5hbA0KPiBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Lg0K PiAgPiBDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBs aW5rcywgb3BlbiBhbnkNCj4gYXR0YWNobWVudHMgb3IgcmVwbHkuDQo+ICA+IEZvbGxvdyB0aGUg J1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvcg0KPiBpbnN0 cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQo+ICA+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ICA+DQo+ICA+IFtOb3RlIHRoaXMgaXMgYSBXRyBMQyByZWxhdGVkIHJldmlldywgbm90IElFVEYg TEMuXQ0KPiAgPg0KPiAgPiBIZWxsbywNCj4gID4NCj4gID4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQg YXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMNCj4gZHJhZnQuIFRo ZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvcg0KPiBy b3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxs IGFuZCBJRVNHDQo+IHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QgLS0g b3IgV0cgTGFzdCBjYWxsIGFzIHdhcyB0aGUNCj4gY2FzZSBoZXJlIC4gVGhlIHB1cnBvc2Ugb2Yg dGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlDQo+IFJvdXRpbmcgQURz LiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxl YXNlDQo+IHNlZSDigItodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dp a2kvUnRnRGlyDQo+ICA+DQo+ICA+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJp bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIChjaGFpcnMgYW5kKQ0KPiBSb3V0aW5nIEFEcywgaXQgd291 bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoDQo+IGFu eSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0 byByZXNvbHZlDQo+IHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBk cmFmdC4NCj4gID4NCj4gID4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC0xNA0KPiAg PiBSZXZpZXdlcjogTG91IEJlcmdlcg0KPiAgPiBSZXZpZXcgRGF0ZTogSnVuZSA4IChsYXRlciB0 aGFuIHJlcXVlc3RlZCBkdWUgdG8gc2NvcGUgb2YgY29tbWVudHMgLS0NCj4gc29ycnkpIFdHIExD IEVuZCBEYXRlOiB1bmtub3duIEludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIHRyYWNrDQo+ICA+ DQo+ICA+IFN1bW1hcnk6DQo+ICA+DQo+ICA+ICAgICAgV2hpbGUgSSB0aGluayB0aGUgZG9jdW1l bnQgaXMgcHJldHR5IGRlY2VudCBmb3IgdGhlIHNjb3BlIG9mIHRoZQ0KPiAgPiAgICAgIHdvcmss IEkgZG8gaGF2ZSBjb25jZXJucyBhYm91dCB0aGlzIGRvY3VtZW50IGFuZCByZWNvbW1lbmQgdGhh dCB0aGUNCj4gID4gICAgICBXRyBDaGFpcnMvUm91dGluZyBBRHMgZGlzY3VzcyB0aGVzZSBpc3N1 ZXMgZnVydGhlciB3aXRoIHRoZSBhdXRob3JzLg0KPiAgPiAgICAgIEknbSBhbHNvIGF2YWlsYWJs ZSBhcy9pZiBuZWVkZWQgdG8gZGlzY3Vzcy4NCj4gID4NCj4gID4gQ29tbWVudHM6DQo+ICA+DQo+ ICA+ICAgICAgSSB0aGluayB0aGUgZG9jdW1lbnQgc2hvd3Mgc2lnbmlmaWNhbnQgZ29vZCB3b3Jr IGFuZCBsb29rcyB0byBiZSBhDQo+ICA+ICAgICAgdXNlZnVsIHByb3RvY29sLCBhbHRob3VnaCBJ J20gbm90IG92ZXJseSBmYW1pbGlhciBpbiB0aGlzIHNwYWNlLg0KPiAgPiAgICAgIFRoYXQgc2Fp ZCwgSSBoYXZlIGEgbnVtYmVyIG9mIHNlcmlvdXMgY29uY2VybnMgYWJvdXQgdGhlIGRvY3VtZW50 LA0KPiAgPiAgICAgIGFuZCBpdHMgY29udGVudHMgZnJvbSBhIGZldyBvZiBwZXJzcGVjdGl2ZXMu ICBUaGVzZSBpbmNsdWRlIGJhc2ljDQo+ICA+ICAgICAgcHJvdG9jb2wgaXNzdWVzLCB1bmRlcnNw ZWNpZmllZCBkZXRhaWxzICAod2hpY2ggY291bGQgbGVhZCB0bw0KPiAgPiAgICAgIGludGVyb3Bl cmFiaWxpdHkgaXNzdWVzKSwgYW5kIHNwZWNpZmljYXRpb24vZWRpdG9yaWFsIGlzc3Vlcy4gSQ0K PiAgPiAgICAgIHRoaW5rIHRoZSBkb2N1bWVudCAvIHByb3RvY29sIGNhbiBiZSBtb2RpZmllZCB0 byBhZGRyZXNzIHRoZSBpc3N1ZXMNCj4gID4gICAgICBJIHJhaXNlIGJlbG93LiAgT2YgY291cnNl LCBpdCBpcyB1cCB0byB0aGUgV0csIGNoYWlycywgYW5kIEFEcyB0bw0KPiAgPiAgICAgIGRlY2lk ZSB3aGljaCBjb21tZW50cyB0byBhZGRyZXNzIGFuZCB3aGljaCB0byAgaWdub3JlLg0KPiAgPiAg ICAgIEkgZG9uJ3QgZXhwZWN0IHRoYXQgYWxsIGNvbW1lbnRzIHdpbGwgcmVzdWx0IGluIGNoYW5n ZXMuDQo+ICA+DQo+ICA+IE1ham9yIElzc3VlczoNCj4gID4NCj4gID4gICAgICAtIFRoZSBsZW5n dGggZmllbGQgb2YgdGhlIGdlbmVyaWMgZGF0YSBpdGVtIChpLmUuLCBUTFYpIGlzIG9ubHkgOA0K PiAgPiAgICAgICAgYml0cy4gIFdoaWxlIDI1NSBieXRlcyAoYXNzdW1pbmcgdGhhdCB0aGlzIGlz IHRoZSB1bml0IG9mIG1lYXN1cmUsDQo+ICA+ICAgICAgICB3aGljaCBCVFcgaXNuJ3Qgc3BlY2lm aWVkKSBpcyBiaWcgZW5vdWdoIHRvZGF5LCBhbGxvd2luZyBmb3INCj4gID4gICAgICAgIGxhcmdl ciB3aWxsIGdyZWF0bHkgc2ltcGxpZnkgdGhpbmdzIHdoZW4gMjU1IGlzbid0IGVub3VnaC4gLS0N Cj4gID4gICAgICAgIFdlJ3ZlIHJ1biBpbnRvIHRoaXMgaW4gUlNWUCBhbmQgaXQncyBhIHJlYWwg cGFpbi4NCj4gID4NCj4gID4gICAgICAtIFZlcnNpb24gbnVtYmVyIGlzIGN1cnJlbnRseSBkZWZp bmVkIGFzIGEgZGF0YSBpdGVtLiAgVGhpcyBtZWFucyBhDQo+ICA+ICAgICAgICBzaWduYWwgKGku ZS4sIG1lc3NhZ2UpIG5lZWRzIHRvIGJlIHBvdGVudGlhbGx5IGZ1bGx5IHBhcnNlZCB0bw0KPiAg PiAgICAgICAgZGlzY292ZXIgd2hhdCB2ZXJzaW9uIGlzIGJlaW5nIHVzZWQuICBUaGlzIHByZWNs dWRlcyBiYXNpYyBmb3JtYXQNCj4gID4gICAgICAgIGNoYW5nZXMgdG8gdGhlIHByb3RvY29sLiAg UGVyaGFwcyB0aGUgRGlzY292ZXJ5IGFuZCBJbml0IFNpZ25hbHMNCj4gID4gICAgICAgIHNob3Vs ZCBiZSBzcGVjaWFsIGNhc2VkIHRvIGluY2x1ZGUgdmVyc2lvbiBpbiB0aGVpciBmb3JtYXRzLiAg KEFuZA0KPiAgPiAgICAgICAgc2hvcnRlbiB2ZXJzaW9uIHRvIDggYml0cyBmcm9tIDMyLCBhcyBt ZW50aW9uZWQgYmVsb3cpLg0KPiAgPg0KPiAgPiAgICAgIC0gVGhlIGRvY3VtZW50IHJlZmVyZW5j ZXMsIGJ1dCBkb2VzIG5vdCBkZWZpbmUsICdpbi1zZXNzaW9uJyBhbmQNCj4gID4gICAgICAgICdk aXNjb3ZlcnknIHN0YXRlcy4gIFRoZXNlIGVpdGhlciBuZWVkIHRvIGJlIGZvcm1hbGx5IGRlZmlu ZWQgb3INCj4gID4gICAgICAgIHJlbW92ZWQuICBCVFcgd2UgaGFkIGV4YWN0bHkgdGhlIHNhbWUg aXNzdWUgd2l0aCBMTVAgKFJGQzQyMDQpIGFuZA0KPiAgPiAgICAgICAgZW5kZWQgdXAgYWRkaW5n IHNlY3Rpb24gMTEgKEZTTXMpIGF0IGEgcHJldHR5IGxhdGUgc3RhZ2Ugb2YgdGhlDQo+ICA+ICAg ICAgICBwcm9jZXNzLg0KPiAgPg0KPiAgPiAgICAgIC0gVENQIHNlc3Npb24gbWFuYWdlbWVudCBp cyBub3QgZGVmaW5lZCwgbm9yIGlzIHRoZSByZWxhdGlvbnNoaXANCj4gID4gICAgICAgIHdpdGgg VENQIGFuZCBETEVQIHNlc3Npb25zIGZ1bGx5IGRlZmluZWQuICBGb3IgZXhhbXBsZToNCj4gID4N Cj4gID4gICAgICAgIG8gQ2xvc2luZyB0aGUgVENQIHNlc3Npb24gaXMgb25seSBtZW50aW9uZWQg aW4gb25lIHBsYWNlIGFuZCBpbiBhDQo+ICA+ICAgICAgICAgIHdheSB0aGF0IGlzIGluY29uc2lz dGVudCB3aXRoIHRoZSBleHBlY3RlZCBwcm90b2NvbCBiZWhhdmlvcg0KPiAgPiAgICAgICAgICAo Y2xvc2UgVENQIGJlZm9yZSBBQ0sgaXMgcmVjZWl2ZWQpLg0KPiAgPg0KPiAgPiAgICAgICAgbyBX aGF0IGhhcHBlbnMgd2hlbiBhIERMRVAgc2Vzc2lvbiBpcyB0ZXJtaW5hdGVkLCBjYW4gdGhlIFRD UA0KPiAgPiAgICAgICAgICBzZXNzaW9uIGJlIHJldXNlZCBvciBtdXN0IGl0IGJlIGNsb3NlZCB0 b28/DQo+ICA+DQo+ICA+ICAgICAgLSBUaGVyZSBpcyBubyB0cmFuc2FjdGlvbiBtb2RlbCBkZWZp bmVkLiAgRm9yIGV4YW1wbGUsIGl0J3MNCj4gID4gICAgICAgIGNvbXBsZXRlbHkgdW5jbGVhciBp ZiBvbmx5IG9uZSB1bmFja25vd2xlZGdlZCBTaWduYWwgYWxsb3dlZCBhdCBhDQo+ICA+ICAgICAg ICB0aW1lLCBvciBwZXJoYXBzIGp1c3Qgb25lIHBlciBzaWduYWwgdHlwZSBpcyBhbGxvd2VkLCBv ciBwZXJoYXBzDQo+ICA+ICAgICAgICB0aGVyZSBhcmUgbm8gcmVzdHJpY3Rpb25zLiAgVGhpcyBu ZWVkcyB0byBiZSBleHBsaWNpdC4NCj4gID4NCj4gID4gICAgICAtIFdoYXQgaXMgdGhlIHB1cnBv c2Ugb2YgcmV0cmllcyBhbmQgdGltZW91dHMgb3ZlciBUQ1A/ICBSZXRyaWVzDQo+ICA+ICAgICAg ICBhcmVuJ3QgbmVlZGVkIG92ZXIgVENQcyBhbmQgaXQncyB1bmNsZWFyIHdoZXkgdGhleSBhcmUg YmVpbmcgdXNlZC4NCj4gID4NCj4gID4gICAgICAtIFRoZSBoaWdoZXIgbGV2ZWwgaW1wbGljYXRp b25zIG9mIEFDS3MsIG92ZXIgVENQLCBpc24ndCByZWFsbHkNCj4gID4gICAgICAgIGNsZWFyLiAg SXQgc2VlbXMgQUNLcyBhcmUgZGVmaW5lZCBmb3IgbXVsdGlwbGUgcHVycG9zZXM6IHJlbGlhYmxl DQo+ICA+ICAgICAgICB0cmFuc3BvcnQsIHRyYW5zYWN0aW9uIGFja25vd2xlZGdtZW50IGFuZCB0 cmFuc2FjdGlvbiByZXN1bHRzLiBPZg0KPiAgPiAgICAgICAgY291cnNlIHRoZSBmaXJzdCBpc24n dCBuZWVkZWQsIGFuZCBpbXBsaWNhdGlvbnMgb2YgdGhlIG90aGVycw0KPiAgPiAgICAgICAgc2hv dWxkIGJlIGNsZWFyLiAgRm9yIGV4YW1wbGUsIGluIHNlY3Rpb24gNy4xMCwgd2h5IHdvdWxkIHRo ZXJlIGJlDQo+ICA+ICAgICAgICBhIHJldHJ5IHdoZW4gcmVjZWl2aW5nIGEgRGVzdGluYXRpb24g VXAgQUNLIHNpZ25hbCBpbmRpY2F0aW5nIGFuDQo+ICA+ICAgICAgICBlcnJvcj8NCj4gID4NCj4g ID4gICAgICAtIFRoZXJlIGlzIG5vIGRpc2N1c3Npb24gb24gc2NhbGluZyBjb25zaWRlcmF0aW9u cy4gQXJlIHRoZXJlIHJlYWxseQ0KPiAgPiAgICAgICAgbm9uZT8gIEZvciBleGFtcGxlLCBob3cg b2Z0ZW4gbWlnaHQgYmUgYXBwcm9wcmlhdGUgdG8gaXNzdWUvbGltaXQNCj4gID4gICAgICAgIFBl ZXIgVXBkYXRlcyBiYXNlZCB0byBjaGFuZ2VzIGluIGxpbmsgcXVhbGl0eSwgb3IgaG93IHRvIGhh bmRsZQ0KPiAgPiAgICAgICAgdGhlIGNhc2Ugd2hlcmUgYSBsYXJnZSBudW1iZXIgKGFsbCBvciBt b3N0KSBvZiBkZXN0aW5hdGlvbnMgZ28NCj4gID4gICAgICAgIGRvd24uDQo+ICA+DQo+ICA+ICAg ICAgLSBUaGVyZSBhcmUgMTMgcGxhY2VzIHdoZXJlIHRoZSBwcm90b2NvbCBhbGxvd3MgaW1wbGVt ZW50YXRpb24gdG8NCj4gID4gICAgICAgIGRlZmluZSB0aGVpciBvd24gJ2hldXJpc3RpY3MnLiAg U29tZSBvZiB0aGVzZSBzZWVtIHVubmVjZXNzYXJ5IGR1ZQ0KPiAgPiAgICAgICAgdG8gdGhlIFRD UCBwb2ludCByYWlzZWQgYWJvdmUsIGJ1dCBhbnkgdGhhdCByZW1haW4gaW4gdGhlIHByb3RvY29s DQo+ICA+ICAgICAgICBzaG91bGQgYmUgZnVsbHkgc3BlY2lmaWVkIHRvIGVuc3VyZSBwcmVkaWN0 YWJsZS9jb25zaXN0ZW50DQo+ICA+ICAgICAgICBiZWhhdmlvciBmcm9tIGltcGxlbWVudGF0aW9u cy4NCj4gID4NCj4gID4gICAgICAtIERhdGEgSXRlbXMgYXJlIGRlZmluZWQgZm9yICJFeHRlbnNp b25zIiBhbmQgIkV4cGVyaW1lbnRhbA0KPiAgPiAgICAgICAgRGVmaW5pdGlvbiIgKFNlY3Rpb25z IDguNyBhbmQgOC44KS4gIEJvdGggc2VlbSB0byBzdXBwb3J0IGZvcg0KPiAgPiAgICAgICAgb3B0 aW9uYWwgbWVjaGFuaXNtcywgYnV0IHRoZSBmb3JtZXIgdXNlcyBhc3NpZ25lZCBudW1lcmljIHZh bHVlcywNCj4gID4gICAgICAgIHdoeSB0aGUgbGF0dGVyIHVzZXMgVVRGLTggc3RyaW5ncy4NCj4g ID4gICAgICAgIG8gV2hhdCwgaWYgYW55LCBpcyB0aGUgaW50ZW5kZWQgZGlzdGluY3Rpb24vcmVs YXRpb25zaGlwIGJldHdlZW4NCj4gID4gICAgICAgICAgdGhlc2U/DQo+ICA+ICAgICAgICBvIEhv dyBkb2VzIGFuICJFeHBlcmltZW50YWwgRGVmaW5pdGlvbiIgYmVjb21lIHN0YW5kYXJkaXplZD8N Cj4gID4NCj4gID4gICAgICAtIFNlY3Rpb25zIDguMTkgYW5kIDguMjAgZGVmaW5lICJSZXNvdXJj ZXMiIHJlbGF0ZWQgRGF0YSBJdGVtcy4gIFRoZQ0KPiAgPiAgICAgICAgZGVmaW5pdGlvbiByZWxh dGVkIHRvIHRoZXNlIGJhc2ljYWxseSBzYXlzIGEgcmVzb3VyY2VzIGlzICJBbg0KPiAgPiAgICAg ICAgOC1iaXQgaW50ZWdlciBwZXJjZW50YWdlLCAwLTEwMCwgcmVwcmVzZW50aW5nIHRoZSBhbW91 bnQgb2YNCj4gID4gICAgICAgIHJlc291cmNlcyBhbGxvY2F0ZWQgdG8gcmVjZWl2aW5nfHRyYW5z bWl0dGluZyBkYXRhLiIuICBJZiBJIHdlcmUNCj4gID4gICAgICAgIGltcGxlbWVudGluZyB0aGlz IHByb3RvY29sLCBJJ2QgaGF2ZSBubyBpZGVhIGhvdyB0byBwcm9kdWNlLA0KPiAgPiAgICAgICAg dXBkYXRlIG9yIHVzZSB0aGlzIGluZm9ybWF0aW9uLiAgSSB0aGluayB0aGVyZSBpcyBzb21lIG1p c3NpbmcNCj4gID4gICAgICAgIGluZm9ybWF0aXZlIGFuZCBub3JtYXRpdmUgKFJGQyAyMTE5KSB0 ZXh0IHJlbGF0ZWQgdG8gdGhlc2UNCj4gID4gICAgICAgIGZvcm1hdHMuDQo+ICA+DQo+ICA+ICAg ICAgLSBTZWN0aW9ucyA4LjIxIGFuZCA4LjIyIChSZWxhdGl2ZSBMaW5rIFF1YWxpdHkpIGhhdmUg YSBzaW1pbGFyDQo+ICA+ICAgICAgICBwcm9ibGVtIG9mIGJlaW5nIHVuZGVyIGRlc2NyaWJlZCwg aW4gcGFydGljdWxhciBpdCdzIHVuY2xlYXIgaWYNCj4gID4gICAgICAgIHRoZXJlJ3MgYSBtZWFu aW5nZnVsLCBub24tcHJvcHJpZXRhcnkgZGVmaW5pdGlvbiBmb3IgbGluayBxdWFsaXR5DQo+ICA+ ICAgICAgICB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGlzIHRvIGFjdCBvbiBvciBpZiB0aGUgcGFz c2VkIHZhbHVlIGlzIGp1c3QNCj4gID4gICAgICAgIHBhc3NlZCBmb3IgYXMgbW9uaXRvcmluZyBp bmZvcm1hdGlvbi4gIEVpdGhlciB3YXksIHRoaXMgbmVlZHMgdG8NCj4gID4gICAgICAgIGJlIGNs YXJpZmllZC4NCj4gID4NCj4gID4gICAgICAtIFNlY3Rpb24gOSBkZWZpbmVzIGEgImNyZWRpdC13 aW5kb3dpbmcgc2NoZW1lIGFuYWxvZ291cyB0byB0aGUgb25lDQo+ICA+ICAgICAgICBkb2N1bWVu dGVkIGluIFtSRkM1NTc4XSIuIEl0IGRlc2NyaWJlcyBob3cgY3JlZGl0cyBhcmUgZXhjaGFuZ2Vk LA0KPiAgPiAgICAgICAgYnV0IGl0IHByb3ZpZGVzIHplcm8gZGVmaW5pdGlvbiBvbiB0aGUgaW1w bGljYXRpb25zIG9yIHVzZSBvZg0KPiAgPiAgICAgICAgY3JlZGl0cyByZWxhdGl2ZSB0byB0aGUg ZGF0YSBwbGFuZS4NCj4gID4NCj4gID4gICAgICAtIE11bHRpcGxlIHdheXMgdG8gaW1wbGVtZW50 IHRoZSBzYW1lIGZ1bmN0aW9uIGFyZSBhbGxvd2VkLCBlLmcuLA0KPiAgPiAgICAgICAgb3B0aW9u YWwgcHJlc2VuY2Ugb2YgU3RhdHVzLCBJbnRlcnZhbCBhbmQgVENQIHBvcnQuICBHZW5lcmFsbHkN Cj4gID4gICAgICAgIGFsbG93aW5nIHN1Y2ggY29tcGxpY2F0ZXMgdGVzdGluZyBhbmQgbGVhZHMg dG8gaW50ZXJvcGVyYWJpbGl0eQ0KPiAgPiAgICAgICAgaXNzdWVzLiAgVGhlIGRvY3VtZW50IHNo b3VsZCBwaWNrIG9uZSB3YXkgYW5kIHJlcXVpcmUgaXQuDQo+ICA+DQo+ICA+ICAgICAgLSBUaGUg ZG9jdW1lbnQgZG9lc24ndCBzdGF0ZSBpZiB0aGVyZSBhcmUgYW55IG9yZGVyaW5nIHJlcXVpcmVt ZW50cw0KPiAgPiAgICAgICAgb24gZGF0YSBpdGVtcy4gSXQgc2hvdWxkIGJlIGV4cGxpY2l0IG9u IHRoaXMsIGUuZy4sIHRoZXJlIGFyZSBubw0KPiAgPiAgICAgICAgb3JkZXJpbmcgcmVxdWlyZW1l bnRzIG9uIHRoZSBwbGFjZW1lbnQgb2YgRGF0YSBJdGVtcyB3aXRoaW4NCj4gID4gICAgICAgIFNp Z25hbHMuDQo+ICA+DQo+ICA+ICAgICAgLSBUaGUgcmVxdWlyZWQgYW5kIG9wdGlvbmFsIGRhdGEg aXRlbXMgdGhhdCBhcmUgcGVybWl0dGVkIG9uIGENCj4gID4gICAgICAgIHNpZ25hbCBpc24ndCBh bHdheXMgY2xlYXIuICBGb3IgZXhhbXBsZSBhcmUgMC8xL04gY29waWVzIG9mIGENCj4gID4gICAg ICAgIHBhcnRpY3VsYXIgRGF0YSBJdGVtIHJlcXVpcmVkL2FsbG93ZWQuICBVc2luZyBzb21ldGhp bmcgbGlrZSBBQk5GDQo+ICA+ICAgICAgICB3b3VsZCByZWFsbHkgaGVscCBmb3JtYWxpemUgYW5k IGNsYXJpZnkgdGhpcy4NCj4gID4NCj4gID4gICAgICAtIFRoZSBkb2N1bWVudCBkb2Vzbid0IGNs ZWFybHkgZGVsaW5lYXRlIGZyb20gaW5mb3JtYXRpdmUvbmFycmF0aXZlDQo+ICA+ICAgICAgICB0 ZXh0LCBub3JtYXRpdmUgLyByZXF1aXJlZCBwcm9jZXNzaW5nIHByb2NlZHVyZXMsIGFuZCBtZXNz YWdlDQo+ICA+ICAgICAgICBmb3JtYXRzLiBUaGlzIGJ5IGl0c2VsZiBpcyBub3QgbmVjZXNzYXJp bHkgYSBtYWpvciBpc3N1ZSwgaXQganVzdA0KPiAgPiAgICAgICAgbWFrZXMgaXQgaGFyZGVyIHRv ICh3cml0ZSwpIHJldmlldyBhbmQgaW1wbGVtZW50IHRoZSBwcm90b2NvbC4NCj4gID4gICAgICAg IFdoYXQgaXMgYSBtYWpvciBpc3N1ZSBpcyB0aGF0IHRoaXMgYXBwcm9hY2ggYWxsb3dzIGZvciBk dXBsaWNhdGUNCj4gID4gICAgICAgIChhbmQgc29tZXRpbWVzIGNvbnRyYWRpY3RvcnkpIG5vcm1h dGl2ZSBwcm9jZWR1cmVzIGFuZCBmb3INCj4gID4gICAgICAgIG9taXNzaW9ucyBpbiBwcm9jZWR1 cmVzIChwYXJ0aWN1bGFybHkgcmVsYXRlZCB0byBleGNlcHRpb24vZXJyb3INCj4gID4gICAgICAg IHByb2Nlc3NpbmcpLiAgU3BlY2lmaWMgZXhhbXBsZXMgYXJlIGluY2x1ZGVkIGFib3ZlIGFuZCBi ZWxvdy4gIEl0DQo+ICA+ICAgICAgICB3b3VsZCBiZSBiZXN0IHRvIGVuc3VyZSB0aGF0IGVhY2gg cmVxdWlyZWQgcHJvY2Vzc2luZyBiZWhhdmlvciBpcw0KPiAgPiAgICAgICAgZGVmaW5lZCBqdXN0 IG9uY2UgYW5kIGluIGEgY29uc2lzdGVudCB3YXkuDQo+ICA+DQo+ICA+ICAgICAgLSBUaGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGlzIGluYWRlcXVhdGUuICBUaGlzIHNlY3Rpb24N Cj4gID4gICAgICAgIHNob3VsZCBhZGRyZXNzIHRoZSBzZWN1cml0eSBvZiB0aGUgRExFUCBwcm90 b2NvbCwgbm90IHVzZXINCj4gID4gICAgICAgIHRyYWZmaWMuICBJdCBzaG91bGQgaW5jbHVkZSBh biBhbmFseXNpcyBvZiByaXNrcy90aHJlYXRzL3Bvc3NpYmxlDQo+ICA+ICAgICAgICBleHBsb2l0 cyBhbmQgaG93IHRoZXNlIGFyZSBtaXRpZ2F0ZWQgYnkgdGhlIHByb3RvY29sLiAgcmZjNjk1MiwN Cj4gID4gICAgICAgIGFuZCB0aGUgcHJvdG9jb2xzIGl0IHJlZmVyZW5jZXMgY2FuIHNlcnZlIGFz IGV4YW1wbGVzLg0KPiAgPg0KPiAgPiBNaW5vciBJc3N1ZXM6DQo+ICA+DQo+ICA+ICAgICAgLSBU aGUgZGF0YSBhbmQgc2lnbmFsIHR5cGUgZmllbGRzIGFyZSBib3RoIDggYml0cy4gIFRoaXMgc2Vl bXMNCj4gID4gICAgICAgIHByZXR0eSBzbWFsbCwgcGFydGljdWxhcmx5IHRoZSBkYXRhIHR5cGUg ZmllbGQuICBHaXZlbiB0aGlzIGlzIGENCj4gID4gICAgICAgIGNvbnRyb2wgcHJvdG9jb2wsIEkg dGhpbmsgYSBsYXJnZXIgKGF0IGxlYXN0IGRhdGEgdHlwZSkgZmllbGQNCj4gID4gICAgICAgIHdv dWxkIHByb3ZpZGUgYmV0dGVyICJmdXR1cmUgcHJvb2ZpbmciLg0KPiAgPg0KPiAgPiAgICAgIC0g Ml4zMiB2ZXJzaW9ucyBhcmUgY3VycmVudGx5IGFsbG93ZWQgKHNlY3Rpb24gOC4xKS4gIFRoaXMg c2VlbXMgYQ0KPiAgPiAgICAgICAgYml0IGV4Y2Vzc2l2ZS4gIEknZCBvcHQgZm9yIG1heCBvZiA4 IGJpdHMgaGVyZSBteXNlbGYuDQo+ICA+DQo+ICA+ICAgICAgLSBJdCdzIHByb2JhYmx5IHRvbyBs YXRlLCBidXQgaXQgcHJvYmFibHkgd291bGQgYmUgY2xlYW5lciB0byBoYXZlIGENCj4gID4gICAg ICAgIGdlbmVyaWMgYWNrIHNpZ25hbCByYXRoZXIgdGhhbiBhIHBlciBzaWduYWwgdHlwZSBhY2su IEkgbWVudGlvbg0KPiAgPiAgICAgICAgdGhpcyBoZXJlIGFzIHRoaXMgbWF5IGNvbWUgdXAgYWdh aW4gd2hlbiBjbGFyaWZ5aW5nIHRoZQ0KPiAgPiAgICAgICAgdHJhbnNhY3Rpb24gbW9kZWwgKGFz IG1lbnRpb25lZCBhYm92ZS4pDQo+ICA+DQo+ICA+ICAgICAgLSBTZWN0aW9uIDI6IEFzc3VtcHRp b25zDQo+ICA+ICAgICAgICBUaGlzIHNlY3Rpb24gaW5jbHVkZXMgaW5mb3JtYXRpdmUgYW5kIG5v cm1hdGl2ZSB0ZXh0IHNvIGlzIG1vcmUNCj4gID4gICAgICAgIHRoYW4ganVzdCBBc3N1bXB0aW9u cy4gIFBlcnNvbmFsbHksIEknZCByZW1vdmUgYWxsIG5vcm1hdGl2ZSB0ZXh0DQo+ICA+ICAgICAg ICBmcm9tIHRoZSBzZWN0aW9uLg0KPiAgPg0KPiAgPiAgICAgIC0gVGhlcmUgYXJlIG5vIHNwZWNp ZmljIHJ1bGVzIHJlbGF0ZWQgdG8gVURQIGhlYWRlciBmb3JtYXRpb24uDQo+ICA+DQo+ICA+ICAg ICAgLSBTZWN0aW9ucyA4LjEwLT44LjE3LiAgSXNuJ3QgYWRkL2Ryb3AgaW5kaWNhdG9yIG5lZWRl ZCBmb3Igc3VibmV0cw0KPiAgPiAgICAgICAgaW4gZGVzdGluYXRpb24gdXBkYXRlIHNpZ25hbHM/ DQo+ICA+DQo+ICA+ICAgICAgLSBUaGUgSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9ucyBtdXN0 IGZvbGxvd+KAiyBSRkMyMzYwLg0KPiAgPg0KPiAgPiAgICAgIC0gTmV3IHJlZ2lzdHJpZXMgbXVz dCBpbmNsdWRlIGluaXRpYWwgdmFsdWVzLCB3aGljaCBhcmUgZGVmaW5lZCBpbg0KPiAgPiAgICAg ICAgdGhlIGRvY3VtZW50LiAgKFRoZSBkb2N1bWVudCBjdXJyZW50bHkgaGFzIG1hbnkgVEJEcyB0 aGF0IHNob3VsZA0KPiAgPiAgICAgICAgYmUgcmVwbGFjZWQuKQ0KPiAgPg0KPiAgPiAgICAgIC0g TmV3IHJlZ2lzdHJpZXMgbmVlZCBhbiBhbGxvY2F0aW9uIHBvbGljeSwgZS5nLjoNCj4gID4gICAg ICBUaGUgcmVnaXN0cnkgc2hvdWxkIGJlIGVzdGFibGlzaGVkIHdpdGggcmVnaXN0cmF0aW9uIHBv bGljaWVzIG9mDQo+ICA+ICAgICAgIlN0YW5kYXJkcyBBY3Rpb24iIChmb3IgU3RhbmRhcmRzIFRy YWNrIGRvY3VtZW50cykgYW5kDQo+ICA+ICAgICAg4oCcU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCIg KGZvciBvdGhlciBkb2N1bWVudHMpLiBUaGUgZGVzaWduYXRlZA0KPiAgPiAgICAgIGV4cGVydCBp cyBhbnkgY3VycmVudCA8ZmlsbC1pbj4gV0cgY2hhaXIuDQo+ICA+DQo+ICA+IE5pdHM6DQo+ICA+ DQo+ICA+ICAgICAgLSBUaGUgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgdGVybXMgInNpZ25hbHMi IGFuZCAiZGF0YSBpdGVtcyIgZm9yDQo+ICA+ICAgICAgICB3aGF0IGlzIGNvbW1vbmx5IGNhbGxl ZCAibWVzc2FnZXMiIGFuZCAiVExWcyIgKG9yIG9iamVjdHMpIGluDQo+ICA+ICAgICAgICBvdGhl ciBwcm90b2NvbHMuICBJdCdzIHByb2JhYmx5IHRvbyBsYXRlIHRvIGNoYW5nZSB0aGlzLCBidXQg SQ0KPiAgPiAgICAgICAgdGhpbmsgdGhlIGludHJvZHVjdGlvbiBvZiB1bmlxdWUgdGVybWlub2xv Z3kgaXMgY291bnRlcg0KPiAgPiAgICAgICAgcHJvZHVjdGl2ZS4NCj4gID4NCj4gID4gICAgICAt IFVzZSBvZiBSRkMgMjExOSBjb25mb3JtYW5jZSBsYW5ndWFnZSBpcyBhIGJpdCByb3VnaCwgYW5k IHRoZXJlIGFyZQ0KPiAgPiAgICAgICAgd29yZHMgaW4gYWxsIGNhcHMgdGhhdCBhcmUgbm90IGRl ZmluZWQgaW4gUkZDMjExOS4gVGFrZSBhIGxvb2sgYXQNCj4gID4gICAgICAgIGh0dHA6Ly90cmFj LnRvb2xzLmlldGYub3JnL3dnL3RlYXMvdHJhYy93aWtpL1BTR3VpZGVsaW5lIGZvciBzb21lDQo+ ICA+ICAgICAgICBzdWdnZXN0aW9ucy4NCj4gID4NCj4gID4gICAgICAtIEludGVybmFsIHNvY2tl dCBvcGVyYXRpb24gaXMgbWVudGlvbmVkIGEgY291cGxlIG9mIHRpbWVzLiAgSXQNCj4gID4gICAg ICAgIHJlYWxseSBzaG91bGRuJ3QgYmUsIHRoZSBzcGVjIHNob3VsZCBkZWZpbmUgYmVoYXZpb3Ig b24gdGhlIHdpcmUuDQo+ICA+DQo+ICA+ICAgICAgLSBUaGUgTGVuZ3RoIGZpZWxkcyBhcmUgbWlz c2luZyB1bml0IG9mIG1lYXN1cmUgKHByZXN1bWFibHkgb2N0ZXRzKQ0KPiAgPg0KPiAgPiAgICAg IC0gVGhlIE1uZW1vbmljcyBhcmUgdXNlZCBiYXNpY2FsbHkgb25jZSBhbmQgZG9uJ3QgcmVhbGx5 IGFkZCB2YWx1ZSwNCj4gID4gICAgICAgIHN1Z2dlc3QgZHJvcHBpbmcgdGhlbS4NCj4gID4NCj4g ID4gICAgICAtIEhvdy93aGVuIGlzIHRoZSAiVW5rbm93biBTaWduYWwiIFN0YXR1cyBDb2RlIHNl bnQ/DQo+ICA+DQo+ICA+ICAgICAgLSBTZWN0aW9uIDguNzogRXh0ZW5zaW9uIExpc3Qgc2hvdWxk IGJlIHNob3duIGFzIGEgdmFyaWFibGUgbGVuZ3RoDQo+ICA+ICAgICAgICBmaWVsZC4NCj4gID4N Cj4gID4gICAgICAtIFNlY3Rpb24gOC44OiBFeHBlcmltZW50IExpc3Qgc2hvdWxkIGJlIHNob3du IGFzIGEgdmFyaWFibGUgbGVuZ3RoDQo+ICA+ICAgICAgICBmaWVsZC4NCj4gID4NCj4gID4gVGhh dCdzIGl0IC0tIGZvciBub3cgLS0gaG9wZWZ1bGx5IEkgZGlkbid0IG1pc3MgYW55dGhpbmcuICBM b29rDQo+IGZvcndhcmQgdG8gaGVhcmluZyByZXNwb25zZSB0byB0aGUgYWJvdmUgKGFuZCBob3cg SSBnb3QgdGhpbmdzDQo+IGhvcGVsZXNzbHkgd3JvbmcgOy0pDQo+ICA+DQo+ICA+IExvdQ0KPiAg Pg0KPiAgPg0KPiAgPg0KPiAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiAgPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gID4gbWFuZXRAaWV0Zi5vcmcN Cj4gID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPiAgPiAq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0KPiAgPiBUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCB0byB0aGUgaW50ZW5kZWQNCj4gID4gcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCj4gID4gcmVjaXBpZW50IHBs ZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQo+ ICA+IFlvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3Ig ZGlzY2xvc2Ugb3INCj4gID4gZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbi4NCj4gID4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCj4gID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gID4gbWFuZXQgbWFpbGluZyBsaXN0DQo+ICA+IG1hbmV0 QGlldGYub3JnDQo+ICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFu ZXQNCj4gID4NCj4NCg0K From nobody Tue Jun 16 05:54:07 2015 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 297E11B33FC; Tue, 16 Jun 2015 05:54:05 -0700 (PDT) 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 GMPCa-jBXoPt; Tue, 16 Jun 2015 05:53:59 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 82E871B33F1; Tue, 16 Jun 2015 05:53:46 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.201 as permitted sender) identity=mailfrom; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,626,1427774400"; d="scan'208,217";a="8030844" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.201]) by ironport2.idirect.net with ESMTP; 16 Jun 2015 08:53:46 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM1.idirect.net (10.250.250.201) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 16 Jun 2015 08:53:44 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Tue, 16 Jun 2015 08:53:44 -0400 From: "Ratliff, Stanley" To: bebemaster , Rick Taylor , "Dearlove, Christopher (UK)" , Lou Berger , "manet-chairs@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqCcaMo+Tw3COyECGObxkTDTDb52vFo+A Date: Tue, 16 Jun 2015 12:53:43 +0000 Message-ID: <75a095cff2c2410d9cf1cd35fc60657e@VAUSDITCHM3.idirect.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: multipart/alternative; boundary="_000_75a095cff2c2410d9cf1cd35fc60657eVAUSDITCHM3idirectnet_" MIME-Version: 1.0 Archived-At: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , "manet@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 12:54:05 -0000 --_000_75a095cff2c2410d9cf1cd35fc60657eVAUSDITCHM3idirectnet_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 QXMgUmljayBzYWlkIOKAkyB3ZSB3aWxsIHdoZW4gd2UgaGF2ZSBhIHBsYW4uDQoNClN0YW4NCg0K DQoNCkZyb206IGJlYmVtYXN0ZXIgW21haWx0bzpiZWJlbWFzdGVyQGdtYWlsLmNvbV0NClNlbnQ6 IFR1ZXNkYXksIEp1bmUgMTYsIDIwMTUgNzoyNSBBTQ0KVG86IFJpY2sgVGF5bG9yOyBEZWFybG92 ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgTG91IEJlcmdlcjsgbWFuZXQtY2hhaXJzQGlldGYub3JnDQpD YzogbWFuZXQtYWRzQGlldGYub3JnOyBydGctZGlyQGlldGYub3JnOyBtYW5ldEBpZXRmLm9yZzsg ZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLmFsbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5ldF0g UnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLTE0DQoNCkl0IHdvdWxkIGJlIGFw cHJvcHJpYXRlIHRvIGhhdmUgc29tZSBvZiB0aGF0IGRpc2N1c3Npb24gb24gdGhlIGxpc3QuIFRo ZXJlIGlzIHF1aXRlIGEgbG90IG9mIGludGVyZXN0IGluIHRoaXMgZHJhZnQgd2l0aGluIHRoZSB3 ZyBhbmQgZ2V0dGluZyBpbnB1dCBvbiBiZXN0IHdheXMgZm9yd2FyZCBvbiB0aGUgdmFyaW91cyBm aXhlcyBiZWZvcmUgdGhleSBhcmUgd3JpdHRlbiB1cCBzaG91bGQgZW5kIHVwIHNhdmluZyB0aW1l Lg0KDQpKdXN0aW4NCg0KLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KRnJvbTog UmljayBUYXlsb3INCkRhdGU6MDYvMTYvMjAxNSA1OjAwIEFNIChHTVQtMDU6MDApDQpUbzogIkRl YXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIiAsIExvdSBCZXJnZXIgLCBtYW5ldC1jaGFpcnNAaWV0 Zi5vcmc8bWFpbHRvOm1hbmV0LWNoYWlyc0BpZXRmLm9yZz4NCkNjOiBtYW5ldC1hZHNAaWV0Zi5v cmc8bWFpbHRvOm1hbmV0LWFkc0BpZXRmLm9yZz4sIHJ0Zy1kaXJAaWV0Zi5vcmc8bWFpbHRvOnJ0 Zy1kaXJAaWV0Zi5vcmc+LCBtYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+LCBk cmFmdC1pZXRmLW1hbmV0LWRsZXAuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1hbmV0 LWRsZXAuYWxsQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFttYW5ldF0gUnRnRGlyIHJldmlldzog ZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLTE0DQoNCkFsbCwNCg0KU3RhbiBhbmQgSSBhcmUgY3VycmVu dGx5IGRpc2N1c3NpbmcgdGhlIHJldmlldy4gIFdlIHdpbGwgY29tZSBiYWNrIHRvDQp0aGUgbGlz dCB3aXRoIGEgcHJvcG9zZWQgc2V0IG9mIGFjdGlvbnMgd2hlbiB3ZSBoYXZlIGEgcGxhbi4NCg0K U29ycnkgZm9yIHRoZSBkZWxheSwNCg0KUmljaw0KDQoNCk9uIDE1LzA2LzE1IDEyOjE2LCBEZWFy bG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSB3cm90ZToNCj4gSSBoYXZlbid0IHNlZW4gYW55IGRpc2N1 c3Npb24gb2YgdGhpcy4gSXQgbG9va3MgdG8gbWUgbGlrZSByZXF1aXJpbmcgYW5vdGhlciBkcmFm dCBmb3IgdGhlIFdHIHRvIHNlZS4gSXQgZG9lcyAoYnkgbXkgcmFwaWQgY291bnQpIGhhdmUgMTcg bWFqb3IgaXNzdWVzLg0KPg0KPiAtLQ0KPiBDaHJpc3RvcGhlciBEZWFybG92ZQ0KPiBTZW5pb3Ig UHJpbmNpcGFsIEVuZ2luZWVyDQo+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+DQo+IFQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNo cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbT4NCj4NCj4gQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2Zv cmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4 SE4uDQo+IHd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2Fp Pg0KPiBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQo+IFJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KPiBSZWdpc3RlcmVkIE9mZmljZTog U3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQo+DQo+DQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1hbmV0IFttYWlsdG86bWFuZXQt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvdSBCZXJnZXINCj4gU2VudDogMDggSnVu ZSAyMDE1IDIwOjExDQo+IFRvOiBtYW5ldC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0LWNo YWlyc0BpZXRmLm9yZz4NCj4gQ2M6IG1hbmV0LWFkc0BpZXRmLm9yZzxtYWlsdG86bWFuZXQtYWRz QGlldGYub3JnPjsgcnRnLWRpckBpZXRmLm9yZzxtYWlsdG86cnRnLWRpckBpZXRmLm9yZz47IG1h bmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz47IGRyYWZ0LWlldGYtbWFuZXQtZGxl cC5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbWFuZXQtZGxlcC5hbGxAaWV0Zi5vcmc+ DQo+IFN1YmplY3Q6IFttYW5ldF0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tYW5ldC1kbGVw LTE0DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5p c2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVy bmV0Lg0KPiBDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFu eSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQo+IEZvbGxvdyB0aGUgJ1Jl cG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlv bnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IFtOb3Rl IHRoaXMgaXMgYSBXRyBMQyByZWxhdGVkIHJldmlldywgbm90IElFVEYgTEMuXQ0KPg0KPiBIZWxs bywNCj4NCj4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUg cmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRv IHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFz cyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBv biBzcGVjaWFsIHJlcXVlc3QgLS0gb3IgV0cgTGFzdCBjYWxsIGFzIHdhcyB0aGUgY2FzZSBoZXJl IC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8g dGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBE aXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVh L3J0Zy90cmFjL3dpa2kvUnRnRGlyDQo+DQo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBw cmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIChjaGFpcnMgYW5kKSBSb3V0aW5nIEFEcywgaXQg d291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFu eSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0 byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFm dC4NCj4NCj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC0xNA0KPiBSZXZpZXdlcjog TG91IEJlcmdlcg0KPiBSZXZpZXcgRGF0ZTogSnVuZSA4IChsYXRlciB0aGFuIHJlcXVlc3RlZCBk dWUgdG8gc2NvcGUgb2YgY29tbWVudHMgLS0gc29ycnkpIFdHIExDIEVuZCBEYXRlOiB1bmtub3du IEludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIHRyYWNrDQo+DQo+IFN1bW1hcnk6DQo+DQo+ICAg ICAgV2hpbGUgSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgcHJldHR5IGRlY2VudCBmb3IgdGhlIHNj b3BlIG9mIHRoZQ0KPiAgICAgIHdvcmssIEkgZG8gaGF2ZSBjb25jZXJucyBhYm91dCB0aGlzIGRv Y3VtZW50IGFuZCByZWNvbW1lbmQgdGhhdCB0aGUNCj4gICAgICBXRyBDaGFpcnMvUm91dGluZyBB RHMgZGlzY3VzcyB0aGVzZSBpc3N1ZXMgZnVydGhlciB3aXRoIHRoZSBhdXRob3JzLg0KPiAgICAg IEknbSBhbHNvIGF2YWlsYWJsZSBhcy9pZiBuZWVkZWQgdG8gZGlzY3Vzcy4NCj4NCj4gQ29tbWVu dHM6DQo+DQo+ICAgICAgSSB0aGluayB0aGUgZG9jdW1lbnQgc2hvd3Mgc2lnbmlmaWNhbnQgZ29v ZCB3b3JrIGFuZCBsb29rcyB0byBiZSBhDQo+ICAgICAgdXNlZnVsIHByb3RvY29sLCBhbHRob3Vn aCBJJ20gbm90IG92ZXJseSBmYW1pbGlhciBpbiB0aGlzIHNwYWNlLg0KPiAgICAgIFRoYXQgc2Fp ZCwgSSBoYXZlIGEgbnVtYmVyIG9mIHNlcmlvdXMgY29uY2VybnMgYWJvdXQgdGhlIGRvY3VtZW50 LA0KPiAgICAgIGFuZCBpdHMgY29udGVudHMgZnJvbSBhIGZldyBvZiBwZXJzcGVjdGl2ZXMuICBU aGVzZSBpbmNsdWRlIGJhc2ljDQo+ICAgICAgcHJvdG9jb2wgaXNzdWVzLCB1bmRlcnNwZWNpZmll ZCBkZXRhaWxzICAod2hpY2ggY291bGQgbGVhZCB0bw0KPiAgICAgIGludGVyb3BlcmFiaWxpdHkg aXNzdWVzKSwgYW5kIHNwZWNpZmljYXRpb24vZWRpdG9yaWFsIGlzc3Vlcy4gSQ0KPiAgICAgIHRo aW5rIHRoZSBkb2N1bWVudCAvIHByb3RvY29sIGNhbiBiZSBtb2RpZmllZCB0byBhZGRyZXNzIHRo ZSBpc3N1ZXMNCj4gICAgICBJIHJhaXNlIGJlbG93LiAgT2YgY291cnNlLCBpdCBpcyB1cCB0byB0 aGUgV0csIGNoYWlycywgYW5kIEFEcyB0bw0KPiAgICAgIGRlY2lkZSB3aGljaCBjb21tZW50cyB0 byBhZGRyZXNzIGFuZCB3aGljaCB0byAgaWdub3JlLg0KPiAgICAgIEkgZG9uJ3QgZXhwZWN0IHRo YXQgYWxsIGNvbW1lbnRzIHdpbGwgcmVzdWx0IGluIGNoYW5nZXMuDQo+DQo+IE1ham9yIElzc3Vl czoNCj4NCj4gICAgICAtIFRoZSBsZW5ndGggZmllbGQgb2YgdGhlIGdlbmVyaWMgZGF0YSBpdGVt IChpLmUuLCBUTFYpIGlzIG9ubHkgOA0KPiAgICAgICAgYml0cy4gIFdoaWxlIDI1NSBieXRlcyAo YXNzdW1pbmcgdGhhdCB0aGlzIGlzIHRoZSB1bml0IG9mIG1lYXN1cmUsDQo+ICAgICAgICB3aGlj aCBCVFcgaXNuJ3Qgc3BlY2lmaWVkKSBpcyBiaWcgZW5vdWdoIHRvZGF5LCBhbGxvd2luZyBmb3IN Cj4gICAgICAgIGxhcmdlciB3aWxsIGdyZWF0bHkgc2ltcGxpZnkgdGhpbmdzIHdoZW4gMjU1IGlz bid0IGVub3VnaC4gLS0NCj4gICAgICAgIFdlJ3ZlIHJ1biBpbnRvIHRoaXMgaW4gUlNWUCBhbmQg aXQncyBhIHJlYWwgcGFpbi4NCj4NCj4gICAgICAtIFZlcnNpb24gbnVtYmVyIGlzIGN1cnJlbnRs eSBkZWZpbmVkIGFzIGEgZGF0YSBpdGVtLiAgVGhpcyBtZWFucyBhDQo+ICAgICAgICBzaWduYWwg KGkuZS4sIG1lc3NhZ2UpIG5lZWRzIHRvIGJlIHBvdGVudGlhbGx5IGZ1bGx5IHBhcnNlZCB0bw0K PiAgICAgICAgZGlzY292ZXIgd2hhdCB2ZXJzaW9uIGlzIGJlaW5nIHVzZWQuICBUaGlzIHByZWNs dWRlcyBiYXNpYyBmb3JtYXQNCj4gICAgICAgIGNoYW5nZXMgdG8gdGhlIHByb3RvY29sLiAgUGVy aGFwcyB0aGUgRGlzY292ZXJ5IGFuZCBJbml0IFNpZ25hbHMNCj4gICAgICAgIHNob3VsZCBiZSBz cGVjaWFsIGNhc2VkIHRvIGluY2x1ZGUgdmVyc2lvbiBpbiB0aGVpciBmb3JtYXRzLiAgKEFuZA0K PiAgICAgICAgc2hvcnRlbiB2ZXJzaW9uIHRvIDggYml0cyBmcm9tIDMyLCBhcyBtZW50aW9uZWQg YmVsb3cpLg0KPg0KPiAgICAgIC0gVGhlIGRvY3VtZW50IHJlZmVyZW5jZXMsIGJ1dCBkb2VzIG5v dCBkZWZpbmUsICdpbi1zZXNzaW9uJyBhbmQNCj4gICAgICAgICdkaXNjb3ZlcnknIHN0YXRlcy4g IFRoZXNlIGVpdGhlciBuZWVkIHRvIGJlIGZvcm1hbGx5IGRlZmluZWQgb3INCj4gICAgICAgIHJl bW92ZWQuICBCVFcgd2UgaGFkIGV4YWN0bHkgdGhlIHNhbWUgaXNzdWUgd2l0aCBMTVAgKFJGQzQy MDQpIGFuZA0KPiAgICAgICAgZW5kZWQgdXAgYWRkaW5nIHNlY3Rpb24gMTEgKEZTTXMpIGF0IGEg cHJldHR5IGxhdGUgc3RhZ2Ugb2YgdGhlDQo+ICAgICAgICBwcm9jZXNzLg0KPg0KPiAgICAgIC0g VENQIHNlc3Npb24gbWFuYWdlbWVudCBpcyBub3QgZGVmaW5lZCwgbm9yIGlzIHRoZSByZWxhdGlv bnNoaXANCj4gICAgICAgIHdpdGggVENQIGFuZCBETEVQIHNlc3Npb25zIGZ1bGx5IGRlZmluZWQu ICBGb3IgZXhhbXBsZToNCj4NCj4gICAgICAgIG8gQ2xvc2luZyB0aGUgVENQIHNlc3Npb24gaXMg b25seSBtZW50aW9uZWQgaW4gb25lIHBsYWNlIGFuZCBpbiBhDQo+ICAgICAgICAgIHdheSB0aGF0 IGlzIGluY29uc2lzdGVudCB3aXRoIHRoZSBleHBlY3RlZCBwcm90b2NvbCBiZWhhdmlvcg0KPiAg ICAgICAgICAoY2xvc2UgVENQIGJlZm9yZSBBQ0sgaXMgcmVjZWl2ZWQpLg0KPg0KPiAgICAgICAg byBXaGF0IGhhcHBlbnMgd2hlbiBhIERMRVAgc2Vzc2lvbiBpcyB0ZXJtaW5hdGVkLCBjYW4gdGhl IFRDUA0KPiAgICAgICAgICBzZXNzaW9uIGJlIHJldXNlZCBvciBtdXN0IGl0IGJlIGNsb3NlZCB0 b28/DQo+DQo+ICAgICAgLSBUaGVyZSBpcyBubyB0cmFuc2FjdGlvbiBtb2RlbCBkZWZpbmVkLiAg Rm9yIGV4YW1wbGUsIGl0J3MNCj4gICAgICAgIGNvbXBsZXRlbHkgdW5jbGVhciBpZiBvbmx5IG9u ZSB1bmFja25vd2xlZGdlZCBTaWduYWwgYWxsb3dlZCBhdCBhDQo+ICAgICAgICB0aW1lLCBvciBw ZXJoYXBzIGp1c3Qgb25lIHBlciBzaWduYWwgdHlwZSBpcyBhbGxvd2VkLCBvciBwZXJoYXBzDQo+ ICAgICAgICB0aGVyZSBhcmUgbm8gcmVzdHJpY3Rpb25zLiAgVGhpcyBuZWVkcyB0byBiZSBleHBs aWNpdC4NCj4NCj4gICAgICAtIFdoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgcmV0cmllcyBhbmQgdGlt ZW91dHMgb3ZlciBUQ1A/ICBSZXRyaWVzDQo+ICAgICAgICBhcmVuJ3QgbmVlZGVkIG92ZXIgVENQ cyBhbmQgaXQncyB1bmNsZWFyIHdoZXkgdGhleSBhcmUgYmVpbmcgdXNlZC4NCj4NCj4gICAgICAt IFRoZSBoaWdoZXIgbGV2ZWwgaW1wbGljYXRpb25zIG9mIEFDS3MsIG92ZXIgVENQLCBpc24ndCBy ZWFsbHkNCj4gICAgICAgIGNsZWFyLiAgSXQgc2VlbXMgQUNLcyBhcmUgZGVmaW5lZCBmb3IgbXVs dGlwbGUgcHVycG9zZXM6IHJlbGlhYmxlDQo+ICAgICAgICB0cmFuc3BvcnQsIHRyYW5zYWN0aW9u IGFja25vd2xlZGdtZW50IGFuZCB0cmFuc2FjdGlvbiByZXN1bHRzLiBPZg0KPiAgICAgICAgY291 cnNlIHRoZSBmaXJzdCBpc24ndCBuZWVkZWQsIGFuZCBpbXBsaWNhdGlvbnMgb2YgdGhlIG90aGVy cw0KPiAgICAgICAgc2hvdWxkIGJlIGNsZWFyLiAgRm9yIGV4YW1wbGUsIGluIHNlY3Rpb24gNy4x MCwgd2h5IHdvdWxkIHRoZXJlIGJlDQo+ICAgICAgICBhIHJldHJ5IHdoZW4gcmVjZWl2aW5nIGEg RGVzdGluYXRpb24gVXAgQUNLIHNpZ25hbCBpbmRpY2F0aW5nIGFuDQo+ICAgICAgICBlcnJvcj8N Cj4NCj4gICAgICAtIFRoZXJlIGlzIG5vIGRpc2N1c3Npb24gb24gc2NhbGluZyBjb25zaWRlcmF0 aW9ucy4gQXJlIHRoZXJlIHJlYWxseQ0KPiAgICAgICAgbm9uZT8gIEZvciBleGFtcGxlLCBob3cg b2Z0ZW4gbWlnaHQgYmUgYXBwcm9wcmlhdGUgdG8gaXNzdWUvbGltaXQNCj4gICAgICAgIFBlZXIg VXBkYXRlcyBiYXNlZCB0byBjaGFuZ2VzIGluIGxpbmsgcXVhbGl0eSwgb3IgaG93IHRvIGhhbmRs ZQ0KPiAgICAgICAgdGhlIGNhc2Ugd2hlcmUgYSBsYXJnZSBudW1iZXIgKGFsbCBvciBtb3N0KSBv ZiBkZXN0aW5hdGlvbnMgZ28NCj4gICAgICAgIGRvd24uDQo+DQo+ICAgICAgLSBUaGVyZSBhcmUg MTMgcGxhY2VzIHdoZXJlIHRoZSBwcm90b2NvbCBhbGxvd3MgaW1wbGVtZW50YXRpb24gdG8NCj4g ICAgICAgIGRlZmluZSB0aGVpciBvd24gJ2hldXJpc3RpY3MnLiAgU29tZSBvZiB0aGVzZSBzZWVt IHVubmVjZXNzYXJ5IGR1ZQ0KPiAgICAgICAgdG8gdGhlIFRDUCBwb2ludCByYWlzZWQgYWJvdmUs IGJ1dCBhbnkgdGhhdCByZW1haW4gaW4gdGhlIHByb3RvY29sDQo+ICAgICAgICBzaG91bGQgYmUg ZnVsbHkgc3BlY2lmaWVkIHRvIGVuc3VyZSBwcmVkaWN0YWJsZS9jb25zaXN0ZW50DQo+ICAgICAg ICBiZWhhdmlvciBmcm9tIGltcGxlbWVudGF0aW9ucy4NCj4NCj4gICAgICAtIERhdGEgSXRlbXMg YXJlIGRlZmluZWQgZm9yICJFeHRlbnNpb25zIiBhbmQgIkV4cGVyaW1lbnRhbA0KPiAgICAgICAg RGVmaW5pdGlvbiIgKFNlY3Rpb25zIDguNyBhbmQgOC44KS4gIEJvdGggc2VlbSB0byBzdXBwb3J0 IGZvcg0KPiAgICAgICAgb3B0aW9uYWwgbWVjaGFuaXNtcywgYnV0IHRoZSBmb3JtZXIgdXNlcyBh c3NpZ25lZCBudW1lcmljIHZhbHVlcywNCj4gICAgICAgIHdoeSB0aGUgbGF0dGVyIHVzZXMgVVRG LTggc3RyaW5ncy4NCj4gICAgICAgIG8gV2hhdCwgaWYgYW55LCBpcyB0aGUgaW50ZW5kZWQgZGlz dGluY3Rpb24vcmVsYXRpb25zaGlwIGJldHdlZW4NCj4gICAgICAgICAgdGhlc2U/DQo+ICAgICAg ICBvIEhvdyBkb2VzIGFuICJFeHBlcmltZW50YWwgRGVmaW5pdGlvbiIgYmVjb21lIHN0YW5kYXJk aXplZD8NCj4NCj4gICAgICAtIFNlY3Rpb25zIDguMTkgYW5kIDguMjAgZGVmaW5lICJSZXNvdXJj ZXMiIHJlbGF0ZWQgRGF0YSBJdGVtcy4gIFRoZQ0KPiAgICAgICAgZGVmaW5pdGlvbiByZWxhdGVk IHRvIHRoZXNlIGJhc2ljYWxseSBzYXlzIGEgcmVzb3VyY2VzIGlzICJBbg0KPiAgICAgICAgOC1i aXQgaW50ZWdlciBwZXJjZW50YWdlLCAwLTEwMCwgcmVwcmVzZW50aW5nIHRoZSBhbW91bnQgb2YN Cj4gICAgICAgIHJlc291cmNlcyBhbGxvY2F0ZWQgdG8gcmVjZWl2aW5nfHRyYW5zbWl0dGluZyBk YXRhLiIuICBJZiBJIHdlcmUNCj4gICAgICAgIGltcGxlbWVudGluZyB0aGlzIHByb3RvY29sLCBJ J2QgaGF2ZSBubyBpZGVhIGhvdyB0byBwcm9kdWNlLA0KPiAgICAgICAgdXBkYXRlIG9yIHVzZSB0 aGlzIGluZm9ybWF0aW9uLiAgSSB0aGluayB0aGVyZSBpcyBzb21lIG1pc3NpbmcNCj4gICAgICAg IGluZm9ybWF0aXZlIGFuZCBub3JtYXRpdmUgKFJGQyAyMTE5KSB0ZXh0IHJlbGF0ZWQgdG8gdGhl c2UNCj4gICAgICAgIGZvcm1hdHMuDQo+DQo+ICAgICAgLSBTZWN0aW9ucyA4LjIxIGFuZCA4LjIy IChSZWxhdGl2ZSBMaW5rIFF1YWxpdHkpIGhhdmUgYSBzaW1pbGFyDQo+ICAgICAgICBwcm9ibGVt IG9mIGJlaW5nIHVuZGVyIGRlc2NyaWJlZCwgaW4gcGFydGljdWxhciBpdCdzIHVuY2xlYXIgaWYN Cj4gICAgICAgIHRoZXJlJ3MgYSBtZWFuaW5nZnVsLCBub24tcHJvcHJpZXRhcnkgZGVmaW5pdGlv biBmb3IgbGluayBxdWFsaXR5DQo+ICAgICAgICB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGlzIHRv IGFjdCBvbiBvciBpZiB0aGUgcGFzc2VkIHZhbHVlIGlzIGp1c3QNCj4gICAgICAgIHBhc3NlZCBm b3IgYXMgbW9uaXRvcmluZyBpbmZvcm1hdGlvbi4gIEVpdGhlciB3YXksIHRoaXMgbmVlZHMgdG8N Cj4gICAgICAgIGJlIGNsYXJpZmllZC4NCj4NCj4gICAgICAtIFNlY3Rpb24gOSBkZWZpbmVzIGEg ImNyZWRpdC13aW5kb3dpbmcgc2NoZW1lIGFuYWxvZ291cyB0byB0aGUgb25lDQo+ICAgICAgICBk b2N1bWVudGVkIGluIFtSRkM1NTc4XSIuIEl0IGRlc2NyaWJlcyBob3cgY3JlZGl0cyBhcmUgZXhj aGFuZ2VkLA0KPiAgICAgICAgYnV0IGl0IHByb3ZpZGVzIHplcm8gZGVmaW5pdGlvbiBvbiB0aGUg aW1wbGljYXRpb25zIG9yIHVzZSBvZg0KPiAgICAgICAgY3JlZGl0cyByZWxhdGl2ZSB0byB0aGUg ZGF0YSBwbGFuZS4NCj4NCj4gICAgICAtIE11bHRpcGxlIHdheXMgdG8gaW1wbGVtZW50IHRoZSBz YW1lIGZ1bmN0aW9uIGFyZSBhbGxvd2VkLCBlLmcuLA0KPiAgICAgICAgb3B0aW9uYWwgcHJlc2Vu Y2Ugb2YgU3RhdHVzLCBJbnRlcnZhbCBhbmQgVENQIHBvcnQuICBHZW5lcmFsbHkNCj4gICAgICAg IGFsbG93aW5nIHN1Y2ggY29tcGxpY2F0ZXMgdGVzdGluZyBhbmQgbGVhZHMgdG8gaW50ZXJvcGVy YWJpbGl0eQ0KPiAgICAgICAgaXNzdWVzLiAgVGhlIGRvY3VtZW50IHNob3VsZCBwaWNrIG9uZSB3 YXkgYW5kIHJlcXVpcmUgaXQuDQo+DQo+ICAgICAgLSBUaGUgZG9jdW1lbnQgZG9lc24ndCBzdGF0 ZSBpZiB0aGVyZSBhcmUgYW55IG9yZGVyaW5nIHJlcXVpcmVtZW50cw0KPiAgICAgICAgb24gZGF0 YSBpdGVtcy4gSXQgc2hvdWxkIGJlIGV4cGxpY2l0IG9uIHRoaXMsIGUuZy4sIHRoZXJlIGFyZSBu bw0KPiAgICAgICAgb3JkZXJpbmcgcmVxdWlyZW1lbnRzIG9uIHRoZSBwbGFjZW1lbnQgb2YgRGF0 YSBJdGVtcyB3aXRoaW4NCj4gICAgICAgIFNpZ25hbHMuDQo+DQo+ICAgICAgLSBUaGUgcmVxdWly ZWQgYW5kIG9wdGlvbmFsIGRhdGEgaXRlbXMgdGhhdCBhcmUgcGVybWl0dGVkIG9uIGENCj4gICAg ICAgIHNpZ25hbCBpc24ndCBhbHdheXMgY2xlYXIuICBGb3IgZXhhbXBsZSBhcmUgMC8xL04gY29w aWVzIG9mIGENCj4gICAgICAgIHBhcnRpY3VsYXIgRGF0YSBJdGVtIHJlcXVpcmVkL2FsbG93ZWQu ICBVc2luZyBzb21ldGhpbmcgbGlrZSBBQk5GDQo+ICAgICAgICB3b3VsZCByZWFsbHkgaGVscCBm b3JtYWxpemUgYW5kIGNsYXJpZnkgdGhpcy4NCj4NCj4gICAgICAtIFRoZSBkb2N1bWVudCBkb2Vz bid0IGNsZWFybHkgZGVsaW5lYXRlIGZyb20gaW5mb3JtYXRpdmUvbmFycmF0aXZlDQo+ICAgICAg ICB0ZXh0LCBub3JtYXRpdmUgLyByZXF1aXJlZCBwcm9jZXNzaW5nIHByb2NlZHVyZXMsIGFuZCBt ZXNzYWdlDQo+ICAgICAgICBmb3JtYXRzLiBUaGlzIGJ5IGl0c2VsZiBpcyBub3QgbmVjZXNzYXJp bHkgYSBtYWpvciBpc3N1ZSwgaXQganVzdA0KPiAgICAgICAgbWFrZXMgaXQgaGFyZGVyIHRvICh3 cml0ZSwpIHJldmlldyBhbmQgaW1wbGVtZW50IHRoZSBwcm90b2NvbC4NCj4gICAgICAgIFdoYXQg aXMgYSBtYWpvciBpc3N1ZSBpcyB0aGF0IHRoaXMgYXBwcm9hY2ggYWxsb3dzIGZvciBkdXBsaWNh dGUNCj4gICAgICAgIChhbmQgc29tZXRpbWVzIGNvbnRyYWRpY3RvcnkpIG5vcm1hdGl2ZSBwcm9j ZWR1cmVzIGFuZCBmb3INCj4gICAgICAgIG9taXNzaW9ucyBpbiBwcm9jZWR1cmVzIChwYXJ0aWN1 bGFybHkgcmVsYXRlZCB0byBleGNlcHRpb24vZXJyb3INCj4gICAgICAgIHByb2Nlc3NpbmcpLiAg U3BlY2lmaWMgZXhhbXBsZXMgYXJlIGluY2x1ZGVkIGFib3ZlIGFuZCBiZWxvdy4gIEl0DQo+ICAg ICAgICB3b3VsZCBiZSBiZXN0IHRvIGVuc3VyZSB0aGF0IGVhY2ggcmVxdWlyZWQgcHJvY2Vzc2lu ZyBiZWhhdmlvciBpcw0KPiAgICAgICAgZGVmaW5lZCBqdXN0IG9uY2UgYW5kIGluIGEgY29uc2lz dGVudCB3YXkuDQo+DQo+ICAgICAgLSBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9u IGlzIGluYWRlcXVhdGUuICBUaGlzIHNlY3Rpb24NCj4gICAgICAgIHNob3VsZCBhZGRyZXNzIHRo ZSBzZWN1cml0eSBvZiB0aGUgRExFUCBwcm90b2NvbCwgbm90IHVzZXINCj4gICAgICAgIHRyYWZm aWMuICBJdCBzaG91bGQgaW5jbHVkZSBhbiBhbmFseXNpcyBvZiByaXNrcy90aHJlYXRzL3Bvc3Np YmxlDQo+ICAgICAgICBleHBsb2l0cyBhbmQgaG93IHRoZXNlIGFyZSBtaXRpZ2F0ZWQgYnkgdGhl IHByb3RvY29sLiAgcmZjNjk1MiwNCj4gICAgICAgIGFuZCB0aGUgcHJvdG9jb2xzIGl0IHJlZmVy ZW5jZXMgY2FuIHNlcnZlIGFzIGV4YW1wbGVzLg0KPg0KPiBNaW5vciBJc3N1ZXM6DQo+DQo+ICAg ICAgLSBUaGUgZGF0YSBhbmQgc2lnbmFsIHR5cGUgZmllbGRzIGFyZSBib3RoIDggYml0cy4gIFRo aXMgc2VlbXMNCj4gICAgICAgIHByZXR0eSBzbWFsbCwgcGFydGljdWxhcmx5IHRoZSBkYXRhIHR5 cGUgZmllbGQuICBHaXZlbiB0aGlzIGlzIGENCj4gICAgICAgIGNvbnRyb2wgcHJvdG9jb2wsIEkg dGhpbmsgYSBsYXJnZXIgKGF0IGxlYXN0IGRhdGEgdHlwZSkgZmllbGQNCj4gICAgICAgIHdvdWxk IHByb3ZpZGUgYmV0dGVyICJmdXR1cmUgcHJvb2ZpbmciLg0KPg0KPiAgICAgIC0gMl4zMiB2ZXJz aW9ucyBhcmUgY3VycmVudGx5IGFsbG93ZWQgKHNlY3Rpb24gOC4xKS4gIFRoaXMgc2VlbXMgYQ0K PiAgICAgICAgYml0IGV4Y2Vzc2l2ZS4gIEknZCBvcHQgZm9yIG1heCBvZiA4IGJpdHMgaGVyZSBt eXNlbGYuDQo+DQo+ICAgICAgLSBJdCdzIHByb2JhYmx5IHRvbyBsYXRlLCBidXQgaXQgcHJvYmFi bHkgd291bGQgYmUgY2xlYW5lciB0byBoYXZlIGENCj4gICAgICAgIGdlbmVyaWMgYWNrIHNpZ25h bCByYXRoZXIgdGhhbiBhIHBlciBzaWduYWwgdHlwZSBhY2suIEkgbWVudGlvbg0KPiAgICAgICAg dGhpcyBoZXJlIGFzIHRoaXMgbWF5IGNvbWUgdXAgYWdhaW4gd2hlbiBjbGFyaWZ5aW5nIHRoZQ0K PiAgICAgICAgdHJhbnNhY3Rpb24gbW9kZWwgKGFzIG1lbnRpb25lZCBhYm92ZS4pDQo+DQo+ICAg ICAgLSBTZWN0aW9uIDI6IEFzc3VtcHRpb25zDQo+ICAgICAgICBUaGlzIHNlY3Rpb24gaW5jbHVk ZXMgaW5mb3JtYXRpdmUgYW5kIG5vcm1hdGl2ZSB0ZXh0IHNvIGlzIG1vcmUNCj4gICAgICAgIHRo YW4ganVzdCBBc3N1bXB0aW9ucy4gIFBlcnNvbmFsbHksIEknZCByZW1vdmUgYWxsIG5vcm1hdGl2 ZSB0ZXh0DQo+ICAgICAgICBmcm9tIHRoZSBzZWN0aW9uLg0KPg0KPiAgICAgIC0gVGhlcmUgYXJl IG5vIHNwZWNpZmljIHJ1bGVzIHJlbGF0ZWQgdG8gVURQIGhlYWRlciBmb3JtYXRpb24uDQo+DQo+ ICAgICAgLSBTZWN0aW9ucyA4LjEwLT44LjE3LiAgSXNuJ3QgYWRkL2Ryb3AgaW5kaWNhdG9yIG5l ZWRlZCBmb3Igc3VibmV0cw0KPiAgICAgICAgaW4gZGVzdGluYXRpb24gdXBkYXRlIHNpZ25hbHM/ DQo+DQo+ICAgICAgLSBUaGUgSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9ucyBtdXN0IGZvbGxv d+KAiyBSRkMyMzYwLg0KPg0KPiAgICAgIC0gTmV3IHJlZ2lzdHJpZXMgbXVzdCBpbmNsdWRlIGlu aXRpYWwgdmFsdWVzLCB3aGljaCBhcmUgZGVmaW5lZCBpbg0KPiAgICAgICAgdGhlIGRvY3VtZW50 LiAgKFRoZSBkb2N1bWVudCBjdXJyZW50bHkgaGFzIG1hbnkgVEJEcyB0aGF0IHNob3VsZA0KPiAg ICAgICAgYmUgcmVwbGFjZWQuKQ0KPg0KPiAgICAgIC0gTmV3IHJlZ2lzdHJpZXMgbmVlZCBhbiBh bGxvY2F0aW9uIHBvbGljeSwgZS5nLjoNCj4gICAgICBUaGUgcmVnaXN0cnkgc2hvdWxkIGJlIGVz dGFibGlzaGVkIHdpdGggcmVnaXN0cmF0aW9uIHBvbGljaWVzIG9mDQo+ICAgICAgIlN0YW5kYXJk cyBBY3Rpb24iIChmb3IgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50cykgYW5kDQo+ICAgICAg4oCc U3BlY2lmaWNhdGlvbiBSZXF1aXJlZCIgKGZvciBvdGhlciBkb2N1bWVudHMpLiBUaGUgZGVzaWdu YXRlZA0KPiAgICAgIGV4cGVydCBpcyBhbnkgY3VycmVudCA8ZmlsbC1pbj4gV0cgY2hhaXIuDQo+ DQo+IE5pdHM6DQo+DQo+ICAgICAgLSBUaGUgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgdGVybXMg InNpZ25hbHMiIGFuZCAiZGF0YSBpdGVtcyIgZm9yDQo+ICAgICAgICB3aGF0IGlzIGNvbW1vbmx5 IGNhbGxlZCAibWVzc2FnZXMiIGFuZCAiVExWcyIgKG9yIG9iamVjdHMpIGluDQo+ICAgICAgICBv dGhlciBwcm90b2NvbHMuICBJdCdzIHByb2JhYmx5IHRvbyBsYXRlIHRvIGNoYW5nZSB0aGlzLCBi dXQgSQ0KPiAgICAgICAgdGhpbmsgdGhlIGludHJvZHVjdGlvbiBvZiB1bmlxdWUgdGVybWlub2xv Z3kgaXMgY291bnRlcg0KPiAgICAgICAgcHJvZHVjdGl2ZS4NCj4NCj4gICAgICAtIFVzZSBvZiBS RkMgMjExOSBjb25mb3JtYW5jZSBsYW5ndWFnZSBpcyBhIGJpdCByb3VnaCwgYW5kIHRoZXJlIGFy ZQ0KPiAgICAgICAgd29yZHMgaW4gYWxsIGNhcHMgdGhhdCBhcmUgbm90IGRlZmluZWQgaW4gUkZD MjExOS4gVGFrZSBhIGxvb2sgYXQNCj4gICAgICAgIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L3dnL3RlYXMvdHJhYy93aWtpL1BTR3VpZGVsaW5lIGZvciBzb21lDQo+ICAgICAgICBzdWdnZXN0 aW9ucy4NCj4NCj4gICAgICAtIEludGVybmFsIHNvY2tldCBvcGVyYXRpb24gaXMgbWVudGlvbmVk IGEgY291cGxlIG9mIHRpbWVzLiAgSXQNCj4gICAgICAgIHJlYWxseSBzaG91bGRuJ3QgYmUsIHRo ZSBzcGVjIHNob3VsZCBkZWZpbmUgYmVoYXZpb3Igb24gdGhlIHdpcmUuDQo+DQo+ICAgICAgLSBU aGUgTGVuZ3RoIGZpZWxkcyBhcmUgbWlzc2luZyB1bml0IG9mIG1lYXN1cmUgKHByZXN1bWFibHkg b2N0ZXRzKQ0KPg0KPiAgICAgIC0gVGhlIE1uZW1vbmljcyBhcmUgdXNlZCBiYXNpY2FsbHkgb25j ZSBhbmQgZG9uJ3QgcmVhbGx5IGFkZCB2YWx1ZSwNCj4gICAgICAgIHN1Z2dlc3QgZHJvcHBpbmcg dGhlbS4NCj4NCj4gICAgICAtIEhvdy93aGVuIGlzIHRoZSAiVW5rbm93biBTaWduYWwiIFN0YXR1 cyBDb2RlIHNlbnQ/DQo+DQo+ICAgICAgLSBTZWN0aW9uIDguNzogRXh0ZW5zaW9uIExpc3Qgc2hv dWxkIGJlIHNob3duIGFzIGEgdmFyaWFibGUgbGVuZ3RoDQo+ICAgICAgICBmaWVsZC4NCj4NCj4g ICAgICAtIFNlY3Rpb24gOC44OiBFeHBlcmltZW50IExpc3Qgc2hvdWxkIGJlIHNob3duIGFzIGEg dmFyaWFibGUgbGVuZ3RoDQo+ICAgICAgICBmaWVsZC4NCj4NCj4gVGhhdCdzIGl0IC0tIGZvciBu b3cgLS0gaG9wZWZ1bGx5IEkgZGlkbid0IG1pc3MgYW55dGhpbmcuICBMb29rIGZvcndhcmQgdG8g aGVhcmluZyByZXNwb25zZSB0byB0aGUgYWJvdmUgKGFuZCBob3cgSSBnb3QgdGhpbmdzIGhvcGVs ZXNzbHkgd3JvbmcgOy0pDQo+DQo+IExvdQ0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFu ZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IFRoaXMgZW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KPiByZWNp cGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZA0KPiByZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBu b3RpZnkgdGhlIHNlbmRlci4NCj4gWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9y IGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcg0KPiBkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0 byBhbnkgb3RoZXIgcGVyc29uLg0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFu ZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgYW5kIGFu eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zCmluZm9ybWF0aW9uIGZyb20gaURp cmVjdCwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5CmFuZC9vciBjb25maWRl bnRpYWwuIEl0IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bApvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBvcmlnaW5hbApyZWNpcGllbnQgb3IgdGhlIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZl cmluZyB0aGUgZW1haWwgdG8gdGhlCmludGVuZGVkIHJlY2lwaWVudCwgYmUgYWR2aXNlZCB0aGF0 IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwKaW4gZXJyb3IsIGFuZCB0aGF0IGFueSB1c2Us IGRpc3NlbWluYXRpb24sIGZvcndhcmRpbmcsIHByaW50aW5nLCBvcgpjb3B5aW5nIG9mIHRoaXMg ZW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmVkIHRoaXMgZW1haWwK aW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2Vu ZGVyLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo= --_000_75a095cff2c2410d9cf1cd35fc60657eVAUSDITCHM3idirectnet_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcyBSaWNrIHNhaWQg4oCTIHdlIHdpbGwgd2hlbiB3ZSBo YXZlIGEgcGxhbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ U3RhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gYmViZW1hc3RlciBbbWFpbHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tXQ0KPGJyPg0K PGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMTYsIDIwMTUgNzoyNSBBTTxicj4NCjxiPlRvOjwv Yj4gUmljayBUYXlsb3I7IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBMb3UgQmVyZ2VyOyBt YW5ldC1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IG1hbmV0LWFkc0BpZXRmLm9yZzsg cnRnLWRpckBpZXRmLm9yZzsgbWFuZXRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC5h bGxAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gUnRnRGlyIHJldmll dzogZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLTE0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRvIGhhdmUg c29tZSBvZiB0aGF0IGRpc2N1c3Npb24gb24gdGhlIGxpc3QuIFRoZXJlIGlzIHF1aXRlIGEgbG90 IG9mIGludGVyZXN0IGluIHRoaXMgZHJhZnQgd2l0aGluIHRoZSB3ZyBhbmQgZ2V0dGluZyBpbnB1 dCBvbiBiZXN0IHdheXMgZm9yd2FyZCBvbiB0aGUgdmFyaW91cyBmaXhlcyBiZWZvcmUgdGhleSBh cmUgd3JpdHRlbiB1cCBzaG91bGQgZW5kIHVwIHNhdmluZw0KIHRpbWUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3RpbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyb206IFJpY2sgVGF5bG9yIDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGF0ZTowNi8xNi8y MDE1IDU6MDAgQU0gKEdNVC0wNTowMCkgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UbzogJnF1b3Q7RGVhcmxvdmUsIENocmlzdG9waGVyIChVSykm cXVvdDsgLCBMb3UgQmVyZ2VyICwgPGEgaHJlZj0ibWFpbHRvOm1hbmV0LWNoYWlyc0BpZXRmLm9y ZyI+DQptYW5ldC1jaGFpcnNAaWV0Zi5vcmc8L2E+IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2M6IDxhIGhyZWY9Im1haWx0bzptYW5ldC1hZHNA aWV0Zi5vcmciPm1hbmV0LWFkc0BpZXRmLm9yZzwvYT4sDQo8YSBocmVmPSJtYWlsdG86cnRnLWRp ckBpZXRmLm9yZyI+cnRnLWRpckBpZXRmLm9yZzwvYT4sIDxhIGhyZWY9Im1haWx0bzptYW5ldEBp ZXRmLm9yZyI+DQptYW5ldEBpZXRmLm9yZzwvYT4sIDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRm LW1hbmV0LWRsZXAuYWxsQGlldGYub3JnIj5kcmFmdC1pZXRmLW1hbmV0LWRsZXAuYWxsQGlldGYu b3JnPC9hPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TdWJqZWN0OiBSZTogW21hbmV0XSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLW1hbmV0 LWRsZXAtMTQNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QWxsLDxicj4NCjxicj4NClN0YW4gYW5kIEkg YXJlIGN1cnJlbnRseSBkaXNjdXNzaW5nIHRoZSByZXZpZXcuJm5ic3A7IFdlIHdpbGwgY29tZSBi YWNrIHRvIDxicj4NCnRoZSBsaXN0IHdpdGggYSBwcm9wb3NlZCBzZXQgb2YgYWN0aW9ucyB3aGVu IHdlIGhhdmUgYSBwbGFuLjxicj4NCjxicj4NClNvcnJ5IGZvciB0aGUgZGVsYXksPGJyPg0KPGJy Pg0KUmljazxicj4NCjxicj4NCjxicj4NCk9uIDE1LzA2LzE1IDEyOjE2LCBEZWFybG92ZSwgQ2hy aXN0b3BoZXIgKFVLKSB3cm90ZTo8YnI+DQomZ3Q7IEkgaGF2ZW4ndCBzZWVuIGFueSBkaXNjdXNz aW9uIG9mIHRoaXMuIEl0IGxvb2tzIHRvIG1lIGxpa2UgcmVxdWlyaW5nIGFub3RoZXIgZHJhZnQg Zm9yIHRoZSBXRyB0byBzZWUuIEl0IGRvZXMgKGJ5IG15IHJhcGlkIGNvdW50KSBoYXZlIDE3IG1h am9yIGlzc3Vlcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZndDsgQ2hyaXN0b3BoZXIg RGVhcmxvdmU8YnI+DQomZ3Q7IFNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQomZ3Q7IEJB RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDs8YnI+DQomZ3Q7IFQ6Jm5ic3A7ICYjNDM7NDQgKDApMTI0NSAyNDIxOTQmbmJz cDsgfCZuYnNwOyBFOiA8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7 IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kg UGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCiZndDsg PGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+d3d3LmJhZXN5c3RlbXMuY29t L2FpPC9hPjxicj4NCiZndDsgQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRl ZDxicj4NCiZndDsgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1 MTxicj4NCiZndDsgUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWls ZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogbWFuZXQgWzxhIGhyZWY9Im1h aWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9y ZzwvYT5dIE9uIEJlaGFsZiBPZiBMb3UgQmVyZ2VyPGJyPg0KJmd0OyBTZW50OiAwOCBKdW5lIDIw MTUgMjA6MTE8YnI+DQomZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86bWFuZXQtY2hhaXJzQGlldGYu b3JnIj5tYW5ldC1jaGFpcnNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBDYzogPGEgaHJlZj0ibWFp bHRvOm1hbmV0LWFkc0BpZXRmLm9yZyI+bWFuZXQtYWRzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0i bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmciPg0KcnRnLWRpckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9 Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWls dG86ZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLmFsbEBpZXRmLm9yZyI+DQpkcmFmdC1pZXRmLW1hbmV0 LWRsZXAuYWxsQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogW21hbmV0XSBSdGdEaXIg cmV2aWV3OiBkcmFmdC1pZXRmLW1hbmV0LWRsZXAtMTQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlz IG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVy IGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC48YnI+DQomZ3Q7 IENvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtz LCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48YnI+DQomZ3Q7IEZvbGxvdyB0aGUgJ1Jl cG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlv bnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuPGJyPg0KJmd0OyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CiZndDs8YnI+DQomZ3Q7IFtOb3RlIHRoaXMgaXMgYSBXRyBMQyByZWxhdGVkIHJldmlldywgbm90 IElFVEYgTEMuXTxicj4NCiZndDs8YnI+DQomZ3Q7IEhlbGxvLDxicj4NCiZndDs8YnI+DQomZ3Q7 IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2Vy IGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcg YWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3Vn aCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lh bCByZXF1ZXN0IC0tIG9yIFdHIExhc3QgY2FsbA0KIGFzIHdhcyB0aGUgY2FzZSBoZXJlIC4gVGhl IHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJv dXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3Rv cmF0ZSwgcGxlYXNlIHNlZSDigIs8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9h cmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVh L3J0Zy90cmFjL3dpa2kvUnRnRGlyPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IEFsdGhvdWdoIHRo ZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIChjaGFpcnMgYW5k KSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIg dGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVj ZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5 IHVwZGF0aW5nIHRoZSBkcmFmdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBEb2N1bWVudDogZHJhZnQt aWV0Zi1tYW5ldC1kbGVwLTE0PGJyPg0KJmd0OyBSZXZpZXdlcjogTG91IEJlcmdlcjxicj4NCiZn dDsgUmV2aWV3IERhdGU6IEp1bmUgOCAobGF0ZXIgdGhhbiByZXF1ZXN0ZWQgZHVlIHRvIHNjb3Bl IG9mIGNvbW1lbnRzIC0tIHNvcnJ5KSBXRyBMQyBFbmQgRGF0ZTogdW5rbm93biBJbnRlbmRlZCBT dGF0dXM6IFN0YW5kYXJkcyB0cmFjazxicj4NCiZndDs8YnI+DQomZ3Q7IFN1bW1hcnk6PGJyPg0K Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2hpbGUgSSB0aGlu ayB0aGUgZG9jdW1lbnQgaXMgcHJldHR5IGRlY2VudCBmb3IgdGhlIHNjb3BlIG9mIHRoZTxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd29yaywgSSBkbyBoYXZlIGNvbmNl cm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgYW5kIHJlY29tbWVuZCB0aGF0IHRoZTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV0cgQ2hhaXJzL1JvdXRpbmcgQURzIGRpc2N1 c3MgdGhlc2UgaXNzdWVzIGZ1cnRoZXIgd2l0aCB0aGUgYXV0aG9ycy48YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEknbSBhbHNvIGF2YWlsYWJsZSBhcy9pZiBuZWVkZWQg dG8gZGlzY3Vzcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBDb21tZW50czo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIHRoaW5rIHRoZSBkb2N1bWVudCBz aG93cyBzaWduaWZpY2FudCBnb29kIHdvcmsgYW5kIGxvb2tzIHRvIGJlIGE8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZWZ1bCBwcm90b2NvbCwgYWx0aG91Z2ggSSdt IG5vdCBvdmVybHkgZmFtaWxpYXIgaW4gdGhpcyBzcGFjZS48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYXQgc2FpZCwgSSBoYXZlIGEgbnVtYmVyIG9mIHNlcmlvdXMg Y29uY2VybnMgYWJvdXQgdGhlIGRvY3VtZW50LDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgYW5kIGl0cyBjb250ZW50cyBmcm9tIGEgZmV3IG9mIHBlcnNwZWN0aXZlcy4m bmJzcDsgVGhlc2UgaW5jbHVkZSBiYXNpYzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcHJvdG9jb2wgaXNzdWVzLCB1bmRlcnNwZWNpZmllZCBkZXRhaWxzJm5ic3A7ICh3 aGljaCBjb3VsZCBsZWFkIHRvPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyksIGFuZCBzcGVjaWZpY2F0aW9uL2VkaXRvcmlhbCBp c3N1ZXMuIEk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaW5rIHRo ZSBkb2N1bWVudCAvIHByb3RvY29sIGNhbiBiZSBtb2RpZmllZCB0byBhZGRyZXNzIHRoZSBpc3N1 ZXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgcmFpc2UgYmVsb3cu Jm5ic3A7IE9mIGNvdXJzZSwgaXQgaXMgdXAgdG8gdGhlIFdHLCBjaGFpcnMsIGFuZCBBRHMgdG88 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlY2lkZSB3aGljaCBjb21t ZW50cyB0byBhZGRyZXNzIGFuZCB3aGljaCB0byZuYnNwOyBpZ25vcmUuPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGRvbid0IGV4cGVjdCB0aGF0IGFsbCBjb21tZW50 cyB3aWxsIHJlc3VsdCBpbiBjaGFuZ2VzLjxicj4NCiZndDs8YnI+DQomZ3Q7IE1ham9yIElzc3Vl czo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRo ZSBsZW5ndGggZmllbGQgb2YgdGhlIGdlbmVyaWMgZGF0YSBpdGVtIChpLmUuLCBUTFYpIGlzIG9u bHkgODxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Yml0cy4mbmJzcDsgV2hpbGUgMjU1IGJ5dGVzIChhc3N1bWluZyB0aGF0IHRoaXMgaXMgdGhlIHVu aXQgb2YgbWVhc3VyZSw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHdoaWNoIEJUVyBpc24ndCBzcGVjaWZpZWQpIGlzIGJpZyBlbm91Z2ggdG9kYXks IGFsbG93aW5nIGZvcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbGFyZ2VyIHdpbGwgZ3JlYXRseSBzaW1wbGlmeSB0aGluZ3Mgd2hlbiAyNTUgaXNu J3QgZW5vdWdoLiAtLTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgV2UndmUgcnVuIGludG8gdGhpcyBpbiBSU1ZQIGFuZCBpdCdzIGEgcmVhbCBwYWlu Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gVmVy c2lvbiBudW1iZXIgaXMgY3VycmVudGx5IGRlZmluZWQgYXMgYSBkYXRhIGl0ZW0uJm5ic3A7IFRo aXMgbWVhbnMgYTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgc2lnbmFsIChpLmUuLCBtZXNzYWdlKSBuZWVkcyB0byBiZSBwb3RlbnRpYWxseSBmdWxs eSBwYXJzZWQgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRpc2NvdmVyIHdoYXQgdmVyc2lvbiBpcyBiZWluZyB1c2VkLiZuYnNwOyBUaGlzIHBy ZWNsdWRlcyBiYXNpYyBmb3JtYXQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGNoYW5nZXMgdG8gdGhlIHByb3RvY29sLiZuYnNwOyBQZXJoYXBzIHRo ZSBEaXNjb3ZlcnkgYW5kIEluaXQgU2lnbmFsczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2hvdWxkIGJlIHNwZWNpYWwgY2FzZWQgdG8gaW5jbHVk ZSB2ZXJzaW9uIGluIHRoZWlyIGZvcm1hdHMuJm5ic3A7IChBbmQ8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNob3J0ZW4gdmVyc2lvbiB0byA4IGJp dHMgZnJvbSAzMiwgYXMgbWVudGlvbmVkIGJlbG93KS48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRoZSBkb2N1bWVudCByZWZlcmVuY2VzLCBidXQg ZG9lcyBub3QgZGVmaW5lLCAnaW4tc2Vzc2lvbicgYW5kPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAnZGlzY292ZXJ5JyBzdGF0ZXMuJm5ic3A7IFRo ZXNlIGVpdGhlciBuZWVkIHRvIGJlIGZvcm1hbGx5IGRlZmluZWQgb3I8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlbW92ZWQuJm5ic3A7IEJUVyB3 ZSBoYWQgZXhhY3RseSB0aGUgc2FtZSBpc3N1ZSB3aXRoIExNUCAoUkZDNDIwNCkgYW5kPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmRlZCB1cCBh ZGRpbmcgc2VjdGlvbiAxMSAoRlNNcykgYXQgYSBwcmV0dHkgbGF0ZSBzdGFnZSBvZiB0aGU8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb2Nlc3Mu PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBUQ1Ag c2Vzc2lvbiBtYW5hZ2VtZW50IGlzIG5vdCBkZWZpbmVkLCBub3IgaXMgdGhlIHJlbGF0aW9uc2hp cDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2l0 aCBUQ1AgYW5kIERMRVAgc2Vzc2lvbnMgZnVsbHkgZGVmaW5lZC4mbmJzcDsgRm9yIGV4YW1wbGU6 PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgbyBDbG9zaW5nIHRoZSBUQ1Agc2Vzc2lvbiBpcyBvbmx5IG1lbnRpb25lZCBpbiBvbmUg cGxhY2UgYW5kIGluIGE8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdheSB0aGF0IGlzIGluY29uc2lzdGVudCB3aXRoIHRoZSBl eHBlY3RlZCBwcm90b2NvbCBiZWhhdmlvcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKGNsb3NlIFRDUCBiZWZvcmUgQUNLIGlz IHJlY2VpdmVkKS48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBvIFdoYXQgaGFwcGVucyB3aGVuIGEgRExFUCBzZXNzaW9uIGlzIHRl cm1pbmF0ZWQsIGNhbiB0aGUgVENQPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXNzaW9uIGJlIHJldXNlZCBvciBtdXN0IGl0 IGJlIGNsb3NlZCB0b28/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLSBUaGVyZSBpcyBubyB0cmFuc2FjdGlvbiBtb2RlbCBkZWZpbmVkLiZuYnNwOyBG b3IgZXhhbXBsZSwgaXQnczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgY29tcGxldGVseSB1bmNsZWFyIGlmIG9ubHkgb25lIHVuYWNrbm93bGVkZ2Vk IFNpZ25hbCBhbGxvd2VkIGF0IGE8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRpbWUsIG9yIHBlcmhhcHMganVzdCBvbmUgcGVyIHNpZ25hbCB0eXBl IGlzIGFsbG93ZWQsIG9yIHBlcmhhcHM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZXJlIGFyZSBubyByZXN0cmljdGlvbnMuJm5ic3A7IFRoaXMg bmVlZHMgdG8gYmUgZXhwbGljaXQuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLSBXaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHJldHJpZXMgYW5kIHRpbWVv dXRzIG92ZXIgVENQPyZuYnNwOyBSZXRyaWVzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcmVuJ3QgbmVlZGVkIG92ZXIgVENQcyBhbmQgaXQncyB1 bmNsZWFyIHdoZXkgdGhleSBhcmUgYmVpbmcgdXNlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRoZSBoaWdoZXIgbGV2ZWwgaW1wbGljYXRpb25z IG9mIEFDS3MsIG92ZXIgVENQLCBpc24ndCByZWFsbHk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNsZWFyLiZuYnNwOyBJdCBzZWVtcyBBQ0tzIGFy ZSBkZWZpbmVkIGZvciBtdWx0aXBsZSBwdXJwb3NlczogcmVsaWFibGU8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRyYW5zcG9ydCwgdHJhbnNhY3Rp b24gYWNrbm93bGVkZ21lbnQgYW5kIHRyYW5zYWN0aW9uIHJlc3VsdHMuIE9mPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb3Vyc2UgdGhlIGZpcnN0 IGlzbid0IG5lZWRlZCwgYW5kIGltcGxpY2F0aW9ucyBvZiB0aGUgb3RoZXJzPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaG91bGQgYmUgY2xlYXIu Jm5ic3A7IEZvciBleGFtcGxlLCBpbiBzZWN0aW9uIDcuMTAsIHdoeSB3b3VsZCB0aGVyZSBiZTxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSByZXRy eSB3aGVuIHJlY2VpdmluZyBhIERlc3RpbmF0aW9uIFVwIEFDSyBzaWduYWwgaW5kaWNhdGluZyBh bjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXJy b3I/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBU aGVyZSBpcyBubyBkaXNjdXNzaW9uIG9uIHNjYWxpbmcgY29uc2lkZXJhdGlvbnMuIEFyZSB0aGVy ZSByZWFsbHk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IG5vbmU/Jm5ic3A7IEZvciBleGFtcGxlLCBob3cgb2Z0ZW4gbWlnaHQgYmUgYXBwcm9wcmlh dGUgdG8gaXNzdWUvbGltaXQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFBlZXIgVXBkYXRlcyBiYXNlZCB0byBjaGFuZ2VzIGluIGxpbmsgcXVhbGl0 eSwgb3IgaG93IHRvIGhhbmRsZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGhlIGNhc2Ugd2hlcmUgYSBsYXJnZSBudW1iZXIgKGFsbCBvciBtb3N0 KSBvZiBkZXN0aW5hdGlvbnMgZ288YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGRvd24uPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLSBUaGVyZSBhcmUgMTMgcGxhY2VzIHdoZXJlIHRoZSBwcm90b2NvbCBh bGxvd3MgaW1wbGVtZW50YXRpb24gdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmluZSB0aGVpciBvd24gJ2hldXJpc3RpY3MnLiZuYnNwOyBT b21lIG9mIHRoZXNlIHNlZW0gdW5uZWNlc3NhcnkgZHVlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byB0aGUgVENQIHBvaW50IHJhaXNlZCBhYm92 ZSwgYnV0IGFueSB0aGF0IHJlbWFpbiBpbiB0aGUgcHJvdG9jb2w8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNob3VsZCBiZSBmdWxseSBzcGVjaWZp ZWQgdG8gZW5zdXJlIHByZWRpY3RhYmxlL2NvbnNpc3RlbnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlaGF2aW9yIGZyb20gaW1wbGVtZW50YXRp b25zLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0g RGF0YSBJdGVtcyBhcmUgZGVmaW5lZCBmb3IgJnF1b3Q7RXh0ZW5zaW9ucyZxdW90OyBhbmQgJnF1 b3Q7RXhwZXJpbWVudGFsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBEZWZpbml0aW9uJnF1b3Q7IChTZWN0aW9ucyA4LjcgYW5kIDguOCkuJm5ic3A7 IEJvdGggc2VlbSB0byBzdXBwb3J0IGZvcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgb3B0aW9uYWwgbWVjaGFuaXNtcywgYnV0IHRoZSBmb3JtZXIg dXNlcyBhc3NpZ25lZCBudW1lcmljIHZhbHVlcyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoeSB0aGUgbGF0dGVyIHVzZXMgVVRGLTggc3RyaW5n cy48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8g V2hhdCwgaWYgYW55LCBpcyB0aGUgaW50ZW5kZWQgZGlzdGluY3Rpb24vcmVsYXRpb25zaGlwIGJl dHdlZW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHRoZXNlPzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgbyBIb3cgZG9lcyBhbiAmcXVvdDtFeHBlcmltZW50YWwgRGVmaW5pdGlv biZxdW90OyBiZWNvbWUgc3RhbmRhcmRpemVkPzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gU2VjdGlvbnMgOC4xOSBhbmQgOC4yMCBkZWZpbmUgJnF1 b3Q7UmVzb3VyY2VzJnF1b3Q7IHJlbGF0ZWQgRGF0YSBJdGVtcy4mbmJzcDsgVGhlPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZpbml0aW9uIHJl bGF0ZWQgdG8gdGhlc2UgYmFzaWNhbGx5IHNheXMgYSByZXNvdXJjZXMgaXMgJnF1b3Q7QW48YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDgtYml0IGlu dGVnZXIgcGVyY2VudGFnZSwgMC0xMDAsIHJlcHJlc2VudGluZyB0aGUgYW1vdW50IG9mPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNvdXJjZXMg YWxsb2NhdGVkIHRvIHJlY2VpdmluZ3x0cmFuc21pdHRpbmcgZGF0YS4mcXVvdDsuJm5ic3A7IElm IEkgd2VyZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgaW1wbGVtZW50aW5nIHRoaXMgcHJvdG9jb2wsIEknZCBoYXZlIG5vIGlkZWEgaG93IHRvIHBy b2R1Y2UsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB1cGRhdGUgb3IgdXNlIHRoaXMgaW5mb3JtYXRpb24uJm5ic3A7IEkgdGhpbmsgdGhlcmUgaXMg c29tZSBtaXNzaW5nPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBpbmZvcm1hdGl2ZSBhbmQgbm9ybWF0aXZlIChSRkMgMjExOSkgdGV4dCByZWxhdGVk IHRvIHRoZXNlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBmb3JtYXRzLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0gU2VjdGlvbnMgOC4yMSBhbmQgOC4yMiAoUmVsYXRpdmUgTGluayBRdWFsaXR5KSBo YXZlIGEgc2ltaWxhcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcHJvYmxlbSBvZiBiZWluZyB1bmRlciBkZXNjcmliZWQsIGluIHBhcnRpY3VsYXIg aXQncyB1bmNsZWFyIGlmPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB0aGVyZSdzIGEgbWVhbmluZ2Z1bCwgbm9uLXByb3ByaWV0YXJ5IGRlZmluaXRp b24gZm9yIGxpbmsgcXVhbGl0eTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBpcyB0byBhY3Qgb24gb3IgaWYg dGhlIHBhc3NlZCB2YWx1ZSBpcyBqdXN0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBwYXNzZWQgZm9yIGFzIG1vbml0b3JpbmcgaW5mb3JtYXRpb24u Jm5ic3A7IEVpdGhlciB3YXksIHRoaXMgbmVlZHMgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIGNsYXJpZmllZC48YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFNlY3Rpb24gOSBkZWZpbmVzIGEg JnF1b3Q7Y3JlZGl0LXdpbmRvd2luZyBzY2hlbWUgYW5hbG9nb3VzIHRvIHRoZSBvbmU8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRvY3VtZW50ZWQg aW4gW1JGQzU1NzhdJnF1b3Q7LiBJdCBkZXNjcmliZXMgaG93IGNyZWRpdHMgYXJlIGV4Y2hhbmdl ZCw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJ1 dCBpdCBwcm92aWRlcyB6ZXJvIGRlZmluaXRpb24gb24gdGhlIGltcGxpY2F0aW9ucyBvciB1c2Ug b2Y8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNy ZWRpdHMgcmVsYXRpdmUgdG8gdGhlIGRhdGEgcGxhbmUuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBNdWx0aXBsZSB3YXlzIHRvIGltcGxlbWVudCB0 aGUgc2FtZSBmdW5jdGlvbiBhcmUgYWxsb3dlZCwgZS5nLiw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wdGlvbmFsIHByZXNlbmNlIG9mIFN0YXR1 cywgSW50ZXJ2YWwgYW5kIFRDUCBwb3J0LiZuYnNwOyBHZW5lcmFsbHk8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFsbG93aW5nIHN1Y2ggY29tcGxp Y2F0ZXMgdGVzdGluZyBhbmQgbGVhZHMgdG8gaW50ZXJvcGVyYWJpbGl0eTxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXNzdWVzLiZuYnNwOyBUaGUg ZG9jdW1lbnQgc2hvdWxkIHBpY2sgb25lIHdheSBhbmQgcmVxdWlyZSBpdC48YnI+DQomZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRoZSBkb2N1bWVudCBkb2Vz bid0IHN0YXRlIGlmIHRoZXJlIGFyZSBhbnkgb3JkZXJpbmcgcmVxdWlyZW1lbnRzPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvbiBkYXRhIGl0ZW1z LiBJdCBzaG91bGQgYmUgZXhwbGljaXQgb24gdGhpcywgZS5nLiwgdGhlcmUgYXJlIG5vPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvcmRlcmluZyBy ZXF1aXJlbWVudHMgb24gdGhlIHBsYWNlbWVudCBvZiBEYXRhIEl0ZW1zIHdpdGhpbjxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2lnbmFscy48YnI+ DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRoZSByZXF1 aXJlZCBhbmQgb3B0aW9uYWwgZGF0YSBpdGVtcyB0aGF0IGFyZSBwZXJtaXR0ZWQgb24gYTxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2lnbmFsIGlz bid0IGFsd2F5cyBjbGVhci4mbmJzcDsgRm9yIGV4YW1wbGUgYXJlIDAvMS9OIGNvcGllcyBvZiBh PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXJ0 aWN1bGFyIERhdGEgSXRlbSByZXF1aXJlZC9hbGxvd2VkLiZuYnNwOyBVc2luZyBzb21ldGhpbmcg bGlrZSBBQk5GPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB3b3VsZCByZWFsbHkgaGVscCBmb3JtYWxpemUgYW5kIGNsYXJpZnkgdGhpcy48YnI+DQom Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRoZSBkb2N1bWVu dCBkb2Vzbid0IGNsZWFybHkgZGVsaW5lYXRlIGZyb20gaW5mb3JtYXRpdmUvbmFycmF0aXZlPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0ZXh0LCBu b3JtYXRpdmUgLyByZXF1aXJlZCBwcm9jZXNzaW5nIHByb2NlZHVyZXMsIGFuZCBtZXNzYWdlPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb3JtYXRz LiBUaGlzIGJ5IGl0c2VsZiBpcyBub3QgbmVjZXNzYXJpbHkgYSBtYWpvciBpc3N1ZSwgaXQganVz dDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFr ZXMgaXQgaGFyZGVyIHRvICh3cml0ZSwpIHJldmlldyBhbmQgaW1wbGVtZW50IHRoZSBwcm90b2Nv bC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdo YXQgaXMgYSBtYWpvciBpc3N1ZSBpcyB0aGF0IHRoaXMgYXBwcm9hY2ggYWxsb3dzIGZvciBkdXBs aWNhdGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IChhbmQgc29tZXRpbWVzIGNvbnRyYWRpY3RvcnkpIG5vcm1hdGl2ZSBwcm9jZWR1cmVzIGFuZCBm b3I8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9t aXNzaW9ucyBpbiBwcm9jZWR1cmVzIChwYXJ0aWN1bGFybHkgcmVsYXRlZCB0byBleGNlcHRpb24v ZXJyb3I8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHByb2Nlc3NpbmcpLiZuYnNwOyBTcGVjaWZpYyBleGFtcGxlcyBhcmUgaW5jbHVkZWQgYWJvdmUg YW5kIGJlbG93LiZuYnNwOyBJdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgd291bGQgYmUgYmVzdCB0byBlbnN1cmUgdGhhdCBlYWNoIHJlcXVpcmVk IHByb2Nlc3NpbmcgYmVoYXZpb3IgaXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmluZWQganVzdCBvbmNlIGFuZCBpbiBhIGNvbnNpc3RlbnQg d2F5Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0g VGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBpcyBpbmFkZXF1YXRlLiZuYnNwOyBU aGlzIHNlY3Rpb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNob3VsZCBhZGRyZXNzIHRoZSBzZWN1cml0eSBvZiB0aGUgRExFUCBwcm90b2NvbCwg bm90IHVzZXI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRyYWZmaWMuJm5ic3A7IEl0IHNob3VsZCBpbmNsdWRlIGFuIGFuYWx5c2lzIG9mIHJpc2tz L3RocmVhdHMvcG9zc2libGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGV4cGxvaXRzIGFuZCBob3cgdGhlc2UgYXJlIG1pdGlnYXRlZCBieSB0aGUg cHJvdG9jb2wuJm5ic3A7IHJmYzY5NTIsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgdGhlIHByb3RvY29scyBpdCByZWZlcmVuY2VzIGNhbiBz ZXJ2ZSBhcyBleGFtcGxlcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBNaW5vciBJc3N1ZXM6PGJyPg0K Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBUaGUgZGF0YSBh bmQgc2lnbmFsIHR5cGUgZmllbGRzIGFyZSBib3RoIDggYml0cy4mbmJzcDsgVGhpcyBzZWVtczxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJldHR5 IHNtYWxsLCBwYXJ0aWN1bGFybHkgdGhlIGRhdGEgdHlwZSBmaWVsZC4mbmJzcDsgR2l2ZW4gdGhp cyBpcyBhPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBjb250cm9sIHByb3RvY29sLCBJIHRoaW5rIGEgbGFyZ2VyIChhdCBsZWFzdCBkYXRhIHR5cGUp IGZpZWxkPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB3b3VsZCBwcm92aWRlIGJldHRlciAmcXVvdDtmdXR1cmUgcHJvb2ZpbmcmcXVvdDsuPGJyPg0K Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSAyXjMyIHZlcnNp b25zIGFyZSBjdXJyZW50bHkgYWxsb3dlZCAoc2VjdGlvbiA4LjEpLiZuYnNwOyBUaGlzIHNlZW1z IGE8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJp dCBleGNlc3NpdmUuJm5ic3A7IEknZCBvcHQgZm9yIG1heCBvZiA4IGJpdHMgaGVyZSBteXNlbGYu PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBJdCdz IHByb2JhYmx5IHRvbyBsYXRlLCBidXQgaXQgcHJvYmFibHkgd291bGQgYmUgY2xlYW5lciB0byBo YXZlIGE8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGdlbmVyaWMgYWNrIHNpZ25hbCByYXRoZXIgdGhhbiBhIHBlciBzaWduYWwgdHlwZSBhY2suIEkg bWVudGlvbjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdGhpcyBoZXJlIGFzIHRoaXMgbWF5IGNvbWUgdXAgYWdhaW4gd2hlbiBjbGFyaWZ5aW5nIHRo ZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHJh bnNhY3Rpb24gbW9kZWwgKGFzIG1lbnRpb25lZCBhYm92ZS4pPGJyPg0KJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBTZWN0aW9uIDI6IEFzc3VtcHRpb25zPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIHNl Y3Rpb24gaW5jbHVkZXMgaW5mb3JtYXRpdmUgYW5kIG5vcm1hdGl2ZSB0ZXh0IHNvIGlzIG1vcmU8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYW4g anVzdCBBc3N1bXB0aW9ucy4mbmJzcDsgUGVyc29uYWxseSwgSSdkIHJlbW92ZSBhbGwgbm9ybWF0 aXZlIHRleHQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGZyb20gdGhlIHNlY3Rpb24uPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLSBUaGVyZSBhcmUgbm8gc3BlY2lmaWMgcnVsZXMgcmVsYXRlZCB0byBV RFAgaGVhZGVyIGZvcm1hdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtIFNlY3Rpb25zIDguMTAtJmd0OzguMTcuJm5ic3A7IElzbid0IGFkZC9k cm9wIGluZGljYXRvciBuZWVkZWQgZm9yIHN1Ym5ldHM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIGRlc3RpbmF0aW9uIHVwZGF0ZSBzaWduYWxz Pzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gVGhl IElBTkEgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbnMgbXVzdCBmb2xsb3figIsgUkZDMjM2MC48YnI+ DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIE5ldyByZWdp c3RyaWVzIG11c3QgaW5jbHVkZSBpbml0aWFsIHZhbHVlcywgd2hpY2ggYXJlIGRlZmluZWQgaW48 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBk b2N1bWVudC4mbmJzcDsgKFRoZSBkb2N1bWVudCBjdXJyZW50bHkgaGFzIG1hbnkgVEJEcyB0aGF0 IHNob3VsZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYmUgcmVwbGFjZWQuKTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0gTmV3IHJlZ2lzdHJpZXMgbmVlZCBhbiBhbGxvY2F0aW9uIHBvbGljeSwgZS5n Ljo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSByZWdpc3RyeSBz aG91bGQgYmUgZXN0YWJsaXNoZWQgd2l0aCByZWdpc3RyYXRpb24gcG9saWNpZXMgb2Y8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O1N0YW5kYXJkcyBBY3Rpb24m cXVvdDsgKGZvciBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnRzKSBhbmQ8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnFNwZWNpZmljYXRpb24gUmVxdWlyZWQmcXVvdDsg KGZvciBvdGhlciBkb2N1bWVudHMpLiBUaGUgZGVzaWduYXRlZDxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZXhwZXJ0IGlzIGFueSBjdXJyZW50ICZsdDtmaWxsLWluJmd0 OyBXRyBjaGFpci48YnI+DQomZ3Q7PGJyPg0KJmd0OyBOaXRzOjxicj4NCiZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gVGhlIGRvY3VtZW50IGludHJvZHVjZXMg dGhlIHRlcm1zICZxdW90O3NpZ25hbHMmcXVvdDsgYW5kICZxdW90O2RhdGEgaXRlbXMmcXVvdDsg Zm9yPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3 aGF0IGlzIGNvbW1vbmx5IGNhbGxlZCAmcXVvdDttZXNzYWdlcyZxdW90OyBhbmQgJnF1b3Q7VExW cyZxdW90OyAob3Igb2JqZWN0cykgaW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IG90aGVyIHByb3RvY29scy4mbmJzcDsgSXQncyBwcm9iYWJseSB0 b28gbGF0ZSB0byBjaGFuZ2UgdGhpcywgYnV0IEk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaW5rIHRoZSBpbnRyb2R1Y3Rpb24gb2YgdW5pcXVl IHRlcm1pbm9sb2d5IGlzIGNvdW50ZXI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb2R1Y3RpdmUuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBVc2Ugb2YgUkZDIDIxMTkgY29uZm9ybWFuY2UgbGFu Z3VhZ2UgaXMgYSBiaXQgcm91Z2gsIGFuZCB0aGVyZSBhcmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdvcmRzIGluIGFsbCBjYXBzIHRoYXQgYXJl IG5vdCBkZWZpbmVkIGluIFJGQzIxMTkuIFRha2UgYSBsb29rIGF0PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy93Zy90ZWFzL3RyYWMvd2lraS9QU0d1aWRlbGluZSI+aHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvd2cvdGVhcy90cmFjL3dpa2kvUFNHdWlkZWxpbmU8L2E+IGZvciBzb21l PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdWdn ZXN0aW9ucy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtIEludGVybmFsIHNvY2tldCBvcGVyYXRpb24gaXMgbWVudGlvbmVkIGEgY291cGxlIG9mIHRp bWVzLiZuYnNwOyBJdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcmVhbGx5IHNob3VsZG4ndCBiZSwgdGhlIHNwZWMgc2hvdWxkIGRlZmluZSBiZWhh dmlvciBvbiB0aGUgd2lyZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtIFRoZSBMZW5ndGggZmllbGRzIGFyZSBtaXNzaW5nIHVuaXQgb2YgbWVhc3Vy ZSAocHJlc3VtYWJseSBvY3RldHMpPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLSBUaGUgTW5lbW9uaWNzIGFyZSB1c2VkIGJhc2ljYWxseSBvbmNlIGFu ZCBkb24ndCByZWFsbHkgYWRkIHZhbHVlLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgc3VnZ2VzdCBkcm9wcGluZyB0aGVtLjxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gSG93L3doZW4gaXMgdGhlICZx dW90O1Vua25vd24gU2lnbmFsJnF1b3Q7IFN0YXR1cyBDb2RlIHNlbnQ/PGJyPg0KJmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBTZWN0aW9uIDguNzogRXh0ZW5z aW9uIExpc3Qgc2hvdWxkIGJlIHNob3duIGFzIGEgdmFyaWFibGUgbGVuZ3RoPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmaWVsZC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFNlY3Rpb24gOC44OiBF eHBlcmltZW50IExpc3Qgc2hvdWxkIGJlIHNob3duIGFzIGEgdmFyaWFibGUgbGVuZ3RoPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmaWVsZC48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBUaGF0J3MgaXQgLS0gZm9yIG5vdyAtLSBob3BlZnVsbHkgSSBkaWRu J3QgbWlzcyBhbnl0aGluZy4mbmJzcDsgTG9vayBmb3J3YXJkIHRvIGhlYXJpbmcgcmVzcG9uc2Ug dG8gdGhlIGFib3ZlIChhbmQgaG93IEkgZ290IHRoaW5ncyBob3BlbGVzc2x5IHdyb25nIDstKTxi cj4NCiZndDs8YnI+DQomZ3Q7IExvdTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7IG1hbmV0IG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm1hbmV0 QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PGJyPg0KJmd0OyAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCiZn dDsgVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhl IGludGVuZGVkPGJyPg0KJmd0OyByZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4NCiZndDsgcmVjaXBpZW50IHBsZWFzZSBk ZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPg0KJmd0 OyBZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRp c2Nsb3NlIG9yPGJyPg0KJmd0OyBkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIg cGVyc29uLjxicj4NCiZndDsgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBtYW5ldCBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5v cmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21hbmV0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0 PC9hPjxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8QlI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojMDAzMzY2Jz4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188QlI+IApUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBhbmQgYW55IGZpbGVzIHRy YW5zbWl0dGVkIHdpdGggaXQgY29udGFpbnM8QlI+CmluZm9ybWF0aW9uIGZyb20gaURpcmVjdCwg d2hpY2ggbWF5IGJlIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5PEJSPgphbmQvb3IgY29uZmlkZW50 aWFsLiBJdCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWw8 QlI+Cm9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3Qg dGhlIG9yaWdpbmFsPEJSPgpyZWNpcGllbnQgb3IgdGhlIHBlcnNvbiByZXNwb25zaWJsZSBmb3Ig ZGVsaXZlcmluZyB0aGUgZW1haWwgdG8gdGhlPEJSPiBpbnRlbmRlZCByZWNpcGllbnQsIGJlIGFk dmlzZWQgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsPEJSPgppbiBlcnJvciwgYW5k IHRoYXQgYW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgZm9yd2FyZGluZywgcHJpbnRpbmcsIG9yPEJS PiBjb3B5aW5nIG9mIHRoaXMgZW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IHJl Y2VpdmVkIHRoaXMgZW1haWw8QlI+CmluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBpbW1l ZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlci48QlI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fIAo8L1NQQU4+PC9ib2R5Pg0KPC9odG1sPg0K --_000_75a095cff2c2410d9cf1cd35fc60657eVAUSDITCHM3idirectnet_-- From nobody Tue Jun 16 06:52:15 2015 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 BDA701B360A for ; Tue, 16 Jun 2015 06:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 8Z4VfQhOd2JB for ; Tue, 16 Jun 2015 06:52:02 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id B25951B3610 for ; Tue, 16 Jun 2015 06:51:59 -0700 (PDT) Received: (qmail 31196 invoked by uid 0); 16 Jun 2015 13:51:57 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 16 Jun 2015 13:51:57 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id h1kB1q00M2SSUrH011kEGC; Tue, 16 Jun 2015 07:44:22 -0600 X-Authority-Analysis: v=2.1 cv=O/iq4nNW c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=d8zPNJv4eCMA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=a6pu-KQ2AAAA:8 a=UHigiq0Vrfw1ecXlO6AA:9 a=tjUArHptcPn_z9Qv:21 a=ArooQ6aq3pEEzGC_:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=bDdQKmH3XfX1yVnIOTfIGSEYi+8ev+f8d/y87ELTuy4=; b=RVCga0wWyIjdHMd2NyC97PWwfgIncg6yRnd51yoyK+dxOqaLIIN0E5nl19FebccNkjmNEMBnJtjP6y2wEZmrTSre1xIAHBe5Dr2GXmkciwr+PpFNg3QTJXhhwfpU6OFc; Received: from box313.bluehost.com ([69.89.31.113]:47573 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z4rHG-0001r4-Lp; Tue, 16 Jun 2015 07:51:46 -0600 Message-ID: <558029EF.7090807@labn.net> Date: Tue, 16 Jun 2015 09:51:43 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Ratliff, Stanley" , bebemaster , Rick Taylor , "Dearlove, Christopher (UK)" , "manet-chairs@ietf.org" , "manet-ads@ietf.org" References: <75a095cff2c2410d9cf1cd35fc60657e@VAUSDITCHM3.idirect.net> In-Reply-To: <75a095cff2c2410d9cf1cd35fc60657e@VAUSDITCHM3.idirect.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "rtg-dir@ietf.org" , "manet@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 13:52:05 -0000 I'm available to discuss my comments at any point & with anyone (including non-authors) who may wish. I also think there's a meta question implicit in my comments for the WG and AD to discuss, i.e., how much protocol change does the WG/AD want to do at this point vs just improving / fully documenting the protocol as it now stands? As just a reviewer, I don't expect to contribute to the discussion on this question. Lou On 06/16/2015 08:53 AM, Ratliff, Stanley wrote: > As Rick said – we will when we have a plan. > > > > Stan > > > > > > > > *From:*bebemaster [mailto:bebemaster@gmail.com] > *Sent:* Tuesday, June 16, 2015 7:25 AM > *To:* Rick Taylor; Dearlove, Christopher (UK); Lou Berger; > manet-chairs@ietf.org > *Cc:* manet-ads@ietf.org; rtg-dir@ietf.org; manet@ietf.org; > draft-ietf-manet-dlep.all@ietf.org > *Subject:* Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 > > > > It would be appropriate to have some of that discussion on the list. > There is quite a lot of interest in this draft within the wg and getting > input on best ways forward on the various fixes before they are written > up should end up saving time. > > > > Justin > > > > -------- Original message -------- > > From: Rick Taylor > > Date:06/16/2015 5:00 AM (GMT-05:00) > > To: "Dearlove, Christopher (UK)" , Lou Berger , manet-chairs@ietf.org > > > Cc: manet-ads@ietf.org , rtg-dir@ietf.org > , manet@ietf.org , > draft-ietf-manet-dlep.all@ietf.org > > > Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 > > > > All, > > Stan and I are currently discussing the review. We will come back to > the list with a proposed set of actions when we have a plan. > > Sorry for the delay, > > Rick > > > On 15/06/15 12:16, Dearlove, Christopher (UK) wrote: >> I haven't seen any discussion of this. It looks to me like requiring > another draft for the WG to see. It does (by my rapid count) have 17 > major issues. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence >> __________________________________________________________________________ >> >> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com > >> >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >> >> >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lou Berger >> Sent: 08 June 2015 20:11 >> To: manet-chairs@ietf.org >> Cc: manet-ads@ietf.org ; rtg-dir@ietf.org > ; manet@ietf.org ; > draft-ietf-manet-dlep.all@ietf.org > >> Subject: [manet] RtgDir review: draft-ietf-manet-dlep-14 >> >> ----------------------! WARNING ! ---------------------- This message > originates from outside our organisation, either from an external > partner or from the internet. >> Consider carefully whether you should click on any links, open any > attachments or reply. >> Follow the 'Report Suspicious Emails' link on IT matters for > instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> [Note this is a WG LC related review, not IETF LC.] >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request -- or WG Last call as was the > case here . The purpose of the review is to provide assistance to the > Routing ADs. For more information about the Routing Directorate, please > see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the (chairs and) > Routing ADs, it would be helpful if you could consider them along with > any other Last Call comments that you receive, and strive to resolve > them through discussion or by updating the draft. >> >> Document: draft-ietf-manet-dlep-14 >> Reviewer: Lou Berger >> Review Date: June 8 (later than requested due to scope of comments -- > sorry) WG LC End Date: unknown Intended Status: Standards track >> >> Summary: >> >> While I think the document is pretty decent for the scope of the >> work, I do have concerns about this document and recommend that the >> WG Chairs/Routing ADs discuss these issues further with the authors. >> I'm also available as/if needed to discuss. >> >> Comments: >> >> I think the document shows significant good work and looks to be a >> useful protocol, although I'm not overly familiar in this space. >> That said, I have a number of serious concerns about the document, >> and its contents from a few of perspectives. These include basic >> protocol issues, underspecified details (which could lead to >> interoperability issues), and specification/editorial issues. I >> think the document / protocol can be modified to address the issues >> I raise below. Of course, it is up to the WG, chairs, and ADs to >> decide which comments to address and which to ignore. >> I don't expect that all comments will result in changes. >> >> Major Issues: >> >> - The length field of the generic data item (i.e., TLV) is only 8 >> bits. While 255 bytes (assuming that this is the unit of measure, >> which BTW isn't specified) is big enough today, allowing for >> larger will greatly simplify things when 255 isn't enough. -- >> We've run into this in RSVP and it's a real pain. >> >> - Version number is currently defined as a data item. This means a >> signal (i.e., message) needs to be potentially fully parsed to >> discover what version is being used. This precludes basic format >> changes to the protocol. Perhaps the Discovery and Init Signals >> should be special cased to include version in their formats. (And >> shorten version to 8 bits from 32, as mentioned below). >> >> - The document references, but does not define, 'in-session' and >> 'discovery' states. These either need to be formally defined or >> removed. BTW we had exactly the same issue with LMP (RFC4204) and >> ended up adding section 11 (FSMs) at a pretty late stage of the >> process. >> >> - TCP session management is not defined, nor is the relationship >> with TCP and DLEP sessions fully defined. For example: >> >> o Closing the TCP session is only mentioned in one place and in a >> way that is inconsistent with the expected protocol behavior >> (close TCP before ACK is received). >> >> o What happens when a DLEP session is terminated, can the TCP >> session be reused or must it be closed too? >> >> - There is no transaction model defined. For example, it's >> completely unclear if only one unacknowledged Signal allowed at a >> time, or perhaps just one per signal type is allowed, or perhaps >> there are no restrictions. This needs to be explicit. >> >> - What is the purpose of retries and timeouts over TCP? Retries >> aren't needed over TCPs and it's unclear whey they are being used. >> >> - The higher level implications of ACKs, over TCP, isn't really >> clear. It seems ACKs are defined for multiple purposes: reliable >> transport, transaction acknowledgment and transaction results. Of >> course the first isn't needed, and implications of the others >> should be clear. For example, in section 7.10, why would there be >> a retry when receiving a Destination Up ACK signal indicating an >> error? >> >> - There is no discussion on scaling considerations. Are there really >> none? For example, how often might be appropriate to issue/limit >> Peer Updates based to changes in link quality, or how to handle >> the case where a large number (all or most) of destinations go >> down. >> >> - There are 13 places where the protocol allows implementation to >> define their own 'heuristics'. Some of these seem unnecessary due >> to the TCP point raised above, but any that remain in the protocol >> should be fully specified to ensure predictable/consistent >> behavior from implementations. >> >> - Data Items are defined for "Extensions" and "Experimental >> Definition" (Sections 8.7 and 8.8). Both seem to support for >> optional mechanisms, but the former uses assigned numeric values, >> why the latter uses UTF-8 strings. >> o What, if any, is the intended distinction/relationship between >> these? >> o How does an "Experimental Definition" become standardized? >> >> - Sections 8.19 and 8.20 define "Resources" related Data Items. The >> definition related to these basically says a resources is "An >> 8-bit integer percentage, 0-100, representing the amount of >> resources allocated to receiving|transmitting data.". If I were >> implementing this protocol, I'd have no idea how to produce, >> update or use this information. I think there is some missing >> informative and normative (RFC 2119) text related to these >> formats. >> >> - Sections 8.21 and 8.22 (Relative Link Quality) have a similar >> problem of being under described, in particular it's unclear if >> there's a meaningful, non-proprietary definition for link quality >> that an implementation is to act on or if the passed value is just >> passed for as monitoring information. Either way, this needs to >> be clarified. >> >> - Section 9 defines a "credit-windowing scheme analogous to the one >> documented in [RFC5578]". It describes how credits are exchanged, >> but it provides zero definition on the implications or use of >> credits relative to the data plane. >> >> - Multiple ways to implement the same function are allowed, e.g., >> optional presence of Status, Interval and TCP port. Generally >> allowing such complicates testing and leads to interoperability >> issues. The document should pick one way and require it. >> >> - The document doesn't state if there are any ordering requirements >> on data items. It should be explicit on this, e.g., there are no >> ordering requirements on the placement of Data Items within >> Signals. >> >> - The required and optional data items that are permitted on a >> signal isn't always clear. For example are 0/1/N copies of a >> particular Data Item required/allowed. Using something like ABNF >> would really help formalize and clarify this. >> >> - The document doesn't clearly delineate from informative/narrative >> text, normative / required processing procedures, and message >> formats. This by itself is not necessarily a major issue, it just >> makes it harder to (write,) review and implement the protocol. >> What is a major issue is that this approach allows for duplicate >> (and sometimes contradictory) normative procedures and for >> omissions in procedures (particularly related to exception/error >> processing). Specific examples are included above and below. It >> would be best to ensure that each required processing behavior is >> defined just once and in a consistent way. >> >> - The security consideration section is inadequate. This section >> should address the security of the DLEP protocol, not user >> traffic. It should include an analysis of risks/threats/possible >> exploits and how these are mitigated by the protocol. rfc6952, >> and the protocols it references can serve as examples. >> >> Minor Issues: >> >> - The data and signal type fields are both 8 bits. This seems >> pretty small, particularly the data type field. Given this is a >> control protocol, I think a larger (at least data type) field >> would provide better "future proofing". >> >> - 2^32 versions are currently allowed (section 8.1). This seems a >> bit excessive. I'd opt for max of 8 bits here myself. >> >> - It's probably too late, but it probably would be cleaner to have a >> generic ack signal rather than a per signal type ack. I mention >> this here as this may come up again when clarifying the >> transaction model (as mentioned above.) >> >> - Section 2: Assumptions >> This section includes informative and normative text so is more >> than just Assumptions. Personally, I'd remove all normative text >> from the section. >> >> - There are no specific rules related to UDP header formation. >> >> - Sections 8.10->8.17. Isn't add/drop indicator needed for subnets >> in destination update signals? >> >> - The IANA Considerations sections must follow​ RFC2360. >> >> - New registries must include initial values, which are defined in >> the document. (The document currently has many TBDs that should >> be replaced.) >> >> - New registries need an allocation policy, e.g.: >> The registry should be established with registration policies of >> "Standards Action" (for Standards Track documents) and >> “Specification Required" (for other documents). The designated >> expert is any current WG chair. >> >> Nits: >> >> - The document introduces the terms "signals" and "data items" for >> what is commonly called "messages" and "TLVs" (or objects) in >> other protocols. It's probably too late to change this, but I >> think the introduction of unique terminology is counter >> productive. >> >> - Use of RFC 2119 conformance language is a bit rough, and there are >> words in all caps that are not defined in RFC2119. Take a look at >> http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuideline for some >> suggestions. >> >> - Internal socket operation is mentioned a couple of times. It >> really shouldn't be, the spec should define behavior on the wire. >> >> - The Length fields are missing unit of measure (presumably octets) >> >> - The Mnemonics are used basically once and don't really add value, >> suggest dropping them. >> >> - How/when is the "Unknown Signal" Status Code sent? >> >> - Section 8.7: Extension List should be shown as a variable length >> field. >> >> - Section 8.8: Experiment List should be shown as a variable length >> field. >> >> That's it -- for now -- hopefully I didn't miss anything. Look > forward to hearing response to the above (and how I got things > hopelessly wrong ;-) >> >> Lou >> >> >> >> _______________________________________________ >> 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. >> ******************************************************************** >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > _____________________________________________________ > This electronic message and any files transmitted with it contains > information from iDirect, which may be privileged, proprietary > and/or confidential. It is intended solely for the use of the individual > or entity to whom they are addressed. If you are not the original > recipient or the person responsible for delivering the email to the > intended recipient, be advised that you have received this email > in error, and that any use, dissemination, forwarding, printing, or > copying of this email is strictly prohibited. If you received this email > in error, please delete it and immediately notify the sender. > _____________________________________________________ From nobody Tue Jun 16 07:14:19 2015 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 72FBF1B2D32; Tue, 16 Jun 2015 07:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKSAD-RSmuL8; Tue, 16 Jun 2015 07:14:16 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03961B3625; Tue, 16 Jun 2015 07:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=726; q=dns/txt; s=iport; t=1434464046; x=1435673646; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=altjsTGMmze7DuGF36RtVpLPoSYZBZhe17mm7q8jv84=; b=YYzfnygS14XADJ8uy5DQRgGzkpDJzcxbPm46T+S4imwxrXvIB0m91R/A 1OR0jGuZrrb32ySb82eJIo7veqKtU//bvWtfpIHM2WBF7ecBglsbqMRyk Lbm7q1LL5UXY2khMA56GETxLRd4rsj0e5LvKG34d4NyipU0gDLXwFEA/h M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMBQCHLoBV/5JdJa1bgxCBMwbFfAKBPTwQAQEBAQEBAYEKhCMBAQQOVxQQAgEIDjgyJQIEAQ0FiC/NMwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLRIRTMweELQEEjDOEWIJUAYtEmBgmY4MWb4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,626,1427760000"; d="scan'208";a="159757195" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP; 16 Jun 2015 14:14:05 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5GEE5Au024805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jun 2015 14:14:05 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.106]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 16 Jun 2015 09:14:05 -0500 From: "Alvaro Retana (aretana)" To: Lou Berger , "manet@ietf.org" , "draft-ietf-manet-dlep@ietf.org" Thread-Topic: [RTG-DIR] [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqCcamPS5xoKVN0yf0KgyeSisLZ2vanaAgAAQNYD//9PwgA== Date: Tue, 16 Jun 2015 14:14:04 +0000 Message-ID: References: <75a095cff2c2410d9cf1cd35fc60657e@VAUSDITCHM3.idirect.net> <558029EF.7090807@labn.net> In-Reply-To: <558029EF.7090807@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.139] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , "manet-chairs@ietf.org" Subject: Re: [manet] [RTG-DIR] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 14:14:17 -0000 On 6/16/15, 10:51 AM, "Lou Berger" wrote: Lou: thanks for the review! >I also think there's a meta question implicit in my comments for the WG >and AD to discuss, i.e., how much protocol change does the WG/AD want to >do at this point vs just improving / fully documenting the protocol as >it now stands? WG: Lou is absolutely right! He points out good improvement recommendations based on his experience, but we clearly need to balance the changes against the existing implementations and their impact on them. As a point of reference to adopt (or not) some of Lou=B9s comments, I suggest that the authors add an =B3Implementation Status=B2 section (rfc698= 2). Thanks! Alvaro. From nobody Tue Jun 16 09:37:19 2015 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 8B9961B2ED5; Tue, 16 Jun 2015 09:37:18 -0700 (PDT) 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 UOLi6qTMNAtn; Tue, 16 Jun 2015 09:37:17 -0700 (PDT) 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 DB64C1B2EEE; Tue, 16 Jun 2015 09:37:13 -0700 (PDT) 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 Jun 2015 17:36:41 +0100 From: Rick Taylor To: "Alvaro Retana (aretana)" , Lou Berger , "manet@ietf.org" , "draft-ietf-manet-dlep@ietf.org" Thread-Topic: [manet] [RTG-DIR] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqD7JyOM2vDUuBkWvQJV0OOC6+Q== Date: Tue, 16 Jun 2015 16:36:39 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C29C91A@tss-server1.home.tropicalstormsoftware.com> References: <75a095cff2c2410d9cf1cd35fc60657e@VAUSDITCHM3.idirect.net> <558029EF.7090807@labn.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , "manet-chairs@ietf.org" Subject: Re: [manet] [RTG-DIR] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 16:37:18 -0000 I think from Stan and my perspective:=0A= =0A= 1) Suggested text changes and improvements will be addressed.=0A= =0A= 2) Minor protocol changes, such as changing bit lengths of version =0A= numbers may be addressed.=0A= =0A= 3) Major protocol changes, such as a single ACK signal for all signals, =0A= will not be addressed, (that particular example had already been =0A= discussed at length and the current way of working is preferred)=0A= =0A= Some comments are based on a misreading of the text, which we take as an = =0A= indication that the missed point was not described clearly enough.=0A= =0A= For the IANA topics, I call on Stan's superior knowledge for guidance.=0A= =0A= Rick=0A= =0A= (Bit rushed off my feet at the moment, but I will reply to the list with = =0A= a full breakdown ASAP)=0A= =0A= On 16/06/15 15:14, Alvaro Retana (aretana) wrote:=0A= > On 6/16/15, 10:51 AM, "Lou Berger" wrote:=0A= >=0A= > Lou: thanks for the review!=0A= >=0A= >> I also think there's a meta question implicit in my comments for the WG= =0A= >> and AD to discuss, i.e., how much protocol change does the WG/AD want to= =0A= >> do at this point vs just improving / fully documenting the protocol as= =0A= >> it now stands?=0A= >=0A= > WG: Lou is absolutely right! He points out good improvement=0A= > recommendations based on his experience, but we clearly need to balance= =0A= > the changes against the existing implementations and their impact on them= .=0A= > As a point of reference to adopt (or not) some of Lou=B9s comments, I= =0A= > suggest that the authors add an =B3Implementation Status=B2 section (rfc6= 982).=0A= >=0A= > Thanks!=0A= >=0A= > Alvaro.=0A= >=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= =0A= From nobody Thu Jun 18 05:38:54 2015 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 3ADD51A8A55; Thu, 18 Jun 2015 05:38:53 -0700 (PDT) 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 I3u5t-N0gRJC; Thu, 18 Jun 2015 05:38:48 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2F01A8A51; Thu, 18 Jun 2015 05:38:47 -0700 (PDT) Received: by wgez8 with SMTP id z8so62620880wge.0; Thu, 18 Jun 2015 05:38:46 -0700 (PDT) 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=lIJotQauVdQPofcC8ipsoUJ8KvTEFl9C7FbtuGwhGjY=; b=hwH+dLe26Oepl4PKQTpmyPB5A/gAY3TEcm/59gByAXl3G3obKMaUXYkrKSt0NkGEEU 4XDAbyCZy+6CZZUaFRVb11hjFn+IOo2RE3lPZ4ZpjbA5+DLZJYUPWoD7TBy8/Ev0MzVf FXP/lI978L2qB0SoOG2o4M2RJzA/ohaUY+ZH6KisZnitHZ8GuS2AKXEcGSRFeXIc9qS2 KNAi4k+sxBkiIC2Mw1wc164x9lWokb8HonnV4RA2YuZmgoYmT2PMPtiCRGGiEGIBmP4i azNBIDatGz1BeExFA6nzat3dS7PFDzLtlt3UYJYU9eTi4rJu8qWlKA9c0wXg8E1srKZZ txYQ== X-Received: by 10.180.88.72 with SMTP id be8mr64729646wib.45.1434631126638; Thu, 18 Jun 2015 05:38:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Thu, 18 Jun 2015 05:38:26 -0700 (PDT) In-Reply-To: <5575E8A7.6030508@labn.net> References: <5575E8A7.6030508@labn.net> From: Henning Rogge Date: Thu, 18 Jun 2015 14:38:26 +0200 Message-ID: To: Lou Berger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: manet-ads@ietf.org, "rtg-dir@ietf.org" , draft-ietf-manet-dlep.all@ietf.org, MANET IETF , manet-chairs@ietf.org Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 12:38:53 -0000 On Mon, Jun 8, 2015 at 9:10 PM, Lou Berger wrote: > [Note this is a WG LC related review, not IETF LC.] > > Hello, Hi... I am NOT one of the DLEP authors, but I have been active during the design process (some people might say "annoyingly active"), so here are my opinions on this review. Hopefully it will be helpful for the authors. > Summary: > > While I think the document is pretty decent for the scope of the > work, I do have concerns about this document and recommend that the > WG Chairs/Routing ADs discuss these issues further with the authors. > I'm also available as/if needed to discuss. > > Comments: > > I think the document shows significant good work and looks to be a > useful protocol, although I'm not overly familiar in this space. > That said, I have a number of serious concerns about the document, > and its contents from a few of perspectives. These include basic > protocol issues, underspecified details (which could lead to > interoperability issues), and specification/editorial issues. I > think the document / protocol can be modified to address the issues > I raise below. Of course, it is up to the WG, chairs, and ADs to > decide which comments to address and which to ignore. > I don't expect that all comments will result in changes. > > Major Issues: > > - The length field of the generic data item (i.e., TLV) is only 8 > bits. While 255 bytes (assuming that this is the unit of measure, > which BTW isn't specified) is big enough today, allowing for > larger will greatly simplify things when 255 isn't enough. -- > We've run into this in RSVP and it's a real pain. On the other side the largest data item we have at the moment is 18 bytes (IPv6 connection point). I am not really seeing lots of use-cases for large data items in DLEP. Still, changing the TLV length to 16 bit would be trivial to do... but would this mean we also should change the signal length field to 4 bytes? > - Version number is currently defined as a data item. This means a > signal (i.e., message) needs to be potentially fully parsed to > discover what version is being used. This precludes basic format > changes to the protocol. Perhaps the Discovery and Init Signals > should be special cased to include version in their formats. (And > shorten version to 8 bits from 32, as mentioned below). Putting it into the UDP based discovery packets as a "header" could work... they are a bit special anyways (UDP) and we don't need to repeat the version later. > - The document references, but does not define, 'in-session' and > 'discovery' states. These either need to be formally defined or > removed. BTW we had exactly the same issue with LMP (RFC4204) and > ended up adding section 11 (FSMs) at a pretty late stage of the > process. I think "discovery phase" is before the TCP connection between radio and router is established. > - TCP session management is not defined, nor is the relationship > with TCP and DLEP sessions fully defined. For example: > > o Closing the TCP session is only mentioned in one place and in a > way that is inconsistent with the expected protocol behavior > (close TCP before ACK is received). Maybe this should be "closing the DLEP session and not using the active TCP session anymore" ? > o What happens when a DLEP session is terminated, can the TCP > session be reused or must it be closed too? No, I think the DLEP strategy is "start from scratch"... when you terminate a DLEP session you go back to the discovery mechanism to start a new one. > - There is no transaction model defined. For example, it's > completely unclear if only one unacknowledged Signal allowed at a > time, or perhaps just one per signal type is allowed, or perhaps > there are no restrictions. This needs to be explicit. I think we don't need restrictions here because of TCP. The other side WILL answer to eachof our signals or the TCP session will be terminated. > - What is the purpose of retries and timeouts over TCP? Retries > aren't needed over TCPs and it's unclear whey they are being used. We want to know when the connection between radio and router is lost... this can take a LONG time when the router is mostly listening to the Radio (TCP timeout is much to long for our use-case), so we use the Heartbeats. > - The higher level implications of ACKs, over TCP, isn't really > clear. It seems ACKs are defined for multiple purposes: reliable > transport, transaction acknowledgment and transaction results. Of > course the first isn't needed, and implications of the others > should be clear. For example, in section 7.10, why would there be > a retry when receiving a Destination Up ACK signal indicating an > error? The DLEP "ACK Signals" are more a response to a "request signal"... transaction acknowledgement and result. > - There is no discussion on scaling considerations. Are there really > none? For example, how often might be appropriate to issue/limit > Peer Updates based to changes in link quality, or how to handle > the case where a large number (all or most) of destinations go > down. Just send as fast as you want and let TCP (buffer) take care of the rest... both Destination up/down are small signals, so it shouldn't be a problem. And you are only allowed to send Destination Updates when you received the Destination ACK. > - There are 13 places where the protocol allows implementation to > define their own 'heuristics'. Some of these seem unnecessary due > to the TCP point raised above, but any that remain in the protocol > should be fully specified to ensure predictable/consistent > behavior from implementations. No comment on this one. > - Data Items are defined for "Extensions" and "Experimental > Definition" (Sections 8.7 and 8.8). Both seem to support for > optional mechanisms, but the former uses assigned numeric values, > why the latter uses UTF-8 strings. > o What, if any, is the intended distinction/relationship between > these? > o How does an "Experimental Definition" become standardized? As far as I understand this "Experimental Definition" is something you use in the lab... you can have a maximum of one experiment for DLEP, so this is more to make sure your special "work in progress" code does not collide too hard with a standard radio/router. On the other side you can support as many "Extensions" as you want... and I expect this WG to standardize a few additional of them after DLEP becomes a RFC. > - Sections 8.19 and 8.20 define "Resources" related Data Items. The > definition related to these basically says a resources is "An > 8-bit integer percentage, 0-100, representing the amount of > resources allocated to receiving|transmitting data.". If I were > implementing this protocol, I'd have no idea how to produce, > update or use this information. I think there is some missing > informative and normative (RFC 2119) text related to these > formats. My only idea about them would be "battery level"... not sure how useful it is to query the radio about this. > - Sections 8.21 and 8.22 (Relative Link Quality) have a similar > problem of being under described, in particular it's unclear if > there's a meaningful, non-proprietary definition for link quality > that an implementation is to act on or if the passed value is just > passed for as monitoring information. Either way, this needs to > be clarified. It seems the radio vendors really like this field. The reason why we made "max/current link speed" mandatory is to make RLQ at least reasonable useful. > - Section 9 defines a "credit-windowing scheme analogous to the one > documented in [RFC5578]". It describes how credits are exchanged, > but it provides zero definition on the implications or use of > credits relative to the data plane. > No comment on this one. > - Multiple ways to implement the same function are allowed, e.g., > optional presence of Status, Interval and TCP port. Generally > allowing such complicates testing and leads to interoperability > issues. The document should pick one way and require it. I think "no status TLV" is always "everything is fine"... > - The document doesn't state if there are any ordering requirements > on data items. It should be explicit on this, e.g., there are no > ordering requirements on the placement of Data Items within > Signals. I think is exactly as most (all?) of us have implemented it... no ordering required. > - The required and optional data items that are permitted on a > signal isn't always clear. For example are 0/1/N copies of a > particular Data Item required/allowed. Using something like ABNF > would really help formalize and clarify this. Can you give an example where this is undefined? As far as I can see the draft explicitly states what and how often you can use TLVs per signal. > - The document doesn't clearly delineate from informative/narrative > text, normative / required processing procedures, and message > formats. This by itself is not necessarily a major issue, it just > makes it harder to (write,) review and implement the protocol. > What is a major issue is that this approach allows for duplicate > (and sometimes contradictory) normative procedures and for > omissions in procedures (particularly related to exception/error > processing). Specific examples are included above and below. It > would be best to ensure that each required processing behavior is > defined just once and in a consistent way. > > - The security consideration section is inadequate. This section > should address the security of the DLEP protocol, not user > traffic. It should include an analysis of risks/threats/possible > exploits and how these are mitigated by the protocol. rfc6952, > and the protocols it references can serve as examples. DLEP is only on the local ethernet connection between the radio and the router... it is NOT spoken between different router/radio components of a network. RFC6952 is talking about securing communication over the routed network. > Minor Issues: > > - The data and signal type fields are both 8 bits. This seems > pretty small, particularly the data type field. Given this is a > control protocol, I think a larger (at least data type) field > would provide better "future proofing". So you would like to move BOTH the type and the length fields of the TLVs to 16 bit? > - 2^32 versions are currently allowed (section 8.1). This seems a > bit excessive. I'd opt for max of 8 bits here myself. Most likely 8 bits are enough, especially because I would expect the version number to become "fixed" after the RFC release. > - It's probably too late, but it probably would be cleaner to have a > generic ack signal rather than a per signal type ack. I mention > this here as this may come up again when clarifying the > transaction model (as mentioned above.) could be... but I am not sure about the advantage of moving the "ack type" into a TLV. > - Section 2: Assumptions > This section includes informative and normative text so is more > than just Assumptions. Personally, I'd remove all normative text > from the section. > > - There are no specific rules related to UDP header formation. UDP header formation? > - Sections 8.10->8.17. Isn't add/drop indicator needed for subnets > in destination update signals? I think we talked about this and the reason was that subnets are only as "fixed settings" supported. > - The IANA Considerations sections must follow RFC2360. > - New registries must include initial values, which are defined in > the document. (The document currently has many TBDs that should > be replaced.) I didn't know about this, I have always seen Drafts with TBDx... > - New registries need an allocation policy, e.g.: > The registry should be established with registration policies of > "Standards Action" (for Standards Track documents) and > =E2=80=9CSpecification Required" (for other documents). The designate= d > expert is any current WG chair. > > Nits: > > - The document introduces the terms "signals" and "data items" for > what is commonly called "messages" and "TLVs" (or objects) in > other protocols. It's probably too late to change this, but I > think the introduction of unique terminology is counter > productive. > > - Use of RFC 2119 conformance language is a bit rough, and there are > words in all caps that are not defined in RFC2119. Take a look at > http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuideline for some > suggestions. > > - Internal socket operation is mentioned a couple of times. It > really shouldn't be, the spec should define behavior on the wire. Not sure what you mean... > - The Length fields are missing unit of measure (presumably octets) Yes, octets. > - The Mnemonics are used basically once and don't really add value, > suggest dropping them. > > - How/when is the "Unknown Signal" Status Code sent? I would guess attached to a "Peer Termination" Signal... the other side sent us something we don't understand. > - Section 8.7: Extension List should be shown as a variable length > field. > > - Section 8.8: Experiment List should be shown as a variable length > field. You mean a "..." in the ascii art? Henning Rogge From nobody Thu Jun 18 06:02:22 2015 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 2E3091B3185; Thu, 18 Jun 2015 06:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 y2Xes89AdQdY; Thu, 18 Jun 2015 06:02:16 -0700 (PDT) Received: from uk-ext-viruswalls.astrium.eads.net (uk-ext-viruswalls.astrium.eads.net [194.62.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 343341B3186; Thu, 18 Jun 2015 06:02:16 -0700 (PDT) Received: from uk-ext-viruswalls.astrium.eads.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 36CE232553; Thu, 18 Jun 2015 14:02:14 +0100 (BST) Received: from auk52542.uk.astrium.corp (unknown [10.201.85.42]) by uk-ext-viruswalls.astrium.eads.net (Postfix) with ESMTP id 2590732551; Thu, 18 Jun 2015 14:02:14 +0100 (BST) Received: from E2K3-PTH-BRIDGEHEAD.UKN.UKNroot.astrium.corp ([10.221.1.31]) by auk52542.uk.astrium.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Jun 2015 14:02:13 +0100 Received: from AUK52982.UKN.UKNROOT.ASTRIUM.CORP ([fe80::543e:db1:48aa:1c6]) by AUK52840.UKN.UKNROOT.ASTRIUM.CORP ([fe80::7584:4b98:38c0:4ce7%15]) with mapi id 14.03.0123.003; Thu, 18 Jun 2015 14:02:13 +0100 From: "MATTY, Steven" To: 'Henning Rogge' , Lou Berger Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhqOLZ7x+mP20iQwyjGq8cNLJ2yMiMAgAAW8zA= Date: Thu, 18 Jun 2015 13:02:13 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> 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.221.1.73] X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-8.0.0.1202-21620.007 X-TM-AS-Result: No--10.119-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jun 2015 13:02:13.0865 (UTC) FILETIME=[FEE2F590:01D0A9C6] X-TM-AS-MML: disable X-imss-scan-details: No--10.119-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-8.0.1202-21620.007 X-TMASE-Result: 10--10.118800-5.000000 X-TMASE-MatchedRID: WMT2WRIkHPOI0KPyMNrNUuadXXcOleEbnqUxbQrzZwy9K1jOJyKSa4Rj b6q99slJa6wE+RtF2cS+gIsf5suMAjZmZl4JoxyNDPhWwJzVhb4mOHJ0aBcO1FB9cMQeUlyMjNE THH9N9TY+zlb3x6e7dBTcMjpPwLpOr4Tjl93LJlcER9Ta+6BEXXfdMkv/4CaG0JrBInoswFHYsk EA9AWxWm2haNW3Vghmpe8QQUgPMYm0F+hlS22zTEFRRoNra+1F5TbwqVVpF+PYWrp179pohhnFe UhjgGQW0aOj3KPSQjv6Y9+ki9MGOSCCuZ8QtFxJ84dsinZ5e1iRPtwwl97omyRwmEMDEuwZkhD5 9e4L9IAMmTMcJuDG7IMcwwzR1zFqlhmb2TDpRhSRfvUfL+585kqAhuLHn5fEOk+gxEw7tLKQVLW ueyFJmFYJIpN1DYJ5kZOl7WKIImrS77Co4bNJXW4djWaei+WE+gD2vYtOFhgqtq5d3cxkNb46et iJf39rGf4ZLor4YCGDehXQlPunHzA1+StOX8a2p5rFmb7o30A= Archived-At: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , MANET IETF , "manet-chairs@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 13:02:20 -0000 SGksDQoNCkFwb2xvZ2llcyBmb3IgaGlqYWNraW5nIHlvdXIgcmVwbHkgYSBsaXR0bGUgSGVubmlu ZywgYnV0IEkgdGhvdWdodCBJIGNvdWxkIGNoaW1lDQppbiBvbiBhIGNvdXBsZSBvZiBwb2ludHMg ZnJvbSBhIHJhZGlvIHZlbmRvciBwb2ludCBvZiB2aWV3IQ0KDQo+PiAgICAgLSBTZWN0aW9ucyA4 LjE5IGFuZCA4LjIwIGRlZmluZSAiUmVzb3VyY2VzIiByZWxhdGVkIERhdGEgSXRlbXMuICBUaGUN Cj4+ICAgICAgIGRlZmluaXRpb24gcmVsYXRlZCB0byB0aGVzZSBiYXNpY2FsbHkgc2F5cyBhIHJl c291cmNlcyBpcyAiQW4NCj4+ICAgICAgIDgtYml0IGludGVnZXIgcGVyY2VudGFnZSwgMC0xMDAs IHJlcHJlc2VudGluZyB0aGUgYW1vdW50IG9mDQo+PiAgICAgICByZXNvdXJjZXMgYWxsb2NhdGVk IHRvIHJlY2VpdmluZ3x0cmFuc21pdHRpbmcgZGF0YS4iLiAgSWYgSSB3ZXJlDQo+PiAgICAgICBp bXBsZW1lbnRpbmcgdGhpcyBwcm90b2NvbCwgSSdkIGhhdmUgbm8gaWRlYSBob3cgdG8gcHJvZHVj ZSwNCj4+ICAgICAgIHVwZGF0ZSBvciB1c2UgdGhpcyBpbmZvcm1hdGlvbi4gIEkgdGhpbmsgdGhl cmUgaXMgc29tZSBtaXNzaW5nDQo+PiAgICAgICBpbmZvcm1hdGl2ZSBhbmQgbm9ybWF0aXZlIChS RkMgMjExOSkgdGV4dCByZWxhdGVkIHRvIHRoZXNlDQo+PiAgICAgICBmb3JtYXRzLg0KPg0KPk15 IG9ubHkgaWRlYSBhYm91dCB0aGVtIHdvdWxkIGJlICJiYXR0ZXJ5IGxldmVsIi4uLiBub3Qgc3Vy ZSBob3cNCj51c2VmdWwgaXQgaXMgdG8gcXVlcnkgdGhlIHJhZGlvIGFib3V0IHRoaXMuDQoNCldo aWxzdCBhIGRlc3RpbmF0aW9uIHJvdXRlIG1heSBiZSB1cCBhbmQgY3VycmVudGx5IHRoZSBwcmVm ZXJyZWQgY2hvaWNlLA0KaWYgaXQncyByZXNvdXJjZXMgYXJlIGRlZ3JhZGluZyBvciBhcHByb2Fj aGluZyB6ZXJvLCB0aGUgcm91dGVyIG1heSBiZQ0KYWJsZSB0byBtYWtlIGFuIGluZm9ybWVkIGRl Y2lzaW9uIHRvIGZpbmQgYW4gYWx0ZXJuYXRlIHJvdXRlIGJlZm9yZSBzYWlkDQpyb3V0ZSBkaXNh cHBlYXJzLiBUaGlzIHdvdWxkIGJlIHByZWZlcmFibGUgdG8gd2FpdGluZyBmb3IgYSBoZWFydGJl YXQNCnRpbWVvdXQuDQoNCj4+ICAgICAtIFNlY3Rpb25zIDguMjEgYW5kIDguMjIgKFJlbGF0aXZl IExpbmsgUXVhbGl0eSkgaGF2ZSBhIHNpbWlsYXINCj4+ICAgICAgIHByb2JsZW0gb2YgYmVpbmcg dW5kZXIgZGVzY3JpYmVkLCBpbiBwYXJ0aWN1bGFyIGl0J3MgdW5jbGVhciBpZg0KPj4gICAgICAg dGhlcmUncyBhIG1lYW5pbmdmdWwsIG5vbi1wcm9wcmlldGFyeSBkZWZpbml0aW9uIGZvciBsaW5r IHF1YWxpdHkNCj4+ICAgICAgIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gaXMgdG8gYWN0IG9uIG9y IGlmIHRoZSBwYXNzZWQgdmFsdWUgaXMganVzdA0KPj4gICAgICAgcGFzc2VkIGZvciBhcyBtb25p dG9yaW5nIGluZm9ybWF0aW9uLiAgRWl0aGVyIHdheSwgdGhpcyBuZWVkcyB0bw0KPj4gICAgICAg YmUgY2xhcmlmaWVkLg0KPg0KPkl0IHNlZW1zIHRoZSByYWRpbyB2ZW5kb3JzIHJlYWxseSBsaWtl IHRoaXMgZmllbGQuIFRoZSByZWFzb24gd2h5IHdlDQo+bWFkZSAibWF4L2N1cnJlbnQgbGluayBz cGVlZCIgbWFuZGF0b3J5IGlzIHRvIG1ha2UgUkxRIGF0IGxlYXN0DQo+cmVhc29uYWJsZSB1c2Vm dWwuDQoNClllcyB3ZSBkbyA6KSBXaGlsc3QgYSBsaW5rIG1heSBiZSBzdXBwb3J0aW5nIGEgZ2l2 ZW4gZGF0YSByYXRlLCBpdA0KY291bGQgYmUgcnVubmluZyBhdCBvciBuZWFyIHRocmVzaG9sZC4g VG8gcHJldmVudCB1bm5lY2Vzc2FyeSBwYWNrZXQNCmxvc3MsIGVzcGVjaWFsbHkgaWYgdGhpcyBp cyBhIHRyYW5zaWVudCBzaXR1YXRpb24gaXQgbWF5IGJlIHByZWZlcmFibGUgZm9yDQp0aGUgcm91 dGVyIHRvIHNheSAibGV0J3MgY2hvb3NlIGEgbW9yZSBzdGFibGUgbGluayIuIFdlIG1pZ2h0LCBm b3IgaW5zdGFuY2UsDQpjaG9vc2UgcmVmbGVjdCBSeCBFYi9OMCAoYWRqdXN0ZWQgdG8gYSAwLTEw MCBmYWN0b3IpLiBBIHJhcGlkbHkgZGVncmFkaW5nDQpsb3NzIG9mIHF1YWxpdHkgY2FuIHRoZW4g YmUgcGlja2VkIHVwIHRoZSByb3V0ZXIgYW5kIGFnYWluIG1ha2UgYSBkZWNpc2lvbg0KYWJvdXQg aG93IGJlc3QgdG8gcm91dGUgdHJhZmZpYy4NCg0KUmVnYXJkcw0KDQpTdGV2ZQ0KDQpUaGlzIGVt YWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwN CmFuZC9vciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIG9yIGluZm9ybWF0aW9uIG90aGVyd2lzZSBw cm90ZWN0ZWQNCmZyb20gZGlzY2xvc3VyZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlDQpub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgZG8gbm90IGNv cHkgdGhpcyBtZXNzYWdlIG9yIGFueQ0KYXR0YWNobWVudHMgYW5kIGRvIG5vdCB1c2UgaXQgZm9y IGFueSBwdXJwb3NlIG9yIGRpc2Nsb3NlIGl0cw0KY29udGVudCB0byBhbnkgcGVyc29uLCBidXQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzDQpmcm9tIHlvdXIgc3lzdGVt LiBBaXJidXMgRGVmZW5jZSBhbmQgU3BhY2UgTGltaXRlZCBkaXNjbGFpbXMgYW55IGFuZCBhbGwg bGlhYmlsaXR5IGlmIHRoaXMgZW1haWwgdHJhbnNtaXNzaW9uIHdhcyB2aXJ1cyBjb3JydXB0ZWQs DQphbHRlcmVkIG9yIGZhbHNpZmllZC4NCi1vLQ0KQWlyYnVzIERlZmVuY2UgYW5kIFNwYWNlIExp bWl0ZWQsIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMgTm8uIDI0NDkyNTkNClJlZ2lz dGVyZWQgT2ZmaWNlOg0KR3VubmVscyBXb29kIFJvYWQsIFN0ZXZlbmFnZSwgSGVydGZvcmRzaGly ZSwgU0cxIDJBUywgRW5nbGFuZA== From nobody Thu Jun 18 06:10:36 2015 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 032D51B3191 for ; Thu, 18 Jun 2015 06:10:35 -0700 (PDT) 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 HhCtFYk14oGI for ; Thu, 18 Jun 2015 06:10:30 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45DC01B318B for ; Thu, 18 Jun 2015 06:10:30 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so60074401wic.1 for ; Thu, 18 Jun 2015 06:10:29 -0700 (PDT) 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=pMAizpatQaEgcsKarhvr6qcqqTDCcID9FrnKl+fZ9TU=; b=oTd9G/GvGrraqorYiy51uz8AyXfOzIsQQCAauY8F1R+5/Xoni12xTxE+094FmtlWHh R0INjB0D4XJ090C6LoH4/Nc2RwKhhbgtCtJEdk0gTT3nrch0hff+ahZGYZkSgRx+C6IK b65gAHZM4uZWQRAu43WCDeyduOwCjhCD4hKimjsKc9GvLVRPIgObTQBw/cgyEhm3Bvwc QrEUcnx/mtj0rj3LTo+abpvyv4uH2U7U/hO8EtvjMRamln7a6p9cx/ZQ7oDeo6QCu3z+ 7nJFi0XF/TICqiYJb5UO33idtgwzzTIrpt9boVlUN1nVUn5lJ23q1O2dzaD/ZnzaHXxq HsDQ== X-Received: by 10.194.250.98 with SMTP id zb2mr15902543wjc.90.1434633029022; Thu, 18 Jun 2015 06:10:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Thu, 18 Jun 2015 06:10:08 -0700 (PDT) In-Reply-To: References: <5575E8A7.6030508@labn.net> From: Henning Rogge Date: Thu, 18 Jun 2015 15:10:08 +0200 Message-ID: To: "MATTY, Steven" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: MANET IETF , Lou Berger Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 13:10:35 -0000 On Thu, Jun 18, 2015 at 3:02 PM, MATTY, Steven wrote: > Apologies for hijacking your reply a little Henning, but I thought I could chime > in on a couple of points from a radio vendor point of view! Good to get more input directly from Radio vendors! >>> - Sections 8.19 and 8.20 define "Resources" related Data Items. The >>> definition related to these basically says a resources is "An >>> 8-bit integer percentage, 0-100, representing the amount of >>> resources allocated to receiving|transmitting data.". If I were >>> implementing this protocol, I'd have no idea how to produce, >>> update or use this information. I think there is some missing >>> informative and normative (RFC 2119) text related to these >>> formats. >> >>My only idea about them would be "battery level"... not sure how >>useful it is to query the radio about this. > > Whilst a destination route may be up and currently the preferred choice, > if it's resources are degrading or approaching zero, the router may be > able to make an informed decision to find an alternate route before said > route disappears. This would be preferable to waiting for a heartbeat > timeout. Yes, that was my line of thought too... use the "battery level" to define the RLQ... then use the RLQ for the "MPR priority" (as an OLSRv2 example) or just to make links more expensive when battery becomes an issue. >>> - Sections 8.21 and 8.22 (Relative Link Quality) have a similar >>> problem of being under described, in particular it's unclear if >>> there's a meaningful, non-proprietary definition for link quality >>> that an implementation is to act on or if the passed value is just >>> passed for as monitoring information. Either way, this needs to >>> be clarified. >> >>It seems the radio vendors really like this field. The reason why we >>made "max/current link speed" mandatory is to make RLQ at least >>reasonable useful. > > Yes we do :) Whilst a link may be supporting a given data rate, it > could be running at or near threshold. To prevent unnecessary packet > loss, especially if this is a transient situation it may be preferable for > the router to say "let's choose a more stable link". We might, for instance, > choose reflect Rx Eb/N0 (adjusted to a 0-100 factor). A rapidly degrading > loss of quality can then be picked up the router and again make a decision > about how best to route traffic. My point was that without the "max/current datarate" the RLQ is very difficult to interpret, especially in heterogeneous networks. "Good that its a perfect link... but it doesn't mean you should go to youtube over it if its a 4 kbit/s VHF connection." ;) I see two extensions coming to DLEP in the future... one to deliver frame-level traffic statistics (sent/received bytes/frames, number of retransmittedn/lost frames, ect) and radio parameters (frequency, bandwidth, signal strength, channel busy/rx/tx time). Henning From nobody Thu Jun 18 11:40:29 2015 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 8FB381B3358 for ; Thu, 18 Jun 2015 11:40:28 -0700 (PDT) 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 oQQwvjc4OJRP for ; Thu, 18 Jun 2015 11:40:24 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 0DD5E1B3351 for ; Thu, 18 Jun 2015 11:40:24 -0700 (PDT) Received: by ykfr66 with SMTP id r66so73509188ykf.0 for ; Thu, 18 Jun 2015 11:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=5mV8+czFGPYP+rx7naG2VmbfB77gBClv4zLbXpz3HeY=; b=0DkG894m9l1OtTXjQ4koqKtn+ihvoOY5WxZd+OGHd+wufu2t4OLmenWnW/cGQJo70A Ug5DqVLxAUfeeyA3kjjon2ykKmfNdsnFUkMml6vL5hz7Gs15LDDWIve7lGBuj9lud5xj 2dlBkalf8DBZAbi7S/13Gvr2f58hjI/TfmZppQE3YrvXcOhcTck34ZcKCjDO5PIhVIcG QpkTnG1kveU1+QUmRz47ti7bbLT8FTueoUWymP8MnzRrMVrbO5j8J09ju5P0c2VxsTVf uQcIgAouG6uNhe3dZLgIHLiNulqYSW38V3xvtRbcx1f+P/+SDRrJH7v/1l8ZC72ouJT3 ZITA== X-Received: by 10.129.133.70 with SMTP id v67mr14333826ywf.158.1434652823069; Thu, 18 Jun 2015 11:40:23 -0700 (PDT) Received: from [10.30.20.18] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id v31sm3353298yha.15.2015.06.18.11.40.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jun 2015 11:40:22 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> Date: Thu, 18 Jun 2015 14:40:21 -0400 To: manet@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 18:40:28 -0000 % Document: draft-ietf-manet-dlep-14 % Reviewer: Lou Berger % Review Date: June 8 (later than requested due to scope of comments -- = sorry) % WG LC End Date: unknown % Intended Status: Standards track %=20 % Summary: % % While I think the document is pretty decent for the scope of the % work, I do have concerns about this document and recommend that the % WG Chairs/Routing ADs discuss these issues further with the authors. % I'm also available as/if needed to discuss. I broadly agree with Lou's review. A point-by-point commentary follows in-line. I think the document needs both clarifications (e.g. more text that is more crisply and clearly written) and also some modest protocol changes. % Comments: % % I think the document shows significant good work and looks to be a % useful protocol, although I'm not overly familiar in this space. % That said, I have a number of serious concerns about the document, % and its contents from a few of perspectives. These include basic % protocol issues, underspecified details (which could lead to % interoperability issues), and specification/editorial issues. I % think the document / protocol can be modified to address the issues % I raise below. Of course, it is up to the WG, chairs, and ADs to % decide which comments to address and which to ignore.=20 % I don't expect that all comments will result in changes. As context, I am a consultant and I work regularly with a well-known radio vendor that designs/sells IP-capable radios. % Major Issues: %=20 % - The length field of the generic data item (i.e., TLV) is only 8 % bits. While 255 bytes (assuming that this is the unit of measure, % which BTW isn't specified) is big enough today, allowing for % larger will greatly simplify things when 255 isn't enough. -- % We've run into this in RSVP and it's a real pain. Agreed. This field is clearly too small. I propose that it be changed to be a 16-bit field, which should be ample. =20 % - Version number is currently defined as a data item. This means a % signal (i.e., message) needs to be potentially fully parsed to % discover what version is being used. This precludes basic format % changes to the protocol. Perhaps the Discovery and Init Signals % should be special cased to include version in their formats. (And % shorten version to 8 bits from 32, as mentioned below). Agreed. This issue has been a problem in a few other IETF protocols. It is MUCH preferable from a protocol evolution perspective to have the version placed in a location where potential future protocol format changes are both possible=20 and practical. I also agree the field is WAY too large. The field should not be larger than 8-bits. In fact, I would be surprised if any IETF protocol needed more than 4-bits worth of version. % - The document references, but does not define, 'in-session' and % 'discovery' states. These either need to be formally defined or % removed. BTW we had exactly the same issue with LMP (RFC4204) and % ended up adding section 11 (FSMs) at a pretty late stage of the % process. Agreed. Undefined states are problematic in any protocol. They are likely to lead to interoperability issues that can be avoided either by more clear definition xor by elimination of these states. % - TCP session management is not defined, nor is the relationship % with TCP and DLEP sessions fully defined. For example: I agree. I view this as a specification clarity issue. % o Closing the TCP session is only mentioned in one place and in a % way that is inconsistent with the expected protocol behavior % (close TCP before ACK is received). IMHO, DLEP ought not be defining/describing a TCP session close=20 in a way that is inconsistent with normal TCP behavior. % o What happens when a DLEP session is terminated, can the TCP % session be reused or must it be closed too? IMHO, the DLEP specification should say that a NORMAL TCP close (i.e. not just sending an abrupt TCP RESET) occurs when a DLEP=20 session terminates. % - There is no transaction model defined. For example, it's % completely unclear if only one unacknowledged Signal allowed at a % time, or perhaps just one per signal type is allowed, or perhaps % there are no restrictions. This needs to be explicit. =20 Agreed. % - What is the purpose of retries and timeouts over TCP? Retries % aren't needed over TCPs and it's unclear whey they are being used. I agree with the question. % - The higher level implications of ACKs, over TCP, isn't really % clear. It seems ACKs are defined for multiple purposes: reliable % transport, transaction acknowledgment and transaction results. Of % course the first isn't needed, and implications of the others % should be clear. For example, in section 7.10, why would there be % a retry when receiving a Destination Up ACK signal indicating an % error? I agree with the question. I believe that a more crisp and clear text description is the minimum needed on this. % - There is no discussion on scaling considerations. Are there really % none? For example, how often might be appropriate to issue/limit % Peer Updates based to changes in link quality, or how to handle % the case where a large number (all or most) of destinations go % down. Some discussion seems needed. If the authors believe there really aren't any, perhaps they could add text with a description of why they aren't any. % - There are 13 places where the protocol allows implementation to % define their own 'heuristics'. Some of these seem unnecessary due % to the TCP point raised above, but any that remain in the protocol % should be fully specified to ensure predictable/consistent % behavior from implementations. I agree. We need interoperability. A clear and complete specification is the best way to achieve interoperability. % - Data Items are defined for "Extensions" and "Experimental % Definition" (Sections 8.7 and 8.8). Both seem to support for % optional mechanisms, but the former uses assigned numeric values, % why the latter uses UTF-8 strings. % o What, if any, is the intended distinction/relationship between % these? % o How does an "Experimental Definition" become standardized ? I don't see an obvious reason for the two kinds of data items to have different syntax (numeric values vs UTF-8 strings). As neas as I can tell, parsing would be simpler if a single form=20 (ideally numeric) were used. % - Sections 8.19 and 8.20 define "Resources" related Data Items. The % definition related to these basically says a resources is "An % 8-bit integer percentage, 0-100, representing the amount of % resources allocated to receiving|transmitting data.". If I were % implementing this protocol, I'd have no idea how to produce, % update or use this information. I think there is some missing % informative and normative (RFC 2119) text related to these % formats. I think I understand what this chunk of text means, and I think that I understand how different radios could calculate this in different ways (e.g. a pure software radio might be different than a silicon-based radio), but I also think that additional clarifying text would help with interoperability. Maybe we could add examples relating to memory or CPU or whatever. It seems to me that "if a device cannot calculate" these values, then that device MUST NOT (rather than SHOULD NOT) send this data item. Sending a data item containing an erroneous or misleading value does not seem helpful to either end of the DLEP session. % - Sections 8.21 and 8.22 (Relative Link Quality) have a similar % problem of being under described, in particular it's unclear if % there's a meaningful, non-proprietary definition for link quality % that an implementation is to act on or if the passed value is just % passed for as monitoring information. Either way, this needs to % be clarified. I think I understand what this chunk of text means, and I totally get that different radio types could calculate this in very different ways, but I also think that additional clarifying text (possibly adding examples) would help with interoperability. As above, I think that this data item "MUST NOT" be sent (rather than "SHOULD NOT") if the device is unable to calculate any link quality metric, because sending erroneous or misleading data does not seem helpful to either end of the DLEP session. % - Section 9 defines a "credit-windowing scheme analogous to the one % documented in [RFC5578]". It describes how credits are exchanged, % but it provides zero definition on the implications or use of % credits relative to the data plane. =20 I understand the value of having some flexibility, but I also agree that more description than exists now is needed for interoperability reasons. % - Multiple ways to implement the same function are allowed, e.g., % optional presence of Status, Interval and TCP port. Generally % allowing such complicates testing and leads to interoperability % issues. The document should pick one way and require it. Agree. Avoidable complexity or low ROI complexity seems undesirable. % - The document doesn't state if there are any ordering requirements % on data items. It should be explicit on this, e.g., there are no % ordering requirements on the placement of Data Items within % Signals. This needs to be specified either as "no ordering requirements" xor whatever the requirements are. My preference is to say explicitly "Data Items can be placed in any order within Signals." =20 % - The required and optional data items that are permitted on a % signal isn't always clear. For example are 0/1/N copies of a % particular Data Item required/allowed. Using something like ABNF % would really help formalize and clarify this. More clarity would help interoperability. % - The document doesn't clearly delineate from informative/narrative % text, normative / required processing procedures, and message % formats. This by itself is not necessarily a major issue, it just % makes it harder to (write,) review and implement the protocol. % What is a major issue is that this approach allows for duplicate % (and sometimes contradictory) normative procedures and for % omissions in procedures (particularly related to exception/error % processing). Specific examples are included above and below. It % would be best to ensure that each required processing behavior is % defined just once and in a consistent way. Agree. % - The security consideration section is inadequate. This section % should address the security of the DLEP protocol, not user % traffic. It should include an analysis of risks/threats/possible % exploits and how these are mitigated by the protocol. rfc6952, % and the protocols it references can serve as examples. TCP session hijacking is known to have been practical on the deployed Internet at least since 1995. CERT Advisories CA-1995-01, CA-1996-21, and CA-2001-09 are historical examples. There is also a practical DOS risk from an adversary sending a forged TCP Reset message. I suspect most of us envision that the router and the radio would be on a single VLAN or Ethernet collision domain, and that generally that wire might have some *assumed* trust associated with it. However, large Ethernet bridged LANs are now commonplace, including multi-site bridged LANs (e.g. to enable VM migration without IP readdressing).=20 So *some* kind of session authentication mechanism ought to be specified, so that we have some chance of interoperating in an authenticated way. My suggestion is that TCP-AO (RFC-5925) be specified as a mandatory to implement authentication method, but there are other IETF standards-track alternatives (e.g. IPsec AH or IPsec ESP). I imagine that most modern IP routers support TCP-AO already. Ideally we would like something that protects against forged TCP Reset messages, which means TLS is not a great choice. % Minor Issues: % % - The data and signal type fields are both 8 bits. This seems % pretty small, particularly the data type field. Given this is a % control protocol, I think a larger (at least data type) field % would provide better "future proofing". For me, this is a MAJOR issue. There are radios that will need to define radio-specific data items. In future, there likely will be a growing number of such data items, even if some of the experimental data items later are standardised. So each of these fields needs to be larger than 8-bits. I think 16-bits would be big enough. Trying to push all experimental extensions (or radio-unique extensions) into a single "Experimental Definition" followed by text strings makes parsing needlessly complex and doesn't really fit the engineering need to have radio-specific extensions to DLEP. Instead, we ought to specify that IANA allocates new Data Item type codes (numeric) for each experimental status data item. Also, the IANA Considerations should specify that experimental status Data Item values are allocated on a "First Come, First Serve" basis and should say that "RFC publication of the data item definition is encouraged, but is NOT required for experimental data item allocations." % - 2^32 versions are currently allowed (section 8.1). This % seems a bit excessive. I'd opt for max of 8 bits here myself. If an IETF protocol needs more than 4-bits for version, then IMHO something is very wrong. =20 I can live with an 8-bit field for alignment reasons, but we surely ought not need a 16-bit field for this. On a related note, I see no reason for having a minor version. NFS is the only IETF protocol that I can think of with both major and minor versions. NFS WG went to some effort to describe the difference between what would change the Major Version versus the Minor Version, which this does NOT do. Either (1) drop the Minor Version entirely or (2) document (a) the compelling reason to keep the Minor Version and (b) exactly when a change would alter the Minor Version and (c) exactly when a change would alter the Major Version. % - It's probably too late, but it probably would be cleaner to have a % generic ack signal rather than a per signal type ack. I mention % this here as this may come up again when clarifying the % transaction model (as mentioned above.) I could go either way on this, provided the conclusion were=20 very clear. % - Section 2: Assumptions % This section includes informative and normative text so is more % than just Assumptions. Personally, I'd remove all normative text % from the section. I very much doubt that J. Random implementer who is handed the DLEP document and told to code it up will expect guidance or normative language to be in a section marked "Assumptions". Perhaps keep the non-normative text inside "Assumptions", but place the guidance ("normative language") in a new section (possibly somewhere in Section 3) that is clearly=20 normative guidance. =20 % - There are no specific rules related to UDP header formation. % - Sections 8.10->8.17. Isn't add/drop indicator needed for subnets % in destination update signals? Good question. % - The IANA Considerations sections must = follow=E2=83=AB=E5=88=80=E4=98=80=E4=8C=80=E3=88=80=E3=8C=80=E3=98=80=E3=80= =80=E2=B8=80=E0=B4=80=E0=B4=80=E5=8C=80=E6=94=80=E6=94=80=E2=80=82=E6=84=80= =E6=88=80=E6=BC=80=E7=98=80=E6=94=80=E2=80=82=E6=98=80=E6=BC=80=E7=88=80=E2= =80=82=E6=BC=80=E7=90=80=E6=A0=80=E6=94=80=E7=88=80=E2=80=82=E6=90=80=E6=A4= =80=E7=8C=80=E6=8C=80=E7=94=80=E7=8C=80=E7=8C=80=E6=A4=80=E6=BC=80=E6=B8=80= =E2=80=82=E6=98=80=E7=88=80=E6=BC=80=E6=B4=80=E2=80=82=E6=B4=80=E6=94=80=E2= =80=82=E6=84=80=E6=88=80=E6=BC=80=E7=94=80=E7=90=80=E2=80=82=E4=A4=80=E4=84= =80=E4=B8=80=E4=84=80=E2=80=82=E4=8C=80=E6=BC=80=E6=B8=80=E7=8C=80=E6=A4=80= =E6=90=80=E6=94=80=E7=88=80=E6=84=80=E7=90=80=E6=A4=80=E6=BC=80=E6=B8=80=E7= =8C=80=E2=B8=80=E0=B4=80=E0=B4=80=E2=94=80=E2=80=82=E2=80=82=E2=B4=80=E2=80= =82=E4=B8=80=E6=94=80=E7=9C=80=E2=80=82=E7=88=80=E6=94=80=E6=9C=80=E6=A4=80= =E7=8C=80=E7=90=80=E7=88=80=E6=A4=80=E6=94=80=E7=8C=80=E2=80=82=E6=B4=80=E7= =94=80=E7=8C=80=E7=90=80=E2=80=82=E6=A4=80=E6=B8=80=E6=8C=80=E6=B0=80=E7=94= =80=E6=90=80=E6=94=80=E2=80=82=E6=A4=80=E6=B8=80=E6=A4=80=E7=90=80=E6=A4=80= =E6=84=80=E6=B0=80=E2=80=82=E7=98=80=E6=84=80=E6=B0=80=E7=94=80=E6=94=80=E7= =8C=80=E2=B0=80=E2=80=82=E7=9C=80=E6=A0=80=E6=A4=80=E6=8C=80=E6=A0=80=E2=80= =82=E6=84=80=E7=88=80=E6=94=80=E2=80=82=E6=90=80=E6=94=80=E6=98=80=E6=A4=80= =E6=B8=80=E6=94=80=E6=90=80=E2=80=82=E6=A4=80=E6=B8=80=E0=B4=80=E2=94=80=E2= =80=82=E2=80=82=E2=80=82=E2=80=82=E7=90=80=E6=A0=80=E6=94=80=E2=80=82=E6=90= =80=E6=BC=80=E6=8C=80=E7=94=80=E6=B4=80=E6=94=80=E6=B8=80=E7=90=80=E2=B8=80= =E2=80=82=E2=80=82=E2=A0=80=E5=90=80=E6=A0=80=E6=94=80=E2=80=82=E6=90=80=E6= =BC=80=E6=8C=80=E7=94=80=E6=B4=80=E6=94=80=E6=B8=80=E7=90=80=E2=80=82=E6=8C= =80=E7=94=80=E7=88=80=E7=88=80=E6=94=80=E6=B8=80=E7=90=80=E6=B0=80=E7=A4=80= =E2=80=82=E6=A0=80=E6=84=80=E7=8C=80=E2=80=82=E6=B4=80=E6=84=80=E6=B8=80=E7= =A4=80=E2=80=82=E5=90=80=E4=88=80=E4=90=80=E7=8C=80=E2=80=82=E7=90=80=E6=A0= =80=E6=84=80=E7=90=80=E2=80=82=E7=8C=80=E6=A0=80=E6=BC=80=E7=94=80=E6=B0=80= =E6=90=80=E0=B4=80=E2=94=80=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E6=88=80=E6= =94=80=E2=80=82=E7=88=80=E6=94=80=E7=80=80=E6=B0=80=E6=84=80=E6=8C=80=E6=94= =80=E6=90=80=E2=B8=80=E2=A4=80=E0=B4=80=E0=B4=80=E2=94=80=E2=80=82=E2=80=82= =E2=80=82=E2=B4=80=E2=80=82=E4=B8=80=E6=94=80=E7=9C=80=E2=80=82=E7=88=80=E6= =94=80=E6=9C=80=E6=A4=80=E7=8C=80=E7=90=80=E7=88=80=E6=A4=80=E6=94=80=E7=8C= =80=E2=80=82=E6=B8=80=E6=94=80=E6=94=80=E6=90=80=E2=80=82=E6=84=80=E6=B8=80= =E2=80=82=E6=84=80=E6=B0=80=E6=B0=80=E6=BC=80=E6=8C=80=E6=84=80=E7=90=80=E6= =A4=80=E6=BC=80=E6=B8=80=E2=80=82=E7=80=80=E6=BC=80=E6=B0=80=E6=A4=80=E6=8C= =80=E7=A4=80=E2=B0=80=E2=80=82=E6=94=80=E2=B8=80=E6=9C=80=E2=B8=80=E3=A8=80= =E0=B4=80=E2=94=80=E2=80=82=E2=80=82=E2=80=82=E5=90=80=E6=A0=80=E6=94=80=E2= =80=82=E7=88=80=E6=94=80=E6=9C=80=E6=A4=80=E7=8C=80=E7=90=80=E7=88=80=E7=A4= =80=E2=80=82=E7=8C=80=E6=A0=80=E6=BC=80=E7=94=80=E6=B0=80=E6=90=80=E2=80=82= =E6=88=80=E6=94=80=E2=80=82=E6=94=80=E7=8C=80=E7=90=80=E6=84=80=E6=88=80=E6= =B0=80=E6=A4=80=E7=8C=80=E6=A0=80=E6=94=80=E6=90=80=E2=80=82=E7=9C=80=E6=A4= =80=E7=90=80=E6=A0=80=E2=80=82=E7=88=80=E6=94=80=E6=9C=80=E6=A4=80=E7=8C=80= =E7=90=80=E7=88=80=E6=84=80=E7=90=80=E6=A4=80=E6=BC=80=E6=B8=80=E2=80=82=E7= =80=80=E6=BC=80=E6=B0=80=E6=A4=80=E6=8C=80=E6=A4=80=E6=94=80=E7=8C=80=E2=80= =82=E6=BC=80=E6=98=80=E0=B4=80=E2=94=80=E2=80=82=E2=80=82=E2=80=82=E2=88=80= =E5=8C=80=E7=90=80=E6=84=80=E6=B8=80=E6=90=80=E6=84=80=E7=88=80=E6=90=80=E7= =8C=80=E2=80=82=E4=84=80=E6=8C=80=E7=90=80=E6=A4=80=E6=BC=80=E6=B8=80=E2=88= =80=E2=80=82=E2=A0=80=E6=98=80=E6=BC=80=E7=88=80=E2=80=82=E5=8C=80=E7=90=80= =E6=84=80=E6=B8=80=E6=90=80=E6=84=80=E7=88=80=E6=90=80=E7=8C=80=E2=80=82=E5= =90=80=E7=88=80=E6=84=80=E6=8C=80=E6=AC=80=E2=80=82=E6=90=80=E6=BC=80=E6=8C= =80=E7=94=80=E6=B4=80=E6=94=80=E6=B8=80=E7=90=80=E7=8C=80=E2=A4=80=E2=80=82= =E6=84=80=E6=B8=80=E6=90=80=E0=B4=80=E2=94=80=E2=80=82=E2=80=82=E2=80=82=EF= =B0=80Specification Required" (for other documents). The designated % expert is any current WG chair. I disagree about "Specification Required" for experimental status Data Items that are defined. Those should be allocated by IANA on a "First Come, First Served" basis with "Specification Optional". % Nits: % % - The document introduces the terms "signals" and "data items" for % what is commonly called "messages" and "TLVs" (or objects) in % other protocols. It's probably too late to change this, but I % think the introduction of unique terminology is counter % productive. Agree. This makes the learning curve for DLEP steeper than it needs to be. % - Use of RFC 2119 conformance language is a bit rough, and there are % words in all caps that are not defined in RFC2119.=20 I agree this is an issue. I doubt the document will get past the IESG until this is fixed. Fixing it now ought to speed the rest of the IETF process. % - Internal socket operation is mentioned a couple of times. It % really shouldn't be, the spec should define behavior on the wire. Agree. % - The Length fields are missing unit of measure (presumably octets) Agree. We need to specify units of measure to ensure interoperability. % - The Mnemonics are used basically once and don't really add value, % suggest dropping them. No objection. % - How/when is the "Unknown Signal" Status Code sent? Clarifying text is needed for this. % - Section 8.7: Extension List should be shown as a variable length % field. % % - Section 8.8: Experiment List should be shown as a variable length % field. I think we ought to get away from having separate Extension List and Experiment List. In reality, both are extensions, some having experimental status. Right ? Please lets simplify the protocol in this area and make interoperability easier to achieve. Yours, Ran Atkinson From nobody Thu Jun 18 14:28:42 2015 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 254C21B3403; Thu, 18 Jun 2015 14:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334] 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 oC3VvOgDOQsF; Thu, 18 Jun 2015 14:28:35 -0700 (PDT) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB941B356D; Thu, 18 Jun 2015 14:28:35 -0700 (PDT) Received: from localhost ([::1]:47156) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Z5hMQ-00086t-UT; Fri, 19 Jun 2015 01:28:35 +0400 Message-ID: <558337FF.5040907@labn.net> Date: Thu, 18 Jun 2015 17:28:31 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Henning Rogge References: <5575E8A7.6030508@labn.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: manet-ads@ietf.org, "rtg-dir@ietf.org" , draft-ietf-manet-dlep.all@ietf.org, MANET IETF , manet-chairs@ietf.org Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 21:28:39 -0000 Henning, Thanks for the opinions. See below for in line response to those topics that have to do with the review and my intent -- I'm staying away from "WG/chair/AD" discussion topics. On 6/18/2015 8:38 AM, Henning Rogge wrote: > On Mon, Jun 8, 2015 at 9:10 PM, Lou Berger wrote: >> [Note this is a WG LC related review, not IETF LC.] >> >> Hello, > Hi... > > I am NOT one of the DLEP authors, but I have been active during the > design process (some people might say "annoyingly active"), so here > are my opinions on this review. Hopefully it will be helpful for the > authors. > >> ... >> Major Issues: >> >> - The length field of the generic data item (i.e., TLV) is only 8 >> bits. While 255 bytes (assuming that this is the unit of measure, >> which BTW isn't specified) is big enough today, allowing for >> larger will greatly simplify things when 255 isn't enough. -- >> We've run into this in RSVP and it's a real pain. > On the other side the largest data item we have at the moment is 18 > bytes (IPv6 connection point). I am not really seeing lots of > use-cases for large data items in DLEP. My experience in the past has been that unknown uses show up later and make this an issue that needs to be solved by some ugly semantic fragmentation, so if possible, I think it should be fixed. > Still, changing the TLV length to 16 bit would be trivial to do... but > would this mean we also should change the signal length field to 4 > bytes? I wasn't suggesting this and I don't think so. 2^16 is a pretty big message. >> - Version number is currently defined as a data item. This means a >> signal (i.e., message) needs to be potentially fully parsed to >> discover what version is being used. This precludes basic format >> changes to the protocol. Perhaps the Discovery and Init Signals >> should be special cased to include version in their formats. (And >> shorten version to 8 bits from 32, as mentioned below). > Putting it into the UDP based discovery packets as a "header" could > work... they are a bit special anyways (UDP) and we don't need to > repeat the version later. Lots of options here. But recall UDP discovery is optional per current spec. > >> - The document references, but does not define, 'in-session' and >> 'discovery' states. These either need to be formally defined or >> removed. BTW we had exactly the same issue with LMP (RFC4204) and >> ended up adding section 11 (FSMs) at a pretty late stage of the >> process. > I think "discovery phase" is before the TCP connection between radio > and router is established. Sure, but the point I was making there's a difference between unambiguously specifying something that can be independently implemented by someone not involved in the WG vs a common understanding in the WG based on discussion while the spec is developed. The challenge is ensuring the document (the former) adequately captures the latter. > >> - TCP session management is not defined, nor is the relationship >> with TCP and DLEP sessions fully defined. For example: >> >> o Closing the TCP session is only mentioned in one place and in a >> way that is inconsistent with the expected protocol behavior >> (close TCP before ACK is received). > Maybe this should be "closing the DLEP session and not using the > active TCP session anymore" ? > >> o What happens when a DLEP session is terminated, can the TCP >> session be reused or must it be closed too? > No, I think the DLEP strategy is "start from scratch"... when you > terminate a DLEP session you go back to the discovery mechanism to > start a new one. Whichever reasonable approach is taken it just needs to be explicitly documented. > >> - There is no transaction model defined. For example, it's >> completely unclear if only one unacknowledged Signal allowed at a >> time, or perhaps just one per signal type is allowed, or perhaps >> there are no restrictions. This needs to be explicit. > I think we don't need restrictions here because of TCP. The other side > WILL answer to eachof our signals or the TCP session will be > terminated. I don't think TCP helps (or hurts here). This is a question of what different implementations will choose to do / support WRT signals of the same or different types being processed in parallel. >> - What is the purpose of retries and timeouts over TCP? Retries >> aren't needed over TCPs and it's unclear whey they are being used. > We want to know when the connection between radio and router is > lost... this can take a LONG time when the router is mostly listening > to the Radio (TCP timeout is much to long for our use-case), so we use > the Heartbeats. This comment relates to the per signal acks and retries. I didn't include the connection failure detection covered by the heartbeat signal in this comment. >> - The higher level implications of ACKs, over TCP, isn't really >> clear. It seems ACKs are defined for multiple purposes: reliable >> transport, transaction acknowledgment and transaction results. Of >> course the first isn't needed, and implications of the others >> should be clear. For example, in section 7.10, why would there be >> a retry when receiving a Destination Up ACK signal indicating an >> error? > The DLEP "ACK Signals" are more a response to a "request signal"... > transaction acknowledgement and result. > >> - There is no discussion on scaling considerations. Are there really >> none? For example, how often might be appropriate to issue/limit >> Peer Updates based to changes in link quality, or how to handle >> the case where a large number (all or most) of destinations go >> down. > Just send as fast as you want and let TCP (buffer) take care of the > rest... both Destination up/down are small signals, so it shouldn't be > a problem. The assumptions behind this "shouldn't part of this" is what should be discussed... > And you are only allowed to send Destination Updates when > you received the Destination ACK. Where is this restriction specified? I don't recall seeing it. >> - There are 13 places where the protocol allows implementation to >> define their own 'heuristics'. Some of these seem unnecessary due >> to the TCP point raised above, but any that remain in the protocol >> should be fully specified to ensure predictable/consistent >> behavior from implementations. > No comment on this one. > >> - Data Items are defined for "Extensions" and "Experimental >> Definition" (Sections 8.7 and 8.8). Both seem to support for >> optional mechanisms, but the former uses assigned numeric values, >> why the latter uses UTF-8 strings. >> o What, if any, is the intended distinction/relationship between >> these? >> o How does an "Experimental Definition" become standardized? > As far as I understand this "Experimental Definition" is something you > use in the lab... you can have a maximum of one experiment for DLEP, Interesting -- where is this restriction defined? Section 7.3 says that "one or more" are allowed. > so this is more to make sure your special "work in progress" code does > not collide too hard with a standard radio/router. It's pretty unclear from the spec how experimental definitions are to be used -- or if they belong in standards track document at all. > On the other side you can support as many "Extensions" as you want... > and I expect this WG to standardize a few additional of them after > DLEP becomes a RFC. okay, look forward to seeing an IANA allocation policy for these. > >> - Sections 8.19 and 8.20 define "Resources" related Data Items. The >> definition related to these basically says a resources is "An >> 8-bit integer percentage, 0-100, representing the amount of >> resources allocated to receiving|transmitting data.". If I were >> implementing this protocol, I'd have no idea how to produce, >> update or use this information. I think there is some missing >> informative and normative (RFC 2119) text related to these >> formats. > My only idea about them would be "battery level"... not sure how > useful it is to query the radio about this. some context would be great. -- sounds like its akin to a routing metric. >> - Sections 8.21 and 8.22 (Relative Link Quality) have a similar >> problem of being under described, in particular it's unclear if >> there's a meaningful, non-proprietary definition for link quality >> that an implementation is to act on or if the passed value is just >> passed for as monitoring information. Either way, this needs to >> be clarified. > It seems the radio vendors really like this field. The reason why we > made "max/current link speed" mandatory is to make RLQ at least > reasonable useful. same comment. >> - Section 9 defines a "credit-windowing scheme analogous to the one >> documented in [RFC5578]". It describes how credits are exchanged, >> but it provides zero definition on the implications or use of >> credits relative to the data plane. >> > No comment on this one. > >> - Multiple ways to implement the same function are allowed, e.g., >> optional presence of Status, Interval and TCP port. Generally >> allowing such complicates testing and leads to interoperability >> issues. The document should pick one way and require it. > I think "no status TLV" is always "everything is fine"... > >> - The document doesn't state if there are any ordering requirements >> on data items. It should be explicit on this, e.g., there are no >> ordering requirements on the placement of Data Items within >> Signals. > I think is exactly as most (all?) of us have implemented it... no > ordering required. Cool, then this is just a simple matter of documenting "what everyone implements". >> - The required and optional data items that are permitted on a >> signal isn't always clear. For example are 0/1/N copies of a >> particular Data Item required/allowed. Using something like ABNF >> would really help formalize and clarify this. > Can you give an example where this is undefined? As far as I can see > the draft explicitly states what and how often you can use TLVs per > signal. I think the experimental data item discussion above is a perfect example. You though only one is allowed the spec is vague in section 8.8 and explicit in 7.3. -- Narrative lacks precision and is easily misread. Something like ABNF is far more transparent. >> - The document doesn't clearly delineate from informative/narrative >> text, normative / required processing procedures, and message >> formats. This by itself is not necessarily a major issue, it just >> makes it harder to (write,) review and implement the protocol. >> What is a major issue is that this approach allows for duplicate >> (and sometimes contradictory) normative procedures and for >> omissions in procedures (particularly related to exception/error >> processing). Specific examples are included above and below. It >> would be best to ensure that each required processing behavior is >> defined just once and in a consistent way. >> >> - The security consideration section is inadequate. This section >> should address the security of the DLEP protocol, not user >> traffic. It should include an analysis of risks/threats/possible >> exploits and how these are mitigated by the protocol. rfc6952, >> and the protocols it references can serve as examples. > DLEP is only on the local ethernet connection between the radio and > the router... it is NOT spoken between different router/radio > components of a network. RFC6952 is talking about securing > communication over the routed network. This is a scoping of the problem that should go into a security the section. RFC4204 covers a similar scoped protocol, although it's security considerations section is quite dated. > >> Minor Issues: >> >> - The data and signal type fields are both 8 bits. This seems >> pretty small, particularly the data type field. Given this is a >> control protocol, I think a larger (at least data type) field >> would provide better "future proofing". > So you would like to move BOTH the type and the length fields of the > TLVs to 16 bit? I'd probably enlarge data items and leave signal type alone. Alternatively you can plan to do something ugly down the road, like type 255 means look in value field for an extended type field - yuck. > >> - 2^32 versions are currently allowed (section 8.1). This seems a >> bit excessive. I'd opt for max of 8 bits here myself. > Most likely 8 bits are enough, especially because I would expect the > version number to become "fixed" after the RFC release. That would be great. >> - It's probably too late, but it probably would be cleaner to have a >> generic ack signal rather than a per signal type ack. I mention >> this here as this may come up again when clarifying the >> transaction model (as mentioned above.) > could be... but I am not sure about the advantage of moving the "ack > type" into a TLV. This would be a really major change at this juncture, as this is a "minor comment" I didn't really expect for it to be changed at this late date -- so no need to debate. >> - Section 2: Assumptions >> This section includes informative and normative text so is more >> than just Assumptions. Personally, I'd remove all normative text >> from the section. >> >> - There are no specific rules related to UDP header formation. > UDP header formation? format. I.e., what addresses and ports must be used. > >> - Sections 8.10->8.17. Isn't add/drop indicator needed for subnets >> in destination update signals? > I think we talked about this and the reason was that subnets are only > as "fixed settings" supported. I'm sorry I don't understand your response. Are you saying subnet reconfiguration requires a session reset? >> - The IANA Considerations sections must follow RFC2360. >> - New registries must include initial values, which are defined in >> the document. (The document currently has many TBDs that should >> be replaced.) > I didn't know about this, I have always seen Drafts with TBDx... TBD is right for existing registries. For new registries IANA doesn't have any policies or guidance. This comes from the document that establish the registries, i.e, this one. > >> - New registries need an allocation policy, e.g.: >> The registry should be established with registration policies of >> "Standards Action" (for Standards Track documents) and >> “Specification Required" (for other documents). The designated >> expert is any current WG chair. >> >> Nits: >> >> - The document introduces the terms "signals" and "data items" for >> what is commonly called "messages" and "TLVs" (or objects) in >> other protocols. It's probably too late to change this, but I >> think the introduction of unique terminology is counter >> productive. >> >> - Use of RFC 2119 conformance language is a bit rough, and there are >> words in all caps that are not defined in RFC2119. Take a look at >> http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuideline for some >> suggestions. >> >> - Internal socket operation is mentioned a couple of times. It >> really shouldn't be, the spec should define behavior on the wire. > Not sure what you mean... This is a specification of behavior "on the wire" . It should be possible to implement in an OS that doesn't implement sockets but properly conforms to the spec. >> - The Length fields are missing unit of measure (presumably octets) > Yes, octets. > >> - The Mnemonics are used basically once and don't really add value, >> suggest dropping them. >> >> - How/when is the "Unknown Signal" Status Code sent? > I would guess attached to a "Peer Termination" Signal... the other > side sent us something we don't understand. > >> - Section 8.7: Extension List should be shown as a variable length >> field. >> >> - Section 8.8: Experiment List should be shown as a variable length >> field. > You mean a "..." in the ascii art? yes. > Henning Rogge > Thanks! Lou From nobody Fri Jun 19 07:23:17 2015 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 E23561A039A for ; Fri, 19 Jun 2015 07:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 WxxF287TiWe4 for ; Fri, 19 Jun 2015 07:23:12 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 879C61A038B for ; Fri, 19 Jun 2015 07:23:12 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5JEN9A1007968; Fri, 19 Jun 2015 10:23:10 -0400 From: "Wiggins, David - 0665 - MITLL" To: RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6q4BISdYAIk+JbR87kxTblJ2z4wAA Date: Fri, 19 Jun 2015 14:23:09 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> In-Reply-To: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3517554188_36577753" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-19_04:2015-06-18,2015-06-19,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-1506190245 Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 14:23:16 -0000 --B_3517554188_36577753 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, Here are a few comments on topics that resonated with me, piggybacked on excerpts of Ran's reply because it was so similar to my thoughts. For context, I am the main developer working on our DLEP implementation. I'm a relative newcomer to DLEP (this year), so I have fresh eyes :) On 6/18/15, 2:40 PM, "RJ Atkinson" wrote: >% - Version number is currently defined as a data item. This means a >% signal (i.e., message) needs to be potentially fully parsed to >% discover what version is being used. This precludes basic format >% changes to the protocol. Perhaps the Discovery and Init Signals >% should be special cased to include version in their formats. (And >% shorten version to 8 bits from 32, as mentioned below). > >Agreed. This issue has been a problem in a few other IETF >protocols. It is MUCH preferable from a protocol evolution >perspective to have the version placed in a location where >potential future protocol format changes are both possible >and practical. Good point. It should be a fixed field in header of the Peer Discovery and Peer Offer signals, and since discovery is optional, it should also be in the Peer Initialization and Peer Initialization Ack signals. Perhaps it would be simpler to just put it in the header for all signals. > >I also agree the field is WAY too large. The field should not >be larger than 8-bits. In fact, I would be surprised if any >IETF protocol needed more than 4-bits worth of version. I have seen 16 bit version numbers work in other (non-IETF) protocols, with one byte each for the major and minor versions. As Ran points out later, this would require careful definition of what it means when each one changes, and that may not be worth the effort. I don't feel strongly about this. The interaction between version number changes and the extension mechanism(s) needs thought too. > >% - The document references, but does not define, 'in-session' and >% 'discovery' states. These either need to be formally defined or >% removed. BTW we had exactly the same issue with LMP (RFC4204) and >% ended up adding section 11 (FSMs) at a pretty late stage of the >% process. > >Agreed. Undefined states are problematic in any protocol. >They are likely to lead to interoperability issues that >can be avoided either by more clear definition xor by >elimination of these states. If it's of any use, we ended up defining our own states for our implementation: - Connected: the TCP connection is established between the peers, but the Init handshake hasn't completed. - In Session: the Peer Init/Ack exchange is complete, and other signals can now be sent. - Terminating: a Termination signal has been sent to the peer, and we are waiting for the Ack. We didn't use the "discovery" state because our states are attached to peers, and during discovery there is no peer. >% - There are 13 places where the protocol allows implementation to >% define their own 'heuristics'. Some of these seem unnecessary due >% to the TCP point raised above, but any that remain in the protocol >% should be fully specified to ensure predictable/consistent >% behavior from implementations. > >I agree. We need interoperability. A clear and complete >specification is the best way to achieve interoperability. Agree. We have implemented 'heuristics', and while I think they should work with other implementations, I'm not sure. I would be more comfortable if the behavior was more completely specified. > >% - Data Items are defined for "Extensions" and "Experimental >% Definition" (Sections 8.7 and 8.8). Both seem to support for >% optional mechanisms, but the former uses assigned numeric values, >% why the latter uses UTF-8 strings. >% o What, if any, is the intended distinction/relationship between >% these? >% o How does an "Experimental Definition" become standardized ? > >I don't see an obvious reason for the two kinds of data items >to have different syntax (numeric values vs UTF-8 strings). >As neas as I can tell, parsing would be simpler if a single form >(ideally numeric) were used. I've been puzzled about the two very similar extension mechanisms, but I figured it had all been hashed out before I started with DLEP. Now that others are raising the issue though, I'll say that I do think it would be good to combine them. I'm concerned about how to mesh the two different mechanisms in the implementation. A possible way to combine them would be to have a 16 bit extension number, with half of the space reserved for standardized extensions and half for experimental/non-standard ones. Perhaps IANA could even assign the experimental ones on a first-come-first-serve, no spec required basis to help with interoperability. >% - Section 9 defines a "credit-windowing scheme analogous to the one >% documented in [RFC5578]". It describes how credits are exchanged, >% but it provides zero definition on the implications or use of >% credits relative to the data plane. > >I understand the value of having some flexibility, but I also >agree that more description than exists now is needed for >interoperability reasons. Agree. The credit scheme will be important to us. > >Yours, > >Ran Atkinson David Wiggins MIT Lincoln Laboratory > --B_3517554188_36577753 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFKPgOmavI2eKcG3O xkNQ+gWr668yMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYxOTE0MjMwOFowDQYJKoZIhvcNAQEBBQAEggEAWB6gS4vxaPdEkFBUaqrICUgqD/6In8pI LVV0akRFB9c/OneNBLZepvk47Y0NOGfrVmwWexivly3vcGpqADrLjm+s4bIJsOSGNWuuHGm6 XVTwqxVKwY4dUJLXx16SZyWuMDy+Jhsr1jtIcv5InNgiP7kN02wRWzeo9YePbV6fDr0FGCeR gLC7xbEqM8G5bS+kSOJyRVi0JRoSpyQPaj/t1bGXyMlwk+jOLuEkxvKmSHYJPjmeRStsxS/A 23GzVUgWaYFfCh6m/0YVOs3cVP+4BsE41ALR4cZ3Zspf8XbQJMq2TiCSBZvouy/wohVdIB7k 7/C8PEjQWmUR+jQMNxq16w== --B_3517554188_36577753-- From nobody Fri Jun 19 09:09:33 2015 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 B83741A9233 for ; Fri, 19 Jun 2015 09:09:32 -0700 (PDT) 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 jPgQ4yEuhMp6 for ; Fri, 19 Jun 2015 09:09:31 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id D5F661A9155 for ; Fri, 19 Jun 2015 09:09:30 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.203 as permitted sender) identity=mailfrom; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,644,1427774400"; d="scan'208";a="17707319" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.203]) by ironport.idirect.net with ESMTP; 19 Jun 2015 12:09:30 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM3.idirect.net (10.250.250.203) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 19 Jun 2015 12:09:29 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Fri, 19 Jun 2015 12:09:29 -0400 From: "Ratliff, Stanley" To: "Wiggins, David - 0665 - MITLL" , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6Mo+Tw3COyECGObxkTDTDb520JhCA///Qh1A= Date: Fri, 19 Jun 2015 16:09:28 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 16:09:32 -0000 OK, since the debate seems to be brewing over "Extensions" and "Experimenta= l Definitions", I figured I'd jump in and try to explain. = > > > >% - Data Items are defined for "Extensions" and "Experimental > >% Definition" (Sections 8.7 and 8.8). Both seem to support for > >% optional mechanisms, but the former uses assigned numeric values, > >% why the latter uses UTF-8 strings. > >% o What, if any, is the intended distinction/relationship between > >% these? > >% o How does an "Experimental Definition" become standardized ? > > > >I don't see an obvious reason for the two kinds of data items to have > >different syntax (numeric values vs UTF-8 strings). > >As neas as I can tell, parsing would be simpler if a single form > >(ideally numeric) were used. > = > I've been puzzled about the two very similar extension mechanisms, but I > figured it had all been hashed out before I started with DLEP. Now that > others are raising the issue though, I'll say that I do think it would be= good to > combine them. I'm concerned about how to mesh the two different > mechanisms in the implementation. A possible way to combine them would > be to have a 16 bit extension number, with half of the space reserved for > standardized extensions and half for experimental/non-standard ones. > Perhaps IANA could even assign the experimental ones on a first-come-firs= t- > serve, no spec required basis to help with interoperability. > = So, let's start with a scenario - assume that DLEP is now RFC-blah-de-blah,= and I have an interoperable version deployed. The sun is rising in the Eas= t, the crops are bountiful, and I've *finally* lost that pesky 30lbs (OK, m= ore like 40) that my doctor keeps needling me about. And then... I get this= great idea, having to do with DLEP. With a small handful of data items, an= d a correspondingly small number of signals, I can put an "It-will-even-mak= e-coffee-for-you-in-the-morning" feature in my modem. But, DLEP is this fix= ed, interoperable protocol. So what to do, what to do? With the -14 draft, I can implement this, *initially*, as an "Experiment". = I conjure up the necessary signals ("DLEP_COFFEEMAKER_START", "DLEP_COFFEEM= AKER_STOP"), and also the requisite data items ("DLEP_COLUMBIAN")... actual= ly, I'd probably add "DLEP_SUMATRAN", since this is a "high-end" modem, but= that's another story... I also map out how these signals/data items look (e.g., is the DLEP_COLUMBI= AN data item 8 bits, 16 bits, or just 1?), and then I start looking for a r= outer vendor to "play nice with me", and support my coffee maker experiment= . Assuming I find such a router vendor, we implement the "Coffee Maker Expe= riment" - and again, since this is *my* scenario, we'll assume that's its w= ildly successful. All of my beta test sites are "Slurping coffee on the mov= e", and enjoying it. In fact, it's so wildly popular that other modem manuf= acturers are now discussing bolting coffee makers onto their modems... So, at this point, it's time for me and my router-vendor partner to approac= h the MANET WG with a draft describing the Coffee-Maker "Experiment" as a D= LEP "Extension". And true to form, the WG debates the weighty issues (e.g.,= Should there be a DLEP_ARABICA data item? NO! YES! Wait! We should allow i= t to MAKE TEA! Yes, that's the ticket! It MUST [proper homage to RFC 2119] = contain a DLEP_EARL_GREY data item!), ad-nauseum, over a period of time tha= t you thought would take a couple of IETF meetings, but actually spans abou= t 5 years (in other words, you *thought* it was going to be a project, but = it turned into a career path)... Finally, clearing Working Group Last Call (and *then* getting a crap-ton of= really useful comments, because apparently, no one reads these things unle= ss/until there's supposedly no chance to change them), you get the official= , approved, "DLEP Coffee Maker Extension" registered with IANA... I and my = router-vendor partner (actually, my grandchild and my router-vendor partner= 's grandchild, since it's taken so long) can then swap over our code to sto= p using the "Experiment", and use the official "Extension" data items and s= ignals. But my point here is, that all the while, my customers have been merrily "s= lupring coffee on the move, and enjoying it" - utilizing the "Experimental"= TLVs gives me (us, actually) the ability to actually be *responsive* to ou= r customers, testing out (and even deploying in limited fashion) changes to= the protocol. If/when those "experiments" prove successful, the mechanism = even gives implementers the ability to shift the code from "Experiment" to = "Extension", providing backward-level compatibility for the move (nothing s= tops me from supporting the exact same functionality in "Experimental" mode= that I'm supporting with a now-documented "Extension"). = ...and that was the motivation behind having both "Experimental" TLVs, and = a documented "Extension" mechanism... = Regards, Stan _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Fri Jun 19 09:18:16 2015 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 D34201A92DD for ; Fri, 19 Jun 2015 09:18:14 -0700 (PDT) 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 Rk2H_vgWBHUA for ; Fri, 19 Jun 2015 09:18:13 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF8F1A9233 for ; Fri, 19 Jun 2015 09:18:13 -0700 (PDT) Received: by wguu7 with SMTP id u7so21498279wgu.3 for ; Fri, 19 Jun 2015 09:18:12 -0700 (PDT) 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=9WFQq5x8ChxaW3LpNuCZGJPSmIceK7mQDkfsZxjP0PY=; b=e4D6h/hzhJcoaROxcKI9ywutGQVa20kPHqmhgvP5AN13gkU0NrD3YGy9YoojSTFwOx DQOoh+tTt3Hflu4HkizpjFYhngG+qmkf8moa8pK3aziK/9jgGSpyzibMKitn3EhooiQ4 jbjyA+0Pqk6o9cBl1z66ik9f4hZ/z637d2TU/QqfZdLB0DI++MMal87bafszlWRsQumG kSkpa3PjrlJDCAWZJU5QyBHrI7hFJUhJldkmR2crPydu6AEz6lo3tpzDK4Aqy/l7odbP 45BVnhCSxMow1xT4nhcGepUM0oKeDVNrqr2PX7Sh20pOOPt/1QtDz71ydJxznbx322Qc 9lFA== X-Received: by 10.180.94.35 with SMTP id cz3mr8176029wib.85.1434730692227; Fri, 19 Jun 2015 09:18:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Fri, 19 Jun 2015 09:17:51 -0700 (PDT) In-Reply-To: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> From: Henning Rogge Date: Fri, 19 Jun 2015 18:17:51 +0200 Message-ID: To: "Ratliff, Stanley" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "manet@ietf.org" , RJ Atkinson Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 16:18:15 -0000 On Fri, Jun 19, 2015 at 6:09 PM, Ratliff, Stanley wrote: > ...and that was the motivation behind having both "Experimental" TLVs, and a documented "Extension" mechanism... The "text identifier" of the Experiments make it also much easier to have multiple experiments in house and even do small tests with other software without worrying about which "experimental number" to take from the Extension so that you don't have collisions. Henning From nobody Fri Jun 19 10:16:50 2015 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 E4F9A1ACD4C for ; Fri, 19 Jun 2015 10:16:48 -0700 (PDT) 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 IZD4mjtOHxbz for ; Fri, 19 Jun 2015 10:16:45 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA131ACD4B for ; Fri, 19 Jun 2015 10:16:44 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5JHGgMl017717; Fri, 19 Jun 2015 13:16:42 -0400 From: "Wiggins, David - 0665 - MITLL" To: "Ratliff, Stanley" , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6q4BISdYAIk+JbR87kxTblJ2z4wAAgABgxAD//8+4AA== Date: Fri, 19 Jun 2015 17:16:41 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3517564600_37216744" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-19_05:2015-06-18,2015-06-19,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-1506190295 Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 17:16:49 -0000 --B_3517564600_37216744 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Stan, Thanks for the clarifications. And the humor is appreciated. If I go through your story, and everywhere it mentions "experiment" I replace it with "experimental extension" using this notion: a 16 bit extension number, with half of the space reserved for standardized extensions and half for experimental/non-standard ones. Perhaps IANA could even assign the experimental ones on a first-come-first- serve, no spec required basis to help with interoperability. ...then I think the story still works. If I'm wrong, I've missed something. The advantage is that now you just have one extension mechanism instead of two. No more questions about how the two mechanisms relate to/interact with one another (and no new words needed to describe such interactions), since there's only one now. No need to implement two sets of extension-handling code. Seems like a win. David On 6/19/15, 12:09 PM, "Ratliff, Stanley" wrote: >OK, since the debate seems to be brewing over "Extensions" and >"Experimental Definitions", I figured I'd jump in and try to explain. > >> > >> >% - Data Items are defined for "Extensions" and "Experimental >> >% Definition" (Sections 8.7 and 8.8). Both seem to support for >> >% optional mechanisms, but the former uses assigned numeric values, >> >% why the latter uses UTF-8 strings. >> >% o What, if any, is the intended distinction/relationship between >> >% these? >> >% o How does an "Experimental Definition" become standardized ? >> > >> >I don't see an obvious reason for the two kinds of data items to have >> >different syntax (numeric values vs UTF-8 strings). >> >As neas as I can tell, parsing would be simpler if a single form >> >(ideally numeric) were used. >> >> I've been puzzled about the two very similar extension mechanisms, but I >> figured it had all been hashed out before I started with DLEP. Now that >> others are raising the issue though, I'll say that I do think it would >>be good to >> combine them. I'm concerned about how to mesh the two different >> mechanisms in the implementation. A possible way to combine them would >> be to have a 16 bit extension number, with half of the space reserved >>for >> standardized extensions and half for experimental/non-standard ones. >> Perhaps IANA could even assign the experimental ones on a >>first-come-first- >> serve, no spec required basis to help with interoperability. >> > >So, let's start with a scenario - assume that DLEP is now >RFC-blah-de-blah, and I have an interoperable version deployed. The sun >is rising in the East, the crops are bountiful, and I've *finally* lost >that pesky 30lbs (OK, more like 40) that my doctor keeps needling me >about. And then... I get this great idea, having to do with DLEP. With a >small handful of data items, and a correspondingly small number of >signals, I can put an "It-will-even-make-coffee-for-you-in-the-morning" >feature in my modem. But, DLEP is this fixed, interoperable protocol. So >what to do, what to do? > >With the -14 draft, I can implement this, *initially*, as an >"Experiment". I conjure up the necessary signals >("DLEP_COFFEEMAKER_START", "DLEP_COFFEEMAKER_STOP"), and also the >requisite data items ("DLEP_COLUMBIAN")... actually, I'd probably add >"DLEP_SUMATRAN", since this is a "high-end" modem, but that's another >story... >I also map out how these signals/data items look (e.g., is the >DLEP_COLUMBIAN data item 8 bits, 16 bits, or just 1?), and then I start >looking for a router vendor to "play nice with me", and support my coffee >maker experiment. Assuming I find such a router vendor, we implement the >"Coffee Maker Experiment" - and again, since this is *my* scenario, we'll >assume that's its wildly successful. All of my beta test sites are >"Slurping coffee on the move", and enjoying it. In fact, it's so wildly >popular that other modem manufacturers are now discussing bolting coffee >makers onto their modems... > >So, at this point, it's time for me and my router-vendor partner to >approach the MANET WG with a draft describing the Coffee-Maker >"Experiment" as a DLEP "Extension". And true to form, the WG debates the >weighty issues (e.g., Should there be a DLEP_ARABICA data item? NO! YES! >Wait! We should allow it to MAKE TEA! Yes, that's the ticket! It MUST >[proper homage to RFC 2119] contain a DLEP_EARL_GREY data item!), >ad-nauseum, over a period of time that you thought would take a couple of >IETF meetings, but actually spans about 5 years (in other words, you >*thought* it was going to be a project, but it turned into a career >path)... > >Finally, clearing Working Group Last Call (and *then* getting a crap-ton >of really useful comments, because apparently, no one reads these things >unless/until there's supposedly no chance to change them), you get the >official, approved, "DLEP Coffee Maker Extension" registered with IANA... >I and my router-vendor partner (actually, my grandchild and my >router-vendor partner's grandchild, since it's taken so long) can then >swap over our code to stop using the "Experiment", and use the official >"Extension" data items and signals. > >But my point here is, that all the while, my customers have been merrily >"slupring coffee on the move, and enjoying it" - utilizing the >"Experimental" TLVs gives me (us, actually) the ability to actually be >*responsive* to our customers, testing out (and even deploying in limited >fashion) changes to the protocol. If/when those "experiments" prove >successful, the mechanism even gives implementers the ability to shift >the code from "Experiment" to "Extension", providing backward-level >compatibility for the move (nothing stops me from supporting the exact >same functionality in "Experimental" mode that I'm supporting with a >now-documented "Extension"). > >...and that was the motivation behind having both "Experimental" TLVs, >and a documented "Extension" mechanism... > >Regards, >Stan > > >_____________________________________________________ >This electronic message and any files transmitted with it contains >information from iDirect, which may be privileged, proprietary >and/or confidential. It is intended solely for the use of the individual >or entity to whom they are addressed. If you are not the original >recipient or the person responsible for delivering the email to the >intended recipient, be advised that you have received this email >in error, and that any use, dissemination, forwarding, printing, or >copying of this email is strictly prohibited. If you received this email >in error, please delete it and immediately notify the sender. >_____________________________________________________ > --B_3517564600_37216744 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFAm21b2BcwzB+huo ZvnIx3nyMfvZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYxOTE3MTY0MFowDQYJKoZIhvcNAQEBBQAEggEAtW4PxnPh/o16Lq1gRa5vXKkVd6ytW7ra AcgdXSk3YtV4QWK1Aws6JrqH8uFPggNaDpdSOXwOfbSoXuFJgzvGRCFzDtYc9ska8b2LiLVK FhK2ASLv7KmCa5JxDshCABlB3rR4Vln9mzk6sEN4Q/DGT3VcpxahG02qVbJoDkwt0/stNqx9 Tyvve/bf+I8MIqzbn+mbhzDeMjWYyBuOEUeF/1nS3YksPNx1clfWuiFtqp9In+RCKf5t06hc WNCchBco/CuMGYWNEk2mtyppxpZHFOISc9U2Z9S2b1ruldGaSEDXpUc05v5VDDZMcM6PmhhX EeZhmL4Idi2cyrZYWcXo6A== --B_3517564600_37216744-- From nobody Fri Jun 19 10:50:52 2015 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 462411ACDE4 for ; Fri, 19 Jun 2015 10:50:50 -0700 (PDT) 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 WaJCiaf3Phlw for ; Fri, 19 Jun 2015 10:50:49 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 018FA1ACDE2 for ; Fri, 19 Jun 2015 10:50:47 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.201; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.201 as permitted sender) identity=mailfrom; client-ip=10.250.250.201; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.201; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,644,1427774400"; d="scan'208";a="17708025" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.201]) by ironport.idirect.net with ESMTP; 19 Jun 2015 13:50:46 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM1.idirect.net (10.250.250.201) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 19 Jun 2015 13:50:45 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Fri, 19 Jun 2015 13:50:45 -0400 From: "Ratliff, Stanley" To: "Wiggins, David - 0665 - MITLL" , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6Mo+Tw3COyECGObxkTDTDb520JhCA///Qh1CAAF/1gP//w+5g Date: Fri, 19 Jun 2015 17:50:45 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 17:50:50 -0000 David, > If I go through your story, and everywhere it mentions "experiment" I > replace it with "experimental extension" using this notion: > = > a 16 bit extension number, with half of the space reserved for > standardized extensions and half for experimental/non-standard ones. > Perhaps IANA could even assign the experimental ones on a > first-come-first- > serve, no spec required basis to help with interoperability. > = As it has been explained to me, that notion collides with IANA/IESG in at l= east a couple of not-so-nice ways: = 1. Creating a "standards-track protocol" with 32,767 experiments, and anoth= er 32,767 extensions, isn't much of a standard - everything's pretty much a= n experiment or an extension. = 2. I don't believe IANA operates that way. They need a WG-approved document= in order to start the assignment process. = So, we intentionally created a small (3? 4?) "Wild-wild-West sandbox" (the = experiments), and the more formal Extensions mechanism, which by necessity,= starts with an IETF draft. = Regards, Stan [snip] _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Fri Jun 19 12:51:53 2015 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 13E571AD376 for ; Fri, 19 Jun 2015 12:51:52 -0700 (PDT) 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 qk31GXa3etrp for ; Fri, 19 Jun 2015 12:51:50 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE531AD370 for ; Fri, 19 Jun 2015 12:51:49 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5JJpmuq000760; Fri, 19 Jun 2015 15:51:48 -0400 From: "Wiggins, David - 0665 - MITLL" To: "Ratliff, Stanley" , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6q4BISdYAIk+JbR87kxTblJ2z4wAAgABgxAD//8+4AIAATJSA///ew4A= Date: Fri, 19 Jun 2015 19:51:47 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3517573907_37795961" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-19_06:2015-06-18,2015-06-19,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-1506190340 Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 19:51:52 -0000 --B_3517573907_37795961 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 6/19/15, 1:50 PM, "Ratliff, Stanley" wrote: >David, > >> If I go through your story, and everywhere it mentions "experiment" I >> replace it with "experimental extension" using this notion: >> >> a 16 bit extension number, with half of the space reserved for >> standardized extensions and half for experimental/non-standard ones. >> Perhaps IANA could even assign the experimental ones on a >> first-come-first- >> serve, no spec required basis to help with interoperability. >> > >As it has been explained to me, that notion collides with IANA/IESG in at >least a couple of not-so-nice ways: >1. Creating a "standards-track protocol" with 32,767 experiments, and >another 32,767 extensions, isn't much of a standard - everything's pretty >much an experiment or an extension. The core protocol as defined in the draft/RFC isn't an extension or an experiment, and that's what is being standardized, at least initially. I'm not sure why IANA/IESG would have an issue with the number of extensions or experiments allowed. > >2. I don't believe IANA operates that way. They need a WG-approved >document in order to start the assignment process. OK. I was under the impression that there could be different rules for experimental extensions in other cases, and they could do a lightweight assignment, but I am no authority here. Maybe someone who knows can chime in. David --B_3517573907_37795961 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFKUG8Sj/4YqQFuTc vVdiKmOFdsWXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYxOTE5NTE0N1owDQYJKoZIhvcNAQEBBQAEggEAOfZqBU5kNPllVF2qs54I8MAYO2Y1zN4h Pqdj563p6XW+3xP5aobcqz0BkAJnIR4BYD1YJV10ez73ASU+5E5OYpgCbfXVVzo+8/icXPwp lPIPxs8Mu0hw7GRGe6A6Vd2t6BAlrXIiSDoYNxfA6Xe0NkWCbR4TgcINrZFq0Q1eBOsGmUbZ pbzznPVMQKGB3YsJDR9uju4CGyxJMZd2J3sVCL/e7PhCgXL0KMkO5prUrCMMd2Te2rz36VpJ lEcZTVwsnOjQlqrJ/uUfUapMy3crKM0wrn7mxqgKiutAIrjgnC5/vw0599873cw7HAU6/pxW jftDQz4GSKQf+cLt/kW5nA== --B_3517573907_37795961-- From nobody Fri Jun 19 14:12:39 2015 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 50D361B2A9A for ; Fri, 19 Jun 2015 14:12:38 -0700 (PDT) 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 LkJI2RiB-jXD for ; Fri, 19 Jun 2015 14:12:36 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB681B2A96 for ; Fri, 19 Jun 2015 14:12:35 -0700 (PDT) Received: by wgbhy7 with SMTP id hy7so98839205wgb.2 for ; Fri, 19 Jun 2015 14:12:34 -0700 (PDT) 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=zM+NHWU1c/Yq7MgmBYCKLeZgiL2IMl0w60Ypw8D9QCs=; b=tzYmVwpYx1tPmLGCEA43W13/NjB81aIf8MjmaBheee/dl6+XiP+xRyY9+N8i7oKYys EtLHI/4T/g22UWRil3mfvB3FulIkX10kes1wRPP8F7PdD1MfBY4Xb09/BIOrZWc3IZFR JP/dXYDT67B1qEInWIdfjFgE4zACvnKHcjH9eorFUgFpCoqcYvKH2Iuht7vt+xd8Bz2j 24hE3Ya+2GNKZzEnIPXxytz4DYGoUpCwQy4BTE6rbcGgSe6rCqNP4Xmqx4L92IPnao68 uEHguduM7ECPSLmop78hmjxqBQmJU32xK2C2sB5uReZWXe4o3WHWZWOugTN25+Vv/37D dqgg== X-Received: by 10.180.188.48 with SMTP id fx16mr10063793wic.35.1434748354559; Fri, 19 Jun 2015 14:12:34 -0700 (PDT) Received: from [10.2.203.230] (dab-glb1-h-1-2.dab.02.net. [82.132.216.222]) by mx.google.com with ESMTPSA id c2sm15689312wjf.18.2015.06.19.14.12.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jun 2015 14:12:33 -0700 (PDT) References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <57EA5E46-BB59-436E-B2E9-B70DF113E9FA@gmail.com> X-Mailer: iPhone Mail (12F70) From: Christopher Dearlove Date: Fri, 19 Jun 2015 22:12:28 +0100 To: "Wiggins, David - 0665 - MITLL" Archived-At: Cc: RJ Atkinson , "manet@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 21:12:38 -0000 I'm not claiming to be an authority, but I've had some experience. This is m= y observation of how I've seen things work, rather than anything official. A= s such if, for example, someone comes along and points out that I've misstat= ed something, with proper references, believe them not me. And I also realise this is a post which many will see as teaching egg suckin= g. Those who do, please do improve on it. To make things more complicated, we have at least two overlapping concepts. First, when we allocate a number space, we typically allocate some numbers f= or private or experimental use. (Those two aren't exactly the same, but clos= e enough for these purposes.) Essentially I shouldn't let things using those= numbers escape onto the wider Internet, they should be confined to my netwo= rk. And on my network I can do what I like. You can use the same number in t= hat space for something completely different in your network. Those numbers a= ren't allocated. Typically the rest are allocated by IANA (usually subject t= o some sort of review process, which makes it not quite first come first ser= ved). Then, separately, I can create something that builds on (extends) a standard= protocol. Obviously I can do that privately, and no one else will care, bec= ause no one else will know. But if I want to do it more broadly I will publi= sh an Internet Draft. While in that state, now lots of people can try it out= on their private networks, and we can even try joining our networks togethe= r (especially possible in a MANET). But again we ought not to pollute the pu= blic Internet. We may then progress to an RFC. Which might be experimental or a Proposed St= andard (it could also be informational, but I won't go there). Obviously in t= he standard case we should be able to use it publicly. I'm not sure what the= exact rules are in the experimental case, but I would assume we should at t= he least be very wary of letting things out or not do so at all depending on= the next point. Which is that any extension (private, ID, experimental or standard) might be= backwardly compatible or not. A non-backwardly compatible standard will hav= e had to jump through lots of hard hoops. I'm not sure how hard a non-backwa= rdly compatible experimental RFC is to get accepted as I haven't had to try t= hat. But it's a good idea to design your protocol to make compatible extensi= ons possible (which means considering things like what to do with an unknown= object). Now crossing the two (allocations and extensions) typically an extension nee= ds new allocations. (Not always, but let's assume it does.) Obviously a new s= tandard is easy to get an allocation for (unless space is low). Whether a ne= w experimental RFC can get an allocation depends on the rules set up when th= e appropriate registry is defined. That should be in the RFC that defines th= e register. There's an RFC (sorry, number not to hand) that lists the option= s here. But it's perfectly possible to set up a registry so that experimenta= l protocols can claim from the IANA allocated part, so we can run a well-def= ined common allocation. Shortly I expect to be able to say been there, done t= hat. I have seen (not in MANET) IANA allocate even at the Internet Draft sta= ge, but I don't know how you persuade anyone to do that (nor do I care to do= it). All of which I think is pretty much consistent with Stan's coffee pot extens= ion, which went through these stages. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 19 Jun 2015, at 20:51, Wiggins, David - 0665 - MITLL wrote: >=20 >> On 6/19/15, 1:50 PM, "Ratliff, Stanley" wrote: >>=20 >> David, >>=20 >>> If I go through your story, and everywhere it mentions "experiment" I >>> replace it with "experimental extension" using this notion: >>>=20 >>> a 16 bit extension number, with half of the space reserved for >>> standardized extensions and half for experimental/non-standard ones. >>> Perhaps IANA could even assign the experimental ones on a >>> first-come-first- >>> serve, no spec required basis to help with interoperability. >>=20 >> As it has been explained to me, that notion collides with IANA/IESG in at= >> least a couple of not-so-nice ways: >> 1. Creating a "standards-track protocol" with 32,767 experiments, and >> another 32,767 extensions, isn't much of a standard - everything's pretty= >> much an experiment or an extension. >=20 > The core protocol as defined in the draft/RFC isn't an extension or an > experiment, and that's what is being standardized, at least initially. > I'm not sure why IANA/IESG would have an issue with the number of > extensions or experiments allowed. >=20 >>=20 >> 2. I don't believe IANA operates that way. They need a WG-approved >> document in order to start the assignment process. >=20 > OK. I was under the impression that there could be different rules for > experimental extensions in other cases, and they could do a lightweight > assignment, but I am no authority here. Maybe someone who knows can chime= > in. >=20 > David > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Sat Jun 20 06:16:32 2015 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 A6CCB1A8752 for ; Sat, 20 Jun 2015 06:16:30 -0700 (PDT) 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 OQEKlLxziz-l for ; Sat, 20 Jun 2015 06:16:28 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 5A9E41A8750 for ; Sat, 20 Jun 2015 06:16:28 -0700 (PDT) Received: by ykdt186 with SMTP id t186so1974516ykd.0 for ; Sat, 20 Jun 2015 06:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=rlTklKX5YJfq5LPsuUmYCmxwSrYsV0DyKHse6q4s8qU=; b=IfjX2WKbQIqUGYa/jhj6iALNsQvA0Tv4vQ0Bj0teGQu+4Or40Ckm1XoZhJRRQML4eI ZtRAIBEJeaJSGLGcHtuyQdPLhp0RZyMh2SH1m24cO1lgDgmA5bplTCLRX5dTa4HF81p9 hl0ZtiubZr3IU6QPB3Um9IvT5z0gnMsxSiUmREflgJGEb/eFCMWaHYtdinzDWoclDDEV 0je+lRgZ286vLfX4dYAiuHeesAEsyL8p0E6ub9IXw0JJ79OGqg9Q6gFAq3r03d12xD+U PpMtfBi73fCZmXZ9dC89XwrzNVjJSjd8/fjUkWMF6A0RHDz+1p17pX7iqfEkus+Sdr0O iv8g== X-Received: by 10.13.231.132 with SMTP id q126mr25835362ywe.14.1434806187717; Sat, 20 Jun 2015 06:16:27 -0700 (PDT) Received: from [10.30.20.18] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id w6sm11184414ywf.31.2015.06.20.06.16.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jun 2015 06:16:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: RJ Atkinson In-Reply-To: Date: Sat, 20 Jun 2015 09:16:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> To: manet@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Sat, 20 Jun 2015 13:16:30 -0000 > On 19 Jun 2015, at 12:09 , Ratliff, Stanley = wrote: >=20 > So, let's start with a scenario - assume that DLEP is now = RFC-blah-de-blah, and I have an interoperable version deployed. The sun = is rising in the East, the crops are bountiful, and I've *finally* lost = that pesky 30lbs (OK, more like 40) that my doctor keeps needling me = about. And then... I get this great idea, having to do with DLEP. With a = small handful of data items, and a correspondingly small number of = signals, I can put an "It-will-even-make-coffee-for-you-in-the-morning" = feature in my modem. But, DLEP is this fixed, interoperable protocol. So = what to do, what to do? Here is a simpler scenario that allows for radio-unique extensions, eliminates the need for a 2nd parser (parsing UTF-8 rather than bits) and is consistent with MANY prior IETF protocols=E2=80=A6 Go to IANA and ask them to assign me Experimental-status Data=20 Item code point(s) and/or Signal code point(s). > With the -14 draft, I can implement this, *initially*, as an = "Experiment". I conjure up the necessary signals = ("DLEP_COFFEEMAKER_START", "DLEP_COFFEEMAKER_STOP"), and also the = requisite data items ("DLEP_COLUMBIAN")... actually, I'd probably add = "DLEP_SUMATRAN", since this is a "high-end" modem, but that's another = story... > I also map out how these signals/data items look (e.g., is the = DLEP_COLUMBIAN data item 8 bits, 16 bits, or just 1?), and then I start = looking for a router vendor to "play nice with me", and support my = coffee maker experiment. Assuming I find such a router vendor, we = implement the "Coffee Maker Experiment" - and again, since this is *my* = scenario, we'll assume that's its wildly successful. All of my beta test = sites are "Slurping coffee on the move", and enjoying it. In fact, it's = so wildly popular that other modem manufacturers are now discussing = bolting coffee makers onto their modems=E2=80=A6 Based on working with a large radio manufacturer, I think that in many = cases these additional code points will be either (a) inherently unique to the particular radio or (b) inherently unique to some property of the radio, modulation scheme/waveform, frequency bands, or something else physical. So I doubt that a typical extension would have utility for most folks. > So, at this point, it's time for me and my router-vendor partner to = approach the MANET WG with a draft describing the Coffee-Maker = "Experiment" as a DLEP "Extension". And true to form, the WG debates the = weighty issues (e.g., Should there be a DLEP_ARABICA data item? NO! YES! = Wait! We should allow it to MAKE TEA! Yes, that's the ticket! It MUST = [proper homage to RFC 2119] contain a DLEP_EARL_GREY data item!), = ad-nauseum, over a period of time that you thought would take a couple = of IETF meetings, but actually spans about 5 years (in other words, you = *thought* it was going to be a project, but it turned into a career = path)=E2=80=A6 Using Stan=E2=80=99s approach, we get to throw away the running code = (because it is UTF-8 rather than using bits) and an entirely new data element or signal gets = added. Users now have to wait for (a) the existing radio vendor to implement = the new=20 things and (b) the existing router vendor(s) to implement the new things = and (c)=20 interoperability issues to be sorted out between the various new = implementations. Alternatively, if we have a single extensions mechanism, and if the = party that obtained the extension codes from IANA thinks it is more broadly useful,=20= then that party can publish an Informational status or Experimental = status RFC (e.g. on the RFC-Editor track, without a lot of process overhead). With this approach, we avoid having 2 parsers (bits vs UTF-8), we have enough Data Item space and Signal space for the foreseeable future (8-bits is too small even if one assumes Stan=E2=80=99s concept), and we = avoid a totally gratuitous period of re-inventing the wheel using bits instead of UTF-8. Things that are useful and openly specified get deployed, regardless=20 of their IETF status. Of course, if radio designer A and radio designer B happen = coincidentally to each design different approaches to the same underlying technology=20 issue, nothing prevents one or both (or some user or some router vendor) from proposing that the appropriate WG (MANET for now) create a standard Data Item or standard Signal for the situation at hand. > Finally, clearing Working Group Last Call (and *then* getting a = crap-ton of really useful comments, because apparently, no one reads = these things unless/until there's supposedly no chance to change them), = you get the official, approved, "DLEP Coffee Maker Extension" registered = with IANA... I and my router-vendor partner (actually, my grandchild and = my router-vendor partner's grandchild, since it's taken so long) can = then swap over our code to stop using the "Experiment", and use the = official "Extension" data items and signals. This is WAY WAY too complex, and the change of syntax between = =E2=80=9CExperiments=E2=80=9D and =E2=80=9CExtensions=E2=80=9D is totally gratuitous (value subtract), = and it is unrealistic. For both physics reasons and technology reasons, there will be some Data = Items=20 (and maybe some Signals) that are inherently tied to the particular = radio,=20 waveform, frequency band, or what have you. Purely as an example, there is an OpenGroup consortium called DirecNet = (TM) that are developing an open-standards radio specification that would be useful for 1st responders. Having some waveform-specific Data Items=20 would be helpful for most waveforms. (Caveat: While I am aware of = DirecNet,=20 and I have attended a meeting or two, my client is NOT a member of = DirecNet.) > But my point here is, that all the while, my customers have been = merrily "slupring coffee on the move, and enjoying it" - utilizing the = "Experimental" TLVs gives me (us, actually) the ability to actually be = *responsive* to our customers, testing out (and even deploying in = limited fashion) changes to the protocol. If/when those "experiments" = prove successful, the mechanism even gives implementers the ability to = shift the code from "Experiment" to "Extension", providing = backward-level compatibility for the move (nothing stops me from = supporting the exact same functionality in "Experimental" mode that I'm = supporting with a now-documented "Extension").=20 But the approach you outline doubles the work versus simply publishing = an Informational or Experimental status RFC once things are sorted out = fully. > ...and that was the motivation behind having both "Experimental" TLVs, = and a documented "Extension" mechanism...=20 I appreciate the explanation. I understand the reasoning. I don=E2=80=99= t think that is a good approach. The additional complexity, including but not limited to having an entire 2nd parser, is too much and the approach is not likely to work well given the real-world = constraints. I would like to see a more conventional IETF approach where we have an=20= obviously large enough code space for Data Items and for Signals, and=20 have an ability to have both standard and non-standard Data Items and=20 Signals added over time as appropriate. Yours, Ran Atkinson From nobody Sat Jun 20 06:21:07 2015 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 CC7671A8766 for ; Sat, 20 Jun 2015 06:21:03 -0700 (PDT) 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 OHXx2IJqNHLe for ; Sat, 20 Jun 2015 06:21:02 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C571A8738 for ; Sat, 20 Jun 2015 06:21:01 -0700 (PDT) Received: by ykfl8 with SMTP id l8so107009595ykf.1 for ; Sat, 20 Jun 2015 06:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=9crnDkDRvJrPcqlw1S3PajyVN9iYRY4fYt84E1dYtIQ=; b=Le95lShqXsPUYbk/7Eg9btsqPrKFcAVtiU/Vv42nHFpSh+0tMwvG0XOIjaKHBSWO/Z WYcARVZ6XcJHIGSoNExGtygIKqnIePks0GsiJKpYLpKpcwDOG/NS4cqh51KL9YYMj77/ yFkSY67fEFNZp7ChBqKlqbFMUMwnXkEQlPbRRpeMCtNT6aA8V0rAnFfxsGkQJC84ZxaS QQt5zLj2nxekzgjqV95YHrNLS7iwpyjihXa5k366IdwtKDY9B2lVBkFpRf8kLa5k49iy I+W7WTHBxdhZQXa5q7jwxL+czc3ldAgjdOKpQsO3M+CMBKk99r6RhsP82IxPOGTi16SA tMTg== X-Received: by 10.170.73.194 with SMTP id p185mr25835668ykp.123.1434806461400; Sat, 20 Jun 2015 06:21:01 -0700 (PDT) Received: from [10.30.20.18] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id j77sm11191801ywg.14.2015.06.20.06.21.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jun 2015 06:21:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: RJ Atkinson In-Reply-To: Date: Sat, 20 Jun 2015 09:21:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <73EE71B1-5C4E-477E-80A8-5D34654FB439@gmail.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> To: manet@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Sat, 20 Jun 2015 13:21:04 -0000 > On 19 Jun 2015, at 12:17 , Henning Rogge wrote: >=20 > On Fri, Jun 19, 2015 at 6:09 PM, Ratliff, Stanley = wrote: >> ...and that was the motivation behind having both "Experimental" = TLVs, and a documented "Extension" mechanism... >=20 > The "text identifier" of the Experiments make it also much easier to > have multiple experiments in house and even do small tests with other > software without worrying about which "experimental number" to take > from the Extension so that you don't have collisions. At present the =E2=80=9Cnumber space=E2=80=9D of 8-bits for Data Items = is already too small =E2=80=94 even assuming the approach Stan outlined in his earlier = note. We need to move to 16-bits for these 2 fields, regardless of the=20 =E2=80=9Cextension approach=E2=80=9D taken. =20 Adding a 2nd parser for UTF-8 is avoidable complexity. The usual IETF approach is to do as David Wiggins suggested, splitting the number space into distinct Standards-track and Experimental subsets, both of which are allocated by IANA (albeit using 2 different allocation policies). Standards-track subspace would use an IETF Standards-Action required policy for code point allocation. The other subspace would use =E2=80=9CFirst Come, First Serve=E2=80=9D with = =E2=80=9CNo specification required=E2=80=9D which some other protocols already do; it works just = fine. Yours, Ran From nobody Sat Jun 20 06:32:39 2015 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 1006C1A8773 for ; Sat, 20 Jun 2015 06:32:38 -0700 (PDT) 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 stfINe1pi0GT for ; Sat, 20 Jun 2015 06:32:36 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (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 9954A1A877B for ; Sat, 20 Jun 2015 06:32:35 -0700 (PDT) Received: by ykdt186 with SMTP id t186so2090097ykd.0 for ; Sat, 20 Jun 2015 06:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=NmRqYA+cNDt5DJutpYkiJXLLQGcRIDanJi4uAa4UxCA=; b=wZtISixt0NxRs00r0gBHEVeFnmpOAjMQvbmayR9JJtV9fdu9ARiYHKonjM8GHJQmlw zELxHRlKTrEmkpeRoukMEuIi3aekdO5/vr0F14ciVma80VSwubfTr+tX1OQMdK+/54be 0PhlQTLawztre4W6fwu9iR6/CKTmRtntlleJMNhSL3jJJVQ2+96AiwtunAERaV5mVlah qvzXochrIxrp2bRAlNO+K8cPou9SfG5Libiv1XYXNZsxfGifGRmxt+5cXSz8fJ6dMkIa 3wedyM+6hYWWHcn309vXQzjpg4utl/DTkGNe3ob/JKqNrpU4eQlLD72Npq4/7gf1GU/v 2qFA== X-Received: by 10.13.227.134 with SMTP id m128mr25867282ywe.131.1434807155034; Sat, 20 Jun 2015 06:32:35 -0700 (PDT) Received: from [10.30.20.18] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id y4sm6374961ywy.2.2015.06.20.06.32.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jun 2015 06:32:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: RJ Atkinson In-Reply-To: Date: Sat, 20 Jun 2015 09:32:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> To: manet@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Sat, 20 Jun 2015 13:32:38 -0000 > On 19 Jun 2015, at 13:50 , Ratliff, Stanley = wrote: >=20 > David, >=20 >> If I go through your story, and everywhere it mentions "experiment" I >> replace it with "experimental extension" using this notion: >>=20 >> a 16 bit extension number, with half of the space reserved for >> standardized extensions and half for experimental/non-standard = ones. >> Perhaps IANA could even assign the experimental ones on a >> first-come-first- >> serve, no spec required basis to help with interoperability. >>=20 >=20 > As it has been explained to me, that notion collides with IANA/IESG in = at least a couple of not-so-nice ways:=20 > 1. Creating a "standards-track protocol" with 32,767 experiments, and = another 32,767 extensions, isn't much of a standard - everything's = pretty much an experiment or an extension.=20 Using a single extension approach would result in a very fine standard,=20= because it ensures that DLEP is extensible and won=E2=80=99t need to be = redone=20 in a few years because the extensibility was too limited/constrained. It also improves interoperability chances because we eliminate the gratuitous UTF-8 parser from all DLEP implementations. 256 standard extensions is likely not enough given the wide range of different radio types in use somewhere on the planet =E2=80=94 and the = rate of growth in different waveforms and radio types and so forth. =20 32K extensions is almost certainly larger than we need. I suppose=20 we could go with a 12-bit field or such like, but alignment benefits=20 suggest either an 8-bit field (too small) or a 16-bit field (more than=20= adequately large). > 2. I don't believe IANA operates that way. They need a WG-approved = document > in order to start the assignment process.=20 This is an incorrect understanding. IANA supports a range of different allocation policies. Each RFC that creates a new protocol number space is required to specify the allocation policies to use precisely BECAUSE=20= IANA supports a range of different policies. If IANA only had one = supported allocation policy, that guidance would not be needed. IANA operates the way you describe ONLY IF the RFC-specified allocation = policy=20 is to require an IETF WG-approved document. IANA can and does manage = various=20 other protocol spaces (most obvious example: TCP/UDP port numbers) using=20= =E2=80=9CFirst Come, First Served=E2=80=9D with =E2=80=9CNo = specification required=E2=80=9D. David Wiggins=E2=80=99 approach is a very good one. Increase the number = space and split the number space. Make one segment =E2=80=9Cstandards-track=E2=80= =9D with an=20 IETF standards-track RFC required for code point allocation from IANA. =20= Make the other segment =E2=80=9CExperimental=E2=80=9D with =E2=80=9CFirst = Come, First Served=E2=80=9D=20 code point allocation from IANA and =E2=80=9Cspecification not = required=E2=80=9D. Yours, Ran Atkinson From nobody Sat Jun 20 06:58:47 2015 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 B91641A87B9 for ; Sat, 20 Jun 2015 06:58:45 -0700 (PDT) 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 3GJ-Y4n2Di2W for ; Sat, 20 Jun 2015 06:58:44 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C811A87BC for ; Sat, 20 Jun 2015 06:58:43 -0700 (PDT) Received: by ykdr198 with SMTP id r198so107668572ykd.3 for ; Sat, 20 Jun 2015 06:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=+SZLUyBBhfIdYCQhyTQ6yDy36s3KOo6zH7OBUsbNGtc=; b=o+zVBZ8m6ZpuDThn2OQgfvChXOcoh03T1qkPO00bP3hdqx2ekNpD9+1Z+z1QpES66H 1kV1PLL18iYPvFIKDJC0GoILo7L9RkhrZFYQNzURY71CGN6M0Ty3J1B2u9c8tvoKE9TS 0yBnqtPmVArau84kpsbXdzzRUerZ139Lq0z+0L+aQXf9d5Tmsy22m8U+NTpKvv42yBj2 FTXg06AZP9/mg59JMFO1c9GguuSKvMn3iIYTbrXs7G3liNxToiVkLjKp6JKlbOdsPtie B0ukASGDmlMEqPsejXJ1aiDgCWar08c9BbKxbETSL1Y0tqgC6JMYqxBm3ki792u/NIKL eh7g== X-Received: by 10.170.188.206 with SMTP id f197mr24379010yke.63.1434808723289; Sat, 20 Jun 2015 06:58:43 -0700 (PDT) Received: from [10.30.20.18] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id c7sm5812067yhb.12.2015.06.20.06.58.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jun 2015 06:58:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: RJ Atkinson In-Reply-To: <57EA5E46-BB59-436E-B2E9-B70DF113E9FA@gmail.com> Date: Sat, 20 Jun 2015 09:58:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0B6EF0E0-1D2B-41BE-B7FB-C67CE7F80B64@gmail.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <57EA5E46-BB59-436E-B2E9-B70DF113E9FA@gmail.com> To: manet@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Sat, 20 Jun 2015 13:58:45 -0000 > On 19 Jun 2015, at 17:12 , Christopher Dearlove = wrote: >=20 > I'm not claiming to be an authority, but I've had some experience. = This is my observation of how I've seen things work, rather than = anything official. As such if, for example, someone comes along and = points out that I've misstated something, with proper references, = believe them not me. >=20 > And I also realise this is a post which many will see as teaching egg = sucking. Those who do, please do improve on it. >=20 > To make things more complicated, we have at least two overlapping = concepts. >=20 > First, when we allocate a number space, we typically allocate some = numbers for private or experimental use. (Those two aren't exactly the = same, but close enough for these purposes.) Essentially I shouldn't let = things using those numbers escape onto the wider Internet, they should = be confined to my network. In my nearly 30 years of IETF experience, the above is not necessarily = the case. =20 There are at least 3 scenarios that one can see if one surveys the set of IETF standards-track protocols, and probably more than that. GIVEN: Standards-track numbers are allocated by IANA upon publication approval for a standards track RFC. On rare occasions, early allocation from IANA will happen for a standards-track I-D=20 when IESG believes it is beneficial to do so. A. The =E2=80=9Cprivate=E2=80=9D or =E2=80=9Cexperimental=E2=80=9D use = numbers are NOT allocated by IANA at all, instead being shared on a non-controlled basis, in which = case packets with those code point values ought not escape one=E2=80=99s = administrative=20 domain. =20 B. Some =E2=80=9Cprivate=E2=80=9D use numbers are allocated =E2=80=9CFirs= t Come, First Serve=E2=80=9D with =E2=80=9Cno specification required=E2=80=9D. C. A hybrid of scenarios A & B. In this case there are 3 different = code point subsets: (1) standards-track (2) private use & allocated by IANA (3) experimental use within one=E2=80=99s own administrative = domain, not allocated by IANA, and =E2=80=9Cits your problem if you = have 2 different implementations=E2=80=9D for a given code point = value The proposal here is (B), but (C) also would be acceptable. =20 If (C) is adopted rather than (B), then I=E2=80=99d make the (C3) pool=20= relatively small (maybe in the range of 8-32 code points). I=E2=80=99d like to see: =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 - more than 8-bits for code points (signals & data items) - 2 different subsets of code points for each=20 - a standards-track code point set that are allocated by IANA upon publication of an IETF standards-track RFC - private use code points allocated by IANA =E2=80=9CFirst Come, First = Served=E2=80=9D with =E2=80=9Cno specification required=E2=80=9D. > And on my network I can do what I like. You can use the same number in = that space for something completely different in your network. Those = numbers aren't allocated. Typically the rest are allocated by IANA = (usually subject to some sort of review process, which makes it not = quite first come first served). =E2=80=9CExpert Review=E2=80=9D is another option, in ADDITION to = =E2=80=9Cstandards-track RFC required=E2=80=9D and =E2=80=9CFirst Come, First Served=E2=80=9D. Normally, one uses =E2=80=9CExpert Review=E2=80=9D either as a = work-around for an overly=20 small set of code points (which bug some of us are trying to avoid here) OR because the protocol was badly designed such that an unrecognized code point causes the protocol behavior to be unspecified/underspecified and implementations are likely to crash horribly (again, something this WG should avoid with DLEP). As I have said, there are a range of existing IANA allocation approaches that can be used in an IETF protocol. > We may then progress to an RFC. Which might be experimental or a = Proposed Standard (it could also be informational, but I won't go = there). Obviously in the standard case we should be able to use it = publicly. I'm not sure what the exact rules are in the experimental = case, but I would assume we should at the least be very wary of letting = things out or not do so at all depending on the next point. The difference between Informational RFC or Experimental RFC sometimes seems subtle. If a code point definition might be =E2=80=9Crisky=E2=80=9D= for the network health, then =E2=80=9CExperimental=E2=80=9D is preferable to = =E2=80=9CInformational=E2=80=9D and the risk ought to be clearly described (see NETBLT). =20 In non-risky cases, either RFC status would be a reasonable choice. Informational RFC is likely better if the goal is to encourage others=20 to use one=E2=80=99s private extension. Justin (with your WG Chair Hat On, please): If it is useful, I am happy to draft up some candidate IANA = Considerations text for the list to evaluate, on the assumption that we increase the code point size to 16-bits. My plan would be to borrow and wordsmith text from other IETF standards-track RFCs in doing this, not to tread new ground. (There is no need for the WG to tread any new ground to do=20= what David and I believe is right.) Yours, Ran From nobody Sat Jun 20 07:38:46 2015 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 AC8B11A023E for ; Sat, 20 Jun 2015 07:38:44 -0700 (PDT) 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 zxQ79K3AhPip for ; Sat, 20 Jun 2015 07:38:42 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E211A0235 for ; Sat, 20 Jun 2015 07:38:41 -0700 (PDT) Received: by obbgp2 with SMTP id gp2so90283856obb.2 for ; Sat, 20 Jun 2015 07:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=bCfJBdB84m5CqIGdmYdfKraBDYvw+78oA36wqj6x8/Y=; b=QqfOaMNSYjeBALmgIdfJM+cBgkmWQ+fcTH+htfA2XLj9fwYAahei6ab0VulFE0l7Rq pGm5i7c3E8ZXzC6qCvehmhpAaVcBmnu1o3GCfGT7TP7YggSrYd9o9cIaDMALA4Yv+B6b FV12Q0rjARR3BKuYjXOBtyYhPHbL/x1HYqKR+9bjvdMXfNR5Q8a/a3Q0QfrdsfAt+LDq lngtFtzmrX0BVFJHd2TfrR22ZHdXTTkdTb15uprx7umPr/N5fvLu5GIGEYXqA/Qrsi1H FTov+IuVT31m9bk2CI1rzMcuUxKDJhemThalWGuX/PqcDPpCmI40ZCLL2v4BoPcFtpUq 9P8w== X-Received: by 10.202.241.67 with SMTP id p64mr7827096oih.87.1434811121298; Sat, 20 Jun 2015 07:38:41 -0700 (PDT) MIME-Version: 1.0 References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <57EA5E46-BB59-436E-B2E9-B70DF113E9FA@gmail.com> <0B6EF0E0-1D2B-41BE-B7FB-C67CE7F80B64@gmail.com> In-Reply-To: <0B6EF0E0-1D2B-41BE-B7FB-C67CE7F80B64@gmail.com> From: Justin Dean Date: Sat, 20 Jun 2015 14:38:30 +0000 Message-ID: To: RJ Atkinson , manet@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0942363474650518f3ffb9 Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Sat, 20 Jun 2015 14:38:44 -0000 --94eb2c0942363474650518f3ffb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ran there is another issue which comes frome a very large first come first serve assignments space. There is little/no incentive to standardize in the standard space and we end up with a bunch of DLEP radios with very limited interoperability support with other vendor DLEP routers. The text based approach was a compromise to help "solve" this issue, if I'm remembering correctly. Propsoed text would be fine but I the main issue was/is the confusion regarding the roles of the different types as presented in the draft. I see value in both approaches. Justin Dean On Sat, Jun 20, 2015, 9:58 AM RJ Atkinson wrote: > > > On 19 Jun 2015, at 17:12 , Christopher Dearlove < > christopher.dearlove@gmail.com> wrote: > > > > I'm not claiming to be an authority, but I've had some experience. This > is my observation of how I've seen things work, rather than anything > official. As such if, for example, someone comes along and points out tha= t > I've misstated something, with proper references, believe them not me. > > > > And I also realise this is a post which many will see as teaching egg > sucking. Those who do, please do improve on it. > > > > To make things more complicated, we have at least two overlapping > concepts. > > > > First, when we allocate a number space, we typically allocate some > numbers for private or experimental use. (Those two aren't exactly the > same, but close enough for these purposes.) Essentially I shouldn't let > things using those numbers escape onto the wider Internet, they should be > confined to my network. > > In my nearly 30 years of IETF experience, the above is not necessarily th= e > case. > > There are at least 3 scenarios that one can see if one surveys the set > of IETF standards-track protocols, and probably more than that. > > GIVEN: Standards-track numbers are allocated by IANA upon publication > approval for a standards track RFC. On rare occasions, early > allocation from IANA will happen for a standards-track I-D > when IESG believes it is beneficial to do so. > > A. The =E2=80=9Cprivate=E2=80=9D or =E2=80=9Cexperimental=E2=80=9D use n= umbers are NOT allocated by IANA > at all, instead being shared on a non-controlled basis, in which case > packets with those code point values ought not escape one=E2=80=99s > administrative > domain. > > B. Some =E2=80=9Cprivate=E2=80=9D use numbers are allocated =E2=80=9CFir= st Come, First Serve=E2=80=9D with > =E2=80=9Cno specification required=E2=80=9D. > > C. A hybrid of scenarios A & B. In this case there are 3 different code > point subsets: > (1) standards-track > (2) private use & allocated by IANA > (3) experimental use within one=E2=80=99s own administrative doma= in, > not allocated by IANA, and =E2=80=9Cits your problem if you h= ave > 2 different implementations=E2=80=9D for a given code point v= alue > > The proposal here is (B), but (C) also would be acceptable. > > If (C) is adopted rather than (B), then I=E2=80=99d make the (C3) pool > relatively small (maybe in the range of 8-32 code points). > > I=E2=80=99d like to see: > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > - more than 8-bits for code points (signals & data items) > - 2 different subsets of code points for each > - a standards-track code point set that are allocated by IANA upon > publication of an IETF standards-track RFC > - private use code points allocated by IANA =E2=80=9CFirst Come, First Se= rved=E2=80=9D > with =E2=80=9Cno specification required=E2=80=9D. > > > And on my network I can do what I like. You can use the same number in > that space for something completely different in your network. Those > numbers aren't allocated. Typically the rest are allocated by IANA (usual= ly > subject to some sort of review process, which makes it not quite first co= me > first served). > > =E2=80=9CExpert Review=E2=80=9D is another option, in ADDITION to =E2=80= =9Cstandards-track RFC > required=E2=80=9D and =E2=80=9CFirst Come, First Served=E2=80=9D. > > Normally, one uses =E2=80=9CExpert Review=E2=80=9D either as a work-aroun= d for an overly > small set of code points (which bug some of us are trying to avoid here) > OR because the protocol was badly designed such that an unrecognized > code point causes the protocol behavior to be unspecified/underspecified > and implementations are likely to crash horribly (again, something this > WG should avoid with DLEP). > > As I have said, there are a range of existing IANA allocation approaches > that can be used in an IETF protocol. > > > We may then progress to an RFC. Which might be experimental or a > Proposed Standard (it could also be informational, but I won't go there). > Obviously in the standard case we should be able to use it publicly. I'm > not sure what the exact rules are in the experimental case, but I would > assume we should at the least be very wary of letting things out or not d= o > so at all depending on the next point. > > The difference between Informational RFC or Experimental RFC sometimes > seems subtle. If a code point definition might be =E2=80=9Crisky=E2=80= =9D for the > network health, then =E2=80=9CExperimental=E2=80=9D is preferable to =E2= =80=9CInformational=E2=80=9D > and the risk ought to be clearly described (see NETBLT). > > In non-risky cases, either RFC status would be a reasonable choice. > Informational RFC is likely better if the goal is to encourage others > to use one=E2=80=99s private extension. > > > Justin (with your WG Chair Hat On, please): > > If it is useful, I am happy to draft up some candidate IANA Consideration= s > text for the list to evaluate, on the assumption that we increase the > code point size to 16-bits. My plan would be to borrow and wordsmith > text from other IETF standards-track RFCs in doing this, not to tread > new ground. (There is no need for the WG to tread any new ground to do > what David and I believe is right.) > > Yours, > > Ran > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --94eb2c0942363474650518f3ffb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ran there is another issue which comes frome a very large fi= rst come first serve assignments space. There is little/no incentive to sta= ndardize in the standard space and we end up with a bunch of DLEP radios wi= th very limited interoperability support with other vendor DLEP routers. Th= e text based approach was a compromise to help "solve" this issue= , if I'm remembering correctly. Propsoed text would be fine but I the m= ain issue was/is the confusion regarding the roles of the different types a= s presented in the draft. I see value in both approaches.

Justin Dean


On Sat, Jun 20, 2015, 9:58 = AM=C2=A0RJ Atkinson <rja.lists@gm= ail.com> wrote:

> On 19=C2=A0 Jun 2015, at 17:12 , Christopher Dearlove <christopher.dearlov= e@gmail.com> wrote:
>
> I'm not claiming to be an authority, but I've had some experie= nce. This is my observation of how I've seen things work, rather than a= nything official. As such if, for example, someone comes along and points o= ut that I've misstated something, with proper references, believe them = not me.
>
> And I also realise this is a post which many will see as teaching egg = sucking. Those who do, please do improve on it.
>
> To make things more complicated, we have at least two overlapping conc= epts.
>
> First, when we allocate a number space, we typically allocate some num= bers for private or experimental use. (Those two aren't exactly the sam= e, but close enough for these purposes.) Essentially I shouldn't let th= ings using those numbers escape onto the wider Internet, they should be con= fined to my network.

In my nearly 30 years of IETF experience, the above is not necessarily the = case.

There are at least 3 scenarios that one can see if one surveys the set
of IETF standards-track protocols, and probably more than that.

GIVEN:=C2=A0 Standards-track numbers are allocated by IANA upon publication=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 approval for a standards track RFC.=C2=A0 On ra= re occasions, early
=C2=A0 =C2=A0 =C2=A0 =C2=A0 allocation from IANA will happen for a standard= s-track I-D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 when IESG believes it is beneficial to do so.
A.=C2=A0 The =E2=80=9Cprivate=E2=80=9D or =E2=80=9Cexperimental=E2=80=9D us= e numbers are NOT allocated by IANA
=C2=A0 =C2=A0 at all, instead being shared on a non-controlled basis, in wh= ich case
=C2=A0 =C2=A0 packets with those code point values ought not escape one=E2= =80=99s administrative
=C2=A0 =C2=A0 domain.

B.=C2=A0 Some =E2=80=9Cprivate=E2=80=9D use numbers are allocated =E2=80=9C= First Come, First Serve=E2=80=9D with
=C2=A0 =C2=A0 =E2=80=9Cno specification required=E2=80=9D.

C.=C2=A0 A hybrid of scenarios A & B.=C2=A0 In this case there are 3 di= fferent code
=C2=A0 =C2=A0 point subsets:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (1) standards-track
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (2) private use & allocated by IANA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (3) experimental use within one=E2=80=99s own a= dministrative domain,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not allocated by IANA, and =E2=80= =9Cits your problem if you have
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 different implementations=E2=80= =9D for a given code point value

The proposal here is (B), but (C) also would be acceptable.

If (C) is adopted rather than (B), then I=E2=80=99d make the (C3) pool
relatively small (maybe in the range of 8-32 code points).

I=E2=80=99d like to see:
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 - more than 8-bits for code points (signals & data items)
- 2 different subsets of code points for each
- a standards-track code point set that are allocated by IANA upon
=C2=A0 publication of an IETF standards-track RFC
- private use code points allocated by IANA =E2=80=9CFirst Come, First Serv= ed=E2=80=9D
=C2=A0 with =E2=80=9Cno specification required=E2=80=9D.

> And on my network I can do what I like. You can use the same number in= that space for something completely different in your network. Those numbe= rs aren't allocated. Typically the rest are allocated by IANA (usually = subject to some sort of review process, which makes it not quite first come= first served).

=E2=80=9CExpert Review=E2=80=9D is another option, in ADDITION to =E2=80=9C= standards-track RFC
required=E2=80=9D and =E2=80=9CFirst Come, First Served=E2=80=9D.

Normally, one uses =E2=80=9CExpert Review=E2=80=9D either as a work-around = for an overly
small set of code points (which bug some of us are trying to avoid here) OR because the protocol was badly designed such that an unrecognized
code point causes the protocol behavior to be unspecified/underspecified and implementations are likely to crash horribly (again, something this
WG should avoid with DLEP).

As I have said, there are a range of existing IANA allocation approaches that can be used in an IETF protocol.

> We may then progress to an RFC. Which might be experimental or a Propo= sed Standard (it could also be informational, but I won't go there). Ob= viously in the standard case we should be able to use it publicly. I'm = not sure what the exact rules are in the experimental case, but I would ass= ume we should at the least be very wary of letting things out or not do so = at all depending on the next point.

The difference between Informational RFC or Experimental RFC sometimes
seems subtle.=C2=A0 If a code point definition might be =E2=80=9Crisky=E2= =80=9D for the
network health, then =E2=80=9CExperimental=E2=80=9D is preferable to =E2=80= =9CInformational=E2=80=9D
and the risk ought to be clearly described (see NETBLT).

In non-risky cases, either RFC status would be a reasonable choice.
Informational RFC is likely better if the goal is to encourage others
to use one=E2=80=99s private extension.


Justin (with your WG Chair Hat On, please):

If it is useful, I am happy to draft up some candidate IANA Considerations<= br> text for the list to evaluate, on the assumption that we increase the
code point size to 16-bits.=C2=A0 My plan would be to borrow and wordsmith<= br> text from other IETF standards-track RFCs in doing this, not to tread
new ground.=C2=A0 (There is no need for the WG to tread any new ground to d= o
what David and I believe is right.)

Yours,

Ran

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--94eb2c0942363474650518f3ffb9-- From nobody Mon Jun 22 02:22:16 2015 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 A42541B2E90 for ; Mon, 22 Jun 2015 02:22:15 -0700 (PDT) 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 4VB66WovGtg5 for ; Mon, 22 Jun 2015 02:22:14 -0700 (PDT) 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 8669F1B2E72 for ; Mon, 22 Jun 2015 02:22:13 -0700 (PDT) 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; Mon, 22 Jun 2015 10:21:47 +0100 From: Rick Taylor To: RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 - Experiments Thread-Index: AQHQrMzaE0ilZbumtEWuopaqaqiIbg== Date: Mon, 22 Jun 2015 09:21:42 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AAD49@tss-server1.home.tropicalstormsoftware.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.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: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 - Experiments 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: Mon, 22 Jun 2015 09:22:15 -0000 Okay, I'm back and I'm jumping in on this one with my author hat on...=0A= =0A= The historical reason for both Experiments and Extensions are:=0A= =0A= 1) We tried it a different way - 'Optional Data Items supported (and =0A= friends)' and everyone hated it.=0A= =0A= 2) There was general consensus that DLEP should be extensible so that =0A= progress could be made standardizing the core functionality without =0A= preventing further good work becoming 'standard extensions' at a later date= .=0A= =0A= 3) Implementers wanted some 'local administratively scoped' sandbox for =0A= their own experiments, prior to approaching the IETF.=0A= =0A= 4) The reason for strings is avoid clashes (like a GUID). We previously = =0A= recommended registered IEEE EUIDs, but strings were viewed as simpler =0A= and less restrictive, i.e. You don't need to pay IEEE.=0A= =0A= The reasoning behind the Experiments are:=0A= =0A= Most current DLEP router implementations talk to multiple radios at =0A= once, and sometimes experimental features are exposed by either peer. =0A= In this use-case it must be possible for the router to advertise to all =0A= radios that it is willing to process Vendor-X experiments *and* Vendor-Y = =0A= experiments, while the experiment is being performed, *before* taking =0A= the results to the IETF, because it is still an experiment.=0A= =0A= Hence: A DLEP peer MUST be able to advertise support for multiple =0A= experiments, but it is up to the implementer how to handle clashes of =0A= ids in the experimental range.=0A= =0A= The reason for using a textual identifier for an experiment is the other = =0A= requirement: Experiment ids SHOULD be scoped locally, there is no =0A= appetite for grabbing an id from some IANA list, registering it for =0A= posterity, etc. just for a quick experiment. That is Extensions. With =0A= text, one can just use one's make and model name, e.g. "Stan's Coffee =0A= machine experiment" is good enough, iff I am talking to Stan's radio in =0A= my lab; it is unlikely that John's tea machine will unintentionally =0A= advertise an identical experiment id.=0A= =0A= As a side note on strings, the UTF8 requirement is there so that the =0A= strings may be output to somewhere user readable. As far as any =0A= processor is concerned, octet by octet compare is all that is required: =0A= memcmp() is enough, no UTF parser needed. A potential criticism would =0A= be that non-printable characters are allowed in the draft currently. If = =0A= UTF8 seems too lose, then let's use [A-Za-z0-9_], but strings are there =0A= for a good reason. A counter argument is adding extra restrictions on =0A= the format of the text adds processing requirements on the peer.=0A= =0A= Adding more signal and data item ids for experiments is irrelevant, the =0A= critical question is how do two peers identify experiments about which =0A= they can negotiate support? Our proposed solution: unique strings.=0A= =0A= In summary: There is a good reason for the split between Experiments =0A= and Extensions. They cover two different use-cases that are in use =0A= today. We have chewed this over thoroughly, and although it seems that =0A= we have proposed a 'dog's breakfast' solution, it is actually backed by =0A= good reasoning.=0A= =0A= By contrast, Extensions are modelled on the SMTP mechanism (but using =0A= numeric ids). There MUST be a document that has passed through the =0A= IETF. IANA MUST assign a unique numeric ID. A peer may implement zero =0A= or more Extensions as it sees fit. The end.=0A= =0A= Hope that helps,=0A= =0A= Rick=0A= From nobody Mon Jun 22 02:50:07 2015 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 113A61B2EDB for ; Mon, 22 Jun 2015 02:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 6DaPpq8sXbG6 for ; Mon, 22 Jun 2015 02:50:01 -0700 (PDT) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA481B2ED7 for ; Mon, 22 Jun 2015 02:50:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,658,1427756400"; d="scan'208";a="388594" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta2.baesystems.com with ESMTP; 22 Jun 2015 10:49:59 +0100 X-IronPort-AV: E=Sophos;i="5.13,658,1427756400"; d="scan'208";a="102302504" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 22 Jun 2015 10:49:59 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.17]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0224.002; Mon, 22 Jun 2015 10:49:58 +0100 From: "Dearlove, Christopher (UK)" To: RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6wK+stmbvhUWtFDx9P52N9Z2z0j6AgAAdtACAABLIgIAACYWAgAAh0YCAABaKAIABGSOAgALsxDA= Date: Mon, 22 Jun 2015 09:49:58 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <57EA5E46-BB59-436E-B2E9-B70DF113E9FA@gmail.com> <0B6EF0E0-1D2B-41BE-B7FB-C67CE7F80B64@gmail.com> In-Reply-To: <0B6EF0E0-1D2B-41BE-B7FB-C67CE7F80B64@gmail.com> 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: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 09:50:06 -0000 Tm8sIG5vdCBuZWNlc3NhcmlseSB0aGUgY2FzZSwgYXMgSSBpbmRpY2F0ZWQuIEJ1dCBtb3N0IG9m IHRoZSBwcm90b2NvbHMgSSd2ZSBvYnNlcnZlZCBoYXZlIG1vcmUgY29udHJvbCB0aGFuIGEgZnJl ZSBmb3IgYWxsIGluIElBTkEgYWxsb2NhdGVkIHNwYWNlLCBwbHVzIGFuIGV4cGVyaW1lbnRhbCBz cGFjZSAobm90IHRoZSBzYW1lIGFzIGFuIGV4cGVyaW1lbnRhbCBwcm90b2NvbCBhcyB5b3Uga25v dyBidXQgSSB0aG91Z2ggYW5vdGhlciBwb3N0IG11ZGRsZWQpIHRoYXQgaXMgcHJpdmF0ZWx5IHVz ZWQuIFRoYXQgcGF0dGVybiB3b3JrcyB3ZWxsIGFuZCByZWR1Y2VzIHByb2JsZW1zLg0KDQpXaGF0 IHByb2JsZW1zPyBMb29rIGF0IGl0IGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHVzZXJzLCB3aGlj aCBpbmNsdWRlcyB0aGUgY29tcGFueSBJIHdvcmsgZm9yLiBUaGV5L3dlIHdvdWxkIHdhbnQgdG8g YnV5IERMRVAtZW5hYmxlZCByYWRpb3MsIGFuZCBETEVQLWVuYWJsZWQgcm91dGVycywgaW5kZXBl bmRlbnRseSwgYW5kIGhhdmUgdGhlbSB3b3JrIHRvZ2V0aGVyLiBVbmZvcnR1bmF0ZWx5IHRoYXQn cyBub3QgYWx3YXlzIGFzIHN0cmFpZ2h0Zm9yd2FyZCBhcyBpdCBvdWdodCB0byBiZSwgYnV0IG15 IGJlbGllZiBpcyB0aGF0IHNvbWUgcmV2aWV3L2NvbnRyb2wgb3ZlciB0aGUgY3JlYXRpb24gb2Yg bmV3IFRMVnMgd291bGQgbWFrZSB0aGF0IG1vcmUgbGlrZWx5LCB3aGlsZSBhIGZyZWUgZm9yIGFs bCBmaXJzdCBjb21lIGZpcnN0IHNlcnZlZCBpbiBhIGxhcmdlIHNwYWNlIHdvdWxkIG1ha2UgaXQg bGVzcyBsaWtlbHkuDQoNCkluIG90aGVyIHdvcmRzLCBDIG9uIHlvdXIgbGlzdCwgd2hpY2ggaXMg d2hhdCBJIGRlc2NyaWJlZCwgd2l0aG91dCBDMi4gVGhlIGxhc3QgcHJvdG9jb2wgSSBsb29rZWQg YXQgd2l0aCBhIEMyIElBTkEgcmVnaXN0cnkgaXQgd2FzIGVtcHR5IGFmdGVyIG1hbnkgeWVhcnMg b2YgZXhpc3RlbmNlLiBBbmQgQzIgaXMgd29yc2Ugd2hlbiB5b3UgaGF2ZSB0d28gdHlwZXMgb2Yg ZXF1aXBtZW50IChyYWRpb3MgYW5kIHJvdXRlcnMpIHRhbGtpbmcgdG8gZWFjaCBvdGhlciwgcmF0 aGVyIHRoYW4gb25lIHR5cGUgKHJvdXRlcnMgcnVubmluZyBhIHJvdXRpbmcgcHJvdG9jb2wpIGFu ZCBmcm9tIGRpZmZlcmVudCBtYW51ZmFjdHVyZXJzLiBBbnl0aGluZyBpbiBDMiwgd2h5IG5vdCBt YWtlIGl0IGluIEMxPw0KDQotLSANCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNp cGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZQ0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KVDogwqArNDQgKDApMTI0NSAyNDIxOTQgwqB8IMKgRTogY2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENo ZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4 IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWkNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50 ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMz NzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQs IFN1cnJleSwgR1UyIDdZUA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBt YW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSSiBBdGtp bnNvbg0KU2VudDogMjAgSnVuZSAyMDE1IDE0OjU5DQpUbzogbWFuZXRAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbbWFuZXRdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC0xNA0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwg ZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCkNv bnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBv cGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNp b3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0 aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoqKiogV0FSTklORyAqKioNClRoaXMg bWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLCBlaXRoZXIg ZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4gQ29uc2lkZXIgY2FyZWZ1 bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFj aG1lbnRzIG9yIHJlcGx5LiBGb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCBTcGVhcnBo aXNoaW5nLCBjbGljayBoZXJlIDxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hv d3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL1BhZ2VzL1NwZWFycGhpc2hpbmdUaXBzLmFzcHg+ LiBJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlz IHByb2Nlc3MuIDxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9z ZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMl MjBFbWFpbHMucGRmPg0KDQo+IE9uIDE5ICBKdW4gMjAxNSwgYXQgMTc6MTIgLCBDaHJpc3RvcGhl ciBEZWFybG92ZSA8Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+ IEknbSBub3QgY2xhaW1pbmcgdG8gYmUgYW4gYXV0aG9yaXR5LCBidXQgSSd2ZSBoYWQgc29tZSBl eHBlcmllbmNlLiBUaGlzIGlzIG15IG9ic2VydmF0aW9uIG9mIGhvdyBJJ3ZlIHNlZW4gdGhpbmdz IHdvcmssIHJhdGhlciB0aGFuIGFueXRoaW5nIG9mZmljaWFsLiBBcyBzdWNoIGlmLCBmb3IgZXhh bXBsZSwgc29tZW9uZSBjb21lcyBhbG9uZyBhbmQgcG9pbnRzIG91dCB0aGF0IEkndmUgbWlzc3Rh dGVkIHNvbWV0aGluZywgd2l0aCBwcm9wZXIgcmVmZXJlbmNlcywgYmVsaWV2ZSB0aGVtIG5vdCBt ZS4NCj4gDQo+IEFuZCBJIGFsc28gcmVhbGlzZSB0aGlzIGlzIGEgcG9zdCB3aGljaCBtYW55IHdp bGwgc2VlIGFzIHRlYWNoaW5nIGVnZyBzdWNraW5nLiBUaG9zZSB3aG8gZG8sIHBsZWFzZSBkbyBp bXByb3ZlIG9uIGl0Lg0KPiANCj4gVG8gbWFrZSB0aGluZ3MgbW9yZSBjb21wbGljYXRlZCwgd2Ug aGF2ZSBhdCBsZWFzdCB0d28gb3ZlcmxhcHBpbmcgY29uY2VwdHMuDQo+IA0KPiBGaXJzdCwgd2hl biB3ZSBhbGxvY2F0ZSBhIG51bWJlciBzcGFjZSwgd2UgdHlwaWNhbGx5IGFsbG9jYXRlIHNvbWUg bnVtYmVycyBmb3IgcHJpdmF0ZSBvciBleHBlcmltZW50YWwgdXNlLiAoVGhvc2UgdHdvIGFyZW4n dCBleGFjdGx5IHRoZSBzYW1lLCBidXQgY2xvc2UgZW5vdWdoIGZvciB0aGVzZSBwdXJwb3Nlcy4p IEVzc2VudGlhbGx5IEkgc2hvdWxkbid0IGxldCB0aGluZ3MgdXNpbmcgdGhvc2UgbnVtYmVycyBl c2NhcGUgb250byB0aGUgd2lkZXIgSW50ZXJuZXQsIHRoZXkgc2hvdWxkIGJlIGNvbmZpbmVkIHRv IG15IG5ldHdvcmsuDQoNCkluIG15IG5lYXJseSAzMCB5ZWFycyBvZiBJRVRGIGV4cGVyaWVuY2Us IHRoZSBhYm92ZSBpcyBub3QgbmVjZXNzYXJpbHkgdGhlIGNhc2UuICANCg0KVGhlcmUgYXJlIGF0 IGxlYXN0IDMgc2NlbmFyaW9zIHRoYXQgb25lIGNhbiBzZWUgaWYgb25lIHN1cnZleXMgdGhlIHNl dCBvZiBJRVRGIHN0YW5kYXJkcy10cmFjayBwcm90b2NvbHMsIGFuZCBwcm9iYWJseSBtb3JlIHRo YW4gdGhhdC4NCg0KR0lWRU46ICBTdGFuZGFyZHMtdHJhY2sgbnVtYmVycyBhcmUgYWxsb2NhdGVk IGJ5IElBTkEgdXBvbiBwdWJsaWNhdGlvbg0KICAgICAgICBhcHByb3ZhbCBmb3IgYSBzdGFuZGFy ZHMgdHJhY2sgUkZDLiAgT24gcmFyZSBvY2Nhc2lvbnMsIGVhcmx5DQogICAgICAgIGFsbG9jYXRp b24gZnJvbSBJQU5BIHdpbGwgaGFwcGVuIGZvciBhIHN0YW5kYXJkcy10cmFjayBJLUQgDQogICAg ICAgIHdoZW4gSUVTRyBiZWxpZXZlcyBpdCBpcyBiZW5lZmljaWFsIHRvIGRvIHNvLg0KDQpBLiAg VGhlIOKAnHByaXZhdGXigJ0gb3Ig4oCcZXhwZXJpbWVudGFs4oCdIHVzZSBudW1iZXJzIGFyZSBO T1QgYWxsb2NhdGVkIGJ5IElBTkENCiAgICBhdCBhbGwsIGluc3RlYWQgYmVpbmcgc2hhcmVkIG9u IGEgbm9uLWNvbnRyb2xsZWQgYmFzaXMsIGluIHdoaWNoIGNhc2UNCiAgICBwYWNrZXRzIHdpdGgg dGhvc2UgY29kZSBwb2ludCB2YWx1ZXMgb3VnaHQgbm90IGVzY2FwZSBvbmXigJlzIGFkbWluaXN0 cmF0aXZlIA0KICAgIGRvbWFpbi4gIA0KDQpCLiAgU29tZSDigJxwcml2YXRl4oCdIHVzZSBudW1i ZXJzIGFyZSBhbGxvY2F0ZWQg4oCcRmlyc3QgQ29tZSwgRmlyc3QgU2VydmXigJ0gd2l0aA0KICAg IOKAnG5vIHNwZWNpZmljYXRpb24gcmVxdWlyZWTigJ0uDQoNCkMuICBBIGh5YnJpZCBvZiBzY2Vu YXJpb3MgQSAmIEIuICBJbiB0aGlzIGNhc2UgdGhlcmUgYXJlIDMgZGlmZmVyZW50IGNvZGUNCiAg ICBwb2ludCBzdWJzZXRzOg0KCSgxKSBzdGFuZGFyZHMtdHJhY2sNCgkoMikgcHJpdmF0ZSB1c2Ug JiBhbGxvY2F0ZWQgYnkgSUFOQQ0KCSgzKSBleHBlcmltZW50YWwgdXNlIHdpdGhpbiBvbmXigJlz IG93biBhZG1pbmlzdHJhdGl2ZSBkb21haW4sDQogICAgICAgICAgICBub3QgYWxsb2NhdGVkIGJ5 IElBTkEsIGFuZCDigJxpdHMgeW91ciBwcm9ibGVtIGlmIHlvdSBoYXZlDQogICAgICAgICAgICAy IGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnPigJ0gZm9yIGEgZ2l2ZW4gY29kZSBwb2ludCB2YWx1 ZQ0KDQpUaGUgcHJvcG9zYWwgaGVyZSBpcyAoQiksIGJ1dCAoQykgYWxzbyB3b3VsZCBiZSBhY2Nl cHRhYmxlLiAgDQoNCklmIChDKSBpcyBhZG9wdGVkIHJhdGhlciB0aGFuIChCKSwgdGhlbiBJ4oCZ ZCBtYWtlIHRoZSAoQzMpIHBvb2wgcmVsYXRpdmVseSBzbWFsbCAobWF5YmUgaW4gdGhlIHJhbmdl IG9mIDgtMzIgY29kZSBwb2ludHMpLg0KDQpJ4oCZZCBsaWtlIHRvIHNlZToNCuKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlA0KLSBtb3JlIHRoYW4gOC1iaXRzIGZvciBjb2RlIHBvaW50cyAoc2lnbmFs cyAmIGRhdGEgaXRlbXMpDQotIDIgZGlmZmVyZW50IHN1YnNldHMgb2YgY29kZSBwb2ludHMgZm9y IGVhY2gNCi0gYSBzdGFuZGFyZHMtdHJhY2sgY29kZSBwb2ludCBzZXQgdGhhdCBhcmUgYWxsb2Nh dGVkIGJ5IElBTkEgdXBvbg0KICBwdWJsaWNhdGlvbiBvZiBhbiBJRVRGIHN0YW5kYXJkcy10cmFj ayBSRkMNCi0gcHJpdmF0ZSB1c2UgY29kZSBwb2ludHMgYWxsb2NhdGVkIGJ5IElBTkEg4oCcRmly c3QgQ29tZSwgRmlyc3QgU2VydmVk4oCdDQogIHdpdGgg4oCcbm8gc3BlY2lmaWNhdGlvbiByZXF1 aXJlZOKAnS4NCg0KPiBBbmQgb24gbXkgbmV0d29yayBJIGNhbiBkbyB3aGF0IEkgbGlrZS4gWW91 IGNhbiB1c2UgdGhlIHNhbWUgbnVtYmVyIGluIHRoYXQgc3BhY2UgZm9yIHNvbWV0aGluZyBjb21w bGV0ZWx5IGRpZmZlcmVudCBpbiB5b3VyIG5ldHdvcmsuIFRob3NlIG51bWJlcnMgYXJlbid0IGFs bG9jYXRlZC4gVHlwaWNhbGx5IHRoZSByZXN0IGFyZSBhbGxvY2F0ZWQgYnkgSUFOQSAodXN1YWxs eSBzdWJqZWN0IHRvIHNvbWUgc29ydCBvZiByZXZpZXcgcHJvY2Vzcywgd2hpY2ggbWFrZXMgaXQg bm90IHF1aXRlIGZpcnN0IGNvbWUgZmlyc3Qgc2VydmVkKS4NCg0K4oCcRXhwZXJ0IFJldmlld+KA nSBpcyBhbm90aGVyIG9wdGlvbiwgaW4gQURESVRJT04gdG8g4oCcc3RhbmRhcmRzLXRyYWNrIFJG QyByZXF1aXJlZOKAnSBhbmQg4oCcRmlyc3QgQ29tZSwgRmlyc3QgU2VydmVk4oCdLg0KDQpOb3Jt YWxseSwgb25lIHVzZXMg4oCcRXhwZXJ0IFJldmlld+KAnSBlaXRoZXIgYXMgYSB3b3JrLWFyb3Vu ZCBmb3IgYW4gb3Zlcmx5IHNtYWxsIHNldCBvZiBjb2RlIHBvaW50cyAod2hpY2ggYnVnIHNvbWUg b2YgdXMgYXJlIHRyeWluZyB0byBhdm9pZCBoZXJlKSBPUiBiZWNhdXNlIHRoZSBwcm90b2NvbCB3 YXMgYmFkbHkgZGVzaWduZWQgc3VjaCB0aGF0IGFuIHVucmVjb2duaXplZCBjb2RlIHBvaW50IGNh dXNlcyB0aGUgcHJvdG9jb2wgYmVoYXZpb3IgdG8gYmUgdW5zcGVjaWZpZWQvdW5kZXJzcGVjaWZp ZWQgYW5kIGltcGxlbWVudGF0aW9ucyBhcmUgbGlrZWx5IHRvIGNyYXNoIGhvcnJpYmx5IChhZ2Fp biwgc29tZXRoaW5nIHRoaXMgV0cgc2hvdWxkIGF2b2lkIHdpdGggRExFUCkuDQoNCkFzIEkgaGF2 ZSBzYWlkLCB0aGVyZSBhcmUgYSByYW5nZSBvZiBleGlzdGluZyBJQU5BIGFsbG9jYXRpb24gYXBw cm9hY2hlcyB0aGF0IGNhbiBiZSB1c2VkIGluIGFuIElFVEYgcHJvdG9jb2wuDQoNCj4gV2UgbWF5 IHRoZW4gcHJvZ3Jlc3MgdG8gYW4gUkZDLiBXaGljaCBtaWdodCBiZSBleHBlcmltZW50YWwgb3Ig YSBQcm9wb3NlZCBTdGFuZGFyZCAoaXQgY291bGQgYWxzbyBiZSBpbmZvcm1hdGlvbmFsLCBidXQg SSB3b24ndCBnbyB0aGVyZSkuIE9idmlvdXNseSBpbiB0aGUgc3RhbmRhcmQgY2FzZSB3ZSBzaG91 bGQgYmUgYWJsZSB0byB1c2UgaXQgcHVibGljbHkuIEknbSBub3Qgc3VyZSB3aGF0IHRoZSBleGFj dCBydWxlcyBhcmUgaW4gdGhlIGV4cGVyaW1lbnRhbCBjYXNlLCBidXQgSSB3b3VsZCBhc3N1bWUg d2Ugc2hvdWxkIGF0IHRoZSBsZWFzdCBiZSB2ZXJ5IHdhcnkgb2YgbGV0dGluZyB0aGluZ3Mgb3V0 IG9yIG5vdCBkbyBzbyBhdCBhbGwgZGVwZW5kaW5nIG9uIHRoZSBuZXh0IHBvaW50Lg0KDQpUaGUg ZGlmZmVyZW5jZSBiZXR3ZWVuIEluZm9ybWF0aW9uYWwgUkZDIG9yIEV4cGVyaW1lbnRhbCBSRkMg c29tZXRpbWVzIHNlZW1zIHN1YnRsZS4gIElmIGEgY29kZSBwb2ludCBkZWZpbml0aW9uIG1pZ2h0 IGJlIOKAnHJpc2t54oCdIGZvciB0aGUgbmV0d29yayBoZWFsdGgsIHRoZW4g4oCcRXhwZXJpbWVu dGFs4oCdIGlzIHByZWZlcmFibGUgdG8g4oCcSW5mb3JtYXRpb25hbOKAnQ0KYW5kIHRoZSByaXNr IG91Z2h0IHRvIGJlIGNsZWFybHkgZGVzY3JpYmVkIChzZWUgTkVUQkxUKS4gIA0KDQpJbiBub24t cmlza3kgY2FzZXMsIGVpdGhlciBSRkMgc3RhdHVzIHdvdWxkIGJlIGEgcmVhc29uYWJsZSBjaG9p Y2UuDQpJbmZvcm1hdGlvbmFsIFJGQyBpcyBsaWtlbHkgYmV0dGVyIGlmIHRoZSBnb2FsIGlzIHRv IGVuY291cmFnZSBvdGhlcnMgdG8gdXNlIG9uZeKAmXMgcHJpdmF0ZSBleHRlbnNpb24uDQoNCg0K SnVzdGluICh3aXRoIHlvdXIgV0cgQ2hhaXIgSGF0IE9uLCBwbGVhc2UpOg0KDQpJZiBpdCBpcyB1 c2VmdWwsIEkgYW0gaGFwcHkgdG8gZHJhZnQgdXAgc29tZSBjYW5kaWRhdGUgSUFOQSBDb25zaWRl cmF0aW9ucw0KdGV4dCBmb3IgdGhlIGxpc3QgdG8gZXZhbHVhdGUsIG9uIHRoZSBhc3N1bXB0aW9u IHRoYXQgd2UgaW5jcmVhc2UgdGhlDQpjb2RlIHBvaW50IHNpemUgdG8gMTYtYml0cy4gIE15IHBs YW4gd291bGQgYmUgdG8gYm9ycm93IGFuZCB3b3Jkc21pdGgNCnRleHQgZnJvbSBvdGhlciBJRVRG IHN0YW5kYXJkcy10cmFjayBSRkNzIGluIGRvaW5nIHRoaXMsIG5vdCB0byB0cmVhZA0KbmV3IGdy b3VuZC4gIChUaGVyZSBpcyBubyBuZWVkIGZvciB0aGUgV0cgdG8gdHJlYWQgYW55IG5ldyBncm91 bmQgdG8gZG8gDQp3aGF0IERhdmlkIGFuZCBJIGJlbGlldmUgaXMgcmlnaHQuKQ0KDQpZb3VycywN Cg0KUmFuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVj aXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBz ZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBu b3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv bi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioK From nobody Mon Jun 22 04:00:42 2015 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 03EF21A8720; Mon, 22 Jun 2015 04:00:40 -0700 (PDT) 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 5kX3J55vqdLM; Mon, 22 Jun 2015 04:00:35 -0700 (PDT) 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 D59C51A010E; Mon, 22 Jun 2015 04:00:34 -0700 (PDT) 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; Mon, 22 Jun 2015 12:00:09 +0100 From: Rick Taylor To: Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 11:00:07 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> 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: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , MANET IETF , "manet-chairs@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 11:00:40 -0000 Hi, Just adding some replies inline... On 18/06/15 22:28, Lou Berger wrote: > Henning, > Thanks for the opinions. See below for in line response to those > topics that have to do with the review and my intent -- I'm staying away > from "WG/chair/AD" discussion topics. > > On 6/18/2015 8:38 AM, Henning Rogge wrote: >> On Mon, Jun 8, 2015 at 9:10 PM, Lou Berger wrote: >>> [Note this is a WG LC related review, not IETF LC.] >>> >>> Hello, >> Hi... >> >> I am NOT one of the DLEP authors, but I have been active during the >> design process (some people might say "annoyingly active"), so here >> are my opinions on this review. Hopefully it will be helpful for the >> authors. I am one of the authors, and I'll try to help clarify why we have gone the direction we have. >> >>> ... > >>> Major Issues: >>> >>> - The length field of the generic data item (i.e., TLV) is only 8 >>> bits. While 255 bytes (assuming that this is the unit of measur= e, >>> which BTW isn't specified) is big enough today, allowing for >>> larger will greatly simplify things when 255 isn't enough. -- >>> We've run into this in RSVP and it's a real pain. >> On the other side the largest data item we have at the moment is 18 >> bytes (IPv6 connection point). I am not really seeing lots of >> use-cases for large data items in DLEP. > > My experience in the past has been that unknown uses show up later and > make this an issue that needs to be solved by some ugly semantic > fragmentation, so if possible, I think it should be fixed. > >> Still, changing the TLV length to 16 bit would be trivial to do... but >> would this mean we also should change the signal length field to 4 >> bytes? > > I wasn't suggesting this and I don't think so. 2^16 is a pretty big > message. There is nothing stopping an extension of the data item length to 2^16 octets, but as Henning pointed out, that would suggest an increase of the signal length field to 2^32 (as signals 'contain' data items). The reason we haven't gone for 2^16 currently are: 1) We have no data items > ~20 octets. 2) We wanted to keep the data items and signals 'short and sweet' in form. An implementation could use small stack allocated buffers in embedded hardware rather than worrying about bigger blocks of memory. But: Adding big data items later would be more difficult. Note: There is no 'bits on the wire' performance concerns here, DLEP is over the local link. There is a third way: If the length field in the signal is replaced with a count field, then both can be kept at 16 bits, but it makes parsing more complicated. Can I ask for some +1/-1's from the list on this one please? It is not a major change to the document. > >>> - Version number is currently defined as a data item. This means = a >>> signal (i.e., message) needs to be potentially fully parsed to >>> discover what version is being used. This precludes basic forma= t >>> changes to the protocol. Perhaps the Discovery and Init Signals >>> should be special cased to include version in their formats. (A= nd >>> shorten version to 8 bits from 32, as mentioned below). >> Putting it into the UDP based discovery packets as a "header" could >> work... they are a bit special anyways (UDP) and we don't need to >> repeat the version later. > > Lots of options here. But recall UDP discovery is optional per current sp= ec. I see no problem with shortening version to 16 bits (major octet, minor octet) I never want to see DLEP version 65538.0! I see the point of holding the version number at a fixed offset in the initial messages of the protocol, and it is something we can definitely do for the UDP discovery messages, as Henning pointed out, they are special anyway. I am loathe to do it to the Initialization signals, as it adds special case code and text. I think it is okay to allow an implementation *not* using discovery to expect a process on the reserved address/port combination to be using some version of DLEP, as long as later DLEP versions ensure back compatibility. > >> >>> - The document references, but does not define, 'in-session' and >>> 'discovery' states. These either need to be formally defined or >>> removed. BTW we had exactly the same issue with LMP (RFC4204) a= nd >>> ended up adding section 11 (FSMs) at a pretty late stage of the >>> process. >> I think "discovery phase" is before the TCP connection between radio >> and router is established. > > Sure, but the point I was making there's a difference between > unambiguously specifying something that can be independently implemented > by someone not involved in the WG vs a common understanding in the WG > based on discussion while the spec is developed. The challenge is > ensuring the document (the former) adequately captures the latter. Fair point. We will revisit the text about states. > >> >>> - TCP session management is not defined, nor is the relationship >>> with TCP and DLEP sessions fully defined. For example: >>> >>> o Closing the TCP session is only mentioned in one place and in = a >>> way that is inconsistent with the expected protocol behavior >>> (close TCP before ACK is received). >> Maybe this should be "closing the DLEP session and not using the >> active TCP session anymore" ? >> >>> o What happens when a DLEP session is terminated, can the TCP >>> session be reused or must it be closed too? >> No, I think the DLEP strategy is "start from scratch"... when you >> terminate a DLEP session you go back to the discovery mechanism to >> start a new one. > > Whichever reasonable approach is taken it just needs to be explicitly > documented. We favour a start from scratch approach. But it does need to explicitly stated somewhere. > >> >>> - There is no transaction model defined. For example, it's >>> completely unclear if only one unacknowledged Signal allowed at = a >>> time, or perhaps just one per signal type is allowed, or perhaps >>> there are no restrictions. This needs to be explicit. >> I think we don't need restrictions here because of TCP. The other side >> WILL answer to eachof our signals or the TCP session will be >> terminated. > > I don't think TCP helps (or hurts here). This is a question of what > different implementations will choose to do / support WRT signals of the > same or different types being processed in parallel. Particularly with the Request signals, there is a weakness in the text about transactions that needs to be addressed. This is one of those areas where those involved early on have a clear idea, but it isn't clear in the text. > >>> - What is the purpose of retries and timeouts over TCP? Retries >>> aren't needed over TCPs and it's unclear whey they are being use= d. >> We want to know when the connection between radio and router is >> lost... this can take a LONG time when the router is mostly listening >> to the Radio (TCP timeout is much to long for our use-case), so we use >> the Heartbeats. > > This comment relates to the per signal acks and retries. I didn't > include the connection failure detection covered by the heartbeat signal > in this comment. The retries and heartbeats are to detect a failure in the process using the TCP connection, rather than a failure of the connection itself. From experience in the MANET space, complex routers and radios can crash internally/lose control plane long before the TCP session times out. > >>> - The higher level implications of ACKs, over TCP, isn't really >>> clear. It seems ACKs are defined for multiple purposes: reliabl= e >>> transport, transaction acknowledgment and transaction results. O= f >>> course the first isn't needed, and implications of the others >>> should be clear. For example, in section 7.10, why would there = be >>> a retry when receiving a Destination Up ACK signal indicating an >>> error? >> The DLEP "ACK Signals" are more a response to a "request signal"... >> transaction acknowledgement and result. ACKs are intended as an processing acknowledgement rather than a receipt acknowledgement, i.e. "I have done/not done what you asked". >> >>> - There is no discussion on scaling considerations. Are there real= ly >>> none? For example, how often might be appropriate to issue/limi= t >>> Peer Updates based to changes in link quality, or how to handle >>> the case where a large number (all or most) of destinations go >>> down. >> Just send as fast as you want and let TCP (buffer) take care of the >> rest... both Destination up/down are small signals, so it shouldn't be >> a problem. > The assumptions behind this "shouldn't part of this" is what should be > discussed... Yes, there is no text about rate limiting updates. Not from a TCP datarate perspective, but from a processing perspective. We don't really want to predict the performance of processors by stating hard rules on rate-limiting. This only applies to Destination_Updates, as everything else is throttled by waiting for ACKs. (Made clearer when some text on transactions is put in) > >> And you are only allowed to send Destination Updates when >> you received the Destination ACK. > > Where is this restriction specified? I don't recall seeing it. It isn't mentioned, but is expected. The text will have to be improved. I think there is a need for a section on transactions. > >>> - There are 13 places where the protocol allows implementation to >>> define their own 'heuristics'. Some of these seem unnecessary d= ue >>> to the TCP point raised above, but any that remain in the protoc= ol >>> should be fully specified to ensure predictable/consistent >>> behavior from implementations. >> No comment on this one. As with rate-limiting, this is a can of worms we have intentionally not opened. We will have a careful look at every place heuristics are mentioned and when possible suggest some sensible defaults. >> >>> - Data Items are defined for "Extensions" and "Experimental >>> Definition" (Sections 8.7 and 8.8). Both seem to support for >>> optional mechanisms, but the former uses assigned numeric values= , >>> why the latter uses UTF-8 strings. >>> o What, if any, is the intended distinction/relationship between >>> these? >>> o How does an "Experimental Definition" become standardized? >> As far as I understand this "Experimental Definition" is something you >> use in the lab... you can have a maximum of one experiment for DLEP, > Interesting -- where is this restriction defined? Section 7.3 says > that "one or more" are allowed. > >> so this is more to make sure your special "work in progress" code does >> not collide too hard with a standard radio/router. > It's pretty unclear from the spec how experimental definitions are to be > used -- or if they belong in standards track document at all. > >> On the other side you can support as many "Extensions" as you want... >> and I expect this WG to standardize a few additional of them after >> DLEP becomes a RFC. > okay, look forward to seeing an IANA allocation policy for these. I have covered this in another mail, so I won't repeat. (see Section 11.6) > >> >>> - Sections 8.19 and 8.20 define "Resources" related Data Items. T= he >>> definition related to these basically says a resources is "An >>> 8-bit integer percentage, 0-100, representing the amount of >>> resources allocated to receiving|transmitting data.". If I were >>> implementing this protocol, I'd have no idea how to produce, >>> update or use this information. I think there is some missing >>> informative and normative (RFC 2119) text related to these >>> formats. >> My only idea about them would be "battery level"... not sure how >> useful it is to query the radio about this. > > some context would be great. -- sounds like its akin to a routing metric= . > >>> - Sections 8.21 and 8.22 (Relative Link Quality) have a similar >>> problem of being under described, in particular it's unclear if >>> there's a meaningful, non-proprietary definition for link qualit= y >>> that an implementation is to act on or if the passed value is ju= st >>> passed for as monitoring information. Either way, this needs to >>> be clarified. >> It seems the radio vendors really like this field. The reason why we >> made "max/current link speed" mandatory is to make RLQ at least >> reasonable useful. > same comment. The Resources and RLQ metrics are there as DLEP builds upon the work done in RFC5578. I have always considered Resources to be some indication of 'work-load' on the modem rather than explicit battery level. Perhaps the descriptive text needs to be expanded. >>> - Section 9 defines a "credit-windowing scheme analogous to the on= e >>> documented in [RFC5578]". It describes how credits are exchanged= , >>> but it provides zero definition on the implications or use of >>> credits relative to the data plane. >>> >> No comment on this one. This is one for Stan. Credit-windowing is his baby. >> >>> - Multiple ways to implement the same function are allowed, e.g., >>> optional presence of Status, Interval and TCP port. Generally >>> allowing such complicates testing and leads to interoperability >>> issues. The document should pick one way and require it. >> I think "no status TLV" is always "everything is fine"... We are currently happy with the way this works. If an optional data item is missing, then the default value is used. This should be explicitly stated whenever an optional data item can be omitted. >> >>> - The document doesn't state if there are any ordering requirement= s >>> on data items. It should be explicit on this, e.g., there are no >>> ordering requirements on the placement of Data Items within >>> Signals. >> I think is exactly as most (all?) of us have implemented it... no >> ordering required. > > Cool, then this is just a simple matter of documenting "what everyone > implements". Section 6 states: "There is no restriction on the order of data items following a signal" > >>> - The required and optional data items that are permitted on a >>> signal isn't always clear. For example are 0/1/N copies of a >>> particular Data Item required/allowed. Using something like ABN= F >>> would really help formalize and clarify this. >> Can you give an example where this is undefined? As far as I can see >> the draft explicitly states what and how often you can use TLVs per >> signal. > > I think the experimental data item discussion above is a perfect > example. You though only one is allowed the spec is vague in section > 8.8 and explicit in 7.3. -- Narrative lacks precision and is easily > misread. Something like ABNF is far more transparent. Section 6 states: "...the multiplicity of duplicate data items is defined by the definition of the signal declared by the type in the signal header." We have attempted to enumerate the multiplicity of every data item in each signal. If we have missed one please point it out. Section 3.3 states: "Multiple Experimental Definition data items MAY appear in the Peer Initialization/Peer Initialization ACK sequence." I have tried to define ABNF, but I struggle with defining the multiplicity and optional ordering rules, any advice gratefully received. > >>> - The document doesn't clearly delineate from informative/narrativ= e >>> text, normative / required processing procedures, and message >>> formats. This by itself is not necessarily a major issue, it jus= t >>> makes it harder to (write,) review and implement the protocol. >>> What is a major issue is that this approach allows for duplicate >>> (and sometimes contradictory) normative procedures and for >>> omissions in procedures (particularly related to exception/error >>> processing). Specific examples are included above and below. I= t >>> would be best to ensure that each required processing behavior i= s >>> defined just once and in a consistent way. This is a hangover of the major rewrites that have occurred over the last 14 versions. Let us have another pass at the text and we can see what we can do. >>> >>> - The security consideration section is inadequate. This section >>> should address the security of the DLEP protocol, not user >>> traffic. It should include an analysis of risks/threats/possibl= e >>> exploits and how these are mitigated by the protocol. rfc6952, >>> and the protocols it references can serve as examples. >> DLEP is only on the local ethernet connection between the radio and >> the router... it is NOT spoken between different router/radio >> components of a network. RFC6952 is talking about securing >> communication over the routed network. > > This is a scoping of the problem that should go into a security the > section. RFC4204 covers a similar scoped protocol, although it's > security considerations section is quite dated. We have done no analysis of a malicious peer in a DLEP session as the nature of the link-local connectivity made it seem unnecessary. Are you suggesting that we need to address this? > >> >>> Minor Issues: >>> >>> - The data and signal type fields are both 8 bits. This seems >>> pretty small, particularly the data type field. Given this is a >>> control protocol, I think a larger (at least data type) field >>> would provide better "future proofing". >> So you would like to move BOTH the type and the length fields of the >> TLVs to 16 bit? > I'd probably enlarge data items and leave signal type alone. > Alternatively you can plan to do something ugly down the road, like type > 255 means look in value field for an extended type field - yuck. See comments above. > >> >>> - 2^32 versions are currently allowed (section 8.1). This seems a >>> bit excessive. I'd opt for max of 8 bits here myself. >> Most likely 8 bits are enough, especially because I would expect the >> version number to become "fixed" after the RFC release. > That would be great. See comments above. > >>> - It's probably too late, but it probably would be cleaner to have= a >>> generic ack signal rather than a per signal type ack. I mention >>> this here as this may come up again when clarifying the >>> transaction model (as mentioned above.) >> could be... but I am not sure about the advantage of moving the "ack >> type" into a TLV. > This would be a really major change at this juncture, as this is a > "minor comment" I didn't really expect for it to be changed at this late > date -- so no need to debate. We have debated this before, and the multiple ACKs approach is preferred by the WG. > >>> - Section 2: Assumptions >>> This section includes informative and normative text so is more >>> than just Assumptions. Personally, I'd remove all normative tex= t >>> from the section. >>> >>> - There are no specific rules related to UDP header formation. >> UDP header formation? > format. I.e., what addresses and ports must be used. > Does Section 5.1 not cover this? >> >>> - Sections 8.10->8.17. Isn't add/drop indicator needed for subnet= s >>> in destination update signals? >> I think we talked about this and the reason was that subnets are only >> as "fixed settings" supported. > I'm sorry I don't understand your response. Are you saying subnet > reconfiguration requires a session reset? Subnet reconfiguration requires a session restart. > >>> - The IANA Considerations sections must follow RFC2360. >>> - New registries must include initial values, which are defined in >>> the document. (The document currently has many TBDs that should >>> be replaced.) >> I didn't know about this, I have always seen Drafts with TBDx... > > TBD is right for existing registries. For new registries IANA doesn't > have any policies or guidance. This comes from the document that > establish the registries, i.e, this one. We shall suggest some values. Probably from the existing interoperable implementations. > >> >>> - New registries need an allocation policy, e.g.: >>> The registry should be established with registration policies of >>> "Standards Action" (for Standards Track documents) and >>> "Specification Required" (for other documents). The designated >>> expert is any current WG chair. This is one for Stan. >>> >>> Nits: >>> >>> - The document introduces the terms "signals" and "data items" for >>> what is commonly called "messages" and "TLVs" (or objects) in >>> other protocols. It's probably too late to change this, but I >>> think the introduction of unique terminology is counter >>> productive TLVs was rejected as a name, as both signals and data items are Type-Length-Value encoded. Signals was selected as they are 'events' rather than RPCs, and it might be a bit late to change the terminology. >>> >>> - Use of RFC 2119 conformance language is a bit rough, and there a= re >>> words in all caps that are not defined in RFC2119. Take a look a= t >>> http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuideline for som= e >>> suggestions. We will have another pass. Can you point out some examples please? >>> >>> - Internal socket operation is mentioned a couple of times. It >>> really shouldn't be, the spec should define behavior on the wire= . >> Not sure what you mean... > This is a specification of behavior "on the wire" . It should be > possible to implement in an OS that doesn't implement sockets but > properly conforms to the spec. Okay, this can be fixed if we add a section about re-use of the TCP connection (don't). > >>> - The Length fields are missing unit of measure (presumably octets= ) >> Yes, octets. Yes, octets, will add. >> >>> - The Mnemonics are used basically once and don't really add value= , >>> suggest dropping them. With the replacement of TBDs with values these should 'boil off'. >>> >>> - How/when is the "Unknown Signal" Status Code sent? >> I would guess attached to a "Peer Termination" Signal... the other >> side sent us something we don't understand. That was the intention. I will check the text to make sure this is clear. >> >>> - Section 8.7: Extension List should be shown as a variable length >>> field. >>> >>> - Section 8.8: Experiment List should be shown as a variable lengt= h >>> field. >> You mean a "..." in the ascii art? > yes. ... will be added. Hope that helps? Rick From nobody Mon Jun 22 04:24:57 2015 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 1CD101B2F7D; Mon, 22 Jun 2015 04:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 E4ETlnoHvqsM; Mon, 22 Jun 2015 04:24:55 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80951B2F75; Mon, 22 Jun 2015 04:24:53 -0700 (PDT) Received: by wiwl6 with SMTP id l6so33928922wiw.0; Mon, 22 Jun 2015 04:24:49 -0700 (PDT) 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=7VdglUiIHRALsDN2leA6PslNlAaN6yqc/gDqO68M/pA=; b=Nwf3a7HxPpz1FgturOk1iwvMoW12UyxUv6ACeCFd8s4D45FrFhfLSnPuZRoOWeaYS5 vM1RY/ExafPayX5hG8nWWZzsk5dmcA1jzHtSyDMe7l/A/QFw8ClxvEcKkrRvym+XzjpJ mi08oV/KTYXuAedMtFzdg9T/unBPlPsJ1DKCXX1Sik+nNpfi/pQ80muKqEDhQTxi2O+0 Vwf28O1Ls52q/DIDfCM7UBMkaGQtyHVzFdq2ecDSOaI/C1IV7na7icHiPupkJNqN9gv3 ih6Ep+pEqY3Y20BFgCwJTXc6nMODIWbIZoNz1QbixclmKQR7sGJMG9Ag2Fj70BraqXVW ja5g== X-Received: by 10.194.250.98 with SMTP id zb2mr51101797wjc.90.1434972289521; Mon, 22 Jun 2015 04:24:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Mon, 22 Jun 2015 04:24:29 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 22 Jun 2015 13:24:29 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtg-dir@ietf.org" , "manet-chairs@ietf.org" , "manet-ads@ietf.org" , MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" , Lou Berger Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 11:24:57 -0000 On Mon, Jun 22, 2015 at 1:00 PM, Rick Taylor wrote: >> Lots of options here. But recall UDP discovery is optional per current spec. > > I see no problem with shortening version to 16 bits (major octet, minor > octet) I never want to see DLEP version 65538.0! > > I see the point of holding the version number at a fixed offset in the > initial messages of the protocol, and it is something we can definitely > do for the UDP discovery messages, as Henning pointed out, they are > special anyway. > > I am loathe to do it to the Initialization signals, as it adds special > case code and text. I think it is okay to allow an implementation *not* > using discovery to expect a process on the reserved address/port > combination to be using some version of DLEP, as long as later DLEP > versions ensure back compatibility. We could maybe define that both for TCP and UDP the first two bytes are a version number... after this we begin decoding signals/tlvs. This sounds reasonable easy and consistent. Henning Rogge From nobody Mon Jun 22 05:11:56 2015 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 A7AC31A039B for ; Mon, 22 Jun 2015 05:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 BTpY6QkLcuPF for ; Mon, 22 Jun 2015 05:11:54 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 7D0DB1A01EA for ; Mon, 22 Jun 2015 05:11:52 -0700 (PDT) Received: (qmail 21909 invoked by uid 0); 22 Jun 2015 12:11:49 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 22 Jun 2015 12:11:49 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id jW4t1q0052SSUrH01W4wd6; Mon, 22 Jun 2015 12:04:56 -0600 X-Authority-Analysis: v=2.1 cv=VdVkYjZ9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=et3v_JSy4e0A:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=AqI0xvK1tnMA:10 a=XAFQembCKUMA:10 a=pGLkceISAAAA:8 a=5vjwwrbCAAAA:8 a=q2ZXapiU9vaECIwNIsAA:9 a=DvyPnj-p3lvvgXBM:21 a=9ywHbMqrE65duSKy:21 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=TZxrBFUesNAqh2rO5S9s6JVPBA0TgW+gphkmflBdamE=; b=q53CcXzVp6hC4cGgihbkYP3L9Q+X8ndk6wyfSJ250wtrUEDrnkpbxxy0bnruT0lTfXCHHZxT3Y5kSLci8L/oJZyV0/F0dDfwwe1D6gH+gCVJzp3x++GvlcyFc/ygXUn2; Received: from [74.96.190.213] (port=53825 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Z70Zl-0002TD-BZ; Mon, 22 Jun 2015 06:11:45 -0600 From: Lou Berger To: Henning Rogge , Rick Taylor Date: Mon, 22 Jun 2015 08:11:43 -0400 Message-ID: <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.7.21 (build: 21070086) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 74.96.190.213 authed with lberger@labn.net} Archived-At: Cc: manet-ads@ietf.org, rtg-dir@ietf.org, MANET IETF , manet-chairs@ietf.org, draft-ietf-manet-dlep.all@ietf.org Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 12:11:54 -0000 I have a really hard time understanding how there could be 2^16 interoperable versions of anything. But maybe dlep means something different than the norm when refering to versions. Can you/some explain a use case for more than a few, being really generious say 10, version numbers? Lou On June 22, 2015 7:25:13 AM Henning Rogge wrote: > On Mon, Jun 22, 2015 at 1:00 PM, Rick Taylor > wrote: > >> Lots of options here. But recall UDP discovery is optional per current spec. > > > > I see no problem with shortening version to 16 bits (major octet, minor > > octet) I never want to see DLEP version 65538.0! > > > > I see the point of holding the version number at a fixed offset in the > > initial messages of the protocol, and it is something we can definitely > > do for the UDP discovery messages, as Henning pointed out, they are > > special anyway. > > > > I am loathe to do it to the Initialization signals, as it adds special > > case code and text. I think it is okay to allow an implementation *not* > > using discovery to expect a process on the reserved address/port > > combination to be using some version of DLEP, as long as later DLEP > > versions ensure back compatibility. > > We could maybe define that both for TCP and UDP the first two bytes > are a version number... after this we begin decoding signals/tlvs. > > This sounds reasonable easy and consistent. > > Henning Rogge > From nobody Mon Jun 22 05:19:33 2015 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 D8C111A03F9; Mon, 22 Jun 2015 05:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001, 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 mQT9eiX41DyW; Mon, 22 Jun 2015 05:19:30 -0700 (PDT) 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 7DDAC1A0368; Mon, 22 Jun 2015 05:19:29 -0700 (PDT) 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; Mon, 22 Jun 2015 13:19:04 +0100 From: Rick Taylor To: Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 12:19:02 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 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: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , MANET IETF , "manet-chairs@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 12:19:31 -0000 Okay, with a 4bit/4bit split of a single octet, we have 0-15 major =0A= versions and 0-15 minor versions.=0A= =0A= We already have implementations on version 0.14, and with a draft-15 =0A= expected, do you suggest a 3bit/5bit split? Why not just use =0A= major.minor 8bits each? We don't have to worry about bytes over the =0A= local link.=0A= =0A= Cheers,=0A= =0A= Rick=0A= =0A= =0A= On 22/06/15 13:11, Lou Berger wrote:=0A= > I have a really hard time understanding how there could be 2^16=0A= > interoperable versions of anything. But maybe dlep means something=0A= > different than the norm when refering to versions.=0A= >=0A= > Can you/some explain a use case for more than a few, being really generio= us=0A= > say 10, version numbers?=0A= >=0A= > Lou=0A= >=0A= >=0A= > On June 22, 2015 7:25:13 AM Henning Rogge wrote:=0A= >=0A= >> On Mon, Jun 22, 2015 at 1:00 PM, Rick Taylor=0A= >> wrote:=0A= >>>> Lots of options here. But recall UDP discovery is optional per current= spec.=0A= >>>=0A= >>> I see no problem with shortening version to 16 bits (major octet, minor= =0A= >>> octet) I never want to see DLEP version 65538.0!=0A= >>>=0A= >>> I see the point of holding the version number at a fixed offset in the= =0A= >>> initial messages of the protocol, and it is something we can definitely= =0A= >>> do for the UDP discovery messages, as Henning pointed out, they are=0A= >>> special anyway.=0A= >>>=0A= >>> I am loathe to do it to the Initialization signals, as it adds special= =0A= >>> case code and text. I think it is okay to allow an implementation *not= *=0A= >>> using discovery to expect a process on the reserved address/port=0A= >>> combination to be using some version of DLEP, as long as later DLEP=0A= >>> versions ensure back compatibility.=0A= >>=0A= >> We could maybe define that both for TCP and UDP the first two bytes=0A= >> are a version number... after this we begin decoding signals/tlvs.=0A= >>=0A= >> This sounds reasonable easy and consistent.=0A= >>=0A= >> Henning Rogge=0A= >>=0A= >=0A= >=0A= >=0A= =0A= From nobody Mon Jun 22 05:26:26 2015 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 5D17A1A1A8B; Mon, 22 Jun 2015 05:26:23 -0700 (PDT) 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 t-DTU_x_EpGn; Mon, 22 Jun 2015 05:26:22 -0700 (PDT) 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 DE8CA1A1A76; Mon, 22 Jun 2015 05:26:21 -0700 (PDT) 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; Mon, 22 Jun 2015 13:25:57 +0100 From: Rick Taylor To: Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 12:25:54 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AD850@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@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: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" , MANET IETF , "manet-chairs@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 12:26:23 -0000 Oops, misread a bit, comments inline...=0A= =0A= On 22/06/15 12:00, Rick Taylor wrote:=0A= > On 18/06/15 22:28, Lou Berger wrote:=0A= >> On 6/18/2015 8:38 AM, Henning Rogge wrote:=0A= >>> On Mon, Jun 8, 2015 at 9:10 PM, Lou Berger wrote:=0A= >>>> Minor Issues:=0A= >>>>=0A= >>>> - The data and signal type fields are both 8 bits. This seems= =0A= >>>> pretty small, particularly the data type field. Given this is= a=0A= >>>> control protocol, I think a larger (at least data type) field= =0A= >>>> would provide better "future proofing".=0A= >>> So you would like to move BOTH the type and the length fields of the=0A= >>> TLVs to 16 bit?=0A= >> I'd probably enlarge data items and leave signal type alone.=0A= >> Alternatively you can plan to do something ugly down the road, like type= =0A= >> 255 means look in value field for an extended type field - yuck.=0A= >=0A= > See comments above.=0A= =0A= I misread this as length field as 16bit. I have no problem with a 16bit = =0A= signal/data item id, as it would allow more space for experimental =0A= assignments. But, we have yet to use more than 23 ids.=0A= =0A= Rick=0A= From nobody Mon Jun 22 05:29:14 2015 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 A82811A1AE8 for ; Mon, 22 Jun 2015 05:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 VIuy4_xIyfMw for ; Mon, 22 Jun 2015 05:29:11 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id B0D721A1ACC for ; Mon, 22 Jun 2015 05:29:11 -0700 (PDT) Received: (qmail 9599 invoked by uid 0); 22 Jun 2015 12:29:11 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 22 Jun 2015 12:29:11 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id jWMw1q00a2SSUrH01WMzH2; Mon, 22 Jun 2015 12:22:00 -0600 X-Authority-Analysis: v=2.1 cv=auUhV0pV c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=et3v_JSy4e0A:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=AqI0xvK1tnMA:10 a=XAFQembCKUMA:10 a=5vjwwrbCAAAA:8 a=pGLkceISAAAA:8 a=8oP1HsYsRD_YW80AfBsA:9 a=EwVFPFRzHEZMrhHp:21 a=4rIbPk5XIaffsgT_:21 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=GeZWcnH9yHutDbX0xmgivfD+BHpLXuI521EM0VxwkR8=; b=F+gzZtTRpV6Q/KZYRZg9x2KH3evV5c9kWAAcliT4tJmU2k5tIXjP9JycjjJtSq5K+fslH7sI67TmIMkGV1PyrE7FPKfh7M+tBDhmbGqXCi3KINLhPI4r9kDb7F5EPbr/; Received: from [74.96.190.213] (port=53833 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Z70qZ-0005Ld-G4; Mon, 22 Jun 2015 06:29:07 -0600 From: Lou Berger To: Rick Taylor , Henning Rogge Date: Mon, 22 Jun 2015 08:29:05 -0400 Message-ID: <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.7.21 (build: 21070086) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 74.96.190.213 authed with lberger@labn.net} Archived-At: Cc: manet-ads@ietf.org, rtg-dir@ietf.org, MANET IETF , manet-chairs@ietf.org, draft-ietf-manet-dlep.all@ietf.org Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 12:29:12 -0000 On June 22, 2015 8:19:32 AM Rick Taylor wrote: > Okay, with a 4bit/4bit split of a single octet, we have 0-15 major > versions and 0-15 minor versions. > > We already have implementations on version 0.14, and with a draft-15 > expected, do you suggest a 3bit/5bit split? This is in fact a unique (at least in my experience ) usage of version. IMO the dlep version for the RFCed version would be 1. > Why not just use > major.minor 8bits each? We don't have to worry about bytes over the > local link. Yes, but you do need to worry about interoperability. If the WG really wants to go down this path, you'll need some tight text defining how versioning and version mismatches are handled. Lou > > Cheers, > > Rick > > > On 22/06/15 13:11, Lou Berger wrote: > > I have a really hard time understanding how there could be 2^16 > > interoperable versions of anything. But maybe dlep means something > > different than the norm when refering to versions. > > > > Can you/some explain a use case for more than a few, being really generious > > say 10, version numbers? > > > > Lou > > > > > > On June 22, 2015 7:25:13 AM Henning Rogge wrote: > > > >> On Mon, Jun 22, 2015 at 1:00 PM, Rick Taylor > >> wrote: > >>>> Lots of options here. But recall UDP discovery is optional per current > spec. > >>> > >>> I see no problem with shortening version to 16 bits (major octet, minor > >>> octet) I never want to see DLEP version 65538.0! > >>> > >>> I see the point of holding the version number at a fixed offset in the > >>> initial messages of the protocol, and it is something we can definitely > >>> do for the UDP discovery messages, as Henning pointed out, they are > >>> special anyway. > >>> > >>> I am loathe to do it to the Initialization signals, as it adds special > >>> case code and text. I think it is okay to allow an implementation *not* > >>> using discovery to expect a process on the reserved address/port > >>> combination to be using some version of DLEP, as long as later DLEP > >>> versions ensure back compatibility. > >> > >> We could maybe define that both for TCP and UDP the first two bytes > >> are a version number... after this we begin decoding signals/tlvs. > >> > >> This sounds reasonable easy and consistent. > >> > >> Henning Rogge > >> > > > > > > > > From nobody Mon Jun 22 05:36:37 2015 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 B50411A1B6E; Mon, 22 Jun 2015 05:36:35 -0700 (PDT) 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 p0JD1EN7t0IU; Mon, 22 Jun 2015 05:36:34 -0700 (PDT) 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 1A7A51A1B69; Mon, 22 Jun 2015 05:36:34 -0700 (PDT) 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; Mon, 22 Jun 2015 13:36:10 +0100 From: Rick Taylor To: Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 12:36:08 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@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: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" , MANET IETF , "manet-chairs@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 12:36:35 -0000 Comments inline...=0A= =0A= >=0A= > On 22/06/15 13:11, Lou Berger wrote:=0A= >> I have a really hard time understanding how there could be 2^16=0A= >> interoperable versions of anything. But maybe dlep means something=0A= >> different than the norm when refering to versions.=0A= >>=0A= >> Can you/some explain a use case for more than a few, being really generi= ous=0A= >> say 10, version numbers?=0A= >>=0A= >> Lou=0A= >>=0A= >>=0A= >> On June 22, 2015 7:25:13 AM Henning Rogge wrote:=0A= >>=0A= >>> On Mon, Jun 22, 2015 at 1:00 PM, Rick Taylor=0A= >>> wrote:=0A= >>>>> Lots of options here. But recall UDP discovery is optional per curren= t spec.=0A= >>>>=0A= >>>> I see no problem with shortening version to 16 bits (major octet, mino= r=0A= >>>> octet) I never want to see DLEP version 65538.0!=0A= >>>>=0A= >>>> I see the point of holding the version number at a fixed offset in the= =0A= >>>> initial messages of the protocol, and it is something we can definitel= y=0A= >>>> do for the UDP discovery messages, as Henning pointed out, they are=0A= >>>> special anyway.=0A= >>>>=0A= >>>> I am loathe to do it to the Initialization signals, as it adds special= =0A= >>>> case code and text. I think it is okay to allow an implementation *no= t*=0A= >>>> using discovery to expect a process on the reserved address/port=0A= >>>> combination to be using some version of DLEP, as long as later DLEP=0A= >>>> versions ensure back compatibility.=0A= >>>=0A= >>> We could maybe define that both for TCP and UDP the first two bytes=0A= >>> are a version number... after this we begin decoding signals/tlvs.=0A= >>>=0A= >>> This sounds reasonable easy and consistent.=0A= =0A= This sounds like a suggestion that the Peer_Init signals should use a =0A= different header.=0A= =0A= Given there are data items that are only used during initialization, =0A= would people be totally against a different wire format for these =0A= packets rather than the signal format?=0A= =0A= Rick=0A= =0A= =0A= From nobody Mon Jun 22 05:39:07 2015 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 28C731A1BCB; Mon, 22 Jun 2015 05:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001, 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 RkIdPsq2IfWE; Mon, 22 Jun 2015 05:39:04 -0700 (PDT) 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 B524E1A1B81; Mon, 22 Jun 2015 05:39:03 -0700 (PDT) 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; Mon, 22 Jun 2015 13:38:40 +0100 From: Rick Taylor To: Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 12:38:39 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 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: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , MANET IETF , "manet-chairs@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 12:39:05 -0000 Okay, I see your point - I have spent too long working with FOSS =0A= software where everything lurks at version 0.97 ;)=0A= =0A= If the WG are happy with a single octet of 1 for the final 'first' =0A= version, then that's good by me.=0A= =0A= +1/-1 please people!=0A= =0A= Rick=0A= =0A= On 22/06/15 13:29, Lou Berger wrote:=0A= >=0A= >=0A= > On June 22, 2015 8:19:32 AM Rick Taylor = wrote:=0A= >=0A= >> Okay, with a 4bit/4bit split of a single octet, we have 0-15 major=0A= >> versions and 0-15 minor versions.=0A= >>=0A= >> We already have implementations on version 0.14, and with a draft-15=0A= >> expected, do you suggest a 3bit/5bit split?=0A= >=0A= > This is in fact a unique (at least in my experience ) usage of version.= =0A= > IMO the dlep version for the RFCed version would be 1.=0A= >=0A= >> Why not just use=0A= >> major.minor 8bits each? We don't have to worry about bytes over the=0A= >> local link.=0A= >=0A= > Yes, but you do need to worry about interoperability. If the WG really= =0A= > wants to go down this path, you'll need some tight text defining how=0A= > versioning and version mismatches are handled.=0A= >=0A= > Lou=0A= >>=0A= >> Cheers,=0A= >>=0A= >> Rick=0A= >>=0A= >>=0A= >> On 22/06/15 13:11, Lou Berger wrote:=0A= >>> I have a really hard time understanding how there could be 2^16=0A= >>> interoperable versions of anything. But maybe dlep means something=0A= >>> different than the norm when refering to versions.=0A= >>>=0A= >>> Can you/some explain a use case for more than a few, being really gener= ious=0A= >>> say 10, version numbers?=0A= >>>=0A= >>> Lou=0A= >>>=0A= >>>=0A= >>> On June 22, 2015 7:25:13 AM Henning Rogge wrote:=0A= >>>=0A= >>>> On Mon, Jun 22, 2015 at 1:00 PM, Rick Taylor=0A= >>>> wrote:=0A= >>>>>> Lots of options here. But recall UDP discovery is optional per curre= nt=0A= >> spec.=0A= >>>>>=0A= >>>>> I see no problem with shortening version to 16 bits (major octet, min= or=0A= >>>>> octet) I never want to see DLEP version 65538.0!=0A= >>>>>=0A= >>>>> I see the point of holding the version number at a fixed offset in th= e=0A= >>>>> initial messages of the protocol, and it is something we can definite= ly=0A= >>>>> do for the UDP discovery messages, as Henning pointed out, they are= =0A= >>>>> special anyway.=0A= >>>>>=0A= >>>>> I am loathe to do it to the Initialization signals, as it adds specia= l=0A= >>>>> case code and text. I think it is okay to allow an implementation *n= ot*=0A= >>>>> using discovery to expect a process on the reserved address/port=0A= >>>>> combination to be using some version of DLEP, as long as later DLEP= =0A= >>>>> versions ensure back compatibility.=0A= >>>>=0A= >>>> We could maybe define that both for TCP and UDP the first two bytes=0A= >>>> are a version number... after this we begin decoding signals/tlvs.=0A= >>>>=0A= >>>> This sounds reasonable easy and consistent.=0A= >>>>=0A= >>>> Henning Rogge=0A= >>>>=0A= >>>=0A= >>>=0A= >>>=0A= >>=0A= >>=0A= >=0A= >=0A= >=0A= =0A= From nobody Mon Jun 22 05:44:21 2015 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 3F2901A1EEE for ; Mon, 22 Jun 2015 05:44:20 -0700 (PDT) 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 6FZYe-Su5x47 for ; Mon, 22 Jun 2015 05:44:18 -0700 (PDT) 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 CF4141A1BFA for ; Mon, 22 Jun 2015 05:44:17 -0700 (PDT) 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; Mon, 22 Jun 2015 13:43:52 +0100 From: Rick Taylor To: Henning Rogge , "MATTY, Steven" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 12:43:51 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AD982@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> 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: Cc: MANET IETF , Lou Berger Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 12:44:20 -0000 I've always tried to explain RLQ as a measure of link stability.=0A= =0A= I mean that in the world of very smart radios, two links may both be =0A= reported as having the same bandwidth and latency, but one link is =0A= operating right at the edge of its performance envelope and may suddenly = =0A= degrade rapidly, whilst the other is happy and stable.=0A= =0A= This is best reflected with a differing RLQs, one low, one high.=0A= =0A= The main reason for not renaming this metric as Relative Link Stability =0A= is simply the RFC5578 heritage.=0A= =0A= Rick=0A= =0A= =0A= On 18/06/15 14:10, Henning Rogge wrote:=0A= > On Thu, Jun 18, 2015 at 3:02 PM, MATTY, Steven=0A= > wrote:=0A= >> Apologies for hijacking your reply a little Henning, but I thought I cou= ld chime=0A= >> in on a couple of points from a radio vendor point of view!=0A= >=0A= > Good to get more input directly from Radio vendors!=0A= >=0A= >>>> - Sections 8.19 and 8.20 define "Resources" related Data Items. = The=0A= >>>> definition related to these basically says a resources is "An= =0A= >>>> 8-bit integer percentage, 0-100, representing the amount of=0A= >>>> resources allocated to receiving|transmitting data.". If I wer= e=0A= >>>> implementing this protocol, I'd have no idea how to produce,=0A= >>>> update or use this information. I think there is some missing= =0A= >>>> informative and normative (RFC 2119) text related to these=0A= >>>> formats.=0A= >>>=0A= >>> My only idea about them would be "battery level"... not sure how=0A= >>> useful it is to query the radio about this.=0A= >>=0A= >> Whilst a destination route may be up and currently the preferred choice,= =0A= >> if it's resources are degrading or approaching zero, the router may be= =0A= >> able to make an informed decision to find an alternate route before said= =0A= >> route disappears. This would be preferable to waiting for a heartbeat=0A= >> timeout.=0A= >=0A= > Yes, that was my line of thought too... use the "battery level" to=0A= > define the RLQ... then use the RLQ for the "MPR priority" (as an=0A= > OLSRv2 example) or just to make links more expensive when battery=0A= > becomes an issue.=0A= >=0A= >>>> - Sections 8.21 and 8.22 (Relative Link Quality) have a similar= =0A= >>>> problem of being under described, in particular it's unclear if= =0A= >>>> there's a meaningful, non-proprietary definition for link quali= ty=0A= >>>> that an implementation is to act on or if the passed value is j= ust=0A= >>>> passed for as monitoring information. Either way, this needs t= o=0A= >>>> be clarified.=0A= >>>=0A= >>> It seems the radio vendors really like this field. The reason why we=0A= >>> made "max/current link speed" mandatory is to make RLQ at least=0A= >>> reasonable useful.=0A= >>=0A= >> Yes we do :) Whilst a link may be supporting a given data rate, it=0A= >> could be running at or near threshold. To prevent unnecessary packet=0A= >> loss, especially if this is a transient situation it may be preferable f= or=0A= >> the router to say "let's choose a more stable link". We might, for insta= nce,=0A= >> choose reflect Rx Eb/N0 (adjusted to a 0-100 factor). A rapidly degradin= g=0A= >> loss of quality can then be picked up the router and again make a decisi= on=0A= >> about how best to route traffic.=0A= >=0A= > My point was that without the "max/current datarate" the RLQ is very=0A= > difficult to interpret, especially in heterogeneous networks.=0A= >=0A= > "Good that its a perfect link... but it doesn't mean you should go to=0A= > youtube over it if its a 4 kbit/s VHF connection." ;)=0A= >=0A= > I see two extensions coming to DLEP in the future... one to deliver=0A= > frame-level traffic statistics (sent/received bytes/frames, number of=0A= > retransmittedn/lost frames, ect) and radio parameters (frequency,=0A= > bandwidth, signal strength, channel busy/rx/tx time).=0A= >=0A= > Henning=0A= >=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= =0A= From nobody Mon Jun 22 06:03:05 2015 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 1573D1A8836; Mon, 22 Jun 2015 06:03:03 -0700 (PDT) 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 InHLIwI6u6EY; Mon, 22 Jun 2015 06:03:00 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBF81A891E; Mon, 22 Jun 2015 06:03:00 -0700 (PDT) Received: from pps.reinject (pps.reinject) by mx1.ll.mit.edu (unknown) with ESMTP id t5MD2wZt029714; Mon, 22 Jun 2015 09:02:58 -0400 Received: from pps.reinject (mx1.ll.mit.edu [127.0.0.1]) by pps.reinject (8.14.5/8.14.5) with SMTP id t5MD2vj9029697; Mon, 22 Jun 2015 09:02:57 -0400 From: "Wiggins, David - 0665 - MITLL" To: Rick Taylor , Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhkq4BISdYAIk+JbR87kxTblJ24kLwA Date: Mon, 22 Jun 2015 12:54:35 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3517808074_51841535" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-22_01:2015-06-22,2015-06-21,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-22_01:2015-06-22,2015-06-21,1970-01-01 signatures=0 X-Proofpoint-Sentinel: stfsU2FsdGVkX1/Dtn7idiGWaqIACnNszwtCnoc0mCiQvazsr3/BruzsCn5y xneIGju3DulJu95QFjv0jjuQsB4otClWI3Mqu2goKDdDIyDVTC/XuxOhDTqbtTuxOk5dxjruxwK2 TCBcDmNZam7p4eO5AYRQYyeJ/GeOkRhyc3aUd3oRsVLGgehf5lR3/mOO725XdVZu5bFKZacrE0oI TIfZyV82GU4c6MpwBJYHMAuWLU204bUxmRuqkfQV0jzXHH5vApI2zfP2dAjHnFO3yIsLWV0RdpBL erH2K+JBpvueZrEwlMMyNvTgxNDrOePtEaQlYiolRysG40d3aQ9LE8ee9K+y1CKsdUKFwo7MMCix a34= Archived-At: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , MANET IETF , "manet-chairs@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 13:03:03 -0000 --B_3517808074_51841535 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit A few comments near the end... On 6/22/15, 8:36 AM, "Rick Taylor" wrote: >Comments inline... > >> >> On 22/06/15 13:11, Lou Berger wrote: >>> I have a really hard time understanding how there could be 2^16 >>> interoperable versions of anything. But maybe dlep means something >>> different than the norm when refering to versions. >>> >>> Can you/some explain a use case for more than a few, being really >>>generious >>> say 10, version numbers? >>> >>> Lou >>> >>> >>> On June 22, 2015 7:25:13 AM Henning Rogge wrote: >>> >>>> On Mon, Jun 22, 2015 at 1:00 PM, Rick Taylor >>>> wrote: >>>>>> Lots of options here. But recall UDP discovery is optional per >>>>>>current spec. >>>>> >>>>> I see no problem with shortening version to 16 bits (major octet, >>>>>minor >>>>> octet) I never want to see DLEP version 65538.0! >>>>> >>>>> I see the point of holding the version number at a fixed offset in >>>>>the >>>>> initial messages of the protocol, and it is something we can >>>>>definitely >>>>> do for the UDP discovery messages, as Henning pointed out, they are >>>>> special anyway. >>>>> >>>>> I am loathe to do it to the Initialization signals, as it adds >>>>>special >>>>> case code and text. I think it is okay to allow an implementation >>>>>*not* >>>>> using discovery to expect a process on the reserved address/port >>>>> combination to be using some version of DLEP, as long as later DLEP >>>>> versions ensure back compatibility. >>>> >>>> We could maybe define that both for TCP and UDP the first two bytes >>>> are a version number... after this we begin decoding signals/tlvs. >>>> >>>> This sounds reasonable easy and consistent. > >This sounds like a suggestion that the Peer_Init signals should use a >different header. I read Henning's proposal as being for all signals ("for TCP and UDP..."). Whether that's what he meant or not, I like the consistency and simplicity of just having it in the same place for all signals. > >Given there are data items that are only used during initialization, >would people be totally against a different wire format for these >packets rather than the signal format? Do you mean having Peer Init and Peer Init Ack would use something other than data items to express the fields they need? That seems like a much larger inconsistency to deal with than having the version number only in some signals. I'd rather keep the format of these signals consistent with the rest. > >Rick David --B_3517808074_51841535 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFByx3jr0iV2h3izy 6CbsN5Asf0u0MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYyMjEyNTQzNFowDQYJKoZIhvcNAQEBBQAEggEACJyOXgWQrP3UunsraBU6Vg37stW4OhjN mRlZlC8JwtJ4yGBpSi7QW+D/aArtZhENkMrfOuP3E0S1Uhu5Mm7JlBI7ralk9TdOP5GCnLQB i5HXbVIhgLOkcH336bh1kMVPBwIEo1y9zaSmgsE5HrrRh3SaBq+KgzGccraY1WoaBj1iNyHR tMRzGlHHlsOK7PXbu+k1/+O7K48FCpCs4Hz3r2pMcb7ZvAmL/p7tDbmcANqZeRmpdFSUYUz4 Xy1X4LjUXb2c9XHThzaCJ4BEP8PVlun6FE/j4ADJLZjDRqJqAHrhBzXMyXG1kYSqHwEPzdjH 8yXECvNIh5YtOvfR2Md8Eg== --B_3517808074_51841535-- From nobody Mon Jun 22 06:03:46 2015 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 505BF1A86EB; Mon, 22 Jun 2015 06:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.609 X-Spam-Level: X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, 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 CnAMG07dD845; Mon, 22 Jun 2015 06:03:35 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3631A8829; Mon, 22 Jun 2015 06:03:34 -0700 (PDT) Received: from pps.reinject (pps.reinject) by mx1.ll.mit.edu (unknown) with ESMTP id t5MD3X2A031339; Mon, 22 Jun 2015 09:03:33 -0400 Received: from pps.reinject (mx1.ll.mit.edu [127.0.0.1]) by pps.reinject (8.14.5/8.14.5) with SMTP id t5MD3XdH031333; Mon, 22 Jun 2015 09:03:33 -0400 From: "Wiggins, David - 0665 - MITLL" To: Rick Taylor , Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhkq4BISdYAIk+JbR87kxTblJ24kccA Date: Mon, 22 Jun 2015 12:58:19 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3517808298_51806467" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-22_01:2015-06-22,2015-06-21,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-22_01:2015-06-22,2015-06-21,1970-01-01 signatures=0 X-Proofpoint-Sentinel: stfsU2FsdGVkX1+X9zxE/qyoKk7VqcTA98nXBjODSHgI0hMEHdcpSQouVDUL ZH+9MWghBnpssWEwDDG4lW1pSSvjwUaTpfLMtVbOz8tk/1H+kLCdgQyqQBd9cp5lCBGHtrtx9W9d H4TEI5quJVz+lQMZ3R3dq/ApBdbTeGuA6t2w0ZR/0YPNtlCO9LUUOp6sHQDu789wbsquVeVbWNXe fyyuRSnUQaj2FGGplnZzg/e3URWJf5bDK4qBKVcp1JJabX3ZfshcvrdQiSk/47EmstAV20x9ZrQU JadW/pdiX6ZlRqy88UTQidTFAxcFkj2+JmCxfJM7ZIGq0aos/hCxKE10+TDzMrSc3+MrzcQBgOwq QMA= Archived-At: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" , MANET IETF , "manet-chairs@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 13:03:43 -0000 --B_3517808298_51806467 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I'm fine with a one byte version with no concept of major/minor. David On 6/22/15, 8:38 AM, "Rick Taylor" wrote: >Okay, I see your point - I have spent too long working with FOSS >software where everything lurks at version 0.97 ;) > >If the WG are happy with a single octet of 1 for the final 'first' >version, then that's good by me. > >+1/-1 please people! > >Rick > >On 22/06/15 13:29, Lou Berger wrote: >> >> >> On June 22, 2015 8:19:32 AM Rick Taylor >> wrote: >> >>> Okay, with a 4bit/4bit split of a single octet, we have 0-15 major >>> versions and 0-15 minor versions. >>> >>> We already have implementations on version 0.14, and with a draft-15 >>> expected, do you suggest a 3bit/5bit split? >> >> This is in fact a unique (at least in my experience ) usage of version. >> IMO the dlep version for the RFCed version would be 1. >> >>> Why not just use >>> major.minor 8bits each? We don't have to worry about bytes over the >>> local link. >> >> Yes, but you do need to worry about interoperability. If the WG really >> wants to go down this path, you'll need some tight text defining how >> versioning and version mismatches are handled. >> >> Lou >>> >>> Cheers, >>> >>> Rick >>> >>> >>> On 22/06/15 13:11, Lou Berger wrote: >>>> I have a really hard time understanding how there could be 2^16 >>>> interoperable versions of anything. But maybe dlep means something >>>> different than the norm when refering to versions. >>>> >>>> Can you/some explain a use case for more than a few, being really >>>>generious >>>> say 10, version numbers? >>>> >>>> Lou >>>> >>>> >>>> On June 22, 2015 7:25:13 AM Henning Rogge wrote: >>>> >>>>> On Mon, Jun 22, 2015 at 1:00 PM, Rick Taylor >>>>> wrote: >>>>>>> Lots of options here. But recall UDP discovery is optional per >>>>>>>current >>> spec. >>>>>> >>>>>> I see no problem with shortening version to 16 bits (major octet, >>>>>>minor >>>>>> octet) I never want to see DLEP version 65538.0! >>>>>> >>>>>> I see the point of holding the version number at a fixed offset in >>>>>>the >>>>>> initial messages of the protocol, and it is something we can >>>>>>definitely >>>>>> do for the UDP discovery messages, as Henning pointed out, they are >>>>>> special anyway. >>>>>> >>>>>> I am loathe to do it to the Initialization signals, as it adds >>>>>>special >>>>>> case code and text. I think it is okay to allow an implementation >>>>>>*not* >>>>>> using discovery to expect a process on the reserved address/port >>>>>> combination to be using some version of DLEP, as long as later DLEP >>>>>> versions ensure back compatibility. >>>>> >>>>> We could maybe define that both for TCP and UDP the first two bytes >>>>> are a version number... after this we begin decoding signals/tlvs. >>>>> >>>>> This sounds reasonable easy and consistent. >>>>> >>>>> Henning Rogge >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet --B_3517808298_51806467 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFA1a7BSqrrlQgNAS Gmt7RoxMswSmMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYyMjEyNTgxOFowDQYJKoZIhvcNAQEBBQAEggEABa5ulEYi1uich5bS8YcXT+AJ/g2gF8pL YRJrPD3kprFEAnKrDLOmmok0/oM+cXqNUgR2dp131QpJf7KCBARSAmpPzSTGgRjrnZG61m+I 5HtDvjN+eSuAE+xpDLrTuxw4o8ERAKxIPXZ/6V10r3m+C9W3Em1o4kaZ5acIw8er/d8Xg+1q 7OxAa54oru99q0sELm62k8rrUUYz7X/COwZbKFY5fxDZxLydNkIs5ifa/5IusjwMAcedXgBX 8kCEQOipjyXPqObQ0Apgfgn87IpuRNXbhSqD4zo9TSNAfvhzo/r1uV3UXz2LiMWmGKhTd7HO 2PBYuOF9y0VDUHIXosRHoQ== --B_3517808298_51806467-- From nobody Mon Jun 22 06:33:05 2015 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 BE25E1A8AE4; Mon, 22 Jun 2015 06:33:03 -0700 (PDT) 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 420v6w_fQShZ; Mon, 22 Jun 2015 06:33:01 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 409951A8AE8; Mon, 22 Jun 2015 06:33:01 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so76835594wic.1; Mon, 22 Jun 2015 06:33:00 -0700 (PDT) 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=Fic76RQydvb/JUE4JQEipHQmh4se8gzZc6fHNDBlTBk=; b=T00czDXRFTOr4S/cRnLW1czds/AaG57JpepFPhPVnJLN9Fhfek3VJVA+Lmrn6K183F kyKlsn+7sRFRi7md9ztVvpS3szG8+Uz/I3uqnHbFrvFPUSmRRnOlsB1S5I6wcH1T/hBo FPvodU7tU+eATFoJdO/TKDJVsbYQJMRNOeid/QoWVv+1j8Jo+QoymMGUS6XeFScCaGRH DVdZVpJXg/aUAsT05OY13UNDcs/ayQ3qpz66nFD3dLO7fHW0OVnhVxH8dhZG2+9SJOKU ZTqgk0FLRu5jJp/bd17bdVslYHFZBKPKdL+ijEjkFkSKvZI/EYagAXATUhPGKMUC0uB6 08qg== X-Received: by 10.180.103.227 with SMTP id fz3mr32147833wib.45.1434979979974; Mon, 22 Jun 2015 06:32:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Mon, 22 Jun 2015 06:32:40 -0700 (PDT) In-Reply-To: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 22 Jun 2015 15:32:40 +0200 Message-ID: To: "Wiggins, David - 0665 - MITLL" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtg-dir@ietf.org" , "manet-chairs@ietf.org" , "manet-ads@ietf.org" , MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 13:33:03 -0000 On Mon, Jun 22, 2015 at 2:54 PM, Wiggins, David - 0665 - MITLL wrote: > I read Henning's proposal as being for all signals ("for TCP and UDP..."). > Whether that's what he meant or not, I like the consistency and > simplicity of just having it in the same place for all signals. No, not for each signal... once for each incoming "network socket". So once for the UDP packet (before you give the rest to the signal processing code) and once for a TCP stream (before you start processing signals). I would not count them as part of the signals, more like a prefix before the signal(s) begin. About the version number thing... do we really need the "major.minor" version number? We have broken compatibility LOTS of times during the "0.x" draft phase, why not use a one-byte version number and keep counting up? Henning From nobody Mon Jun 22 06:48:59 2015 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 BEFCC1A9089; Mon, 22 Jun 2015 06:48:57 -0700 (PDT) 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 J6glOAFc2QXR; Mon, 22 Jun 2015 06:48:53 -0700 (PDT) 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 40B771A9073; Mon, 22 Jun 2015 06:48:53 -0700 (PDT) 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; Mon, 22 Jun 2015 14:48:27 +0100 From: Rick Taylor To: Henning Rogge , "Wiggins, David - 0665 - MITLL" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 13:48:26 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@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: Cc: "rtg-dir@ietf.org" , "manet-chairs@ietf.org" , "manet-ads@ietf.org" , MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 13:48:57 -0000 On 22/06/15 14:33, Henning Rogge wrote:=0A= > On Mon, Jun 22, 2015 at 2:54 PM, Wiggins, David - 0665 - MITLL=0A= > wrote:=0A= >> I read Henning's proposal as being for all signals ("for TCP and UDP..."= ).=0A= >> Whether that's what he meant or not, I like the consistency and=0A= >> simplicity of just having it in the same place for all signals.=0A= >=0A= > No, not for each signal... once for each incoming "network socket".=0A= >=0A= > So once for the UDP packet (before you give the rest to the signal=0A= > processing code) and once for a TCP stream (before you start=0A= > processing signals).=0A= >=0A= > I would not count them as part of the signals, more like a prefix=0A= > before the signal(s) begin.=0A= =0A= I would definitely only want the version numbers once. In each UDP =0A= packet, and once on TCP connection start, not on every signal.=0A= =0A= The question is, how to I describe that? Have an extra 1 octet header =0A= used during initialization? Once I start writing that, why not expand =0A= it out to include all those data items only used during initialization?=0A= =0A= I'll come back with some ASCII art...=0A= =0A= >=0A= >=0A= >=0A= > About the version number thing...=0A= >=0A= > do we really need the "major.minor" version number? We have broken=0A= > compatibility LOTS of times during the "0.x" draft phase, why not use=0A= > a one-byte version number and keep counting up?=0A= =0A= I think I'm hearing consensus for a single octet, version 1.=0A= =0A= Rick=0A= From nobody Mon Jun 22 06:53:58 2015 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 E2B4E1A90D1; Mon, 22 Jun 2015 06:53:56 -0700 (PDT) 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 DBBvPhVao-r4; Mon, 22 Jun 2015 06:53:54 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720831A90C2; Mon, 22 Jun 2015 06:53:54 -0700 (PDT) Received: by wguu7 with SMTP id u7so70033269wgu.3; Mon, 22 Jun 2015 06:53:52 -0700 (PDT) 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=OKGx56pchBHZk3yDJlODUqWawRev7O4oJzA7ZT+196c=; b=SFu/3TPYhFlANbpfazVQQvhp+qfTZfDgLQP3XRehLCh8jtHxfwxsfww1KkAEyvp0pd ty1KNoL9rkem02EQgwHdUXnvXNWLFspzIPcqcctD0mDEOqXNN7eXN3u8b75h0wzuwBpl VElAAU0fr8dvGR01j87JIYZ8lZsx9VIqA5gisoUSegsB72UF50EcksP6+DwKICeIoUsQ mS781XnHjzvhxOKYVFOruI2jdF9pMSgkMfphlDFU4/4bIOKqcIqUhmkSQXL/Dx2FOREf BhDQ82ZB4n9sEuWGILE3eqCEe4OS6kDfMRt14CJOHTDh9i864CeHSdY1hlQL6byjgCgp 9IQQ== X-Received: by 10.180.23.66 with SMTP id k2mr7345145wif.85.1434981232175; Mon, 22 Jun 2015 06:53:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Mon, 22 Jun 2015 06:53:32 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 22 Jun 2015 15:53:32 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtg-dir@ietf.org" , "manet-chairs@ietf.org" , MANET IETF , "manet-ads@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 13:53:57 -0000 On Mon, Jun 22, 2015 at 3:48 PM, Rick Taylor wrote: >> No, not for each signal... once for each incoming "network socket". >> >> So once for the UDP packet (before you give the rest to the signal >> processing code) and once for a TCP stream (before you start >> processing signals). >> >> I would not count them as part of the signals, more like a prefix >> before the signal(s) begin. > > I would definitely only want the version numbers once. In each UDP > packet, and once on TCP connection start, not on every signal. Agreed... up to 4 times until a DLEP session is completely working... one in the UDP packets each, and one at the head of the TCP stream (in both directions!) > The question is, how to I describe that? Have an extra 1 octet header > used during initialization? Once I start writing that, why not expand > it out to include all those data items only used during initialization? Whats about this? > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | DLEP signal(s) ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Henning From nobody Mon Jun 22 07:08:13 2015 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 675D91AC3F4; Mon, 22 Jun 2015 07:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, 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 eVAW6jL7myjj; Mon, 22 Jun 2015 07:08:08 -0700 (PDT) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A931A9300; Mon, 22 Jun 2015 07:08:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,659,1427756400"; d="scan'208";a="411910" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta2.baesystems.com with ESMTP; 22 Jun 2015 15:08:05 +0100 X-IronPort-AV: E=Sophos;i="5.13,659,1427756400"; d="scan'208";a="102362388" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 22 Jun 2015 15:08:05 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.17]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0224.002; Mon, 22 Jun 2015 15:08:05 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojiIwK+stmbvhUWtFDx9P52N9Z24o16w Date: Mon, 22 Jun 2015 14:08:04 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@tss-server1.home.tropicalstormsoftware.com> 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: Cc: "manet-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" , MANET IETF , "manet-chairs@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:08:10 -0000 I like one rarely changing octet, but ... So we've designed DLEP, it's version 0 or 1 (according to how you like numb= ering things). Now let's consider an extension of what may well be the most common type, a= new piece of information that a radio can report, with a new TLV etc. We don't want that to update that version octet unless we really have to. A= nd we may well not need to, if we behave like: New radio, old router - ignore unrecognised TLV. New router, old radio - either use a default value, or do something based o= n knowing that you don't know. And that's the but, we need a specification that covers the unknown and mis= sing cases. To be honest, I don't recall how well the draft covers that. (If we have an extension that can't be so handled, then we're into a versio= n change. But hopefully not often.) -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Rick Taylor Sent: 22 June 2015 13:39 To: Lou Berger; Henning Rogge Cc: manet-ads@ietf.org; rtg-dir@ietf.org; MANET IETF; manet-chairs@ietf.org= ; draft-ietf-manet-dlep.all@ietf.org Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 ----------------------! 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. -------------------------------------------------------- *** WARNING *** This message originates from outside our organization, either from an exter= nal partner or the internet. Consider carefully whether you should click on= any links, open any attachments or reply. For additional information about= Spearphishing, click here . If you feel the email is s= uspicious, please follow this process. Okay, I see your point - I have spent too long working with FOSS software w= here everything lurks at version 0.97 ;) If the WG are happy with a single octet of 1 for the final 'first' = version, then that's good by me. +1/-1 please people! Rick On 22/06/15 13:29, Lou Berger wrote: > > > On June 22, 2015 8:19:32 AM Rick Taylor = wrote: > >> Okay, with a 4bit/4bit split of a single octet, we have 0-15 major = >> versions and 0-15 minor versions. >> >> We already have implementations on version 0.14, and with a draft-15 = >> expected, do you suggest a 3bit/5bit split? > > This is in fact a unique (at least in my experience ) usage of version. > IMO the dlep version for the RFCed version would be 1. > >> Why not just use >> major.minor 8bits each? We don't have to worry about bytes over the = >> local link. > > Yes, but you do need to worry about interoperability. If the WG = > really wants to go down this path, you'll need some tight text = > defining how versioning and version mismatches are handled. > > Lou >> >> Cheers, >> >> Rick >> >> >> On 22/06/15 13:11, Lou Berger wrote: >>> I have a really hard time understanding how there could be 2^16 = >>> interoperable versions of anything. But maybe dlep means something = >>> different than the norm when refering to versions. >>> >>> Can you/some explain a use case for more than a few, being really = >>> generious say 10, version numbers? >>> >>> Lou >>> >>> >>> On June 22, 2015 7:25:13 AM Henning Rogge wrote: >>> >>>> On Mon, Jun 22, 2015 at 1:00 PM, Rick Taylor = >>>> wrote: >>>>>> Lots of options here. But recall UDP discovery is optional per = >>>>>> current >> spec. >>>>> >>>>> I see no problem with shortening version to 16 bits (major octet, = >>>>> minor >>>>> octet) I never want to see DLEP version 65538.0! >>>>> >>>>> I see the point of holding the version number at a fixed offset in = >>>>> the initial messages of the protocol, and it is something we can = >>>>> definitely do for the UDP discovery messages, as Henning pointed = >>>>> out, they are special anyway. >>>>> >>>>> I am loathe to do it to the Initialization signals, as it adds = >>>>> special case code and text. I think it is okay to allow an = >>>>> implementation *not* using discovery to expect a process on the = >>>>> reserved address/port combination to be using some version of = >>>>> DLEP, as long as later DLEP versions ensure back compatibility. >>>> >>>> We could maybe define that both for TCP and UDP the first two bytes = >>>> are a version number... after this we begin decoding signals/tlvs. >>>> >>>> This sounds reasonable easy and consistent. >>>> >>>> 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 Mon Jun 22 07:12:07 2015 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 2CC311AC40D for ; Mon, 22 Jun 2015 07:12:06 -0700 (PDT) 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 GJAabPSV8Jke for ; Mon, 22 Jun 2015 07:12:05 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (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 9BFDA1AC410 for ; Mon, 22 Jun 2015 07:12:04 -0700 (PDT) Received: by wguu7 with SMTP id u7so70531534wgu.3 for ; Mon, 22 Jun 2015 07:12:03 -0700 (PDT) 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=a8I/CYioKkGWikllGetGKL/aQjKB+xvcQoZKT9Dkkv0=; b=XAf9oQm6gP/UkymWGLaEaMnRqWMxPh+EhuDjC/i+7XY++345yzxiwTjIIcADMtHV2Z NqtgRCPz0Adm5ettDae/Ju4hfM6efnwVP3HNSOOfSmubueo7IdrNJ9gmHewRomQ/ermr 40/Qe1MXnOouD9f81ukW1gUbr7459iMmH5T1BByEAO/1aiuuUNhDOk9x0MAIdZmR/QEO olUQfHr9EjbcS+dolPK/c6s5QRYu4Jsh7N5NNBYDIZgtp5n0CuS6Y3ocoTtKEy7ukM2C G4Kie+9B60Q/KZgzJPy7OErydak1FrC2JaG7iH8Wq1F5+ZSQtWcuQcM36/2JpQBo2zCx hyPA== X-Received: by 10.194.5.4 with SMTP id o4mr42581083wjo.51.1434982323311; Mon, 22 Jun 2015 07:12:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Mon, 22 Jun 2015 07:11:43 -0700 (PDT) In-Reply-To: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 22 Jun 2015 16:11:43 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: MANET IETF Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:12:06 -0000 On Mon, Jun 22, 2015 at 4:08 PM, Dearlove, Christopher (UK) wrote: > I like one rarely changing octet, but ... > > So we've designed DLEP, it's version 0 or 1 (according to how you like numbering things). > > Now let's consider an extension of what may well be the most common type, a new piece of information that a radio can report, with a new TLV etc. > > We don't want that to update that version octet unless we really have to. And we may well not need to, if we behave like: > > New radio, old router - ignore unrecognised TLV. > > New router, old radio - either use a default value, or do something based on knowing that you don't know. > > And that's the but, we need a specification that covers the unknown and missing cases. To be honest, I don't recall how well the draft covers that. You don't need a new version for a new extension... because you have to announce your extension in Peer Initialization (ack). If the other side doesn't support your extension, you are not allowed to send its TLVs. The only thing that would require a version change would be an incompatible parser/generator behaviour like a change in the TLV header fields or something else that breaks compatibility. Hennning From nobody Mon Jun 22 07:14:30 2015 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 583521AC426 for ; Mon, 22 Jun 2015 07:14:29 -0700 (PDT) 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 Fh_HgiaxEZfZ for ; Mon, 22 Jun 2015 07:14:27 -0700 (PDT) Received: from ukmta4.baesystems.com (ukmta4.baesystems.com [20.133.40.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5A01AC42E for ; Mon, 22 Jun 2015 07:14:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,659,1427756400"; d="scan'208";a="224117" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta4.baesystems.com with ESMTP; 22 Jun 2015 15:14:23 +0100 X-IronPort-AV: E=Sophos;i="5.13,659,1427756400"; d="scan'208";a="106520570" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 22 Jun 2015 15:14:23 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.17]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0224.002; Mon, 22 Jun 2015 15:14:23 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojiIwK+stmbvhUWtFDx9P52N9Z24o16w///yKICAABD+UA== Date: Mon, 22 Jun 2015 14:14:22 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@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="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:14:29 -0000 Good, that's what I hoped (and really should have checked). Given that, one octet is enough. (Or you could even use a half octet and re= serve the other half, just in case of something else wanted in future, such= as some flags.) -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 22 June 2015 15:12 To: Dearlove, Christopher (UK) Cc: MANET IETF Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 ----------------------! 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. -------------------------------------------------------- *** WARNING *** This message originates from outside our organization, either from an exter= nal partner or the internet. Consider carefully whether you should click on= any links, open any attachments or reply. For additional information about= Spearphishing, click here . If you feel the email is s= uspicious, please follow this process. On Mon, Jun 22, 2015 at 4:08 PM, Dearlove, Christopher (UK) wrote: > I like one rarely changing octet, but ... > > So we've designed DLEP, it's version 0 or 1 (according to how you like nu= mbering things). > > Now let's consider an extension of what may well be the most common type,= a new piece of information that a radio can report, with a new TLV etc. > > We don't want that to update that version octet unless we really have to.= And we may well not need to, if we behave like: > > New radio, old router - ignore unrecognised TLV. > > New router, old radio - either use a default value, or do something based= on knowing that you don't know. > > And that's the but, we need a specification that covers the unknown and m= issing cases. To be honest, I don't recall how well the draft covers that. You don't need a new version for a new extension... because you have to ann= ounce your extension in Peer Initialization (ack). If the other side doesn't support your extension, you are not allowed to se= nd its TLVs. The only thing that would require a version change would be an incompatible= parser/generator behaviour like a change in the TLV header fields or somet= hing else that breaks compatibility. Hennning _______________________________________________ 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 Mon Jun 22 07:17:10 2015 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 4E4841ACD0C for ; Mon, 22 Jun 2015 07:17:09 -0700 (PDT) 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 fGdV3myyaJ7g for ; Mon, 22 Jun 2015 07:17:08 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (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 8CC751ACD15 for ; Mon, 22 Jun 2015 07:17:05 -0700 (PDT) Received: by wgbhy7 with SMTP id hy7so142768049wgb.2 for ; Mon, 22 Jun 2015 07:17:04 -0700 (PDT) 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=QHi8hN4qOqa9ATaM7vVAUScQyKlKBwcopJKlJpGm3Fs=; b=AZSgoOHmrOh1xm2M8WKlB9ZzjYqj3sTuefJ+hSLnMZBHFigX6+YEnCMJ/Lg/JANYZi HpVNdsMTgOLREdw0y7vSXq4G1zRah3Rsz9qFUy/UPZ0FsKebJAashoVWXa95rMwGF0f9 BX7TlVHCtPioDz4Hn02bKFlcqXKK+9FHxfLY9F4+Qdj9v3qNAF0L+3oaN2ECUrSGfany VU3Ni59ILdsjyE5d7FnjDfFjb/toOiQ+IZNEhvC2EF1aUVp0+k4CAGLwG4CBDXaZ8VoP WpTioiBLDiANWGojtG5Wfw6rdl341J6tURM7xCtS8YuzkRvPSjHCKdYDElKSkDcJ1C9b jcMA== X-Received: by 10.180.88.99 with SMTP id bf3mr18284652wib.75.1434982624398; Mon, 22 Jun 2015 07:17:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Mon, 22 Jun 2015 07:16:44 -0700 (PDT) In-Reply-To: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 22 Jun 2015 16:16:44 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: MANET IETF Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:17:09 -0000 On Mon, Jun 22, 2015 at 4:14 PM, Dearlove, Christopher (UK) wrote: > Good, that's what I hoped (and really should have checked). > > Given that, one octet is enough. (Or you could even use a half octet and reserve the other half, just in case of something else wanted in future, such as some flags.) We could "easily" add flags by changing the version number and appending an additional byte... hopefully it will not be necessary in the future. Henning From nobody Mon Jun 22 07:19:46 2015 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 C9B301ACD37; Mon, 22 Jun 2015 07:19:43 -0700 (PDT) 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 2UBs9gH0e3ij; Mon, 22 Jun 2015 07:19:42 -0700 (PDT) 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 1314D1ACD33; Mon, 22 Jun 2015 07:19:42 -0700 (PDT) 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; Mon, 22 Jun 2015 15:19:08 +0100 From: Rick Taylor To: Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 14:19:07 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@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: Cc: "rtg-dir@ietf.org" , "manet-chairs@ietf.org" , MANET IETF , "manet-ads@ietf.org" , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:19:43 -0000 On 22/06/15 14:53, Henning Rogge wrote:=0A= > On Mon, Jun 22, 2015 at 3:48 PM, Rick Taylor=0A= > wrote:=0A= >>> No, not for each signal... once for each incoming "network socket".=0A= >>>=0A= >>> So once for the UDP packet (before you give the rest to the signal=0A= >>> processing code) and once for a TCP stream (before you start=0A= >>> processing signals).=0A= >>>=0A= >>> I would not count them as part of the signals, more like a prefix=0A= >>> before the signal(s) begin.=0A= >>=0A= >> I would definitely only want the version numbers once. In each UDP=0A= >> packet, and once on TCP connection start, not on every signal.=0A= >=0A= > Agreed... up to 4 times until a DLEP session is completely working...=0A= >=0A= > one in the UDP packets each, and one at the head of the TCP stream (in=0A= > both directions!)=0A= >=0A= >> The question is, how to I describe that? Have an extra 1 octet header= =0A= >> used during initialization? Once I start writing that, why not expand= =0A= >> it out to include all those data items only used during initialization?= =0A= >=0A= > Whats about this?=0A= >=0A= >> 0 1 2 3=0A= >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= >> | Version | DLEP signal(s) ... |=0A= >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= >=0A= =0A= That has the advantage of simplicity!=0A= =0A= I tried to pack all the Peer_Init data items into a Peer_Init struct and = =0A= it just looked like a standard DLEP signal, but with strict ordering.=0A= =0A= Actually, I'm still scratching my head to work out what the problem with = =0A= the current method is:=0A= =0A= Byte(0) =3D Peer_Init/ACK=0A= Bytes(1+2) =3D Length=0A= Check length for sanity=0A= Scan data items for Version, parse version.=0A= =0A= Is the problem that people are worried that the TCP connection they have = =0A= made is not to a DLEP peer that they have a) discovered, or b) =0A= configured. Remember this isn't some remote peer that has been met, =0A= this is locally attached.=0A= =0A= If we were discussing a file format, then I can see the advantage of =0A= having some identifier at a well-known offset, but I'm unconvinced in =0A= this case.=0A= =0A= Rick=0A= From nobody Mon Jun 22 07:20:27 2015 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 A22761A8AB7 for ; Mon, 22 Jun 2015 07:20:24 -0700 (PDT) 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 ysHB37jME-O2 for ; Mon, 22 Jun 2015 07:20:21 -0700 (PDT) Received: from ukmta4.baesystems.com (ukmta4.baesystems.com [20.133.40.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BA31ACD3F for ; Mon, 22 Jun 2015 07:20:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,659,1427756400"; d="scan'208";a="224676" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta4.baesystems.com with ESMTP; 22 Jun 2015 15:20:04 +0100 X-IronPort-AV: E=Sophos;i="5.13,659,1427756400"; d="scan'208";a="106521841" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 22 Jun 2015 15:20:00 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.17]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0224.002; Mon, 22 Jun 2015 15:19:59 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojiIwK+stmbvhUWtFDx9P52N9Z24o16w///yKICAABD+UP//8GkAgAARZbA= Date: Mon, 22 Jun 2015 14:19:58 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@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="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: MANET IETF Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:20:24 -0000 U3VyZSwgYnV0IHdvdWxkIGJlIGEgYmlnZ2VyIGNoYW5nZS4NCg0KKEFtIEkgc2VyaW91c2x5IHBy b3Bvc2luZyB0aGUgc3BsaXQgb2N0ZXQ/IElmIEkgd2VyZSBhbiBhdXRob3IgSSBtaWdodC4gQXMg YSBub24tYXV0aG9yIEkgd29uJ3QuKQ0KDQotLSANCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5p b3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KVDogwqArNDQgKDApMTI0NSAyNDIxOTQgwqB8IMKgRTogY2hy aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp Z2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2Zv cmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWkNCkJBRSBTeXN0ZW1zIEFw cGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVz IE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBH dWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEhlbm5pbmcgUm9nZ2UgW21haWx0bzpocm9nZ2VAZ21haWwuY29tXSANClNlbnQ6 IDIyIEp1bmUgMjAxNSAxNToxNw0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzog TUFORVQgSUVURg0KU3ViamVjdDogUmU6IFttYW5ldF0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0 Zi1tYW5ldC1kbGVwLTE0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBv dXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20g dGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGlj ayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9sbG93IHRo ZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3Ry dWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk9uIE1v biwgSnVuIDIyLCAyMDE1IGF0IDQ6MTQgUE0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxj aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gd3JvdGU6DQo+IEdvb2QsIHRoYXQncyB3aGF0 IEkgaG9wZWQgKGFuZCByZWFsbHkgc2hvdWxkIGhhdmUgY2hlY2tlZCkuDQo+DQo+IEdpdmVuIHRo YXQsIG9uZSBvY3RldCBpcyBlbm91Z2guIChPciB5b3UgY291bGQgZXZlbiB1c2UgYSBoYWxmIG9j dGV0IA0KPiBhbmQgcmVzZXJ2ZSB0aGUgb3RoZXIgaGFsZiwganVzdCBpbiBjYXNlIG9mIHNvbWV0 aGluZyBlbHNlIHdhbnRlZCBpbiANCj4gZnV0dXJlLCBzdWNoIGFzIHNvbWUgZmxhZ3MuKQ0KDQpX ZSBjb3VsZCAiZWFzaWx5IiBhZGQgZmxhZ3MgYnkgY2hhbmdpbmcgdGhlIHZlcnNpb24gbnVtYmVy IGFuZCBhcHBlbmRpbmcgYW4gYWRkaXRpb25hbCBieXRlLi4uIGhvcGVmdWxseSBpdCB3aWxsIG5v dCBiZSBuZWNlc3NhcnkgaW4gdGhlIGZ1dHVyZS4NCg0KSGVubmluZw0KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKVGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVu ZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0g YW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBm b3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== From nobody Mon Jun 22 07:22:43 2015 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 4F3541ACD4D for ; Mon, 22 Jun 2015 07:22:42 -0700 (PDT) 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 UdkYHjrMGjlc for ; Mon, 22 Jun 2015 07:22:41 -0700 (PDT) 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 118351ACD47 for ; Mon, 22 Jun 2015 07:22:41 -0700 (PDT) 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; Mon, 22 Jun 2015 15:22:06 +0100 From: Rick Taylor To: Henning Rogge , "Dearlove, Christopher (UK)" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 14:22:05 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AF0EB@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@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: Cc: MANET IETF Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:22:42 -0000 Thank you Henning, you beat me to it.=0A= =0A= Chris, that is exactly what Extensions are for.=0A= =0A= The only reason for a version 2 would be an incompatible change in the =0A= wire protocol, such as changing field lengths.=0A= =0A= Rick=0A= =0A= On 22/06/15 15:11, Henning Rogge wrote:=0A= > On Mon, Jun 22, 2015 at 4:08 PM, Dearlove, Christopher (UK)=0A= > wrote:=0A= >> I like one rarely changing octet, but ...=0A= >>=0A= >> So we've designed DLEP, it's version 0 or 1 (according to how you like n= umbering things).=0A= >>=0A= >> Now let's consider an extension of what may well be the most common type= , a new piece of information that a radio can report, with a new TLV etc.= =0A= >>=0A= >> We don't want that to update that version octet unless we really have to= . And we may well not need to, if we behave like:=0A= >>=0A= >> New radio, old router - ignore unrecognised TLV.=0A= >>=0A= >> New router, old radio - either use a default value, or do something base= d on knowing that you don't know.=0A= >>=0A= >> And that's the but, we need a specification that covers the unknown and = missing cases. To be honest, I don't recall how well the draft covers that.= =0A= >=0A= > You don't need a new version for a new extension... because you have=0A= > to announce your extension in Peer Initialization (ack).=0A= >=0A= > If the other side doesn't support your extension, you are not allowed=0A= > to send its TLVs.=0A= >=0A= > The only thing that would require a version change would be an=0A= > incompatible parser/generator behaviour like a change in the TLV=0A= > header fields or something else that breaks compatibility.=0A= >=0A= > Hennning=0A= >=0A= =0A= From nobody Mon Jun 22 07:24:34 2015 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 D51FA1ACD53 for ; Mon, 22 Jun 2015 07:24:31 -0700 (PDT) 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 jOjJ9rcVbCZH for ; Mon, 22 Jun 2015 07:24:31 -0700 (PDT) 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 96A201ACD38 for ; Mon, 22 Jun 2015 07:24:30 -0700 (PDT) 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; Mon, 22 Jun 2015 15:23:56 +0100 From: Rick Taylor To: Henning Rogge , "Dearlove, Christopher (UK)" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 14:23:54 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AF12F@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@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: Cc: MANET IETF Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:24:32 -0000 On 22/06/15 15:17, Henning Rogge wrote:=0A= > On Mon, Jun 22, 2015 at 4:14 PM, Dearlove, Christopher (UK)=0A= > wrote:=0A= >> Good, that's what I hoped (and really should have checked).=0A= >>=0A= >> Given that, one octet is enough. (Or you could even use a half octet and= reserve the other half, just in case of something else wanted in future, s= uch as some flags.)=0A= >=0A= > We could "easily" add flags by changing the version number and=0A= > appending an additional byte... hopefully it will not be necessary in=0A= > the future.=0A= >=0A= =0A= We hope the Extensions mechanism provides the functionality of flags in =0A= a slightly more flexible way.=0A= =0A= There is nothing to stop an implementation announcing an Extension who's = =0A= presence indicates nothing more than a Boolean value meaning "I do (or =0A= do not) do this"=0A= =0A= Rick=0A= =0A= From nobody Mon Jun 22 07:25:47 2015 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 42C6C1A908E for ; Mon, 22 Jun 2015 07:25:45 -0700 (PDT) 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 s-3ZdZAbODST for ; Mon, 22 Jun 2015 07:25:44 -0700 (PDT) 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 3E84D1A9132 for ; Mon, 22 Jun 2015 07:25:44 -0700 (PDT) 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; Mon, 22 Jun 2015 15:25:09 +0100 From: Rick Taylor To: "Dearlove, Christopher (UK)" , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 14:25:08 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AF13E@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@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: Cc: MANET IETF Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:25:45 -0000 On 22/06/15 15:20, Dearlove, Christopher (UK) wrote:=0A= > Sure, but would be a bigger change.=0A= >=0A= > (Am I seriously proposing the split octet? If I were an author I might. A= s a non-author I won't.)=0A= >=0A= =0A= Stan and I have been convinced by the WG that the major minor split is =0A= not needed.=0A= =0A= Rick=0A= From nobody Mon Jun 22 07:26:22 2015 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 6DB8E1A908E for ; Mon, 22 Jun 2015 07:26:20 -0700 (PDT) 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 Vrb717UsXtyy for ; Mon, 22 Jun 2015 07:26:19 -0700 (PDT) Received: from ukmta4.baesystems.com (ukmta4.baesystems.com [20.133.40.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055EA1A9040 for ; Mon, 22 Jun 2015 07:26:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,659,1427756400"; d="scan'208";a="225640" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta4.baesystems.com with ESMTP; 22 Jun 2015 15:26:17 +0100 X-IronPort-AV: E=Sophos;i="5.13,659,1427756400"; d="scan'208";a="106523207" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 22 Jun 2015 15:26:17 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.17]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0224.002; Mon, 22 Jun 2015 15:26:17 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojiIwK+stmbvhUWtFDx9P52N9Z24qjXQ Date: Mon, 22 Jun 2015 14:26:16 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF13E@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2AF13E@tss-server1.home.tropicalstormsoftware.com> 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: Cc: MANET IETF Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:26:20 -0000 It wasn't a major/minor split I would have suggested, but a version/reserve= d split. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] = Sent: 22 June 2015 15:25 To: Dearlove, Christopher (UK); Henning Rogge Cc: MANET IETF Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 ----------------------! 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. -------------------------------------------------------- On 22/06/15 15:20, Dearlove, Christopher (UK) wrote: > Sure, but would be a bigger change. > > (Am I seriously proposing the split octet? If I were an author I = > might. As a non-author I won't.) > Stan and I have been convinced by the WG that the major minor split is not = needed. Rick ******************************************************************** 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 Mon Jun 22 07:27:11 2015 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 D08321AC431; Mon, 22 Jun 2015 07:27:09 -0700 (PDT) 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 1yblRf2ZU_Qh; Mon, 22 Jun 2015 07:27:08 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1487D1A908E; Mon, 22 Jun 2015 07:27:08 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,659,1427774400"; d="scan'208";a="8155512" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport2.idirect.net with ESMTP; 22 Jun 2015 10:27:07 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 22 Jun 2015 10:27:06 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Mon, 22 Jun 2015 10:27:06 -0400 From: "Ratliff, Stanley" To: Rick Taylor , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQoh7bMo+Tw3COyECGObxkTDTDb524qZ6Q Date: Mon, 22 Jun 2015 14:27:06 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:27:10 -0000 > -----Original Message----- > From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] > Sent: Monday, June 22, 2015 10:19 AM > To: Henning Rogge > Cc: Wiggins, David - 0665 - MITLL; Lou Berger; manet-ads@ietf.org; rtg- > dir@ietf.org; draft-ietf-manet-dlep.all@ietf.org; MANET IETF; manet- > chairs@ietf.org > Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 > = > On 22/06/15 14:53, Henning Rogge wrote: > > On Mon, Jun 22, 2015 at 3:48 PM, Rick Taylor > > wrote: > >>> No, not for each signal... once for each incoming "network socket". > >>> > >>> So once for the UDP packet (before you give the rest to the signal > >>> processing code) and once for a TCP stream (before you start > >>> processing signals). > >>> > >>> I would not count them as part of the signals, more like a prefix > >>> before the signal(s) begin. > >> > >> I would definitely only want the version numbers once. In each UDP > >> packet, and once on TCP connection start, not on every signal. > > > > Agreed... up to 4 times until a DLEP session is completely working... > > > > one in the UDP packets each, and one at the head of the TCP stream (in > > both directions!) > > > >> The question is, how to I describe that? Have an extra 1 octet > >> header used during initialization? Once I start writing that, why > >> not expand it out to include all those data items only used during > initialization? > > > > Whats about this? > > > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Version | DLEP signal(s) ... | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > = > That has the advantage of simplicity! > = > I tried to pack all the Peer_Init data items into a Peer_Init struct and = it just > looked like a standard DLEP signal, but with strict ordering. > = > Actually, I'm still scratching my head to work out what the problem with = the > current method is: > = > Byte(0) =3D Peer_Init/ACK > Bytes(1+2) =3D Length > Check length for sanity > Scan data items for Version, parse version. > = > Is the problem = As I understand it, the problem is people are worried that, in order to par= se for the version TLV, you have to know how to parse the signal (in genera= l terms). A "substantial enough" (whatever that means) change in DLEP *migh= t* render an implementation unable to "scan data items for Version, parse v= ersion". = I get slapped every time I've brought this up, but - sence we're only talki= ng about 4 signals (Discovery, Offer, Peer_Init, Peer_Init_ACK), why not de= clare that Version MUST be the first TLV in those packets (and ONLY those p= ackets)? Regards, Stan = >that people are worried that the TCP connection they have > made is not to a DLEP peer that they have a) discovered, or b) configured. > Remember this isn't some remote peer that has been met, this is locally > attached. > = > If we were discussing a file format, then I can see the advantage of havi= ng > some identifier at a well-known offset, but I'm unconvinced in this case. > = > Rick _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Mon Jun 22 07:32:20 2015 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 51BF11ACD6B for ; Mon, 22 Jun 2015 07:32:18 -0700 (PDT) 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 dX2xa4yNQcRm for ; Mon, 22 Jun 2015 07:32:16 -0700 (PDT) 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 69BAE1ACD57 for ; Mon, 22 Jun 2015 07:32:16 -0700 (PDT) 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; Mon, 22 Jun 2015 15:31:52 +0100 From: Rick Taylor To: "Dearlove, Christopher (UK)" , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 14:31:51 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AF19D@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <14e1b3e4698.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AD924@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF13E@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: Cc: MANET IETF Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:32:18 -0000 On 22/06/15 15:26, Dearlove, Christopher (UK) wrote:=0A= > It wasn't a major/minor split I would have suggested, but a version/reser= ved split.=0A= >=0A= =0A= Given the text will say something along the lines of "1 octet, value 1" =0A= then we have reserved 7 bits with value 0 already ;-)=0A= =0A= Rick=0A= From nobody Mon Jun 22 07:34:01 2015 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 9D7321ACD83; Mon, 22 Jun 2015 07:33:59 -0700 (PDT) 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 1Q1xBAisJx_x; Mon, 22 Jun 2015 07:33:58 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 1AA221ACD78; Mon, 22 Jun 2015 07:33:58 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so77315203wib.1; Mon, 22 Jun 2015 07:33:56 -0700 (PDT) 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=+d1/qv4qGzJCNjmeUzSZ0PXZp//KIJ1qrvkIqNX9njs=; b=GxHhcCOyQJ3XuEh/FI8SGG2Ay+QOpiQ7SHLNfUd0DqJ7kj0pI/S0RdHJOW6HIjtLyU GOo/W8tAdK31nTICgZvoLleQHaj7AaonPctFwJybqBWI+BwUNezUPc/asRcf/HePDs9e 54Fg9PunXrEtxC0frXd4rM3v6uAdsbEmJSzMc/98gQKmxjxZHZuwYOp868PiQuMT0ppo qj6DcfzW5kGMbpX1uY2c4u64B1gkeCq2X0QquXoCU+fWNG3qs6KzzPhCHxqD48rmBHEE 83p2ptI7+AGCBw9zQXnOEJqY/OE/0oBO4IsVq5jcvI2V/JiieX09usJK20fc5Odh3G+B lkpg== X-Received: by 10.194.5.4 with SMTP id o4mr42752117wjo.51.1434983636908; Mon, 22 Jun 2015 07:33:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Mon, 22 Jun 2015 07:33:37 -0700 (PDT) In-Reply-To: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 22 Jun 2015 16:33:37 +0200 Message-ID: To: "Ratliff, Stanley" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:33:59 -0000 On Mon, Jun 22, 2015 at 4:27 PM, Ratliff, Stanley wr= ote: > As I understand it, the problem is people are worried that, in order to p= arse for the version TLV, you have to know how to parse the signal (in gene= ral terms). A "substantial enough" (whatever that means) change in DLEP *mi= ght* render an implementation unable to "scan data items for Version, parse= version". > > I get slapped every time I've brought this up, but - sence we're only tal= king about 4 signals (Discovery, Offer, Peer_Init, Peer_Init_ACK), why not = declare that Version MUST be the first TLV in those packets (and ONLY those= packets)? And then we get "version 2" which extends the maximum length of signals to 32 bit to allow some awesome faster than light transmission. If we think we can keep the current signal/version structure, we don't need a version TLV at all. If we want to be careful, lets put it outside our signal/tlv structure. **** I just had a "lightly crazy" idea... if we really need backward compatibility to current implementations, we could make the RFC version (delivered in the first byte of UDP packet and TCP stream) number 4... because all the older versions had PEER Discovery/Initialization messages at this place, which began with a 0 to 3. This way (if someone needs it) its possible to produce a DLEP version that understands both the DLEP-draft version (at least things since ~ draft 5-6) AND a DLEP RFC with a version number. Henning From nobody Mon Jun 22 07:37:50 2015 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 B7E5B1ACD8D; Mon, 22 Jun 2015 07:37:48 -0700 (PDT) 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 5oMYSZ7pMfAv; Mon, 22 Jun 2015 07:37:47 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 049961ACD8A; Mon, 22 Jun 2015 07:37:46 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.201 as permitted sender) identity=mailfrom; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,659,1427774400"; d="scan'208";a="8155969" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.201]) by ironport2.idirect.net with ESMTP; 22 Jun 2015 10:37:46 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM1.idirect.net (10.250.250.201) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 22 Jun 2015 10:37:45 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Mon, 22 Jun 2015 10:37:45 -0400 From: "Ratliff, Stanley" To: Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQoh7bMo+Tw3COyECGObxkTDTDb524qZ6QgABGC4D//71hsA== Date: Mon, 22 Jun 2015 14:37:45 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:37:48 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGVubmluZyBSb2dnZSBb bWFpbHRvOmhyb2dnZUBnbWFpbC5jb21dDQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAyMiwgMjAxNSAx MDozNCBBTQ0KPiBUbzogUmF0bGlmZiwgU3RhbmxleQ0KPiBDYzogUmljayBUYXlsb3I7IFdpZ2dp bnMsIERhdmlkIC0gMDY2NSAtIE1JVExMOyBMb3UgQmVyZ2VyOyBkcmFmdC1pZXRmLW1hbmV0LQ0K PiBkbGVwLmFsbEBpZXRmLm9yZzsgTUFORVQgSUVURg0KPiBTdWJqZWN0OiBSZTogW21hbmV0XSBS dGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLW1hbmV0LWRsZXAtMTQNCj4gDQo+IE9uIE1vbiwgSnVu IDIyLCAyMDE1IGF0IDQ6MjcgUE0sIFJhdGxpZmYsIFN0YW5sZXkgPHNyYXRsaWZmQGlkaXJlY3Qu bmV0PiB3cm90ZToNCj4gPiBBcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBwcm9ibGVtIGlzIHBlb3Bs ZSBhcmUgd29ycmllZCB0aGF0LCBpbiBvcmRlciB0byBwYXJzZQ0KPiBmb3IgdGhlIHZlcnNpb24g VExWLCB5b3UgaGF2ZSB0byBrbm93IGhvdyB0byBwYXJzZSB0aGUgc2lnbmFsIChpbiBnZW5lcmFs DQo+IHRlcm1zKS4gQSAic3Vic3RhbnRpYWwgZW5vdWdoIiAod2hhdGV2ZXIgdGhhdCBtZWFucykg Y2hhbmdlIGluIERMRVANCj4gKm1pZ2h0KiByZW5kZXIgYW4gaW1wbGVtZW50YXRpb24gdW5hYmxl IHRvICJzY2FuIGRhdGEgaXRlbXMgZm9yIFZlcnNpb24sDQo+IHBhcnNlIHZlcnNpb24iLg0KPiA+ DQo+ID4gSSBnZXQgc2xhcHBlZCBldmVyeSB0aW1lIEkndmUgYnJvdWdodCB0aGlzIHVwLCBidXQg LSBzZW5jZSB3ZSdyZSBvbmx5IHRhbGtpbmcNCj4gYWJvdXQgNCBzaWduYWxzIChEaXNjb3Zlcnks IE9mZmVyLCBQZWVyX0luaXQsIFBlZXJfSW5pdF9BQ0spLCB3aHkgbm90IGRlY2xhcmUNCj4gdGhh dCBWZXJzaW9uIE1VU1QgYmUgdGhlIGZpcnN0IFRMViBpbiB0aG9zZSBwYWNrZXRzIChhbmQgT05M WSB0aG9zZQ0KPiBwYWNrZXRzKT8NCj4gDQo+IEFuZCB0aGVuIHdlIGdldCAidmVyc2lvbiAyIiB3 aGljaCBleHRlbmRzIHRoZSBtYXhpbXVtIGxlbmd0aCBvZiBzaWduYWxzIHRvDQo+IDMyIGJpdCB0 byBhbGxvdyBzb21lIGF3ZXNvbWUgZmFzdGVyIHRoYW4gbGlnaHQgdHJhbnNtaXNzaW9uLg0KDQpG cm9tIHdoYXQgSSBoZWFyLCB0aGVyZSdzICphbHJlYWR5KiBhIHB1c2ggdG8gZXh0ZW5kIHRoZSBt YXggc2lnbmFsIGxlbmd0aCB0byAzMiBiaXRzLi4uICBBbmQvb3IsIGlmIHlvdSd2ZSBnb3QgdG8g ZG8gc29tZXRoaW5nIGxpa2UgdGhhdCwgYWxsb2NhdGUgbmV3IGNvZGUgcG9pbnRzIGZvciB0aGUg bmV3ZXIgRGlzY292ZXJ5ICYgSW5pdCBzaWduYWxzLiBXaXRoIGEgNjVLIG51bWJlcmluZyBzcGFj ZSAoZWFybGllciBkaXNjdXNzaW9ucyksIHRoZXJlIHdpbGwgYmUgcm9vbS4NCg0KRG9lc24ndCBU TFMgZW5jb2RlIGl0cyB2ZXJzaW9uIGluZm9ybWF0aW9uICppbnRvKiBvbmUgb2YgdGhlIGVhcmx5 IG1lc3NhZ2VzPyANCg0KUmVnYXJkcywNClN0YW4NCg0KPiANCj4gSWYgd2UgdGhpbmsgd2UgY2Fu IGtlZXAgdGhlIGN1cnJlbnQgc2lnbmFsL3ZlcnNpb24gc3RydWN0dXJlLCB3ZSBkb24ndCBuZWVk IGENCj4gdmVyc2lvbiBUTFYgYXQgYWxsLiBJZiB3ZSB3YW50IHRvIGJlIGNhcmVmdWwsIGxldHMg cHV0IGl0IG91dHNpZGUgb3VyIHNpZ25hbC90bHYNCj4gc3RydWN0dXJlLg0KPiANCj4gKioqKg0K PiANCj4gSSBqdXN0IGhhZCBhICJsaWdodGx5IGNyYXp5IiBpZGVhLi4uIGlmIHdlIHJlYWxseSBu ZWVkIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgdG8NCj4gY3VycmVudCBpbXBsZW1lbnRhdGlvbnMs IHdlIGNvdWxkIG1ha2UgdGhlIFJGQyB2ZXJzaW9uIChkZWxpdmVyZWQgaW4gdGhlDQo+IGZpcnN0 IGJ5dGUgb2YgVURQIHBhY2tldCBhbmQgVENQIHN0cmVhbSkgbnVtYmVyIDQuLi4NCj4gDQo+IGJl Y2F1c2UgYWxsIHRoZSBvbGRlciB2ZXJzaW9ucyBoYWQgUEVFUiBEaXNjb3ZlcnkvSW5pdGlhbGl6 YXRpb24gbWVzc2FnZXMgYXQNCj4gdGhpcyBwbGFjZSwgd2hpY2ggYmVnYW4gd2l0aCBhIDAgdG8g My4NCj4gDQo+IFRoaXMgd2F5IChpZiBzb21lb25lIG5lZWRzIGl0KSBpdHMgcG9zc2libGUgdG8g cHJvZHVjZSBhIERMRVAgdmVyc2lvbiB0aGF0DQo+IHVuZGVyc3RhbmRzIGJvdGggdGhlIERMRVAt ZHJhZnQgdmVyc2lvbiAoYXQgbGVhc3QgdGhpbmdzIHNpbmNlIH4gZHJhZnQgNS02KQ0KPiBBTkQg YSBETEVQIFJGQyB3aXRoIGEgdmVyc2lvbiBudW1iZXIuDQo+IA0KPiBIZW5uaW5nDQoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVGhpcyBlbGVj dHJvbmljIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGNvbnRhaW5z CmluZm9ybWF0aW9uIGZyb20gaURpcmVjdCwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQsIHByb3By aWV0YXJ5CmFuZC9vciBjb25maWRlbnRpYWwuIEl0IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbApvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNz ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBvcmlnaW5hbApyZWNpcGllbnQgb3IgdGhlIHBlcnNvbiBy ZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0aGUgZW1haWwgdG8gdGhlCmludGVuZGVkIHJlY2lw aWVudCwgYmUgYWR2aXNlZCB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwKaW4gZXJy b3IsIGFuZCB0aGF0IGFueSB1c2UsIGRpc3NlbWluYXRpb24sIGZvcndhcmRpbmcsIHByaW50aW5n LCBvcgpjb3B5aW5nIG9mIHRoaXMgZW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91 IHJlY2VpdmVkIHRoaXMgZW1haWwKaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIGltbWVk aWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwo= From nobody Mon Jun 22 07:49:12 2015 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 F3E211ACDA6; Mon, 22 Jun 2015 07:49:10 -0700 (PDT) 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 59_vXoonXSuF; Mon, 22 Jun 2015 07:49:09 -0700 (PDT) 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 409221A03E3; Mon, 22 Jun 2015 07:49:09 -0700 (PDT) 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; Mon, 22 Jun 2015 15:48:43 +0100 From: Rick Taylor To: "Ratliff, Stanley" , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 14:48:42 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@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: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:49:11 -0000 On 22/06/15 15:27, Ratliff, Stanley wrote:=0A= >=0A= >=0A= >> -----Original Message-----=0A= >> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com]=0A= >> Sent: Monday, June 22, 2015 10:19 AM=0A= >> To: Henning Rogge=0A= >> Cc: Wiggins, David - 0665 - MITLL; Lou Berger; manet-ads@ietf.org; rtg-= =0A= >> dir@ietf.org; draft-ietf-manet-dlep.all@ietf.org; MANET IETF; manet-=0A= >> chairs@ietf.org=0A= >> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14=0A= >>=0A= >> On 22/06/15 14:53, Henning Rogge wrote:=0A= >>> On Mon, Jun 22, 2015 at 3:48 PM, Rick Taylor=0A= >>> wrote:=0A= >>>>> No, not for each signal... once for each incoming "network socket".= =0A= >>>>>=0A= >>>>> So once for the UDP packet (before you give the rest to the signal=0A= >>>>> processing code) and once for a TCP stream (before you start=0A= >>>>> processing signals).=0A= >>>>>=0A= >>>>> I would not count them as part of the signals, more like a prefix=0A= >>>>> before the signal(s) begin.=0A= >>>>=0A= >>>> I would definitely only want the version numbers once. In each UDP=0A= >>>> packet, and once on TCP connection start, not on every signal.=0A= >>>=0A= >>> Agreed... up to 4 times until a DLEP session is completely working...= =0A= >>>=0A= >>> one in the UDP packets each, and one at the head of the TCP stream (in= =0A= >>> both directions!)=0A= >>>=0A= >>>> The question is, how to I describe that? Have an extra 1 octet=0A= >>>> header used during initialization? Once I start writing that, why=0A= >>>> not expand it out to include all those data items only used during=0A= >> initialization?=0A= >>>=0A= >>> Whats about this?=0A= >>>=0A= >>>> 0 1 2 3=0A= >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= >>>> | Version | DLEP signal(s) ... |=0A= >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= >>>=0A= >>=0A= >> That has the advantage of simplicity!=0A= >>=0A= >> I tried to pack all the Peer_Init data items into a Peer_Init struct and= it just=0A= >> looked like a standard DLEP signal, but with strict ordering.=0A= >>=0A= >> Actually, I'm still scratching my head to work out what the problem with= the=0A= >> current method is:=0A= >>=0A= >> Byte(0) =3D Peer_Init/ACK=0A= >> Bytes(1+2) =3D Length=0A= >> Check length for sanity=0A= >> Scan data items for Version, parse version.=0A= >>=0A= >> Is the problem=0A= >=0A= > As I understand it, the problem is people are worried that, in order to p= arse for the version TLV, you have to know how to parse the signal (in gene= ral terms). A "substantial enough" (whatever that means) change in DLEP *mi= ght* render an implementation unable to "scan data items for Version, parse= version".=0A= >=0A= > I get slapped every time I've brought this up, but - sence we're only tal= king about 4 signals (Discovery, Offer, Peer_Init, Peer_Init_ACK), why not = declare that Version MUST be the first TLV in those packets (and ONLY those= packets)?=0A= =0A= Grr... please let's not make some things ordered.=0A= =0A= Rick=0A= From nobody Mon Jun 22 07:51:43 2015 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 7AD681ACDCF; Mon, 22 Jun 2015 07:51:41 -0700 (PDT) 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 KD5oHc9ps9k9; Mon, 22 Jun 2015 07:51:40 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id D23591A0397; Mon, 22 Jun 2015 07:51:39 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.203 as permitted sender) identity=mailfrom; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,660,1427774400"; d="scan'208";a="8156430" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.203]) by ironport2.idirect.net with ESMTP; 22 Jun 2015 10:51:38 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM3.idirect.net (10.250.250.203) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 22 Jun 2015 10:51:38 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Mon, 22 Jun 2015 10:51:38 -0400 From: "Ratliff, Stanley" To: Rick Taylor , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQoh7bMo+Tw3COyECGObxkTDTDb524sSRA Date: Mon, 22 Jun 2015 14:51:36 +0000 Message-ID: <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:51:41 -0000 > -----Original Message----- > From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] > Sent: Monday, June 22, 2015 10:49 AM > To: Ratliff, Stanley; Henning Rogge > Cc: Wiggins, David - 0665 - MITLL; Lou Berger; draft-ietf-manet- > dlep.all@ietf.org; MANET IETF > Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 > = > On 22/06/15 15:27, Ratliff, Stanley wrote: > > > > > >> -----Original Message----- > >> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] > >> Sent: Monday, June 22, 2015 10:19 AM > >> To: Henning Rogge > >> Cc: Wiggins, David - 0665 - MITLL; Lou Berger; manet-ads@ietf.org; > >> rtg- dir@ietf.org; draft-ietf-manet-dlep.all@ietf.org; MANET IETF; > >> manet- chairs@ietf.org > >> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 > >> > >> On 22/06/15 14:53, Henning Rogge wrote: > >>> On Mon, Jun 22, 2015 at 3:48 PM, Rick Taylor > >>> wrote: > >>>>> No, not for each signal... once for each incoming "network socket". > >>>>> > >>>>> So once for the UDP packet (before you give the rest to the signal > >>>>> processing code) and once for a TCP stream (before you start > >>>>> processing signals). > >>>>> > >>>>> I would not count them as part of the signals, more like a prefix > >>>>> before the signal(s) begin. > >>>> > >>>> I would definitely only want the version numbers once. In each UDP > >>>> packet, and once on TCP connection start, not on every signal. > >>> > >>> Agreed... up to 4 times until a DLEP session is completely working... > >>> > >>> one in the UDP packets each, and one at the head of the TCP stream > >>> (in both directions!) > >>> > >>>> The question is, how to I describe that? Have an extra 1 octet > >>>> header used during initialization? Once I start writing that, why > >>>> not expand it out to include all those data items only used during > >> initialization? > >>> > >>> Whats about this? > >>> > >>>> 0 1 2 3 > >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> | Version | DLEP signal(s) ... | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >> > >> That has the advantage of simplicity! > >> > >> I tried to pack all the Peer_Init data items into a Peer_Init struct > >> and it just looked like a standard DLEP signal, but with strict orderi= ng. > >> > >> Actually, I'm still scratching my head to work out what the problem > >> with the current method is: > >> > >> Byte(0) =3D Peer_Init/ACK > >> Bytes(1+2) =3D Length > >> Check length for sanity > >> Scan data items for Version, parse version. > >> > >> Is the problem > > > > As I understand it, the problem is people are worried that, in order to= parse > for the version TLV, you have to know how to parse the signal (in general > terms). A "substantial enough" (whatever that means) change in DLEP > *might* render an implementation unable to "scan data items for Version, > parse version". > > > > I get slapped every time I've brought this up, but - sence we're only t= alking > about 4 signals (Discovery, Offer, Peer_Init, Peer_Init_ACK), why not dec= lare > that Version MUST be the first TLV in those packets (and ONLY those > packets)? > = > Grr... please let's not make some things ordered. Tempest in a teapot... then let's just jettison the whole damned version ch= eck. You either support the protocol or you don't. Extensions are declared.= The rest of this is mental gymnastics for sake of.... what? We're all just= spinning the propellers on our beanies at this point, trying to see who ca= n generate the most lift. = Stan > = > Rick _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Mon Jun 22 07:53:43 2015 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 9DF351ACDDC; Mon, 22 Jun 2015 07:53:40 -0700 (PDT) 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 PUNoRPMkt4jA; Mon, 22 Jun 2015 07:53:39 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id B98BC1ACDD1; Mon, 22 Jun 2015 07:53:38 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5MErajU021910; Mon, 22 Jun 2015 10:53:36 -0400 From: "Wiggins, David - 0665 - MITLL" To: Rick Taylor , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhkq4BISdYAIk+JbR87kxTblJ24sfyA Date: Mon, 22 Jun 2015 14:53:36 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3517815215_52229291" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-22_02:2015-06-22,2015-06-22,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-1506220247 Archived-At: Cc: "rtg-dir@ietf.org" , "manet-chairs@ietf.org" , "manet-ads@ietf.org" , MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:53:40 -0000 --B_3517815215_52229291 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 6/22/15, 10:19 AM, "Rick Taylor" wrote: >On 22/06/15 14:53, Henning Rogge wrote: >> On Mon, Jun 22, 2015 at 3:48 PM, Rick Taylor >> wrote: >>>> No, not for each signal... once for each incoming "network socket". >>>> >>>> So once for the UDP packet (before you give the rest to the signal >>>> processing code) and once for a TCP stream (before you start >>>> processing signals). >>>> >>>> I would not count them as part of the signals, more like a prefix >>>> before the signal(s) begin. >>> >>> I would definitely only want the version numbers once. In each UDP >>> packet, and once on TCP connection start, not on every signal. >> >> Agreed... up to 4 times until a DLEP session is completely working... >> >> one in the UDP packets each, and one at the head of the TCP stream (in >> both directions!) >> >>> The question is, how to I describe that? Have an extra 1 octet header >>> used during initialization? Once I start writing that, why not expand >>> it out to include all those data items only used during initialization? >> >> Whats about this? >> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Version | DLEP signal(s) ... | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > >That has the advantage of simplicity! So let me see if I understand this proposal. In the Peer Discovery and Peer Offer signals, we'd add the version to the signal header. When the TCP connection is made, but before any signals are sent, each side sends their one-byte version number. After that, signals do not contain a version. If that's right, I count three different ways of handling the version. The last one is a no-op, but still, different from the others. I agree that this would work, but it sure seems simpler to me to just put version as a fixed part of the signal header of all signals. David --B_3517815215_52229291 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFFBPmyhBcjeIZBBd O8jSf72sRJElMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYyMjE0NTMzNVowDQYJKoZIhvcNAQEBBQAEggEAT7G0Zx8YH1M4Fqm0fv2fucE5014kmx5A n1nycTmcbAn6bmqYksGbl0sVxkHUiPf+B3ueksvVo5SZG4spTh0HCO/SpTBYsKIsjyAmz2lP FcYanp7UsiIPFh4KZjyM8iDBUeyNNdUjrnvPv9ORIrBI8GkqS/G/hjY+6DHi+ajMpUdcMbJA UeP0l9rpFhBKDb7Yjepty2IE2npzGKDUdjNsRELy+D9Yef9UAK1tPlVFhoGq/bBqqsQplVuf avsy5dg2zpCOiQR6l1KCvrFXFeYLWDYVTuxA/U4LrUgGISCu50GL7yhzqqR+Y+EmLMJUTGCa IUpBC+balAkRMm6/QQ6W2Q== --B_3517815215_52229291-- From nobody Mon Jun 22 07:54:32 2015 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 E5C131ACDEB; Mon, 22 Jun 2015 07:54:31 -0700 (PDT) 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 qRPaJDElwYlu; Mon, 22 Jun 2015 07:54:30 -0700 (PDT) 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 B697A1ACDE8; Mon, 22 Jun 2015 07:54:19 -0700 (PDT) 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; Mon, 22 Jun 2015 15:53:53 +0100 From: Rick Taylor To: "Ratliff, Stanley" , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 14:53:51 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AF302@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@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: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:54:32 -0000 On 22/06/15 15:37, Ratliff, Stanley wrote:=0A= >=0A= >=0A= >> -----Original Message-----=0A= >> From: Henning Rogge [mailto:hrogge@gmail.com]=0A= >> Sent: Monday, June 22, 2015 10:34 AM=0A= >> To: Ratliff, Stanley=0A= >> Cc: Rick Taylor; Wiggins, David - 0665 - MITLL; Lou Berger; draft-ietf-m= anet-=0A= >> dlep.all@ietf.org; MANET IETF=0A= >> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14=0A= >>=0A= >> On Mon, Jun 22, 2015 at 4:27 PM, Ratliff, Stanley = wrote:=0A= >>> As I understand it, the problem is people are worried that, in order to= parse=0A= >> for the version TLV, you have to know how to parse the signal (in genera= l=0A= >> terms). A "substantial enough" (whatever that means) change in DLEP=0A= >> *might* render an implementation unable to "scan data items for Version,= =0A= >> parse version".=0A= >>>=0A= >>> I get slapped every time I've brought this up, but - sence we're only t= alking=0A= >> about 4 signals (Discovery, Offer, Peer_Init, Peer_Init_ACK), why not de= clare=0A= >> that Version MUST be the first TLV in those packets (and ONLY those=0A= >> packets)?=0A= >>=0A= >> And then we get "version 2" which extends the maximum length of signals = to=0A= >> 32 bit to allow some awesome faster than light transmission.=0A= >=0A= > From what I hear, there's *already* a push to extend the max signal leng= th to 32 bits... And/or, if you've got to do something like that, allocate= new code points for the newer Discovery & Init signals. With a 65K numberi= ng space (earlier discussions), there will be room.=0A= >=0A= > Doesn't TLS encode its version information *into* one of the early messag= es?=0A= =0A= Yes it does, ClientHello has the version number.=0A= =0A= I still don't see the problem.=0A= =0A= Rick=0A= From nobody Mon Jun 22 07:57:04 2015 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 B09491ACDF4; Mon, 22 Jun 2015 07:57:02 -0700 (PDT) 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 qvC2C8jWk2mJ; Mon, 22 Jun 2015 07:57:01 -0700 (PDT) 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 BDF321ACDF2; Mon, 22 Jun 2015 07:57:00 -0700 (PDT) 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; Mon, 22 Jun 2015 15:56:36 +0100 From: Rick Taylor To: "Ratliff, Stanley" , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Mon, 22 Jun 2015 14:56:34 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2AF31A@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> 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: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 14:57:02 -0000 On 22/06/15 15:51, Ratliff, Stanley wrote:=0A= >=0A= >=0A= >> -----Original Message-----=0A= >> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com]=0A= >> Sent: Monday, June 22, 2015 10:49 AM=0A= >> To: Ratliff, Stanley; Henning Rogge=0A= >> Cc: Wiggins, David - 0665 - MITLL; Lou Berger; draft-ietf-manet-=0A= >> dlep.all@ietf.org; MANET IETF=0A= >> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14=0A= >>=0A= >> On 22/06/15 15:27, Ratliff, Stanley wrote:=0A= >>>=0A= >>>=0A= >>>> -----Original Message-----=0A= >>>> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com]=0A= >>>> Sent: Monday, June 22, 2015 10:19 AM=0A= >>>> To: Henning Rogge=0A= >>>> Cc: Wiggins, David - 0665 - MITLL; Lou Berger; manet-ads@ietf.org;=0A= >>>> rtg- dir@ietf.org; draft-ietf-manet-dlep.all@ietf.org; MANET IETF;=0A= >>>> manet- chairs@ietf.org=0A= >>>> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14=0A= >>>>=0A= >>>> On 22/06/15 14:53, Henning Rogge wrote:=0A= >>>>> On Mon, Jun 22, 2015 at 3:48 PM, Rick Taylor=0A= >>>>> wrote:=0A= >>>>>>> No, not for each signal... once for each incoming "network socket".= =0A= >>>>>>>=0A= >>>>>>> So once for the UDP packet (before you give the rest to the signal= =0A= >>>>>>> processing code) and once for a TCP stream (before you start=0A= >>>>>>> processing signals).=0A= >>>>>>>=0A= >>>>>>> I would not count them as part of the signals, more like a prefix= =0A= >>>>>>> before the signal(s) begin.=0A= >>>>>>=0A= >>>>>> I would definitely only want the version numbers once. In each UDP= =0A= >>>>>> packet, and once on TCP connection start, not on every signal.=0A= >>>>>=0A= >>>>> Agreed... up to 4 times until a DLEP session is completely working...= =0A= >>>>>=0A= >>>>> one in the UDP packets each, and one at the head of the TCP stream=0A= >>>>> (in both directions!)=0A= >>>>>=0A= >>>>>> The question is, how to I describe that? Have an extra 1 octet=0A= >>>>>> header used during initialization? Once I start writing that, why= =0A= >>>>>> not expand it out to include all those data items only used during= =0A= >>>> initialization?=0A= >>>>>=0A= >>>>> Whats about this?=0A= >>>>>=0A= >>>>>> 0 1 2 3=0A= >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1= =0A= >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= >>>>>> | Version | DLEP signal(s) ... |=0A= >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= >>>>>=0A= >>>>=0A= >>>> That has the advantage of simplicity!=0A= >>>>=0A= >>>> I tried to pack all the Peer_Init data items into a Peer_Init struct= =0A= >>>> and it just looked like a standard DLEP signal, but with strict orderi= ng.=0A= >>>>=0A= >>>> Actually, I'm still scratching my head to work out what the problem=0A= >>>> with the current method is:=0A= >>>>=0A= >>>> Byte(0) =3D Peer_Init/ACK=0A= >>>> Bytes(1+2) =3D Length=0A= >>>> Check length for sanity=0A= >>>> Scan data items for Version, parse version.=0A= >>>>=0A= >>>> Is the problem=0A= >>>=0A= >>> As I understand it, the problem is people are worried that, in order to= parse=0A= >> for the version TLV, you have to know how to parse the signal (in genera= l=0A= >> terms). A "substantial enough" (whatever that means) change in DLEP=0A= >> *might* render an implementation unable to "scan data items for Version,= =0A= >> parse version".=0A= >>>=0A= >>> I get slapped every time I've brought this up, but - sence we're only t= alking=0A= >> about 4 signals (Discovery, Offer, Peer_Init, Peer_Init_ACK), why not de= clare=0A= >> that Version MUST be the first TLV in those packets (and ONLY those=0A= >> packets)?=0A= >>=0A= >> Grr... please let's not make some things ordered.=0A= >=0A= > Tempest in a teapot... then let's just jettison the whole damned version = check. You either support the protocol or you don't. Extensions are declare= d. The rest of this is mental gymnastics for sake of.... what? We're all ju= st spinning the propellers on our beanies at this point, trying to see who = can generate the most lift.=0A= >=0A= =0A= Lets leave the Version as a data item: 1 octet, version 1. If you can't = =0A= find the data item then it's not DLEP.=0A= =0A= Rick=0A= =0A= From nobody Mon Jun 22 08:00:04 2015 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 3CB0C1ACE09 for ; Mon, 22 Jun 2015 08:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.81 X-Spam-Level: X-Spam-Status: No, score=-11.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBycdJb6ru06 for ; Mon, 22 Jun 2015 08:00:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979E51ACDB1 for ; Mon, 22 Jun 2015 08:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8734; q=dns/txt; s=iport; t=1434985201; x=1436194801; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1uhMn1HN+dxKI9/N7fBYb7IhSNwMj2a71sZd2dx4l7E=; b=dXq/QdMOrz0olTQRsUmjwJIPXJCdFfOWz0ZEaHoDz2YTeQxmt6anfZ2f CD25QMibJ5U8G1NSYyoij9w2a+IU+NpGDWg042sVHoQIXRu8sOb/zO3ei ImVXgHVGB3DOqgwB2d0yqrNB2s3yf7vWuAscrAkYher2kvkJm9kRay+Qe I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AcBQBpIYhV/4kNJK1cFoIvS1RfBrlahhaFfAKBODsRAQEBAQEBAYEKhCMBAQSBCQIBCD8HMhQHAQYDAgQTiC8NygIBAQEBAQEEAQEBAQEBARuLRYUNhCsFk30Bi02RIocPJmODFm8BgUWBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,660,1427760000"; d="scan'208,217";a="5544420" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP; 22 Jun 2015 15:00:00 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5MF00Ve010834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Jun 2015 15:00:00 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.106]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Mon, 22 Jun 2015 10:00:00 -0500 From: "Alvaro Retana (aretana)" To: "manet@ietf.org" Thread-Topic: [gaia] Agenda: IRTF GAIA Research Group Meeting at the IETF in Prague Thread-Index: AQHQrPwcX60CIiVD/kaYOOVafGVP1Q== Date: Mon, 22 Jun 2015 15:00:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_D1AD9B1AB92CFaretanaciscocom_" MIME-Version: 1.0 Archived-At: Subject: [manet] FW: [gaia] Agenda: IRTF GAIA Research Group Meeting at the IETF in Prague 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: Mon, 22 Jun 2015 15:00:03 -0000 --_000_D1AD9B1AB92CFaretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FYI.. On 6/20/15, 4:35 AM, "gaia on behalf of Arjuna Sathiaseelan" on behalf of arjuna.sathiaseelan@cl.= cam.ac.uk> wrote: All - the final agenda for the GAIA RG meeting at the IETF in Prague is bel= ow: Agenda: WEDNESDAY, July 22, 2015: 0900-1130 Morning Session I (Room: Berlin/Brusse= ls) 1. Welcome (10 mins) (Chairs: Arjuna Sathiaseelan & Mat Ford) 2. Alternative Networks draft status and Traffic Optimisation (20 mins): J= ose Saldana (University of Zaragoza) 3. Broadband to the Village (15 mins): Nalini Elkins (InsideStack) 4. Wireless for Communities (W4C) (15 mins): Neil Harper (ISOC) 5. TVWS: Challenges and Experiences from Latin America and Africa (20 mins)= : Andres Arcia Moret (University of Cambridge) 6. Rural PAWS (20 mins): Gorry Fairhurst (Aberdeen) 7. RIFE =96 building the Internet for Everybody (20 mins): Dirk Trossen (I= nterDigital) 8. Service Centric Networking for the Developing World (20 mins): Arjuna Sa= thiaseelan (University of Cambridge) 9. Wrapup (10 mins) Regards -- Arjuna Sathiaseelan Personal: http://www.cl.cam.ac.uk/~as2330/ N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d --_000_D1AD9B1AB92CFaretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <454B3658A348244ABCF8426A5A9713C8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
FYI..

On 6/20/15, 4:35 AM, "gaia on behalf of Arjuna Sathiaseelan"= <gaia-bounces@irtf.org on = behalf of arjuna.sathiaseelan@cl.= cam.ac.uk> wrote:

All - the final agenda for the GAIA RG meeting at the IETF in Prague i= s below:

Agenda: 
W=
EDNESDAY, July 22, 2015: 09=
00-1130  Morning Session I (Room: Berlin/Brussels)

1. Welcome (10 mins) (Chairs: Arjuna Sathiaseelan & Mat Ford)

2. Alternative Networks draft stat= us and Traffic Optimisation (20 mins):  Jose Saldana (University of Zaragoza) =
= 3. Broadband to the Village (15 mins):  Nali= ni Elkins (InsideStack)
=
= 4.  Wireless for Communities (W4C) (15 mins): Neil Harper (ISOC)

5. TVWS: Challenges and Experience= s from Latin America and Africa (20 mins) : Andres Arcia Moret (University of Cambridge)

6.  Rural PAWS (20 mins): Gorry Fairhurst (Aberdeen)

7.  RIFE =96 building the Internet for Everybody (20 mins): Dirk Trossen (InterDigital)

8. Service Centric Networking for the Developing World (20 mi= ns): Arjuna Sathiaseelan (University of Cambridge)

9. Wrapup (10 mins)

Regards
--
Arjuna Sathiaseelan
Personal: ht= tp://www.cl.cam.ac.uk/~as2330/
N4D Lab: = http://www.cl.cam.ac.uk/~as2330/n4d
 --_000_D1AD9B1AB92CFaretanaciscocom_-- From nobody Mon Jun 22 08:23:01 2015 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 803CC1ACEA6; Mon, 22 Jun 2015 08:22:59 -0700 (PDT) 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 20eBDlZcvZC0; Mon, 22 Jun 2015 08:22:58 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4C63C1ACEA5; Mon, 22 Jun 2015 08:22:58 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,660,1427774400"; d="scan'208";a="17723530" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport.idirect.net with ESMTP; 22 Jun 2015 11:22:55 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 22 Jun 2015 11:22:54 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Mon, 22 Jun 2015 11:22:54 -0400 From: "Ratliff, Stanley" To: Rick Taylor , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQoh7bMo+Tw3COyECGObxkTDTDb524uicQ Date: Mon, 22 Jun 2015 15:22:53 +0000 Message-ID: <5d3d428c21f743dc9b1cb1c134122fe4@VAUSDITCHM3.idirect.net> References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AF31A@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2AF31A@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 15:22:59 -0000 > = > Lets leave the Version as a data item: 1 octet, version 1. If you can't = find the > data item then it's not DLEP. > = Changing the version to a single octet and leaving everything else alone wo= rks for me. = Stan _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Mon Jun 22 11:09:10 2015 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 C5E9A1A0171 for ; Mon, 22 Jun 2015 11:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 s0D8q_sdY2cN for ; Mon, 22 Jun 2015 11:08:48 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 679F31A011D for ; Mon, 22 Jun 2015 11:08:44 -0700 (PDT) Received: (qmail 989 invoked by uid 0); 22 Jun 2015 18:08:41 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 22 Jun 2015 18:08:41 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id jVyD1q0032SSUrH01VyG8K; Mon, 22 Jun 2015 11:58:19 -0600 X-Authority-Analysis: v=2.1 cv=RekDVTdv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=5vjwwrbCAAAA:8 a=48vgC7mUAAAA:8 a=OomOZXYVBQNdkOQF21YA:9 a=dlku61Uh0as-PWOQ:21 a=Zv-piLpw3kWVFNjJ:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ygZUSfKE3DEwU1Bzrm1DGtKMfJE/qVJCGjBoTyM2zwc=; b=Hc/iIyNGNMnKaARHqgHfIJ0ZDtS6TrZBmymoZAJoyI64e9QvH9Ae2VAqK6IhQOouPkX8Jj10UHGGbZtMlj5uiq3PyJ7frP7WVoNqQiQFYLCw3ikE1TcdwxAmKeApk/11; Received: from box313.bluehost.com ([69.89.31.113]:37637 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z7693-00087N-SG; Mon, 22 Jun 2015 12:08:34 -0600 Message-ID: <55884F14.2040505@labn.net> Date: Mon, 22 Jun 2015 14:08:20 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rick Taylor , Henning Rogge References: <5575E8A7.6030508@labn.net> <558337FF.5040907@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: manet-ads@ietf.org, rtg-dir@ietf.org, MANET IETF , manet-chairs@ietf.org, draft-ietf-manet-dlep.all@ietf.org Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 18:08:51 -0000 Rick, Thanks for the response. See below. On June 22, 2015 7:00:44 AM Rick Taylor wrote: >... > >> > >>> ... > > > >>> Major Issues: > >>> > >>> - The length field of the generic data item (i.e., TLV) is only 8 > >>> bits. While 255 bytes (assuming that this is the unit of measure, > >>> which BTW isn't specified) is big enough today, allowing for > >>> larger will greatly simplify things when 255 isn't enough. -- > >>> We've run into this in RSVP and it's a real pain. > >> On the other side the largest data item we have at the moment is 18 > >> bytes (IPv6 connection point). I am not really seeing lots of > >> use-cases for large data items in DLEP. > > > > My experience in the past has been that unknown uses show up later and > > make this an issue that needs to be solved by some ugly semantic > > fragmentation, so if possible, I think it should be fixed. > > > >> Still, changing the TLV length to 16 bit would be trivial to do... but > >> would this mean we also should change the signal length field to 4 > >> bytes? > > > > I wasn't suggesting this and I don't think so. 2^16 is a pretty big > > message. > > There is nothing stopping an extension of the data item length to 2^16 > octets, but as Henning pointed out, that would suggest an increase of > the signal length field to 2^32 (as signals 'contain' data items). I think both being 2^16 is fine. It just means data items have a length constraint that is less than the field size. Nothing unique in that. > > The reason we haven't gone for 2^16 currently are: > > 1) We have no data items > ~20 octets. > > 2) We wanted to keep the data items and signals 'short and sweet' in > form. An implementation could use small stack allocated buffers in > embedded hardware rather than worrying about bigger blocks of memory. > > But: Adding big data items later would be more difficult. > > Note: There is no 'bits on the wire' performance concerns here, DLEP is > over the local link. > > There is a third way: If the length field in the signal is replaced > with a count field, then both can be kept at 16 bits, but it makes > parsing more complicated. > > Can I ask for some +1/-1's from the list on this one please? It is not > a major change to the document. > My experience is that usage of successful protocols go beyond what's originally envisioned. So unless the constraint is important I'd "be liberal" here and go for the larger size. > > > >>> - Version number is currently defined as a data item. This means a > >>> signal (i.e., message) needs to be potentially fully parsed to > >>> discover what version is being used. This precludes basic format > >>> changes to the protocol. Perhaps the Discovery and Init Signals > >>> should be special cased to include version in their formats. (And > >>> shorten version to 8 bits from 32, as mentioned below). > >> Putting it into the UDP based discovery packets as a "header" could > >> work... they are a bit special anyways (UDP) and we don't need to > >> repeat the version later. > > > > Lots of options here. But recall UDP discovery is optional per current spec. > > I see no problem with shortening version to 16 bits (major octet, minor > octet) I never want to see DLEP version 65538.0! > > I see the point of holding the version number at a fixed offset in the > initial messages of the protocol, and it is something we can definitely > do for the UDP discovery messages, as Henning pointed out, they are > special anyway. > > I am loathe to do it to the Initialization signals, as it adds special > case code and text. I think it is okay to allow an implementation *not* > using discovery to expect a process on the reserved address/port > combination to be using some version of DLEP, as long as later DLEP > versions ensure back compatibility. > > ... > > > > >> > >>> - TCP session management is not defined, nor is the relationship > >>> with TCP and DLEP sessions fully defined. For example: > >>> > >>> o Closing the TCP session is only mentioned in one place and in a > >>> way that is inconsistent with the expected protocol behavior > >>> (close TCP before ACK is received). > >> Maybe this should be "closing the DLEP session and not using the > >> active TCP session anymore" ? > >> > >>> o What happens when a DLEP session is terminated, can the TCP > >>> session be reused or must it be closed too? > >> No, I think the DLEP strategy is "start from scratch"... when you > >> terminate a DLEP session you go back to the discovery mechanism to > >> start a new one. > > > > Whichever reasonable approach is taken it just needs to be explicitly > > documented. > > We favour a start from scratch approach. But it does need to explicitly > stated somewhere. > WFM, just needs to be documented. > > > >> > >>> - There is no transaction model defined. For example, it's > >>> completely unclear if only one unacknowledged Signal allowed at a > >>> time, or perhaps just one per signal type is allowed, or perhaps > >>> there are no restrictions. This needs to be explicit. > >> I think we don't need restrictions here because of TCP. The other side > >> WILL answer to eachof our signals or the TCP session will be > >> terminated. > > > > I don't think TCP helps (or hurts here). This is a question of what > > different implementations will choose to do / support WRT signals of the > > same or different types being processed in parallel. > > Particularly with the Request signals, there is a weakness in the text > about transactions that needs to be addressed. This is one of those > areas where those involved early on have a clear idea, but it isn't > clear in the text. > thanks > > > >>> - What is the purpose of retries and timeouts over TCP? Retries > >>> aren't needed over TCPs and it's unclear whey they are being used. > >> We want to know when the connection between radio and router is > >> lost... this can take a LONG time when the router is mostly listening > >> to the Radio (TCP timeout is much to long for our use-case), so we use > >> the Heartbeats. > > > > This comment relates to the per signal acks and retries. I didn't > > include the connection failure detection covered by the heartbeat signal > > in this comment. > > The retries and heartbeats are to detect a failure in the process using > the TCP connection, rather than a failure of the connection itself. > From experience in the MANET space, complex routers and radios can > crash internally/lose control plane long before the TCP session times out. > Again, this is *not* the point I raised. > > > >>> - The higher level implications of ACKs, over TCP, isn't really > >>> clear. It seems ACKs are defined for multiple purposes: reliable > >>> transport, transaction acknowledgment and transaction results. Of > >>> course the first isn't needed, and implications of the others > >>> should be clear. For example, in section 7.10, why would there be > >>> a retry when receiving a Destination Up ACK signal indicating an > >>> error? > >> The DLEP "ACK Signals" are more a response to a "request signal"... > >> transaction acknowledgement and result. > > ACKs are intended as an processing acknowledgement rather than a receipt > acknowledgement, i.e. "I have done/not done what you asked". > Okay, I think calling them something like responses rather than acks would clarify this. And the purpose of retries is??? > >> > >>> - There is no discussion on scaling considerations. Are there really > >>> none? For example, how often might be appropriate to issue/limit > >>> Peer Updates based to changes in link quality, or how to handle > >>> the case where a large number (all or most) of destinations go > >>> down. > >> Just send as fast as you want and let TCP (buffer) take care of the > >> rest... both Destination up/down are small signals, so it shouldn't be > >> a problem. > > The assumptions behind this "shouldn't part of this" is what should be > > discussed... > > Yes, there is no text about rate limiting updates. Not from a TCP > datarate perspective, but from a processing perspective. We don't > really want to predict the performance of processors by stating hard > rules on rate-limiting. > > This only applies to Destination_Updates, as everything else is > throttled by waiting for ACKs. (Made clearer when some text on > transactions is put in) > Seems like some discussion on this is warranted. > > > >> And you are only allowed to send Destination Updates when > >> you received the Destination ACK. > > > > Where is this restriction specified? I don't recall seeing it. > > It isn't mentioned, but is expected. The text will have to be improved. > I think there is a need for a section on transactions. > > > > >>> - There are 13 places where the protocol allows implementation to > >>> define their own 'heuristics'. Some of these seem unnecessary due > >>> to the TCP point raised above, but any that remain in the protocol > >>> should be fully specified to ensure predictable/consistent > >>> behavior from implementations. > >> No comment on this one. > > As with rate-limiting, this is a can of worms we have intentionally not > opened. We will have a careful look at every place heuristics are > mentioned and when possible suggest some sensible defaults. > I think this will be an interoperability and conformance testing nightmare. Also, keep in mind a standard helps users know what they should expect from an implementation / vendor and this leaves major behaviors wide open . > >> > >>> - Data Items are defined for "Extensions" and "Experimental > >>> Definition" (Sections 8.7 and 8.8). Both seem to support for > >>> optional mechanisms, but the former uses assigned numeric values, > >>> why the latter uses UTF-8 strings. > >>> o What, if any, is the intended distinction/relationship between > >>> these? > >>> o How does an "Experimental Definition" become standardized? > >> As far as I understand this "Experimental Definition" is something you > >> use in the lab... you can have a maximum of one experiment for DLEP, > > Interesting -- where is this restriction defined? Section 7.3 says > > that "one or more" are allowed. > > > >> so this is more to make sure your special "work in progress" code does > >> not collide too hard with a standard radio/router. > > It's pretty unclear from the spec how experimental definitions are to be > > used -- or if they belong in standards track document at all. > > > >> On the other side you can support as many "Extensions" as you want... > >> and I expect this WG to standardize a few additional of them after > >> DLEP becomes a RFC. > > okay, look forward to seeing an IANA allocation policy for these. > > I have covered this in another mail, so I won't repeat. (see Section 11.6) > okay, will go looking for it. > > > >> > >>> - Sections 8.19 and 8.20 define "Resources" related Data Items. The > >>> definition related to these basically says a resources is "An > >>> 8-bit integer percentage, 0-100, representing the amount of > >>> resources allocated to receiving|transmitting data.". If I were > >>> implementing this protocol, I'd have no idea how to produce, > >>> update or use this information. I think there is some missing > >>> informative and normative (RFC 2119) text related to these > >>> formats. > >> My only idea about them would be "battery level"... not sure how > >> useful it is to query the radio about this. > > > > some context would be great. -- sounds like its akin to a routing metric. > > > >>> - Sections 8.21 and 8.22 (Relative Link Quality) have a similar > >>> problem of being under described, in particular it's unclear if > >>> there's a meaningful, non-proprietary definition for link quality > >>> that an implementation is to act on or if the passed value is just > >>> passed for as monitoring information. Either way, this needs to > >>> be clarified. > >> It seems the radio vendors really like this field. The reason why we > >> made "max/current link speed" mandatory is to make RLQ at least > >> reasonable useful. > > same comment. > > The Resources and RLQ metrics are there as DLEP builds upon the work > done in RFC5578. I have always considered Resources to be some > indication of 'work-load' on the modem rather than explicit battery > level. Perhaps the descriptive text needs to be expanded. > yes, please. > > >>> - Section 9 defines a "credit-windowing scheme analogous to the one > >>> documented in [RFC5578]". It describes how credits are exchanged, > >>> but it provides zero definition on the implications or use of > >>> credits relative to the data plane. > >>> > >> No comment on this one. > > This is one for Stan. Credit-windowing is his baby. > > >> > >>> - Multiple ways to implement the same function are allowed, e.g., > >>> optional presence of Status, Interval and TCP port. Generally > >>> allowing such complicates testing and leads to interoperability > >>> issues. The document should pick one way and require it. > >> I think "no status TLV" is always "everything is fine"... > > We are currently happy with the way this works. If an optional data > item is missing, then the default value is used. This should be > explicitly stated whenever an optional data item can be omitted. options make conformance and interoperability testing much harder. In general, if they don't serve a specific purpose options *should* be eliminated. Too many options have dead-ended protocols in the past. > > >> > >>> - The document doesn't state if there are any ordering requirements > >>> on data items. It should be explicit on this, e.g., there are no > >>> ordering requirements on the placement of Data Items within > >>> Signals. > >> I think is exactly as most (all?) of us have implemented it... no > >> ordering required. > > > > Cool, then this is just a simple matter of documenting "what everyone > > implements". > > Section 6 states: "There is no restriction on the order of data items > following a signal" > Okay missed that. Certainly for version number this is probably not the best answer. For everything else, don't really have an opinion. > > > >>> - The required and optional data items that are permitted on a > >>> signal isn't always clear. For example are 0/1/N copies of a > >>> particular Data Item required/allowed. Using something like ABNF > >>> would really help formalize and clarify this. > >> Can you give an example where this is undefined? As far as I can see > >> the draft explicitly states what and how often you can use TLVs per > >> signal. > > > > I think the experimental data item discussion above is a perfect > > example. You though only one is allowed the spec is vague in section > > 8.8 and explicit in 7.3. -- Narrative lacks precision and is easily > > misread. Something like ABNF is far more transparent. > > Section 6 states: "...the multiplicity of duplicate data items is > defined by the definition of the signal declared by the type in the > signal header." > > We have attempted to enumerate the multiplicity of every data item in > each signal. If we have missed one please point it out. > > Section 3.3 states: "Multiple Experimental Definition data items MAY > appear in the Peer Initialization/Peer Initialization ACK sequence." > > I have tried to define ABNF, but I struggle with defining the > multiplicity and optional ordering rules, any advice gratefully received. > I have done far too much ABNF so to me this isn't too hard. Unicast me what you have and I'll provide feedback. > > > >>> - The document doesn't clearly delineate from informative/narrative > >>> text, normative / required processing procedures, and message > >>> formats. This by itself is not necessarily a major issue, it just > >>> makes it harder to (write,) review and implement the protocol. > >>> What is a major issue is that this approach allows for duplicate > >>> (and sometimes contradictory) normative procedures and for > >>> omissions in procedures (particularly related to exception/error > >>> processing). Specific examples are included above and below. It > >>> would be best to ensure that each required processing behavior is > >>> defined just once and in a consistent way. > > This is a hangover of the major rewrites that have occurred over the > last 14 versions. Let us have another pass at the text and we can see > what we can do. > > > >>> > >>> - The security consideration section is inadequate. This section > >>> should address the security of the DLEP protocol, not user > >>> traffic. It should include an analysis of risks/threats/possible > >>> exploits and how these are mitigated by the protocol. rfc6952, > >>> and the protocols it references can serve as examples. > >> DLEP is only on the local ethernet connection between the radio and > >> the router... it is NOT spoken between different router/radio > >> components of a network. RFC6952 is talking about securing > >> communication over the routed network. > > > > This is a scoping of the problem that should go into a security the > > section. RFC4204 covers a similar scoped protocol, although it's > > security considerations section is quite dated. > > We have done no analysis of a malicious peer in a DLEP session as the > nature of the link-local connectivity made it seem unnecessary. Are you > suggesting that we need to address this? I'm suggesting that the IESG/Security review will block this document until there is a substantive Security Consideration section. I've just pointed to some examples that may help construct one. ...> > > > > > >>> - Section 2: Assumptions > >>> This section includes informative and normative text so is more > >>> than just Assumptions. Personally, I'd remove all normative text > >>> from the section. > >>> > >>> - There are no specific rules related to UDP header formation. > >> UDP header formation? > > format. I.e., what addresses and ports must be used. > > > > Does Section 5.1 not cover this? > No. Not every implementation may use sockets. Also much of the text relates to TCP socket init. I think a sentence that says something like: For the Peer Discovery signals the IP destination address MUST be set to the DLEP link-local multicast address and port (TBA), there is no restriction on the UDP source port. For Peer Offer signals the IP destination address and port MUST be set to the source IP address and Port contained in the received Peer Discovery signal, the source IP address and port MUST be set to the DLEP port. For both signals, the source IP address MUST be set to the IP address that will be used in subsequent DLEP TCP connections. > >> > >>> - Sections 8.10->8.17. Isn't add/drop indicator needed for subnets > >>> in destination update signals? > >> I think we talked about this and the reason was that subnets are only > >> as "fixed settings" supported. > > I'm sorry I don't understand your response. Are you saying subnet > > reconfiguration requires a session reset? > > Subnet reconfiguration requires a session restart. fine. this needs to be explicit. > > > > >>> - The IANA Considerations sections must follow RFC2360. > >>> - New registries must include initial values, which are defined in > >>> the document. (The document currently has many TBDs that should > >>> be replaced.) > >> I didn't know about this, I have always seen Drafts with TBDx... > > > > TBD is right for existing registries. For new registries IANA doesn't > > have any policies or guidance. This comes from the document that > > establish the registries, i.e, this one. > > We shall suggest some values. Again, whatever for new registries the document defining the registry *must* define initial values. > Probably from the existing interoperable > implementations. Makes sense. > > > > >> > >>> - New registries need an allocation policy, e.g.: > >>> The registry should be established with registration policies of > >>> "Standards Action" (for Standards Track documents) and > >>> "Specification Required" (for other documents). The designated > >>> expert is any current WG chair. > > This is one for Stan. > > >>> > >>> Nits: > >>> > >>> - The document introduces the terms "signals" and "data items" for > >>> what is commonly called "messages" and "TLVs" (or objects) in > >>> other protocols. It's probably too late to change this, but I > >>> think the introduction of unique terminology is counter > >>> productive > > TLVs was rejected as a name, as both signals and data items are > Type-Length-Value encoded. Signals was selected as they are 'events' > rather than RPCs, and I don't follow -- but doesn't really matter as topic seems to be OBE. >it might be a bit late to change the terminology. > > >>> > >>> - Use of RFC 2119 conformance language is a bit rough, and there are > >>> words in all caps that are not defined in RFC2119. Take a look at > >>> http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuideline for some > >>> suggestions. > > We will have another pass. Can you point out some examples please? Just a few picked at random-- *not* the full list: Section 3. the first two MUSTs are duplicative, the same requirement is listed for a third time in the third paragraph with a lower case "required". The "OPTION" and "MAY" clauses are duplicative. Section 4: "DLEP Does NOT specify..." Section 7.3: "there is NO support" > ... > > Hope that helps? > Yes. Thanks. Lou > Rick > From nobody Mon Jun 22 11:11:14 2015 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 218031A0140 for ; Mon, 22 Jun 2015 11:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 tjUW19VEbkbB for ; Mon, 22 Jun 2015 11:11:12 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id EA7411A00D8 for ; Mon, 22 Jun 2015 11:11:11 -0700 (PDT) Received: (qmail 27128 invoked by uid 0); 22 Jun 2015 18:11:10 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 22 Jun 2015 18:11:10 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id jc3s1q0292SSUrH01c3vcJ; Mon, 22 Jun 2015 18:03:58 -0600 X-Authority-Analysis: v=2.1 cv=auUhV0pV c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=6SJT_ALYCh_T8znH6rMA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=sethlTmfk5D7NoUVJtJPl88B8D+wbs3FWNHcMKQ9xN0=; b=JEcnSmAtK5jAMdUWA+tR4VJrkjgqi+aKOzoTo4yO18RHA9E/P7JiEwcp9EAF5urCGVWXWFIgWt0wcRZo0rm9dRj1qNVeXzrIrsJ6g1eliHPBrqYJVKzTSLce1PUfnxBH; Received: from box313.bluehost.com ([69.89.31.113]:37826 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z76BT-00005I-QG; Mon, 22 Jun 2015 12:11:03 -0600 Message-ID: <55884FAD.2070005@labn.net> Date: Mon, 22 Jun 2015 14:10:53 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Ratliff, Stanley" , Rick Taylor , Henning Rogge References: <5575E8A7.6030508@labn.net> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AF31A@tss-server1.home.tropicalstormsoftware.com> <5d3d428c21f743dc9b1cb1c134122fe4@VAUSDITCHM3.idirect.net> In-Reply-To: <5d3d428c21f743dc9b1cb1c134122fe4@VAUSDITCHM3.idirect.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 18:11:13 -0000 Do you mean leave version as a data item and encoded in any order? Not exactly typical and means you are limiting the format of messages carrying version numbers. (Think about how IP would work if version was encoded as an IPv4 Option.) Lou On 6/22/2015 11:22 AM, Ratliff, Stanley wrote: >> Lets leave the Version as a data item: 1 octet, version 1. If you can't find the >> data item then it's not DLEP. >> > Changing the version to a single octet and leaving everything else alone works for me. > > Stan > > > > _____________________________________________________ > This electronic message and any files transmitted with it contains > information from iDirect, which may be privileged, proprietary > and/or confidential. It is intended solely for the use of the individual > or entity to whom they are addressed. If you are not the original > recipient or the person responsible for delivering the email to the > intended recipient, be advised that you have received this email > in error, and that any use, dissemination, forwarding, printing, or > copying of this email is strictly prohibited. If you received this email > in error, please delete it and immediately notify the sender. > _____________________________________________________ > > From nobody Mon Jun 22 11:20:56 2015 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 A01931A09C9 for ; Mon, 22 Jun 2015 11:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 dCknAIEieXyi for ; Mon, 22 Jun 2015 11:20:53 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 5E58D1A0193 for ; Mon, 22 Jun 2015 11:20:53 -0700 (PDT) Received: (qmail 14101 invoked by uid 0); 22 Jun 2015 18:20:53 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 22 Jun 2015 18:20:53 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id jcDe1q00i2SSUrH01cDhWX; Mon, 22 Jun 2015 18:13:41 -0600 X-Authority-Analysis: v=2.1 cv=auUhV0pV c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=0jT5QnzcyqIVTuSwSLMA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=YOAapcqcE308f/2MsCFK/SuSFkwaCXQbFbWFa648YeI=; b=WIeYBlUZM5c/Ro3hDI01L1lmjXacDqwnMKe7zXqlG0EvozD+piN35YiTQDHiCn0/4Fg6hMAB4kVY5I34KgYGlrHlmjo/eYnY9Emwj5SPvjiOuULItsewc12vmPFoi369; Received: from box313.bluehost.com ([69.89.31.113]:38748 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z76Kv-0002Fx-T3; Mon, 22 Jun 2015 12:20:49 -0600 Message-ID: <558851F6.3040908@labn.net> Date: Mon, 22 Jun 2015 14:20:38 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Ratliff, Stanley" , Rick Taylor , Henning Rogge References: <5575E8A7.6030508@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> In-Reply-To: <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 18:20:54 -0000 Stan, On 6/22/2015 10:51 AM, Ratliff, Stanley wrote: > ... > Tempest in a teapot... then let's just jettison the whole damned version check. You either support the protocol or you don't. Extensions are declared. The rest of this is mental gymnastics for sake of.... what? We're all just spinning the propellers on our beanies at this point, trying to see who can generate the most lift. > > > Stan > Actually, killing version numbers in the protocol is just fine assuming that the well-known IANA assigned UDP and TCP ports are defined to map to DLEPv1. Any future incompatible change would just need to get new port numbers. Lou PS Yes, I have no idea if you were joking or not. From nobody Mon Jun 22 11:27:09 2015 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 3B67E1A1A27; Mon, 22 Jun 2015 11:27:06 -0700 (PDT) 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 47k9e3vRtdec; Mon, 22 Jun 2015 11:27:03 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (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 A6C651A19E3; Mon, 22 Jun 2015 11:26:58 -0700 (PDT) Received: by wgbhy7 with SMTP id hy7so148682834wgb.2; Mon, 22 Jun 2015 11:26:57 -0700 (PDT) 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=AWKu6cS3l/XLmv4NQ+TYNm3IKOYUiaQhRpk63gJIv6I=; b=lb536CFTzdhiMU2oTg6bc5etbN5BDNboTNw7Eu+1ZKgqit1Sbob+hfxb8ibgUUK6Ov xI3eQ1uBoV/jQgUtc4opFz3TJDMstXdFE46TzHZSszln0tTt72m/9BIRmVvWmsm4Nmds wLunGqeT7j74QPidX9tvNbYmEVs3rqOWKemN2c/wKLPQkfX6yH3cy/cNy7XKDulG1j+Y A+4DVUJq9acGDwm9iBHsvjrarQPM4kxW70GMYy6nRNptvNa1xKUl70rf70GCf9EBq6v7 R5t6W7SBcUs046Ss/LM9aRgr+b+8o0hGIln93PerjHonTkxRGbLMKVuXNdTKqDltCS13 aSEg== X-Received: by 10.180.88.99 with SMTP id bf3mr20322851wib.75.1434997617437; Mon, 22 Jun 2015 11:26:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Mon, 22 Jun 2015 11:26:37 -0700 (PDT) In-Reply-To: <558851F6.3040908@labn.net> References: <5575E8A7.6030508@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> From: Henning Rogge Date: Mon, 22 Jun 2015 20:26:37 +0200 Message-ID: To: Lou Berger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 18:27:06 -0000 On Mon, Jun 22, 2015 at 8:20 PM, Lou Berger wrote: > Stan, > On 6/22/2015 10:51 AM, Ratliff, Stanley wrote: >> ... >> Tempest in a teapot... then let's just jettison the whole damned version= check. You either support the protocol or you don't. Extensions are declar= ed. The rest of this is mental gymnastics for sake of.... what? We're all j= ust spinning the propellers on our beanies at this point, trying to see who= can generate the most lift. > Actually, killing version numbers in the protocol is just fine > assuming that the well-known IANA assigned UDP and TCP ports are defined > to map to DLEPv1. Any future incompatible change would just need to get > new port numbers. I think it could work well, especially if we increase the tlv-value length and maybe tlv-type length. Henning From nobody Mon Jun 22 11:27:54 2015 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 1FDF21A1A2D; Mon, 22 Jun 2015 11:27:53 -0700 (PDT) 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 oZmSuKnqoall; Mon, 22 Jun 2015 11:27:51 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9A46E1A1A27; Mon, 22 Jun 2015 11:27:51 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.201 as permitted sender) identity=mailfrom; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,660,1427774400"; d="scan'208";a="8163740" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.201]) by ironport2.idirect.net with ESMTP; 22 Jun 2015 14:27:51 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM1.idirect.net (10.250.250.201) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 22 Jun 2015 14:27:50 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Mon, 22 Jun 2015 14:27:50 -0400 From: "Ratliff, Stanley" To: Lou Berger , Rick Taylor , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQoh7bMo+Tw3COyECGObxkTDTDb524sSRAgAB98wD//71+IA== Date: Mon, 22 Jun 2015 18:27:49 +0000 Message-ID: <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> References: <5575E8A7.6030508@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC391@tss-server1.home.tropicalstormsoftware.com> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> In-Reply-To: <558851F6.3040908@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 18:27:53 -0000 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Monday, June 22, 2015 2:21 PM > To: Ratliff, Stanley; Rick Taylor; Henning Rogge > Cc: Wiggins, David - 0665 - MITLL; draft-ietf-manet-dlep.all@ietf.org; MA= NET > IETF > Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 > = > Stan, > On 6/22/2015 10:51 AM, Ratliff, Stanley wrote: > > ... > > Tempest in a teapot... then let's just jettison the whole damned version > check. You either support the protocol or you don't. Extensions are decla= red. > The rest of this is mental gymnastics for sake of.... what? We're all just > spinning the propellers on our beanies at this point, trying to see who c= an > generate the most lift. > > > > > > Stan > > > = > Actually, killing version numbers in the protocol is just fine assumi= ng that > the well-known IANA assigned UDP and TCP ports are defined to map to > DLEPv1. Any future incompatible change would just need to get new port > numbers. > = > Lou > = > PS Yes, I have no idea if you were joking or not. Lou, = Sorry. I was (somewhat) joking... ;-) I sort-of like the idea of allocating a new port number in the event that t= here's a radical enough change in DLEP to warrant a new version... But, I s= till go back to TLS - it introduces version numbers inside of TLS-parsable = messages, I think. Rick mentioned that version information is in the Client= Hello. So like Rick, I'm just not seeing the criticality. Regards, Stan _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Mon Jun 22 11:38:19 2015 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 5C6D41A1A30 for ; Mon, 22 Jun 2015 11:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 t4AC3nHAx1Zj for ; Mon, 22 Jun 2015 11:38:17 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id B59A21A1AFC for ; Mon, 22 Jun 2015 11:38:14 -0700 (PDT) Received: (qmail 11131 invoked by uid 0); 22 Jun 2015 18:38:14 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy9.mail.unifiedlayer.com with SMTP; 22 Jun 2015 18:38:14 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id jWTp1q00C2SSUrH01WTsGD; Mon, 22 Jun 2015 12:27:53 -0600 X-Authority-Analysis: v=2.1 cv=RekDVTdv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=e6mfScHLdAOPG8wbvY8A:9 a=UN5-nWSFdcbZudCg:21 a=g82AgX9fn2-EQH1y:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=l9gzODQmgjH3HhaR4onteu7qUFGav+WGAvS4N2SyDGE=; b=dUR1N7l9eQZ6VFcHDy6IPxvkYzE93mMzpc876wSzJYVSoL5ANLYAsNegNuZbjAGxvwWO0fEOepkrYCw2Kntx/+W2+sYyQmdr8yW8MEYY0vp+OxPXXVlDMx1kXcSOpJ+8; Received: from box313.bluehost.com ([69.89.31.113]:39654 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z76bi-00055t-5p; Mon, 22 Jun 2015 12:38:10 -0600 Message-ID: <55885606.4030309@labn.net> Date: Mon, 22 Jun 2015 14:37:58 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Ratliff, Stanley" , Rick Taylor , Henning Rogge References: <5575E8A7.6030508@labn.net> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> In-Reply-To: <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 18:38:18 -0000 Stan, On 6/22/2015 2:27 PM, Ratliff, Stanley wrote: > ... >> Actually, killing version numbers in the protocol is just fine assuming that >> the well-known IANA assigned UDP and TCP ports are defined to map to >> DLEPv1. Any future incompatible change would just need to get new port >> numbers. >> >> Lou >> >> PS Yes, I have no idea if you were joking or not. > > Lou, > > Sorry. I was (somewhat) joking... ;-) > > I sort-of like the idea of allocating a new port number in the event that there's a radical enough change in DLEP to warrant a new version... But, I still go back to TLS - it introduces version numbers inside of TLS-parsable messages, I think. Rick mentioned that version information is in the ClientHello. So like Rick, I'm just not seeing the criticality. > > Regards, > Stan > Unless I'm mistaken It's in a fixed location in the message. I think having to parse a full message to figure out what parser to use (which may be based on version number) is, to say mildly, just a bit backwards. Lou > _____________________________________________________ > This electronic message and any files transmitted with it contains > information from iDirect, which may be privileged, proprietary > and/or confidential. It is intended solely for the use of the individual > or entity to whom they are addressed. If you are not the original > recipient or the person responsible for delivering the email to the > intended recipient, be advised that you have received this email > in error, and that any use, dissemination, forwarding, printing, or > copying of this email is strictly prohibited. If you received this email > in error, please delete it and immediately notify the sender. > _____________________________________________________ > > BTW can you get rid of this, sort of annoying --- or do you have no control? From nobody Mon Jun 22 11:42:03 2015 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 1FCE81A1B25; Mon, 22 Jun 2015 11:42:02 -0700 (PDT) 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 DMss6pqR4gGP; Mon, 22 Jun 2015 11:42:00 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1D28D1A1B24; Mon, 22 Jun 2015 11:41:59 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.201; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.201 as permitted sender) identity=mailfrom; client-ip=10.250.250.201; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.201; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,660,1427774400"; d="scan'208";a="17726078" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.201]) by ironport.idirect.net with ESMTP; 22 Jun 2015 14:41:58 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM1.idirect.net (10.250.250.201) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 22 Jun 2015 14:41:57 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Mon, 22 Jun 2015 14:41:57 -0400 From: "Ratliff, Stanley" To: Lou Berger , Rick Taylor , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQoh7bMo+Tw3COyECGObxkTDTDb524sSRAgAB98wD//71+IIAAR1oA//+9xVA= Date: Mon, 22 Jun 2015 18:41:56 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> <55885606.4030309@labn.net> In-Reply-To: <55885606.4030309@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 18:42:02 -0000 > = > Unless I'm mistaken It's in a fixed location in the message. I think hav= ing to > parse a full message to figure out what parser to use (which may be based= on > version number) is, to say mildly, just a bit backwards. > = That said, I'm back to jettisoning the version checking altogether, and goi= ng with an alternate port assignment in the case where DLEP significantly c= hanges. Other opinions? Regards, Stan _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Mon Jun 22 11:51:23 2015 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 DCA5F1A0AF1 for ; Mon, 22 Jun 2015 11:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 G9MADNNoI6S1 for ; Mon, 22 Jun 2015 11:51:20 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 8DF721A1BBD for ; Mon, 22 Jun 2015 11:51:19 -0700 (PDT) Received: (qmail 2461 invoked by uid 0); 22 Jun 2015 18:51:19 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 22 Jun 2015 18:51:19 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id jck51q0072SSUrH01ck8Fs; Mon, 22 Jun 2015 18:44:08 -0600 X-Authority-Analysis: v=2.1 cv=auUhV0pV c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=-GH4mZ5FvcrG9RdDqP0A:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=OmKOu/H1jui0pLlgD8tdtw76+SE8t0xU1tjEBTt/5Vc=; b=K2oZbgju/iJf6bHbGTuY7rRkDWO1/DXBJSudQhohkATat50iWvEfo1Obtcih3TLBgw73Q7fdADscgQhSRGp8uc0W89tRMomdULuPZf5vYAli79yAsB2EjiQUFYLZWUzG; Received: from box313.bluehost.com ([69.89.31.113]:40406 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z76oO-0007e7-6p; Mon, 22 Jun 2015 12:51:16 -0600 Message-ID: <55885918.5020509@labn.net> Date: Mon, 22 Jun 2015 14:51:04 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Ratliff, Stanley" , "Wiggins, David - 0665 - MITLL" , RJ Atkinson , "manet@ietf.org" References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 18:51:22 -0000 Stan, On 6/19/2015 1:50 PM, Ratliff, Stanley wrote: > So, we intentionally created a small (3? 4?) "Wild-wild-West sandbox" (the experiments), and the more formal Extensions mechanism, which by necessity, starts with an IETF draft. I believe the fairly typical way other protocols deal with this issue is via proper IANA allocation policies, see rfc5226. For example the single extensions field can be defined to have a range, say 1-N with one policy and another range, say N-M with another policy. Based on the discussion I'd suggest : 0, Reserved 1-N "Standards Action" (for Standards Track documents) and "Specification Required" (for other documents, including experimental) (The registry allows a request to indicate which policy applies) N- Private Use I think the private use space should be pretty small. I'd also increase the Extension filed to be larger, as 256 seems pretty small assuming the protocol has any level of success/long life. Lou From nobody Mon Jun 22 12:17:12 2015 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 C40C11A888B; Mon, 22 Jun 2015 12:17:10 -0700 (PDT) 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 ZdQc1NHXsPN5; Mon, 22 Jun 2015 12:17:09 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE271A8880; Mon, 22 Jun 2015 12:17:08 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5MJH30e001723; Mon, 22 Jun 2015 15:17:06 -0400 From: "Wiggins, David - 0665 - MITLL" To: "Ratliff, Stanley" , Lou Berger , Rick Taylor , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhkq4BISdYAIk+JbR87kxTblJ249H0AgAA6ZwCAAAICgIAAAtYAgAABGwD//8bCgA== Date: Mon, 22 Jun 2015 19:17:04 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> <55885606.4030309@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3517831023_53183928" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-22_04:2015-06-22,2015-06-22,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-1506220322 Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 19:17:10 -0000 --B_3517831023_53183928 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 6/22/15, 2:41 PM, "Ratliff, Stanley" wrote: >> >> Unless I'm mistaken It's in a fixed location in the message. I think >>having to >> parse a full message to figure out what parser to use (which may be >>based on >> version number) is, to say mildly, just a bit backwards. >> > >That said, I'm back to jettisoning the version checking altogether, and >going with an alternate port assignment in the case where DLEP >significantly changes. Other opinions? Aren't ports considered scarce? If we're sure that this will fly with whomever else in IETF/IANA has to approve, then I'm OK with it. Not my favorite solution, but in the interest of progress, I defer to the draft authors. David --B_3517831023_53183928 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFLHNKsuXXqTpPNZ4 etzH1ahZI6BkMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYyMjE5MTcwM1owDQYJKoZIhvcNAQEBBQAEggEAxgW/qpvjnSPSTYPhAoDNoiJha3+Yp2Uv TG/Sua92BPqg0O5C6Djx6dccQmOnKrXy39keFyKEFVq/IYuwBApvjhoISa3X0ltBOq1TentX dCxNY2PAfi6a7ZdtuXsdO1+aQnyDMOy6ZngW06R02yF0I8Kv/tm9+IthUkAGBxbbd5f0H0Wa 0KbnXEv3If1WjqH4bsaBRjQg5e7lVrMjCwgQIB3/bw9xY30E8Fidv1dsrF1It0r3ZCg/oP/s Tq3u8YUVYDixOE5/KnyOqhUhihEdZcEXoce6jf3KpurPy70zVTcM5GirAu3FoRenbn7ZfWP8 oBrpoq40it24jTW13aa77g== --B_3517831023_53183928-- From nobody Mon Jun 22 13:52:03 2015 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 682221ACF18 for ; Mon, 22 Jun 2015 13:52:01 -0700 (PDT) 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 rYD9yAvL84xL for ; Mon, 22 Jun 2015 13:52:00 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (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 D2C911AD072 for ; Mon, 22 Jun 2015 13:51:59 -0700 (PDT) Received: by ykdt186 with SMTP id t186so32386743ykd.0 for ; Mon, 22 Jun 2015 13:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=mlpkOqguEAEjeWBlIPNLTHpo9o9ctRywK2fH/W/iirw=; b=sewjq7P5muuf92pqdF9+G5xR2pEnqNOa/VDIwmgxKV9i/t4WNH4hTHfp1UHh20qubx 0Xt/0nLMjXKC0+8VspCIW1mBGkABbZ4BABf/LtDHjKz6RAhwY3auBMjovcNv2MT9HrIA WfTYuVDac3ZaG9Z5xA7GlD/djsHsK3uBJ+qFfSnhPp0p5jOC+Zyfro3g0rMEJl0eF7hb QVlC8GrBADu+oYky5z6WDjROiUkG7mHGRK8nWQBLp0ri60ZN/b0ZS/oukVWrfh4FWW5Y YRSZkoTft0oIBIZfT0az7AEw6jYh2iNg1NbHdE0FBqN6W8ehIFk4z23ZHPWI3qUlwK8z tAIw== X-Received: by 10.129.109.211 with SMTP id i202mr37332859ywc.23.1435006319180; Mon, 22 Jun 2015 13:51:59 -0700 (PDT) Received: from [10.30.20.16] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id v186sm16780648ywb.24.2015.06.22.13.51.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jun 2015 13:51:58 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: RJ Atkinson In-Reply-To: <55885918.5020509@labn.net> Date: Mon, 22 Jun 2015 16:51:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <243316EE-618B-495D-AA60-9F413AB04D2F@gmail.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> To: manet@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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: Mon, 22 Jun 2015 20:52:01 -0000 > On 22 Jun 2015, at 14:51 , Lou Berger wrote: >=20 >=20 > Stan, > On 6/19/2015 1:50 PM, Ratliff, Stanley wrote: >> So, we intentionally created a small (3? 4?) "Wild-wild-West sandbox=94= >> (the experiments), and the more formal Extensions mechanism, >> which by necessity, starts with an IETF draft.=20 >=20 > I believe the fairly typical way other protocols deal with this issue = is > via proper IANA allocation policies, see rfc5226. For example the = single > extensions field can be defined to have a range, say 1-N with one = policy > and another range, say N-M with another policy. >=20 > Based on the discussion I'd suggest : > =20 > 0, Reserved > =20 > 1-N "Standards Action" (for Standards Track > documents) or "Specification Required=94 > (for other documents, including = experimental) > (The registry allows a request to indicate > which policy applies.) > =20 > N- Private Use >=20 > I think the private use space should be pretty small. > I'd also increase the Extension filed to be larger, > as 256 seems pretty small assuming the protocol has > any level of success/long life. >=20 > Lou I agree that something along the lines of what Lou proposed above=20 seems like a reasonable basis for a compromise. =20 I concur that 256 is too small a number for . Quoting from RFC 5226, Section 4.1, Page 10: "Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path. For RFC publication, the normal RFC review process is expected to provide the necessary review for interoperability, though the Designated Expert may be a particularly well-qualified person to perform such a review. Examples: Diffserv-aware TE Bandwidth Constraints Model Identifiers [RFC4124], TLS ClientCertificateType Identifiers [RFC4346], ROHC Profile Identifiers [RFC4995]." Yours, Ran From nobody Mon Jun 22 14:24:59 2015 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 E3B391A1BC8 for ; Mon, 22 Jun 2015 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 gPQxH1og2qL0 for ; Mon, 22 Jun 2015 14:21:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 967871A0AF1 for ; Mon, 22 Jun 2015 14:21:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B63F6180452; Mon, 22 Jun 2015 14:18:44 -0700 (PDT) To: ulrich@herberg.name, chris.dearlove@baesystems.com, T.Clausen@computer.org, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, sratliff@idirect.net, bebemaster@gmail.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150622211844.B63F6180452@rfc-editor.org> Date: Mon, 22 Jun 2015 14:18:44 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 22 Jun 2015 14:24:58 -0700 Cc: manet@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Editorial Errata Reported] RFC7183 (4397) 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: Mon, 22 Jun 2015 21:21:32 -0000 The following errata report has been submitted for RFC7183, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7183&eid=4397 -------------------------------------- Type: Editorial Reported by: Jiazi Section: 4 Original Text ------------- Generation of TIMESTAMP Message TLVs (as defined in [RFC7182]) for inclusion in an outgoing message. An implementation of [RFC6130] and [RFC7181] MAY use more than one ICV TLV in a message, but it MUST NOT use the same type extensio Corrected Text -------------- Generation of TIMESTAMP Message TLVs (as defined in [RFC7182]) for inclusion in an outgoing message. An implementation of [RFC6130] and [RFC7181] MAY use more than one TIMESTAMP TLV in a message , but it MUST NOT use the same type extensio Notes ----- We are only talking about TIMESTAMP TLV in this paragraph. I think it's an error when copying the text from the previous paragraph. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7183 (draft-ietf-manet-nhdp-olsrv2-sec-05) -------------------------------------- Title : Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) Publication Date : April 2014 Author(s) : U. Herberg, C. Dearlove, T. Clausen Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Jun 22 14:48:51 2015 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 0378A1ACD90; Mon, 22 Jun 2015 14:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 iTc680zVfNCj; Mon, 22 Jun 2015 14:48:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id C6A451ACD82; Mon, 22 Jun 2015 14:48:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1781B18045A; Mon, 22 Jun 2015 14:46:04 -0700 (PDT) To: ietf@jiaziyi.com, ulrich@herberg.name, chris.dearlove@baesystems.com, T.Clausen@computer.org X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150622214604.1781B18045A@rfc-editor.org> Date: Mon, 22 Jun 2015 14:46:04 -0700 (PDT) Archived-At: Cc: manet@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Errata Held for Document Update] RFC7183 (4397) 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: Mon, 22 Jun 2015 21:48:51 -0000 The following errata report has been held for document update for RFC7183, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7183&eid=4397 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Jiazi Date Reported: 2015-06-22 Held by: Alvaro Retana (IESG) Section: 4 Original Text ------------- Generation of TIMESTAMP Message TLVs (as defined in [RFC7182]) for inclusion in an outgoing message. An implementation of [RFC6130] and [RFC7181] MAY use more than one ICV TLV in a message, but it MUST NOT use the same type extensio Corrected Text -------------- Generation of TIMESTAMP Message TLVs (as defined in [RFC7182]) for inclusion in an outgoing message. An implementation of [RFC6130] and [RFC7181] MAY use more than one TIMESTAMP TLV in a message , but it MUST NOT use the same type extensio Notes ----- We are only talking about TIMESTAMP TLV in this paragraph. I think it's an error when copying the text from the previous paragraph. -------------------------------------- RFC7183 (draft-ietf-manet-nhdp-olsrv2-sec-05) -------------------------------------- Title : Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) Publication Date : April 2014 Author(s) : U. Herberg, C. Dearlove, T. Clausen Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Jun 23 01:28:03 2015 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 567D91A90B1 for ; Tue, 23 Jun 2015 01:28:02 -0700 (PDT) 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 uqHh0b-3gZU2 for ; Tue, 23 Jun 2015 01:28:01 -0700 (PDT) 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 840631A908F for ; Tue, 23 Jun 2015 01:28:00 -0700 (PDT) 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 Jun 2015 09:27:31 +0100 From: Rick Taylor To: RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY63v1bQ2j6/kOycfKuSsomuQ== Date: Tue, 23 Jun 2015 08:27:29 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2B2344@tss-server1.home.tropicalstormsoftware.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <243316EE-618B-495D-AA60-9F413AB04D2F@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 08:28:02 -0000 Comments inline...=0A= =0A= On 22/06/15 21:52, RJ Atkinson wrote:=0A= >=0A= >> On 22 Jun 2015, at 14:51 , Lou Berger wrote:=0A= >>=0A= >>=0A= >> Stan,=0A= >> On 6/19/2015 1:50 PM, Ratliff, Stanley wrote:=0A= >>> So, we intentionally created a small (3? 4?) "Wild-wild-West sandbox=94= =0A= >>> (the experiments), and the more formal Extensions mechanism,=0A= >>> which by necessity, starts with an IETF draft.=0A= >>=0A= >> I believe the fairly typical way other protocols deal with this issue is= =0A= >> via proper IANA allocation policies, see rfc5226. For example the single= =0A= >> extensions field can be defined to have a range, say 1-N with one policy= =0A= >> and another range, say N-M with another policy.=0A= >>=0A= >> Based on the discussion I'd suggest :=0A= >>=0A= >> 0, Reserved=0A= >>=0A= >> 1-N "Standards Action" (for Standards Track=0A= >> documents) or "Specification Required=94=0A= >> (for other documents, including experimental= )=0A= >> (The registry allows a request to indicate= =0A= >> which policy applies.)=0A= >>=0A= >> N- Private Use=0A= >>=0A= >> I think the private use space should be pretty small.=0A= >> I'd also increase the Extension filed to be larger,=0A= >> as 256 seems pretty small assuming the protocol has=0A= >> any level of success/long life.=0A= >>=0A= >> Lou=0A= >=0A= > I agree that something along the lines of what Lou proposed above=0A= > seems like a reasonable basis for a compromise.=0A= >=0A= > I concur that 256 is too small a number for .=0A= >=0A= > Quoting from RFC 5226, Section 4.1, Page 10:=0A= >=0A= > "Specification Required - Values and their meanings must be=0A= > documented in a permanent and readily available public=0A= > specification, in sufficient detail so that interoperability= =0A= > between independent implementations is possible. When used,= =0A= > Specification Required also implies use of a Designated=0A= > Expert, who will review the public specification and=0A= > evaluate whether it is sufficiently clear to allow=0A= > interoperable implementations. The intention behind=0A= > "permanent and readily available" is that a document can=0A= > reasonably be expected to be findable and retrievable long= =0A= > after IANA assignment of the requested value. Publication= =0A= > of an RFC is an ideal means of achieving this requirement,= =0A= > but Specification Required is intended to also cover the=0A= > case of a document published outside of the RFC path. For= =0A= > RFC publication, the normal RFC review process is expected= =0A= > to provide the necessary review for interoperability, though= =0A= > the Designated Expert may be a particularly well-qualified= =0A= > person to perform such a review.=0A= >=0A= > Examples: Diffserv-aware TE Bandwidth Constraints Model=0A= > Identifiers [RFC4124], TLS ClientCertificateType Identifiers= =0A= > [RFC4346], ROHC Profile Identifiers [RFC4995]."=0A= >=0A= =0A= Okay, this seems sensible, given we expand the id bits to 16, and have =0A= no special 0 value, then we can have a registry for data items and a =0A= second for signals, like so:=0A= =0A= 0 - M: IANA allocated, DLEP 'core' ids (from this soon-to-be-RFC)=0A= M - N: Reserved for IANA allocated Extensions ids (as they arrive)=0A= N - 0xFFF: Private space, reserved for Experiments.=0A= =0A= M is 26 for data items, and 16 for signals.=0A= =0A= I am thinking, that N should be 0xFF00.=0A= =0A= How's that?=0A= =0A= Rick=0A= =0A= From nobody Tue Jun 23 01:31:04 2015 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 80E4D1A90D5; Tue, 23 Jun 2015 01:31:03 -0700 (PDT) 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 iwrtqEHb_CTr; Tue, 23 Jun 2015 01:31:02 -0700 (PDT) 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 3498D1A90D2; Tue, 23 Jun 2015 01:31:02 -0700 (PDT) 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 Jun 2015 09:30:38 +0100 From: Rick Taylor To: "Ratliff, Stanley" , Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Tue, 23 Jun 2015 08:30:36 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2B2369@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> <55885606.4030309@labn.net> 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: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 08:31:03 -0000 On 22/06/15 19:41, Ratliff, Stanley wrote:=0A= >>=0A= >> Unless I'm mistaken It's in a fixed location in the message. I think ha= ving to=0A= >> parse a full message to figure out what parser to use (which may be base= d on=0A= >> version number) is, to say mildly, just a bit backwards.=0A= >>=0A= >=0A= > That said, I'm back to jettisoning the version checking altogether, and g= oing with an alternate port assignment in the case where DLEP significantly= changes. Other opinions?=0A= >=0A= =0A= If people think it will wash with the IESG et al. I'm happy to lose the =0A= version numbers.=0A= =0A= There is something quite appealing in a protocol that is =0A= self-descriptive enough to not require versioning.=0A= =0A= Rick=0A= =0A= From nobody Tue Jun 23 01:42:04 2015 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 4A11F1A9115; Tue, 23 Jun 2015 01:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 JVRkEcjC-gD9; Tue, 23 Jun 2015 01:42:01 -0700 (PDT) Received: from uk-ext-viruswalls.astrium.eads.net (uk-ext-viruswalls.astrium.eads.net [194.62.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id AB8C81A9114; Tue, 23 Jun 2015 01:42:00 -0700 (PDT) Received: from uk-ext-viruswalls.astrium.eads.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A2E923254E; Tue, 23 Jun 2015 09:41:58 +0100 (BST) Received: from auk52782.uk.astrium.corp (unknown [10.201.208.4]) by uk-ext-viruswalls.astrium.eads.net (Postfix) with ESMTP id 8C2643250F; Tue, 23 Jun 2015 09:41:58 +0100 (BST) Received: from E2K3-PTH-BRIDGEHEAD.UKN.UKNroot.astrium.corp ([10.221.1.32]) by auk52782.uk.astrium.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Jun 2015 09:41:58 +0100 Received: from AUK52982.UKN.UKNROOT.ASTRIUM.CORP ([fe80::543e:db1:48aa:1c6]) by AUK52839.UKN.UKNROOT.ASTRIUM.CORP ([fe80::cdf2:d214:a3a9:7510%15]) with mapi id 14.03.0123.003; Tue, 23 Jun 2015 09:41:58 +0100 From: "MATTY, Steven" To: "'Ratliff, Stanley'" , Lou Berger , Rick Taylor , "Henning Rogge" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhqOLZ7x+mP20iQwyjGq8cNLJ24oKsAgAA6ZwCAAAICgIAAAtYAgAABHACAAPmWYA== Date: Tue, 23 Jun 2015 08:41:57 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> <55885606.4030309@labn.net> 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.221.1.73] X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-8.0.0.1202-21630.006 X-TM-AS-Result: No--16.041-5.0-31-10 X-TM-AS-User-Approved-Sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jun 2015 08:41:58.0238 (UTC) FILETIME=[77501FE0:01D0AD90] X-TM-AS-MML: disable X-imss-scan-details: No--16.041-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-8.0.1202-21630.006 X-TMASE-Result: 10--16.041100-5.000000 X-TMASE-MatchedRID: vEvJ7Rh1lGhNilkTrUY0jmwjJ4TFeU1uj/xLIaDSshHwZxaFJX+r1a0R omhWPJaQTut0H2Qyzsvw3wi3Muh6TKX2s5Nec6illGudLLtRO1sR5c83KIxTTrv408/GP5HqN1N eJEsbqQ58jMmJRHrRb+izsiQoq4e/1xQ2OgXti5XhxtkyjliJLmCeXI3igpd8tXl9IxEPXOq7Jy GQsl8KJ/QUm2x80xzXl/s8zpk5FbzBXlkPaxAt1afXIl6Cf6VrKVrLOZD1BXRCV2UGS59WtlndW Xl0RYumnccJ1pOJRjQKJmROwROsPdZKbj1LaMdS5qhand0wQAMNgFUqZt55AxBMzcCTqrAdaNB8 dHgjP3M9I+RojwVYZJYlxuk1ogQA+zoAW8R15l8c8J6ZrWP/q30tCKdnhB58pvI8UZOf47jUZxE AlFPo846HM5rqDwqtoShZAxp5VmXvPWobNw1FkvCMeeYh3uVlRVPCm7klFIL5tOV2osjuWg== Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 08:42:03 -0000 Hi I would prefer to stick with a single known port and keep version checkin= g in. If a future DLEPv2 implementation wants to remain backwards-compatible wi= th v1 then it will need to then have to be listening on two ports. And hey, = if we get to DLEP v10 or whatever that could be quite a mess! Also if there are a n= umber of firewalls in your network then you'll have the [admittedly small] over= head of having to open another port. I don't see the issue in just keeping DLEP Version placement as-is, but n= arrowing the field width to 8 bits. Just my tuppence ha'penny... Regards Steve >-----Original Message----- >From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ratliff, Stanle= y >Sent: Monday, June 22, 2015 7:42 PM >To: Lou Berger; Rick Taylor; Henning Rogge >Cc: MANET IETF; draft-ietf-manet-dlep.all@ietf.org >Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 > >> >> Unless I'm mistaken It's in a fixed location in the message. I think = having to >> parse a full message to figure out what parser to use (which may be ba= sed >on >> version number) is, to say mildly, just a bit backwards. >> > >That said, I'm back to jettisoning the version checking altogether, and = going >with an alternate port assignment in the case where DLEP significantly >changes. Other opinions? > >Regards, >Stan > >_____________________________________________________ >This electronic message and any files transmitted with it contains >information from iDirect, which may be privileged, proprietary >and/or confidential. It is intended solely for the use of the individual >or entity to whom they are addressed. If you are not the original >recipient or the person responsible for delivering the email to the >intended recipient, be advised that you have received this email >in error, and that any use, dissemination, forwarding, printing, or >copying of this email is strictly prohibited. If you received this email >in error, please delete it and immediately notify the sender. >_____________________________________________________ > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space Limited disclaims any and all = liability if this email transmission was virus corrupted, altered or falsified. -o- Airbus Defence and Space Limited, Registered in England and Wales No. 244= 9259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England From nobody Tue Jun 23 01:47:31 2015 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 A3A591A9233; Tue, 23 Jun 2015 01:47:30 -0700 (PDT) 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 ArhG8EQy-BWw; Tue, 23 Jun 2015 01:47:28 -0700 (PDT) Received: from ukmta4.baesystems.com (ukmta4.baesystems.com [20.133.40.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2615C1A9238; Tue, 23 Jun 2015 01:47:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,664,1427756400"; d="scan'208";a="243232" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta4.baesystems.com with ESMTP; 23 Jun 2015 09:47:26 +0100 X-IronPort-AV: E=Sophos;i="5.13,664,1427756400"; d="scan'208";a="106602990" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 23 Jun 2015 09:47:27 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.17]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0224.002; Tue, 23 Jun 2015 09:47:26 +0100 From: "Dearlove, Christopher (UK)" To: "MATTY, Steven" , "'Ratliff, Stanley'" , Lou Berger , Rick Taylor , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojiIwK+stmbvhUWtFDx9P52N9Z24oKsAgAA6ZwCAAAICgIAAAtYAgAABGwCAAOqzgIAAEZ1Q Date: Tue, 23 Jun 2015 08:47:25 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> <55885606.4030309@labn.net> 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: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 08:47:30 -0000 A single octet with version number that's the very first thing (in what I'd= still prefer to call a message) would be what I'd suggest too. It will pas= s the IESG, where a whole "we could use multiple ports" might not, and woul= d have the disadvantage noted below. And this isn't an over-the-air MANET s= ignal where every octet counts. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of MATTY, Steven Sent: 23 June 2015 09:42 To: 'Ratliff, Stanley'; Lou Berger; Rick Taylor; Henning Rogge Cc: MANET IETF; draft-ietf-manet-dlep.all@ietf.org Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 ----------------------! 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. -------------------------------------------------------- *** WARNING *** This message originates from outside our organization, either from an exter= nal partner or the internet. Consider carefully whether you should click on= any links, open any attachments or reply. For additional information about= Spearphishing, click here . If you feel the email is s= uspicious, please follow this process. Hi I would prefer to stick with a single known port and keep version checking = in. If a future DLEPv2 implementation wants to remain backwards-compatible with v1 then it will need to then have to be listening on two ports. And hey, if= we get to DLEP v10 or whatever that could be quite a mess! Also if there a= re a number of firewalls in your network then you'll have the [admittedly s= mall] overhead of having to open another port. = I don't see the issue in just keeping DLEP Version placement as-is, but nar= rowing the field width to 8 bits. Just my tuppence ha'penny... Regards Steve >-----Original Message----- >From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ratliff, = >Stanley >Sent: Monday, June 22, 2015 7:42 PM >To: Lou Berger; Rick Taylor; Henning Rogge >Cc: MANET IETF; draft-ietf-manet-dlep.all@ietf.org >Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 > >> >> Unless I'm mistaken It's in a fixed location in the message. I think = >> having to parse a full message to figure out what parser to use = >> (which may be based >on >> version number) is, to say mildly, just a bit backwards. >> > >That said, I'm back to jettisoning the version checking altogether, and = >going with an alternate port assignment in the case where DLEP = >significantly changes. Other opinions? > >Regards, >Stan > >_____________________________________________________ >This electronic message and any files transmitted with it contains = >information from iDirect, which may be privileged, proprietary and/or = >confidential. It is intended solely for the use of the individual or = >entity to whom they are addressed. If you are not the original = >recipient or the person responsible for delivering the email to the = >intended recipient, be advised that you have received this email in = >error, and that any use, dissemination, forwarding, printing, or = >copying of this email is strictly prohibited. If you received this = >email in error, please delete it and immediately notify the sender. >_____________________________________________________ > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet This email (including any attachments) may contain confidential and/or priv= ileged information or information otherwise protected from disclosure. If y= ou are not the intended recipient, please notify the sender immediately, do= not copy this message or any attachments and do not use it for any purpose= or disclose its content to any person, but delete this message and any att= achments from your system. Airbus Defence and Space Limited disclaims any a= nd all liability if this email transmission was virus corrupted, altered or= falsified. -o- Airbus Defence and Space Limited, Registered in England and Wales No. 24492= 59 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England _______________________________________________ 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 Tue Jun 23 01:56:34 2015 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 B79DB1A92B4; Tue, 23 Jun 2015 01:56:32 -0700 (PDT) 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 ETPmDDDSAQm4; Tue, 23 Jun 2015 01:56:31 -0700 (PDT) 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 8782E1A9248; Tue, 23 Jun 2015 01:56:30 -0700 (PDT) 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 Jun 2015 09:56:06 +0100 From: Rick Taylor To: "MATTY, Steven" , "'Ratliff, Stanley'" , Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Tue, 23 Jun 2015 08:56:05 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2B3731@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> <55885606.4030309@labn.net> 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: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 08:56:32 -0000 Steve,=0A= =0A= I can completely see where you are coming from, but can I pose this =0A= question:=0A= =0A= What is the difference between a Version data item, used at Peer Init, =0A= and an Extension data item, used at Peer Init, that says "Core + this =0A= new stuff"?=0A= =0A= The only version-breaking changes to DLEP as it stands is to alter the =0A= fields of the signal and data item headers, and given we are increasing =0A= all of them now to 16bits, I don't believe we are going to run out of =0A= space soon.=0A= =0A= Even if we did run out of space in the future, there is nothing to =0A= prevent a future DLEP extension of "Very big fields", announced using =0A= the existing mechanism, and taking effect only if both peers agree.=0A= =0A= I understand that dropping the version number seems unnatural, but it =0A= has proven to work with several protocols and formats to date (JSON for =0A= example), and protocols with a solid extension mechanism last for a very = =0A= long time (e.g. SMTP)=0A= =0A= I predict that if a major issue is found with DLEP, it will not be a =0A= fault with the wire protocol, but a fault with the methodology, and that = =0A= will probably result in an entirely new protocol.=0A= =0A= Rick=0A= =0A= =0A= On 23/06/15 09:41, MATTY, Steven wrote:=0A= > Hi=0A= >=0A= > I would prefer to stick with a single known port and keep version checkin= g in.=0A= > If a future DLEPv2 implementation wants to remain backwards-compatible wi= th=0A= > v1 then it will need to then have to be listening on two ports. And hey, = if we get=0A= > to DLEP v10 or whatever that could be quite a mess! Also if there are a n= umber=0A= > of firewalls in your network then you'll have the [admittedly small] over= head of=0A= > having to open another port.=0A= >=0A= > I don't see the issue in just keeping DLEP Version placement as-is, but n= arrowing=0A= > the field width to 8 bits.=0A= >=0A= > Just my tuppence ha'penny...=0A= >=0A= > Regards=0A= >=0A= > Steve=0A= >=0A= >> -----Original Message-----=0A= >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ratliff, Stanle= y=0A= >> Sent: Monday, June 22, 2015 7:42 PM=0A= >> To: Lou Berger; Rick Taylor; Henning Rogge=0A= >> Cc: MANET IETF; draft-ietf-manet-dlep.all@ietf.org=0A= >> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14=0A= >>=0A= >>>=0A= >>> Unless I'm mistaken It's in a fixed location in the message. I think h= aving to=0A= >>> parse a full message to figure out what parser to use (which may be bas= ed=0A= >> on=0A= >>> version number) is, to say mildly, just a bit backwards.=0A= >>>=0A= >>=0A= >> That said, I'm back to jettisoning the version checking altogether, and = going=0A= >> with an alternate port assignment in the case where DLEP significantly= =0A= >> changes. Other opinions?=0A= >>=0A= >> Regards,=0A= >> Stan=0A= >>=0A= >> _____________________________________________________=0A= >> This electronic message and any files transmitted with it contains=0A= >> information from iDirect, which may be privileged, proprietary=0A= >> and/or confidential. It is intended solely for the use of the individual= =0A= >> or entity to whom they are addressed. If you are not the original=0A= >> recipient or the person responsible for delivering the email to the=0A= >> intended recipient, be advised that you have received this email=0A= >> in error, and that any use, dissemination, forwarding, printing, or=0A= >> copying of this email is strictly prohibited. If you received this email= =0A= >> in error, please delete it and immediately notify the sender.=0A= >> _____________________________________________________=0A= >>=0A= >> _______________________________________________=0A= >> manet mailing list=0A= >> manet@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/manet=0A= > This email (including any attachments) may contain confidential=0A= > and/or privileged information or information otherwise protected=0A= > from disclosure. If you are not the intended recipient, please=0A= > notify the sender immediately, do not copy this message or any=0A= > attachments and do not use it for any purpose or disclose its=0A= > content to any person, but delete this message and any attachments=0A= > from your system. Airbus Defence and Space Limited disclaims any and all = liability if this email transmission was virus corrupted,=0A= > altered or falsified.=0A= > -o-=0A= > Airbus Defence and Space Limited, Registered in England and Wales No. 244= 9259=0A= > Registered Office:=0A= > Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England=0A= >=0A= >=0A= =0A= From nobody Tue Jun 23 02:20:05 2015 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 7D1121AC3B8; Tue, 23 Jun 2015 02:20:03 -0700 (PDT) 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 DCnhxn3iQTI7; Tue, 23 Jun 2015 02:20:02 -0700 (PDT) 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 C39451AC3B4; Tue, 23 Jun 2015 02:20:01 -0700 (PDT) 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 Jun 2015 10:19:37 +0100 From: Rick Taylor To: "Dearlove, Christopher (UK)" , "MATTY, Steven" , "'Ratliff, Stanley'" , Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Tue, 23 Jun 2015 09:19:36 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2B385A@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> <55885606.4030309@labn.net> 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: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 09:20:03 -0000 On 23/06/15 09:47, Dearlove, Christopher (UK) wrote:=0A= > A single octet with version number that's the very first thing (in what I= 'd still prefer to call a message) would be what I'd suggest too. It will p= ass the IESG, where a whole "we could use multiple ports" might not, and wo= uld have the disadvantage noted below. And this isn't an over-the-air MANET= signal where every octet counts.=0A= >=0A= =0A= I still don't actually see what the problem is with the way we do =0A= versioning at the moment.=0A= =0A= There are 5 implementations known to me, 2 pairs at least interoperate, =0A= and at no point have I had feedback from the implementers saying the =0A= version scheme is weird or difficult.=0A= =0A= Currently we have a version number, that is included in all the right =0A= signals. This discussion seems to have highlighted that it is probably =0A= irrelevant.=0A= =0A= Frankly, I can delete the text, or I can leave it in, but at this point =0A= I don't feel the need to change what we have (a consistent flexible =0A= format) to something that seems clunky (adding a special case number) =0A= for what appears to be other peoples personal preference.=0A= =0A= Sorry that sounds grumpy, but I think we are getting lost in the long =0A= grass here.=0A= =0A= Cheers,=0A= =0A= Rick=0A= =0A= ...channelling my inner Stan=0A= From nobody Tue Jun 23 02:20:57 2015 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 44B311AC3C3; Tue, 23 Jun 2015 02:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 1P3AdTMcTgDU; Tue, 23 Jun 2015 02:20:48 -0700 (PDT) Received: from uk-ext-viruswalls.astrium.eads.net (uk-ext-viruswalls.astrium.eads.net [194.62.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id A9C611AC3B8; Tue, 23 Jun 2015 02:20:47 -0700 (PDT) Received: from uk-ext-viruswalls.astrium.eads.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EDAE032564; Tue, 23 Jun 2015 10:20:46 +0100 (BST) Received: from auk52782.uk.astrium.corp (unknown [10.201.208.4]) by uk-ext-viruswalls.astrium.eads.net (Postfix) with ESMTP id D6B293255C; Tue, 23 Jun 2015 10:20:46 +0100 (BST) Received: from E2K3-PTH-BRIDGEHEAD.UKN.UKNroot.astrium.corp ([10.221.1.31]) by auk52782.uk.astrium.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Jun 2015 10:20:46 +0100 Received: from AUK52982.UKN.UKNROOT.ASTRIUM.CORP ([fe80::543e:db1:48aa:1c6]) by AUK52840.UKN.UKNROOT.ASTRIUM.CORP ([fe80::7584:4b98:38c0:4ce7%15]) with mapi id 14.03.0123.003; Tue, 23 Jun 2015 10:20:46 +0100 From: "MATTY, Steven" To: 'Rick Taylor' , "'Ratliff, Stanley'" , Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhqOLZ7x+mP20iQwyjGq8cNLJ255dJw Date: Tue, 23 Jun 2015 09:20:45 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> <55885606.4030309@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B3731@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B3731@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.1.73] X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-8.0.0.1202-21630.006 X-TM-AS-Result: No--25.968-5.0-31-10 X-TM-AS-User-Approved-Sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jun 2015 09:20:46.0522 (UTC) FILETIME=[E31411A0:01D0AD95] X-TM-AS-MML: disable X-imss-scan-details: No--25.968-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-8.0.1202-21630.006 X-TMASE-Result: 10--25.967700-5.000000 X-TMASE-MatchedRID: hwsFDxVJcFnMy6K24fisq4bBPrt55wnwj/xLIaDSshFMiFptqWknWZgH JNUdT0L5wXrcF4EPS58A1xjuGL35BgFuUZy6kMeHjWe5HOFKvuP9GaYSzB/sh33hz57t9YhwJz/ Fli73wMjbxxPaDKk/YUZsUV6dYCsyW0WwPyv6x8zM1jffIgQXhk8ikszWUoVb1onV4DXZ9meuwS XfcqI7mT4COvkkIkpY+xX46HSJqq/wkLAKwBnPlvyAR9DgC/hHHznaOB9+eYhaW2Ktn+I8/t3+Y NN+fbG9FWjiE8Qr1h8mGa1M82+724PkG71n77vIYD9XTRdaMO0ZKp0SZ4P+dfzeqIj4AoEULVCQ fSxiPcZjDrpknoTJl8cG+qFF0Dyyw9dU5xwENT3Ht9VUPuskRiT0t/+p7zHHdGD+JjwWcAHt3sd EIHprepqu2hrwsYkQpA5sNI/7fj7khsdzyWixdRmCYUYerLHrzbQL1PyxipnfUZT83lbkEElmz+ P/3+i2Tns4EBxmwZm8zFLEy/tSeSthqKdvHzOSHcQQBuf4ZFvLXL+Mi6hlnr+Q9SbkwLomCo9lz wtw5KRaEQ60KWAy23VALpStBs0q8IDC+zKI/xjK09/T6AzbVqVj4bdO+FqNR+JqSnmX4cpe9tX9 WdS/So9Zm8Ov7SprPDF4aOlLYwdKl5uDD6k69sL6jhga4Ht71QQ6Jx/fflZV84HrPxCfbOrEiRS ZkkEfQqfTEoHCRdFJaCfC36CzXkarpPB1j+3zngIgpj8eDcDInWAWA4yE6foA9r2LThYYKrauXd 3MZDUD/dHyT/Xh7Q== Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 09:20:50 -0000 Hi Rick That's a fair point and the example you give works well to probably accommodate most of any likely tweaks to DLEP. I guess my concern is with the future unknown. Once DLEP is out in the wild amongst the mass= es, then who knows what potentially vital and version-breaking changes may arise? Preserving some version information would perhaps go some way to ensure v1 implementations don't interfere with v2 etc. (with a downsid= e in that we may be unnecessarily inhibiting forward-compatibility). As I'm fairly new to this game, I'm happy to bow to the elders :) Regards Steve >-----Original Message----- >From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] >Sent: Tuesday, June 23, 2015 9:56 AM >To: MATTY, Steven; 'Ratliff, Stanley'; Lou Berger; Henning Rogge >Cc: MANET IETF; draft-ietf-manet-dlep.all@ietf.org >Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 > >Steve, > >I can completely see where you are coming from, but can I pose this >question: > >What is the difference between a Version data item, used at Peer Init, >and an Extension data item, used at Peer Init, that says "Core + this >new stuff"? > >The only version-breaking changes to DLEP as it stands is to alter the >fields of the signal and data item headers, and given we are increasing >all of them now to 16bits, I don't believe we are going to run out of >space soon. > >Even if we did run out of space in the future, there is nothing to >prevent a future DLEP extension of "Very big fields", announced using >the existing mechanism, and taking effect only if both peers agree. > >I understand that dropping the version number seems unnatural, but it >has proven to work with several protocols and formats to date (JSON for >example), and protocols with a solid extension mechanism last for a very >long time (e.g. SMTP) > >I predict that if a major issue is found with DLEP, it will not be a >fault with the wire protocol, but a fault with the methodology, and that >will probably result in an entirely new protocol. > >Rick > > >On 23/06/15 09:41, MATTY, Steven wrote: >> Hi >> >> I would prefer to stick with a single known port and keep version chec= king >in. >> If a future DLEPv2 implementation wants to remain backwards-compatible >with >> v1 then it will need to then have to be listening on two ports. And he= y, if we >get >> to DLEP v10 or whatever that could be quite a mess! Also if there are = a >number >> of firewalls in your network then you'll have the [admittedly small] >overhead of >> having to open another port. >> >> I don't see the issue in just keeping DLEP Version placement as-is, bu= t >narrowing >> the field width to 8 bits. >> >> Just my tuppence ha'penny... >> >> Regards >> >> Steve >> >>> -----Original Message----- >>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ratliff, >Stanley >>> Sent: Monday, June 22, 2015 7:42 PM >>> To: Lou Berger; Rick Taylor; Henning Rogge >>> Cc: MANET IETF; draft-ietf-manet-dlep.all@ietf.org >>> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 >>> >>>> >>>> Unless I'm mistaken It's in a fixed location in the message. I thin= k having >to >>>> parse a full message to figure out what parser to use (which may be >based >>> on >>>> version number) is, to say mildly, just a bit backwards. >>>> >>> >>> That said, I'm back to jettisoning the version checking altogether, a= nd going >>> with an alternate port assignment in the case where DLEP significantl= y >>> changes. Other opinions? >>> >>> Regards, >>> Stan >>> >>> _____________________________________________________ >>> This electronic message and any files transmitted with it contains >>> information from iDirect, which may be privileged, proprietary >>> and/or confidential. It is intended solely for the use of the individ= ual >>> or entity to whom they are addressed. If you are not the original >>> recipient or the person responsible for delivering the email to the >>> intended recipient, be advised that you have received this email >>> in error, and that any use, dissemination, forwarding, printing, or >>> copying of this email is strictly prohibited. If you received this em= ail >>> in error, please delete it and immediately notify the sender. >>> _____________________________________________________ >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> This email (including any attachments) may contain confidential >> and/or privileged information or information otherwise protected >> from disclosure. If you are not the intended recipient, please >> notify the sender immediately, do not copy this message or any >> attachments and do not use it for any purpose or disclose its >> content to any person, but delete this message and any attachments >> from your system. Airbus Defence and Space Limited disclaims any and a= ll >liability if this email transmission was virus corrupted, >> altered or falsified. >> -o- >> Airbus Defence and Space Limited, Registered in England and Wales No. >2449259 >> Registered Office: >> Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England >> >> This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space Limited disclaims any and all = liability if this email transmission was virus corrupted, altered or falsified. -o- Airbus Defence and Space Limited, Registered in England and Wales No. 244= 9259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England From nobody Tue Jun 23 02:23:27 2015 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 818241AC3BB; Tue, 23 Jun 2015 02:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 QwPQuJ5XZB0x; Tue, 23 Jun 2015 02:23:24 -0700 (PDT) Received: from uk-ext-viruswalls.astrium.eads.net (uk-ext-viruswalls.astrium.eads.net [194.62.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2C55D1AC3BA; Tue, 23 Jun 2015 02:23:24 -0700 (PDT) Received: from uk-ext-viruswalls.astrium.eads.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1C6E13255C; Tue, 23 Jun 2015 10:23:23 +0100 (BST) Received: from auk52782.uk.astrium.corp (unknown [10.201.208.4]) by uk-ext-viruswalls.astrium.eads.net (Postfix) with ESMTP id 083EB3256C; Tue, 23 Jun 2015 10:23:23 +0100 (BST) Received: from E2K3-PTH-BRIDGEHEAD.UKN.UKNroot.astrium.corp ([10.221.1.31]) by auk52782.uk.astrium.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Jun 2015 10:23:22 +0100 Received: from AUK52982.UKN.UKNROOT.ASTRIUM.CORP ([fe80::543e:db1:48aa:1c6]) by AUK52840.UKN.UKNROOT.ASTRIUM.CORP ([fe80::7584:4b98:38c0:4ce7%15]) with mapi id 14.03.0123.003; Tue, 23 Jun 2015 10:23:22 +0100 From: "MATTY, Steven" To: 'Rick Taylor' , "Dearlove, Christopher (UK)" , "'Ratliff, Stanley'" , Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhqOLZ7x+mP20iQwyjGq8cNLJ2557TQ Date: Tue, 23 Jun 2015 09:23:22 +0000 Message-ID: References: <5575E8A7.6030508@labn.net> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> <55885606.4030309@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B385A@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B385A@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.1.73] X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-8.0.0.1202-21630.006 X-TM-AS-Result: No--10.396-5.0-31-10 X-TM-AS-User-Approved-Sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jun 2015 09:23:22.0706 (UTC) FILETIME=[402BDB20:01D0AD96] X-TM-AS-MML: disable X-imss-scan-details: No--10.396-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-8.0.1202-21630.006 X-TMASE-Result: 10--10.396100-5.000000 X-TMASE-MatchedRID: QW5G6BKkLTrYfPOPCpnfAhs0aZbkV7Ca9mnDjfUPq57/eGzI/UZTpcLm p4jPUF8tMQamJ/o/leldbQKBVIHwk8EIemFKn0+S2OSj4qJA9QY6QNs2WCY79buOSVu5iDENUS3 54uMGPVGM9WlW5vkXcU9LrXCRT8i0gRy3HHXz6cZgP1dNF1ow7Xtm/Mb+S1nc6i5zlFx/UHTPnM Ai6bw5xBhfASa6ondvmrNKxVIgCVFQmsLD9hiOVKOBH/lppPcd2aYdnwn7qHfCSQFHjDva/BMGt PkUyFbdCEuVF6nuSDF/JgN7Aw6tAFZFWWuOwo7w3QfwsVk0UbtuRXh7bFKB7j9vlLlIVx+aFI/V izslH9DVzqNyi2sxXJMQuqzDK2MXxYVzI3UCCaY= Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 09:23:25 -0000 +1 to this, there are perhaps more important issues that deserve the auth= ors' attention! >-----Original Message----- >From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] [..snip..] >I still don't actually see what the problem is with the way we do >versioning at the moment. > >There are 5 implementations known to me, 2 pairs at least interoperate, >and at no point have I had feedback from the implementers saying the >version scheme is weird or difficult. > >Currently we have a version number, that is included in all the right >signals. This discussion seems to have highlighted that it is probably >irrelevant. > >Frankly, I can delete the text, or I can leave it in, but at this point >I don't feel the need to change what we have (a consistent flexible >format) to something that seems clunky (adding a special case number) >for what appears to be other peoples personal preference. > >Sorry that sounds grumpy, but I think we are getting lost in the long >grass here. > >Cheers, > >Rick This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space Limited disclaims any and all = liability if this email transmission was virus corrupted, altered or falsified. -o- Airbus Defence and Space Limited, Registered in England and Wales No. 244= 9259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England From nobody Tue Jun 23 02:46:13 2015 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 A85821AC42C; Tue, 23 Jun 2015 02:46:11 -0700 (PDT) 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 lDbvn--7toFB; Tue, 23 Jun 2015 02:46:10 -0700 (PDT) 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 2E7E21AC439; Tue, 23 Jun 2015 02:43:06 -0700 (PDT) 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 Jun 2015 10:42:41 +0100 From: Rick Taylor To: "MATTY, Steven" , "Dearlove, Christopher (UK)" , "'Ratliff, Stanley'" , Lou Berger , Henning Rogge Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQojhp3v1bQ2j6/kOycfKuSsomuQ== Date: Tue, 23 Jun 2015 09:42:40 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2B398F@tss-server1.home.tropicalstormsoftware.com> References: <5575E8A7.6030508@labn.net> <14e1b2e5c60.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AC742@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AD8DA@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> <55885606.4030309@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B385A@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: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 09:46:11 -0000 On 23/06/15 10:23, MATTY, Steven wrote:=0A= > +1 to this, there are perhaps more important issues that deserve the auth= ors' attention!=0A= =0A= Given you're one of the interoperating implementers Steve, I think that =0A= counts as +10=0A= =0A= Rick=0A= =0A= >=0A= >> -----Original Message-----=0A= >> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com]=0A= >=0A= > [..snip..]=0A= >=0A= >> I still don't actually see what the problem is with the way we do=0A= >> versioning at the moment.=0A= >>=0A= >> There are 5 implementations known to me, 2 pairs at least interoperate,= =0A= >> and at no point have I had feedback from the implementers saying the=0A= >> version scheme is weird or difficult.=0A= >>=0A= >> Currently we have a version number, that is included in all the right=0A= >> signals. This discussion seems to have highlighted that it is probably= =0A= >> irrelevant.=0A= >>=0A= >> Frankly, I can delete the text, or I can leave it in, but at this point= =0A= >> I don't feel the need to change what we have (a consistent flexible=0A= >> format) to something that seems clunky (adding a special case number)=0A= >> for what appears to be other peoples personal preference.=0A= >>=0A= >> Sorry that sounds grumpy, but I think we are getting lost in the long=0A= >> grass here.=0A= >>=0A= >> Cheers,=0A= >>=0A= >> Rick=0A= > This email (including any attachments) may contain confidential=0A= > and/or privileged information or information otherwise protected=0A= > from disclosure. If you are not the intended recipient, please=0A= > notify the sender immediately, do not copy this message or any=0A= > attachments and do not use it for any purpose or disclose its=0A= > content to any person, but delete this message and any attachments=0A= > from your system. Airbus Defence and Space Limited disclaims any and all = liability if this email transmission was virus corrupted,=0A= > altered or falsified.=0A= > -o-=0A= > Airbus Defence and Space Limited, Registered in England and Wales No. 244= 9259=0A= > Registered Office:=0A= > Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England=0A= >=0A= >=0A= =0A= From nobody Tue Jun 23 04:00:36 2015 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 E2CD31B2AE9 for ; Tue, 23 Jun 2015 04:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 w4uMiYajOt7u for ; Tue, 23 Jun 2015 04:00:33 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 978A11B2ADF for ; Tue, 23 Jun 2015 04:00:33 -0700 (PDT) Received: (qmail 2347 invoked by uid 0); 23 Jun 2015 11:00:27 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 23 Jun 2015 11:00:27 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id jstM1q00m2SSUrH01stQ8g; Tue, 23 Jun 2015 10:53:35 -0600 X-Authority-Analysis: v=2.1 cv=VdVkYjZ9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=4rZ2bqLMvaFmPzVcNa8A:9 a=MBQ8WfJAsjtawpnt:21 a=BjBx08ckzwxkY93d:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=DRJuecId0AA6itRMz1H0/R1GqAyCZgJd8gq9DicO0P0=; b=tlrvhCf8lphGnpYPOl4mT0WfCPeJjOcGoDrdx/48oB8riLGoiN8zhVGOm9mIlO7j7QJnEXQ2FfsUkXoIV5XChzQ0VZDxZy5kuliHkBEV6arPBEizLUf98XRg/el3aofr; Received: from box313.bluehost.com ([69.89.31.113]:34517 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z7Lw5-0002gA-Op; Tue, 23 Jun 2015 05:00:13 -0600 Message-ID: <55893C38.8080806@labn.net> Date: Tue, 23 Jun 2015 07:00:08 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rick Taylor , "Dearlove, Christopher (UK)" , "MATTY, Steven" , "'Ratliff, Stanley'" , Henning Rogge References: <5575E8A7.6030508@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2AEF2D@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF0D2@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2AF2B6@tss-server1.home.tropicalstormsoftware.com> <62192530de974a1d810bea65236b95c0@VAUSDITCHM3.idirect.net> <558851F6.3040908@labn.net> <1d07d27a4d574a779167aa761b31ba59@VAUSDITCHM3.idirect.net> <55885606.4030309@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B385A@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B385A@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: MANET IETF , "draft-ietf-manet-dlep.all@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 11:00:35 -0000 Rick, On 6/23/2015 5:19 AM, Rick Taylor wrote: > On 23/06/15 09:47, Dearlove, Christopher (UK) wrote: >> A single octet with version number that's the very first thing (in what I'd still prefer to call a message) would be what I'd suggest too. It will pass the IESG, where a whole "we could use multiple ports" might not, and would have the disadvantage noted below. And this isn't an over-the-air MANET signal where every octet counts. >> > I still don't actually see what the problem is with the way we do > versioning at the moment. Protocol versioning is a pretty typical and useful mechanism that allow for significant changes of a protocol. In practice, most protocols stay with the same version for a long time. But let's consider cases where the protocol goes through a major change, significant enough to warrant a version change. One driver we've seen in other protocols is changing the basic formats used by the protocol -- this means a new parser. To facilitate and simplify such changes, the version number is typically placed in (1) a *fixed location* and (2) near the *beginning* of the protocol message. Again, consider IP as an example. IP's version number is the first thing on the wire. Receivers of different versions need only look at the 1st field to determine which parser to use (or which versions to drop). This approach allows maximum flexibility between versions. The problem I see with the current definition is it (1) requires parsing at a fairly deep level to find the version and (2) version can be anywhere in the message/signal. IMO this eliminates the primary values of the version number -- and simply doesn't seem thought through. There may be some value, but I'm not sure really what. > > There are 5 implementations known to me, 2 pairs at least interoperate, > and at no point have I had feedback from the implementers saying the > version scheme is weird or difficult. I suspect that if you show this to the IESG or IAB in its current form most will view it as at least odd. I'd be surprised if it's not blocked by at least one AD. > Currently we have a version number, that is included in all the right > signals. This discussion seems to have highlighted that it is probably > irrelevant. > > Frankly, I can delete the text, or I can leave it in, but at this point > I don't feel the need to change what we have (a consistent flexible > format) to something that seems clunky (adding a special case number) And this is what lead to the port-based version solution. > for what appears to be other peoples personal preference. I'm guessing this would be me. I actually don't have any real preferences related to this protocol, I do have opinions on what is good/bad to see in a protocol -- and have been asked to share them with the AD/chairs/WG WRT this protocol. I certainly have no issue with the WG deciding that my opinion is wrong or irrelevant. They are, after all, just my opinions. That said, per the routing review process, any item that the reviewer has flagged as a Major item is expected to be discussed with the AD (Alvaro) at some point. Often the Major issues are resolved with the reviewer and the AD doesn't become involved. In general, the distinction I made in choosing between Major and Minor issues was made based on what I thought would end up being either (a) major interoperability issues or (b) likely to be raised as a blocking issue by the IESG. In this case, I believe (b) applies. If/when it does come up in AD/IESG/IETF review, and if I was the one who needed to defend the protocol, my answer would be that when the parser changes to that degree a new DLEP port number should be used. This may or may not fly. You can always ask the AD to weigh in. > Sorry that sounds grumpy, but I think we are getting lost in the long > grass here. No problem from my end. I wouldn't be happy receiving a review of a protocol that I worked long and hard on like the one I sent. So some grumpiness was anticipated;-) -- In all seriousness, I think having such discussion is exactly what these routing reviews should/are expected to generate. Lou > Cheers, > > Rick > > ...channelling my inner Stan > From nobody Tue Jun 23 06:33:45 2015 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 9835E1B2A14 for ; Tue, 23 Jun 2015 06:33:43 -0700 (PDT) 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 FhiIE0Rdrfq5 for ; Tue, 23 Jun 2015 06:33:42 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id A1EE91B29FE for ; Tue, 23 Jun 2015 06:33:41 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,665,1427774400"; d="scan'208";a="8181149" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport2.idirect.net with ESMTP; 23 Jun 2015 09:33:27 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 23 Jun 2015 09:33:25 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Tue, 23 Jun 2015 09:33:25 -0400 From: "Ratliff, Stanley" To: Rick Taylor , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6Mo+Tw3COyECGObxkTDTDb526HhAg Date: Tue, 23 Jun 2015 13:33:25 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <243316EE-618B-495D-AA60-9F413AB04D2F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016C2B2344@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B2344@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 13:33:43 -0000 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Rick Taylor > Sent: Tuesday, June 23, 2015 4:27 AM > To: RJ Atkinson; manet@ietf.org > Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 > = > Comments inline... > = > On 22/06/15 21:52, RJ Atkinson wrote: > > > >> On 22 Jun 2015, at 14:51 , Lou Berger wrote: > >> > >> > >> Stan, > >> On 6/19/2015 1:50 PM, Ratliff, Stanley wrote: > >>> So, we intentionally created a small (3? 4?) "Wild-wild-West sandbox" > >>> (the experiments), and the more formal Extensions mechanism, which > >>> by necessity, starts with an IETF draft. > >> > >> I believe the fairly typical way other protocols deal with this issue > >> is via proper IANA allocation policies, see rfc5226. For example the > >> single extensions field can be defined to have a range, say 1-N with > >> one policy and another range, say N-M with another policy. > >> > >> Based on the discussion I'd suggest : > >> > >> 0, Reserved > >> > >> 1-N "Standards Action" (for Standards Track > >> documents) or "Specification Required" > >> (for other documents, including experiment= al) > >> (The registry allows a request to indicate > >> which policy applies.) > >> > >> N- Private Use > >> > >> I think the private use space should be pretty small. > >> I'd also increase the Extension filed to be larger, as 256 seems > >> pretty small assuming the protocol has any level of success/long > >> life. > >> > >> Lou > > > > I agree that something along the lines of what Lou proposed above > > seems like a reasonable basis for a compromise. > > > > I concur that 256 is too small a number for . > > > > Quoting from RFC 5226, Section 4.1, Page 10: > > > > "Specification Required - Values and their meanings must be > > documented in a permanent and readily available public > > specification, in sufficient detail so that interoperabili= ty > > between independent implementations is possible. When use= d, > > Specification Required also implies use of a Designated > > Expert, who will review the public specification and > > evaluate whether it is sufficiently clear to allow > > interoperable implementations. The intention behind > > "permanent and readily available" is that a document can > > reasonably be expected to be findable and retrievable long > > after IANA assignment of the requested value. Publication > > of an RFC is an ideal means of achieving this requirement, > > but Specification Required is intended to also cover the > > case of a document published outside of the RFC path. For > > RFC publication, the normal RFC review process is expected > > to provide the necessary review for interoperability, thou= gh > > the Designated Expert may be a particularly well-qualified > > person to perform such a review. > > > > Examples: Diffserv-aware TE Bandwidth Constraints Model > > Identifiers [RFC4124], TLS ClientCertificateType Identifie= rs > > [RFC4346], ROHC Profile Identifiers [RFC4995]." > > > = > Okay, this seems sensible, given we expand the id bits to 16, and have no > special 0 value, then we can have a registry for data items and a second = for > signals, like so: > = > 0 - M: IANA allocated, DLEP 'core' ids (from this soon-to-be-RFC) > M - N: Reserved for IANA allocated Extensions ids (as they arrive) > N - 0xFFF: Private space, reserved for Experiments. > = > M is 26 for data items, and 16 for signals. > = > I am thinking, that N should be 0xFF00. I think the private space is too large. IMO, it shouldn't be any larger tha= n 5. = Regards, Stan > = > How's that? > = > Rick > = > = > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Tue Jun 23 06:34:16 2015 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 35AFE1B2BCE for ; Tue, 23 Jun 2015 06:34:15 -0700 (PDT) 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, MIME_QP_LONG_LINE=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 ImJrLaachXae for ; Tue, 23 Jun 2015 06:34:13 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA241B29C8 for ; Tue, 23 Jun 2015 06:34:13 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5NDY9CY031058; Tue, 23 Jun 2015 09:34:11 -0400 From: "Wiggins, David - 0665 - MITLL" To: Lou Berger , "Ratliff, Stanley" , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6q4BISdYAIk+JbR87kxTblJ2z4wAAgABgxAD//8+4AIAATJSAgATH2QCAAPa7gA== Date: Tue, 23 Jun 2015 13:34:10 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> In-Reply-To: <55885918.5020509@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3517896849_57143087" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-23_03:2015-06-22,2015-06-23,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-1506230213 Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 13:34:15 -0000 --B_3517896849_57143087 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Lou, I like this direction as a replacement for the experiment string. I think a unified mechanism simplifies understanding of the protocol. It seems like the implementation would be simpler too, since you don't have to make two different extension mechanisms play well together. A few questions below... On 6/22/15, 2:51 PM, "Lou Berger" wrote: > >Stan, >On 6/19/2015 1:50 PM, Ratliff, Stanley wrote: >> So, we intentionally created a small (3? 4?) "Wild-wild-West sandbox" >>(the experiments), and the more formal Extensions mechanism, which by >>necessity, starts with an IETF draft. > >I believe the fairly typical way other protocols deal with this issue is >via proper IANA allocation policies, see rfc5226. For example the single >extensions field can be defined to have a range, say 1-N with one policy >and another range, say N-M with another policy. > >Based on the discussion I'd suggest : >0, Reserved >1-N "Standards Action" (for Standards Track > documents) and "Specification Required" (for other > documents, including experimental) > (The registry allows a request to indicate which policy >applies) >N- Private Use The Reserved range above encompasses the entire range (I'm assuming refers to the same value in the 1st and 3rd case). So I'm not clear on the sense of "Reserved" here. For the Private Use range, which policy (from Ran's message a few days ago) do these follow? : A. The =B3private=B2 or =B3experimental=B2 use numbers are NOT allocated by IANA at all, instead being shared on a non-controlled basis, in which case packets with those code point values ought not escape one=B9s administrative=20 domain. =20 B. Some =B3private=B2 use numbers are allocated =B3First Come, First Serve=B2 with =B3no specification required=B2. C. A hybrid of scenarios A & B. In this case there are 3 different code=20 point subsets: (1) standards-track (2) private use & allocated by IANA (3) experimental use within one=B9s own administrative domain, not allocated by IANA, and =B3its your problem if you have 2 different implementations=B2 for a given code point value I like C (except Private Use would not include standards-track); you get a little bit of everything. David --B_3517896849_57143087 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFMHxQahkhaXGg86U DSpgekjhZjTpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYyMzEzMzQwOVowDQYJKoZIhvcNAQEBBQAEggEAbFhognPeRQwKCYsK7hvkgwLfs5geHImF 656IljKR+5B7c9+I3MzLGjoBLC6/Q91wL0Ee5vKbUUmo6BBPnOXiW6GiXt1DKXlWlyctlHGW NZ6F83/GJmmd+HgRB9nVEHTwBTMQyKjxb9pnZbCJ66QUZB+9CfuvauvJl9a8vNen+NHyVYFV sFqcfN1JO02u76xtvjHJbjYUQiAaRSWR3v0h0TrvIUUa0OmPn45Tc3WBjkfIYQm8V6XKbz8W 85+X0Lt4if+5brSI6ckbuRyqRuREp9IWZW5cQC+YtQp7WOvf4/MHneCkMqafQPXWAcAdkcX1 RfqiEJQwliZSeGE4etxLxw== --B_3517896849_57143087-- From nobody Tue Jun 23 07:10:16 2015 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 40D1F1A0211 for ; Tue, 23 Jun 2015 07:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 izUl_QYFzdf4 for ; Tue, 23 Jun 2015 07:10:13 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 46EE21B2C55 for ; Tue, 23 Jun 2015 07:08:06 -0700 (PDT) Received: (qmail 15982 invoked by uid 0); 23 Jun 2015 14:08:05 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy6.mail.unifiedlayer.com with SMTP; 23 Jun 2015 14:08:05 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id jpxc1q00r2SSUrH01pxfjY; Tue, 23 Jun 2015 07:57:43 -0600 X-Authority-Analysis: v=2.1 cv=RekDVTdv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=2gWURZ47ssWLdEEZ7voA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=KZRfp4MehC1K71zem/Q98nR/EoZblrF0K0kRumwrzOE=; b=ElG164U1jzRF2akh3wckrtrSABa4b4A/+slaWiz4ky7RDa/KVQEbZt9Gl0fjJ0ShbBe45vqZU46uGS3JsbEYejDnZ96Tsg9au04Ql15t6btCMooOYozZKRr6OOwcqbZJ; Received: from box313.bluehost.com ([69.89.31.113]:45138 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z7Orl-00016a-Gu; Tue, 23 Jun 2015 08:07:57 -0600 Message-ID: <5589681D.6010202@labn.net> Date: Tue, 23 Jun 2015 10:07:25 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Wiggins, David - 0665 - MITLL" , "Ratliff, Stanley" , RJ Atkinson , "manet@ietf.org" References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 14:10:15 -0000 David, See below. On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote: > Hi Lou, > > I like this direction as a replacement for the experiment string. I think > a unified mechanism simplifies understanding of the protocol. It seems > like the implementation would be simpler too, since you don't have to make > two different extension mechanisms play well together. A few questions > below... > > On 6/22/15, 2:51 PM, "Lou Berger" wrote: > >> Stan, >> On 6/19/2015 1:50 PM, Ratliff, Stanley wrote: >>> So, we intentionally created a small (3? 4?) "Wild-wild-West sandbox" >>> (the experiments), and the more formal Extensions mechanism, which by >>> necessity, starts with an IETF draft. >> I believe the fairly typical way other protocols deal with this issue is >> via proper IANA allocation policies, see rfc5226. For example the single >> extensions field can be defined to have a range, say 1-N with one policy >> and another range, say N-M with another policy. >> >> Based on the discussion I'd suggest : >> 0, Reserved >> 1-N "Standards Action" (for Standards Track >> documents) and "Specification Required" (for other >> documents, including experimental) >> (The registry allows a request to indicate which policy >> applies) >> N- Private Use > The Reserved range above encompasses the entire range (I'm assuming value> refers to the same value in the 1st and 3rd case). There was comma there. Let me try this: 0 Reserved Reserved > So I'm not clear on the sense of "Reserved" here. https://tools.ietf.org/html/rfc5226#section-4 Reserved: Not to be assigned. Reserved values are held for special uses, such as to extend the namespace when it become exhausted. Reserved values are not available for general assignment. > For the Private Use range, which policy (from Ran's message a few days > ago) do these follow? : > > A. The ³private² or ³experimental² use numbers are NOT allocated by IANA > at all, instead being shared on a non-controlled basis, in which case > packets with those code point values ought not escape one¹s > administrative > domain. > B. Some ³private² use numbers are allocated ³First Come, First Serve² > with > ³no specification required². > > C. A hybrid of scenarios A & B. In this case there are 3 different > code > point subsets: > (1) standards-track > (2) private use & allocated by IANA > (3) experimental use within one¹s own administrative domain, > not allocated by IANA, and ³its your problem if you have > 2 different implementations² for a given code point value > > > I like C (except Private Use would not include standards-track); you get a > little bit of everything. > The terms I used are also defined in rfc5226 Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG. Examples: BGP message types [RFC4271 ], Mobile Node Identifier option types [RFC4283 ], DCCP Packet Types [RFC4340 ]. Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path. For RFC publication, the normal RFC review process is expected to provide the necessary review for interoperability, though the Designated Expert may be a particularly well-qualified person to perform such a review. Examples: Diffserv-aware TE Bandwidth Constraints Model Identifiers [RFC4124 ], TLS ClientCertificateType Identifiers [RFC4346 ], ROHC Profile Identifiers [RFC4995 ]. Private Use - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments (since IANA does not record them) and assignments are not generally useful for broad interoperability. It is the responsibility of the sites making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). Examples: Site-specific options in DHCP [DHCP-IANA ], Fibre Channel Port Type Registry [RFC4044 ], Exchange Types in the IKEv2 header [RFC4306 ]. Lou > David From nobody Tue Jun 23 07:23:35 2015 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 D0FA81A9039 for ; Tue, 23 Jun 2015 07:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 SfTa6F343RUB for ; Tue, 23 Jun 2015 07:23:27 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id C35C61A8F42 for ; Tue, 23 Jun 2015 07:23:27 -0700 (PDT) Received: (qmail 23491 invoked by uid 0); 23 Jun 2015 14:23:20 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 23 Jun 2015 14:23:20 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id jwFx1q00v2SSUrH01wG0q6; Tue, 23 Jun 2015 14:16:08 -0600 X-Authority-Analysis: v=2.1 cv=auUhV0pV c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=FO1XMMZS__gV4D_EXpgA:9 a=93t665Iyh44WfsHR:21 a=zqvxQFX4Ht7LuBlg:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=xB0TmXmvy6jDe2BiYq6TBB4PQ3z42/vi9QUlEkUwsgA=; b=tLTWDhzvx+pC42a0yXYbjR8Q/G6OYap5lzbb4zqJwXcqp8+uX7wopR4W6unfumkzH0J3mH2w5EeJBLXBvZIgVCKs2SK4fq4ONh9yaXGJw4CCW2C64eBO1gUp1d5pi1jG; Received: from box313.bluehost.com ([69.89.31.113]:46635 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z7P6S-0004WI-T1; Tue, 23 Jun 2015 08:23:08 -0600 Message-ID: <55896BC8.4090108@labn.net> Date: Tue, 23 Jun 2015 10:23:04 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rick Taylor , RJ Atkinson , "manet@ietf.org" References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <243316EE-618B-495D-AA60-9F413AB04D2F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016C2B2344@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B2344@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 14:23:34 -0000 Rick, See below. On 6/23/2015 4:27 AM, Rick Taylor wrote: > Comments inline... > > On 22/06/15 21:52, RJ Atkinson wrote: >>> On 22 Jun 2015, at 14:51 , Lou Berger wrote: >>> >>> >>> Stan, >>> On 6/19/2015 1:50 PM, Ratliff, Stanley wrote: >>>> So, we intentionally created a small (3? 4?) "Wild-wild-West sandbox” >>>> (the experiments), and the more formal Extensions mechanism, >>>> which by necessity, starts with an IETF draft. >>> I believe the fairly typical way other protocols deal with this issue is >>> via proper IANA allocation policies, see rfc5226. For example the single >>> extensions field can be defined to have a range, say 1-N with one policy >>> and another range, say N-M with another policy. >>> >>> Based on the discussion I'd suggest : >>> >>> 0, Reserved >>> >>> 1-N "Standards Action" (for Standards Track >>> documents) or "Specification Required” >>> (for other documents, including experimental) >>> (The registry allows a request to indicate >>> which policy applies.) >>> >>> N- Private Use >>> >>> I think the private use space should be pretty small. >>> I'd also increase the Extension filed to be larger, >>> as 256 seems pretty small assuming the protocol has >>> any level of success/long life. >>> >>> Lou >> I agree that something along the lines of what Lou proposed above >> seems like a reasonable basis for a compromise. >> >> I concur that 256 is too small a number for . >> >> Quoting from RFC 5226, Section 4.1, Page 10: >> >> "Specification Required - Values and their meanings must be >> documented in a permanent and readily available public >> specification, in sufficient detail so that interoperability >> between independent implementations is possible. When used, >> Specification Required also implies use of a Designated >> Expert, who will review the public specification and >> evaluate whether it is sufficiently clear to allow >> interoperable implementations. The intention behind >> "permanent and readily available" is that a document can >> reasonably be expected to be findable and retrievable long >> after IANA assignment of the requested value. Publication >> of an RFC is an ideal means of achieving this requirement, >> but Specification Required is intended to also cover the >> case of a document published outside of the RFC path. For >> RFC publication, the normal RFC review process is expected >> to provide the necessary review for interoperability, though >> the Designated Expert may be a particularly well-qualified >> person to perform such a review. >> >> Examples: Diffserv-aware TE Bandwidth Constraints Model >> Identifiers [RFC4124], TLS ClientCertificateType Identifiers >> [RFC4346], ROHC Profile Identifiers [RFC4995]." >> > Okay, this seems sensible, given we expand the id bits to 16, and have > no special 0 value, then we can have a registry for data items and a > second for signals, like so: > > 0 - M: IANA allocated, DLEP 'core' ids (from this soon-to-be-RFC) > M - N: Reserved for IANA allocated Extensions ids (as they arrive) > N - 0xFFF: Private space, reserved for Experiments. I would not use the word experiments here as it has a specific meaning to iana. The "Private" policy as defined in rfc5226 should suffice. no? > M is 26 for data items, and 16 for signals. Given that signal values and data item values are carried in separate fields they are their own number spaces and should have their own registries. Assignment in each should start at 1. (1-16 for signals, 1-26 for data items.) To avoid issues in the long term, a single number base should be used (i.e., base 10). Lou > I am thinking, that N should be 0xFF00. > How's that? > > Rick > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Tue Jun 23 07:58:53 2015 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 15A0C1B2CD5 for ; Tue, 23 Jun 2015 07:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJjgguXg4NIS for ; Tue, 23 Jun 2015 07:58:48 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (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 269AB1B2CDB for ; Tue, 23 Jun 2015 07:58:48 -0700 (PDT) Received: by ykdr198 with SMTP id r198so6789905ykd.3 for ; Tue, 23 Jun 2015 07:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=zeGjMZJ3iOFDb6LxSBZKjEBaAdeXev4+vBzQqP4/gi0=; b=QDRfbdp9YjCYveoxDR19uGSCDUhpVKpWgK4BPSJq67C4ndIlMTBanN/hkrMpgLy337 8fFPVk4OnAFnVPD19oP8CYXD82X/xcGPeM5bV/FOmLH3IbhfHePTH04Gb+1OIqmsFOGg RJ6JP6+lU+KhM2kCzf9QKNdq6pXhgUaBvrKoOZ1bKlPMsiZ4Oibx81YiRfhubiUn75H/ JZeKD1Tqq/LcEDzI4e3AvduYaeVDfMny82xPc3paEVTGhxuYVdAh7MV/WzGI6KE9fSgQ EGum/k1AC9uXeQa0jVcbV2Eq2KtRaHUGtYh1o3na4qQqCy+qDH08RXRy9bHDKbUsa3Xb 05YQ== X-Received: by 10.129.128.199 with SMTP id q190mr6058570ywf.117.1435071527532; Tue, 23 Jun 2015 07:58:47 -0700 (PDT) Received: from [10.30.20.16] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id v31sm9967681yha.15.2015.06.23.07.58.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jun 2015 07:58:46 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: RJ Atkinson In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B2344@tss-server1.home.tropicalstormsoftware.com> Date: Tue, 23 Jun 2015 10:58:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <45D9DCD2-1DC5-4A30-8558-80374231F61C@gmail.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <243316EE-618B-495D-AA60-9F413AB04D2F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016C2B2344@tss-server1.home.tropicalstormsoftware.com> To: manet@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 14:58:51 -0000 > On 23 Jun 2015, at 04:27 , Rick Taylor = wrote: >=20 > Okay, this seems sensible, given we expand the id bits to 16, and have=20= > no special 0 value, I=92m not sure what =93no special 0 value=94 means just above. My understanding of Lou=92s proposal was that both 0 and max-value would be Reserved =97 as in not allocated/used. This is quite common in IETF standards-track protocols. > then we can have a registry for data items and a=20 > second for signals, like so: >=20 > 0 - M: IANA allocated, DLEP 'core' ids (from this soon-to-be-RFC) > M - N: Reserved for IANA allocated Extensions ids (as they arrive) Under Lou=92s proposal, any IANA allocated Extension ID either (A) would be IETF standards-track or (B) would be =93Specification Required=94 so anyone could implement it and be interoperable. With his proposal, it becomes trivial to move a non-standard extension into a standard extension =97 simply publish an RFC saying that extension with ID=3DX is now standards-track =97 without needing to change ANY code in ANY existing implementation. That has real interoperability advantages. So I don=92t see a value in separating these numeric ranges. With a 16-bit Data Item space, we don=92t need to separate them out. > N - 0xFFF: Private space, reserved for Experiments. Hmm. Can we please discuss this using integers, as is commonly done in standards-track RFC IANA Considerations sections, rather than discussing using a mixture of=20 integer and hexadecimal notations ? > M is 26 for data items, and 16 for signals. > I am thinking, that N should be 0xFF00. I am confused about precisely what is being proposed above, given the mixture of hex and decimal notations. For now, I prefer Lou=92s proposed approach, in part because I believe I understand what he is proposing. Yours, Ran From nobody Tue Jun 23 08:00:16 2015 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 BAD7D1ACD4F for ; Tue, 23 Jun 2015 08:00:15 -0700 (PDT) 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 yfCOqXvnsCcO for ; Tue, 23 Jun 2015 08:00:09 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 845911B2C75 for ; Tue, 23 Jun 2015 08:00:08 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5NF06u5006606; Tue, 23 Jun 2015 11:00:06 -0400 From: "Wiggins, David - 0665 - MITLL" To: Lou Berger , "Ratliff, Stanley" , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6q4BISdYAIk+JbR87kxTblJ2z4wAAgABgxAD//8+4AIAATJSAgATH2QCAAPa7gIAATFqA///LqIA= Date: Tue, 23 Jun 2015 15:00:06 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> In-Reply-To: <5589681D.6010202@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3517902005_57442426" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-23_03:2015-06-23,2015-06-23,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-1506230238 Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 15:00:15 -0000 --B_3517902005_57442426 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 6/23/15, 10:07 AM, "Lou Berger" wrote: >On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote: >>The Reserved range above encompasses the entire range (I'm assuming > value> refers to the same value in the 1st and 3rd case). >There was comma there. Let me try this: >0 Reserved > Reserved Yes, that was my confusion. You're reserving two values, not the whole range. >The terms I used are also defined in rfc5226 I plead guilty for not having read 5226, so the excerpts are helpful. Thanks. I guess we can do without the "no specification required, but still IANA-registered" option. David --B_3517902005_57442426 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFA4EzZQdFQEOzIGW 7V5oyY1In1HJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYyMzE1MDAwNVowDQYJKoZIhvcNAQEBBQAEggEAC78hm/JdBA5oMGShdKuOnHnXM7fi2Sb1 BCJM/i2z0eKFPxhhNTJMl4FgKUFNEieWhE1m/O6SlwT+eaJk9CgvxyL9GW/hV2cGtFapLBtc IIt1SQr+F6lN/m4hJjnPu24gZujWr1+VI28NW5uQEcd0tjBfeHpb1AE1b2WEjJHX+7ajlVxm 6fb3i8ThaWcFrz7CNwqqgnbwHZPZEXcFLK2YNjIs+LZIgG0U93BGanSG6EtBUEHJGv9yqMCx RT9UJzS2GjEeGsmBfO/yakqa2KZ5kHkNMAsT/rSdU0MxAB7PplCV7JJmsJtbbfU1IKj2kz38 89gOoTr2VJXz6Csy70v2Xg== --B_3517902005_57442426-- From nobody Tue Jun 23 08:41:09 2015 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 2FF021A8A1B for ; Tue, 23 Jun 2015 08:41:07 -0700 (PDT) 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 ffz6pRAIaspT for ; Tue, 23 Jun 2015 08:41:06 -0700 (PDT) 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 AD4051A89C7 for ; Tue, 23 Jun 2015 08:41:05 -0700 (PDT) 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 Jun 2015 16:40:40 +0100 From: Rick Taylor To: "Wiggins, David - 0665 - MITLL" , Lou Berger , "Ratliff, Stanley" , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY63v1bQ2j6/kOycfKuSsomuQ== Date: Tue, 23 Jun 2015 15:40:38 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> 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: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 15:41:07 -0000 First, apologies for mixing hex and decimal.=0A= =0A= Following from Lou's RFC5226 guidance:=0A= =0A= For data item ids:=0A= =0A= 0 - Reserved=0A= 1-20 - Standards Action - DLEP core=0A= 21-23 - Standards Action - Credit windowing=0A= 24-65519 - Specification Required - space for future Extensions=0A= 65520-65534 - Private Use - space for Experiments=0A= 65535 - Reserved=0A= =0A= For signal ids:=0A= =0A= 0 - Reserved=0A= 1-16 - Standards Action - DLEP core=0A= 17-65519 - Specification Required - space for future Extensions=0A= 65520-65534 - Private Use - space for Experiments=0A= 65535 - Reserved=0A= =0A= For Extension ids:=0A= =0A= 0 - Reserved=0A= 1 - Standards Action - DLEP Credit Windowing=0A= 17-65534 - Specification Required - future Extension ids=0A= 65535 - Reserved=0A= =0A= Experiments MUST use the Private Use area. Extensions MUST use the =0A= Specification Required area.=0A= =0A= Hope that's clearer?=0A= =0A= Rick=0A= =0A= On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote:=0A= > On 6/23/15, 10:07 AM, "Lou Berger" wrote:=0A= >> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote:=0A= >>> The Reserved range above encompasses the entire range (I'm assuming >> value> refers to the same value in the 1st and 3rd case).=0A= >> There was comma there. Let me try this:=0A= >> 0 Reserved=0A= >> Reserved=0A= >=0A= > Yes, that was my confusion. You're reserving two values, not the whole= =0A= > range.=0A= >=0A= >> The terms I used are also defined in rfc5226=0A= >=0A= > I plead guilty for not having read 5226, so the excerpts are helpful.=0A= > Thanks. I guess we can do without the "no specification required, but=0A= > still IANA-registered" option.=0A= >=0A= > David=0A= >=0A= =0A= From nobody Tue Jun 23 08:43:20 2015 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 B49E91A8ADC for ; Tue, 23 Jun 2015 08:43:18 -0700 (PDT) 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 uHF4fsgeXxlx for ; Tue, 23 Jun 2015 08:43:17 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id E5BE61A8ACC for ; Tue, 23 Jun 2015 08:43:16 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,666,1427774400"; d="scan'208";a="8185996" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport2.idirect.net with ESMTP; 23 Jun 2015 11:43:16 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 23 Jun 2015 11:43:15 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Tue, 23 Jun 2015 11:43:15 -0400 From: "Ratliff, Stanley" To: Rick Taylor , "Wiggins, David - 0665 - MITLL" , Lou Berger , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6Mo+Tw3COyECGObxkTDTDb526QqGQ Date: Tue, 23 Jun 2015 15:43:14 +0000 Message-ID: <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 15:43:18 -0000 Rick, = I'm still of the opinion that the private-use space is too large. = Regards, Stan > -----Original Message----- > From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] > Sent: Tuesday, June 23, 2015 11:41 AM > To: Wiggins, David - 0665 - MITLL; Lou Berger; Ratliff, Stanley; RJ Atkin= son; > manet@ietf.org > Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 > = > First, apologies for mixing hex and decimal. > = > Following from Lou's RFC5226 guidance: > = > For data item ids: > = > 0 - Reserved > 1-20 - Standards Action - DLEP core > 21-23 - Standards Action - Credit windowing > 24-65519 - Specification Required - space for future Extensions > 65520-65534 - Private Use - space for Experiments > 65535 - Reserved > = > For signal ids: > = > 0 - Reserved > 1-16 - Standards Action - DLEP core > 17-65519 - Specification Required - space for future Extensions > 65520-65534 - Private Use - space for Experiments > 65535 - Reserved > = > For Extension ids: > = > 0 - Reserved > 1 - Standards Action - DLEP Credit Windowing > 17-65534 - Specification Required - future Extension ids > 65535 - Reserved > = > Experiments MUST use the Private Use area. Extensions MUST use the > Specification Required area. > = > Hope that's clearer? > = > Rick > = > On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote: > > On 6/23/15, 10:07 AM, "Lou Berger" wrote: > >> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote: > >>> The Reserved range above encompasses the entire range (I'm assuming > >>> >>> value> refers to the same value in the 1st and 3rd case). > >> There was comma there. Let me try this: > >> 0 Reserved > >> Reserved > > > > Yes, that was my confusion. You're reserving two values, not the > > whole range. > > > >> The terms I used are also defined in rfc5226 > > > > I plead guilty for not having read 5226, so the excerpts are helpful. > > Thanks. I guess we can do without the "no specification required, but > > still IANA-registered" option. > > > > David > > _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Tue Jun 23 08:47:46 2015 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 920711A8AF3 for ; Tue, 23 Jun 2015 08:47:45 -0700 (PDT) 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 ITFGkZieWXPB for ; Tue, 23 Jun 2015 08:47:44 -0700 (PDT) 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 A40751A8AD7 for ; Tue, 23 Jun 2015 08:47:43 -0700 (PDT) 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 Jun 2015 16:47:13 +0100 From: Rick Taylor To: "Wiggins, David - 0665 - MITLL" , Lou Berger , "Ratliff, Stanley" , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY63v1bQ2j6/kOycfKuSsomuQ== Date: Tue, 23 Jun 2015 15:47:11 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2B5D45@tss-server1.home.tropicalstormsoftware.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@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: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 15:47:45 -0000 Oops, cut'n'paste problem!=0A= =0A= Should be:=0A= =0A= For Extension ids:=0A= =0A= 0 - Reserved=0A= 1 - Standards Action - DLEP Credit Windowing=0A= 2-65534 - Specification Required - future Extension ids=0A= 65535 - Reserved=0A= =0A= Sorry=0A= =0A= Rick=0A= =0A= On 23/06/15 16:41, Rick Taylor wrote:=0A= > First, apologies for mixing hex and decimal.=0A= >=0A= > Following from Lou's RFC5226 guidance:=0A= >=0A= > For data item ids:=0A= >=0A= > 0 - Reserved=0A= > 1-20 - Standards Action - DLEP core=0A= > 21-23 - Standards Action - Credit windowing=0A= > 24-65519 - Specification Required - space for future Extensions=0A= > 65520-65534 - Private Use - space for Experiments=0A= > 65535 - Reserved=0A= >=0A= > For signal ids:=0A= >=0A= > 0 - Reserved=0A= > 1-16 - Standards Action - DLEP core=0A= > 17-65519 - Specification Required - space for future Extensions=0A= > 65520-65534 - Private Use - space for Experiments=0A= > 65535 - Reserved=0A= >=0A= > For Extension ids:=0A= >=0A= > 0 - Reserved=0A= > 1 - Standards Action - DLEP Credit Windowing=0A= > 17-65534 - Specification Required - future Extension ids=0A= > 65535 - Reserved=0A= >=0A= > Experiments MUST use the Private Use area. Extensions MUST use the=0A= > Specification Required area.=0A= >=0A= > Hope that's clearer?=0A= >=0A= > Rick=0A= >=0A= > On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote:=0A= >> On 6/23/15, 10:07 AM, "Lou Berger" wrote:=0A= >>> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote:=0A= >>>> The Reserved range above encompasses the entire range (I'm assuming >>> value> refers to the same value in the 1st and 3rd case).=0A= >>> There was comma there. Let me try this:=0A= >>> 0 Reserved=0A= >>> Reserved=0A= >>=0A= >> Yes, that was my confusion. You're reserving two values, not the whole= =0A= >> range.=0A= >>=0A= >>> The terms I used are also defined in rfc5226=0A= >>=0A= >> I plead guilty for not having read 5226, so the excerpts are helpful.=0A= >> Thanks. I guess we can do without the "no specification required, but= =0A= >> still IANA-registered" option.=0A= >>=0A= >> David=0A= >>=0A= >=0A= >=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= =0A= From nobody Tue Jun 23 08:49:03 2015 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 B54B91A8AF3 for ; Tue, 23 Jun 2015 08:48:51 -0700 (PDT) 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 Yt1Hl_27ze88 for ; Tue, 23 Jun 2015 08:48:50 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 986E01A8EA9 for ; Tue, 23 Jun 2015 08:48:49 -0700 (PDT) Received: by wiwl6 with SMTP id l6so70553662wiw.0 for ; Tue, 23 Jun 2015 08:48:48 -0700 (PDT) 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=s6q5LTkS4I79H+V5tFzK9pJCniH8ONM1Lz3YTUnKV44=; b=aPUJDM9oOrbXi3w3BL6ShJyNHErl9sY1TamY5soLFZlpUgEPzX9qO4rwoSb6hoUaU7 1QAn6LWzXn9YOQLyRHKS0ivTMpCPkLQGy68cKWMs3PEjyKqyjGnNnRiXcwARVg1k4iIV 2aGplLeMXeaADDdXpOQHzAEEF9IZgbVWMOBFzOfNh9lCcIA46yOJGeKTYQlsDZekxKx4 dTk36EP+Fte92Lqep+bxrCfQ2dSLP+xD5D7araiYb6S49frQuAvzngjKX2rDxOWKg4mZ nfJbD4ACPBpVn5PyN+I/t+DUqlLiN2o48c3tqHVk1mjdmUZeDauaNnsdNkTIyVY/oRIr ugYQ== X-Received: by 10.180.94.35 with SMTP id cz3mr4693121wib.85.1435074528386; Tue, 23 Jun 2015 08:48:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Tue, 23 Jun 2015 08:48:18 -0700 (PDT) In-Reply-To: <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> From: Henning Rogge Date: Tue, 23 Jun 2015 17:48:18 +0200 Message-ID: To: "Ratliff, Stanley" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "manet@ietf.org" , RJ Atkinson Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 15:48:51 -0000 Stan, my "layer 2 frame statistics" would need (if I want to transmit everything) 8 or 10 data items... the "layer1 data export" is I think 6 or 8 data items. I think 15 TLV types for experiments is not that much. It might not even be enough to run both of my experiments at the same time. Henning On Tue, Jun 23, 2015 at 5:43 PM, Ratliff, Stanley wrote: > Rick, > > I'm still of the opinion that the private-use space is too large. > > Regards, > Stan > > >> -----Original Message----- >> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] >> Sent: Tuesday, June 23, 2015 11:41 AM >> To: Wiggins, David - 0665 - MITLL; Lou Berger; Ratliff, Stanley; RJ Atkinson; >> manet@ietf.org >> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 >> >> First, apologies for mixing hex and decimal. >> >> Following from Lou's RFC5226 guidance: >> >> For data item ids: >> >> 0 - Reserved >> 1-20 - Standards Action - DLEP core >> 21-23 - Standards Action - Credit windowing >> 24-65519 - Specification Required - space for future Extensions >> 65520-65534 - Private Use - space for Experiments >> 65535 - Reserved >> >> For signal ids: >> >> 0 - Reserved >> 1-16 - Standards Action - DLEP core >> 17-65519 - Specification Required - space for future Extensions >> 65520-65534 - Private Use - space for Experiments >> 65535 - Reserved >> >> For Extension ids: >> >> 0 - Reserved >> 1 - Standards Action - DLEP Credit Windowing >> 17-65534 - Specification Required - future Extension ids >> 65535 - Reserved >> >> Experiments MUST use the Private Use area. Extensions MUST use the >> Specification Required area. >> >> Hope that's clearer? >> >> Rick >> >> On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote: >> > On 6/23/15, 10:07 AM, "Lou Berger" wrote: >> >> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote: >> >>> The Reserved range above encompasses the entire range (I'm assuming >> >>> > >>> value> refers to the same value in the 1st and 3rd case). >> >> There was comma there. Let me try this: >> >> 0 Reserved >> >> Reserved >> > >> > Yes, that was my confusion. You're reserving two values, not the >> > whole range. >> > >> >> The terms I used are also defined in rfc5226 >> > >> > I plead guilty for not having read 5226, so the excerpts are helpful. >> > Thanks. I guess we can do without the "no specification required, but >> > still IANA-registered" option. >> > >> > David >> > > > > _____________________________________________________ > This electronic message and any files transmitted with it contains > information from iDirect, which may be privileged, proprietary > and/or confidential. It is intended solely for the use of the individual > or entity to whom they are addressed. If you are not the original > recipient or the person responsible for delivering the email to the > intended recipient, be advised that you have received this email > in error, and that any use, dissemination, forwarding, printing, or > copying of this email is strictly prohibited. If you received this email > in error, please delete it and immediately notify the sender. > _____________________________________________________ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Jun 23 08:50:55 2015 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 50E3E1A9076 for ; Tue, 23 Jun 2015 08:50:54 -0700 (PDT) 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 DzLxmewn0CNv for ; Tue, 23 Jun 2015 08:50:51 -0700 (PDT) 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 2F2471A9073 for ; Tue, 23 Jun 2015 08:50:51 -0700 (PDT) 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 Jun 2015 16:50:18 +0100 From: Rick Taylor To: "Ratliff, Stanley" , "Wiggins, David - 0665 - MITLL" , Lou Berger , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY63v1bQ2j6/kOycfKuSsomuQ== Date: Tue, 23 Jun 2015 15:50:17 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2B5D61@tss-server1.home.tropicalstormsoftware.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> 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: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 15:50:54 -0000 Stan,=0A= =0A= I'm not convinced. If we put in the effort to allow (possibly multiple) = =0A= experiments, we may as well give them enough room to run them.=0A= =0A= I would personally like to give them more than 14 ids. 254 seems more =0A= generous, but I know you are worried about being too 'loose'.=0A= =0A= Rick=0A= =0A= =0A= =0A= On 23/06/15 16:43, Ratliff, Stanley wrote:=0A= > Rick,=0A= >=0A= > I'm still of the opinion that the private-use space is too large.=0A= >=0A= > Regards,=0A= > Stan=0A= >=0A= >=0A= >> -----Original Message-----=0A= >> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com]=0A= >> Sent: Tuesday, June 23, 2015 11:41 AM=0A= >> To: Wiggins, David - 0665 - MITLL; Lou Berger; Ratliff, Stanley; RJ Atki= nson;=0A= >> manet@ietf.org=0A= >> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14=0A= >>=0A= >> First, apologies for mixing hex and decimal.=0A= >>=0A= >> Following from Lou's RFC5226 guidance:=0A= >>=0A= >> For data item ids:=0A= >>=0A= >> 0 - Reserved=0A= >> 1-20 - Standards Action - DLEP core=0A= >> 21-23 - Standards Action - Credit windowing=0A= >> 24-65519 - Specification Required - space for future Extensions=0A= >> 65520-65534 - Private Use - space for Experiments=0A= >> 65535 - Reserved=0A= >>=0A= >> For signal ids:=0A= >>=0A= >> 0 - Reserved=0A= >> 1-16 - Standards Action - DLEP core=0A= >> 17-65519 - Specification Required - space for future Extensions=0A= >> 65520-65534 - Private Use - space for Experiments=0A= >> 65535 - Reserved=0A= >>=0A= >> For Extension ids:=0A= >>=0A= >> 0 - Reserved=0A= >> 1 - Standards Action - DLEP Credit Windowing=0A= >> 17-65534 - Specification Required - future Extension ids=0A= >> 65535 - Reserved=0A= >>=0A= >> Experiments MUST use the Private Use area. Extensions MUST use the=0A= >> Specification Required area.=0A= >>=0A= >> Hope that's clearer?=0A= >>=0A= >> Rick=0A= >>=0A= >> On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote:=0A= >>> On 6/23/15, 10:07 AM, "Lou Berger" wrote:=0A= >>>> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote:=0A= >>>>> The Reserved range above encompasses the entire range (I'm assuming= =0A= >>>>> >>>> value> refers to the same value in the 1st and 3rd case).=0A= >>>> There was comma there. Let me try this:=0A= >>>> 0 Reserved=0A= >>>> Reserved=0A= >>>=0A= >>> Yes, that was my confusion. You're reserving two values, not the=0A= >>> whole range.=0A= >>>=0A= >>>> The terms I used are also defined in rfc5226=0A= >>>=0A= >>> I plead guilty for not having read 5226, so the excerpts are helpful.= =0A= >>> Thanks. I guess we can do without the "no specification required, but= =0A= >>> still IANA-registered" option.=0A= >>>=0A= >>> David=0A= >>>=0A= >=0A= >=0A= > _____________________________________________________=0A= > This electronic message and any files transmitted with it contains=0A= > information from iDirect, which may be privileged, proprietary=0A= > and/or confidential. It is intended solely for the use of the individual= =0A= > or entity to whom they are addressed. If you are not the original=0A= > recipient or the person responsible for delivering the email to the=0A= > intended recipient, be advised that you have received this email=0A= > in error, and that any use, dissemination, forwarding, printing, or=0A= > copying of this email is strictly prohibited. If you received this email= =0A= > in error, please delete it and immediately notify the sender.=0A= > _____________________________________________________=0A= >=0A= >=0A= =0A= From nobody Tue Jun 23 08:52:01 2015 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 8207B1A90D1 for ; Tue, 23 Jun 2015 08:51:59 -0700 (PDT) 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 SUVBbh7iNJfM for ; Tue, 23 Jun 2015 08:51:53 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5819C1A90A1 for ; Tue, 23 Jun 2015 08:51:45 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5NFpfJX023349; Tue, 23 Jun 2015 11:51:44 -0400 From: "Wiggins, David - 0665 - MITLL" To: Rick Taylor , Lou Berger , "Ratliff, Stanley" , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6q4BISdYAIk+JbR87kxTblJ26RRIA Date: Tue, 23 Jun 2015 15:51:43 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2B5D45@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B5D45@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3517905102_57654100" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-23_06:2015-06-23,2015-06-23,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-1506230250 Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 15:51:59 -0000 --B_3517905102_57654100 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I think we need some Private Use extension ids too. David On 6/23/15, 11:47 AM, "Rick Taylor" wrote: >Oops, cut'n'paste problem! > >Should be: > >For Extension ids: > >0 - Reserved >1 - Standards Action - DLEP Credit Windowing >2-65534 - Specification Required - future Extension ids >65535 - Reserved > >Sorry > >Rick > >On 23/06/15 16:41, Rick Taylor wrote: >> First, apologies for mixing hex and decimal. >> >> Following from Lou's RFC5226 guidance: >> >> For data item ids: >> >> 0 - Reserved >> 1-20 - Standards Action - DLEP core >> 21-23 - Standards Action - Credit windowing >> 24-65519 - Specification Required - space for future Extensions >> 65520-65534 - Private Use - space for Experiments >> 65535 - Reserved >> >> For signal ids: >> >> 0 - Reserved >> 1-16 - Standards Action - DLEP core >> 17-65519 - Specification Required - space for future Extensions >> 65520-65534 - Private Use - space for Experiments >> 65535 - Reserved >> >> For Extension ids: >> >> 0 - Reserved >> 1 - Standards Action - DLEP Credit Windowing >> 17-65534 - Specification Required - future Extension ids >> 65535 - Reserved >> >> Experiments MUST use the Private Use area. Extensions MUST use the >> Specification Required area. >> >> Hope that's clearer? >> >> Rick >> >> On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote: >>> On 6/23/15, 10:07 AM, "Lou Berger" wrote: >>>> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote: >>>>> The Reserved range above encompasses the entire range (I'm assuming >>>>>>>>> value> refers to the same value in the 1st and 3rd case). >>>> There was comma there. Let me try this: >>>> 0 Reserved >>>> Reserved >>> >>> Yes, that was my confusion. You're reserving two values, not the whole >>> range. >>> >>>> The terms I used are also defined in rfc5226 >>> >>> I plead guilty for not having read 5226, so the excerpts are helpful. >>> Thanks. I guess we can do without the "no specification required, but >>> still IANA-registered" option. >>> >>> David >>> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > --B_3517905102_57654100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFD0SLGAC19V44SsJ P7F91TBSq+h0MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYyMzE1NTE0MlowDQYJKoZIhvcNAQEBBQAEggEAbR1CG5d19ftyu3rh+hCdfYRqe418k/zy 6L2cz5g6dV3yxP52efOjXcQBo3RXQk6ecgH+ib4sgDpN9Vq+MIiykZj2SGvfx225eddU3qcd kKIBrUpC5ZuNhinNSnhk8jdl8RvJ7mEU/MrQZOTrBzHk0gMNG0Iomz3woysOMoz9RMo+KKaC cIZDXpFZqFiBIPy7dFFRPp0naZ1PMv/XCFTmiLmHC2RBzTNXOqBZlynQuzAPE27yZNZJfs7q 5oj6y5y5QVFl4Ytg8Kuh0fRelw+22zDbNgQ4wcUK1BOJ+fF8e+wfTA1Q0f+qDLeWSC9dB8Im g8i6UJS2tmho1TfEJ01QfQ== --B_3517905102_57654100-- From nobody Tue Jun 23 08:57:13 2015 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 38A5B1A6F11 for ; Tue, 23 Jun 2015 08:57:11 -0700 (PDT) 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 56O9DTCXD2uF for ; Tue, 23 Jun 2015 08:57:09 -0700 (PDT) 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 3ED981A8BB3 for ; Tue, 23 Jun 2015 08:57:09 -0700 (PDT) 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 Jun 2015 16:56:30 +0100 From: Rick Taylor To: "Wiggins, David - 0665 - MITLL" , Lou Berger , "Ratliff, Stanley" , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY63v1bQ2j6/kOycfKuSsomuQ== Date: Tue, 23 Jun 2015 15:56:29 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2B5DAD@tss-server1.home.tropicalstormsoftware.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2B5D45@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: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 15:57:11 -0000 On 23/06/15 16:51, Wiggins, David - 0665 - MITLL wrote:=0A= > I think we need some Private Use extension ids too.=0A= =0A= No, Extensions are Specification Required by design. Experiments are =0A= provided for Private Use id use.=0A= =0A= Rick=0A= =0A= >=0A= > David=0A= >=0A= > On 6/23/15, 11:47 AM, "Rick Taylor" wrot= e:=0A= >=0A= >> Oops, cut'n'paste problem!=0A= >>=0A= >> Should be:=0A= >>=0A= >> For Extension ids:=0A= >>=0A= >> 0 - Reserved=0A= >> 1 - Standards Action - DLEP Credit Windowing=0A= >> 2-65534 - Specification Required - future Extension ids=0A= >> 65535 - Reserved=0A= >>=0A= >> Sorry=0A= >>=0A= >> Rick=0A= >>=0A= >> On 23/06/15 16:41, Rick Taylor wrote:=0A= >>> First, apologies for mixing hex and decimal.=0A= >>>=0A= >>> Following from Lou's RFC5226 guidance:=0A= >>>=0A= >>> For data item ids:=0A= >>>=0A= >>> 0 - Reserved=0A= >>> 1-20 - Standards Action - DLEP core=0A= >>> 21-23 - Standards Action - Credit windowing=0A= >>> 24-65519 - Specification Required - space for future Extensions=0A= >>> 65520-65534 - Private Use - space for Experiments=0A= >>> 65535 - Reserved=0A= >>>=0A= >>> For signal ids:=0A= >>>=0A= >>> 0 - Reserved=0A= >>> 1-16 - Standards Action - DLEP core=0A= >>> 17-65519 - Specification Required - space for future Extensions=0A= >>> 65520-65534 - Private Use - space for Experiments=0A= >>> 65535 - Reserved=0A= >>>=0A= >>> For Extension ids:=0A= >>>=0A= >>> 0 - Reserved=0A= >>> 1 - Standards Action - DLEP Credit Windowing=0A= >>> 17-65534 - Specification Required - future Extension ids=0A= >>> 65535 - Reserved=0A= >>>=0A= >>> Experiments MUST use the Private Use area. Extensions MUST use the=0A= >>> Specification Required area.=0A= >>>=0A= >>> Hope that's clearer?=0A= >>>=0A= >>> Rick=0A= >>>=0A= >>> On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote:=0A= >>>> On 6/23/15, 10:07 AM, "Lou Berger" wrote:=0A= >>>>> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote:=0A= >>>>>> The Reserved range above encompasses the entire range (I'm assuming= =0A= >>>>>> >>>>> value> refers to the same value in the 1st and 3rd case).=0A= >>>>> There was comma there. Let me try this:=0A= >>>>> 0 Reserved=0A= >>>>> Reserved=0A= >>>>=0A= >>>> Yes, that was my confusion. You're reserving two values, not the whol= e=0A= >>>> range.=0A= >>>>=0A= >>>>> The terms I used are also defined in rfc5226=0A= >>>>=0A= >>>> I plead guilty for not having read 5226, so the excerpts are helpful.= =0A= >>>> Thanks. I guess we can do without the "no specification required, but= =0A= >>>> still IANA-registered" option.=0A= >>>>=0A= >>>> David=0A= >>>>=0A= >>>=0A= >>>=0A= >>> _______________________________________________=0A= >>> manet mailing list=0A= >>> manet@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/manet=0A= >>>=0A= >>=0A= =0A= From nobody Tue Jun 23 08:57:55 2015 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 B8F0A1A910E for ; Tue, 23 Jun 2015 08:57:53 -0700 (PDT) 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 Ihf9gHqJQoUc for ; Tue, 23 Jun 2015 08:57:51 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id F15A61A923A for ; Tue, 23 Jun 2015 08:57:40 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5NFvdAI032435; Tue, 23 Jun 2015 11:57:39 -0400 From: "Wiggins, David - 0665 - MITLL" To: Rick Taylor , "Ratliff, Stanley" , Lou Berger , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6q4BISdYAIk+JbR87kxTblJ26RrsA Date: Tue, 23 Jun 2015 15:57:38 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5D61@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B5D61@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3517905458_57678576" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-23_06:2015-06-23,2015-06-23,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-1506230251 Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 15:57:53 -0000 --B_3517905458_57678576 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I also think the private space is too small. The effect could be to force people to encroach on the Specification Required space to get more Privates, making the division meaningless. 254 would probably be enough, though I'm not really seeing the harm in making it even larger. David On 6/23/15, 11:50 AM, "Rick Taylor" wrote: >Stan, > >I'm not convinced. If we put in the effort to allow (possibly multiple) >experiments, we may as well give them enough room to run them. > >I would personally like to give them more than 14 ids. 254 seems more >generous, but I know you are worried about being too 'loose'. > >Rick > > > >On 23/06/15 16:43, Ratliff, Stanley wrote: >> Rick, >> >> I'm still of the opinion that the private-use space is too large. >> >> Regards, >> Stan >> >> >>> -----Original Message----- >>> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] >>> Sent: Tuesday, June 23, 2015 11:41 AM >>> To: Wiggins, David - 0665 - MITLL; Lou Berger; Ratliff, Stanley; RJ >>>Atkinson; >>> manet@ietf.org >>> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 >>> >>> First, apologies for mixing hex and decimal. >>> >>> Following from Lou's RFC5226 guidance: >>> >>> For data item ids: >>> >>> 0 - Reserved >>> 1-20 - Standards Action - DLEP core >>> 21-23 - Standards Action - Credit windowing >>> 24-65519 - Specification Required - space for future Extensions >>> 65520-65534 - Private Use - space for Experiments >>> 65535 - Reserved >>> >>> For signal ids: >>> >>> 0 - Reserved >>> 1-16 - Standards Action - DLEP core >>> 17-65519 - Specification Required - space for future Extensions >>> 65520-65534 - Private Use - space for Experiments >>> 65535 - Reserved >>> >>> For Extension ids: >>> >>> 0 - Reserved >>> 1 - Standards Action - DLEP Credit Windowing >>> 17-65534 - Specification Required - future Extension ids >>> 65535 - Reserved >>> >>> Experiments MUST use the Private Use area. Extensions MUST use the >>> Specification Required area. >>> >>> Hope that's clearer? >>> >>> Rick >>> >>> On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote: >>>> On 6/23/15, 10:07 AM, "Lou Berger" wrote: >>>>> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote: >>>>>> The Reserved range above encompasses the entire range (I'm assuming >>>>>> >>>>> value> refers to the same value in the 1st and 3rd case). >>>>> There was comma there. Let me try this: >>>>> 0 Reserved >>>>> Reserved >>>> >>>> Yes, that was my confusion. You're reserving two values, not the >>>> whole range. >>>> >>>>> The terms I used are also defined in rfc5226 >>>> >>>> I plead guilty for not having read 5226, so the excerpts are helpful. >>>> Thanks. I guess we can do without the "no specification required, but >>>> still IANA-registered" option. >>>> >>>> David >>>> >> >> >> _____________________________________________________ >> This electronic message and any files transmitted with it contains >> information from iDirect, which may be privileged, proprietary >> and/or confidential. It is intended solely for the use of the individual >> or entity to whom they are addressed. If you are not the original >> recipient or the person responsible for delivering the email to the >> intended recipient, be advised that you have received this email >> in error, and that any use, dissemination, forwarding, printing, or >> copying of this email is strictly prohibited. If you received this email >> in error, please delete it and immediately notify the sender. >> _____________________________________________________ >> >> > --B_3517905458_57678576 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFEBkAwNzXqD+Z951 OvL9l3MbapKgMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYyMzE1NTczOFowDQYJKoZIhvcNAQEBBQAEggEAMYJRubIpXbSwe4kyoERZVp2ypt1ZWbYZ zfJe1+c2NzX88oWRnPUCBx942MAKt1UTRWGJi953fJkuXxAdh14nojtyDCYBCEKgSM1IL8mX MskUdGumdi5e5WCh5XWq61p/AAn72f+PJEVtk39kwpHQA49aGdUU4RXLFiFS4jmVO4E/eOjw lJm+whnzZqMHrVxvyY/ZKEi/shfPiKwQSNq4FCSakJDEYRGCRlso7G/WXzSoxTCme9VWEYvG Zos+dB+vJ5Y87rAlNPG99Aw3Li9uuitttv0ISB7X/PTVYOz9jpwtU3RbpWkuZfAFu3Xm8nfG o/fSLECsT/C0NY/KJgJ4Rw== --B_3517905458_57678576-- From nobody Tue Jun 23 09:25:30 2015 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 CF5821ACE4B for ; Tue, 23 Jun 2015 09:25:28 -0700 (PDT) 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 hzyO0AdxVvo7 for ; Tue, 23 Jun 2015 09:25:27 -0700 (PDT) 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 A67E61ACE2B for ; Tue, 23 Jun 2015 09:25:26 -0700 (PDT) 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 Jun 2015 17:25:01 +0100 From: Rick Taylor To: "Wiggins, David - 0665 - MITLL" , "Ratliff, Stanley" , Lou Berger , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY63v1bQ2j6/kOycfKuSsomuQ== Date: Tue, 23 Jun 2015 16:25:00 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2B5F16@tss-server1.home.tropicalstormsoftware.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5D61@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: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 16:25:29 -0000 The original reasons for having a very small Private Use space were:=0A= =0A= 1) We only had 256 ids.=0A= =0A= 2) We didn't want experiments to become de-facto Extensions.=0A= =0A= 3) We were worried that a more generous Private Use space would set of =0A= alarm bells at the draft passed through the various review stages.=0A= =0A= Now with the wider id field, 1) is now irrelevant, but we need guidance =0A= on 3), and 2) might be impossible to solve.=0A= =0A= Lou, do you have a comment?=0A= =0A= Rick=0A= =0A= =0A= On 23/06/15 16:57, Wiggins, David - 0665 - MITLL wrote:=0A= > I also think the private space is too small. The effect could be to forc= e=0A= > people to encroach on the Specification Required space to get more=0A= > Privates, making the division meaningless. 254 would probably be enough,= =0A= > though I'm not really seeing the harm in making it even larger.=0A= >=0A= > David=0A= >=0A= > On 6/23/15, 11:50 AM, "Rick Taylor" wrot= e:=0A= >=0A= >> Stan,=0A= >>=0A= >> I'm not convinced. If we put in the effort to allow (possibly multiple)= =0A= >> experiments, we may as well give them enough room to run them.=0A= >>=0A= >> I would personally like to give them more than 14 ids. 254 seems more=0A= >> generous, but I know you are worried about being too 'loose'.=0A= >>=0A= >> Rick=0A= >>=0A= >>=0A= >>=0A= >> On 23/06/15 16:43, Ratliff, Stanley wrote:=0A= >>> Rick,=0A= >>>=0A= >>> I'm still of the opinion that the private-use space is too large.=0A= >>>=0A= >>> Regards,=0A= >>> Stan=0A= >>>=0A= >>>=0A= >>>> -----Original Message-----=0A= >>>> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com]=0A= >>>> Sent: Tuesday, June 23, 2015 11:41 AM=0A= >>>> To: Wiggins, David - 0665 - MITLL; Lou Berger; Ratliff, Stanley; RJ=0A= >>>> Atkinson;=0A= >>>> manet@ietf.org=0A= >>>> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14=0A= >>>>=0A= >>>> First, apologies for mixing hex and decimal.=0A= >>>>=0A= >>>> Following from Lou's RFC5226 guidance:=0A= >>>>=0A= >>>> For data item ids:=0A= >>>>=0A= >>>> 0 - Reserved=0A= >>>> 1-20 - Standards Action - DLEP core=0A= >>>> 21-23 - Standards Action - Credit windowing=0A= >>>> 24-65519 - Specification Required - space for future Extensions=0A= >>>> 65520-65534 - Private Use - space for Experiments=0A= >>>> 65535 - Reserved=0A= >>>>=0A= >>>> For signal ids:=0A= >>>>=0A= >>>> 0 - Reserved=0A= >>>> 1-16 - Standards Action - DLEP core=0A= >>>> 17-65519 - Specification Required - space for future Extensions=0A= >>>> 65520-65534 - Private Use - space for Experiments=0A= >>>> 65535 - Reserved=0A= >>>>=0A= >>>> For Extension ids:=0A= >>>>=0A= >>>> 0 - Reserved=0A= >>>> 1 - Standards Action - DLEP Credit Windowing=0A= >>>> 17-65534 - Specification Required - future Extension ids=0A= >>>> 65535 - Reserved=0A= >>>>=0A= >>>> Experiments MUST use the Private Use area. Extensions MUST use the=0A= >>>> Specification Required area.=0A= >>>>=0A= >>>> Hope that's clearer?=0A= >>>>=0A= >>>> Rick=0A= >>>>=0A= >>>> On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote:=0A= >>>>> On 6/23/15, 10:07 AM, "Lou Berger" wrote:=0A= >>>>>> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote:=0A= >>>>>>> The Reserved range above encompasses the entire range (I'm assuming= =0A= >>>>>>> >>>>>> value> refers to the same value in the 1st and 3rd case).=0A= >>>>>> There was comma there. Let me try this:=0A= >>>>>> 0 Reserved=0A= >>>>>> Reserved=0A= >>>>>=0A= >>>>> Yes, that was my confusion. You're reserving two values, not the=0A= >>>>> whole range.=0A= >>>>>=0A= >>>>>> The terms I used are also defined in rfc5226=0A= >>>>>=0A= >>>>> I plead guilty for not having read 5226, so the excerpts are helpful.= =0A= >>>>> Thanks. I guess we can do without the "no specification required, bu= t=0A= >>>>> still IANA-registered" option.=0A= >>>>>=0A= >>>>> David=0A= >>>>>=0A= >>>=0A= >>>=0A= >>> _____________________________________________________=0A= >>> This electronic message and any files transmitted with it contains=0A= >>> information from iDirect, which may be privileged, proprietary=0A= >>> and/or confidential. It is intended solely for the use of the individua= l=0A= >>> or entity to whom they are addressed. If you are not the original=0A= >>> recipient or the person responsible for delivering the email to the=0A= >>> intended recipient, be advised that you have received this email=0A= >>> in error, and that any use, dissemination, forwarding, printing, or=0A= >>> copying of this email is strictly prohibited. If you received this emai= l=0A= >>> in error, please delete it and immediately notify the sender.=0A= >>> _____________________________________________________=0A= >>>=0A= >>>=0A= >>=0A= =0A= From nobody Tue Jun 23 09:34:33 2015 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 858751A90BA for ; Tue, 23 Jun 2015 01:29:01 -0700 (PDT) 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 xmHaTmhvAUC8 for ; Tue, 23 Jun 2015 01:28:59 -0700 (PDT) Received: from ukmta4.baesystems.com (ukmta4.baesystems.com [20.133.40.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8AA1A90B2 for ; Tue, 23 Jun 2015 01:28:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,664,1427756400"; d="scan'208";a="241938" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta4.baesystems.com with ESMTP; 23 Jun 2015 09:28:57 +0100 X-IronPort-AV: E=Sophos;i="5.13,664,1427756400"; d="scan'208";a="106599318" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 23 Jun 2015 09:28:57 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.17]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0224.002; Tue, 23 Jun 2015 09:28:57 +0100 From: "Dearlove, Christopher (UK)" To: RFC Errata System , "ulrich@herberg.name" , "T.Clausen@computer.org" , "akatlas@gmail.com" , "db3546@att.com" , "aretana@cisco.com" , "sratliff@idirect.net" , "bebemaster@gmail.com" Thread-Topic: [Editorial Errata Reported] RFC7183 (4397) Thread-Index: AQHQrTFsa277/0tVG0GFb+Q2LeoTXZ25wrGg Date: Tue, 23 Jun 2015 08:28:56 +0000 Message-ID: References: <20150622211844.B63F6180452@rfc-editor.org> In-Reply-To: <20150622211844.B63F6180452@rfc-editor.org> 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: X-Mailman-Approved-At: Tue, 23 Jun 2015 09:34:32 -0700 Cc: "manet@ietf.org" Subject: Re: [manet] [Editorial Errata Reported] RFC7183 (4397) 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 Jun 2015 08:29:01 -0000 (Author commenting.) That's a clear cut and paste error we failed to spot. Should be accepted. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] = Sent: 22 June 2015 22:19 To: ulrich@herberg.name; Dearlove, Christopher (UK); T.Clausen@computer.org= ; akatlas@gmail.com; db3546@att.com; aretana@cisco.com; sratliff@idirect.ne= t; bebemaster@gmail.com Cc: ietf@jiaziyi.com; manet@ietf.org; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC7183 (4397) ----------------------! 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. -------------------------------------------------------- The following errata report has been submitted for RFC7183, "Integrity Prot= ection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link St= ate Routing Protocol Version 2 (OLSRv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D7183&eid=3D4397 -------------------------------------- Type: Editorial Reported by: Jiazi Section: 4 Original Text ------------- Generation of TIMESTAMP Message TLVs (as defined in [RFC7182]) for inclusion in an outgoing message. An implementation of [RFC6130] and [RFC7181] MAY use more than one ICV TLV in a message, but it MUST NOT use the same type extensio Corrected Text -------------- Generation of TIMESTAMP Message TLVs (as defined in [RFC7182]) for inclusion in an outgoing message. An implementation of [RFC6130] and [RFC7181] MAY use more than one TIMESTAMP TLV in a message , but it MUST NOT use the same type extensio Notes ----- We are only talking about TIMESTAMP TLV in this paragraph. = I think it's an error when copying the text from the previous paragraph. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "R= eply All" to discuss whether it should be verified or rejected. When a deci= sion is reached, the verifying party (IESG) can log in to change the status= and edit the report, if necessary. = -------------------------------------- RFC7183 (draft-ietf-manet-nhdp-olsrv2-sec-05) -------------------------------------- Title : Integrity Protection for the Neighborhood Discovery P= rotocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) Publication Date : April 2014 Author(s) : U. Herberg, C. Dearlove, T. Clausen Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG ******************************************************************** 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 Tue Jun 23 09:37:12 2015 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 ABF441ACED7 for ; Tue, 23 Jun 2015 09:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q_m_P9371SBA for ; Tue, 23 Jun 2015 09:37:10 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 004D31ACED1 for ; Tue, 23 Jun 2015 09:37:09 -0700 (PDT) Received: (qmail 23443 invoked by uid 0); 23 Jun 2015 16:37:07 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy2.mail.unifiedlayer.com with SMTP; 23 Jun 2015 16:37:07 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id jyW91q0242SSUrH01yWCnh; Tue, 23 Jun 2015 16:30:14 -0600 X-Authority-Analysis: v=2.1 cv=VdVkYjZ9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=5vjwwrbCAAAA:8 a=Vz0JMtYISUq2X7sbimIA:9 a=-XJrPJxQrsJywPf_:21 a=JmuzbB-_ubWqJXPG:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=2/Vnv6jqTwl3V94nRTnKEu+JDifSGe4yuI/2fMZP69U=; b=ZGGtxKv7pnfSOh6n/VM7t+8e0gko8jKvdI71/ujfsZccofm62MVM+AokPAV61AG8MXk0BjH3goAj/3Ef6b/FdTHRrd7W0GKK5QDN9Jbf7rHEcf0eJBE/kIoOytIJeLTC; Received: from box313.bluehost.com ([69.89.31.113]:55289 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z7RC2-0004vP-6d; Tue, 23 Jun 2015 10:37:02 -0600 Message-ID: <55898B29.2090007@labn.net> Date: Tue, 23 Jun 2015 12:36:57 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rick Taylor , "Wiggins, David - 0665 - MITLL" , "Ratliff, Stanley" , RJ Atkinson , "manet@ietf.org" References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5D61@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2B5F16@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B5F16@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 16:37:11 -0000 Rick, On 6/23/2015 12:25 PM, Rick Taylor wrote: > The original reasons for having a very small Private Use space were: > > 1) We only had 256 ids. > > 2) We didn't want experiments to become de-facto Extensions. > > 3) We were worried that a more generous Private Use space would set of > alarm bells at the draft passed through the various review stages. > > Now with the wider id field, 1) is now irrelevant, but we need guidance > on 3), and 2) might be impossible to solve. > > Lou, do you have a comment? I suspect that some relatively small number, say in the small 100s, of private use values is unlikely to cause too many question. Keep in mind that private use is not the same as experimental use from the IANA/process perspective: Private Use - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments (since IANA does not record them) and assignments are not generally useful for broad interoperability. It is the responsibility of the sites making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). Examples: Site-specific options in DHCP [DHCP-IANA ], Fibre Channel Port Type Registry [RFC4044 ], Exchange Types in the IKEv2 header [RFC4306 ]. I don't think a specific experimental use range/policy serves much value as it complicates transition from experiment to standard - and the specification required policy can support experimental non-private usage. Lou > Rick > > > On 23/06/15 16:57, Wiggins, David - 0665 - MITLL wrote: >> I also think the private space is too small. The effect could be to force >> people to encroach on the Specification Required space to get more >> Privates, making the division meaningless. 254 would probably be enough, >> though I'm not really seeing the harm in making it even larger. >> >> David >> >> On 6/23/15, 11:50 AM, "Rick Taylor" wrote: >> >>> Stan, >>> >>> I'm not convinced. If we put in the effort to allow (possibly multiple) >>> experiments, we may as well give them enough room to run them. >>> >>> I would personally like to give them more than 14 ids. 254 seems more >>> generous, but I know you are worried about being too 'loose'. >>> >>> Rick >>> >>> >>> >>> On 23/06/15 16:43, Ratliff, Stanley wrote: >>>> Rick, >>>> >>>> I'm still of the opinion that the private-use space is too large. >>>> >>>> Regards, >>>> Stan >>>> >>>> >>>>> -----Original Message----- >>>>> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] >>>>> Sent: Tuesday, June 23, 2015 11:41 AM >>>>> To: Wiggins, David - 0665 - MITLL; Lou Berger; Ratliff, Stanley; RJ >>>>> Atkinson; >>>>> manet@ietf.org >>>>> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 >>>>> >>>>> First, apologies for mixing hex and decimal. >>>>> >>>>> Following from Lou's RFC5226 guidance: >>>>> >>>>> For data item ids: >>>>> >>>>> 0 - Reserved >>>>> 1-20 - Standards Action - DLEP core >>>>> 21-23 - Standards Action - Credit windowing >>>>> 24-65519 - Specification Required - space for future Extensions >>>>> 65520-65534 - Private Use - space for Experiments >>>>> 65535 - Reserved >>>>> >>>>> For signal ids: >>>>> >>>>> 0 - Reserved >>>>> 1-16 - Standards Action - DLEP core >>>>> 17-65519 - Specification Required - space for future Extensions >>>>> 65520-65534 - Private Use - space for Experiments >>>>> 65535 - Reserved >>>>> >>>>> For Extension ids: >>>>> >>>>> 0 - Reserved >>>>> 1 - Standards Action - DLEP Credit Windowing >>>>> 17-65534 - Specification Required - future Extension ids >>>>> 65535 - Reserved >>>>> >>>>> Experiments MUST use the Private Use area. Extensions MUST use the >>>>> Specification Required area. >>>>> >>>>> Hope that's clearer? >>>>> >>>>> Rick >>>>> >>>>> On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote: >>>>>> On 6/23/15, 10:07 AM, "Lou Berger" wrote: >>>>>>> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote: >>>>>>>> The Reserved range above encompasses the entire range (I'm assuming >>>>>>>> >>>>>>> value> refers to the same value in the 1st and 3rd case). >>>>>>> There was comma there. Let me try this: >>>>>>> 0 Reserved >>>>>>> Reserved >>>>>> Yes, that was my confusion. You're reserving two values, not the >>>>>> whole range. >>>>>> >>>>>>> The terms I used are also defined in rfc5226 >>>>>> I plead guilty for not having read 5226, so the excerpts are helpful. >>>>>> Thanks. I guess we can do without the "no specification required, but >>>>>> still IANA-registered" option. >>>>>> >>>>>> David >>>>>> >>>> >>>> _____________________________________________________ >>>> This electronic message and any files transmitted with it contains >>>> information from iDirect, which may be privileged, proprietary >>>> and/or confidential. It is intended solely for the use of the individual >>>> or entity to whom they are addressed. If you are not the original >>>> recipient or the person responsible for delivering the email to the >>>> intended recipient, be advised that you have received this email >>>> in error, and that any use, dissemination, forwarding, printing, or >>>> copying of this email is strictly prohibited. If you received this email >>>> in error, please delete it and immediately notify the sender. >>>> _____________________________________________________ >>>> >>>> > From nobody Tue Jun 23 10:14:56 2015 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 4255B1B2E5A for ; Tue, 23 Jun 2015 10:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 k9fgjdqmkipc for ; Tue, 23 Jun 2015 10:14:51 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id D5EAE1B2E58 for ; Tue, 23 Jun 2015 10:14:51 -0700 (PDT) Received: (qmail 17023 invoked by uid 0); 23 Jun 2015 17:14:48 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 23 Jun 2015 17:14:48 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id jz7Q1q00p2SSUrH01z7Tzd; Tue, 23 Jun 2015 17:07:36 -0600 X-Authority-Analysis: v=2.1 cv=auUhV0pV c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=fz3OxHwexY2Q6Zj1L6gA:9 a=9KKQAmd8cJ-Cj-5l:21 a=IiZslR7b5ZwhbRV5:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=2+/WWQ35AHJEpQ+wKnDRx1uZTIwK/vPTsvJgvbTcv0w=; b=m7pvaK4ezf/ngU70pt5n2H2NPxEZX0hCatHVoC7tgMbKlZDxthhzVUiUQKBEZ+ssBKs7zOheNSZ3hgt0e0Kjffmb6gOyy7Mk2QPnx21tbNUZOkUq1JnrzUVc7poO/Usc; Received: from box313.bluehost.com ([69.89.31.113]:57400 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z7RmN-0003DW-Vn; Tue, 23 Jun 2015 11:14:36 -0600 Message-ID: <558993F7.1090001@labn.net> Date: Tue, 23 Jun 2015 13:14:31 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rick Taylor , "Wiggins, David - 0665 - MITLL" , "Ratliff, Stanley" , RJ Atkinson , "manet@ietf.org" References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2B5D45@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B5D45@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 17:14:53 -0000 Rick, Specific values need to be provided for delp defined registries. I think you have : Registry: DLEP Signal Type Range Registration Procedures --------- -------------------------------- 0-N, M Standards Action or Specification Required N-(M-1) Private Use Value Use ------- ------------------------------- 0 Reserved 1 Peer Discovery 2 Peer Offer 3 Peer Initialization 4 Peer Initialization ACK 5 Peer Update 6 Peer Update ACK 7 Peer Termination 8 Peer Termination ACK 9 Destination Up 10 Destination Up ACK 11 Destination Down 12 Destination Down ACK 13 Destination Update 14 Heartbeat 15 Link Characteristics Request 16 Link Characteristics ACK 17-N Unassigned N-(M-1) Private Use M Reserved Registry: DLEP Data Item Type Range Registration Procedures --------- -------------------------------- 0-N, 65535 Standards Action or Specification Required N-65534 Private Use Value Use ------- ------------------------------- 0 Reserved 1 Status 2 IPv4 Connection Point 3 IPv6 Connection Point 4 Peer Type 5 Heartbeat Interval 6 Extensions Supported 7 Experimental Definition 8 MAC Address 9 IPv4 Address 10 IPv6 Address 11 IPv4 Attached Subnet 12 IPv6 Attached Subnet 13 Maximum Data Rate (Receive) MDRR) 14 Maximum Data Rate (Transmit) (MDRT) 15 Current Data Rate (Receive) (CDRR) 16 Current Data Rate (Transmit) (CDRT) 17 Latency 18 Resources (Receive) (RESR) 19 Resources (Transmit) (REST) 20 Relative Link Quality (Receive) (RLQR) 21 Relative Link Quality (Transmit)(RLQT) 22 Link Characteristics ACK Timer 23 Credit Grant 24 Credit Window Status 25 Credit Request 26-N Unassigned N-65534 Private Use 65535 Reserved Registry: DLEP Extension Type Range Registration Procedures --------- -------------------------------- 0-N, 65535 Standards Action or Specification Required N-65534 Private Use Value Use ------- ------------------------------- 0 Reserved 1 Credit-Windowing 2-N Unassigned N-65534 Private Use 65535 Reserved Lou On 6/23/2015 11:47 AM, Rick Taylor wrote: > Oops, cut'n'paste problem! > > Should be: > > For Extension ids: > > 0 - Reserved > 1 - Standards Action - DLEP Credit Windowing > 2-65534 - Specification Required - future Extension ids > 65535 - Reserved > > Sorry > > Rick > > On 23/06/15 16:41, Rick Taylor wrote: >> First, apologies for mixing hex and decimal. >> >> Following from Lou's RFC5226 guidance: >> >> For data item ids: >> >> 0 - Reserved >> 1-20 - Standards Action - DLEP core >> 21-23 - Standards Action - Credit windowing >> 24-65519 - Specification Required - space for future Extensions >> 65520-65534 - Private Use - space for Experiments >> 65535 - Reserved >> >> For signal ids: >> >> 0 - Reserved >> 1-16 - Standards Action - DLEP core >> 17-65519 - Specification Required - space for future Extensions >> 65520-65534 - Private Use - space for Experiments >> 65535 - Reserved >> >> For Extension ids: >> >> 0 - Reserved >> 1 - Standards Action - DLEP Credit Windowing >> 17-65534 - Specification Required - future Extension ids >> 65535 - Reserved >> >> Experiments MUST use the Private Use area. Extensions MUST use the >> Specification Required area. >> >> Hope that's clearer? >> >> Rick >> >> On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote: >>> On 6/23/15, 10:07 AM, "Lou Berger" wrote: >>>> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote: >>>>> The Reserved range above encompasses the entire range (I'm assuming >>>> value> refers to the same value in the 1st and 3rd case). >>>> There was comma there. Let me try this: >>>> 0 Reserved >>>> Reserved >>> Yes, that was my confusion. You're reserving two values, not the whole >>> range. >>> >>>> The terms I used are also defined in rfc5226 >>> I plead guilty for not having read 5226, so the excerpts are helpful. >>> Thanks. I guess we can do without the "no specification required, but >>> still IANA-registered" option. >>> >>> David >>> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > From nobody Tue Jun 23 10:17:37 2015 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 1B5891B2E64 for ; Tue, 23 Jun 2015 10:17:36 -0700 (PDT) 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 n-jdkP_GQgv3 for ; Tue, 23 Jun 2015 10:17:33 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 535FF1B2E66 for ; Tue, 23 Jun 2015 10:17:31 -0700 (PDT) Received: by oigb199 with SMTP id b199so11918273oig.3 for ; Tue, 23 Jun 2015 10:17:30 -0700 (PDT) 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=+GsH86JwFo+skiguLR/MMah43VDkWVljinlry2IWEJU=; b=dsNMWo/uwsKXcCalfVsMfG7hsiswfQfAAXQ3BT8xzYXAVk3A5kK/71UNBaFq8VyXZ3 ZgZlpncKOJD/PeCeek4Y6mZBYCl5FDQks84bMT4vWwtaPkx+twju0fPbMnBP4GWVuDcn nlHBE7GCiAk7gCwJmoycWl8oO5goSPWXQCiHo2wIlPDzcOjOA5Kja4YKafLbm6B4oEHh pgxavDGz+Epwh3pYJhTnWsKOS6zTEbKSsNW7z4Bnlox8ZuaF3R+MnoVhh/iJeDBgR7yd 1yk48bfY+FA9TmcSk0HmGp+aDXYKhTC0pGNcawKD9386qQtvds8VZUW77dPnClCzzDeC +gPg== MIME-Version: 1.0 X-Received: by 10.182.112.138 with SMTP id iq10mr21132426obb.38.1435079850718; Tue, 23 Jun 2015 10:17:30 -0700 (PDT) Received: by 10.202.195.134 with HTTP; Tue, 23 Jun 2015 10:17:30 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B5F16@tss-server1.home.tropicalstormsoftware.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5D61@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2B5F16@tss-server1.home.tropicalstormsoftware.com> Date: Tue, 23 Jun 2015 13:17:30 -0400 Message-ID: From: Justin Dean To: Rick Taylor Content-Type: multipart/alternative; boundary=089e0149cd4eb9fba505193290d5 Archived-At: Cc: RJ Atkinson , "manet@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 17:17:36 -0000 --089e0149cd4eb9fba505193290d5 Content-Type: text/plain; charset=UTF-8 Private use in the 100-200 range seems appropriate to me. It should be large enough to provide space for multiple experiments to be run at the same time but not so large that number collisions wouldn't be a worry. Pushing people who use/create these extensions to document/specify and grab an official code point. On Tue, Jun 23, 2015 at 12:25 PM, Rick Taylor < rick@tropicalstormsoftware.com> wrote: > The original reasons for having a very small Private Use space were: > > 1) We only had 256 ids. > > 2) We didn't want experiments to become de-facto Extensions. > > 3) We were worried that a more generous Private Use space would set of > alarm bells at the draft passed through the various review stages. > > Now with the wider id field, 1) is now irrelevant, but we need guidance > on 3), and 2) might be impossible to solve. > > Lou, do you have a comment? > > Rick > > > On 23/06/15 16:57, Wiggins, David - 0665 - MITLL wrote: > > I also think the private space is too small. The effect could be to > force > > people to encroach on the Specification Required space to get more > > Privates, making the division meaningless. 254 would probably be enough, > > though I'm not really seeing the harm in making it even larger. > > > > David > > > > On 6/23/15, 11:50 AM, "Rick Taylor" > wrote: > > > >> Stan, > >> > >> I'm not convinced. If we put in the effort to allow (possibly multiple) > >> experiments, we may as well give them enough room to run them. > >> > >> I would personally like to give them more than 14 ids. 254 seems more > >> generous, but I know you are worried about being too 'loose'. > >> > >> Rick > >> > >> > >> > >> On 23/06/15 16:43, Ratliff, Stanley wrote: > >>> Rick, > >>> > >>> I'm still of the opinion that the private-use space is too large. > >>> > >>> Regards, > >>> Stan > >>> > >>> > >>>> -----Original Message----- > >>>> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] > >>>> Sent: Tuesday, June 23, 2015 11:41 AM > >>>> To: Wiggins, David - 0665 - MITLL; Lou Berger; Ratliff, Stanley; RJ > >>>> Atkinson; > >>>> manet@ietf.org > >>>> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 > >>>> > >>>> First, apologies for mixing hex and decimal. > >>>> > >>>> Following from Lou's RFC5226 guidance: > >>>> > >>>> For data item ids: > >>>> > >>>> 0 - Reserved > >>>> 1-20 - Standards Action - DLEP core > >>>> 21-23 - Standards Action - Credit windowing > >>>> 24-65519 - Specification Required - space for future Extensions > >>>> 65520-65534 - Private Use - space for Experiments > >>>> 65535 - Reserved > >>>> > >>>> For signal ids: > >>>> > >>>> 0 - Reserved > >>>> 1-16 - Standards Action - DLEP core > >>>> 17-65519 - Specification Required - space for future Extensions > >>>> 65520-65534 - Private Use - space for Experiments > >>>> 65535 - Reserved > >>>> > >>>> For Extension ids: > >>>> > >>>> 0 - Reserved > >>>> 1 - Standards Action - DLEP Credit Windowing > >>>> 17-65534 - Specification Required - future Extension ids > >>>> 65535 - Reserved > >>>> > >>>> Experiments MUST use the Private Use area. Extensions MUST use the > >>>> Specification Required area. > >>>> > >>>> Hope that's clearer? > >>>> > >>>> Rick > >>>> > >>>> On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote: > >>>>> On 6/23/15, 10:07 AM, "Lou Berger" wrote: > >>>>>> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITLL wrote: > >>>>>>> The Reserved range above encompasses the entire range (I'm assuming > >>>>>>> >>>>>>> value> refers to the same value in the 1st and 3rd case). > >>>>>> There was comma there. Let me try this: > >>>>>> 0 Reserved > >>>>>> Reserved > >>>>> > >>>>> Yes, that was my confusion. You're reserving two values, not the > >>>>> whole range. > >>>>> > >>>>>> The terms I used are also defined in rfc5226 > >>>>> > >>>>> I plead guilty for not having read 5226, so the excerpts are helpful. > >>>>> Thanks. I guess we can do without the "no specification required, > but > >>>>> still IANA-registered" option. > >>>>> > >>>>> David > >>>>> > >>> > >>> > >>> _____________________________________________________ > >>> This electronic message and any files transmitted with it contains > >>> information from iDirect, which may be privileged, proprietary > >>> and/or confidential. It is intended solely for the use of the > individual > >>> or entity to whom they are addressed. If you are not the original > >>> recipient or the person responsible for delivering the email to the > >>> intended recipient, be advised that you have received this email > >>> in error, and that any use, dissemination, forwarding, printing, or > >>> copying of this email is strictly prohibited. If you received this > email > >>> in error, please delete it and immediately notify the sender. > >>> _____________________________________________________ > >>> > >>> > >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e0149cd4eb9fba505193290d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Private use in the 100-200 range seems appropriate to me.= =C2=A0 It should be large enough to provide space for multiple experiments = to be run at the same time but not so large that number collisions wouldn&#= 39;t be a worry.=C2=A0 Pushing people who use/create these extensions to do= cument/specify and grab an official code point.

On Tue, Jun 23, 2015 at 12:25 PM, R= ick Taylor <rick@tropicalstormsoftware.com> wro= te:
The original reasons for having a ver= y small Private Use space were:

1) We only had 256 ids.

2) We didn't want experiments to become de-facto Extensions.

3) We were worried that a more generous Private Use space would set of
alarm bells at the draft passed through the various review stages.

Now with the wider id field, 1) is now irrelevant, but we need guidance
on 3), and 2) might be impossible to solve.

Lou, do you have a comment?

Rick


On 23/06/15 16:57, Wiggins, David - 0665 - MITLL wrote:
> I also think the private space is too small.=C2=A0 The effect could be= to force
> people to encroach on the Specification Required space to get more
> Privates, making the division meaningless.=C2=A0 254 would probably be= enough,
> though I'm not really seeing the harm in making it even larger. >
> David
>
> On 6/23/15, 11:50 AM, "Rick Taylor" <rick@tropicalstormsoftware.com> wrote:=
>
>> Stan,
>>
>> I'm not convinced.=C2=A0 If we put in the effort to allow (pos= sibly multiple)
>> experiments, we may as well give them enough room to run them.
>>
>> I would personally like to give them more than 14 ids. 254 seems m= ore
>> generous, but I know you are worried about being too 'loose= 9;.
>>
>> Rick
>>
>>
>>
>> On 23/06/15 16:43, Ratliff, Stanley wrote:
>>> Rick,
>>>
>>> I'm still of the opinion that the private-use space is too= large.
>>>
>>> Regards,
>>> Stan
>>>
>>>
>>>> -----Original Message-----
>>>> From: Rick Taylor [mailto:rick@tropicalstormsoftware.com]
>>>> Sent: Tuesday, June 23, 2015 11:41 AM
>>>> To: Wiggins, David - 0665 - MITLL; Lou Berger; Ratliff, St= anley; RJ
>>>> Atkinson;
>>>> manet@ietf.org
>>>> Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-= 14
>>>>
>>>> First, apologies for mixing hex and decimal.
>>>>
>>>> Following from Lou's RFC5226 guidance:
>>>>
>>>> For data item ids:
>>>>
>>>> 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Reserved=
>>>> 1-20=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 Standards Action -= DLEP core
>>>> 21-23=C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Standards Action -= Credit windowing
>>>> 24-65519=C2=A0 =C2=A0 -=C2=A0 Specification Required - spa= ce for future Extensions
>>>> 65520-65534 -=C2=A0 Private Use - space for Experiments >>>> 65535=C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Reserved
>>>>
>>>> For signal ids:
>>>>
>>>> 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Reserved=
>>>> 1-16=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 Standards Action -= DLEP core
>>>> 17-65519=C2=A0 =C2=A0 -=C2=A0 Specification Required - spa= ce for future Extensions
>>>> 65520-65534 -=C2=A0 Private Use - space for Experiments >>>> 65535=C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Reserved
>>>>
>>>> For Extension ids:
>>>>
>>>> 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Reserved=
>>>> 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Standard= s Action - DLEP Credit Windowing
>>>> 17-65534=C2=A0 =C2=A0 -=C2=A0 Specification Required - fut= ure Extension ids
>>>> 65535=C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Reserved
>>>>
>>>> Experiments MUST use the Private Use area.=C2=A0 Extension= s MUST use the
>>>> Specification Required area.
>>>>
>>>> Hope that's clearer?
>>>>
>>>> Rick
>>>>
>>>> On 23/06/15 16:00, Wiggins, David - 0665 - MITLL wrote: >>>>> On 6/23/15, 10:07 AM, "Lou Berger" <lberger@labn.net> wrote:
>>>>>> On 6/23/2015 9:34 AM, Wiggins, David - 0665 - MITL= L wrote:
>>>>>>> The Reserved range above encompasses the entir= e range (I'm assuming
>>>>>>> <max
>>>>>>> value> refers to the same value in the 1st = and 3rd case).
>>>>>> There was comma there.=C2=A0 Let me try this:
>>>>>> 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reserved
>>>>>> <max value>=C2=A0 =C2=A0 Reserved
>>>>>
>>>>> Yes, that was my confusion.=C2=A0 You're reserving= two values, not the
>>>>> whole range.
>>>>>
>>>>>> The terms I used are also defined in rfc5226
>>>>>
>>>>> I plead guilty for not having read 5226, so the excerp= ts are helpful.
>>>>> Thanks.=C2=A0 I guess we can do without the "no s= pecification required, but
>>>>> still IANA-registered" option.
>>>>>
>>>>> David
>>>>>
>>>
>>>
>>> _____________________________________________________
>>> This electronic message and any files transmitted with it cont= ains
>>> information from iDirect, which may be privileged, proprietary=
>>> and/or confidential. It is intended solely for the use of the = individual
>>> or entity to whom they are addressed. If you are not the origi= nal
>>> recipient or the person responsible for delivering the email t= o the
>>> intended recipient, be advised that you have received this ema= il
>>> in error, and that any use, dissemination, forwarding, printin= g, or
>>> copying of this email is strictly prohibited. If you received = this email
>>> in error, please delete it and immediately notify the sender.<= br> >>> _____________________________________________________
>>>
>>>
>>


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

--089e0149cd4eb9fba505193290d5-- From nobody Tue Jun 23 10:39:29 2015 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 E880A1B2EBD for ; Tue, 23 Jun 2015 10:39:26 -0700 (PDT) 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 dnp6hGbmgi_c for ; Tue, 23 Jun 2015 10:39:25 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (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 9EDAD1B2EAC for ; Tue, 23 Jun 2015 10:39:25 -0700 (PDT) Received: by yhnv31 with SMTP id v31so6751467yhn.1 for ; Tue, 23 Jun 2015 10:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=yHudiubQqVJt4cBq5DO1DrPArGvqjkvFpohx4f9DZe8=; b=ooU8TSflfeddhLn5vbgFTFSC5B/WcQV8GB0JJb7eUNycyZU59bwGGocQ0yhdSoj89Q J0DqnA6XWfwQr8LRRyGLU4FKLTv0oCDZrMRhvplp5PXipwset5zilG/zuxul/Nvp+3jv OAFzqaMEtD+tiXDwYE9s/n4SJRRMrlk3hsi4GlrplVu63E4WaPk2/XQSjG/7YhTmJpI+ rAwYiSZYsoD1LFgebZxARqD2Duleb5pkgc7yypG5SUO06touFq4tozz+VFiifRq3VF7J PbfdO7v6KsZY0FVGY5ThmHx30ZPrbyXnzcezvLPeD0XAOGK1Z8jH5JKnRfJpC/hlOYbI jPTQ== X-Received: by 10.13.229.198 with SMTP id o189mr44027470ywe.108.1435081165020; Tue, 23 Jun 2015 10:39:25 -0700 (PDT) Received: from [10.30.20.16] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id 194sm4469259ywe.43.2015.06.23.10.39.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jun 2015 10:39:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: RJ Atkinson In-Reply-To: <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> Date: Tue, 23 Jun 2015 13:39:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> To: manet@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 17:39:27 -0000 > On 23 Jun 2015, at 11:43 , Ratliff, Stanley = wrote: >=20 > Rick,=20 >=20 > I'm still of the opinion that the private-use space is too large.=20 Stan, I think it is far far too small. There needs to be a reasonably large private use space, particularly since a single type value now is used for a single datum, whereas with the former Experimental value a single type could be used for many data items. If someone is experimenting, for example with a prototype radio, one might concurrently want to experiment with (for example) more precise metrics, alternative queueing/precedence strategies, and wave-form-specific data items concurrently to see how the combination(s) work together. With PPPoE, there are a LOT of code points available for experimentation at present. If DLEP has prohibitively private use spaces, then there is a strong incentive to use PPPoE instead of DLEP. =20 How is that a good outcome for the IETF or for this WG ? I=E2=80=99d suggest about 200 Private Use values for Data Items. Yours, Ran From nobody Tue Jun 23 10:43:21 2015 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 02CE01B2EFA for ; Tue, 23 Jun 2015 10:43:19 -0700 (PDT) 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 N1yn7xMdBZbs for ; Tue, 23 Jun 2015 10:43:17 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (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 992D71B2EF5 for ; Tue, 23 Jun 2015 10:43:17 -0700 (PDT) Received: by yhak3 with SMTP id k3so6754941yha.2 for ; Tue, 23 Jun 2015 10:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xfvFNWnaqa/tsNAOzxA3F9FWDP4AiPbBnco4dQh18qc=; b=lcbVx9uVWLv+bcpqKklFL5xkCEbIhZw10CxWtw7XoRx1ITdqAdo8K/FqZkMxMrsF7M bYoTV+tyIOW0SCPVwkYvQlfzKaCrTeveWAzzg7Pay7IclpEE8As0n76yqqZrzNTowm5I zcNVZVFaKG4PRfOKTznplMZVN2fHmPINBPrRYlTCsjTw+KecqZRtN/U21SiVaRgybRzX fa2Bi49AfqZQAaNjq3cH9OHbsqGk08ltELWPgRjdmfna7fPLwPR5kyohPQUJX4/Kpy7M yQidc2s7dm/V0thQ4t6IkPubiGB5MMBo6sBwsewJzUE1XxUsWh1hjdsu+MZg2iXzwW7f iipQ== X-Received: by 10.13.192.3 with SMTP id b3mr44899993ywd.76.1435081397001; Tue, 23 Jun 2015 10:43:17 -0700 (PDT) Received: from [10.30.20.16] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id w189sm18888386ywc.23.2015.06.23.10.43.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jun 2015 10:43:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: RJ Atkinson In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B5DAD@tss-server1.home.tropicalstormsoftware.com> Date: Tue, 23 Jun 2015 13:43:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2B5D45@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2B5DAD@tss-server1.home.tropicalstormsoftware.com> To: Rick Taylor X-Mailer: Apple Mail (2.2098) Archived-At: Cc: manet@ietf.org Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 17:43:19 -0000 > On 23 Jun 2015, at 11:56 , Rick Taylor = wrote: >=20 > On 23/06/15 16:51, Wiggins, David - 0665 - MITLL wrote: >> I think we need some Private Use extension ids too. >=20 > No, Extensions are Specification Required by design. Experiments are=20= > provided for Private Use id use. Rick, Your answer appears to refer to draft-14, rather than Lou Berger=E2=80=99s proposal. However, I suspect David is talking about the Lou Berger proposal, and I think that he means that the DLEP spec needs a reasonably=20 large =E2=80=9CPrivate Use=E2=80=9D space that can be used for = Experiments (again,=20 in the context of Lou=E2=80=99s proposal). Please also see Henning = Rogge=E2=80=99s note=20 from today at 11:48 US EDT. If your quoted text above meant something other than those 2 = candidates, I was not able to puzzle your meaning out. Please rephrase. Thanks, Ran From nobody Tue Jun 23 11:06:00 2015 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 DF6971A005B for ; Tue, 23 Jun 2015 11:05:59 -0700 (PDT) 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 FD-p1TvrJ-87 for ; Tue, 23 Jun 2015 11:05:58 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3022D1A0058 for ; Tue, 23 Jun 2015 11:05:58 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.201 as permitted sender) identity=mailfrom; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,666,1427774400"; d="scan'208";a="8191457" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.201]) by ironport2.idirect.net with ESMTP; 23 Jun 2015 14:05:57 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM1.idirect.net (10.250.250.201) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 23 Jun 2015 14:05:57 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Tue, 23 Jun 2015 14:05:57 -0400 From: "Ratliff, Stanley" To: RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6Mo+Tw3COyECGObxkTDTDb526QqGQgABjmID//8G9QA== Date: Tue, 23 Jun 2015 18:05:56 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 18:06:00 -0000 UmFuLA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbWFuZXQgW21h aWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUkogQXRraW5zb24NCj4g U2VudDogVHVlc2RheSwgSnVuZSAyMywgMjAxNSAxOjM5IFBNDQo+IFRvOiBtYW5ldEBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW21hbmV0XSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLW1hbmV0 LWRsZXAtMTQNCj4gDQo+IA0KPiA+IE9uIDIzICBKdW4gMjAxNSwgYXQgMTE6NDMgLCBSYXRsaWZm LCBTdGFubGV5IDxzcmF0bGlmZkBpZGlyZWN0Lm5ldD4gd3JvdGU6DQo+ID4NCj4gPiBSaWNrLA0K PiA+DQo+ID4gSSdtIHN0aWxsIG9mIHRoZSBvcGluaW9uIHRoYXQgdGhlIHByaXZhdGUtdXNlIHNw YWNlIGlzIHRvbyBsYXJnZS4NCj4gDQo+IFN0YW4sDQo+IA0KPiBJIHRoaW5rIGl0IGlzIGZhciBm YXIgdG9vIHNtYWxsLiAgVGhlcmUgbmVlZHMgdG8gYmUgYSByZWFzb25hYmx5IGxhcmdlIHByaXZh dGUgdXNlDQo+IHNwYWNlLCBwYXJ0aWN1bGFybHkgc2luY2UgYSBzaW5nbGUgdHlwZSB2YWx1ZSBu b3cgaXMgdXNlZCBmb3IgYSBzaW5nbGUgZGF0dW0sDQo+IHdoZXJlYXMgd2l0aCB0aGUgZm9ybWVy IEV4cGVyaW1lbnRhbCB2YWx1ZSBhIHNpbmdsZSB0eXBlIGNvdWxkIGJlIHVzZWQgZm9yDQo+IG1h bnkgZGF0YSBpdGVtcy4NCj4gDQoNCkkgYmVsaWV2ZSB0aGUgZGlzY3Vzc2lvbiBpcyBub3cgY2Vu dGVyaW5nIGFyb3VuZCAzIGRpZmZlcmVudCBuYW1lL251bWJlciBzcGFjZXM6ICAoMSkgRGF0YSBJ dGVtcywgKDIpIFNpZ25hbHMsIGFuZCAoMykgRXh0ZW5zaW9ucy4gSSBjYW4gc2VlIGEgbmVlZCBm b3IgYSBsYXJnZXIgcHJpdmF0ZSB1c2Ugc3BhY2UgaW4gdGhlIGRhdGEgaXRlbXMgcmVnaXN0cnkg dGhhbiBmb3IgdGhlIHNpZ25hbHMgcmVnaXN0cnksIGZvciBleGFtcGxlLiBTbyBJIGJlbGlldmUg d2UnbGwgd2luZCB1cCB3aXRoIGRpZmZlcmVudCBhbGxvY2F0aW9ucywgZm9yIHRoZSAzIGRpZmZl cmVudCByZWdpc3RyaWVzLiBGcm9tIHdoYXQgSSBnYXRoZXIgaW4geW91ciBub3RlLCBpdCBzZWVt cyB0aGF0IHlvdSBhcmUgbW9yZSBpbnRlcmVzdGVkIGluIHRoZSBzaXplIG9mIHRoZSBwcml2YXRl IHVzZSBkYXRhIGl0ZW0gc3BhY2UuIERpZCBJIGdldCB0aGF0IGNvcnJlY3Q/IElmIG5vdCwgcGxl YXNlIGFkdmlzZS4NCg0KSW4gYW55IGV2ZW50LCBJIGJlbGlldmUgdGhhdCBhIGRyaXZpbmcgcHJp bmNpcGxlIGZvciB0aGUgYWxsb2NhdGlvbnMgaXMgd2hhdCBKdXN0aW4gRGVhbiBzdGF0ZWQ6ICIu Li4gUHVzaGluZyBwZW9wbGUgd2hvIHVzZS9jcmVhdGUgdGhlc2UgZXh0ZW5zaW9ucyB0byBkb2N1 bWVudC9zcGVjaWZ5IGFuZCBncmFiIGFuIG9mZmljaWFsIGNvZGUgcG9pbnQuIiBIZW5jZSwgbXkg ZGVzaXJlIHRvIHJlc3RyaWN0IHRoZSBzaXplIG9mIHByaXZhdGUgdXNlIGFsbG9jYXRpb25zIHRv IHRoZSBiYXJlIG1pbmltdW0uDQoNCj4gSWYgc29tZW9uZSBpcyBleHBlcmltZW50aW5nLCBmb3Ig ZXhhbXBsZSB3aXRoIGEgcHJvdG90eXBlIHJhZGlvLCBvbmUgbWlnaHQNCj4gY29uY3VycmVudGx5 IHdhbnQgdG8gZXhwZXJpbWVudCB3aXRoIChmb3IgZXhhbXBsZSkgbW9yZSBwcmVjaXNlIG1ldHJp Y3MsDQo+IGFsdGVybmF0aXZlIHF1ZXVlaW5nL3ByZWNlZGVuY2Ugc3RyYXRlZ2llcywgYW5kIHdh dmUtZm9ybS1zcGVjaWZpYyBkYXRhDQo+IGl0ZW1zIGNvbmN1cnJlbnRseSB0byBzZWUgaG93IHRo ZQ0KPiBjb21iaW5hdGlvbihzKSB3b3JrIHRvZ2V0aGVyLg0KPiANCj4gV2l0aCBQUFBvRSwgdGhl cmUgYXJlIGEgTE9UIG9mIGNvZGUgcG9pbnRzIGF2YWlsYWJsZSBmb3IgZXhwZXJpbWVudGF0aW9u IGF0DQo+IHByZXNlbnQuICBJZiBETEVQIGhhcyBwcm9oaWJpdGl2ZWx5IHByaXZhdGUgdXNlIHNw YWNlcywgdGhlbiB0aGVyZSBpcyBhIHN0cm9uZw0KPiBpbmNlbnRpdmUgdG8gdXNlIFBQUG9FIGlu c3RlYWQgb2YgRExFUC4NCj4gSG93IGlzIHRoYXQgYSBnb29kIG91dGNvbWUgZm9yIHRoZSBJRVRG IG9yIGZvciB0aGlzIFdHID8NCj4gDQoNCkZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHNvbWVvbmUg d2hvIGlzIGEgY28tYXV0aG9yIG9mIFJGQyA1NTc4IChQUFBvRSBFeHRlbnNpb25zIGZvciByYWRp by1iYXNlZCB0cmFmZmljKSwgSSBjYW4gdGVsbCB5b3UgdGhhdCB0aGVyZSBhcmUgKmEgbG90KiBv ZiBvdGhlciByZWFzb25zIHRvIGF2b2lkIFBQUG9FIGxpa2UgdGhlIHBsYWd1ZS4uLiA7LSkNCg0K UmVnYXJkcywNClN0YW4NCg0KDQo+IEnigJlkIHN1Z2dlc3QgYWJvdXQgMjAwIFByaXZhdGUgVXNl IHZhbHVlcyBmb3IgRGF0YSBJdGVtcy4NCj4gDQo+IFlvdXJzLA0KPiANCj4gUmFuDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtYW5ldCBt YWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tYW5ldA0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGFuZCBhbnkgZmlsZXMg dHJhbnNtaXR0ZWQgd2l0aCBpdCBjb250YWlucwppbmZvcm1hdGlvbiBmcm9tIGlEaXJlY3QsIHdo aWNoIG1heSBiZSBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeQphbmQvb3IgY29uZmlkZW50aWFsLiBJ dCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwKb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgb3JpZ2lu YWwKcmVjaXBpZW50IG9yIHRoZSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdGhl IGVtYWlsIHRvIHRoZQppbnRlbmRlZCByZWNpcGllbnQsIGJlIGFkdmlzZWQgdGhhdCB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsCmluIGVycm9yLCBhbmQgdGhhdCBhbnkgdXNlLCBkaXNzZW1p bmF0aW9uLCBmb3J3YXJkaW5nLCBwcmludGluZywgb3IKY29weWluZyBvZiB0aGlzIGVtYWlsIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzIGVtYWlsCmluIGVycm9y LCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlci4KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K From nobody Tue Jun 23 11:14:04 2015 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 CA4A81A0087 for ; Tue, 23 Jun 2015 11:14:01 -0700 (PDT) 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 VdfkXqypKMVa for ; Tue, 23 Jun 2015 11:14:00 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AFC11A006C for ; Tue, 23 Jun 2015 11:14:00 -0700 (PDT) Received: by wiga1 with SMTP id a1so114130484wig.0 for ; Tue, 23 Jun 2015 11:13:59 -0700 (PDT) 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=r1YIEvweDMCvp08n/2KgVn3acbm0ycCsSgxwxI5Pybo=; b=Lf2Md8BpWjISp8vnZtjiv1ra1izTPpxWAN+pBLT5S3D5Cmte1YZu4AHGCag5T2DMzE f48pD/OL0gr1dnR19ZpHAIhkVtp1N7QqaLO3664Jw6hILvXjoub1Iyr5C0eD0+7ap9O8 YwmLzD1EAOayGqY8teJVaTI9VmDvKzoJs9kgdCIunnzUg63epXMylP4uKiToN1FVZVzD UqpgaLjJ1vv7MiuZOkiPy7bRqLwuT3V53liSwob0aWbClNTE5Q8nHWDJwq8LS/kJ4wfT xxQkY0+iY9cnWFxOZersJc1lbQETIwuScYbGQInsYsAlx2fcXV/s54uQRuwAN0N8zWLz S2vg== X-Received: by 10.180.88.99 with SMTP id bf3mr5755039wib.75.1435083239026; Tue, 23 Jun 2015 11:13:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Tue, 23 Jun 2015 11:13:29 -0700 (PDT) In-Reply-To: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> From: Henning Rogge Date: Tue, 23 Jun 2015 20:13:29 +0200 Message-ID: To: "Ratliff, Stanley" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" , RJ Atkinson Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 18:14:02 -0000 On Tue, Jun 23, 2015 at 8:05 PM, Ratliff, Stanley wr= ote: > I believe the discussion is now centering around 3 different name/number = spaces: (1) Data Items, (2) Signals, and (3) Extensions. I can see a need = for a larger private use space in the data items registry than for the sign= als registry, for example. So I believe we'll wind up with different alloca= tions, for the 3 different registries. From what I gather in your note, it = seems that you are more interested in the size of the private use data item= space. Did I get that correct? If not, please advise. Yes... "a lot of" private data items... some private signals... and (if any) only a few "private" extensions. Otherwise we will see lots of propietary Extensions with no will to move to the IETF. > From the perspective of someone who is a co-author of RFC 5578 (PPPoE Ext= ensions for radio-based traffic), I can tell you that there are *a lot* of = other reasons to avoid PPPoE like the plague... ;-) I know a few people who talked about a "multicast adapter" for PPPoE radios... not sure if it ever worked well. ;) Henning From nobody Tue Jun 23 11:41:26 2015 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 0494E1B2F2E for ; Tue, 23 Jun 2015 11:41:25 -0700 (PDT) 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 8naotUf7XY8T for ; Tue, 23 Jun 2015 11:41:24 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (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 CE9F21B2F62 for ; Tue, 23 Jun 2015 11:41:23 -0700 (PDT) Received: by yhan67 with SMTP id n67so7416745yha.3 for ; Tue, 23 Jun 2015 11:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hL13pmbT6oBUicLDgl1n9K5V6rDzVNY/xaDLNYtfsVc=; b=SxQYoHz80zzvDpUUaz8vkpfqhx8AUJXOtBtETCU15IHEyh/X8jVdx16PWNZTfL6mf2 KNCwPQFCAIjhPtPirCezrZCQZ6dqP+p0tA7N2zz41ilWmGVe2j5YyV4mYnx5qpbICtF6 663JpLFsmACUr8HHfzP+rLC/60ew4LH890h4hBhcLErThoBo7GJI0aEdq1+Im+qQ1KiI cCRU5t5tb8EaN6LIQR1aUU++82lcTAJplQ0fY7auPT5+j47/JY5BbFrHGHVioo130l0M lvV6+4JKfPOp7ZVxgFCPhQS22k+vE6Aw4tNMrtdBJXuviKHbk7UJbmgQ+LWF5A7Bm5lg OVZw== X-Received: by 10.13.209.7 with SMTP id t7mr44338395ywd.121.1435084882275; Tue, 23 Jun 2015 11:41:22 -0700 (PDT) Received: from [10.30.20.16] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id q206sm19005664ywb.13.2015.06.23.11.41.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jun 2015 11:41:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: RJ Atkinson In-Reply-To: Date: Tue, 23 Jun 2015 14:41:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <569CFA47-0F19-408B-8B93-BED36B84C849@gmail.com> References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> To: "Ratliff, Stanley" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 18:41:25 -0000 > On 23 Jun 2015, at 14:05 , Ratliff, Stanley = wrote: >=20 > I believe the discussion is now centering around 3 different = name/number spaces: =20 > (1) Data Items, (2) Signals, and (3) Extensions.=20 Stan, If that is the case, I am confused by your current node, and might not have understood Lou=E2=80=99s most recent note. I have thought we were talking about "Data Items=E2=80=9D alone just = now,=20 and segmenting that number space into multiple chunks with (a) some=20 Reserved outright and (b) a number space that is BOTH pre-defined=20 Data Items and future extensions to Data Items and (c) a different=20 number space reserved for Private Use. I also thought we were=20 talking about possible size ranges for the several different chunks of Data Item number space. Lets back up one step in hope of clarity. In your mind, how is a=20 Data Item fundamentally a different animal from an Extension ? =20 Whether it is defined in the base DLEP RFC ? Signals are worthy of discussion, and I recognize that Lou has mentioned them, but I have been trying to hold off on that topic for now, in hope of avoiding the cross-threading that seems already=20 to have occurred. It might help clarify discussion if we updated=20 subject lines and tried to separate the threads of discussion. Yours, Ran From nobody Tue Jun 23 11:51:23 2015 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 B60F11A024E for ; Tue, 23 Jun 2015 11:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 m2l9B_SCmB0O for ; Tue, 23 Jun 2015 11:51:14 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 8E2CB1A0263 for ; Tue, 23 Jun 2015 11:51:14 -0700 (PDT) Received: (qmail 10095 invoked by uid 0); 23 Jun 2015 18:51:07 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 23 Jun 2015 18:51:07 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id k0kB1q01V2SSUrH010kElD; Tue, 23 Jun 2015 18:44:14 -0600 X-Authority-Analysis: v=2.1 cv=VdVkYjZ9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=texx4mzSAAAA:8 a=48vgC7mUAAAA:8 a=DG8x741T839zklzjvB0A:9 a=-qsLkcmdS9EjTKdx:21 a=v8Uf8k8kcE0G2JIv:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=/Wy5XHEkdMA8vrkdBRwobO8cQ82bpEn4BzyZLmKKHYY=; b=wB27XXNpnsuMLxpn/tpkyJL3zyYA1LyuitLlAnoWJorGqtBHLJ8nW+XJoIeSUTTGTYV2uWBVCrvq9vixpdF+n11wCGuvt9f50Hhc4SIVikDmqhO0QHUF+dPDU+YRvaJO; Received: from box313.bluehost.com ([69.89.31.113]:34300 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z7THk-0003WE-42; Tue, 23 Jun 2015 12:51:04 -0600 Message-ID: <5589AA93.9020206@labn.net> Date: Tue, 23 Jun 2015 14:50:59 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: RJ Atkinson , "Ratliff, Stanley" References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <100d61acc64140c59a72bdadf86a2fe7@VAUSDITCHM3.idirect.net> <569CFA47-0F19-408B-8B93-BED36B84C849@gmail.com> In-Reply-To: <569CFA47-0F19-408B-8B93-BED36B84C849@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 18:51:16 -0000 Ran, On 6/23/2015 2:41 PM, RJ Atkinson wrote: >> On 23 Jun 2015, at 14:05 , Ratliff, Stanley wrote: >> >> I believe the discussion is now centering around 3 different name/number spaces: >> (1) Data Items, (2) Signals, and (3) Extensions. > Stan, > > If that is the case, I am confused by your current node, > and might not have understood Lou’s most recent note. I'm not sure what you are referring to, but I think the draft requires the 3 new registries mentioned above in addition to the Status Code registry already mentioned in the draft. > I have thought we were talking about "Data Items†alone just now, > and segmenting that number space into multiple chunks with (a) some > Reserved outright and (b) a number space that is BOTH pre-defined > Data Items and future extensions to Data Items and (c) a different > number space reserved for Private Use. I also thought we were > talking about possible size ranges for the several different > chunks of Data Item number space. One of the other messages brought in the other two registries and I did reply to that and I think this is what Stan is referring to. > Lets back up one step in hope of clarity. In your mind, how is a > Data Item fundamentally a different animal from an Extension ? > Whether it is defined in the base DLEP RFC ? > > Signals are worthy of discussion, and I recognize that Lou has > mentioned them, but I have been trying to hold off on that topic > for now, That's fair. > in hope of avoiding the cross-threading that seems already > to have occurred. Correct ;-) Lou > It might help clarify discussion if we updated > subject lines and tried to separate the threads of discussion. > > Yours, > > Ran > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Jun 23 13:01:04 2015 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 AE4421B2FD3 for ; Tue, 23 Jun 2015 13:01:01 -0700 (PDT) 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 v1qDVXEpfm7L for ; Tue, 23 Jun 2015 13:01:00 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 DF9DE1B2FDC for ; Tue, 23 Jun 2015 13:00:50 -0700 (PDT) Received: by oiax193 with SMTP id x193so15189003oia.2 for ; Tue, 23 Jun 2015 13:00:50 -0700 (PDT) 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=ERdgQGUUq/JhHVumXxvjWpO31j/a2M+tCwslFttA2I0=; b=bc4tuhGDEOWSfkASc3DPjyDso87JsZReFz6cg/FGX35FyabEac+tFvzYXVD/HyulcH J7za9GbfZF06Ds/4DevJbD8Oi6myNVmrDcZ81uuLak4GZwq59rp+AxNU8xJYO9LiKlCz H5yW/QuvBwjsATKvZyTtXu3r7vQAC4CSVogVPzuxTNIAR6EtLHxF3s93B5FatT6mADKM FwNehS4gfEIZdIe7/y+O/9L7A40LKdNZo0ftj2ao48gxXzhBWFVZEfeHH/CWIefxkBYC DKe9ziosxjbg9ZwnsZOrwBWBPQxV0Is+x5QVfiyqtukIl35+vucnpfi6S8+WOdtIQ10u cndg== MIME-Version: 1.0 X-Received: by 10.60.15.133 with SMTP id x5mr31149295oec.80.1435089650294; Tue, 23 Jun 2015 13:00:50 -0700 (PDT) Received: by 10.202.195.134 with HTTP; Tue, 23 Jun 2015 13:00:50 -0700 (PDT) Date: Tue, 23 Jun 2015 16:00:50 -0400 Message-ID: From: Justin Dean To: "manet@ietf.org" , Christopher Dearlove Content-Type: multipart/alternative; boundary=089e014945c0d3a777051934d895 Archived-At: Subject: [manet] Draft change state 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 Jun 2015 20:01:01 -0000 --089e014945c0d3a777051934d895 Content-Type: text/plain; charset=UTF-8 As mentioned by Stan on the list and within the last working group interim meeting RFC5444 usage document draft-clausen-manet-rfc5444-usage-00 was proposed to be adopted. There was consensous on the list to adopt the draft so it has been moved. Chris/Ulrich/Thomas please rev the draft with a new title so we can replace the personal draft. The wg draft "Multi-path Extension for the Optimized Link State Routing Protocol version 2" has also been updated addressing my concerns unless there is objection this draft will be last called soon. Justin Dean --089e014945c0d3a777051934d895 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As mentioned by Stan on the list and within the last = working group interim meeting RFC5444 usage document draft-clausen-manet-rfc5444-usage-00 was prop= osed to be adopted.=C2=A0 There was consensous on the list to adopt the dra= ft so it has been moved.=C2=A0 Chris/Ulrich/Thomas please rev the draft wit= h a new title so we can replace the personal draft.



The wg draft "Multi-path Extension for the Optimize= d Link State Routing Protocol version 2" has also been updated address= ing my concerns unless there is objection this draft will be last called so= on.

Justin= Dean
--089e014945c0d3a777051934d895-- From nobody Tue Jun 23 14:06:20 2015 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 ABA531A19E4 for ; Tue, 23 Jun 2015 14:06:17 -0700 (PDT) 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 nMyLj0RNBD3P for ; Tue, 23 Jun 2015 14:06:15 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id A977D1A19E5 for ; Tue, 23 Jun 2015 14:06:15 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5NL60sw030742; Tue, 23 Jun 2015 17:06:07 -0400 From: "Wiggins, David - 0665 - MITLL" To: Rick Taylor , Lou Berger , "Ratliff, Stanley" , RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] RtgDir review: draft-ietf-manet-dlep-14 Thread-Index: AQHQqfY6q4BISdYAIk+JbR87kxTblJ26nOSA Date: Tue, 23 Jun 2015 21:06:02 +0000 Message-ID: References: <8E5FEB61-DB01-4965-AFF8-DBCD85F0F961@gmail.com> <55885918.5020509@labn.net> <5589681D.6010202@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2B5CBB@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2B5D45@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016C2B5DAD@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B5DAD@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3517923961_58759001" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-23_07:2015-06-23,2015-06-23,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-1506230336 Archived-At: Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-14 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 Jun 2015 21:06:17 -0000 --B_3517923961_58759001 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Rick, On 6/23/15, 11:56 AM, "Rick Taylor" wrote: >On 23/06/15 16:51, Wiggins, David - 0665 - MITLL wrote: >> I think we need some Private Use extension ids too. > >No, Extensions are Specification Required by design. Experiments are >provided for Private Use id use. Are Experiments specified by the Experiment Name (string) data item, or are you replacing that with something else? David --B_3517923961_58759001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFBksiVKZCLHE68A9 ngjQ0/N/6PPpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYyMzIxMDYwMVowDQYJKoZIhvcNAQEBBQAEggEAF5HqV+Tv4Wl6qQCvgPHGQRbtr3mVCRWM hBOSYsfCSD5ygqV32bt8OSW7WWyA5ojdjut1IjLyFcscwY+dld3EM1QWcrMRe2BTqqX+jDWo +txJP7z93BzscynRrvgcOfomU7waUsgYtvTEztDK8ukeKsfYQFq+qxdouCWNuHN5FLoozPPV YTVkYkGkHGO47u8lQKpsyn5X9jE547/tusEX+Zc4mVozo6qMfRHX6tG8c29mIThO0vf0ScJ8 dblmLrxc7Uivqb0zZfw9Hp4pqap/J9X4UhIH0AzraS81Lsg4eG5AO6YhbrdYyjlkvYX/n6+z 61sJpawe4Cl+3FTBCbWmhA== --B_3517923961_58759001-- From nobody Tue Jun 23 22:17:21 2015 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 751621ACD5A; Tue, 23 Jun 2015 22:17:18 -0700 (PDT) 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 kfg7I1EXazTp; Tue, 23 Jun 2015 22:17:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4831ACD55; Tue, 23 Jun 2015 22:17:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150624051717.466.19224.idtracker@ietfa.amsl.com> Date: Tue, 23 Jun 2015 22:17:17 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-00.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: Wed, 24 Jun 2015 05:17:18 -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 : Rules For Designing Protocols Using the RFC5444 Generalized Packet/ Message Format Authors : Thomas Clausen Christopher Dearlove Ulrich Herberg Henning Rogge Filename : draft-ietf-manet-rfc5444-usage-00.txt Pages : 17 Date : 2015-06-23 Abstract: This document updates the generalized MANET packet/message format, specified in RFC5444, by providing prescriptive guidelines for how protocols can use that packet/message format. In particular, these mandatory guidelines prohibit a number of uses of RFC5444 that have been suggested in various proposals, and which would have lead to interoperability problems, to impediment of protocol extension development, and to inability to use generic RFC5444 parsers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-00 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 Jun 23 23:19:05 2015 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 0ABAB1B2A4F for ; Tue, 23 Jun 2015 23:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622] 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 Z_Nh00e_aZ9T for ; Tue, 23 Jun 2015 23:19:01 -0700 (PDT) Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::22f]) (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 5AD961B2A29 for ; Tue, 23 Jun 2015 23:19:01 -0700 (PDT) Received: by vnbf7 with SMTP id f7so4859771vnb.13 for ; Tue, 23 Jun 2015 23:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=U4EOOb/gBfDRTbLvq5QeZFtFoQD/+KcdgKM2g78lEgc=; b=RrIX1uOE9R56tNY6QZ00hGLoVJqYdjVQBvNf3rM23AWw0SIRChV414dpCvOMZV2DQe OI985QBcHI3thgI7CRih2mDuGXUwJdCoqC3ye7EVY3WXSO7tM5K5/dzHqPafpvgA+iOn 4PRkbmWsyZPB7zMVHmWJwjMN9Mt8kUClYjqsg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=U4EOOb/gBfDRTbLvq5QeZFtFoQD/+KcdgKM2g78lEgc=; b=Ewm3CUoOjuBjca3ipsoQS9M26xXd5VNhNiWMyEgn8XChmB9PlnrRO9t8DgaNCfN6O0 fVU0fySYY6BpI30vG69CtyrDKBQfvqyF8bhxESMeT4ub2p690GmLQlo9fyeYujNNDCF9 ymJMp3GrvlNkUxwR6A4az+oVGFHk5TFBppjD++WKVI0QWwVzS5strvtur8wuElvDsvU1 VzSpl67/otj2RAWZYCnt3HTSmmw3WUxscNfyCnBqBI1F0TX1x9H5qg6dJZgh28soklL+ buyEMp503kaTVa1f1INNrZl3LCHTovVZGybuXGkNnZ0x+8gDnWQ8857OvU538bZLq44h txjw== X-Gm-Message-State: ALoCoQkIdBsrV0dwugtBMU7cSNUM71Y//SfMVVpd1wbrhHhkkODc+nG4pA3aGaHKg7VFtroDybx7 MIME-Version: 1.0 X-Received: by 10.52.136.239 with SMTP id qd15mr21778118vdb.89.1435126740519; Tue, 23 Jun 2015 23:19:00 -0700 (PDT) Received: by 10.31.97.4 with HTTP; Tue, 23 Jun 2015 23:19:00 -0700 (PDT) In-Reply-To: <20150624051717.466.19224.idtracker@ietfa.amsl.com> References: <20150624051717.466.19224.idtracker@ietfa.amsl.com> Date: Tue, 23 Jun 2015 23:19:00 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-00.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: Wed, 24 Jun 2015 06:19:03 -0000 I have posted the -00 WG version (draft-ietf-manet-rfc5444-usage-00). It is the same as draft-clausen-manet-rfc5444-usage-00, with the exception of some minor spelling and idnits fixes. I apologize that we haven't yet responded to some comments (from Lotte); busy times... we hope to get to it soon. Best regards Ulrich On Tue, Jun 23, 2015 at 10:17 PM, 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 : Rules For Designing Protocols Using the RFC5444 Generalized Packet/ Message Format > Authors : Thomas Clausen > Christopher Dearlove > Ulrich Herberg > Henning Rogge > Filename : draft-ietf-manet-rfc5444-usage-00.txt > Pages : 17 > Date : 2015-06-23 > > Abstract: > This document updates the generalized MANET packet/message format, > specified in RFC5444, by providing prescriptive guidelines for how > protocols can use that packet/message format. In particular, these > mandatory guidelines prohibit a number of uses of RFC5444 that have > been suggested in various proposals, and which would have lead to > interoperability problems, to impediment of protocol extension > development, and to inability to use generic RFC5444 parsers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-00 > > > 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 Wed Jun 24 01:14:25 2015 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 4F19B1B31E3 for ; Wed, 24 Jun 2015 01:14:24 -0700 (PDT) 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 B2mPwuAGxjhU for ; Wed, 24 Jun 2015 01:14:23 -0700 (PDT) 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 E2EC31B31DD for ; Wed, 24 Jun 2015 01:14:22 -0700 (PDT) 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; Wed, 24 Jun 2015 09:13:44 +0100 From: Rick Taylor To: manet IETF Thread-Topic: DLEP-14 comments Thread-Index: AdCuVa8IZvnIVLfUTqC4Gk3K/6/NiA== Date: Wed, 24 Jun 2015 08:13:42 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2B89FB@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: Subject: [manet] DLEP-14 comments 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 Jun 2015 08:14:24 -0000 Can I say a big thank you to everyone who has given us feedback on DLEP-14.= =0A= =0A= We are currently updating the draft, to integrate the comments we have. =0A= With that in mind, can I ask for some patience and a moratorium on the = =0A= topics of Versioning and Ids please?=0A= =0A= Thanks=0A= =0A= Rick=0A= From nobody Wed Jun 24 07:27:56 2015 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 4DBB31AC416 for ; Wed, 24 Jun 2015 07:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, 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 KKsRRx-NX054 for ; Wed, 24 Jun 2015 07:27:53 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92561AC419 for ; Wed, 24 Jun 2015 07:27:43 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1Z7leQ-0036Pe-9T>; Wed, 24 Jun 2015 16:27:42 +0200 Received: from [141.22.28.170] (helo=frankenbook-pro.cpt.haw-hamburg.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1Z7leQ-001VGT-3B>; Wed, 24 Jun 2015 16:27:42 +0200 From: Lotte Steenbrink Content-Type: multipart/mixed; boundary="Apple-Mail=_384F1C68-8974-406B-A511-493C6DE2C736" Date: Wed, 24 Jun 2015 16:27:41 +0200 To: manet@ietf.org Message-Id: <1F5C22A3-80F0-4F34-A13C-5A5C560C3133@fu-berlin.de> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: 141.22.28.170 X-ZEDAT-Hint: A Archived-At: Subject: [manet] AODVv2 RFC5444 packet changes 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 Jun 2015 14:27:55 -0000 --Apple-Mail=_384F1C68-8974-406B-A511-493C6DE2C736 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, after a lot of discussion and some consultation with Henning, we've = updated AODVv2's RFC5444 packet section so that each Address is now = associated with a TLV that can definitively identify the Type of the = Address (i.e. Originating Address, Target Address, etc). We've chosen to = create a new Address Block TLV type for this, namely ADDRESS_TYPE. Each = address is associated with an ADDRESS_TYPE TLV which contains a specific = value encoding the type of the address (see Table 12).=20 Attached you'll find the modified sections.=20 Additionally, we removed the following two paragraphs from Section 7: =46rom 7.1: The OrigSeqNum data element in a RteMsg MUST apply only to OrigAddr. Therefore the other address in the AddressList is TargAddr. If the TargSeqNum data element is included, then it MUST apply only to TargAddr. =46rom 7.2: The TargSeqNum data element in a RteMsg MUST apply only to TargAddr. Therefore the other address in the AddressList is OrigAddr. As always, we're looking forward to your feedback! Regards, Lotte --Apple-Mail=_384F1C68-8974-406B-A511-493C6DE2C736 Content-Disposition: attachment; filename*0="AODVv2 RFC5444 Representation v2 (Replaces Draft 9 Sections 8 an"; filename*1="d 12)" Content-Type: application/octet-stream; x-unix-mode=0644; name="AODVv2 RFC5444 Representation v2 (Replaces Draft 9 Sections 8 and 12)" Content-Transfer-Encoding: 7bit 8. RFC 5444 Representation AODVv2 specifies that all control plane messages between routers SHOULD use the Generalized Mobile Ad Hoc Network Packet/Message Format [RFC5444], and therefore AODVv2 defines route messages comprising data elements that map to message elements in RFC 5444. RFC 5444 provides a multiplexed transport for multiple protocols. An RFC 5444 multiplexer may choose to optimize the content of certain message elements to reduce control plane overhead. A brief summary of the RFC 5444 format: 1. A packet contains zero or more messages 2. A message contains a Message Header, one Message TLV Block, zero or more Address Blocks, and one Address Block TLV Block per Address Block 3. The Message TLV Block MAY contain zero or more Message TLVs 4. An Address Block TLV Block MAY include zero or more Address Block TLVs 5. Each TLV value in an Address Block TLV Block can be associated with all of the addresses, a contiguous set of addresses, or a single address in the Address Block AODVv2 does not require access to the RFC 5444 packet header. In the message header, AODVv2 uses , , and . indicates the length of any addresses in the message (using := address length in octets - 1, i.e. 3 for IPv4 and 15 for IPv6). Each address included in the Address Block is identified as OrigAddr, TargAddr, PktSource, or Unreachable Address by including an ADDRESS_TYPE TLV in the Address Block TLV Block. The addresses in an Address Block may appear in any order, and values in a TLV in the Address Block TLV Block must be associated with the correct address in the Address Block. To indicate which value is associated with each address, the AODVv2 message representation uses lists where the order of the addresses in the AODVv2 AddressList data element matches the order of values in other list-based data elements, e.g., the order of SeqNums in the SeqNumList in a RERR. The following sections show how AODVv2 data elements are represented in RFC 5444 messages. See Section 12 for more information about the Message TLVs and Address Block TLVs AODVv2 defines, and the type numbers allocated. Where the extension type of a TLV is set to zero, this is the default RFC 5444 value and the extension type will not be included in the message. 8.1. RREQ 8.1.1. Message Header +---------------+-----------------+---------------------------------+ | Data Element | Header Field | Value | +---------------+-----------------+---------------------------------+ | None | | RREQ | | msg_hop_limit | | MAX_HOPCOUNT | | msg_hop_count | | Number of hops traversed so far | | | | by the message. | +---------------+-----------------+---------------------------------+ 8.1.2. Message TLV Block A RREQ contains no Message TLVs. 8.1.3. Address Block A RREQ contains two Addresses, OrigAddr and TargAddr, and each address has an associated prefix length. If the prefix length has not been included in the AODVv2 message, it is equal to the address length in bits. +-------------------------+------------------------------+ | Data Elements | Address Block | +-------------------------+------------------------------+ | OrigAddr/OrigPrefixLen |
+ | | TargAddr/TargPrefixLen |
+ | +-------------------------+------------------------------+ 8.1.4. Address Block TLV Block Address Block TLVs are always associated with addresses in the Address Block. The following sections show the TLVs that apply to each address. 8.1.4.1. Address Block TLVs for OrigAddr +--------------+---------------+------------+-----------------------+ | Data Element | TLV Type | Extension | Value | | | | Type | | +--------------+---------------+------------+-----------------------+ | None | ADDRESS_TYPE | 0 | ADDRTYPE_ORIGADDR | | OrigSeqNum | SEQ_NUM | 0 | Sequence Number of | | | | | RREQ_Gen, the router | | | | | which initiated route | | | | | discovery. | | OrigMetric | PATH_METRIC | MetricType | Metric for the route | | /MetricType | | | to OrigAddr, using | | | | | MetricType. | | ValidityTime | VALIDITY_TIME | 0 | ValidityTime for | | | | | route to OrigAddr. | +--------------+---------------+------------+-----------------------+ In the AODVv2 representation, if the message relates to DEFAULT_METRIC_TYPE, MetricType is not included in the message. The RFC 5444 representation will set the extension type in the PATH_METRIC TLV to 0. AODVv2 interprets a MetricType of 0 as DEFAULT_METRIC_TYPE. 8.1.4.2. Address Block TLVs for TargAddr +------------+--------------+-------------+-------------------------+ | Data | TLV Type | Extension | Value | | Element | | Type | | +------------+--------------+-------------+-------------------------+ | None | ADDRESS_TYPE | 0 | ADDRTYPE_TARGADDR | | TargSeqNum | SEQ_NUM | 0 | The last known | | | | | TargSeqNum for | | | | | TargAddr. | +------------+--------------+-------------+-------------------------+ 8.2. RREP 8.2.1. Message Header +---------------+-----------------+---------------------------------+ | Data Element | Header Field | Value | +---------------+-----------------+---------------------------------+ | None | | RREP | | msg_hop_limit | | from | | | | corresponding RREQ. | | msg_hop_count | | Number of hops traversed so far | | | | by the message. | +---------------+-----------------+---------------------------------+ 8.2.2. Message TLV Block A RREP may contain the AAckReq data element in order to monitor adjacency, as described in Section 6.2. +---------------+-----------+-----------------+--------+ | Data Element | TLV Type | Extension Type | Value | +---------------+-----------+-----------------+--------+ | AckReq | ACK_REQ | 0 | None | +---------------+-----------+-----------------+--------+ 8.2.3. Address Block A RREP contains two Addresses, OrigAddr and TargAddr, and each address has an associated prefix length. If the prefix length has not been included in the AODVv2 message, it is equal to the address length in bits. +-------------------------+------------------------------+ | Data Elements | Address Block | +-------------------------+------------------------------+ | OrigAddr/OrigPrefixLen |
+ | | TargAddr/TargPrefixLen |
+ | +-------------------------+------------------------------+ 8.2.4. Address Block TLV Block Address Block TLVs are always associated with addresses in the Address Block. The following sections show the TLVs that apply to each address. 8.2.4.1. Address Block TLVs for OrigAddr +-------------+---------------+----------------+--------------------+ | Data | TLV Type | Extension Type | Value | | Element | | | | +-------------+---------------+----------------+--------------------+ | None | ADDRESS_TYPE | 0 | ADDRTYPE_ORIGADDR | +-------------+---------------+----------------+--------------------+ 8.2.4.2. Address Block TLVs for TargAddr +--------------+---------------+------------+-----------------------+ | Data Element | TLV Type | Extension | Value | | | | Type | | +--------------+---------------+------------+-----------------------+ | None | ADDRESS_TYPE | 0 | ADDRTYPE_TARGADDR | | TargSeqNum | SEQ_NUM | 0 | Sequence number of | | | | | RREP_Gen, the router | | | | | which created the | | | | | RREP. | | TargMetric | PATH_METRIC | MetricType | Metric for the route | | /MetricType | | | to TargAddr, using | | | | | MetricType. | | ValidityTime | VALIDITY_TIME | 0 | ValidityTime for | | | | | route to TargAddr. | +--------------+---------------+------------+-----------------------+ In the AODVv2 representation, if the message relates to DEFAULT_METRIC_TYPE, MetricType is not included in the message. The RFC 5444 representation will set the extension type in the PATH_METRIC TLV to 0. AODVv2 interprets a MetricType of 0 as DEFAULT_METRIC_TYPE. 8.3. RREP_Ack 8.3.1. Message Header +---------------+---------------+-----------+ | Data Element | Header Field | Value | +---------------+---------------+-----------+ | None | | RREP_Ack | +---------------+---------------+-----------+ 8.3.2. Message TLV Block A RREP_Ack contains no Message TLVs. 8.3.3. Address Block A RREP_Ack contains no Address Block. 8.3.4. Address Block TLV Block A RREP_Ack contains no Address Block TLV Block. 8.4. RERR 8.4.1. Message Header +----------------+------------------+---------------+ | Data Element | Header Field | Value | +----------------+------------------+---------------+ | None | | RERR | | msg_hop_limit | | MAX_HOPCOUNT | +----------------+------------------+---------------+ 8.4.2. Message TLV Block A RERR contains no Message TLVs. 8.4.3. Address Block The Address Block in a RERR may contain PktSource, the source IP address of the packet triggering RERR generation, as detailed in Section 7.4. Prefix Length associated with PktSource is equal to the address length in bits. Address Block always contains one Address per route that is no longer valid, and each address has an associated prefix length. If a prefix length has not been included for this address, it is equal to the address length in bits. +------------------------------+------------------------------------+ | Data Element | Address Block | +------------------------------+------------------------------------+ | PktSource |
+ for | | | PktSource | | AddressList/PrefixLengthList |
+ for | | | each unreachable address in | | | AddressList | +------------------------------+------------------------------------+ 8.4.4. Address Block TLV Block Address Block TLVs are always associated with addresses in the Address Block. The following sections show the TLVs that apply to each type of address in the RERR. 8.4.4.1. Address Block TLVs for PktSource +--------------+---------------+---------------+--------------------+ | Data Element | TLV Type | Extension | Value | | | | Type | | +--------------+---------------+---------------+--------------------+ | PktSource | ADDRESS_TYPE | 0 | ADDRTYPE_PKTSOURCE | +--------------+---------------+---------------+--------------------+ 8.4.4.2. Address Block TLVs for Unreachable Addresses +----------------+--------------+------------+----------------------+ | Data Element | TLV Type | Extension | Value | | | | Type | | +----------------+--------------+------------+----------------------+ | None | ADDRESS_TYPE | 0 | ADDRTYPE_UNREACHABLE | | SeqNumList | SEQ_NUM | 0 | Sequence Number | | | | | associated with | | | | | invalid route to the | | | | | unreachable address. | | MetricTypeList | PATH_METRIC | MetricType | None. Extension Type | | | | | set to MetricType of | | | | | the route to the | | | | | unreachable address. | +----------------+--------------+------------+----------------------+ Multiple PATH_METRIC TLVs may be necessary if routes with multiple MetricTypes are included in the RERR. In the AODVv2 representation, if the RERR message includes only routes with DEFAULT_METRIC_TYPE, MetricType is not included in the message. In this case, the RFC 5444 representation does not need to include a PATH_METRIC TLV to indicate the DEFAULT_METRIC_TYPE. If the RERR message includes both routes with DEFAULT_METRIC_TYPE and other MetricTypes, only the routes with non-default MetricType need to be marked with a PATH_METRIC TLV using Extension Type to indicate MetricType. AODVv2 interprets the absence of MetricType information as an indication of DEFAULT_METRIC_TYPE. 12. IANA Considerations This section specifies several RFC 5444 message types, message tlv- types, and address tlv-types required for AODVv2. Also, a new registry of 16-bit metric types is specified. 12.1. RFC 5444 Message Types +-----------------------------------------+-----------+ | Name of Message | Type | +-----------------------------------------+-----------+ | Route Request (RREQ) | 10 (TBD) | | Route Reply (RREP) | 11 (TBD) | | Route Error (RERR) | 12 (TBD) | | Route Reply Acknowledgement (RREP_Ack) | 13 (TBD) | +-----------------------------------------+-----------+ Table 8: AODVv2 Message Types 12.2. RFC 5444 Message TLV Types +--------------------------+----------+---------------+-------------+ | Name of TLV | Type | Length | Reference | | | | (octets) | | +--------------------------+----------+---------------+-------------+ | ACK_REQ (Acknowledgment | 10 (TBD) | 0 | Section 6.2 | | Request) | | | | +--------------------------+----------+---------------+-------------+ Table 9: AODVv2 Message TLV Types 12.3. RFC 5444 Address Block TLV Types +------------------------+----------+---------------+---------------+ | Name of TLV | Type | Length | Reference | | | | (octets) | | +------------------------+----------+---------------+---------------+ | PATH_METRIC | 10 (TBD) | depends on | Section 7 | | | | MetricType | | | SEQ_NUM | 11 (TBD) | 2 | Section 7 | | ADDRESS_TYPE | 15 (TBD) | 1 | Section 8 | | VALIDITY_TIME | 1 | 1 | [RFC5497] | +------------------------+----------+---------------+---------------+ Table 10: AODVv2 Address Block TLV Types 12.4. MetricType Allocation Metric types are identified according to the assignments in [RFC6551]. +------------------------+----------+--------------+ | Name of MetricType | Type | Metric Size | +------------------------+----------+--------------+ | Unassigned | 0 | Undefined | | Currently Unsupported | 1 - 2 | TBD | | Hop Count | 3 [TBD] | 1 octet | | Currently Unsupported | 4 - 8 | TBD | | Unallocated | 9 - 254 | TBD | | Reserved | 255 | Undefined | +------------------------+----------+--------------+ Table 11: AODVv2 Metric Types When creating AODVv2 messages which relate to the DEFAULT_METRIC_TYPE, MetricType is not reported in the message. In the RFC 5444 message representation, the PATH_METRIC TLV will not include an extension type. While RFC 5444 would interpret the lack of an extension type to mean extension type is zero, AODVv2 will interpret an extension type of zero to mean the DEFAULT_METRIC_TYPE configured on the router. This is possible because zero is not assigned to any metric type ([RFC6551]). 12.5. AddressType Allocation The values used in the Address Type TLV used in Section 8 are given in the table below: +-----------------------+--------+ | Address Type | Value | +-----------------------+--------+ | ADDRTYPE_ORIGADDR | 0 | | ADDRTYPE_TARGADDR | 1 | | ADDRTYPE_UNREACHABLE | 2 | | ADDRTYPE_PKTSOURCE | 3 | +-----------------------+--------+ Table 12: AODVv2 Address Types --Apple-Mail=_384F1C68-8974-406B-A511-493C6DE2C736-- From nobody Wed Jun 24 07:52:08 2015 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 139011A01CB for ; Wed, 24 Jun 2015 07:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 YEef_DG21CEl for ; Wed, 24 Jun 2015 07:52:06 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id A2BB61A01AA for ; Wed, 24 Jun 2015 07:52:06 -0700 (PDT) Received: (qmail 2062 invoked by uid 0); 24 Jun 2015 14:52:03 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 24 Jun 2015 14:52:03 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id kLl11q00u2SSUrH01Ll42D; Wed, 24 Jun 2015 14:45:10 -0600 X-Authority-Analysis: v=2.1 cv=LLP1Hvm9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=r1qcpBXOjk-qiTxzV4UA:9 a=pILNOxqGKmIA:10 a=rKrVYePj7rwA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=Qovjy+gmNhIw3XCzRPvJK38RZ8AYasB9tm36B6Wf8SM=; b=P5l99e/6Rzu/IQT0mneA4tWvAgHMmx8S/p1jVkBN2/uKU7QytjNRSpPNrnXAwzEKMW+MujoA6uVELWpkhn/wScnU+w7WzgCL72eInaitFlMsjzpBZ3Z29TNB62Df+Iue; Received: from box313.bluehost.com ([69.89.31.113]:37244 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z7m1p-000658-Ou; Wed, 24 Jun 2015 08:51:54 -0600 Message-ID: <558AC3FF.9020704@labn.net> Date: Wed, 24 Jun 2015 10:51:43 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rick Taylor , manet IETF References: <38A5475DE83986499AEACD2CFAFC3F98016C2B89FB@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2B89FB@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [manet] DLEP-14 comments 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 Jun 2015 14:52:08 -0000 Rick, On 6/24/2015 4:13 AM, Rick Taylor wrote: > Can I say a big thank you to everyone who has given us feedback on DLEP-14. > > We are currently updating the draft, to integrate the comments we have. > With that in mind, can I ask for some patience and a moratorium on the > topics of Versioning and Ids please? I think I see the rough consensus that can be document on IDs, but I'm not sure I've seen it on Versioning. Could you summarize the Versioning consensus that you'll be documenting? Thanks, Lou > Thanks > > Rick > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Wed Jun 24 08:21:08 2015 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 002171A8794; Wed, 24 Jun 2015 08:21:05 -0700 (PDT) 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 L7AhWRDTqJ87; Wed, 24 Jun 2015 08:21:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1301A8797; Wed, 24 Jun 2015 08:21:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150624152102.18080.39959.idtracker@ietfa.amsl.com> Date: Wed, 24 Jun 2015 08:21:02 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-tlv-naming-05.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: Wed, 24 Jun 2015 15:21:06 -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 : TLV Naming in the MANET Generalized Packet/Message Format Authors : Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-tlv-naming-05.txt Pages : 15 Date : 2015-06-24 Abstract: This document reorganizes the naming of already allocated TLV (type- length-value) types and type extensions in the Mobile Ad hoc NETwork (MANET) registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation. This document also updates the Expert Review guidelines from RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC 5444. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-tlv-naming/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-tlv-naming-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-tlv-naming-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 24 12:45:10 2015 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 45DF71B2D41 for ; Wed, 24 Jun 2015 12:45:09 -0700 (PDT) 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 sWl4MAMVVBDS for ; Wed, 24 Jun 2015 12:45:08 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF32A1B2D43 for ; Wed, 24 Jun 2015 12:44:59 -0700 (PDT) Received: by ykdr198 with SMTP id r198so29577929ykd.3 for ; Wed, 24 Jun 2015 12:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=9gJwbx9q9JXl1SDRz7egOUY5MTSKa2awzBZ00CRnl/Y=; b=MP6Ole/6yJhR/P1+bJ0guyBTp+Yn4IGHuJgosJU2RN/0irb7mro7W1QpEw61e5oApm JpztsHVzmLTBQxE0j3uEyexzntQIJzIIblq8tasMnxYGvVDlY9KOdS8bA9Kv0XOUKEpK UHla/q6v5Sn4tRNI25XI61KW5dUqd1IgEqHZeKrSPwr60URlnhFBQT2zzKYtOHTTlKxi Gpf3naTvkx4zYs39O3V468EhNdVdjdl8vroIQUcpCJES31eY8hkeE0yYRy8PuS/dF+sQ onjPt/H5uOOVnPyEGZbbhFdSa70ou4OzZWn37ITIGRm0ZL2ZI0gg4CLx8+taOi2xlmbV tGpw== X-Received: by 10.170.87.134 with SMTP id e128mr50122493yka.109.1435175099246; Wed, 24 Jun 2015 12:44:59 -0700 (PDT) Received: from [10.30.20.16] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id s10sm11699670yha.22.2015.06.24.12.44.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jun 2015 12:44:58 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2015 15:45:03 -0400 To: manet@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [manet] DLEP-14: Terminology 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 Jun 2015 19:45:09 -0000 (ASIDE: In this and any other near-term posts I am changing=20 the SUBJECT line(s) of the email to try to separate out=20 different conversation threads to reduce potential for confusion.) In common IETF terminology, =E2=80=9Cextension=E2=80=9D or = =E2=80=9Cextensions=E2=80=9D can refer to any proposed addition to an IETF protocol, such as an additional Data Item or an additional Signal. As such, using =E2=80=9CExtensions=E2=80=9D with the special DLEP = meaning of DLEP-14 in Section 3.1, in Section 7.3, and in Section 9.0 tends to create some confusion. Might I suggest that this special DLEP meaning be renamed to something else ? =20 A straw man replacement term is =E2=80=9CCapability Set=E2=80=9D. =20 I=E2=80=99m flexible, but I am looking for a term that would not be confusing in ordinary discussions about how a protocol might be =E2=80=98extended=E2=80=99 - for example by adding new Data = Items=20 or adding new Signals. Thanks, Ran=20 From nobody Wed Jun 24 12:51:37 2015 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 602441A1A7F for ; Wed, 24 Jun 2015 12:51:36 -0700 (PDT) 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 D-lRdTQaYCZh for ; Wed, 24 Jun 2015 12:51:35 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (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 F0D3E1A1A72 for ; Wed, 24 Jun 2015 12:51:34 -0700 (PDT) Received: by yhpn97 with SMTP id n97so20912129yhp.0 for ; Wed, 24 Jun 2015 12:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=GhtgfrreekiCW56PlKXcVZbAZL6jM+4EkHkDd56v/CY=; b=DTENb5InwPENjC9NiwykE9ncSYfNE0F6E3oTLSk4NbkCgO7XH1tw4LXL1TgT0Fwkoe VJFINYUH+e26xUIquZdj0uD9JnWxn1PZvoMjvo1M5f8wehMQkIIgA2tGDJ7azPC+GHCf vQzVJ3m+RseWIpjPam1oIL/TmzMb2uj+p82I47cYr94tuO1lByX7QiBZTzT7Ay1h9pN0 DjBdyuaifGNVYjalGoRsNtcG7C+vNf8EmnTFgq5PRZqqZSNRdqZMq8vAkFmMs49X4J/z 3tDB8l9ZoBD9A/LSJ7QkxaUtrcbhxj9Dj6AXqWceYd9RNgB2qF2WaHvuabokYThwAZlm l5eQ== X-Received: by 10.13.238.71 with SMTP id x68mr52586114ywe.129.1435175494355; Wed, 24 Jun 2015 12:51:34 -0700 (PDT) Received: from [10.30.20.16] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id q206sm21677969ywb.13.2015.06.24.12.51.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jun 2015 12:51:33 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2015 15:51:38 -0400 To: manet@ietf.org Message-Id: <220318AD-531B-4C42-A8B1-D2BD0BA3E89D@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [manet] DLEP-14: Credit Windowing (Section 9) 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 Jun 2015 19:51:36 -0000 Hi, First, I am a big fan of the Credit Windowing mechanism currently specified as =E2=80=9Coptional=E2=80=9D in Section 9. I think it would be helpful if that were pulled out of the DLEP base specification and into a separate I-D, with every intention that both drafts would progress together. Doing so would make DLEP-15 just the mandatory items and mandatory capabilities, but would retain the Credit-Windowing capability in its own focused, smaller, document with an explicit requirement that anything claiming to implement this separate Credit-Windowing document MUST do the whole Credit-Windowing capability as per that RFC-to-be. =20 This separation approach also would make it simpler (more clear)=20 whether a particular DLEP-capable product supported that=20 Credit-Windowing capability. If a user wanted that capability,=20 they could say that they want a widget that not only implements=20 RFC-DLEP-Base-Spec but also implements RFC-DLEP-Credit-Windowing. =20 Implementers of both could have both RFCs listed on their data sheets. The other benefit is that the DLEP base specification would be shorter so that someone first coming up to speed on basic DLEP could do so more quickly. Thanks, Ran From nobody Wed Jun 24 23:18:29 2015 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 C3A561B2BFD for ; Wed, 24 Jun 2015 23:18:27 -0700 (PDT) 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 HUcPLJRQ2u6A for ; Wed, 24 Jun 2015 23:18:26 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 E46011ACE19 for ; Wed, 24 Jun 2015 23:18:25 -0700 (PDT) Received: by wiwl6 with SMTP id l6so7858298wiw.0 for ; Wed, 24 Jun 2015 23:18:24 -0700 (PDT) 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=sEJFM/MMfT7LEG7vI34CPzaElPbRFaM/FW3AbG+wUmI=; b=iTG7PKO2zg9wJII1fc+Ua6soZ7M1s61G7ew/nZingxG7xARTJaCvPVxr6PZy3DXOfF Q2+RAsc5H1FWXckJApihWGvePE4q41c4q4tW/0226a5TNzSqfokrkOj2EqCoD4gaLjmT ARD8ZFvI1g8222WtSmYqg4GvkJb8hB0qUdjT+2OW0i0z0IcjM0D7sTEPYPlO9x76oDMI ItyWrUYB9a4V7TuA22TudYdAsVU90tpvyGLU5B1uxX4bw4lM/LJs8DiSqevBCMqpduOX fCp1t3UTBp3v73f9UA8M3Xqj0a9QK5UByWkXoBz2AU6s7FYmLADljNF6ElplgNnqvQKx 78fg== X-Received: by 10.180.88.72 with SMTP id be8mr2554797wib.45.1435213104757; Wed, 24 Jun 2015 23:18:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Wed, 24 Jun 2015 23:17:55 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Thu, 25 Jun 2015 08:17:55 +0200 Message-ID: To: RJ Atkinson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF Subject: Re: [manet] DLEP-14: Terminology 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 Jun 2015 06:18:27 -0000 On Wed, Jun 24, 2015 at 9:45 PM, RJ Atkinson wrote: > (ASIDE: In this and any other near-term posts I am changing > the SUBJECT line(s) of the email to try to separate out > different conversation threads to reduce potential for confusion.) > > In common IETF terminology, =E2=80=9Cextension=E2=80=9D or =E2=80=9Cexten= sions=E2=80=9D can > refer to any proposed addition to an IETF protocol, such as > an additional Data Item or an additional Signal. A DLEP extension is exactly that... a group of (standardized) additional signals/data-items. The "extension TLV" is just the way to tell the other side "hey, I am supporting this extension!" Henning Rogge From nobody Thu Jun 25 02:26:15 2015 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 501C51B2CDA for ; Thu, 25 Jun 2015 02:26:14 -0700 (PDT) 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 pRRx7tJ8gUCj for ; Thu, 25 Jun 2015 02:26:12 -0700 (PDT) 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 84AF71B2CCA for ; Thu, 25 Jun 2015 02:26:12 -0700 (PDT) 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, 25 Jun 2015 10:25:44 +0100 From: Rick Taylor To: Henning Rogge , RJ Atkinson Thread-Topic: [manet] DLEP-14: Terminology Thread-Index: AQHQrw7AnXETJjb4rke8Q4+Zp37zvQ== Date: Thu, 25 Jun 2015 09:25:42 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2BCB66@tss-server1.home.tropicalstormsoftware.com> References: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: MANET IETF Subject: Re: [manet] DLEP-14: Terminology 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 Jun 2015 09:26:14 -0000 I must admit that I'm with Henning on this one.=0A= =0A= A DLEP Extension is exactly that: a (Standardized) Extension to DLEP.=0A= =0A= Rick=0A= =0A= On 25/06/15 07:18, Henning Rogge wrote:=0A= > On Wed, Jun 24, 2015 at 9:45 PM, RJ Atkinson wrote:= =0A= >> (ASIDE: In this and any other near-term posts I am changing=0A= >> the SUBJECT line(s) of the email to try to separate out=0A= >> different conversation threads to reduce potential for confusion.)=0A= >>=0A= >> In common IETF terminology, =93extension=94 or =93extensions=94 can=0A= >> refer to any proposed addition to an IETF protocol, such as=0A= >> an additional Data Item or an additional Signal.=0A= >=0A= > A DLEP extension is exactly that... a group of (standardized)=0A= > additional signals/data-items. The "extension TLV" is just the way to=0A= > tell the other side "hey, I am supporting this extension!"=0A= >=0A= > Henning Rogge=0A= >=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= =0A= From nobody Thu Jun 25 03:53:52 2015 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 EADAA1B34D0 for ; Thu, 25 Jun 2015 03:53:50 -0700 (PDT) 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 gUxjPVdx8MvM for ; Thu, 25 Jun 2015 03:53:49 -0700 (PDT) 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 2A94A1B34CF for ; Thu, 25 Jun 2015 03:53:49 -0700 (PDT) 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, 25 Jun 2015 11:53:15 +0100 From: Rick Taylor To: Lou Berger , manet IETF Thread-Topic: [manet] DLEP-14 comments Thread-Index: AQHQro1S+WoBHcrUHUiRy2A0+PWP6Q== Date: Thu, 25 Jun 2015 10:53:03 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2BCF8F@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016C2B89FB@tss-server1.home.tropicalstormsoftware.com> <558AC3FF.9020704@labn.net> 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: Subject: Re: [manet] DLEP-14 comments 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 Jun 2015 10:53:51 -0000 On 24/06/15 15:51, Lou Berger wrote:=0A= > Rick,=0A= >=0A= > On 6/24/2015 4:13 AM, Rick Taylor wrote:=0A= >> Can I say a big thank you to everyone who has given us feedback on DLEP-= 14.=0A= >>=0A= >> We are currently updating the draft, to integrate the comments we have.= =0A= >> With that in mind, can I ask for some patience and a moratorium on th= e=0A= >> topics of Versioning and Ids please?=0A= > I think I see the rough consensus that can be document on IDs, but I'm=0A= > not sure I've seen it on Versioning. Could you summarize the Versioning= =0A= > consensus that you'll be documenting?=0A= =0A= After much consideration, Stan and I have decided to go for the KISS =0A= solution (not white face-paint and platforms) and drop version numbers =0A= from the TCP session, and alter the Discovery signal. The reasons:=0A= =0A= 1) The current version data item has been criticised as non-trivial to =0A= parse.=0A= =0A= 2) We have a more flexible solution to managing changes and updates to =0A= the protocol than a monotonically increasing number, via the Extensions =0A= mechanism.=0A= =0A= 3) If a radical change to the protocol was required that broke the =0A= Extensions mechanism then it stops being DLEP, and becomes something =0A= else, and a new IANA multicast address/port registration is the cleanest = =0A= solution.=0A= =0A= 4) The discovery mechanism must allow peers to determine if the probes =0A= are DLEP discovery queries rather than anything else.=0A= =0A= 5) I do not see consensus on versioning from the recent discussions, so =0A= we are returning to the rough consensus of the last 4 years of DLEP =0A= design, where a granular extensions mechanism has been preferred over =0A= monolithic version changes.=0A= =0A= I know this will be contentious, but we need to make progress. Can I =0A= request that any comments on versioning use the following template: "I =0A= don't like this approach because it prevents my future enhancement from =0A= doing: X"? Otherwise we can continue to discuss each others personal =0A= preferences.=0A= =0A= To mis-quote The Matrix: "There is no version number..." - Just Extensions.= =0A= =0A= Rick.=0A= =0A= From nobody Thu Jun 25 04:27:41 2015 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 E83D81A1B18 for ; Thu, 25 Jun 2015 04:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 pHpCVPs9C9ZG for ; Thu, 25 Jun 2015 04:27:39 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id E68FF1B353C for ; Thu, 25 Jun 2015 04:27:38 -0700 (PDT) Received: (qmail 24957 invoked by uid 0); 25 Jun 2015 11:27:35 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 25 Jun 2015 11:27:35 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id khLL1q0072SSUrH01hLPyL; Thu, 25 Jun 2015 11:20:24 -0600 X-Authority-Analysis: v=2.1 cv=HpvlRSjS c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=T0NKIN4WI23cgSt3vsYA:9 a=Iv0h54wvL7c8YNKS:21 a=g4IX0205yLnISZ1U:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=9uYCZXeBTeAlhV3NvYDZLgvTQzjWLM6AvV93xPGDdzw=; b=h4Mt7bUx1tSZfh5E85zZIIK0ZfEpXS9XZZ989Px9z6pu0cyWJHaYMxcKU6O4Cvu6dOTyZanVRQVjUOEev8zhWCP7ICi+oI5kdu/D2POG23Ps3BMTM5bDUcwiGU/JE9JP; Received: from box313.bluehost.com ([69.89.31.113]:46354 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z85Jb-0001YP-Cs; Thu, 25 Jun 2015 05:27:31 -0600 Message-ID: <558BE59E.4070303@labn.net> Date: Thu, 25 Jun 2015 07:27:26 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rick Taylor , manet IETF References: <38A5475DE83986499AEACD2CFAFC3F98016C2B89FB@tss-server1.home.tropicalstormsoftware.com> <558AC3FF.9020704@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2BCF8F@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2BCF8F@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [manet] DLEP-14 comments 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 Jun 2015 11:27:40 -0000 Rick, Thanks for the summary. This approach resolves the issue I raised for TCP sessions. Is the same approach followed for UDP signals? Lou On 6/25/2015 6:53 AM, Rick Taylor wrote: > On 24/06/15 15:51, Lou Berger wrote: >> Rick, >> >> On 6/24/2015 4:13 AM, Rick Taylor wrote: >>> Can I say a big thank you to everyone who has given us feedback on DLEP-14. >>> >>> We are currently updating the draft, to integrate the comments we have. >>> With that in mind, can I ask for some patience and a moratorium on the >>> topics of Versioning and Ids please? >> I think I see the rough consensus that can be document on IDs, but I'm >> not sure I've seen it on Versioning. Could you summarize the Versioning >> consensus that you'll be documenting? > After much consideration, Stan and I have decided to go for the KISS > solution (not white face-paint and platforms) and drop version numbers > from the TCP session, and alter the Discovery signal. The reasons: > > 1) The current version data item has been criticised as non-trivial to > parse. > > 2) We have a more flexible solution to managing changes and updates to > the protocol than a monotonically increasing number, via the Extensions > mechanism. > > 3) If a radical change to the protocol was required that broke the > Extensions mechanism then it stops being DLEP, and becomes something > else, and a new IANA multicast address/port registration is the cleanest > solution. > > 4) The discovery mechanism must allow peers to determine if the probes > are DLEP discovery queries rather than anything else. > > 5) I do not see consensus on versioning from the recent discussions, so > we are returning to the rough consensus of the last 4 years of DLEP > design, where a granular extensions mechanism has been preferred over > monolithic version changes. > > I know this will be contentious, but we need to make progress. Can I > request that any comments on versioning use the following template: "I > don't like this approach because it prevents my future enhancement from > doing: X"? Otherwise we can continue to discuss each others personal > preferences. > > To mis-quote The Matrix: "There is no version number..." - Just Extensions. > > Rick. > > From nobody Thu Jun 25 05:39:58 2015 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 2389A1A1A16 for ; Thu, 25 Jun 2015 05:39:57 -0700 (PDT) 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 ehOk3LBd-574 for ; Thu, 25 Jun 2015 05:39:56 -0700 (PDT) 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 B65B51A1A0C for ; Thu, 25 Jun 2015 05:39:55 -0700 (PDT) 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, 25 Jun 2015 13:39:25 +0100 From: Rick Taylor To: Lou Berger , manet IETF Thread-Topic: [manet] DLEP-14 comments Thread-Index: AQHQro1S+WoBHcrUHUiRy2A0+PWP6Q== Date: Thu, 25 Jun 2015 12:39:24 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2BD47C@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016C2B89FB@tss-server1.home.tropicalstormsoftware.com> <558AC3FF.9020704@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2BCF8F@tss-server1.home.tropicalstormsoftware.com> <558BE59E.4070303@labn.net> 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: Subject: Re: [manet] DLEP-14 comments 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 Jun 2015 12:39:57 -0000 On 25/06/15 12:27, Lou Berger wrote:=0A= > Rick,=0A= > Thanks for the summary. This approach resolves the issue I raised= =0A= > for TCP sessions.=0A= =0A= Thank you for your support!=0A= =0A= >=0A= > Is the same approach followed for UDP signals?=0A= =0A= Is a very good question...=0A= =0A= We don't really need a signal header, as one type of packet is multicast = =0A= and the other unicast, so no type requirement, and given we are using =0A= UDP, we don't need another length field, and less octets is better for =0A= datagrams.=0A= =0A= So using my new skills in RFC-5511:=0A= =0A= ::=3D "DLEP"=0A= []=0A= =0A= ::=3D "DLEP"=0A= []=0A= ( | ) ...=0A= =0A= I have put in the "DLEP" literal as a discriminator for receivers, and =0A= so that there has to be at least something in the Discovery packet!=0A= =0A= The data item order doesn't matter, just the "DLEP" literal needs to be =0A= first.=0A= =0A= To differentiate between the UDP format and the TCP format, I am going =0A= to rename the TCP 'signals' to 'messages' to underline their difference =0A= (and transactional nature).=0A= =0A= Rick=0A= =0A= From nobody Thu Jun 25 06:11:03 2015 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 079401A87E6 for ; Thu, 25 Jun 2015 06:11:02 -0700 (PDT) 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 rkhy0wnzx09t for ; Thu, 25 Jun 2015 06:11:00 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id C69CF1A87D5 for ; Thu, 25 Jun 2015 06:10:59 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.203 as permitted sender) identity=mailfrom; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,677,1427774400"; d="scan'208";a="17763690" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.203]) by ironport.idirect.net with ESMTP; 25 Jun 2015 09:10:59 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM3.idirect.net (10.250.250.203) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 25 Jun 2015 09:10:58 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Thu, 25 Jun 2015 09:10:58 -0400 From: "Ratliff, Stanley" To: RJ Atkinson , "manet@ietf.org" Thread-Topic: [manet] DLEP-14: Credit Windowing (Section 9) Thread-Index: AQHQrrc8pHf2w+oXA02jpUrJUyM6k529Mj2Q Date: Thu, 25 Jun 2015 13:10:58 +0000 Message-ID: <160b67a67e864567b23300aaa9940536@VAUSDITCHM3.idirect.net> References: <220318AD-531B-4C42-A8B1-D2BD0BA3E89D@gmail.com> In-Reply-To: <220318AD-531B-4C42-A8B1-D2BD0BA3E89D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [manet] DLEP-14: Credit Windowing (Section 9) 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 Jun 2015 13:11:02 -0000 UmFuLA0KDQpUaGUgb3B0aW9uIG9mIHNwbGl0dGluZyB0aGUgQ3JlZGl0IEV4dGVuc2lvbnMgb3V0 IGludG8gYSBzZXBhcmF0ZSBkb2N1bWVudCB3YXMgdGhvcm91Z2hseSBkaXNjdXNzZWQsIGJvdGgg b24tbGlzdCwgYW5kIGluIHRoZSBETEVQIGRlc2lnbiB0ZWFtLiBUaGUgRFQgY2xvc2VkIHdvcmsg YXQgSUVURiA4OSAoTG9uZG9uKSwgcmVhY2hpbmcgY29uc2Vuc3VzIG9uIHRoaXMgYW5kIG90aGVy IGlzc3Vlcy4gVGhlIGNvbnNlbnN1cyB3YXMgdG8gbGVhdmUgdGhlIENyZWRpdCBXaW5kb3dpbmcg ZGVzY3JpcHRpb25zIGluIHRoZSAiY29yZSIgZG9jdW1lbnQuIE5vIGNvbnRyYXJ5IG9waW5pb25z IHdlcmUgZXhwcmVzc2VkIG9uLWxpc3QsIHVudGlsIG5vdy4gDQoNClNvIGF0IHRoaXMgcG9pbnQs IHdpdGggdGhlIHNwZWMgaGF2aW5nIGFscmVhZHkgY2xlYXJlZCBXR0xDLCB3ZSdyZSBnb2luZyB0 byBsZWF2ZSBDcmVkaXQgRXh0ZW5zaW9ucyBpbiB0aGUgYmFzZSBkb2MuIA0KDQpSZWdhcmRzLA0K U3Rhbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1hbmV0IFttYWls dG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJKIEF0a2luc29uDQo+IFNl bnQ6IFdlZG5lc2RheSwgSnVuZSAyNCwgMjAxNSAzOjUyIFBNDQo+IFRvOiBtYW5ldEBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBbbWFuZXRdIERMRVAtMTQ6IENyZWRpdCBXaW5kb3dpbmcgKFNlY3Rpb24g OSkNCj4gDQo+IA0KPiBIaSwNCj4gDQo+ICAgRmlyc3QsIEkgYW0gYSBiaWcgZmFuIG9mIHRoZSBD cmVkaXQgV2luZG93aW5nIG1lY2hhbmlzbSBjdXJyZW50bHkgc3BlY2lmaWVkDQo+IGFzIOKAnG9w dGlvbmFs4oCdIGluIFNlY3Rpb24gOS4NCj4gDQo+ICAgSSB0aGluayBpdCB3b3VsZCBiZSBoZWxw ZnVsIGlmIHRoYXQgd2VyZSBwdWxsZWQgb3V0IG9mIHRoZSBETEVQIGJhc2UNCj4gc3BlY2lmaWNh dGlvbiBhbmQgaW50byBhIHNlcGFyYXRlIEktRCwgd2l0aCBldmVyeSBpbnRlbnRpb24gdGhhdCBi b3RoIGRyYWZ0cw0KPiB3b3VsZCBwcm9ncmVzcyB0b2dldGhlci4NCj4gDQo+ICAgRG9pbmcgc28g d291bGQgbWFrZSBETEVQLTE1IGp1c3QgdGhlIG1hbmRhdG9yeSBpdGVtcyBhbmQgbWFuZGF0b3J5 DQo+IGNhcGFiaWxpdGllcywgYnV0IHdvdWxkIHJldGFpbiB0aGUgQ3JlZGl0LVdpbmRvd2luZyBj YXBhYmlsaXR5IGluIGl0cyBvd24NCj4gZm9jdXNlZCwgc21hbGxlciwgZG9jdW1lbnQgd2l0aCBh biBleHBsaWNpdCByZXF1aXJlbWVudCB0aGF0IGFueXRoaW5nDQo+IGNsYWltaW5nIHRvIGltcGxl bWVudCB0aGlzIHNlcGFyYXRlIENyZWRpdC1XaW5kb3dpbmcgZG9jdW1lbnQgTVVTVCBkbw0KPiB0 aGUgd2hvbGUgQ3JlZGl0LVdpbmRvd2luZyBjYXBhYmlsaXR5IGFzIHBlciB0aGF0IFJGQy10by1i ZS4NCj4gDQo+ICAgVGhpcyBzZXBhcmF0aW9uIGFwcHJvYWNoIGFsc28gd291bGQgbWFrZSBpdCBz aW1wbGVyIChtb3JlIGNsZWFyKSB3aGV0aGVyIGENCj4gcGFydGljdWxhciBETEVQLWNhcGFibGUg cHJvZHVjdCBzdXBwb3J0ZWQgdGhhdCBDcmVkaXQtV2luZG93aW5nIGNhcGFiaWxpdHkuDQo+IElm IGEgdXNlciB3YW50ZWQgdGhhdCBjYXBhYmlsaXR5LCB0aGV5IGNvdWxkIHNheSB0aGF0IHRoZXkg d2FudCBhIHdpZGdldCB0aGF0DQo+IG5vdCBvbmx5IGltcGxlbWVudHMgUkZDLURMRVAtQmFzZS1T cGVjIGJ1dCBhbHNvIGltcGxlbWVudHMgUkZDLURMRVAtDQo+IENyZWRpdC1XaW5kb3dpbmcuDQo+ IEltcGxlbWVudGVycyBvZiBib3RoIGNvdWxkIGhhdmUgYm90aCBSRkNzIGxpc3RlZCBvbiB0aGVp ciBkYXRhIHNoZWV0cy4NCj4gDQo+ICAgVGhlIG90aGVyIGJlbmVmaXQgaXMgdGhhdCB0aGUgRExF UCBiYXNlIHNwZWNpZmljYXRpb24gd291bGQgYmUgc2hvcnRlciBzbw0KPiB0aGF0IHNvbWVvbmUg Zmlyc3QgY29taW5nIHVwIHRvIHNwZWVkIG9uIGJhc2ljIERMRVAgY291bGQgZG8gc28gbW9yZQ0K PiBxdWlja2x5Lg0KPiANCj4gVGhhbmtzLA0KPiANCj4gUmFuDQo+IA0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbWFuZXQgbWFpbGluZyBs aXN0DQo+IG1hbmV0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWFuZXQNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBhbmQgYW55IGZpbGVzIHRyYW5zbWl0 dGVkIHdpdGggaXQgY29udGFpbnMKaW5mb3JtYXRpb24gZnJvbSBpRGlyZWN0LCB3aGljaCBtYXkg YmUgcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnkKYW5kL29yIGNvbmZpZGVudGlhbC4gSXQgaXMgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsCm9yIGVudGl0eSB0byB3 aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIG9yaWdpbmFsCnJlY2lw aWVudCBvciB0aGUgcGVyc29uIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRoZSBlbWFpbCB0 byB0aGUKaW50ZW5kZWQgcmVjaXBpZW50LCBiZSBhZHZpc2VkIHRoYXQgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbAppbiBlcnJvciwgYW5kIHRoYXQgYW55IHVzZSwgZGlzc2VtaW5hdGlvbiwg Zm9yd2FyZGluZywgcHJpbnRpbmcsIG9yCmNvcHlpbmcgb2YgdGhpcyBlbWFpbCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBlbWFpbAppbiBlcnJvciwgcGxlYXNl IGRlbGV0ZSBpdCBhbmQgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIuCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCg== From nobody Thu Jun 25 06:16:03 2015 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 39E101A878B for ; Thu, 25 Jun 2015 06:16:02 -0700 (PDT) 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 Xjl9kfB9YFvh for ; Thu, 25 Jun 2015 06:16:01 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6D51A1B5F for ; Thu, 25 Jun 2015 06:16:00 -0700 (PDT) Received: by ykfy125 with SMTP id y125so40269678ykf.1 for ; Thu, 25 Jun 2015 06:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=140Le+Lmr5HI60rN4i5Msct1fiY47qpR8qNvH1N4CyA=; b=Al+M19Cpd1dZ3psWdD/KYc2M+zJ5ANNjoZ7s+INPirP3XLVIDxrIIpWYsMsFmKMrIp kt9BFkQ14Ux38wZoqGYzR0ud9JaUCYkUvEBeX5ZyHbHYO1PP7OXfr6pRkHwEwKXlllg4 gR2oFtg3wnH0prTQkztFc/mhTFpMm+bI2IraqqqBbwi9onydlT5LXlIVWlceH3q8hcCX TSDWF3UdJWwskEz1L8MdO1K2mOavQcy2wjUisHiDzV8MqBokLEszB369SXIUOCqB8zkz ZXGvLa8oqFEVAn7zM+VPySjYFSJ20CJqRzZXV5xEt7iRQxeOuFxfvoGNAhAfhcOCbxhD dzNw== X-Received: by 10.170.87.134 with SMTP id e128mr54624325yka.109.1435238160211; Thu, 25 Jun 2015 06:16:00 -0700 (PDT) Received: from [10.30.20.16] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id k8sm12640959yha.18.2015.06.25.06.15.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jun 2015 06:15:59 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: RJ Atkinson In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2BCB66@tss-server1.home.tropicalstormsoftware.com> Date: Thu, 25 Jun 2015 09:15:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38A5475DE83986499AEACD2CFAFC3F98016C2BCB66@tss-server1.home.tropicalstormsoftware.com> To: manet@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [manet] DLEP-14: Terminology 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 Jun 2015 13:16:02 -0000 > On 25 Jun 2015, at 05:25 , Rick Taylor = wrote: >=20 > I must admit that I'm with Henning on this one. >=20 > A DLEP Extension is exactly that: a (Standardized) Extension to DLEP. >=20 > Rick >=20 > On 25/06/15 07:18, Henning Rogge wrote: >> On Wed, Jun 24, 2015 at 9:45 PM, RJ Atkinson = wrote: >>> (ASIDE: In this and any other near-term posts I am changing >>> the SUBJECT line(s) of the email to try to separate out >>> different conversation threads to reduce potential for confusion.) >>>=20 >>> In common IETF terminology, =93extension=94 or =93extensions=94 can >>> refer to any proposed addition to an IETF protocol, such as >>> an additional Data Item or an additional Signal. >>=20 >> A DLEP extension is exactly that... a group of (standardized) >> additional signals/data-items. The "extension TLV" is just the way to >> tell the other side "hey, I am supporting this extension!" >>=20 >> Henning Rogge Hi, In general, considering IETF protocols, the new Data Item(s) and/or=20 the new Signal(s) are most commonly considered to be the actual=20 extensions to the specification. The so-called =93Extensions=94 field is really a mechanism to indicate a=20= set of new Data Item(s) and/or new Signal(s) that an implementation=20 is capable of supporting. Regardless, the current terminology is, in practice and as shown during recent list discussions, confusing. =20 Can we please find a more clear term ? =20 If folks don=92t like =93Capability Set=94, then maybe =93Extensions = Set=94 or =93Extensions Label=94 (or pick some other term that folks do like=20 that also will be more clear to a random reader/implementer in future=20 =97 someone who has not participated in the MANET WG discussions) ? Thanks, Ran From nobody Thu Jun 25 06:22:51 2015 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 787831A8844 for ; Thu, 25 Jun 2015 06:22:50 -0700 (PDT) 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 e3buc7p_lhdr for ; Thu, 25 Jun 2015 06:22:49 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (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 179801A883D for ; Thu, 25 Jun 2015 06:22:24 -0700 (PDT) Received: by yhpn97 with SMTP id n97so29512224yhp.0 for ; Thu, 25 Jun 2015 06:22:23 -0700 (PDT) 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 :content-transfer-encoding:message-id:references:to; bh=nNO78lW/M47+DymaV6CPgIevOd5QaUrqoxMwT4lik4A=; b=uAvP+zZ7dxW5rqPoA0P6aGz/DvCV553yVeUefRxjlrKvQFg8eIMJOvZ3/LdzG9oOI+ VbusM5t8BUpWePwvmTKrojfybiuETCqhEQBLAwfdw8V4kWm5tquagMiOrnfZKnNlozrt KwQagDZm/I2OmzgLkZaCVKLXcMW6+TzonmD5CUJU2jSeULHOHJFmaGKUR7zDeJ8NvbMf kK/3ojnumgLXVDajZlV1fammuw9ar92J8J0JhASBGyByWAU3bFv4LT1w8A575ydDkQwH URbP5MYKmPXCMeO9dJ3jRaPVVrUY42OJh5lNOdFUNHcgBU4hXUGN0X3Ym9ciA9+8r9+i Hd6w== X-Received: by 10.170.48.134 with SMTP id 128mr54904547ykq.36.1435238543472; Thu, 25 Jun 2015 06:22:23 -0700 (PDT) Received: from [10.30.20.16] (pool-108-31-161-77.washdc.fios.verizon.net. [108.31.161.77]) by mx.google.com with ESMTPSA id h135sm23333343ywc.4.2015.06.25.06.22.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jun 2015 06:22:23 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset=utf-8 From: RJ Atkinson In-Reply-To: <160b67a67e864567b23300aaa9940536@VAUSDITCHM3.idirect.net> Date: Thu, 25 Jun 2015 09:22:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <220318AD-531B-4C42-A8B1-D2BD0BA3E89D@gmail.com> <160b67a67e864567b23300aaa9940536@VAUSDITCHM3.idirect.net> To: "Ratliff, Stanley" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-14: Credit Windowing (Section 9) 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 Jun 2015 13:22:50 -0000 > On 25 Jun 2015, at 09:10 , Ratliff, Stanley = wrote: >=20 > The option of splitting the Credit Extensions out into a separate = document was thoroughly discussed, both on-list, and in the DLEP design = team. The DT closed work at IETF 89 (London), reaching consensus on this = and other issues. Stan, - Design Teams do not get to make decisions for WGs. - Design Teams propose items to a WG for WG review. - So the Design Team discussion above is a bit of a Red Herring, from an IETF process perspective. Further, in-person meetings are SECONDARY to on-list discussion. For example, any potential consensus item in an in-person meeting needs to be confirmed via the WG mailing list. > The consensus was to leave the Credit Windowing descriptions > in the "core" document. No contrary opinions were expressed on-list, > until now.=20 Maybe so. Now there are other opinions, so we should have the discussion again. I provided concrete reasoning in my proposal,=20 which reasoning no one has disagreed with in any technical terms. Note that in any case, I very much want the Credit-Windowing capability to move forward in parallel with the DLEP base spec. > So at this point, with the spec having already cleared WGLC, > we're going to leave Credit Extensions in the base doc.=20 We either can discuss it again now here or we can discuss it=20 again in future during IETF Last Call. =20 =46rom an IETF process perspective, the DLEP-14 document very clearly=20= needs a revision =E2=80=94 and that revision will need another WG Last = Call=20 regardless of this issue. It will reduce time to RFC if we have that discussion here and now. Cheers, Ran From nobody Thu Jun 25 07:04:32 2015 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 7D1931A8905 for ; Thu, 25 Jun 2015 07:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 mWX13gl5Olro for ; Thu, 25 Jun 2015 07:04:30 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (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 A5CB61A8937 for ; Thu, 25 Jun 2015 07:04:29 -0700 (PDT) Received: by wgck11 with SMTP id k11so63691313wgc.0 for ; Thu, 25 Jun 2015 07:04:28 -0700 (PDT) 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=/R459uuGYdXWyM1iwu2RoQ+nsmpg8SizivSECQCtt8A=; b=r9gYQb9y9a3m+lNrleLEnbmk1vBfXq4zvFCwa1EvryABqxWM5vARRDNAeOZlOEOu/E g3qpWx+tssiLjkHkkFOdBo4kLbdbmyyltonJeW1Y8EkpawtjEijNpXIkfi0V5c9EG6xw pJsjxbnEP1z5YbY+ZCBfr3mWnZgbXxx9n1oX0ggH2MyqSW+Y3mrY4kKWV3OLi58T1b/e tzfn5j/waM0EN7hraN5tdtMFKffe8tjaF2Yq2iwu5S+gpURaAZ8p4idU1WJH9b0YqZvQ IHqcKAin2Z/MILj7/WJ9wc5uZYXZ3xWNUvyyJv97FpMUTuEn+NjQb5lIF9J9aPVFTqvO WvuA== X-Received: by 10.180.86.234 with SMTP id s10mr5933995wiz.50.1435240646576; Thu, 25 Jun 2015 06:57:26 -0700 (PDT) Received: from [10.0.4.178] ([217.158.48.187]) by mx.google.com with ESMTPSA id lu5sm45844878wjb.9.2015.06.25.06.57.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 06:57:25 -0700 (PDT) Message-ID: <558C08C4.3050907@gmail.com> Date: Thu, 25 Jun 2015 14:57:24 +0100 From: John Dowdell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: manet@ietf.org References: <220318AD-531B-4C42-A8B1-D2BD0BA3E89D@gmail.com> <160b67a67e864567b23300aaa9940536@VAUSDITCHM3.idirect.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [manet] DLEP-14: Credit Windowing (Section 9) 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 Jun 2015 14:04:31 -0000 On 25/06/15 14:22, RJ Atkinson wrote: >> On 25 Jun 2015, at 09:10 , Ratliff, Stanley wrote: >> >> The option of splitting the Credit Extensions out into a separate document was thoroughly discussed, both on-list, and in the DLEP design team. The DT closed work at IETF 89 (London), reaching consensus on this and other issues. > Stan, > > - Design Teams do not get to make decisions for WGs. > - Design Teams propose items to a WG for WG review. > - So the Design Team discussion above is a bit of a Red Herring, > from an IETF process perspective. Ran, I've only been at IETF meetings for a few years, and was a member of the design team for DLEP. Your comments are noted, but I've never actually seen a working group take a decision in the way that a business project team would. In practice, working group members either seem to care or not, and if they care they usually seem to post regularly on the topic, or are invited to become part of a design or author team. The design team in this case was a group of individuals who had all regularly posted to the list on this topic for a good two years prior to the formation of the DT. Despite asking frequently, both on-list and off-list, including radio manufacturers and system integrators that I would occasionally meet, few other opinions were ever expressed on-list. Many members of the design team have implementations, which yielded valuable experience in what worked and what didn't, and this went back into the draft. We're now four and a half years since draft-00. I know there are major organisations waiting for DLEP to get finished so they can inform their own strategies and development cycles, and for that they need a stable and implementable specification that those of us who have a stake in this protocol can agree on. I don't for a second dispute your right to make suggestions or propose text or provide review based on implementation experience with this or a similar protocol, but those who do care about this draft have lived and breathed it for at least the four and a half years it has already existed. I would just ask you to consider your comments in the light of this situation. John From nobody Thu Jun 25 07:24:10 2015 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 BC11D1A896E for ; Thu, 25 Jun 2015 07:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 qYuZlLvs1q28 for ; Thu, 25 Jun 2015 07:24:08 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id DB1EF1A896C for ; Thu, 25 Jun 2015 07:24:07 -0700 (PDT) Received: (qmail 5879 invoked by uid 0); 25 Jun 2015 14:24:05 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 25 Jun 2015 14:24:05 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id keDR1q00R2SSUrH01eDUes; Thu, 25 Jun 2015 08:13:44 -0600 X-Authority-Analysis: v=2.1 cv=ALgDonD0 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=ew7u_023nkb77jha0_MA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=eufKEtcebp9Fdtnx8KZo32TbObVY6IdktfkYmdhJnHc=; b=kdSAGKSVBv+J0hO3OXObb7NTv2hy5hAVimYHyBmZcUg0YfYIIKykMA+rPpMLliiVph94M5eU0/jVuDdzf5Oz+55PgRmZP1FafwO4abFPVN620dZv52iAoZP6lS0cha2K; Received: from box313.bluehost.com ([69.89.31.113]:55564 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z884A-00065Y-5Z; Thu, 25 Jun 2015 08:23:46 -0600 Message-ID: <558C0EEB.4060105@labn.net> Date: Thu, 25 Jun 2015 10:23:39 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rick Taylor , manet IETF References: <38A5475DE83986499AEACD2CFAFC3F98016C2B89FB@tss-server1.home.tropicalstormsoftware.com> <558AC3FF.9020704@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2BCF8F@tss-server1.home.tropicalstormsoftware.com> <558BE59E.4070303@labn.net> <38A5475DE83986499AEACD2CFAFC3F98016C2BD47C@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016C2BD47C@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [manet] DLEP-14 comments 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 Jun 2015 14:24:08 -0000 Hi Rick, On 6/25/2015 8:39 AM, Rick Taylor wrote: > On 25/06/15 12:27, Lou Berger wrote: >> Rick, >> Thanks for the summary. This approach resolves the issue I raised >> for TCP sessions. > Thank you for your support! Sure - although to be clear I wasn't endorsing this as the "right" answer -- I don' have enough of a vested interest in DLEP to make such an endorsement -- but rather as "an answer" that resolves the issue. >> Is the same approach followed for UDP signals? > Is a very good question... > > We don't really need a signal header, as one type of packet is multicast > and the other unicast, so no type requirement, and given we are using > UDP, we don't need another length field, and less octets is better for > datagrams. > > So using my new skills in RFC-5511: > > ::= "DLEP" > [] > > ::= "DLEP" > [] > ( | ) ... > > I have put in the "DLEP" literal as a discriminator for receivers, and > so that there has to be at least something in the Discovery packet! Based on the current rev I think you have: ::= [] ::= [] [ ... ] [ ... ] Yes, this allows both v4 and v6 in the same message, but that's how I read what -14 says. > > The data item order doesn't matter, just the "DLEP" literal needs to be > first. > > To differentiate between the UDP format and the TCP format, I am going > to rename the TCP 'signals' to 'messages' to underline their difference > (and transactional nature). okay. Thanks, Lou > > Rick > > From nobody Thu Jun 25 07:28:36 2015 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 CA5F11A897E for ; Thu, 25 Jun 2015 07:28:34 -0700 (PDT) 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 swqbukPuZJAJ for ; Thu, 25 Jun 2015 07:28:32 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 5CEF71A897C for ; Thu, 25 Jun 2015 07:28:32 -0700 (PDT) Received: by oigb199 with SMTP id b199so53676275oig.3 for ; Thu, 25 Jun 2015 07:28:31 -0700 (PDT) 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=kdT31OgCOnAikKOKoX8pFjTQq8UfrLS3nXZ7wrN8/Qw=; b=bw+y4eich0GHCQLHhbuoPkHWYU8cqKxtJ5uT39YSBUzO9DQZ+lJqyGkV5ieuCT3fZf PMzWFvZiSvh+vyUWo6jpzw3ClG06TiOwUbKEQXcukpzueSuLgufyw8fZJT/OkSR34s9K 7kFq0OcaAf6HQFU6x3xOzoM+MUacsIz2IiWW5KSesrrSHW12+OFu9oGIlkRjijduyPdm QI89wcVty3Jyg1xG38sLofwrpyl47obCdZZd1iruNEA3bf3oFtkR7dh9TmDS03E0OkKh HjIZth9+zxIDsedeG6Xa63M2O43nezvsgL9YybdVkoOjQ3A7NiO03yUx57mknZUdTqi+ GnPg== MIME-Version: 1.0 X-Received: by 10.202.75.2 with SMTP id y2mr7788000oia.44.1435242511822; Thu, 25 Jun 2015 07:28:31 -0700 (PDT) Received: by 10.202.195.134 with HTTP; Thu, 25 Jun 2015 07:28:31 -0700 (PDT) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F98016C2BCB66@tss-server1.home.tropicalstormsoftware.com> Date: Thu, 25 Jun 2015 10:28:31 -0400 Message-ID: From: Justin Dean To: RJ Atkinson Content-Type: multipart/alternative; boundary=001a113e3db81575e905195870a5 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-14: Terminology 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 Jun 2015 14:28:35 -0000 --001a113e3db81575e905195870a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >> A DLEP extension is exactly that... a group of (standardized) >> additional signals/data-items. The "extension TLV" is just the way to >> tell the other side "hey, I am supporting this extension!" >> >> Henning Rogge "Extension Set Supported" vs "Extensions Supported" seems like a nit of a issue and not really an issue either way. Although Extension Set does seem a tad clearer to me. To the root of the issue can be cleaned up with a bit more clarity for section 8.7 The Extensions Supported data item MAY be used in both the Peer Initialization and Peer Initialization ACK signals. The Extensions Supported data item is used by the router and modem to negotiate *additional optional functionality* they are willing to support. The Extensions List is a concatenation of the types of each supported extension, found in the IANA DLEP Extensions repository. to The Extensions Supported data item MAY be used in both the Peer Initialization and Peer Initialization ACK signals. The Extensions Supported data item is used by the router and modem to negotiate additional optional functionality they are willing to support. The Extensions List is a concatenation of Extension Types, defined in the IANA DLEP Extensions repository. Each Extension Type definition includes which additional signals and data-items are supported. On Thu, Jun 25, 2015 at 9:15 AM, RJ Atkinson wrote: > > > On 25 Jun 2015, at 05:25 , Rick Taylor > wrote: > > > > I must admit that I'm with Henning on this one. > > > > A DLEP Extension is exactly that: a (Standardized) Extension to DLEP. > > > > Rick > > > > On 25/06/15 07:18, Henning Rogge wrote: > >> On Wed, Jun 24, 2015 at 9:45 PM, RJ Atkinson > wrote: > >>> (ASIDE: In this and any other near-term posts I am changing > >>> the SUBJECT line(s) of the email to try to separate out > >>> different conversation threads to reduce potential for confusion.) > >>> > >>> In common IETF terminology, =E2=80=9Cextension=E2=80=9D or =E2=80=9Ce= xtensions=E2=80=9D can > >>> refer to any proposed addition to an IETF protocol, such as > >>> an additional Data Item or an additional Signal. > >> > >> A DLEP extension is exactly that... a group of (standardized) > >> additional signals/data-items. The "extension TLV" is just the way to > >> tell the other side "hey, I am supporting this extension!" > >> > >> Henning Rogge > > Hi, > > In general, considering IETF protocols, the new Data Item(s) and/or > the new Signal(s) are most commonly considered to be the actual > extensions to the specification. > > The so-called =E2=80=9CExtensions=E2=80=9D field is really a mechanism to= indicate a > set of new Data Item(s) and/or new Signal(s) that an implementation > is capable of supporting. > > Regardless, the current terminology is, in practice and as shown during > recent list discussions, confusing. > > Can we please find a more clear term ? > > If folks don=E2=80=99t like =E2=80=9CCapability Set=E2=80=9D, then maybe = =E2=80=9CExtensions Set=E2=80=9D > or =E2=80=9CExtensions Label=E2=80=9D (or pick some other term that folks= do like > that also will be more clear to a random reader/implementer in future > =E2=80=94 someone who has not participated in the MANET WG discussions) ? > > Thanks, > > Ran > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a113e3db81575e905195870a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>> A DLEP ext= ension is exactly that... a group of (standardized)
>> additional signals/data-items. The "extension TLV" is ju= st the way to
>> tell the other side "hey, I am supporting this extension!&quo= t;
>>
>> Henning Rogge

"Extension Set Support= ed" vs "Extensions Supported" seems like a nit of a issue an= d not really an issue either way.=C2=A0 Although Extension Set does seem a = tad clearer to me.
To the root of the issue can be cleaned up= with a bit more clarity for section 8.7

The Extensions Supported da= ta item MAY be used in both the Peer
=C2=A0=C2=A0 Initialization and Pee= r Initialization ACK signals.=C2=A0 The Extensions
=C2=A0=C2=A0 Supporte= d data item is used by the router and modem to negotiate
=C2=A0=C2=A0 additional optional functionality they are willing to support.=C2=A0 T= he
=C2=A0=C2=A0 Extensions List is a concatenation of the types of each = supported
=C2=A0=C2=A0 extension, found in the IANA DLEP Extensions repo= sitory.

to

The Extensions Supported data i= tem MAY be used in both the Peer
=C2=A0=C2=A0 Initialization and Peer In= itialization ACK signals.=C2=A0 The Extensions
=C2=A0=C2=A0 Supported da= ta item is used by the router and modem to negotiate
=C2=A0=C2=A0 additional optional functionality they are willing to support.=C2=A0 The=C2=A0=C2=A0 Extensions List is a concatenation of Extension Types, defin= ed in
=C2=A0=C2=A0 the IANA DLEP Extensions repository.=C2=A0 Each Exte= nsion Type
=C2=A0=C2=A0 definition includes which additional signals an= d data-items are supported.

On Thu, Jun 25, 2015 at 9:15 AM, = RJ Atkinson <rja.lists@gmail.com> wrote:

> On 25=C2=A0 Jun 2015, at 05:25 , Rick Taylor <rick@tropicalstormsoftware.com> wrote:<= br> >
> I must admit that I'm with Henning on this one.
>
> A DLEP Extension is exactly that: a (Standardized) Extension to DLEP.<= br> >
> Rick
>
> On 25/06/15 07:18, Henning Rogge wrote:
>> On Wed, Jun 24, 2015 at 9:45 PM, RJ Atkinson <rja.lists@gmail.com> wrote:
>>> (ASIDE:=C2=A0 In this and any other near-term posts I am chang= ing
>>> the SUBJECT line(s) of the email to try to separate out
>>> different conversation threads to reduce potential for confusi= on.)
>>>
>>> In common IETF terminology, =E2=80=9Cextension=E2=80=9D or =E2= =80=9Cextensions=E2=80=9D can
>>> refer to any proposed addition to an IETF protocol, such as >>> an additional Data Item or an additional Signal.
>>
>> A DLEP extension is exactly that... a group of (standardized)
>> additional signals/data-items. The "extension TLV" is ju= st the way to
>> tell the other side "hey, I am supporting this extension!&quo= t;
>>
>> Henning Rogge

Hi,

In general, considering IETF protocols, the new Data Item(s) and/or
the new Signal(s) are most commonly considered to be the actual
extensions to the specification.

The so-called =E2=80=9CExtensions=E2=80=9D field is really a mechanism to i= ndicate a
set of new Data Item(s) and/or new Signal(s) that an implementation
is capable of supporting.

Regardless, the current terminology is, in practice and as shown during
recent list discussions, confusing.

Can we please find a more clear term ?

If folks don=E2=80=99t like =E2=80=9CCapability Set=E2=80=9D, then maybe = =E2=80=9CExtensions Set=E2=80=9D
or =E2=80=9CExtensions Label=E2=80=9D (or pick some other term that folks d= o like
that also will be more clear to a random reader/implementer in future
=E2=80=94 someone who has not participated in the MANET WG discussions) ?
Thanks,

Ran

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

--001a113e3db81575e905195870a5-- From nobody Thu Jun 25 07:42:21 2015 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 4CEFC1A89E1 for ; Thu, 25 Jun 2015 07:42:20 -0700 (PDT) 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 HweejVYzbLGi for ; Thu, 25 Jun 2015 07:42:18 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 1F39A1A89C6 for ; Thu, 25 Jun 2015 07:42:17 -0700 (PDT) Received: by oigb199 with SMTP id b199so53998392oig.3 for ; Thu, 25 Jun 2015 07:42:16 -0700 (PDT) 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=3f8qSXePyn3w0+MShWtpahmhxbhwAVCvOyf0u1alQ64=; b=GRcnFiQQJCSMmjZqQFVjWdZgZzKf6BV33oMRsf/eqwZraQiLCVmmlmyO2hNIFqXdV8 OoiBFjqEgQs17FJ7m85hY2Hn9qOZhbjIuubgR58Cs0dM9Sr8dRSgQWHpum8wPuIMvsCo lHPK5zKsI1A8OtAvgk4pzIcxlRQMed1VmObebyMpJFPkqNi7pDbwawG6zwTaqZ3DZLFM GWFcbvvVigbRk3z5dcpMACV+mdgKttA79DDAdccOTfghdCVkyaXcotE00Oz7cDEf/A33 ++k+RT7jqG3c/M+jovMNDxLDfEKRNYmMOKUhK24aw/+W35oH2MOALsMUtfa6dJRkuibr Scdg== MIME-Version: 1.0 X-Received: by 10.60.56.97 with SMTP id z1mr40306963oep.59.1435243336594; Thu, 25 Jun 2015 07:42:16 -0700 (PDT) Received: by 10.202.195.134 with HTTP; Thu, 25 Jun 2015 07:42:16 -0700 (PDT) In-Reply-To: <558C08C4.3050907@gmail.com> References: <220318AD-531B-4C42-A8B1-D2BD0BA3E89D@gmail.com> <160b67a67e864567b23300aaa9940536@VAUSDITCHM3.idirect.net> <558C08C4.3050907@gmail.com> Date: Thu, 25 Jun 2015 10:42:16 -0400 Message-ID: From: Justin Dean To: John Dowdell Content-Type: multipart/alternative; boundary=001a11c204fa3e7a14051958a1ef Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-14: Credit Windowing (Section 9) 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 Jun 2015 14:42:20 -0000 --001a11c204fa3e7a14051958a1ef Content-Type: text/plain; charset=UTF-8 I'm going to +1 for keeping it as one draft. I see merit in breaking it up into two (and that may still happen) but I also see the value in having it within a single draft. It allows reading DLEP for the first time to see how to go about writing an extension without having to know about another draft RFC. We did something similar for SMF and it worked well there too. Unless there is further comments on list supporting breaking the document up I don't think rough WG consensus has changed on this issue just become more rough. Others please comment one way or another as the editor team is working hard to rev the document and assuming consensus isn't nearly as good as knowing. Justin Dean On Thu, Jun 25, 2015 at 9:57 AM, John Dowdell wrote: > > > On 25/06/15 14:22, RJ Atkinson wrote: > >> On 25 Jun 2015, at 09:10 , Ratliff, Stanley >>> wrote: >>> >>> The option of splitting the Credit Extensions out into a separate >>> document was thoroughly discussed, both on-list, and in the DLEP design >>> team. The DT closed work at IETF 89 (London), reaching consensus on this >>> and other issues. >>> >> Stan, >> >> - Design Teams do not get to make decisions for WGs. >> - Design Teams propose items to a WG for WG review. >> - So the Design Team discussion above is a bit of a Red Herring, >> from an IETF process perspective. >> > Ran, > > I've only been at IETF meetings for a few years, and was a member of the > design team for DLEP. Your comments are noted, but I've never actually seen > a working group take a decision in the way that a business project team > would. In practice, working group members either seem to care or not, and > if they care they usually seem to post regularly on the topic, or are > invited to become part of a design or author team. > > The design team in this case was a group of individuals who had all > regularly posted to the list on this topic for a good two years prior to > the formation of the DT. Despite asking frequently, both on-list and > off-list, including radio manufacturers and system integrators that I would > occasionally meet, few other opinions were ever expressed on-list. Many > members of the design team have implementations, which yielded valuable > experience in what worked and what didn't, and this went back into the > draft. We're now four and a half years since draft-00. I know there are > major organisations waiting for DLEP to get finished so they can inform > their own strategies and development cycles, and for that they need a > stable and implementable specification that those of us who have a stake in > this protocol can agree on. > > I don't for a second dispute your right to make suggestions or propose > text or provide review based on implementation experience with this or a > similar protocol, but those who do care about this draft have lived and > breathed it for at least the four and a half years it has already existed. > I would just ask you to consider your comments in the light of this > situation. > > John > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c204fa3e7a14051958a1ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm going to +1 for keeping it as one draft.=C2= =A0 I see merit in breaking it up into two (and that may still happen) but = I also see the value in having it within a single draft.=C2=A0 It allows re= ading DLEP for the first time to see how to go about writing an extension w= ithout having to know about another draft RFC.=C2=A0 We did something simil= ar for SMF and it worked well there too.=C2=A0 Unless there is further comm= ents on list supporting breaking the document up I don't think rough WG= consensus has changed on this issue just become more rough.=C2=A0

= Others please comment one way or another as the editor team is working hard= to rev the document and assuming consensus isn't nearly as good as kno= wing.

Justin Dean

On Thu, Jun 25, 2015 at 9:57 AM, John Dowdell <john.dowdell.ietf@gmail.com> wrote:


On 25/06/15 14:22, RJ Atkinson wrote:
On 25=C2=A0 Jun 2015, at 09:10 , Ratliff, Stanley <sratliff@idirect.net> wrote:
The option of splitting the Credit Extensions out into a separate document = was thoroughly discussed, both on-list, and in the DLEP design team. The DT= closed work at IETF 89 (London), reaching consensus on this and other issu= es.
Stan,

- Design Teams do not get to make decisions for WGs.
- Design Teams propose items to a WG for WG review.
- So the Design Team discussion above is a bit of a Red Herring,
=C2=A0 =C2=A0from an IETF process perspective.
 Ran,

I've only been at IETF meetings for a few years, and was a member of th= e design team for DLEP. Your comments are noted, but I've never actuall= y seen a working group take a decision in the way that a business project t= eam would. In practice, working group members either seem to care or not, a= nd if they care they usually seem to post regularly on the topic, or are in= vited to become part of a design or author team.

The design team in this case was a group of individuals who had all regular= ly posted to the list on this topic for a good two years prior to the forma= tion of the DT. Despite asking frequently, both on-list and off-list, inclu= ding radio manufacturers and system integrators that I would occasionally m= eet, few other opinions were ever expressed on-list. Many members of the de= sign team have implementations, which yielded valuable experience in what w= orked and what didn't, and this went back into the draft. We're now= four and a half years since draft-00. I know there are major organisations= waiting for DLEP to get finished so they can inform their own strategies a= nd development cycles, and for that they need a stable and implementable sp= ecification that those of us who have a stake in this protocol can agree on= .

I don't for a second dispute your right to make suggestions or propose = text or provide review based on implementation experience with this or a si= milar protocol, but those who do care about this draft have lived and breat= hed it for at least the four and a half years it has already existed. I wou= ld just ask you to consider your comments in the light of this situation.

John


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

--001a11c204fa3e7a14051958a1ef-- From nobody Thu Jun 25 07:56:19 2015 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 542521A8A3B for ; Thu, 25 Jun 2015 07:56:18 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ENDVVw9_Vonq for ; Thu, 25 Jun 2015 07:56:16 -0700 (PDT) Received: from uk-ext-viruswalls.astrium.eads.net (uk-ext-viruswalls.astrium.eads.net [194.62.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 688DA1A89FC for ; Thu, 25 Jun 2015 07:56:15 -0700 (PDT) Received: from uk-ext-viruswalls.astrium.eads.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C2E5A325B8; Thu, 25 Jun 2015 15:56:13 +0100 (BST) Received: from auk52542.uk.astrium.corp (unknown [10.201.85.42]) by uk-ext-viruswalls.astrium.eads.net (Postfix) with ESMTP id B5553325B6; Thu, 25 Jun 2015 15:56:13 +0100 (BST) Received: from E2K3-PTH-BRIDGEHEAD.UKN.UKNroot.astrium.corp ([10.221.1.31]) by auk52542.uk.astrium.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Jun 2015 15:56:13 +0100 Received: from AUK52982.UKN.UKNROOT.ASTRIUM.CORP ([fe80::543e:db1:48aa:1c6]) by AUK52840.UKN.UKNROOT.ASTRIUM.CORP ([fe80::7584:4b98:38c0:4ce7%15]) with mapi id 14.03.0123.003; Thu, 25 Jun 2015 15:56:12 +0100 From: "MATTY, Steven" To: 'Justin Dean' , John Dowdell Thread-Topic: [manet] DLEP-14: Credit Windowing (Section 9) Thread-Index: AQHQr1Umg4WclMNtG0qTc+EkzE+Aw529Tz1A Date: Thu, 25 Jun 2015 14:56:12 +0000 Message-ID: References: <220318AD-531B-4C42-A8B1-D2BD0BA3E89D@gmail.com> <160b67a67e864567b23300aaa9940536@VAUSDITCHM3.idirect.net> <558C08C4.3050907@gmail.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.221.1.73] X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-8.0.0.1202-21636.000 X-TM-AS-Result: No--18.231-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: multipart/alternative; boundary="_000_D9712B947A4CCA43AB42F01B90AF1DECD8553C04AUK52982UKNUKNR_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jun 2015 14:56:13.0198 (UTC) FILETIME=[14569AE0:01D0AF57] X-TM-AS-MML: disable X-imss-scan-details: No--18.231-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-8.0.1202-21636.000 X-TMASE-Result: 10--18.231200-5.000000 X-TMASE-MatchedRID: 0dFPYP4mu5R1kP8tHq3XVArQqZj0elT9K1qsYoC+xNAwp/4s3hUlGPyq yC9xEtnee5NH0ip3DJoZ1+Tyl23R0UL2oRfsBIKxGYJhRh6ssesm25c4W+3YIxZ50KsQddqX4e3 +py1f2c/lztime3+UZXink9VwYPZpDnEaSBk1PhC8coKUcaOOvcWmFF22SfTeIE7vV05wapunv2 v0a5LefKY08boCBoAlSaVfaxxV94/trubt8TkL4cG0UNgaZpYqGsvgUMYAn4WW+zaNLK605OygQ WdkAVMs0Nt5/j+aSDEUI4s17Ql301mKiy1F9pgLuIwLnB3Aqp13Bf9JIqsoeA8YwboCQc88oEMH fz15cBjMDEuDg15grA26ehZuKFNXAS9NkAgyXs0iPTMUjkOgki1RIwMdx4yupOwTxn+Ouv61ndJ wwFgO/WXljhnB0lbauh/tM+km/DzxJ84tD7jMf54CIKY/Hg3AaZGo0EeYG96lPA9G9KhcvZkw8K dMzN86eSC65CityAxHlCtC6dQhheHc11m1914YNXG4ILlX+JSYZbHWInaEb37cGd19dSFd Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-14: Credit Windowing (Section 9) 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 Jun 2015 14:56:18 -0000 --_000_D9712B947A4CCA43AB42F01B90AF1DECD8553C04AUK52982UKNUKNR_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZnJvbSBtZSwgd2hpbHN0IG5vdCBwcmVzZW50bHkgaGF2aW5nIGFueSBpbnRlcmVzdCBpbiBj cmVkaXQgd2luZG93aW5nLCBpdCBkb2VzIHNlcnZlIGFzIGEgZ29vZCBleGFtcGxlIG9uIERMRVAg ZXh0ZW5zaW9ucyBhbmQgYXQgdGhpcyBsYXRlIGRheSBJIHJlYWxseSBkb27igJl0IHdhbnQgdG8g ZGVsYXkgRExFUOKAmXMgb253YXJkIG1hcmNoIHRocm91Z2ggc3RhbmRhcmRzIHRyYWNrLg0KDQoN CkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEp1c3RpbiBEZWFuDQpTZW50OiBUaHVyc2RheSwgSnVuZSAyNSwgMjAxNSAzOjQyIFBNDQpUbzog Sm9obiBEb3dkZWxsDQpDYzogbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIERM RVAtMTQ6IENyZWRpdCBXaW5kb3dpbmcgKFNlY3Rpb24gOSkNCg0KSSdtIGdvaW5nIHRvICsxIGZv ciBrZWVwaW5nIGl0IGFzIG9uZSBkcmFmdC4gIEkgc2VlIG1lcml0IGluIGJyZWFraW5nIGl0IHVw IGludG8gdHdvIChhbmQgdGhhdCBtYXkgc3RpbGwgaGFwcGVuKSBidXQgSSBhbHNvIHNlZSB0aGUg dmFsdWUgaW4gaGF2aW5nIGl0IHdpdGhpbiBhIHNpbmdsZSBkcmFmdC4gIEl0IGFsbG93cyByZWFk aW5nIERMRVAgZm9yIHRoZSBmaXJzdCB0aW1lIHRvIHNlZSBob3cgdG8gZ28gYWJvdXQgd3JpdGlu ZyBhbiBleHRlbnNpb24gd2l0aG91dCBoYXZpbmcgdG8ga25vdyBhYm91dCBhbm90aGVyIGRyYWZ0 IFJGQy4gIFdlIGRpZCBzb21ldGhpbmcgc2ltaWxhciBmb3IgU01GIGFuZCBpdCB3b3JrZWQgd2Vs bCB0aGVyZSB0b28uICBVbmxlc3MgdGhlcmUgaXMgZnVydGhlciBjb21tZW50cyBvbiBsaXN0IHN1 cHBvcnRpbmcgYnJlYWtpbmcgdGhlIGRvY3VtZW50IHVwIEkgZG9uJ3QgdGhpbmsgcm91Z2ggV0cg Y29uc2Vuc3VzIGhhcyBjaGFuZ2VkIG9uIHRoaXMgaXNzdWUganVzdCBiZWNvbWUgbW9yZSByb3Vn aC4NCg0KT3RoZXJzIHBsZWFzZSBjb21tZW50IG9uZSB3YXkgb3IgYW5vdGhlciBhcyB0aGUgZWRp dG9yIHRlYW0gaXMgd29ya2luZyBoYXJkIHRvIHJldiB0aGUgZG9jdW1lbnQgYW5kIGFzc3VtaW5n IGNvbnNlbnN1cyBpc24ndCBuZWFybHkgYXMgZ29vZCBhcyBrbm93aW5nLg0KSnVzdGluIERlYW4N Cg0KDQpUaGlzIGVtYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBj b25maWRlbnRpYWwNCmFuZC9vciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIG9yIGluZm9ybWF0aW9u IG90aGVyd2lzZSBwcm90ZWN0ZWQNCmZyb20gZGlzY2xvc3VyZS4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlDQpub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSwgZG8gbm90IGNvcHkgdGhpcyBtZXNzYWdlIG9yIGFueQ0KYXR0YWNobWVudHMgYW5kIGRvIG5v dCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG9yIGRpc2Nsb3NlIGl0cw0KY29udGVudCB0byBhbnkg cGVyc29uLCBidXQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzDQpmcm9t IHlvdXIgc3lzdGVtLiBBaXJidXMgRGVmZW5jZSBhbmQgU3BhY2UgTGltaXRlZCBkaXNjbGFpbXMg YW55IGFuZCBhbGwgbGlhYmlsaXR5IGlmIHRoaXMgZW1haWwgdHJhbnNtaXNzaW9uIHdhcyB2aXJ1 cyBjb3JydXB0ZWQsDQphbHRlcmVkIG9yIGZhbHNpZmllZC4NCi1vLQ0KQWlyYnVzIERlZmVuY2Ug YW5kIFNwYWNlIExpbWl0ZWQsIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMgTm8uIDI0 NDkyNTkNClJlZ2lzdGVyZWQgT2ZmaWNlOg0KR3VubmVscyBXb29kIFJvYWQsIFN0ZXZlbmFnZSwg SGVydGZvcmRzaGlyZSwgU0cxIDJBUywgRW5nbGFuZA== --_000_D9712B947A4CCA43AB42F01B90AF1DECD8553C04AUK52982UKNUKNR_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mIzQzOzEgZnJvbSBtZSwgd2hpbHN0IG5vdCBwcmVzZW50bHkgaGF2aW5nIGFueSBpbnRl cmVzdCBpbiBjcmVkaXQgd2luZG93aW5nLCBpdCBkb2VzIHNlcnZlIGFzIGEgZ29vZCBleGFtcGxl IG9uIERMRVAgZXh0ZW5zaW9ucyBhbmQgYXQgdGhpcyBsYXRlIGRheSBJIHJlYWxseSBkb27igJl0 DQogd2FudCB0byBkZWxheSBETEVQ4oCZcyBvbndhcmQgbWFyY2ggdGhyb3VnaCBzdGFuZGFyZHMg dHJhY2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+SnVzdGluIERlYW48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bmUgMjUsIDIwMTUg Mzo0MiBQTTxicj4NCjxiPlRvOjwvYj4gSm9obiBEb3dkZWxsPGJyPg0KPGI+Q2M6PC9iPiBtYW5l dEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBETEVQLTE0OiBDcmVk aXQgV2luZG93aW5nIChTZWN0aW9uIDkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PkknbSBnb2luZyB0byAmIzQzOzEgZm9yIGtlZXBpbmcgaXQgYXMgb25lIGRyYWZ0LiZuYnNwOyBJ IHNlZSBtZXJpdCBpbiBicmVha2luZyBpdCB1cCBpbnRvIHR3byAoYW5kIHRoYXQgbWF5IHN0aWxs IGhhcHBlbikgYnV0IEkgYWxzbyBzZWUgdGhlIHZhbHVlIGluIGhhdmluZyBpdCB3aXRoaW4gYSBz aW5nbGUgZHJhZnQuJm5ic3A7IEl0IGFsbG93cyByZWFkaW5nIERMRVAgZm9yIHRoZSBmaXJzdA0K IHRpbWUgdG8gc2VlIGhvdyB0byBnbyBhYm91dCB3cml0aW5nIGFuIGV4dGVuc2lvbiB3aXRob3V0 IGhhdmluZyB0byBrbm93IGFib3V0IGFub3RoZXIgZHJhZnQgUkZDLiZuYnNwOyBXZSBkaWQgc29t ZXRoaW5nIHNpbWlsYXIgZm9yIFNNRiBhbmQgaXQgd29ya2VkIHdlbGwgdGhlcmUgdG9vLiZuYnNw OyBVbmxlc3MgdGhlcmUgaXMgZnVydGhlciBjb21tZW50cyBvbiBsaXN0IHN1cHBvcnRpbmcgYnJl YWtpbmcgdGhlIGRvY3VtZW50IHVwIEkgZG9uJ3QgdGhpbmsgcm91Z2gNCiBXRyBjb25zZW5zdXMg aGFzIGNoYW5nZWQgb24gdGhpcyBpc3N1ZSBqdXN0IGJlY29tZSBtb3JlIHJvdWdoLiZuYnNwOyA8 YnI+DQo8YnI+DQpPdGhlcnMgcGxlYXNlIGNvbW1lbnQgb25lIHdheSBvciBhbm90aGVyIGFzIHRo ZSBlZGl0b3IgdGVhbSBpcyB3b3JraW5nIGhhcmQgdG8gcmV2IHRoZSBkb2N1bWVudCBhbmQgYXNz dW1pbmcgY29uc2Vuc3VzIGlzbid0IG5lYXJseSBhcyBnb29kIGFzIGtub3dpbmcuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3RpbiBEZWFuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg0KPHRh YmxlPjx0cj48dGQgYmdjb2xvcj0jZmZmZmZmPjxmb250IGNvbG9yPSMwMDAwMDA+PHByZT5UaGlz IGVtYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRp YWwNCmFuZC9vciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIG9yIGluZm9ybWF0aW9uIG90aGVyd2lz ZSBwcm90ZWN0ZWQNCmZyb20gZGlzY2xvc3VyZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlDQpub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgZG8gbm90 IGNvcHkgdGhpcyBtZXNzYWdlIG9yIGFueQ0KYXR0YWNobWVudHMgYW5kIGRvIG5vdCB1c2UgaXQg Zm9yIGFueSBwdXJwb3NlIG9yIGRpc2Nsb3NlIGl0cw0KY29udGVudCB0byBhbnkgcGVyc29uLCBi dXQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzDQpmcm9tIHlvdXIgc3lz dGVtLiBBaXJidXMgRGVmZW5jZSBhbmQgU3BhY2UgTGltaXRlZCBkaXNjbGFpbXMgYW55IGFuZCBh bGwgbGlhYmlsaXR5IGlmIHRoaXMgZW1haWwgdHJhbnNtaXNzaW9uIHdhcyB2aXJ1cyBjb3JydXB0 ZWQsDQphbHRlcmVkIG9yIGZhbHNpZmllZC4NCi1vLQ0KQWlyYnVzIERlZmVuY2UgYW5kIFNwYWNl IExpbWl0ZWQsIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMgTm8uIDI0NDkyNTkNClJl Z2lzdGVyZWQgT2ZmaWNlOg0KR3VubmVscyBXb29kIFJvYWQsIFN0ZXZlbmFnZSwgSGVydGZvcmRz aGlyZSwgU0cxIDJBUywgRW5nbGFuZDwvcHJlPjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --_000_D9712B947A4CCA43AB42F01B90AF1DECD8553C04AUK52982UKNUKNR_-- From nobody Thu Jun 25 08:07:37 2015 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 C60C41A8A59 for ; Thu, 25 Jun 2015 08:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 vrQQ4dsWNb0j for ; Thu, 25 Jun 2015 08:07:35 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 089891A8A4B for ; Thu, 25 Jun 2015 08:07:34 -0700 (PDT) Received: (qmail 17404 invoked by uid 0); 25 Jun 2015 15:07:30 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 25 Jun 2015 15:07:30 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id kl0Z1q01G2SSUrH01l0cmr; Thu, 25 Jun 2015 15:00:38 -0600 X-Authority-Analysis: v=2.1 cv=LLP1Hvm9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=QrohdLjRRo4A:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XAFQembCKUMA:10 a=6ZQ8sS9GVcHFhRDKpx0A:9 a=0FzIns50BnnjF_ER:21 a=j5vcF84Kv9yegQ5E:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=AT4tvFIP8DkRk925GjWJlvk3QlzpOOskm7G29aOZ2ag=; b=DXouWaIf0c4e5YoCokcXJMU/nFUYagvx9QU0R7DkavvD3R+rDyCGh6PYZZyyJ3Mt8RiZRd60VYljuie8eY+oVXq4yOzSkzSGXRRsHMYg+27N89kFp6xKi7Rw7buMnRai; Received: from box313.bluehost.com ([69.89.31.113]:57793 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z88kQ-0005j4-8j; Thu, 25 Jun 2015 09:07:26 -0600 Message-ID: <558C1928.1060802@labn.net> Date: Thu, 25 Jun 2015 11:07:20 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Ratliff, Stanley" References: <220318AD-531B-4C42-A8B1-D2BD0BA3E89D@gmail.com> <160b67a67e864567b23300aaa9940536@VAUSDITCHM3.idirect.net> In-Reply-To: <160b67a67e864567b23300aaa9940536@VAUSDITCHM3.idirect.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-14: Credit Windowing (Section 9) 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 Jun 2015 15:07:36 -0000 On 6/25/2015 9:10 AM, Ratliff, Stanley wrote: > So at this point, with the spec having already cleared WGLC, we're going to leave Credit Extensions in the base doc. Stan, A couple of points on the extension: 1) Per my review IMO the current definition of the extension is insufficient to ensure interoperable implementations -- I think this can readily be fixed by including parallel descriptions and mechanisms from RFC5578 -- but it will take time to get this done. 2) Optional functionality in a base spec is generally not a great idea from the process / IETF standards perspective. In particular, if a user specifies/requires, or a vendor claims conformance with, an RFC, there is no way to know if the perfectly conformant implementations will interoperate / support the optional functionality. I think both points, particularly the second, support separating out the credit extension. From a WG process standpoint I don't see this as anyway a reset or back step. I've seen (and as chair even initiated) late stage document splits/merges multiple times and it isn't a big deal. Lou From nobody Thu Jun 25 08:11:41 2015 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 57F2E1A9121 for ; Thu, 25 Jun 2015 08:11:40 -0700 (PDT) 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 ngHacy_QGVbf for ; Thu, 25 Jun 2015 08:11:36 -0700 (PDT) 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 BC7C21A90DD for ; Thu, 25 Jun 2015 08:11:31 -0700 (PDT) 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, 25 Jun 2015 16:11:07 +0100 From: Rick Taylor To: "MATTY, Steven" , 'Justin Dean' , John Dowdell Thread-Topic: [manet] DLEP-14: Credit Windowing (Section 9) Thread-Index: AQHQr1UgKOGROtISb0iF45lqlgF4tQ== Date: Thu, 25 Jun 2015 15:11:05 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2BDC04@tss-server1.home.tropicalstormsoftware.com> References: <220318AD-531B-4C42-A8B1-D2BD0BA3E89D@gmail.com> <160b67a67e864567b23300aaa9940536@VAUSDITCHM3.idirect.net> <558C08C4.3050907@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-14: Credit Windowing (Section 9) 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 Jun 2015 15:11:40 -0000 This is a +1 for one draft from me.=0A= =0A= It was always intended to stay in the draft as a 'worked example' of an =0A= extension.=0A= =0A= Also, I have enough typing to do already ;)=0A= =0A= Rick=0A= =0A= =0A= On 25/06/15 15:56, MATTY, Steven wrote:=0A= > +1 from me, whilst not presently having any interest in credit=0A= > windowing, it does serve as a good example on DLEP extensions and at=0A= > this late day I really don=92t want to delay DLEP=92s onward march throug= h=0A= > standards track.=0A= >=0A= > *From:*manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Justin Dean= =0A= > *Sent:* Thursday, June 25, 2015 3:42 PM=0A= > *To:* John Dowdell=0A= > *Cc:* manet@ietf.org=0A= > *Subject:* Re: [manet] DLEP-14: Credit Windowing (Section 9)=0A= >=0A= > I'm going to +1 for keeping it as one draft. I see merit in breaking it= =0A= > up into two (and that may still happen) but I also see the value in=0A= > having it within a single draft. It allows reading DLEP for the first=0A= > time to see how to go about writing an extension without having to know= =0A= > about another draft RFC. We did something similar for SMF and it worked= =0A= > well there too. Unless there is further comments on list supporting=0A= > breaking the document up I don't think rough WG consensus has changed on= =0A= > this issue just become more rough.=0A= >=0A= > Others please comment one way or another as the editor team is working=0A= > hard to rev the document and assuming consensus isn't nearly as good as= =0A= > knowing.=0A= >=0A= > Justin Dean=0A= >=0A= > This email (including any attachments) may contain confidential=0A= > and/or privileged information or information otherwise protected=0A= > from disclosure. If you are not the intended recipient, please=0A= > notify the sender immediately, do not copy this message or any=0A= > attachments and do not use it for any purpose or disclose its=0A= > content to any person, but delete this message and any attachments=0A= > from your system. Airbus Defence and Space Limited disclaims any and all = liability if this email transmission was virus corrupted,=0A= > altered or falsified.=0A= > -o-=0A= > Airbus Defence and Space Limited, Registered in England and Wales No. 244= 9259=0A= > Registered Office:=0A= > Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England=0A= >=0A= =0A= From nobody Thu Jun 25 08:14:27 2015 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 F10D91A906B for ; Thu, 25 Jun 2015 08:14:25 -0700 (PDT) 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 8uLTs-7KVGUW for ; Thu, 25 Jun 2015 08:14:25 -0700 (PDT) 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 A3F911A904E for ; Thu, 25 Jun 2015 08:14:24 -0700 (PDT) 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, 25 Jun 2015 16:14:00 +0100 From: Rick Taylor To: Justin Dean , RJ Atkinson Thread-Topic: [manet] DLEP-14: Terminology Thread-Index: AQHQrw7AnXETJjb4rke8Q4+Zp37zvQ== Date: Thu, 25 Jun 2015 15:13:58 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016C2BDC16@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016C2BCB66@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: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-14: Terminology 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 Jun 2015 15:14:26 -0000 On 25/06/15 15:28, Justin Dean wrote:=0A= >>> A DLEP extension is exactly that... a group of (standardized)=0A= >>> additional signals/data-items. The "extension TLV" is just the way to= =0A= >>> tell the other side "hey, I am supporting this extension!"=0A= >>>=0A= >>> Henning Rogge=0A= >=0A= > "Extension Set Supported" vs "Extensions Supported" seems like a nit of= =0A= > a issue and not really an issue either way. Although Extension Set does= =0A= > seem a tad clearer to me.=0A= > To the root of the issue can be cleaned up with a bit more clarity for=0A= > section 8.7=0A= >=0A= > The Extensions Supported data item MAY be used in both the Peer=0A= > Initialization and Peer Initialization ACK signals. The Extensions= =0A= > Supported data item is used by the router and modem to negotiate=0A= > *additional optional functionality* they are willing to support. The=0A= > Extensions List is a concatenation of the types of each supported=0A= > extension, found in the IANA DLEP Extensions repository.=0A= >=0A= > to=0A= >=0A= > The Extensions Supported data item MAY be used in both the Peer=0A= > Initialization and Peer Initialization ACK signals. The Extensions= =0A= > Supported data item is used by the router and modem to negotiate=0A= > **additional optional functionality they are willing to support. The=0A= > Extensions List is a concatenation of Extension Types, defined in=0A= > the IANA DLEP Extensions repository. Each Extension Type=0A= > definition includes which additional signals and data-items are=0A= > supported.=0A= =0A= Agreed, it's in proto-draft-15.=0A= =0A= Rick=0A= =0A= From nobody Thu Jun 25 08:14:45 2015 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 00D711A90ED for ; Thu, 25 Jun 2015 08:14:44 -0700 (PDT) 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 ergZb8LI47LE for ; Thu, 25 Jun 2015 08:14:42 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 F15E41A90EB for ; Thu, 25 Jun 2015 08:14:41 -0700 (PDT) Received: by wicgi11 with SMTP id gi11so79025769wic.0 for ; Thu, 25 Jun 2015 08:14:40 -0700 (PDT) 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=+LT6DIZMrbQdHtRLyrtlT3t7+WUHtf7+WQL8qFkMkyc=; b=eTPdOp3WmzCv46eIZ0SfdDFkk0pCO1D+J3usv5iH4VgzST0MTFMzoUO/G4qEdVfM+6 tsiT/Ckzj+XUQlN5dEY0zwBHPmpN3Xb9d7M02/U6dM01onMToXZ6KJqeLK6seMtxStbA rzlwVRtssFocBEfZvJuU9jhv6HJ5iFGgP59KriCE/wsxlm8vt+T4377EYt6A5fMPIr1Q ow5wbeTjZ9/uNMMc6CVjP444dRC5SxGfIiHE0Au20qzpPQoVXCPVLKSWKshJ0cyQV7Kx oqCS9kWxznpFoXy1evb+peAKz70JpWRbNpVvQ7PNzEFh5bsIGDgXUzVH3kt9grYkh8pi BywA== X-Received: by 10.194.187.170 with SMTP id ft10mr81372413wjc.26.1435245280768; Thu, 25 Jun 2015 08:14:40 -0700 (PDT) Received: from [10.0.4.178] ([217.158.48.187]) by mx.google.com with ESMTPSA id pg1sm46302593wjb.39.2015.06.25.08.14.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 08:14:39 -0700 (PDT) Message-ID: <558C1ADF.4080803@gmail.com> Date: Thu, 25 Jun 2015 16:14:39 +0100 From: John Dowdell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "manet@ietf.org" References: <220318AD-531B-4C42-A8B1-D2BD0BA3E89D@gmail.com> <160b67a67e864567b23300aaa9940536@VAUSDITCHM3.idirect.net> <558C08C4.3050907@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070005040807000709060008" Archived-At: Subject: Re: [manet] DLEP-14: Credit Windowing (Section 9) 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 Jun 2015 15:14:44 -0000 This is a multi-part message in MIME format. --------------070005040807000709060008 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +1 from me too. On 25/06/15 15:56, MATTY, Steven wrote: > > +1 from me, whilst not presently having any interest in credit > windowing, it does serve as a good example on DLEP extensions and at > this late day I really don’t want to delay DLEP’s onward march through > standards track. > > *From:*manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Justin Dean > *Sent:* Thursday, June 25, 2015 3:42 PM > *To:* John Dowdell > *Cc:* manet@ietf.org > *Subject:* Re: [manet] DLEP-14: Credit Windowing (Section 9) > > I'm going to +1 for keeping it as one draft. I see merit in breaking > it up into two (and that may still happen) but I also see the value in > having it within a single draft. It allows reading DLEP for the first > time to see how to go about writing an extension without having to > know about another draft RFC. We did something similar for SMF and it > worked well there too. Unless there is further comments on list > supporting breaking the document up I don't think rough WG consensus > has changed on this issue just become more rough. > > Others please comment one way or another as the editor team is working > hard to rev the document and assuming consensus isn't nearly as good > as knowing. > > --------------070005040807000709060008 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1 from me too.

On 25/06/15 15:56, MATTY, Steven wrote:

+1 from me, whilst not presently having any interest in credit windowing, it does serve as a good example on DLEP extensions and at this late day I really don’t want to delay DLEP’s onward march through standards track.

 

 

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean
Sent: Thursday, June 25, 2015 3:42 PM
To: John Dowdell
Cc: manet@ietf.org
Subject: Re: [manet] DLEP-14: Credit Windowing (Section 9)

 

I'm going to +1 for keeping it as one draft.  I see merit in breaking it up into two (and that may still happen) but I also see the value in having it within a single draft.  It allows reading DLEP for the first time to see how to go about writing an extension without having to know about another draft RFC.  We did something similar for SMF and it worked well there too.  Unless there is further comments on list supporting breaking the document up I don't think rough WG consensus has changed on this issue just become more rough. 

Others please comment one way or another as the editor team is working hard to rev the document and assuming consensus isn't nearly as good as knowing.

--------------070005040807000709060008-- From nobody Thu Jun 25 08:28:08 2015 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 60E8E1A00B6 for ; Thu, 25 Jun 2015 08:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 IwIAVcjBn-eR for ; Thu, 25 Jun 2015 08:28:05 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 81BBA1A0092 for ; Thu, 25 Jun 2015 08:28:05 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5PFS3N2030993; Thu, 25 Jun 2015 11:28:03 -0400 From: "Wiggins, David - 0665 - MITLL" To: Justin Dean , John Dowdell Thread-Topic: [manet] DLEP-14: Credit Windowing (Section 9) Thread-Index: AQHQr1Unw2/ZU6D3skuGO3g+5nDus529WGCA Date: Thu, 25 Jun 2015 15:28:02 +0000 Message-ID: References: <220318AD-531B-4C42-A8B1-D2BD0BA3E89D@gmail.com> <160b67a67e864567b23300aaa9940536@VAUSDITCHM3.idirect.net> <558C08C4.3050907@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3518076481_67916062" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-25_05:2015-06-25,2015-06-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-1506250262 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-14: Credit Windowing (Section 9) 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 Jun 2015 15:28:08 -0000 --B_3518076481_67916062 Content-type: multipart/alternative; boundary="B_3518076481_67952236" --B_3518076481_67952236 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I think the credit windowing extension needs significant work. I have looked briefly at implementing it and I felt like I had to do a lot of guesswork/assumptions to make sense of it. I'm concerned that fixing this will delay the main DLEP draft. So, I'm in favor of splitting them. David From: Justin Dean Date: Thursday, June 25, 2015 at 10:42 AM To: John Dowdell Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-14: Credit Windowing (Section 9) I'm going to +1 for keeping it as one draft. I see merit in breaking it up into two (and that may still happen) but I also see the value in having it within a single draft. It allows reading DLEP for the first time to see how to go about writing an extension without having to know about another draft RFC. We did something similar for SMF and it worked well there too. Unless there is further comments on list supporting breaking the document up I don't think rough WG consensus has changed on this issue just become more rough. Others please comment one way or another as the editor team is working hard to rev the document and assuming consensus isn't nearly as good as knowing. Justin Dean On Thu, Jun 25, 2015 at 9:57 AM, John Dowdell wrote: > > > On 25/06/15 14:22, RJ Atkinson wrote: >>> On 25 Jun 2015, at 09:10 , Ratliff, Stanley wrote: >>> >>> The option of splitting the Credit Extensions out into a separate document >>> was thoroughly discussed, both on-list, and in the DLEP design team. The DT >>> closed work at IETF 89 (London), reaching consensus on this and other >>> issues. >> Stan, >> >> - Design Teams do not get to make decisions for WGs. >> - Design Teams propose items to a WG for WG review. >> - So the Design Team discussion above is a bit of a Red Herring, >> from an IETF process perspective. > Ran, > > I've only been at IETF meetings for a few years, and was a member of the > design team for DLEP. Your comments are noted, but I've never actually seen a > working group take a decision in the way that a business project team would. > In practice, working group members either seem to care or not, and if they > care they usually seem to post regularly on the topic, or are invited to > become part of a design or author team. > > The design team in this case was a group of individuals who had all regularly > posted to the list on this topic for a good two years prior to the formation > of the DT. Despite asking frequently, both on-list and off-list, including > radio manufacturers and system integrators that I would occasionally meet, few > other opinions were ever expressed on-list. Many members of the design team > have implementations, which yielded valuable experience in what worked and > what didn't, and this went back into the draft. We're now four and a half > years since draft-00. I know there are major organisations waiting for DLEP to > get finished so they can inform their own strategies and development cycles, > and for that they need a stable and implementable specification that those of > us who have a stake in this protocol can agree on. > > I don't for a second dispute your right to make suggestions or propose text or > provide review based on implementation experience with this or a similar > protocol, but those who do care about this draft have lived and breathed it > for at least the four and a half years it has already existed. I would just > ask you to consider your comments in the light of this situation. > > John > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --B_3518076481_67952236 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
I think the credit windowing = extension needs significant work.  I have looked briefly at implementin= g it and I felt like I had to do a lot of guesswork/assumptions to make sens= e of it.  I'm concerned that fixing this will delay the main DLEP draft= .  So, I'm in favor of splitting them.

David

From: Justin Dean <= ;bebemaster@gmail.com>
Date: Thursday, June 25, 2015 at 10:42 AM<= br>To: John Dowdell <john.dowdell.ietf@gmail.com>
Cc: "manet= @ietf.org" <manet@ietf.org>Subject: Re: [manet] DLEP-14: Credit= Windowing (Section 9)

I'm goin= g to +1 for keeping it as one draft.  I see merit in breaking it up int= o two (and that may still happen) but I also see the value in having it with= in a single draft.  It allows reading DLEP for the first time to see ho= w to go about writing an extension without having to know about another draft RFC.  We did something sim= ilar for SMF and it worked well there too.  Unless there is further com= ments on list supporting breaking the document up I don't think rough WG con= sensus has changed on this issue just become more rough. 

Others please comment one way or another as the editor team is working hard= to rev the document and assuming consensus isn't nearly as good as knowing.=

Justin Dean

= On Thu, Jun 25, 2015 at 9:57 AM, John Dowdell <john.dowde= ll.ietf@gmail.com> wrote:


On 25/06/15 14:22, RJ Atkinson wrote:
On 25  Jun 2015, at 09:10 , Ratliff, Stanley <sratliff@idirect.net> wrote:

= The option of splitting the Credit Extensions out into a separate document = was thoroughly discussed, both on-list, and in the DLEP design team. The DT = closed work at IETF 89 (London), reaching consensus on this and other issues= .
Stan,

- Design Teams do not get to make decisions for WGs.
- Design Teams propose items to a WG for WG review.
- So the Design Team discussion above is a bit of a Red Herring,
   from an IETF process perspective.
Ran,<= br>
I've only been at IETF meetings for a few years, and was a member of the de= sign team for DLEP. Your comments are noted, but I've never actually seen a = working group take a decision in the way that a business project team would.= In practice, working group members either seem to care or not, and if they care they usually seem to post reg= ularly on the topic, or are invited to become part of a design or author tea= m.

The design team in this case was a group of individuals who had all regular= ly posted to the list on this topic for a good two years prior to the format= ion of the DT. Despite asking frequently, both on-list and off-list, includi= ng radio manufacturers and system integrators that I would occasionally meet, few other opinions were ever e= xpressed on-list. Many members of the design team have implementations, whic= h yielded valuable experience in what worked and what didn't, and this went = back into the draft. We're now four and a half years since draft-00. I know there are major organisations= waiting for DLEP to get finished so they can inform their own strategies an= d development cycles, and for that they need a stable and implementable spec= ification that those of us who have a stake in this protocol can agree on.

I don't for a second dispute your right to make suggestions or propose text= or provide review based on implementation experience with this or a similar= protocol, but those who do care about this draft have lived and breathed it= for at least the four and a half years it has already existed. I would just ask you to consider your commen= ts in the light of this situation.

John


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

 --B_3518076481_67952236-- --B_3518076481_67916062 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFM0KOr2PS0OaFPnC cSIxQ0Q1Ii5rMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYyNTE1MjgwMVowDQYJKoZIhvcNAQEBBQAEggEAG+QTOccUTdXWErwrakZBWgPbMzNMlCh3 6aC2xyyo3ABD1BZEOcZfSDlW1LBm+BPNxxu5ngjhIHmP/Kvp1Aos2nGSXI3Oj0aZY3Prc4V8 DkbC5PtitfuAq+eL+tqfTKXZQ+H6kxL434KExxwx4Oyod6JwE39EP/rgYis/NR7Ic6NqdYT7 0booYeuousJgXwJbKm2g0A1OKYJkLxMt5ikhxr0uaznKUZsZTGS2XKheoY7D7BDlHJrUTTN0 DNQWNv7PY3uVA2/SafaESPwU80Ig5ReZgu5FhA7T6YmORrsFcNnP7OdpsJOA2uHJsHlT82YT u5CcbIo9OZepJ6bTbgH59g== --B_3518076481_67916062-- From nobody Thu Jun 25 08:38:48 2015 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 DBC731A038C; Thu, 25 Jun 2015 08:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z5-d5f00CQf; Thu, 25 Jun 2015 08:38:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93631A038D; Thu, 25 Jun 2015 08:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6782; q=dns/txt; s=iport; t=1435246721; x=1436456321; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OQZMayUwofRz1PdtzHbhIxBKCoej8TL3ILoGIO0oBBo=; b=edTDhx/IavNPycRYK6Hd/2GgS2/dRPnL+O9cmypBv1mQNS4QO5aRaTkq 88Ts2ZbI0ML3VorLI5z8TPpDc0Mjji3brREZbVRVvvPfOphw45Uht0EKE eRNmPkQTCbWY5HMWtnJLJtFQUBFzvI18N4ncH/gwAhNmjf87B589MEQxq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AdBAD3H4xV/4kNJK1bgxGBMwaDGLVJhCsJh14CHIEeOBQBAQEBAQEBgQqEIwEBBCMRNw4QAgEIGAICJgICAjAVEAIEAQ0FiC+4OJY1AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiimFBgeCaIFDBYcDiiaCXQGHL4QigTqOfYgCJmOBWoE9b4FGgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,677,1427760000"; d="scan'208";a="10290646" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jun 2015 15:38:39 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5PFcdBL030344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jun 2015 15:38:39 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.106]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 10:38:39 -0500 From: "Alvaro Retana (aretana)" To: "Benoit Claise (bclaise)" , Susan Hares Thread-Topic: Benoit Claise's Discuss on draft-ietf-manet-olsrv2-multitopology-05: (with DISCUSS) Thread-Index: AQHQmUnuajLfhADH00edYzbRKWlUcJ2uKqWAgA9tiYA= Date: Thu, 25 Jun 2015 15:38:38 +0000 Message-ID: References: <20150528132630.13861.80616.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-manet-olsrv2-multitopology@ietf.org" , "ops-dir@ietf.org" , "manet@ietf.org" , The IESG , "manet-chairs@ietf.org" Subject: Re: [manet] Benoit Claise's Discuss on draft-ietf-manet-olsrv2-multitopology-05: (with DISCUSS) 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 Jun 2015 15:38:43 -0000 QmVub2l0L1N1ZToNCg0KQW55IGNvbW1lbnRzPw0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0KT24g Ni8xNS8xNSwgNDowMiBQTSwgIkFsdmFybyBSZXRhbmEgKGFyZXRhbmEpIiA8YXJldGFuYUBjaXNj by5jb20+IHdyb3RlOg0KDQo+T24gNS8yOC8xNSwgOToyNiBBTSwgIkJlbm9pdCBDbGFpc2UgKGJj bGFpc2UpIiA8YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0KPg0KPltCZWNhdXNlIHRoZSBhdXRo b3JzIGRpZG7CuXQgaGF2ZSB0aW1lIHRvIHJldmlldyB0aGUgb3BzLWRpciBjb21tZW50cw0KPmJl Zm9yZSB0aGUgdGVsZWNoYXQsIG9yIGJlZm9yZSB0aGV5IGJlY2FtZSBhIERJU0NVU1MsIEnCuW0g ZXhwbGljaXRseQ0KPmNjwrlpbmcgaXQgaGVyZSBhcyB3ZWxsIGFzIFN1ZS5dDQo+DQo+QmVub2l0 Og0KPg0KPkhpIQ0KPg0KPlNvcnJ5IGl0IHRvb2sgbWUgYSB3aGlsZSB0byBnZXQgdG8gdGhpcy4u DQo+DQo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+RElTQ1VTUzoNCj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+ VGhlIG11bHRpcGxlIHBvaW50cywgYnJvdWdodCB1cCBieSBTdWUgcGFydCBvZiBoZXIgT1BTLURJ UiByZXZpZXcsDQo+PmRlc2VydmUgYSBESVNDVVNTLiBMZXQncyBlbmdhZ2UgaW4gdGhlIGRpc2N1 c3Npb24uDQo+LiAuIC4NCj4NCj4NCj4+U3VtbWFyeSBvZiBDb21tZW50czoNCj4+DQo+Pk15IGNv bW1lbnRzIGhhdmUgNiBtYWpvciBpc3N1ZXMsIGFuZCBhIHNldCBvZiBlZGl0b3JpYWwgY2hhbmdl cy4gIEZpdmUgb2YNCj4+bXkgbWFqb3IgcG9pbnRzIGhhdmUgdG8gZG8gd2l0aCBhZGRpbmcgbW9y ZSBkZXRhaWxzIHRvIHRoZSBkcmFmdCB0byBqdWRnZQ0KPj50aGUgZXhwZXJpbWVudCB2YWx1YWJs ZS4gIE9uZSB3YXkgdG8gcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBpcyB0byBjcmVhdGUNCj4+ZG9j dW1lbnQgcHJvdmlkaW5nIGRldGFpbHMgb24gdGhlIHRlc3QgdGhhdCB3aWxsIGJlIHJ1bi4gIEEg c2Vjb25kIHdheSB0bw0KPj5yZXNvbHZlIHRoZXNlIGNvbW1lbnRzIG9uIGV4cGVyaW1lbnQgaXMg dG8gcHJvdmlkZSBhZGRpdGlvbmFsIGhpZ2gtbGV2ZWwNCj4+Z3VpZGFuY2UgaW4gdGhpcyBkb2N1 bWVudC4NCj4NCj5Ob3RlIHRoYXQgc2VjdGlvbiAxLjEgKE1vdGl2YXRpb24gYW5kIEV4cGVyaW1l bnRhdGlvbikgYWxyZWFkeSBwcm92aWRlcw0KPmhpZ2gtbGV2ZWwgZ3VpZGFuY2Ugb2YgdGhlIHR5 cGUgb2YgaW5mb3JtYXRpb24gdG8gYmUgZXZhbHVhdGVkLg0KPg0KPiAgIFdoaWxlIGdlbmVyYWwg ZXhwZXJpZW5jZXMgd2l0aCB0aGlzIHByb3RvY29sIGV4dGVuc2lvbiwgaW5jbHVkaW5nDQo+ICAg aW50ZXJvcGVyYWJpbGl0eSBvZiBpbXBsZW1lbnRhdGlvbnMsIGFyZSBlbmNvdXJhZ2VkLCBzcGVj aWZpYw0KPiAgIGluZm9ybWF0aW9uIHdvdWxkIGJlIHBhcnRpY3VsYXJseSBhcHByZWNpYXRlZCBv biB0aGUgZm9sbG93aW5nIGFyZWFzOg0KPg0KPiAgIG8gIE9wZXJhdGlvbiBpbiBhIG5ldHdvcmsg dGhhdCBjb250YWlucyBib3RoIHJvdXRlcnMgaW1wbGVtZW50aW5nDQo+ICAgICAgdGhpcyBleHRl bnNpb24sIGFuZCByb3V0ZXJzIGltcGxlbWVudGluZyBvbmx5IFtSRkM3MTgxXSwgaW4NCj4gICAg ICBwYXJ0aWN1bGFyIGFyZSB0aGVyZSBhbnkgdW5leHBlY3RlZCBpbnRlcmFjdGlvbnMgdGhhdCBj YW4gYnJlYWsNCj4gICAgICB0aGUgbmV0d29yaz8NCj4NCj4gICBvICBPcGVyYXRpb24gaW4gcmVh bGlzdGljIGRlcGxveW1lbnRzLCBhbmQgZGV0YWlscyB0aGVyZW9mLCBpbmNsdWRpbmcNCj4gICAg ICBpbiBwYXJ0aWN1bGFyIGluZGljYXRpbmcgaG93IG1hbnkgY29uY3VycmVudCB0b3BvbG9naWVz IHdlcmUNCj4gICAgICByZXF1aXJlZC4NCj4NCj4gICBBIGJyb2FkZXIgaXNzdWUgdGhhdCBhcHBs aWVzIHRvIHVuZXh0ZW5kZWQgW1JGQzcxODFdIGFzIHdlbGwgYXMgdGhpcw0KPiAgIGV4dGVuc2lv biAoYW5kIHBvdGVudGlhbGx5IHRvIG90aGVyIE1BTkVUIHJvdXRpbmcgcHJvdG9jb2xzKSBpcyB3 aGljaA0KPiAgIGxpbmsgbWV0cmljIHR5cGVzIGFyZSB1c2VmdWwgaW4gYSBNQU5FVCwgYW5kIGhv dyB0byBlc3RhYmxpc2ggdGhlDQo+ICAgbWV0cmljcyB0byBhc3NvY2lhdGUgd2l0aCBhIGdpdmVu IGxpbmsuICBXaGlsZSB0aGlzIGlzc3VlIGlzIG5vdCBvbmx5DQo+ICAgcmVsYXRlZCB0byB0aGlz IGV4dGVuc2lvbiwgdGhlIGFiaWxpdHkgZm9yIGFuIE9MU1J2MiBuZXR3b3JrIHRvDQo+ICAgbWFp bnRhaW4gZGlmZmVyZW50IGNvbmN1cnJlbnQgbGluayBtZXRyaWNzIG1heSBmYWNpbGl0YXRlIGJv dGgNCj4gICBleHBlcmltZW50cyB3aXRoIGRpZmZlcmVudCBsaW5rIG1ldHJpYyB0eXBlcywgd2F5 cyB0byBtZWFzdXJlIHRoZW0sDQo+ICAgZXRjLiBhbmQgbWF5IGFsc28gYWxsb3cgZXhwZXJpbWVu dGF0aW9uIHdpdGggbGluayBtZXRyaWMgdHlwZXMgdGhhdA0KPiAgIGFyZSBub3QgY29tcHJvbWlz ZXMgdG8gaGFuZGxlIG11bHRpcGxlIHRyYWZmaWMgdHlwZXMuDQo+DQo+DQo+Q2xlYXJseSB0aGUg Zm9jdXMgaXMgb24gwrNydW5uaW5nIGNvZGXCsjogb3BlcmF0aW9uIGluIHJlYWwgZGVwbG95bWVu dHMgYW5kDQo+bWl4ZWQgZW52aXJvbm1lbnRzLg0KPg0KPg0KPlRoZSBzdWdnZXN0aW9ucyBmb3Ig dGVzdHMgbWFkZSBpbiB0aGUgT3BzLURpciByZXZpZXcgYXJlIGdyZWF0ISAgSG93ZXZlciwNCj5J IGRvbsK5dCBiZWxpZXZlIHRoYXQgc3VjaCBkZXRhaWwgYmVsb25ncyBpbiB0aGlzIGRvY3VtZW50 LCB3aGVyZSB0aGUgbWFpbg0KPnB1cnBvc2UgaXMgdG8gZG9jdW1lbnQgdGhlIGV4dGVuc2lvbi4g IEluIGZhY3QsIEkgdGhpbmsgdGhlIHN1Z2dlc3Rpb25zDQo+YmVsb25nIG1vcmUgYXMgcGFydCBv ZiBhIHRlc3QgcGxhbiAodXNlZCBieSBpbXBsZW1lbnRvcnMg4oC5IHNpbWlsYXIgbWF5YmUNCj50 byB0aGUgd29yayBkb25lIGluIGJtd2csIGZvciBleGFtcGxlKSwgd2hpY2ggc2VlbXMgdG8gYmUg aW4gbGluZSB3aXRoIHRoZQ0KPmNvbW1lbnRzOiAoU3VlIHdyb3RlKSDCs1RoZSByZWNvbW1lbmRl ZCB0ZXN0cyBpbiBtYWpvciBjb25jZXJuIDEtNCBjb3VsZCBiZQ0KPmNyZWF0ZWQgaW4gYSBzZXBh cmF0ZSBkcmFmdC7Csg0KPg0KPkl0IGlzIG5vdCBpbiB0aGUgbWFuZXQgV0dzIGNoYXJ0ZXIgdG8g cHJvZHVjZSB0ZXN0IHBsYW5zLiAgSW4gb3JkZXIgdG8gbm90DQo+bG9vc2UgU3VlwrlzIHZhbHVh YmxlIGlucHV0LCBJIHN1Z2dlc3Qgd2Uga2VlcCB0aGVtIGluIHRoZSBXR8K5cyB3aWtpIOKAuQ0K PndoaWNoIHdpbGwgYWxsb3cgZm9yIG90aGVyIHRlc3QgY2FzZXMgdG8gYmUgYWRkZWQsIGRldGFp bHMgaW5jbHVkZWQsDQo+cmVzdWx0cyByZWZsZWN0ZWQsIGV0Yy4NCj4NCj4NCj4uIC4gLg0KPj5N YWpvciBjb25jZXJuIDU6ICBFeHBlcmltZW50cyBzaG91bGQgZHJpdmUgdG8gY3JlYXRlIG9wZXJh dGlvbmFsDQo+Pmd1aWRlbGluZXMgZm9yIGRlcGxveW1lbnQsIGNvbmZpZ3VyYXRpb24ga25vYnMs IGFuZCB1c2UgY2FzZXMgKEFET1YtMiwNCj4+T0xTUi12MiwgTVQtT0xTUi12MikNCj4NCj5Db21w bGV0ZWx5IGFncmVlISAgSW1wbGVtZW50YXRpb24gYW5kIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2Ug KG5vdCBqdXN0DQo+ZXhwZXJpbWVudHMpIHNob3VsZCBpbiBmYWN0IHJlc3VsdCBpbiB0aGF0IHR5 cGUgb2YgZ3VpZGVsaW5lcy4NCj4NCj5BZ2FpbiwgdGhlIGRldGFpbHMgYXJlIG5vdCB3aXRoaW4g dGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuLmFuZCBndWlkYW5jZQ0KPmlzIGFscmVhZHkgZ2l2 ZW4gaW4gMS4xIGFib3V0IHRoZSB1c2UgaW4gcmVhbCBuZXR3b3Jrcy4NCj4NCj5Ob3RlIHRoYXQg dGhpcyBjb21tZW50IG1lbnRpb25zIG5vdCBqdXN0IHRoZSBleHRlbnNpb25zIHByb3Bvc2VkLCBi dXQgdGhlDQo+YmFzZSBwcm90b2NvbCBhbmQgZXZlbiBBT0RWdjIuICBBbGwgdGhlc2UgZ3VpZGVs aW5lcyBhcmUgaW1wb3J0YW50IGZyb20gYW4NCj5vcGVyYXRpb25zIHBvaW50IG9mIHZpZXcsIGJ1 dCBzaG91bGRuwrl0IGJlIHRpZWQgdG8gdGhpcyBkb2N1bWVudC4NCj4NCj5Bc2lkZTogdGhlIE1B TkVUIFdHIGlzIGluIHByb2Nlc3Mgb2YgcmVjaGFydGVyaW5nLiAgVGhpcyB0eXBlIG9mDQo+c3Vn Z2VzdGlvbnMgc2hvdWxkIGJlIHByZXNlbnRlZCBmb3IgZGlzY3Vzc2lvbi4NCj4NCj4NCj4uIC4g Lg0KPj5NYWpvciA2OiBUaGUgSUFOQSBzZWN0aW9uIGRvZXMgbm90IGFuc3dlciBhbGwgdGhlIElB TkEgcXVlc3Rpb25zLg0KPj4NCj4+SXQgaGFzIG1vc3Qgb2YgdGhlIGluZm9ybWF0aW9uLCBidXQg SSB0aGluayBpdCBpcyBub3QgdXAgdG8gdGhlIGxhdGVzdA0KPj5JQU5BIGZvcm1hdCBhbmQgaW5m b3JtYXRpb24uICAgQmFycnkgTGVpYmEgYW5kIG90aGVycyBoYXZlIG5vdGVkIHRoYXQgdGhlDQo+ PlJGQyA3MTgxIGFuZCBSRkM3MTg4IGRvIG5vdCBtYXRjaCB0aGlzIElBTkEgc2VjdGlvbi4gIFJh dGhlciB0aGFuIHJlcGVhdA0KPj50aGVzZSBjb21tZW50cywgSSB3aWxsIHNpbXBsZSBzdGF0ZSB0 aGUgZGF0YSBuZWVkcyB0byBiZSBjb25zaXN0ZW50IGFuZA0KPj50aGUgZm9ybWF0IG1hdGNoIElB TkHCuXMgY29tbWVudHMuDQo+DQo+QmFycnnCuXMgY29tbWVudCBoYXMgYmVlbiBzb2x2ZWQgYW5k IHdpbGwgYmUgcmVmbGVjdGVkIGluIGFuIHVwZGF0ZS4NCj4NCj5UaGUgYXV0aG9ycyBoYXZlIGJl ZW4gdGFsa2luZyB0byBJQU5BIGRpcmVjdGx5LiAgV2UgYXJlIG5vdyB3YWl0aW5nIGZvcg0KPnJl dmlldyBmcm9tIHRoZSBNQU5FVCByZWdpc3RyeSBleHBlcnRzICh3aGljaCBpcyB0aGUgb25lIG9w ZW4gaXRlbSB3aXRoDQo+SUFOQSkuDQo+DQo+VGhhbmtzIQ0KPg0KPkFsdmFyby4NCj4NCg0K From nobody Thu Jun 25 10:22:07 2015 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 4BCB01AC400; Thu, 25 Jun 2015 10:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 kg_iV_-udx_c; Thu, 25 Jun 2015 10:22:00 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D559D1AC408; Thu, 25 Jun 2015 10:21:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.187.115; From: "Susan Hares" To: "'Alvaro Retana \(aretana\)'" , "'Benoit Claise \(bclaise\)'" References: <20150528132630.13861.80616.idtracker@ietfa.amsl.com> In-Reply-To: Date: Thu, 25 Jun 2015 13:21:59 -0400 Message-ID: <011401d0af6b$72770ab0$57652010$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0115_01D0AF49.EB6D0BD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQELvMZoBgjCE5iqXPy91Hp57pY8LwIwXgyBAM9TWuCfL1v7UA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-manet-olsrv2-multitopology@ietf.org, ops-dir@ietf.org, manet@ietf.org, 'The IESG' , manet-chairs@ietf.org Subject: Re: [manet] Benoit Claise's Discuss on draft-ietf-manet-olsrv2-multitopology-05: (with DISCUSS) 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 Jun 2015 17:22:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0115_01D0AF49.EB6D0BD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To the Manet author of the comments:=20 =20 To help with the comments: I've pulled them up.=20 =20 >>The suggestions for tests made in the Ops-Dir review are great! =20 >>However, I don=C2=B9t believe that such detail belongs in this = document,=20 >>where the main purpose is to document the extension. In fact, I think = >>the suggestions belong more as part of a test plan (used by=20 >>implementors =E2=80=B9 similar maybe to the work done in bmwg, for = example),=20 >>which seems to be in line with the >>comments: (Sue wrote) =C2=B3The recommended tests in major concern 1-4 = could=20 >>be created in a separate draft.=C2=B2 =20 Let's go to the higher level purpose rather than the "not my WG charter" = reasoning. =20 =20 If you are running an experiment with this protocol, you need to have = specific details enough to determine if this experimental protocol is a = success. Otherwise, you will continue to have the OLSR vs. AODV-v2, or = vague review on RFC5444 additions to the protocol. This ends up in = emotional debate without substantial experimental results to back it up. = Emotional debates recycle. My suggestions aim at providing enough = detail to settle these arguments with experimental results. MANET has = lots of exciting work to do in the advent of 5G, 802.11ac, and other = mobile network changes.=20 =20 As you noted, the reviews on operational portion of this work points out = how these experimental results are critical to designing an appropriate = operational interface.=20 =20 So.. bottom line... Staying "not in my charter" and asking to pass this = document on without settling on a mechanism to fix it - is a mistake. = Decide how the MANET WG is going to determine this is a success and put = together a plan. BMWG usually does device compliance. If you want aid = on a network-compliance test case, they will work with and review the = document. However, the real expertise is still in MANET.=20 =20 ON IANA ... That's covered by Barry's discuss.=20 =20 Sue=20 =20 PS =E2=80=93 If you are tired of the document and debate, as a WG chair, = I understand. However, the value of the reviews is a fresh set of eyes = and emotions.=20 =20 -----Original Message----- From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]=20 Sent: Thursday, June 25, 2015 11:39 AM To: Benoit Claise (bclaise); Susan Hares Cc: draft-ietf-manet-olsrv2-multitopology@ietf.org; manet@ietf.org; = manet-chairs@ietf.org; The IESG; ops-dir@ietf.org Subject: Re: Benoit Claise's Discuss on = draft-ietf-manet-olsrv2-multitopology-05: (with DISCUSS) =20 Benoit/Sue: =20 Any comments? =20 Thanks! =20 Alvaro. =20 On 6/15/15, 4:02 PM, "Alvaro Retana (aretana)" < = aretana@cisco.com> wrote: =20 >On 5/28/15, 9:26 AM, "Benoit Claise (bclaise)" < = bclaise@cisco.com> wrote: >=20 >[Because the authors didn=C2=B9t have time to review the ops-dir = comments=20 >before the telechat, or before they became a DISCUSS, I=C2=B9m = explicitly=20 >cc=C2=B9ing it here as well as Sue.] >=20 >Benoit: >=20 >Hi! >=20 >Sorry it took me a while to get to this.. >=20 >>---------------------------------------------------------------------- >>DISCUSS: >>---------------------------------------------------------------------- >>=20 >>The multiple points, brought up by Sue part of her OPS-DIR review,=20 >>deserve a DISCUSS. Let's engage in the discussion. >. . . >=20 >=20 >>Summary of Comments: >>=20 >>My comments have 6 major issues, and a set of editorial changes. Five = >>of my major points have to do with adding more details to the draft to = >>judge the experiment valuable. One way to resolve these comments is=20 >>to create document providing details on the test that will be run. A=20 >>second way to resolve these comments on experiment is to provide=20 >>additional high-level guidance in this document. >=20 >Note that section 1.1 (Motivation and Experimentation) already provides = >high-level guidance of the type of information to be evaluated. >=20 > While general experiences with this protocol extension, including > interoperability of implementations, are encouraged, specific > information would be particularly appreciated on the following = areas: >=20 > o Operation in a network that contains both routers implementing > this extension, and routers implementing only [RFC7181], in > particular are there any unexpected interactions that can break > the network? >=20 > o Operation in realistic deployments, and details thereof, = including > in particular indicating how many concurrent topologies were > required. >=20 > A broader issue that applies to unextended [RFC7181] as well as this > extension (and potentially to other MANET routing protocols) is = which > link metric types are useful in a MANET, and how to establish the > metrics to associate with a given link. While this issue is not = only > related to this extension, the ability for an OLSRv2 network to > maintain different concurrent link metrics may facilitate both > experiments with different link metric types, ways to measure them, > etc. and may also allow experimentation with link metric types that > are not compromises to handle multiple traffic types. >=20 >=20 >Clearly the focus is on =C2=B3running code=C2=B2: operation in real = deployments=20 >and mixed environments. >=20 >=20 >The suggestions for tests made in the Ops-Dir review are great! =20 >However, I don=C2=B9t believe that such detail belongs in this = document,=20 >where the main purpose is to document the extension. In fact, I think=20 >the suggestions belong more as part of a test plan (used by=20 >implementors =E2=80=B9 similar maybe to the work done in bmwg, for = example),=20 >which seems to be in line with the >comments: (Sue wrote) =C2=B3The recommended tests in major concern 1-4 = could=20 >be created in a separate draft.=C2=B2 >=20 >It is not in the manet WGs charter to produce test plans. In order to=20 >not loose Sue=C2=B9s valuable input, I suggest we keep them in the = WG=C2=B9s wiki=20 >=E2=80=B9 which will allow for other test cases to be added, details = included,=20 >results reflected, etc. >=20 >=20 >. . . >>Major concern 5: Experiments should drive to create operational=20 >>guidelines for deployment, configuration knobs, and use cases (ADOV-2, = >>OLSR-v2, MT-OLSR-v2) >=20 >Completely agree! Implementation and operational experience (not just >experiments) should in fact result in that type of guidelines. >=20 >Again, the details are not within the scope of this document..and=20 >guidance is already given in 1.1 about the use in real networks. >=20 >Note that this comment mentions not just the extensions proposed, but=20 >the base protocol and even AODVv2. All these guidelines are important=20 >from an operations point of view, but shouldn=C2=B9t be tied to this = document. >=20 >Aside: the MANET WG is in process of rechartering. This type of=20 >suggestions should be presented for discussion. >=20 >=20 >. . . >>Major 6: The IANA section does not answer all the IANA questions. >>=20 >>It has most of the information, but I think it is not up to the latest >>IANA format and information. Barry Leiba and others have noted that = the >>RFC 7181 and RFC7188 do not match this IANA section. Rather than=20 >>repeat these comments, I will simple state the data needs to be=20 >>consistent and the format match IANA=C2=B9s comments. >=20 >Barry=C2=B9s comment has been solved and will be reflected in an = update. >=20 >The authors have been talking to IANA directly. We are now waiting for = >review from the MANET registry experts (which is the one open item with = >IANA). >=20 >Thanks! >=20 >Alvaro. >=20 =20 ------=_NextPart_000_0115_01D0AF49.EB6D0BD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

To = the Manet author of the comments:

 

To = help with the comments:=C2=A0 I've pulled them up.

 

>>The suggestions for tests made in the = Ops-Dir review are great!=C2=A0

>>However, I don=C2=B9t believe that such = detail belongs in this document,

>>where the main purpose is to document the = extension.=C2=A0 In fact, I think

>>the suggestions belong more as part of a = test plan (used by

>>implementors =E2=80=B9 similar maybe to the = work done in bmwg, for example),

>>which seems to be in line with = the

>>comments: (Sue wrote) = =C2=B3The recommended tests in major concern 1-4 could

>>be created in a separate = draft.=C2=B2

 

Let's go to the higher level purpose rather = than the "not my WG charter" reasoning. = =C2=A0

 

If you are running an experiment with this = protocol, you need to have specific details enough to determine if this = experimental protocol is a success.=C2=A0 Otherwise, you will continue = to have the OLSR vs. AODV-v2, or vague review on RFC5444 additions to = the protocol. =C2=A0This ends up in emotional debate without substantial = experimental results to back it up. =C2=A0Emotional debates recycle. My = suggestions aim at providing enough detail to settle these arguments = with experimental results. =C2=A0MANET has lots of exciting work to do = in the advent of 5G, 802.11ac, and other =C2=A0mobile network changes. =

 

As you noted, the reviews on operational portion of = this work points out how these experimental results are critical to = designing an appropriate operational interface.

 

So.. = bottom line... Staying "not in my charter" and asking to pass = this document on without settling on a mechanism to fix it - is a = mistake.=C2=A0 Decide how the MANET WG is going to determine this is a = success and put together a plan.=C2=A0 BMWG usually does device = compliance.=C2=A0 If you want aid on a network-compliance test case, = they will work with =C2=A0and review the document. However, the real = expertise is still in MANET.

=C2=A0

ON = IANA ... That's covered by Barry's discuss.

 

Sue =

 

PS =E2=80=93 If you are tired of the document and = debate, as a WG chair, I understand.=C2=A0 However, the value of the = reviews is a fresh set of eyes and emotions.

 

-----Original Message-----
From: Alvaro Retana = (aretana) [mailto:aretana@cisco.com]
Sent: Thursday, June 25, 2015 = 11:39 AM
To: Benoit Claise (bclaise); Susan Hares
Cc: = draft-ietf-manet-olsrv2-multitopology@ietf.org; manet@ietf.org; = manet-chairs@ietf.org; The IESG; ops-dir@ietf.org
Subject: Re: Benoit = Claise's Discuss on draft-ietf-manet-olsrv2-multitopology-05: (with = DISCUSS)

 

Benoit/Sue:

 

Any = comments?

 

Thanks!

 

Alvaro.

 

On = 6/15/15, 4:02 PM, "Alvaro Retana (aretana)" <aretana@cisco.com<= /a>> wrote:

 

>On = 5/28/15, 9:26 AM, "Benoit Claise (bclaise)" <bclaise@cisco.com<= /a>> wrote:

> 

>[Because the authors didn=C2=B9t have time to = review the ops-dir comments

>before the telechat, or before they became a = DISCUSS, I=C2=B9m explicitly

>cc=C2=B9ing it here as well as = Sue.]

> 

>Benoit:

> 

>Hi!

> 

>Sorry it took me a while to get to = this..

> 

>>--------------------------------------------= --------------------------

>>DISCUSS:

>>--------------------------------------------= --------------------------

>> 

>>The multiple points, brought up by Sue part = of her OPS-DIR review,

>>deserve a DISCUSS. Let's engage in the = discussion.

>. . = .

> 

> 

>>Summary of Comments:

>> 

>>My comments have 6 major issues, and a set = of editorial changes.=C2=A0 Five

>>of my major points have to do with adding = more details to the draft to

>>judge the experiment valuable.=C2=A0 One = way to resolve these comments is

>>to create document providing details on the = test that will be run.=C2=A0 A

>>second way to resolve these comments on = experiment is to provide

>>additional high-level guidance in this = document.

> 

>Note that section 1.1 (Motivation and = Experimentation) already provides

>high-level guidance of the type of information = to be evaluated.

> 

>=C2=A0=C2=A0 While general experiences with = this protocol extension, including

>=C2=A0=C2=A0 interoperability of = implementations, are encouraged, specific

>=C2=A0=C2=A0 information would be particularly = appreciated on the following areas:

> 

>=C2=A0=C2=A0 o=C2=A0 Operation in a network = that contains both routers implementing

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this extension, = and routers implementing only [RFC7181], in

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 particular are = there any unexpected interactions that can break

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the = network?

> 

>=C2=A0=C2=A0 o=C2=A0 Operation in realistic = deployments, and details thereof, including

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in particular = indicating how many concurrent topologies were

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = required.

> 

>=C2=A0=C2=A0 A broader issue that applies to = unextended [RFC7181] as well as this

>=C2=A0=C2=A0 extension (and potentially to = other MANET routing protocols) is which

>=C2=A0=C2=A0 link metric types are useful in a = MANET, and how to establish the

>=C2=A0=C2=A0 metrics to associate with a given = link.=C2=A0 While this issue is not only

>=C2=A0=C2=A0 related to this extension, the = ability for an OLSRv2 network to

>=C2=A0=C2=A0 maintain different concurrent link = metrics may facilitate both

>=C2=A0=C2=A0 experiments with different link = metric types, ways to measure them,

>=C2=A0=C2=A0 etc. and may also allow = experimentation with link metric types that

>=C2=A0=C2=A0 are not compromises to handle = multiple traffic types.

> 

> 

>Clearly the focus is on =C2=B3running = code=C2=B2: operation in real deployments

>and mixed environments.

> 

> 

>The suggestions for tests made in the Ops-Dir = review are great!=C2=A0

>However, I don=C2=B9t believe that such detail = belongs in this document,

>where the main purpose is to document the = extension.=C2=A0 In fact, I think

>the suggestions belong more as part of a test = plan (used by

>implementors = =E2=80=B9 similar maybe to the work done in bmwg, for example), =

>which seems to be in line = with the

>comments: (Sue wrote) = =C2=B3The recommended tests in major concern 1-4 could

>be created in a separate = draft.=C2=B2

> 

>It is not in the manet WGs charter to produce = test plans.=C2=A0 In order to

>not loose Sue=C2=B9s valuable input, I suggest = we keep them in the WG=C2=B9s wiki

>=E2=80=B9 which will allow for other test cases = to be added, details included,

>results reflected, etc.

> 

> 

>. . .

>>Major concern 5:=C2=A0 Experiments should = drive to create operational

>>guidelines for deployment, configuration = knobs, and use cases (ADOV-2,

>>OLSR-v2, MT-OLSR-v2)

> 

>Completely agree!=C2=A0 Implementation and = operational experience (not just

>experiments) should in fact result in that type = of guidelines.

> 

>Again, the details are not within the scope of = this document..and

>guidance = is already given in 1.1 about the use in real networks.

> 

>Note that this comment mentions not just the = extensions proposed, but

>the = base protocol and even AODVv2.=C2=A0 All these guidelines are important =

>from an operations point of = view, but shouldn=C2=B9t be tied to this document.

> 

>Aside: the MANET WG is in process of = rechartering.=C2=A0 This type of

>suggestions should be presented for = discussion.

> 

> 

>. . .

>>Major 6: The IANA section does not answer = all the IANA questions.

>> 

>>It has most of the information, but I think = it is not up to the latest

>>IANA format and information.=C2=A0=C2=A0 = Barry Leiba and others have noted that the

>>RFC 7181 and RFC7188 do not match this IANA = section.=C2=A0 Rather than

>>repeat these comments, I will simple state = the data needs to be

>>consistent and the format match IANA=C2=B9s = comments.

> 

>Barry=C2=B9s comment has been solved and will = be reflected in an update.

> 

>The authors have been talking to IANA = directly.=C2=A0 We are now waiting for

>review from the MANET registry experts (which = is the one open item with

>IANA).

> 

>Thanks!

> 

>Alvaro.

> 

 

------=_NextPart_000_0115_01D0AF49.EB6D0BD0-- From michael.w.benson@boeing.com Fri Jun 26 12:19:29 2015 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 E1B221AC40B for ; Fri, 26 Jun 2015 12:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 dQOGKfTsMoyf for ; Fri, 26 Jun 2015 12:19:27 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DDB1AC3EA for ; Fri, 26 Jun 2015 12:19:27 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id t5QJJRjT006534 for ; Fri, 26 Jun 2015 14:19:27 -0500 Received: from XCH-BLV-312.nw.nos.boeing.com (xch-blv-312.nw.nos.boeing.com [137.136.239.125]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t5QJJQN6006169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 26 Jun 2015 14:19:27 -0500 Received: from XCH-PHX-504.sw.nos.boeing.com ([169.254.5.204]) by XCH-BLV-312.nw.nos.boeing.com ([169.254.12.183]) with mapi id 14.03.0235.001; Fri, 26 Jun 2015 12:19:25 -0700 From: "Benson, Michael W" To: "manet@ietf.org" Thread-Topic: DLEP Draft 14: Discovery Initiation Contradiction/Clarification Thread-Index: AdCwQ4/IDWQitQ/dSzO1Yv6uIDm1FA== Date: Fri, 26 Jun 2015 19:19:25 +0000 Message-ID: <87DE9EF05D35724EAF25741A65FA2BFC27413C70@XCH-PHX-504.sw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_87DE9EF05D35724EAF25741A65FA2BFC27413C70XCHPHX504swnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [manet] DLEP Draft 14: Discovery Initiation Contradiction/Clarification 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, 26 Jun 2015 19:20:38 -0000 --_000_87DE9EF05D35724EAF25741A65FA2BFC27413C70XCHPHX504swnosb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The first paragraph of section 5 states that discovery is initiated in the = DLEP modem by sending a Peer Discovery Signal. The verbiage and diagrams i= n section 2, section 7.1, section 7.2, and appendix A all indicate the proc= ess is initiated by the router, not the modem. Recommend the first paragra= ph of section 5 be changed to indicate that the router initializes the disc= overy process or better clarify that the modem's role in the section 5 verb= iage. Also recommend that the "sending to a well-known multicast address" of sect= ion 5 be stated in the respective 7.1 and 7.2 sections (sending/receiving).= Section 7.1 doesn't specify where the message is sent, while section 7.2 = specifies the modem's response is sent to the unicast address of the origin= ator. From what I am reading, I am assuming the modem is listening for the= peer discovery on the "well known multicast address" and that the router i= s doing the sending. Thanks, Wayne ____________________________________ Michael Wayne Benson Boeing Research & Technology Cyber Systems and Network Technology michael.w.benson@boeing.com Office: (256) 937-5911 --_000_87DE9EF05D35724EAF25741A65FA2BFC27413C70XCHPHX504swnosb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The first paragraph of section 5 states that discove= ry is initiated in the DLEP modem by sending a Peer Discovery Signal. = The verbiage and diagrams in section 2, section 7.1, section 7.2, and appe= ndix A all indicate the process is initiated by the router, not the modem.  Recommend the first paragraph o= f section 5 be changed to indicate that the router initializes the discover= y process or better clarify that the modem’s role in the section 5 ve= rbiage.

 

Also recommend that the “sending to a w= ell-known multicast address” of section 5 be stated in the respective= 7.1 and 7.2 sections (sending/receiving).  Section 7.1 doesn’t = specify where the message is sent, while section 7.2 specifies the modem’s response is sent to the unicast address of the originato= r.  From what I am reading, I am assuming the modem is listening for t= he peer discovery on the “well known multicast address” and tha= t the router is doing the sending.

 

Thanks,

Wayne

____________________________________<= /span>

Michael Wayne Benson

Boeing Research & Technology

Cyber Systems and Network Technology<= /span>

michael.w.benson@boeing.com

Office:  (256) = 937-5911

 

--_000_87DE9EF05D35724EAF25741A65FA2BFC27413C70XCHPHX504swnosb_-- From nobody Fri Jun 26 12:36:51 2015 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 E0D471A9251 for ; Fri, 26 Jun 2015 12:36:49 -0700 (PDT) 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 j5F3KwX5cSh8 for ; Fri, 26 Jun 2015 12:36:47 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id F1A011A8AE4 for ; Fri, 26 Jun 2015 12:36:46 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.203 as permitted sender) identity=mailfrom; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,686,1427774400"; d="scan'208,217";a="8327040" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.203]) by ironport2.idirect.net with ESMTP; 26 Jun 2015 15:36:29 -0400 Received: from VAUSDITCHM3.idirect.net (10.250.250.203) by VAUSDITCHM3.idirect.net (10.250.250.203) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 26 Jun 2015 15:36:29 -0400 Received: from VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226]) by VAUSDITCHM3.idirect.net ([fe80::f4eb:7acb:f0a8:3226%15]) with mapi id 15.00.1076.000; Fri, 26 Jun 2015 15:36:29 -0400 From: "Ratliff, Stanley" To: "Benson, Michael W" , "manet@ietf.org" Thread-Topic: [manet] DLEP Draft 14: Discovery Initiation Contradiction/Clarification Thread-Index: AdCwQ4/IDWQitQ/dSzO1Yv6uIDm1FAAA3xHw Date: Fri, 26 Jun 2015 19:36:28 +0000 Message-ID: <1a69e5cbebee41b4b07060eee99341c0@VAUSDITCHM3.idirect.net> References: <87DE9EF05D35724EAF25741A65FA2BFC27413C70@XCH-PHX-504.sw.nos.boeing.com> In-Reply-To: <87DE9EF05D35724EAF25741A65FA2BFC27413C70@XCH-PHX-504.sw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: multipart/alternative; boundary="_000_1a69e5cbebee41b4b07060eee99341c0VAUSDITCHM3idirectnet_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP Draft 14: Discovery Initiation Contradiction/Clarification 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, 26 Jun 2015 19:36:50 -0000 --_000_1a69e5cbebee41b4b07060eee99341c0VAUSDITCHM3idirectnet_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Wayne, Thanks for the catch. You are correct in that the modem should be listening= on the well-known port; the router optionally sends the Peer Discovery Sig= nal. In earlier revisions, this relationship was flipped, and we missed a refere= nce. Thanks again. Regards, Stan From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Benson, Michael W Sent: Friday, June 26, 2015 3:19 PM To: manet@ietf.org Subject: [manet] DLEP Draft 14: Discovery Initiation Contradiction/Clarific= ation The first paragraph of section 5 states that discovery is initiated in the = DLEP modem by sending a Peer Discovery Signal. The verbiage and diagrams i= n section 2, section 7.1, section 7.2, and appendix A all indicate the proc= ess is initiated by the router, not the modem. Recommend the first paragra= ph of section 5 be changed to indicate that the router initializes the disc= overy process or better clarify that the modem's role in the section 5 verb= iage. Also recommend that the "sending to a well-known multicast address" of sect= ion 5 be stated in the respective 7.1 and 7.2 sections (sending/receiving).= Section 7.1 doesn't specify where the message is sent, while section 7.2 = specifies the modem's response is sent to the unicast address of the origin= ator. From what I am reading, I am assuming the modem is listening for the= peer discovery on the "well known multicast address" and that the router i= s doing the sending. Thanks, Wayne ____________________________________ Michael Wayne Benson Boeing Research & Technology Cyber Systems and Network Technology michael.w.benson@boeing.com Office: (256) 937-5911 _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ --_000_1a69e5cbebee41b4b07060eee99341c0VAUSDITCHM3idirectnet_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Wayne,

 

Thanks for the catch. = You are correct in that the modem should be listening on the well-known por= t; the router optionally sends the Peer Discovery Signal.

 

In earlier revisions, = this relationship was flipped, and we missed a reference.

 

Thanks again.

 

Regards,
Stan

 

 

From: manet [mailto:manet-bounces@ietf.org] <= b>On Behalf Of Benson, Michael W
Sent: Friday, June 26, 2015 3:19 PM
To: manet@ietf.org
Subject: [manet] DLEP Draft 14: Discovery Initiation Contradiction/C= larification

 

The first paragraph of section 5 states that discove= ry is initiated in the DLEP modem by sending a Peer Discovery Signal. = The verbiage and diagrams in section 2, section 7.1, section 7.2, and appe= ndix A all indicate the process is initiated by the router, not the modem.  Recommend the first paragraph o= f section 5 be changed to indicate that the router initializes the discover= y process or better clarify that the modem’s role in the section 5 ve= rbiage.

 

Also recommend that the “sending to a w= ell-known multicast address” of section 5 be stated in the respective= 7.1 and 7.2 sections (sending/receiving).  Section 7.1 doesn’t = specify where the message is sent, while section 7.2 specifies the modem’s response is sent to the unicast address of the originato= r.  From what I am reading, I am assuming the modem is listening for t= he peer discovery on the “well known multicast address” and tha= t the router is doing the sending.

 

Thanks,

Wayne

____________________________________<= /span>

Michael Wayne Benson

Boeing Research & Technology

Cyber Systems and Network Technology<= /span>

m= ichael.w.benson@boeing.com

Office:  (256) = 937-5911

 


_____________________________________________________
= This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
int= ended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
cop= ying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________ = --_000_1a69e5cbebee41b4b07060eee99341c0VAUSDITCHM3idirectnet_-- From nobody Sat Jun 27 05:18:47 2015 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 81A8B1B33C5 for ; Sat, 27 Jun 2015 05:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeVjA1c3Gx11 for ; Sat, 27 Jun 2015 05:18:44 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (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 D765E1B3395 for ; Sat, 27 Jun 2015 05:18:43 -0700 (PDT) Received: by wguu7 with SMTP id u7so107242399wgu.3 for ; Sat, 27 Jun 2015 05:18:42 -0700 (PDT) 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=N1JuGrrnU5vDqy/+hvpLKrZFWWHLdUffKFh8neH/wZc=; b=k0Ep/CCQttBVFIl5euehfUh22UAVpSNLhGHUNance7zn81FjNx4WPjXh+okxV1QNel OXmJhgptpmAjoQcljHp+m8BS2NEAlt56LkoU5YMZyIEm1VLb2PIonkOftLRxOaqg9dAR dOHv1L9i08eMiWn0M2prbMwMNAp+JTs7ffdmAQuUA0Ha7wldaAlQg6nWKa9yaBozrAA8 Sva9AeRpVRg5yxiWRE8HfbyNWCSNTvOxfjIfYbIEBqfq4MGKYt5sYkTQbKpgv0aTPjbv 7oY8ROVsQwAGtFPpcF6yljz8+bbnqtwgULYqspz7kl6bbjP1o2y56FMhYhNpHcgZ0jhl rfuw== X-Received: by 10.180.101.233 with SMTP id fj9mr5419889wib.45.1435407522521; Sat, 27 Jun 2015 05:18:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Sat, 27 Jun 2015 05:18:12 -0700 (PDT) In-Reply-To: <1F5C22A3-80F0-4F34-A13C-5A5C560C3133@fu-berlin.de> References: <1F5C22A3-80F0-4F34-A13C-5A5C560C3133@fu-berlin.de> From: Henning Rogge Date: Sat, 27 Jun 2015 14:18:12 +0200 Message-ID: To: Lotte Steenbrink Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF Subject: Re: [manet] AODVv2 RFC5444 packet changes 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: Sat, 27 Jun 2015 12:18:45 -0000 On Wed, Jun 24, 2015 at 4:27 PM, Lotte Steenbrink wrote: > Hi all, > after a lot of discussion and some consultation with Henning, we've updat= ed AODVv2's RFC5444 packet section so that each Address is now associated w= ith a TLV that can definitively identify the Type of the Address (i.e. Orig= inating Address, Target Address, etc). We've chosen to create a new Address= Block TLV type for this, namely ADDRESS_TYPE. Each address is associated w= ith an ADDRESS_TYPE TLV which contains a specific value encoding the type o= f the address (see Table 12). > Attached you'll find the modified sections. > Additionally, we removed the following two paragraphs from Section 7: > > From 7.1: > The OrigSeqNum data element in a RteMsg MUST apply only to OrigAddr. > Therefore the other address in the AddressList is TargAddr. If the > TargSeqNum data element is included, then it MUST apply only to > TargAddr. > > From 7.2: > The TargSeqNum data element in a RteMsg MUST apply only to TargAddr. > Therefore the other address in the AddressList is OrigAddr. Hi, I contributed to this change and I think it should resolve all of the RFC5444 encoding issues... there is no dependency anymore necessary for the order of addresses, for the splitup into address blocks or on addresses without address block tlvs. It also simplifies a few parts of the encoding which should allow making the "sequence number TLV" a generic TLV for all future RFC5444 messages (same with the PATH COST TLV). Maybe some of the other RFC5444 specialists can have a look, maybe I forgot about something. Henning Rogge From nobody Sun Jun 28 06:15:21 2015 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 451FC1B2CE1 for ; Sun, 28 Jun 2015 06:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 adaCvdKWHE3j for ; Sun, 28 Jun 2015 06:15:19 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (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 B87FA1ACE5E for ; Sun, 28 Jun 2015 06:15:18 -0700 (PDT) Received: by wguu7 with SMTP id u7so121134027wgu.3 for ; Sun, 28 Jun 2015 06:15:17 -0700 (PDT) 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=ly/ZfwRTo/EF3E+I3bwtQbaOZNt7VKbJLOXgC70OefI=; b=lwlI1CbJ/tYFAyY1g9jejI6Gg5PHs2huA+DMVgOQcuOLBvpQ4bb3qceAbSqcYnyH0A KzV+Gb+BmsLrunmSEVS/JG8zwa7alai5/0NQcNvFkhk581Mv3QEYWWszmwC83aFGonmK XkJ6SHWtE1ACDiXqN1+H1TZv95s2vsLVbFkLjDO5zr0V/H1eDadg/NVJltmw1zfQwBqT 426gmOAJqw6+aHnBaSUcUEtPfD+XojyRrB2Ss++pEMlAuNi3NbaTxzHFW3H8KPNiVHeZ vCA3W4DHFSHkpiBGxi+Yqw7UTqfN1EV3tbdhgHnkUYdck9y4yZYRvr/K6xZMuivw7iAd tbIA== X-Received: by 10.194.5.4 with SMTP id o4mr21448611wjo.51.1435497316840; Sun, 28 Jun 2015 06:15:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Sun, 28 Jun 2015 06:14:47 -0700 (PDT) In-Reply-To: <011401d0af6b$72770ab0$57652010$@ndzh.com> References: <20150528132630.13861.80616.idtracker@ietfa.amsl.com> <011401d0af6b$72770ab0$57652010$@ndzh.com> From: Henning Rogge Date: Sun, 28 Jun 2015 15:14:47 +0200 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Benoit Claise \(bclaise\)" , MANET IETF Subject: Re: [manet] Benoit Claise's Discuss on draft-ietf-manet-olsrv2-multitopology-05: (with DISCUSS) 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: Sun, 28 Jun 2015 13:15:20 -0000 On Thu, Jun 25, 2015 at 7:21 PM, Susan Hares wrote: > Let's go to the higher level purpose rather than the "not my WG charter" > reasoning. > > > > If you are running an experiment with this protocol, you need to have > specific details enough to determine if this experimental protocol is a > success. Otherwise, you will continue to have the OLSR vs. AODV-v2, or > vague review on RFC5444 additions to the protocol. This ends up in > emotional debate without substantial experimental results to back it up. > Emotional debates recycle. My suggestions aim at providing enough detail to > settle these arguments with experimental results. MANET has lots of > exciting work to do in the advent of 5G, 802.11ac, and other mobile network > changes. We (Fraunhofer FKIE) need multitopology for our heterogeneous networks... what use is it to talk about "good routing metric" if your video traffic is put onto the VHF link with 20 kBit/s? Different service classes have different needs... and some network/radio technologies would only serve a sub-group of them. Thats why I implemented the multitopology draft while it was in an early draft state. Henning Rogge From nobody Mon Jun 29 15:37:56 2015 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 AF8281AD371; Mon, 29 Jun 2015 15:37:53 -0700 (PDT) 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 yYmM51XS8ShR; Mon, 29 Jun 2015 15:37:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A9B1B29AB; Mon, 29 Jun 2015 15:37:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150629223750.14715.16298.idtracker@ietfa.amsl.com> Date: Mon, 29 Jun 2015 15:37:50 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-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, 29 Jun 2015 22:37:53 -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 : Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Jiazi Yi Benoit Parrein Filename : draft-ietf-manet-olsrv2-multipath-04.txt Pages : 19 Date : 2015-06-29 Abstract: This document specifies a multi-path extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-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 Jun 29 15:58:51 2015 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 699AB1B2CDA for ; Mon, 29 Jun 2015 15:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 2YegzmtqGHUa for ; Mon, 29 Jun 2015 15:58:49 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 79C981B2CD6 for ; Mon, 29 Jun 2015 15:58:49 -0700 (PDT) Received: by wiwl6 with SMTP id l6so114080754wiw.0 for ; Mon, 29 Jun 2015 15:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=r6Cg9AjFfPv28DV3vTDoxQFa6SFFKErnRX93NHCbmVw=; b=N0JEGOLosSPVTx5YyJGXbPoazbvlge8gBsFtKCYLmaIV+OFB9ifUtitTOmyx/BM58x 15fF7DnmbSNwuVYu32pqnlF6ca8VzQWZfF9YsddB4ZqnlQKFROJzuQ0ecwiUGfbdKkoD 520qLl66r5yvpOQDSG+BJ4TTNSTJoDcGgGz51xBMKEnTxYYfo50EQw4NrnmUKNbM6Puh k+Z5kwGAcu8vfyIIMCyJa4kLjyvZxilkwWEC9WaEahqEDaVCwq+LlxPMcxOMrbdSv9uo PhxeVPRYR96TjT1utaEILS35oAGy79vCOv8ataJkvOHNKyM00ZxIcLrsnRNsSLHufTfs sI9w== MIME-Version: 1.0 X-Received: by 10.180.90.209 with SMTP id by17mr27177269wib.2.1435618728141; Mon, 29 Jun 2015 15:58:48 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.28.86.9 with HTTP; Mon, 29 Jun 2015 15:58:48 -0700 (PDT) In-Reply-To: <20150629223750.14715.16298.idtracker@ietfa.amsl.com> References: <20150629223750.14715.16298.idtracker@ietfa.amsl.com> Date: Tue, 30 Jun 2015 00:58:48 +0200 X-Google-Sender-Auth: WKJ29F3VC92ayjPCAi-E0vedai8 Message-ID: From: Jiazi YI To: manet Content-Type: multipart/alternative; boundary=f46d043c80d252e9160519b0085f Archived-At: Subject: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-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: Mon, 29 Jun 2015 22:58:51 -0000 --f46d043c80d252e9160519b0085f Content-Type: text/plain; charset=UTF-8 Hi, We just submitted a new revision of olsrv2-multipath. The updates include: - Changed the SR_OLSRv2 TLV (for identifying a router supporting source routing) from message-type-specific TLV to Message TLV. By doing so, only one additional TLV is needed for the extension. In fact, identifying a source-routing supported router may be useful for other extensions also. - Based on the comments from Philippe ( http://www.ietf.org/mail-archive/web/manet/current/msg17683.html), I added an example in the appendix, which clarifies the choice of the Multi-path Dijkstra algorithm. - Updated the link of the open source implementations. - nits picking. regards Jiazi ---------- Forwarded message ---------- From: Date: Tue, Jun 30, 2015 at 12:37 AM Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt To: i-d-announce@ietf.org Cc: manet@ietf.org 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 : Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Jiazi Yi Benoit Parrein Filename : draft-ietf-manet-olsrv2-multipath-04.txt Pages : 19 Date : 2015-06-29 Abstract: This document specifies a multi-path extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-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 --f46d043c80d252e9160519b0085f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

We just submitted = a new revision of olsrv2-multipath. The updates include:

=C2=A0- Changed the SR_OLSRv2 TLV (for identifying a router supporti= ng source routing) from message-type-specific TLV to Message TLV. By doing = so, only one additional TLV is needed for the extension. In fact, identifyi= ng a source-routing supported router may be useful for other extensions als= o.=C2=A0

=C2=A0 - Based on the comments from Phili= ppe (http://www.ietf.org/mail-archive/web/manet/current/msg17683.html= ), I added an example in the appendix, which clarifies the choice of the Mu= lti-path Dijkstra algorithm.=C2=A0

=C2=A0 - Update= d the link of the open source implementations.=C2=A0

=C2=A0 - nits picking.=C2=A0

regards
=
Jiazi

---------- Forward= ed message ----------
From: <internet-drafts@ie= tf.org>
Date: Tue, Jun 30, 2015 at 12:37 AM
Subject: [m= anet] I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt
To: i-d-announce@ietf.org
Cc: manet@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Mobile Ad-hoc Networks Working Group= of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Multi-path Extension for the Optimized Link State Routing Protocol version= 2 (OLSRv2)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Jiaz= i Yi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Benoit Parrein
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-manet-olsrv2-multipath-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-06-29

Abstract:
=C2=A0 =C2=A0This document specifies a multi-path extension for the Optimiz= ed Link
=C2=A0 =C2=A0State Routing Protocol version 2 (OLSRv2) to discover multiple=
=C2=A0 =C2=A0disjoint paths, so as to improve reliability of the OLSRv2 pro= tocol.
=C2=A0 =C2=A0The interoperability with OLSRv2 is retained.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-manet-olsrv2-multipath/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ie= tf-manet-olsrv2-multipath-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-manet-olsrv2-multipath-04


Please note that it may take a couple of minutes from the time of submissio= n
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

--f46d043c80d252e9160519b0085f-- From nobody Tue Jun 30 01:44:25 2015 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 2652C1A1B7B for ; Tue, 30 Jun 2015 01:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 XJaDNp9wsBWl for ; Tue, 30 Jun 2015 01:44:17 -0700 (PDT) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA931A1B7C for ; Tue, 30 Jun 2015 01:44:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,376,1432594800"; d="scan'208,217";a="805228" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta2.baesystems.com with ESMTP; 30 Jun 2015 09:44:14 +0100 X-IronPort-AV: E=Sophos;i="5.15,376,1432594800"; d="scan'208,217";a="103293523" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 30 Jun 2015 09:44:14 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.12]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 09:44:14 +0100 From: "Dearlove, Christopher (UK)" To: Jiazi YI , manet Thread-Topic: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt Thread-Index: AQHQsr8uCeO7F3OEzk6cOTzzXtl1hJ3Euplw Date: Tue, 30 Jun 2015 08:44:13 +0000 Message-ID: References: <20150629223750.14715.16298.idtracker@ietfa.amsl.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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40F24464GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-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, 30 Jun 2015 08:44:25 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40F24464GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SSBoYXZlbuKAmXQgaGFkIHRpbWUgdG8gcmVhZCB0aGlzIHlldCwgYnV0IGp1c3QgYXMgYW4gaW1t ZWRpYXRlIG9ic2VydmF0aW9uLCBpZiB0aGUgbWVhbmluZyBvZiB0aGlzIFRMViBpcyB0byBzYXkg 4oCcc3VwcG9ydHMgc291cmNlIHJvdXRpbmfigJ0gYW5kIG1heSBiZSBhcHBsaWNhYmxlIG1vcmUg d2lkZWx5LCB0aGVuIFNSX09MU1J2MiBpcyBub3QgYSBnb29kIG5hbWUsIGl0IG5lZWRzIHRvIGJl IGluZGVwZW5kZW50IG9mIE9MU1J2Mi4gU3VpdGFibGUgbmFtZSBkZXBlbmRzIG9uIG5leHQgcG9p bnQsIGJ1dCBhc3N1bWluZyBub3QsIGNvdWxkIGJlIGUuZy4gU09VUkNFX1JPVVRFIChJIGxpa2Ug dG8ga2VlcCBuYW1lcyBkb3duIHRvIG5vIG1vcmUgdGhhbiAxMyBjaGFyYWN0ZXJzLCB0aGV5IGZp dCBiZXR0ZXIgaW4gbWVzc2FnZSBldGMuIHBpY3R1cmVzKS4NCg0KVGhlbiwgaXTigJlzIHdvcnRo IGhhdmluZyBhIHF1aWNrIHRob3VnaHQgYXMgdG8gaG93IGdlbmVyYWwgdGhpcyBzaG91bGQgYmUu IEEgdmFsdWVsZXNzIFRMViB0aGF0IHNheXMg4oCcc3VwcG9ydHMgc291cmNlIHJvdXRpbmfigJ0g aXMgZmluZSwgYW5kIG1pZ2h0IGJlIHRoZSBhbnN3ZXIuIEJ1dCBpdCBjb3VsZCBiZSAoZm9yIGV4 YW1wbGUpIGEgVExWIHRoYXQgY2FycmllcyBpbmZvcm1hdGlvbiBpbiBpdHMgdmFsdWUocykgb25l IHBvc3NpYmlsaXR5IGZvciB3aGljaCBpcyBzb3VyY2Ugcm91dGluZy4NCg0KKElmIG5vIG9uZSBt YWtlIGFueSBzdWdnZXN0aW9uIGFsb25nIHRoZSBsYXR0ZXIgbGluZXMsIHRoZW4gd2hhdOKAmXMg dGhlcmUgaXMg4oCTIGFwYXJ0IGZyb20gbmFtZSDigJMgdGhlIHJpZ2h0IGFuc3dlci4pDQoNCi0t DQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQg KDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0 bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJ bnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENo ZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3 dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExp bWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0 ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1Uy IDdZUA0KDQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEppYXppIFlJDQpTZW50OiAyOSBKdW5lIDIwMTUgMjM6NTkNClRvOiBtYW5ldA0K U3ViamVjdDogW21hbmV0XSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYy LW11bHRpcGF0aC0wNC50eHQNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmln aW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRl cm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVy IHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciBy ZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBs b29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRy YW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9j dW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGlj aW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVz eXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGlu ZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQoqKiogV0FSTklORyAqKioNClRo aXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLCBlaXRo ZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4gQ29uc2lkZXIgY2Fy ZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0 dGFjaG1lbnRzIG9yIHJlcGx5LiBGb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCBTcGVh cnBoaXNoaW5nLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20v aG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvUGFnZXMvU3BlYXJwaGlzaGluZ1RpcHMuYXNw eD4uIElmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRo aXMgcHJvY2Vzcy48aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3Vz JTIwRW1haWxzLnBkZj4NCg0KSGksDQoNCldlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IHJldmlzaW9u IG9mIG9sc3J2Mi1tdWx0aXBhdGguIFRoZSB1cGRhdGVzIGluY2x1ZGU6DQoNCiAtIENoYW5nZWQg dGhlIFNSX09MU1J2MiBUTFYgKGZvciBpZGVudGlmeWluZyBhIHJvdXRlciBzdXBwb3J0aW5nIHNv dXJjZSByb3V0aW5nKSBmcm9tIG1lc3NhZ2UtdHlwZS1zcGVjaWZpYyBUTFYgdG8gTWVzc2FnZSBU TFYuIEJ5IGRvaW5nIHNvLCBvbmx5IG9uZSBhZGRpdGlvbmFsIFRMViBpcyBuZWVkZWQgZm9yIHRo ZSBleHRlbnNpb24uIEluIGZhY3QsIGlkZW50aWZ5aW5nIGEgc291cmNlLXJvdXRpbmcgc3VwcG9y dGVkIHJvdXRlciBtYXkgYmUgdXNlZnVsIGZvciBvdGhlciBleHRlbnNpb25zIGFsc28uDQoNCiAg LSBCYXNlZCBvbiB0aGUgY29tbWVudHMgZnJvbSBQaGlsaXBwZSAoaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTc2ODMuaHRtbCksIEkgYWRkZWQg YW4gZXhhbXBsZSBpbiB0aGUgYXBwZW5kaXgsIHdoaWNoIGNsYXJpZmllcyB0aGUgY2hvaWNlIG9m IHRoZSBNdWx0aS1wYXRoIERpamtzdHJhIGFsZ29yaXRobS4NCg0KICAtIFVwZGF0ZWQgdGhlIGxp bmsgb2YgdGhlIG9wZW4gc291cmNlIGltcGxlbWVudGF0aW9ucy4NCg0KICAtIG5pdHMgcGlja2lu Zy4NCg0KcmVnYXJkcw0KDQpKaWF6aQ0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0t LS0tLS0tLS0NCkZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4+DQpEYXRlOiBUdWUsIEp1biAzMCwgMjAxNSBhdCAxMjozNyBBTQ0K U3ViamVjdDogW21hbmV0XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0 aXBhdGgtMDQudHh0DQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3Vu Y2VAaWV0Zi5vcmc+DQpDYzogbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0K DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIE1vYmlsZSBBZC1ob2MgTmV0d29ya3MgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4N Cg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBNdWx0aS1wYXRoIEV4dGVuc2lvbiBmb3IgdGhl IE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wgdmVyc2lvbiAyIChPTFNSdjIp DQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IEppYXppIFlpDQogICAgICAgICAgICAgICAgICAg ICAgICAgIEJlbm9pdCBQYXJyZWluDQogICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0wNC50eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAg IDogMTkNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNS0wNi0yOQ0KDQpBYnN0cmFjdDoN CiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbXVsdGktcGF0aCBleHRlbnNpb24gZm9yIHRo ZSBPcHRpbWl6ZWQgTGluaw0KICAgU3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9uIDIgKE9M U1J2MikgdG8gZGlzY292ZXIgbXVsdGlwbGUNCiAgIGRpc2pvaW50IHBhdGhzLCBzbyBhcyB0byBp bXByb3ZlIHJlbGlhYmlsaXR5IG9mIHRoZSBPTFNSdjIgcHJvdG9jb2wuDQogICBUaGUgaW50ZXJv cGVyYWJpbGl0eSB3aXRoIE9MU1J2MiBpcyByZXRhaW5lZC4NCg0KDQpUaGUgSUVURiBkYXRhdHJh Y2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC8NCg0KVGhlcmUn cyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTA0DQoNCkEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgt MDQNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRm Lm9yZz4uDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3Vz IEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxp c3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKVGhpcyBlbWFpbCBh bmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJlY2lw aWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlm eSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40F24464GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBoYXZlbuKAmXQgaGFkIHRpbWUgdG8gcmVhZCB0aGlzIHlldCwgYnV0 IGp1c3QgYXMgYW4gaW1tZWRpYXRlIG9ic2VydmF0aW9uLCBpZiB0aGUgbWVhbmluZyBvZiB0aGlz IFRMViBpcyB0byBzYXkg4oCcc3VwcG9ydHMgc291cmNlIHJvdXRpbmfigJ0gYW5kIG1heSBiZSBh cHBsaWNhYmxlDQogbW9yZSB3aWRlbHksIHRoZW4gU1JfT0xTUnYyIGlzIG5vdCBhIGdvb2QgbmFt ZSwgaXQgbmVlZHMgdG8gYmUgaW5kZXBlbmRlbnQgb2YgT0xTUnYyLiBTdWl0YWJsZSBuYW1lIGRl cGVuZHMgb24gbmV4dCBwb2ludCwgYnV0IGFzc3VtaW5nIG5vdCwgY291bGQgYmUgZS5nLiBTT1VS Q0VfUk9VVEUgKEkgbGlrZSB0byBrZWVwIG5hbWVzIGRvd24gdG8gbm8gbW9yZSB0aGFuIDEzIGNo YXJhY3RlcnMsIHRoZXkgZml0IGJldHRlciBpbiBtZXNzYWdlIGV0Yy4NCiBwaWN0dXJlcykuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGVuLCBpdOKAmXMgd29ydGggaGF2aW5nIGEgcXVpY2sgdGhvdWdodCBhcyB0byBo b3cgZ2VuZXJhbCB0aGlzIHNob3VsZCBiZS4gQSB2YWx1ZWxlc3MgVExWIHRoYXQgc2F5cyDigJxz dXBwb3J0cyBzb3VyY2Ugcm91dGluZ+KAnSBpcyBmaW5lLCBhbmQgbWlnaHQgYmUgdGhlIGFuc3dl ci4NCiBCdXQgaXQgY291bGQgYmUgKGZvciBleGFtcGxlKSBhIFRMViB0aGF0IGNhcnJpZXMgaW5m b3JtYXRpb24gaW4gaXRzIHZhbHVlKHMpIG9uZSBwb3NzaWJpbGl0eSBmb3Igd2hpY2ggaXMgc291 cmNlIHJvdXRpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPihJZiBubyBvbmUgbWFrZSBhbnkgc3VnZ2VzdGlvbiBh bG9uZyB0aGUgbGF0dGVyIGxpbmVzLCB0aGVuIHdoYXTigJlzIHRoZXJlIGlzIOKAkyBhcGFydCBm cm9tIG5hbWUg4oCTIHRoZSByaWdodCBhbnN3ZXIuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5p b3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2U8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JF QkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOyYjNDM7NDQgKDApMTI0NSAyNDIxOTQgJm5ic3A7fCAm bmJzcDs8Yj5FOg0KPC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z LmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxs aWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNm b3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5j b20vYWkiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyO3RleHQtZGVjb3JhdGlvbjpub25lIj53 d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4Qjky Ij5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJl ZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBT dXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5KaWF6aSBZSTxicj4NCjxiPlNlbnQ6PC9iPiAyOSBKdW5lIDIwMTUgMjM6 NTk8YnI+DQo8Yj5Ubzo8L2I+IG1hbmV0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFttYW5ldF0gRndk OiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDQudHh0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBw dCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dy b3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4q KiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMg ZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBh cnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVs bHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNo bWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3Jt YXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ry b25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlv dSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVm PSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z cG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwv ZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9s bG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29y ay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lv dXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwv aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0LjBwdCAxLjBwdCA0LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQiPio8c3Ryb25nPioqIFdBUk5JTkcgKioqPC9zdHJv bmc+PC9zcGFuPjxicj4NCjxlbT5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUg b3VyIG9yZ2FuaXphdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUg aW50ZXJuZXQuIENvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24g YW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4gRm9yIGFkZGl0aW9uYWwg aW5mb3JtYXRpb24gYWJvdXQgU3BlYXJwaGlzaGluZywgY2xpY2sNCjxhIGhyZWY9Imh0dHA6Ly9p bnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMv UGFnZXMvU3BlYXJwaGlzaGluZ1RpcHMuYXNweCI+DQpoZXJlPC9hPi4gSWYgeW91IGZlZWwgdGhl IGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyA8YSBocmVmPSJodHRwOi8v aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz L0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnBy b2Nlc3MuPC9hPjwvZW0+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyByZXZpc2lvbiBvZiBv bHNydjItbXVsdGlwYXRoLiBUaGUgdXBkYXRlcyBpbmNsdWRlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDstIENoYW5nZWQgdGhlIFNS X09MU1J2MiBUTFYgKGZvciBpZGVudGlmeWluZyBhIHJvdXRlciBzdXBwb3J0aW5nIHNvdXJjZSBy b3V0aW5nKSBmcm9tIG1lc3NhZ2UtdHlwZS1zcGVjaWZpYyBUTFYgdG8gTWVzc2FnZSBUTFYuIEJ5 IGRvaW5nIHNvLCBvbmx5IG9uZSBhZGRpdGlvbmFsIFRMViBpcyBuZWVkZWQgZm9yIHRoZSBleHRl bnNpb24uIEluIGZhY3QsIGlkZW50aWZ5aW5nIGEgc291cmNlLXJvdXRpbmcgc3VwcG9ydGVkDQog cm91dGVyIG1heSBiZSB1c2VmdWwgZm9yIG90aGVyIGV4dGVuc2lvbnMgYWxzby4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 IC0gQmFzZWQgb24gdGhlIGNvbW1lbnRzIGZyb20gUGhpbGlwcGUgKDxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE3NjgzLmh0bWwi Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE3 NjgzLmh0bWw8L2E+KSwgSSBhZGRlZCBhbiBleGFtcGxlIGluIHRoZSBhcHBlbmRpeCwgd2hpY2gg Y2xhcmlmaWVzDQogdGhlIGNob2ljZSBvZiB0aGUgTXVsdGktcGF0aCBEaWprc3RyYSBhbGdvcml0 aG0uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAtIFVwZGF0ZWQgdGhlIGxpbmsgb2YgdGhlIG9wZW4gc291cmNlIGltcGxl bWVudGF0aW9ucy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0gbml0cyBwaWNraW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWdhcmRzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkppYXppPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1l c3NhZ2UgLS0tLS0tLS0tLTxicj4NCkZyb206ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkRh dGU6IFR1ZSwgSnVuIDMwLCAyMDE1IGF0IDEyOjM3IEFNPGJyPg0KU3ViamVjdDogW21hbmV0XSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDQudHh0PGJyPg0K VG86IDxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmktZC1hbm5vdW5jZUBp ZXRmLm9yZzwvYT48YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5l dEBpZXRmLm9yZzwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3Jp ZXMuPGJyPg0KJm5ic3A7VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTW9iaWxlIEFk LWhvYyBOZXR3b3JrcyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7OiBNdWx0aS1wYXRoIEV4dGVuc2lvbiBmb3IgdGhlIE9wdGltaXplZCBMaW5r IFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wgdmVyc2lvbiAyIChPTFNSdjIpPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7OiBKaWF6aSBZaTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBCZW5v aXQgUGFycmVpbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0 aC0wNC50eHQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMTk8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgRGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogMjAxNS0wNi0yOTxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlz IGRvY3VtZW50IHNwZWNpZmllcyBhIG11bHRpLXBhdGggZXh0ZW5zaW9uIGZvciB0aGUgT3B0aW1p emVkIExpbms8YnI+DQombmJzcDsgJm5ic3A7U3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9u IDIgKE9MU1J2MikgdG8gZGlzY292ZXIgbXVsdGlwbGU8YnI+DQombmJzcDsgJm5ic3A7ZGlzam9p bnQgcGF0aHMsIHNvIGFzIHRvIGltcHJvdmUgcmVsaWFiaWxpdHkgb2YgdGhlIE9MU1J2MiBwcm90 b2NvbC48YnI+DQombmJzcDsgJm5ic3A7VGhlIGludGVyb3BlcmFiaWxpdHkgd2l0aCBPTFNSdjIg aXMgcmV0YWluZWQuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWFu ZXQtb2xzcnYyLW11bHRpcGF0aC88L2E+PGJyPg0KPGJyPg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6 ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0wNCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LW9sc3J2 Mi1tdWx0aXBhdGgtMDQ8L2E+PGJyPg0KPGJyPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDQiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1t YW5ldC1vbHNydjItbXVsdGlwYXRoLTA0PC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+KioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+ClRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxi cj4KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0 ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4KZGlzdHJpYnV0ZSBpdHMg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+CioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9wPjwvYm9keT4N CjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40F24464GLKXM0002VGREEN_-- From nobody Tue Jun 30 02:00:15 2015 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 55AF81A1BEE for ; Tue, 30 Jun 2015 02:00:14 -0700 (PDT) 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 KDpcwgBVqj4v for ; Tue, 30 Jun 2015 02:00:12 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 BD3C21A1B6D for ; Tue, 30 Jun 2015 02:00:11 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so9925812wib.1 for ; Tue, 30 Jun 2015 02:00:10 -0700 (PDT) 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=+1tuXDIpPIm/pgtbiuFsgDb9pJ+csl0DVVNVaydud6E=; b=ce/8TpDmtNL+HMVWsRTDwCnreYZnk89rgxVQgUTopsSLVpEZS3jdPWWczfqhjpko4I mAOZ/aFFFR0aa1uUAOBHYrsTEHsxGrROe07Xn4zCFNk0jpaSnnGf0gqpiG8eHZeb2T6T cHW2nwBfHndS5Q7GRevyLd1p4AcOJUmCiSpLZthfukwqMKYZTh693XVbQziwCZwzjK9o I/bbNZi1BOWCDXPqCmqeszZAJACUT4NphmA8tKNh5Bv9akZ4eLAQO0Zz9wQ3rrAFLtx6 l/BpRF506VTDhkNGO5jSzuSL9P+P1OFRgaiZDrmHR5T5IKi1a1HoIqo62wdDO1FVp8rn FCag== X-Received: by 10.194.203.3 with SMTP id km3mr34817722wjc.114.1435654810477; Tue, 30 Jun 2015 02:00:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Tue, 30 Jun 2015 01:59:41 -0700 (PDT) In-Reply-To: References: <20150629223750.14715.16298.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Tue, 30 Jun 2015 10:59:41 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: manet Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-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, 30 Jun 2015 09:00:14 -0000 On Tue, Jun 30, 2015 at 10:44 AM, Dearlove, Christopher (UK) wrote: > I haven=E2=80=99t had time to read this yet, but just as an immediate obs= ervation, > if the meaning of this TLV is to say =E2=80=9Csupports source routing=E2= =80=9D and may be > applicable more widely, then SR_OLSRv2 is not a good name, it needs to be > independent of OLSRv2. Suitable name depends on next point, but assuming > not, could be e.g. SOURCE_ROUTE (I like to keep names down to no more tha= n > 13 characters, they fit better in message etc. pictures). > > Then, it=E2=80=99s worth having a quick thought as to how general this sh= ould be. A > valueless TLV that says =E2=80=9Csupports source routing=E2=80=9D is fine= , and might be the > answer. But it could be (for example) a TLV that carries information in i= ts > value(s) one possibility for which is source routing. We will need something similar for "source specific routing" too. Maybe we could start a "NODE_CAPABILITY" TLV which contains a bit-array? And the first allocated bit in this array will be "supports source-routing"= ? Henning Rogge From nobody Tue Jun 30 05:38:13 2015 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 60A061A8BB4 for ; Tue, 30 Jun 2015 05:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 YGZ-z8R70aNy for ; Tue, 30 Jun 2015 05:38:05 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 086271A8BB3 for ; Tue, 30 Jun 2015 05:38:05 -0700 (PDT) Received: by wiga1 with SMTP id a1so97034944wig.0 for ; Tue, 30 Jun 2015 05:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=a2F/mfcZp28/QRSvrrDF+047r9KYbiEBhBsxJF3t/4g=; b=PEJxjwLMEPz4Wp/HjKEjMfT00ci2ODQEt5zcrFu4Ij2lA5P929+1wcRSOUZQe/S7Al 9fi6N7+c89lBlLaIWXQPH6eDuXnlnoNjyQqwkm++TBlBhCeNoad7tQBQSSDAvSR9BrR9 C1DwSR2sTumXuDpuP29AC6saDb0kONSjTlamVrWD8WcuFOcDf9MwwaLu8+Xm3IQ+z9Zj Wxf8MNKzka2eFfVCuBrpXn85+vfABRHO4/c4XrywXFE4sQFc3auiR8p5/M1uf1v8DOQa hP8qT132v12OGDkdajXcGyNviBzq2AuwYWg8D5cPKltNBUavS+0tIiJhGqK0s1dJ1Alq fxDQ== MIME-Version: 1.0 X-Received: by 10.194.62.228 with SMTP id b4mr40547409wjs.2.1435667883751; Tue, 30 Jun 2015 05:38:03 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.28.86.9 with HTTP; Tue, 30 Jun 2015 05:38:03 -0700 (PDT) In-Reply-To: References: <20150629223750.14715.16298.idtracker@ietfa.amsl.com> Date: Tue, 30 Jun 2015 14:38:03 +0200 X-Google-Sender-Auth: 4iey9HDIuUJe8opm9jWr8fpF9WQ Message-ID: From: Jiazi YI To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7bacc1103a009a0519bb7a3e Archived-At: Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-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, 30 Jun 2015 12:38:11 -0000 --047d7bacc1103a009a0519bb7a3e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks to Chris and Henning. I think it's a good idea. Restricting the source-routing flag to OLSRv2 is not necessary. best Jiazi On Tue, Jun 30, 2015 at 10:59 AM, Henning Rogge wrote: > On Tue, Jun 30, 2015 at 10:44 AM, Dearlove, Christopher (UK) > wrote: > > I haven=E2=80=99t had time to read this yet, but just as an immediate > observation, > > if the meaning of this TLV is to say =E2=80=9Csupports source routing= =E2=80=9D and may be > > applicable more widely, then SR_OLSRv2 is not a good name, it needs to = be > > independent of OLSRv2. Suitable name depends on next point, but assumin= g > > not, could be e.g. SOURCE_ROUTE (I like to keep names down to no more > than > > 13 characters, they fit better in message etc. pictures). > > > > Then, it=E2=80=99s worth having a quick thought as to how general this = should > be. A > > valueless TLV that says =E2=80=9Csupports source routing=E2=80=9D is fi= ne, and might be > the > > answer. But it could be (for example) a TLV that carries information in > its > > value(s) one possibility for which is source routing. > > We will need something similar for "source specific routing" too. > > Maybe we could start a "NODE_CAPABILITY" TLV which contains a bit-array? > > And the first allocated bit in this array will be "supports > source-routing" ? > > Henning Rogge > --047d7bacc1103a009a0519bb7a3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks to Chris and Henning.=C2=A0

I th= ink it's a good idea. Restricting the source-routing flag to OLSRv2 is = not necessary.=C2=A0

best

Jiazi

On Tue, Jun 30, 2015 at 10:59 A= M, Henning Rogge <hrogge@gmail.com> wrote:
On Tue, Jun 30, 2015 at 10:44 AM, Dearlove= , Christopher (UK)
<chris.dearlove@baesyst= ems.com> wrote:
> I haven=E2=80=99t had time to read this yet, but just as an immediate = observation,
> if the meaning of this TLV is to say =E2=80=9Csupports source routing= =E2=80=9D and may be
> applicable more widely, then SR_OLSRv2 is not a good name, it needs to= be
> independent of OLSRv2. Suitable name depends on next point, but assumi= ng
> not, could be e.g. SOURCE_ROUTE (I like to keep names down to no more = than
> 13 characters, they fit better in message etc. pictures).
>
> Then, it=E2=80=99s worth having a quick thought as to how general this= should be. A
> valueless TLV that says =E2=80=9Csupports source routing=E2=80=9D is f= ine, and might be the
> answer. But it could be (for example) a TLV that carries information i= n its
> value(s) one possibility for which is source routing.

We will need something similar for "source specific routing&quo= t; too.

Maybe we could start a "NODE_CAPABILITY" TLV which contains a bit= -array?

And the first allocated bit in this array will be "supports source-rou= ting" ?

Henning Rogge

--047d7bacc1103a009a0519bb7a3e-- From nobody Tue Jun 30 06:03:22 2015 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 D14801ACEA1 for ; Tue, 30 Jun 2015 06:03:21 -0700 (PDT) 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 l7NrOWDD11bC for ; Tue, 30 Jun 2015 06:03:19 -0700 (PDT) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30601A90C8 for ; Tue, 30 Jun 2015 06:03:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,377,1432594800"; d="scan'208";a="830431" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta2.baesystems.com with ESMTP; 30 Jun 2015 14:03:09 +0100 X-IronPort-AV: E=Sophos;i="5.15,377,1432594800"; d="scan'208";a="103354173" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 30 Jun 2015 14:03:09 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.12]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 14:03:08 +0100 From: "Dearlove, Christopher (UK)" To: Jiazi YI , Henning Rogge Thread-Topic: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt Thread-Index: AQHQsr8uCeO7F3OEzk6cOTzzXtl1hJ3Euplw///1WICAAD0DgIAAFPfA Date: Tue, 30 Jun 2015 13:03:07 +0000 Message-ID: References: <20150629223750.14715.16298.idtracker@ietfa.amsl.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="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: manet Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-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, 30 Jun 2015 13:03:22 -0000 Rm9yIHNvbWUgcmVhc29uIEhlbm5pbmfigJlzIG1lc3NhZ2UgaGFzbuKAmXQgcmVhY2hlZCBtZSwg ZXhjZXB0IGFzIHF1b3RlZCBoZXJlLg0KDQpJZiB3ZSBhZ3JlZSB0aGVyZSBhcmUgcG9zc2libGUg YXR0cmlidXRlcyB0byBpbmRpY2F0ZSwgc291cmNlIHJvdXRpbmcgYmVpbmcgb25lLCB0aGVuIEkg Y2FuIHNlZSBhdCBsZWFzdCB0aHJlZSB3YXlzIHRvIGRvIHRoYXQuIEhlcmUgSeKAmW0gbm90IHRy eWluZyB0byBpbmRpY2F0ZSBhIHByZWZlcmVuY2UuDQoNCihhKSBXZSB1c2UgYSBiaXQgdmVjdG9y LiBXaGlsZSB0aGVyZSBhcmUgbm8gbW9yZSB0aGFuIGVpZ2h0IGF0dHJpYnV0ZXMgZGVmaW5lZCB0 aGlzIHRha2VzIGEgc2luZ2xlIG9jdGV0IHZhbHVlLCBidXQgbWlnaHQgbmVlZCBtb3JlIGxhdGVy LiAoVGhhdCB3b3VsZCBiZSBiYWNrd2FyZGx5IGNvbXBhdGlibGUgdXNpbmcgUkZDIDcxODggcnVs ZXMuKQ0KKGIpIFdlIGRlZmluZSB2YWx1ZXMsIHNpbWlsYXJseSB0byBUTFZzIGxpa2UgTElOS19T VEFUVVMuIERpZmZlcmVuY2UgaXMgdGhhdCB3ZSBtaWdodCBzb21ldGltZXMgbmVlZCBtb3JlIHRo YW4gb25lIHZhbHVlLCB3aGljaCBsZWFkcyB0byBhIHZhcmlhYmxlIHNpemVkIFRMViB2YWx1ZSwg b3IgbXVsdGlwbGUgdXNlIG9mIHRoZSBUTFYuDQooYykgV2UgbGV0IHRoZSBtZWFuaW5nIGJlIGEg dHlwZSBleHRlbnNpb24uIFNvdXJjZSByb3V0ZWQgd291bGQgKHVubGVzcyBkZWNpZGVkIG90aGVy d2lzZSkgZ2V0IHRoZSBwbHVtIHR5cGUgZXh0ZW5zaW9uIHplcm8gdGhhdCBjYW4gYmUgb21pdHRl ZCBkYXRhIHBvaW50LiBNdWx0aXBsZSBjYXNlcyBuZWVkIG11bHRpcGxlIFRMVnMuDQoNClRoZXJl IGFyZSB2YXJpb3VzIHRyYWRlb2ZmcyBpbiB0aGUgYWJvdmUgaW4gdGVybXMgb2Ygc3BhY2UgYW5k IHNpbXBsaWNpdHkgLSBhbmQgdGhlIGltcGFjdCBvbiB0aGlzIGRyYWZ0IC0gdGhhdCBJJ20gbm90 IGdvaW5nIHRvIGF0dGVtcHQgdG8gaW5kaWNhdGUgaGVyZS4gKElmIGFueSBkaXNjdXNzaW9uIGhh cHBlbnMgSSBtYXkgdGhlbiBpbmRpY2F0ZSBhIHByZWZlcmVuY2UuKSBBbmQgb2YgY291cnNlIEkg bWF5IGhhdmUgb3Zlcmxvb2tlZCBhIChkKS4NCg0KLS0gDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0K U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNClQ6IMKgKzQ0ICgwKTEyNDUgMjQyMTk0IMKgfCDCoEU6 IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50 ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVs bXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpDQpCQUUgU3lzdGVt cyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBX YWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFy aywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KDQpGcm9tOiB5aS5qaWF6aUBnbWFpbC5j b20gW21haWx0bzp5aS5qaWF6aUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBKaWF6aSBZSQ0KU2Vu dDogMzAgSnVuZSAyMDE1IDEzOjM4DQpUbzogSGVubmluZyBSb2dnZQ0KQ2M6IERlYXJsb3ZlLCBD aHJpc3RvcGhlciAoVUspOyBtYW5ldA0KU3ViamVjdDogUmU6IFttYW5ldF0gRndkOiBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDQudHh0DQoNCg0KKioqIFdB Uk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2Fu aXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQu DQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5r cywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJk aW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVj ZWl2ZSwgY2xpY2sgaGVyZS4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBw bGVhc2UgZm9sbG93IHRoaXMgcHJvY2Vzcy4NClRoYW5rcyB0byBDaHJpcyBhbmQgSGVubmluZy7C oA0KDQpJIHRoaW5rIGl0J3MgYSBnb29kIGlkZWEuIFJlc3RyaWN0aW5nIHRoZSBzb3VyY2Utcm91 dGluZyBmbGFnIHRvIE9MU1J2MiBpcyBub3QgbmVjZXNzYXJ5LsKgDQoNCmJlc3QNCg0KSmlhemkN Cg0KT24gVHVlLCBKdW4gMzAsIDIwMTUgYXQgMTA6NTkgQU0sIEhlbm5pbmcgUm9nZ2UgPGhyb2dn ZUBnbWFpbC5jb20+IHdyb3RlOg0KT24gVHVlLCBKdW4gMzAsIDIwMTUgYXQgMTA6NDQgQU0sIERl YXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQo8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+ IHdyb3RlOg0KPiBJIGhhdmVu4oCZdCBoYWQgdGltZSB0byByZWFkIHRoaXMgeWV0LCBidXQganVz dCBhcyBhbiBpbW1lZGlhdGUgb2JzZXJ2YXRpb24sDQo+IGlmIHRoZSBtZWFuaW5nIG9mIHRoaXMg VExWIGlzIHRvIHNheSDigJxzdXBwb3J0cyBzb3VyY2Ugcm91dGluZ+KAnSBhbmQgbWF5IGJlDQo+ IGFwcGxpY2FibGUgbW9yZSB3aWRlbHksIHRoZW4gU1JfT0xTUnYyIGlzIG5vdCBhIGdvb2QgbmFt ZSwgaXQgbmVlZHMgdG8gYmUNCj4gaW5kZXBlbmRlbnQgb2YgT0xTUnYyLiBTdWl0YWJsZSBuYW1l IGRlcGVuZHMgb24gbmV4dCBwb2ludCwgYnV0IGFzc3VtaW5nDQo+IG5vdCwgY291bGQgYmUgZS5n LiBTT1VSQ0VfUk9VVEUgKEkgbGlrZSB0byBrZWVwIG5hbWVzIGRvd24gdG8gbm8gbW9yZSB0aGFu DQo+IDEzIGNoYXJhY3RlcnMsIHRoZXkgZml0IGJldHRlciBpbiBtZXNzYWdlIGV0Yy4gcGljdHVy ZXMpLg0KPg0KPiBUaGVuLCBpdOKAmXMgd29ydGggaGF2aW5nIGEgcXVpY2sgdGhvdWdodCBhcyB0 byBob3cgZ2VuZXJhbCB0aGlzIHNob3VsZCBiZS4gQQ0KPiB2YWx1ZWxlc3MgVExWIHRoYXQgc2F5 cyDigJxzdXBwb3J0cyBzb3VyY2Ugcm91dGluZ+KAnSBpcyBmaW5lLCBhbmQgbWlnaHQgYmUgdGhl DQo+IGFuc3dlci4gQnV0IGl0IGNvdWxkIGJlIChmb3IgZXhhbXBsZSkgYSBUTFYgdGhhdCBjYXJy aWVzIGluZm9ybWF0aW9uIGluIGl0cw0KPiB2YWx1ZShzKSBvbmUgcG9zc2liaWxpdHkgZm9yIHdo aWNoIGlzIHNvdXJjZSByb3V0aW5nLg0KDQpXZSB3aWxsIG5lZWQgc29tZXRoaW5nIHNpbWlsYXIg Zm9yICJzb3VyY2Ugc3BlY2lmaWMgcm91dGluZyIgdG9vLg0KDQpNYXliZSB3ZSBjb3VsZCBzdGFy dCBhICJOT0RFX0NBUEFCSUxJVFkiIFRMViB3aGljaCBjb250YWlucyBhIGJpdC1hcnJheT8NCg0K QW5kIHRoZSBmaXJzdCBhbGxvY2F0ZWQgYml0IGluIHRoaXMgYXJyYXkgd2lsbCBiZSAic3VwcG9y dHMgc291cmNlLXJvdXRpbmciID8NCg0KSGVubmluZyBSb2dnZQ0KDQoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlz IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5k ZWQKcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBh bmQgbm90aWZ5IHRoZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZv ciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8g YW55IG90aGVyIHBlcnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioK From nobody Tue Jun 30 06:22:54 2015 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 317ED1AD062 for ; Tue, 30 Jun 2015 06:22:52 -0700 (PDT) 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 h-pXPC_yZop3 for ; Tue, 30 Jun 2015 06:22:48 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238051AD061 for ; Tue, 30 Jun 2015 06:22:48 -0700 (PDT) Received: by wgjx7 with SMTP id x7so9611828wgj.2 for ; Tue, 30 Jun 2015 06:22:46 -0700 (PDT) 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=kPHYdSGW2sCwItP8V7WwUeDOtbhijf9DqdEl+iwIwGE=; b=04MdTGjJ5ZbejW6u7nATmijBggZ+oqzZwzELTjdHYq1bjm/tPsKJt812lxiP/5R2Q0 e+8F1UE0AGDq1nsolaCxCxyvkqIDjwdld/ulYRWPdxMlbXuV2fiwuCCWKbFoGlv+bn69 DxwDL41CCxH9OTBp2X7YdLlxQ9YIPnbpLI5LZGaJCkysEhQ38MU1WM3+14H9b5wkfnyh 1LIE+HoSsdQNbdwFC9SOmRtsPPdfdV7gSHd073uNk68ti8av541wOQdurHW7CdHUENVR 52yKjX+MWfnihv1VN+UyfzAI7Ot93gmxzNxZKTnd2WoAC8XI7rSoGYCQgyjktQQV8ZFA PrUQ== X-Received: by 10.194.203.3 with SMTP id km3mr36646940wjc.114.1435670566850; Tue, 30 Jun 2015 06:22:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Tue, 30 Jun 2015 06:22:17 -0700 (PDT) In-Reply-To: References: <20150629223750.14715.16298.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Tue, 30 Jun 2015 15:22:17 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: manet Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-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, 30 Jun 2015 13:22:52 -0000 On Tue, Jun 30, 2015 at 3:03 PM, Dearlove, Christopher (UK) wrote: > For some reason Henning=E2=80=99s message hasn=E2=80=99t reached me, exce= pt as quoted here. > > If we agree there are possible attributes to indicate, source routing bei= ng one, then I can see at least three ways to do that. Here I=E2=80=99m not= trying to indicate a preference. > > (a) We use a bit vector. While there are no more than eight attributes de= fined this takes a single octet value, but might need more later. (That wou= ld be backwardly compatible using RFC 7188 rules.) A bit vector would be fine, especially if we allow to increase the length later. This would give us "as many capabilities as we want", not that I expect that many. Henning From nobody Tue Jun 30 06:27:06 2015 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 8C6CC1AD09F for ; Tue, 30 Jun 2015 06:27:05 -0700 (PDT) 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 Loy0o6FKL_Gk for ; Tue, 30 Jun 2015 06:26:59 -0700 (PDT) Received: from ukmta4.baesystems.com (ukmta4.baesystems.com [20.133.40.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378351AD06C for ; Tue, 30 Jun 2015 06:26:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,377,1432594800"; d="scan'208";a="456693" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta4.baesystems.com with ESMTP; 30 Jun 2015 14:26:57 +0100 X-IronPort-AV: E=Sophos;i="5.15,377,1432594800"; d="scan'208";a="107481616" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 30 Jun 2015 14:26:57 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.12]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 14:26:57 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt Thread-Index: AQHQszfpB15XYoXUJEWNsQ2igdIVUp3FCk3A Date: Tue, 30 Jun 2015 13:26:56 +0000 Message-ID: References: <20150629223750.14715.16298.idtracker@ietfa.amsl.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="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: manet Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-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, 30 Jun 2015 13:27:05 -0000 SXMgIndvdWxkIGJlIGZpbmUiIHRoZSBzYW1lIGFzICJteSBwcmVmZXJlbmNlIGFtb25nIG9wdGlv bnMiPw0KDQotLSANCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2lu ZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZQ0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KVDogwqArNDQgKDApMTI0NSAyNDIxOTQgwqB8IMKgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQg VGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4u DQp3d3cuYmFlc3lzdGVtcy5jb20vYWkNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl IExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVn aXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwg R1UyIDdZUA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1hbmV0IFtt YWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhlbm5pbmcgUm9nZ2UN ClNlbnQ6IDMwIEp1bmUgMjAxNSAxNDoyMg0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp DQpDYzogbWFuZXQNClN1YmplY3Q6IFJlOiBbbWFuZXRdIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTA0LnR4dA0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2lu YXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJu YWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0 aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBv ciByZXBseS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJ VCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwg bWVzc2FnZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZy b20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0 bmVyIG9yIHRoZSBpbnRlcm5ldC4gQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3Vs ZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5LiBGb3Ig YWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCBTcGVhcnBoaXNoaW5nLCBjbGljayBoZXJlIDxo dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90 bGlnaHRzL1BhZ2VzL1NwZWFycGhpc2hpbmdUaXBzLmFzcHg+LiBJZiB5b3UgZmVlbCB0aGUgZW1h aWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3MuIDxodHRwOi8vaW50 cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0Rv Y3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPg0KDQpPbiBU dWUsIEp1biAzMCwgMjAxNSBhdCAzOjAzIFBNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8 Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+IHdyb3RlOg0KPiBGb3Igc29tZSByZWFzb24g SGVubmluZ+KAmXMgbWVzc2FnZSBoYXNu4oCZdCByZWFjaGVkIG1lLCBleGNlcHQgYXMgcXVvdGVk IGhlcmUuDQo+DQo+IElmIHdlIGFncmVlIHRoZXJlIGFyZSBwb3NzaWJsZSBhdHRyaWJ1dGVzIHRv IGluZGljYXRlLCBzb3VyY2Ugcm91dGluZyBiZWluZyBvbmUsIHRoZW4gSSBjYW4gc2VlIGF0IGxl YXN0IHRocmVlIHdheXMgdG8gZG8gdGhhdC4gSGVyZSBJ4oCZbSBub3QgdHJ5aW5nIHRvIGluZGlj YXRlIGEgcHJlZmVyZW5jZS4NCj4NCj4gKGEpIFdlIHVzZSBhIGJpdCB2ZWN0b3IuIFdoaWxlIHRo ZXJlIGFyZSBubyBtb3JlIHRoYW4gZWlnaHQgYXR0cmlidXRlcyANCj4gZGVmaW5lZCB0aGlzIHRh a2VzIGEgc2luZ2xlIG9jdGV0IHZhbHVlLCBidXQgbWlnaHQgbmVlZCBtb3JlIGxhdGVyLiANCj4g KFRoYXQgd291bGQgYmUgYmFja3dhcmRseSBjb21wYXRpYmxlIHVzaW5nIFJGQyA3MTg4IHJ1bGVz LikNCg0KQSBiaXQgdmVjdG9yIHdvdWxkIGJlIGZpbmUsIGVzcGVjaWFsbHkgaWYgd2UgYWxsb3cg dG8gaW5jcmVhc2UgdGhlIGxlbmd0aCBsYXRlci4gVGhpcyB3b3VsZCBnaXZlIHVzICJhcyBtYW55 IGNhcGFiaWxpdGllcyBhcyB3ZSB3YW50Iiwgbm90IHRoYXQgSSBleHBlY3QgdGhhdCBtYW55Lg0K DQpIZW5uaW5nDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50 IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQK cmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRo ZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9z ZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioK From nobody Tue Jun 30 06:29:05 2015 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 4CDF61AD0A9 for ; Tue, 30 Jun 2015 06:29:03 -0700 (PDT) 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 6zke0BIq0pkI for ; Tue, 30 Jun 2015 06:29:02 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 0C5C91AD09F for ; Tue, 30 Jun 2015 06:29:02 -0700 (PDT) Received: by wicgi11 with SMTP id gi11so16758519wic.0 for ; Tue, 30 Jun 2015 06:29:00 -0700 (PDT) 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=pIrg7VXgayJWP8ZnhceCD4NM+ceXNE1Co+z08BOjT2I=; b=lf4d1I8/0M4KNu71tEU+4xB2MbEfHEMnln6+6N4SNPo0XoEQI2b6UOxh4tRgcIv2BK ++lca6jINfUjuXfInrPUEEaZy54BFgBmqn/U5a7YikaC/XIfeMp/s9lMnROiZaou3uFw Yc6ITFPYKRboft4fZGPwa7oGWhOOzfPYfES9eEkVkafyBFQa9H2jIgbvQbUspKXBzihG to09Y4S+iun/IvFV1W7geU1nR/v5FjWQc1UvBcuB8bYemmqCebA8YvUalJHTKp7YiCoV Lcro43VSb7zkXI1YboYBiY0dk8J9sWiWiR7oiNeRl0IT6E/R4cvdqq5PlDStauPWG54j EQCg== X-Received: by 10.194.5.4 with SMTP id o4mr42060661wjo.51.1435670940763; Tue, 30 Jun 2015 06:29:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.223.205 with HTTP; Tue, 30 Jun 2015 06:28:31 -0700 (PDT) In-Reply-To: References: <20150629223750.14715.16298.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Tue, 30 Jun 2015 15:28:31 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: manet Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-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, 30 Jun 2015 13:29:03 -0000 On Tue, Jun 30, 2015 at 3:26 PM, Dearlove, Christopher (UK) wrote: > Is "would be fine" the same as "my preference among options"? Yes... especially if we keep it constraint to "binary capabilities"... something a node does support or does not support. Anything more complicated should have a TLV of its own. Henning From nobody Tue Jun 30 07:37:05 2015 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 7F6D91A1A59 for ; Tue, 30 Jun 2015 07:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 ithOyhKVTaCl for ; Tue, 30 Jun 2015 07:37:01 -0700 (PDT) Received: from ukmta4.baesystems.com (ukmta4.baesystems.com [20.133.40.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9765C1A9024 for ; Tue, 30 Jun 2015 07:36:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,378,1432594800"; d="scan'208,217";a="461944" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta4.baesystems.com with ESMTP; 30 Jun 2015 15:35:59 +0100 X-IronPort-AV: E=Sophos;i="5.15,378,1432594800"; d="scan'208,217";a="107498152" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 30 Jun 2015 15:35:59 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.12]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 15:35:59 +0100 From: "Dearlove, Christopher (UK)" To: Jiazi YI , manet Thread-Topic: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-04.txt Thread-Index: AQHQsr8uCeO7F3OEzk6cOTzzXtl1hJ3FHUqA Date: Tue, 30 Jun 2015 14:35:58 +0000 Message-ID: References: <20150629223750.14715.16298.idtracker@ietfa.amsl.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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40F246F4GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-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, 30 Jun 2015 14:37:04 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40F246F4GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 VGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpc27igJl0IHJpZ2h0LiBPZiBjb3Vyc2Ug ZXhhY3RseSB3aGF0IGl0IHNob3VsZCBsb29rIGxpa2UgZGVwZW5kcyBvbiBjdXJyZW50IGNvbnNp ZGVyYXRpb24sIGJ1dCBmaXJzdCB5b3UgbmVlZCB0byByZXF1ZXN0IGEgVExWIGZyb20gdGhlIE1l c3NhZ2UgVExWcyByZWdpc3RyeS4gWW91IGRvbuKAmXQgZ2V0IHRvIGNob29zZSB0aGUgbnVtYmVy LCBqdXN0IFRCRC4gVGhhdCByZXF1aXJlcyB5b3UgdG8gY3JlYXRlIGEgdHlwZSBleHRlbnNpb25z IHJlZ2lzdHJ5IGZvciB0aGF0IHR5cGUuIFRoZSBuYW1pbmcgc3R5bGUgYW5kIHRhYmxlIGxheW91 dCB5b3Ugc2hvdWxkIHRha2UgZnJvbSB0aGUgSUFOQSByZWdpc3RyeSBhcyBtb2RpZmllZCBieSB0 aGUgVExWIG5hbWluZyBkcmFmdCAoYWxyZWFkeSBjaGFuZ2VkIGJ5IElBTkEgYXMgdGhhdCBkcmFm dCBpcyB3aXRoIHRoZSBSRkMgZWRpdG9yKS4gKFlvdSBjYW4gcHJvYmFibHkgc3RlYWwgZnJvbSB0 aGF0IGRyYWZ04oCZcyBYTUwuKSBZb3UgbWF5IHRoZW4gbmVlZCAodHdvIG9mIHRoZSB0aHJlZSBv cHRpb25zIEkgaW5kaWNhdGVkLCBidXQgbm90IHRoaXMgYXMgaXQgY3VycmVudGx5IHN0YW5kcykg YSBmdXJ0aGVyIGRlZmluaXRpb24gb2YgdGhlIHZhbHVlLCBwcm9iYWJseSBuZWVkaW5nIGFub3Ro ZXIgdGFibGUuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBF bmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBH cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5j b20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQg SW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAw MTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZv cmQsIFN1cnJleSwgR1UyIDdZUA0KDQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppYXppIFlJDQpTZW50OiAyOSBKdW5lIDIwMTUgMjM6 NTkNClRvOiBtYW5ldA0KU3ViamVjdDogW21hbmV0XSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWll dGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0wNC50eHQNCg0KDQoqKiogV0FSTklORyAqKioNClRo aXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRo ZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNh cmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBh dHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdz IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBo ZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5 L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUg ZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2lu dHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9E b2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQoqKiog V0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3Jn YW5pemF0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5l dC4gQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlu a3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5LiBGb3IgYWRkaXRpb25hbCBpbmZvcm1h dGlvbiBhYm91dCBTcGVhcnBoaXNoaW5nLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQu YmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvUGFnZXMvU3BlYXJw aGlzaGluZ1RpcHMuYXNweD4uIElmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBw bGVhc2UgZm9sbG93IHRoaXMgcHJvY2Vzcy48aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1z LmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdp dGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4NCg0KSGksDQoNCldlIGp1c3Qgc3VibWl0dGVk IGEgbmV3IHJldmlzaW9uIG9mIG9sc3J2Mi1tdWx0aXBhdGguIFRoZSB1cGRhdGVzIGluY2x1ZGU6 DQoNCiAtIENoYW5nZWQgdGhlIFNSX09MU1J2MiBUTFYgKGZvciBpZGVudGlmeWluZyBhIHJvdXRl ciBzdXBwb3J0aW5nIHNvdXJjZSByb3V0aW5nKSBmcm9tIG1lc3NhZ2UtdHlwZS1zcGVjaWZpYyBU TFYgdG8gTWVzc2FnZSBUTFYuIEJ5IGRvaW5nIHNvLCBvbmx5IG9uZSBhZGRpdGlvbmFsIFRMViBp cyBuZWVkZWQgZm9yIHRoZSBleHRlbnNpb24uIEluIGZhY3QsIGlkZW50aWZ5aW5nIGEgc291cmNl LXJvdXRpbmcgc3VwcG9ydGVkIHJvdXRlciBtYXkgYmUgdXNlZnVsIGZvciBvdGhlciBleHRlbnNp b25zIGFsc28uDQoNCiAgLSBCYXNlZCBvbiB0aGUgY29tbWVudHMgZnJvbSBQaGlsaXBwZSAoaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTc2ODMu aHRtbCksIEkgYWRkZWQgYW4gZXhhbXBsZSBpbiB0aGUgYXBwZW5kaXgsIHdoaWNoIGNsYXJpZmll cyB0aGUgY2hvaWNlIG9mIHRoZSBNdWx0aS1wYXRoIERpamtzdHJhIGFsZ29yaXRobS4NCg0KICAt IFVwZGF0ZWQgdGhlIGxpbmsgb2YgdGhlIG9wZW4gc291cmNlIGltcGxlbWVudGF0aW9ucy4NCg0K ICAtIG5pdHMgcGlja2luZy4NCg0KcmVnYXJkcw0KDQpKaWF6aQ0KDQotLS0tLS0tLS0tIEZvcndh cmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8 bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+DQpEYXRlOiBUdWUsIEp1biAzMCwgMjAx NSBhdCAxMjozNyBBTQ0KU3ViamVjdDogW21hbmV0XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1h bmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDQudHh0DQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnPG1h aWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpDYzogbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1h bmV0QGlldGYub3JnPg0KDQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KIFRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE1vYmlsZSBBZC1ob2MgTmV0d29ya3MgV29ya2luZyBHcm91 cCBvZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBNdWx0aS1wYXRoIEV4 dGVuc2lvbiBmb3IgdGhlIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wgdmVy c2lvbiAyIChPTFNSdjIpDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IEppYXppIFlpDQogICAg ICAgICAgICAgICAgICAgICAgICAgIEJlbm9pdCBQYXJyZWluDQogICAgICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0wNC50eHQNCiAgICAgICAg UGFnZXMgICAgICAgICAgIDogMTkNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNS0wNi0y OQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbXVsdGktcGF0aCBl eHRlbnNpb24gZm9yIHRoZSBPcHRpbWl6ZWQgTGluaw0KICAgU3RhdGUgUm91dGluZyBQcm90b2Nv bCB2ZXJzaW9uIDIgKE9MU1J2MikgdG8gZGlzY292ZXIgbXVsdGlwbGUNCiAgIGRpc2pvaW50IHBh dGhzLCBzbyBhcyB0byBpbXByb3ZlIHJlbGlhYmlsaXR5IG9mIHRoZSBPTFNSdjIgcHJvdG9jb2wu DQogICBUaGUgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIE9MU1J2MiBpcyByZXRhaW5lZC4NCg0KDQpU aGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRp cGF0aC8NCg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlw YXRoLTA0DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1hbmV0LW9s c3J2Mi1tdWx0aXBhdGgtMDQNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0 dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt YW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhl IGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBz eXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVz ZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRl bnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40F246F4GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpc27igJl0IHJp Z2h0LiBPZiBjb3Vyc2UgZXhhY3RseSB3aGF0IGl0IHNob3VsZCBsb29rIGxpa2UgZGVwZW5kcyBv biBjdXJyZW50IGNvbnNpZGVyYXRpb24sIGJ1dCBmaXJzdCB5b3UgbmVlZCB0byByZXF1ZXN0IGEg VExWDQogZnJvbSB0aGUgTWVzc2FnZSBUTFZzIHJlZ2lzdHJ5LiBZb3UgZG9u4oCZdCBnZXQgdG8g Y2hvb3NlIHRoZSBudW1iZXIsIGp1c3QgVEJELiBUaGF0IHJlcXVpcmVzIHlvdSB0byBjcmVhdGUg YSB0eXBlIGV4dGVuc2lvbnMgcmVnaXN0cnkgZm9yIHRoYXQgdHlwZS4gVGhlIG5hbWluZyBzdHls ZSBhbmQgdGFibGUgbGF5b3V0IHlvdSBzaG91bGQgdGFrZSBmcm9tIHRoZSBJQU5BIHJlZ2lzdHJ5 IGFzIG1vZGlmaWVkIGJ5IHRoZSBUTFYgbmFtaW5nIGRyYWZ0DQogKGFscmVhZHkgY2hhbmdlZCBi eSBJQU5BIGFzIHRoYXQgZHJhZnQgaXMgd2l0aCB0aGUgUkZDIGVkaXRvcikuIChZb3UgY2FuIHBy b2JhYmx5IHN0ZWFsIGZyb20gdGhhdCBkcmFmdOKAmXMgWE1MLikgWW91IG1heSB0aGVuIG5lZWQg KHR3byBvZiB0aGUgdGhyZWUgb3B0aW9ucyBJIGluZGljYXRlZCwgYnV0IG5vdCB0aGlzIGFzIGl0 IGN1cnJlbnRseSBzdGFuZHMpIGEgZnVydGhlciBkZWZpbml0aW9uIG9mIHRoZSB2YWx1ZSwgcHJv YmFibHkgbmVlZGluZw0KIGFub3RoZXIgdGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMDA3RTdFIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlv ciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j ZTxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVC RUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZu YnNwOzxiPkU6DQo8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu Y29tIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp Z2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2Zv cmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNv bS9haSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTI7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnd3 dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIi PkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVk IGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1 cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkppYXppIFlJPGJyPg0KPGI+U2VudDo8L2I+IDI5IEp1bmUgMjAxNSAyMzo1 OTxicj4NCjxiPlRvOjwvYj4gbWFuZXQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW21hbmV0XSBGd2Q6 IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0wNC50eHQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0 IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIi IHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3Jv dW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioq KiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBm cm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFy dG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxs eSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2ht ZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1h dGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJv bmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91 IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLA0KIGNsaWNrIDxhIGhyZWY9 Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nw b3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpoZXJlPC9hPi48L3NwYW4+PC9l bT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xs b3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3Jr L3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91 cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+PC9lbT48L3NwYW4+PC9p PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQg d2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjEuMHB0IDQuMHB0IDEuMHB0IDQuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjE2LjBwdCI+KjxzdHJvbmc+KiogV0FSTklORyAqKio8L3N0cm9u Zz48L3NwYW4+PGJyPg0KPGVtPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBv dXIgb3JnYW5pemF0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBp bnRlcm5ldC4gQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBh bnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5LiBGb3IgYWRkaXRpb25hbCBp bmZvcm1hdGlvbiBhYm91dCBTcGVhcnBoaXNoaW5nLCBjbGljaw0KPGEgaHJlZj0iaHR0cDovL2lu dHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Q YWdlcy9TcGVhcnBoaXNoaW5nVGlwcy5hc3B4Ij4NCmhlcmU8L2E+LiBJZiB5b3UgZmVlbCB0aGUg ZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIDxhIGhyZWY9Imh0dHA6Ly9p bnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMv RG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KcHJv Y2Vzcy48L2E+PC9lbT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGksJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IHJldmlzaW9uIG9mIG9s c3J2Mi1tdWx0aXBhdGguIFRoZSB1cGRhdGVzIGluY2x1ZGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOy0gQ2hhbmdlZCB0aGUgU1Jf T0xTUnYyIFRMViAoZm9yIGlkZW50aWZ5aW5nIGEgcm91dGVyIHN1cHBvcnRpbmcgc291cmNlIHJv dXRpbmcpIGZyb20gbWVzc2FnZS10eXBlLXNwZWNpZmljIFRMViB0byBNZXNzYWdlIFRMVi4gQnkg ZG9pbmcgc28sIG9ubHkgb25lIGFkZGl0aW9uYWwgVExWIGlzIG5lZWRlZCBmb3IgdGhlIGV4dGVu c2lvbi4gSW4gZmFjdCwgaWRlbnRpZnlpbmcgYSBzb3VyY2Utcm91dGluZyBzdXBwb3J0ZWQNCiBy b3V0ZXIgbWF5IGJlIHVzZWZ1bCBmb3Igb3RoZXIgZXh0ZW5zaW9ucyBhbHNvLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg LSBCYXNlZCBvbiB0aGUgY29tbWVudHMgZnJvbSBQaGlsaXBwZSAoPGEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTc2ODMuaHRtbCI+ aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTc2 ODMuaHRtbDwvYT4pLCBJIGFkZGVkIGFuIGV4YW1wbGUgaW4gdGhlIGFwcGVuZGl4LCB3aGljaCBj bGFyaWZpZXMNCiB0aGUgY2hvaWNlIG9mIHRoZSBNdWx0aS1wYXRoIERpamtzdHJhIGFsZ29yaXRo bS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7IC0gVXBkYXRlZCB0aGUgbGluayBvZiB0aGUgb3BlbiBzb3VyY2UgaW1wbGVt ZW50YXRpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgLSBuaXRzIHBpY2tpbmcuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlZ2FyZHM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Smlhemk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVz c2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KRGF0 ZTogVHVlLCBKdW4gMzAsIDIwMTUgYXQgMTI6MzcgQU08YnI+DQpTdWJqZWN0OiBbbWFuZXRdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0wNC50eHQ8YnI+DQpU bzogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGll dGYub3JnPC9hPjxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0 QGlldGYub3JnPC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCkEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmll cy48YnI+DQombmJzcDtUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBNb2JpbGUgQWQt aG9jIE5ldHdvcmtzIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs6IE11bHRpLXBhdGggRXh0ZW5zaW9uIGZvciB0aGUgT3B0aW1pemVkIExpbmsg U3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9uIDIgKE9MU1J2Mik8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9ycyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs6IEppYXppIFlpPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEJlbm9p dCBQYXJyZWluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRo LTA0LnR4dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAxOTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg OiAyMDE1LTA2LTI5PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMg ZG9jdW1lbnQgc3BlY2lmaWVzIGEgbXVsdGktcGF0aCBleHRlbnNpb24gZm9yIHRoZSBPcHRpbWl6 ZWQgTGluazxicj4NCiZuYnNwOyAmbmJzcDtTdGF0ZSBSb3V0aW5nIFByb3RvY29sIHZlcnNpb24g MiAoT0xTUnYyKSB0byBkaXNjb3ZlciBtdWx0aXBsZTxicj4NCiZuYnNwOyAmbmJzcDtkaXNqb2lu dCBwYXRocywgc28gYXMgdG8gaW1wcm92ZSByZWxpYWJpbGl0eSBvZiB0aGUgT0xTUnYyIHByb3Rv Y29sLjxicj4NCiZuYnNwOyAmbmJzcDtUaGUgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIE9MU1J2MiBp cyByZXRhaW5lZC48YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgvIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5l dC1vbHNydjItbXVsdGlwYXRoLzwvYT48YnI+DQo8YnI+DQpUaGVyZSdzIGFsc28gYSBodG1saXpl ZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTA0IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtb2xzcnYy LW11bHRpcGF0aC0wNDwvYT48YnI+DQo8YnI+DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0wNCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1h bmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDQ8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cD4qKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4KVGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJy PgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3Rl bSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVz ZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPgpkaXN0cmlidXRlIGl0cyBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L3A+PC9ib2R5Pg0K PC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40F246F4GLKXM0002VGREEN_-- From nobody Tue Jun 30 13:28:36 2015 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 BF5A91B2D9A for ; Tue, 30 Jun 2015 13:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 4uOXjDZc7LpI for ; Tue, 30 Jun 2015 13:28:32 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 770BA1B2D96 for ; Tue, 30 Jun 2015 13:28:32 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so27305568wib.1 for ; Tue, 30 Jun 2015 13:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lyc4k7A+4m53iAl+i46TEZS4cRgV9ily9rj2AHiAP04=; b=fdyMMzFm6b41/yRjhBJ8YnttgMKPPcJDv3WvSSjx9U/f2dqkW2BMhvZhuR0ucjg9VY B3iksYT1v5wD0uWSg1PkNN1YTfKvt4QOBM36PKHiPCe39U5EqjCB+LfeysF+Obn5VxZV vPhoz9Z/rlOPEFh8mpbESCJWm2ieuoh2mdrWuBRfL1ZWBve4n1ZEL35Utrxj6zO1Dam9 wG3nK0heGbg3kgNtOnf6wW4pWiFSCrbrmRDvP8yox+O7riyJVJdI4aVEbCJhfqTeBMSh 2oGiiLho0FagOs4iwxQ93ISZYzZt/Y8NsWRVOKDO60u6x4n+4vRhk78EAwdBWj/PIl2/ iknw== MIME-Version: 1.0 X-Received: by 10.180.107.138 with SMTP id hc10mr36843700wib.2.1435696065841; Tue, 30 Jun 2015 13:27:45 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.28.86.9 with HTTP; Tue, 30 Jun 2015 13:27:45 -0700 (PDT) In-Reply-To: References: <20150629223750.14715.16298.idtracker@ietfa.amsl.com> Date: Tue, 30 Jun 2015 22:27:45 +0200 X-Google-Sender-Auth: eybExGs3fzpBx3e2rUBk52cRFNI Message-ID: From: Jiazi YI To: Henning Rogge Content-Type: multipart/alternative; boundary=e89a8f23573902900f0519c20a3d Archived-At: Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-olsrv2-multipath-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, 30 Jun 2015 20:28:34 -0000 --e89a8f23573902900f0519c20a3d Content-Type: text/plain; charset=UTF-8 A bit vector seems to be enough in this case and future extensions for NODE_CAPABILITY TLV (which generally indicates ON/OFF status of a function). And thanks Chris for indicating the error in the IANA consideration section. I'll draft a new text after we decided which approach to take for the source-route related TLV. best Jiazi On Tue, Jun 30, 2015 at 3:28 PM, Henning Rogge wrote: > On Tue, Jun 30, 2015 at 3:26 PM, Dearlove, Christopher (UK) > wrote: > > Is "would be fine" the same as "my preference among options"? > > Yes... especially if we keep it constraint to "binary capabilities"... > something a node does support or does not support. > > Anything more complicated should have a TLV of its own. > > Henning > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --e89a8f23573902900f0519c20a3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A bit vector seems to be enough in this case and future ex= tensions for=C2=A0NODE_CAPABIL= ITY TLV (which generally indicates ON/OFF status of a function).=C2=A0

<= span style=3D"font-size:12.8000001907349px">And thanks Chris for indicating= the error in the IANA consideration section. I'll draft a new text aft= er we decided which approach to take for the source-route related TLV.=C2= =A0

best
=

Jiazi

On Tue, Jun 30, 2015 at 3:= 28 PM, Henning Rogge <hrogge@gmail.com> wrote:
On Tue, Jun 30, 2015 at 3:26 PM, Dearl= ove, Christopher (UK)
<chris.dearlove@baesyst= ems.com> wrote:
> Is "would be fine" the same as "my preference among opt= ions"?

Yes... especially if we keep it constraint to "binary capabilit= ies"...
something a node does support or does not support.

Anything more complicated should have a TLV of its own.

Henning

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

--e89a8f23573902900f0519c20a3d--