From charliep@computer.org Fri Feb 1 13:52:44 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E26021F8C38 for ; Fri, 1 Feb 2013 13:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3oLWAbX9xTA for ; Fri, 1 Feb 2013 13:52:42 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id A45A521F88E8 for ; Fri, 1 Feb 2013 13:52:33 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1U1OXA-0006Jv-DH for manet@ietf.org; Fri, 01 Feb 2013 16:52:32 -0500 Message-ID: <510C391B.7000604@computer.org> Date: Fri, 01 Feb 2013 13:52:27 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86dd79bc78ad8c7d1ba306e7ce5c11be1f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Subject: [manet] Micro-history about reactive protocol evolution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 21:52:44 -0000 Hello folks, As part of the process of making progress on the reactive protocol specification, it was suggested that a bit of history might be helpful to understand how we have arrived at the current state. Since most people on this list have been around for a while and have seen first hand the recent discussions, I won't go into that. Instead, I'd like to make a very short summary of what might be unfamiliar to many people involved in the current discussion. AODV and DSR were published as experimental RFCs for reactive protocols. OLSR and TBRPF were published as experimental RFCs for proactive. The plan was to have two later RFCs -- one for proactive, one for reactive. The proponents of TBRPF didn't stick around too long, so, the proactive protocol became simply OLSRv2. The proponents of AODV and DSR took it as their job to merge the two "experimental" protocols into a new reactive standards track protocol. AODV and DSR together have had hundreds (thousands?) of citations in peer-reviewed papers, so their features are pretty well understood. The main difference between AODV and DSR is that DSR uses source routes whereas AODV uses distance-vector. The authors determined that the best way to do the merge was to have a feature allowing "path accumulation", which is now optional in AODVv2. There were some other features that were dropped from the specification, in particular "local repair". The name "DYMO" was picked because it was neither "AODV" nor "DSR", and we all thought it was better to represent the protocol as a fresh start. Ian Chakeres took over as editor when Dave Johnson eventually stopped coming to IETF and as I almost dropped out myself, being in a start-up, etc. In retrospect, we lost name recognition and the new name never really caught on. In 2011, when I was asked to resume editorial duties, several people (frequent contributors to this mailing list) convinced me that the protocol should be called AODVv2. Ian was co-author (with Luke Klein-Berndt) for a protocol called "AODV Jr.", and so Ian was quite favorable towards crafting DYMO as a "stripped-down" version of AODV. This is one reason why DYMO de-emphasized some of the other features of AODV, while yet incorporating features from DSR. The main changes to DYMO have been: - conversion to RFC 5444 packet formats - moving Intermediate RREP to separate document - simplification of rules for incrementing sequence numbers - renaming to be AODVv2, numerous terminology simplifications - lastly, enabling the use of alternate metrics I hope this is helpful to understand the evolution of the reactive protocol effort within [manet]. I wrote it from memory, and so I might have missed one or two details. There is a lot more that could be written, but then this email would get way too long. -- Regards, Charlie P. From abdussalambaryun@gmail.com Fri Feb 1 17:29:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E1421F898A for ; Fri, 1 Feb 2013 17:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icBuoRpRwCvv for ; Fri, 1 Feb 2013 17:29:36 -0800 (PST) Received: from mail-we0-x234.google.com (we-in-x0234.1e100.net [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id A261A21F8984 for ; Fri, 1 Feb 2013 17:29:35 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id k14so3335681wer.25 for ; Fri, 01 Feb 2013 17:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=QJyoDcoGIQgN8abuFFkPqerIK6GuLR+xnK0W6AlvZCM=; b=1BVrRXFlOo9l2yBumCa7wQ5Gs4VglhLo3n42jtEZBfVvr7i1FH0aGwkInwXe6k/m6+ j8R+KwfgZAndRKKDoTv/7i7jx+gHYpXnR1YJaOiuKv062S+P5Qf+IZeDuwDll47tm+R6 chde6oXNeSVH60FSY7BXGyhKz2Q+x/OWNDCsVrp8QyGbT2T8szsPVJz4woVBJNgEqJmt wJi7G4R1xfWJlDP4AVT7h67UajLMsLB/uhM0jXPtILAwN4aSRDFdJOx13KrexHGWp0kM vp+zzsOXBsXup7PNhUdfWSPwq5JSiaKzKAKMkhwhXVfQs4bWrjXuEn7YC2ijrvm+JaiN VHlw== MIME-Version: 1.0 X-Received: by 10.194.90.11 with SMTP id bs11mr24867582wjb.18.1359768574780; Fri, 01 Feb 2013 17:29:34 -0800 (PST) Received: by 10.180.14.33 with HTTP; Fri, 1 Feb 2013 17:29:34 -0800 (PST) In-Reply-To: <510C391B.7000604@computer.org> References: <510C391B.7000604@computer.org> Date: Sat, 2 Feb 2013 02:29:34 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Micro-history about reactive protocol evolution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 01:29:36 -0000 Thanks, it is always special to hear history from the actors themself. I recommend that we start an initial historical I-D including these memories (Proactive and Reactive Protocols) to be submitted not later than June 2017. At least each 20 years WG participants could document their technical involvement history within WG work. Some MANET addition IETF history dates as; Start of MANET WG: 12 Jun 1997 Start publish of AODV: 20 Nov 1997 Discussion list Started: 30 Jan 2002 RFC3561 AODV: 01 July 2003 Start Publish of DYMO: 01 Jan 2005 Start DYMO to AODVv2: 12 Mar 2012 AB ++ On 2/1/13, Charles E. Perkins wrote: > > Hello folks, > > As part of the process of making progress on the reactive protocol > specification, it was suggested that a bit of history might be helpful > to understand how we have arrived at the current state. Since most > people on this list have been around for a while and have seen first > hand the recent discussions, I won't go into that. Instead, I'd like > to make a very short summary of what might be unfamiliar to many > people involved in the current discussion. > > AODV and DSR were published as experimental RFCs for reactive protocols. > OLSR and TBRPF were published as experimental RFCs for proactive. > The plan was to have two later RFCs -- one for proactive, one for reactive. > The proponents of TBRPF didn't stick around too long, so, the proactive > protocol became simply OLSRv2. The proponents of AODV and DSR took it > as their job to merge the two "experimental" protocols into a new reactive > standards track protocol. AODV and DSR together have had hundreds > (thousands?) of citations in peer-reviewed papers, so their features are > pretty well understood. > > The main difference between AODV and DSR is that DSR uses source > routes whereas AODV uses distance-vector. The authors determined > that the best way to do the merge was to have a feature allowing > "path accumulation", which is now optional in AODVv2. There were > some other features that were dropped from the specification, in > particular "local repair". The name "DYMO" was picked because it > was neither "AODV" nor "DSR", and we all thought it was better to > represent the protocol as a fresh start. Ian Chakeres took over as > editor when Dave Johnson eventually stopped coming to IETF and as > I almost dropped out myself, being in a start-up, etc. In retrospect, > we lost name recognition and the new name never really caught on. > In 2011, when I was asked to resume editorial duties, several people > (frequent contributors to this mailing list) convinced me that the > protocol should be called AODVv2. > > Ian was co-author (with Luke Klein-Berndt) for a protocol called > "AODV Jr.", and so Ian was quite favorable towards crafting DYMO > as a "stripped-down" version of AODV. This is one reason why DYMO > de-emphasized some of the other features of AODV, while yet > incorporating features from DSR. > > The main changes to DYMO have been: > - conversion to RFC 5444 packet formats > - moving Intermediate RREP to separate document > - simplification of rules for incrementing sequence numbers > - renaming to be AODVv2, numerous terminology simplifications > - lastly, enabling the use of alternate metrics > > I hope this is helpful to understand the evolution of the reactive > protocol effort within [manet]. I wrote it from memory, and so I > might have missed one or two details. There is a lot more that > could be written, but then this email would get way too long. > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From john.dowdell@cassidian.com Mon Feb 4 03:26:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8377D21F861F for ; Mon, 4 Feb 2013 03:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3drT61EDTOV for ; Mon, 4 Feb 2013 03:26:43 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2170A21F85AC for ; Mon, 4 Feb 2013 03:26:34 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 04 Feb 2013 12:26:31 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 4 Feb 2013 12:26:31 +0100 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Feb 2013 12:26:31 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Feb 2013 12:26:31 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 4 Feb 2013 11:26:30 +0000 From: "Dowdell, John" To: "manet@ietf.org" Thread-Topic: 'Useless' in AODVv2 draft 25 Thread-Index: Ac4CynZ6LjxrFogBQL2JEtx2XSiSyg== Date: Mon, 4 Feb 2013 11:26:30 +0000 Message-ID: <603F5FD847B5174CBDA37A9DC00532FB06AC41AB@SUCNPTEXM02.com.ad.uk.ds.corp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.216.52] Content-Type: multipart/alternative; boundary="_000_603F5FD847B5174CBDA37A9DC00532FB06AC41ABSUCNPTEXM02coma_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Feb 2013 11:26:31.0168 (UTC) FILETIME=[7B10F000:01CE02CA] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19612.006 X-TM-AS-Result: No--10.421800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: [manet] 'Useless' in AODVv2 draft 25 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 11:26:50 -0000 --_000_603F5FD847B5174CBDA37A9DC00532FB06AC41ABSUCNPTEXM02coma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Charlie I note that in draft-ietf-manet-dymo-25 you use the word 'useless' in secti= ons 5.7, 7.4, 7.5.1, 7.6 and 13.4. Please can you clarify the meaning of the word as you use it here, assuming= the meaning is the same in all those sections? Do you mean: - out of date (in that the overall situation has changed and the c= ontent is wrong) - repeated (in that the content has previously been advised and is= being re-advised in the same form) - not needed (because the content advises a less satisfactory rout= e) - or some other meaning? Regards John The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com --_000_603F5FD847B5174CBDA37A9DC00532FB06AC41ABSUCNPTEXM02coma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Charlie

 

I note that in draft-ietf-manet-dymo-25 you= use the word ‘useless’ in sections 5.7, 7.4, 7.5.1, 7.6 and 13= .4.

 

Please can you clarify the meaning of the w= ord as you use it here, assuming the meaning is the same in all those secti= ons? Do you mean:

 

-    &nbs= p;     out of date (in that the overall situation has changed and t= he content is wrong)

-    &nbs= p;     repeated (in that the content has previously been advised an= d is being re-advised in the same form)

-    &nbs= p;     not needed (because the content advises a less satisfactory = route)

-    &nbs= p;     or some other meaning?

 

Regards

John

 

The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-mail or attached files, please con= tact the sender prior to any such disclosure. If you are not the intended r= ecipient, any disclosure, copying or distribution is prohibited. Please als= o contact the sender and inform them of the error and delete the e-mail, including any attached files from= your system. Cassidian Limited, Registered Office : Quadrant House, Celtic= Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cas= sidian.com --_000_603F5FD847B5174CBDA37A9DC00532FB06AC41ABSUCNPTEXM02coma_-- From charliep@computer.org Mon Feb 4 11:36:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4C721F899E for ; Mon, 4 Feb 2013 11:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igSSwkSqnI3p for ; Mon, 4 Feb 2013 11:36:09 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 36A4221F8953 for ; Mon, 4 Feb 2013 11:36:08 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1U2Rpl-0001ma-5i; Mon, 04 Feb 2013 14:36:05 -0500 Message-ID: <51100D99.5030203@computer.org> Date: Mon, 04 Feb 2013 11:35:53 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Dowdell, John" References: <603F5FD847B5174CBDA37A9DC00532FB06AC41AB@SUCNPTEXM02.com.ad.uk.ds.corp> In-Reply-To: <603F5FD847B5174CBDA37A9DC00532FB06AC41AB@SUCNPTEXM02.com.ad.uk.ds.corp> Content-Type: multipart/alternative; boundary="------------020705040307030106050808" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861fc34b64756b6c8dd4e7e5d797fcbffd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "manet@ietf.org" Subject: Re: [manet] 'Useless' in AODVv2 draft 25 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 19:36:11 -0000 This is a multi-part message in MIME format. --------------020705040307030106050808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello John, The word "useless" means "redundant" in the various places it appears in the document. In each case where "useless" appears, I have checked that "redundant" keeps the proper meaning. I agree that your other two meanings of "useless" ("out-of-date" or "suboptimal") are often used, but not in the AODVv2 specification. I looked for instances of "useful". There are occurrences of "useful" that do NOT mean "not redundant". For instance, "useful" has the meaning "relevant" at certain places in the document. "useful" also means "applicable". If you think that some of these uses are similarly ambiguous, please don't hesitate to point them out. Regards, Charlie P. On 2/4/2013 3:26 AM, Dowdell, John wrote: > > Charlie > > I note that in draft-ietf-manet-dymo-25 you use the word 'useless' in > sections 5.7, 7.4, 7.5.1, 7.6 and 13.4. > > Please can you clarify the meaning of the word as you use it here, > assuming the meaning is the same in all those sections? Do you mean: > > -out of date (in that the overall situation has changed and the > content is wrong) > > -repeated (in that the content has previously been advised and is > being re-advised in the same form) > > -not needed (because the content advises a less satisfactory route) > > -or some other meaning? > > Regards > > John > > The information contained within this e-mail and any files attached to > this e-mail is private and in addition may include commercially > sensitive information. The contents of this e-mail are for the > intended recipient only and therefore if you wish to disclose the > information contained within this e-mail or attached files, please > contact the sender prior to any such disclosure. If you are not the > intended recipient, any disclosure, copying or distribution is > prohibited. Please also contact the sender and inform them of the > error and delete the e-mail, including any attached files from your > system. Cassidian Limited, Registered Office : Quadrant House, Celtic > Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 > http://www.cassidian.com > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. --------------020705040307030106050808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello John,

The word "useless" means "redundant" in the various places it appears
in the document.  In each case where "useless" appears, I have checked
that "redundant" keeps the proper meaning.  I agree that your other
two meanings of "useless" ("out-of-date" or "suboptimal") are often
used, but not in the AODVv2 specification.

I looked for instances of "useful".  There are occurrences of "useful"
that do NOT mean "not redundant".  For instance, "useful" has the
meaning "relevant" at certain places in the document.  "useful" also
means "applicable".

If you think that some of these uses are similarly ambiguous,
please don't hesitate to point them out.

Regards,
Charlie P.




On 2/4/2013 3:26 AM, Dowdell, John wrote:

Charlie

 

I note that in draft-ietf-manet-dymo-25 you use the word ‘useless’ in sections 5.7, 7.4, 7.5.1, 7.6 and 13.4.

 

Please can you clarify the meaning of the word as you use it here, assuming the meaning is the same in all those sections? Do you mean:

 

-          out of date (in that the overall situation has changed and the content is wrong)

-          repeated (in that the content has previously been advised and is being re-advised in the same form)

-          not needed (because the content advises a less satisfactory route)

-          or some other meaning?

 

Regards

John

 

The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com 

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



-- 
Regards,
Charlie P.
--------------020705040307030106050808-- From charliep@computer.org Mon Feb 4 12:22:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4B121F8B0A for ; Mon, 4 Feb 2013 12:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbb0Lk5g4Icl for ; Mon, 4 Feb 2013 12:22:47 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5D18D21F8759 for ; Mon, 4 Feb 2013 12:22:37 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1U2SYm-00032S-HO for manet@ietf.org; Mon, 04 Feb 2013 15:22:36 -0500 Message-ID: <51101881.6070409@computer.org> Date: Mon, 04 Feb 2013 12:22:25 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861bd9afae15d757de28563d1c9ded3263350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Subject: [manet] Ordering of message components in RFC 5444 format X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 20:22:48 -0000 Hello folks, Reading through the numerous (and voluminous) emails on this topic, I've noticed that there is some ambiguity about the matter. One could imagine some positional significance to any of the following orderings: - messages in a packet - address data (AddrData) in a message (i.e., ) == unfortunately, I could not find existing terminology for this, and the handy term "Address Object" has been already used for some other concept in RFFC 5444. So in this email I use "AddrData" - address TLVs (AddrTLV) in the TLV block of the address data - the list of addresses that appear in an Address Block (AddrBlk) Some of the discussion favoring "positional independence" actually seems to be arguing for positional independence for the order of AddrTLVs in the AddrData. There is no positional dependence of the AddrTLVs specified in the AODVv2 specification. I am not aware of any past version of RFC-5444 compliant versions that made any such specification for positional dependence of AddrTLVs within the list of address TLVs following an AddrBlk. Likewise, there has been no suggestion of imposing ordering significance on the collection of messages in a packet, and no requirement for ordering the AddrBlks in messages that might have multiple AddrBlks. Up until the current discussion, AODVv2 has attached positional meaning to the order of addresses in an AddrBlk. According to email I sent out on Jan. 21, it is proposed to remove this positional dependence by creating new AddrTLVs, and this week is likely to see a new version of the AODVv2 specification incorporating the new proposal. Nevertheless, there is certainly still disagreement on whether or not it is reasonable to assign positional dependence to order of appearance of addresses in an AddrBlk. I'll follow up on that discussion in a later email. -- Regards, Charlie P. From charliep@computer.org Mon Feb 4 13:25:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DD921F8AB8 for ; Mon, 4 Feb 2013 13:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Zm0hbYmDlJe for ; Mon, 4 Feb 2013 13:25:58 -0800 (PST) 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 4FF0121F8B0B for ; Mon, 4 Feb 2013 13:25:58 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1U2TY5-0005VE-MN for manet@ietf.org; Mon, 04 Feb 2013 16:25:57 -0500 Message-ID: <5110275C.2000806@computer.org> Date: Mon, 04 Feb 2013 13:25:48 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86f77cabd32d417db9d02db2a4d55fbbad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Subject: [manet] Terminology simplifications X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 21:25:59 -0000 Hello folks, The term "HandlingRtr" appears in various places of the AODVv2 specification. Most of the appearances are located in section 7.5, "Handling a Received RteMsg". It turns out that the section reads quite well if "HandlingRtr" is simply replaced by "the router", as long as it is made clear in the beginning of the section that the router under discussion is the router handling the RteMsg. I propose to make this change, and to investigate whether other instances of "HandlingRtr" are amenable to better wordsmithing. According to the earlier discussion about "useless", I propose to replace existing instances of "useless" by "redundant". Then, section 7.6 becomes "Suppressing Redundant RteMsgs". Another aspect of simplification would be to replace occurrences of "RteMsg" by "RREQ" within section 7.6, since the specification does not mandate suppressing redundant RREP messages. Such redundant RREP messages typically would not occur unless the optional feature in section 13.4 were implemented. With this additional change, section 7.6 would be entitled "Suppressing Redundant RREQ messages". -- Regards, Charlie P. From charliep@computer.org Mon Feb 4 15:41:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762E821F8A77 for ; Mon, 4 Feb 2013 15:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_00=-2.599, FRT_LOLITA1=1.865] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRtREz-w08tk for ; Mon, 4 Feb 2013 15:41:04 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id D575021F8A71 for ; Mon, 4 Feb 2013 15:41:03 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1U2Vep-0003hd-3H for manet@ietf.org; Mon, 04 Feb 2013 18:41:03 -0500 Message-ID: <51104703.2040302@computer.org> Date: Mon, 04 Feb 2013 15:40:51 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: manet References: <50FD9E4A.7010807@computer.org> In-Reply-To: <50FD9E4A.7010807@computer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad865211ce00e2c8c2b718e175fde93d6996350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Subject: Re: [manet] New TLVs for reactive protocol messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 23:41:04 -0000 Hello again folks, It turns out that the version of SeqNum TLV that does not depend on the function of the address in the AddrBlk is used for RERR. So, instead of dropping the SeqNum TLV from the specification, I think it is better to keep it, but just add the two new TLVs. Proposed names: OrigSeqNum TLV and TargSeqNum TLV to be used whenever the more verbose names below don't fit well. Regards, Charlie P. On 1/21/2013 12:00 PM, Charles E. Perkins wrote: > > Hello folks, > > As Henning has proposed, it is possible to revise the AODVv2 Address TLV > definitions so that in the base protocol, the AddrBlk addresses do not > need > to have any additional position-based semantics. I have made some > example packet formats and definitions, herewith... > > ========================================================== > > "Route Discovery Originator Sequence Number": > The sequence number for the originating node that triggered > the RREQ message initiating the Route Discovery operation. > > Another TLV for "Route Discovery Target Sequence Number" > The sequence number for the target node for which a route > was requested by way of RREQ from the originating router. > > The following packet formats look best with fixed-width fonts. > If I didn't get all the RFC 5444 bits correct, please don't shoot > me, but I think they're correct. > > > Original: SeqNum TLV shown with an example AddrBlk: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | num-addr=2 |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Head (bytes for Orig & Target)| Orig.Tail | Target.Tail | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | addr.tlvs-length=6 | type=SeqNum |0|1|0|1|0|0|Rsv| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Index-start=0 | tlv-length=2 | Orig.Node Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > One Sequence Number: Original Node SeqNum TLV: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | addr.tlvs-length=6 | type=OSeqNum |0|1|0|1|0|0|Rsv| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Index-start=0 | tlv-length=2 | Orig.Node Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > One Sequence Number: Target Node SeqNum TLV: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | addr.tlvs-length=6 | type=TSeqNum |0|1|0|1|0|0|Rsv| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Index-start=1 | tlv-length=2 | Targ.Node Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Two Sequence Numbers: SeqNum TLV: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | addr.tlvs-length=7 | type=SeqNum |0|0|0|1|0|1|Rsv| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | tlv-length=4 | Orig.Node Sequence # | TargNode Seq# | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TargNode Seq# | > +-+-+-+-+-+-+-+-+ > > Two Sequence Numbers: Originating and Target Node SeqNum TLVs: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | addr.tlvs-length=12 | type=OSeqNum |0|1|0|1|0|0|Rsv| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Index-start=0 | tlv-length=2 | Orig.Node Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | type=TSeqNum |0|1|0|1|0|0|Rsv| Index-start=1 | tlv-length=2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Targ.Node Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > I propose to replace the existing AODVv2 TLVs with the TLVs defined > above, > and to move the positional-dependent SeqNum TLV to iRREP specification. > -- Regards, Charlie P. From abdussalambaryun@gmail.com Tue Feb 5 03:42:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D18F21F86EB for ; Tue, 5 Feb 2013 03:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XEzAr8tBFXQ for ; Tue, 5 Feb 2013 03:42:42 -0800 (PST) Received: from mail-we0-x22e.google.com (we-in-x022e.1e100.net [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2C19521F85D2 for ; Tue, 5 Feb 2013 03:42:41 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id r6so31914wey.33 for ; Tue, 05 Feb 2013 03:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PsFgUG+8PYNd9QaCPJU+/i9WP8qWNKD97XVPLTDu9XM=; b=sNg6+RZ4q0NvO5frpMxwHwxr1RuXamQrvSl+jaR4LNprefPVnLGPjxrfqyvfoZwngj mP4ZASJuiY2YO/dINTX8aL1rh+4I+azfmROuNED6Z1Mvpr/0PUBNOA2C7k2+O8rsptEN 7Ks/Sk+WHsFMhTFYnbI9EWGmk1vQG/kBh1T/8JmpIXYI2d+wyVXIRvhVaz4PH8OXsA1U DhsO8lHEy20Z/vjZ6vLEKAucX28KUCsncotWaJ+Upl/JLI16YuUjnPkBgn5n8LDoKDzA a+j2N4/J9MpJW1llHTc+xkhTFvyTzjnSJGSgcJg/IvnQXAMdjAbVzJGgMN5b45Y+xqGA JVLA== MIME-Version: 1.0 X-Received: by 10.180.73.80 with SMTP id j16mr16488793wiv.5.1360064561151; Tue, 05 Feb 2013 03:42:41 -0800 (PST) Received: by 10.180.101.70 with HTTP; Tue, 5 Feb 2013 03:42:41 -0800 (PST) In-Reply-To: <51100D99.5030203@computer.org> References: <603F5FD847B5174CBDA37A9DC00532FB06AC41AB@SUCNPTEXM02.com.ad.uk.ds.corp> <51100D99.5030203@computer.org> Date: Tue, 5 Feb 2013 11:42:41 +0000 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=f46d043bdf3809fdc404d4f8b539 Subject: Re: [manet] 'Useless' in AODVv2 draft 25 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 11:42:43 -0000 --f46d043bdf3809fdc404d4f8b539 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think the word useful means useful and useless means useless, we cannot change English meanings only if specified in draft. I understood that useless means NOT USED or NOT USEFUL, in my interpretation. If the author meant *redundant*, or other, then recommend mention that in the draft. AB On Mon, Feb 4, 2013 at 7:35 PM, Charles E. Perkins w= rote: > > Hello John, > > The word "useless" means "redundant" in the various places it appears > in the document. In each case where "useless" appears, I have checked > that "redundant" keeps the proper meaning. I agree that your other > two meanings of "useless" ("out-of-date" or "suboptimal") are often > used, but not in the AODVv2 specification. > > I looked for instances of "useful". There are occurrences of "useful" > that do NOT mean "not redundant". For instance, "useful" has the > meaning "relevant" at certain places in the document. "useful" also > means "applicable". > > If you think that some of these uses are similarly ambiguous, > please don't hesitate to point them out. > > Regards, > Charlie P. > > > > > > On 2/4/2013 3:26 AM, Dowdell, John wrote: > > Charlie > > > > I note that in draft-ietf-manet-dymo-25 you use the word =91useless=92 in > sections 5.7, 7.4, 7.5.1, 7.6 and 13.4. > > > > Please can you clarify the meaning of the word as you use it here, > assuming the meaning is the same in all those sections? Do you mean: > > > > - out of date (in that the overall situation has changed and the > content is wrong) > > - repeated (in that the content has previously been advised and > is being re-advised in the same form) > > - not needed (because the content advises a less satisfactory > route) > > - or some other meaning? > > > > Regards > > John > > > The information contained within this e-mail and any files attached to > this e-mail is private and in addition may include commercially sensitive > information. The contents of this e-mail are for the intended recipient > only and therefore if you wish to disclose the information contained with= in > this e-mail or attached files, please contact the sender prior to any suc= h > disclosure. If you are not the intended recipient, any disclosure, copyin= g > or distribution is prohibited. Please also contact the sender and inform > them of the error and delete the e-mail, including any attached files fro= m > your system. Cassidian Limited, Registered Office : Quadrant House, Celti= c > Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 > http://www.cassidian.com > > _______________________________________________ > manet mailing listmanet@ietf.orghttps://www.ietf.org/mailman/listinfo/man= et > > > > -- > Regards, > Charlie P. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --f46d043bdf3809fdc404d4f8b539 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I think the word useful means useful and useless means useless, we can= not change English meanings only if specified in draft. I understood that u= seless means NOT USED or NOT USEFUL, in my interpretation.
=A0
If the author meant *redundant*, or other, then recommend mention that= in the draft.
=A0
AB

On Mon, Feb 4, 2013 at 7:35 PM, Charles E. Perkins <charliep@co= mputer.org> wrote:
=20 =20 =20

Hello John,

The word "useless" means "redundant" in the vario= us places it appears
in the document.=A0 In each case where "useless" appears, I= have checked
that "redundant" keeps the proper meaning.=A0 I agree that = your other
two meanings of "useless" ("out-of-date" or "= ;suboptimal") are often
used, but not in the AODVv2 specification.

I looked for instances of "useful".=A0 There are occurrence= s of "useful"
that do NOT mean "not redundant".=A0 For instance, "us= eful" has the
meaning "relevant" at certain places in the document.=A0 &q= uot;useful" also
means "applicable".

If you think that some of these uses are similarly ambiguous,
please don't hesitate to point them out.

Regards,
Charlie P.





On 2/4/2013 3:26 AM, Dowdell, John wrote:
=20 =20

Charlie

=A0

I note that in draft-ietf-manet-dymo-25 you use the word =91useless=92 in sections 5.7, 7.4, 7.5.1, 7.6 and 13.4.

=A0

Please can you clarify the meaning of the word as you use it here, assuming the meaning is the same in all those sections? Do you mean:

=A0

-=A0=A0=A0= =A0=A0=A0=A0=A0=A0 <= span style=3D"font-family:Arial">out of date (in that the overall situation has changed and the content is wrong)=

-=A0=A0=A0= =A0=A0=A0=A0=A0=A0 <= span style=3D"font-family:Arial">repeated (in that the content has previously been advised and is being re-advised in the same form)

-=A0=A0=A0= =A0=A0=A0=A0=A0=A0 <= span style=3D"font-family:Arial">not needed (because the content advises a less satisfactory route)

-=A0=A0=A0= =A0=A0=A0=A0=A0=A0 <= span style=3D"font-family:Arial">or some other meaning?

=A0

Regards

John

=A0

The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com 

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



--=20
Regards,
Charlie P.

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


--f46d043bdf3809fdc404d4f8b539-- From john.dowdell@cassidian.com Tue Feb 5 03:58:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF99C21F865B for ; Tue, 5 Feb 2013 03:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzC3ptEUcOOz for ; Tue, 5 Feb 2013 03:58:49 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0801821F8681 for ; Tue, 5 Feb 2013 03:58:46 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 05 Feb 2013 12:58:42 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 5 Feb 2013 12:58:41 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Feb 2013 12:58:41 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Feb 2013 12:58:40 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 11:58:38 +0000 From: "Dowdell, John" To: Abdussalam Baryun , manet Thread-Topic: [manet] 'Useless' in AODVv2 draft 25 Thread-Index: AQHOA5XnRSK+zljrcEexxkmncq9+vZhrJ0DQ Date: Tue, 5 Feb 2013 11:58:38 +0000 Message-ID: <603F5FD847B5174CBDA37A9DC00532FB06AC4F68@SUCNPTEXM02.com.ad.uk.ds.corp> References: <603F5FD847B5174CBDA37A9DC00532FB06AC41AB@SUCNPTEXM02.com.ad.uk.ds.corp> <51100D99.5030203@computer.org> 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.80.23.131] Content-Type: multipart/alternative; boundary="_000_603F5FD847B5174CBDA37A9DC00532FB06AC4F68SUCNPTEXM02coma_" MIME-Version: 1.0 X-OriginalArrivalTime: 05 Feb 2013 11:58:40.0673 (UTC) FILETIME=[238DC910:01CE0398] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19614.006 X-TM-AS-Result: No--9.663500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] 'Useless' in AODVv2 draft 25 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 11:58:52 -0000 --_000_603F5FD847B5174CBDA37A9DC00532FB06AC4F68SUCNPTEXM02coma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Abdussalam As you point out, 'useless' can have a number of meanings depending on the = context in which the word is used, and is therefore open to interpretation.= I was asking Charlie to clarify the meaning that he wanted to convey in ea= ch of the contexts in which he used the word, so that the scope for differe= nt interpretations can be reduced or eliminated. He has now done so, and I = believe he will amend the next draft to use a word that conveys a more spec= ific meaning. John ________________________________ From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 05 February 2013 11:43 To: manet Cc: Dowdell, John; Charles E. Perkins Subject: Re: [manet] 'Useless' in AODVv2 draft 25 I think the word useful means useful and useless means useless, we cannot c= hange English meanings only if specified in draft. I understood that useles= s means NOT USED or NOT USEFUL, in my interpretation. If the author meant *redundant*, or other, then recommend mention that in t= he draft. AB On Mon, Feb 4, 2013 at 7:35 PM, Charles E. Perkins > wrote: Hello John, The word "useless" means "redundant" in the various places it appears in the document. In each case where "useless" appears, I have checked that "redundant" keeps the proper meaning. I agree that your other two meanings of "useless" ("out-of-date" or "suboptimal") are often used, but not in the AODVv2 specification. I looked for instances of "useful". There are occurrences of "useful" that do NOT mean "not redundant". For instance, "useful" has the meaning "relevant" at certain places in the document. "useful" also means "applicable". If you think that some of these uses are similarly ambiguous, please don't hesitate to point them out. Regards, Charlie P. On 2/4/2013 3:26 AM, Dowdell, John wrote: Charlie I note that in draft-ietf-manet-dymo-25 you use the word 'useless' in secti= ons 5.7, 7.4, 7.5.1, 7.6 and 13.4. Please can you clarify the meaning of the word as you use it here, assuming= the meaning is the same in all those sections? Do you mean: - out of date (in that the overall situation has changed and the c= ontent is wrong) - repeated (in that the content has previously been advised and is= being re-advised in the same form) - not needed (because the content advises a less satisfactory rout= e) - or some other meaning? Regards John The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com --_000_603F5FD847B5174CBDA37A9DC00532FB06AC4F68SUCNPTEXM02coma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Abdussalam

 

As you point out= , ‘useless’ can have a number of meanings depending on the cont= ext in which the word is used, and is therefore open to interpretation. I was asking Charlie to clarify the meaning that he wanted= to convey in each of the contexts in which he used the word, so that the s= cope for different interpretations can be reduced or eliminated. He has now= done so, and I believe he will amend the next draft to use a word that conveys a more specific meaning.

 

John

 

 

From:= Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 05 February 2013 11:43=
To: manet
Cc: Dowdell, John; Charles E= . Perkins
Subject: Re: [manet] 'Useles= s' in AODVv2 draft 25

 

I think the word useful means useful and useless mea= ns useless, we cannot change English meanings only if specified in draft. I= understood that useless means NOT USED or NOT USEFUL, in my interpretation.

 

If the author meant *redundant*, or other, then reco= mmend mention that in the draft.

 

AB

On Mon, Feb 4, 2013 at 7:35 PM, Charles E. Perkins &= lt;charliep@comp= uter.org> wrote:


Hello John,

The word "useless" means "redundant" in the various pla= ces it appears
in the document.  In each case where "useless" appears, I ha= ve checked
that "redundant" keeps the proper meaning.  I agree that you= r other
two meanings of "useless" ("out-of-date" or "subop= timal") are often
used, but not in the AODVv2 specification.

I looked for instances of "useful".  There are occurrences o= f "useful"
that do NOT mean "not redundant".  For instance, "usefu= l" has the
meaning "relevant" at certain places in the document.  "= ;useful" also
means "applicable".

If you think that some of these uses are similarly ambiguous,
please don't hesitate to point them out.

Regards,
Charlie P.






On 2/4/2013 3:26 AM, Dowdell, John wrote:

Charlie

 

I note that in draft-ietf-manet-= dymo-25 you use the word ‘useless’ in sections 5.7, 7.4, 7.5.1,= 7.6 and 13.4.

 

Please can you clarify the meani= ng of the word as you use it here, assuming the meaning is the same in all = those sections? Do you mean:

 

- =          out of date (in that the overall situation has changed and the content is = wrong)

- =          repeated (in that the content has previously been advised and is being re-= advised in the same form)

- =          not needed (because the content advises a less satisfactory route)<= /font>

- =          or some other meaning?

 

Regards

John

 

The information contained within this e-mail and any= files attached to this e-mail is private and in addition may include comme= rcially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wi= sh to disclose the information contained within this e-mail or attached fil= es, please contact the sender prior to any such disclosure. If you are not = the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and = inform them of the error and delete the e-mail, including any attached file= s from your system. Cassidian Limited, Registered Office : Quadrant House, = Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com 

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




-- 
Regards,
Charlie P.


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

 

The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-mail or attached files, please con= tact the sender prior to any such disclosure. If you are not the intended r= ecipient, any disclosure, copying or distribution is prohibited. Please als= o contact the sender and inform them of the error and delete the e-mail, including any attached files from= your system. Cassidian Limited, Registered Office : Quadrant House, Celtic= Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cas= sidian.com --_000_603F5FD847B5174CBDA37A9DC00532FB06AC4F68SUCNPTEXM02coma_-- From abdussalambaryun@gmail.com Tue Feb 5 05:03:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B7E21F8753 for ; Tue, 5 Feb 2013 05:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb7vCWcy8Bcz for ; Tue, 5 Feb 2013 05:03:23 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8447021F8751 for ; Tue, 5 Feb 2013 05:03:19 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hm6so144806wib.14 for ; Tue, 05 Feb 2013 05:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=X3hvuRW3l8Y9wZZUUOlSVoHl210NXsUMFsJOBV6QZyA=; b=t3faXRmXs9yD/h6W/onNLb+MVAaVtHuehy+I3KbXMtCy5R+2dvC5uwq+M6xrJS3Zt3 1ZzHntmkwC6jVPSabHSzO89kUgZ+q+Hujy3h8AsstNMQC9AN2GPAlrz7CWcAur3VH40x pqn8Dw0Mjwnf0Sm+OghooSIXRS8iNkmMZ8SAMSgYri0kPF/LA0IFDqsvXzvvesZi1+Gv YYr4OPLxk3Ub9frgTJ+A07L+v0PgBcXQ9n/OASO/MBixx/fHbkuIZEtYM+6aiyatMy5X ZP7kLfALcU5mfG8CcBf86Mfy3ilOADK6Xpq1hnhz4Gi1tsyTDztjtYrzc7Q+INk0oRJe kLnQ== MIME-Version: 1.0 X-Received: by 10.194.118.166 with SMTP id kn6mr7303714wjb.18.1360069398704; Tue, 05 Feb 2013 05:03:18 -0800 (PST) Received: by 10.180.101.70 with HTTP; Tue, 5 Feb 2013 05:03:18 -0800 (PST) In-Reply-To: <603F5FD847B5174CBDA37A9DC00532FB06AC4F68@SUCNPTEXM02.com.ad.uk.ds.corp> References: <603F5FD847B5174CBDA37A9DC00532FB06AC41AB@SUCNPTEXM02.com.ad.uk.ds.corp> <51100D99.5030203@computer.org> <603F5FD847B5174CBDA37A9DC00532FB06AC4F68@SUCNPTEXM02.com.ad.uk.ds.corp> Date: Tue, 5 Feb 2013 13:03:18 +0000 Message-ID: From: Abdussalam Baryun To: "Dowdell, John" Content-Type: multipart/alternative; boundary=089e01228a286133cb04d4f9d514 Cc: manet Subject: Re: [manet] 'Useless' in AODVv2 draft 25 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 13:03:25 -0000 --089e01228a286133cb04d4f9d514 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Feb 5, 2013 at 11:58 AM, Dowdell, John wrote: > Abdussalam > > > > As you point out, =91useless=92 can have a number of meanings depending o= n the > context in which the word is used, and is therefore open to interpretatio= n. > I was asking Charlie to clarify the meaning that he wanted to convey in > each of the contexts in which he used the word, so that the scope for > different interpretations can be reduced or eliminated. He has now done s= o, > and I believe he will amend the next draft to use a word that conveys a > more specific meaning. > > > > > The reply of the I-D authors to your message did not include any amendment nor intention of change to be done, please advise, AB --089e01228a286133cb04d4f9d514 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 5, 2013 at 11:58 AM, Dowdell, John <= span dir=3D"ltr"><John.Dowdell@cassidian.com> wrote:

Abdussalam

=A0

As you point out, = =91useless=92 can have a number of meanings depending on the context in whi= ch the word is used, and is therefore open to interpretation. I was asking Charlie to clarify the meaning that he wanted= to convey in each of the contexts in which he used the word, so that the s= cope for different interpretations can be reduced or eliminated. He has now= done so, and I believe he will amend the next draft to use a word that conveys a more specific meaning.

=A0

=A0

The reply of the I-D authors to your message= did not include any amendment nor intention of change=A0to be done, please= advise,
=A0
AB=A0

--089e01228a286133cb04d4f9d514-- From charliep@computer.org Tue Feb 5 12:01:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2131421F8684 for ; Tue, 5 Feb 2013 12:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of9v4zUkDn7u for ; Tue, 5 Feb 2013 12:01:05 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8C721F8833 for ; Tue, 5 Feb 2013 12:00:55 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.247]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1U2ohD-0005SA-Ts; Tue, 05 Feb 2013 15:00:48 -0500 Message-ID: <511164E5.90900@computer.org> Date: Tue, 05 Feb 2013 12:00:37 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <603F5FD847B5174CBDA37A9DC00532FB06AC41AB@SUCNPTEXM02.com.ad.uk.ds.corp> <51100D99.5030203@computer.org> <603F5FD847B5174CBDA37A9DC00532FB06AC4F68@SUCNPTEXM02.com.ad.uk.ds.corp> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020002030903090801000301" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8605d3f4c776e8431225599148d34cc2a0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet Subject: Re: [manet] 'Useless' in AODVv2 draft 25 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 20:01:11 -0000 This is a multi-part message in MIME format. --------------020002030903090801000301 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello Abdussalam, Here are a few changes that I have proposed, in accordance with the terminology discussions. These proposals include a suggestion about replacing "useless" by "redundant". > The term "HandlingRtr" appears in various places of the AODVv2 > specification. Most of the appearances are located in section 7.5, > "Handling a Received RteMsg". It turns out that the section reads > quite well if "HandlingRtr" is simply replaced by "the router", as > long as it is made clear in the beginning of the section that the > router under discussion is the router handling the RteMsg. > > I propose to make this change, and to investigate whether other > instances of "HandlingRtr" are amenable to better wordsmithing. > > According to the earlier discussion about "useless", I propose > to replace existing instances of "useless" by "redundant". Then, > section 7.6 becomes "Suppressing Redundant RteMsgs". > > Another aspect of simplification would be to replace occurrences > of "RteMsg" by "RREQ" within section 7.6, since the specification > does not mandate suppressing redundant RREP messages. Such > redundant RREP messages typically would not occur unless the > optional feature in section 13.4 were implemented. With this > additional change, section 7.6 would be entitled > "Suppressing Redundant RREQ messages". Regards, Charlie P. On 2/5/2013 5:03 AM, Abdussalam Baryun wrote: > On Tue, Feb 5, 2013 at 11:58 AM, Dowdell, John > > wrote: > > Abdussalam > > As you point out, ‘useless’ can have a number of meanings > depending on the context in which the word is used, and is > therefore open to interpretation. I was asking Charlie to clarify > the meaning that he wanted to convey in each of the contexts in > which he used the word, so that the scope for different > interpretations can be reduced or eliminated. He has now done so, > and I believe he will amend the next draft to use a word that > conveys a more specific meaning. > > The reply of the I-D authors to your message did not include any > amendment nor intention of change to be done, please advise, > AB > -- Regards, Charlie P. --------------020002030903090801000301 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hello Abdussalam,

Here are a few changes that I have proposed, in accordance with the
terminology discussions.  These proposals include a suggestion about
replacing "useless" by "redundant".

The term "HandlingRtr" appears in various places of the AODVv2
specification.  Most of the appearances are located in section 7.5,
"Handling a Received RteMsg".  It turns out that the section reads
quite well if "HandlingRtr" is simply replaced by "the router", as
long as it is made clear in the beginning of the section that the
router under discussion is the router handling the RteMsg.

I propose to make this change, and to investigate whether other
instances of "HandlingRtr" are amenable to better wordsmithing.

According to the earlier discussion about "useless", I propose
to replace existing instances of "useless" by "redundant".  Then,
section 7.6 becomes "Suppressing Redundant RteMsgs".

Another aspect of simplification would be to replace occurrences
of "RteMsg" by "RREQ" within section 7.6, since the specification
does not mandate suppressing redundant RREP messages.  Such
redundant RREP messages typically would not occur unless the
optional feature in section 13.4 were implemented.  With this
additional change, section 7.6 would be entitled
"Suppressing Redundant RREQ messages".


Regards,
Charlie P.



On 2/5/2013 5:03 AM, Abdussalam Baryun wrote:
On Tue, Feb 5, 2013 at 11:58 AM, Dowdell, John <John.Dowdell@cassidian.com> wrote:

Abdussalam

 

As you point out, ‘useless’ can have a number of meanings depending on the context in which the word is used, and is therefore open to interpretation. I was asking Charlie to clarify the meaning that he wanted to convey in each of the contexts in which he used the word, so that the scope for different interpretations can be reduced or eliminated. He has now done so, and I believe he will amend the next draft to use a word that conveys a more specific meaning.

 

 

The reply of the I-D authors to your message did not include any amendment nor intention of change to be done, please advise,
 
AB 



-- 
Regards,
Charlie P.
--------------020002030903090801000301-- From abdussalambaryun@gmail.com Tue Feb 5 19:18:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E99321F8A1D for ; Tue, 5 Feb 2013 19:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCt8wLhdEsuj for ; Tue, 5 Feb 2013 19:18:41 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B428921F8A1C for ; Tue, 5 Feb 2013 19:18:40 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id t57so770920wey.13 for ; Tue, 05 Feb 2013 19:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=+TUxxVLKe3oH/jGK2zIcMhWeklT1tdL5YtYoHacXQpw=; b=OkxOsa6oCwOZ5fau1BuNUAoTeCLZcRV5mDacavkFWJoLTYObKrnSXlGDdS2AyEO/kq uvFNYJFEnwvPD9fMgt/kEmOtEHo1QJfjEykgT5Q+lnsWFSwWrchihTOrT52rsJIY5z7T ZqHyUdXf3AECqyCgP2RFRUvJUNRSjWK6L1obI0Or+o+J5YfFMQfX5Yjp4RRhGMyWK1Bv 3UQN42HER95CTTCPna5FXGtOxuq5YBRXkloX7qz1Csd+u8BLm97/rBvxr9GrsaZz0teJ WjRT2cERY+52NU7g7FNcYUL2D5bujy9LP1Dhgz8pecxk3XgF6zX1SIHXe65joNpVpwb7 IjOA== MIME-Version: 1.0 X-Received: by 10.194.118.166 with SMTP id kn6mr11793131wjb.18.1360120719743; Tue, 05 Feb 2013 19:18:39 -0800 (PST) Received: by 10.180.101.70 with HTTP; Tue, 5 Feb 2013 19:18:39 -0800 (PST) In-Reply-To: <511164E5.90900@computer.org> References: <603F5FD847B5174CBDA37A9DC00532FB06AC41AB@SUCNPTEXM02.com.ad.uk.ds.corp> <51100D99.5030203@computer.org> <603F5FD847B5174CBDA37A9DC00532FB06AC4F68@SUCNPTEXM02.com.ad.uk.ds.corp> <511164E5.90900@computer.org> Date: Wed, 6 Feb 2013 04:18:39 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet Subject: Re: [manet] 'Useless' in AODVv2 draft 25 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 03:18:41 -0000 IMO, I still like the word useless because more related if we read the full draft. Not sure why it is needed to be change, the three meanings that were asked have no harm, or do you think they do? or do you think redundant covers the three asked meanings? In your first reply message you mention like a missing of meaning of the word useful more than useless. I don't think your proposal will be reasonable for me if you ignore changing the AODVv2 test of usefulness in draft. The change proposed for section 7.6 is ok. AB On 2/5/13, Charles E. Perkins wrote: > > Hello Abdussalam, > > Here are a few changes that I have proposed, in accordance with the > terminology discussions. These proposals include a suggestion about > replacing "useless" by "redundant". > >> The term "HandlingRtr" appears in various places of the AODVv2 >> specification. Most of the appearances are located in section 7.5, >> "Handling a Received RteMsg". It turns out that the section reads >> quite well if "HandlingRtr" is simply replaced by "the router", as >> long as it is made clear in the beginning of the section that the >> router under discussion is the router handling the RteMsg. >> >> I propose to make this change, and to investigate whether other >> instances of "HandlingRtr" are amenable to better wordsmithing. >> >> According to the earlier discussion about "useless", I propose >> to replace existing instances of "useless" by "redundant". Then, >> section 7.6 becomes "Suppressing Redundant RteMsgs". >> >> Another aspect of simplification would be to replace occurrences >> of "RteMsg" by "RREQ" within section 7.6, since the specification >> does not mandate suppressing redundant RREP messages. Such >> redundant RREP messages typically would not occur unless the >> optional feature in section 13.4 were implemented. With this >> additional change, section 7.6 would be entitled >> "Suppressing Redundant RREQ messages". > > > Regards, > Charlie P. > > > > On 2/5/2013 5:03 AM, Abdussalam Baryun wrote: >> On Tue, Feb 5, 2013 at 11:58 AM, Dowdell, John >> > wrote: >> >> Abdussalam >> >> As you point out, =91useless=92 can have a number of meanings >> depending on the context in which the word is used, and is >> therefore open to interpretation. I was asking Charlie to clarify >> the meaning that he wanted to convey in each of the contexts in >> which he used the word, so that the scope for different >> interpretations can be reduced or eliminated. He has now done so, >> and I believe he will amend the next draft to use a word that >> conveys a more specific meaning. >> >> The reply of the I-D authors to your message did not include any >> amendment nor intention of change to be done, please advise, >> AB >> > > > -- > Regards, > Charlie P. > > From abdussalambaryun@gmail.com Tue Feb 5 19:37:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989A321F8702 for ; Tue, 5 Feb 2013 19:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prME2T3BApFy for ; Tue, 5 Feb 2013 19:37:05 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id E681321F8622 for ; Tue, 5 Feb 2013 19:37:04 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id dr13so727868wgb.2 for ; Tue, 05 Feb 2013 19:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7q85LCgJ5TWjoYtnTxggJc+UyJ+UN0oVq0CeYGO+ScI=; b=jTRnNorzgvxcQmGOv9Dtm/1pP4dOw4ZsNVHTcBJJfQ35flCf1zIBYEmr1CHQH5enRh wiibRktQPaMxK+PfDFTNKCb1iW9F3X0I5MFOxsKqLHSBbrKrC4sLl607+YBbmTSYtvpT ZJ6tNe54boQnA9IMHS5F1RNsjQS1PRXo76t10krS7vZg+0we0GISLwBwAXPN8bpzff5P kScuf/Iq+TyFuvULAZjCkWhihcmWu7iSCWKfB/T2jf6XRiClvZxJjdx3b/7DnNHq9Zo7 XDUwpfyEyCa647l3soYdE2EMcdRgD7W9VZv0eomEZiZqgI6s2icFJrrGnQmQSHezQB7p vOmQ== MIME-Version: 1.0 X-Received: by 10.194.20.231 with SMTP id q7mr46762904wje.44.1360121824105; Tue, 05 Feb 2013 19:37:04 -0800 (PST) Received: by 10.180.101.70 with HTTP; Tue, 5 Feb 2013 19:37:04 -0800 (PST) In-Reply-To: <5110275C.2000806@computer.org> References: <5110275C.2000806@computer.org> Date: Wed, 6 Feb 2013 04:37:04 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Terminology simplifications X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 03:37:05 -0000 On 2/4/13, Charles E. Perkins wrote: > The term "HandlingRtr" appears in various places of the AODVv2 > specification. Most of the appearances are located in section 7.5, > "Handling a Received RteMsg". It turns out that the section reads > quite well if "HandlingRtr" is simply replaced by "the router", as > long as it is made clear in the beginning of the section that the > router under discussion is the router handling the RteMsg. > Agree > I propose to make this change, and to investigate whether other > instances of "HandlingRtr" are amenable to better wordsmithing. > ok > According to the earlier discussion about "useless", I propose > to replace existing instances of "useless" by "redundant". what about the draft mentions test of usefulness? > Then, > section 7.6 becomes "Suppressing Redundant RteMsgs". > ok > Another aspect of simplification would be to replace occurrences > of "RteMsg" by "RREQ" within section 7.6, since the specification > does not mandate suppressing redundant RREP messages. Such > redundant RREP messages typically would not occur unless the > optional feature in section 13.4 were implemented. With this > additional change, section 7.6 would be entitled > "Suppressing Redundant RREQ messages". Yes agree, AB From skb_a02@yahoo.com Thu Feb 7 22:53:31 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA8821F89D5 for ; Thu, 7 Feb 2013 22:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.838 X-Spam-Level: *** X-Spam-Status: No, score=3.838 tagged_above=-999 required=5 tests=[BAYES_60=1, RCVD_IN_SORBS_WEB=0.619, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXXutNaCcLaF for ; Thu, 7 Feb 2013 22:53:30 -0800 (PST) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) by ietfa.amsl.com (Postfix) with SMTP id AC55121F89B5 for ; Thu, 7 Feb 2013 22:53:30 -0800 (PST) Received: from [98.139.215.142] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 08 Feb 2013 06:53:28 -0000 Received: from [98.139.212.246] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 08 Feb 2013 06:53:28 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 08 Feb 2013 06:53:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 274484.2038.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 72808 invoked by uid 60001); 8 Feb 2013 06:53:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360306407; bh=8N84/lKFODffqQwnPKK9fnrkGDMiIMBrbNo/jfx2RBs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=5p4hFx9cpthnzaVP7J4NFuk3UrJH7lVbO3oT6CZywKOqjaKI+oQZy5BCF1MXfoBfzAEdRF7uIwpMLwUOtPXPNRHHbCJUF4xU7g7HxRauM4YHfFqyRfb6EfWH1BhEsylUCJTdLYCEXQ/UYFCfaMZknnuJhN+RrqIqMT39bx3G8Bg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=ROEMC2G5/FvkV00Zk+Qr382uK8npeu4YQ1eqjmayV3pK+s6OLu/9wi51Oq7IFJKkujSvQmR7BFN8kyk7lNY+HmleCVfiyEEJzKIK8YC8fJuJx2HaczoEsvAZ27/V5THFzqWXFscq2mpi1onV+IqlB0q74Kqz2oh9TUV8tGpdo/I=; X-YMail-OSG: R5CC7N4VM1k1Noh0yKwV7P2Vq.ziqwo7UKUnZ0jbG6N9lG2 7LCFZqEJ84p5Cij44dxSNHTH6ofbse26NAowbq9DaGtCoIZ6x955xcgUqCXM SjCdhLmPHosi9nRk5VHqHlSX8Qn_8JZaNhh..OAyUUApciGXiJ9uCN22T_wb sJMVnAcLoqLthwMfrO4vvNR3KvP9povA72FvGA2Jgcd_eGCnJJPyU5zCbgkw llan9lTBufNCmrgInCCWEbugd4GLSmXn49GOMasFcJ1rt7mc_3_uqHEXpx1g 8xwHqGRU6YHLnDBWswuu.vKd6XYhT0kf9fo94B33LoDZ4iAMS19FGalLpPcg afTQ20ylV_tnLTWafC9pvgluEwY6x2B_YIzmXlq87WaTm6fjR0tqRSlqseMZ 1fj5f1jXxFh_80H1IViw7N9VDVFSnPm2L3OS5DeDkSDKnfxsAo1JBt8wtwxq KhB25l4xRcN17dasHPvRW4fTmesZOEgyaNMF4xHCuc4eWHZIIb3bIsKI6ez8 WHvaK3bcXzzClsJBLIDTEzq9qsvQ4XjmDv_4cBQHJubVEC3HwFcY- Received: from [14.99.94.217] by web161701.mail.bf1.yahoo.com via HTTP; Thu, 07 Feb 2013 22:53:27 PST X-Rocket-MIMEInfo: 001.001, Cmh0dHA6Ly9jZS10c3YuZnIvZmFjZWJvb2suY29tLndlaWdodGRyb3BuLnBocD9TSUQ9MTM0ATABAQEB X-Mailer: YahooMailWebService/0.8.132.503 Message-ID: <1360306407.72257.BPMail_high_noncarrier@web161701.mail.bf1.yahoo.com> Date: Thu, 7 Feb 2013 22:53:27 -0800 (PST) From: Sanjay Kumar To: manet@ietf.org, check_mateboy@bismillah.com, gradstudies@ntu.edu.sg, Zahoor.Khan@dal.ca, muhammad.khan.azam84@gmail.com, hashmi7@hotmail.com, umar.qasim@ualberta.ca, hamid_hashmi006@yahoo.com, ayeshabibi88@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 06:53:31 -0000 http://ce-tsv.fr/facebook.com.weightdropn.php?SID=134 From valerio.arnaboldi@iit.cnr.it Fri Feb 8 04:24:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3685A21F86AE for ; Fri, 8 Feb 2013 04:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8NKIsIhiWjI for ; Fri, 8 Feb 2013 04:24:04 -0800 (PST) Received: from irina.iit.cnr.it (irina-lan.iit.cnr.it [146.48.96.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3970721F86C9 for ; Fri, 8 Feb 2013 04:24:03 -0800 (PST) Received: by irina.iit.cnr.it (Postfix, from userid 1001) id CE3013D81AA; Fri, 8 Feb 2013 13:24:01 +0100 (CET) Date: Fri, 08 Feb 2013 13:24:01 +0100 From: Valerio Arnaboldi To: manet@ietf.org Message-ID: <5114ee61.MfgNgkEt7mUX0dhu%valerio.arnaboldi@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [manet] ComCom SI on Opportunistic Networking: Deadline Extended to Feb 26, 2013 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 12:24:05 -0000 *** Our Sincere Apologies if you receive multiple copies of this messag= e *** -----------------------------------------------------------------------= --------- =3D=3D=3D=3D=3D=3D=3D=3D=3D PAPER SUBMISSION DEADLINE HAS BEEN EX= TENDED TO =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 FEBRUARY 26, 2013 (11:59pm PST) -----------------------------------------------------------------------= --------- CALL FOR PAPERS Elsevier - Computer Communications Journal Special Issue on Opportunistic Networking Submission Deadline (extended): February 26, 2013 -----------------------------------------------------------------------= --------- The widespread availability of mobile portable devices enriched with a = variety of sensing capabilities, coupled with the impelling need of com= munication anytime and anywhere, has rapidly raised the interest toward= s new approaches to communications between users. Opportunistic network= s are an instance of the delay tolerant paradigm applied to networks ma= de up of users' portable devices (such as smartphones and tablets). As = such, they are able to cope with challenged network conditions that are= often present in real life, such as high node mobility, variable conne= ctivity, and disconnections, which would impair communications in tradi= tional Mobile Ad Hoc Networks. In this scenario, user mobility becomes = one of the main drivers to enable message delivery. In fact, according = to the store-carry-and-forward paradigm, user devices store messages an= d carry them around while they move in the network, exchanging them upo= n encounter with other nodes, and eventually delivering them to their d= estination or to interested users. This new communication paradigm enab= les legacy applications in challenged scenarios, as well as it paves th= e way to innovative solutions. While opportunistic networks initially r= eceived attention to support communication where an infrastructure is n= ot available (for disaster recovery or in rural areas), nowadays a numb= er of applications can be envisaged ranging from content sharing, throu= gh mobile social networking, to participatory and urban sensing. All th= ese applications rely on data forwarding amongst devices. As a consequ= ence, two aspects become relevant, that is, the need for mechanisms gua= ranteeing trusted and secure communications while preserving users' pri= vacy (in the absence of infrastructure and sometimes even end-to-end co= nnectivity), and incentive mechanisms able to boost the participation i= n the network. This Special Issue of Computer Communications seeks contributions pushi= ng the state of the art in Opportunistic Networking. Topics of interest= include (but are not limited to) the following: - Mobility measurements and models, mobility trace analysis - Measurements, models, and analysis for user behaviors on mobile devic= es =20 - Unicast and multicast routing - Transport, congestion control, and reliability issues - Content dissemination, content caching, service composition, opportun= istic computing - Trust, security & privacy in opportunistic forwarding, incentive mech= anisms, reputation systems, and key management - Application support and middleware for opportunistic networks - New applications and services relying on opportunistic networking - Systems and experience for real-world deployments Schedule -------- Submission deadline (extended): February 26, 2013 Author notification: May 24, 2013 Revised paper due: June 30, 2013 Final author notification: September 16, 2013 Publication: TBD Guest Editors ------------- Chiara Boldrini, IIT-CNR, Italy Kyunghan Lee, Ulsan National Institute of Science and Technology (UNIST= ), Korea Melek Onen, EURECOM, France Joerg Ott, Aalto University, Finland Elena Pagani, Universita' degli Studi di Milano, Italy Instructions for submission --------------------------- Manuscripts must not have been previously published nor currently under= review by other journals or conferences. If the paper was published in= a conference, the submitted manuscript should be a substantial extensi= on of the conference paper. In this case, authors are also required to = submit their published conference articles and a summary document expla= ining the enhancements made in the journal version. Papers must be submitted through the Computer Communications website at= http://ees.elsevier.com/comcom, where guidelines for manuscript prepar= ation can also be found. To ensure that all manuscripts are correctly i= dentified for consideration by the Special Issue, the authors should se= lect "Special Issue: Opp-Net" when they reach the "Article Type" step i= n the submission process. For further information, please contact the guest editors at comcomsi_oppnet@iit.cnr.it From rdroms.ietf@gmail.com Fri Feb 8 10:22:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E559A21F886F for ; Fri, 8 Feb 2013 10:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFO-zj47okzU for ; Fri, 8 Feb 2013 10:22:57 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 23E1621F85E2 for ; Fri, 8 Feb 2013 10:22:57 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id n11so2482467vch.19 for ; Fri, 08 Feb 2013 10:22:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=QSnY3/3a1xsSOSXiAeUDCYiFCLn8EP0BUemu2IbcWTs=; b=wPBGrt00jcPUvsrNdp8Yjd5Oj8O+8mthWg4L44qaLvAh7wJQWz94ST71efwxsBVVWO cuYPh69SGvoN5zOaHIdTAbVRbkTTyZ5a68uC6we7/00iHmrTVSBtWE0ju93UdKPfo31h TvbrN8pRczx6RmJM7RaV1WheR6VIi6br9a6r14Owb7fkplHkX9awXBYYnMggcDHT/zu4 Uou/AbtNG6/O0+WUQHc5M1OiVLIjP5xAC1XYH7utgRR6bHAdP6JBrL67NRwBsqvTqDwx KjJhp2DBM0oM2UOCC6og3x4iW0auuSd4NhiVwFllsu6vlMv3tiS+X7xW116wTRRraxJC QBKQ== X-Received: by 10.58.19.232 with SMTP id i8mr7880491vee.53.1360347776592; Fri, 08 Feb 2013 10:22:56 -0800 (PST) Received: from rtp-rdroms-89113.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id h11sm43345401vdj.12.2013.02.08.10.22.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 10:22:55 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 8 Feb 2013 13:22:52 -0500 To: manet Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [manet] IETF last call and review of draft-cardenas-dff-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 18:22:58 -0000 draft-cardenas-dff is under consideration for publication as an = AD-sponsored individual submission Experimental RFC. I agreed to = sponsor it for publication because it doesn't really fit in any existing = working groups and the requested publication status is Experimental. As = part of the review process, the document is in a 2-week IETF last call. = The last call announcement is included below. To ensure the quality of = the document, it would be helpful to get reviews from manet WG = participants (posted to the ietf@ietf.org discussion list). Thanks. - Ralph =3D=3D=3D=3D=3D The IESG has received a request from an individual submitter to consider the following document: - 'Depth-First Forwarding in Unreliable Networks (DFF)' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-24. Exceptionally, comments may = be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the "Depth-First Forwarding" (DFF) protocol for IPv6 networks, a data forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane, but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies the DFF mechanism both for IPv6 networks (as specified in RFC2460) and in addition also for LoWPAN "mesh-under" networks (as specified in RFC4944). The file can be obtained via http://datatracker.ietf.org/doc/draft-cardenas-dff/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1645/ http://datatracker.ietf.org/ipr/1646/ From charliep@computer.org Fri Feb 8 15:22:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9517321F84E4 for ; Fri, 8 Feb 2013 15:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUXG5SZUTYA9 for ; Fri, 8 Feb 2013 15:22:34 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id EA50D21F8815 for ; Fri, 8 Feb 2013 15:22:33 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1U3xH7-0001rC-CU for manet@ietf.org; Fri, 08 Feb 2013 18:22:33 -0500 Message-ID: <511588AC.7020404@computer.org> Date: Fri, 08 Feb 2013 15:22:20 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: manet@ietf.org References: <061.db3c48158682d65cd854a9d5c40c741f@trac.tools.ietf.org> In-Reply-To: <061.db3c48158682d65cd854a9d5c40c741f@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86749beef7e3bb259a395ec51ab418842d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Subject: Re: [manet] #5: Reorganizing the route table entry timeout management X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 23:22:34 -0000 Hello folks, The route table timeout issue and proposed resolution has been incorporated in the most recent revisions for the AODVv2 specification. If the new timeout structure and definitions are satisfactory, the AODVv2 editing team will consider closing issue #5. Please let us know if there is any objection to closing the issue. Regards, Charlie P. On 11/4/2012 8:52 PM, manet issue tracker wrote: > #5: Reorganizing the route table entry timeout management > > The current set of route timeouts and concepts is confusing. Instead, one > can view a route table entry as having a normal lifetime progressing > through the following stages: Active --> Idle --> Expired --> Expunged. > Alternatively a route can be prematurely invalidated if one of its path > components breaks (i.e., the link to a next hop breaks). By reorganizing > route lifetime information in this way, a much simpler description can be > given. The following proposed text should make this approach clearer. > Instead of previous manifest constants for various timeout information, > the new approach only requires ACTIVE_INTERVAL, MAX_IDLETIME, and > MAX_SEQNUM_LIFETIME. The following text has been (provisionally) added to > Section 4.1. > > ======================================================================== > > A route table entry (i.e., a route) may be in one of the following > states: > > Active > An Active route is in current use for forwarding packets > > Idle > An Idle route can be used for forwarding packets, even though it > is not in current use > > Expired > After a route has been idle for too long, it expires, and may no > longer be used for forwarding packets > > Broken > A route marked as Broken cannot be used for forwarding packets but > still has valid destination sequence number information. > > The route's state determines the operations that can be performed on > the route table entry. During use, an Active route is maintained > continuously by AODVv2 and is considered to remain active as long as > it is used at least once every ACTIVE_INTERVAL. When a route is no > longer Active, it becomes an Idle route. After a route remains Idle > for MAX_IDLETIME, it becomes an Expired route; after that, the route > is not used for forwarding, but the sequence number information is > maintained until the destination sequence number has had no updates > for MAX_SEQNUM_LIFETIME. After MAX_SEQNUM_LIFETIME, old sequence > number information is considered no longer valuable and the route is > expunged. > > MAX_SEQNUM_LIFETIME is the time after a reboot during which an AODVv2 > router MUST NOT transmit any routing messages. Thus, if all other > AODVv2 routers expunge routes to the rebooted router after that time > interval, the rebooted AODVv2 router's sequence number will not be > considered stale by any other AODVv2 router in the MANET. > > When the link to a route's next hop is broken, the route is in the > Broken state, and it may no longer be used. > > ======================================================================== > > Note that if (ACTIVE_INTERVAL + MAX_IDLETIME) == MAX_SEQNUM_LIFETIME, > then a route has to be expunged as soon as it has been idle too long. > This has little negative impact on the base protocol but may eliminate the > possibility for some optional features related to route repair. > -- Regards, Charlie P. From abdussalambaryun@gmail.com Fri Feb 8 17:00:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B7C21F8C45 for ; Fri, 8 Feb 2013 17:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGoipkinD0ci for ; Fri, 8 Feb 2013 17:00:52 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 17CBF21F8C3F for ; Fri, 8 Feb 2013 17:00:51 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id x8so3518684wey.6 for ; Fri, 08 Feb 2013 17:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EMuil04IOiiExjsrvb8a0qdXWnOj7jOritdfgSbR184=; b=BzDWPn2Mpv97BUHHNc2X+oh8Z6jnO8/0c2H6+ZHGUuCC9zwyEB1LwlG66lAPvXiRY9 ZeDthrLL8+3Q0jBMVfsQ54f9gE9St9jhb0L9nGAF3sFBYcCC8WthOkbwELDYYlVY9rAu e26Wo5nNoTK178h+kv+vf44y0hj2395kbd75ZIs5RHR0kRbV1NRohGn06SgNWAPSqwbl BzdVuvzOIqqC7sfwPJAIOLn4cpHOeIg4ItflmSjqgoAToGU+Cztok7URM5TFN+MDt8Bm 8quN0SuPv05Dn/BNuvDtRuer4R6a8XYudlFfg6z/yunpKF5AT+gK5lnmT75pfiqq31FU h/dw== MIME-Version: 1.0 X-Received: by 10.194.109.102 with SMTP id hr6mr12915692wjb.24.1360371651167; Fri, 08 Feb 2013 17:00:51 -0800 (PST) Received: by 10.180.101.70 with HTTP; Fri, 8 Feb 2013 17:00:50 -0800 (PST) In-Reply-To: <511588AC.7020404@computer.org> References: <061.db3c48158682d65cd854a9d5c40c741f@trac.tools.ietf.org> <511588AC.7020404@computer.org> Date: Sat, 9 Feb 2013 02:00:50 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] #5: Reorganizing the route table entry timeout management X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 01:00:53 -0000 +1 I have no objection. AB On 2/9/13, Charles E. Perkins wrote: > > Hello folks, > > The route table timeout issue and proposed resolution has been incorporated > in the most recent revisions for the AODVv2 specification. If the new > timeout > structure and definitions are satisfactory, the AODVv2 editing team will > consider closing issue #5. Please let us know if there is any objection to > closing the issue. > > Regards, > Charlie P. > > On 11/4/2012 8:52 PM, manet issue tracker wrote: >> #5: Reorganizing the route table entry timeout management >> >> The current set of route timeouts and concepts is confusing. Instead, >> one >> can view a route table entry as having a normal lifetime progressing >> through the following stages: Active --> Idle --> Expired --> Expunged. >> Alternatively a route can be prematurely invalidated if one of its path >> components breaks (i.e., the link to a next hop breaks). By >> reorganizing >> route lifetime information in this way, a much simpler description can >> be >> given. The following proposed text should make this approach clearer. >> Instead of previous manifest constants for various timeout information, >> the new approach only requires ACTIVE_INTERVAL, MAX_IDLETIME, and >> MAX_SEQNUM_LIFETIME. The following text has been (provisionally) added >> to >> Section 4.1. >> >> >> ======================================================================== >> >> A route table entry (i.e., a route) may be in one of the following >> states: >> >> Active >> An Active route is in current use for forwarding packets >> >> Idle >> An Idle route can be used for forwarding packets, even though it >> is not in current use >> >> Expired >> After a route has been idle for too long, it expires, and may no >> longer be used for forwarding packets >> >> Broken >> A route marked as Broken cannot be used for forwarding packets >> but >> still has valid destination sequence number information. >> >> The route's state determines the operations that can be performed on >> the route table entry. During use, an Active route is maintained >> continuously by AODVv2 and is considered to remain active as long as >> it is used at least once every ACTIVE_INTERVAL. When a route is no >> longer Active, it becomes an Idle route. After a route remains Idle >> for MAX_IDLETIME, it becomes an Expired route; after that, the route >> is not used for forwarding, but the sequence number information is >> maintained until the destination sequence number has had no updates >> for MAX_SEQNUM_LIFETIME. After MAX_SEQNUM_LIFETIME, old sequence >> number information is considered no longer valuable and the route is >> expunged. >> >> MAX_SEQNUM_LIFETIME is the time after a reboot during which an >> AODVv2 >> router MUST NOT transmit any routing messages. Thus, if all other >> AODVv2 routers expunge routes to the rebooted router after that time >> interval, the rebooted AODVv2 router's sequence number will not be >> considered stale by any other AODVv2 router in the MANET. >> >> When the link to a route's next hop is broken, the route is in the >> Broken state, and it may no longer be used. >> >> >> ======================================================================== >> >> Note that if (ACTIVE_INTERVAL + MAX_IDLETIME) == MAX_SEQNUM_LIFETIME, >> then a route has to be expunged as soon as it has been idle too long. >> This has little negative impact on the base protocol but may eliminate >> the >> possibility for some optional features related to route repair. >> > > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Fri Feb 8 17:04:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B084321F8C50 for ; Fri, 8 Feb 2013 17:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOgMy7GQ+TCL for ; Fri, 8 Feb 2013 17:04:58 -0800 (PST) Received: from mail-we0-x22c.google.com (we-in-x022c.1e100.net [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E1E2D21F8C45 for ; Fri, 8 Feb 2013 17:04:57 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so3553736wey.17 for ; Fri, 08 Feb 2013 17:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2FWZj51CpGW1IrjkDyeANPtVmI66HHoPqWpITnPh66s=; b=pbwIBuUya7pHS1R3C5mn95QCZicOSVAYMZqUAAKbabUFAT0eYLMFFn/KYA59s9PnQS TmgJ9vBNX84l8j6ltwIZeSQCt9sLDsOq/IuYexlm+L8/izftb50t34grIH0wLnbtbUYw 8AeXY5x5nb54FRXrvgeTt1TQp4kmcpolFgbiRPUpAjxvqFywZvt/V7MtS3C1lskLD6uN VFKYok/mh4QWLP8Yq+0yQtuufOkFwt1EJA7Edpt/eG8mJFU2yeCY+Sw1BZUTkjJ1CGlp QuC5oQrp/FeWyLjcrPSxS72jpdrCcAK5lE4TxTCDE+lW9F0aiUYu4ekBHQdbSuqdbpWY nCKg== MIME-Version: 1.0 X-Received: by 10.194.75.196 with SMTP id e4mr12884404wjw.44.1360371896794; Fri, 08 Feb 2013 17:04:56 -0800 (PST) Received: by 10.180.101.70 with HTTP; Fri, 8 Feb 2013 17:04:56 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Feb 2013 02:04:56 +0100 Message-ID: From: Abdussalam Baryun To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] IETF last call and review of draft-cardenas-dff-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 01:04:59 -0000 I think it fits in 6LowPAN WG but as undertood from authors it seems like the IETF is not allowing new items in that WG. However, I will do my comment as your request, AB On 2/8/13, Ralph Droms wrote: > draft-cardenas-dff is under consideration for publication as an AD-sponsored > individual submission Experimental RFC. I agreed to sponsor it for > publication because it doesn't really fit in any existing working groups and > the requested publication status is Experimental. As part of the review > process, the document is in a 2-week IETF last call. The last call > announcement is included below. To ensure the quality of the document, it > would be helpful to get reviews from manet WG participants (posted to the > ietf@ietf.org discussion list). > > Thanks. > > - Ralph > > > ===== > > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Depth-First Forwarding in Unreliable Networks (DFF)' > as Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-02-24. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document specifies the "Depth-First Forwarding" (DFF) protocol > for IPv6 networks, a data forwarding mechanism that can increase > reliability of data delivery in networks with dynamic topology and/or > lossy links. The protocol operates entirely on the forwarding plane, > but may interact with the routing plane. DFF forwards data packets > using a mechanism similar to a "depth-first search" for the > destination of a packet. The routing plane may be informed of > failures to deliver a packet or loops. This document specifies the > DFF mechanism both for IPv6 networks (as specified in RFC2460) and in > addition also for LoWPAN "mesh-under" networks (as specified in > RFC4944). > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-cardenas-dff/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/1645/ > http://datatracker.ietf.org/ipr/1646/ > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From rdroms@cisco.com Fri Feb 8 17:27:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBEA21F8867 for ; Fri, 8 Feb 2013 17:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSGTLMhH2A7w for ; Fri, 8 Feb 2013 17:27:49 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 66FD621F8843 for ; Fri, 8 Feb 2013 17:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3133; q=dns/txt; s=iport; t=1360373269; x=1361582869; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+wA8YH67vigJBZYD/LvHH5jkRNW/vwNR/Y3jndOZCSo=; b=C0HHkseQxCsGrILlrTsx3zUaB3b7wQ0YwCZGF7Gra42mP6cNT2vCG3kd u55/44kU/mKeA2f/uE7SxiO5pfuyDthBdrOBAH9IeQaOdnxm22WK3T3AV ewaSlpatf+LsNc6temehkSTKRusrTg57nQKla+EmW0OA1pFh0xFP6iPfk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigNAP6kFVGtJV2Z/2dsb2JhbABFgXUIvxUWc4IfAQEBAwEBAQE3NAsFCwIBCBgeECEGCyUCBA4Fh38DCQYMtSoNiVaMFoRlYQOUS4FZgR2KI4UTgwA X-IronPort-AV: E=Sophos;i="4.84,632,1355097600"; d="scan'208";a="175134677" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 09 Feb 2013 01:27:48 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r191RmYB021701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Feb 2013 01:27:48 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.188]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 19:27:47 -0600 From: "Ralph Droms (rdroms)" To: Abdussalam Baryun Thread-Topic: [manet] IETF last call and review of draft-cardenas-dff-09.txt Thread-Index: AQHOBilWgRyDtvjrnEGX1lhksHZjZZhxGzUA//+hzYU= Date: Sat, 9 Feb 2013 01:27:47 +0000 Message-ID: <0C572DC4-1724-4E60-8AD5-E511BD748C34@cisco.com> References: , In-Reply-To: Accept-Language: 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 Cc: manet , Ralph Droms Subject: Re: [manet] IETF last call and review of draft-cardenas-dff-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 01:27:50 -0000 On Feb 8, 2013, at 8:05 PM, "Abdussalam Baryun" wrote: > I think it fits in 6LowPAN WG but as undertood from authors it seems > like the IETF is not allowing new items in that WG. However, I will do > my comment as your request, Thanks and your comments will be appreciated. - Ralph >=20 > AB >=20 > On 2/8/13, Ralph Droms wrote: >> draft-cardenas-dff is under consideration for publication as an AD-spons= ored >> individual submission Experimental RFC. I agreed to sponsor it for >> publication because it doesn't really fit in any existing working groups= and >> the requested publication status is Experimental. As part of the review >> process, the document is in a 2-week IETF last call. The last call >> announcement is included below. To ensure the quality of the document, = it >> would be helpful to get reviews from manet WG participants (posted to th= e >> ietf@ietf.org discussion list). >>=20 >> Thanks. >>=20 >> - Ralph >>=20 >>=20 >> =3D=3D=3D=3D=3D >>=20 >>=20 >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Depth-First Forwarding in Unreliable Networks (DFF)' >> as Experimental RFC >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2013-02-24. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> This document specifies the "Depth-First Forwarding" (DFF) protocol >> for IPv6 networks, a data forwarding mechanism that can increase >> reliability of data delivery in networks with dynamic topology and/or >> lossy links. The protocol operates entirely on the forwarding plane, >> but may interact with the routing plane. DFF forwards data packets >> using a mechanism similar to a "depth-first search" for the >> destination of a packet. The routing plane may be informed of >> failures to deliver a packet or loops. This document specifies the >> DFF mechanism both for IPv6 networks (as specified in RFC2460) and in >> addition also for LoWPAN "mesh-under" networks (as specified in >> RFC4944). >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-cardenas-dff/ >>=20 >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ >>=20 >>=20 >> The following IPR Declarations may be related to this I-D: >>=20 >> http://datatracker.ietf.org/ipr/1645/ >> http://datatracker.ietf.org/ipr/1646/ >>=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 From abdussalambaryun@gmail.com Mon Feb 11 00:03:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3722121F89AA for ; Mon, 11 Feb 2013 00:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4VsyVrazBUk for ; Mon, 11 Feb 2013 00:03:23 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6621F88A3 for ; Mon, 11 Feb 2013 00:03:22 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so4402769wgd.4 for ; Mon, 11 Feb 2013 00:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=VJ4i/d9Wp0gE3uhSOZL9mq8Z1IAKxGgM+5SywdMpbM8=; b=sxpY2EDGHKiexkkJc8Iw48MIlyfHQVZgp4hcGeDDjv5QkdQDeyXYBI+ktEvuDtdg2r CxJr4GOwyFjDm23GvMKBVbRsqNmRP9aOUSHWTskupi+JYFzG4W8c9Tonxgyd4kLk2h8W EoEpx6q4F5uanD/j0KqR6vnaa9AplR1NNm8OLWu5XuI211JmXFwwSLVcrnIbqi/EProN ly6Qckzef/yVvXbvDDy3xdKMQOGilKqvi10Ljqf4RrxTrg42RUazjCE9kwfZpWhHJkPy z3hAu9aTd0JIVuxqjDicMog15wiH+/aNgAyoMJWq3sfWBFE5JRbOqNVR6kpDNygZwFEJ TWcQ== MIME-Version: 1.0 X-Received: by 10.180.78.137 with SMTP id b9mr14053412wix.30.1360569802066; Mon, 11 Feb 2013 00:03:22 -0800 (PST) Received: by 10.180.101.70 with HTTP; Mon, 11 Feb 2013 00:03:21 -0800 (PST) In-Reply-To: <511588AC.7020404@computer.org> References: <061.db3c48158682d65cd854a9d5c40c741f@trac.tools.ietf.org> <511588AC.7020404@computer.org> Date: Mon, 11 Feb 2013 09:03:21 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] #5: Reorganizing the route table entry timeout management X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 08:03:24 -0000 I advise not to close any related issue until Chair makes input. We still not received the email of chair regarding editing team of the reactive protocol. IMO, it is reasonable to close WG-issues only after receiving the Chair's advises. Otherwise why the chair is a chair, I think the chair helps to close such WG issues. The co-chair mentioned to continue WG discuss or I may understand to open issues but not understand to close issues, If I mistaken or missed something please advise, AB On 2/9/13, Charles E. Perkins wrote: > > Hello folks, > > The route table timeout issue and proposed resolution has been incorporated > in the most recent revisions for the AODVv2 specification. If the new > timeout > structure and definitions are satisfactory, the AODVv2 editing team will > consider closing issue #5. Please let us know if there is any objection to > closing the issue. > > Regards, > Charlie P. > > On 11/4/2012 8:52 PM, manet issue tracker wrote: >> #5: Reorganizing the route table entry timeout management >> >> The current set of route timeouts and concepts is confusing. Instead, >> one >> can view a route table entry as having a normal lifetime progressing >> through the following stages: Active --> Idle --> Expired --> Expunged. >> Alternatively a route can be prematurely invalidated if one of its path >> components breaks (i.e., the link to a next hop breaks). By >> reorganizing >> route lifetime information in this way, a much simpler description can >> be >> given. The following proposed text should make this approach clearer. >> Instead of previous manifest constants for various timeout information, >> the new approach only requires ACTIVE_INTERVAL, MAX_IDLETIME, and >> MAX_SEQNUM_LIFETIME. The following text has been (provisionally) added >> to >> Section 4.1. >> >> >> ======================================================================== >> >> A route table entry (i.e., a route) may be in one of the following >> states: >> >> Active >> An Active route is in current use for forwarding packets >> >> Idle >> An Idle route can be used for forwarding packets, even though it >> is not in current use >> >> Expired >> After a route has been idle for too long, it expires, and may no >> longer be used for forwarding packets >> >> Broken >> A route marked as Broken cannot be used for forwarding packets >> but >> still has valid destination sequence number information. >> >> The route's state determines the operations that can be performed on >> the route table entry. During use, an Active route is maintained >> continuously by AODVv2 and is considered to remain active as long as >> it is used at least once every ACTIVE_INTERVAL. When a route is no >> longer Active, it becomes an Idle route. After a route remains Idle >> for MAX_IDLETIME, it becomes an Expired route; after that, the route >> is not used for forwarding, but the sequence number information is >> maintained until the destination sequence number has had no updates >> for MAX_SEQNUM_LIFETIME. After MAX_SEQNUM_LIFETIME, old sequence >> number information is considered no longer valuable and the route is >> expunged. >> >> MAX_SEQNUM_LIFETIME is the time after a reboot during which an >> AODVv2 >> router MUST NOT transmit any routing messages. Thus, if all other >> AODVv2 routers expunge routes to the rebooted router after that time >> interval, the rebooted AODVv2 router's sequence number will not be >> considered stale by any other AODVv2 router in the MANET. >> >> When the link to a route's next hop is broken, the route is in the >> Broken state, and it may no longer be used. >> >> >> ======================================================================== >> >> Note that if (ACTIVE_INTERVAL + MAX_IDLETIME) == MAX_SEQNUM_LIFETIME, >> then a route has to be expunged as soon as it has been idle too long. >> This has little negative impact on the base protocol but may eliminate >> the >> possibility for some optional features related to route repair. >> > > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From yi.jiazi@gmail.com Mon Feb 11 10:47:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E1121F87BB; Mon, 11 Feb 2013 10:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftPn+mF6sc5Z; Mon, 11 Feb 2013 10:47:42 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id B7CB021F87B9; Mon, 11 Feb 2013 10:47:41 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hi8so3499835wib.13 for ; Mon, 11 Feb 2013 10:47:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=LoKYms5qDmvFztiT55JAXcUYvWxu5AtpBJsOpdASfH8=; b=H0CSFsa9ZQjrKYonMjBPnb+oWGBiSsX9btaoUEDhGrnoK9df17cenhJHv/19C9TGpg Pd70ailDTlmnjrDATqfVXL0hG3R+CJvMzzPrfvZ+pTJnrOhM+XmbpxsarIMPdoJVOh5r Y10FJdhnMU1yyF/einTyalsTZ8Sc8tiR+ysgrOGB2SMBWmF6oxDXt9KJTBPhNujB8fM6 oY/oQ7IHMmhfYkY7160/O9XV8yHPatSghuUklCCJURjgYxYTW7fvH2JExGnB5z0p1QLY TSo25jVqUYogZkIduvpEh8K9XAT6uDo8tiHlgjYWJlAEbcsalWSTQvkxfiarqPopJvZ/ oaWg== X-Received: by 10.194.161.135 with SMTP id xs7mr26003218wjb.41.1360608460810; Mon, 11 Feb 2013 10:47:40 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id bf2sm23751366wib.6.2013.02.11.10.47.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 10:47:40 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Mon, 11 Feb 2013 19:47:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0794B0E9-7309-4246-92A2-CFEA023DBBCD@jiaziyi.com> References: To: Ralph Droms , ietf@ietf.org, Ulrich Herberg , "manet@ietf.org List" X-Mailer: Apple Mail (2.1499) Subject: Re: [manet] IETF last call and review of draft-cardenas-dff-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 18:47:43 -0000 Dear all,=20 I had a through review of dff-07 with detailed comments. In the new = revision, my questions and concerns have been properly addressed -- = thanks to all the authors.=20 The mechanism is well documented, and I have tested the protocol in the = scenarios described in the applicability statement, which brings = interesting performance improvement.=20 Therefore, I would like to encourage the publication of it.=20 Just one more comment: o In section 8 Protocol Parameters, it would be better to have = some limitations or recommendations for those parameters. For = P_HOLD_TIME, I think it's OK by saying "at least be MAX_HOP_LIMIT times = the expected time to send a Packet to a router on the same link.". It = would be event better to give such limitations to MAX_HOP_LIMIT. A = regular value related to NET_DIAMETER won't work, because DFF can have = significant higher hop count and result in packet drop. Maybe we can = have something like "it MUST NOT be higher than the number of routers in = the DFF routing domain. If the number of routers is greater than 255, it = is set to 255 by default."=20 best Jiazi On Feb 8, 2013, at 7:22 PM, Ralph Droms wrote: > draft-cardenas-dff is under consideration for publication as an = AD-sponsored individual submission Experimental RFC. I agreed to = sponsor it for publication because it doesn't really fit in any existing = working groups and the requested publication status is Experimental. As = part of the review process, the document is in a 2-week IETF last call. = The last call announcement is included below. To ensure the quality of = the document, it would be helpful to get reviews from manet WG = participants (posted to the ietf@ietf.org discussion list). >=20 > Thanks. >=20 > - Ralph >=20 >=20 > =3D=3D=3D=3D=3D >=20 >=20 > The IESG has received a request from an individual submitter to = consider > the following document: > - 'Depth-First Forwarding in Unreliable Networks (DFF)' > as Experimental RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-02-24. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document specifies the "Depth-First Forwarding" (DFF) protocol > for IPv6 networks, a data forwarding mechanism that can increase > reliability of data delivery in networks with dynamic topology and/or > lossy links. The protocol operates entirely on the forwarding plane, > but may interact with the routing plane. DFF forwards data packets > using a mechanism similar to a "depth-first search" for the > destination of a packet. The routing plane may be informed of > failures to deliver a packet or loops. This document specifies the > DFF mechanism both for IPv6 networks (as specified in RFC2460) and in > addition also for LoWPAN "mesh-under" networks (as specified in > RFC4944). >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-cardenas-dff/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ >=20 >=20 > The following IPR Declarations may be related to this I-D: >=20 > http://datatracker.ietf.org/ipr/1645/ > http://datatracker.ietf.org/ipr/1646/ >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Mon Feb 11 11:49:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C73821F8799 for ; Mon, 11 Feb 2013 11:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fok3QUy6F+v7 for ; Mon, 11 Feb 2013 11:49:34 -0800 (PST) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB2021F878F for ; Mon, 11 Feb 2013 11:49:33 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id oz10so5482209veb.4 for ; Mon, 11 Feb 2013 11:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=9qb1/w5Lrd1yXjhL0N4CRzCZ2ywyo6gSwLGppUHUc5w=; b=Z+Fc03JKBIH2FvLDPL1NHfjW6MrHTwWiXA0i6MuB4sJ8JmUYQy5lgJPjudkfpU/Exq NgVlguSvN03/0C0sEM9y/UnQxvPIYXSvnU60Bn/QC0QeAiPzZwynZMn2gDz2iZ9iOzHM H0OyZnlYQtLiFl/KmfqY30QSCXwZ895m/yhWo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=9qb1/w5Lrd1yXjhL0N4CRzCZ2ywyo6gSwLGppUHUc5w=; b=VO1keFwnCdcXYNDBcXsOwoZ8jKEY8TCCyW0zHT4imh7TnyY3HCqtKGZnnCg3iDbXYp zzJRKKJLjVUGsIxqi6gQqoPi2foSFmseuuUIkItxIT+GhcHC3ISL86AUuJfdOS3mKekP luypwH75npwqkt1HUeOnUe+NeeC6MoagSaPLNvOWTLc0sggxdDhu2cf7u+CqFDRZoB/K Bi6B5WYOjAvZ8TWKuBMTK26/R5gh1BgpmPU6ItM+16KqMIIyUNWvJdxYvu/e3vd/4cTW A+nLekFttBziLerCd+9eh81jVE2UsSSMF2bpi81q479MdEDldZFooObUmFSH24Oqoxnt xatQ== MIME-Version: 1.0 X-Received: by 10.52.32.230 with SMTP id m6mr17751738vdi.83.1360612172730; Mon, 11 Feb 2013 11:49:32 -0800 (PST) Received: by 10.220.146.199 with HTTP; Mon, 11 Feb 2013 11:49:32 -0800 (PST) In-Reply-To: <0794B0E9-7309-4246-92A2-CFEA023DBBCD@jiaziyi.com> References: <0794B0E9-7309-4246-92A2-CFEA023DBBCD@jiaziyi.com> Date: Mon, 11 Feb 2013 11:49:32 -0800 Message-ID: From: Ulrich Herberg To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmyESQCHsLF5k40zrzrqkSM5bDX9+rg/sR08zUbWs79/qPtI4sSNT8TZ2ThHj/7uvGYeS0s Cc: "manet@ietf.org List" , Ralph Droms , ietf@ietf.org Subject: Re: [manet] IETF last call and review of draft-cardenas-dff-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 19:49:35 -0000 Jiazi, thank you very much for your review. I am glad that the latest revision addresses your previous concerns. As to your suggestion, I agree that having some constraints is useful. To your suggestion considering the number of routers in the DFF domain, I think this would be difficult to use normative language, as the number of routers may not be known (e.g. when not using a proactive routing protocol). DFF does not mandate to have this information at hand. Another example of setting the value would be to depend on the expected path length (e.g. based on information from the routing protocol). It may, e.g., be reasonable to set a MAX_HOP_LIMIT that is, say, 50% longer than the distance in hops indicated by a routing protocol. I think that it would be very interesting to find out appropriate values as experiments for the protocol (given that the document is Experimental). How about adding the following text to MAX_HOP_LIMIT: ----- added text ------ Finding optimal values for MAX_HOP_LIMIT is part of experiments that can be performed with the protocol proposed in this document. For example, one possible experiment would be to set MAX_HOP_LIMIT to different factors of the expected path length to the destination in number of hops if provided by a routing protocol. --------------------- Best regards Ulrich On Mon, Feb 11, 2013 at 10:47 AM, Jiazi Yi wrote: > > Dear all, > > I had a through review of dff-07 with detailed comments. In the new revis= ion, my questions and concerns have been properly addressed -- thanks to al= l the authors. > > The mechanism is well documented, and I have tested the protocol in the s= cenarios described in the applicability statement, which brings interesting= performance improvement. > > Therefore, I would like to encourage the publication of it. > > Just one more comment: > > o In section 8 Protocol Parameters, it would be better to have so= me limitations or recommendations for those parameters. For P_HOLD_TIME, I = think it's OK by saying "at least be MAX_HOP_LIMIT times the expected time= to send a Packet to a router on the same link.". It would be event better = to give such limitations to MAX_HOP_LIMIT. A regular value related to NET_D= IAMETER won't work, because DFF can have significant higher hop count and r= esult in packet drop. Maybe we can have something like "it MUST NOT be high= er than the number of routers in the DFF routing domain. If the number of r= outers is greater than 255, it is set to 255 by default." > > best > > Jiazi > > > On Feb 8, 2013, at 7:22 PM, Ralph Droms wrote: > > > draft-cardenas-dff is under consideration for publication as an AD-spon= sored individual submission Experimental RFC. I agreed to sponsor it for p= ublication because it doesn't really fit in any existing working groups and= the requested publication status is Experimental. As part of the review p= rocess, the document is in a 2-week IETF last call. The last call announce= ment is included below. To ensure the quality of the document, it would be= helpful to get reviews from manet WG participants (posted to the ietf@ietf= .org discussion list). > > > > Thanks. > > > > - Ralph > > > > > > =3D=3D=3D=3D=3D > > > > > > The IESG has received a request from an individual submitter to conside= r > > the following document: > > - 'Depth-First Forwarding in Unreliable Networks (DFF)' > > as Experimental RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2013-02-24. Exceptionally, comments may = be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document specifies the "Depth-First Forwarding" (DFF) protocol > > for IPv6 networks, a data forwarding mechanism that can increase > > reliability of data delivery in networks with dynamic topology and/or > > lossy links. The protocol operates entirely on the forwarding plane, > > but may interact with the routing plane. DFF forwards data packets > > using a mechanism similar to a "depth-first search" for the > > destination of a packet. The routing plane may be informed of > > failures to deliver a packet or loops. This document specifies the > > DFF mechanism both for IPv6 networks (as specified in RFC2460) and in > > addition also for LoWPAN "mesh-under" networks (as specified in > > RFC4944). > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-cardenas-dff/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ > > > > > > The following IPR Declarations may be related to this I-D: > > > > http://datatracker.ietf.org/ipr/1645/ > > http://datatracker.ietf.org/ipr/1646/ > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > From yi.jiazi@gmail.com Mon Feb 11 12:37:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD2C21F8923; Mon, 11 Feb 2013 12:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tg5+X+t1C+Or; Mon, 11 Feb 2013 12:37:18 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 63D4821F891D; Mon, 11 Feb 2013 12:37:17 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ez12so3616053wid.0 for ; Mon, 11 Feb 2013 12:37:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=yWVGGPdYccTcmhTfGAhgvTtcxcfYl8vdk0RtqpKeAU0=; b=bJ7FeX/EgsE1mWIqdd43lsa9crXeBCD3mmkBU4Lp+WmVBeyIeoMbVQXjSlbIz/V9pN ScAqkgpuPrVrvFkBgIiSlrR3AOPj3tPM0dBcGC7/EtLp3ijmhYVAUmm6oSBf4bHKySdW jX48KQnscrUMnVngocwubBaKU/TT74k86qwgEDDQ6na5DxYjZP7yiamHCsaZskGiqoEH rs8H8kOLjmunFWWZiNjVFjglrC5ww61O9UG7CTmSAWU8vYNRgvkU4PR01V8tCGQFsnq1 HSyKB8ApPp0V4Wv8NsLGKd8ZvvXDOciqp1VaLTWsADmpQgb7wZtvq31IMiTelPRFBvgd U/7w== X-Received: by 10.194.109.102 with SMTP id hr6mr26409640wjb.24.1360615036505; Mon, 11 Feb 2013 12:37:16 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id s8sm32942518wif.9.2013.02.11.12.37.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 12:37:15 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Mon, 11 Feb 2013 21:37:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <53B9FC50-10C2-4D73-B281-562999E6347C@jiaziyi.com> References: <0794B0E9-7309-4246-92A2-CFEA023DBBCD@jiaziyi.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org List" , Ralph Droms , ietf@ietf.org Subject: Re: [manet] IETF last call and review of draft-cardenas-dff-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 20:37:19 -0000 Hi,=20 I can imagine that it would be hard to set this parameter. According to = my simulation results, even with the same network scenario, the hop = count would be very different depending on if a routing protocol is = used, or which protocol is used.=20 I think it's a good idea to indicate the experimental point, to = encourage people to try it out, and give feedback.=20 best Jiazi On Feb 11, 2013, at 8:49 PM, Ulrich Herberg wrote: > Jiazi, >=20 > thank you very much for your review. I am glad that the latest > revision addresses your previous concerns. >=20 > As to your suggestion, I agree that having some constraints is useful. > To your suggestion considering the number of routers in the DFF > domain, I think this would be difficult to use normative language, as > the number of routers may not be known (e.g. when not using a > proactive routing protocol). DFF does not mandate to have this > information at hand. > Another example of setting the value would be to depend on the > expected path length (e.g. based on information from the routing > protocol). It may, e.g., be reasonable to set a MAX_HOP_LIMIT that is, > say, 50% longer than the distance in hops indicated by a routing > protocol. I think that it would be very interesting to find out > appropriate values as experiments for the protocol (given that the > document is Experimental). >=20 > How about adding the following text to MAX_HOP_LIMIT: >=20 > ----- added text ------ > Finding optimal values for MAX_HOP_LIMIT is part of experiments that > can be performed with the protocol proposed in this document. > For example, one possible experiment would be to set MAX_HOP_LIMIT to > different factors of the expected path length to the destination in > number of hops if provided by a routing protocol. > --------------------- >=20 >=20 >=20 > Best regards > Ulrich >=20 >=20 > On Mon, Feb 11, 2013 at 10:47 AM, Jiazi Yi wrote: >>=20 >> Dear all, >>=20 >> I had a through review of dff-07 with detailed comments. In the new = revision, my questions and concerns have been properly addressed -- = thanks to all the authors. >>=20 >> The mechanism is well documented, and I have tested the protocol in = the scenarios described in the applicability statement, which brings = interesting performance improvement. >>=20 >> Therefore, I would like to encourage the publication of it. >>=20 >> Just one more comment: >>=20 >> o In section 8 Protocol Parameters, it would be better to have = some limitations or recommendations for those parameters. For = P_HOLD_TIME, I think it's OK by saying "at least be MAX_HOP_LIMIT times = the expected time to send a Packet to a router on the same link.". It = would be event better to give such limitations to MAX_HOP_LIMIT. A = regular value related to NET_DIAMETER won't work, because DFF can have = significant higher hop count and result in packet drop. Maybe we can = have something like "it MUST NOT be higher than the number of routers in = the DFF routing domain. If the number of routers is greater than 255, it = is set to 255 by default." >>=20 >> best >>=20 >> Jiazi >>=20 >>=20 >> On Feb 8, 2013, at 7:22 PM, Ralph Droms = wrote: >>=20 >>> draft-cardenas-dff is under consideration for publication as an = AD-sponsored individual submission Experimental RFC. I agreed to = sponsor it for publication because it doesn't really fit in any existing = working groups and the requested publication status is Experimental. As = part of the review process, the document is in a 2-week IETF last call. = The last call announcement is included below. To ensure the quality of = the document, it would be helpful to get reviews from manet WG = participants (posted to the ietf@ietf.org discussion list). >>>=20 >>> Thanks. >>>=20 >>> - Ralph >>>=20 >>>=20 >>> =3D=3D=3D=3D=3D >>>=20 >>>=20 >>> The IESG has received a request from an individual submitter to = consider >>> the following document: >>> - 'Depth-First Forwarding in Unreliable Networks (DFF)' >>> as Experimental RFC >>>=20 >>> The IESG plans to make a decision in the next few weeks, and = solicits >>> final comments on this action. Please send substantive comments to = the >>> ietf@ietf.org mailing lists by 2013-02-24. Exceptionally, comments = may be >>> sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>>=20 >>> Abstract >>>=20 >>>=20 >>> This document specifies the "Depth-First Forwarding" (DFF) protocol >>> for IPv6 networks, a data forwarding mechanism that can increase >>> reliability of data delivery in networks with dynamic topology = and/or >>> lossy links. The protocol operates entirely on the forwarding = plane, >>> but may interact with the routing plane. DFF forwards data packets >>> using a mechanism similar to a "depth-first search" for the >>> destination of a packet. The routing plane may be informed of >>> failures to deliver a packet or loops. This document specifies the >>> DFF mechanism both for IPv6 networks (as specified in RFC2460) and = in >>> addition also for LoWPAN "mesh-under" networks (as specified in >>> RFC4944). >>>=20 >>>=20 >>>=20 >>>=20 >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-cardenas-dff/ >>>=20 >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ >>>=20 >>>=20 >>> The following IPR Declarations may be related to this I-D: >>>=20 >>> http://datatracker.ietf.org/ipr/1645/ >>> http://datatracker.ietf.org/ipr/1646/ >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 From ulrich@herberg.name Mon Feb 11 13:26:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EF521F8A96 for ; Mon, 11 Feb 2013 13:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.755 X-Spam-Level: X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9lOpNtoJdlX for ; Mon, 11 Feb 2013 13:26:09 -0800 (PST) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id D7E0B21F8A66 for ; Mon, 11 Feb 2013 13:26:08 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id oz10so5567976veb.4 for ; Mon, 11 Feb 2013 13:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=aUnfGnFh4JmTz0CjZ2BRR5UqLbtdEjQShCkxEzBmskQ=; b=z+b91mHM5i2y6L2qg8JEgJxdJne/aKva6tOagAg6ZhauMpPOR5u3tL7mTW4bFzYg/y 7MbXEQQ7df5gL7FAdpZ0k/7JkIDWlrPFSAVuUpcd5pTswVTu5nHF92ALC1EGoHC5n85h 0iT0x19iFDlCrpY3LlulQjETu7CaS7svimKoA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=aUnfGnFh4JmTz0CjZ2BRR5UqLbtdEjQShCkxEzBmskQ=; b=joXVo0qYzlfR8P9Xlh0HxztdqvJO6CK7Xe2U8cz29A+hhdZZdlrFnASj+BVO1F5kJo NyNvNZhuLBSeh1wud7iEoaMZZcUZrbcGQJUMLOZPVYpDB+akzXAuANCLHb4ZSYHN9o94 Bri+wdWSKo7JhTj2zGpfXcCtiJVK1baDg6xx+bwksdY7/g4ivzG9w/z2gzaZHNv130/g +h0Znzr2FIZ8gH3iCfQggOvr3A2Kx4YHZKNeuAlXB1H4ICB/641H90bQaUqgpC+FJ6R9 ozeHPK9eXlb42Z8MOFh5Ce7w3XOHc52owAJIkedDcoOYUI3LS7YLbx4/CEOACYYbwRmM ZLAA== MIME-Version: 1.0 X-Received: by 10.52.28.101 with SMTP id a5mr17886127vdh.92.1360617968313; Mon, 11 Feb 2013 13:26:08 -0800 (PST) Received: by 10.220.146.199 with HTTP; Mon, 11 Feb 2013 13:26:08 -0800 (PST) In-Reply-To: <53B9FC50-10C2-4D73-B281-562999E6347C@jiaziyi.com> References: <0794B0E9-7309-4246-92A2-CFEA023DBBCD@jiaziyi.com> <53B9FC50-10C2-4D73-B281-562999E6347C@jiaziyi.com> Date: Mon, 11 Feb 2013 13:26:08 -0800 Message-ID: From: Ulrich Herberg To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmrfjrMomIa1L/EaKg5sGIZVCRRd6E2XsEA1E5AbEY0Tjl0sSWKld57JA/3v2BveBoNpnPe Cc: "manet@ietf.org List" , Ralph Droms , ietf@ietf.org Subject: Re: [manet] IETF last call and review of draft-cardenas-dff-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 21:26:10 -0000 Hi Jiazi, I agree with your observation. I will add the sentence. Best Ulrich On Mon, Feb 11, 2013 at 12:37 PM, Jiazi Yi wrote: > Hi, > > I can imagine that it would be hard to set this parameter. According to m= y simulation results, even with the same network scenario, the hop count wo= uld be very different depending on if a routing protocol is used, or which = protocol is used. > > I think it's a good idea to indicate the experimental point, to encourage= people to try it out, and give feedback. > > best > > Jiazi > > On Feb 11, 2013, at 8:49 PM, Ulrich Herberg wrote: > >> Jiazi, >> >> thank you very much for your review. I am glad that the latest >> revision addresses your previous concerns. >> >> As to your suggestion, I agree that having some constraints is useful. >> To your suggestion considering the number of routers in the DFF >> domain, I think this would be difficult to use normative language, as >> the number of routers may not be known (e.g. when not using a >> proactive routing protocol). DFF does not mandate to have this >> information at hand. >> Another example of setting the value would be to depend on the >> expected path length (e.g. based on information from the routing >> protocol). It may, e.g., be reasonable to set a MAX_HOP_LIMIT that is, >> say, 50% longer than the distance in hops indicated by a routing >> protocol. I think that it would be very interesting to find out >> appropriate values as experiments for the protocol (given that the >> document is Experimental). >> >> How about adding the following text to MAX_HOP_LIMIT: >> >> ----- added text ------ >> Finding optimal values for MAX_HOP_LIMIT is part of experiments that >> can be performed with the protocol proposed in this document. >> For example, one possible experiment would be to set MAX_HOP_LIMIT to >> different factors of the expected path length to the destination in >> number of hops if provided by a routing protocol. >> --------------------- >> >> >> >> Best regards >> Ulrich >> >> >> On Mon, Feb 11, 2013 at 10:47 AM, Jiazi Yi wrote: >>> >>> Dear all, >>> >>> I had a through review of dff-07 with detailed comments. In the new rev= ision, my questions and concerns have been properly addressed -- thanks to = all the authors. >>> >>> The mechanism is well documented, and I have tested the protocol in the= scenarios described in the applicability statement, which brings interesti= ng performance improvement. >>> >>> Therefore, I would like to encourage the publication of it. >>> >>> Just one more comment: >>> >>> o In section 8 Protocol Parameters, it would be better to have s= ome limitations or recommendations for those parameters. For P_HOLD_TIME, I= think it's OK by saying "at least be MAX_HOP_LIMIT times the expected tim= e to send a Packet to a router on the same link.". It would be event better= to give such limitations to MAX_HOP_LIMIT. A regular value related to NET_= DIAMETER won't work, because DFF can have significant higher hop count and = result in packet drop. Maybe we can have something like "it MUST NOT be hig= her than the number of routers in the DFF routing domain. If the number of = routers is greater than 255, it is set to 255 by default." >>> >>> best >>> >>> Jiazi >>> >>> >>> On Feb 8, 2013, at 7:22 PM, Ralph Droms wrote: >>> >>>> draft-cardenas-dff is under consideration for publication as an AD-spo= nsored individual submission Experimental RFC. I agreed to sponsor it for = publication because it doesn't really fit in any existing working groups an= d the requested publication status is Experimental. As part of the review = process, the document is in a 2-week IETF last call. The last call announc= ement is included below. To ensure the quality of the document, it would b= e helpful to get reviews from manet WG participants (posted to the ietf@iet= f.org discussion list). >>>> >>>> Thanks. >>>> >>>> - Ralph >>>> >>>> >>>> =3D=3D=3D=3D=3D >>>> >>>> >>>> The IESG has received a request from an individual submitter to consid= er >>>> the following document: >>>> - 'Depth-First Forwarding in Unreliable Networks (DFF)' >>>> as Experimental RFC >>>> >>>> The IESG plans to make a decision in the next few weeks, and solicits >>>> final comments on this action. Please send substantive comments to the >>>> ietf@ietf.org mailing lists by 2013-02-24. Exceptionally, comments may= be >>>> sent to iesg@ietf.org instead. In either case, please retain the >>>> beginning of the Subject line to allow automated sorting. >>>> >>>> Abstract >>>> >>>> >>>> This document specifies the "Depth-First Forwarding" (DFF) protocol >>>> for IPv6 networks, a data forwarding mechanism that can increase >>>> reliability of data delivery in networks with dynamic topology and/or >>>> lossy links. The protocol operates entirely on the forwarding plane, >>>> but may interact with the routing plane. DFF forwards data packets >>>> using a mechanism similar to a "depth-first search" for the >>>> destination of a packet. The routing plane may be informed of >>>> failures to deliver a packet or loops. This document specifies the >>>> DFF mechanism both for IPv6 networks (as specified in RFC2460) and in >>>> addition also for LoWPAN "mesh-under" networks (as specified in >>>> RFC4944). >>>> >>>> >>>> >>>> >>>> The file can be obtained via >>>> http://datatracker.ietf.org/doc/draft-cardenas-dff/ >>>> >>>> IESG discussion can be tracked via >>>> http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ >>>> >>>> >>>> The following IPR Declarations may be related to this I-D: >>>> >>>> http://datatracker.ietf.org/ipr/1645/ >>>> http://datatracker.ietf.org/ipr/1646/ >>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> > From jpmacker@gmail.com Wed Feb 13 09:21:02 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C03B21F8939 for ; Wed, 13 Feb 2013 09:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnDnatZJhKMk for ; Wed, 13 Feb 2013 09:21:00 -0800 (PST) Received: from mail-la0-x22a.google.com (la-in-x022a.1e100.net [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 610DB21F8994 for ; Wed, 13 Feb 2013 09:20:55 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id fe20so1420969lab.29 for ; Wed, 13 Feb 2013 09:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=3cylubhprsI93uOsqziIvvnrczlNvPYuy/1cHw1y2jM=; b=luTMcccKyqyFteWpFg1jW74j+hscQ9YoCyGG0OYJXLrmHOSLNgdI2QHbvFWB6wlr8H sY+w6Im/pIzTkjRsFzpga26HUdz6JFVHjnwP5gy3axUrAhTPSLi5gY0ywbrpUQvsq1ZZ 18l6BBHPwtsyT2sgZoGHyf7018PIftMg0NiPHFA+E8DUvNqbc9kKWp+zb2YvYk/6AaAP FYErG8dxBW/2J+ZhyPs4skuOQ8YCIECnR895RUlbZN95cK929qPDMfZAJOkqwAl0U8P4 8FXwseO+UoP8LIs2aGZHxYgAGN1h/LUMyCRh+fGP3QiPoZxuTHrjgRsC7WstzT2IQqG7 ZePg== MIME-Version: 1.0 X-Received: by 10.152.104.199 with SMTP id gg7mr20661152lab.14.1360776053002; Wed, 13 Feb 2013 09:20:53 -0800 (PST) Received: by 10.112.46.197 with HTTP; Wed, 13 Feb 2013 09:20:52 -0800 (PST) Date: Wed, 13 Feb 2013 12:20:52 -0500 Message-ID: From: Joseph Macker To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=f46d040890c14210e504d59e5dcc Subject: [manet] Reactive Protocol Editorship Team X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:21:02 -0000 --f46d040890c14210e504d59e5dcc Content-Type: text/plain; charset=ISO-8859-1 All: We as the WG chairs have spent some additional time trying recruit some diverse editorship for the reactive protocol document including authors from other personal reactive IDs. The editing team at present is: Stan Ratliff Charlie Perkins John Dowdell I would like to remind people that major technical content contributors does not necessarily have to originate from editors so I am hoping that we maintain diverse input, review, and consensus-based modifications from the WG community. Actually Stan is serving in an editor role to stimulate that part of the process. Regards, Joe --f46d040890c14210e504d59e5dcc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All:

We as the WG chairs have spent some addit= ional time trying recruit some diverse editorship for the reactive protocol= document including authors from other personal reactive IDs.

The editing team at present is:

Stan Ratliff
Charlie Perkins
John Dowdell

I would like to re= mind people that major technical content contributors does not necessarily = have to originate from editors so I am hoping that we maintain diverse inpu= t, review, and consensus-based modifications from the WG community.=A0 Actu= ally Stan is serving in an editor role to stimulate that part of the proces= s.

Regards,
Joe
--f46d040890c14210e504d59e5dcc-- From abdussalambaryun@gmail.com Wed Feb 13 10:36:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6AB21F84ED for ; Wed, 13 Feb 2013 10:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNiyAf8KL2ry for ; Wed, 13 Feb 2013 10:36:12 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 682DD21F84EA for ; Wed, 13 Feb 2013 10:36:12 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id o1so1796348wic.5 for ; Wed, 13 Feb 2013 10:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BYhUy/rW4NM5+Zh/Xbfv5v2uMnjdz0UGyIdu7C86Hss=; b=gq2a+RdjF6KCXNFnhdmrqyIwR6uo3zAjwlQbax93XKjZ6BYdJXzGrjJkXy0cfBzsWY IJY2mc5ftE1TX5PfvzWT5ynij44OHYOy/OFwqPv247mYMwLPrccdgwpaO79E3+WHmB0m AgwnHYhX0VybyR7aSeJuRe3wo1f+U97PQ+9im8zqovsIBGfK3aBg+X+4gAQ2pY3FyVHG HzHvHNG1uAHOsqT1fAVh57KFZHYLC/jU/qUrzs5hCVdym/18emNbwjZe0wnNhOEafrbn oiuH8lGi01oOTrnxhwdHDQNPEYRxk1QpBXtAqtjzQBosrmVRA0Ut2x75lMIz7KFdP698 fNJQ== MIME-Version: 1.0 X-Received: by 10.194.118.166 with SMTP id kn6mr40170169wjb.18.1360780571607; Wed, 13 Feb 2013 10:36:11 -0800 (PST) Received: by 10.180.101.70 with HTTP; Wed, 13 Feb 2013 10:36:11 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Feb 2013 19:36:11 +0100 Message-ID: From: Abdussalam Baryun To: Joseph Macker Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Editorship Team X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 18:36:13 -0000 Thanks Joe, So do we get to discuss on a new draft-00 that we will wait for submission or do you recommend we continue on the current active reactive draft, please advise, AB On 2/13/13, Joseph Macker wrote: > All: > > We as the WG chairs have spent some additional time trying recruit some > diverse editorship for the reactive protocol document including authors > from other personal reactive IDs. > > The editing team at present is: > > Stan Ratliff > Charlie Perkins > John Dowdell > > I would like to remind people that major technical content contributors > does not necessarily have to originate from editors so I am hoping that we > maintain diverse input, review, and consensus-based modifications from the > WG community. Actually Stan is serving in an editor role to stimulate that > part of the process. > > Regards, > Joe > From sratliff@cisco.com Wed Feb 13 11:35:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1025D21E803D for ; Wed, 13 Feb 2013 11:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJDAouK51RvQ for ; Wed, 13 Feb 2013 11:35:58 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 634C721E803A for ; Wed, 13 Feb 2013 11:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1329; q=dns/txt; s=iport; t=1360784158; x=1361993758; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=muR8aSX4IICVDLgXX/qATllrsYc6bFfWbPvVP6a7fiw=; b=hj3KAe+2qaU5tyDdMU6Y8zFwQxEeSgCNDrTxmtCCVr+2LYIBzDtxAHve f+TE9fMMRwgV8x+EW035cvRsbDlW1fWvRywHS3G7k88Xku38gYxd+Eq9q Ln0F16UcY/O0MkRs18ShXef0bx+pijmhusREZ27j5zNlT6dksMyKxdgaD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHjqG1GtJXHA/2dsb2JhbABFwG4Wc4IfAQEBAwEBAQE3NAsFCwIBCBgKFBAhBgslAgQOBQgMh2wDCQYMtWgNiVcEjDaEbWEDlEuNGYUTgwaCJw X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; d="scan'208";a="173771031" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 13 Feb 2013 19:35:57 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1DJZv8D026704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 19:35:57 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 13:35:57 -0600 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] Reactive Protocol Editorship Team Thread-Index: AQHOCg6Eat0XuaIOm06yR/graUr16ph4gnWAgAAQs4A= Date: Wed, 13 Feb 2013 19:35:57 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10028D26@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.156.0.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <1FFB32B24BD1E2478C37DE0B4FD10486@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Editorship Team X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:35:59 -0000 AB,=20 The current discussion is helping to drive the posting of an AODVv2-00 draf= t. So please, let's continue the discussion on the list.=20 Regards, Stan On Feb 13, 2013, at 1:36 PM, Abdussalam Baryun wrote: > Thanks Joe, >=20 > So do we get to discuss on a new draft-00 that we will wait for > submission or do you recommend we continue on the current active > reactive draft, please advise, >=20 > AB >=20 > On 2/13/13, Joseph Macker wrote: >> All: >>=20 >> We as the WG chairs have spent some additional time trying recruit some >> diverse editorship for the reactive protocol document including authors >> from other personal reactive IDs. >>=20 >> The editing team at present is: >>=20 >> Stan Ratliff >> Charlie Perkins >> John Dowdell >>=20 >> I would like to remind people that major technical content contributors >> does not necessarily have to originate from editors so I am hoping that = we >> maintain diverse input, review, and consensus-based modifications from t= he >> WG community. Actually Stan is serving in an editor role to stimulate t= hat >> part of the process. >>=20 >> Regards, >> Joe >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Wed Feb 13 11:41:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747EE21E8040 for ; Wed, 13 Feb 2013 11:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YD3cqUa9lnaM for ; Wed, 13 Feb 2013 11:41:47 -0800 (PST) Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id C25D721E803D for ; Wed, 13 Feb 2013 11:41:46 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id ds1so4525571wgb.4 for ; Wed, 13 Feb 2013 11:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cWnZUQBiUjrVdDKT8f3VEpNaPD1kvgosSb02WBlfqbM=; b=CprfKfakxQakS/0nuz+9+r5Q3x4hEjMy4E9z32wfj3d83OMlaXaGROm5p8jm4vGBmI ZgOOsYUcbiAGIi6kY2RAqMjp3B2/EQsu9vf/Ey0FC7HGPrL8gfo6XJKjc6RMmt46wFrH ytwvnam9jpqUtPPKEYJzwpPrCtzUidNwxVtwutpsFXMbLJqdg5Bui2pSbBO+fMXW8AdP NO8FpKOrrnJPN7/bmEs4EH0fx0Rr1KIo75iwJuKwWgw5/t9XLGrO9rFnAC5PkfN8nj4Y mSzUe+UTBHxkWUVUJQ9UltVc1/VMaKDYIuV08s7xtZ3yJ5rMgH/7lfaWygsGRv51H0pB MHiQ== MIME-Version: 1.0 X-Received: by 10.194.118.166 with SMTP id kn6mr40513367wjb.18.1360784505674; Wed, 13 Feb 2013 11:41:45 -0800 (PST) Received: by 10.180.101.70 with HTTP; Wed, 13 Feb 2013 11:41:45 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Feb 2013 20:41:45 +0100 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Reactive Protocol Editorship Team X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:41:47 -0000 On 2/13/13, Joseph Macker wrote: > All: > > We as the WG chairs have spent some additional time trying recruit some > diverse editorship for the reactive protocol document including authors > from other personal reactive IDs. I send you my interest to be added in the team but seems that I failed to match the criteria, :-) > I would like to remind people that major technical content contributors > does not necessarily have to originate from editors so I am hoping that we > maintain diverse input, review, and consensus-based modifications from the > WG community. Actually Stan is serving in an editor role to stimulate that > part of the process. I will have to think if I will continue to participate in such item while my interest was ignored :( AB From abdussalambaryun@gmail.com Wed Feb 13 11:42:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064FA21E8040 for ; Wed, 13 Feb 2013 11:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TUJ13EiAexb for ; Wed, 13 Feb 2013 11:42:57 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5B521E803D for ; Wed, 13 Feb 2013 11:42:57 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id 12so1305206wgh.7 for ; Wed, 13 Feb 2013 11:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wAFjwi1ePu1PaU1j7+RkbsXYh35qwPz0DcL80uEAxec=; b=PT/v5MG7aKf1xuTL6rU3BIHXrEv9MOZ4N8rHpFIo1QAa95ThKoz5+DPgCMMeUPXEkG y+CntjqAYOfQTvCeLnJG2MnR7orZTlxQ7MT77HmamALyisEPh87wS7heMG3d8gypLhby oLiyxkkvz6pHQNGBSjQ0v2pbR5qJTZwc2eFk6snxefdz0k3ZT3f9MOWB7/Zz3NeVU4ct x9i1u4ISwHXOe6glj7ah1Ss8JbivxfmWSDXTelppznYOVErgADF9D5CnXKtJ+lIFVIV8 IqBZWqlGdiht/d3eMRPZ10iYDJWfMz3NyHFnD1fA7E88hoOadgX6E+QJcX73ZNO2bTiv c0fA== MIME-Version: 1.0 X-Received: by 10.180.87.98 with SMTP id w2mr12326661wiz.30.1360784576293; Wed, 13 Feb 2013 11:42:56 -0800 (PST) Received: by 10.180.101.70 with HTTP; Wed, 13 Feb 2013 11:42:56 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10028D26@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C10028D26@xmb-aln-x03.cisco.com> Date: Wed, 13 Feb 2013 20:42:56 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Editorship Team X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:42:58 -0000 Thanks Stan, I will try to see if things in the group become interesting :) AB On 2/13/13, Stan Ratliff (sratliff) wrote: > AB, > > The current discussion is helping to drive the posting of an AODVv2-00 > draft. So please, let's continue the discussion on the list. > > Regards, > Stan > > On Feb 13, 2013, at 1:36 PM, Abdussalam Baryun wrote: > >> Thanks Joe, >> >> So do we get to discuss on a new draft-00 that we will wait for >> submission or do you recommend we continue on the current active >> reactive draft, please advise, >> >> AB >> >> On 2/13/13, Joseph Macker wrote: >>> All: >>> >>> We as the WG chairs have spent some additional time trying recruit some >>> diverse editorship for the reactive protocol document including authors >>> from other personal reactive IDs. >>> >>> The editing team at present is: >>> >>> Stan Ratliff >>> Charlie Perkins >>> John Dowdell >>> >>> I would like to remind people that major technical content contributors >>> does not necessarily have to originate from editors so I am hoping that >>> we >>> maintain diverse input, review, and consensus-based modifications from >>> the >>> WG community. Actually Stan is serving in an editor role to stimulate >>> that >>> part of the process. >>> >>> Regards, >>> Joe >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From bebemaster@gmail.com Thu Feb 14 17:13:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832A621F892C for ; Thu, 14 Feb 2013 17:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCmH2wAekppX for ; Thu, 14 Feb 2013 17:13:00 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 09C5B21F88BC for ; Thu, 14 Feb 2013 17:12:59 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id go11so2196586lbb.22 for ; Thu, 14 Feb 2013 17:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=h0zlwYb8Q0CLW72ZNkFaBCHdpx9dqAuljeqcqKltC/8=; b=LuO/vG9QxRmYuI+hD7bzRskvxnUuDbz09X4d9RAaDiGsWuiAtMa2ylPX+rSmmu34vJ o2Y71NHCcOgQaPXtU2YKmxWa4C6jlQ0PEbKyLSQwY0J4mT3o2elOd16rA9IzWGbHNtll 7hyWS9BxGAqTqiabDpRN59RR5f45/93kZTO0GXwFUNbJsg+TpMLscTW+90gxZ5NNIzQt +T9F6l3X0PWpwYLiyEVpp7g7p+ADG5S6ZtCWT5Be5fMSxJoHlxwcUfR0L/UeY0Fp+/+z 426kdLRhuW3iv4SW7ZpMZ4p4w1XEztd3MWPNTp7DPY58dapjJAAeX/K9qZlD4FKCN5FO +jHw== MIME-Version: 1.0 X-Received: by 10.112.27.33 with SMTP id q1mr1436770lbg.78.1360890778848; Thu, 14 Feb 2013 17:12:58 -0800 (PST) Received: by 10.152.20.197 with HTTP; Thu, 14 Feb 2013 17:12:58 -0800 (PST) Date: Thu, 14 Feb 2013 20:12:58 -0500 Message-ID: From: Justin Dean To: manet@ietf.org Content-Type: multipart/alternative; boundary=bcaec554da72738f4304d5b91377 Subject: [manet] Reactive protocol decision process, for the record thoughts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 01:13:01 -0000 --bcaec554da72738f4304d5b91377 Content-Type: text/plain; charset=ISO-8859-1 Let me start by saying that I think no good will come from this message but I feel it's important to get my thoughts (which I believe reflect those of a not insubstantial number of manet participants) out here on the record. The following message may seem very late to the party and it is. I have held off for so long because I was hopeful that things could still work themselves out between between the loadng-dymo camps, clearly this did not happen. Also, I was hopeful that things would still work themselves out between loadng-dymo authors, clearly this has not happened. I do feel getting my thoughts out there on the record is important regardless of how unproductive it may be which is why I am sending it after much internal debate. I am disappointed in the choice of the starting point, dymo over loadng, as the working group document. My personal opinion about the decision matters little in this regard, however what I really most object to is the process by which this decision was made. A while back Adrian was brought in to break a deadlock after the last IETF to facilitate a productive way forward (I did not and still don't envy his job in this regard). He posted [17 Dec] to the list asking people to reply to three options for a way forward: 1. Remove reactive protocol from the charter; 2. Have the AD select one of the documents (other unlikely to be published); 3. Work on both as experimental. For the record I did not reply as I thought these options weren't the only options. Also quote from that email "This is not a vote, but I am taking the mood of the working group in order to inform my decision." Later [14 Jan] it seems to me that it very much was used as a vote when a single document was selected. The rational for selection of one document over the other has been entirely lacking. There have been arguments from both sides on why one document is better than the other. To me those arguments are not equally valid but I can see how they could be considered equal to to some. If they were equal or near enough then a coin flip or some other such random method of choosing would be appropriate. As it happened we were handed a decision, one which (to me) went one step further than what I believed to be a false representation of the options to begin with: deciding that the wg would proceed with versus having an AD picking one of the documents. I had expected some limited time/discussion to allow manet members to put forth their arguments/rational on which document should be selected. Unfortunately, this was not the case. This message is not intended to roll back time or assign blame. It very much seems to me that nearly everyone involved is doing the best they can with what they have. I just wanted my thoughts on the process recorded now before it was entirely too late to do so. Justin Dean --bcaec554da72738f4304d5b91377 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Let me start by saying that I think no good= will come from this message but I feel it's important to get my though= ts (which I believe reflect those of a not insubstantial number of manet pa= rticipants) out here on the record.=A0 The following message may seem very = late to the party and it is. I have held off for so long because I was hope= ful that things could still work themselves out between between the loadng-= dymo camps, clearly this did not happen. Also, I was hopeful that things wo= uld still work themselves out between loadng-dymo authors, clearly this has= not happened. I do feel getting my thoughts out there on the record is imp= ortant regardless of how unproductive it may be which is why I am sending i= t after much internal debate.

I am disappointed in the choice of the starting point, dymo over = loadng, as the working group document.=A0 My personal opinion about the dec= ision matters little in this regard, however what I really most object to i= s the process by which this decision was made.=A0

A while back Adrian was brought in to break a deadlock after the last I= ETF to facilitate a productive way forward (I did not and still don't e= nvy his job in this regard). He posted [17 Dec] to the list asking people t= o reply to three options for a way forward: 1. Remove reactive protocol fro= m the charter; 2. Have the AD select one of the documents (other unlikely t= o be published); 3. Work on both as experimental.=A0 For the record I did n= ot reply as I thought these options weren't the only options.=A0 Also q= uote from that email "This is not a vote, but I am taking the mood of = the working group in order to inform my decision."=A0 Later [14 Jan] i= t seems to me that it very much was used as a vote when a single document w= as selected.

The rational for selection of one document over the other has bee= n entirely lacking. There have been arguments from both sides on why one do= cument is better than the other.=A0 To me those arguments are not equally v= alid but I can see how they could be considered equal to to some.=A0 If the= y were equal or near enough then a coin flip or some other such random meth= od of choosing would be appropriate.=A0 As it happened we were handed a dec= ision, one which (to me) went one step further than what I believed to be a= false representation of the options to begin with:=A0 deciding that the wg= would proceed with versus having an AD picking one of the documents. I had= expected some limited time/discussion to allow manet members to put forth = their arguments/rational on which document should be selected. Unfortunatel= y, this was not the case.

This message is not intended to roll back time or assign bla= me.=A0 It very much seems to me that nearly everyone involved is doing the = best they can with what they have.=A0 I just wanted my thoughts on the proc= ess recorded now before it was entirely too late to do so.

Justin Dean
--bcaec554da72738f4304d5b91377-- From henning.rogge@fkie.fraunhofer.de Thu Feb 14 23:11:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197DF21F86AF for ; Thu, 14 Feb 2013 23:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3e9ViEP6b6eu for ; Thu, 14 Feb 2013 23:11:28 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id F2BFE21F8976 for ; Thu, 14 Feb 2013 23:11:26 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U6FSA-0004lW-0x for manet@ietf.org; Fri, 15 Feb 2013 08:11:26 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U6FS9-0000Gb-Ua for manet@ietf.org; Fri, 15 Feb 2013 08:11:25 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 15 Feb 2013 08:11:25 +0100 Message-ID: <511DDF95.3080706@fkie.fraunhofer.de> Date: Fri, 15 Feb 2013 08:11:17 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030009040607070000070507" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16685/Thu Feb 14 22:24:25 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: a22a8819f20226a2167e46b22584aa1b Subject: Re: [manet] Reactive protocol decision process, for the record thoughts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 07:11:29 -0000 --------------ms030009040607070000070507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 02/15/2013 02:12 AM, Justin Dean wrote: > This message is not intended to roll back time or assign blame. It ver= y > much seems to me that nearly everyone involved is doing the best they > can with what they have. I just wanted my thoughts on the process > recorded now before it was entirely too late to do so. Thank you Justin for speaking out loud what quite a few participants of=20 this list have thought since the decision. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030009040607070000070507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMTUwNzExMjNaMCMGCSqGSIb3DQEJBDEWBBQ4+muIFeXuheK/FkW8VIXwfs7MgDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAEjB3AgDqd7hfM3RnrdzKxzyvXcaD0/GN20cd01SJIxHh 9r0201OATH3S5wrAn5UHSq9mmzQ3hjrYrMIdnaI570afWqpUghX+yLW9PpnzA+FDzMEUlGhk oNIzm8VPa+xLNObriuGWmgirDevQNN3tqqfIyvlgiG52Akn/xrzIJIzntCnoEuX2zScmJ1yc +9o8YtnArK/J/Fz0wkHhwGtGYCn++rf6xsAONFtR1TnOU2Al34GqTofWfj2d1aX0qNxriOLO itG/9qWkDBv5f8/q+/XygXEK1kCEyiK9Rmg0DiI9BES+FAMXQLz7P8fhpS0Mo9R6ueGyFx+w kH/TUVPcYQAAAAAAAA== --------------ms030009040607070000070507-- From henning.rogge@fkie.fraunhofer.de Thu Feb 14 23:46:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A00121F8C01 for ; Thu, 14 Feb 2013 23:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iQEVstE1uT0 for ; Thu, 14 Feb 2013 23:46:57 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id B1F7421F8A7E for ; Thu, 14 Feb 2013 23:46:56 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U6G0V-0008RD-Fg for manet@ietf.org; Fri, 15 Feb 2013 08:46:55 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U6G0V-0001Du-Cz for manet@ietf.org; Fri, 15 Feb 2013 08:46:55 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 15 Feb 2013 08:46:55 +0100 Message-ID: <511DE7EE.7080005@fkie.fraunhofer.de> Date: Fri, 15 Feb 2013 08:46:54 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000901000607040900090102" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16685/Thu Feb 14 22:24:25 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 324d8966091bca9045707e25a905f109 Subject: [manet] Feedback for NHDP implementers. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 07:46:58 -0000 --------------ms000901000607040900090102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, after having quite some work to redesign my NHDP solution I would=20 suggest everyone who wants to implement NHDP to test their=20 implementation with all 11 examples in the RFC... especially the last one. Example number 11 can easily break NHDP implementations (it broke mine=20 and it breaks the NRL implementation at the moment) and it is NOT an=20 unreasonable case. I think you can get a similar situation if a node with IPv6 stateless=20 auto-configuration has a Manet running on to VLAN's of the same ether=20 net card (you will get the same linklocal-IP). This will give a=20 neighbors NHDP two links to a router, with the same IP's on the routers=20 interfaces. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000901000607040900090102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMTUwNzQ2NTRaMCMGCSqGSIb3DQEJBDEWBBQzpP4A/DPPO3l0PK/zGZCpEaRUczBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAPU/ERNjpd/6OSU9SgTe591G7+cqk9xHBF3V33oQ41A/c RqbC3ZXAzmX/b3IV6+9Vi/5bokWBe5pp0a0G2ETfu6/0N30mU8Yq2+XKiA4LaaEdtKurhNLM VNKG8rkvInRRn0YdqIqfQKWaUww8bprTkty4cIhzwaiCl++xkQ5JavE+WjSLspNA8yGFCoRg psUYgp4FmK5MudZ/tzHMuk118VGkm9BNg0Q3qw1+Agqv6hDvvLOp43B7jPdXMV17UlDTQzu8 v2ZY4weR/8i8RkHYwQecWMwUwTLSqHjXjljoT6DIphz+dMp47g4FT+I1vsAuUKPe9/p5wCGm yUf8PA1dAgAAAAAAAA== --------------ms000901000607040900090102-- From abdussalambaryun@gmail.com Fri Feb 15 01:24:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7142E21F8319 for ; Fri, 15 Feb 2013 01:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuk79zUugSt0 for ; Fri, 15 Feb 2013 01:24:51 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4D621F88EA for ; Fri, 15 Feb 2013 01:24:25 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id 16so2544747wgi.15 for ; Fri, 15 Feb 2013 01:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=H/chiiUpgVCxvgSHbHqvAucfa9OmX5OI7Xu6gzuuRdg=; b=moY4wGtLEBGreeXgv5ZphHL6Ty2my4G2pv9qs6Co4YJD1tSszrUqp1Cld1oVMHjtww 7JyUHsHvHYl2DprykIkztW4sW12/RLA4nBUbq02i0nTZ7oV/zWflTOQq94kbh2bNQ2Aa Nhh/MrlSVnGjFOKUsWWE7lRV7uEqkaTKNouCMHuAIMD2YiEpsrIJ9guU9mStDmaElczu 7xpXDeZ9IrYHCWsZoL+LWU/vbL1VQKg0Zp7/8MiqtvGBC7p+c04BgiNLAaGlPQFC1Tg+ fjlLb/GJxwaahqzZMPDs0t442HdzsWUrzy4q56DZXGQNfDk5IlhxVlNtEqZydPnRAHHH pn4A== MIME-Version: 1.0 X-Received: by 10.194.75.196 with SMTP id e4mr2699001wjw.44.1360920263392; Fri, 15 Feb 2013 01:24:23 -0800 (PST) Received: by 10.180.101.70 with HTTP; Fri, 15 Feb 2013 01:24:23 -0800 (PST) In-Reply-To: References: Date: Fri, 15 Feb 2013 10:24:23 +0100 Message-ID: From: Abdussalam Baryun To: Justin Dean Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] Reactive protocol decision process, for the record thoughts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:24:52 -0000 Hi Justin, The IETF WGs is all about participating in its work progress, and to encourage progress with more participation. I thank you for your input, but I think also that all MANET participants have to be involve in any item in the MANET WG, we should not let dymo-load camp or min-groups make decisions for our IETF group. I recommend we always make our input related to our work, we don't let mini-group decide for us. I don't think that direction of AD was taken by votes as you assumed, IMO it was taken after relating to the IETF rules and way of progress, voting is not allowed as I understand, however, the AD can explain to you. My thoughts were always on the list, and some may think that I am sending many input but I disagree. I think the best way/direction is what was suggested by AD for progress. To update the WG DYMO draft and take from LOADng into dymo-25 to be used in the new reactive protocol. I suggest that the new team (or camp as you describe) to author the new reactive protocol to be the ones that were participating on the list for the MANET reactive protocol ( prefered to have LOADng authors if available, but if not others who participated and interetsed). AB ++ On 2/15/13, Justin Dean wrote: > Let me start by saying that I think no good will come from this message but > I feel it's important to get my thoughts (which I believe reflect those of > a not insubstantial number of manet participants) out here on the record. > The following message may seem very late to the party and it is. I have > held off for so long because I was hopeful that things could still work > themselves out between between the loadng-dymo camps, clearly this did not > happen. Also, I was hopeful that things would still work themselves out > between loadng-dymo authors, clearly this has not happened. I do feel > getting my thoughts out there on the record is important regardless of how > unproductive it may be which is why I am sending it after much internal > debate. > > I am disappointed in the choice of the starting point, dymo over loadng, as > the working group document. My personal opinion about the decision matters > little in this regard, however what I really most object to is the process > by which this decision was made. > > A while back Adrian was brought in to break a deadlock after the last IETF > to facilitate a productive way forward (I did not and still don't envy his > job in this regard). He posted [17 Dec] to the list asking people to reply > to three options for a way forward: 1. Remove reactive protocol from the > charter; 2. Have the AD select one of the documents (other unlikely to be > published); 3. Work on both as experimental. For the record I did not > reply as I thought these options weren't the only options. Also quote from > that email "This is not a vote, but I am taking the mood of the working > group in order to inform my decision." Later [14 Jan] it seems to me that > it very much was used as a vote when a single document was selected. > > The rational for selection of one document over the other has been entirely > lacking. There have been arguments from both sides on why one document is > better than the other. To me those arguments are not equally valid but I > can see how they could be considered equal to to some. If they were equal > or near enough then a coin flip or some other such random method of > choosing would be appropriate. As it happened we were handed a decision, > one which (to me) went one step further than what I believed to be a false > representation of the options to begin with: deciding that the wg would > proceed with versus having an AD picking one of the documents. I had > expected some limited time/discussion to allow manet members to put forth > their arguments/rational on which document should be selected. > Unfortunately, this was not the case. > > This message is not intended to roll back time or assign blame. It very > much seems to me that nearly everyone involved is doing the best they can > with what they have. I just wanted my thoughts on the process recorded now > before it was entirely too late to do so. > > Justin Dean > From abdussalambaryun@gmail.com Fri Feb 15 01:29:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8C421F8645 for ; Fri, 15 Feb 2013 01:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwoN-zFcEA-K for ; Fri, 15 Feb 2013 01:29:11 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id F2A0D21F8EC3 for ; Fri, 15 Feb 2013 01:29:10 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id ds1so711038wgb.4 for ; Fri, 15 Feb 2013 01:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=LLkBh3ZLW1RecIGcn8IMx54K7Cz5LpLZg+88ciuQx9w=; b=j2x6t3h/inNYAaFjcsDWRRLNhtv7kYrTGPrSzQSC8Nqeacqy3HbEvT+AcTSVdDeCi/ AvtE7cBDmjkHthSeIx4kwjfwf3U3N+qGWB1iYxRcchubgXyFsLaa0762jPC7UP34BVoK 1P9loO5fmPx1VjmZME+iZaEuHdZw745aaDGXMol5mZ0sC+otdyVb+oPfw9/U17PnyjEk gJYZdJpR7xFKffFib6deYM9yLcWTdYjzMFL7fgSNRWfn70EKBXkCIf0M7BzOMaAfU7nc ELF9kv1DnFqmYg501olVAhCGeWEFZtBIR8uv9i89osFaIdbSKYdyaBEMrD+cYvbzSu7Y kbZw== MIME-Version: 1.0 X-Received: by 10.180.95.66 with SMTP id di2mr4597597wib.18.1360920550083; Fri, 15 Feb 2013 01:29:10 -0800 (PST) Received: by 10.180.101.70 with HTTP; Fri, 15 Feb 2013 01:29:09 -0800 (PST) In-Reply-To: <511DE7EE.7080005@fkie.fraunhofer.de> References: <511DE7EE.7080005@fkie.fraunhofer.de> Date: Fri, 15 Feb 2013 10:29:09 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Feedback for NHDP implementers. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:29:12 -0000 thanks for your advise, I am interested also to make my test as well. Why your latest implementation did not pass the break, or what was the main problem which was not understood, AB On 2/15/13, Henning Rogge wrote: > Hi, > > after having quite some work to redesign my NHDP solution I would > suggest everyone who wants to implement NHDP to test their > implementation with all 11 examples in the RFC... > > especially the last one. > > Example number 11 can easily break NHDP implementations (it broke mine > and it breaks the NRL implementation at the moment) and it is NOT an > unreasonable case. > > I think you can get a similar situation if a node with IPv6 stateless > auto-configuration has a Manet running on to VLAN's of the same ether > net card (you will get the same linklocal-IP). This will give a > neighbors NHDP two links to a router, with the same IP's on the routers > interfaces. > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From henning.rogge@fkie.fraunhofer.de Fri Feb 15 01:37:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E8D21F88EE for ; Fri, 15 Feb 2013 01:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVUHyAcK6qFZ for ; Fri, 15 Feb 2013 01:37:54 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id E327921F8770 for ; Fri, 15 Feb 2013 01:37:53 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U6Hjt-0003BP-9A; Fri, 15 Feb 2013 10:37:53 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U6Hjt-0004D9-6W; Fri, 15 Feb 2013 10:37:53 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 15 Feb 2013 10:37:52 +0100 Message-ID: <511E01EB.3000305@fkie.fraunhofer.de> Date: Fri, 15 Feb 2013 10:37:47 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <511DE7EE.7080005@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030708000505040003040700" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16685/Thu Feb 14 22:24:25 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: cf4e294f566e9b0166dbdd65a574298f Cc: "manet@ietf.org" Subject: Re: [manet] Feedback for NHDP implementers. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:37:55 -0000 --------------ms030708000505040003040700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 02/15/2013 10:29 AM, Abdussalam Baryun wrote: > thanks for your advise, I am interested also to make my test as well. > Why your latest implementation did not pass the break, or what was the > main problem which was not understood, My latest implementation does pass the test successfully. One problem was that I had accidentally not implemented an independent=20 link database for each local interface but one in total. This prevented=20 me from storing multiple links with the same address on the other side. You also have to keep an eye on your index data-structures, because this = "same IP, different link" can easily break these. Pointers/references between neighbor-addresses and link-addresses can=20 create the same problem if you have multiple link-addresses mapping on=20 the same neighbor-address. Do you have an open-source implementation of NHDP? If yes I would like=20 to get a link to the code. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms030708000505040003040700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMTUwOTM3NTBaMCMGCSqGSIb3DQEJBDEWBBQaIfWRuxn2zgGca4q1NuSTgAq1JDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEADolI52DR56gfe4+hQwbzU0BUOaQEg9tEfgAgx8f7VsX9 3PTizrdC8IhuQyYQaYw8zprBn99sz+oDNDXuA/mdQoco+4o6JZqBSmQoemjKYpsW7AYNkEhW rCO+ltwLm2Vn396jTNhRfj25X89uHy/KKe9Zi7P7t4lIdp8dsVQJgeKMY8mFNiPGRi0+YhqO WWzcQQEoo0HujlolYp6zx/ZQM0g5Cs5z6872XwhbYdcGdmiCrsEM8qg8dZOMN0Ui0slYb611 KVnZJ99iQKGGxVuEVUJ7l3INVJMZzQ3wBhinWfZP5SKFTWSfJY9iaSQfi9I3bVESdle4CmO8 LKSKm6yKcAAAAAAAAA== --------------ms030708000505040003040700-- From abdussalambaryun@gmail.com Fri Feb 15 03:45:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542D721F8692 for ; Fri, 15 Feb 2013 03:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1uqSPWUY2S4 for ; Fri, 15 Feb 2013 03:45:58 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 033BD21F8A5F for ; Fri, 15 Feb 2013 03:45:51 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so2721264wge.10 for ; Fri, 15 Feb 2013 03:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=AG/mIqry5bbbavQ1RB1oUWro1j5y168aBXOdSfNa+1g=; b=VYsUbQFcCzDmXooOJgEZG98bHhKKWEjgPL26qLsFU6I96jYkc/FEGKH7k+6JSfeiZT 2+0vHhMagq0g23MUdRUTJLd7pun43wX2za4i/fDYeh7vpTlsTXYpF2rheUxj41CIhb+Z mXnNzKIMtMGwBfm5Nlw+dNGEQEMXuXderjQEgxPYnVvKFskr3yu2g7G/1AgtWSvB/MYy viRaaRi44glRrWQOlMPiZiJE6w7RRfxkVeEfrGk5cmo59knjdWigFpR5h1cTwEHVbGaN oxq5ZM/S7zedw0qyFm11dJ9KlHv7V4OT7MCBflvV3xnfIG8sX0ETUgC2Wa/CLxPBSEF9 kPEg== MIME-Version: 1.0 X-Received: by 10.180.95.66 with SMTP id di2mr5377356wib.18.1360928751215; Fri, 15 Feb 2013 03:45:51 -0800 (PST) Received: by 10.180.101.70 with HTTP; Fri, 15 Feb 2013 03:45:51 -0800 (PST) In-Reply-To: <511E01EB.3000305@fkie.fraunhofer.de> References: <511DE7EE.7080005@fkie.fraunhofer.de> <511E01EB.3000305@fkie.fraunhofer.de> Date: Fri, 15 Feb 2013 12:45:51 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Feedback for NHDP implementers. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 11:45:59 -0000 Hi Henning, I still not complete the NHDP implementation may take some time, but like to send you link when completed to get your opinion, however, thanks for your advise, AB On 2/15/13, Henning Rogge wrote: > On 02/15/2013 10:29 AM, Abdussalam Baryun wrote: >> thanks for your advise, I am interested also to make my test as well. >> Why your latest implementation did not pass the break, or what was the >> main problem which was not understood, > > My latest implementation does pass the test successfully. > > One problem was that I had accidentally not implemented an independent > link database for each local interface but one in total. This prevented > me from storing multiple links with the same address on the other side. > > You also have to keep an eye on your index data-structures, because this > "same IP, different link" can easily break these. > > Pointers/references between neighbor-addresses and link-addresses can > create the same problem if you have multiple link-addresses mapping on > the same neighbor-address. > > Do you have an open-source implementation of NHDP? If yes I would like > to get a link to the code. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > From ulrich@herberg.name Sat Feb 16 09:45:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6092421F8716 for ; Sat, 16 Feb 2013 09:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T76mfj+HP9Kv for ; Sat, 16 Feb 2013 09:45:01 -0800 (PST) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2003921F86D3 for ; Sat, 16 Feb 2013 09:45:00 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id fa15so2843394vbb.11 for ; Sat, 16 Feb 2013 09:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=H7wL+Ue7LhpPVkvJ00Z6qmK/suSRxupMUqlvkO8OFps=; b=f9FfG38edEvmH+mc3JzNbXjGo6aOpLmtglfbyFjLMr8y6rJagaz8iVh89SHe70DXdN U7VHl7+au/6OBtoFR/VYFMyEyC0pIx0QYOQ7IEERxopFFe2i5M3vuZNatAaV9T3uWz0h 4DmQMiWVnseL+rEGPzt9ZU3epsrgeeas4+OZY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=H7wL+Ue7LhpPVkvJ00Z6qmK/suSRxupMUqlvkO8OFps=; b=HR9lFv11TBRt0QU8T2AhCLATHGpC33KrGsaz4qp1EMSOoTYk2piXFF8Bpdj4ys37Pb S7lc0A2Fc7OoGkYYUQfe9NvPLtdr2tsymodboPRDldRMeI5iNGEiBrdZkZhU5VLNHnSR NgWrOYJ7HbfQVHcT/ohldB380OzMEWZSh1VoGGgsjcv2S18f3zHiXDYfFKvF+r0FxOji jHU3GOHvU5AjQ8ZYqnE6eFOkl+yHUVuilM/4JYiKpyW7vI+CDtmnIcUI7cqMLi0MJXbD dNOIzv6OVecJwSEWue/04Qo2b8Kc5oSA9mFst+yZhwPxQwg3PTZ6w3vza/TWlBoM+J6m EBAQ== MIME-Version: 1.0 X-Received: by 10.59.9.201 with SMTP id du9mr8815193ved.38.1361036700453; Sat, 16 Feb 2013 09:45:00 -0800 (PST) Received: by 10.220.24.74 with HTTP; Sat, 16 Feb 2013 09:45:00 -0800 (PST) In-Reply-To: References: Date: Sat, 16 Feb 2013 09:45:00 -0800 Message-ID: From: Ulrich Herberg To: Justin Dean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkFayR9z7Mo7UVPBSdru1fYFkdbASFpIzmnPRt+yF3wFicqBZA20wBL0mVp3Zf1xp5m/PXa Cc: "manet@ietf.org" Subject: Re: [manet] Reactive protocol decision process, for the record thoughts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 17:45:03 -0000 Justin, I very much agree with you, Justin. One point I would like to add is that the WG will now spend a lot of time making the new AODVv2 compatible with LOADng (which is claimed in the current DYMO draft); that is, in my opinion, a wasted effort since the LOADng draft is per definition 100% compatible with LOADng (had that been the starting point). Ignoring a document that has multiple interoperable implementations, deployments, MIB document, as well a support from at least a dozen MANET participants (not only LOADng authors) without giving rational was a disappointment for me. Best regards Ulrich On Feb 14, 2013, at 17:12, Justin Dean wrote: > Let me start by saying that I think no good will come from this message b= ut I feel it's important to get my thoughts (which I believe reflect those = of a not insubstantial number of manet participants) out here on the record= . The following message may seem very late to the party and it is. I have = held off for so long because I was hopeful that things could still work the= mselves out between between the loadng-dymo camps, clearly this did not hap= pen. Also, I was hopeful that things would still work themselves out betwee= n loadng-dymo authors, clearly this has not happened. I do feel getting my = thoughts out there on the record is important regardless of how unproductiv= e it may be which is why I am sending it after much internal debate. > > I am disappointed in the choice of the starting point, dymo over loadng, = as the working group document. My personal opinion about the decision matt= ers little in this regard, however what I really most object to is the proc= ess by which this decision was made. > > A while back Adrian was brought in to break a deadlock after the last IET= F to facilitate a productive way forward (I did not and still don't envy hi= s job in this regard). He posted [17 Dec] to the list asking people to repl= y to three options for a way forward: 1. Remove reactive protocol from the = charter; 2. Have the AD select one of the documents (other unlikely to be p= ublished); 3. Work on both as experimental. For the record I did not reply= as I thought these options weren't the only options. Also quote from that= email "This is not a vote, but I am taking the mood of the working group i= n order to inform my decision." Later [14 Jan] it seems to me that it very= much was used as a vote when a single document was selected. > > The rational for selection of one document over the other has been entire= ly lacking. There have been arguments from both sides on why one document i= s better than the other. To me those arguments are not equally valid but I= can see how they could be considered equal to to some. If they were equal= or near enough then a coin flip or some other such random method of choosi= ng would be appropriate. As it happened we were handed a decision, one whi= ch (to me) went one step further than what I believed to be a false represe= ntation of the options to begin with: deciding that the wg would proceed w= ith versus having an AD picking one of the documents. I had expected some l= imited time/discussion to allow manet members to put forth their arguments/= rational on which document should be selected. Unfortunately, this was not = the case. > > This message is not intended to roll back time or assign blame. It very = much seems to me that nearly everyone involved is doing the best they can w= ith what they have. I just wanted my thoughts on the process recorded now = before it was entirely too late to do so. > > Justin Dean > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Sat Feb 16 12:16:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63DE21F899F for ; Sat, 16 Feb 2013 12:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mp7toj4kgRGK for ; Sat, 16 Feb 2013 12:16:25 -0800 (PST) Received: from mail-we0-x234.google.com (we-in-x0234.1e100.net [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3856721F89A6 for ; Sat, 16 Feb 2013 12:16:25 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id k14so3660697wer.39 for ; Sat, 16 Feb 2013 12:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=MMAwwrFzzFKHyaTA0bNfQ5+zJ0b8axoE4BUWWIBzUkQ=; b=rq3Z6IlaxfhzdvUoY6TkNe+dc/Xkb2EUxTfXpJxlf7tcAv+iRbtWtMBUKgz71JiwZW doZ93teEh1ip0GP5qoCFUwZQlrpD1fI+r4hiSN9cBo7HUUbhBdHhOR1++uGqqk5xLHDf OE0sQ+VvbzeGgIv9YSgbHBVSrG4R4J6/e49u6Xni88wFLStfOJHXqVuXv0jUS2tTDGcH QjBrshWvkNCaWJPvaqTna6OSPCkx+Le0rdFCv/hS2a0kE1hERKD+JucsEOx6SAPy++fX QL3HEA+Mo/Drgsx9lAA4aFJDKdP+wIMyd/zu6g2Gf+R9L/a7qLYTlt+dRth/7tm0oGu3 m+yQ== MIME-Version: 1.0 X-Received: by 10.194.109.102 with SMTP id hr6mr10886028wjb.24.1361045784315; Sat, 16 Feb 2013 12:16:24 -0800 (PST) Received: by 10.180.101.70 with HTTP; Sat, 16 Feb 2013 12:16:24 -0800 (PST) In-Reply-To: References: Date: Sat, 16 Feb 2013 21:16:24 +0100 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Reactive protocol decision process, for the record thoughts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 20:16:25 -0000 > Ignoring a document that has multiple interoperable implementations, > deployments, MIB document, as well a support from at least a dozen > MANET participants (not only LOADng authors) without giving rational > was a disappointment for me. My understanding to the rationale; there was less discussions on the list related to LOADng, it seems like the draft was done outside IETF and then brought to the WG without authors replying on list. For the DYMO there was alot of discussions with replies from authors. AB From hrogge@googlemail.com Sat Feb 16 14:41:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29BF21F86BB for ; Sat, 16 Feb 2013 14:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kqq87j9zc7o for ; Sat, 16 Feb 2013 14:41:24 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 59EA421F89CE for ; Sat, 16 Feb 2013 14:41:24 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c13so6203820ieb.9 for ; Sat, 16 Feb 2013 14:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=wSFmoS+8najcBl6oGbd0fei+7XDYBLuXfQzruHZTqG0=; b=imgB5W7EicGsUNfJGOWYYXC6g0oQ9fQxKq+vTavEcmoTgJDAnTJW09AEjiO/nV4/XB dZsI0zwr7y8uuPxKrG9283IixnQC2GeYPswnWqeobgumS68az3EmTor62G6BBMaAEehs 9yfdzS7UCCMHTCDGo/XEysEg8PAzVneTTlV1bpxW4tgnxIANI44pWcWYSotI8I3tjJEI YO+GctXhL8+/7JEpEH9SgEDFiPvmbH8l9kVxWgxLH0uNcYJsQ3GqcD9ihPD7PgSROV3K RSnQd9kqQryU6YZMez9rqSUOufOuOn33ahrJXeEx+o9T4A1lQFpCEdENSThPDShRc7pZ pKag== X-Received: by 10.50.5.244 with SMTP id v20mr4195163igv.86.1361054483840; Sat, 16 Feb 2013 14:41:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.142.169 with HTTP; Sat, 16 Feb 2013 14:41:03 -0800 (PST) In-Reply-To: References: From: Henning Rogge Date: Sat, 16 Feb 2013 23:41:03 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive protocol decision process, for the record thoughts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 22:41:25 -0000 On Sat, Feb 16, 2013 at 9:16 PM, Abdussalam Baryun wrote: > My understanding to the rationale; there was less discussions on the list > related to LOADng, it seems like the draft was done outside IETF and > then brought to the WG without authors replying on list. For the DYMO > there was alot of discussions with replies from authors. This statement is misleading at best. I think the only person which SOMETIMES did not get a reply from the LOADng team were you... Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From charliep@computer.org Sat Feb 16 17:19:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F6521F868B for ; Sat, 16 Feb 2013 17:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNMtq20elH4C for ; Sat, 16 Feb 2013 17:19:31 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id AFD8F21F84C7 for ; Sat, 16 Feb 2013 17:19:31 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1U6sug-0005j8-Rs; Sat, 16 Feb 2013 20:19:31 -0500 Message-ID: <5120300C.30504@computer.org> Date: Sat, 16 Feb 2013 17:19:08 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Justin Dean References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8628705c4c43d870bb16437e1ac7e8529e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet@ietf.org Subject: Re: [manet] Reactive protocol decision process, for the record thoughts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 01:19:32 -0000 Hello Justin, I can't comment on the process. But I can comment on the likelihood that the result will be a quality document for reactive protocol implementations. I think you would agree that the WG document has undergone really major improvement since October. I am quite sure that the existing editor team will be responsive to requests for changes to the (already pretty good) document, as we have been during recent discussions. I don't want to rehash the history precdeding the month of October. Suffice it to say that the events earlier in the year were not oriented towards resolving technical issues as part of the mailing list and face-to-face discussion. I am very confident that we are making a high-quality specification that fulfills the charter item of the working group, and I know that we will continue to be responsive to the technical issues raised by everyone in the working group. In particular, as I have stated many times, I hope to resolve any issues that would impede LOADng conformance to the specification, but this will have to be a two-way discussion; your input as a LOADng author is especially welcome. -- Regards, Charlie P. From ulrich@herberg.name Sat Feb 16 22:19:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F63B21F8A2F for ; Sat, 16 Feb 2013 22:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7-bUSmL8MYr for ; Sat, 16 Feb 2013 22:19:26 -0800 (PST) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id D4FCC21F8A22 for ; Sat, 16 Feb 2013 22:19:25 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id d10so4075707vea.40 for ; Sat, 16 Feb 2013 22:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=YVjn9zq4rHXFbpFS0lSPNXkd2UVLEUsOCCk2c5wJudU=; b=wjO/J3F/vYCu3vLpNLgDzKSX8FoqWIPoubknq63ZsQ85zxTKrO/5VdWpH1P7LDjTVb P8cvuVH4S5RPQaTXoZ3et7QG96Wnf8SRiR0fIwSMgfsEs0aG2gTHJCydZBRnYBYTbUZU uixqo9QKMLFKju4Z/NxtXEoExmhNOAVbP3a3U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=YVjn9zq4rHXFbpFS0lSPNXkd2UVLEUsOCCk2c5wJudU=; b=Gk/K8CGuyY6Q4IfgquUEit7gnPpXUrjhgw0nuKoJ3TVjYb3V0ovt1/TjdnRQLn/G/O tZTF4pqT71at9B22JWETCXgspMNaVeJz6nug8PNeaJDNFppdOaKF2LqmHfCK7bcojDH4 GkoHh9tcwo2c26x/35ZW3NtZIhhL4TRNiwQSvleVCfWylO0VGkbCbJtZFxKwltIemgEJ h3vu2PTriRS3YT6iQEQ/upK5ZLDpzEt/9YhCf7k1qfdRA+k0x0eM93Az8p/NzHnvnC0K sbjIVv9xc44CGtjOGi99ORFgmUBt3TuRr+hbWGMFiAzKccHI7UBFvwd779k2p6aFXEoX YQOw== MIME-Version: 1.0 X-Received: by 10.52.177.161 with SMTP id cr1mr8954350vdc.64.1361081965299; Sat, 16 Feb 2013 22:19:25 -0800 (PST) Received: by 10.220.24.74 with HTTP; Sat, 16 Feb 2013 22:19:25 -0800 (PST) Date: Sat, 16 Feb 2013 22:19:25 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf3071ceac0d463404d5e59776 X-Gm-Message-State: ALoCoQlPYSbN/6R+sP7qGXbk2U1aOEgoj8efn08t0IRZ2oy62x6FaUh86XoDmZ16MruRcvbfvE8I Cc: manet-chairs@tools.ietf.org Subject: [manet] Slot requests X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 06:19:27 -0000 --20cf3071ceac0d463404d5e59776 Content-Type: text/plain; charset=ISO-8859-1 Hi, please send an email to the chairs and myself if you would like to request a slot during the MANET meeting. The MANET meeting will take place on Thursday, March 14, 3.10pm to 5.10pm, in the room Boca 2. Best regards Ulrich --20cf3071ceac0d463404d5e59776 Content-Type: text/html; charset=ISO-8859-1 Hi,

please send an email to the chairs and myself if you would like to request a slot during the MANET meeting.

The MANET meeting will take place on Thursday, March 14, 3.10pm to 5.10pm, in the room Boca 2.

Best regards
Ulrich
--20cf3071ceac0d463404d5e59776-- From yi.jiazi@gmail.com Sun Feb 17 14:53:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D411621F8A53 for ; Sun, 17 Feb 2013 14:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=-3.242, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBdDYQAGfZWh for ; Sun, 17 Feb 2013 14:53:49 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 985DD21F8A0D for ; Sun, 17 Feb 2013 14:53:48 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id p43so2431598wea.38 for ; Sun, 17 Feb 2013 14:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=xBz5hQM3jrC9gaMw7MW5ZisxCzExlTEA5oGWKcOpt3A=; b=LfuHDTSElMwkplEAu6V5vbBVCpiHtLRgw0w+uU+tskgljqsdTVwhILna3sUm6AZRaT xxUOyC1Sp/kD2q8Aaeu7FBIMevN3yRLjo/6Za+PTyIgCico+YaBFB/xNsZhzds+utkCv LhdElofLjEnfhF+F8qR9RZI8c+aHs/AQwk8D5jUKWtfg3/ZqkDU7SaZ+wQxCF3thiL9i eUBOtgP8+xSYW+VrdVLscByzH4GzHpMr3E80Y+8IUfZ6s/gZlJV0t4t/QJpUsFBsH/eC SyKLrkOBUQaJpC2I+jcSQCgi5p6awZtjDN8HqPByY8r+0fqjPtJ6D3ZNU4I5V8Zz/VQU vPYg== X-Received: by 10.180.98.232 with SMTP id el8mr13363579wib.22.1361141622165; Sun, 17 Feb 2013 14:53:42 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id bs6sm18477691wib.4.2013.02.17.14.53.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 14:53:41 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: <510C391B.7000604@computer.org> Date: Sun, 17 Feb 2013 23:53:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4435713A-CD94-44B9-8AFD-4BFC1E3E06E1@jiaziyi.com> References: <510C391B.7000604@computer.org> To: Charles E. Perkins X-Mailer: Apple Mail (2.1499) Cc: manet Subject: Re: [manet] Micro-history about reactive protocol evolution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 22:53:52 -0000 Dear Charlie, all: As long as there is a mail on the *history* as suggested, if you don't = mind, please allow me to add the one or two details that missed, which = are kind of important.=20 I have no intention to bring any dispute at this moment, but just to = keep a record of what happened in the past several years on reactive = routing protocol.=20 I'm trying my best to be objective, and writing all those down without = personal comment, but with related references to the archive (which = makes the mail a little long). If there is any important detail missing, = or wrong, please don't hesitate to correct me.=20 Jul. 27 2010 - 78 IETF Maastricht, MANET meeting DYMO-21 was submitted before the meeting, but the editors didn't = present the draft.=20 =46rom that time, DYMO was actually "parked" in the following 2~ = years, because of lack of interest and activity in the WG.=20 Jul. 28 2010 - To stimulate the work of DYMO, long comments were given = from different participants.=20 dymo review from Ulrich = http://www.ietf.org/mail-archive/web/manet/current/msg11859.html (July = 2010) dymo review from Thomas = http://www.ietf.org/mail-archive/web/manet/current/msg11858.html (July = 2010) dymo review from Georg = http://www.ietf.org/mail-archive/web/manet/current/msg11974.html (Jan. = 2011) Nov. 2010 (IETF Beijing) Mar. 2011 (IETF Prague)=20 Jul. 2011 (IETF Quebec) There was no presentation and no discussion on DYMO.=20 The dymo editor expressed that he had no time and no passion to = work on the reactive protocol, on different occasions.=20 See minutes: http://tools.ietf.org/wg/manet/minutes?item=3Dminutes79.html = (IETF 79) http://tools.ietf.org/wg/manet/minutes?item=3Dminutes80.html = (IETF 80) Slides: (IETF80) http://www.ietf.org/proceedings/80/slides/manet-6.pdf=20 Revision needed, no revision planned by authors (PARKED = DOCUMENT)=20 http://tools.ietf.org/wg/manet/minutes?item=3Dminutes81.html = (IETF 81) "Currently it is in "parked" status, there is nobody committed = to work on it " (Joe, in 81IETF meeting) =09 Oct. 2011 -00 submission of LOADng, as an individual draft.=20 Nov 2011 13-18, IETF Taipei. The dymo editor was aware of the LOAng = work, and expressed the interested to join.=20 On Nov 18, from 9am to 11 am, there was meeting between the DYMO = editor and part of LOADng authors in the Hyatt hotel of Taipei. On that = meeting, all the participants expressed their interest in working = together on reactive protocol, based on the LOADng document + companion = documents. Renaming it to AODVv2 was discussed, but as not all authors = were party to this meeting, no decision was made on this point.=20 After several mail exchanges, a mail is sent to the WG chairs, = after getting OK from all the authors, including the DYMO editor: > From: Ulrich Herberg > Date: November 29, 2011 7:00:08 PM GMT+01:00 > Subject: DYMO > Joe, Stan, >=20 > During the IETF, Thomas mentioned that we are working on a draft, = called "LOADng" (draft-clausen-lln-loadng). The draft specifies a = reactive routing protocol, mainly intended for low-power and lossy = networks (LLNs). As such, it contains a number of simplifications = compared to AODV and a smaller message overhead. >=20 > During the IETF, we discussed that Charlie join the author list, and = that this document be submitted in place of the currently stalled DYMO = I-D, to satisfy the charter item of a reactive routing protocol. >=20 > Any thoughts on this matter? >=20 > On behalf of the authors, The reply from the chairs was that, they were OK, as long as there was = agreement between the authors.=20 Then the technical discussion continued.=20 Mar. 2012, Paris IETF, dymo editor submitted dymo-22, mostly based on = the design of LOADng http://tools.ietf.org/html/draft-ietf-manet-dymo-22#appendix-A The LOADng authors had expressed that it would be beneficial to = get together - LOADng and DYMO authors - in Paris, and discuss with the = WG prior to submitting an update of DYMO - since having two seemingly = competing documents would be confusing and potentially contentious. The = LOADng authors were unhappy that the DYMO editor dismissed this opinion.=20= Jul. 2012, the DYMO editor said that he wanted to officially join the = author team of LOADng, and to be listed as first author.=20 While accepting the DYMO editor in the LOAng author list, the = request of being first author from the DYMO editor was declined. This, = because so far the author list order was simply reflecting the order in = which each individual had joined the LOADng document. While re-ordering = that (e.g., based on amount of contributions or alphabetically, or ...) = was not excluded, the argument was made that this could be done later / = at the end of the work / by the WG, if the document was adopted. In addition to the first author issue, there were also other two = issues: o The LOADng authors prefer no designated editors, or = editors are only honorific title, while the DYMO editor insisted that he = should be the designated editor, and the one holding the pen.=20 o The LOADng authors prefer continue the editing process = that has been proven to be productive (issue tracker + consensus based), = while the DYMO editor insisted that he wanted to be able to more liberty = in rewriting the draft.=20 There were hundreds mails exchanged in the following 2~ months, = but the DYMO editor was against all the other 9 LOADng authors on the 3 = issues listed above. Oct. 18, 2012, a mail was sent to WG chairs and AD, proposing a way to = go forward, in the spirit of "rough" consensus of the author team: o Select Thomas Clausen and Charlie Perkins as editors.=20= o The "editor" title doesn't change to current editing = process of LOADng.=20 o The author order is unchanged.=20 It was called "rough", because the DYMO editor didn't support = it.=20 Oct. 22, 2012, the DYMO editor began replying to the reviews 2+ years = ago.=20 http://www.ietf.org/mail-archive/web/manet/current/msg13821.html http://www.ietf.org/mail-archive/web/manet/current/msg13811.html At the same time, after 1~ year development cycle, the status of = LOADng was:=20 o at its -06 revision, = http://tools.ietf.org/html/draft-clausen-lln-loadng-06 o with 4 known interoperable running implementations o having completed 4 interop events, documented in an = interop report =20 = http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report= -04 o deployed in field with 2000+ nodes =09 Oct. 30 2012: The 300~mail storm on reactive protocol before Atlanta = IETF=20 http://www.ietf.org/mail-archive/web/manet/current/msg13872.html Nov. 7, 2012, IETF manet meeting, Atlanta. No decision was made, but = "wait for DYMO-24" =09 Dec. 17 2012, AD asked for "mood" from the working group http://www.ietf.org/mail-archive/web/manet/current/msg14446.html Jan. 14, 2013, AD made the decision to take DYMO http://www.ietf.org/mail-archive/web/manet/current/msg14598.html Again, this mail is just to record the facts that happened. The text = above is based on meeting minutes/audio stream/mails exchanged/mailing = list archive.=20 best Jiazi On Feb 1, 2013, at 10:52 PM, Charles E. Perkins = wrote: >=20 > Hello folks, >=20 > As part of the process of making progress on the reactive protocol > specification, it was suggested that a bit of history might be helpful > to understand how we have arrived at the current state. Since most > people on this list have been around for a while and have seen first > hand the recent discussions, I won't go into that. Instead, I'd like > to make a very short summary of what might be unfamiliar to many > people involved in the current discussion. >=20 > AODV and DSR were published as experimental RFCs for reactive = protocols. > OLSR and TBRPF were published as experimental RFCs for proactive. > The plan was to have two later RFCs -- one for proactive, one for = reactive. > The proponents of TBRPF didn't stick around too long, so, the = proactive > protocol became simply OLSRv2. The proponents of AODV and DSR took it > as their job to merge the two "experimental" protocols into a new = reactive > standards track protocol. AODV and DSR together have had hundreds > (thousands?) of citations in peer-reviewed papers, so their features = are > pretty well understood. >=20 > The main difference between AODV and DSR is that DSR uses source > routes whereas AODV uses distance-vector. The authors determined > that the best way to do the merge was to have a feature allowing > "path accumulation", which is now optional in AODVv2. There were > some other features that were dropped from the specification, in > particular "local repair". The name "DYMO" was picked because it > was neither "AODV" nor "DSR", and we all thought it was better to > represent the protocol as a fresh start. Ian Chakeres took over as > editor when Dave Johnson eventually stopped coming to IETF and as > I almost dropped out myself, being in a start-up, etc. In retrospect, > we lost name recognition and the new name never really caught on. > In 2011, when I was asked to resume editorial duties, several people > (frequent contributors to this mailing list) convinced me that the > protocol should be called AODVv2. >=20 > Ian was co-author (with Luke Klein-Berndt) for a protocol called > "AODV Jr.", and so Ian was quite favorable towards crafting DYMO > as a "stripped-down" version of AODV. This is one reason why DYMO > de-emphasized some of the other features of AODV, while yet > incorporating features from DSR. >=20 > The main changes to DYMO have been: > - conversion to RFC 5444 packet formats > - moving Intermediate RREP to separate document > - simplification of rules for incrementing sequence numbers > - renaming to be AODVv2, numerous terminology simplifications > - lastly, enabling the use of alternate metrics >=20 > I hope this is helpful to understand the evolution of the reactive > protocol effort within [manet]. I wrote it from memory, and so I > might have missed one or two details. There is a lot more that > could be written, but then this email would get way too long. >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Sun Feb 17 15:46:02 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EF521F8AF4 for ; Sun, 17 Feb 2013 15:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.115 X-Spam-Level: X-Spam-Status: No, score=-10.115 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSte3ee92VAz for ; Sun, 17 Feb 2013 15:46:01 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B1A7721F8A6C for ; Sun, 17 Feb 2013 15:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1728; q=dns/txt; s=iport; t=1361144761; x=1362354361; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dDa4AromFWltS/QwmkG0CE0vZzuVfq2yfoPELonysQo=; b=dAuWa3b40qQMwjGxWgZvPhz7U8yllpaVmOyHtkMr0KaoH7UeooWDi3r6 LUpifU8sNKp0qWWFZq7fIB3u6dkxtgZyMO6QEM1w2S2NsqqG+Wlzm7S7M lr2JcCJZpSgKtYafdK67ve8VJqkTP2D0BhXtd0RDm9pkovmbQna76DtTQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIhrIVGtJXHB/2dsb2JhbABEwB2BAhZzgh8BAQEDAQEBATc0CwULAgEIGAoUECEGCyUCBA4FCAyHbAMJBgy0Ow2JVgSMWYIrAjEHgl9hA5RRjR6FFYMHgic X-IronPort-AV: E=Sophos;i="4.84,683,1355097600"; d="scan'208";a="178129138" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 17 Feb 2013 23:45:41 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1HNjfXT017159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Feb 2013 23:45:41 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 17:45:41 -0600 From: "JP Vasseur (jvasseur)" To: "Stan Ratliff (sratliff)" Thread-Topic: [manet] Reactive Protocol Editorship Team Thread-Index: AQHODWjkrO8SaYEKI0yDY1KujbfZWA== Date: Sun, 17 Feb 2013 23:45:40 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77232C1305@xmb-rcd-x02.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C10028D26@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10028D26@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.148.109] Content-Type: text/plain; charset="us-ascii" Content-ID: <7C07464039F94E41A3AA067CFE2CAB49@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Reactive Protocol Editorship Team X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 23:46:02 -0000 Thanks Stan, looking forward to seeing the AODVv2-00 draft to send detailed= comments. Thanks for the great progress. JP. On Feb 13, 2013, at 11:35 AM, Stan Ratliff (sratliff) wrote: > AB,=20 >=20 > The current discussion is helping to drive the posting of an AODVv2-00 dr= aft. So please, let's continue the discussion on the list.=20 >=20 > Regards, > Stan >=20 > On Feb 13, 2013, at 1:36 PM, Abdussalam Baryun wrote: >=20 >> Thanks Joe, >>=20 >> So do we get to discuss on a new draft-00 that we will wait for >> submission or do you recommend we continue on the current active >> reactive draft, please advise, >>=20 >> AB >>=20 >> On 2/13/13, Joseph Macker wrote: >>> All: >>>=20 >>> We as the WG chairs have spent some additional time trying recruit some >>> diverse editorship for the reactive protocol document including authors >>> from other personal reactive IDs. >>>=20 >>> The editing team at present is: >>>=20 >>> Stan Ratliff >>> Charlie Perkins >>> John Dowdell >>>=20 >>> I would like to remind people that major technical content contributors >>> does not necessarily have to originate from editors so I am hoping that= we >>> maintain diverse input, review, and consensus-based modifications from = the >>> WG community. Actually Stan is serving in an editor role to stimulate = that >>> part of the process. >>>=20 >>> Regards, >>> Joe >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Mon Feb 18 11:41:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1365A21F8BE8 for ; Mon, 18 Feb 2013 11:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.162 X-Spam-Level: X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOYKRwYqDNIJ for ; Mon, 18 Feb 2013 11:41:33 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id 64E7F21F8A85 for ; Mon, 18 Feb 2013 11:41:30 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id l22so3851420vbn.0 for ; Mon, 18 Feb 2013 11:41:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=x-received:references:from:in-reply-to:mime-version:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=RdV7DIeN/rsUP+vW4iTn510oT7vEMe5HJVP2JnNd0GE=; b=u4gRpcTShelaREPZ2l04g+gZtpyu4+ajvh+Dsug+QllpRZ03003g5M8EGxjGjIEnQC oXBpbQsO/rii4gnaipOkx3Ij28655dLtBd88CDOy0mGzaY8NQz5qjsumZevKuPs6vrBm BtPHL0H6sk8ZMbFe+POUvAZxj51aODArP/Jys= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:from:in-reply-to:mime-version:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=RdV7DIeN/rsUP+vW4iTn510oT7vEMe5HJVP2JnNd0GE=; b=jGpvl4X+bWO03mPToULE9sVg1neDr98Ioh2X/YYdKel4NuTRNCsbJjVXuqIjIFmHCr cs2cBDZLfTvzVDnSEWZz8Yz8RiJDToed0Rf6G0Z1boSg7rttUtAtUA0VI4Ttd+9g94eD 4ietNyZwSTOpPqxtnPXcH1E7ovyu+cttgOsojC/OTX9qNh07L7hM0sfi83LAsoQ2tRm1 lgxw/1Y7KbvuBySlxCjNSumfXm2bvbdLoXL87T9Nv4+AEVhydKZQ1G037WFrplCjCp/e 4UZFJjoGkae8326yPQpmykpqdu/XIoNdRZxn08bxz9b66gMeydgzmW0Do1znyN/NWGEL SXJg== X-Received: by 10.52.67.105 with SMTP id m9mr15110184vdt.128.1361216489771; Mon, 18 Feb 2013 11:41:29 -0800 (PST) References: <510C391B.7000604@computer.org> <4435713A-CD94-44B9-8AFD-4BFC1E3E06E1@jiaziyi.com> From: Ulrich Herberg In-Reply-To: <4435713A-CD94-44B9-8AFD-4BFC1E3E06E1@jiaziyi.com> Mime-Version: 1.0 (1.0) Date: Mon, 18 Feb 2013 11:41:28 -0800 Message-ID: <-2582793250435930327@unknownmsgid> To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQla3pm5u+eYHLMYYkjBRcLNaxbViYz9crDqZfbrF5oCoSe1pcOoR3BkgFMG/RLpntycRNZC Cc: manet Subject: Re: [manet] Micro-history about reactive protocol evolution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:41:35 -0000 Thanks Jiazi for summarizing the history. It reflects very much how I remember it, too. Ulrich Sent from my iPhone On Feb 17, 2013, at 2:54 PM, Jiazi Yi wrote: > Dear Charlie, all: > > As long as there is a mail on the *history* as suggested, if you don't mi= nd, please allow me to add the one or two details that missed, which are ki= nd of important. > I have no intention to bring any dispute at this moment, but just to keep= a record of what happened in the past several years on reactive routing pr= otocol. > > I'm trying my best to be objective, and writing all those down without pe= rsonal comment, but with related references to the archive (which makes the= mail a little long). If there is any important detail missing, or wrong, p= lease don't hesitate to correct me. > > Jul. 27 2010 - 78 IETF Maastricht, MANET meeting > DYMO-21 was submitted before the meeting, but the editors didn't presen= t the draft. > From that time, DYMO was actually "parked" in the following 2~ years, b= ecause of lack of interest and activity in the WG. > > Jul. 28 2010 - To stimulate the work of DYMO, long comments were given f= rom different participants. > dymo review from Ulrich http://www.ietf.org/mail-archive/web/manet/curr= ent/msg11859.html (July 2010) > dymo review from Thomas http://www.ietf.org/mail-archive/web/manet/c= urrent/msg11858.html (July 2010) > dymo review from Georg http://www.ietf.org/mail-archive/web/manet/curre= nt/msg11974.html (Jan. 2011) > > Nov. 2010 (IETF Beijing) > Mar. 2011 (IETF Prague) > Jul. 2011 (IETF Quebec) > There was no presentation and no discussion on DYMO. > The dymo editor expressed that he had no time and no passion to work on= the reactive protocol, on different occasions. > See minutes: > http://tools.ietf.org/wg/manet/minutes?item=3Dminutes79.html (IETF 79) > http://tools.ietf.org/wg/manet/minutes?item=3Dminutes80.html (IETF 80) > Slides: (IETF80) > http://www.ietf.org/proceedings/80/slides/manet-6.pdf > Revision needed, no revision planned by authors (PARKED DOCUMENT) > http://tools.ietf.org/wg/manet/minutes?item=3Dminutes81.html (IETF 81) > "Currently it is in "parked" status, there is nobody committed to work = on it " (Joe, in 81IETF meeting) > > > Oct. 2011 -00 submission of LOADng, as an individual draft. > > Nov 2011 13-18, IETF Taipei. The dymo editor was aware of the LOAng work,= and expressed the interested to join. > On Nov 18, from 9am to 11 am, there was meeting between the DYMO editor= and part of LOADng authors in the Hyatt hotel of Taipei. On that meeting, = all the participants expressed their interest in working together on reacti= ve protocol, based on the LOADng document + companion documents. Renaming i= t to AODVv2 was discussed, but as not all authors were party to this meetin= g, no decision was made on this point. > After several mail exchanges, a mail is sent to the WG chairs, after ge= tting OK from all the authors, including the DYMO editor: >> From: Ulrich Herberg >> Date: November 29, 2011 7:00:08 PM GMT+01:00 >> Subject: DYMO >> Joe, Stan, >> >> During the IETF, Thomas mentioned that we are working on a draft, called= "LOADng" (draft-clausen-lln-loadng). The draft specifies a reactive routin= g protocol, mainly intended for low-power and lossy networks (LLNs). As suc= h, it contains a number of simplifications compared to AODV and a smaller m= essage overhead. >> >> During the IETF, we discussed that Charlie join the author list, and tha= t this document be submitted in place of the currently stalled DYMO I-D, to= satisfy the charter item of a reactive routing protocol. >> >> Any thoughts on this matter? >> >> On behalf of the authors, > > The reply from the chairs was that, they were OK, as long as there was ag= reement between the authors. > Then the technical discussion continued. > > Mar. 2012, Paris IETF, dymo editor submitted dymo-22, mostly based on the= design of LOADng > http://tools.ietf.org/html/draft-ietf-manet-dymo-22#appendix-A > The LOADng authors had expressed that it would be beneficial to get tog= ether - LOADng and DYMO authors - in Paris, and discuss with the WG prior t= o submitting an update of DYMO - since having two seemingly competing docum= ents would be confusing and potentially contentious. The LOADng authors wer= e unhappy that the DYMO editor dismissed this opinion. > > Jul. 2012, the DYMO editor said that he wanted to officially join the aut= hor team of LOADng, and to be listed as first author. > While accepting the DYMO editor in the LOAng author list, the request o= f being first author from the DYMO editor was declined. This, because so f= ar the author list order was simply reflecting the order in which each ind= ividual had joined the LOADng document. While re-ordering that (e.g., based= on amount of contributions or alphabetically, or ...) was not excluded, th= e argument was made that this could be done later / at the end of the work = / by the WG, if the document was adopted. > In addition to the first author issue, there were also other two issues= : > o The LOADng authors prefer no designated editors, or editors are o= nly honorific title, while the DYMO editor insisted that he should be the d= esignated editor, and the one holding the pen. > o The LOADng authors prefer continue the editing process that has b= een proven to be productive (issue tracker + consensus based), while the DY= MO editor insisted that he wanted to be able to more liberty in rewriting t= he draft. > There were hundreds mails exchanged in the following 2~ months, but the= DYMO editor was against all the other 9 LOADng authors on the 3 issues lis= ted above. > > Oct. 18, 2012, a mail was sent to WG chairs and AD, proposing a way to go= forward, in the spirit of "rough" consensus of the author team: > o Select Thomas Clausen and Charlie Perkins as editors. > o The "editor" title doesn't change to current editing process of L= OADng. > o The author order is unchanged. > It was called "rough", because the DYMO editor didn't support it. > > Oct. 22, 2012, the DYMO editor began replying to the reviews 2+ years ago= . > http://www.ietf.org/mail-archive/web/manet/current/msg13821.html > http://www.ietf.org/mail-archive/web/manet/current/msg13811.html > > At the same time, after 1~ year development cycle, the status of LOADng= was: > o at its -06 revision, > http://tools.ietf.org/html/draft-clausen-lln-loadng-06 > o with 4 known interoperable running implementations > o having completed 4 interop events, documented in an interop repor= t > http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperabi= lity-report-04 > o deployed in field with 2000+ nodes > > Oct. 30 2012: The 300~mail storm on reactive protocol before Atlanta IETF > http://www.ietf.org/mail-archive/web/manet/current/msg13872.html > > Nov. 7, 2012, IETF manet meeting, Atlanta. No decision was made, but "wai= t for DYMO-24" > > Dec. 17 2012, AD asked for "mood" from the working group > http://www.ietf.org/mail-archive/web/manet/current/msg14446.html > > Jan. 14, 2013, AD made the decision to take DYMO > http://www.ietf.org/mail-archive/web/manet/current/msg14598.html > > Again, this mail is just to record the facts that happened. The text abov= e is based on meeting minutes/audio stream/mails exchanged/mailing list arc= hive. > > best > > Jiazi > > On Feb 1, 2013, at 10:52 PM, Charles E. Perkins w= rote: > >> >> Hello folks, >> >> As part of the process of making progress on the reactive protocol >> specification, it was suggested that a bit of history might be helpful >> to understand how we have arrived at the current state. Since most >> people on this list have been around for a while and have seen first >> hand the recent discussions, I won't go into that. Instead, I'd like >> to make a very short summary of what might be unfamiliar to many >> people involved in the current discussion. >> >> AODV and DSR were published as experimental RFCs for reactive protocols. >> OLSR and TBRPF were published as experimental RFCs for proactive. >> The plan was to have two later RFCs -- one for proactive, one for reacti= ve. >> The proponents of TBRPF didn't stick around too long, so, the proactive >> protocol became simply OLSRv2. The proponents of AODV and DSR took it >> as their job to merge the two "experimental" protocols into a new reacti= ve >> standards track protocol. AODV and DSR together have had hundreds >> (thousands?) of citations in peer-reviewed papers, so their features are >> pretty well understood. >> >> The main difference between AODV and DSR is that DSR uses source >> routes whereas AODV uses distance-vector. The authors determined >> that the best way to do the merge was to have a feature allowing >> "path accumulation", which is now optional in AODVv2. There were >> some other features that were dropped from the specification, in >> particular "local repair". The name "DYMO" was picked because it >> was neither "AODV" nor "DSR", and we all thought it was better to >> represent the protocol as a fresh start. Ian Chakeres took over as >> editor when Dave Johnson eventually stopped coming to IETF and as >> I almost dropped out myself, being in a start-up, etc. In retrospect, >> we lost name recognition and the new name never really caught on. >> In 2011, when I was asked to resume editorial duties, several people >> (frequent contributors to this mailing list) convinced me that the >> protocol should be called AODVv2. >> >> Ian was co-author (with Luke Klein-Berndt) for a protocol called >> "AODV Jr.", and so Ian was quite favorable towards crafting DYMO >> as a "stripped-down" version of AODV. This is one reason why DYMO >> de-emphasized some of the other features of AODV, while yet >> incorporating features from DSR. >> >> The main changes to DYMO have been: >> - conversion to RFC 5444 packet formats >> - moving Intermediate RREP to separate document >> - simplification of rules for incrementing sequence numbers >> - renaming to be AODVv2, numerous terminology simplifications >> - lastly, enabling the use of alternate metrics >> >> I hope this is helpful to understand the evolution of the reactive >> protocol effort within [manet]. I wrote it from memory, and so I >> might have missed one or two details. There is a lot more that >> could be written, but then this email would get way too long. >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> 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 abdussalambaryun@gmail.com Mon Feb 18 14:23:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126E621F8CDF for ; Mon, 18 Feb 2013 14:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5OzEOeh9AKs for ; Mon, 18 Feb 2013 14:23:11 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8C22C21F8CDB for ; Mon, 18 Feb 2013 14:23:11 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md12so1879412pbc.30 for ; Mon, 18 Feb 2013 14:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=o5lQrExode2KNs3vlCjRqVUvD2OVCdqKBVzfRmgKzH4=; b=GlYc5GfoVSQk0wf6QgZKieVVMxflLc0cnmAJKWUogn7BXWBpRXRr2tUJ8eSo91rd4L PewGif/eUx/+TKgKhVbXPP/e54xy704L2SFPqRFCMI4dIrS36n2D7N0CoOU4cNQmlxtt KWgepqvIDf34uUX/gGc+pndaHvVxo1mdPlHXFHJjbsIXh4jQ+AEb8UjO/NNhdlYpREqv bUl6/9/q6rfcuoAl3z6mEvFWLCF25YjOQgtVm4lMM1XPvljPUlDItEpywg7IBtKZfy4y O2lvm3+WL8+xCNw3I4G3Wo3vnfEnamLiAPUrpmXOAb0lc3Xtm4q0AKOnQzROrdtzo3Xj NPJg== MIME-Version: 1.0 X-Received: by 10.68.211.103 with SMTP id nb7mr23040940pbc.140.1361226190814; Mon, 18 Feb 2013 14:23:10 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 18 Feb 2013 14:23:10 -0800 (PST) In-Reply-To: References: <510C391B.7000604@computer.org> <4435713A-CD94-44B9-8AFD-4BFC1E3E06E1@jiaziyi.com> Date: Mon, 18 Feb 2013 23:23:10 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Micro-history about reactive protocol evolution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 22:23:12 -0000 Don't ignore the history sequence; Discuss reactive status of starting renew WG draft on 19 Oct 2012: http://www.ietf.org/mail-archive/web/manet/current/msg13801.html http://www.ietf.org/mail-archive/web/manet/current/msg13805.html Reply to old comment because it was parked and no WG replied; http://www.ietf.org/mail-archive/web/manet/current/msg13811.html Chairs request input; http://www.ietf.org/mail-archive/web/manet/current/msg13872.html AB From imene.gam@gmail.com Tue Feb 19 07:41:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECE621F8E01; Tue, 19 Feb 2013 07:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIJtOuisYc0w; Tue, 19 Feb 2013 07:41:23 -0800 (PST) Received: from mail-bk0-f68.google.com (mail-bk0-f68.google.com [209.85.214.68]) by ietfa.amsl.com (Postfix) with ESMTP id B658421F8E00; Tue, 19 Feb 2013 07:41:22 -0800 (PST) Received: by mail-bk0-f68.google.com with SMTP id q16so1188376bkw.3 for ; Tue, 19 Feb 2013 07:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=r390mBrbitjROZ1M56v2a63RHpdMWJewfXHTxw0OYcQ=; b=gWfqyPOuhqIrTwCkkx3VGk0hgW2AB1a1UKabjn9LK1J5Z6sidbqtAgZA59vBdDPTO+ DhbT/7hwUXBxaaNDfA+17UxZYeSww2dU6dJv71SqoEFUUpDGYex0PSrTaJLRdFdcmdrT MrC3yXlvNw8SMSmbdvo6xAhKTuBRGNBkKbSLPu1KucRrj/G9KrjThEewXwFv+58TSgSF p1xPjS52CiN2W3GMGF6IFgL3bMZxJz2pcsYe2YYYrlY86l8rRKG6lD6DfSrYYDRsVuU4 EbMZ94UGrrzhKWgtTI32lHg+xWUo5bYkqPtMGlR9jZ/WvE7kdZE5gs44L2mf8o9bb5oC 4y/A== MIME-Version: 1.0 X-Received: by 10.205.134.3 with SMTP id ia3mr1067750bkc.92.1361288481252; Tue, 19 Feb 2013 07:41:21 -0800 (PST) Received: by 10.204.157.129 with HTTP; Tue, 19 Feb 2013 07:41:21 -0800 (PST) Date: Tue, 19 Feb 2013 16:41:21 +0100 Message-ID: From: imene gam To: manet-request@ietf.org, manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] help X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 15:46:28 -0000 Hi all, > I am looking for an implementation of watchdog mechanism for data packets. I am looking for ns2-35 simulation. Does anyone have any suggestion? I am using AODV. I want to implement watchdog on data packets (not on AODV control messages). Thanks. > > Imene > 2013/2/19, manet-request@ietf.org : > Welcome to the manet@ietf.org mailing list! Welcome to the manet > mailing list. > > The MANET WG charter can be found at > http://www.ietf.org/html.charters/manet-charter.html. > > Please use the list responsibly and keep postings focused on WG > topics. > > Please refrain from sending CFP or asking simulator specific > questions. Instead please email the appropriate mailing list directly, > see URLs below. > > If you have a question about material appropriateness, please email > the chairs directly before posting. > > If you post inappropriate material, you will be warned. For repeat > offenders, your posting rights will be moderated. > > For call for papers/journals/conferences/workshops/grants/etc, I > suggest you subscribe or post to the TCCC list at > http://www.comsoc.org/~tccc/. > > Please take a note of instructions providing for subscribing and > unsubscribing. > > NOTE: This list has a members only posting policy to limit spam, etc > so please try to post from the original subscribed e-mail account. > > To post to this list, send your email to: > > manet@ietf.org > > General information about the mailing list is at: > > https://www.ietf.org/mailman/listinfo/manet > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > https://www.ietf.org/mailman/options/manet/imene.gam%40gmail.com > > You can also make such adjustments via email by sending a message to: > > manet-request@ietf.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > 01091990 > > Normally, Mailman will remind you of your ietf.org mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. > From abdussalambaryun@gmail.com Wed Feb 20 03:04:02 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C10621F8754 for ; Wed, 20 Feb 2013 03:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4LnjeQ0Gbzv for ; Wed, 20 Feb 2013 03:04:01 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBF821F86D5 for ; Wed, 20 Feb 2013 03:03:59 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id bj3so4012889pad.34 for ; Wed, 20 Feb 2013 03:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=2wn6j+9qpj22ssS52BXwELT9C5rcsaE2LrzqR5I4KKM=; b=MKfZBm8Cs+jE/FWeetKlQlftLiiY6ke6xlpS1AoD8WiGZzamQ3itQjFjo6CnlgkPcK 8WVJYa1WcxXHQfBOxmt6nEi/WPuPon1yJjCR1XA6tn18trEatcwZyjOhuQikmDg+9kJ4 KoRNhAEzdIOHDdBoRnS+AJGGLkLiw2jaO4qg9ofJ6tzvwQcz9l0p5Ga/aWjOZblCtdSs 71AlpQ/3f1MItlc9Ctwh9whHKO0EWEQZMtxvKKT/eW0yjd85tr8lhjrBcFWSAHyuelse I0oUcQv3eifj3dFXFNU86qhAcEbnnJm8UWvrTZKJznB+yRKI4TRxA9KHSSezPJ0ngSnK +REw== MIME-Version: 1.0 X-Received: by 10.68.245.229 with SMTP id xr5mr47762268pbc.163.1361358238968; Wed, 20 Feb 2013 03:03:58 -0800 (PST) Received: by 10.68.33.132 with HTTP; Wed, 20 Feb 2013 03:03:58 -0800 (PST) Date: Wed, 20 Feb 2013 12:03:58 +0100 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 11:04:02 -0000 Hi Folks, I am not sure why we will make effort of AODVv2 compatible with LOADng, I am trying to find a good reason mentioned in the WG. I seen the intention by some participants, but not sure was it intention to merge DYMO+LOADng without compatibility (with either DYMO or LOADng) or with percentage of compatibility. Do you think it is good way to make the reactive protocol and then try to make it compatible? Please advise, I will have to agree with the below proposal, that if the WG is agreeing to make compatible with LOADng, then why not go for 100% compatibility, just change the name title. AB Sub:Re: [manet] Reactive protocol decision process, for the record thoughts On 2/16/13, Ulrich Herberg wrote: > Justin, > > I very much agree with you, Justin. One point I would like to add is > that the WG will now spend a lot of time making the new AODVv2 > compatible with LOADng (which is claimed in the current DYMO draft); > that is, in my opinion, a wasted effort since the LOADng draft is per > definition 100% compatible with LOADng (had that been the starting > point). > Ignoring a document that has multiple interoperable implementations, > deployments, MIB document, as well a support from at least a dozen > MANET participants (not only LOADng authors) without giving rational > was a disappointment for me. > > Best regards > Ulrich > From jvasseur@cisco.com Wed Feb 20 07:26:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F273421F87E4 for ; Wed, 20 Feb 2013 07:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ7IuM8jPhrg for ; Wed, 20 Feb 2013 07:26:42 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C2BB821F86D0 for ; Wed, 20 Feb 2013 07:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6364; q=dns/txt; s=iport; t=1361374002; x=1362583602; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=K5lmxROrcIHL656hlAhUojCKXGleh6owb/HN1lthQLA=; b=HcL4cAU5pz5WZxaYpRLSQiCaYoKTuiGgUgU6i14vj0sShhbxp/EkCTFX LMGeVkC/hg66aGfjvsa1ku38okWN5aZ7j88trC/0ZjjJZ8Tub0DMi/K9+ rHeR7phcZr/pWYn2Pbk8sV6TgC4sD2ttyeknwHMjVAa1hv1LSQtoqRChz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAM/qJFGtJV2b/2dsb2JhbABFwFeBABZzgiABAQQBAQFrCxACAQgiHQcnCxQRAgQOBQgMh34MwDAEjl0xB4JfYQOnB4MHgic X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; d="scan'208,217";a="179201463" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 20 Feb 2013 15:26:33 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1KFQX7o028606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 15:26:33 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 09:26:33 -0600 From: "JP Vasseur (jvasseur)" To: Abdussalam Baryun Thread-Topic: [manet] Why the WG Reactive Protocol to be Compatible with another? Thread-Index: AQHOD36pPPlc817GAEiJ+2e5cuLhAQ== Date: Wed, 20 Feb 2013 15:26:32 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.145.251] Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77232CA63Dxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:26:43 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77232CA63Dxmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi AB, This is critical topic and I cannot agree more with you; the objective is i= n my opinion to come up with the best protocol for the IETF. Let's be clear: the objective of the IETF is to produce qualitative protoco= ls for the best of the IETF community and industry, not to make X or Y happy. Every single good ideas borrowed from Load should in my opini= on be adopted by AODVv2, if there is a consensus. On the other hand, trying to design AODVv2 with the constraint of making it compat= ible with another protocol is a COMPLETE non sense. Thanks. JP. On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote: Hi Folks, I am not sure why we will make effort of AODVv2 compatible with LOADng, I am trying to find a good reason mentioned in the WG. I seen the intention by some participants, but not sure was it intention to merge DYMO+LOADng without compatibility (with either DYMO or LOADng) or with percentage of compatibility. Do you think it is good way to make the reactive protocol and then try to make it compatible? Please advise, I will have to agree with the below proposal, that if the WG is agreeing to make compatible with LOADng, then why not go for 100% compatibility, just change the name title. AB Sub:Re: [manet] Reactive protocol decision process, for the record thoughts On 2/16/13, Ulrich Herberg = > wrote: Justin, I very much agree with you, Justin. One point I would like to add is that the WG will now spend a lot of time making the new AODVv2 compatible with LOADng (which is claimed in the current DYMO draft); that is, in my opinion, a wasted effort since the LOADng draft is per definition 100% compatible with LOADng (had that been the starting point). Ignoring a document that has multiple interoperable implementations, deployments, MIB document, as well a support from at least a dozen MANET participants (not only LOADng authors) without giving rational was a disappointment for me. Best regards Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_03B78081B371D44390ED6E7BADBB4A77232CA63Dxmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi AB,

This is critical topic and I cannot agree more with you; the objective= is in my opinion to come up with the best protocol for the IETF.
Let's be clear: the objective of the IETF is to produce qualitative pr= otocols for the best of the IETF community and industry, not to make
X or Y happy. Every= single good ideas borrowed from Load should in my opinion be adopted by AO= DVv2, if there is a consensus. On the
other hand, trying = to design AODVv2 with the constraint of making it compatible with another p= rotocol is a COMPLETE non sense.

Thanks.

JP.

On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote:

Hi Folks,

I am not sure why we will make effort of AODVv2 compatible with
LOADng, I am trying to find a good reason mentioned in the WG. I seen
the intention by some participants, but not sure was it intention to
merge DYMO+LOADng without compatibility (with either DYMO or LOADng) or with percentage of compatibility. Do you think it is good way to
make the reactive protocol and then try to make it compatible?  Please=
advise,

I will have to agree with the below proposal, that if the WG is
agreeing to make compatible with LOADng, then why not go for 100%
compatibility, just change the name title.

AB

Sub:Re: [manet] Reactive protocol decision process, for the record thoughts=
On 2/16/13, Ulrich Herberg <ulric= h@herberg.name> wrote:
Justin,

I very much agree with you, Justin. One point I w= ould like to add is
that the WG will now spend a lot of time making t= he new AODVv2
compatible with LOADng (which is claimed in the c= urrent DYMO draft);
that is, in my opinion, a wasted effort since the= LOADng draft is per
definition 100% compatible with LOADng (had that = been the starting
point).
Ignoring a document that has multiple interoperab= le implementations,
deployments, MIB document, as well a support from= at least a dozen
MANET participants (not only LOADng authors) with= out giving rational
was a disappointment for me.

Best regards
Ulrich

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

--_000_03B78081B371D44390ED6E7BADBB4A77232CA63Dxmbrcdx02ciscoc_-- From hrogge@googlemail.com Wed Feb 20 07:53:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEF521F85C0 for ; Wed, 20 Feb 2013 07:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuu0tFmh66oA for ; Wed, 20 Feb 2013 07:53:29 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 082C421F85BD for ; Wed, 20 Feb 2013 07:53:28 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id go11so5965342lbb.8 for ; Wed, 20 Feb 2013 07:53:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=aWAjmbymzeytQFMs2DJvOsq9eluj6euWz9Jc4NGONGE=; b=qrzLXz/41IwbcJspVilrRqrV0T161peLHpWxEl6ZegyKM/LHVWNVfQF7anXsKC6CNW hU3PqYq77t5u/hnWqktNS9sGscfhRTWN+uBq4PVgTvlCf7Y91BH+2Tff9IrN/Fx4cBbh 2fqQylx4UmcYXiJI+oITJT1xSNvueosSCIeOMb1jznqR5G/8sVW6hBH4eM6MoHpovkLr uDmqWhMz0rV6tof841sCfwPpDpr+GN3uH0nttCHOEE2zA4CAK3pLdAyigMFIyhJU/Wwf aclulUpFTb3VddJmRiQiFF3SFEURV5YONxi4oZk37j5tgF6NFMJctoTrgyWPPvdDDrBP jRVQ== X-Received: by 10.152.111.5 with SMTP id ie5mr18199401lab.31.1361375607827; Wed, 20 Feb 2013 07:53:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Wed, 20 Feb 2013 07:53:07 -0800 (PST) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Wed, 20 Feb 2013 16:53:07 +0100 Message-ID: To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:53:30 -0000 One great idea of LOADng was to have a compact core document which describes the the basic protocol (fully functional on its own) and put additional features into companion documents. This would also give people a way to describe which "optional" features a software implementation supports. "We implemented the core plus the RFC xyz and abc." Documents with lots of "optional features" in the core quickly become non-interoperable with each other because different people implement different subsets of the options and all are just "standard compliant". Henning Rogge On Wed, Feb 20, 2013 at 4:26 PM, JP Vasseur (jvasseur) wrote: > Hi AB, > > This is critical topic and I cannot agree more with you; the objective is in > my opinion to come up with the best protocol for the IETF. > Let's be clear: the objective of the IETF is to produce qualitative > protocols for the best of the IETF community and industry, not to make > X or Y happy. Every single good ideas borrowed from Load should in my > opinion be adopted by AODVv2, if there is a consensus. On the > other hand, trying to design AODVv2 with the constraint of making it > compatible with another protocol is a COMPLETE non sense. > > Thanks. > > JP. > > On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote: > > Hi Folks, > > I am not sure why we will make effort of AODVv2 compatible with > LOADng, I am trying to find a good reason mentioned in the WG. I seen > the intention by some participants, but not sure was it intention to > merge DYMO+LOADng without compatibility (with either DYMO or LOADng) > or with percentage of compatibility. Do you think it is good way to > make the reactive protocol and then try to make it compatible? Please > advise, > > I will have to agree with the below proposal, that if the WG is > agreeing to make compatible with LOADng, then why not go for 100% > compatibility, just change the name title. > > AB > > Sub:Re: [manet] Reactive protocol decision process, for the record thoughts > On 2/16/13, Ulrich Herberg wrote: > > Justin, > > > I very much agree with you, Justin. One point I would like to add is > > that the WG will now spend a lot of time making the new AODVv2 > > compatible with LOADng (which is claimed in the current DYMO draft); > > that is, in my opinion, a wasted effort since the LOADng draft is per > > definition 100% compatible with LOADng (had that been the starting > > point). > > Ignoring a document that has multiple interoperable implementations, > > deployments, MIB document, as well a support from at least a dozen > > MANET participants (not only LOADng authors) without giving rational > > was a disappointment for me. > > > Best regards > > Ulrich > > > _______________________________________________ > 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 > -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From charliep@computer.org Wed Feb 20 08:28:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2759321F86BA for ; Wed, 20 Feb 2013 08:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgPnG+a9vq5Q for ; Wed, 20 Feb 2013 08:28:28 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5778B21F86AB for ; Wed, 20 Feb 2013 08:28:28 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.161]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1U8CWw-0002B1-7Z; Wed, 20 Feb 2013 11:28:26 -0500 Message-ID: <5124F99F.2080107@computer.org> Date: Wed, 20 Feb 2013 08:28:15 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Henning Rogge References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86436323f195b5dee14887c8cc6b610937350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:28:29 -0000 Hello Henning, I don't think it makes sense to spread optional features into new documents just because they're optional. If there is any ambiguity about which are the "core features", then that is a defect of the specification, not a result of co-location in a document together. Otherwise, even a simple flag might need a new document. Anyway, if you find that some parts of the AODVv2 document do not clearly delineate core versus optional features, please let us know so we can fix it to be more accurate. Regards, Charlie P. On 2/20/2013 7:53 AM, Henning Rogge wrote: > One great idea of LOADng was to have a compact core document which > describes the the basic protocol (fully functional on its own) and put > additional features into companion documents. > > This would also give people a way to describe which "optional" > features a software implementation supports. > > "We implemented the core plus the RFC xyz and abc." > > Documents with lots of "optional features" in the core quickly become > non-interoperable with each other because different people implement > different subsets of the options and all are just "standard > compliant". > > Henning Rogge > > On Wed, Feb 20, 2013 at 4:26 PM, JP Vasseur (jvasseur) > wrote: >> Hi AB, >> >> This is critical topic and I cannot agree more with you; the objective is in >> my opinion to come up with the best protocol for the IETF. >> Let's be clear: the objective of the IETF is to produce qualitative >> protocols for the best of the IETF community and industry, not to make >> X or Y happy. Every single good ideas borrowed from Load should in my >> opinion be adopted by AODVv2, if there is a consensus. On the >> other hand, trying to design AODVv2 with the constraint of making it >> compatible with another protocol is a COMPLETE non sense. >> >> Thanks. >> >> JP. >> >> On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote: >> >> Hi Folks, >> >> I am not sure why we will make effort of AODVv2 compatible with >> LOADng, I am trying to find a good reason mentioned in the WG. I seen >> the intention by some participants, but not sure was it intention to >> merge DYMO+LOADng without compatibility (with either DYMO or LOADng) >> or with percentage of compatibility. Do you think it is good way to >> make the reactive protocol and then try to make it compatible? Please >> advise, >> >> I will have to agree with the below proposal, that if the WG is >> agreeing to make compatible with LOADng, then why not go for 100% >> compatibility, just change the name title. >> >> AB >> >> Sub:Re: [manet] Reactive protocol decision process, for the record thoughts >> On 2/16/13, Ulrich Herberg wrote: >> >> Justin, >> >> >> I very much agree with you, Justin. One point I would like to add is >> >> that the WG will now spend a lot of time making the new AODVv2 >> >> compatible with LOADng (which is claimed in the current DYMO draft); >> >> that is, in my opinion, a wasted effort since the LOADng draft is per >> >> definition 100% compatible with LOADng (had that been the starting >> >> point). >> >> Ignoring a document that has multiple interoperable implementations, >> >> deployments, MIB document, as well a support from at least a dozen >> >> MANET participants (not only LOADng authors) without giving rational >> >> was a disappointment for me. >> >> >> Best regards >> >> Ulrich >> >> >> _______________________________________________ >> 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 >> > > -- Regards, Charlie P. From abdussalambaryun@gmail.com Wed Feb 20 08:49:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADA221F87CC for ; Wed, 20 Feb 2013 08:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjHp4qv5eQFI for ; Wed, 20 Feb 2013 08:49:05 -0800 (PST) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB9921F87B1 for ; Wed, 20 Feb 2013 08:49:05 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id ro8so2971311pbb.18 for ; Wed, 20 Feb 2013 08:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0/9nWqzSIU67lBNrgywM4JIczp6unxjuf+GL93ze80k=; b=O+ePgwhMLkXhUYOpu1QdhdqgRmZquRozbTGqpYp3Ua9g4hTSl0NDL/d4a0BF4+14fm rSd+Scq7GauvCGq6GQFPsPcIscxotWMqQvAnDhtmuHJL5LcRBw9BRcakcXIl9c+1sWaP +BS186chQxWYTIMM7ZwuxQ18Fzh0RjXdx+jqKihHhU99HVyrMVlvfvDTi02Sezcy9hd9 UbB5E7R/Y4gawcfygv24K41AfOj2zRkxQTHnEZR2yKThR4hgR5fYOe0gW2Oe0fv8db78 p+UwE4E5F7u948briNTWkTDeDYnFelsE5/1mKxMpqWvpaKFv0N2hQX5584kRNd40yfNA OSTA== MIME-Version: 1.0 X-Received: by 10.66.185.33 with SMTP id ez1mr3346093pac.93.1361378945351; Wed, 20 Feb 2013 08:49:05 -0800 (PST) Received: by 10.68.33.132 with HTTP; Wed, 20 Feb 2013 08:49:05 -0800 (PST) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> Date: Wed, 20 Feb 2013 17:49:05 +0100 Message-ID: From: Abdussalam Baryun To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:49:06 -0000 Hi JP, Yes that was my first discussion approach (the best technical features to be adopted in the WG protocol), but seen some inputs that our reactive protocol to be compatible to another, and I thought why the other don't be compatible to this which I needed an answer. I agree that we will waste time if we choose to make our work compatible to other reactive protocol or as you mention it will be non sense. In addition, it needs to use RFC5444 (was discussed) and also to be compatible to NHDP, AB On 2/20/13, JP Vasseur (jvasseur) wrote: > Hi AB, > > This is critical topic and I cannot agree more with you; the objective is in > my opinion to come up with the best protocol for the IETF. > Let's be clear: the objective of the IETF is to produce qualitative > protocols for the best of the IETF community and industry, not to make > X or Y happy. Every single good ideas borrowed from Load should in my > opinion be adopted by AODVv2, if there is a consensus. On the > other hand, trying to design AODVv2 with the constraint of making it > compatible with another protocol is a COMPLETE non sense. > > Thanks. > > JP. > > On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote: > > Hi Folks, > > I am not sure why we will make effort of AODVv2 compatible with > LOADng, I am trying to find a good reason mentioned in the WG. I seen > the intention by some participants, but not sure was it intention to > merge DYMO+LOADng without compatibility (with either DYMO or LOADng) > or with percentage of compatibility. Do you think it is good way to > make the reactive protocol and then try to make it compatible? Please > advise, > > I will have to agree with the below proposal, that if the WG is > agreeing to make compatible with LOADng, then why not go for 100% > compatibility, just change the name title. > > AB > > Sub:Re: [manet] Reactive protocol decision process, for the record thoughts > On 2/16/13, Ulrich Herberg > > wrote: > Justin, > > I very much agree with you, Justin. One point I would like to add is > that the WG will now spend a lot of time making the new AODVv2 > compatible with LOADng (which is claimed in the current DYMO draft); > that is, in my opinion, a wasted effort since the LOADng draft is per > definition 100% compatible with LOADng (had that been the starting > point). > Ignoring a document that has multiple interoperable implementations, > deployments, MIB document, as well a support from at least a dozen > MANET participants (not only LOADng authors) without giving rational > was a disappointment for me. > > Best regards > Ulrich > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > From abdussalambaryun@gmail.com Wed Feb 20 08:55:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C12321F8816 for ; Wed, 20 Feb 2013 08:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzK3x2SyfMtr for ; Wed, 20 Feb 2013 08:55:06 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6B66721F87C4 for ; Wed, 20 Feb 2013 08:55:06 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id bg4so4133414pad.40 for ; Wed, 20 Feb 2013 08:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y7XvHgB9/NMK2xJ/S3v7Z9a1UhU+7ExmK0cmUAh/yOM=; b=qwrpV3YIqbj+cQKudJfkP/8B/jZDdlNlQlB/dOUde7AcfNxWuAAIDpJSK7XRXUVUy5 5Aai+0AhkQHUYnm50hGySJfNs3pl6WrMLMYUxgDXc1SyDjkImxyuqvc5gaMm2Eg6sI2w 6QNQ4OuxMDqjdJmDPIb8HFx09Z1xmBkgRY0ohbc02Z/QzV29oVYJF3dNh9wfm5Svu3KC 5QLqUTsLX9zgWrLOTKBCSnNAkeY9SF8Liu+Fn8kOe+eWJYm5WZmeFQBq0MaFJQGlSD/N 59QZV1V7zOR9Q7cQZKBCVWwOwHqawPl51inS2Xjzi5XpAW4QDRpIKJCvy8qcOMHw5Mij fP0w== MIME-Version: 1.0 X-Received: by 10.68.217.2 with SMTP id ou2mr50110524pbc.6.1361379306156; Wed, 20 Feb 2013 08:55:06 -0800 (PST) Received: by 10.68.33.132 with HTTP; Wed, 20 Feb 2013 08:55:06 -0800 (PST) In-Reply-To: <5124F99F.2080107@computer.org> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> <5124F99F.2080107@computer.org> Date: Wed, 20 Feb 2013 17:55:06 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:55:07 -0000 Hi Charlie, I may undersatnd from Henning input that it is important to read the core function in a light specification and/or if we get many optional feature within a specification, it is recommended to have other documents, as I understand you done for iRREP-draft, AB On 2/20/13, Charles E. Perkins wrote: > Hello Henning, > > I don't think it makes sense to spread optional features into new > documents just because they're optional. If there is any ambiguity > about which are the "core features", then that is a defect of the > specification, not a result of co-location in a document together. > > Otherwise, even a simple flag might need a new document. > > Anyway, if you find that some parts of the AODVv2 document do > not clearly delineate core versus optional features, please let us > know so we can fix it to be more accurate. > > Regards, > Charlie P. > > > On 2/20/2013 7:53 AM, Henning Rogge wrote: >> One great idea of LOADng was to have a compact core document which >> describes the the basic protocol (fully functional on its own) and put >> additional features into companion documents. >> >> This would also give people a way to describe which "optional" >> features a software implementation supports. >> >> "We implemented the core plus the RFC xyz and abc." >> >> Documents with lots of "optional features" in the core quickly become >> non-interoperable with each other because different people implement >> different subsets of the options and all are just "standard >> compliant". >> >> Henning Rogge >> >> On Wed, Feb 20, 2013 at 4:26 PM, JP Vasseur (jvasseur) >> wrote: >>> Hi AB, >>> >>> This is critical topic and I cannot agree more with you; the objective is >>> in >>> my opinion to come up with the best protocol for the IETF. >>> Let's be clear: the objective of the IETF is to produce qualitative >>> protocols for the best of the IETF community and industry, not to make >>> X or Y happy. Every single good ideas borrowed from Load should in my >>> opinion be adopted by AODVv2, if there is a consensus. On the >>> other hand, trying to design AODVv2 with the constraint of making it >>> compatible with another protocol is a COMPLETE non sense. >>> >>> Thanks. >>> >>> JP. >>> >>> On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote: >>> >>> Hi Folks, >>> >>> I am not sure why we will make effort of AODVv2 compatible with >>> LOADng, I am trying to find a good reason mentioned in the WG. I seen >>> the intention by some participants, but not sure was it intention to >>> merge DYMO+LOADng without compatibility (with either DYMO or LOADng) >>> or with percentage of compatibility. Do you think it is good way to >>> make the reactive protocol and then try to make it compatible? Please >>> advise, >>> >>> I will have to agree with the below proposal, that if the WG is >>> agreeing to make compatible with LOADng, then why not go for 100% >>> compatibility, just change the name title. >>> >>> AB >>> >>> Sub:Re: [manet] Reactive protocol decision process, for the record >>> thoughts >>> On 2/16/13, Ulrich Herberg wrote: >>> >>> Justin, >>> >>> >>> I very much agree with you, Justin. One point I would like to add is >>> >>> that the WG will now spend a lot of time making the new AODVv2 >>> >>> compatible with LOADng (which is claimed in the current DYMO draft); >>> >>> that is, in my opinion, a wasted effort since the LOADng draft is per >>> >>> definition 100% compatible with LOADng (had that been the starting >>> >>> point). >>> >>> Ignoring a document that has multiple interoperable implementations, >>> >>> deployments, MIB document, as well a support from at least a dozen >>> >>> MANET participants (not only LOADng authors) without giving rational >>> >>> was a disappointment for me. >>> >>> >>> Best regards >>> >>> Ulrich >>> >>> >>> _______________________________________________ >>> 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 >>> >> >> > > > -- > Regards, > Charlie P. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From yi.jiazi@gmail.com Wed Feb 20 09:22:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEC621F8936 for ; Wed, 20 Feb 2013 09:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhMFiQVa7rka for ; Wed, 20 Feb 2013 09:22:50 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 96E1E21F8821 for ; Wed, 20 Feb 2013 09:22:50 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id fg15so6496751wgb.1 for ; Wed, 20 Feb 2013 09:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=pZmVPG1PzZitn0yUmPalk4cWKsnbUXxpBvPOlxJTgbQ=; b=nBkpzHCG7x9iZJ2zMRCprtzFcmXW0g9xe/jfWk3MIVQ/q6fsXdy6ieNr1qagv7dYKj J2kx30OMrrq//zEcK09+EYlVLn26x3GF0l3N4gRljUvHURdxYQKmFj+BWXq3U6GK/lwq BKlOLv80qmn5Wfdn8Mm65F/RJH8ht0S65LnNcw3cCK2BjS+qJtpGuLpC+98zNDthQcM8 mBcVutUL9fOiIS4b4KfyjXXONs1cMw5usv9uD1xIKCYYRab8Vf+86Xgz0lCTt6js3382 7HdT5F7WZ/3HmVoFPOxsMdEldgwZjvjOmvs4sxudAAkyBaf3e1JQaT1BVhM1QQ7Bf1bm hmXw== X-Received: by 10.194.7.196 with SMTP id l4mr4269625wja.28.1361380969152; Wed, 20 Feb 2013 09:22:49 -0800 (PST) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id j4sm30509458wiz.10.2013.02.20.09.22.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 09:22:48 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> Date: Wed, 20 Feb 2013 18:22:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> To: JP Vasseur (jvasseur) X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:22:51 -0000 Hi AB, JP: I also have doubts why the editor of DYMO declares that it will be = compatible with LOADng, and how it can be achieved.=20 Although those two protocols share the general idea, the packet format = and message processing details are very different. As one who = participated in all LOADng interop tests and know dymo draft relatively = well, I can say that a lot of effort are needed to make DYMO and LOADng = compatible, not to mention the interop tests needed to verify the = compatibility (at this point, I have no idea if there is DYMO = implementation, so I'm not even sure if such test is possible).=20 btw,=20 > the objective of the IETF is to produce qualitative protocols for the = best of the IETF community and industry, not to make X or Y happy I can't agree more.=20 best Jiazi On Feb 20, 2013, at 4:26 PM, JP Vasseur (jvasseur) = wrote: > Hi AB, >=20 > This is critical topic and I cannot agree more with you; the objective = is in my opinion to come up with the best protocol for the IETF. > Let's be clear: the objective of the IETF is to produce qualitative = protocols for the best of the IETF community and industry, not to make > X or Y happy. Every single good ideas borrowed from Load should in my = opinion be adopted by AODVv2, if there is a consensus. On the > other hand, trying to design AODVv2 with the constraint of making it = compatible with another protocol is a COMPLETE non sense. >=20 > Thanks. >=20 > JP. >=20 > On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote: >=20 >> Hi Folks, >>=20 >> I am not sure why we will make effort of AODVv2 compatible with >> LOADng, I am trying to find a good reason mentioned in the WG. I seen >> the intention by some participants, but not sure was it intention to >> merge DYMO+LOADng without compatibility (with either DYMO or LOADng) >> or with percentage of compatibility. Do you think it is good way to >> make the reactive protocol and then try to make it compatible? = Please >> advise, >>=20 >> I will have to agree with the below proposal, that if the WG is >> agreeing to make compatible with LOADng, then why not go for 100% >> compatibility, just change the name title. >>=20 >> AB >>=20 >> Sub:Re: [manet] Reactive protocol decision process, for the record = thoughts >> On 2/16/13, Ulrich Herberg wrote: >>> Justin, >>>=20 >>> I very much agree with you, Justin. One point I would like to add is >>> that the WG will now spend a lot of time making the new AODVv2 >>> compatible with LOADng (which is claimed in the current DYMO draft); >>> that is, in my opinion, a wasted effort since the LOADng draft is = per >>> definition 100% compatible with LOADng (had that been the starting >>> point). >>> Ignoring a document that has multiple interoperable implementations, >>> deployments, MIB document, as well a support from at least a dozen >>> MANET participants (not only LOADng authors) without giving rational >>> was a disappointment for me. >>>=20 >>> Best regards >>> Ulrich >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Wed Feb 20 09:40:44 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E703D21F8931 for ; Wed, 20 Feb 2013 09:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m12Tdr1xGQro for ; Wed, 20 Feb 2013 09:40:43 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id C34EC21F8925 for ; Wed, 20 Feb 2013 09:40:24 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id go11so6192890lbb.36 for ; Wed, 20 Feb 2013 09:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=6qjeUtsFQBG1j9U/9V/0+sTwfyoXnJE5S6wRCpPXJzU=; b=CsRg6lf3ejkSTsX0gKst/1N0HySXkr5/jNVBpU8cuJ9eCnOhHDE99FduUy1H0cg/ln FcS0N8jyIi4JzeqWAfGuC73b89Tb6Z+Uk8Z+eEq+xovPmmtBL3jfafW13WCxeia9a8PG 3BXX2ddPFrP78uFlx+Q5LS3osjLXk1kQCsGkkjjrr1cVGy+VEtgUx7R3dTtRog2NzJGh CbOOHpYZ1QQH85R3fkBVByOLz+pOoJTWCXTA3FBohbnPtdzjNW15umFPikWYbY3qbSbE qvE0TO9NYQg9lccagB+73gQ6nC2YCKTMQe5hCpYRAdlrdxlqiUIR/7COF6mhooRY9PPE ZXQg== X-Received: by 10.112.28.102 with SMTP id a6mr8868837lbh.109.1361382022990; Wed, 20 Feb 2013 09:40:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Wed, 20 Feb 2013 09:40:02 -0800 (PST) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> From: Henning Rogge Date: Wed, 20 Feb 2013 18:40:02 +0100 Message-ID: To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:40:47 -0000 On Wed, Feb 20, 2013 at 4:26 PM, JP Vasseur (jvasseur) wrote: > Let's be clear: the objective of the IETF is to produce qualitative > protocols for the best of the IETF community and industry, not to make > X or Y happy. We ALL agree on this... we just might disagree who is X and Y. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From charliep@computer.org Wed Feb 20 09:45:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FB321F87CC for ; Wed, 20 Feb 2013 09:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YErO9eYJtEkk for ; Wed, 20 Feb 2013 09:45:52 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4311521F869E for ; Wed, 20 Feb 2013 09:45:52 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.161]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1U8Djr-0004Xt-8f; Wed, 20 Feb 2013 12:45:51 -0500 Message-ID: <51250BC6.2050306@computer.org> Date: Wed, 20 Feb 2013 09:45:42 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: manet@ietf.org References: <066.51de40fe9c0e229a90ae823d91b65254@trac.tools.ietf.org> In-Reply-To: <066.51de40fe9c0e229a90ae823d91b65254@trac.tools.ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867ad0c034cd56c91f88dd85847efd84e7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet issue tracker Subject: Re: [manet] #15: Reactive Design Approach X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:45:53 -0000 Hello Abussalam, I also agree that the hybrid approach may offer many benefits. When we're done with the reactive approach, I hope we can get into developing a hybrid solution. As I understand it, this was among the initial motivations for RFC 5444 -- enabling a common message "platform" for ad hoc network nodes to interpret both reactive and proactive signaling. It seems to me that you are not specifically requesting any changes to the AODVv2 document for this purpose. If you do have changes in mind, please let me know which sections and if possible some suggested text for the changes. Regards, Charlie P. On 1/19/2013 4:11 PM, manet issue tracker wrote: > #15: Reactive Design Approach > > There is a problem that reactive work better in some application > scenarios and proactive work better in other application scenarios, > but both are important for MANETs in general. However, there are some > application scenarios where the hybrid routing is the best choice for > the MANET. Another problem is that generated routing information are > different in reactive and proactive, so it will be reasonable that > there may be different best formatting, which needs an answer/discuss. > > The design approach to start with the messaging format before the > completion of designing both proactive and reactive separate standards > can't be the right approach for designing general purpose protocols. That > may be a good approach for manet hybrid routing that includes both > reactive and proactive routing functions. However, there is no prove that > similar message formatting will give better performance for two separate > protocols for different scenarios. > > I suggest the WG reactive protocol modified without thinking of a hybrid > or proactive routing, but just the reactive. Also I suggest we don't think > about gateway issues as leave it in separate draft. > -- Regards, Charlie P. From charliep@computer.org Wed Feb 20 10:01:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AF721F871C for ; Wed, 20 Feb 2013 10:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOGh-rQp8O6S for ; Wed, 20 Feb 2013 10:01:49 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 99F9721F888A for ; Wed, 20 Feb 2013 10:01:48 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.161]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1U8DzF-000331-Ef; Wed, 20 Feb 2013 13:01:47 -0500 Message-ID: <51250F81.2060207@computer.org> Date: Wed, 20 Feb 2013 10:01:37 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jiazi Yi References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8629438a353081a8892b79e529814f2ba0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:01:49 -0000 Hello Jiazi, I do not agree that the protocols are all that different. I did not declare that AODVv2 will be compatible with LOADng. Instead, what I have said all along is that we should make the effort to achieve compatibility. This means to make the comparison and to resolve differences. I have agreed to make a comparison draft, and I have tried to enlist the aid of another LOADng author in the effort. Once the comparison is made, we can have a discussion about each point of difference, to decide upon the best resolution. I am pretty sure that, if we do this with honest effort, we will get a better result overall. Do you want to help? Regards, Charlie P. On 2/20/2013 9:22 AM, Jiazi Yi wrote: > Hi AB, JP: > > I also have doubts why the editor of DYMO declares that it will be compatible with LOADng, and how it can be achieved. > > Although those two protocols share the general idea, the packet format and message processing details are very different. As one who participated in all LOADng interop tests and know dymo draft relatively well, I can say that a lot of effort are needed to make DYMO and LOADng compatible, not to mention the interop tests needed to verify the compatibility (at this point, I have no idea if there is DYMO implementation, so I'm not even sure if such test is possible). > > btw, > >> the objective of the IETF is to produce qualitative protocols for the best of the IETF community and industry, not to make X or Y happy > > I can't agree more. > > best > > Jiazi > > On Feb 20, 2013, at 4:26 PM, JP Vasseur (jvasseur) wrote: > >> Hi AB, >> >> This is critical topic and I cannot agree more with you; the objective is in my opinion to come up with the best protocol for the IETF. >> Let's be clear: the objective of the IETF is to produce qualitative protocols for the best of the IETF community and industry, not to make >> X or Y happy. Every single good ideas borrowed from Load should in my opinion be adopted by AODVv2, if there is a consensus. On the >> other hand, trying to design AODVv2 with the constraint of making it compatible with another protocol is a COMPLETE non sense. >> >> Thanks. >> >> JP. >> >> On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote: >> >>> Hi Folks, >>> >>> I am not sure why we will make effort of AODVv2 compatible with >>> LOADng, I am trying to find a good reason mentioned in the WG. I seen >>> the intention by some participants, but not sure was it intention to >>> merge DYMO+LOADng without compatibility (with either DYMO or LOADng) >>> or with percentage of compatibility. Do you think it is good way to >>> make the reactive protocol and then try to make it compatible? Please >>> advise, >>> >>> I will have to agree with the below proposal, that if the WG is >>> agreeing to make compatible with LOADng, then why not go for 100% >>> compatibility, just change the name title. >>> >>> AB >>> >>> Sub:Re: [manet] Reactive protocol decision process, for the record thoughts >>> On 2/16/13, Ulrich Herberg wrote: >>>> Justin, >>>> >>>> I very much agree with you, Justin. One point I would like to add is >>>> that the WG will now spend a lot of time making the new AODVv2 >>>> compatible with LOADng (which is claimed in the current DYMO draft); >>>> that is, in my opinion, a wasted effort since the LOADng draft is per >>>> definition 100% compatible with LOADng (had that been the starting >>>> point). >>>> Ignoring a document that has multiple interoperable implementations, >>>> deployments, MIB document, as well a support from at least a dozen >>>> MANET participants (not only LOADng authors) without giving rational >>>> was a disappointment for me. >>>> >>>> Best regards >>>> Ulrich >>>> >>> _______________________________________________ >>> 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 > -- Regards, Charlie P. From abdussalambaryun@gmail.com Wed Feb 20 10:46:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B0821F8722 for ; Wed, 20 Feb 2013 10:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0u0jKb8cPf1 for ; Wed, 20 Feb 2013 10:46:48 -0800 (PST) Received: from mail-da0-f45.google.com (mail-da0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAA821F8716 for ; Wed, 20 Feb 2013 10:46:48 -0800 (PST) Received: by mail-da0-f45.google.com with SMTP id v40so170435dad.32 for ; Wed, 20 Feb 2013 10:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Jqbj2WsYeawQYwRjMFITmJnD+NqPNZkwfOUzqx4AA9w=; b=pHmDCsNmjOJaCrE0ekvk++9sjgMrVplX3UoW9tnCwK/keFWSsUx2mRZGp1FagKQ5QQ c2W8NmH0wycuY/GtSAmpgMK6TXtvB7uXCQtw+nZb95ArFbR06VKakqDdThVQ7ugKyea7 NYLtp5OFF+f1yULpNNAWxaAOqMQbw3CwTTAbuGj1qCy8rnZVZt8Fd51XhDFT857aIEmt hpX5Isi9PXCLgS3KjbUhc56aFpIVIYweiwGct5K4iZhFHE0tvXK2bc1p2VBMUkcFHTr4 m/PLCM8h1LB6XbmpTF0xLWU4Ay3g48NIXJSUX8B4hRQacB9ah6/Lfv0Ofrx5F8RyAzTc +X9w== MIME-Version: 1.0 X-Received: by 10.68.153.97 with SMTP id vf1mr50713152pbb.93.1361386008352; Wed, 20 Feb 2013 10:46:48 -0800 (PST) Received: by 10.68.33.132 with HTTP; Wed, 20 Feb 2013 10:46:48 -0800 (PST) In-Reply-To: <51250BC6.2050306@computer.org> References: <066.51de40fe9c0e229a90ae823d91b65254@trac.tools.ietf.org> <51250BC6.2050306@computer.org> Date: Wed, 20 Feb 2013 19:46:48 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org, manet issue tracker Subject: Re: [manet] #15: Reactive Design Approach X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:46:49 -0000 > It seems to me that you are not specifically requesting any changes to > the AODVv2 document for this purpose. If you do have changes in mind, > please let me know which sections and if possible some suggested text > for the changes. I have no change request as long as I already agreed with last DYMO. I think the track was about the WG approach to the new WG reactive document not about last dymo-draft content, as the approach of transfering DYMO contents/ideas to the new protocol. So we can say this design approach helps us know how to start make AODVv2-00. Please note that the new reactive protocol is not yet published, and some think that we may take similar as proactive approach or compatible with another reactive protocol, AB From charliep@computer.org Wed Feb 20 10:59:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A925421F8992 for ; Wed, 20 Feb 2013 10:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZ1Z0FgOZjxr for ; Wed, 20 Feb 2013 10:59:33 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3154421F8984 for ; Wed, 20 Feb 2013 10:59:33 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.161]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1U8Et9-0005w5-Sv; Wed, 20 Feb 2013 13:59:32 -0500 Message-ID: <51251D0E.1050202@computer.org> Date: Wed, 20 Feb 2013 10:59:26 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: manet@ietf.org References: <066.02811072057e3e608e2532e3a9c56d6d@trac.tools.ietf.org> In-Reply-To: <066.02811072057e3e608e2532e3a9c56d6d@trac.tools.ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8678fffd474cd4dd23f4e89b82cb6281e4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: manet issue tracker Subject: Re: [manet] #16: The Reactive Protocol Duplicate Suppression Table X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:59:33 -0000 Hello Abdussalam, There was a revision of AODVv2 that included RREPs in the duplicate suppression table. It did have the effect of making the description more difficult to understand without additional benefit in the typical case where RREPs are unicast. For multicast RREP, there would be quite a bit more benefit, but the use case for multicast RREP involves networks with unidirectional links, which have not seen much attention lately in the working group. Moreover, the duplicate suppression table itself would need to distinguish between RREQ and RREP messages if they were combined in the same table, so logically speaking the table could still be viewed as two separate tables. If there is interest, handling multicast RREPs in a similar table could be more explicitly specified in the document. Regards, Charlie P. On 1/19/2013 5:13 PM, manet issue tracker wrote: > #16: The Reactive Protocol Duplicate Suppression Table > > I agree with the proposed to add RREPs in table as RREQ for suppression as > below message, however, will need to discuss if there are side affects > > http://www.ietf.org/mail-archive/web/manet/current/msg14472.html > -- Regards, Charlie P. From trac+manet@trac.tools.ietf.org Wed Feb 20 11:11:17 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1275921F8759 for ; Wed, 20 Feb 2013 11:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsXV-D14w6T5 for ; Wed, 20 Feb 2013 11:11:16 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3C44621F871F for ; Wed, 20 Feb 2013 11:11:16 -0800 (PST) Received: from localhost ([127.0.0.1]:33955 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U8F4R-0000BO-0f; Wed, 20 Feb 2013 20:11:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: charliep@computer.org, abdussalambaryun@gmail.com X-Trac-Project: manet Date: Wed, 20 Feb 2013 19:11:11 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/17#comment:2 Message-ID: <081.203a92bb3f4f4d1dce29ad7af8d81cb5@trac.tools.ietf.org> References: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, abdussalambaryun@gmail.com, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: Re: [manet] #17: Proposed Reactive Protocols' Alternative Message Formats X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:11:17 -0000 #17: Proposed Reactive Protocols' Alternative Message Formats Changes (by charliep@computer.org): * owner: Abdussalam Baryun => charliep@computer.org * status: new => assigned Comment: The new TLVs suggested by Henning Rogge have been incorporated into the upcoming new revision for the AODVv2 specification. I think it will resolve this issue. The Address TLVs have the effect of disambiguating the roles of the addresses in the !AddrBlk; consequently the roles of the addresses do not require positional significance otherwise. After the publication of the new revision, it should be determined whether this issue can be closed. -- ----------------------------------------+---------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Type: enhancement | charliep@computer.org Priority: major | Status: assigned Component: dymo | Milestone: milestone1 Severity: Active WG Document | Version: Keywords: RFC5444, Address TLVs | Resolution: ----------------------------------------+---------------------------------- Ticket URL: manet From sratliff@cisco.com Wed Feb 20 12:52:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B3B21E803D for ; Wed, 20 Feb 2013 12:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lOuSzSHDDR4 for ; Wed, 20 Feb 2013 12:52:37 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F09BC21E8039 for ; Wed, 20 Feb 2013 12:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5008; q=dns/txt; s=iport; t=1361393557; x=1362603157; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XjkI+Auj4QCC3s9upHaUxpGeB/w2UAJFmOgYivD+Z40=; b=RV30J1Y3UQ0WEWf3OUFRFpoEesaqREYshEvg5iUePMulwuoPFTgcsDZY p0mUBoKvTiMWMvBFC56ZEKZEFyBeyzP1bQq6HlWmIPbPf0Uosoypn5Huj V1TSOsJqvijxhQXtRpuO6QPHv3LNGtLuouZPXCDUSikOYU08NBi1rq5AL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANI2JVGtJV2Y/2dsb2JhbABFwF+BAhZzgh8BAQEDAQEBATc0CwULAgEIDgoKFBAnCyUCBA4FCAyHeAYMwEoEjlsCMQeCX2EDpweDB4In X-IronPort-AV: E=Sophos;i="4.84,703,1355097600"; d="scan'208";a="179328631" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 20 Feb 2013 20:52:36 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1KKqa6Z012161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Feb 2013 20:52:36 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 14:52:35 -0600 From: "Stan Ratliff (sratliff)" To: Jiazi Yi Thread-Topic: [manet] Why the WG Reactive Protocol to be Compatible with another? Thread-Index: AQHOD475cnCSPRLIwUq4RrZ8Yc8u8ZiDneKA Date: Wed, 20 Feb 2013 20:52:35 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100315E3@xmb-aln-x03.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.124] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:52:38 -0000 Jiazi,=20 On Feb 20, 2013, at 12:22 PM, Jiazi Yi wrote: > Hi AB, JP: >=20 > I also have doubts why the editor of DYMO declares that it will be compat= ible with LOADng, and how it can be achieved.=20 It probably won't be achieved - especially if you and the other LOADng co-a= uthors decide not to help us, taking the position of standing back and lobb= ing emails like this one into the fray. If this is a desirable, then I woul= d say "suggest some alternatives, help us out". If not, then let us as a wo= rking group declare it a dead issue, and move on.=20 >=20 > Although those two protocols share the general idea, the packet format an= d message processing details are very different. As one who participated in= all LOADng interop tests and know dymo draft relatively well, I can say th= at a lot of effort are needed to make DYMO and LOADng compatible, not to me= ntion the interop tests needed to verify the compatibility (at this point, = I have no idea if there is DYMO implementation, so I'm not even sure if suc= h test is possible).=20 OK. Going on (yet another) "micro-cosmic trip through MANET reactive protoc= ol history", I'll note that AODV compatibility with LOADng was something th= at the co-chairs mandated from the combined author teams when we thought th= at merging the two documents was something that could actually be accomplis= hed. The rationale there was to not exclude existing LOADng implementations= from being able to say they were compliant with the RFC - something that *= no one* on the author teams (including yourself) complained about *at the t= ime*.=20 So to restate, the fundamentals of the issue have changed - the effort to m= erge the documents was a total, miserable failure. At this juncture it is f= air to ask if LOADng compatibility is even something that is desirable. The= general trend of comments I'm reading on the list indicates that it is not= . Are there other opinions?=20 Stan=20 >=20 > btw,=20 >=20 >> the objective of the IETF is to produce qualitative protocols for the be= st of the IETF community and industry, not to make X or Y happy >=20 >=20 > I can't agree more.=20 >=20 > best >=20 > Jiazi >=20 > On Feb 20, 2013, at 4:26 PM, JP Vasseur (jvasseur) w= rote: >=20 >> Hi AB, >>=20 >> This is critical topic and I cannot agree more with you; the objective i= s in my opinion to come up with the best protocol for the IETF. >> Let's be clear: the objective of the IETF is to produce qualitative prot= ocols for the best of the IETF community and industry, not to make >> X or Y happy. Every single good ideas borrowed from Load should in my op= inion be adopted by AODVv2, if there is a consensus. On the >> other hand, trying to design AODVv2 with the constraint of making it com= patible with another protocol is a COMPLETE non sense. >>=20 >> Thanks. >>=20 >> JP. >>=20 >> On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote: >>=20 >>> Hi Folks, >>>=20 >>> I am not sure why we will make effort of AODVv2 compatible with >>> LOADng, I am trying to find a good reason mentioned in the WG. I seen >>> the intention by some participants, but not sure was it intention to >>> merge DYMO+LOADng without compatibility (with either DYMO or LOADng) >>> or with percentage of compatibility. Do you think it is good way to >>> make the reactive protocol and then try to make it compatible? Please >>> advise, >>>=20 >>> I will have to agree with the below proposal, that if the WG is >>> agreeing to make compatible with LOADng, then why not go for 100% >>> compatibility, just change the name title. >>>=20 >>> AB >>>=20 >>> Sub:Re: [manet] Reactive protocol decision process, for the record thou= ghts >>> On 2/16/13, Ulrich Herberg wrote: >>>> Justin, >>>>=20 >>>> I very much agree with you, Justin. One point I would like to add is >>>> that the WG will now spend a lot of time making the new AODVv2 >>>> compatible with LOADng (which is claimed in the current DYMO draft); >>>> that is, in my opinion, a wasted effort since the LOADng draft is per >>>> definition 100% compatible with LOADng (had that been the starting >>>> point). >>>> Ignoring a document that has multiple interoperable implementations, >>>> deployments, MIB document, as well a support from at least a dozen >>>> MANET participants (not only LOADng authors) without giving rational >>>> was a disappointment for me. >>>>=20 >>>> Best regards >>>> Ulrich >>>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From yi.jiazi@gmail.com Wed Feb 20 14:03:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502C721F8721 for ; Wed, 20 Feb 2013 14:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.024 X-Spam-Level: * X-Spam-Status: No, score=1.024 tagged_above=-999 required=5 tests=[AWL=-2.461, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, J_CHICKENPOX_46=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM4y8H2BaRwF for ; Wed, 20 Feb 2013 14:03:24 -0800 (PST) Received: from mail-we0-x22f.google.com (we-in-x022f.1e100.net [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6F121F86E7 for ; Wed, 20 Feb 2013 14:03:18 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id x8so7092281wey.6 for ; Wed, 20 Feb 2013 14:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=K+HY6l5ONTDeF/LEwTYUFUv94q9zAjFIKk7jhVWrwEU=; b=R5CvNFlbey1mBMJ6RgXEc9RWVk78qgDUtscvzcuilxHbtyvfCGrUgBuLMoHTzZTcvH yaBxCFaXyD4B/WcJi2EjwOIpg5MF5Jr3DPcuRDGslY9uldgPF+N3BOWoORYlQxEXlvcT 1CxU8ZaaY1W3FImUTWawZ+SwFXAZvM7/uPPfPvxh9uyEcFvbnISk/XpjWwoNDwbc4Usm nz+aBj2UYPfQAsFag5nyRJ/OlNT7vYUQJ9MTlqrq8GL5yNXt+PHgvm0v4LOcmLxOWllP C1mH7TQbuoDYXZqri78hDGLA4KvcA1MKH45t2+mifXH3bsO6ILEBXkA5Y8MoWnpLv9qH O4JA== X-Received: by 10.180.74.131 with SMTP id t3mr37585206wiv.23.1361397797526; Wed, 20 Feb 2013 14:03:17 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id eo10sm36515242wib.9.2013.02.20.14.03.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 14:03:15 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C100315E3@xmb-aln-x03.cisco.com> Date: Wed, 20 Feb 2013 23:03:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100315E3@xmb-aln-x03.cisco.com> To: "Stan Ratliff (sratliff)" , "Charles E. Perkins" X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org List" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:03:25 -0000 Hi,=20 Please check inline (I'm just speaking on behalf of myself, not the = LOADng author team) : On Feb 20, 2013, at 9:52 PM, Stan Ratliff (sratliff) = wrote: > Jiazi,=20 >=20 > On Feb 20, 2013, at 12:22 PM, Jiazi Yi wrote: >=20 >> Hi AB, JP: >>=20 >> I also have doubts why the editor of DYMO declares that it will be = compatible with LOADng, and how it can be achieved.=20 >=20 > It probably won't be achieved - especially if you and the other LOADng = co-authors decide not to help us, taking the position of standing back = and lobbing emails like this one into the fray. If this is a desirable, = then I would say "suggest some alternatives, help us out". If not, then = let us as a working group declare it a dead issue, and move on.=20 In the last 2~years, the LOADng co-authors have spent huge amount of = effort in reactive protocols. For me personally, it's the core of my = research project, and I invested most of my time in it. Hopefully it = won't be regarded as "not willing to help".=20 >=20 >>=20 >> Although those two protocols share the general idea, the packet = format and message processing details are very different. As one who = participated in all LOADng interop tests and know dymo draft relatively = well, I can say that a lot of effort are needed to make DYMO and LOADng = compatible, not to mention the interop tests needed to verify the = compatibility (at this point, I have no idea if there is DYMO = implementation, so I'm not even sure if such test is possible).=20 >=20 > OK. Going on (yet another) "micro-cosmic trip through MANET reactive = protocol history", I'll note that AODV compatibility with LOADng was = something that the co-chairs mandated from the combined author teams = when we thought that merging the two documents was something that could = actually be accomplished. The rationale there was to not exclude = existing LOADng implementations from being able to say they were = compliant with the RFC - something that *no one* on the author teams = (including yourself) complained about *at the time*.=20 Since the Taipei IETF, the starting point agreed by the authors teams = was always LOADng, as indicated in Ulrich's mail to the chairs.=20 In that context, all the authors agree that companion documents can be = developed, so that the dymo functions can be supported to be compatible.=20= Thanks for adding the note.=20 The issue of starting point didn't come out until several months before = Atlanta IETF. If I knew that the document would be based on DYMO, it = would be a totally different issue.=20 >=20 > So to restate, the fundamentals of the issue have changed - the effort = to merge the documents was a total, miserable failure. At this juncture = it is fair to ask if LOADng compatibility is even something that is = desirable. The general trend of comments I'm reading on the list = indicates that it is not. Are there other opinions?=20 I agree that the fundamentals of the issue have changed, since the = starting point and the design principle (slim core + companion document) = were changed.=20 As far as I can see, LOADng has no intention to be changed to "get = closer to DYMO". Having DYMO be compatible with LOADng would need great = effort and add extra complexity to the protocol - starting from scratch = probably would be easier to make a clear specification and be compatible = with LOADng.=20 I have spent days and nights in the interop tests of LOADng. Producing = ONE clear specification with limited options, and making it able to = interoperable among independent implementations are already hard enough. = Having TWO specifications, and one of them is a super set with all those = additional options which are not specified clearly, would be a = nightmare. Awful among of iterations and tests would be required.=20 Therefore, personally, I would say LOADng compatibility is not = desirable.=20 best Jiazi >=20 > Stan=20 >=20 >=20 >>=20 >> btw,=20 >>=20 >>> the objective of the IETF is to produce qualitative protocols for = the best of the IETF community and industry, not to make X or Y happy >>=20 >>=20 >> I can't agree more.=20 >>=20 >> best >>=20 >> Jiazi >>=20 >> On Feb 20, 2013, at 4:26 PM, JP Vasseur (jvasseur) = wrote: >>=20 >>> Hi AB, >>>=20 >>> This is critical topic and I cannot agree more with you; the = objective is in my opinion to come up with the best protocol for the = IETF. >>> Let's be clear: the objective of the IETF is to produce qualitative = protocols for the best of the IETF community and industry, not to make >>> X or Y happy. Every single good ideas borrowed from Load should in = my opinion be adopted by AODVv2, if there is a consensus. On the >>> other hand, trying to design AODVv2 with the constraint of making it = compatible with another protocol is a COMPLETE non sense. >>>=20 >>> Thanks. >>>=20 >>> JP. >>>=20 >>> On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote: >>>=20 >>>> Hi Folks, >>>>=20 >>>> I am not sure why we will make effort of AODVv2 compatible with >>>> LOADng, I am trying to find a good reason mentioned in the WG. I = seen >>>> the intention by some participants, but not sure was it intention = to >>>> merge DYMO+LOADng without compatibility (with either DYMO or = LOADng) >>>> or with percentage of compatibility. Do you think it is good way to >>>> make the reactive protocol and then try to make it compatible? = Please >>>> advise, >>>>=20 >>>> I will have to agree with the below proposal, that if the WG is >>>> agreeing to make compatible with LOADng, then why not go for 100% >>>> compatibility, just change the name title. >>>>=20 >>>> AB >>>>=20 >>>> Sub:Re: [manet] Reactive protocol decision process, for the record = thoughts >>>> On 2/16/13, Ulrich Herberg wrote: >>>>> Justin, >>>>>=20 >>>>> I very much agree with you, Justin. One point I would like to add = is >>>>> that the WG will now spend a lot of time making the new AODVv2 >>>>> compatible with LOADng (which is claimed in the current DYMO = draft); >>>>> that is, in my opinion, a wasted effort since the LOADng draft is = per >>>>> definition 100% compatible with LOADng (had that been the starting >>>>> point). >>>>> Ignoring a document that has multiple interoperable = implementations, >>>>> deployments, MIB document, as well a support from at least a dozen >>>>> MANET participants (not only LOADng authors) without giving = rational >>>>> was a disappointment for me. >>>>>=20 >>>>> Best regards >>>>> Ulrich >>>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From abdussalambaryun@gmail.com Wed Feb 20 16:10:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C3521F8C99 for ; Wed, 20 Feb 2013 16:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vxGMVi6M5mU for ; Wed, 20 Feb 2013 16:10:27 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF2B21F843E for ; Wed, 20 Feb 2013 16:10:27 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id kp14so4346532pab.5 for ; Wed, 20 Feb 2013 16:10:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HUIwG7iL9gJJe7FugKxbV1lAX3noSjfzUpSgUhIEMAU=; b=m0QUrK10kHPkZr4i5Dyrn9P4Ny2wulp4YQHGWKSQKOqCqvHRc8ysLkat2SNKJ7vjA3 bNbFIpJ+ytaKSliQvdTyhphDDQW5XL0tjqCZPyHF8cFIjDfKZYHX5N2i1Ki6YvM2IfcY +1hJqxvaTnOL6Apqnjs/sSev7RdI7s+LrplM/zSI+Tp+RYWnDTNzGrQu76brdugWCIFL 7OdvsWdVawI4gvcOhRhMFha/0E4tAI6pQdpbFsoPOzR3D6E08Ju6yjmQXNTRL7UTeN/b +6MSdd8T/8nuEqv7rai2Gamgze8r4wPyGJIVJofElYbSHAbfLMStbsoVh3KZVYs4kGt9 x05g== MIME-Version: 1.0 X-Received: by 10.68.204.68 with SMTP id kw4mr51371597pbc.113.1361405427194; Wed, 20 Feb 2013 16:10:27 -0800 (PST) Received: by 10.68.33.132 with HTTP; Wed, 20 Feb 2013 16:10:27 -0800 (PST) In-Reply-To: <51251D0E.1050202@computer.org> References: <066.02811072057e3e608e2532e3a9c56d6d@trac.tools.ietf.org> <51251D0E.1050202@computer.org> Date: Thu, 21 Feb 2013 01:10:27 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org, manet issue tracker Subject: Re: [manet] #16: The Reactive Protocol Duplicate Suppression Table X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 00:10:28 -0000 Hello Charlie, I agree, but why there is not much attention in the WG for unidirectional links? Regarding RREP it can be optional, but I prefer one table for duplicate RteMsg, AB On 2/20/13, Charles E. Perkins wrote: > > Hello Abdussalam, > > There was a revision of AODVv2 that included RREPs in the duplicate > suppression table. It did have the effect of making the description more > difficult to understand without additional benefit in the typical case > where RREPs are unicast. For multicast RREP, there would be quite a > bit more benefit, but the use case for multicast RREP involves networks > with unidirectional links, which have not seen much attention lately in > the working group. Moreover, the duplicate suppression table itself > would need to distinguish between RREQ and RREP messages if they > were combined in the same table, so logically speaking the table could > still be viewed as two separate tables. > > If there is interest, handling multicast RREPs in a similar table could > be more explicitly specified in the document. > > Regards, > Charlie P. > > > On 1/19/2013 5:13 PM, manet issue tracker wrote: >> #16: The Reactive Protocol Duplicate Suppression Table >> >> I agree with the proposed to add RREPs in table as RREQ for suppression >> as >> below message, however, will need to discuss if there are side affects >> >> http://www.ietf.org/mail-archive/web/manet/current/msg14472.html >> > > > -- > Regards, > Charlie P. > > From ulrich@herberg.name Wed Feb 20 17:09:14 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D322E21F8CB5 for ; Wed, 20 Feb 2013 17:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXjq8NE-7YRl for ; Wed, 20 Feb 2013 17:09:14 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id B2E4B21F8CB3 for ; Wed, 20 Feb 2013 17:09:13 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id f13so2225616vcb.26 for ; Wed, 20 Feb 2013 17:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=9naZwRbT590qSKV2awduFlx7kTLiV9ssJ32262zWFk0=; b=BLgLwbe2YsJHRXvOYZaTHKNRQ1GcC6/GnA2VkbDV3n4sQbJsMSRykyxR6o2DYc2Ou2 Oxw8mqmDB8ChPbitO+WHCUclWpvYqVKyjzGVKaRA6xyoC+wJ5BHGUZOgohnTOhVccFYy CJxixbF51nJX/ESjwE6d92Qjwb8JW8/9wlNeo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=9naZwRbT590qSKV2awduFlx7kTLiV9ssJ32262zWFk0=; b=cA20cY54KxS8G8TEBwLa8sVS6CgjHLgLv6uiAqHRgnFupxxdrSluMP4XAQIlZWh6jD UDRu3iKixora+3VLBokv+lzfKnR32gHU70x2iGJRar/cQZKmFtZVFDO7LFKAdeTIbLRg PqWFIBwks3kAdGT12mxF60BnLBBiwsoCfVmbLCxEDW2Cjv16HurR+TMHv2jlWmLKZrhJ 6s7PSBkycmbtuGGP+V1d2oEy3gBlrjE9CcYeZ789wt8MDFjeefo71IVdAx5bqa0OAwDN gqvO9KK8mlLw+dX2nC5YZqnThCJktUbrfLe/dtYyw/1MnhmtyjQalE+Xcjhw7LgT5daF ik/Q== MIME-Version: 1.0 X-Received: by 10.220.154.14 with SMTP id m14mr17304034vcw.21.1361408949223; Wed, 20 Feb 2013 17:09:09 -0800 (PST) Received: by 10.220.107.7 with HTTP; Wed, 20 Feb 2013 17:09:09 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 17:09:09 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=f46d043d64afd001f904d631b8b1 X-Gm-Message-State: ALoCoQkM8n3f1QzpCxfh3R0ZqNLwuA65cosly7zcqzuFN5YCrJrX9GZGS/ENPbXr51oXEdREUr4A Subject: [manet] Fwd: 86th IETF - WG/BoF/IRTF Agendas X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:09:15 -0000 --f46d043d64afd001f904d631b8b1 Content-Type: text/plain; charset=ISO-8859-1 Hi, please send your slot requests soon. A draft agenda is due on Feb 27, so it would be good to get requests before then. Thanks Ulrich ---------- Forwarded message ---------- From: Wanda Lo Date: Tue, Feb 19, 2013 at 1:58 PM Subject: 86th IETF - WG/BoF/IRTF Agendas To: "wgchairs@ietf.org Group" Cc: Internet Research Steering Group Dear WG, BoF, and IRTF Chairs, Draft Working Group agendas are due, Wednesday, February 27, 2013. Please upload using the IETF Meeting Materials Management Tool, https://pub.ietf.org/proceedings/ . Revised Working Group agendas are due by Monday, March 4, 2013, upload using the IETF Meeting Materials Management Tool https://pub.ietf.org/proceedings/ . Please upload at your earliest convenience. Only 18 days to IETF 86! Thanks, Wanda ===========================**** Wanda Lo / Project Manager**** Internet Engineering Task Force (IETF)**** ****48377 Fremont Blvd., Ste. 117** **Fremont**, **California** **94538**** / ****USA**** T: +1.510.492.4082 F: +1.510.492.4001 *www.ietf.org***** **** *--*** Managed by Association Management Solutions (AMS)**** Forum Management, Meeting and Event Planning**** www.amsl.com --f46d043d64afd001f904d631b8b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

please send your slot requests soon. A draft agenda is due on Fe= b 27, so it would be good to get requests before then.

Thanks
Ulr= ich

---------- Forwarded message --------= --
From: Wanda Lo <wlo@amsl.com>
Date: Tue, Feb 1= 9, 2013 at 1:58 PM
Subject: 86th IETF - WG/BoF/IRTF Agendas
To: "= ;wgchairs@ietf.org Group" <= ;wgchairs@ietf.org>
Cc: Internet Research Steering Group <i= rsg@irtf.org>


De= ar WG, BoF, and IRTF Chairs,


Draft Worki= ng Group agendas are due, Wednesday, February 27, 2013. =A0Please upload us= ing the IETF Meeting Materials Management Tool,=A0https://pub= .ietf.org/proceedings/.

Revised Working Group agendas are due by Monday, March 4, 2013, upload = using the IETF Meeting=A0Materials Management Tool=A0https://= pub.ietf.org/proceedings/.

Please upload at your earliest convenience.


Only = 18 days to IETF 86!


Thanks,
Wanda






=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
Wanda Lo / Proj= ect Manager
Internet Engine= ering Task Force (IETF)
<= /u>48= 377 Fremont Blvd., Ste. 117=A0
Fremont,=A0California=A094538=A0/=A0USA=A0
T: +1.510.492.4082=
F: +1.510.492.4001=A0
www.ietf.org
=A0
--
Managed by Association Management Solutions (AMS)
For= um Management, Meeting and Event Planning



<= /span>


--f46d043d64afd001f904d631b8b1-- From sratliff@cisco.com Wed Feb 20 17:25:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C21521E8055 for ; Wed, 20 Feb 2013 17:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bMQZ5jHR8WY for ; Wed, 20 Feb 2013 17:25:47 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAEE21E804B for ; Wed, 20 Feb 2013 17:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8165; q=dns/txt; s=iport; t=1361409947; x=1362619547; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GZWmk50TLpdAT4SMI6bqVqEHPCGtfzZKY8LlLodsHEg=; b=Zwz7eqzdlw7anRzoOmuxYsJV9EPO/4KKSal9Qa3FjxmkpIR0suNBeEtb j1k+eh4RjZ1Kz8Oh9E830aQi/iTAMGW1mfv8y+CvWcrK8kNDxMbgUVRy2 0KnwP/y4FlcA6L+sEoIBtAFThwOU271w7oRqsuM/SfI1pZVGpqXKGnho+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAM92JVGtJXG//2dsb2JhbABFwFmBBBZzgh8BAQEDAQEBATc0CwULAgEIDgoKFBAnCyUCBA4FCAyHeAYMwDEEjUcGgQ4CMQeCX2EDpweDB4FpCRce X-IronPort-AV: E=Sophos;i="4.84,705,1355097600"; d="scan'208";a="179192267" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 21 Feb 2013 01:25:46 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1L1Pk20006273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 01:25:46 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 19:25:46 -0600 From: "Stan Ratliff (sratliff)" To: Jiazi Yi Thread-Topic: [manet] Why the WG Reactive Protocol to be Compatible with another? Thread-Index: AQHOD7YdnV9QWCTj4ky9SbpNJTHig5iD6eaA Date: Thu, 21 Feb 2013 01:25:45 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10031A69@xmb-aln-x03.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100315E3@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.212] Content-Type: text/plain; charset="us-ascii" Content-ID: <60A928079FF8C4439A32C33755D4AC4D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:25:48 -0000 On Feb 20, 2013, at 5:03 PM, Jiazi Yi wrote: > Hi,=20 >=20 > Please check inline (I'm just speaking on behalf of myself, not the LOADn= g author team) : >=20 >=20 > On Feb 20, 2013, at 9:52 PM, Stan Ratliff (sratliff) = wrote: >=20 >> Jiazi,=20 >>=20 >> On Feb 20, 2013, at 12:22 PM, Jiazi Yi wrote: >>=20 >>> Hi AB, JP: >>>=20 >>> I also have doubts why the editor of DYMO declares that it will be comp= atible with LOADng, and how it can be achieved.=20 >>=20 >> It probably won't be achieved - especially if you and the other LOADng c= o-authors decide not to help us, taking the position of standing back and l= obbing emails like this one into the fray. If this is a desirable, then I w= ould say "suggest some alternatives, help us out". If not, then let us as a= working group declare it a dead issue, and move on.=20 >=20 > In the last 2~years, the LOADng co-authors have spent huge amount of effo= rt in reactive protocols. For me personally, it's the core of my research p= roject, and I invested most of my time in it. Hopefully it won't be regarde= d as "not willing to help".=20 FWIW, here's how I look at it: The past history is what it is. The AD made = the decision he made. We are where we are. The operative question is whethe= r or not any given working group participant is willing to help the WG move= forward., *from where we are*, to the best reactive protocol we can specif= y. Any and all assistance and ideas are welcome, and contributors will be a= cknowledged.=20 >=20 >=20 >>=20 >>>=20 >>> Although those two protocols share the general idea, the packet format = and message processing details are very different. As one who participated = in all LOADng interop tests and know dymo draft relatively well, I can say = that a lot of effort are needed to make DYMO and LOADng compatible, not to = mention the interop tests needed to verify the compatibility (at this point= , I have no idea if there is DYMO implementation, so I'm not even sure if s= uch test is possible).=20 >>=20 >> OK. Going on (yet another) "micro-cosmic trip through MANET reactive pro= tocol history", I'll note that AODV compatibility with LOADng was something= that the co-chairs mandated from the combined author teams when we thought= that merging the two documents was something that could actually be accomp= lished. The rationale there was to not exclude existing LOADng implementati= ons from being able to say they were compliant with the RFC - something tha= t *no one* on the author teams (including yourself) complained about *at th= e time*.=20 >=20 > Since the Taipei IETF, the starting point agreed by the authors teams was= always LOADng, as indicated in Ulrich's mail to the chairs.=20 > In that context, all the authors agree that companion documents can be de= veloped, so that the dymo functions can be supported to be compatible.=20 > Thanks for adding the note.=20 > The issue of starting point didn't come out until several months before A= tlanta IETF. If I knew that the document would be based on DYMO, it would b= e a totally different issue.=20 We can quibble about the exact timing of when "the starting point" came out= - my memory is that the requirement was clearly stated to the parties invo= lved in YVR. However, my point is that it did come out, has been out "for a= while", and no dissent was received. So any implication that this popped u= p out of the blue is incorrect. Stan >=20 >=20 >>=20 >> So to restate, the fundamentals of the issue have changed - the effort t= o merge the documents was a total, miserable failure. At this juncture it i= s fair to ask if LOADng compatibility is even something that is desirable. = The general trend of comments I'm reading on the list indicates that it is = not. Are there other opinions?=20 >=20 >=20 > I agree that the fundamentals of the issue have changed, since the starti= ng point and the design principle (slim core + companion document) were cha= nged.=20 > As far as I can see, LOADng has no intention to be changed to "get closer= to DYMO". Having DYMO be compatible with LOADng would need great effort an= d add extra complexity to the protocol - starting from scratch probably wo= uld be easier to make a clear specification and be compatible with LOADng.= =20 > I have spent days and nights in the interop tests of LOADng. Producing ON= E clear specification with limited options, and making it able to interoper= able among independent implementations are already hard enough. Having TWO = specifications, and one of them is a super set with all those additional op= tions which are not specified clearly, would be a nightmare. Awful among of= iterations and tests would be required.=20 >=20 > Therefore, personally, I would say LOADng compatibility is not desirable.= =20 >=20 > best >=20 > Jiazi >=20 >=20 >>=20 >> Stan=20 >>=20 >>=20 >>>=20 >>> btw,=20 >>>=20 >>>> the objective of the IETF is to produce qualitative protocols for the = best of the IETF community and industry, not to make X or Y happy >>>=20 >>>=20 >>> I can't agree more.=20 >>>=20 >>> best >>>=20 >>> Jiazi >>>=20 >>> On Feb 20, 2013, at 4:26 PM, JP Vasseur (jvasseur) = wrote: >>>=20 >>>> Hi AB, >>>>=20 >>>> This is critical topic and I cannot agree more with you; the objective= is in my opinion to come up with the best protocol for the IETF. >>>> Let's be clear: the objective of the IETF is to produce qualitative pr= otocols for the best of the IETF community and industry, not to make >>>> X or Y happy. Every single good ideas borrowed from Load should in my = opinion be adopted by AODVv2, if there is a consensus. On the >>>> other hand, trying to design AODVv2 with the constraint of making it c= ompatible with another protocol is a COMPLETE non sense. >>>>=20 >>>> Thanks. >>>>=20 >>>> JP. >>>>=20 >>>> On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote: >>>>=20 >>>>> Hi Folks, >>>>>=20 >>>>> I am not sure why we will make effort of AODVv2 compatible with >>>>> LOADng, I am trying to find a good reason mentioned in the WG. I seen >>>>> the intention by some participants, but not sure was it intention to >>>>> merge DYMO+LOADng without compatibility (with either DYMO or LOADng) >>>>> or with percentage of compatibility. Do you think it is good way to >>>>> make the reactive protocol and then try to make it compatible? Pleas= e >>>>> advise, >>>>>=20 >>>>> I will have to agree with the below proposal, that if the WG is >>>>> agreeing to make compatible with LOADng, then why not go for 100% >>>>> compatibility, just change the name title. >>>>>=20 >>>>> AB >>>>>=20 >>>>> Sub:Re: [manet] Reactive protocol decision process, for the record th= oughts >>>>> On 2/16/13, Ulrich Herberg wrote: >>>>>> Justin, >>>>>>=20 >>>>>> I very much agree with you, Justin. One point I would like to add is >>>>>> that the WG will now spend a lot of time making the new AODVv2 >>>>>> compatible with LOADng (which is claimed in the current DYMO draft); >>>>>> that is, in my opinion, a wasted effort since the LOADng draft is pe= r >>>>>> definition 100% compatible with LOADng (had that been the starting >>>>>> point). >>>>>> Ignoring a document that has multiple interoperable implementations, >>>>>> deployments, MIB document, as well a support from at least a dozen >>>>>> MANET participants (not only LOADng authors) without giving rational >>>>>> was a disappointment for me. >>>>>>=20 >>>>>> Best regards >>>>>> Ulrich >>>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From yi.jiazi@gmail.com Thu Feb 21 05:29:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16E121F8C7A for ; Thu, 21 Feb 2013 05:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.27 X-Spam-Level: ** X-Spam-Status: No, score=2.27 tagged_above=-999 required=5 tests=[AWL=-4.920, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_FR=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0HZLcysyzlU for ; Thu, 21 Feb 2013 05:29:52 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9E80021F8CAD for ; Thu, 21 Feb 2013 05:29:52 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so7724190wey.17 for ; Thu, 21 Feb 2013 05:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Mq/Z4PxMv6U/111JhfsDQDW0QSfmM+N6suX4DxgBsXw=; b=M/N39a7J6s6MTAFjXerLFPGD0sQk0tDRNRLF1rg2vozqZoq6JUij+lcAh+QIhfxG5w FB6Nwmov06GIW0CSBvGGTJVmWajDxas4I9ub5dAMIyEEFYCpQ8NIhQC4kF/ggsgvv5tn VA1x8t9sTwWwGzkpdmdhmq7TLrF9HJiN1ClHD/FTZ3TnmGyG/4Be1BbbJz1ygA7xoDk4 cL2XGnM6wCwngF2RJpCtUKp3idR4UUvOsMZ8Y7v0B2IZ/aTR34+4mITBUlCTYmhTvhJc sVscxIwg+ijtav+lmepCN7BolKKdQD7Hv/POqiMjijkYXBVEec5YEfGJB2m0l4whrbS4 yGMg== X-Received: by 10.194.236.233 with SMTP id ux9mr41217013wjc.36.1361453391585; Thu, 21 Feb 2013 05:29:51 -0800 (PST) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id bg5sm40157915wib.8.2013.02.21.05.29.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 05:29:50 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi Date: Thu, 21 Feb 2013 14:29:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130219143718.22863.41678.idtracker@ietfa.amsl.com> To: Stan Ratliff , Joe Macker , Ulrich Herberg X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org List" Subject: [manet] Fwd: New Version Notification for draft-nguyen-manet-management-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 13:29:54 -0000 Dear all,=20 FYI, there is a new draft in the management architecture for MANET.=20 This draft is created on the request of Benoit Claise, operations and = management AD. During the NHDP-MIB IESG evaluation, Benoit Claise agreed = to let the draft pass under the condition that we promise to write a = draft describing the applicability of MANET management, to answer the = question "what to manage in MANETs, and how to manage MANETs".=20 In the meantime, OLSRv2-MIB has completed WGLC in Dec. 2012, and = expected to proceed to AD review soon. It's very likely that the = OLSRv2-MIB draft won't pass Benoit in the IESG evaluation, without such = management applicability draft, ideally as WG document.=20 This draft has exactly that purpose. Benoit have already given feedback = on the outline, and said that we are in the right direction.=20 The draft is still at -00, mainly to provide a general idea and the = outline. We would like to: - have comments from the WG on the draft, mainly the structure = of the document (the details are still to be polished by the authors).=20= - request a slot to present the draft in the upcoming IETF = (haven't decided who will present yet) - see the draft to be adopted by the WG shortly after IETF in = Orlando, so that the MIB documents won't be jeopardized.=20 best Jiazi Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nguyen-manet-management-00.txt > Date: February 19, 2013 3:37:18 PM GMT+01:00 > To: james.h.nguyen4.civ@mail.mil > Cc: robert.g.cole.civ@mail.mil, jiazi@jiaziyi.com, = ulrich@herberg.name, jdean@itd.nrl.navy.mil >=20 >=20 > A new version of I-D, draft-nguyen-manet-management-00.txt > has been successfully submitted by James Nguyen and posted to the > IETF repository. >=20 > Filename: draft-nguyen-manet-management > Revision: 00 > Title: Network Management of Mobile Ad hoc Networks = (MANET): Architecture, Use Cases, and Applicability > Creation date: 2013-02-18 > Group: Individual Submission > Number of pages: 24 > URL: = http://www.ietf.org/internet-drafts/draft-nguyen-manet-management-00.txt > Status: = http://datatracker.ietf.org/doc/draft-nguyen-manet-management > Htmlized: = http://tools.ietf.org/html/draft-nguyen-manet-management-00 >=20 >=20 > Abstract: > This document aims at providing an extended architecture, use case > and applicability statement for management of MANETs, as a guideline > for how to manage MANETs. This document describes different > management activities, such as network configuration, monitoring of > state, monitoring of performance, fault management, and software > upgrades. Different aspects of a MANET management architecture are > illustrated (e.g., distributed vs. centralized management, flat vs. > hierarchical management, management of an entire network vs. an > individual router, etc.) and contrasted to the NMS architecture in > the Internet. A desciption of typical MANET use cases relevant for > management is followed by an overview of current standard management > protocols that can be used in MANETs. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From abdussalambaryun@gmail.com Thu Feb 21 06:42:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7219121F8AAD for ; Thu, 21 Feb 2013 06:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNGySqA+M2eF for ; Thu, 21 Feb 2013 06:42:10 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0B89721F8CA5 for ; Thu, 21 Feb 2013 06:42:10 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id kp14so4796998pab.33 for ; Thu, 21 Feb 2013 06:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=0J6xBMYLpvW1ZCxZDvxhrbEKISaMFGNYdiSbNpI51rA=; b=R0T1lIfi9F7IBlo2id+kII2agn5RKYfkJjJqVpvSoIT7sFT23QLrArPweOrVt1823H VuIPkKtevzOLQD/AC1xBnKLPe9Y2oXkf0tljsQuvuV+rkq+tbVyn5PTv0tXGHTlyndtM CXXegXnDMz+vVL1rBIJI+xSKkMJ334k62H+RF461kjiNTD252rF4kSqL5xkhPZi62fKO pqmEDEkmHDMxsemwojqAxYU50pK605QN6HPwGDargjxdty9REvqGdrqoTgVFK+f7zRUv PuTtUeOreuUshfywxSrmRxj69rTKpTnpHXnEvMyEpcZdrPpqNqyetx35gz3oT7Kz1EfH PEjw== MIME-Version: 1.0 X-Received: by 10.66.220.227 with SMTP id pz3mr8470968pac.190.1361457729880; Thu, 21 Feb 2013 06:42:09 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 06:42:09 -0800 (PST) Date: Thu, 21 Feb 2013 15:42:09 +0100 Message-ID: From: Abdussalam Baryun To: "manet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:42:10 -0000 Hi Jiazi, Yes there are many implementation but not presented well, I think the authors have an implementation, and also many researchers have tested the old DYMO, AB ++ Sub: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? On 2/20/13, Jiazi Yi wrote: > I have no idea if there is DYMO implementation, > http://www.ietf.org/mail-archive/web/manet/current/msg14948.html From henning.rogge@fkie.fraunhofer.de Thu Feb 21 06:46:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2C521F8CBF for ; Thu, 21 Feb 2013 06:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaF9Jc-IkdTO for ; Thu, 21 Feb 2013 06:46:40 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id C282F21F8CA5 for ; Thu, 21 Feb 2013 06:46:39 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U8XPy-0002wk-Ae for manet@ietf.org; Thu, 21 Feb 2013 15:46:38 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U8XPy-0001lx-7z for manet@ietf.org; Thu, 21 Feb 2013 15:46:38 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 21 Feb 2013 15:46:38 +0100 Message-ID: <51263342.1080207@fkie.fraunhofer.de> Date: Thu, 21 Feb 2013 15:46:26 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070805030704070505000708" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16712/Thu Feb 21 12:40:19 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: b17092e937cef22d8bf42b2c04946c57 Subject: Re: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:46:41 -0000 --------------ms070805030704070505000708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 02/21/2013 03:42 PM, Abdussalam Baryun wrote: > Hi Jiazi, > > Yes there are many implementation but not presented well, I think the > authors have an implementation, and also many researchers have tested > the old DYMO, This is a very bold statement... do you have some evidence for this? I remember a few people trying to track down a working AODV=20 implementation and failing. But I never have seen a DYMO implementation. If someone on this list HAS an implementation, I would like to hear=20 about it. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070805030704070505000708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMjExNDQ2MzZaMCMGCSqGSIb3DQEJBDEWBBTSsZXvuXxGwDM1n8ro7BzXe0W19jBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAl0sisGLBJ4dQ/Df3euD11jYf6mZeTZrMXu3pJRhzCMQh k2YxFn8Ru04kzSn0GjZEsge/2vy3PHxj7Lci3ChFm1vmdxKrS5Q3uB5XlB6zxP4+XvfOToFX Xgfz++NZ7rVAqjfD5msgJHkz7AtY6vz+Ytt+LNb26vNx/QpVBci/HII5idkz+5sKbvR1goHr SS6yhYkzPMp5R/ylY17WIueDag9XsXYzYxWqacK8hVRbDyi2Awwujn2//rIj44fNhwggF8/d hHhkor6dwZZVHh6OfYKEaI6y3iCyTWGJc3cLmB7hwLiYNv2P4lpsIzKZ/5DvS0zU5gcFr+Im bJCFvDr+oAAAAAAAAA== --------------ms070805030704070505000708-- From fjros@um.es Thu Feb 21 07:02:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED41E21F85C0 for ; Thu, 21 Feb 2013 07:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P51uJh40d6or for ; Thu, 21 Feb 2013 07:02:46 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id AF52521F8CAC for ; Thu, 21 Feb 2013 07:02:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 2F9A75D567; Thu, 21 Feb 2013 16:02:44 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UtSxn9NBX0xI; Thu, 21 Feb 2013 16:02:43 +0100 (CET) Received: from eduroam_um-228-233.inf.um.es (eduroam_um-228-233.inf.um.es [155.54.228.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fjros) by xenon14.um.es (Postfix) with ESMTPSA id C9BC85D563; Thu, 21 Feb 2013 16:02:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= In-Reply-To: <51263342.1080207@fkie.fraunhofer.de> Date: Thu, 21 Feb 2013 16:02:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3969D96F-B639-4DDF-A7F7-66067B383551@um.es> References: <51263342.1080207@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1085) Cc: manet@ietf.org Subject: Re: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:02:48 -0000 Hi Henning, A long time ago I wrote an implementation that is mostly compliant with = draft dymo-04, and it incorporates some features from dymo-05. = Therefore, I'm afraid that the codebase is far from being compliant with = aodvv2-00. Unfortunately, I have no time to maintain this code any more. = However it is publicly available, so if anyone is interested in updating = it please go ahead (I don't know whether this is better than starting = from scratch). DYMOUM: http://masimum.inf.um.es/fjrm/?page_id=3D126 You can find a list of other implementations (AFAIK also outdated) in http://www.ianchak.com/dymo/ Best, fran El 21/02/2013, a las 15:46, Henning Rogge escribi=F3: > On 02/21/2013 03:42 PM, Abdussalam Baryun wrote: >> Hi Jiazi, >>=20 >> Yes there are many implementation but not presented well, I think the >> authors have an implementation, and also many researchers have tested >> the old DYMO, >=20 > This is a very bold statement... do you have some evidence for this? >=20 > I remember a few people trying to track down a working AODV = implementation and failing. >=20 > But I never have seen a DYMO implementation. >=20 > If someone on this list HAS an implementation, I would like to hear = about it. >=20 > Henning Rogge > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Francisco J. Ros, PhD Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ From yi.jiazi@gmail.com Thu Feb 21 07:15:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729A021F8E63 for ; Thu, 21 Feb 2013 07:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.489 X-Spam-Level: X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[AWL=2.760, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgLjdFAT5Ocx for ; Thu, 21 Feb 2013 07:15:13 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id B1DE921F8E45 for ; Thu, 21 Feb 2013 07:15:12 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so7636440wib.9 for ; Thu, 21 Feb 2013 07:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=phHqKDTJT/AHaiz5SGcCoJZ5yaIN0j8Kh5GAXbJG6Yc=; b=VdnAZOwcMaT0U8i/nt3iUd76hM3GZ7uKwngPzOE/SqhTTPQl6on0dPfsdZVPxJ7DG4 uSaLVo/lFVHzAut2xXeU2c1LxpIYEvDf0456lRUjMRoVDcmVqcs1QiAeiQOlt2SMxyxX ikkcUuWRzGYpTtFL1TlKCMYghMRVkGKp/ggSzaso+twbj3wPe9Nc3F+EEzRI5lrsSXIC GNt0ICmjWvI4Uw2LKE6aWSgFiuhsDErVCXhJmLI/LG+IjlxQglT3xiKDYgqHElMrYyss F0X+qGmAtDvoDNCBdjvNp+Ol3TOuxbtvzZDeNC2WUVkXkuUsRUXS1Fx7SMNvR8P/L7W4 TF+Q== X-Received: by 10.180.79.133 with SMTP id j5mr18755896wix.27.1361459711729; Thu, 21 Feb 2013 07:15:11 -0800 (PST) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id j4sm35611511wiz.10.2013.02.21.07.15.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 07:15:11 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Thu, 21 Feb 2013 16:15:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7C036429-1FF6-4384-BBF9-4E300E8D7415@jiaziyi.com> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:15:13 -0000 AB,=20 I'm aware of some dymo implementation in academic conferences. However, = that was quite long time ago. DYMO had very big changes since its -21.=20= When I'm saying implementations, I actually mean: o It's complaint to the latest version of the document o It's publicly known (not necessarily open source) For example, when I'm saying LOADng has 4 publicly known = implementations, it means: o It's updated to the latest (or very recent) revision o Those four are publicly known, in the interop draft, and = different scientific publications. I know there are several others, but = at this point, I can't disclose them (so they are not counted into 4 = known implementations).=20 best Jiazi On Feb 21, 2013, at 3:42 PM, Abdussalam Baryun = wrote: > Hi Jiazi, >=20 > Yes there are many implementation but not presented well, I think the > authors have an implementation, and also many researchers have tested > the old DYMO, >=20 > AB > ++ > Sub: Re: [manet] Why the WG Reactive Protocol to be Compatible with = another? > On 2/20/13, Jiazi Yi wrote: >> I have no idea if there is DYMO implementation, >>=20 > http://www.ietf.org/mail-archive/web/manet/current/msg14948.html > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Thu Feb 21 07:16:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB2621F8E64 for ; Thu, 21 Feb 2013 07:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teYv0EnQDQEB for ; Thu, 21 Feb 2013 07:16:55 -0800 (PST) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id C9BB821F8E63 for ; Thu, 21 Feb 2013 07:16:55 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id rr4so3521133pbb.27 for ; Thu, 21 Feb 2013 07:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NT6eIy1UDiO8WpStKzWRwk+Mozpi61F/uYdwesP+oqk=; b=BkEMePrHfA0NoytshipAHSEu4CRor/Rshm7FAWAcGCj46lRd4rOUczI1kAvNmNF4Qr FayApAEOmztiQ9C2Bh0Bnsij5V6ge2ae6V3J0vMlg77HYeAUSKE9LffEKE89lh0CiwB5 En4RUKpnkLlsvIlxssKtCjg3sQWCBCHaI5XROyPy0bjXZesWrma9prjTIthfGfIKgqXx q3UBMYhGnuDtEJd+EShjh36O8mBR9jft/Xdg6hGrjGlUL/vBnWDmGRuaf7Yklljc7D7R LQee4KjJO2IqAiayF58Sz/dFjWmo5To03cGva/k6QYjt7b9AZ1GbTGaJXmh7qRDfjxcN Lw1Q== MIME-Version: 1.0 X-Received: by 10.66.185.33 with SMTP id ez1mr8629527pac.93.1361459815545; Thu, 21 Feb 2013 07:16:55 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 07:16:55 -0800 (PST) In-Reply-To: <50F7DDFD.8010100@hitachi.com> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <379DFA7A-3E9E-4624-A3BF-639F691A2886@thomasclausen.org> <50F7DDFD.8010100@hitachi.com> Date: Thu, 21 Feb 2013 16:16:55 +0100 Message-ID: From: Abdussalam Baryun To: Yuichi IGARASHI Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:16:56 -0000 I understand that the implementation interoperability tests were conducted according to the specification in [LOADng-00]. So it was implemented for LLNs not for MANETs, and that for future tests of same protocol in MANETs interoperability we will need test specification LOADng-06 not version 00. Do you think both will have same effects spec 00 and 06? AB On 1/17/13, Yuichi IGARASHI wrote: > Hi Abdussalam, > > We have two different independent implementations. Even in my company, > we had no director among implementors, because our main purpose was to > confirm the interoperability of LOADng spec. > > Best regards, > Yuichi From abdussalambaryun@gmail.com Thu Feb 21 07:20:02 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3E021F8E56 for ; Thu, 21 Feb 2013 07:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZM8pa2wOfBt for ; Thu, 21 Feb 2013 07:20:01 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8F59921F8E23 for ; Thu, 21 Feb 2013 07:20:01 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa10so4798215pad.27 for ; Thu, 21 Feb 2013 07:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4c3qb2hwefk5CM+bgi0zC21fh0dyjrHtgnulz9k8NyE=; b=Sbduy510UyNBdRGUKIYf7wch8M+RhwbyJZoeYZL6ItOS84ZqL4MDeFWGpDBuSEI8iw YhN8fDext6FL2+wZqIogMxYb+PHEsn3EtSBrOeEBpg8DHkU4Z4E5hqnFY7dfwpSj/gs7 NfEM57ww/pu/zpwcnEc+Ue++fs59YKh2DKxRv7MRXPdkiCE2YRfQh9hm5UO9yUyHbT2s X7p1c5s5YOxWXGA4RFLW0Sw5USI7DpZLOlbLZPY/4knBfpWWmyfm/H6FLe/yftMSdQKl vZos8/EebSIOw6Hv+lBZkgiP5L4Bs549Vodk/UyfsygUb7jVh1IWIylotX79dVnd5J/2 /8LQ== MIME-Version: 1.0 X-Received: by 10.68.245.229 with SMTP id xr5mr54688566pbc.163.1361460001195; Thu, 21 Feb 2013 07:20:01 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 07:20:01 -0800 (PST) In-Reply-To: References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <379DFA7A-3E9E-4624-A3BF-639F691A2886@thomasclausen.org> <50F7DDFD.8010100@hitachi.com> Date: Thu, 21 Feb 2013 16:20:01 +0100 Message-ID: From: Abdussalam Baryun To: "charliep@computer.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Stan Ratliff Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:20:02 -0000 Hi All, We will need a fresh running code for the new reactive protocol, or to develop the old DYMO, it will make the new protocol more interesting, AB From abdussalambaryun@gmail.com Thu Feb 21 07:24:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B9121F8DDC for ; Thu, 21 Feb 2013 07:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB4Q6sRneN-2 for ; Thu, 21 Feb 2013 07:24:13 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id E4EF321F8AC3 for ; Thu, 21 Feb 2013 07:24:12 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id t11so4189574daj.36 for ; Thu, 21 Feb 2013 07:24:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vUIvJNL1UnGd/BOiDdzrmELDPjVdIQtktq0qXsXvT3o=; b=djNqUd3xEx4QijBqJlW7EqNikpdSkCm+dcjRHU5BMG4qdOPhNDri/u9iDv7Smf0a51 mJuSG/2TQwLZgQb+yltChdNr+Ohqk9S3mzKDXTi7h+b3sbozv39vU86TBqyuldz/3u76 iAFwbo5/jhyPWxijhr8lqfYRLvkUoWIlGuNdqQvhjS/+ip7OslnF4wWq1oZnGUpRviyj azN0ZAzdotLSnHrK53w8y428suE0/cf5Cq+W0v6/RCXfZIN9nExJ5VIgLcs9QsYE7WGY t1OCTEtYoyegZvvp89qx5voGRUP7PqwCsMn95Alj0S3rJlfNuAv0OL0ovlUtmF4o9Aqg Lhkw== MIME-Version: 1.0 X-Received: by 10.68.217.2 with SMTP id ou2mr55461264pbc.6.1361460252734; Thu, 21 Feb 2013 07:24:12 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 07:24:12 -0800 (PST) In-Reply-To: <7C036429-1FF6-4384-BBF9-4E300E8D7415@jiaziyi.com> References: <7C036429-1FF6-4384-BBF9-4E300E8D7415@jiaziyi.com> Date: Thu, 21 Feb 2013 16:24:12 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:24:13 -0000 Hi Jiazi, I know that DYMO implements are old, (hopfully developed to new AODVv2) I already stated that, just wanted to answer to your question. Regarding LOADng it was an implementation for LLNs not for MANETs. So far there is no implementation that uses the RFC5498, which I am interested in as OLSRv2 is using, AB On 2/21/13, Jiazi Yi wrote: > AB, > > I'm aware of some dymo implementation in academic conferences. However, that > was quite long time ago. DYMO had very big changes since its -21. > > When I'm saying implementations, I actually mean: > o It's complaint to the latest version of the document > o It's publicly known (not necessarily open source) > > For example, when I'm saying LOADng has 4 publicly known implementations, it > means: > o It's updated to the latest (or very recent) revision > o Those four are publicly known, in the interop draft, and different > scientific publications. I know there are several others, but at this point, > I can't disclose them (so they are not counted into 4 known > implementations). > > best > > Jiazi > > On Feb 21, 2013, at 3:42 PM, Abdussalam Baryun > wrote: > >> Hi Jiazi, >> >> Yes there are many implementation but not presented well, I think the >> authors have an implementation, and also many researchers have tested >> the old DYMO, >> >> AB >> ++ >> Sub: Re: [manet] Why the WG Reactive Protocol to be Compatible with >> another? >> On 2/20/13, Jiazi Yi wrote: >>> I have no idea if there is DYMO implementation, >>> >> http://www.ietf.org/mail-archive/web/manet/current/msg14948.html >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From yi.jiazi@gmail.com Thu Feb 21 07:24:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1806821F8E57 for ; Thu, 21 Feb 2013 07:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.81 X-Spam-Level: *** X-Spam-Status: No, score=3.81 tagged_above=-999 required=5 tests=[AWL=-3.380, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_FR=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNJ5sodo3RHP for ; Thu, 21 Feb 2013 07:24:24 -0800 (PST) Received: from mail-we0-x22d.google.com (we-in-x022d.1e100.net [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BDA6D21F8CB2 for ; Thu, 21 Feb 2013 07:24:21 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id r5so7603222wey.18 for ; Thu, 21 Feb 2013 07:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=/FkkxYeGDinwyJEu0wsMSle9WanZ7rMSErQ3dLgWRpk=; b=Ls4iFl2ZaavSob1FSP6J007fJs1BkuANcnOB91NBXXtmZbYdT8oUgsrVSa+2q16sDE yZph0v+gaZ4xBXDGBb8w1ZZYEQcSlfjoD10uES+kP8RGnKmUx1tWbgyHZJni+z5q8du5 9KaexC2fY/5sVts0et0pTYNTx0hGH++MRFW/8F9K4Imo8XbBuZjIlRezS0o/cbtINGaf Uf+RR1muad/qmd+bfbzhkvqVr5L17lAtTMf8NlGNHKZ7F2LJXVYXgnRIgBg+Z7iTHNPB J/HpqRBC4HBbjCmz99nOdmDpe4eaje4pQHHkfUosEgW8pMf5FBnP0o5/maEMQpHb1FeC OQ8w== X-Received: by 10.180.98.198 with SMTP id ek6mr19472221wib.7.1361460260651; Thu, 21 Feb 2013 07:24:20 -0800 (PST) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id m6sm40801667wic.2.2013.02.21.07.24.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 07:24:19 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Thu, 21 Feb 2013 16:24:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <379DFA7A-3E9E-4624-A3BF-639F691A2886@thomasclausen.org> <50F7DDFD.8010100@hitachi.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:24:25 -0000 On Feb 21, 2013, at 4:16 PM, Abdussalam Baryun = wrote: > I understand that the implementation interoperability tests were > conducted according to the specification in [LOADng-00]. That's not true.=20 Before giving comments, please read related drafts first.=20 It was clearly called out in the interop draft, and loadng-08, = implementation status section.=20 Jiazi > So it was > implemented for LLNs not for MANETs, and that for future tests of same > protocol in MANETs interoperability we will need test specification > LOADng-06 not version 00. Do you think both will have same effects > spec 00 and 06? >=20 > AB >=20 > On 1/17/13, Yuichi IGARASHI wrote: >> Hi Abdussalam, >>=20 >> We have two different independent implementations. Even in my = company, >> we had no director among implementors, because our main purpose was = to >> confirm the interoperability of LOADng spec. >>=20 >> Best regards, >> Yuichi > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Thu Feb 21 07:30:44 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D68C21F8E9A for ; Thu, 21 Feb 2013 07:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5hBYmRzwsiM for ; Thu, 21 Feb 2013 07:30:42 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD72D21F8E95 for ; Thu, 21 Feb 2013 07:30:42 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id wz12so3550026pbc.17 for ; Thu, 21 Feb 2013 07:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QxHOiV1UH2RQg8Mg4hGBlcpZmGysKK5r6kel6IDFNd8=; b=S3oB+Eomhoxm9L36dryoa0+HBXjbxH7jH9UT1CRcqwQJLsCZCOmdNKsPl+jYDNhZLW SvWqTfxsa1YO9MpTINLkxULQA0T37e7bw0AQTRqRhhpEzkVHlALbjvyRj41KuUSCb8TA LkX8MsrxJ0KaUuaoSeI2VtmJbTsK4fzD+K2NKQySGx3Ze0YBDHGbj/VIipz0ttMpr7CL ea3o8MIHY8NeTFUU1K5A+LdDP7nyya6ufs9YBbbBCYOOAs5EaAOE3nKcTE8Bq7GZYvIK RaIyTQw447jHR82tRDdFtVYFCuRvXmVYpbfqWqLhFGz5KVYbdrHaXzo1tilSPLoRr6zC wdTQ== MIME-Version: 1.0 X-Received: by 10.66.158.2 with SMTP id wq2mr8735575pab.113.1361460637869; Thu, 21 Feb 2013 07:30:37 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 07:30:37 -0800 (PST) In-Reply-To: References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <379DFA7A-3E9E-4624-A3BF-639F691A2886@thomasclausen.org> <50F7DDFD.8010100@hitachi.com> Date: Thu, 21 Feb 2013 16:30:37 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:30:45 -0000 I read now again, please read section 4, that it called implemetation of specification [LOADng-00], not the -06 or -08 (only from -06 is MANET). AB On 2/21/13, Jiazi Yi wrote: > > > On Feb 21, 2013, at 4:16 PM, Abdussalam Baryun > wrote: > >> I understand that the implementation interoperability tests were >> conducted according to the specification in [LOADng-00]. > > That's not true. > Before giving comments, please read related drafts first. > It was clearly called out in the interop draft, and loadng-08, > implementation status section. > > Jiazi > >> So it was >> implemented for LLNs not for MANETs, and that for future tests of same >> protocol in MANETs interoperability we will need test specification >> LOADng-06 not version 00. Do you think both will have same effects >> spec 00 and 06? >> >> AB >> >> On 1/17/13, Yuichi IGARASHI wrote: >>> Hi Abdussalam, >>> >>> We have two different independent implementations. Even in my company, >>> we had no director among implementors, because our main purpose was to >>> confirm the interoperability of LOADng spec. >>> >>> Best regards, >>> Yuichi >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From abdussalambaryun@gmail.com Thu Feb 21 07:32:44 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD1421F8EA4 for ; Thu, 21 Feb 2013 07:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEsuqL3KhSSU for ; Thu, 21 Feb 2013 07:32:40 -0800 (PST) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 788CC21F8E98 for ; Thu, 21 Feb 2013 07:32:40 -0800 (PST) Received: by mail-da0-f53.google.com with SMTP id g27so1061880dan.40 for ; Thu, 21 Feb 2013 07:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eJCCz1UPX3/eJZw5uR6AemlOWgdwXKblBfAruW+SGXQ=; b=N85MupdYdpIVMEAdCWVt8bsXUh3JXJ8Z7UdOWKOLYqdPdwdBfG4iKlRr400e8F4AMq IwKhoX/SA60tXzh0UG9JQQSPBRpGcjsqq+StUdsZY7oM2YkDt7u0jKJeGguV6j8gJFAp mF0l56BiGGEvHdzTJguL7GVMa7mDZE3RBYO0iu3qfOK0meUM2O+LfJ4VOtBJgSE8TMh4 oD/NE5NA8reg8uuk4/aWsIAcuvKZhcTDQvitxuUrrGH+bO3kkYz4SenDz05CrNfXW+u6 UhevuE0x/XPkCDuXCDdxEr/bFQ0uAa2Ugs248C4qy2d5a30W1TcYqVN/Hvqlx9u9+ljL kHUg== MIME-Version: 1.0 X-Received: by 10.67.5.193 with SMTP id co1mr60280370pad.6.1361460759960; Thu, 21 Feb 2013 07:32:39 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 07:32:39 -0800 (PST) In-Reply-To: References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <379DFA7A-3E9E-4624-A3BF-639F691A2886@thomasclausen.org> <50F7DDFD.8010100@hitachi.com> Date: Thu, 21 Feb 2013 16:32:39 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:32:44 -0000 For Router: LOADng running codes ++++++++++++++++++++++++ Sorry please read section 4> http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report-04 If I am wrong please advise, I just trying to know the facts, AB On 2/21/13, Abdussalam Baryun wrote: > I read now again, please read section 4, that it called implemetation > of specification [LOADng-00], not the -06 or -08 (only from -06 is > MANET). > > AB > On 2/21/13, Jiazi Yi wrote: >> >> >> On Feb 21, 2013, at 4:16 PM, Abdussalam Baryun >> >> wrote: >> >>> I understand that the implementation interoperability tests were >>> conducted according to the specification in [LOADng-00]. >> >> That's not true. >> Before giving comments, please read related drafts first. >> It was clearly called out in the interop draft, and loadng-08, >> implementation status section. >> >> Jiazi >> >>> So it was >>> implemented for LLNs not for MANETs, and that for future tests of same >>> protocol in MANETs interoperability we will need test specification >>> LOADng-06 not version 00. Do you think both will have same effects >>> spec 00 and 06? >>> >>> AB >>> >>> On 1/17/13, Yuichi IGARASHI wrote: >>>> Hi Abdussalam, >>>> >>>> We have two different independent implementations. Even in my company, >>>> we had no director among implementors, because our main purpose was to >>>> confirm the interoperability of LOADng spec. >>>> >>>> Best regards, >>>> Yuichi >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> > From yi.jiazi@gmail.com Thu Feb 21 07:35:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF6221F89B5 for ; Thu, 21 Feb 2013 07:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[AWL=2.685, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ulw2uE0YAlrk for ; Thu, 21 Feb 2013 07:35:07 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id A1A3821F880F for ; Thu, 21 Feb 2013 07:35:06 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id fg15so7331598wgb.13 for ; Thu, 21 Feb 2013 07:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=6Wx8Z2bLUVVITN/q+YBJ+e09w8VlwrEo+bHBDdjVwc0=; b=GouCdKMB2gxsFF6kkG+dejoXLNCRfazQo0Chg+kMihkJ6rdWAPp3+VVaBNUpeAeBnR vCPHbpv+XyTaTlISVsYj1BIzZDqFPNkstXeo7OHCxRIdF8Pt5xvqsbmt0S+GUMGwTmIR 3ohQDPi/xMjsMW7TxAWsUi213S8ZBAu/INsCOQAfK4+JMjcO3Xye86VgNmVPbzzzBHNT my3EC8vwXTvs0eqEOHW1bKHnxlW4BXsw7nvT8jwk/4VE69vlWQhPaEMlwANEZEthpkB8 dQGNECCSduuFKZtA4IlB1bNTPjSjzUIddxNehjL/UKHlt14JHbjxVpGOdrjV7+YuSQcI H68w== X-Received: by 10.194.77.129 with SMTP id s1mr42538571wjw.17.1361460905777; Thu, 21 Feb 2013 07:35:05 -0800 (PST) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id ed6sm474842wib.9.2013.02.21.07.35.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 07:35:05 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Thu, 21 Feb 2013 16:35:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5249C253-D8DB-4F9C-82B9-8771982B7D72@jiaziyi.com> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <379DFA7A-3E9E-4624-A3BF-639F691A2886@thomasclausen.org> <50F7DDFD.8010100@hitachi.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:35:08 -0000 then please keep reading section 5, 6, and 7 of loadng-interop.=20 and related section in loadng-08 Jiazi On Feb 21, 2013, at 4:30 PM, Abdussalam Baryun = wrote: > I read now again, please read section 4, that it called implemetation > of specification [LOADng-00], not the -06 or -08 (only from -06 is > MANET). >=20 > AB > On 2/21/13, Jiazi Yi wrote: >>=20 >>=20 >> On Feb 21, 2013, at 4:16 PM, Abdussalam Baryun = >> wrote: >>=20 >>> I understand that the implementation interoperability tests were >>> conducted according to the specification in [LOADng-00]. >>=20 >> That's not true. >> Before giving comments, please read related drafts first. >> It was clearly called out in the interop draft, and loadng-08, >> implementation status section. >>=20 >> Jiazi >>=20 >>> So it was >>> implemented for LLNs not for MANETs, and that for future tests of = same >>> protocol in MANETs interoperability we will need test specification >>> LOADng-06 not version 00. Do you think both will have same effects >>> spec 00 and 06? >>>=20 >>> AB >>>=20 >>> On 1/17/13, Yuichi IGARASHI wrote: >>>> Hi Abdussalam, >>>>=20 >>>> We have two different independent implementations. Even in my = company, >>>> we had no director among implementors, because our main purpose was = to >>>> confirm the interoperability of LOADng spec. >>>>=20 >>>> Best regards, >>>> Yuichi >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 From hrogge@googlemail.com Thu Feb 21 07:36:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E38821F8EA2 for ; Thu, 21 Feb 2013 07:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGOeVNOF8ec3 for ; Thu, 21 Feb 2013 07:36:05 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 4873A21F8E8C for ; Thu, 21 Feb 2013 07:36:05 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id m4so6989940lbo.0 for ; Thu, 21 Feb 2013 07:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5rtD86o6vhOq0QK9+dBfS3xRxBM2NHIQs18oVGUAMsM=; b=ZPeXkC8NAfH5aX2k9/q0SuzHtZPrd5JRb6o0eI4dKwYZvZ9OJqPKerclgtOdb6TSp2 jr7FxvEVZVBE9mP304cy6lUM4hBOX5l03joD3XG0Gy7/BoiQSaFXykCtgBf8WOS33Q1C sDo420Diycc+jw5NS7Zv63uMvLx/2s+LQu7Wz9ESHHJFNtsNJWwt7WGpkd5o8s/i7G1P Q+SqDu3MWA81x74NoK5DzCGmfNE8fuBN1MmbSaAUsF2LVgaUIatIIYOO9fZFaPsOgW78 1bx4m405PY7wbdM1LGHnyww4yCrTFU25n5yoj++/x0XP2JuT9IzDmvlBCNqY1AKwZ5rD pZXA== X-Received: by 10.152.133.67 with SMTP id pa3mr21257968lab.44.1361460963692; Thu, 21 Feb 2013 07:36:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Thu, 21 Feb 2013 07:35:43 -0800 (PST) In-Reply-To: References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <379DFA7A-3E9E-4624-A3BF-639F691A2886@thomasclausen.org> <50F7DDFD.8010100@hitachi.com> From: Henning Rogge Date: Thu, 21 Feb 2013 16:35:43 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:36:06 -0000 On Thu, Feb 21, 2013 at 4:32 PM, Abdussalam Baryun wrote: > For Router: LOADng running codes > ++++++++++++++++++++++++ > > Sorry please read section 4> > > http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report-04 > > If I am wrong please advise, I just trying to know the facts, Have a look at the summary of chapter 4... its called "Interop 01: Yokohama, Japan, October 2011" Now look further down to chapter 7... its called "Interop 04: Vancouver, Canada, August, 2011" Notice that EACH chapter has its own Versionof LOADng that was tested... see chapter 4.1, 5.1, 6.1 and 7.1. Henning -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From abdussalambaryun@gmail.com Thu Feb 21 07:39:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DD321F8E5D for ; Thu, 21 Feb 2013 07:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C616+KRSm3b0 for ; Thu, 21 Feb 2013 07:39:18 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 480F421F8E46 for ; Thu, 21 Feb 2013 07:39:18 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id bh2so4832412pad.30 for ; Thu, 21 Feb 2013 07:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=abTm9byNfOpW5v+sD3EhlliUY9/wvsoDMpRG+rbFQ2c=; b=WbLtr9G0uZBp4UppQb4C+NI4oF8gIx6hsdYYQNEg6QrjkWYoJDv8alaeJT2hjilZIu 02ZCjBxyZHoGRv7ZNEtCXeDc/h0UzLxn7rAnTnofEUqpPh3bE1rr7IMg6rikuNQZI8e6 0khG3KvjX7f7AM4I8DLKyLSHXCJH5LSony3ZJQQvcmk/csjiz+HtDec7NyO9bauxusqt yJgRTQkSWsfOMYtbVUQz2+6clQRoMiwg9B452aeSKtpZOVY4qelCtNe2P5hKrbfrz1bS 03Fbs7EwKFdPVCK/UVhRCWIAR0nmsSUjnm1NniO8foX/Whgd+g3hVLhQQJhPYVzgbBWm q53g== MIME-Version: 1.0 X-Received: by 10.68.204.68 with SMTP id kw4mr54882365pbc.113.1361461157829; Thu, 21 Feb 2013 07:39:17 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 07:39:17 -0800 (PST) In-Reply-To: <3969D96F-B639-4DDF-A7F7-66067B383551@um.es> References: <51263342.1080207@fkie.fraunhofer.de> <3969D96F-B639-4DDF-A7F7-66067B383551@um.es> Date: Thu, 21 Feb 2013 16:39:17 +0100 Message-ID: From: Abdussalam Baryun To: =?ISO-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:39:19 -0000 I agree with your advise, we will need to look into the available DYMO implementations and use the best for the new reactive protocol, I hope the authors can give us advise on this important matter, As I agree with one participant's input that IETF is about running code, AB On 2/21/13, Francisco Javier Ros Mu=F1oz wrote: > Hi Henning, > > A long time ago I wrote an implementation that is mostly compliant with > draft dymo-04, and it incorporates some features from dymo-05. Therefore, > I'm afraid that the codebase is far from being compliant with aodvv2-00. > Unfortunately, I have no time to maintain this code any more. However it = is > publicly available, so if anyone is interested in updating it please go > ahead (I don't know whether this is better than starting from scratch). > > DYMOUM: > http://masimum.inf.um.es/fjrm/?page_id=3D126 > > You can find a list of other implementations (AFAIK also outdated) in > http://www.ianchak.com/dymo/ > > Best, > fran > > El 21/02/2013, a las 15:46, Henning Rogge escribi=F3: > >> On 02/21/2013 03:42 PM, Abdussalam Baryun wrote: >>> Hi Jiazi, >>> >>> Yes there are many implementation but not presented well, I think the >>> authors have an implementation, and also many researchers have tested >>> the old DYMO, >> >> This is a very bold statement... do you have some evidence for this? >> >> I remember a few people trying to track down a working AODV implementati= on >> and failing. >> >> But I never have seen a DYMO implementation. >> >> If someone on this list HAS an implementation, I would like to hear abou= t >> it. >> >> Henning Rogge >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > -- > Francisco J. Ros, PhD > Dept. of Information and Communications Engineering > University of Murcia, Murcia (Spain) > http://masimum.inf.um.es/fjrm/ > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From yi.jiazi@gmail.com Thu Feb 21 07:40:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E998621F8EB4 for ; Thu, 21 Feb 2013 07:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.118 X-Spam-Level: **** X-Spam-Status: No, score=4.118 tagged_above=-999 required=5 tests=[AWL=-3.072, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_FR=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATQWUOC9GBWK for ; Thu, 21 Feb 2013 07:40:47 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 181CA21F8EAD for ; Thu, 21 Feb 2013 07:40:46 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so7866659wey.35 for ; Thu, 21 Feb 2013 07:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=vk8lf3sdMsDV4pogoOvb5lt5qYEKVLB6vQSZ/3v4WTo=; b=OW6Id0b4P9K0wGuXrWmTQzkqi8VFM+tp7tos4YRBjoZpsT1SgVvgzX6LHUIlQhlZh0 zVJqa18gTKFy1ajRpE6TvgAlrk9nyHQUiEcWWzRPF15aXpRVBpZBE+R3XdoF35dRYUO6 qXOUqBDGX1YPmSSBf5NRByJ+FUBwVnQtFTfxFN8ea/3DXakV0zd6Z2JqMv3kcy4KRUeY fi4clTLUrrcrDCYQlTuCuBcp8057CaCcMD7lpI/0VqCo8DTo7tPYQd/Nzw6UlnSf4HJU 1ejUqQi4HnzlmtYbJgVlH7vZOtdab/vdfZLkZ36dssOX4yUIXmBovMPKxcIlDVFzsZ38 YpMA== X-Received: by 10.194.120.169 with SMTP id ld9mr4082665wjb.24.1361461246278; Thu, 21 Feb 2013 07:40:46 -0800 (PST) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id fv2sm37595275wib.6.2013.02.21.07.40.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 07:40:45 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Thu, 21 Feb 2013 16:40:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C036429-1FF6-4384-BBF9-4E300E8D7415@jiaziyi.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:40:48 -0000 On Feb 21, 2013, at 4:24 PM, Abdussalam Baryun = wrote: > Hi Jiazi, >=20 > I know that DYMO implements are old, (hopfully developed to new > AODVv2) I already stated that, just wanted to answer to your question. > Regarding LOADng it was an implementation for LLNs not for MANETs. That's not true.=20 > So > far there is no implementation that uses the RFC5498, the using of ports is just a matter of setting one parameter in the = code.=20 Jiazi > which I am > interested in as OLSRv2 is using, >=20 > AB >=20 > On 2/21/13, Jiazi Yi wrote: >> AB, >>=20 >> I'm aware of some dymo implementation in academic conferences. = However, that >> was quite long time ago. DYMO had very big changes since its -21. >>=20 >> When I'm saying implementations, I actually mean: >> o It's complaint to the latest version of the document >> o It's publicly known (not necessarily open source) >>=20 >> For example, when I'm saying LOADng has 4 publicly known = implementations, it >> means: >> o It's updated to the latest (or very recent) revision >> o Those four are publicly known, in the interop draft, and = different >> scientific publications. I know there are several others, but at this = point, >> I can't disclose them (so they are not counted into 4 known >> implementations). >>=20 >> best >>=20 >> Jiazi >>=20 >> On Feb 21, 2013, at 3:42 PM, Abdussalam Baryun = >> wrote: >>=20 >>> Hi Jiazi, >>>=20 >>> Yes there are many implementation but not presented well, I think = the >>> authors have an implementation, and also many researchers have = tested >>> the old DYMO, >>>=20 >>> AB >>> ++ >>> Sub: Re: [manet] Why the WG Reactive Protocol to be Compatible with >>> another? >>> On 2/20/13, Jiazi Yi wrote: >>>> I have no idea if there is DYMO implementation, >>>>=20 >>> http://www.ietf.org/mail-archive/web/manet/current/msg14948.html >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 From abdussalambaryun@gmail.com Thu Feb 21 07:46:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F6221F8E97 for ; Thu, 21 Feb 2013 07:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z10R23sYBK9l for ; Thu, 21 Feb 2013 07:46:12 -0800 (PST) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEB121F8E6A for ; Thu, 21 Feb 2013 07:46:12 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id uo15so3521277pbc.5 for ; Thu, 21 Feb 2013 07:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=C5EE+LGwGOn4rZcnHvCbBz0IOmRvX7h542GgchCJY+Y=; b=Hbb4Ip83rTaOVHSY1H4F3zzuWZAierGLS8Xpt2UP8rfbw7j9W/Q1x7g7ogeAC5PKHW fTdri5qOadALJf/BkgOxyaV/sTe6g/mjQXQf5da7m5flRicZ/47VHkva54HBsw9sljDH T2yDRuVPFVnb0C/e8fjNQdKEVUQ4wwT9IreMWHlIuGsRa/XsVKegOpFy3PsUMvLOw04U rxXgXCy906cH/Sg7H0rrFC3E1QdOpHWatOJ5rwircnRy0CNZ7zEQuGAUwxI/mqtHkBHk N3BUXjOXdXFyxynof87MuV2SEr8hyF0VZzm8UhRQ0CVhC9Q2nHSbw14Ys3Im4FLbrCpv RDxw== MIME-Version: 1.0 X-Received: by 10.66.13.74 with SMTP id f10mr8938872pac.202.1361461566089; Thu, 21 Feb 2013 07:46:06 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 07:46:05 -0800 (PST) In-Reply-To: <5249C253-D8DB-4F9C-82B9-8771982B7D72@jiaziyi.com> References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <379DFA7A-3E9E-4624-A3BF-639F691A2886@thomasclausen.org> <50F7DDFD.8010100@hitachi.com> <5249C253-D8DB-4F9C-82B9-8771982B7D72@jiaziyi.com> Date: Thu, 21 Feb 2013 16:46:05 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:46:13 -0000 Ok, thanks, so does the implementations use RFC5498, please advise, AB On 2/21/13, Jiazi Yi wrote: > then please keep reading section 5, 6, and 7 of loadng-interop. > and related section in loadng-08 > > Jiazi > From ietf@thomasclausen.org Thu Feb 21 07:54:59 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4190821F8E77 for ; Thu, 21 Feb 2013 07:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhO4Ri65DyYU for ; Thu, 21 Feb 2013 07:54:58 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 98DF421F8E68 for ; Thu, 21 Feb 2013 07:54:58 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 494A2A67AE for ; Thu, 21 Feb 2013 07:54:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CDA371C08E7; Thu, 21 Feb 2013 07:54:57 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.149.136.124] (unknown [37.160.27.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 239471C07D0; Thu, 21 Feb 2013 07:54:52 -0800 (PST) References: <50F53CC2.6040205@fkie.fraunhofer.de> <003601cdf453$c2736de0$475a49a0$@ndzh.com> <68E4589B-5A28-401F-9338-C4D4081058F4@thomasclausen.org> <379DFA7A-3E9E-4624-A3BF-639F691A2886@thomasclausen.org> <50F7DDFD.8010100@hitachi.com> <5249C253-D8DB-4F9C-82B9-8771982B7D72@jiaziyi.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B143) From: Thomas Heide Clausen Date: Thu, 21 Feb 2013 16:54:47 +0100 To: Abdussalam Baryun Cc: "manet@ietf.org" Subject: Re: [manet] Router's Implemetation and Running Code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:54:59 -0000 Yes --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 On 21 f=C3=A9vr. 2013, at 16:46, Abdussalam Baryun wrote: > Ok, thanks, so does the implementations use RFC5498, >=20 > please advise, >=20 > AB >=20 > On 2/21/13, Jiazi Yi wrote: >> then please keep reading section 5, 6, and 7 of loadng-interop. >> and related section in loadng-08 >>=20 >> Jiazi > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Thu Feb 21 08:47:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772E721F8E89 for ; Thu, 21 Feb 2013 08:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+lrjhRz-930 for ; Thu, 21 Feb 2013 08:47:18 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 0C72921F8E74 for ; Thu, 21 Feb 2013 08:47:17 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id bh2so4896298pad.16 for ; Thu, 21 Feb 2013 08:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=54VdTEP43Ktdk5cuurhy4A6SeJULVTHy5Dr6IqjGTfM=; b=qBmah/Z9O9uGd+rCLuKZQAIN2TzAo65/LK59jvUWF5fdf1Xjwn9Ikc8iEeUeiHylL1 WADT0pBKL1MIfbLiMPTBS8DwT3o2X9N2jfvJgfhVAd0rn7FZ9uSQhs4V2AzoTLIFx3Gs 4mlWba9IlbuFTaGLfqmIvHLBmAtmQk7ASMTH6cgDNOQ4E+HVhIthHBO6CU0QjSpX3tBd jqUgeYMxbA1VvLU6qWzslt5PG5P5KdeI2vzTSnH2AwVb+ueFkIGfuJxpdN50WIu0npkk svnATbuYcb6p+MmPuiWbXMz5COc3I5z3bjbbW94e5AFhDI9OJJMKhiSIUfBgqjwqi7YL BgxQ== MIME-Version: 1.0 X-Received: by 10.68.245.229 with SMTP id xr5mr55097948pbc.163.1361465237770; Thu, 21 Feb 2013 08:47:17 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 08:47:17 -0800 (PST) In-Reply-To: References: <51263342.1080207@fkie.fraunhofer.de> <3969D96F-B639-4DDF-A7F7-66067B383551@um.es> Date: Thu, 21 Feb 2013 17:47:17 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:47:18 -0000 As reply to [*] I want more to discuss the DYMO implementations, interoperability and running code than to discuss comparison with others, [*] http://www.ietf.org/mail-archive/web/manet/current/msg14951.html AB On 2/21/13, Abdussalam Baryun wrote: > I agree with your advise, we will need to look into the available DYMO > implementations and use the best for the new reactive protocol, I hope > the authors can give us advise on this important matter, > > As I agree with one participant's input that IETF is about running code, > > AB > From c.chauvenet@watteco.com Thu Feb 21 08:56:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C8C21F8EB2 for ; Thu, 21 Feb 2013 08:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eur07dPQnLfS for ; Thu, 21 Feb 2013 08:56:17 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 33E3121F8EB7 for ; Thu, 21 Feb 2013 08:56:17 -0800 (PST) Received: from mail104-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Feb 2013 16:56:16 +0000 Received: from mail104-ch1 (localhost [127.0.0.1]) by mail104-ch1-R.bigfish.com (Postfix) with ESMTP id 9834F2E016C; Thu, 21 Feb 2013 16:56:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.85; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0511HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371Ic89bh1431Jc85dhzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dh18c673h84d07hz2dh2a8h668h839hbe3hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1155h) Received: from mail104-ch1 (localhost.localdomain [127.0.0.1]) by mail104-ch1 (MessageSwitch) id 1361465774590471_11262; Thu, 21 Feb 2013 16:56:14 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail104-ch1.bigfish.com (Postfix) with ESMTP id 83C472C0049; Thu, 21 Feb 2013 16:56:14 +0000 (UTC) Received: from AMXPRD0511HT004.eurprd05.prod.outlook.com (157.56.250.85) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Feb 2013 16:56:05 +0000 Received: from AMXPRD0511MB552.eurprd05.prod.outlook.com ([169.254.3.138]) by AMXPRD0511HT004.eurprd05.prod.outlook.com ([10.242.10.165]) with mapi id 14.16.0263.000; Thu, 21 Feb 2013 16:56:02 +0000 From: C Chauvenet To: Jiazi Yi Thread-Topic: [manet] DYMO Implementation Thread-Index: AQHOEEGoMiSEjOeiEkmR3+A1nkZnJZiEa/kAgAAChACAAAScAIAAFQuA Date: Thu, 21 Feb 2013 16:56:02 +0000 Message-ID: <42D3E931-7278-4C21-AB7E-5CBD92847500@watteco.com> References: <7C036429-1FF6-4384-BBF9-4E300E8D7415@jiaziyi.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.67.132] Content-Type: multipart/alternative; boundary="_000_42D3E93172784C21AB7E5CBD92847500wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "manet@ietf.org" Subject: Re: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:56:18 -0000 --_000_42D3E93172784C21AB7E5CBD92847500wattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI, Le 21 f=E9vr. 2013 =E0 16:40, Jiazi Yi a =E9crit : On Feb 21, 2013, at 4:24 PM, Abdussalam Baryun > wrote: Hi Jiazi, I know that DYMO implements are old, (hopfully developed to new AODVv2) I already stated that, just wanted to answer to your question. Regarding LOADng it was an implementation for LLNs not for MANETs. That's not true. Maybe AB had this feeling when reading this previously quoted mail ? : From: Ulrich Herberg > Date: November 29, 2011 7:00:08 PM GMT+01:00 Subject: DYMO Joe, Stan, During the IETF, Thomas mentioned that we are working on a draft, called "L= OADng" (draft-clausen-lln-loadng). The draft specifies a reactive routing p= rotocol, mainly intended for low-power and lossy networks (LLNs). C=E9dric. So far there is no implementation that uses the RFC5498, the using of ports is just a matter of setting one parameter in the code. Jiazi which I am interested in as OLSRv2 is using, AB On 2/21/13, Jiazi Yi > wrote: AB, I'm aware of some dymo implementation in academic conferences. However, tha= t was quite long time ago. DYMO had very big changes since its -21. When I'm saying implementations, I actually mean: o It's complaint to the latest version of the document o It's publicly known (not necessarily open source) For example, when I'm saying LOADng has 4 publicly known implementations, i= t means: o It's updated to the latest (or very recent) revision o Those four are publicly known, in the interop draft, and different scientific publications. I know there are several others, but at this point= , I can't disclose them (so they are not counted into 4 known implementations). best Jiazi On Feb 21, 2013, at 3:42 PM, Abdussalam Baryun > wrote: Hi Jiazi, Yes there are many implementation but not presented well, I think the authors have an implementation, and also many researchers have tested the old DYMO, AB ++ Sub: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? On 2/20/13, Jiazi Yi > wrote: I have no idea if there is DYMO implementation, http://www.ietf.org/mail-archive/web/manet/current/msg14948.html _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_42D3E93172784C21AB7E5CBD92847500wattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable HI, 

Le 21 f=E9vr. 2013 =E0 16:40, Jiazi Yi a =E9crit :



On Feb 21, 2013, at 4:24 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Jiazi,

I know that DYMO implements are old, (hopfully de= veloped to new
AODVv2) I already stated that, just wanted to ans= wer to your question.
Regarding LOADng it was an implementation for LLN= s not for MANETs.

That's not true.

Maybe AB had this feeling when reading this previously quoted mai= l ? : 

From: Ulrich Herberg <ulrich@herberg.name>
Date: November 29, 2011 7:00:08 PM GMT+01:00<= br>
Subject: DYMO
Joe, Stan,

During the IETF, Thomas mentioned that we are wor= king on a draft, called "LOADng" (draft-clausen-lln-loadng). The = draft specifies a reactive routing protocol, mainly intended for low-power = and lossy networks (LLNs). 


C=E9dric. 


So
far there is no implementation that uses the RFC5= 498,

the using of ports is just a matter of setting one parameter in the code. <= br>
Jiazi

which I am
interested in as OLSRv2 is using,

AB

On 2/21/13, Jiazi Yi <ietf@jiaziyi.com> wrote:
AB,

I'm aware of some dymo implementation in academic= conferences. However, that
was quite long time ago. DYMO had very big change= s since its -21.

When I'm saying implementations, I actually mean:=
o It's complaint to the latest version of the document
o It's publicly known (not necessarily open source)

For example, when I'm saying LOADng has 4 publicl= y known implementations, it
means:
o It's updated to the latest (or very recent) revision
o Those four are publicly known, in the interop draft, and d= ifferent
scientific publications. I know there are several= others, but at this point,
I can't disclose them (so they are not counted in= to 4 known
implementations).

best

Jiazi

On Feb 21, 2013, at 3:42 PM, Abdussalam Baryun &l= t;abdussalambaryun@gmail.com<= /a>>
wrote:

Hi Jiazi,

Yes there are many implementation but not present= ed well, I think the
authors have an implementation, and also many res= earchers have tested
the old DYMO,

AB
++
Sub: Re: [manet] Why the WG Reactive Protocol to = be Compatible with
another?
On 2/20/13, Jiazi Yi <ietf@jiaziyi.com> wrote:
I have no idea if there is DYMO implementation,

http://www.ietf.org/mail-archive/web/manet/curr= ent/msg14948.html
_______________________________________________
manet mailing list
manet@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/manet



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


--_000_42D3E93172784C21AB7E5CBD92847500wattecocom_-- From yi.jiazi@gmail.com Thu Feb 21 09:14:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807C221F8EFF for ; Thu, 21 Feb 2013 09:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.63 X-Spam-Level: **** X-Spam-Status: No, score=4.63 tagged_above=-999 required=5 tests=[AWL=-2.560, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_FR=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNSJD1VRVjOK for ; Thu, 21 Feb 2013 09:14:51 -0800 (PST) Received: from mail-wi0-x229.google.com (wi-in-x0229.1e100.net [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id D242321F8F18 for ; Thu, 21 Feb 2013 09:14:49 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so1066903wie.4 for ; Thu, 21 Feb 2013 09:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=TdLISXWMPn77SpVhG5gObq+uNjjVNb8swWc4edm04ag=; b=PUAD89cYtmqdKpyseIeBBGVfJP/egxy8itKTUId1ZcGQtQFDVREqwCioFKFl6BRQGG P2WlU7ZGGhxgorQeVEu7XWt8lXgphRvA/EoCW+GBjPdsZYW+pRnqxRPphrsJ9rgAVwel oRW/uJdeNHwggE67fRpAvr4FrVLH6uCRfpSrJ6bpd4fXsuClr9cCqKJtW8rv8BacAmff UmPo+ojGa8LBzZJK9o2BotbcYCcJmXWE4tQ6ajYTtUCviRdxI/OFp3VMPjWCR8Pbovao klyFI1nbiE2G1HfXkA/Hq7WoNSbKbbbLs0Tg4uIiFZyjNio66ZD91gfy+MeDCocEvmtL emtg== X-Received: by 10.194.9.166 with SMTP id a6mr43453832wjb.2.1361466888946; Thu, 21 Feb 2013 09:14:48 -0800 (PST) Received: from 193.55.177-98.saclay.inria.fr ([193.55.177.98]) by mx.google.com with ESMTPS id j4sm36230162wiz.10.2013.02.21.09.14.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 09:14:48 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: <42D3E931-7278-4C21-AB7E-5CBD92847500@watteco.com> Date: Thu, 21 Feb 2013 18:14:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <03281492-43C0-4BED-A261-66D54F487FD6@jiaziyi.com> References: <7C036429-1FF6-4384-BBF9-4E300E8D7415@jiaziyi.com> <42D3E931-7278-4C21-AB7E-5CBD92847500@watteco.com> To: C Chauvenet X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:14:51 -0000 Hi,=20 On Feb 21, 2013, at 5:56 PM, C Chauvenet = wrote: > HI,=20 >=20 > Le 21 f=E9vr. 2013 =E0 16:40, Jiazi Yi a =E9crit : >=20 >>=20 >>=20 >> On Feb 21, 2013, at 4:24 PM, Abdussalam Baryun = wrote: >>=20 >>> Hi Jiazi, >>>=20 >>> I know that DYMO implements are old, (hopfully developed to new >>> AODVv2) I already stated that, just wanted to answer to your = question. >>> Regarding LOADng it was an implementation for LLNs not for MANETs. >>=20 >> That's not true.=20 >=20 > Maybe AB had this feeling when reading this previously quoted mail ? :=20= Then this *feeling* is wrong.=20 Jiazi >=20 >> From: Ulrich Herberg >> Date: November 29, 2011 7:00:08 PM GMT+01:00 >> Subject: DYMO >> Joe, Stan, >>=20 >> During the IETF, Thomas mentioned that we are working on a draft, = called "LOADng" (draft-clausen-lln-loadng). The draft specifies a = reactive routing protocol, mainly intended for low-power and lossy = networks (LLNs).=20 >=20 >=20 > C=E9dric.=20 >=20 >>=20 >>> So >>> far there is no implementation that uses the RFC5498, >>=20 >> the using of ports is just a matter of setting one parameter in the = code.=20 >>=20 >> Jiazi >>=20 >>> which I am >>> interested in as OLSRv2 is using, >>>=20 >>> AB >>>=20 >>> On 2/21/13, Jiazi Yi wrote: >>>> AB, >>>>=20 >>>> I'm aware of some dymo implementation in academic conferences. = However, that >>>> was quite long time ago. DYMO had very big changes since its -21. >>>>=20 >>>> When I'm saying implementations, I actually mean: >>>> o It's complaint to the latest version of the document >>>> o It's publicly known (not necessarily open source) >>>>=20 >>>> For example, when I'm saying LOADng has 4 publicly known = implementations, it >>>> means: >>>> o It's updated to the latest (or very recent) revision >>>> o Those four are publicly known, in the interop draft, and = different >>>> scientific publications. I know there are several others, but at = this point, >>>> I can't disclose them (so they are not counted into 4 known >>>> implementations). >>>>=20 >>>> best >>>>=20 >>>> Jiazi >>>>=20 >>>> On Feb 21, 2013, at 3:42 PM, Abdussalam Baryun = >>>> wrote: >>>>=20 >>>>> Hi Jiazi, >>>>>=20 >>>>> Yes there are many implementation but not presented well, I think = the >>>>> authors have an implementation, and also many researchers have = tested >>>>> the old DYMO, >>>>>=20 >>>>> AB >>>>> ++ >>>>> Sub: Re: [manet] Why the WG Reactive Protocol to be Compatible = with >>>>> another? >>>>> On 2/20/13, Jiazi Yi wrote: >>>>>> I have no idea if there is DYMO implementation, >>>>>>=20 >>>>> http://www.ietf.org/mail-archive/web/manet/current/msg14948.html >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From ulrich@herberg.name Thu Feb 21 13:15:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2485C21F8E90 for ; Thu, 21 Feb 2013 13:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.858 X-Spam-Level: X-Spam-Status: No, score=-2.858 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6k5e9WQhJ4lO for ; Thu, 21 Feb 2013 13:15:50 -0800 (PST) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id F208621F8E62 for ; Thu, 21 Feb 2013 13:15:49 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id ox1so8469803veb.27 for ; Thu, 21 Feb 2013 13:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3fe4U1cLR6Qf7g8t2VhPnR6sQoejQ/lNjKBnag24lKk=; b=xI9kaFIsnXohWyDJE76PBf/DwUrxC/TmrdzIfcDNHC85V1ACc+HxZiOw1apvLitf8u U+DhKXMaPB2os/cYQs36bUkggAEcwWqEfb4kaCKRq5zzPnq+kDQr5jaI/ZO0eQgPdBTf aGuHicAfA3xh0T+N3CI9RbZ2fbrgIS777FY/w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=3fe4U1cLR6Qf7g8t2VhPnR6sQoejQ/lNjKBnag24lKk=; b=lUUPvzkWtTxgZeh/42Huhr0/dnmaw/eJh3ZKB9I6ZI5i3f5s6xPPXSWl4wAGRzguWf uDyr/9k77bRNW+En0s2Qs9Eq4gEAMsrAeZgSaKIhqdEEdkdUxxk1i7C2G1g1EhumbAgU 59NYi1NZyLvVfZxqv2aPI/+fmHGSRlgS2gDYjJFVqBYYYLHwGOSbBff+XPP+2HPrlRGm EiD85hQjZtDIxn6JTvxHFKZ5mQCmTkECkNJG7J48KjAet/RQRt3DW1HWWHRQpbJo8ufd +wEJugFzKqeW0pxxRt7ccCZADTBy4hcKHsxjlQGBTrWJ+jicmKzymJTrK3NxhVIIx/lB 9MoQ== MIME-Version: 1.0 X-Received: by 10.58.229.197 with SMTP id ss5mr34594218vec.14.1361481349311; Thu, 21 Feb 2013 13:15:49 -0800 (PST) Received: by 10.220.107.7 with HTTP; Thu, 21 Feb 2013 13:15:49 -0800 (PST) In-Reply-To: <42D3E931-7278-4C21-AB7E-5CBD92847500@watteco.com> References: <7C036429-1FF6-4384-BBF9-4E300E8D7415@jiaziyi.com> <42D3E931-7278-4C21-AB7E-5CBD92847500@watteco.com> Date: Thu, 21 Feb 2013 13:15:49 -0800 Message-ID: From: Ulrich Herberg To: C Chauvenet Content-Type: multipart/alternative; boundary=047d7bd6c31031fc6704d64294f4 X-Gm-Message-State: ALoCoQnfOKUt7qkGb6aQU4ok2xg0dUZipHP8y7TM1LWdAVOXLsAlV1W9rkS1fAqammXIDsOXb2xK Cc: "manet@ietf.org" Subject: Re: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 21:15:51 -0000 --047d7bd6c31031fc6704d64294f4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable C=E9dric, do we honestly want to start this discussion about LLNs vs MANET again? Personally, I don't want to. AB, I don't know how often we have to repeat this on the list: The LOADng implementations tested in the interop tests are conform with the latest LOADng revision and use RFC5444/5498. Best regards Ulrich On Thu, Feb 21, 2013 at 8:56 AM, C Chauvenet wrote= : > HI, > > Le 21 f=E9vr. 2013 =E0 16:40, Jiazi Yi a =E9crit : > > > > On Feb 21, 2013, at 4:24 PM, Abdussalam Baryun > wrote: > > Hi Jiazi, > > > I know that DYMO implements are old, (hopfully developed to new > > AODVv2) I already stated that, just wanted to answer to your question. > > Regarding LOADng it was an implementation for LLNs not for MANETs. > > > That's not true. > > > Maybe AB had this feeling when reading this previously quoted mail ? : > > From: Ulrich Herberg > > Date: November 29, 2011 7:00:08 PM GMT+01:00 > > Subject: DYMO > > Joe, Stan, > > > During the IETF, Thomas mentioned that we are working on a draft, called > "LOADng" (draft-clausen-lln-loadng). The draft specifies a reactive routi= ng > protocol, mainly intended for low-power and lossy networks (LLNs). > > > > C=E9dric. > > > So > > far there is no implementation that uses the RFC5498, > > > the using of ports is just a matter of setting one parameter in the code. > > Jiazi > > which I am > > interested in as OLSRv2 is using, > > > AB > > > On 2/21/13, Jiazi Yi wrote: > > AB, > > > I'm aware of some dymo implementation in academic conferences. However, > that > > was quite long time ago. DYMO had very big changes since its -21. > > > When I'm saying implementations, I actually mean: > > o It's complaint to the latest version of the document > > o It's publicly known (not necessarily open source) > > > For example, when I'm saying LOADng has 4 publicly known > implementations, it > > means: > > o It's updated to the latest (or very recent) revision > > o Those four are publicly known, in the interop draft, and different > > scientific publications. I know there are several others, but at this > point, > > I can't disclose them (so they are not counted into 4 known > > implementations). > > > best > > > Jiazi > > > On Feb 21, 2013, at 3:42 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> > > wrote: > > > Hi Jiazi, > > > Yes there are many implementation but not presented well, I think the > > authors have an implementation, and also many researchers have tested > > the old DYMO, > > > AB > > ++ > > Sub: Re: [manet] Why the WG Reactive Protocol to be Compatible with > > another? > > On 2/20/13, Jiazi Yi wrote: > > I have no idea if there is DYMO implementation, > > > http://www.ietf.org/mail-archive/web/manet/current/msg14948.html > > _______________________________________________ > > 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 > > --047d7bd6c31031fc6704d64294f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable C=E9dric,

do we honestly want to start this discussion about LLNs vs= MANET again? Personally, I don't want to.

AB, I don't know = how often we have to repeat this on the list: The LOADng implementations te= sted in the interop tests are conform with the latest LOADng revision and u= se RFC5444/5498.

Best regards
Ulrich


On Thu, Fe= b 21, 2013 at 8:56 AM, C Chauvenet <c.chauvenet@watteco.com><= /span> wrote:
HI,=A0

Le 21 f=E9vr. 2013 =E0 16:40, Jiazi Yi a =E9crit :



On Feb 21, 2013, at 4:24 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> = wrote:

Hi Jiazi,

I know that DYMO implements are old, (hopfully de= veloped to new
AODVv2) I already stated that, just wanted to ans= wer to your question.
Regarding LOADng it was an implementation for LLN= s not for MANETs.

That's not true.

Maybe AB had this feeling when reading this previously=A0quoted = mail ? :=A0

From: Ulrich Herberg <ulrich@herberg.name>
Date: November 29, 2011 7:00:08 PM GMT+01:00
Subject: DYMO
Joe, Stan,

During the IETF, Thomas mentioned that we are wor= king on a draft, called "LOADng" (draft-clausen-lln-loadng). The = draft specifies a reactive routing protocol, mainly intended for low-power = and lossy networks (LLNs).=A0


C=E9dric.=A0


So
far there is no implementation that uses the RFC5= 498,

the using of ports is just a matter of setting one parameter in the code. <= br>
Jiazi

which I am
interested in as OLSRv2 is using,

AB

On 2/21/13, Jiazi Yi <ietf@jiaziyi.com> wrote:
AB,

I'm aware of some dymo implementation in acad= emic conferences. However, that
was quite long time ago. DYMO had very big change= s since its -21.

When I'm saying implementations, I actually m= ean:
o It&= #39;s complaint to the latest version of the document
o It&= #39;s publicly known (not necessarily open source)

For example, when I'm saying LOADng has 4 pub= licly known implementations, it
means:
o It&= #39;s updated to the latest (or very recent) revision
o Tho= se four are publicly known, in the interop draft, and different
scientific publications. I know there are several= others, but at this point,
I can't disclose them (so they are not counte= d into 4 known
implementations).

best

Jiazi

On Feb 21, 2013, at 3:42 PM, Abdussalam Baryun &l= t;abdussala= mbaryun@gmail.com>
wrote:

Hi Jiazi,

Yes there are many implementation but not present= ed well, I think the
authors have an implementation, and also many res= earchers have tested
the old DYMO,

AB
++
Sub: Re: [manet] Why the WG Reactive Protocol to = be Compatible with
another?
On 2/20/13, Jiazi Yi <ietf@jiaziyi.com> wrote:
I have no idea if there is DYMO implementation,

http://www.ietf.org/mail-arch= ive/web/manet/current/msg14948.html
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



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



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


--047d7bd6c31031fc6704d64294f4-- From c.chauvenet@watteco.com Thu Feb 21 13:42:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320A921E8034 for ; Thu, 21 Feb 2013 13:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+wcaiMKgu9z for ; Thu, 21 Feb 2013 13:42:06 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id E972E21E8039 for ; Thu, 21 Feb 2013 13:42:05 -0800 (PST) Received: from mail227-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Feb 2013 21:42:05 +0000 Received: from mail227-va3 (localhost [127.0.0.1]) by mail227-va3-R.bigfish.com (Postfix) with ESMTP id 3EBEBA80224; Thu, 21 Feb 2013 21:42:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.85; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0511HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI98dI9371Ic89bh1431Jc85dh1418Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dh18c673h84d07hz2dh2a8h668h839hbe3hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1155h) Received: from mail227-va3 (localhost.localdomain [127.0.0.1]) by mail227-va3 (MessageSwitch) id 136148292258236_6901; Thu, 21 Feb 2013 21:42:02 +0000 (UTC) Received: from VA3EHSMHS045.bigfish.com (unknown [10.7.14.252]) by mail227-va3.bigfish.com (Postfix) with ESMTP id 0BB4E6C0067; Thu, 21 Feb 2013 21:42:02 +0000 (UTC) Received: from AMXPRD0511HT001.eurprd05.prod.outlook.com (157.56.250.85) by VA3EHSMHS045.bigfish.com (10.7.99.55) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Feb 2013 21:42:00 +0000 Received: from AMXPRD0511MB552.eurprd05.prod.outlook.com ([169.254.3.138]) by AMXPRD0511HT001.eurprd05.prod.outlook.com ([10.242.10.162]) with mapi id 14.16.0263.000; Thu, 21 Feb 2013 21:41:58 +0000 From: C Chauvenet To: Ulrich Herberg Thread-Topic: [manet] DYMO Implementation Thread-Index: AQHOEEGoMiSEjOeiEkmR3+A1nkZnJZiEa/kAgAAChACAAAScAIAAFQuAgABIloCAAAdRAA== Date: Thu, 21 Feb 2013 21:41:58 +0000 Message-ID: <1308D66C-77D7-4CDC-85DB-C4DD899A224D@watteco.com> References: <7C036429-1FF6-4384-BBF9-4E300E8D7415@jiaziyi.com> <42D3E931-7278-4C21-AB7E-5CBD92847500@watteco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: multipart/alternative; boundary="_000_1308D66C77D74CDC85DBC4DD899A224Dwattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "manet@ietf.org" Subject: Re: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 21:42:07 -0000 --_000_1308D66C77D74CDC85DBC4DD899A224Dwattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Le 21 f=E9vr. 2013 =E0 22:15, Ulrich Herberg a =E9crit : C=E9dric, do we honestly want to start this discussion about LLNs vs MANET again? Per= sonally, I don't want to. Not at all. As requested by chairs, I think that we should now act decisions and move o= n toward a good WG document. C=E9dric AB, I don't know how often we have to repeat this on the list: The LOADng i= mplementations tested in the interop tests are conform with the latest LOAD= ng revision and use RFC5444/5498. Best regards Ulrich On Thu, Feb 21, 2013 at 8:56 AM, C Chauvenet > wrote: HI, Le 21 f=E9vr. 2013 =E0 16:40, Jiazi Yi a =E9crit : On Feb 21, 2013, at 4:24 PM, Abdussalam Baryun > wrote: Hi Jiazi, I know that DYMO implements are old, (hopfully developed to new AODVv2) I already stated that, just wanted to answer to your question. Regarding LOADng it was an implementation for LLNs not for MANETs. That's not true. Maybe AB had this feeling when reading this previously quoted mail ? : From: Ulrich Herberg > Date: November 29, 2011 7:00:08 PM GMT+01:00 Subject: DYMO Joe, Stan, During the IETF, Thomas mentioned that we are working on a draft, called "L= OADng" (draft-clausen-lln-loadng). The draft specifies a reactive routing p= rotocol, mainly intended for low-power and lossy networks (LLNs). C=E9dric. So far there is no implementation that uses the RFC5498, the using of ports is just a matter of setting one parameter in the code. Jiazi which I am interested in as OLSRv2 is using, AB On 2/21/13, Jiazi Yi > wrote: AB, I'm aware of some dymo implementation in academic conferences. However, tha= t was quite long time ago. DYMO had very big changes since its -21. When I'm saying implementations, I actually mean: o It's complaint to the latest version of the document o It's publicly known (not necessarily open source) For example, when I'm saying LOADng has 4 publicly known implementations, i= t means: o It's updated to the latest (or very recent) revision o Those four are publicly known, in the interop draft, and different scientific publications. I know there are several others, but at this point= , I can't disclose them (so they are not counted into 4 known implementations). best Jiazi On Feb 21, 2013, at 3:42 PM, Abdussalam Baryun > wrote: Hi Jiazi, Yes there are many implementation but not presented well, I think the authors have an implementation, and also many researchers have tested the old DYMO, AB ++ Sub: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? On 2/20/13, Jiazi Yi > wrote: I have no idea if there is DYMO implementation, http://www.ietf.org/mail-archive/web/manet/current/msg14948.html _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_1308D66C77D74CDC85DBC4DD899A224Dwattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Le 21 f=E9vr. 2013 =E0 22:15, Ulrich Herberg a =E9crit :

C=E9dric,

do we honestly want to start this discussion about LLNs vs MANET again? Per= sonally, I don't want to.

Not at all.
As requested by chairs, I think that we should now act decisions and m= ove on toward a good WG document. 

C=E9dric


AB, I don't know how often we have to repeat this on the list: The LOADng i= mplementations tested in the interop tests are conform with the latest LOAD= ng revision and use RFC5444/5498.

Best regards
Ulrich


On Thu, Feb 21, 2013 at 8:56 AM, C Chauvenet <c.chauvene= t@watteco.com> wrote:
HI, 

Le 21 f=E9vr. 2013 =E0 16:40, Jiazi Yi a =E9crit :



On Feb 21, 2013, at 4:24 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> = wrote:

Hi Jiazi,

I know that DYMO implements are old, (hopfully de= veloped to new
AODVv2) I already stated that, just wanted to ans= wer to your question.
Regarding LOADng it was an implementation for LLN= s not for MANETs.

That's not true.

Maybe AB had this feeling when reading this previously quoted mai= l ? : 

From: Ulrich Herberg <ulrich@herberg.name>
Date: November 29, 2011 7:00:08 PM GMT+01:00<= br>
Subject: DYMO
Joe, Stan,

During the IETF, Thomas mentioned that we are wor= king on a draft, called "LOADng" (draft-clausen-lln-loadng). The = draft specifies a reactive routing protocol, mainly intended for low-power = and lossy networks (LLNs). 


C=E9dric. 


So
far there is no implementation that uses the RFC5= 498,

the using of ports is just a matter of setting one parameter in the code. <= br>
Jiazi

which I am
interested in as OLSRv2 is using,

AB

On 2/21/13, Jiazi Yi <ietf@jiaziyi.com> wrote:
AB,

I'm aware of some dymo implementation in academic= conferences. However, that
was quite long time ago. DYMO had very big change= s since its -21.

When I'm saying implementations, I actually mean:=
o It'= s complaint to the latest version of the document
o It'= s publicly known (not necessarily open source)

For example, when I'm saying LOADng has 4 publicl= y known implementations, it
means:
o It'= s updated to the latest (or very recent) revision
o Tho= se four are publicly known, in the interop draft, and different
scientific publications. I know there are several= others, but at this point,
I can't disclose them (so they are not counted in= to 4 known
implementations).

best

Jiazi

On Feb 21, 2013, at 3:42 PM, Abdussalam Baryun &l= t;abdussala= mbaryun@gmail.com>
wrote:

Hi Jiazi,

Yes there are many implementation but not present= ed well, I think the
authors have an implementation, and also many res= earchers have tested
the old DYMO,

AB
++
Sub: Re: [manet] Why the WG Reactive Protocol to = be Compatible with
another?
On 2/20/13, Jiazi Yi <ietf@jiaziyi.com> wrote:
I have no idea if there is DYMO implementation,

http://www.ietf.org/mail-arch= ive/web/manet/current/msg14948.html
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



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



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



--_000_1308D66C77D74CDC85DBC4DD899A224Dwattecocom_-- From henning.rogge@fkie.fraunhofer.de Thu Feb 21 22:23:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C3921F8C4C for ; Thu, 21 Feb 2013 22:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vqf1KH2-kePy for ; Thu, 21 Feb 2013 22:23:44 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A749621F8C48 for ; Thu, 21 Feb 2013 22:23:43 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U8m2m-0001jm-Tu; Fri, 22 Feb 2013 07:23:40 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U8m2m-00048K-RC; Fri, 22 Feb 2013 07:23:40 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 22 Feb 2013 07:23:40 +0100 Message-ID: <51270EE2.3050900@fkie.fraunhofer.de> Date: Fri, 22 Feb 2013 07:23:30 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= References: <51263342.1080207@fkie.fraunhofer.de> <3969D96F-B639-4DDF-A7F7-66067B383551@um.es> In-Reply-To: <3969D96F-B639-4DDF-A7F7-66067B383551@um.es> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090005070504060109090604" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16718/Fri Feb 22 06:38:47 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 71f20a6753145be45d3fd9933e2b2e69 Cc: manet@ietf.org Subject: Re: [manet] DYMO Implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 06:23:50 -0000 --------------ms090005070504060109090604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 02/21/2013 04:02 PM, Francisco Javier Ros Mu=F1oz wrote: > Hi Henning, > > A long time ago I wrote an implementation that is mostly compliant with= draft dymo-04, and it incorporates some features from dymo-05. Therefore= , I'm afraid that the codebase is far from being compliant with aodvv2-00= =2E Unfortunately, I have no time to maintain this code any more. However= it is publicly available, so if anyone is interested in updating it plea= se go ahead (I don't know whether this is better than starting from scrat= ch). > > DYMOUM: > http://masimum.inf.um.es/fjrm/?page_id=3D126 > > You can find a list of other implementations (AFAIK also outdated) in > http://www.ianchak.com/dymo/ I have look through the list of the implementations. One of them is DYMO-10 (aka July 2007). One is DYMO-9 (aka May 2007). the rest is DYMO-4 or DYMO-5 (March/June 2006). I was unable to track down a more recent implementation on my own. If this list is representative, there is no current DYMO implementation, = not even close. @Charles E. Perkins: Are you aware of a recent DYMO implementation (maybe something done in=20 2012?). Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms090005070504060109090604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMjIwNjIzMzhaMCMGCSqGSIb3DQEJBDEWBBTjXsdcBF3I0DJGd9Jm4eYP4nhXvTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAmfgiiUKk+2rZfNRrCzrjqFNwSpaBPZMZN4l7NnfPBPSc GrY/jkadUp9at2J1ggbsYfvGsESSW1qW+CYCvKCL86aAPwzo8uixW3kslt82yc9Os33XG/R6 Hyoimr3dkFm9t4MqJObK55buu5gMylzLWDSQhQXcO4LVGq2otTRR2Y+SV805G6fvy/0yVN/h syZJEdvNKXi6XDwO6GNsDwG4VjPcyosGcEbwzsBGgTQN7Fw5qfxQQXrzhsnqLmC//PD2XmVf 8uuSs+zp6GJBfCWfIP1KfiMKFDXT+ROi7aoRRMqwR4VvC/H1fHJKl8deh6fASVMYeFSxteVQ VjyDvieergAAAAAAAA== --------------ms090005070504060109090604-- From henning.rogge@fkie.fraunhofer.de Fri Feb 22 00:27:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184F221F8F5B for ; Fri, 22 Feb 2013 00:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xxbXXs1xChs for ; Fri, 22 Feb 2013 00:27:21 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id B337C21F87A3 for ; Fri, 22 Feb 2013 00:27:20 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U8nyL-0001FW-U1; Fri, 22 Feb 2013 09:27:13 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U8nyL-0007Ov-RJ; Fri, 22 Feb 2013 09:27:13 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 22 Feb 2013 09:27:13 +0100 Message-ID: <51272BD8.7040403@fkie.fraunhofer.de> Date: Fri, 22 Feb 2013 09:27:04 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070009040904020005090307" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16718/Fri Feb 22 06:38:47 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 00b54f98fe2f0cea78af7465bd8f318d Cc: "manet@ietf.org" Subject: [manet] Advise about posting on the IETF Manet list X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 08:27:22 -0000 --------------ms070009040904020005090307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Abdussalam Baryun, I am irritated about some of your posts on this mailing list in the last = months, so I would like to give you an advise. In the past you have put up mails on this list with "facts" at least=20 three times which were shown to be wrong or unsupported by facts nearly=20 instantly ("LOADng interop draft was only done with one implementation", = "LOADng interop draft was only about LOADng-00" and "There are many DYMO = implementations"). In two of this cases this could have been prevented by just reading the=20 draft you were talking about. I would suggest you do a bit more personal research on your own before=20 posting, stating things about IETF documents without reading them is bad = style in my opinion. If you state that something exists (e.g. 'many DYMO implementations'),=20 try to come up with some evidence it does (for example linking to an=20 external document) or make it clear that you are speculating. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070009040904020005090307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMjIwODI3MTBaMCMGCSqGSIb3DQEJBDEWBBQ9bprPhEdEsdaKnKIyHaUyka+mETBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAQfUF60xMsnajZgTUkL4CwFn1PQy79HgkrC98ypR2p3tq 6p6hpk974n66/MXyK+wZG/OsbJ7XInxc8jkwsgbRH7C+0tbYZPp5Mdv9sR9VxRAV/onsN72Y p7W/yYz1NPGPk2JpMEhiduqgQgJnNHAwStDrzWEzZGwyTLYIB6b83Olu49cnPi8cW+8z+4rv Xu12NvVNA0yTwbQIf/bLu8rSoAUS1eDl4FNuOhCN2fysHJG2c5wh3aw1T5I4dNPYVgg/23VG EDvGJZpx1B2zqWRylZrV4tzQhj+7VCmLD1q7dnhNDD7tbPR4kpP5NMEgvxBAXKpO4ljPW/vu HAw0JJOPCQAAAAAAAA== --------------ms070009040904020005090307-- From internet-drafts@ietf.org Fri Feb 22 03:28:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09EE21F8E77; Fri, 22 Feb 2013 03:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swJnUpUBg9rk; Fri, 22 Feb 2013 03:28:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE73921F8EA9; Fri, 22 Feb 2013 03:28:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130222112847.22275.38109.idtracker@ietfa.amsl.com> Date: Fri, 22 Feb 2013 03:28:47 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:28:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Link Metrics for the Mobile Ad Hoc Network (MANET) Routi= ng Protocol OLSRv2 - Rationale Author(s) : Christopher Dearlove Thomas Heide Clausen Philippe Jacquet Filename : draft-ietf-manet-olsrv2-metrics-rationale-02.txt Pages : 29 Date : 2013-02-22 Abstract: OLSRv2 includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-metrics-rational= e-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From thomas@thomasclausen.org Fri Feb 22 03:37:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A460F21F8E97 for ; Fri, 22 Feb 2013 03:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KPaPzDLLZTv for ; Fri, 22 Feb 2013 03:37:21 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA1921F8EB3 for ; Fri, 22 Feb 2013 03:37:20 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 8A5B4A368E for ; Fri, 22 Feb 2013 03:37:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5F4F21BCDA09; Fri, 22 Feb 2013 03:37:19 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.115] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9C0811BCDA03; Fri, 22 Feb 2013 03:37:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Heide Clausen In-Reply-To: <20130222112847.22275.38109.idtracker@ietfa.amsl.com> Date: Fri, 22 Feb 2013 12:37:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <206AD221-FBA1-4554-B17B-4E191C39BE6E@thomasclausen.org> References: <20130222112847.22275.38109.idtracker@ietfa.amsl.com> To: manet List X-Mailer: Apple Mail (2.1499) Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:37:21 -0000 Just a heads up. This review folds in a couple of suggestions that our = AD made from his review. In summary, it amounts to a sentence in the = abstract and a paragraph in the introduction explaining the motivation = for publishing this document, plus a couple of nits that he caught = (thanks!). Thank you, Adrian, for your review and assistance on this matter For the authors, Thomas On Feb 22, 2013, at 12:28 , internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Link Metrics for the Mobile Ad Hoc Network = (MANET) Routing Protocol OLSRv2 - Rationale > Author(s) : Christopher Dearlove > Thomas Heide Clausen > Philippe Jacquet > Filename : = draft-ietf-manet-olsrv2-metrics-rationale-02.txt > Pages : 29 > Date : 2013-02-22 >=20 > Abstract: > OLSRv2 includes the ability to assign metrics to links and to use > those metrics to allow routing by other than minimum hop count > routes. This document provides a historic record of the rationale > for, and design considerations behind, how link metrics were = included > in OLSRv2. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale= >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-02 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-metrics-rationa= le-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Fri Feb 22 03:41:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9191021F8EC6 for ; Fri, 22 Feb 2013 03:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5edG6rB8N18 for ; Fri, 22 Feb 2013 03:41:10 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 65D1921F8EBC for ; Fri, 22 Feb 2013 03:41:10 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U8r01-0007zm-Oa for manet@ietf.org; Fri, 22 Feb 2013 12:41:09 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U8r01-0004TL-Ly for manet@ietf.org; Fri, 22 Feb 2013 12:41:09 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 22 Feb 2013 12:41:09 +0100 Message-ID: <51275950.80301@fkie.fraunhofer.de> Date: Fri, 22 Feb 2013 12:41:04 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20130222112847.22275.38109.idtracker@ietfa.amsl.com> In-Reply-To: <20130222112847.22275.38109.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070304060601020404010106" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16718/Fri Feb 22 06:38:47 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: d11929bbb37d0bf82123645737fe3651 Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:41:11 -0000 --------------ms070304060601020404010106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 02/22/2013 12:28 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group= of the IETF. > > Title : Link Metrics for the Mobile Ad Hoc Network (MANET) R= outing Protocol OLSRv2 - Rationale > Author(s) : Christopher Dearlove > Thomas Heide Clausen > Philippe Jacquet > Filename : draft-ietf-manet-olsrv2-metrics-rationale-02.txt > Pages : 29 > Date : 2013-02-22 The changes look quite reasonable. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070304060601020404010106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMjIxMTQxMDdaMCMGCSqGSIb3DQEJBDEWBBRlb/SLGDB1TPeBUbs8xQ9X36oL4DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAJbDmlOVq47W3wFRlXqDI1mLN2AExrmgwIX9BacRS7N5w OcGjnA0wR0AYGrh8fEuzZrLJNyu6nBqSdjXSkiw5+tfPA6+JQSgBVEIxybtBlJ6WAxv7rvCS nP832XL9WAU/e7zRunZFeMZfWWZd+ihCQdfs03p89uXGi5np+xhNLcr2D3sw2QJ8OzHTyhoR +QMUSgTGE+fu46gkeW7AVMI3OdS+VFWmfY1AhMWuooxCwVb4RGjBWlvDXOKdGgyJOAcpuOl+ fcYpQ8+GKzFDnrteIiSfdJO7WLuWVizgOtgS0Zf2U7hJRmm+UJOoWvRooykcriK6qFV7ocgp 5uaWccaOYQAAAAAAAA== --------------ms070304060601020404010106-- From thomas@thomasclausen.org Fri Feb 22 03:42:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8F221F8F30 for ; Fri, 22 Feb 2013 03:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4FxB6B75cEd for ; Fri, 22 Feb 2013 03:42:33 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5E98221F8EC6 for ; Fri, 22 Feb 2013 03:42:33 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 3C20DA37BD for ; Fri, 22 Feb 2013 03:42:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id EA4321BCDAFD; Fri, 22 Feb 2013 03:42:32 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 4278D1BCDAF9; Fri, 22 Feb 2013 03:42:32 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Clausen In-Reply-To: <51275950.80301@fkie.fraunhofer.de> Date: Fri, 22 Feb 2013 12:42:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <22C5BDB7-FC30-44D2-8260-32B9E5BD8836@thomasclausen.org> References: <20130222112847.22275.38109.idtracker@ietfa.amsl.com> <51275950.80301@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1499) Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:42:34 -0000 Thank you, Henning. We were just following reasonable advice from a reasonable man :D Thomas On Feb 22, 2013, at 12:41 PM, Henning Rogge = wrote: > On 02/22/2013 12:28 PM, internet-drafts@ietf.org wrote: >>=20 >> 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. >>=20 >> Title : Link Metrics for the Mobile Ad Hoc Network = (MANET) Routing Protocol OLSRv2 - Rationale >> Author(s) : Christopher Dearlove >> Thomas Heide Clausen >> Philippe Jacquet >> Filename : = draft-ietf-manet-olsrv2-metrics-rationale-02.txt >> Pages : 29 >> Date : 2013-02-22 >=20 > The changes look quite reasonable. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Fri Feb 22 04:18:02 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A9A21F8EDC for ; Fri, 22 Feb 2013 04:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.863 X-Spam-Level: X-Spam-Status: No, score=-2.863 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrjZG1uflhP0 for ; Fri, 22 Feb 2013 04:18:01 -0800 (PST) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by ietfa.amsl.com (Postfix) with ESMTP id D845821F8EC7 for ; Fri, 22 Feb 2013 04:18:00 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id e21so350619vbm.20 for ; Fri, 22 Feb 2013 04:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0LN9duOnZp4BSPGl5AHfV9fraEwfZDKKaCa9OT4xcZg=; b=WdjuWph1q4qOYUl/qKaTDuX+dMhRpyE0ghynCbH3yxYLMiWFgBXYoQ6cDspsXzyz8e ZgVb1sFMERzm7e2mULzhXthOqaCo9g+k7J0+eS6iGxa7ZzOuN0qEFTS7nq7U/aSnRfV0 TA+ICij6A5Yxp8h0VcQ95U1HZFPx6z4vtxCpE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=0LN9duOnZp4BSPGl5AHfV9fraEwfZDKKaCa9OT4xcZg=; b=lKt82LjNiI25rvgrN5iVGdTsTvsP9Uv0eOIwC+sBDnhrXKVUKGYBNLLLE1reQs4yS3 z96nABniLJjiSjCcH1DPyGKJrEvnfUaJ3vLTDHx08/ZVMlCxQhcFgJkzFpxgT2owqI0t ta77uisHvQdIS9/OsTqU0Lx3lk6A1jDP3nbLPcuigA8a53gfGNyyEfh6U8T90NcR7TW4 K5dlcFXc/fK6iFR0LuMRtcdffdvVFoQ518ZzKFTIWTNsSpBgu1yYApKHbsDdO+JAkvEx RBbwcR+U9lgh7L8E1nxYhJvLTyYtN9KvLuRDs+hr+07Xf5hWc/dJe+vd8OoM1+QQzWaO nHxw== MIME-Version: 1.0 X-Received: by 10.52.100.5 with SMTP id eu5mr1901443vdb.66.1361535479940; Fri, 22 Feb 2013 04:17:59 -0800 (PST) Received: by 10.220.107.7 with HTTP; Fri, 22 Feb 2013 04:17:59 -0800 (PST) In-Reply-To: <51275950.80301@fkie.fraunhofer.de> References: <20130222112847.22275.38109.idtracker@ietfa.amsl.com> <51275950.80301@fkie.fraunhofer.de> Date: Fri, 22 Feb 2013 04:17:59 -0800 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: multipart/alternative; boundary=20cf3071cf9aa1d2b504d64f2e52 X-Gm-Message-State: ALoCoQkCbRZrbtS8K/tyaDVqmW+Vwjj8ar2/LeiXQJ/ucuyBgo+Sh3eItsaYeJg0lHfWRPYF4klO Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 12:18:02 -0000 --20cf3071cf9aa1d2b504d64f2e52 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Henning. Thanks for the update of the draft. Ulrich On Fri, Feb 22, 2013 at 3:41 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > On 02/22/2013 12:28 PM, internet-drafts@ietf.org wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobile Ad-hoc Networks Working Group >> of the IETF. >> >> Title : Link Metrics for the Mobile Ad Hoc Network >> (MANET) Routing Protocol OLSRv2 - Rationale >> Author(s) : Christopher Dearlove >> Thomas Heide Clausen >> Philippe Jacquet >> Filename : draft-ietf-manet-olsrv2-** >> metrics-rationale-02.txt >> Pages : 29 >> Date : 2013-02-22 >> > > The changes look quite reasonable. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf3071cf9aa1d2b504d64f2e52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Henning. Thanks for the update of the draft.

Ulrich
=
On Fri, Feb 22, 2013 at 3:41 AM, Henning Rog= ge <henning.rogge@fkie.fraunhofer.de> wrote:<= br>
On 02/22/2013 12:28 PM, internet-drafts= @ietf.org wrote:

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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Link Metrics for the Mobile Ad = Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Christopher Dearlove
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thomas Heide Clausen=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Philippe Jacquet
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-manet-olsrv2-me= trics-rationale-02.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 29
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-22

The changes look quite reasonable.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


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


--20cf3071cf9aa1d2b504d64f2e52-- From rdroms.ietf@gmail.com Fri Feb 22 06:16:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D59A21F8DDA for ; Fri, 22 Feb 2013 06:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.548 X-Spam-Level: X-Spam-Status: No, score=-103.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUA7Z0LatKJ8 for ; Fri, 22 Feb 2013 06:16:10 -0800 (PST) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id 72DC921F8DD9 for ; Fri, 22 Feb 2013 06:16:10 -0800 (PST) Received: by mail-vb0-f48.google.com with SMTP id fc21so414374vbb.7 for ; Fri, 22 Feb 2013 06:16:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=drhyLRGe3ixAuQYUXcDn2DAtIBRIH/vRDmOSurr1y8M=; b=ehke4xhG0OpdhbMbLkkr8WN+Pn2Y99g3hSiobYUrKSKrqb43hk1C4N2807Qiz8Bl5a 2R2kjy5/0foSq+rNKPhvJQvmMy1+OE6VGm9lnXU0Frr8En4O31j90oZp4FWY108eS+j/ T2NL4e2wj7QxQgi0Qkvm89HqjDjeaZBNaL68CR/MvU5theP3+e8Ki1ysdhXou8ZlCHs+ CINVvakFQdQ/q8BBrX/6YiOBq0xN4s5L/cMptzGq1FxjeERDI3nmxZj6Nsqwim+r44mw nwTkoGw+h3v9Ffpp/f3NklBOQVNzCPdbTsRtJn435K7Mu8x0zH38b7guD+XNoAcbqa+8 rn4g== X-Received: by 10.220.157.18 with SMTP id z18mr2611255vcw.72.1361542562605; Fri, 22 Feb 2013 06:16:02 -0800 (PST) Received: from ?IPv6:2001:420:2481:20:b1d6:2d09:fcb3:235d? ([2001:420:2481:20:b1d6:2d09:fcb3:235d]) by mx.google.com with ESMTPS id p7sm3719563vdt.2.2013.02.22.06.16.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 06:16:01 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 22 Feb 2013 09:15:58 -0500 To: manet Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [manet] IETF last call and review of draft-cardenas-dff-09.txt (reminder) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:16:11 -0000 draft-cardenas-dff is under consideration for publication as an = AD-sponsored individual submission Experimental RFC. I agreed to = sponsor it for publication because it doesn't really fit in any existing = working groups and the requested publication status is Experimental. As = part of the review process, the document is in a 2-week IETF last call. = The last call announcement is included below. To ensure the quality of = the document, it would be helpful to get reviews from manet WG = participants (posted to the ietf@ietf.org discussion list). Expressions of an opinion about whether or not to publish the document, = in addition to technical input to the authors, would be useful. Thanks. - Ralph =3D=3D=3D=3D=3D The IESG has received a request from an individual submitter to consider the following document: - 'Depth-First Forwarding in Unreliable Networks (DFF)' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-24. Exceptionally, comments may = be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the "Depth-First Forwarding" (DFF) protocol for IPv6 networks, a data forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane, but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies the DFF mechanism both for IPv6 networks (as specified in RFC2460) and in addition also for LoWPAN "mesh-under" networks (as specified in RFC4944). The file can be obtained via http://datatracker.ietf.org/doc/draft-cardenas-dff/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1645/ http://datatracker.ietf.org/ipr/1646/ From joseph.macker@nrl.navy.mil Fri Feb 22 12:28:35 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D7921F867D for ; Fri, 22 Feb 2013 12:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.501 X-Spam-Level: * X-Spam-Status: No, score=1.501 tagged_above=-999 required=5 tests=[AWL=4.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfTVQVxmxbVS for ; Fri, 22 Feb 2013 12:28:34 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) by ietfa.amsl.com (Postfix) with ESMTP id 8E95C21F888B for ; Fri, 22 Feb 2013 12:28:30 -0800 (PST) Received: from vpn217206.nrl.navy.mil (vpn217206.nrl.navy.mil [132.250.217.206]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id r1MKSTpM015973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 22 Feb 2013 15:28:29 -0500 From: Joe Macker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6AC6ED8F-8717-4D20-8D9C-67592C5C8AF4@nrl.navy.mil> Date: Fri, 22 Feb 2013 15:28:21 -0500 To: manet IETF Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Subject: [manet] WG Last Call for draft-ietf-manet-nhdp-sec-threats-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:28:35 -0000 The WG chairs announce a WG Last Call for the nhdp-sec-threats document. = Its intended status is INFORMATIONAL. The WG Last Call will last two weeks from today until Friday, Mar 8. -Joe Macker From shares@ndzh.com Fri Feb 22 13:02:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D2A21F8E7E for ; Fri, 22 Feb 2013 13:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.906 X-Spam-Level: X-Spam-Status: No, score=0.906 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83LC5fuoUNwP for ; Fri, 22 Feb 2013 13:02:12 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5395121F8E7A for ; Fri, 22 Feb 2013 13:02:12 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Thomas Heide Clausen'" , "'manet List'" References: <20130222112847.22275.38109.idtracker@ietfa.amsl.com> <206AD221-FBA1-4554-B17B-4E191C39BE6E@thomasclausen.org> In-Reply-To: <206AD221-FBA1-4554-B17B-4E191C39BE6E@thomasclausen.org> Date: Fri, 22 Feb 2013 16:02:06 -0500 Message-ID: <00e901ce113f$df82dbb0$9e889310$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQLxDAZjuCGxduqF7CVn8q7dAXgVbwHiwMQVljFRFEA= X-Authenticated-User: skh@ndzh.com Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:02:13 -0000 Thomas: Thank you for revising this draft which has been helpful in understanding your motivations. If you'd like specific how it has been helpful.. just ask (private or public). Sue Hares [snip] Thomas > Title : Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale > Author(s) : Christopher Dearlove > Thomas Heide Clausen > Philippe Jacquet > Filename : draft-ietf-manet-olsrv2-metrics-rationale-02.txt > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale > From abdussalambaryun@gmail.com Fri Feb 22 16:03:19 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D9D21F8917 for ; Fri, 22 Feb 2013 16:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrXPsGsIm10j for ; Fri, 22 Feb 2013 16:03:17 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 487D321F890F for ; Fri, 22 Feb 2013 16:03:17 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md12so674484pbc.2 for ; Fri, 22 Feb 2013 16:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yJEpzWhhL8SHqpmZmElve+hdVpWxTAsSsRrV+Rj5Hc8=; b=zLrML2JCupKZrXDQzGTIUavytTHSxfFNQt5YacF9JHMh4oIJZe4dyVMlMiqoseFySr JW70OfYeayPWAH5tgVAM/h2+rH330gNXJa+XSbZK/3laZ/RQL1BJNyUS82hpkSQPCYfp A1JF39X/XJuatx10MQflbE4Y8hOG8c0kOtAXk/STJ9KjQlq8HZe9mYvcz1nvsvUG5ijn +88qo2LqFrmv5ASwhvq5oX93DByNmxOci335iUqe3BBZ4bAErEyG9fvj3qH1mNzmGL0V EJgHn1ozmGbESwe16OVkhJIkVw2zWRc0p7QMx6wTktQkZ4+Btf9/Vo4cNcEhqOrWv1fS XldA== MIME-Version: 1.0 X-Received: by 10.67.5.193 with SMTP id co1mr6924423pad.6.1361577797053; Fri, 22 Feb 2013 16:03:17 -0800 (PST) Received: by 10.68.33.132 with HTTP; Fri, 22 Feb 2013 16:03:16 -0800 (PST) In-Reply-To: <206AD221-FBA1-4554-B17B-4E191C39BE6E@thomasclausen.org> References: <20130222112847.22275.38109.idtracker@ietfa.amsl.com> <206AD221-FBA1-4554-B17B-4E191C39BE6E@thomasclausen.org> Date: Sat, 23 Feb 2013 01:03:16 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: manet List Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 00:03:19 -0000 Hi Thomas, Thanks for update, it covers the two main point of the review. However, while checking the AD review [1], not sure there was a reply to AD review from authors (did they do private, because one reply was happy christmas) on the WG list. I recommend we get a reply to the review then the update. The reason is because IMHO the review mentions that : *As usual, all my comments are open for discussion.*, I did not want to discuss but was waiting for authors to start a reply, but now see a jump to update, I hope we can see reply to AD review [1] including last two points, please advise, [1] http://www.ietf.org/mail-archive/web/manet/current/msg14440.html AB On 2/22/13, Thomas Heide Clausen wrote: > Just a heads up. This review folds in a couple of suggestions that our AD > made from his review. In summary, it amounts to a sentence in the abstract > and a paragraph in the introduction explaining the motivation for publishing > this document, plus a couple of nits that he caught (thanks!). > > Thank you, Adrian, for your review and assistance on this matter > > For the authors, > > Thomas > > On Feb 22, 2013, at 12:28 , internet-drafts@ietf.org wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobile Ad-hoc Networks Working Group of >> the IETF. >> >> Title : Link Metrics for the Mobile Ad Hoc Network (MANET) >> Routing Protocol OLSRv2 - Rationale >> Author(s) : Christopher Dearlove >> Thomas Heide Clausen >> Philippe Jacquet >> Filename : draft-ietf-manet-olsrv2-metrics-rationale-02.txt >> Pages : 29 >> Date : 2013-02-22 >> >> Abstract: >> OLSRv2 includes the ability to assign metrics to links and to use >> those metrics to allow routing by other than minimum hop count >> routes. This document provides a historic record of the rationale >> for, and design considerations behind, how link metrics were included >> in OLSRv2. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-metrics-rationale-02 >> >> >> 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 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Fri Feb 22 17:32:09 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CAA21F89A3 for ; Fri, 22 Feb 2013 17:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zUYwmR18l54 for ; Fri, 22 Feb 2013 17:32:08 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFC821F8956 for ; Fri, 22 Feb 2013 17:32:08 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md12so709061pbc.16 for ; Fri, 22 Feb 2013 17:32:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iwzodPgIOGIUJWcQgUpO2o9sNwAYwlF9cXmgbmmFLj8=; b=Bq2sGPR6HAog+e478ShCeEV7DTtNlIgbVK+Ot00CwKSDHlZMe3VTz0hU7ftfAWCiZv OeHeKJL4zgUMYS3Pr7TQnd9PVoUfAM9TJdJ3LiFlf5KBmnG3Jrom/AH3XwZVNyjL4V3v NaYdkMqnP76/x8i6YvHRUKVBMKhtlAtRBSBu36zRxtKuzN8msdZiWRskrNhGHO2vok4Q 7FnE9Trt6dUuqTX+P0N0nguM66k3ime7WsQLAXTKJEoG1uKYf7QfJbYxVJUGpBfHqFlV 1gwqytQoIE/q9ZmCpNO7ew5/xrb8PlwsC1SMndjKCMG+hvtNBYy632WJrZ5NCawKnyJM 8k5A== MIME-Version: 1.0 X-Received: by 10.66.234.132 with SMTP id ue4mr7035495pac.163.1361583128277; Fri, 22 Feb 2013 17:32:08 -0800 (PST) Received: by 10.68.33.132 with HTTP; Fri, 22 Feb 2013 17:32:07 -0800 (PST) In-Reply-To: <6AC6ED8F-8717-4D20-8D9C-67592C5C8AF4@nrl.navy.mil> References: <6AC6ED8F-8717-4D20-8D9C-67592C5C8AF4@nrl.navy.mil> Date: Sat, 23 Feb 2013 02:32:07 +0100 Message-ID: From: Abdussalam Baryun To: Joe Macker Content-Type: text/plain; charset=ISO-8859-1 Cc: manet IETF Subject: Re: [manet] WG Last Call for draft-ietf-manet-nhdp-sec-threats-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 01:32:09 -0000 Hi Joe, There was WG discussion [1][2] not followed by authors to update the WG draft, and the draft was expired last year, I recommend authors to follow and update it before the WGLC [1] http://www.ietf.org/mail-archive/web/manet/current/msg13361.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg13378.html AB On 2/22/13, Joe Macker wrote: > The WG chairs announce a WG Last Call for the nhdp-sec-threats document. > Its intended status is INFORMATIONAL. > > The WG Last Call will last two weeks from today until Friday, Mar 8. > > -Joe Macker > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From ulrich@herberg.name Fri Feb 22 17:46:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB91C21E8043 for ; Fri, 22 Feb 2013 17:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB7zrOf+Y90h for ; Fri, 22 Feb 2013 17:46:14 -0800 (PST) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id E85C021E803F for ; Fri, 22 Feb 2013 17:46:13 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id pb11so1085519veb.5 for ; Fri, 22 Feb 2013 17:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uVR/UoEcIuoK4ALRcZS3ffck4GJ/Vt2MLB/0QfP+XHA=; b=xS0qcTWZ8DkEsJwWaQTHIQxgt7+4uXJaI8XBfLw4cyCtteFfqAtGvK3SapCUwoHH44 45VzbTzGVyJRmvUs7DOfaui4J6IWGfUdCscm9mnwBoyU30ydPggS/mcBZfCp56LZDg5f k61ARw7qH8FPoCqRw8d4RqPQ+N57sODl2BK2o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=uVR/UoEcIuoK4ALRcZS3ffck4GJ/Vt2MLB/0QfP+XHA=; b=QkOW230ADh8bZXV4LOfOrasniyEa6ceoefuCjaC7QypEZF+BLz8OtdRB4ZkbrqBZzn JSJ8QzC6UUGbBIQ+W8YCEb71GJHYbCny4hVea4wsbi5heJwLZne2zIo/F9QVzlcPFKEi nbk5jBEoN2QzF+vIYP8rH44C9UrN1y9J0Cpd8wRT4cu+ukqBYNPmdifueapA2iIFZDjD Gq3uw8UXEBuuZwcu5UyRpBhQtiQHTT8iI22tunFKU5Z09XkDBK4PFG3+fb0bQr9m8wdq 9D+A1jGyIoehmfWePdMjSbhOScTaGMVg/V29QSplx0IpGWdYMOxfQUEfDeu6QYZWAReK UBuA== MIME-Version: 1.0 X-Received: by 10.220.219.77 with SMTP id ht13mr5328572vcb.66.1361583973230; Fri, 22 Feb 2013 17:46:13 -0800 (PST) Received: by 10.220.107.7 with HTTP; Fri, 22 Feb 2013 17:46:12 -0800 (PST) In-Reply-To: References: <6AC6ED8F-8717-4D20-8D9C-67592C5C8AF4@nrl.navy.mil> Date: Fri, 22 Feb 2013 17:46:12 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=14dae9cfc8a80eb96104d65a793e X-Gm-Message-State: ALoCoQlGD3azMUjnNqmrUqe4zzGWJ8qzFhAcCTxgjfYyTprk5gRKfEzOM6QIRWSGlW0H0Hm2DoHi Cc: manet IETF , Joe Macker Subject: Re: [manet] WG Last Call for draft-ietf-manet-nhdp-sec-threats-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 01:46:15 -0000 --14dae9cfc8a80eb96104d65a793e Content-Type: text/plain; charset=ISO-8859-1 AB, I let Jiazi confirm (who did the updates of the text), but as far as I can see the text has been updated as promised. Also you are wrong, the draft [1] has not expired. It will expire in April 2013. [1] http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-01 Best regards Ulrich On Fri, Feb 22, 2013 at 5:32 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Joe, > > There was WG discussion [1][2] not followed by authors to update the > WG draft, and the draft was expired last year, I recommend authors to > follow and update it before the WGLC > > [1] http://www.ietf.org/mail-archive/web/manet/current/msg13361.html > [2] http://www.ietf.org/mail-archive/web/manet/current/msg13378.html > > AB > > On 2/22/13, Joe Macker wrote: > > The WG chairs announce a WG Last Call for the nhdp-sec-threats document. > > Its intended status is INFORMATIONAL. > > > > The WG Last Call will last two weeks from today until Friday, Mar 8. > > > > -Joe Macker > > > > > > _______________________________________________ > > 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 > --14dae9cfc8a80eb96104d65a793e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AB,

I let Jiazi confirm (who did the updates of the text), but as fa= r as I can see the text has been updated as promised. Also you are wrong, t= he draft [1] has not expired. It will expire in April 2013.

[1] ht= tp://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-01

Best regards
Ulrich

On Fri, Feb 22= , 2013 at 5:32 PM, Abdussalam Baryun <abdussalambaryun@gmail.com<= /a>> wrote:
Hi Joe,

There was WG discussion [1][2] not followed by authors to update the
WG draft, and the draft was expired last year, I recommend authors to
follow and update it before the WGLC

[1] http://www.ietf.org/mail-archive/web/manet/current/= msg13361.html
[2] http://www.ietf.org/mail-archive/web/manet/current/= msg13378.html

AB

On 2/22/13, Joe Macker <jo= seph.macker@nrl.navy.mil> wrote:
> The WG chairs announce a WG Last Call for the nhdp-sec-threats documen= t.
> Its intended status is INFORMATIONAL.
>
> The WG Last Call will last two weeks from today until Friday, Mar 8. >
> -Joe Macker
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--14dae9cfc8a80eb96104d65a793e-- From abdussalambaryun@gmail.com Sat Feb 23 03:44:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E9D21F87FA for ; Sat, 23 Feb 2013 03:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdKwdYBJd8hc for ; Sat, 23 Feb 2013 03:44:25 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id D116B21F8697 for ; Sat, 23 Feb 2013 03:44:25 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id bj3so940179pad.34 for ; Sat, 23 Feb 2013 03:44:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WEV1Ty/BOS/rRpqnhS9ecgA7fveEFFvywR1kC70n6QI=; b=LgX+he7ydtIz7JReR8PaSCCazmkpXYI6ljEmoF8LaTc46y22ziVUSBzvgtGWN5fnzB PJyCHtflHyyNaaKFCWgtqz3sJuaX5fJAAaJm2tN0Hh3C6JtF8ZFRUIDW2/SA4hL5sd3c rKZt7nDRvhfkWfTwD1hyAayzBNj4Ks4kF7/ZIfauEYlqx9pw65AEZR8vRRhVWpUeeS0p v+LwuNUdOIk7+vWPXYh2zcgELwMx2cKaROjUhqDFodqL1bD1Mp1SWrig2HeSm1UH5qj7 AWDIAg4tA/Rg3e03XiaMGW7KsTeB7griFk2njcsy2kMLfhuLsxGv7hnOZ5R2ekI45b6a gGfw== MIME-Version: 1.0 X-Received: by 10.66.185.33 with SMTP id ez1mr8953880pac.93.1361619865529; Sat, 23 Feb 2013 03:44:25 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sat, 23 Feb 2013 03:44:25 -0800 (PST) In-Reply-To: <01c701cdda51$8f829bc0$ae87d340$@olddog.co.uk> References: <01c701cdda51$8f829bc0$ae87d340$@olddog.co.uk> Date: Sat, 23 Feb 2013 12:44:25 +0100 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org, draft-ietf-manet-olsrv2-metrics-rationale.all@tools.ietf.org Subject: Re: [manet] AD review of draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 11:44:26 -0000 Hi Adrian, As the draft now updates the main point of your review, I would like to comment/discuss on other last points of the below review (I deleted the main points), but just my thoughts, On 12/15/12, Adrian Farrel wrote: > Hi, > > I have done my usual AD review of your draft prior to issuing IETF > last call. The purpose of the review is to clear up any issues that > might arise during last call or IESG evaluation to save other reviewers > time, and to smooth the passage of the draft in those stages. > > This document looks in pretty good shape to me. As a calibration, I > noted a number of questions as I went along, only to find you answered > them about half a page later. Thanks for all the work you must have put > in. > > I have a number of comments, but only the first two really need > attention. The others would be "nice to have". > > If you can respin the document addressing these comments, I will issue > last call. As usual, all my comments are open for discussion. > > Thanks, > Adrian > > --- > > There is a mismatched double quote at symmetric link in the middle > paragraph. > Did not understand this point, but hope that it was updated, > --- > > I wonder whether you want to make any comments about node metrics. > Obviously, you don't have them (neighbor metrics being a different > thing), but you could comment on why you don't have them (if this was > ever discussed). > > The question is slightly touched on in 5.2 in discussion of "delay". I may agree that it will be valuable to add text to explain metric type of delay, but the draft stated that no relation with the metric and the physical real information, so I may understand that there is no rationale in OLSRv2 for this issue. If there is a rationale then it should be in scope (in introduction states that it is out of scope). > > --- > > Section 8 > > Were there any security considerations that cropped up while designing > metric support in OSLRv2? If so, here would be the place to mention > them. I agree, otherwise it can be mentioned/stated that there was no rationale of security on the link metric for OLSRv2. Reading OLSRv2-16 there is *signature using TLV* that may be related. Section 8 rationale seems not complete IMO, AB>Amend> This document does not specify any security considerations, because there is no rationale of security consideration on OLSRv2 link metric design. Regards AB From yi.jiazi@gmail.com Sat Feb 23 06:48:02 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE5621F8C75 for ; Sat, 23 Feb 2013 06:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.339 X-Spam-Level: * X-Spam-Status: No, score=1.339 tagged_above=-999 required=5 tests=[AWL=-1.546, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5F4l2aQVWsr for ; Sat, 23 Feb 2013 06:48:01 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 79F2821F86E8 for ; Sat, 23 Feb 2013 06:48:01 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t11so1334512wey.14 for ; Sat, 23 Feb 2013 06:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=7moO22ZvrQHsyQ8qf2Y3gRHCtNMkeGzeR/n637Rd2F8=; b=DmSaIlWAJR2i0AGoL+8eEJTl69OyIrvIk5VfqOksyzYG6PH2nngCGKt+wRtBT4tpOO nUAH280f2EYY7g66UvqfcVpLBqfd1cjLcVMSKa7B5dvV4O0CUO0G2cMW9rubg2O6buSF CGkIJadteNhsVm8KC5VdnxX1JXvIaA8T+l87ND1Jf6sui9C5ve4RIexwF+MZ0zXEKhPD F5l0p345mhctvQrQ1nMl/PXGdGn99mTVmFCGuyX99Yx7IHS3C60Dfyvr1qtgbExYxKgl vKX3FzMS0XVQ9Q4e7+MqOWw2vB1yunXmAG9KzeYnKck+7IMBxCIaJ6WYQZZ/rIrDWk2U iMSw== X-Received: by 10.194.63.240 with SMTP id j16mr9332228wjs.45.1361630876133; Sat, 23 Feb 2013 06:47:56 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id bs6sm4364203wib.4.2013.02.23.06.47.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Feb 2013 06:47:55 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Sat, 23 Feb 2013 15:47:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6AC6ED8F-8717-4D20-8D9C-67592C5C8AF4@nrl.navy.mil> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: manet IETF , Joe Macker Subject: Re: [manet] WG Last Call for draft-ietf-manet-nhdp-sec-threats-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 14:48:02 -0000 Dear AB,=20 I would suggest read the latest revision before making comments.=20 Those changes have been integrated.=20 best Jiazi On Feb 23, 2013, at 2:32 AM, Abdussalam Baryun = wrote: > Hi Joe, >=20 > There was WG discussion [1][2] not followed by authors to update the > WG draft, and the draft was expired last year, I recommend authors to > follow and update it before the WGLC >=20 > [1] http://www.ietf.org/mail-archive/web/manet/current/msg13361.html > [2] http://www.ietf.org/mail-archive/web/manet/current/msg13378.html >=20 > AB >=20 > On 2/22/13, Joe Macker wrote: >> The WG chairs announce a WG Last Call for the nhdp-sec-threats = document. >> Its intended status is INFORMATIONAL. >>=20 >> The WG Last Call will last two weeks from today until Friday, Mar 8. >>=20 >> -Joe Macker >>=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 From abdussalambaryun@gmail.com Sat Feb 23 08:05:16 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C570221F8FCD for ; Sat, 23 Feb 2013 08:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74A8PzVTJJJy for ; Sat, 23 Feb 2013 08:05:16 -0800 (PST) Received: from mail-da0-f47.google.com (mail-da0-f47.google.com [209.85.210.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED5621F8FCC for ; Sat, 23 Feb 2013 08:05:15 -0800 (PST) Received: by mail-da0-f47.google.com with SMTP id s35so823459dak.6 for ; Sat, 23 Feb 2013 08:05:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=05xM7zWmCwW+DeeVYy6Lq95P1L1oy9+eosbsnwSjODU=; b=dHj25dO0yh34W08Njhpr2lohBXkmsyO8qk3HKNdUVuFQNbUoefcqlBwjv7cV9ufAI+ cHDVjDIQjBJYrF6tcLAEP04IO2fgoAYoLvavakyT/9rXrQnDAEoPFjtKNPg6/jrgBfCB yWSa0K/SoUNg4zqAkldn/Mw/FsEDEW1SubLd5/dE5SeTolMGwdIx9jgFcunOJuzE/byn Yssw94gD+0PhAl+/D+4R9p9TXrEvt5m+ggrtb8h33tdE+akFIuV5hBPhGkiZ9UK3r3Ms rGudShpA3GankrsVO8z4nfpanTCVTsHL7etBU2OZ1lrTCGePDt5QwC8qWK8Nrls/PimT iZ1Q== MIME-Version: 1.0 X-Received: by 10.68.143.40 with SMTP id sb8mr9054778pbb.202.1361635514581; Sat, 23 Feb 2013 08:05:14 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sat, 23 Feb 2013 08:05:14 -0800 (PST) In-Reply-To: References: <6AC6ED8F-8717-4D20-8D9C-67592C5C8AF4@nrl.navy.mil> Date: Sat, 23 Feb 2013 17:05:14 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Cc: manet IETF Subject: Re: [manet] WG Last Call for draft-ietf-manet-nhdp-sec-threats-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 16:05:16 -0000 Ok sorry, I made a mistake in checking herberg-manet-nhdp-sec-threats-01, but when checking the discussions I think the comments below are valid and few still not fulfill, I will comment on the replies when available, http://www.ietf.org/mail-archive/web/manet/current/msg13286.html http://www.ietf.org/mail-archive/web/manet/current/msg13361.html AB On 2/23/13, Jiazi Yi wrote: > Dear AB, > > I would suggest read the latest revision before making comments. > Those changes have been integrated. > > best > > Jiazi > > On Feb 23, 2013, at 2:32 AM, Abdussalam Baryun > wrote: > >> Hi Joe, >> >> There was WG discussion [1][2] not followed by authors to update the >> WG draft, and the draft was expired last year, I recommend authors to >> follow and update it before the WGLC >> >> [1] http://www.ietf.org/mail-archive/web/manet/current/msg13361.html >> [2] http://www.ietf.org/mail-archive/web/manet/current/msg13378.html >> >> AB >> >> On 2/22/13, Joe Macker wrote: >>> The WG chairs announce a WG Last Call for the nhdp-sec-threats document. >>> Its intended status is INFORMATIONAL. >>> >>> The WG Last Call will last two weeks from today until Friday, Mar 8. >>> >>> -Joe Macker >>> >>> >>> _______________________________________________ >>> 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 abdussalambaryun@gmail.com Sat Feb 23 08:16:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A8221F8FB1 for ; Sat, 23 Feb 2013 08:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QjOMDOEtoCR for ; Sat, 23 Feb 2013 08:16:02 -0800 (PST) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACE621F8FA2 for ; Sat, 23 Feb 2013 08:16:02 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id uo15so944908pbc.19 for ; Sat, 23 Feb 2013 08:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+t1HVJu+3UKemmSHhw/pMTElMaaYQHhwI5fMttBaqVw=; b=t+xxNbdrdPTtY3E8EGM+JbfgVAyj0C+RsLt29vKKAkkeep+hSYXi8jnI5MmcJksdT4 EHZamgO7ulJSk6oyAKiBnhhRl00LtzwRaXzil/t5Nsnk006FeYnAXy/MYDowDod7skFv ZvpixNPIhu7GI5xP0wGcX0tPQrn4g1x8zc0Oja4w0ih8oARLjQyN9eNSw9IVMV1uCtp0 Dyl3jTEQsG7m+Q1foAYd69qOyvsVAp0Ut+uUPFiUIwBTU03TSQH1V2U+/z3tV61Nwn4p LWzgvtSGjaPKQWQJVHwHPAejd1AgOxU68YyHJKvPUU0vb9v4G0gr7mX/AygFchlXZt6w qPlA== MIME-Version: 1.0 X-Received: by 10.68.28.194 with SMTP id d2mr8849320pbh.215.1361636162297; Sat, 23 Feb 2013 08:16:02 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sat, 23 Feb 2013 08:16:02 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> Date: Sat, 23 Feb 2013 17:16:02 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi YI Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 16:16:13 -0000 On 10/23/12, Jiazi YI wrote: > Dear all, > > The new revision of the WG document draft-ietf-manet-nhdp-sec-threats has > addressed most of the comments from the WG. > > The main changes include: > > o Take the misconfiguration of NHDP routers into consideration. > o Added a sub-section of Denial of service attack. ok, agree > o Removed sub-section Sequence Number Attack, which should be more related > to OLSRv2. Why related only to the router do you mean that NHDP has no sequence number, or its sequence numbers have no threats on the protocol? please advise, > o some text on the assumption & scope of the document. > > I would like to thank again for the comments from the WG. Further comments > are always appreciated. Thanks to the update, but I recommend you mention thanks into the document, which has no acknowledgements :) AB From yi.jiazi@gmail.com Sat Feb 23 10:49:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD4321F8E8E for ; Sat, 23 Feb 2013 10:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=2.005, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBSfRZ+rt4rR for ; Sat, 23 Feb 2013 10:49:37 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id A938521F8759 for ; Sat, 23 Feb 2013 10:49:36 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id fg15so1346598wgb.1 for ; Sat, 23 Feb 2013 10:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=XYYXQXtr5GTsHWYS/asGjjnJrdG9ExiQVplMlLJNyWs=; b=JZJgd/7LIsFkKE9P3QNJO5VpXsJ0oGx4lA6dWM/VB45xBCEqcsDWZROVVxbGl1tl7M 7Si0EGlD5caIqdXDoF6e+2OARrVpZ3y6j7y2yQWN59fEtjmr3VnUMWSSd9f67ZLFDTjy qC8EHoIoZPrgtwHaLIv8vr4rlwwJ1LZMCN9dC3xURezNfPV7nTGweGFYNENxgT7FX2Io Bln8MQiaCrfwHFkeD9UFP3N1u4XflEjPFE1s1cPhqE/MpRGhWiI83u/ZZ+rwe1cMmArM I7fhsyRZejRk5WgiazDGjflOFmHWfFYgGo5cu5MZkTK2RRH8RI6jxmqu8TfVmxmBIwlT Vgxg== X-Received: by 10.194.235.196 with SMTP id uo4mr10264407wjc.30.1361645375879; Sat, 23 Feb 2013 10:49:35 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id er3sm5056380wib.1.2013.02.23.10.49.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Feb 2013 10:49:35 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Sat, 23 Feb 2013 19:49:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3D267863-2D9F-4AE9-8DB2-ED65D57FC89C@jiaziyi.com> References: <6AC6ED8F-8717-4D20-8D9C-67592C5C8AF4@nrl.navy.mil> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: manet IETF Subject: Re: [manet] WG Last Call for draft-ietf-manet-nhdp-sec-threats-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 18:49:37 -0000 Dear AB,=20 I have replied the mail from John and Teco. Those comments were either = addressed, or provided with considerations of the authors.=20 If you have different opinion, please elaborate.=20 best Jiazi On Feb 23, 2013, at 5:05 PM, Abdussalam Baryun = wrote: > Ok sorry, I made a mistake in checking > herberg-manet-nhdp-sec-threats-01, but when checking the discussions I > think the comments below are valid and few still not fulfill, I will > comment on the replies when available, >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg13286.html > http://www.ietf.org/mail-archive/web/manet/current/msg13361.html >=20 > AB >=20 > On 2/23/13, Jiazi Yi wrote: >> Dear AB, >>=20 >> I would suggest read the latest revision before making comments. >> Those changes have been integrated. >>=20 >> best >>=20 >> Jiazi >>=20 >> On Feb 23, 2013, at 2:32 AM, Abdussalam Baryun = >> wrote: >>=20 >>> Hi Joe, >>>=20 >>> There was WG discussion [1][2] not followed by authors to update the >>> WG draft, and the draft was expired last year, I recommend authors = to >>> follow and update it before the WGLC >>>=20 >>> [1] http://www.ietf.org/mail-archive/web/manet/current/msg13361.html >>> [2] http://www.ietf.org/mail-archive/web/manet/current/msg13378.html >>>=20 >>> AB >>>=20 >>> On 2/22/13, Joe Macker wrote: >>>> The WG chairs announce a WG Last Call for the nhdp-sec-threats = document. >>>> Its intended status is INFORMATIONAL. >>>>=20 >>>> The WG Last Call will last two weeks from today until Friday, Mar = 8. >>>>=20 >>>> -Joe Macker >>>>=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 >>=20 >>=20 From yi.jiazi@gmail.com Sat Feb 23 11:07:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253CD21F8EFD for ; Sat, 23 Feb 2013 11:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=1.671, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VpJKri0Nwos for ; Sat, 23 Feb 2013 11:07:35 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id E3A7321F8EE8 for ; Sat, 23 Feb 2013 11:07:34 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hq4so2088976wib.0 for ; Sat, 23 Feb 2013 11:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=bLQ+0eBBRd1ABj4rRoE6PXt0rDyDOdF+t6v2msoNmR0=; b=QwuDSHfI8ZKhyx14oSscv16ZHkw0L/I0J95xPKP4vX9P8gdHlb/L/OVdz66dCHnLm8 gLhmn3Fb1QdpQMZaQIqak6VpdzIp1Fns2ugXE48VATXAmqyKG0pvzEkzr5B/M/esUdFx he3EeFM27zwt2ApDECWpE13qplN+6XPkQqZt9LDAtpJ8nEvzfoMhLL/8lr/uoA6neCeL fqBJer4pd2nXdnyIa+V/6anNpRuwJDDUMyWi4MOiBcVaHqZpU7BXHP4YQThVdBHPmp0W BlMazJKs7Jpuci9GN/JgdrB9SJbPvTyq4QphqKUtdNx6MLdXhrFkIs5BXykEJhHlO/wY Gj5w== X-Received: by 10.180.98.198 with SMTP id ek6mr3831556wib.7.1361646451664; Sat, 23 Feb 2013 11:07:31 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id ay10sm5136564wib.3.2013.02.23.11.07.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Feb 2013 11:07:31 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Sat, 23 Feb 2013 20:07:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 19:07:36 -0000 Hi,=20 On Feb 23, 2013, at 5:16 PM, Abdussalam Baryun = wrote: > On 10/23/12, Jiazi YI wrote: >> Dear all, >>=20 >> The new revision of the WG document draft-ietf-manet-nhdp-sec-threats = has >> addressed most of the comments from the WG. >>=20 >> The main changes include: >>=20 >> o Take the misconfiguration of NHDP routers into consideration. >> o Added a sub-section of Denial of service attack. >=20 > ok, agree >=20 >> o Removed sub-section Sequence Number Attack, which should be = more related >> to OLSRv2. >=20 > Why related only to the router do you mean that NHDP has no sequence > number, or its sequence numbers have no threats on the protocol? > please advise, In fact, it's because sequence number is normally not used in HELLO = message.=20 >=20 >> o some text on the assumption & scope of the document. >>=20 >> I would like to thank again for the comments from the WG. Further = comments >> are always appreciated. >=20 > Thanks to the update, but I recommend you mention thanks into the > document, which has no acknowledgements :) Thanks for the reminder. I think for a document at its very early = revision, it's normal that the acknowledgements section is not included.=20= It will be added in the future, and all the major contributors will be = acknowledged, according to RFC 3978.=20 best Jiazi=20 >=20 > AB From adrian@olddog.co.uk Sat Feb 23 11:41:05 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EFC21F8E8B for ; Sat, 23 Feb 2013 11:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMzJleZgb1Jk for ; Sat, 23 Feb 2013 11:41:04 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id D1AB321F8E7E for ; Sat, 23 Feb 2013 11:41:03 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1NJf2Fs020883; Sat, 23 Feb 2013 19:41:02 GMT Received: from 950129200 (089144192111.atnat0001.highway.a1.net [89.144.192.111]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1NJf0Im020870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Feb 2013 19:41:01 GMT From: "Adrian Farrel" To: "'Thomas Heide Clausen'" References: <20130222112847.22275.38109.idtracker@ietfa.amsl.com> <206AD221-FBA1-4554-B17B-4E191C39BE6E@thomasclausen.org> In-Reply-To: <206AD221-FBA1-4554-B17B-4E191C39BE6E@thomasclausen.org> Date: Sat, 23 Feb 2013 19:41:00 -0000 Message-ID: <021601ce11fd$b69e7880$23db6980$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxDAZjuCGxduqF7CVn8q7dAXgVbwHiwMQVljLK8zA= Content-Language: en-gb Cc: draft-ietf-manet-olsrv2-metrics-rationale.all@tools.ietf.org, 'manet List' Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 19:41:05 -0000 Hi Thomas, Thanks for the update. I've been through the diff and (as noted by some others) the changes look reasonable. >From my original review there were a couple of points where you didn't make changes, and didn't make any comments to me or on the list. This is not a big deal (as my comments were largely for discussion), but for cleanliness, I'll make some statements on the list here, and you can disagree or let them stand: --- > I wonder whether you want to make any comments about node > metrics. Obviously, you don't have them (neighbor metrics being > a different thing), but you could comment on why you don't have > them (if this was ever discussed). > > The question is slightly touched on in 5.2 in discussion of "delay". The issue was never discussed as an idea for inclusion in OLSRv2, and while node metrics could be added in the future, there was no suggestion that there is a requirement. Thus, there is no reason to add any notes on node metrics to this document. --- > Section 8 > > Were there any security considerations that cropped up while > designing metric support in OSLRv2? If so, here would be the > place to mention them. Security issues arising from the inclusion of metrics in OLSRv2 did not get any specific discussion. Since OLSRv2 has its own security considerations to cover the whole protocol, there is nothing further to say in this document. --- If you have any responses to these points that need to be addressed in the text, we can handle it in IETF last call which I will start with no further (well, you know, real time and all that) delay. Cheers, Adrian > -----Original Message----- > From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] > Sent: 22 February 2013 11:37 > To: manet List > Cc: Adrian Farrel > Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt > > Just a heads up. This review folds in a couple of suggestions that our AD made > from his review. In summary, it amounts to a sentence in the abstract and a > paragraph in the introduction explaining the motivation for publishing this > document, plus a couple of nits that he caught (thanks!). > > Thank you, Adrian, for your review and assistance on this matter > > For the authors, > > Thomas > > On Feb 22, 2013, at 12:28 , internet-drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Mobile Ad-hoc Networks Working Group of the > IETF. > > > > Title : Link Metrics for the Mobile Ad Hoc Network (MANET) Routing > Protocol OLSRv2 - Rationale > > Author(s) : Christopher Dearlove > > Thomas Heide Clausen > > Philippe Jacquet > > Filename : draft-ietf-manet-olsrv2-metrics-rationale-02.txt > > Pages : 29 > > Date : 2013-02-22 > > > > Abstract: > > OLSRv2 includes the ability to assign metrics to links and to use > > those metrics to allow routing by other than minimum hop count > > routes. This document provides a historic record of the rationale > > for, and design considerations behind, how link metrics were included > > in OLSRv2. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-metrics-rationale-02 > > > > > > 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 abdussalambaryun@gmail.com Sat Feb 23 16:35:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAF821F8EC5 for ; Sat, 23 Feb 2013 16:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5cvFjcezbKB for ; Sat, 23 Feb 2013 16:35:02 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3FED421F8E9A for ; Sat, 23 Feb 2013 16:35:02 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id kp6so1113595pab.8 for ; Sat, 23 Feb 2013 16:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oLDMLTYYalzChrAc7TI2V+gPBWQjbi3y04IckoiVxj8=; b=tVEWtTxPiTB6s80FbiQtDDWAMYZJaD5qEgCAVnpGSPJGaBRLhBk2tDpucJztnmJfz/ JhDkB+fxvWxysoTjdV20pft4rcn16948ZdSJDdTsmrdI4X8gDgLclPE/gqP9lqYzxZ2x X2frUZSbvuD1h20dYbHMNcvz3vWotZOCGhnfVc5IIjL5hFEaCP07Suqu6e5LdKB4lG78 SRcow9jvh6HgfgiCd4X4kBCRP2tLSz6R1uEVRiFVpSykrIimOsFQWs8Y780zzEoF0o9E Pj7dLPHUxrmqfJmZx5Z4Lxq8IKhzC8457KDmb0KK77SmCtS/ZT2/0XImYrG8OUCt7RjY lqqQ== MIME-Version: 1.0 X-Received: by 10.68.143.40 with SMTP id sb8mr10696001pbb.202.1361666100957; Sat, 23 Feb 2013 16:35:00 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sat, 23 Feb 2013 16:35:00 -0800 (PST) In-Reply-To: <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Sun, 24 Feb 2013 01:35:00 +0100 Message-ID: From: Abdussalam Baryun To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 00:35:03 -0000 Hi Jiazi So I understand that you state if there is an attack on the sequence number in the packet/message, there is no threat on the NHDP, AB On 2/23/13, Jiazi Yi wrote: > Hi, > > On Feb 23, 2013, at 5:16 PM, Abdussalam Baryun > wrote: > >> On 10/23/12, Jiazi YI wrote: >>> Dear all, >>> >>> The new revision of the WG document draft-ietf-manet-nhdp-sec-threats >>> has >>> addressed most of the comments from the WG. >>> >>> The main changes include: >>> >>> o Take the misconfiguration of NHDP routers into consideration. >>> o Added a sub-section of Denial of service attack. >> >> ok, agree >> >>> o Removed sub-section Sequence Number Attack, which should be more >>> related >>> to OLSRv2. >> >> Why related only to the router do you mean that NHDP has no sequence >> number, or its sequence numbers have no threats on the protocol? >> please advise, > > In fact, it's because sequence number is normally not used in HELLO message. > > >> >>> o some text on the assumption & scope of the document. >>> >>> I would like to thank again for the comments from the WG. Further >>> comments >>> are always appreciated. >> >> Thanks to the update, but I recommend you mention thanks into the >> document, which has no acknowledgements :) > > Thanks for the reminder. I think for a document at its very early revision, > it's normal that the acknowledgements section is not included. > It will be added in the future, and all the major contributors will be > acknowledged, according to RFC 3978. > > best > > Jiazi > >> >> AB > > From ulrich@herberg.name Sun Feb 24 00:31:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E84521F8934 for ; Sun, 24 Feb 2013 00:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRrJEf+Yj12U for ; Sun, 24 Feb 2013 00:31:07 -0800 (PST) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB9F21F861C for ; Sun, 24 Feb 2013 00:31:06 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id fl17so1212897vcb.41 for ; Sun, 24 Feb 2013 00:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q1dfEW1s1PIwGxoNS1AzOHtToeWz3/xVEtWZ19odIJ0=; b=Aj+xZiwJ6VLHEhvhRWahsHqBTAAlpB769y6jAGmaGOWhsIfH510StveAZJWyA2YS+4 uJro0d2kt8kLEztAQqJFi50NLxiLjIS9AT5SwFPDsvwilb+jJA/lzT1pvlMp2Y2L7mbO ij0LA3urATbWzlp2ICaQhjGwrtaabp3PVBFfo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=q1dfEW1s1PIwGxoNS1AzOHtToeWz3/xVEtWZ19odIJ0=; b=nZVgxQyH22EyrsiiXpry+RmHCluzbPlRmQ4bG3xyWZFfZ3dMzPoPPNH3zcsFbcFg/j 5MKvfoqiS+ISr75hwmjOir6d7ha/Cqc6wM8zStYkWkSa3iiO4OQfsUaaQAm0PZuX2aIG kbyzhWbEsF47B2vHN6LgnPjIqvPScM28xtW+2krfVeCqlS6AhLcihRYTge3WXdMsO8dn CTMLgy0XbjMcZv8+6KphACP2OFS8bYWX+azeqd/j2iNvMh1yi3UzCxxDqHwiOAdzcUMv 3a5R6xftrfv2Ce0X50usPqJt9ucvKiykIgtRlY0EE2fMBa+xpQ2A95MgHa5W2TwFYLAN WjTw== MIME-Version: 1.0 X-Received: by 10.52.32.230 with SMTP id m6mr7253567vdi.83.1361694666291; Sun, 24 Feb 2013 00:31:06 -0800 (PST) Received: by 10.220.107.7 with HTTP; Sun, 24 Feb 2013 00:31:06 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Sun, 24 Feb 2013 00:31:06 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=bcaec517c4b2e0975504d6743e9c X-Gm-Message-State: ALoCoQm2XYFJ93FoHLShSuF6Q0IKd685KnGOb3rPDBkgktMHqur1FjDf9+6K7RLBDY/GR2t9X+0m Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 08:31:08 -0000 --bcaec517c4b2e0975504d6743e9c Content-Type: text/plain; charset=ISO-8859-1 AB, packet sequence numbers are irrelevant for NHDP because they are used on a lower layer (RFC5444 multiplexer). Message sequence numbers don't matter for NHDP because HELLO sequence numbers are not recorded (like TC messages in the "Received Set" in OLSRv2). So there is no such DoS attack possible in NHDP. Ulrich On Sat, Feb 23, 2013 at 4:35 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Jiazi > > So I understand that you state if there is an attack on the sequence > number in the packet/message, there is no threat on the NHDP, > > AB > > On 2/23/13, Jiazi Yi wrote: > > Hi, > > > > On Feb 23, 2013, at 5:16 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> > > wrote: > > > >> On 10/23/12, Jiazi YI wrote: > >>> Dear all, > >>> > >>> The new revision of the WG document draft-ietf-manet-nhdp-sec-threats > >>> has > >>> addressed most of the comments from the WG. > >>> > >>> The main changes include: > >>> > >>> o Take the misconfiguration of NHDP routers into consideration. > >>> o Added a sub-section of Denial of service attack. > >> > >> ok, agree > >> > >>> o Removed sub-section Sequence Number Attack, which should be more > >>> related > >>> to OLSRv2. > >> > >> Why related only to the router do you mean that NHDP has no sequence > >> number, or its sequence numbers have no threats on the protocol? > >> please advise, > > > > In fact, it's because sequence number is normally not used in HELLO > message. > > > > > >> > >>> o some text on the assumption & scope of the document. > >>> > >>> I would like to thank again for the comments from the WG. Further > >>> comments > >>> are always appreciated. > >> > >> Thanks to the update, but I recommend you mention thanks into the > >> document, which has no acknowledgements :) > > > > Thanks for the reminder. I think for a document at its very early > revision, > > it's normal that the acknowledgements section is not included. > > It will be added in the future, and all the major contributors will be > > acknowledged, according to RFC 3978. > > > > best > > > > Jiazi > > > >> > >> AB > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec517c4b2e0975504d6743e9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AB,

packet sequence numbers are irrelevant for NHDP because they are= used on a lower layer (RFC5444 multiplexer). Message sequence numbers don&= #39;t matter for NHDP because HELLO sequence numbers are not recorded (like= TC messages in the "Received Set" in OLSRv2). So there is no suc= h DoS attack possible in NHDP.

Ulrich

On Sat, Feb 23, 2013 at 4:35 P= M, Abdussalam Baryun <abdussalambaryun@gmail.com> w= rote:
Hi Jiazi

So I understand that you state if there is an attack on the sequence
number in the packet/message, there is no threat on the NHDP,

AB

On 2/23/13, Jiazi Yi <ietf@jiaziyi.c= om> wrote:
> Hi,
>
> On Feb 23, 2013, at 5:16 PM, Abdussalam Baryun <abdussalambaryun@gmail.com>
> wrote:
>
>> On 10/23/12, Jiazi YI <ietf= @jiaziyi.com> wrote:
>>> Dear all,
>>>
>>> The new revision of the WG document draft-ietf-manet-nhdp-sec-= threats
>>> has
>>> addressed most of the comments from the WG.
>>>
>>> The main changes include:
>>>
>>> =A0 =A0 o Take the misconfiguration of NHDP routers into consi= deration.
>>> =A0 =A0 o Added a sub-section of Denial of service attack.
>>
>> ok, agree
>>
>>> =A0 =A0 o Removed sub-section Sequence Number Attack, which sh= ould be more
>>> related
>>> to OLSRv2.
>>
>> Why related only to the router do you mean that NHDP has no sequen= ce
>> number, or its sequence numbers have no threats on the protocol? >> please advise,
>
> In fact, it's because sequence number is normally not used in HELL= O message.
>
>
>>
>>> =A0 =A0 o some text on the assumption & scope of the docum= ent.
>>>
>>> I would like to thank again for the comments from the WG. Furt= her
>>> comments
>>> are always appreciated.
>>
>> Thanks to the update, but I recommend you mention thanks into the<= br> >> document, which has no acknowledgements :)
>
> Thanks for the reminder. I think for a document at its very early revi= sion,
> it's normal that the acknowledgements section is not included.
> It will be added in the future, and all the major contributors will be=
> acknowledged, according to RFC = 3978.
>
> best
>
> Jiazi
>
>>
>> AB
>
>
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec517c4b2e0975504d6743e9c-- From abdussalambaryun@gmail.com Sun Feb 24 02:12:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55E621F9016 for ; Sun, 24 Feb 2013 02:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpP1XQJ1b2xt for ; Sun, 24 Feb 2013 02:12:12 -0800 (PST) Received: from mail-we0-x230.google.com (we-in-x0230.1e100.net [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id EA62421F9019 for ; Sun, 24 Feb 2013 02:12:11 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so1700420wey.35 for ; Sun, 24 Feb 2013 02:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7Xm1GCnno4uQTSGvfgqtDb51C7m/ZDX70AX91jbMBAs=; b=A19DfQoUGZ5TaZ/OMnzNQF84vG+Le6bcvTVIbNmUENfvpcSwZVN5GJWYT9D5SzSh88 Yv1+Vqr4Dr915vQGEBYtWUvnqCB0MFVwrY74wQesvVZW+jneh+Vg3b7vu+kMby/63eFM YKj01a2ctjPYXDq6QA05vFJlzSYfDS7fi8Qe4JxmUL7ZNO47gx2zqV8HnmmRMXNc4erv xfXMTEXj2ds5MKI1uQaiURecM86DUBbWtziLrcGRCObRC0cDUtQOY1IEAcKq3c73a7OT ZGJbUDPXwsZO328EaLAc0hKFLxRh4wlul8sPVoZl82U62Oq0Y4q/2krbGh8aT1WL5oz3 W1LQ== MIME-Version: 1.0 X-Received: by 10.180.94.69 with SMTP id da5mr6042851wib.30.1361700722734; Sun, 24 Feb 2013 02:12:02 -0800 (PST) Received: by 10.180.101.70 with HTTP; Sun, 24 Feb 2013 02:12:02 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Sun, 24 Feb 2013 11:12:02 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 10:12:13 -0000 Hi Ulrich, Usually in reactive protocols sequence number is very important in nieghbor discovery, and maybe also in proactive. In RFC6130-section14.4 it states an affect as below (may be a threat); [RFC6130] 14.4 Updating Link Quality A router MAY update link quality based on any information available to it. Particular cases that MAY be used include: [I include only one from list related] o Receipt or loss of control packets. If control packets include a sequential packet sequence number, as defined in [RFC5444], then link quality can be updated when a control packet is received, whether or not it contains a HELLO message. The link quality may then, for example, be based on whether the last N out of M control packets on the link were received, or may use a "leaky integrator" tracking packet reception and loss. [AB] So I feel that the input of John regarding sequencing MAY be related to NHDP, it changes link quality, AB On 2/24/13, Ulrich Herberg wrote: > AB, > > packet sequence numbers are irrelevant for NHDP because they are used on a > lower layer (RFC5444 multiplexer). Message sequence numbers don't matter > for NHDP because HELLO sequence numbers are not recorded (like TC messages > in the "Received Set" in OLSRv2). So there is no such DoS attack possible > in NHDP. > > Ulrich > > On Sat, Feb 23, 2013 at 4:35 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Jiazi >> >> So I understand that you state if there is an attack on the sequence >> number in the packet/message, there is no threat on the NHDP, >> >> AB From ulrich@herberg.name Sun Feb 24 02:31:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D0D21F901C for ; Sun, 24 Feb 2013 02:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaRG7wqVGo03 for ; Sun, 24 Feb 2013 02:31:53 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6D38B21F9019 for ; Sun, 24 Feb 2013 02:31:53 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so1225695vba.13 for ; Sun, 24 Feb 2013 02:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=H+8q2gfZ1So4PXgt6GugsjN2a2briki94mHrI3pr1Zg=; b=JRUrIY4s8hd4h9dbpCxoVS+p6PxtBZmOzfPvaJzK8y14aZG/xpl9/22a151OUD5BLr h83Q10MT69PpIcy6iN8xlrIC29eSWr7jORTOSOricL4XsBMkN069DhcmRc7Eym6tW/Ry /ua5U6d48AwdunlTTc+Zrq+den0WNRBseQQlw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=H+8q2gfZ1So4PXgt6GugsjN2a2briki94mHrI3pr1Zg=; b=L4LYgKqIcOBUjM5Cu3PB+qBAOmGyuha8m/chbVYpn8Alqi92wx8wRux7EH3nKI55/L z8X5xGrFh9JVX5ZjAK37cIjrf7lJRUZXnOfaBmdupwpBlqjJDgocdr3OD3guVtRjRRm1 HXrqz4ye/PXKcqQx5N+UkbKdVdj4HR4LztBFLK2STAkStGwHbWJPYtx5ldDyqSHmZHic YOzfnGCM1ndFdcugzcIfUn7GL3xOLgfdlZdel9M+ieSUVbnXyLTCi+9bIp2mJ+WkKa3A DqgX9qX+iBR0mla9LOfvQqz2TGTCrn/TIit6foApyJ4DKmG9lZagOCqel0MPiPnNZkg9 YShg== MIME-Version: 1.0 X-Received: by 10.52.29.116 with SMTP id j20mr7711022vdh.16.1361701912706; Sun, 24 Feb 2013 02:31:52 -0800 (PST) Received: by 10.220.107.7 with HTTP; Sun, 24 Feb 2013 02:31:52 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Sun, 24 Feb 2013 02:31:52 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=20cf3079b792cc1c2804d675ee07 X-Gm-Message-State: ALoCoQlm4583N0aL0DlxR+lq05vsbps4Y3wNz2rmB92uCCflKGP5uKIqI4Pmav+xq3aLq85MVZZ8 Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 10:31:54 -0000 --20cf3079b792cc1c2804d675ee07 Content-Type: text/plain; charset=ISO-8859-1 AB, On Sun, Feb 24, 2013 at 2:12 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Ulrich, > > Usually in reactive protocols sequence number is very important in > nieghbor discovery, and maybe also in proactive. It is not used by NHDP, though. It is not mandated to use the message sequence number, and it is not used a single time in the normative part of the document. > In > RFC6130-section14.4 it states an affect as below (may be a threat); > > [RFC6130] > 14.4 Updating Link Quality > A router MAY update link quality based on any information available > to it. Particular cases that MAY be used include: > > [I include only one from list related] > > o Receipt or loss of control packets. If control packets include a > sequential packet sequence number, as defined in [RFC5444], then > link quality can be updated when a control packet is received, > whether or not it contains a HELLO message. The link quality may > then, for example, be based on whether the last N out of M control > packets on the link were received, or may use a "leaky integrator" > tracking packet reception and loss. > > [AB] > So I feel that the input of John regarding sequencing MAY be related > to NHDP, it changes link quality, > This is non normative part of NHDP, thus I don't think it can be a threat to NHDP itself. If someone implements (or specifies in a document) such a mechanism (that is purely given as example in RFC6130), then maybe that can be considered a threat to that implementation or document. For such a mechanism (again, outside of the normative part of RFC6130) that uses lost packets for link quality calculation, an attacker could spoof another router's address and increase link quality by sending many packets. I don't think that's a very efficient attack though. Ulrich > > AB > > On 2/24/13, Ulrich Herberg wrote: > > AB, > > > > packet sequence numbers are irrelevant for NHDP because they are used on > a > > lower layer (RFC5444 multiplexer). Message sequence numbers don't matter > > for NHDP because HELLO sequence numbers are not recorded (like TC > messages > > in the "Received Set" in OLSRv2). So there is no such DoS attack possible > > in NHDP. > > > > Ulrich > > > > On Sat, Feb 23, 2013 at 4:35 PM, Abdussalam Baryun < > > abdussalambaryun@gmail.com> wrote: > > > >> Hi Jiazi > >> > >> So I understand that you state if there is an attack on the sequence > >> number in the packet/message, there is no threat on the NHDP, > >> > >> AB > --20cf3079b792cc1c2804d675ee07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AB,

On Sun, Feb 24, 2013 at 2:12 AM, Abdu= ssalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi Ulrich,

Usually in reactive protocols sequence number is very important in
nieghbor discovery, and maybe also in proactive.

It is= not used by NHDP, though. It is not mandated to use the message sequence n= umber, and it is not used a single time in the normative part of the docume= nt.

=A0
In
RFC6130-section14.4 it states an affect as below (may be a threat);

[RFC6130]
14.4 Updating Link Quality
A router MAY update link quality based on any information available
to it. Particular cases that MAY be used include:

[I include only one from list related]

o Receipt or loss of control packets. If control packets include a
sequential packet sequence number, as defined in [RFC5444], then
link quality can be updated when a control packet is received,
whether or not it contains a HELLO message. The link quality may
then, for example, be based on whether the last N out of M control
packets on the link were received, or may use a "leaky integrator"= ;
tracking packet reception and loss.

[AB]
So I feel that the input of John regarding sequencing MAY be related
to NHDP, it changes link quality,


This is non = normative part of NHDP, thus I don't think it can be a threat to NHDP i= tself. If someone implements (or specifies in a document) such a mechanism = (that is purely given as example in RFC6130), then maybe that can be consid= ered a threat to that implementation or document.

For such a mechanism (again, outside of the normative part of RFC6130) = that uses lost packets for link quality calculation, an attacker could spoo= f another router's address and increase link quality by sending many pa= ckets. I don't think that's a very efficient attack though.

Ulrich

=A0

AB

On 2/24/13, Ulrich Herberg <ulric= h@herberg.name> wrote:
> AB,
>
> packet sequence numbers are irrelevant for NHDP because they are used = on a
> lower layer (RFC5444 multiplexer). Message sequence numbers don't = matter
> for NHDP because HELLO sequence numbers are not recorded (like TC mess= ages
> in the "Received Set" in OLSRv2). So there is no such DoS at= tack possible
> in NHDP.
>
> Ulrich
>
> On Sat, Feb 23, 2013 at 4:35 PM, Abdussalam Baryun <
> abdussalambaryun@gmail.c= om> wrote:
>
>> Hi Jiazi
>>
>> So I understand that you state if there is an attack on the sequen= ce
>> number in the packet/message, there is no threat on the NHDP,
>>
>> AB

--20cf3079b792cc1c2804d675ee07-- From abdussalambaryun@gmail.com Sun Feb 24 05:20:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10A221F8FAB for ; Sun, 24 Feb 2013 05:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0IBne9Szpqi for ; Sun, 24 Feb 2013 05:20:47 -0800 (PST) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 50C6E21F8F98 for ; Sun, 24 Feb 2013 05:20:47 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rp2so1206984pbb.6 for ; Sun, 24 Feb 2013 05:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZemIHUl99s69NoFSj/zx8f8gM5j8DCuBO2aWjCEX0FY=; b=d9aN32ai6KFPwIPU9BG0W5sDAr/8FI6cEEFfjWeLUKq8MG0rXx9tO+KhodQr4xfV/S onANVMUoGTPPYd7Io9HZZsXi8aHhKLcVkmuQbrRd9qYAt4n8UPijiEuafHVEmC5Jjb4R tWVQnNwMIaViYtW8f5DyQwZSoyQJPUPXHR0qvmxTyu2dfqLrF4Nq/0liEbPDS5ME1u7J NLlLbGLQUxvBWdxnjgN9VAmXDf10OseH7BZLP+nAMoi+kxEGT627fr6Crl8tr7rqVLgC grrj3cMqtkPPDU38LJHCTpdc/Oy9OhrhiFkWClHSCG1skWGD3+gOxQwVekED4EXjxchh ftPQ== MIME-Version: 1.0 X-Received: by 10.66.13.74 with SMTP id f10mr13908428pac.202.1361712047032; Sun, 24 Feb 2013 05:20:47 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sun, 24 Feb 2013 05:20:46 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Sun, 24 Feb 2013 13:20:46 +0000 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=bcaec520e62fd98a7004d6784a16 Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 13:20:48 -0000 --bcaec520e62fd98a7004d6784a16 Content-Type: text/plain; charset=ISO-8859-1 Hi Ulrich, comments below, On Sun, Feb 24, 2013 at 10:31 AM, Ulrich Herberg wrote: > AB, > This is non normative part of NHDP, thus I don't think it can be a threat > to NHDP itself. If someone implements (or specifies in a document) such a > mechanism (that is purely given as example in RFC6130), then maybe that can > be considered a threat to that implementation or document. > > I don't know what you mean by normative part if nothing in the document mentions norm-partitions of the documents, there are sections, and no text mentions that this is normative and this is not normative (my speculate or understanding). I believe that section 14 is important to NHDP and we should not ignore. Regarding implementation, John input [1] already mentioned in his input the implementation issue is not considered in the threat doc, why the authors don't include it if you now stating that a threat may occur with such implementation, > For such a mechanism (again, outside of the normative part of RFC6130) > that uses lost packets for link quality calculation, an attacker could > spoof another router's address and increase link quality by sending many > packets. I don't think that's a very efficient attack though. > > but you do think it is an attack. Please note that IMHO; the NHDP can be implemented with thoes mechanism the RFC6130 does not exclude them from its function. [1] http://www.ietf.org/mail-archive/web/manet/current/msg13286.html AB --bcaec520e62fd98a7004d6784a16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ulrich,
=A0
comments below,
On Sun, Feb 24, 2013 at 10:31 AM, Ulrich Herberg <ulric= h@herberg.name> wrote:
AB,
This is non normati= ve part of NHDP, thus I don't think it can be a threat to NHDP itself. = If someone implements (or specifies in a document) such a mechanism (that i= s purely given as example in RFC6130), then maybe that can be considered a = threat to that implementation or document.

I don't know what you mean by normati= ve part if nothing in the document mentions norm-partitions of the document= s, there are sections, and no text mentions that this is normative and this= is not normative (my speculate or understanding). I believe that section 1= 4 is important to NHDP and we should not ignore.
Regarding implementation, John input [1] already mentioned in hi= s input the implementation issue is not considered in the threat doc, why t= he authors don't include it=A0if you now stating that a threat may occu= r with such implementation,
=A0
For such a m= echanism (again, outside of the normative part of RFC6130) that uses lost p= ackets for link quality calculation, an attacker could spoof another router= 's address and increase link quality by sending many packets. I don'= ;t think that's a very efficient attack though.
=A0
but you do think it is an attack.=A0P= lease note that IMHO; the NHDP can be implemented with thoes mechanism the = RFC6130 does not exclude them from its function.
=A0

--bcaec520e62fd98a7004d6784a16-- From abdussalambaryun@gmail.com Sun Feb 24 05:35:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA53321F8E6A for ; Sun, 24 Feb 2013 05:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPbZ6Ly8zQBO for ; Sun, 24 Feb 2013 05:35:07 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3B59421F8E3A for ; Sun, 24 Feb 2013 05:35:07 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id xa12so1216582pbc.36 for ; Sun, 24 Feb 2013 05:35:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ngi1kc9L1tpUreN8IMqBsCm6abZoIFFQyGMVW2WathM=; b=GvPXw1FJxw7wyAITXKV+Z8XxsxqcVC59vGEH6TZKcttriFnG3w1zvX2DDGbcr0WFzr 5ADxIQ474ePH16xBX48NnFGJgWku2SiEcXADpYtFdU4h7O3xbOs2mQDQuxbQ5yoc6IUm v9MeLfEeYdLDFQvzuzAoJfOgKipNWPOquP2FI/4P4oH7xGSAtHZRe2DsODy0hxpULLi2 PFAHjkN9O7wzYQF9+yPRc/Z60VVf6kO7l/hm2J5gpgvdudPJkGesnNyMQbYI7dhnbsw9 G3/WzldpLrfP4faJW12UdIsUkKz5rFVHXxO12fmp6/GEB/AXOT62qyJQzt6BbsdDqkfV 0YWQ== MIME-Version: 1.0 X-Received: by 10.68.143.40 with SMTP id sb8mr12993375pbb.202.1361712906988; Sun, 24 Feb 2013 05:35:06 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sun, 24 Feb 2013 05:35:06 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Sun, 24 Feb 2013 13:35:06 +0000 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=047d7b2e42a21b6be804d6787ead Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 13:35:08 -0000 --047d7b2e42a21b6be804d6787ead Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 24, 2013 at 10:31 AM, Ulrich Herberg wrote: > AB, > > On Sun, Feb 24, 2013 at 2:12 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Ulrich, >> >> Usually in reactive protocols sequence number is very important in >> nieghbor discovery, and maybe also in proactive. > > > It is not used by NHDP, though. It is not mandated to use the message > sequence number, and it is not used a single time in the normative part of > the document. > > I think it MAY be used sequence number (SQN) by NHDP [RFC6130], so the NHDP can depend on it. I don't care her about mandates items, because this protocol is a general use by MANET so it cannot mandate every thing, it should be flexible. I care now about the RFC6130 does not exclude the *USE* of SQNs in Packet/Message, as we can see from section 14 and others. AB +++++++++++++++++++ If I am wrong please advise. Please note that the above is the poster understanding (we never claim that we are always right, nor does any IETF participants) from reading RFC6130 and the subject WGLC draft. --047d7b2e42a21b6be804d6787ead Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Feb 24, 2013 at 10:31 AM, Ulrich= Herberg <ulrich@herberg.name> wrote:
AB,

On Sun, Feb 24, 201= 3 at 2:12 AM, Abdussalam Baryun <abdussalambaryun@gmail.com&g= t; wrote:
Hi Ulrich,

Usually in reactive protocols sequence number is very important in
nieghbor discovery, and maybe also in proactive.
It is not used by NHDP, though. It is not mandated to use the message sequ= ence number, and it is not used a single time in the normative part of the = document.
=A0
=A0
I think it MAY be= used sequence number (SQN) by NHDP [RFC6130], so the NHDP can depend on it= . I don't care her about mandates items,=A0because this protocol is a g= eneral use by MANET so it cannot mandate every thing, it should be flexible= .=A0 I care now about =A0the RFC6130 does not exclude the *USE* of SQNs in = Packet/Message, as we can see from section 14 and others.
=A0
AB
+++++++++++++++++++
If I am wrong= please advise. Please note that the above is the=A0poster understanding (w= e never claim that we are always right, nor does any IETF participants) fro= m reading RFC6130 and the subject WGLC draft.
=A0
--047d7b2e42a21b6be804d6787ead-- From hrogge@googlemail.com Sun Feb 24 14:01:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4B521F9109 for ; Sun, 24 Feb 2013 14:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hR+QCB01P73 for ; Sun, 24 Feb 2013 14:01:37 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4901021F90EC for ; Sun, 24 Feb 2013 14:01:37 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id gg6so1806169lbb.13 for ; Sun, 24 Feb 2013 14:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=YFM+GNXiV+36kZ0QcXyJXhSOtzZtqa7WGO9zgG/Sm4g=; b=WmCe+bV9TghRJCwhlXydj6mGmBCTaPOFM1sl6cY3E64Peb6t1Q3irnaJiHwk5dAk/f Iop/hrcF3EermgTkFgYCIMGtqKs1FxKgrX84X0AHzvqSgIOnqXcnDDek+HisknuKJi4G E37j89dg5fnO6TiW3cC4104xW6EhZSfZNEkJidS2rU2brjcHrHRanilFGqrahgD8zzK6 STDU1s8pqHLTxrp6ATpRfOSobHkxqbUqkYiVkAxig+pHg46S82jlw6/c8eivcLazm9GP HjTtvDFUi0tNX9nhk5e0D4mNCsPKEPX60nrpAdR0NMkxsBOIYuSaNQoOnNJu/LvRNQuD q0Dw== X-Received: by 10.152.102.177 with SMTP id fp17mr8078828lab.0.1361743296181; Sun, 24 Feb 2013 14:01:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Sun, 24 Feb 2013 14:01:16 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> From: Henning Rogge Date: Sun, 24 Feb 2013 23:01:16 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 22:01:38 -0000 On Sun, Feb 24, 2013 at 2:35 PM, Abdussalam Baryun wrote: > I think it MAY be used sequence number (SQN) by NHDP [RFC6130], so the NHDP > can depend on it. I don't care her about mandates items, because this > protocol is a general use by MANET so it cannot mandate every thing, it > should be flexible. I care now about the RFC6130 does not exclude the > *USE* of SQNs in Packet/Message, as we can see from section 14 and others. RFC5444 is designed as a very flexible and easily extendable format. If we include everything into the NHDP-threat document that MAY be used in a NHDP implementation but is out of scope of the normative sections, the threat document might become VERY long. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From ulrich@herberg.name Sun Feb 24 14:20:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033CC21F8EB2 for ; Sun, 24 Feb 2013 14:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyYbkZs8Go8K for ; Sun, 24 Feb 2013 14:20:23 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id 995D921F8EB0 for ; Sun, 24 Feb 2013 14:20:23 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id l22so1422136vbn.0 for ; Sun, 24 Feb 2013 14:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Falb3wXtIuKvJgQ/07bozBxspqLmiXm/Jch3MPrP/Ng=; b=CE5UIT53svcYcOGdehhPpsA3LNyIKcbLkHbRsoFx+rS6JGFjTxi7YgFn5l8j9565kD rOIrdkVy9rn4HlwJQBXnJrg3oAZLtDyYPG6jM4rfrepXagqiwSAKjc2y8LCbZFt0+dUj iEiq+FJsKHWptUWasHg6ZdIDiCDxnsUtpIVgo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Falb3wXtIuKvJgQ/07bozBxspqLmiXm/Jch3MPrP/Ng=; b=iLguZ8upDhQ6B5osWCxy4+4BnQaamnfOnazFRpmMum7AVS7s2Z0OxUIuG+j68Agq+R CdqwbM48IzXd6SZpIlBQbk0OowaBVZDnZfgEb2qWLY6V6uhLUl1glkdnNDe7TczrVcqt SOYUHtIfcIFy75nrqixCAo7QoKY5wC+i37ZJvrybP0lNcchZg6NlOh7rOgfAk2MDoKf7 f4NkgEVE3ZO6f/qR6yO3ZXHcYoy6OvhyVn+8xy8tACBPfx1g4BHc/vUPJYTGRHVSAvN5 XrZhdV9F0dIPN8DGEYQ5WI8AVrC9EuWIbHm6g9Mqa4BTTY/SHdnIwd9R/57+b6G6SQji llhQ== MIME-Version: 1.0 X-Received: by 10.58.45.168 with SMTP id o8mr5886468vem.3.1361744422858; Sun, 24 Feb 2013 14:20:22 -0800 (PST) Received: by 10.220.107.7 with HTTP; Sun, 24 Feb 2013 14:20:22 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Sun, 24 Feb 2013 14:20:22 -0800 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: multipart/alternative; boundary=089e01182a5899c5eb04d67fd4e8 X-Gm-Message-State: ALoCoQkQe/aqN+AuyXPnUjMD3YLRCqSaMFFK0vQ5B8mf8x6ulzfsQTVLvRvCn4qsR33RYdgFSIv2 Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 22:20:25 -0000 --089e01182a5899c5eb04d67fd4e8 Content-Type: text/plain; charset=ISO-8859-1 AB, this part about link quality calculation is not normative, i.e., it does not mandate you "MUST do it exactly this way", but it is merely an example what could be done to calculate link quality (read: "The link quality may then, *for example*, be based on whether the last N out of M control packets on the link were received, or may use a "leaky integrator" tracking packet reception and loss.") Like Henning said, the draft would be of infinite length if I tried to predict what each implementer may add to the normative part of the protocol. Regards Ulrich On Sun, Feb 24, 2013 at 2:01 PM, Henning Rogge wrote: > On Sun, Feb 24, 2013 at 2:35 PM, Abdussalam Baryun > wrote: > > I think it MAY be used sequence number (SQN) by NHDP [RFC6130], so the > NHDP > > can depend on it. I don't care her about mandates items, because this > > protocol is a general use by MANET so it cannot mandate every thing, it > > should be flexible. I care now about the RFC6130 does not exclude the > > *USE* of SQNs in Packet/Message, as we can see from section 14 and > others. > > RFC5444 is designed as a very flexible and easily extendable format. > > If we include everything into the NHDP-threat document that MAY be > used in a NHDP implementation but is out of scope of the normative > sections, the threat document might become VERY long. > > Henning Rogge > -- > We began as wanderers, and we are wanderers still. We have lingured > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > --089e01182a5899c5eb04d67fd4e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AB,

this part about link quality calculation is not normative, i.e.,= it does not mandate you "MUST do it exactly this way", but it is= merely an example what could be done to calculate link quality (read: &quo= t;The link quality may then, for example, be based on whether the last N out of M con= trol packets on the link were received, or may use a "leaky integrato= r" tracking packet reception and loss.")

Like Henning said, = the draft would be of infinite length if I tried to predict what each imple= menter may add to the normative part of the protocol.


Regards Ulrich

On Sun, Feb 24, 2013 at 2:01 PM, H= enning Rogge <hrogge@googlemail.com> wrote:
On Sun, Feb 24, 2013 at 2:35 PM, Abdussalam Baryun
<abdussalambaryun@gmail.co= m> wrote:
> I think it MAY be used sequence number (SQN) by NHDP [RFC6130], so the= NHDP
> can depend on it. I don't care her about mandates items, because t= his
> protocol is a general use by MANET so it cannot mandate every thing, i= t
> should be flexible. =A0I care now about =A0the RFC6130 does not exclud= e the
> *USE* of SQNs in Packet/Message, as we can see from section 14 and oth= ers.

RFC5444 is designed as a very flexible and easily extendable format.<= br>
If we include everything into the NHDP-threat document that MAY be
used in a NHDP implementation but is out of scope of the normative
sections, the threat document might become VERY long.

Henning Rogge
--
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

--089e01182a5899c5eb04d67fd4e8-- From abdussalambaryun@gmail.com Sun Feb 24 22:19:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E51C21F91AF for ; Sun, 24 Feb 2013 22:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMbBwBvmbgCw for ; Sun, 24 Feb 2013 22:19:21 -0800 (PST) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7825E21F91A3 for ; Sun, 24 Feb 2013 22:19:20 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id xb4so1483958pbc.1 for ; Sun, 24 Feb 2013 22:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LJgnTpevf25aQuYIKmVdyWinhq/aXNBDUw1KCpqsk48=; b=h266qcLfyIRu5VdjyRsAuWamdkhJsdG4JU1Un08BE1eYiWRIhENedFqNwwLv06Nz+q DeKDGk1Hx1IaSMUA7B51GKUWggqgE/tIjy0DBvtoRXFke6Whx5mtxWfnYtYvvZwodAEo yekAMVFF0ZUQkbjNRJoillD0EGYoge2b5rnF6B/3FYW1XoH9hwB4H5y0GXZWUtMZBUHa hrSoAup9LEm2/SyY8zYM1922z60T9+y+wufGfElB2gDfNLyAVdN+JSNg7be8CSC1DgvG udEE6sJLVLBWfN2zWsKKXfbPbdONTay5tMASl6k/26izANgdPMvucth0YoK4QUQ9wx9V nzXw== MIME-Version: 1.0 X-Received: by 10.66.158.2 with SMTP id wq2mr17204353pab.113.1361773160251; Sun, 24 Feb 2013 22:19:20 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sun, 24 Feb 2013 22:19:20 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Mon, 25 Feb 2013 07:19:20 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 06:19:23 -0000 Hi Ulrich and Henning My intentions was not about RFC5444 nor about making things long, it is about the RFC6130 job to backup routing and the threats to that job. We understand that RFC6130 is used most by the MANET routing protocols (OLSRv2, AODVv2, etc.), my point is why we don't mention in the document Sequence Number threat (mentioned in NHDP Hello Msg, but MAY be used by NHDP), while I think is important use in AODVv2 neighbor discovery. The document will not be long but reasonable if it considers all important threats affecting the NHDP job as a discovery for the routing protocol concerns (proactive and reactive). AB On 2/24/13, Ulrich Herberg wrote: > AB, > > this part about link quality calculation is not normative, i.e., it does > not mandate you "MUST do it exactly this way", but it is merely an example > what could be done to calculate link quality (read: "The link quality may > then, *for example*, be based on whether the last N out of M control > packets on the link were received, or may use a "leaky integrator" tracking > packet reception and loss.") > > Like Henning said, the draft would be of infinite length if I tried to > predict what each implementer may add to the normative part of the > protocol. > > > Regards > Ulrich > > On Sun, Feb 24, 2013 at 2:01 PM, Henning Rogge > wrote: > >> On Sun, Feb 24, 2013 at 2:35 PM, Abdussalam Baryun >> wrote: >> > I think it MAY be used sequence number (SQN) by NHDP [RFC6130], so the >> NHDP >> > can depend on it. I don't care her about mandates items, because this >> > protocol is a general use by MANET so it cannot mandate every thing, it >> > should be flexible. I care now about the RFC6130 does not exclude the >> > *USE* of SQNs in Packet/Message, as we can see from section 14 and >> others. >> >> RFC5444 is designed as a very flexible and easily extendable format. >> >> If we include everything into the NHDP-threat document that MAY be >> used in a NHDP implementation but is out of scope of the normative >> sections, the threat document might become VERY long. >> >> Henning Rogge >> -- >> We began as wanderers, and we are wanderers still. We have lingured >> long enough on the shores of the cosmic ocean. We are ready at last to >> set sail for the stars - Carl Sagan >> > From abdussalambaryun@gmail.com Sun Feb 24 23:12:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9291121F9202 for ; Sun, 24 Feb 2013 23:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+amanAFGX5U for ; Sun, 24 Feb 2013 23:12:03 -0800 (PST) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 109CA21F91F4 for ; Sun, 24 Feb 2013 23:12:03 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rp2so1515835pbb.20 for ; Sun, 24 Feb 2013 23:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=PWboIdnW+brG0RgSbhLFGo5l6PkxGckjyy6mQMqN5fE=; b=gUp1XREBHd3eH+O1zZ9TbIw/OBnBHdJ2T5RvoQn0FgmXCBOXYdDJ0JeEX+BVVyr2rO Nk6MFP1bXqmnb6R873LH5S7PzY1g7r9h4CEcxgr5cU+KaVfW0rfQM9DRI/g+fRVb0Rbg oamYTFyofv7ndK1otQ7VmypryEt8k6gv4iZ8uzQ47+0n94L2LKesznLpwLn4lnUClLgc ZpCEMuh6/gByHqm52yQlCUGnGdtwg7LlSr2fGWbrFQ2gG8LakJtYsQtbGQ5Aa5W3y4gO ux4I8eSaykdNfG8up1fr31j/A6h/YCYbZbzaTqpfwxPlwj+AX6XDfaWO/FjXlSRa4fhE BD3Q== MIME-Version: 1.0 X-Received: by 10.66.27.199 with SMTP id v7mr17072127pag.215.1361776322886; Sun, 24 Feb 2013 23:12:02 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sun, 24 Feb 2013 23:12:02 -0800 (PST) Date: Mon, 25 Feb 2013 08:12:02 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Advise to Participant Who is Editing the WG draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 07:12:03 -0000 Hi I got experience while in this WG that some drafts are very difficult to edit by WG participants (excluding authors) even though the draft were WG draft, it seems like it is authors' draft carying the name of the group. I think all participants should be involved and the WG editor to follow the WG decisions not the authors. In one draft of this group I could not even get a small text into the introduction which is strange strategy to me :( Some editors just change what they like without consulting the WG, is that right? others ask for discussion before and then make the change, AB From ulrich@herberg.name Sun Feb 24 23:12:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5899521F9209 for ; Sun, 24 Feb 2013 23:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSad4bpCnI-R for ; Sun, 24 Feb 2013 23:12:21 -0800 (PST) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id 2777521F920A for ; Sun, 24 Feb 2013 23:12:21 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id fs19so1520508vbb.2 for ; Sun, 24 Feb 2013 23:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5MhR8Me4np490WRASgHXFI+h3QEGP7MxLHXiYVgDO7A=; b=WmheDl95/wD/ZuUVLTSVwF+OxrN54gtpZI2D+0Qxm+6YVGrMUAoa9knZ2deOlfVUoA RFmJTcP4h7SvNXtNMroKq0EBtajoHoT9pWvL+UW7ILh1CB8dpSMTc2Yrqjc97a8kSt2v RnEB1HR4USxDnCXldEjD4IAg7We/tIPudarV4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=5MhR8Me4np490WRASgHXFI+h3QEGP7MxLHXiYVgDO7A=; b=PHs4nS/XOIhPcDT9GDT0aFF9gn4xaNfNDYJUaxTVD8h3BRlR50MH3Fk8De3KF/WY3Y PX+jnMWYPjkGo15ML+TvXwhX1DELEXT4yyt59CMq7lTxjDu8yJtUCQ5qDQggr8YsqcOM IVOxQsUIT0RgzeHlVY7QQ4n4VyouWTX5cyHk1Ub0EEZ6DCx5r+PFQt8G0KKE2+BnEhO2 yVqTzvuLLf+UM8g/ej2goxLYhoIONpt0lClmxFR0ep8KxpadwVkQsYtJw373LKw7R71k J6vFM/Rkp/zF50ieOzKU5b/Ch6M4U4ruogezXvGpe+VDvkyRLWaUJ08FLEUtXYk6yR/J rnRQ== MIME-Version: 1.0 X-Received: by 10.52.96.7 with SMTP id do7mr8023240vdb.115.1361776340567; Sun, 24 Feb 2013 23:12:20 -0800 (PST) Received: by 10.220.107.7 with HTTP; Sun, 24 Feb 2013 23:12:20 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Sun, 24 Feb 2013 23:12:20 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=20cf307ac8670b206b04d6874381 X-Gm-Message-State: ALoCoQnMAlA+9kpGNV9E+lRpviNZGPTXvYHGYf44uU25fJCn4ug/mJhfXKdLFKMjrCZWZBoIh2tZ Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 07:12:22 -0000 --20cf307ac8670b206b04d6874381 Content-Type: text/plain; charset=ISO-8859-1 AB, again, sequence numbers are not used by NHDP, therefore not a threat to NHDP. If another protocols uses that information, it may be a threat to that protocol, and may be documented in a security threats analysis for that protocol. It seems you are the only one advocating for changing the draft on this aspect. I will wait if someone else also asks for changes on this matter before changing it. Regards Ulrich On Sun, Feb 24, 2013 at 10:19 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Ulrich and Henning > > My intentions was not about RFC5444 nor about making things long, it > is about the RFC6130 job to backup routing and the threats to that > job. > > We understand that RFC6130 is used most by the MANET routing protocols > (OLSRv2, AODVv2, etc.), my point is why we don't mention in the > document Sequence Number threat (mentioned in NHDP Hello Msg, but MAY > be used by NHDP), while I think is important use in AODVv2 neighbor > discovery. > > The document will not be long but reasonable if it considers all > important threats affecting the NHDP job as a discovery for the > routing protocol concerns (proactive and reactive). > > AB > > On 2/24/13, Ulrich Herberg wrote: > > AB, > > > > this part about link quality calculation is not normative, i.e., it does > > not mandate you "MUST do it exactly this way", but it is merely an > example > > what could be done to calculate link quality (read: "The link quality may > > then, *for example*, be based on whether the last N out of M control > > packets on the link were received, or may use a "leaky integrator" > tracking > > packet reception and loss.") > > > > Like Henning said, the draft would be of infinite length if I tried to > > predict what each implementer may add to the normative part of the > > protocol. > > > > > > Regards > > Ulrich > > > > On Sun, Feb 24, 2013 at 2:01 PM, Henning Rogge > > wrote: > > > >> On Sun, Feb 24, 2013 at 2:35 PM, Abdussalam Baryun > >> wrote: > >> > I think it MAY be used sequence number (SQN) by NHDP [RFC6130], so the > >> NHDP > >> > can depend on it. I don't care her about mandates items, because this > >> > protocol is a general use by MANET so it cannot mandate every thing, > it > >> > should be flexible. I care now about the RFC6130 does not exclude > the > >> > *USE* of SQNs in Packet/Message, as we can see from section 14 and > >> others. > >> > >> RFC5444 is designed as a very flexible and easily extendable format. > >> > >> If we include everything into the NHDP-threat document that MAY be > >> used in a NHDP implementation but is out of scope of the normative > >> sections, the threat document might become VERY long. > >> > >> Henning Rogge > >> -- > >> We began as wanderers, and we are wanderers still. We have lingured > >> long enough on the shores of the cosmic ocean. We are ready at last to > >> set sail for the stars - Carl Sagan > >> > > > --20cf307ac8670b206b04d6874381 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AB,

again, sequence numbers are not used by NHDP, therefore not a th= reat to NHDP. If another protocols uses that information, it may be a threa= t to that protocol, and may be documented in a security threats analysis fo= r that protocol.

It seems you are the only one advocating for changing the draft on this= aspect. I will wait if someone else also asks for changes on this matter b= efore changing it.

Regards
Ulrich

On Sun, Feb 24, 2013 at 10:19 PM, Abdussalam Baryun <<= a href=3D"mailto:abdussalambaryun@gmail.com" target=3D"_blank">abdussalamba= ryun@gmail.com> wrote:
Hi Ulrich and Henning

My intentions was not about RFC5444 nor about making things long, it
is about the RFC6130 job to backup routing and the threats to that
job.

We understand that RFC6130 is used most by the MANET routing protocols
(OLSRv2, AODVv2, etc.), my point is why we don't mention in the
document Sequence Number threat (mentioned in NHDP Hello Msg, but MAY
be used by NHDP), while I think is important use in AODVv2 neighbor
discovery.

The document will not be long but reasonable if it considers all
important threats affecting the NHDP job as a discovery for the
routing protocol concerns (proactive and reactive).

AB

On 2/24/13, Ulrich Herberg <ulric= h@herberg.name> wrote:
> AB,
>
> this part about link quality calculation is not normative, i.e., it do= es
> not mandate you "MUST do it exactly this way", but it is mer= ely an example
> what could be done to calculate link quality (read: "The link qua= lity may
> then, *for example*, be based on whether the last N out of M con= trol
> packets on the link were recei= ved, or may use a "leaky integrator" tracking
> packet reception and loss.")
>
> Like Henning said, the draft would be of infinite length if I tried to=
> predict what each implementer may add to the normative part of the
> protocol.
>
>
> Regards
> Ulrich
>
> On Sun, Feb 24, 2013 at 2:01 PM, Henning Rogge
> <hrogge@googlemail.com= >wrote:
>
>> On Sun, Feb 24, 2013 at 2:35 PM, Abdussalam Baryun
>> <abdussalambaryun= @gmail.com> wrote:
>> > I think it MAY be used sequence number (SQN) by NHDP [RFC6130= ], so the
>> NHDP
>> > can depend on it. I don't care her about mandates items, = because this
>> > protocol is a general use by MANET so it cannot mandate every= thing, it
>> > should be flexible. =A0I care now about =A0the RFC6130 does n= ot exclude the
>> > *USE* of SQNs in Packet/Message, as we can see from section 1= 4 and
>> others.
>>
>> RFC5444 is designed as a very flexible and easily extendable forma= t.
>>
>> If we include everything into the NHDP-threat document that MAY be=
>> used in a NHDP implementation but is out of scope of the normative=
>> sections, the threat document might become VERY long.
>>
>> Henning Rogge
>> --
>> We began as wanderers, and we are wanderers still. We have lingure= d
>> long enough on the shores of the cosmic ocean. We are ready at las= t to
>> set sail for the stars - Carl Sagan
>>
>

--20cf307ac8670b206b04d6874381-- From abdussalambaryun@gmail.com Sun Feb 24 23:17:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B0A21F91FB for ; Sun, 24 Feb 2013 23:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfkcGZvGjSyQ for ; Sun, 24 Feb 2013 23:17:53 -0800 (PST) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED2B21F914D for ; Sun, 24 Feb 2013 23:17:53 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id un15so1506784pbc.24 for ; Sun, 24 Feb 2013 23:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4e2ke9wiCkztXeGg8ELJrPBUQM7WMxhVq+6ydbkbptE=; b=mJhERpoGytAoYvk9KnFPLbcDJP6AQn7El27YgadpuG5IktdTYY8OPYVmThS7ewqwt7 rU/8gxhPtOSgq61hBSON5uXcWhIH32j1VcBk/MlTw07zq/fzuxfVkohCxv2oCNcbjgZc gbD2zRyFzOwvjKDyr5PoaR4YLnXQ4wwcN2ecAfBhiaQypSrOyeIIoRl/w3kWJ44OzlXt 1zXQUyBSkAykaqaNvGWth6z05SdMzHpuIK/p9L5PrecJ0s8Lbkle+C5OVvk08FdBsKcf Mvpsrxji5fb/YGAzLk81pZAF2fCak+/RlOvH6fhYj3gP0WDyalxk5QxRD6Nw6gXVSuAJ qIbg== MIME-Version: 1.0 X-Received: by 10.66.185.33 with SMTP id ez1mr17334750pac.93.1361776672908; Sun, 24 Feb 2013 23:17:52 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sun, 24 Feb 2013 23:17:52 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Mon, 25 Feb 2013 08:17:52 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 07:17:54 -0000 Hi Ulrich, It seems that some editors like to take over wg drafts, and making things difficult to participation. There was John input that I supported but you ignored, please check my input related. I don't care of the way the draft management is doing, but I will note this down, AB On 2/25/13, Ulrich Herberg wrote: > AB, > > again, sequence numbers are not used by NHDP, therefore not a threat to > NHDP. If another protocols uses that information, it may be a threat to > that protocol, and may be documented in a security threats analysis for > that protocol. > > It seems you are the only one advocating for changing the draft on this > aspect. I will wait if someone else also asks for changes on this matter > before changing it. > > Regards > Ulrich > > On Sun, Feb 24, 2013 at 10:19 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Ulrich and Henning >> >> My intentions was not about RFC5444 nor about making things long, it >> is about the RFC6130 job to backup routing and the threats to that >> job. >> >> We understand that RFC6130 is used most by the MANET routing protocols >> (OLSRv2, AODVv2, etc.), my point is why we don't mention in the >> document Sequence Number threat (mentioned in NHDP Hello Msg, but MAY >> be used by NHDP), while I think is important use in AODVv2 neighbor >> discovery. >> >> The document will not be long but reasonable if it considers all >> important threats affecting the NHDP job as a discovery for the >> routing protocol concerns (proactive and reactive). >> >> AB >> >> On 2/24/13, Ulrich Herberg wrote: >> > AB, >> > >> > this part about link quality calculation is not normative, i.e., it >> > does >> > not mandate you "MUST do it exactly this way", but it is merely an >> example >> > what could be done to calculate link quality (read: "The link quality >> > may >> > then, *for example*, be based on whether the last N out of M control >> > packets on the link were received, or may use a "leaky integrator" >> tracking >> > packet reception and loss.") >> > >> > Like Henning said, the draft would be of infinite length if I tried to >> > predict what each implementer may add to the normative part of the >> > protocol. >> > >> > >> > Regards >> > Ulrich >> > >> > On Sun, Feb 24, 2013 at 2:01 PM, Henning Rogge >> > wrote: >> > >> >> On Sun, Feb 24, 2013 at 2:35 PM, Abdussalam Baryun >> >> wrote: >> >> > I think it MAY be used sequence number (SQN) by NHDP [RFC6130], so >> >> > the >> >> NHDP >> >> > can depend on it. I don't care her about mandates items, because >> >> > this >> >> > protocol is a general use by MANET so it cannot mandate every thing, >> it >> >> > should be flexible. I care now about the RFC6130 does not exclude >> the >> >> > *USE* of SQNs in Packet/Message, as we can see from section 14 and >> >> others. >> >> >> >> RFC5444 is designed as a very flexible and easily extendable format. >> >> >> >> If we include everything into the NHDP-threat document that MAY be >> >> used in a NHDP implementation but is out of scope of the normative >> >> sections, the threat document might become VERY long. >> >> >> >> Henning Rogge >> >> -- >> >> We began as wanderers, and we are wanderers still. We have lingured >> >> long enough on the shores of the cosmic ocean. We are ready at last to >> >> set sail for the stars - Carl Sagan >> >> >> > >> > From trac+manet@trac.tools.ietf.org Sun Feb 24 23:40:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D3321F920F for ; Sun, 24 Feb 2013 23:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1swJQAZL8Zly for ; Sun, 24 Feb 2013 23:40:32 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 111A821F9204 for ; Sun, 24 Feb 2013 23:40:31 -0800 (PST) Received: from localhost ([127.0.0.1]:45476 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U9sfd-00040g-9b; Mon, 25 Feb 2013 08:40:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com X-Trac-Project: manet Date: Mon, 25 Feb 2013 07:40:21 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/18 Message-ID: <066.1f1dc1e7a958c726a83d410656ac5449@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, draft-ietf-manet-nhdp-sec-threats@tools.ietf.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jiazi@jiaziyi.com, t.clausen@computer.org, ulrich@herberg.name Resent-Message-Id: <20130225074032.111A821F9204@ietfa.amsl.com> Resent-Date: Sun, 24 Feb 2013 23:40:31 -0800 (PST) Resent-From: trac+manet@trac.tools.ietf.org Cc: draft-ietf-manet-nhdp-sec-threats@tools.ietf.org, manet@ietf.org Subject: [manet] #18: NHDP Sequence Number Threat X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 07:40:33 -0000 #18: NHDP Sequence Number Threat I don't know how the sequence number section was ignored/deleted in the updated draft but would like to advise to include as per the below input discussions. http://www.ietf.org/mail-archive/web/manet/current/msg13286.html http://www.ietf.org/mail-archive/web/manet/current/msg15004.html http://www.ietf.org/mail-archive/web/manet/current/msg15006.html The attack to sequence number of packets/messages may make changes into NHDP and routing. If you disagree please discuss, Regards AB -- ----------------------------------------+------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: nhdp-sec-threats | Version: 1.0 Severity: In WG Last Call | Keywords: NHDP ----------------------------------------+------------------------------- Ticket URL: manet From henning.rogge@fkie.fraunhofer.de Sun Feb 24 23:42:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0507A21F9218 for ; Sun, 24 Feb 2013 23:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jftarMLBWHi8 for ; Sun, 24 Feb 2013 23:42:23 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id AD65E21F920B for ; Sun, 24 Feb 2013 23:42:22 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U9shZ-0006Nw-JF for manet@ietf.org; Mon, 25 Feb 2013 08:42:21 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U9shZ-0007tE-Gd for manet@ietf.org; Mon, 25 Feb 2013 08:42:21 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 25 Feb 2013 08:42:21 +0100 Message-ID: <512B15DC.1030002@fkie.fraunhofer.de> Date: Mon, 25 Feb 2013 08:42:20 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000407030907070209000809" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16735/Mon Feb 25 00:42:27 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c7f8db32b27897ddd5dcaf8162788e46 Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 07:42:24 -0000 --------------ms000407030907070209000809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 02/25/2013 08:17 AM, Abdussalam Baryun wrote: > Hi Ulrich, > > It seems that some editors like to take over wg drafts, and making > things difficult to participation. There was John input that I > supported but you ignored, please check my input related. > > I don't care of the way the draft management is doing, but I will note > this down, Maybe instead of shouting and "noting things down", you should read my=20 last advise mail again... after this you should read the NHDP RFC again, especially the section=20 you are talking about (Section 14.4 I think). after doing this too, you will notice RFC6130 talks about the=20 possibility to use **packet** sequence numbers. Packet sequence numbers are not used to detect incoming duplicates, you=20 are mixing things up with message sequence numbers. In my opinion message sequence numbers are USELESS for hysteresis=20 calculation, because the NHDP Hello messages will not have a continuous=20 sequence (no pun intended) of message sequence numbers (unless you ONLY=20 run NHDP and do not combine it with another protocol). Any attack mitigation for NHDP sequence numbers will highly depend on=20 the hysteresis implementation, which makes the value of your request=20 dubious at best. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000407030907070209000809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMjUwNzQyMjBaMCMGCSqGSIb3DQEJBDEWBBQSPYvNpSKOAinoFuAirT3cAn8VvDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAtIBckileakhGNZF91kkeNGtqj788h5sopkqOOhUOrGXC CNB+/52+6vyR2Dxdfy4wPwxPAU8YxrRcTv6PDYz5j55P/43/5AonaYUdsbHCIUT6NhTo+MTq 4/ytrbi8We2pQZTR9LB1eGcmq9cp3XeaWYMThQ6WvJwR8ab1AKfDYrgk1glfKkmqOQiNNVfU 4fy6XYST2Hv0EHJrOAqZfFcvBNEKRaCIjyuTKUo8tOJgJ3usUUAvru+ucZOBe4IMdYMKK+AD xl5Abw1GdEzWBCIcB0g5N40Dkj0Amf53LrbxP4ryVrtrV6JDLy1Xbnk59BZDLao0MvyDVzgj WakMTRTBWQAAAAAAAA== --------------ms000407030907070209000809-- From abdussalambaryun@gmail.com Sun Feb 24 23:49:46 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DE621F9236 for ; Sun, 24 Feb 2013 23:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeAUdJJ1Yi28 for ; Sun, 24 Feb 2013 23:49:46 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 663A421F9231 for ; Sun, 24 Feb 2013 23:49:45 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id xa12so1508673pbc.8 for ; Sun, 24 Feb 2013 23:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QMR62NO+SrAL/H5zjrxcweHr5c19b71jk+0fCS9f3Ak=; b=f3m4Q84hcUow3AqbtjW/1YXK/fhEjWPuUE8IjWmxqDxQPk1CmWFB8yj2E3pBYn374Y cXAnXilu6Cr/NYmRyfZYGO2Q1RAt9Mb7r4rFAOA10s2sviS2EG4NuoyKQPMUdR+SUk0S rbWYLDED0BAl/nEPoI6BtdIc0z3P/1dShBlh7W/Y/sqJm3VZ8q/E0bTJRWCoFIUP15cU bqxfYMSKWLWDvUhA2jM/UqgnDx3/X66soEO2nXqoHaQls52qcvE8/Xz3f4qrv1jlfcgf Pm3YnEBXJY/TfAcUCs2cIa9fF1kOFMr+e8c0fVt90cCvpEW/UslICRxEvAsrlqkMrU4t 2vnA== MIME-Version: 1.0 X-Received: by 10.66.234.132 with SMTP id ue4mr17505273pac.163.1361778585249; Sun, 24 Feb 2013 23:49:45 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sun, 24 Feb 2013 23:49:45 -0800 (PST) In-Reply-To: <512B15DC.1030002@fkie.fraunhofer.de> References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> <512B15DC.1030002@fkie.fraunhofer.de> Date: Mon, 25 Feb 2013 08:49:45 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 07:49:46 -0000 On 2/25/13, Henning Rogge wrote: > On 02/25/2013 08:17 AM, Abdussalam Baryun wrote: >> Hi Ulrich, >> >> It seems that some editors like to take over wg drafts, and making >> things difficult to participation. There was John input that I >> supported but you ignored, please check my input related. >> >> I don't care of the way the draft management is doing, but I will note >> this down, > > Maybe instead of shouting and "noting things down", you should read my > last advise mail again... I never shout, how do you hear the sound on the list, my voice is nice, just comments responding, to understand how things should be, > > after this you should read the NHDP RFC again, especially the section > you are talking about (Section 14.4 I think). > > after doing this too, you will notice RFC6130 talks about the > possibility to use **packet** sequence numbers. > > Packet sequence numbers are not used to detect incoming duplicates, you > are mixing things up with message sequence numbers. I mean both sequence are important otherwise why do we have them in our work, > > In my opinion message sequence numbers are USELESS for hysteresis > calculation, because the NHDP Hello messages will not have a continuous > sequence (no pun intended) of message sequence numbers (unless you ONLY > run NHDP and do not combine it with another protocol). If useless then you should remove them why making things difficult, > > Any attack mitigation for NHDP sequence numbers will highly depend on > the hysteresis implementation, which makes the value of your request > dubious at best. Ok why does the document not talk about the hysteresis implementation then :) Please note that I respect all works in the WG so my voice for all inputs is low not high, please don't assume other :-) Regards AB From henning.rogge@fkie.fraunhofer.de Mon Feb 25 00:07:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95D721F908D for ; Mon, 25 Feb 2013 00:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3Nczic3FKNY for ; Mon, 25 Feb 2013 00:07:51 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 29DB121F8FA4 for ; Mon, 25 Feb 2013 00:07:50 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U9t6D-0006QX-Al; Mon, 25 Feb 2013 09:07:49 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U9t6D-00009M-84; Mon, 25 Feb 2013 09:07:49 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 25 Feb 2013 09:07:48 +0100 Message-ID: <512B1BD3.8080303@fkie.fraunhofer.de> Date: Mon, 25 Feb 2013 09:07:47 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> <512B15DC.1030002@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060807020006090409020107" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16735/Mon Feb 25 00:42:27 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ab3a174db55cc7687c315337a34e1612 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:07:52 -0000 --------------ms060807020006090409020107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 02/25/2013 08:49 AM, Abdussalam Baryun wrote: >> after this you should read the NHDP RFC again, especially the >> section you are talking about (Section 14.4 I think). >> >> after doing this too, you will notice RFC6130 talks about the >> possibility to use **packet** sequence numbers. >> >> Packet sequence numbers are not used to detect incoming duplicates, >> you are mixing things up with message sequence numbers. > > I mean both sequence are important otherwise why do we have them in > our work, You certainly do not understand the "duplicate detection poison" attack. >> In my opinion message sequence numbers are USELESS for hysteresis >> calculation, because the NHDP Hello messages will not have a >> continuous sequence (no pun intended) of message sequence numbers >> (unless you ONLY run NHDP and do not combine it with another >> protocol). > > If useless then you should remove them why making things difficult, Okay, I will explain it once again. RFC6130 mentions the possibility (among other things) to use packet sequence numbers for hysteresis calculations, without going into details what to do with them. Because of this its a not a good idea to describe the "drop duplicate=20 because of spoofed high sequence numbers attack", because the attack=20 does not apply to this case at all. The duplicate detection described=20 for RFC5444 does only work for message sequence numbers. An attack on packet sequence level would not be a NHDP attack but a=20 RFC5444 (de-)multiplixer attack, which would belong into a=20 packetbb-sec-threats document. >> Any attack mitigation for NHDP sequence numbers will highly depend >> on the hysteresis implementation, which makes the value of your >> request dubious at best. > > Ok why does the document not talk about the hysteresis implementation > then :) There was a hysteresis implementation example in OLSRv1 (RFC3626)... it didn't worked well. I think that is the reason NHDP only gives some=20 hints what you could look at when implementing a hysteresis function. NHDP also mentions the possibility to use signal-to-noise ratio or=20 packet-acknowledgements. Do you want to add "threats descriptions and mitigations" to this=20 attacks too? If I ever write down my "packet sequence number based ETX", it should=20 contain a "security" section because it would be the first Manet-WG=20 document using the packet sequence numbers I think. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms060807020006090409020107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMjUwODA3NDdaMCMGCSqGSIb3DQEJBDEWBBRzY40nEd2MQQZhHnZDKn5KOAzCZzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAXfBsfoyC+M9Y7fzMKH0y9mgiDtLze4Er68kuF8QFfD4g ApWOdwYVAGdkEwt5/UVNVP+WMtUNzVvVNQgfusKoYJuESXL5GHI9P1UD4xMZ9aUE9fz1s98K bnFKxIL5ATOnTS+JAGkI7ofkjFM9sxf0VtSohHm3GwaRLDt+YtpKLeLgtzzC9e6UA5IbmScB ceF3ltvtPA46G3I2EgQy3E8vtrCiZNovIlGJ0002N6JsjxyTKITf0Rh7Ui9211iUtgxPdlHy jaSatxER6MgNLlY+J/p21ZvGY/v8itvQVLlCaIVmQJdl0DISe5kniD4W8V5oLWah4n2qf7YK X+4pFcdGHAAAAAAAAA== --------------ms060807020006090409020107-- From drdanhe@gmail.com Mon Feb 25 01:27:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAE921F8F00 for ; Mon, 25 Feb 2013 01:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4iIqAmrhXon for ; Mon, 25 Feb 2013 01:27:46 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id BF5C821F8E7E for ; Mon, 25 Feb 2013 01:27:46 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id bn7so2796219ieb.25 for ; Mon, 25 Feb 2013 01:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+CLuuEczejT9Z8OKvPqpUos67Cc28aGZH0dvKocEyLs=; b=sjdcpIWZlVy3lnC5dtbtNshiVsBIUbChRFBLJc/fapIlEJC7fRIIxBV4il/+6IZjmW I/Kfky9m/0sIX0Q7WIDUhnsZspq64Gd+xGF1mumkD2wEYC75Bl+3A0Jkl9zUurpHgeHa 44njbdBPk9pZtLNj2djge5KoFD0CFWe8/UMO7Vb/+TGgUNeflAKnXlXw0xCbHjkEr5Uf YyFESQZ6OvENkHmCj1oK9XyGi/ab5pVmkl3jkZ2jpzor7anulI5MtR3Pp8LVd67gX1N1 OoUxfPZHZtenbnL1i+A2uH3UdSZAdngno4mQlexWGjvuKNfVnSA4a6xfbi+ZBbB1apM2 B8cQ== MIME-Version: 1.0 X-Received: by 10.50.191.133 with SMTP id gy5mr3256538igc.50.1361784466351; Mon, 25 Feb 2013 01:27:46 -0800 (PST) Received: by 10.50.85.6 with HTTP; Mon, 25 Feb 2013 01:27:46 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> <512B15DC.1030002@fkie.fraunhofer.de> Date: Mon, 25 Feb 2013 09:27:46 +0000 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=14dae934071960a5c904d68927eb Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 09:27:47 -0000 --14dae934071960a5c904d68927eb Content-Type: text/plain; charset=ISO-8859-1 Hi Mr Abdussalam Baryun, Since early 2012, you started to give "COMMENTS" on many things in IETF mailing list, which seems good. However, most of your comments are unnecessary! if I have to say about your "noting things down", I have to cite Murray S. Kucherawy's comment on you >>If I may quote Blazing Saddles: >>Reverend! http://www.ietf.org/mail-archive/web/ietf/current/msg74224.html ("+2", for those unfamiliar.) Cheers, Daniel On 25 February 2013 07:49, Abdussalam Baryun wrote: > On 2/25/13, Henning Rogge wrote: > > On 02/25/2013 08:17 AM, Abdussalam Baryun wrote: > >> Hi Ulrich, > >> > >> It seems that some editors like to take over wg drafts, and making > >> things difficult to participation. There was John input that I > >> supported but you ignored, please check my input related. > >> > >> I don't care of the way the draft management is doing, but I will note > >> this down, > > > > Maybe instead of shouting and "noting things down", you should read my > > last advise mail again... > > I never shout, how do you hear the sound on the list, my voice is > nice, just comments responding, to understand how things should be, > --14dae934071960a5c904d68927eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mr Abdussalam Baryun,

Since early 2012, you started to give "= ;COMMENTS" on many things in IETF mailing list, which seems good. Howe= ver, most of your comments are unnecessary!

if I have to say about = your "noting things down", I have to cite Murray S. Kucherawy'= ;s comment on you

>>If I may quote Blazing Saddles:

>>Reverend!

http://www.ietf.org/mail-archive/web/ietf/current=
/msg74224.html

("+2", for those unfamiliar.)
Cheers,

Daniel


On 25 Feb= ruary 2013 07:49, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
On 2/25/13, Henning Rogge = <henning.rogge@fkie.= fraunhofer.de> wrote:
> On 02/25/2013 08:17 AM, Abdussalam Baryun wrote:
>> Hi Ulrich,
>>
>> It seems that some editors like to take over wg drafts, and making=
>> things difficult to participation. There was John input that I
>> supported but you ignored, please check my input related.
>>
>> I don't care of the way the draft management is doing, but I w= ill note
>> this down,
>
> Maybe instead of shouting and "noting things down", you shou= ld read my
> last advise mail again...

I never shout, how do you hear the sound on the list, my voice is
nice, just comments responding, to understand how things should be,

--14dae934071960a5c904d68927eb-- From abdussalambaryun@gmail.com Mon Feb 25 04:36:10 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA42121F92EB for ; Mon, 25 Feb 2013 04:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1psqCW7FJ1FN for ; Mon, 25 Feb 2013 04:36:10 -0800 (PST) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id DC70421F92E2 for ; Mon, 25 Feb 2013 04:36:09 -0800 (PST) Received: by mail-da0-f50.google.com with SMTP id h15so1255606dan.37 for ; Mon, 25 Feb 2013 04:36:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hQWg6ctUlcl1QjG7MPQOa4y+DwnkwCfqFclQQiDFnvc=; b=d3FwfHFkPpEmGr3IqI7WCyK+PUMCVJjJV8yIk6fxGshmaxeOvml9c613aqmyNigZuu s1EhhTYlwXrkl2+zcMi/UPXMHsQo9SgzdIRrRHwG0DO4l6Q4RbhaSy3ndFunz89Nk9SV KHHHUgxvOtyVQRBuVk5bmYpUGFdlzjAc+YgD7XGKHc+qawvwJXy5f3BCJOK6kOdFQV2j +38ucbCmVOZgQC8c59mKs4v99g168E9wP3bgPXRq0lb937dW6Vvybs0EqZwaVtc3QOvJ sG1A1q5B1QE4zXVCi4p2uGN9/8h8/P5mDqkUIjVooGmPj/8nYOiAUSbAXEwzEH6s9fgy F39A== MIME-Version: 1.0 X-Received: by 10.68.217.2 with SMTP id ou2mr17879601pbc.6.1361795762473; Mon, 25 Feb 2013 04:36:02 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 25 Feb 2013 04:36:02 -0800 (PST) In-Reply-To: <512B1BD3.8080303@fkie.fraunhofer.de> References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> Date: Mon, 25 Feb 2013 12:36:02 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=e89a8ff2430badcbe504d68bc83a Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 12:36:11 -0000 --e89a8ff2430badcbe504d68bc83a Content-Type: text/plain; charset=ISO-8859-1 Hi Henning, I agree that we should first had RFC5444-sec-threats, but don't mind just doing NHDP because this discovery protocol is used by our routing protocols. We should focus on the NHDP's processes and information if attacked in this doc. Comments below, > Okay, I will explain it once again. > > RFC6130 mentions the possibility (among other things) to use packet > sequence numbers for hysteresis calculations, without going into details > what to do with them. > I agree not to go into details as well, I like that, but want details what are the information in NHDP, > > Because of this its a not a good idea to describe the "drop duplicate > because of spoofed high sequence numbers attack", because the attack does > not apply to this case at all. The duplicate detection described for > RFC5444 does only work for message sequence numbers. > We don't want to describe the duplicate detection, I wanted to describe the threats is a change in the NHDP information which may be wrong info. Any information in NHDP may be used by the router. Some think it is threat to router only, I think no also NHDP is attacked in its useless info that may be useful for more important functions in the node. > > An attack on packet sequence level would not be a NHDP attack but a > RFC5444 (de-)multiplixer attack, which would belong into a > packetbb-sec-threats document. > > > All messages are in RFC5444 packet , if the packet attacked then message is attacked, if the message is attacked may not mean that packet is attacked. Does that make sense? I agree that we will need packetbb-sec-threat to be added in all threat documents that use packetbb, but if we don't have now a participant volunteering on the packetbb-threat then we should add related issues in our other threat docs. We separated routing and NHDP but I don't agree to separate messaging from protocols because such protocols not only use packetbb but eat packetbb, > > There was a hysteresis implementation example in OLSRv1 (RFC3626)... it > didn't worked well. I think that is the reason NHDP only gives some hints > what you could look at when implementing a hysteresis function. > > NHDP also mentions the possibility to use signal-to-noise ratio or > packet-acknowledgements. > maybe that SNR can be a threat but did not see a wg routing using that info. If the NHDP is updating SNR and another routing protocol is using that info from NHDP, I think if an attack on SNR then it will affect the NHDP info and then the routing process. > > Do you want to add "threats descriptions and mitigations" to this attacks > too? > Threats documented are not only to the NHDP processes, but also its information. If the NHDP does not use one information item, then it does not mean that if the item information was attacked the NHDP is not attacked. Any information in NHDP is the NHDP responsibility don't you think, > > If I ever write down my "packet sequence number based ETX", it should > contain a "security" section because it would be the first Manet-WG > document using the packet sequence numbers I think. > > > I did not want to make it complicated just simple issues that affect the neighbor discovery related to our standard routings OLSR and AODV. AB --e89a8ff2430badcbe504d68bc83a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Henning,

=A0
I agree that we should first had=A0RFC= 5444-sec-threats, but don't mind just doing NHDP because this discovery= protocol is used by our routing protocols. We should focus on the NHDP'= ;s processes and information if attacked in this doc. Comments below,
=A0
Okay, I will explain it once again.

RFC6130 mentions the possibility (among other things) to use packet
sequence numbers for hysteresis calculations, without going into details what to do with them.
=A0
I agree not = to go into details as well, I like that, but want details=A0what are the in= formation=A0in NHDP,=A0
=A0

Because of this its a not a good idea to describe the "drop duplicate = because of spoofed high sequence numbers attack", because the attack d= oes not apply to this case at all. The duplicate detection described for RF= C5444 does only work for message sequence numbers.
=A0
We don't want to describe the dup= licate detection, I wanted to describe the threats is a change in the NHDP = information which may be wrong info. Any information in NHDP may be used by= the router. Some think it is threat to router only, I think no also NHDP i= s attacked in its useless info that may be useful for more important functi= ons in the node.
=A0

An attack on packet sequence level would not be a NHDP attack but a RFC5444= (de-)multiplixer attack, which would belong into a packetbb-sec-threats do= cument.
=A0
=A0
All=A0messages a= re in RFC5444 packet=A0, if the packet attacked then message is attacked,
if the message is attacked may not mean that packet is attacked. Does = that make sense?
=A0
I agree that we will need packetbb= -sec-threat to be added in all threat documents that use packetbb,=A0but if= we don't have now a participant volunteering on the packetbb-threat th= en we should add related issues in our other threat docs. We separated rout= ing and NHDP but I don't agree to separate messaging from protocols bec= ause such=A0protocols not only use packetbb but eat packetbb,
=A0

There was a hysteresis implementation example in OLSRv1 (RFC3626)... it
didn't worked well. I think that is the reason NHDP only gives some hin= ts what you could look at when implementing a hysteresis function.

NHDP also mentions the possibility to use signal-to-noise ratio or packet-a= cknowledgements.
=A0
maybe that SNR can be a= threat but did not see a wg routing using that info. If the NHDP is updati= ng SNR and another routing protocol is using that info from NHDP, I think i= f an attack on SNR then it will affect the NHDP info and then the routing p= rocess.
=A0


Do you want to add "threats descriptions and mitigations" to this= attacks too?

=A0
Threats documented are= not only to the NHDP processes, but also its information. If the NHDP does= not use one=A0information item, then it does not mean that if the item inf= ormation was attacked the NHDP is not attacked.=A0Any information in NHDP i= s the NHDP responsibility don't you think,


If I ever write down my "packet sequence number based ETX", it sh= ould contain a "security" section because it would be the first M= anet-WG document using the packet sequence numbers I think.

=A0

=A0
I did not want to make it complicated just = simple issues that affect the neighbor discovery related to our standard ro= utings OLSR and AODV.=A0

AB --e89a8ff2430badcbe504d68bc83a-- From ulrich@herberg.name Mon Feb 25 04:45:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D5721F92FA for ; Mon, 25 Feb 2013 04:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.889 X-Spam-Level: X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUUlVWRty9As for ; Mon, 25 Feb 2013 04:45:46 -0800 (PST) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 603FC21F8825 for ; Mon, 25 Feb 2013 04:45:43 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id ox1so2135515veb.27 for ; Mon, 25 Feb 2013 04:45:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LEZkZsFTrBpZvlBV3LhEp6j46G8odixCvOOYffRWW70=; b=hxpXi9WHDRaFIvM0B+iWcM8/T6FIVyypyk6GZtmRw9OiMgRR1DsCZPkfXhdCykHLfq Wr7QvQhOOPWWOhf0YD/Dq3MBBYh9caGGjo9na/gYWMu0UXQIJnXhZJBJfyAjZ4jAEL30 9Zr3d1Vv1g69oXad+VbERPqRJIvwyaZQlBAgc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=LEZkZsFTrBpZvlBV3LhEp6j46G8odixCvOOYffRWW70=; b=e2bIfxB3cPEDbJ1eiCPoh/ZRoypwdMNu0esau04COJP3joaiAyX6UNp0rDG7I7LJvy IwwwvMtchedPBiE4+tm0JKnpxBatE4snM6G49OSJbu4PmNma0d6O9vWnMkUJdGmZiugp njf0rBjvrnCGTJBi2R1ct2NBh+xE4ERjryYWn7lUoxnIqs+uhm36R3/E2cx/o7YvacY3 pnUWC6uCmfvrHM4OH6dDFeTAYFKbFJjrFbgYxw58MvWCV3mE9urltPK1REDvVvznEV9L 1aCGmMGnhmG8q8EsKF/RAXQIc7VBL9fUiveg1jSOPV5TOrEe8fd51ZjpgQFk5Hg4Oa7T rxIQ== MIME-Version: 1.0 X-Received: by 10.220.154.14 with SMTP id m14mr9649584vcw.21.1361796342787; Mon, 25 Feb 2013 04:45:42 -0800 (PST) Received: by 10.220.107.7 with HTTP; Mon, 25 Feb 2013 04:45:42 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Mon, 25 Feb 2013 04:45:42 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=f46d043d64af44b85304d68beb67 X-Gm-Message-State: ALoCoQmGGIGa555kJ9yEVDUKT0eGxYweFpb3eEY91i06iWTOv3H+IQV7NuhHviy7rCP2Ls4I2LhL Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 12:45:47 -0000 --f46d043d64af44b85304d68beb67 Content-Type: text/plain; charset=ISO-8859-1 AB, I disclaim your accusations. An editor is supposed to write text that represents WG consensus. I have heard your argument, provided arguments against it (confirmed by Henning and Jiazi), nobody has backed up your argument. Therefore, your arguments hardly represent WG consensus. Best regards Ulrich On Sun, Feb 24, 2013 at 11:17 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Ulrich, > > It seems that some editors like to take over wg drafts, and making > things difficult to participation. There was John input that I > supported but you ignored, please check my input related. > > I don't care of the way the draft management is doing, but I will note > this down, > > AB > > On 2/25/13, Ulrich Herberg wrote: > > AB, > > > > again, sequence numbers are not used by NHDP, therefore not a threat to > > NHDP. If another protocols uses that information, it may be a threat to > > that protocol, and may be documented in a security threats analysis for > > that protocol. > > > > It seems you are the only one advocating for changing the draft on this > > aspect. I will wait if someone else also asks for changes on this matter > > before changing it. > > > > Regards > > Ulrich > > > > On Sun, Feb 24, 2013 at 10:19 PM, Abdussalam Baryun < > > abdussalambaryun@gmail.com> wrote: > > > >> Hi Ulrich and Henning > >> > >> My intentions was not about RFC5444 nor about making things long, it > >> is about the RFC6130 job to backup routing and the threats to that > >> job. > >> > >> We understand that RFC6130 is used most by the MANET routing protocols > >> (OLSRv2, AODVv2, etc.), my point is why we don't mention in the > >> document Sequence Number threat (mentioned in NHDP Hello Msg, but MAY > >> be used by NHDP), while I think is important use in AODVv2 neighbor > >> discovery. > >> > >> The document will not be long but reasonable if it considers all > >> important threats affecting the NHDP job as a discovery for the > >> routing protocol concerns (proactive and reactive). > >> > >> AB > >> > >> On 2/24/13, Ulrich Herberg wrote: > >> > AB, > >> > > >> > this part about link quality calculation is not normative, i.e., it > >> > does > >> > not mandate you "MUST do it exactly this way", but it is merely an > >> example > >> > what could be done to calculate link quality (read: "The link quality > >> > may > >> > then, *for example*, be based on whether the last N out of M control > >> > packets on the link were received, or may use a "leaky integrator" > >> tracking > >> > packet reception and loss.") > >> > > >> > Like Henning said, the draft would be of infinite length if I tried to > >> > predict what each implementer may add to the normative part of the > >> > protocol. > >> > > >> > > >> > Regards > >> > Ulrich > >> > > >> > On Sun, Feb 24, 2013 at 2:01 PM, Henning Rogge > >> > wrote: > >> > > >> >> On Sun, Feb 24, 2013 at 2:35 PM, Abdussalam Baryun > >> >> wrote: > >> >> > I think it MAY be used sequence number (SQN) by NHDP [RFC6130], so > >> >> > the > >> >> NHDP > >> >> > can depend on it. I don't care her about mandates items, because > >> >> > this > >> >> > protocol is a general use by MANET so it cannot mandate every > thing, > >> it > >> >> > should be flexible. I care now about the RFC6130 does not exclude > >> the > >> >> > *USE* of SQNs in Packet/Message, as we can see from section 14 and > >> >> others. > >> >> > >> >> RFC5444 is designed as a very flexible and easily extendable format. > >> >> > >> >> If we include everything into the NHDP-threat document that MAY be > >> >> used in a NHDP implementation but is out of scope of the normative > >> >> sections, the threat document might become VERY long. > >> >> > >> >> Henning Rogge > >> >> -- > >> >> We began as wanderers, and we are wanderers still. We have lingured > >> >> long enough on the shores of the cosmic ocean. We are ready at last > to > >> >> set sail for the stars - Carl Sagan > >> >> > >> > > >> > > > --f46d043d64af44b85304d68beb67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AB,

I disclaim your accusations. An editor is supposed to write text= that represents WG consensus. I have heard your argument, provided argumen= ts against it (confirmed by Henning and Jiazi), nobody has backed up your a= rgument. Therefore, your arguments hardly represent WG consensus.

Best regards
Ulrich

On Sun, Feb 24= , 2013 at 11:17 PM, Abdussalam Baryun <abdussalambaryun@gmail.com= > wrote:
Hi Ulrich,

It seems that some editors like to take over wg drafts, and making
things difficult to participation. There was John input that I
supported but you ignored, please check my input related.

I don't care of the way the draft management is doing, but I will note<= br> this down,

AB

On 2/25/13, Ulrich Herberg <ulric= h@herberg.name> wrote:
> AB,
>
> again, sequence numbers are not used by NHDP, therefore not a threat t= o
> NHDP. If another protocols uses that information, it may be a threat t= o
> that protocol, and may be documented in a security threats analysis fo= r
> that protocol.
>
> It seems you are the only one advocating for changing the draft on thi= s
> aspect. I will wait if someone else also asks for changes on this matt= er
> before changing it.
>
> Regards
> Ulrich
>
> On Sun, Feb 24, 2013 at 10:19 PM, Abdussalam Baryun <
> abdussalambaryun@gmail.c= om> wrote:
>
>> Hi Ulrich and Henning
>>
>> My intentions was not about RFC5444 nor about making things long, = it
>> is about the RFC6130 job to backup routing and the threats to that=
>> job.
>>
>> We understand that RFC6130 is used most by the MANET routing proto= cols
>> (OLSRv2, AODVv2, etc.), my point is why we don't mention in th= e
>> document Sequence Number threat (mentioned in NHDP Hello Msg, but = MAY
>> be used by NHDP), while I think is important use in AODVv2 neighbo= r
>> discovery.
>>
>> The document will not be long but reasonable if it considers all >> important threats affecting the NHDP job as a discovery for the >> routing protocol concerns (proactive and reactive).
>>
>> AB
>>
>> On 2/24/13, Ulrich Herberg <ulrich@herberg.name> wrote:
>> > AB,
>> >
>> > this part about link quality calculation is not normative, i.= e., it
>> > does
>> > not mandate you "MUST do it exactly this way", but = it is merely an
>> example
>> > what could be done to calculate link quality (read: "The= link quality
>> > may
>> > then, *for example*, be based on whether the last N out of M = control
>> > packets on the link were received, or may use a "leaky i= ntegrator"
>> tracking
>> > packet reception and loss.")
>> >
>> > Like Henning said, the draft would be of infinite length if I= tried to
>> > predict what each implementer may add to the normative part o= f the
>> > protocol.
>> >
>> >
>> > Regards
>> > Ulrich
>> >
>> > On Sun, Feb 24, 2013 at 2:01 PM, Henning Rogge
>> > <hrogge@googlemai= l.com>wrote:
>> >
>> >> On Sun, Feb 24, 2013 at 2:35 PM, Abdussalam Baryun
>> >> <abdussa= lambaryun@gmail.com> wrote:
>> >> > I think it MAY be used sequence number (SQN) by NHDP= [RFC6130], so
>> >> > the
>> >> NHDP
>> >> > can depend on it. I don't care her about mandate= s items, because
>> >> > this
>> >> > protocol is a general use by MANET so it cannot mand= ate every thing,
>> it
>> >> > should be flexible. =A0I care now about =A0the RFC61= 30 does not exclude
>> the
>> >> > *USE* of SQNs in Packet/Message, as we can see from = section 14 and
>> >> others.
>> >>
>> >> RFC5444 is designed as a very flexible and easily extenda= ble format.
>> >>
>> >> If we include everything into the NHDP-threat document th= at MAY be
>> >> used in a NHDP implementation but is out of scope of the = normative
>> >> sections, the threat document might become VERY long.
>> >>
>> >> Henning Rogge
>> >> --
>> >> We began as wanderers, and we are wanderers still. We hav= e lingured
>> >> long enough on the shores of the cosmic ocean. We are rea= dy at last to
>> >> set sail for the stars - Carl Sagan
>> >>
>> >
>>
>

--f46d043d64af44b85304d68beb67-- From abdussalambaryun@gmail.com Mon Feb 25 05:03:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A18021F8E43 for ; Mon, 25 Feb 2013 05:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxYLex5L-dP7 for ; Mon, 25 Feb 2013 05:03:26 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2B15321F92D1 for ; Mon, 25 Feb 2013 05:03:26 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id bg4so1731922pad.26 for ; Mon, 25 Feb 2013 05:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TSbYSZtxj3QE79kgkoGkR9pAf//1FfJDxd1w5xyf6V4=; b=p/wsDFFldDW0LSGGwI9Wjtmxd0Logou16aRvsNh/bd8a2DSeLPn4rD5hh4U4x40sSQ Wm32qDcILS8vsrFJ6cGmIZux0p964GNtBjpxFH7B6tdtigRHAlkp7SptVCpM2erwRgy8 XumGzuq8RTYBl3grUdS11E1/OTi+KyoKMlNtOduc9b7E5VKna5pJHESPIUjuQCa5UN7r 6l7qCy6Gg9ErJvgQ1j0WvnmFfW+w6sCx46GTmPE9j5xd85NKesBgc72xqIJEWxRXCbdX +nmNSDqdAtkOmF6VfqDyipCANpKMyHg4amdAWe4IvDdJJuB8ygiKyR+xnXSxVE2zqXt0 +8Fw== MIME-Version: 1.0 X-Received: by 10.68.138.170 with SMTP id qr10mr17623621pbb.190.1361797405813; Mon, 25 Feb 2013 05:03:25 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 25 Feb 2013 05:03:25 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Mon, 25 Feb 2013 13:03:25 +0000 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=047d7b15aa2fa12cf204d68c2aea Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 13:03:27 -0000 --047d7b15aa2fa12cf204d68c2aea Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 25, 2013 at 12:45 PM, Ulrich Herberg wrote: > AB, > > I disclaim your accusations. An editor is supposed to write text that > represents WG consensus. I have heard your argument, provided arguments > against it (confirmed by Henning and Jiazi), nobody has backed up your > argument. Therefore, your arguments hardly represent WG consensus. > The editor/authors should not decide on behalf of the WG (maybe chair can). There is no consensus on any update you done so far either, people are bussy, but for me the reputation of the draft is not good, however, good luck, AB > > Best regards > Ulrich > > > On Sun, Feb 24, 2013 at 11:17 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Ulrich, >> >> It seems that some editors like to take over wg drafts, and making >> things difficult to participation. There was John input that I >> supported but you ignored, please check my input related. >> >> I don't care of the way the draft management is doing, but I will note >> this down, >> >> AB >> >> On 2/25/13, Ulrich Herberg wrote: >> > AB, >> > >> > again, sequence numbers are not used by NHDP, therefore not a threat to >> > NHDP. If another protocols uses that information, it may be a threat to >> > that protocol, and may be documented in a security threats analysis for >> > that protocol. >> > >> > It seems you are the only one advocating for changing the draft on this >> > aspect. I will wait if someone else also asks for changes on this matter >> > before changing it. >> > >> > Regards >> > Ulrich >> > >> > On Sun, Feb 24, 2013 at 10:19 PM, Abdussalam Baryun < >> > abdussalambaryun@gmail.com> wrote: >> > >> >> Hi Ulrich and Henning >> >> >> >> My intentions was not about RFC5444 nor about making things long, it >> >> is about the RFC6130 job to backup routing and the threats to that >> >> job. >> >> >> >> We understand that RFC6130 is used most by the MANET routing protocols >> >> (OLSRv2, AODVv2, etc.), my point is why we don't mention in the >> >> document Sequence Number threat (mentioned in NHDP Hello Msg, but MAY >> >> be used by NHDP), while I think is important use in AODVv2 neighbor >> >> discovery. >> >> >> >> The document will not be long but reasonable if it considers all >> >> important threats affecting the NHDP job as a discovery for the >> >> routing protocol concerns (proactive and reactive). >> >> >> >> AB >> >> >> >> On 2/24/13, Ulrich Herberg wrote: >> >> > AB, >> >> > >> >> > this part about link quality calculation is not normative, i.e., it >> >> > does >> >> > not mandate you "MUST do it exactly this way", but it is merely an >> >> example >> >> > what could be done to calculate link quality (read: "The link quality >> >> > may >> >> > then, *for example*, be based on whether the last N out of M control >> >> > packets on the link were received, or may use a "leaky integrator" >> >> tracking >> >> > packet reception and loss.") >> >> > >> >> > Like Henning said, the draft would be of infinite length if I tried >> to >> >> > predict what each implementer may add to the normative part of the >> >> > protocol. >> >> > >> >> > >> >> > Regards >> >> > Ulrich >> >> > >> >> > On Sun, Feb 24, 2013 at 2:01 PM, Henning Rogge >> >> > wrote: >> >> > >> >> >> On Sun, Feb 24, 2013 at 2:35 PM, Abdussalam Baryun >> >> >> wrote: >> >> >> > I think it MAY be used sequence number (SQN) by NHDP [RFC6130], so >> >> >> > the >> >> >> NHDP >> >> >> > can depend on it. I don't care her about mandates items, because >> >> >> > this >> >> >> > protocol is a general use by MANET so it cannot mandate every >> thing, >> >> it >> >> >> > should be flexible. I care now about the RFC6130 does not >> exclude >> >> the >> >> >> > *USE* of SQNs in Packet/Message, as we can see from section 14 and >> >> >> others. >> >> >> >> >> >> RFC5444 is designed as a very flexible and easily extendable format. >> >> >> >> >> >> If we include everything into the NHDP-threat document that MAY be >> >> >> used in a NHDP implementation but is out of scope of the normative >> >> >> sections, the threat document might become VERY long. >> >> >> >> >> >> Henning Rogge >> >> >> -- >> >> >> We began as wanderers, and we are wanderers still. We have lingured >> >> >> long enough on the shores of the cosmic ocean. We are ready at last >> to >> >> >> set sail for the stars - Carl Sagan >> >> >> >> >> > >> >> >> > >> > > --047d7b15aa2fa12cf204d68c2aea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 25, 2013 at 12:45 PM, Ulrich Herberg= <ulrich@herberg.name> wrote:
AB,

I disclaim your accusations. An editor is supposed to write text= that represents WG consensus. I have heard your argument, provided argumen= ts against it (confirmed by Henning and Jiazi), nobody has backed up your a= rgument. Therefore, your arguments hardly represent WG consensus.
=A0
The editor/authors should not decide on beh= alf of the WG (maybe chair can). There is no consensus on any update you do= ne so far either, people are bussy, but for me the reputation of the draft = is not good, however, good luck,=A0
=A0
AB

Best regards
Ulrich


On Sun, Feb 24, 2013 at 11:17 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi Ulrich,

It seems that some editors like to take over wg drafts, and making
things difficult to participation. There was John input that I
supported but you ignored, please check my input related.

I don't care of the way the draft management is doing, but I will note<= br> this down,

AB

On 2/25/13, Ulrich Herberg <ulrich@herberg.name> wrote:
> AB,
>
> again, sequence numbers are not used by NHDP, therefore not a threat t= o
> NHDP. If another protocols uses that information, it may be a threat t= o
> that protocol, and may be documented in a security threats analysis fo= r
> that protocol.
>
> It seems you are the only one advocating for changing the draft on thi= s
> aspect. I will wait if someone else also asks for changes on this matt= er
> before changing it.
>
> Regards
> Ulrich
>
> On Sun, Feb 24, 2013 at 10:19 PM, Abdussalam Baryun <
> abduss= alambaryun@gmail.com> wrote:
>
>> Hi Ulrich and Henning
>>
>> My intentions was not about RFC5444 nor about making things long, = it
>> is about the RFC6130 job to backup routing and the threats to that=
>> job.
>>
>> We understand that RFC6130 is used most by the MANET routing proto= cols
>> (OLSRv2, AODVv2, etc.), my point is why we don't mention in th= e
>> document Sequence Number threat (mentioned in NHDP Hello Msg, but = MAY
>> be used by NHDP), while I think is important use in AODVv2 neighbo= r
>> discovery.
>>
>> The document will not be long but reasonable if it considers all >> important threats affecting the NHDP job as a discovery for the >> routing protocol concerns (proactive and reactive).
>>
>> AB
>>
>> On 2/24/13, Ulrich Herberg <ulrich@herberg.name> wrote:
>> > AB,
>> >
>> > this part about link quality calculation is not normative, i.= e., it
>> > does
>> > not mandate you "MUST do it exactly this way", but = it is merely an
>> example
>> > what could be done to calculate link quality (read: "The= link quality
>> > may
>> > then, *for example*, be based on whether the last N out of M = control
>> > packets on the link were received, or may use a "leaky i= ntegrator"
>> tracking
>> > packet reception and loss.")
>> >
>> > Like Henning said, the draft would be of infinite length if I= tried to
>> > predict what each implementer may add to the normative part o= f the
>> > protocol.
>> >
>> >
>> > Regards
>> > Ulrich
>> >
>> > On Sun, Feb 24, 2013 at 2:01 PM, Henning Rogge
>> > <hrogge@googlemail.com>wrote:
>> >
>> >> On Sun, Feb 24, 2013 at 2:35 PM, Abdussalam Baryun
>> >> <abdussalambaryun@gmail.com> wrote:
>> >> > I think it MAY be used sequence number (SQN) by NHDP= [RFC6130], so
>> >> > the
>> >> NHDP
>> >> > can depend on it. I don't care her about mandate= s items, because
>> >> > this
>> >> > protocol is a general use by MANET so it cannot mand= ate every thing,
>> it
>> >> > should be flexible. =A0I care now about =A0the RFC61= 30 does not exclude
>> the
>> >> > *USE* of SQNs in Packet/Message, as we can see from = section 14 and
>> >> others.
>> >>
>> >> RFC5444 is designed as a very flexible and easily extenda= ble format.
>> >>
>> >> If we include everything into the NHDP-threat document th= at MAY be
>> >> used in a NHDP implementation but is out of scope of the = normative
>> >> sections, the threat document might become VERY long.
>> >>
>> >> Henning Rogge
>> >> --
>> >> We began as wanderers, and we are wanderers still. We hav= e lingured
>> >> long enough on the shores of the cosmic ocean. We are rea= dy at last to
>> >> set sail for the stars - Carl Sagan
>> >>
>> >
>>
>


--047d7b15aa2fa12cf204d68c2aea-- From henning.rogge@fkie.fraunhofer.de Mon Feb 25 05:16:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949B221F931D for ; Mon, 25 Feb 2013 05:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDhmaU-Oss5d for ; Mon, 25 Feb 2013 05:16:56 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id DCCB421F930B for ; Mon, 25 Feb 2013 05:16:53 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U9xvJ-0002zj-6i for manet@ietf.org; Mon, 25 Feb 2013 14:16:53 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U9xvJ-0001fm-40 for manet@ietf.org; Mon, 25 Feb 2013 14:16:53 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 25 Feb 2013 14:16:52 +0100 Message-ID: <512B6443.9020807@fkie.fraunhofer.de> Date: Mon, 25 Feb 2013 14:16:51 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090201020901000302080107" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16737/Mon Feb 25 12:43:01 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c7fbbc3bfe2de368a9522e1ccdb970b4 Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 13:16:56 -0000 --------------ms090201020901000302080107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Am 25.02.2013 13:36, schrieb Abdussalam Baryun: >> There was a hysteresis implementation example in OLSRv1 >> (RFC3626)... it didn't worked well. I think that is the reason NHDP >> only gives some hints what you could look at when implementing a >> hysteresis function. >> >> NHDP also mentions the possibility to use signal-to-noise ratio or >> packet-acknowledgements. > > maybe that SNR can be a threat but did not see a wg routing using > that info. Then you are just ignorant about things like SNR based hysteresis and=20 link metrics. I suggest reading RFC6130 and=20 draft-ietf-manet-olsrv2-metrics-rationale-02 as a start, both mention=20 SNR in relation to MANET routing. Search engines like Google will give you lots of results about the topic = too. > If the NHDP is updating SNR and another routing protocol > is using that info from NHDP, I think if an attack on SNR then it > will affect the NHDP info and then the routing process. NHDP "updating" SNR? > Threats documented are not only to the NHDP processes, but also its > information. If the NHDP does not use one information item, then it > does not mean that if the item information was attacked the NHDP is > not attacked. Any information in NHDP is the NHDP responsibility > don't you think, Threats documents are about attacks against the specified protocol=20 mechanisms. NHDP does not specify any hysteresis mechanism. NHDP suggest a couple of ideas how to to hysteresis. Nobody (including=20 you) seems to suggest to put attacks against all of them into the threat = document. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms090201020901000302080107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMjUxMzE2NTFaMCMGCSqGSIb3DQEJBDEWBBSnrVTRAUX5ModkbJlMtw/UtQcfazBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAKSuYu4pm9D4jkwKb3KP35mtcx3jbopjrP3V+RiU+osxg CHyCgm9g8xCzfFTQN0vsVixUcCz6jH/yvTbSLqHcHLPxQx/wFEXpBMwa0USc0cUfJ3Bzqd4g GY2Y4Qwo2jjC56U5zEWBDlKayshcZSv8Pi1U1w1Vk5Rdi6qRuCnIoONc8R/gAxT4PPYetwiZ oGOjmOLVc7McsHZpj+8TqiaWSt73q7BFt5qI0tHhyHjZitQ5Z1Ap2FwLp+jX0vKkIPvQqyaL AP1AxFqvfgyvhVhUBJnAk1UIOrnHIP5zuG72HAJ1iP/MqWyDJ7o9ABDf/LB+tE6QI1CtGGF4 tzOGgO2vqAAAAAAAAA== --------------ms090201020901000302080107-- From iesg-secretary@ietf.org Mon Feb 25 06:53:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EB321F9378; Mon, 25 Feb 2013 06:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss93mbq9tCiu; Mon, 25 Feb 2013 06:53:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5731821F9362; Mon, 25 Feb 2013 06:53:55 -0800 (PST) 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: 4.40 Message-ID: <20130225145355.12757.50947.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 06:53:55 -0800 Cc: manet@ietf.org Subject: [manet] Last Call: (Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale) to Informational RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:53:56 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract OLSRv2 includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Feb 25 06:53:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1701C21F9362 for ; Mon, 25 Feb 2013 06:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS2LbPH3Xqpd; Mon, 25 Feb 2013 06:53:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7035D21F9364; Mon, 25 Feb 2013 06:53:55 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40 X-IETF-Draft-string: draft-ietf-manet-olsrv2-metrics-rationale X-IETF-Draft-revision: 02 Message-ID: <20130225145355.12757.70183.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 06:53:55 -0800 Cc: manet@ietf.org Subject: [manet] Last Call: (Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale) to Informational RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:53:56 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract OLSRv2 includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale/ballot/ No IPR declarations have been submitted directly on this I-D. From wwwrun@rfc-editor.org Mon Feb 25 07:18:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC0E21F92C8 for ; Mon, 25 Feb 2013 07:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJV5NoYveS0d for ; Mon, 25 Feb 2013 07:18:14 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 65D0D21F9269 for ; Mon, 25 Feb 2013 07:18:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EB129B1E008; Mon, 25 Feb 2013 07:17:05 -0800 (PST) To: T.Clausen@computer.org, chris.dearlove@baesystems.com, jdean@itd.nrl.navy.mil, Cedric.Adjih@inria.fr, stbryant@cisco.com, adrian@olddog.co.uk, sratliff@cisco.com, macker@itd.nrl.navy.mil From: RFC Errata System Message-Id: <20130225151705.EB129B1E008@rfc-editor.org> Date: Mon, 25 Feb 2013 07:17:05 -0800 (PST) X-Mailman-Approved-At: Mon, 25 Feb 2013 07:35:48 -0800 Cc: chris.dearlove@baesystems.com, manet@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:18:15 -0000 The following errata report has been submitted for RFC5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=3496 -------------------------------------- Type: Technical Reported by: Christopher Dearlove Section: Appendix A Original Text ------------- o The field, if present, contains a sequence number that is incremented by 1 for each packet generated by a node. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way. Corrected Text -------------- o The field, if present, contains a sequence number that SHOULD be maintained for each participating interface and incremented by 1 for each packet generated by a node for that interface. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way. Notes ----- Packet sequence number should be per interface, not per node. Uses that recognise missing packet sequence numbers only work in the corrected (intended) case. Instructions: ------------- This errata 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. -------------------------------------- RFC5444 (draft-ietf-manet-packetbb-17) -------------------------------------- Title : Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format Publication Date : February 2009 Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Feb 25 07:20:28 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2788321F9472 for ; Mon, 25 Feb 2013 07:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt+CuCCr9Hne for ; Mon, 25 Feb 2013 07:20:27 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B26F421F9471 for ; Mon, 25 Feb 2013 07:20:27 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 44E19B1E008; Mon, 25 Feb 2013 07:19:19 -0800 (PST) To: T.Clausen@computer.org, chris.dearlove@baesystems.com, jdean@itd.nrl.navy.mil, Cedric.Adjih@inria.fr, stbryant@cisco.com, adrian@olddog.co.uk, sratliff@cisco.com, macker@itd.nrl.navy.mil From: RFC Errata System Message-Id: <20130225151919.44E19B1E008@rfc-editor.org> Date: Mon, 25 Feb 2013 07:19:19 -0800 (PST) X-Mailman-Approved-At: Mon, 25 Feb 2013 07:35:48 -0800 Cc: chris.dearlove@baesystems.com, manet@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Editorial Errata Reported] RFC5444 (3497) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:20:28 -0000 The following errata report has been submitted for RFC5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=3497 -------------------------------------- Type: Editorial Reported by: Christopher Dearlove Section: Appendix D.6 Original Text ------------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |0|0|0|0|1|M|Rsv| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Corrected Text -------------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |0|0|0|1|1|M|Rsv| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Notes ----- Corrects example TLV to have correct bits. Instructions: ------------- This errata 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. -------------------------------------- RFC5444 (draft-ietf-manet-packetbb-17) -------------------------------------- Title : Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format Publication Date : February 2009 Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From abdussalambaryun@gmail.com Mon Feb 25 07:47:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D13E21F9455 for ; Mon, 25 Feb 2013 07:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya-Pl1894lCl for ; Mon, 25 Feb 2013 07:47:51 -0800 (PST) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9D45121F9454 for ; Mon, 25 Feb 2013 07:47:51 -0800 (PST) Received: by mail-da0-f50.google.com with SMTP id h15so1311851dan.9 for ; Mon, 25 Feb 2013 07:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=hC5DDz2xTlGjTo9k0A834AZzaynrYwcMyq4LWdDd5/w=; b=fq4Mj6fm1A6CoU87nhkQ2Cw8mo7tjtjnZ5pNDoyRJaYt9r4zidZyfgIdO2cZPYI2E+ uMt2YfbjtnLcm2+OM3QtFGtzSr8SaEPNnInFIDbk1jBmLi1RV3LzNi2iYHaIDLytSqPk gqZ+tO9CXoXdpTb10LRQKJQPwNX+p6UKjKzSItJZgRpJZsnL3eD2pcrWHzI3qRzO2P7K nAfduYk3QaVgmnBtvrz2d0STW5aVkEhL28rE9viOGZwQUd7+euKJD9QmFVmsZqcUtsRw gzamramFj5+7424MUbGH84FVGisFZEgNbAg46wPjj855KZ76noViU+rtFMCHezyigD41 OIyA== MIME-Version: 1.0 X-Received: by 10.66.220.227 with SMTP id pz3mr19361787pac.190.1361807271228; Mon, 25 Feb 2013 07:47:51 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 25 Feb 2013 07:47:51 -0800 (PST) In-Reply-To: <20130225151705.EB129B1E008@rfc-editor.org> References: <20130225151705.EB129B1E008@rfc-editor.org> Date: Mon, 25 Feb 2013 15:47:51 +0000 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=047d7b5d49f4a7755d04d68e7677 Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:47:52 -0000 --047d7b5d49f4a7755d04d68e7677 Content-Type: text/plain; charset=ISO-8859-1 I agree with the update AB On Mon, Feb 25, 2013 at 3:17 PM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > > The following errata report has been submitted for RFC5444, > "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=3496 > > -------------------------------------- > Type: Technical > Reported by: Christopher Dearlove > > Section: Appendix A > > Original Text > ------------- > o The field, if present, contains a sequence number > that is incremented by 1 for each packet generated by a node. The > sequence number after 65535 is 0. In other words, the sequence > number "wraps" in the usual way. > > > Corrected Text > -------------- > o The field, if present, contains a sequence number > that SHOULD be maintained for each participating interface and > incremented by 1 for each packet generated by a node for that > interface. The sequence number after 65535 is 0. In other words, > the sequence number "wraps" in the usual way. > > > Notes > ----- > Packet sequence number should be per interface, not per node. Uses that > recognise missing packet sequence numbers only work in the corrected > (intended) case. > > Instructions: > ------------- > This errata 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. > > -------------------------------------- > RFC5444 (draft-ietf-manet-packetbb-17) > -------------------------------------- > Title : Generalized Mobile Ad Hoc Network (MANET) > Packet/Message Format > Publication Date : February 2009 > Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih > Category : PROPOSED STANDARD > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b5d49f4a7755d04d68e7677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with the update
=A0
AB

On Mon, Feb 25, 2013 at 3:17 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The following errata report has been submitted for RFC5444,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format"= .

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D5444&eid=3D3496

--------------------------------------
Type: Technical
Reported by: Christopher Dearlove <chris.dearlove@baesystems.com>

Section: Appendix A

Original Text
-------------
=A0 =A0o =A0The <pkt-seq-num> field, if present, contains a sequence = number
=A0 =A0 =A0 that is incremented by 1 for each packet generated by a node. = =A0The
=A0 =A0 =A0 sequence number after 65535 is 0. =A0In other words, the sequen= ce
=A0 =A0 =A0 number "wraps" in the usual way.


Corrected Text
--------------
=A0 =A0o =A0The <pkt-seq-num> field, if present, contains a sequence = number
=A0 =A0 =A0 that SHOULD be maintained for each participating interface and<= br> =A0 =A0 =A0 incremented by 1 for each packet generated by a node for that =A0 =A0 =A0 interface. =A0The sequence number after 65535 is 0. =A0In other= words,
=A0 =A0 =A0 the sequence number "wraps" in the usual way.


Notes
-----
Packet sequence number should be per interface, not per node. Uses that rec= ognise missing packet sequence numbers only work in the corrected (intended= ) case.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
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.

--------------------------------------
RFC5444 (draft-ietf-manet-packetbb-17)
--------------------------------------
Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Generalized Mobile Ad Hoc Network (MANE= T) Packet/Message Format
Publication Date =A0 =A0: February 2009
Author(s) =A0 =A0 =A0 =A0 =A0 : T. Clausen, C. Dearlove, J. Dean, C. Adjih<= br> Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Mobile Ad-hoc Networks
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7b5d49f4a7755d04d68e7677-- From abdussalambaryun@gmail.com Mon Feb 25 07:51:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E92021F94E5 for ; Mon, 25 Feb 2013 07:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQfxwNbFE12x for ; Mon, 25 Feb 2013 07:51:36 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 43DA521F94AB for ; Mon, 25 Feb 2013 07:51:36 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md12so1754203pbc.30 for ; Mon, 25 Feb 2013 07:51:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=R5DEoTx2a+8Yaq4ySR+AQZYMTV4u+4/5toELQoK/m3M=; b=ERM042kQL5KqmJPfAUF+pp1phTaY2hBPzdGBqPeHbMB9n9nXea9Oc++C2pPNivrvUb EInK05MqyXjA0nUKgzIVJa4K2OO6GZ8JeKx8E74O4pXRFH3EqdI1LsVIG/mJEInHp7ei rNFi4/S0Cluknr6xkeNywldQgO8MBK+6lrAEe5oTlbj15vTZ6+ySNTONeT8LW29pujv0 qT1nrmHCg1VdIsy57V6nioTvfaiKUWjnOCQnIBioPVhQaSpphz2mKM8DwZab5zBpymi9 COoTSEOG7CPKil3kJxB2H8tyUeHc+hyQ3kR4b3upzR1kvfG+oEuw6FvfhlOZMbYKIaYN Abnw== MIME-Version: 1.0 X-Received: by 10.68.143.40 with SMTP id sb8mr18753954pbb.202.1361807496013; Mon, 25 Feb 2013 07:51:36 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 25 Feb 2013 07:51:35 -0800 (PST) In-Reply-To: <512B6443.9020807@fkie.fraunhofer.de> References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fkie.fraunhofer.de> Date: Mon, 25 Feb 2013 15:51:35 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b2e42a20d674704d68e8478 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:51:38 -0000 --047d7b2e42a20d674704d68e8478 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is an update by RFC5444 author regarding sequence number of the RFC5444 packet. Now it become related to interface sequencing, AB On Mon, Feb 25, 2013 at 1:16 PM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > Am 25.02.2013 13:36, schrieb Abdussalam Baryun: > > There was a hysteresis implementation example in OLSRv1 >>> (RFC3626)... it didn't worked well. I think that is the reason NHDP >>> only gives some hints what you could look at when implementing a >>> hysteresis function. >>> >>> NHDP also mentions the possibility to use signal-to-noise ratio or >>> packet-acknowledgements. >>> >> >> maybe that SNR can be a threat but did not see a wg routing using >> that info. >> > > Then you are just ignorant about things like SNR based hysteresis and lin= k > metrics. > > I suggest reading RFC6130 and draft-ietf-manet-olsrv2-**metrics-rationale= -02 > as a start, both mention SNR in relation to MANET routing. > > Search engines like Google will give you lots of results about the topic > too. > > > > If the NHDP is updating SNR and another routing protocol > >> is using that info from NHDP, I think if an attack on SNR then it >> will affect the NHDP info and then the routing process. >> > > NHDP "updating" SNR? > > > Threats documented are not only to the NHDP processes, but also its >> information. If the NHDP does not use one information item, then it >> does not mean that if the item information was attacked the NHDP is >> not attacked. Any information in NHDP is the NHDP responsibility >> don't you think, >> > > Threats documents are about attacks against the specified protocol > mechanisms. NHDP does not specify any hysteresis mechanism. > > NHDP suggest a couple of ideas how to to hysteresis. Nobody (including > you) seems to suggest to put attacks against all of them into the threat > document. > > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b2e42a20d674704d68e8478 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There is an update by RFC5444 author regarding sequence number of the = RFC5444 packet. Now it become related to interface sequencing,
= =A0
AB

On Mon, Feb 25, 20= 13 at 1:16 PM, Henning Rogge <henning.rogge@fkie.fraunhofer= .de> wrote:
Am 25.02.2013 13:36, schrieb Abdussalam Baryun:

There was a hysteresis implementation example in OLSRv1
(RFC3626)... it didn't worked well. I think that is the reason NHDP
only gives some hints what you could look at when implementing a
hysteresis function.

NHDP also mentions the possibility to use signal-to-noise ratio or
packet-acknowledgements.

maybe that SNR can be a threat but did not see a wg routing using
that info.

Then you are just ignorant about things like SNR based hysteresis and link = metrics.

I suggest reading RFC6130 and draft-ietf-manet-olsrv2-metrics-ration= ale-02 as a start, both mention SNR in relation to MANET routing.

Search engines like Google will give you lots of results about the topic to= o.


> If the NHDP is updating SNR and another routing protocol
is using that info from NHDP, I think if an attack on SNR then it
will affect the NHDP info and then the routing process.

NHDP "updating" SNR?


Threats documented are not only to the NHDP processes, but also its
information. If the NHDP does not use one information item, then it
does not mean that if the item information was attacked the NHDP is
not attacked. Any information in NHDP is the NHDP responsibility
don't you think,

Threats documents are about attacks against the specified protocol mechanis= ms. NHDP does not specify any hysteresis mechanism.

NHDP suggest a couple of ideas how to to hysteresis. Nobody (including you)= seems to suggest to put attacks against all of them into the threat docume= nt.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0


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


--047d7b2e42a20d674704d68e8478-- From hrogge@googlemail.com Mon Feb 25 07:58:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B33521F9242 for ; Mon, 25 Feb 2013 07:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXKsY51uiuRP for ; Mon, 25 Feb 2013 07:58:05 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 20E3821F9240 for ; Mon, 25 Feb 2013 07:58:04 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id l12so2362476lbo.33 for ; Mon, 25 Feb 2013 07:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Kvn0Hxh3lWLzKHXjLrkOr/JoEiD7DwBx1rK3m1U1/vY=; b=biY7eH9ibG/i5pKWOXfiYy7xdhNieDWEla4zI1KXwq6DHJ8IQky8xGCTDGh4YiQ/L6 Lsimghw1hrcJvDBM62T/h06ALzYtwSPYY8ViAyCgjZrUT0Mx0gwQeyfAMy4r68FUWEOO nHkoZZRsPtgt4Anz5QDc9MVluolIekyz709sKlFXvR1ELILMk0dtA/fTc6/yvi7mmDHs H0fuSHc/Zu4CdzsmTo7TCWmeelcYeTi/1Vz3e46O+WKhoDgJoVAX0JQ39D7J7BBhcRwq swR1nK+72GqZJ5XCa8+DrrRagzSHb4Ssz3yHSmv3vPglGpggw2HYKcXiyXkWc9rhY0S2 an1Q== X-Received: by 10.152.123.34 with SMTP id lx2mr10351057lab.52.1361807875718; Mon, 25 Feb 2013 07:57:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Mon, 25 Feb 2013 07:57:34 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fkie.fraunhofer.de> From: Henning Rogge Date: Mon, 25 Feb 2013 16:57:34 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:58:06 -0000 It always was... the "error" has been known for a long time. My implementation of the RFC5444 (de)multiplexer has been using this "packet sequence number per interface" for a long time. Henning Rogge On Mon, Feb 25, 2013 at 4:51 PM, Abdussalam Baryun wrote: > There is an update by RFC5444 author regarding sequence number of the > RFC5444 packet. Now it become related to interface sequencing, > > AB > > On Mon, Feb 25, 2013 at 1:16 PM, Henning Rogge > wrote: >> >> Am 25.02.2013 13:36, schrieb Abdussalam Baryun: >> >>>> There was a hysteresis implementation example in OLSRv1 >>>> (RFC3626)... it didn't worked well. I think that is the reason NHDP >>>> only gives some hints what you could look at when implementing a >>>> hysteresis function. >>>> >>>> NHDP also mentions the possibility to use signal-to-noise ratio or >>>> packet-acknowledgements. >>> >>> >>> maybe that SNR can be a threat but did not see a wg routing using >>> that info. >> >> >> Then you are just ignorant about things like SNR based hysteresis and li= nk >> metrics. >> >> I suggest reading RFC6130 and draft-ietf-manet-olsrv2-metrics-rationale-= 02 >> as a start, both mention SNR in relation to MANET routing. >> >> Search engines like Google will give you lots of results about the topic >> too. >> >> >> > If the NHDP is updating SNR and another routing protocol >>> >>> is using that info from NHDP, I think if an attack on SNR then it >>> will affect the NHDP info and then the routing process. >> >> >> NHDP "updating" SNR? >> >> >>> Threats documented are not only to the NHDP processes, but also its >>> information. If the NHDP does not use one information item, then it >>> does not mean that if the item information was attacked the NHDP is >>> not attacked. Any information in NHDP is the NHDP responsibility >>> don't you think, >> >> >> Threats documents are about attacks against the specified protocol >> mechanisms. NHDP does not specify any hysteresis mechanism. >> >> NHDP suggest a couple of ideas how to to hysteresis. Nobody (including >> you) seems to suggest to put attacks against all of them into the threat >> document. >> >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From Chris.Dearlove@baesystems.com Mon Feb 25 08:21:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3370221F953D for ; Mon, 25 Feb 2013 08:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MzZ9WVW6KIe for ; Mon, 25 Feb 2013 08:21:10 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 496D321F952F for ; Mon, 25 Feb 2013 08:21:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; d="scan'208";a="267651303" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 25 Feb 2013 16:21:09 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r1PGL89m000305 for ; Mon, 25 Feb 2013 16:21:08 GMT X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; d="scan'208";a="8702245" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 25 Feb 2013 16:21:08 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Mon, 25 Feb 2013 16:21:08 +0000 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Abdussalam Baryun Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt Thread-Index: AQHOEeEdQcK/1dKC6UukRyjp9E9HrJiHzkyAgABbgACAAIUFAIAAHDMAgAAFiwCAADMyAIAAjWwAgAAFVgCAAIXSAIAADs8AgAABjACAAAbWAIAAAhKAgAAFCoCAAErzAIAAC2eAgAArPICAAAGsAIAABTig Date: Mon, 25 Feb 2013 16:21:08 +0000 Message-ID: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fkie.fraunhofer.de> 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 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:21:12 -0000 Both errata I submitted today were originally pointed out by other people, = I forget who (maybe even Henning for this one). Originally I left it to the= discovers to submit and claim the (fairly small) credit, but they didn't, = and it drifted, and then I finally got around to them today. This in fact just matches behaviour in RFC 3626. As for how to protect it, should you care, the answer would be in a securit= y mechanism for RFC 5444. It's fairly obvious reading RFC 6622 (or bis) wha= t that would be (ICV and TIMESTAMP packet TLVs). --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 25 February 2013 15:58 To: Abdussalam Baryun Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- It always was... the "error" has been known for a long time. My implementation of the RFC5444 (de)multiplexer has been using this "packet sequence number per interface" for a long time. Henning Rogge On Mon, Feb 25, 2013 at 4:51 PM, Abdussalam Baryun wrote: > There is an update by RFC5444 author regarding sequence number of the > RFC5444 packet. Now it become related to interface sequencing, > > AB > > On Mon, Feb 25, 2013 at 1:16 PM, Henning Rogge > wrote: >> >> Am 25.02.2013 13:36, schrieb Abdussalam Baryun: >> >>>> There was a hysteresis implementation example in OLSRv1 >>>> (RFC3626)... it didn't worked well. I think that is the reason NHDP >>>> only gives some hints what you could look at when implementing a >>>> hysteresis function. >>>> >>>> NHDP also mentions the possibility to use signal-to-noise ratio or >>>> packet-acknowledgements. >>> >>> >>> maybe that SNR can be a threat but did not see a wg routing using >>> that info. >> >> >> Then you are just ignorant about things like SNR based hysteresis and li= nk >> metrics. >> >> I suggest reading RFC6130 and draft-ietf-manet-olsrv2-metrics-rationale-= 02 >> as a start, both mention SNR in relation to MANET routing. >> >> Search engines like Google will give you lots of results about the topic >> too. >> >> >> > If the NHDP is updating SNR and another routing protocol >>> >>> is using that info from NHDP, I think if an attack on SNR then it >>> will affect the NHDP info and then the routing process. >> >> >> NHDP "updating" SNR? >> >> >>> Threats documented are not only to the NHDP processes, but also its >>> information. If the NHDP does not use one information item, then it >>> does not mean that if the item information was attacked the NHDP is >>> not attacked. Any information in NHDP is the NHDP responsibility >>> don't you think, >> >> >> Threats documents are about attacks against the specified protocol >> mechanisms. NHDP does not specify any hysteresis mechanism. >> >> NHDP suggest a couple of ideas how to to hysteresis. Nobody (including >> you) seems to suggest to put attacks against all of them into the threat >> document. >> >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan _______________________________________________ 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 hrogge@googlemail.com Mon Feb 25 08:29:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CC621F9572 for ; Mon, 25 Feb 2013 08:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HW4Q0kXUVqTH for ; Mon, 25 Feb 2013 08:29:12 -0800 (PST) Received: from mail-la0-x236.google.com (la-in-x0236.1e100.net [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD0921F9521 for ; Mon, 25 Feb 2013 08:29:11 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id gw10so2896483lab.27 for ; Mon, 25 Feb 2013 08:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=gdvhqKpSrgSHQxGI2jRUQn2FZpbAgJ6exZ0Sq9wR+Qo=; b=Y4v4hOTMVE9pvb0CY/hTrkicW0cgoZSWCihXaJENzACCPlDgXBk60rhbvA2y+yfA3r ztTJrFRroE8Cj6ghjrOdB0tv7R4qbi4r54QKn9j1yReRhpBOh6/fSE2bVns8xToVoigq G/ZkktJ3xtKOLJ/LpGzYLnP3N5Gk9G62h9VI8g6BQxE+bCKRzQjvycPySEp/zavDowd2 He1PQhSd/m+VDsLKDUN3SvhMkWWnuDn8RhEpHJR8qtoLXHAzZuBp+ntZWY2CqnjlImkA iBTNlDNrOz9Y98nzjvSaHWTN/I8Wwo0K0prI5z2W+DOT8Uzpfx7Cj8U3B0QN73gvXPGt NPkg== X-Received: by 10.112.40.228 with SMTP id a4mr4686206lbl.26.1361809750262; Mon, 25 Feb 2013 08:29:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Mon, 25 Feb 2013 08:28:49 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fkie.fraunhofer.de> From: Henning Rogge Date: Mon, 25 Feb 2013 17:28:49 +0100 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:29:15 -0000 On Mon, Feb 25, 2013 at 5:21 PM, Dearlove, Christopher (UK) wrote: > Both errata I submitted today were originally pointed out by other people= , I forget who (maybe even Henning for this one). Originally I left it to t= he discovers to submit and claim the (fairly small) credit, but they didn't= , and it drifted, and then I finally got around to them today. Might be... but the important thing is that we got it fixed. > This in fact just matches behaviour in RFC 3626. Yes. > As for how to protect it, should you care, the answer would be in a secur= ity mechanism for RFC 5444. It's fairly obvious reading RFC 6622 (or bis) w= hat that would be (ICV and TIMESTAMP packet TLVs). Yes. It is packet level data, it should be protected by packet-level securi= ty. Henning Rogge --=20 We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From abdussalambaryun@gmail.com Mon Feb 25 08:32:14 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743D021F959B for ; Mon, 25 Feb 2013 08:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KHBUirF3M+t for ; Mon, 25 Feb 2013 08:32:12 -0800 (PST) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0A92F21F9599 for ; Mon, 25 Feb 2013 08:32:08 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id kl14so1848927pab.4 for ; Mon, 25 Feb 2013 08:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kTAEqZ5PxnKEjPCfflyBKdTOQ2OqBYXHbspfT7CRMN0=; b=jH1tF8vBlCb+ktWA++SgkUp0aV0q1h4U72JAfqh7pEZd02ICDARJ1uJ+y82qwPrx3V zfslRKbi12aIADxmZMCKJN+tv/OgoA4jusnSrYNsuqQHB/b2VElAlTwwzV4WYbgW5jRe DXczK1xM8/O/EgaTDDwUg0wonlct0/iBwYv1DQ5+uFVw/FYifOZPdxZi0mllrP8s0kYA HF1kHHXiWu87hpapvlOEojK8pVzvpXKgcD02/a2Yr3oHAxhcpjei1ozHXmfrKULPd+1Y Rini9PIvS3nWHYw8aXEqMOcZBd+niZNEZ1OPmmfdbS+ywjCsvwpfW9w0kyCIdFEu3wrB jQkg== MIME-Version: 1.0 X-Received: by 10.68.245.229 with SMTP id xr5mr18773701pbc.163.1361809927733; Mon, 25 Feb 2013 08:32:07 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 25 Feb 2013 08:32:07 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fkie.fraunhofer.de> Date: Mon, 25 Feb 2013 16:32:07 +0000 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=047d7b2e155dfe808d04d68f1478 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:32:14 -0000 --047d7b2e155dfe808d04d68f1478 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Chris, What is more important for me is your opinion about adding NHDP sequence number in the threat doc or not, please advise, AB On Mon, Feb 25, 2013 at 4:21 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > Both errata I submitted today were originally pointed out by other people= , > I forget who (maybe even Henning for this one). Originally I left it to t= he > discovers to submit and claim the (fairly small) credit, but they didn't, > and it drifted, and then I finally got around to them today. > > This in fact just matches behaviour in RFC 3626. > > As for how to protect it, should you care, the answer would be in a > security mechanism for RFC 5444. It's fairly obvious reading RFC 6622 (or > bis) what that would be (ICV and TIMESTAMP packet TLVs). > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Henning Rogge > Sent: 25 February 2013 15:58 > To: Abdussalam Baryun > Cc: manet@ietf.org > Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > It always was... the "error" has been known for a long time. > > My implementation of the RFC5444 (de)multiplexer has been using this > "packet sequence number per interface" for a long time. > > Henning Rogge > > On Mon, Feb 25, 2013 at 4:51 PM, Abdussalam Baryun > wrote: > > There is an update by RFC5444 author regarding sequence number of the > > RFC5444 packet. Now it become related to interface sequencing, > > > > AB > > > > On Mon, Feb 25, 2013 at 1:16 PM, Henning Rogge > > wrote: > >> > >> Am 25.02.2013 13:36, schrieb Abdussalam Baryun: > >> > >>>> There was a hysteresis implementation example in OLSRv1 > >>>> (RFC3626)... it didn't worked well. I think that is the reason NHDP > >>>> only gives some hints what you could look at when implementing a > >>>> hysteresis function. > >>>> > >>>> NHDP also mentions the possibility to use signal-to-noise ratio or > >>>> packet-acknowledgements. > >>> > >>> > >>> maybe that SNR can be a threat but did not see a wg routing using > >>> that info. > >> > >> > >> Then you are just ignorant about things like SNR based hysteresis and > link > >> metrics. > >> > >> I suggest reading RFC6130 and > draft-ietf-manet-olsrv2-metrics-rationale-02 > >> as a start, both mention SNR in relation to MANET routing. > >> > >> Search engines like Google will give you lots of results about the top= ic > >> too. > >> > >> > >> > If the NHDP is updating SNR and another routing protocol > >>> > >>> is using that info from NHDP, I think if an attack on SNR then it > >>> will affect the NHDP info and then the routing process. > >> > >> > >> NHDP "updating" SNR? > >> > >> > >>> Threats documented are not only to the NHDP processes, but also its > >>> information. If the NHDP does not use one information item, then it > >>> does not mean that if the item information was attacked the NHDP is > >>> not attacked. Any information in NHDP is the NHDP responsibility > >>> don't you think, > >> > >> > >> Threats documents are about attacks against the specified protocol > >> mechanisms. NHDP does not specify any hysteresis mechanism. > >> > >> NHDP suggest a couple of ideas how to to hysteresis. Nobody (including > >> you) seems to suggest to put attacks against all of them into the thre= at > >> document. > >> > >> > >> Henning Rogge > >> > >> -- > >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >> Kommunikationssysteme (KOM) > >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >> Telefon +49 228 9435-961, Fax +49 228 9435 685 > >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > >> > >> > >> _______________________________________________ > >> 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 > > > > > > -- > We began as wanderers, and we are wanderers still. We have lingured > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > 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. > ******************************************************************** > > --047d7b2e155dfe808d04d68f1478 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chris,
=A0
What is more important for me is you= r opinion about adding NHDP sequence number in the threat doc or not, pleas= e advise,
=A0
AB

On Mon, Feb 25, 2013 at 4:21 PM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:
Both errata I submitted today were originally pointed out = by other people, I forget who (maybe even Henning for this one). Originally= I left it to the discovers to submit and claim the (fairly small) credit, = but they didn't, and it drifted, and then I finally got around to them = today.

This in fact just matches behaviour in RFC 3626.

As for how to protect it, should you care, the answer would be in a securit= y mechanism for RFC 5444. It's fairly obvious reading RFC 6622 (or bis)= what that would be (ICV and TIMESTAMP packet TLVs).

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245= 242194=A0| =A0Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://ww= w.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge
Sent: 25 February 2013 15:58
To: Abdussalam Baryun
Cc: manet@ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt
----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

It always was... the "error" has been known for a long time.

My implementation of the RFC5444 (de)multiplexer has been using this
"packet sequence number per interface" for a long time.

Henning Rogge

On Mon, Feb 25, 2013 at 4:51 PM, Abdussalam Baryun
<abdussalambaryun@gmail.co= m> wrote:
> There is an update by RFC5444 author regarding sequence number of the<= br> > RFC5444 packet. Now it become related to interface sequencing,
>
> AB
>
> On Mon, Feb 25, 2013 at 1:16 PM, Henning Rogge
> <henning.rogge@= fkie.fraunhofer.de> wrote:
>>
>> Am 25.02.20= 13 13:36, schrieb Abdussalam Baryun:
>>
>>>> There was a hysteresis implementation example in OLSRv1 >>>> (RFC3626)... it didn't worked well. I think that is th= e reason NHDP
>>>> only gives some hints what you could look at when implemen= ting a
>>>> hysteresis function.
>>>>
>>>> NHDP also mentions the possibility to use signal-to-noise = ratio or
>>>> packet-acknowledgements.
>>>
>>>
>>> maybe that SNR can be a threat but did not see a wg routing us= ing
>>> that info.
>>
>>
>> Then you are just ignorant about things like SNR based hysteresis = and link
>> metrics.
>>
>> I suggest reading RFC6130 and draft-ietf-manet-olsrv2-metrics-rati= onale-02
>> as a start, both mention SNR in relation to MANET routing.
>>
>> Search engines like Google will give you lots of results about the= topic
>> too.
>>
>>
>> > If the NHDP is updating SNR and another routing protocol
>>>
>>> is using that info from NHDP, I think if an attack on SNR then= it
>>> will affect the NHDP info and then the routing process.
>>
>>
>> NHDP "updating" SNR?
>>
>>
>>> Threats documented are not only to the NHDP processes, but als= o its
>>> information. If the NHDP does not use one information item, th= en it
>>> does not mean that if the item information was attacked the NH= DP is
>>> not attacked. Any information in NHDP is the NHDP responsibili= ty
>>> don't you think,
>>
>>
>> Threats documents are about attacks against the specified protocol=
>> mechanisms. NHDP does not specify any hysteresis mechanism.
>>
>> NHDP suggest a couple of ideas how to to hysteresis. Nobody (inclu= ding
>> you) seems to suggest to put attacks against all of them into the = threat
>> document.
>>
>>
>> Henning Rogge
>>
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM)
>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>> Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685
>> mailto:henning= .rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
>>
>>
>> _______________________________________________
>> 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
>



--
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://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.
********************************************************************


--047d7b2e155dfe808d04d68f1478-- From abdussalambaryun@gmail.com Mon Feb 25 08:41:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D1421F9552 for ; Mon, 25 Feb 2013 08:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyRccGRBBcqw for ; Mon, 25 Feb 2013 08:41:11 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D911C21F9550 for ; Mon, 25 Feb 2013 08:41:11 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1550047dae.3 for ; Mon, 25 Feb 2013 08:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BpFqy1PgaEftfzYIj2FFc90qy/tukx/DaVx16rf5j5E=; b=u8TPKtorTHrPeYQqnIiCkBHhKcpCCNOFxMVIikMD12kI4wKsq+MaXhC36qP9Mhw0te SfxOdTawKp7AsEkxttidmeIFKk2V6sWAOyk72nud/bqIN0ms6JgAEs4KVocW1DCLdTFc 2sMk1llO96edRS2/0N9jgDHXBM9b/vBMtWaDEvAfHOGczVy1K2MWIedccZuz7bCaI0yl R3EwGw61Ygmb5KTIi+rr4bHUkdX1C5dkf0/hyhRsxIOYW4TiAzlX4aYK7q/yUVCu/1VC hSbNAjyKFE5/7C/vDV9KWGniJK532zRV2f6/pF14kDoM3tMSnD35E2thEB2/A4Y7O/b1 mt2Q== MIME-Version: 1.0 X-Received: by 10.67.5.193 with SMTP id co1mr20008954pad.6.1361810471396; Mon, 25 Feb 2013 08:41:11 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 25 Feb 2013 08:41:11 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fkie.fraunhofer.de> Date: Mon, 25 Feb 2013 16:41:11 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b15a5a36624a704d68f3552 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:41:12 -0000 --047d7b15a5a36624a704d68f3552 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 25, 2013 at 3:57 PM, Henning Rogge wrote: > It always was... the "error" has been known for a long time. > > My implementation of the RFC5444 (de)multiplexer has been using this > "packet sequence number per interface" for a long time. > That is good so the RFC5444 was not correct for a long time then, and some people in the Internet Community did not know that. I knew also that RFC5444 needed update and still beleive that, This is wrong behavior of a WG to keep things related to RFC5444 for long time, I may misunderstanded your point, AB --047d7b15a5a36624a704d68f3552 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 25, 2013 at 3:57 PM, Henning Rogge <= span dir=3D"ltr"><hrogge@googlemail.com> wrote:
It always was... the "error" has been known for a long time.

My implementation of the RFC5444 (de)multiplexer has been using this
"packet sequence number per interface" for a long time.
=A0
That is good so=A0the RFC5444 was not correct for= a long time then, and some people in the Internet Community did not know t= hat. I knew also that RFC5444 needed update and still beleive that,
=A0
This is wrong behavior of a WG to keep things related to= RFC5444 for long time, I may misunderstanded your point,
=A0
AB
--047d7b15a5a36624a704d68f3552-- From hrogge@googlemail.com Mon Feb 25 08:52:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC6621F950F for ; Mon, 25 Feb 2013 08:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZX4nRBU8RXj for ; Mon, 25 Feb 2013 08:52:29 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 27FB121F94ED for ; Mon, 25 Feb 2013 08:52:28 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id fo13so2923017lab.38 for ; Mon, 25 Feb 2013 08:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=4CzmUKLKLx2giKQmF5lsDeq8ounON9LRao2VcqU4Hdg=; b=GPz950qTWAcSLJELqRDSjW0gWzNlaNm4bmYNgV9yJ43BQ7OzfGntMNVt/et8O6CBXo gU9u8UMbzEuWldsSuMk7sgNJHsKy8yfibdJLuDNlOqJso8EsCP4xzfXbdQm0Pv7UZpru utDaDpbpUFXL/Tv4weE0By/g1wjXGT1g5Pb/2qQjDGif98qClzfP367jgtMqf4+XrTeK HtlxACWaNBQ4GNbg4B3/TrT/S8UfsiUejjlhfRZF2Ex6sKOqccf8lAMrkysK9CgmJTLV cKhjo9K6XwWb57TpZEEYnvE254BEStMh5uA94fMWRE0vxLYvI7LV4aRxt0rAnrqzHoP2 jO7A== X-Received: by 10.112.24.199 with SMTP id w7mr4721526lbf.102.1361811148022; Mon, 25 Feb 2013 08:52:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Mon, 25 Feb 2013 08:52:07 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fkie.fraunhofer.de> From: Henning Rogge Date: Mon, 25 Feb 2013 17:52:07 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:52:30 -0000 On Mon, Feb 25, 2013 at 5:41 PM, Abdussalam Baryun wrote: > On Mon, Feb 25, 2013 at 3:57 PM, Henning Rogge > wrote: >> >> It always was... the "error" has been known for a long time. >> >> My implementation of the RFC5444 (de)multiplexer has been using this >> "packet sequence number per interface" for a long time. > > That is good so the RFC5444 was not correct for a long time then, and some > people in the Internet Community did not know that. I knew also that RFC5444 > needed update and still beleive that, We talked about this on this list quite some time ago. http://www.ietf.org/mail-archive/web/manet/current/msg11340.html Most likely the "trigger errata" got lost in the long discussion. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From abdussalambaryun@gmail.com Mon Feb 25 09:03:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FD421F959A for ; Mon, 25 Feb 2013 09:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHOVL2z-A5zh for ; Mon, 25 Feb 2013 09:03:25 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3141C21F9538 for ; Mon, 25 Feb 2013 09:03:23 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id hz10so1844684pad.7 for ; Mon, 25 Feb 2013 09:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JlJS6pft5UzxX7lwoyB6eNRartLZgWy70ibYF9zuTrI=; b=N7BfRP6p/Wk9wKrTSZo41Ucix+OwsStm3NEXU7/IRXfc70tW0PHgRC+ZeW8iP3jIV7 HUBjybMTAu2cZpQ8xk4Fk0SETFqEITS0Kdbx4pZvk4t4oMk1vIveswWeBmQhK/hq5H6m LNzIyUM3qu49jOq2TxaJKHKDV06dPG+xoQ9I9bmfdZHlTZDjeSwVE1UMcRAJMjoomLAV joExc2M3QcDmuFhVBgL7hzNRMVQQXYw+QfLifp9CmMtZwJM/PY35VrsFt24RT8L1CIYe PZA3HV1ZjNcmWlP6xAEz+N/D7GuPG6EKip4xOYmxnl9vOcBnYr8kMJs8IQZPW7hEyI13 HIAw== MIME-Version: 1.0 X-Received: by 10.66.13.74 with SMTP id f10mr20081341pac.202.1361811802967; Mon, 25 Feb 2013 09:03:22 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 25 Feb 2013 09:03:22 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fkie.fraunhofer.de> Date: Mon, 25 Feb 2013 17:03:22 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=bcaec520e62fc44ee904d68f8421 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:03:26 -0000 --bcaec520e62fc44ee904d68f8421 Content-Type: text/plain; charset=ISO-8859-1 Hi Henning, I agree that these things may happen in WG but we should try to not let it happen again. Many people may use the RFC5444 and not know that discussion. I think the WG Chair assigned within that discussion time is responsible for such situation, AB On Mon, Feb 25, 2013 at 4:52 PM, Henning Rogge wrote: > On Mon, Feb 25, 2013 at 5:41 PM, Abdussalam Baryun > wrote: > > On Mon, Feb 25, 2013 at 3:57 PM, Henning Rogge > > wrote: > >> > >> It always was... the "error" has been known for a long time. > >> > >> My implementation of the RFC5444 (de)multiplexer has been using this > >> "packet sequence number per interface" for a long time. > > > > That is good so the RFC5444 was not correct for a long time then, and > some > > people in the Internet Community did not know that. I knew also that > RFC5444 > > needed update and still beleive that, > > We talked about this on this list quite some time ago. > > http://www.ietf.org/mail-archive/web/manet/current/msg11340.html > > Most likely the "trigger errata" got lost in the long discussion. > > Henning Rogge > > -- > We began as wanderers, and we are wanderers still. We have lingured > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > --bcaec520e62fc44ee904d68f8421 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Henning,
=A0
I agree that these things may happ= en in WG but we should try to not let it happen again. Many people may use = the RFC5444 and not know that discussion. I think the WG Chair assigned wit= hin that discussion time is responsible for such situation,
=A0
AB

On Mon, Feb 2= 5, 2013 at 4:52 PM, Henning Rogge <hrogge@googlemail.com> wrote:
On Mon, Feb 25, 2013 at 5:41 PM, Abdussa= lam Baryun
<abdussalambaryun@gmail.co= m> wrote:
> On Mon, Feb 25, 2013 at 3:57 PM, Henning Rogge <hrogge@googlemail.com>
> wrote:
>>
>> It always was... the "error" has been known for a long t= ime.
>>
>> My implementation of the RFC5444 (de)multiplexer has been using th= is
>> "packet sequence number per interface" for a long time.<= br> >
> That is good so the RFC5444 was not correct for a long time then, and = some
> people in the Internet Community did not know that. I knew also that R= FC5444
> needed update and still beleive that,

We talked about this on this list quite some time ago.

http://www.ietf.org/mail-archive/web/manet/current/msg1= 1340.html

Most likely the "trigger errata" got lost in the long discussion.=

Henning Rogge

--
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

--bcaec520e62fc44ee904d68f8421-- From hrogge@googlemail.com Mon Feb 25 09:17:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301A721F8F6C for ; Mon, 25 Feb 2013 09:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fBpcUuh9GCc for ; Mon, 25 Feb 2013 09:17:49 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8EE21F8E43 for ; Mon, 25 Feb 2013 09:17:41 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id n8so2429513lbj.3 for ; Mon, 25 Feb 2013 09:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=8YgCw0YQftop7iUHrueiPADuIvQ6Vzhklj0vZEs87Vw=; b=XIZu7lG6XQ7PJdSXy4LNjX54mUiFMHRZuo5X9Dp4sHzWsAlyEFnhrOBOMulbFomIW8 FgCFLI3b60Ho8Zg0gqeniH4bhGqy6PNWA360ajGaQX3SuQl3U7aIwA/EsZ5VB1790Sym DC72PFtf8WiJw+HmrHvMDZ4yZEV551qA8sMB5TQjodxTj1/t8LrmKOgQ5mW5wJohWe+G X8nPsoV/Bw8vhcc+ZWj+uegQa2hP9SK4FD2vRLg1ELK5ro2/ABY56YrZnyx9GYlEkzLK +Vl+Z4QlnauaA2nkxL0XkjrPGZQn5uz/fJeg3lW1WZTej9C07uKRr5HL/WWTUG7Ya4Oq 7OGg== X-Received: by 10.152.148.133 with SMTP id ts5mr10705817lab.2.1361812660269; Mon, 25 Feb 2013 09:17:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Mon, 25 Feb 2013 09:17:20 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fkie.fraunhofer.de> From: Henning Rogge Date: Mon, 25 Feb 2013 18:17:20 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:17:50 -0000 On Mon, Feb 25, 2013 at 6:03 PM, Abdussalam Baryun wrote: > Hi Henning, > > I agree that these things may happen in WG but we should try to not let it > happen again. Many people may use the RFC5444 and not know that discussion. > I think the WG Chair assigned within that discussion time is responsible for > such situation, I think you are trying to make an issue out of nothing. First, the errata is a SHOULD, which means that any proprietary protocol can do whatever it likes. Second, neither DYMO nor NHDP nor OLSRv2 nor DLEP (which was using RFC5444 for some time) uses packet sequence numbers. In fact the only draft I remember which used RFC5444 packet sequence numbers was the "funkfeuer ETX" draft, which explicitly specified that the packet sequence numbers had to be interface specific to use this ETX variant. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From drdanhe@gmail.com Mon Feb 25 10:55:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280CE21F9374 for ; Mon, 25 Feb 2013 10:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMuHhdIIbxY3 for ; Mon, 25 Feb 2013 10:55:38 -0800 (PST) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 820EB21F9362 for ; Mon, 25 Feb 2013 10:55:32 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id j5so2750304iaf.14 for ; Mon, 25 Feb 2013 10:55:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pRK+bNPT54qfyzbumAPQUZ1/GbwoEWWR5l42BYsw5V8=; b=ul2IBcw5oPv/y7da6I1DrRtDtV8+OVskGrRHFZtzmsk8Jul7ATeYfwsnVfz6SyWLWS aiJSmR4rtElXt8kSI00aGJFpsjPmtAIK7vlqziGgeqsumP1ix+CY6BBZ0yV9R+YKqDxl iN1AhUHNgMFtzu9iOZV7p+KpV2Y7jql21mMEPSfgXsMGJRrmig6YG676ZggNfiFExQFx wPj85548vR3c5rOEX7z0OW1WsO1VWA3FKNWUxUhg/ND776I0sHhuPr2fMFDcUZZ+Bv2W GwPtqnjjLDfc/AKjhl5AJt1hAhuXceE1HYwos3uSNJhOg9uLNxwBfcD5+9eYYECc0dnJ EAaQ== MIME-Version: 1.0 X-Received: by 10.50.190.231 with SMTP id gt7mr3892092igc.85.1361818528048; Mon, 25 Feb 2013 10:55:28 -0800 (PST) Received: by 10.50.85.6 with HTTP; Mon, 25 Feb 2013 10:55:27 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fkie.fraunhofer.de> Date: Mon, 25 Feb 2013 18:55:27 +0000 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=14dae9340d159ce71104d69115a5 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 18:55:40 -0000 --14dae9340d159ce71104d69115a5 Content-Type: text/plain; charset=ISO-8859-1 Hi Mr Baryun, So what? if you didn't know that issues, that is you not on the whole internet community. Don't speak for US! Even we didn' t know those issues, now it is corrected that it is pretty fine to US. there is no wrong behavior as you accused of commiting on the time. I would like to remind you: DON'T SPAM in this mailing list. Every day I received your email for nothing! Cheers, Dan > > That is good so the RFC5444 was not correct for a long time then, and some > people in the Internet Community did not know that. I knew also that > RFC5444 needed update and still beleive that, > > This is wrong behavior of a WG to keep things related to RFC5444 for long > time, I may misunderstanded your point, > > AB > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --14dae9340d159ce71104d69115a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mr Baryun,

So what? if you didn't know that issues, that is y= ou not on the whole internet
community. Don't speak for US!

E= ven we didn' t know=A0 those issues, now it is corrected that it
is= pretty fine to US. there is no wrong behavior as you accused of commiting<= br> on the time. I would like to remind you: DON'T SPAM in this mailing lis= t.
Every day I received your email for nothing!

Cheers,

Da= n
=A0
That = is good so=A0the RFC5444 was not correct for a long time then, and some peo= ple in the Internet Community did not know that. I knew also that RFC5444 n= eeded update and still beleive that,
=A0
This is wrong behavior of a WG to keep things related to= RFC5444 for long time, I may misunderstanded your point,
=A0
AB

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




--14dae9340d159ce71104d69115a5-- From abdussalambaryun@gmail.com Mon Feb 25 07:39:40 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46BD21F9488 for ; Mon, 25 Feb 2013 07:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1-ky3MIvtQo for ; Mon, 25 Feb 2013 07:39:39 -0800 (PST) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id A925B21F946E for ; Mon, 25 Feb 2013 07:39:39 -0800 (PST) Received: by mail-da0-f54.google.com with SMTP id p1so933720dad.41 for ; Mon, 25 Feb 2013 07:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=U0Z1fB00opYCHZNyF8atzRUzM0EcAGExE0FFXhaHBAs=; b=YQrZ4oATUfTOf5wr4hZcHx06jpyg1c3PbeP9Zss1bE220iA3WbVMEE/tRKrrr2QwGY t/j6DpM4u58gF7fULLidBuCjJHFuLNMyxXK9YnHNJjMCHgnEx6wGu/erzap2ON7pX0/C juy+pqA+i609OlpUw66M9Pj6+EmWHrnuzVOswfuHMgcGs3qVaBnPSVFEIqJc40XEo98g rDmOTnJ121hMaA15IaD784PwibeyIQjrYvD8WXmWUJyJFxnZ/C4skUGkncvPx2InelAx apYau7WBu1Hb4Lf9kg1XL8hRIbhtaqsJZTvl+EPoHxvTMqzt55FZK+y5U0PGyDbd45SG Vr6Q== MIME-Version: 1.0 X-Received: by 10.68.138.170 with SMTP id qr10mr18370459pbb.190.1361806779392; Mon, 25 Feb 2013 07:39:39 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 25 Feb 2013 07:39:39 -0800 (PST) In-Reply-To: <20130225151705.EB129B1E008@rfc-editor.org> References: <20130225151705.EB129B1E008@rfc-editor.org> Date: Mon, 25 Feb 2013 15:39:39 +0000 Message-ID: From: Abdussalam Baryun To: RFC Errata System Content-Type: multipart/alternative; boundary=047d7b15aa2f56a3f104d68e5928 X-Mailman-Approved-At: Mon, 25 Feb 2013 13:42:52 -0800 Cc: macker@itd.nrl.navy.mil, T.Clausen@computer.org, chris.dearlove@baesystems.com, manet@ietf.org, Cedric.Adjih@inria.fr, sratliff@cisco.com, jdean@itd.nrl.navy.mil Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:39:40 -0000 --047d7b15aa2f56a3f104d68e5928 Content-Type: text/plain; charset=ISO-8859-1 +1 AB On Mon, Feb 25, 2013 at 3:17 PM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > > The following errata report has been submitted for RFC5444, > "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=3496 > > -------------------------------------- > Type: Technical > Reported by: Christopher Dearlove > > Section: Appendix A > > Original Text > ------------- > o The field, if present, contains a sequence number > that is incremented by 1 for each packet generated by a node. The > sequence number after 65535 is 0. In other words, the sequence > number "wraps" in the usual way. > > > Corrected Text > -------------- > o The field, if present, contains a sequence number > that SHOULD be maintained for each participating interface and > incremented by 1 for each packet generated by a node for that > interface. The sequence number after 65535 is 0. In other words, > the sequence number "wraps" in the usual way. > > > Notes > ----- > Packet sequence number should be per interface, not per node. Uses that > recognise missing packet sequence numbers only work in the corrected > (intended) case. > > Instructions: > ------------- > This errata 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. > > -------------------------------------- > RFC5444 (draft-ietf-manet-packetbb-17) > -------------------------------------- > Title : Generalized Mobile Ad Hoc Network (MANET) > Packet/Message Format > Publication Date : February 2009 > Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih > Category : PROPOSED STANDARD > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b15aa2f56a3f104d68e5928 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1
=A0
AB

= On Mon, Feb 25, 2013 at 3:17 PM, RFC Errata System <rfc-editor@rfc= -editor.org> wrote:

The following errata report has been submitted for RFC5444,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format"= .

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D5444&eid=3D3496

--------------------------------------
Type: Technical
Reported by: Christopher Dearlove <chris.dearlove@baesystems.com>

Section: Appendix A

Original Text
-------------
=A0 =A0o =A0The <pkt-seq-num> field, if present, contains a sequence = number
=A0 =A0 =A0 that is incremented by 1 for each packet generated by a node. = =A0The
=A0 =A0 =A0 sequence number after 65535 is 0. =A0In other words, the sequen= ce
=A0 =A0 =A0 number "wraps" in the usual way.


Corrected Text
--------------
=A0 =A0o =A0The <pkt-seq-num> field, if present, contains a sequence = number
=A0 =A0 =A0 that SHOULD be maintained for each participating interface and<= br> =A0 =A0 =A0 incremented by 1 for each packet generated by a node for that =A0 =A0 =A0 interface. =A0The sequence number after 65535 is 0. =A0In other= words,
=A0 =A0 =A0 the sequence number "wraps" in the usual way.


Notes
-----
Packet sequence number should be per interface, not per node. Uses that rec= ognise missing packet sequence numbers only work in the corrected (intended= ) case.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
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.

--------------------------------------
RFC5444 (draft-ietf-manet-packetbb-17)
--------------------------------------
Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Generalized Mobile Ad Hoc Network (MANE= T) Packet/Message Format
Publication Date =A0 =A0: February 2009
Author(s) =A0 =A0 =A0 =A0 =A0 : T. Clausen, C. Dearlove, J. Dean, C. Adjih<= br> Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Mobile Ad-hoc Networks
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7b15aa2f56a3f104d68e5928-- From internet-drafts@ietf.org Mon Feb 25 15:02:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE3521F9347; Mon, 25 Feb 2013 15:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbZAlCyFkMVc; Mon, 25 Feb 2013 15:02:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E5121E814D; Mon, 25 Feb 2013 15:01:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 15:01:39 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 23:02:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Dynamic MANET On-demand (AODVv2) Routing Author(s) : Charles E. Perkins Stan Ratliff John Dowdell Filename : draft-ietf-manet-dymo-26.txt Pages : 60 Date : 2013-02-25 Abstract: The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dymo There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-dymo-26 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From charliep@computer.org Mon Feb 25 15:09:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4242F21F94CC for ; Mon, 25 Feb 2013 15:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgSPRzUO4pyH for ; Mon, 25 Feb 2013 15:09:19 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8F60A21F94D7 for ; Mon, 25 Feb 2013 15:09:19 -0800 (PST) Received: from [107.1.141.74] (helo=[192.168.252.161]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1UA7Ab-00079y-PO; Mon, 25 Feb 2013 18:09:17 -0500 Message-ID: <512BEF17.70605@computer.org> Date: Mon, 25 Feb 2013 15:09:11 -0800 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: manet@ietf.org References: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> In-Reply-To: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8670afc80299bd6001dd5c5bdd4b6abaf0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Cc: Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 23:09:20 -0000 Hello folks, draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts directories. The only problem is that it's got the wrong name, namely "draft-ietf-manet-dymo-26.txt" This is because it's now a week past the submission deadline for ...-00.txt initial drafts, and the submission tool would not allow me to upload it with it's intended new name. This naming problem will be rectified at the earliest opportunity. Regards, Charlie P. On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. > > Title : Dynamic MANET On-demand (AODVv2) Routing > Author(s) : Charles E. Perkins > Stan Ratliff > John Dowdell > Filename : draft-ietf-manet-dymo-26.txt > Pages : 60 > Date : 2013-02-25 > > Abstract: > The revised Ad Hoc On-demand Distance Vector (AODVv2) routing > protocol is intended for use by mobile routers in wireless, multihop > networks. AODVv2 determines unicast routes among AODVv2 routers > within the network in an on-demand fashion, offering on-demand > convergence in dynamic topologies. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dymo > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-dymo-26 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dymo-26 > > > 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 > -- Regards, Charlie P. From teco@inf-net.nl Mon Feb 25 22:42:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B421021F913E for ; Mon, 25 Feb 2013 22:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deR-dSjWKyIj for ; Mon, 25 Feb 2013 22:42:24 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C378621F90E0 for ; Mon, 25 Feb 2013 22:42:23 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id j4so1694810bkw.31 for ; Mon, 25 Feb 2013 22:42:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=6rHLMGzcIBPQ1h39Z0NZ7XEzXW2Wt4qyGkm8pNAivRY=; b=UE3C6V5ywC50jVnAcrOmqFXNoaUvI4xClLohiibC3hnSbV6aaGpr2MhOv6d3SPZRlT i44PDF3umAve3w9E7qQ6kPRXHAPZ9M5E/WHbRcbaH85nY7SIpeDtgtsKedeNuwp+iRwB Ub0XK6ubzYV+LF1ScVF3ylCqu0p2wr24SzOxLoYocfPmMbq7PvOfaWN2iHZ9ZhloJ08c JOL4nazzrqMLN7W65IWBpqNGqVfVdmdo3rdDD+IPAhOuJyaCw7z4cP2vUyK2XAHGrWOY HIFveuFyNCwHh9nE+V6jFbyq0eCzozM+1Kq/Jm/Po89bgMbdaEAghUbSF4vXExdU7X/+ rXfg== X-Received: by 10.204.132.81 with SMTP id a17mr5942692bkt.133.1361860942838; Mon, 25 Feb 2013 22:42:22 -0800 (PST) Received: from [10.87.54.105] ([88.128.80.4]) by mx.google.com with ESMTPS id b21sm4267501bkw.12.2013.02.25.22.42.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 22:42:22 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Teco Boot In-Reply-To: Date: Tue, 26 Feb 2013 07:41:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmdzwF0O61b6hojM/08EGTGYu8c6vPWfmzd19pO13HiGOIehaFhHMkiNf7qqeTtM0zGeteP Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 06:42:24 -0000 Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg het = volgende geschreven: > AB, >=20 > again, sequence numbers are not used by NHDP, therefore not a threat = to NHDP. If another protocols uses that information, it may be a threat = to that protocol, and may be documented in a security threats analysis = for that protocol.=20 >=20 > It seems you are the only one advocating for changing the draft on = this aspect. I will wait if someone else also asks for changes on this = matter before changing it. Don't judge too early. I'm with AB that threats on optional parts of a = standard should be enlightened. Teco From teco@inf-net.nl Mon Feb 25 22:51:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1052121F9651 for ; Mon, 25 Feb 2013 22:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6ubmZ5s9a6u for ; Mon, 25 Feb 2013 22:51:43 -0800 (PST) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by ietfa.amsl.com (Postfix) with ESMTP id A183221F9654 for ; Mon, 25 Feb 2013 22:51:38 -0800 (PST) Received: by mail-bk0-f50.google.com with SMTP id jg9so1646179bkc.23 for ; Mon, 25 Feb 2013 22:51:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=jin7Ywo6hQ100VCYRP9LRDO2cynwi5+qjiUrtEMRXkc=; b=mLkrgjv+8HG+EjMXaGKE26cEao1VB8lOTBkwUAG5jQVMpaqK0gcmxZmgMfUM2lc80G U0yIa0uG+eF4Lv3CGg22UFb/Yz6LKkVivgT5+JRTOI2DD3ODjRY/LWyVF9T7pE/+THAO wJ15QnextWGmcRipMektfAYzrQfiAmNpAf4ImzPH0OZLO8p3sQxz6Ss+TzKnH48yuTnL RXL2TKQbkp9eTlAgarB12YIMR/kZKXxazJUOFkwkCPh+D3DLc7EanJnLENo/9Zoh6ZaS 8j5OuFTgBkUYenP8f7EHpIWjspKTur0BmMwvPyGt8S5AgVbikfZBW5Z7KYd40gL92ejX WSaA== X-Received: by 10.204.4.84 with SMTP id 20mr5965144bkq.56.1361861497686; Mon, 25 Feb 2013 22:51:37 -0800 (PST) Received: from [10.87.54.105] ([88.128.80.4]) by mx.google.com with ESMTPS id gy3sm4272541bkc.16.2013.02.25.22.51.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 22:51:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Teco Boot In-Reply-To: Date: Tue, 26 Feb 2013 07:51:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <785A4304-747E-47D8-8276-D79D312DD6C4@inf-net.nl> References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fk ie.fraunhofer.de> To: Henning Rogge , "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmwL58C/FYTo2gfjcARVuL+XezKPGzSTDNyjqJcDq6JnbF4cQjL0mJ2MlZ5OOIi9P8/NDA5 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 06:51:45 -0000 Op 25 feb. 2013, om 17:28 heeft Henning Rogge = het volgende geschreven: > On Mon, Feb 25, 2013 at 5:21 PM, Dearlove, Christopher (UK) > wrote: >> Both errata I submitted today were originally pointed out by other = people, I forget who (maybe even Henning for this one). Originally I = left it to the discovers to submit and claim the (fairly small) credit, = but they didn't, and it drifted, and then I finally got around to them = today. >=20 > Might be... but the important thing is that we got it fixed. Just for the record: I commented on per link packet seq numbers on the = mike, as comment on mib link quality reporting. Teco >=20 >> This in fact just matches behaviour in RFC 3626. >=20 > Yes. >=20 >> As for how to protect it, should you care, the answer would be in a = security mechanism for RFC 5444. It's fairly obvious reading RFC 6622 = (or bis) what that would be (ICV and TIMESTAMP packet TLVs). >=20 > Yes. It is packet level data, it should be protected by packet-level = security. >=20 > Henning Rogge >=20 > --=20 > We began as wanderers, and we are wanderers still. We have lingured > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Mon Feb 25 23:35:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19F921F966A for ; Mon, 25 Feb 2013 23:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNXIiQfQhBRV for ; Mon, 25 Feb 2013 23:35:37 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id CFFE321F9669 for ; Mon, 25 Feb 2013 23:35:36 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UAF4a-00064q-6j for manet@ietf.org; Tue, 26 Feb 2013 08:35:36 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UAF4a-00039d-45 for manet@ietf.org; Tue, 26 Feb 2013 08:35:36 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 26 Feb 2013 08:35:35 +0100 Message-ID: <512C65BB.8000305@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 08:35:23 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070501030905000606000906" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16744/Tue Feb 26 00:43:55 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 63d11b563531d75ada9d42d73b6da78e Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 07:35:38 -0000 --------------ms070501030905000606000906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 02/26/2013 07:41 AM, Teco Boot wrote: > > Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg > het volgende geschreven: > >> AB, >> >> again, sequence numbers are not used by NHDP, therefore not a >> threat to NHDP. If another protocols uses that information, it may >> be a threat to that protocol, and may be documented in a security >> threats analysis for that protocol. >> >> It seems you are the only one advocating for changing the draft on >> this aspect. I will wait if someone else also asks for changes on >> this matter before changing it. > Don't judge too early. I'm with AB that threats on optional parts of > a standard should be enlightened. In my opinion the interesting question is where to put generic RFC5444 attacks. Attacks on packet sequence numbers is one of them, attacks on message sequence numbers is another one. But we also have attacks on hopcount and hoplimit fields of messages, both which can NOT be solved by signing messages (except for messages like NHDP Hellos that are not forwarded at all). Hopcount attacks look very interesting when a protocol use Multi-Value Time TLVs as described in RFC 5497. The classic attack would be to fake the originator field of an RFC5444 message to impersonate a different node. I have a problem with putting sequence number based attacks in a NHDP=20 attached document because NHDP doesn't specify anything in relation to=20 sequence numbers, not even as an optional part. What it does is mentioning a few possibilities what could be useful for=20 hysteresis calculation without specifying a protocol or algorithm. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms070501030905000606000906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMjYwNzM1MzNaMCMGCSqGSIb3DQEJBDEWBBQty0BFufOga6wdyOHjh4tZKhKbsTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAJvtTDvR2/5rWacuIJ/EG11Oqe9DtsQXi4oajbpeTfKFE aPv/mNY+JNa6qrSj3A4Sdc5w8WaRuWxuLr/Ridefn2QllcTVVIBgf1KUkWzvw5rNXeiCO0ui pb+ByTF2SC7P7Mhf78TWu1IAOo0pR7M+Cwf+ZTIqmZAoSUzYQ2M1bb0sUlX2vycVFa8y7ZkZ vL+ac/5WDhGWKm8MEWW8MXdpFefEH8bpybWABW89KWteDkUDgSUu8a8y/GtjEOQBD6B/kNZP BGhJhNtBWq9wN6sQ5G5ro23dD1qlNQDu+FmcBwwjE9vtb+qzR/zhX592+7aTyLVY52KqM0NR LVYI7uhESwAAAAAAAA== --------------ms070501030905000606000906-- From ulrich@herberg.name Mon Feb 25 23:37:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C448821F968B for ; Mon, 25 Feb 2013 23:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.892 X-Spam-Level: X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JEpWRJpByf1 for ; Mon, 25 Feb 2013 23:37:27 -0800 (PST) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id DBFA021F9683 for ; Mon, 25 Feb 2013 23:37:26 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id cz10so3022200veb.7 for ; Mon, 25 Feb 2013 23:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TdvDc0VJywis+8476hKDMNrW9t+JHZebqvIwSlAQM+A=; b=jgj1JQZiZDj6rDs4iIMT/Ae+BPNghZFoVYVG6JNwK356nKhknZMYjOqrslxht69HP1 xh3bpv7YF7SvaISIbCa84JhDAt9ouI1suZ0PZv0DjutnlVsMMu1owjuvO4Loix9a1mmx 5lX4P249RFhpHLMrDdSTb9te/00zXAs8RhGrk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=TdvDc0VJywis+8476hKDMNrW9t+JHZebqvIwSlAQM+A=; b=CZjem0EWS3aYfy5X1J6OkWEdQBMzkPZPhNoCcpPuENd0jpwywarZpIvbulRmCY0Mpf CM1dF0grrNPYNmRkrAUBl9d0Bcwd2Mgqlz9HK1HtnC1800Z0/kY2sUO3WYI4RvUxoxT9 rho8UtGgVUR74MteoTkDHbCz1cdIqmP8DhQygrUvEdi8+AVEgFtPmK/pKwsf7VIaUPR5 06VglwvyJIQp2xbYZ8BhMdfF3gV6MWWpo+S24IUuMMsxyaRrqAVg0xLbFd79ud2RlG/D erNIapg2fXeZ7Ga0oKZlVspLb9nbfjYo8JNFtYDXS9puqYaP14XPsTwu2bS9kIWf4rSB Ygpw== MIME-Version: 1.0 X-Received: by 10.52.100.5 with SMTP id eu5mr9686260vdb.66.1361864246236; Mon, 25 Feb 2013 23:37:26 -0800 (PST) Received: by 10.220.107.7 with HTTP; Mon, 25 Feb 2013 23:37:25 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Mon, 25 Feb 2013 23:37:25 -0800 Message-ID: From: Ulrich Herberg To: Teco Boot Content-Type: multipart/alternative; boundary=20cf3071cf9aa164af04d69bbafd X-Gm-Message-State: ALoCoQnA+S/vg/4p0sCXvwXrqBHZCDsDz5LiiHBtuJjN67zPqbbPOITZA//oambycYxXZoW3YwhQ Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 07:37:27 -0000 --20cf3071cf9aa164af04d69bbafd Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 25, 2013 at 10:41 PM, Teco Boot wrote: > > Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg het > volgende geschreven: > > > AB, > > > > again, sequence numbers are not used by NHDP, therefore not a threat to > NHDP. If another protocols uses that information, it may be a threat to > that protocol, and may be documented in a security threats analysis for > that protocol. > > > > It seems you are the only one advocating for changing the draft on this > aspect. I will wait if someone else also asks for changes on this matter > before changing it. > > Don't judge too early. I'm with AB that threats on optional parts of a > standard should be enlightened. > But it is *not* an optional part of NHDP (nor is it mandatory). It is simply named as example what implementers may do, but it is outside of the normative part. I cannot guess what people can implement in addition to the normative part, since there may be infinite possibilities. Please tell me how I should write security threats for these potentially infinite, non-normative, things that people can implement. I can only repeat it again: NHDP does *not* use sequence numbers, neither packet nor message sequence numbers. Ulrich --20cf3071cf9aa164af04d69bbafd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 25, 2013 at 10:41 PM, Teco B= oot <teco@inf-net.nl> wrote:

Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg <ulrich@herberg.name> het volgende geschreven:

> AB,
>
> again, sequence numbers are not used by NHDP, therefore not a threat t= o NHDP. If another protocols uses that information, it may be a threat to t= hat protocol, and may be documented in a security threats analysis for that= protocol.
>
> It seems you are the only one advocating for changing the draft on thi= s aspect. I will wait if someone else also asks for changes on this matter = before changing it.
=A0
Don't judge too early. I'm with AB that threats on optional p= arts of a standard should be enlightened.

But it is *not* an opti= onal part of NHDP (nor is it mandatory). It is simply named as example what= implementers may do, but it is outside of the normative part. I cannot gue= ss what people can implement in addition to the normative part, since there= may be infinite possibilities. Please tell me how I should write security = threats for these potentially infinite, non-normative, things that people c= an implement.

I can only repeat it again: NHDP does *not* use sequence numbers, neith= er packet nor message sequence numbers.

Ulrich
--20cf3071cf9aa164af04d69bbafd-- From ulrich@herberg.name Tue Feb 26 00:14:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F16A21F8A11 for ; Tue, 26 Feb 2013 00:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiMHn+SxAQfD for ; Tue, 26 Feb 2013 00:14:48 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5156921F89FB for ; Tue, 26 Feb 2013 00:14:48 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id fo13so2343715vcb.11 for ; Tue, 26 Feb 2013 00:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=HzZpAWi0QSnOjnKV7tAYjtlozlQED68VVjRKBH5rwFs=; b=quBICSEliI1KIIEzxX1aZ6/WUwRmb89bjP3oyU6gFAwuZr6HXKFzv6Du73uBpqIzlx Sf9jDkG00ikUnWbyDs8UrAfeYZZFalsEsc63reqr1ojcadUPc200gPM2UBJl/QzyRcEO 0U8ROlYn/yJT8BuQMWZzxmDQUjwuHG1mGSqkE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=HzZpAWi0QSnOjnKV7tAYjtlozlQED68VVjRKBH5rwFs=; b=OT1ZrhFDJXRllTf2dx0CobyUHB+ILZ1ZlIiW7oDjvY7eYUP2hOQ0P8zK0cXOv1epH1 h2fb2Oub8r5TdOS8K9RC+gAZZ6k+X9knNIbgDgyXe+rNT7cVsebhR+j6RKyMOSDxOdXg gz5z5id74P9752cY6r5oJEOntfMGO641tKjeQ3m3CkgHT3XY5SPAp9i7xET5IWhGDMvn 18ouvxJ9OCz+4j6mTUqe5DaLOvFS7vXAUW0bdWMYuJB0ZAPO5Wc2veNs7wwAeplgerxV fWlgU9X0QJ7QFzOdkWcUpmB9lVzQ7JzEdEUG8zn651/Z5vy0YbLDbEE9BrW4fmPG+1Bz dm7A== MIME-Version: 1.0 X-Received: by 10.58.186.241 with SMTP id fn17mr11442251vec.8.1361866487712; Tue, 26 Feb 2013 00:14:47 -0800 (PST) Received: by 10.220.107.7 with HTTP; Tue, 26 Feb 2013 00:14:47 -0800 (PST) Date: Tue, 26 Feb 2013 00:14:47 -0800 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=047d7b6dcf463b942e04d69c404a X-Gm-Message-State: ALoCoQlXGsIuXHmFwDtdTYUtOV14vvN0/ykwAzZ0ChvPh6odNBHjjpm48+LTcyZZAqXIdLHpQREU Cc: manet-chairs@tools.ietf.org Subject: [manet] Slides please X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 08:14:49 -0000 --047d7b6dcf463b942e04d69c404a Content-Type: text/plain; charset=ISO-8859-1 Hello, if you want to present in the MANET meeting, please send your slides soon to the chairs and myself. Thank you Ulrich --047d7b6dcf463b942e04d69c404a Content-Type: text/html; charset=ISO-8859-1 Hello,

if you want to present in the MANET meeting, please send your slides soon to the chairs and myself.

Thank you
Ulrich
--047d7b6dcf463b942e04d69c404a-- From abdussalambaryun@gmail.com Tue Feb 26 03:10:06 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD5121F8962 for ; Tue, 26 Feb 2013 03:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHDY1p0IG-7u for ; Tue, 26 Feb 2013 03:10:06 -0800 (PST) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 07B9321F888B for ; Tue, 26 Feb 2013 03:10:06 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id fb1so2386064pad.39 for ; Tue, 26 Feb 2013 03:10:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=k3Wwn7IFeUFBZ9O7WadmOdhiuw72X9Cj+Yv7LWSrspc=; b=SI2/Vi+M3F7IdO258KNk96zvDOqbeJnC9AjYGhLn5STaRDVRBdTJpR8C+joDRDazAH tb3re0UUw8DiNuFYg2rmx3voub3tlE1pkki9VeVydkvqK2SV+3z/tL8PFnlh9r7OZQ3e ClfK7sg2HK3YXIprooKGar5P3ODCuH/FO581+TyJNONcZUErJtrEEaHg8eLfzzGlmHdS SGwlhcri9tw7GZGggY7sdtcSZzbm2KPpyGpvUo2JAR/L6MdC0liFfN4oE+ezsAg0Df+V PpERYIJG2K2y6FH40hswyr6vzxMUWEGW6qnDSB9PNZ00fwvUnb3k54L4REkDS+/d7jOm +otA== MIME-Version: 1.0 X-Received: by 10.66.158.2 with SMTP id wq2mr1149875pab.113.1361877005741; Tue, 26 Feb 2013 03:10:05 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 03:10:05 -0800 (PST) In-Reply-To: <512BEF17.70605@computer.org> References: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> <512BEF17.70605@computer.org> Date: Tue, 26 Feb 2013 11:10:05 +0000 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=047d7b86c9f027b49304d69eb3d7 Cc: manet@ietf.org, Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 11:10:06 -0000 --047d7b86c9f027b49304d69eb3d7 Content-Type: text/plain; charset=ISO-8859-1 Hi AODVv2 Editors, So do you mean if I review now the dymo-26 it is the same as aodvv2-00, please advise, AB On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins wrote: > > Hello folks, > > draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts > directories. The only problem is that it's got the wrong name, namely > "draft-ietf-manet-dymo-26.txt" > > This is because it's now a week past the submission deadline for ...-00.txt > initial drafts, and the submission tool would not allow me to upload it > with > it's intended new name. > > This naming problem will be rectified at the earliest opportunity. > > Regards, > Charlie P. > > > > > On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobile Ad-hoc Networks Working Group >> of the IETF. >> >> Title : Dynamic MANET On-demand (AODVv2) Routing >> Author(s) : Charles E. Perkins >> Stan Ratliff >> John Dowdell >> Filename : draft-ietf-manet-dymo-26.txt >> Pages : 60 >> Date : 2013-02-25 >> >> Abstract: >> The revised Ad Hoc On-demand Distance Vector (AODVv2) routing >> protocol is intended for use by mobile routers in wireless, multihop >> networks. AODVv2 determines unicast routes among AODVv2 routers >> within the network in an on-demand fashion, offering on-demand >> convergence in dynamic topologies. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/**doc/draft-ietf-manet-dymo >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/**draft-ietf-manet-dymo-26 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?**url2=draft-ietf-manet-dymo-26 >> >> >> 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 >> >> > > -- > Regards, > Charlie P. > > > ______________________________**_________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/**listinfo/manet > --047d7b86c9f027b49304d69eb3d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi AODVv2 Editors,
=A0
So do you mean if I review = now the dymo-26 it is the same as aodvv2-00,
please advise,
=
=A0
AB

On Mon, Feb 2= 5, 2013 at 11:09 PM, Charles E. Perkins <charliep@computer.org>= wrote:

Hello folks,

draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts directories. =A0The only problem is that it's got the wrong name, namel= y
"draft-ietf-manet-dymo-26.txt"

This is because it's now a week past the submission deadline for ...-00= .txt
initial drafts, and the submission tool would not allow me to upload it wit= h
it's intended new name.

This naming problem will be rectified at the earliest opportunity.

Regards,
Charlie P.




On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0 This draft is a work item of the Mobile Ad-hoc Networks Working Group o= f the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Dynamic MANET On-demand (AODVv2= ) Routing
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Charles E. Perkins
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stan Ratliff
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0John Dowdell
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-manet-dymo-26.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 60
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-25

Abstract:
=A0 =A0 The revised Ad Hoc On-demand Distance Vector (AODVv2) routing
=A0 =A0 protocol is intended for use by mobile routers in wireless, multiho= p
=A0 =A0 networks. =A0AODVv2 determines unicast routes among AODVv2 routers<= br> =A0 =A0 within the network in an on-demand fashion, offering on-demand
=A0 =A0 convergence in dynamic topologies.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-dymo-26

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-d= ymo-26


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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



--
Regards,
Charlie P.


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

--047d7b86c9f027b49304d69eb3d7-- From abdussalambaryun@gmail.com Tue Feb 26 03:22:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E4C21F8A1D for ; Tue, 26 Feb 2013 03:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w771KvL2QcF for ; Tue, 26 Feb 2013 03:21:59 -0800 (PST) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by ietfa.amsl.com (Postfix) with ESMTP id B686821F8A53 for ; Tue, 26 Feb 2013 03:21:59 -0800 (PST) Received: by mail-da0-f46.google.com with SMTP id z8so753041dad.33 for ; Tue, 26 Feb 2013 03:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8AG99xRzhTH1izLJ8H1oivT1HI6vH/6BDKzWA/unazE=; b=YIoeJNSiRSitli8hRAkLqmvxtxURSmnojZhs0MdbwY9vQYJ/b/lzdAdhJ92cABkHKz 1z+sJrolbsG1QZbnfs2U3CgWEqDu1HcgAd01vTiXkQkuPXKYOL9x5i66SKtvMjAiOvJF StQfF57JP+ZfBHcmv05tvdDLmCg4blqDnnu02R00gqM38px7M5AZtry281g7FD5q9y3N Uzc24zLLd5bMiRohmueHmw/WjzrCOu4nSVVU0vSwDVWOZChl8NxSKlQlToa+rtrSgbcX E5BoQ/MsiJ5Sob1DLNAojMmN1S1hcaQa2LP5N4lscYaEAt0jp7AGmZqP5S8RfGD6DTbE p4sQ== MIME-Version: 1.0 X-Received: by 10.68.138.170 with SMTP id qr10mr22808393pbb.190.1361877719422; Tue, 26 Feb 2013 03:21:59 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 03:21:59 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Tue, 26 Feb 2013 11:21:59 +0000 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=047d7b15aa2fb19f8404d69eddba Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 11:22:00 -0000 --047d7b15aa2fb19f8404d69eddba Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 26, 2013 at 7:37 AM, Ulrich Herberg wrote: > > > But it is *not* an optional part of NHDP (nor is it mandatory). It is > simply named as example what implementers may do, but it is outside of the > normative part. I cannot guess what people can implement in addition to the > normative part, since there may be infinite possibilities. Please tell me > how I should write security threats for these potentially infinite, > non-normative, things that people can implement. > There were comments for the draft to be updated, so please just do what we think needs to be added we don't want infinite, no one said that as all unmentioned options, I think it is editor assumption, > > I can only repeat it again: NHDP does *not* use sequence numbers, neither > packet nor message sequence numbers. > That is your opinion which I disagree, and disagree that the editors removed the section of sequence number without consensus of WG. AB --047d7b15aa2fb19f8404d69eddba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 26, 2013 at 7:37 AM, Ulrich Herberg = <ulrich@herberg.name> wrote:

But it is *not* an optional part of NHD= P (nor is it mandatory). It is simply named as example what implementers ma= y do, but it is outside of the normative part. I cannot guess what people c= an implement in addition to the normative part, since there may be infinite= possibilities. Please tell me how I should write security threats for thes= e potentially infinite, non-normative, things that people can implement.
=A0
There were comments for the dra= ft to be updated, so please=A0just do what we think needs to be added=A0we = don't want infinite, no=A0one said that=A0as all unmentioned options,= =A0I think it is editor assumption,
=A0

I can only repeat it again: NHDP does *not* use sequence numbers, neith= er packet nor message sequence numbers.
= =A0
That is your opinion which I disagree, and disagree that the = editors removed the section of sequence number without consensus of WG.
=A0
AB
--047d7b15aa2fb19f8404d69eddba-- From henning.rogge@fkie.fraunhofer.de Tue Feb 26 03:38:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2DE21F89DA for ; Tue, 26 Feb 2013 03:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.322 X-Spam-Level: X-Spam-Status: No, score=-1.322 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGBvhr-5sqoq for ; Tue, 26 Feb 2013 03:38:42 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD3221F8920 for ; Tue, 26 Feb 2013 03:38:41 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UAIro-0007UR-BG for manet@ietf.org; Tue, 26 Feb 2013 12:38:40 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UAIro-0004gg-8d for manet@ietf.org; Tue, 26 Feb 2013 12:38:40 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 26 Feb 2013 12:38:40 +0100 Message-ID: <512C9EBB.3060902@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 12:38:35 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040903010807000003040503" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16744/Tue Feb 26 00:43:55 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: b17092e937cef22d8bf42b2c04946c57 Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 11:38:43 -0000 --------------ms040903010807000003040503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: > I can only repeat it again: NHDP does *not* use sequence numbers, > neither packet nor message sequence numbers. > > That is your opinion which I disagree, and disagree that the editors > removed the section of sequence number without consensus of WG. You know that the old section was plain WRONG, yes? (I suggest reading section 4.5 of nhdp-threats-00) Because the attack it described cannot happen to NHDP. If you want to get the "sequence number attack" paragraph back, maybe=20 you should write a new one... one that applies to NHDP. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms040903010807000003040503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMjYxMTM4MzhaMCMGCSqGSIb3DQEJBDEWBBT2ZJWYI2dN4djuIuHJG8Bc1hAsIjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAj7Kj8JniJjZdtfv7Cvkvkbgq1NGXnvNciOUfeu470d4M ay7x++Akh/dm4E82os/ApGgj4B24yhJCQ2luDPQkstAnSH2LiQ8VwYVFBom12ObL1tPwcj+i Gm/hz0YBpjcA071vLrMwAuY+llmruTkcQvCPTAW6clVBo5kRxbKr1MjW1XfbAbOvKbHAxap4 mKJB3n2W4q9dtFguC7C4mkpPzcIANr423NI7jF/7Miz0qvCvSjEcQf5SRgrtSRQ5REda70oB 7ELLWBR6pO3QhQ3U4G/n8uqje0x1AHYk4IYugT7ZaaZ4MwXe39oH7mEClJHh72OkDW21pGOS HXHYGRx4QQAAAAAAAA== --------------ms040903010807000003040503-- From ulrich@herberg.name Tue Feb 26 03:45:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9035D21F8A25 for ; Tue, 26 Feb 2013 03:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCACutuPM-dw for ; Tue, 26 Feb 2013 03:45:55 -0800 (PST) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id ABE8B21F8A48 for ; Tue, 26 Feb 2013 03:45:52 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id oz10so3270357veb.18 for ; Tue, 26 Feb 2013 03:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=XsztOgpXBZsjmmc1oox0I1M6kV+esmmm9VeQ53Lot/A=; b=145onV60FiwGBt6koJissLnAxZvWLtr1hUG2DvQ0HmdLrDUVfnJ292SdUSohIE8s+M 2o3S8QBd9yEStCXfoIJFYs8MQxJViO9b5NwJxuB+ZTfOcGvYhmxI0ZQe4nZzQQv/ujwQ fPO85JnFrOVeyQzOoZ5KXJLtXMrmVMCliGoEE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=XsztOgpXBZsjmmc1oox0I1M6kV+esmmm9VeQ53Lot/A=; b=bKvFvwRjg4DBVdpfWxIoQztLIOPGaSNPeD/lMk+K0A8EkiFJD2nupaIuGemVQ2+7KF AgJisM0NA49qaGTHzN9HLXOO/6CGtn0G8+ErylyxreEzD57cDhMrqu0cCr9Ych2cB03V isaQmzzFw8NmscZhvwXZmGCT2fYkWkuwLqlss8xFFW54cN43A3CP5Ygvn7mio1rNIXhk AR/dun0YGUryVoPpEoc5sI2vBr9F37VCMQr5cfqaQXV4m2Ji6eGWEU1OvDrqJPakg3G4 ZK9g4X/l2aQok0q8V6dvSQ99n4XlwnUakzOCw5vHOKFSs9Ii93Fm/YoIEGT68uLZTJOr gHqA== X-Received: by 10.52.32.230 with SMTP id m6mr9929377vdi.83.1361879152020; Tue, 26 Feb 2013 03:45:52 -0800 (PST) References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> <512C9EBB.3060902@fkie.fraunhofer.de> From: Ulrich Herberg Mime-Version: 1.0 (1.0) In-Reply-To: <512C9EBB.3060902@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 20:45:20 +0900 Message-ID: <3914261153023490535@unknownmsgid> To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk/KWRiIWpEb956EpxDBQuns1yPsTuroGkEEBLWaC5o86nxvBs9zGcTU+VykOajPvYBB8oS Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 11:45:56 -0000 Exactly. We confused it with OLSRv2. The old section is 100% wrong. Ulrich Sent from my iPhone On Feb 26, 2013, at 8:38 PM, Henning Rogge wrote: > On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: >> I can only repeat it again: NHDP does *not* use sequence numbers, >> neither packet nor message sequence numbers. >> >> That is your opinion which I disagree, and disagree that the editors >> removed the section of sequence number without consensus of WG. > > You know that the old section was plain WRONG, yes? > > (I suggest reading section 4.5 of nhdp-threats-00) > > Because the attack it described cannot happen to NHDP. > > If you want to get the "sequence number attack" paragraph back, maybe you= should write a new one... one that applies to NHDP. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Tue Feb 26 04:08:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93B921F8901 for ; Tue, 26 Feb 2013 04:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.322 X-Spam-Level: X-Spam-Status: No, score=-1.322 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BD0RguHlAmPN for ; Tue, 26 Feb 2013 04:08:17 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A05EC21F88FB for ; Tue, 26 Feb 2013 04:08:16 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UAJKR-0001D3-Lx; Tue, 26 Feb 2013 13:08:15 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UAJKR-0005t5-JF; Tue, 26 Feb 2013 13:08:15 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 26 Feb 2013 13:08:15 +0100 Message-ID: <512CA5AD.4030800@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 13:08:13 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "manet@ietf.org" References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080302020008000905090906" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16744/Tue Feb 26 00:43:55 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c51b770f3e2e0970392bce6b101b1534 Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:08:18 -0000 --------------ms080302020008000905090906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, so do we have an agreement that the old "sequence number attack" section = of nhdp-threats-00 is wrong and must be removed because it describes=20 something that does not apply to NHDP? If we (as a working group) decide we want a "sequence number attack"=20 section in nhdp-threats, someone needs to write up a corresponding=20 section and we have to see if it gets consensus in the group. Henning Rogge On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: > your right thanks :) > AB > > On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge > > wrote: > > On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: > > I can only repeat it again: NHDP does *not* use sequence > numbers, > neither packet nor message sequence numbers. > > That is your opinion which I disagree, and disagree that the ed= itors > removed the section of sequence number without consensus of WG.= > > > You know that the old section was plain WRONG, yes? > > (I suggest reading section 4.5 of nhdp-threats-00) > > Because the attack it described cannot happen to NHDP. > > If you want to get the "sequence number attack" paragraph back, > maybe you should write a new one... one that applies to NHDP. > > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961 , Fax +49 22= 8 > 9435 685 > mailto:henning.rogge@fkie.__fraunhofer.de > http://www.fkie.fraunhofe= r.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms080302020008000905090906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMjYxMjA4MTNaMCMGCSqGSIb3DQEJBDEWBBSqsVLRmWy33ZfSeHShBfWZArWCuDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAFpxISG0s5YZm4BRRkDIAyBdcd9zUYkBf5ChkhzKUiOrk gv0DU5TrgHVog7sY4DBc85/uwCr5IRtStpUHBKVrCZYYZL705tSkNRJcK/Yx0pFIVyXPyjT0 zw38gLR/jaOf//UT/TOdYM2LJyZvL0lYYfoQFb8Wi1kCiiCmdKEfJTDQL4NF+iNkD+LC7j+N ZvxT3hrHvQU6pFFRcZ0pOUdC34Xjn8TMFXHF3C+igayPcWk0/3KNRGjf5ANYvZbP2HhKB2+l DaTa3yuX3vdVZvvV1+kYZoz2piw+aAFzw2h1XfOL+UPaUNs3qLowXRliYR3wqoTL2LoLRHC6 oC8Jtcq0jQAAAAAAAA== --------------ms080302020008000905090906-- From drdanhe@gmail.com Tue Feb 26 04:13:18 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EB321F8464 for ; Tue, 26 Feb 2013 04:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SezqO7ezBOsD for ; Tue, 26 Feb 2013 04:13:17 -0800 (PST) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id EA33E21F85AD for ; Tue, 26 Feb 2013 04:13:16 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id u20so3336467iag.5 for ; Tue, 26 Feb 2013 04:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=O7f7CrV4FQdsu0r0qkDIQ0Uze9bl0qveEcfnaait7ko=; b=yPQ8zlAQOvRSsEa2kkI8bcz6A7E9Gb9GNw/Lvo3P/zFzqGCrOrvvUp4K4RRfnaZwsU A0R11qNn8qPZtfpAYPXzyjVe6PxCqVeN+pkl1C7sY2/lb6MHn4T8f2lvlDpsXRIrHY2m IWoB4CsrHGtrNTSNbTcD0he+xBLCHNPjmE6qYNX1PyYt2vnq1Vfn91cDdXEugw9Qqiji bw3eWKEG20dGn0iT8laoBVAQZlBwiSGDFvSl/AZ7EyWLUNkYczaINho2hKKUaVfgsP2z ApVN5odt9x8WiqkopFHR4LnhMarbxHAE/1HUeu85zKNbguouqEgKOTyWCKMj6TWOjzbs rttQ== MIME-Version: 1.0 X-Received: by 10.42.215.196 with SMTP id hf4mr6047047icb.23.1361880794818; Tue, 26 Feb 2013 04:13:14 -0800 (PST) Received: by 10.50.85.6 with HTTP; Tue, 26 Feb 2013 04:13:14 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Tue, 26 Feb 2013 12:13:14 +0000 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=20cf301d3dc6006ef304d69f9572 Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:13:18 -0000 --20cf301d3dc6006ef304d69f9572 Content-Type: text/plain; charset=ISO-8859-1 I don't see why we need sequence number. if you disagree, could you please explain why? I couldn't image which particular threat will be? > There were comments for the draft to be updated, so please just do what we > think needs to be added we don't want infinite, no one said that as all > unmentioned options, I think it is editor assumption, > > >> >> I can only repeat it again: NHDP does *not* use sequence numbers, neither >> packet nor message sequence numbers. >> > > That is your opinion which I disagree, and disagree that the editors > removed the section of sequence number without consensus of WG. > > > AB > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf301d3dc6006ef304d69f9572 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't see why we need sequence number. if you disagree, could you ple= ase
explain why? I couldn't image which particular threat will be? <= br>

=A0
There= were comments for the draft to be updated, so please=A0just do what we thi= nk needs to be added=A0we don't want infinite, no=A0one said that=A0as = all unmentioned options,=A0I think it is editor assumption,
=A0

I can only repeat it again: NHDP does *not* use sequence numbers, neith= er packet nor message sequence numbers.
= =A0
That is your opinion which I disagree, and disagree tha= t the editors removed the section of sequence number without consensus of W= G.
=A0
=A0
AB

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


--20cf301d3dc6006ef304d69f9572-- From abdussalambaryun@gmail.com Tue Feb 26 04:18:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A703D21F86C1 for ; Tue, 26 Feb 2013 04:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2PyUy53EcrQ for ; Tue, 26 Feb 2013 04:18:12 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id C809621F86C0 for ; Tue, 26 Feb 2013 04:18:12 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id t11so1049442daj.8 for ; Tue, 26 Feb 2013 04:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3IxqQ+GNQqfOJFnux9k5V1gl3XwuxC2SddpLYIlVNGI=; b=DhUenosSsAvSDaKooK3iQciPZKoqVoAQJNdal7TtCTUHKmj932SSa/gvTJr8hBxi9q Wa3K5PdfHgozH0sheYcxuYSHZ0LM8kcb52K+m3F9Jj+bj/w9L4dPHoDlhWKweebzKUxc +VeWkZPo5xj4XAqu9a5o5Hm6WT57EjIq2C7hjH/kapkO7yc3r/FO74LVJiGr8B737BoP l7pWXos3i30QsBycWE/DAh2Tzr+5bQ06oqbcqRO//axIGYdh4posgzg/YDGz+dxJDfiE UBLmZ5WlfJAbJxRSH0nr70bCLfj43P40lF0fv0FvupZOOz5Q2pTIdFd5V7HfyJxdnKML I5RA== MIME-Version: 1.0 X-Received: by 10.66.158.2 with SMTP id wq2mr1409673pab.113.1361881092466; Tue, 26 Feb 2013 04:18:12 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 04:18:12 -0800 (PST) In-Reply-To: <512CA5AD.4030800@fkie.fraunhofer.de> References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> <512CA5AD.4030800@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 12:18:12 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b86c9f0be3f2c04d69fa6b4 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:18:13 -0000 --047d7b86c9f0be3f2c04d69fa6b4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes the content of the section may be removed if the editors made mistake or confused with other protocol, but the should not remove the section title I think, it will change the structure of the draft, AB On Tue, Feb 26, 2013 at 12:08 PM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > Hi, > > so do we have an agreement that the old "sequence number attack" section > of nhdp-threats-00 is wrong and must be removed because it describes > something that does not apply to NHDP? > > If we (as a working group) decide we want a "sequence number attack" > section in nhdp-threats, someone needs to write up a corresponding sectio= n > and we have to see if it gets consensus in the group. > > Henning Rogge > > > On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: > >> your right thanks :) >> AB >> >> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge >> >> >> >> wrote: >> >> On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: >> >> I can only repeat it again: NHDP does *not* use sequence >> numbers, >> neither packet nor message sequence numbers. >> >> That is your opinion which I disagree, and disagree that the >> editors >> removed the section of sequence number without consensus of WG. >> >> >> You know that the old section was plain WRONG, yes? >> >> (I suggest reading section 4.5 of nhdp-threats-00) >> >> Because the attack it described cannot happen to NHDP. >> >> If you want to get the "sequence number attack" paragraph back, >> maybe you should write a new one... one that applies to NHDP. >> >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961 , Fax +49 228 >> 9435 685 >> mailto:henning.rogge@fkie.__fr**aunhofer.de >> >> > >> http://www.fkie.fraunhofer.de >> >> >> ______________________________**_________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/**listinfo/manet >> >> >> > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > > --047d7b86c9f0be3f2c04d69fa6b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes the content of the section may be removed if the editors made mist= ake or confused with other protocol, but the should not remove the section = title I think, it will change the structure of the draft,
=A0
AB

On Tue, Feb 26, 2013 at 12:= 08 PM, Henning Rogge <henning.rogge@fkie.fraunhofer.de&= gt; wrote:
Hi,

so do we have an agreement that the old "sequence number attack" = section of nhdp-threats-00 is wrong and must be removed because it describe= s something that does not apply to NHDP?

If we (as a working group) decide we want a "sequence number attack&qu= ot; section in nhdp-threats, someone needs to write up a corresponding sect= ion and we have to see if it gets consensus in the group.

Henning Rogge


On 02/26/2013 12:41 PM, Abdussalam Baryun wrote:
your right thanks :)
AB

On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge
<h= enning.rogge@fkie.fraunhofer.de
<mailto:henning.rogge@fkie.fraunhofer.de>> wrote:

=A0 =A0 On 02/26/2013 12:21 PM, Abdussalam Baryun wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0I can only repeat it again: NHDP does *not* use = sequence
=A0 =A0 =A0 =A0 numbers,
=A0 =A0 =A0 =A0 =A0 =A0 =A0neither packet nor message sequence numbers.

=A0 =A0 =A0 =A0 That is your opinion which I disagree, and disagree that th= e editors
=A0 =A0 =A0 =A0 removed the section of sequence number without consensus of= WG.


=A0 =A0 You know that the old section was plain WRONG, yes?

=A0 =A0 (I suggest reading section 4.5 of nhdp-threats-00)

=A0 =A0 Because the attack it described cannot happen to NHDP.

=A0 =A0 If you want to get the "sequence number attack" paragraph= back,
=A0 =A0 maybe you should write a new one... one that applies to NHDP.


=A0 =A0 Henning Rogge

=A0 =A0 --
=A0 =A0 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
=A0 =A0 Kommunikation, Informationsverarbeitung und Ergonomie FKIE
=A0 =A0 Kommunikationssysteme (KOM)
=A0 =A0 Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
=A0 =A0 Telefon +49 228 9435-961 <tel:%2B49%20228%209435-961&g= t;, =A0 Fax +49 228
=A0 =A0 9435 685 <tel:%2B49%20228%209435%20685>
=A0 =A0 mailto:hen= ning.rogge@fkie.__fr= aunhofer.de

=A0 =A0 <mailto:henning.rogge@fkie.fraunhofer.de> http://www.fkie.fraunhofer.d= e


=A0 =A0 _______________________________________________
=A0 =A0 manet mailing list
=A0 =A0 manet@ietf.org<= /a> <mailto:manet@ie= tf.org>
=A0 =A0 https://www.ietf.org/mailman/listinfo/manet




--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


--047d7b86c9f0be3f2c04d69fa6b4-- From thomas@thomasclausen.org Tue Feb 26 04:19:02 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B4E21F86C5 for ; Tue, 26 Feb 2013 04:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLtTlpf9Hl3n for ; Tue, 26 Feb 2013 04:19:01 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id B0D5621F86C2 for ; Tue, 26 Feb 2013 04:19:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A2F8E1BC6644; Tue, 26 Feb 2013 04:19:01 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E86981BC6643; Tue, 26 Feb 2013 04:19:00 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Clausen In-Reply-To: <512CA5AD.4030800@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 13:18:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> <512CA5A D.4030800@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:19:02 -0000 On Feb 26, 2013, at 1:08 PM, Henning Rogge = wrote: > Hi, >=20 > so do we have an agreement that the old "sequence number attack" = section of nhdp-threats-00 is wrong and must be removed because it = describes something that does not apply to NHDP? >=20 > If we (as a working group) decide we want a "sequence number attack" = section in nhdp-threats, someone needs to write up a corresponding = section and we have to see if it gets consensus in the group. >=20 I believe that if there is a sequence number attack on NHDP, then it = should be written down. I also believe that I've not seen anything indicating that such an = attack exists. That's what you're saying, isn't it? > Henning Rogge >=20 > On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: >> your right thanks :) >> AB >>=20 >> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge >> > > wrote: >>=20 >> On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: >>=20 >> I can only repeat it again: NHDP does *not* use sequence >> numbers, >> neither packet nor message sequence numbers. >>=20 >> That is your opinion which I disagree, and disagree that the = editors >> removed the section of sequence number without consensus of = WG. >>=20 >>=20 >> You know that the old section was plain WRONG, yes? >>=20 >> (I suggest reading section 4.5 of nhdp-threats-00) >>=20 >> Because the attack it described cannot happen to NHDP. >>=20 >> If you want to get the "sequence number attack" paragraph back, >> maybe you should write a new one... one that applies to NHDP. >>=20 >>=20 >> Henning Rogge >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961 , Fax +49 = 228 >> 9435 685 >> mailto:henning.rogge@fkie.__fraunhofer.de >> = http://www.fkie.fraunhofer.de >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >=20 >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From john.dowdell@cassidian.com Tue Feb 26 04:20:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C2121F86CB for ; Tue, 26 Feb 2013 04:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzFDYza28Qqa for ; Tue, 26 Feb 2013 04:20:18 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 036AD21F8A08 for ; Tue, 26 Feb 2013 04:20:16 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 26 Feb 2013 13:20:11 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 26 Feb 2013 13:20:11 +0100 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Feb 2013 13:20:10 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Feb 2013 13:20:10 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 12:20:10 +0000 From: "Dowdell, John" To: Abdussalam Baryun , "Charles E. Perkins" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-26.txt Thread-Index: AQHOFBHUnaSl0DuIqUWtgEDniQHpzZiMDrKg Date: Tue, 26 Feb 2013 12:20:10 +0000 Message-ID: <603F5FD847B5174CBDA37A9DC00532FB06ACABBD@SUCNPTEXM02.com.ad.uk.ds.corp> References: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> <512BEF17.70605@computer.org> <7117edef-b2ee-40d5-90fd-7002c639a6cb@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <7117edef-b2ee-40d5-90fd-7002c639a6cb@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.131] Content-Type: multipart/alternative; boundary="_000_603F5FD847B5174CBDA37A9DC00532FB06ACABBDSUCNPTEXM02coma_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Feb 2013 12:20:10.0882 (UTC) FILETIME=[9F40CE20:01CE141B] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19658.003 X-TM-AS-Result: No--19.259100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:20:22 -0000 --_000_603F5FD847B5174CBDA37A9DC00532FB06ACABBDSUCNPTEXM02coma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Abdussalam Yes that is the case. As Charlie mentioned it was forced on us by the IT ma= chinery. We will fix it as soon as we are able. Regards John From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: 26 February 2013 11:10 To: Charles E. Perkins Cc: manet@ietf.org; Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt Hi AODVv2 Editors, So do you mean if I review now the dymo-26 it is the same as aodvv2-00, please advise, AB On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins > wrote: Hello folks, draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts directories. The only problem is that it's got the wrong name, namely "draft-ietf-manet-dymo-26.txt" This is because it's now a week past the submission deadline for ...-00.txt initial drafts, and the submission tool would not allow me to upload it wit= h it's intended new name. This naming problem will be rectified at the earliest opportunity. Regards, Charlie P. On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of = the IETF. Title : Dynamic MANET On-demand (AODVv2) Routing Author(s) : Charles E. Perkins Stan Ratliff John Dowdell Filename : draft-ietf-manet-dymo-26.txt Pages : 60 Date : 2013-02-25 Abstract: The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dymo There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-dymo-26 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26 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 -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com --_000_603F5FD847B5174CBDA37A9DC00532FB06ACABBDSUCNPTEXM02coma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Abdussalam

 

Yes that is the case. As Charlie mentioned it = was forced on us by the IT machinery. We will fix it as soon as we are able= .

 

Regards

 

John

 

 

 

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.o= rg] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 11:10
To: Charles E. Perkins
Cc: manet@ietf.org; Stan Ratliff
Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt=

 

Hi AODVv2 Editors,

 

So do you mean if I review now the dymo-26 it is the= same as aodvv2-00,

please advise,

 

AB

On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins= <charliep@co= mputer.org> wrote:


Hello folks,

draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts directories.  The only problem is that it's got the wrong name, namely=
"draft-ietf-manet-dymo-26.txt"

This is because it's now a week past the submission deadline for ...-00.txt=
initial drafts, and the submission tool would not allow me to upload it wit= h
it's intended new name.

This naming problem will be rectified at the earliest opportunity.

Regards,
Charlie P.





On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote:

A New Internet-Draft = is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Mobile Ad-hoc Networks Working Grou= p of the IETF.

        Title           : Dyna= mic MANET On-demand (AODVv2) Routing
        Author(s)       : Charles E. Per= kins
                     = ;      Stan Ratliff
                     = ;      John Dowdell
        Filename        : draft-iet= f-manet-dymo-26.txt
        Pages           : 60         Date            := 2013-02-25

Abstract:
    The revised Ad Hoc On-demand Distance Vector (AODVv2) routing=
    protocol is intended for use by mobile routers in wireless, m= ultihop
    networks.  AODVv2 determines unicast routes among AODVv2= routers
    within the network in an on-demand fashion, offering on-deman= d
    convergence in dynamic topologies.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-dymo-26

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26<= /a>


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

 

--
Regards,
Charlie P.



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

 

The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-mail or attached files, please con= tact the sender prior to any such disclosure. If you are not the intended r= ecipient, any disclosure, copying or distribution is prohibited. Please als= o contact the sender and inform them of the error and delete the e-mail, including any attached files from= your system. Cassidian Limited, Registered Office : Quadrant House, Celtic= Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cas= sidian.com --_000_603F5FD847B5174CBDA37A9DC00532FB06ACABBDSUCNPTEXM02coma_-- From abdussalambaryun@gmail.com Tue Feb 26 04:20:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40ADB21F8A96 for ; Tue, 26 Feb 2013 04:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3oZkbJdNoQV for ; Tue, 26 Feb 2013 04:20:46 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42A4D21F86C5 for ; Tue, 26 Feb 2013 04:20:46 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id kp1so2424530pab.3 for ; Tue, 26 Feb 2013 04:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cHEV47f+OCGrXlVQfWydGzm7NYqQeaO1esQeflGorZU=; b=E/rIZlhrp8JJpCUV1eQrum0WygtbDI+rvLCrKFGRg+CU+bnPcgkPls8KLH+RBdmnfi qf3zS20b0hVMAPZQaBYeDk2SDfSNGmYx1vDS2fzO4p//Aehkj6EcSCzT7L84khsJTIqI plu74cm9/s7//+c3CfrcjtCJECTU0Q6Wn9e7dLIY3KRS5JoptCViWhtRBVRNyH/fWmQN y/wofc4T8e4Rg4o2ZR93TWS3EEVbU09EQzqOIKAIoQ40bMIOMti5f5t6SFiJoswwzfXy 4+S2Dawo7YIHY6SRfGssNxvT5nBoUeXwHFLfQKURHQ0AKaIR3SYyUhdTjGS2M4AyM2Xf Ob9Q== MIME-Version: 1.0 X-Received: by 10.68.204.68 with SMTP id kw4mr23200878pbc.113.1361881245863; Tue, 26 Feb 2013 04:20:45 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 04:20:45 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> <512CA5AD.4030800@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 12:20:45 +0000 Message-ID: From: Abdussalam Baryun To: Thomas Clausen Content-Type: multipart/alternative; boundary=047d7b10cd95e56b4f04d69fafac Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:20:47 -0000 --047d7b10cd95e56b4f04d69fafac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There was a input of John which I refered to in the ticket, AB On Tue, Feb 26, 2013 at 12:18 PM, Thomas Clausen wrote: > > On Feb 26, 2013, at 1:08 PM, Henning Rogge < > henning.rogge@fkie.fraunhofer.de> wrote: > > > Hi, > > > > so do we have an agreement that the old "sequence number attack" sectio= n > of nhdp-threats-00 is wrong and must be removed because it describes > something that does not apply to NHDP? > > > > If we (as a working group) decide we want a "sequence number attack" > section in nhdp-threats, someone needs to write up a corresponding sectio= n > and we have to see if it gets consensus in the group. > > > > I believe that if there is a sequence number attack on NHDP, then it > should be written down. > I also believe that I've not seen anything indicating that such an attack > exists. > > That's what you're saying, isn't it? > > > Henning Rogge > > > > On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: > >> your right thanks :) > >> AB > >> > >> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge > >> >> > wrote: > >> > >> On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: > >> > >> I can only repeat it again: NHDP does *not* use sequence > >> numbers, > >> neither packet nor message sequence numbers. > >> > >> That is your opinion which I disagree, and disagree that the > editors > >> removed the section of sequence number without consensus of WG. > >> > >> > >> You know that the old section was plain WRONG, yes? > >> > >> (I suggest reading section 4.5 of nhdp-threats-00) > >> > >> Because the attack it described cannot happen to NHDP. > >> > >> If you want to get the "sequence number attack" paragraph back, > >> maybe you should write a new one... one that applies to NHDP. > >> > >> > >> Henning Rogge > >> > >> -- > >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >> Kommunikationssysteme (KOM) > >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >> Telefon +49 228 9435-961 , Fax +49 22= 8 > >> 9435 685 > >> mailto:henning.rogge@fkie.__fraunhofer.de > >> > http://www.fkie.fraunhofer.de > >> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > >> > >> > > > > > > -- > > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > > Kommunikationssysteme (KOM) > > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > > Telefon +49 228 9435-961, Fax +49 228 9435 685 > > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > > _______________________________________________ > > 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 > --047d7b10cd95e56b4f04d69fafac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There was a input of John which I refered to in the ticket,
= =A0
AB

On Tue, Feb 26, 20= 13 at 12:18 PM, Thomas Clausen <thomas@thomasclausen.org> wrote:

On Feb 26, 2013, at 1:08 PM, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:

> Hi,
>
> so do we have an agreement that the old "sequence number attack&q= uot; section of nhdp-threats-00 is wrong and must be removed because it des= cribes something that does not apply to NHDP?
>
> If we (as a working group) decide we want a "sequence number atta= ck" section in nhdp-threats, someone needs to write up a corresponding= section and we have to see if it gets consensus in the group.
>

I believe that if there is a sequence number attack on NHDP, then it = should be written down.
I also believe that I've not seen anything indicating that such an atta= ck exists.

That's what you're saying, isn't it?

> Henning Rogge
>
> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote:
>> your right thanks :)
>> AB
>>
>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge
>> <henning.ro= gge@fkie.fraunhofer.de
>> <mailto:hen= ning.rogge@fkie.fraunhofer.de>> wrote:
>>
>> =A0 =A0On 02/26/2013 12:21 PM, Abdussalam Baryun wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 I can only repeat it again: NHDP does *not= * use sequence
>> =A0 =A0 =A0 =A0numbers,
>> =A0 =A0 =A0 =A0 =A0 =A0 neither packet nor message sequence number= s.
>>
>> =A0 =A0 =A0 =A0That is your opinion which I disagree, and disagree= that the editors
>> =A0 =A0 =A0 =A0removed the section of sequence number without cons= ensus of WG.
>>
>>
>> =A0 =A0You know that the old section was plain WRONG, yes?
>>
>> =A0 =A0(I suggest reading section 4.5 of nhdp-threats-00)
>>
>> =A0 =A0Because the attack it described cannot happen to NHDP.
>>
>> =A0 =A0If you want to get the "sequence number attack" p= aragraph back,
>> =A0 =A0maybe you should write a new one... one that applies to NHD= P.
>>
>>
>> =A0 =A0Henning Rogge
>>
>> =A0 =A0--
>> =A0 =A0Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f= =FCr
>> =A0 =A0Kommunikation, Informationsverarbeitung und Ergonomie FKIE<= br> >> =A0 =A0Kommunikationssysteme (KOM)
>> =A0 =A0Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>> =A0 =A0Telefon +49 228 9435-961 <tel:%2B49%20228%209435-961>, =A0 Fa= x +49 228
>> =A0 =A09435 685 <tel:%2B49%20228%209435%20685>
>> =A0 =A0mailto:henning.rogge= @fkie.__fraunhofer.d= e
>> =A0 =A0<mailto:henning.rogge@fkie.fraunhofer.de> http://www.fkie.fraunhofer.de
>>
>>
>> =A0 =A0_______________________________________________
>> =A0 =A0manet mailing list
>> =A0 =A0manet@ietf.org <ma= ilto:manet@ietf.org>
>> =A0 =A0https://www.ietf.org/mailman/listinfo/manet
>>
>>
>
>
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685
> mailto:henning.rog= ge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>
> _______________________________________________
> 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

--047d7b10cd95e56b4f04d69fafac-- From thomas@thomasclausen.org Tue Feb 26 04:22:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076A021F8A9B for ; Tue, 26 Feb 2013 04:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzdzEH3vVmtV for ; Tue, 26 Feb 2013 04:22:11 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id F1D3E21F86E1 for ; Tue, 26 Feb 2013 04:22:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DD13D1BC6687; Tue, 26 Feb 2013 04:22:10 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 1B8D11BC6680; Tue, 26 Feb 2013 04:22:08 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DA258A20-F156-4D15-A2FA-42166EAFC11B" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Clausen In-Reply-To: <603F5FD847B5174CBDA37A9DC00532FB06ACABBD@SUCNPTEXM02.com.ad.uk.ds.corp> Date: Tue, 26 Feb 2013 13:22:05 +0100 Message-Id: <0CFB809D-6517-47A9-AF15-EECAF852204E@thomasclausen.org> References: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> <512BEF17.70605@computer.org> <7117edef-b2ee-40d5-90fd-7002c639a6cb@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB06ACABBD@SUCNPTEXM02.com.ad.uk.ds.corp> To: "Dowdell, John" X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:22:12 -0000 --Apple-Mail=_DA258A20-F156-4D15-A2FA-42166EAFC11B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Before a new document is adopted as a WG document, the WG will be polled = for adoption - yes? Thomas On Feb 26, 2013, at 1:20 PM, "Dowdell, John" = wrote: > Abdussalam > =20 > Yes that is the case. As Charlie mentioned it was forced on us by the = IT machinery. We will fix it as soon as we are able. > =20 > Regards > =20 > John > =20 > =20 > =20 > =20 > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Abdussalam Baryun > Sent: 26 February 2013 11:10 > To: Charles E. Perkins > Cc: manet@ietf.org; Stan Ratliff > Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt > =20 > Hi AODVv2 Editors, > =20 > So do you mean if I review now the dymo-26 it is the same as = aodvv2-00, > please advise, > =20 > AB >=20 > On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins = wrote: >=20 > Hello folks, >=20 > draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet = Drafts > directories. The only problem is that it's got the wrong name, namely > "draft-ietf-manet-dymo-26.txt" >=20 > This is because it's now a week past the submission deadline for = ...-00.txt > initial drafts, and the submission tool would not allow me to upload = it with > it's intended new name. >=20 > This naming problem will be rectified at the earliest opportunity. >=20 > Regards, > Charlie P. >=20 >=20 >=20 >=20 > On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Mobile Ad-hoc Networks Working = Group of the IETF. >=20 > Title : Dynamic MANET On-demand (AODVv2) Routing > Author(s) : Charles E. Perkins > Stan Ratliff > John Dowdell > Filename : draft-ietf-manet-dymo-26.txt > Pages : 60 > Date : 2013-02-25 >=20 > Abstract: > The revised Ad Hoc On-demand Distance Vector (AODVv2) routing > protocol is intended for use by mobile routers in wireless, = multihop > networks. AODVv2 determines unicast routes among AODVv2 routers > within the network in an on-demand fashion, offering on-demand > convergence in dynamic topologies. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dymo >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-dymo-26 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > =20 > --=20 > Regards, > Charlie P. >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 > The information contained within this e-mail and any files attached to = this e-mail is private and in addition may include commercially = sensitive information. The contents of this e-mail are for the intended = recipient only and therefore if you wish to disclose the information = contained within this e-mail or attached files, please contact the = sender prior to any such disclosure. If you are not the intended = recipient, any disclosure, copying or distribution is prohibited. Please = also contact the sender and inform them of the error and delete the = e-mail, including any attached files from your system. Cassidian = Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, = Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com = _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_DA258A20-F156-4D15-A2FA-42166EAFC11B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Before a new document is = adopted as a WG document, the WG will be polled for adoption - = yes?

Thomas

On Feb 26, 2013, at 1:20 = PM, "Dowdell, John" <John.Dowdell@Cassidian.com&= gt; wrote:

Yes that is the case. As Charlie = mentioned it was forced on us by the IT machinery. We will fix it as = soon as we are able.

Regards

 

John

 

 

 manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam = Baryun
Sent: 26 February 2013 = 11:10
To: Charles E. = Perkins
Cc: manet@ietf.org; Stan Ratliff
Subject: Re: [manet] I-D Action: = draft-ietf-manet-dymo-26.txt

 

Hi = AODVv2 Editors,

 

So do you mean = if I review now the dymo-26 it is the same as = aodvv2-00,
please = advise,

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

        Title       =     : Dynamic MANET On-demand (AODVv2) Routing
  =       Author(s)       : Charles E. = Perkins
                =            Stan Ratliff
    =                     =    John Dowdell
        Filename   =      : draft-ietf-manet-dymo-26.txt
    =     Pages           : 60
  =       Date            : = 2013-02-25

Abstract:
    The revised Ad Hoc = On-demand Distance Vector (AODVv2) routing
    protocol is = intended for use by mobile routers in wireless, multihop
  =   networks.  AODVv2 determines unicast routes among AODVv2 = routers
    within the network in an on-demand fashion, = offering on-demand
    convergence in dynamic = topologies.


The IETF datatracker status page for this draft = is:
manet@ietf.org

The information = contained within this e-mail and any files attached to this e-mail is = private and in addition may include commercially sensitive information. = The contents of this e-mail are for the intended recipient only and = therefore if you wish to disclose the information contained within this = e-mail or attached files, please contact the sender prior to any such = disclosure. If you are not the intended recipient, any disclosure, = copying or distribution is prohibited. Please also contact the sender = and inform them of the error and delete the e-mail, including any = attached files from your system. Cassidian Limited, Registered Office : = Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company = No: 04191036 http://www.cassidian.com _____________________________= __________________
manet mailing list
manet@ietf.org
Content-Type: multipart/alternative; boundary=047d7b2e42a2fec5fc04d69fb503 Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:22:29 -0000 --047d7b2e42a2fec5fc04d69fb503 Content-Type: text/plain; charset=ISO-8859-1 Thanks John I will try to review and respond, Best AB On Tue, Feb 26, 2013 at 12:20 PM, Dowdell, John wrote: > Abdussalam > > > > Yes that is the case. As Charlie mentioned it was forced on us by the IT > machinery. We will fix it as soon as we are able. > > > > Regards > > > > John > > > > > > > > > > *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On Behalf > Of *Abdussalam Baryun > *Sent:* 26 February 2013 11:10 > *To:* Charles E. Perkins > *Cc:* manet@ietf.org; Stan Ratliff > *Subject:* Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt > > > > Hi AODVv2 Editors, > > > > So do you mean if I review now the dymo-26 it is the same as aodvv2-00, > > please advise, > > > > AB > > On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins < > charliep@computer.org> wrote: > > > Hello folks, > > draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts > directories. The only problem is that it's got the wrong name, namely > "draft-ietf-manet-dymo-26.txt" > > This is because it's now a week past the submission deadline for ...-00.txt > initial drafts, and the submission tool would not allow me to upload it > with > it's intended new name. > > This naming problem will be rectified at the earliest opportunity. > > Regards, > Charlie P. > > > > > > On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. > > Title : Dynamic MANET On-demand (AODVv2) Routing > Author(s) : Charles E. Perkins > Stan Ratliff > John Dowdell > Filename : draft-ietf-manet-dymo-26.txt > Pages : 60 > Date : 2013-02-25 > > Abstract: > The revised Ad Hoc On-demand Distance Vector (AODVv2) routing > protocol is intended for use by mobile routers in wireless, multihop > networks. AODVv2 determines unicast routes among AODVv2 routers > within the network in an on-demand fashion, offering on-demand > convergence in dynamic topologies. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dymo > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-dymo-26 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dymo-26 > > > 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 > > > > -- > Regards, > Charlie P. > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > The information contained within this e-mail and any files attached to > this e-mail is private and in addition may include commercially sensitive > information. The contents of this e-mail are for the intended recipient > only and therefore if you wish to disclose the information contained within > this e-mail or attached files, please contact the sender prior to any such > disclosure. If you are not the intended recipient, any disclosure, copying > or distribution is prohibited. Please also contact the sender and inform > them of the error and delete the e-mail, including any attached files from > your system. Cassidian Limited, Registered Office : Quadrant House, Celtic > Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 > http://www.cassidian.com > --047d7b2e42a2fec5fc04d69fb503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks John
=A0
I will try to review and respond,=
=A0
Best
=A0AB

On Tue, Feb 26, 2013 at 12:20 PM, Dowdell, John <John.= Dowdell@cassidian.com> wrote:

Abdussalam

=A0

Yes that is the case. As Charlie mentioned it w= as forced on us by the IT machinery. We will fix it as soon as we are able.=

=A0

Regards

=A0

John

=A0

=A0

=A0

=A0

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 11:10
To: Charles E. Perkins
Cc: manet@ietf.o= rg; Stan Ratliff
Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt=

=A0

Hi AODVv2 Editors,

=A0

So do you mean if I review now the dymo-26 it is the= same as aodvv2-00,

please advise,

=A0

AB

On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins= <charliep@co= mputer.org> wrote:


Hello folks,

draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts directories. =A0The only problem is that it's got the wrong name, namel= y
"draft-ietf-manet-dymo-26.txt"

This is because it's now a week past the submission deadline for ...-00= .txt
initial drafts, and the submission tool would not allow me to upload it wit= h
it's intended new name.

This naming problem will be rectified at the earliest opportunity.

Regards,
Charlie P.





On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote:

A New Internet-Draft is= available from the on-line Internet-Drafts directories.
=A0 This draft is a work item of the Mobile Ad-hoc Networks Working Group o= f the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Dynamic MANET On-demand (AODVv2= ) Routing
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Charles E. Perkins
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stan Ratliff
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0John Dowdell
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-manet-dymo-26.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 60
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-25

Abstract:
=A0 =A0 The revised Ad Hoc On-demand Distance Vector (AODVv2) routing
=A0 =A0 protocol is intended for use by mobile routers in wireless, multiho= p
=A0 =A0 networks. =A0AODVv2 determines unicast routes among AODVv2 routers<= br> =A0 =A0 within the network in an on-demand fashion, offering on-demand
=A0 =A0 convergence in dynamic topologies.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-dymo-26

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26<= /a>


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

=A0

--
Regards,
Charlie P.



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

=A0

The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-mail or attached files, please con= tact the sender prior to any such disclosure. If you are not the intended r= ecipient, any disclosure, copying or distribution is prohibited. Please als= o contact the sender and inform them of the error and delete the e-mail, including any attached files from= your system. Cassidian Limited, Registered Office : Quadrant House, Celtic= Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

--047d7b2e42a2fec5fc04d69fb503-- From wwwrun@rfc-editor.org Tue Feb 26 05:24:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3835E21F88FC for ; Tue, 26 Feb 2013 05:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vh2MHW302vC3 for ; Tue, 26 Feb 2013 05:24:22 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D83B821F869F for ; Tue, 26 Feb 2013 05:24:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 97678B1E006; Tue, 26 Feb 2013 05:23:09 -0800 (PST) To: macker@itd.nrl.navy.mil, stbryant@cisco.com, adrian@olddog.co.uk, sratliff@cisco.com, macker@itd.nrl.navy.mil From: RFC Errata System Message-Id: <20130226132309.97678B1E006@rfc-editor.org> Date: Tue, 26 Feb 2013 05:23:09 -0800 (PST) Cc: elloyd@udel.edu, manet@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 13:24:24 -0000 The following errata report has been submitted for RFC6621, "Simplified Multicast Forwarding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6621&eid=3499 -------------------------------------- Type: Technical Reported by: Errol Lloyd Section: B.4. Original Text ------------- 1. Initialize the set "MPR" to empty. 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". 3. Initialize the set "N2" to include all 2-hop neighbors, excluding "n0" and any routers in "N1". Nodes that are only reachable via "N1" routers with router priority values of NEVER are also excluded. 4. For each interface "y" in "N1", initialize a set "N2(y)" to include any interfaces in "N2" that are 1-hop neighbors of "y". 5. For each interface "x" in "N1" with a router priority value of "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR: A. Add "x" to the set "MPR" and remove "x" from "N1". B. For each interface "z" in "N2(x)", remove "z" from "N2". C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)". 6. For each interface "z" in "N2", initialize the set "N1(z)" to include any interfaces in "N1" that are 1-hop neighbors of "z". 7. For each interface "x" in "N2" where "N1(x)" has only one member, select "x" as an MPR: A. Add "x" to the set "MPR" and remove "x" from "N1". B. For each interface "z" in "N2(x)", remove "z" from "N2" and delete "N1(z)". C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)". 8. While "N2" is not empty, select the interface "x" in "N1" with the largest router priority that has the number of members in "N_2(x)" as an MPR: A. Add "x" to the set "MPR" and remove "x" from "N1". B. For each interface "z" in "N2(x)", remove "z" from "N2". C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)". Corrected Text -------------- 1. Initialize the set "MPR" to empty. 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". 3. Initialize the set "N2" to include all 2-hop neighbors, excluding "n0" and any routers in "N1". Nodes that are only reachable via "N1" routers with router priority values of NEVER are also excluded. 4. For each interface "y" in "N1", initialize a set "N2(y)" to include any interfaces in "N2" that are 1-hop neighbors of "y". 5. For each interface "x" in "N1" with a router priority value of "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR: A. Add "x" to the set "MPR" and remove "x" from "N1". B. For each interface "z" in "N2(x)", remove "z" from "N2". C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)". 6. For each interface "z" in "N2", initialize the set "N1(z)" to include any interfaces in "N1" that are 1-hop neighbors of "z". 7. For each interface "w" in "N2" where "N1(w)" has only one member, "x", select "x" as an MPR: A. Add "x" to the set "MPR" and remove "x" from "N1". B. For each interface "z" in "N2(x)", remove "z" from "N2". C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)". 8. While "N2" is not empty, select the interface "x" in "N1" with the highest router priority [break ties in favor of the node with the largest number of members in "N_2(x)"] as an MPR: A. Add "x" to the set "MPR" and remove "x" from "N1". B. For each interface "z" in "N2(x)", remove "z" from "N2". C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)". Notes ----- There are three changes: On line 7, the first and second occurrences of x are replaced by w, and then x is given as the name of the sole member of N1(w). On line 7B, the phrase 'delete "N1(z)" is dropped to be consistent with the rest of the algorithm. On line 8 some rewording is done for clarification. This errata prepared in consultation with Justin Dean and Gus Macker. Instructions: ------------- This errata 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. -------------------------------------- RFC6621 (draft-ietf-manet-smf-14) -------------------------------------- Title : Simplified Multicast Forwarding Publication Date : May 2012 Author(s) : J. Macker, Ed. Category : EXPERIMENTAL Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From abdussalambaryun@gmail.com Tue Feb 26 06:09:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3F421F8994 for ; Tue, 26 Feb 2013 06:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zsMHFLul4eA for ; Tue, 26 Feb 2013 06:09:51 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 59DEF21F8991 for ; Tue, 26 Feb 2013 06:09:51 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id kp6so2426916pab.8 for ; Tue, 26 Feb 2013 06:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q/D7fZMH9uVK/wf41qd0MR/W3kd3bOexo9ppTEmLf8Q=; b=xF+1ylsYjKakWyfC/vxrhFvgRBxt85u8S3TtuXqTIxLKm4zYHSjFwWbuRjQPOVt0nK J0v3Ga6d6d83ArJPUoRmK15IwMw/pium6dSmcmjUEUgwgPe8c5BmH3z2WwSGkhgkBW+t 27PIs1ppD2ybifR9t+AyIOpYF4dKDlnnyGWp08NcjawmRGjCgZIkS+Mcccszz37vE4Dm bMNfRBSVSXZD/CVKrG0FK0B5LK6dzl6nrUH48MfS+T3zsSVITpwayU+OBvznGIT4sQcA +wc3h0BPY76SM/3J/cPoYtxEEgZBiswNQYlu4sRQozV5FEUypCUABhU3Paafo/8lvwJq Y14w== MIME-Version: 1.0 X-Received: by 10.68.245.229 with SMTP id xr5mr23676880pbc.163.1361887791109; Tue, 26 Feb 2013 06:09:51 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 06:09:50 -0800 (PST) In-Reply-To: <20130225151705.EB129B1E008@rfc-editor.org> References: <20130225151705.EB129B1E008@rfc-editor.org> Date: Tue, 26 Feb 2013 14:09:50 +0000 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=047d7b2e155d035fa204d6a1361a Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:09:52 -0000 --047d7b2e155d035fa204d6a1361a Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, and All Does the changes in RFC5444 will affect other RFCs or protocols? we need to discuss this through, because many depend on RFC5444, and we did not understand the authors suggestions as they are the experts of the work, AB On Mon, Feb 25, 2013 at 3:17 PM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > > The following errata report has been submitted for RFC5444, > "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=3496 > > -------------------------------------- > Type: Technical > Reported by: Christopher Dearlove > > Section: Appendix A > > Original Text > ------------- > o The field, if present, contains a sequence number > that is incremented by 1 for each packet generated by a node. The > sequence number after 65535 is 0. In other words, the sequence > number "wraps" in the usual way. > > > Corrected Text > -------------- > o The field, if present, contains a sequence number > that SHOULD be maintained for each participating interface and > incremented by 1 for each packet generated by a node for that > interface. The sequence number after 65535 is 0. In other words, > the sequence number "wraps" in the usual way. > > > Notes > ----- > Packet sequence number should be per interface, not per node. Uses that > recognise missing packet sequence numbers only work in the corrected > (intended) case. > > Instructions: > ------------- > This errata 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. > > -------------------------------------- > RFC5444 (draft-ietf-manet-packetbb-17) > -------------------------------------- > Title : Generalized Mobile Ad Hoc Network (MANET) > Packet/Message Format > Publication Date : February 2009 > Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih > Category : PROPOSED STANDARD > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b2e155d035fa204d6a1361a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chris, and All
=A0
Does the changes in RFC5444 = will affect other RFCs or protocols? we need to discuss this through, becau= se many depend on RFC5444, and we did not understand the authors suggestion= s as they are the experts of the work,
=A0
AB

On Mon, Feb 2= 5, 2013 at 3:17 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The following errata report has been submitted for RFC5444,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format"= .

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D5444&eid=3D3496

--------------------------------------
Type: Technical
Reported by: Christopher Dearlove <chris.dearlove@baesystems.com>

Section: Appendix A

Original Text
-------------
=A0 =A0o =A0The <pkt-seq-num> field, if present, contains a sequence = number
=A0 =A0 =A0 that is incremented by 1 for each packet generated by a node. = =A0The
=A0 =A0 =A0 sequence number after 65535 is 0. =A0In other words, the sequen= ce
=A0 =A0 =A0 number "wraps" in the usual way.


Corrected Text
--------------
=A0 =A0o =A0The <pkt-seq-num> field, if present, contains a sequence = number
=A0 =A0 =A0 that SHOULD be maintained for each participating interface and<= br> =A0 =A0 =A0 incremented by 1 for each packet generated by a node for that =A0 =A0 =A0 interface. =A0The sequence number after 65535 is 0. =A0In other= words,
=A0 =A0 =A0 the sequence number "wraps" in the usual way.


Notes
-----
Packet sequence number should be per interface, not per node. Uses that rec= ognise missing packet sequence numbers only work in the corrected (intended= ) case.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
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.

--------------------------------------
RFC5444 (draft-ietf-manet-packetbb-17)
--------------------------------------
Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Generalized Mobile Ad Hoc Network (MANE= T) Packet/Message Format
Publication Date =A0 =A0: February 2009
Author(s) =A0 =A0 =A0 =A0 =A0 : T. Clausen, C. Dearlove, J. Dean, C. Adjih<= br> Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Mobile Ad-hoc Networks
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7b2e155d035fa204d6a1361a-- From abdussalambaryun@gmail.com Tue Feb 26 06:15:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCDA21F8A6B for ; Tue, 26 Feb 2013 06:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw+B2A42gph9 for ; Tue, 26 Feb 2013 06:15:25 -0800 (PST) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id CEA1821F8995 for ; Tue, 26 Feb 2013 06:15:24 -0800 (PST) Received: by mail-da0-f42.google.com with SMTP id z17so2037754dal.15 for ; Tue, 26 Feb 2013 06:15:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3lgwztPVlaJvVbTIc7Db62gbfD6Tj3bVwE1vpqdalfE=; b=MAb+tsUezsduJZ51dwHJ3DXf7wnYRZV6E6yU0lnY3GQygmLnczzhKgvpEESod28f6Y OMLXNeFwC9NX7o0atkELdRwnSKF9288oNLxES559bvUbcFx9b6paElRZTwFrjZWj+aq0 Ji/Mc1Drte6LvtvV7HBla0VhsAtD1H3klSdx1OON48O+f4Bfk/fAHANF3NMDmzXYiVLB nvT3075EXEevMd7gsAy2NkeACodVpkihPX1uDIkvHau9ptLSxGIXH5id6sb+cQS7dBQU RJz2qBPoaDVKtn20Fvm/yAcC2sl5T7czdEVf/SYGLPr/KruJC49z7Zv+hBOz1lCXskmX B5zQ== MIME-Version: 1.0 X-Received: by 10.68.28.194 with SMTP id d2mr23298320pbh.215.1361888124578; Tue, 26 Feb 2013 06:15:24 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 06:15:24 -0800 (PST) In-Reply-To: <20130226132309.97678B1E006@rfc-editor.org> References: <20130226132309.97678B1E006@rfc-editor.org> Date: Tue, 26 Feb 2013 14:15:24 +0000 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: multipart/alternative; boundary=bcaec5216263e3b36a04d6a149fe Cc: elloyd@udel.edu, sratliff@cisco.com, macker@itd.nrl.navy.mil, RFC Errata System Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:15:26 -0000 --bcaec5216263e3b36a04d6a149fe Content-Type: text/plain; charset=ISO-8859-1 Hi Editors of RFC6621 or Errata reporter, Could you inform us why is this errata now posted, I need to discuss with you to understand, AB On Tue, Feb 26, 2013 at 1:23 PM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > > The following errata report has been submitted for RFC6621, > "Simplified Multicast Forwarding". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6621&eid=3499 > > -------------------------------------- > Type: Technical > Reported by: Errol Lloyd > > Section: B.4. > > Original Text > ------------- > 1. Initialize the set "MPR" to empty. > > 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". > > 3. Initialize the set "N2" to include all 2-hop neighbors, excluding > "n0" and any routers in "N1". Nodes that are only reachable via > "N1" routers with router priority values of NEVER are also > excluded. > > 4. For each interface "y" in "N1", initialize a set "N2(y)" to > include any interfaces in "N2" that are 1-hop neighbors of "y". > > 5. For each interface "x" in "N1" with a router priority value of > "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". > > 6. For each interface "z" in "N2", initialize the set "N1(z)" to > include any interfaces in "N1" that are 1-hop neighbors of "z". > > 7. For each interface "x" in "N2" where "N1(x)" has only one member, > select "x" as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2" and > delete "N1(z)". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". > > 8. While "N2" is not empty, select the interface "x" in "N1" with > the largest router priority that has the number of members in > "N_2(x)" as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". > > > > > > Corrected Text > -------------- > 1. Initialize the set "MPR" to empty. > > 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". > > 3. Initialize the set "N2" to include all 2-hop neighbors, excluding > "n0" and any routers in "N1". Nodes that are only reachable via > "N1" routers with router priority values of NEVER are also > excluded. > > 4. For each interface "y" in "N1", initialize a set "N2(y)" to > include any interfaces in "N2" that are 1-hop neighbors of "y". > > 5. For each interface "x" in "N1" with a router priority value of > "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". > > 6. For each interface "z" in "N2", initialize the set "N1(z)" to > include any interfaces in "N1" that are 1-hop neighbors of "z". > > 7. For each interface "w" in "N2" where "N1(w)" has only one member, > "x", > select "x" as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". > > 8. While "N2" is not empty, select the interface "x" in "N1" with > the highest router priority [break ties in favor of the node with > the > largest number of members in "N_2(x)"] as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". > > > > > > Notes > ----- > There are three changes: > > On line 7, the first and second occurrences of x are replaced by w, and > then x is given as the name of the sole member of N1(w). > > On line 7B, the phrase 'delete "N1(z)" is dropped to be consistent with > the rest of the algorithm. > > On line 8 some rewording is done for clarification. > > This errata prepared in consultation with Justin Dean and Gus Macker. > > Instructions: > ------------- > This errata 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. > > -------------------------------------- > RFC6621 (draft-ietf-manet-smf-14) > -------------------------------------- > Title : Simplified Multicast Forwarding > Publication Date : May 2012 > Author(s) : J. Macker, Ed. > Category : EXPERIMENTAL > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec5216263e3b36a04d6a149fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Editors of RFC6621 or Errata reporter,
=A0
Coul= d you inform us why is this errata now posted, I need to discuss with you t= o understand,
=A0
AB

On Tue, Feb 26, 2013 at 1:23 PM, RFC Errata System <rfc-editor@rfc= -editor.org> wrote:

The following errata report has been submitted for RFC6621,
"Simplified Multicast Forwarding".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D6621&eid=3D3499

--------------------------------------
Type: Technical
Reported by: Errol Lloyd <elloyd@udel= .edu>

Section: B.4.

Original Text
-------------
=A0 1. =A0Initialize the set "MPR" to empty.

=A0 =A02. =A0Initialize the set "N1" to include all 1-hop neighbo= rs of "n0".

=A0 =A03. =A0Initialize the set "N2" to include all 2-hop neighbo= rs, excluding
=A0 =A0 =A0 =A0"n0" and any routers in "N1". =A0Nodes t= hat are only reachable via
=A0 =A0 =A0 =A0"N1" routers with router priority values of NEVER = are also
=A0 =A0 =A0 =A0excluded.

=A0 =A04. =A0For each interface "y" in "N1", initialize= a set "N2(y)" to
=A0 =A0 =A0 =A0include any interfaces in "N2" that are 1-hop neig= hbors of "y".

=A0 =A05. =A0For each interface "x" in "N1" with a rout= er priority value of
=A0 =A0 =A0 =A0"ALWAYS" (or using the CF relay algorithm), select= "x" as an MPR:

=A0 =A0 =A0 =A0A. =A0Add "x" to the set "MPR" and remov= e "x" from "N1".

=A0 =A0 =A0 =A0B. =A0For each interface "z" in "N2(x)",= remove "z" from "N2".

=A0 =A0 =A0 =A0C. =A0For each interface "y" in "N1", re= move any interfaces in
=A0 =A0 =A0 =A0 =A0 =A0"N2(x)" from "N2(y)".

=A0 =A06. =A0For each interface "z" in "N2", initialize= the set "N1(z)" to
=A0 =A0 =A0 =A0include any interfaces in "N1" that are 1-hop neig= hbors of "z".

=A0 =A07. =A0For each interface "x" in "N2" where "= ;N1(x)" has only one member,
=A0 =A0 =A0 =A0select "x" as an MPR:

=A0 =A0 =A0 =A0A. =A0Add "x" to the set "MPR" and remov= e "x" from "N1".

=A0 =A0 =A0 =A0B. =A0For each interface "z" in "N2(x)",= remove "z" from "N2" and
=A0 =A0 =A0 =A0 =A0 =A0delete "N1(z)".

=A0 =A0 =A0 =A0C. =A0For each interface "y" in "N1", re= move any interfaces in
=A0 =A0 =A0 =A0 =A0 =A0"N2(x)" from "N2(y)".

=A0 =A08. =A0While "N2" is not empty, select the interface "= x" in "N1" with
=A0 =A0 =A0 =A0the largest router priority that has the number of members i= n
=A0 =A0 =A0 =A0"N_2(x)" as an MPR:

=A0 =A0 =A0 =A0A. =A0Add "x" to the set "MPR" and remov= e "x" from "N1".

=A0 =A0 =A0 =A0B. =A0For each interface "z" in "N2(x)",= remove "z" from "N2".

=A0 =A0 =A0 =A0C. =A0For each interface "y" in "N1", re= move any interfaces in
=A0 =A0 =A0 =A0 =A0 =A0"N2(x)" from "N2(y)".





Corrected Text
--------------
=A0 1. =A0Initialize the set "MPR" to empty.

=A0 =A02. =A0Initialize the set "N1" to include all 1-hop neighbo= rs of "n0".

=A0 =A03. =A0Initialize the set "N2" to include all 2-hop neighbo= rs, excluding
=A0 =A0 =A0 =A0"n0" and any routers in "N1". =A0Nodes t= hat are only reachable via
=A0 =A0 =A0 =A0"N1" routers with router priority values of NEVER = are also
=A0 =A0 =A0 =A0excluded.

=A0 =A04. =A0For each interface "y" in "N1", initialize= a set "N2(y)" to
=A0 =A0 =A0 =A0include any interfaces in "N2" that are 1-hop neig= hbors of "y".

=A0 =A05. =A0For each interface "x" in "N1" with a rout= er priority value of
=A0 =A0 =A0 =A0"ALWAYS" (or using the CF relay algorithm), select= "x" as an MPR:

=A0 =A0 =A0 =A0A. =A0Add "x" to the set "MPR" and remov= e "x" from "N1".

=A0 =A0 =A0 =A0B. =A0For each interface "z" in "N2(x)",= remove "z" from "N2".

=A0 =A0 =A0 =A0C. =A0For each interface "y" in "N1", re= move any interfaces in
=A0 =A0 =A0 =A0 =A0 =A0"N2(x)" from "N2(y)".

=A0 =A06. =A0For each interface "z" in "N2", initialize= the set "N1(z)" to
=A0 =A0 =A0 =A0include any interfaces in "N1" that are 1-hop neig= hbors of "z".

=A0 =A07. =A0For each interface "w" in "N2" where "= ;N1(w)" has only one member, "x",
=A0 =A0 =A0 =A0select "x" as an MPR:

=A0 =A0 =A0 =A0A. =A0Add "x" to the set "MPR" and remov= e "x" from "N1".

=A0 =A0 =A0 =A0B. =A0For each interface "z" in "N2(x)",= remove "z" from "N2".

=A0 =A0 =A0 =A0C. =A0For each interface "y" in "N1", re= move any interfaces in
=A0 =A0 =A0 =A0 =A0 =A0"N2(x)" from "N2(y)".

=A0 =A08. =A0While "N2" is not empty, select the interface "= x" in "N1" with
=A0 =A0 =A0 =A0the highest router priority [break ties in favor of the node= with the
=A0 =A0 =A0 =A0largest number of members in "N_2(x)"] as an MPR:<= br>
=A0 =A0 =A0 =A0A. =A0Add "x" to the set "MPR" and remov= e "x" from "N1".

=A0 =A0 =A0 =A0B. =A0For each interface "z" in "N2(x)",= remove "z" from "N2".

=A0 =A0 =A0 =A0C. =A0For each interface "y" in "N1", re= move any interfaces in
=A0 =A0 =A0 =A0 =A0 =A0"N2(x)" from "N2(y)".





Notes
-----
There are three changes:

On line 7, the first and second occurrences of x are replaced by w, and the= n x is given as the name of the sole member of N1(w).

On line 7B, the phrase 'delete "N1(z)" is dropped to be consi= stent with the rest of the algorithm.

On line 8 some rewording is done for clarification.

This errata prepared in consultation with Justin Dean and Gus Macker.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
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.

--------------------------------------
RFC6621 (draft-ietf-manet-smf-14)
--------------------------------------
Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Simplified Multicast Forwarding
Publication Date =A0 =A0: May 2012
Author(s) =A0 =A0 =A0 =A0 =A0 : J. Macker, Ed.
Category =A0 =A0 =A0 =A0 =A0 =A0: EXPERIMENTAL
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Mobile Ad-hoc Networks
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec5216263e3b36a04d6a149fe-- From henning.rogge@fkie.fraunhofer.de Tue Feb 26 06:22:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4795F21F8A6B for ; Tue, 26 Feb 2013 06:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.322 X-Spam-Level: X-Spam-Status: No, score=-1.322 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6QLnQzszQUz for ; Tue, 26 Feb 2013 06:22:24 -0800 (PST) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id C4FED21F8A68 for ; Tue, 26 Feb 2013 06:22:23 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UALQF-0005c8-65 for manet@ietf.org; Tue, 26 Feb 2013 15:22:23 +0100 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UALQF-0001kr-3S for manet@ietf.org; Tue, 26 Feb 2013 15:22:23 +0100 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 26 Feb 2013 15:22:22 +0100 Message-ID: <512CC517.20404@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 15:22:15 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <20130225151705.EB129B1E008@rfc-editor.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010802030300000901030902" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.6/16746/Tue Feb 26 13:50:28 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 4c0df1132e657673ab78dbdd5ac9f7d6 Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:22:26 -0000 --------------ms010802030300000901030902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 02/26/2013 03:09 PM, Abdussalam Baryun wrote: > Hi Chris, and All Does the changes in RFC5444 will affect other RFCs > or protocols? we need to discuss this through, because many depend on > RFC5444, > and we did not understand the authors suggestions maybe you intended to write "I did not understand..." ? > as they are the experts of the work, AB Allow me to quote myself from yesterday... On 02/25/2013 06:17 PM, Henning Rogge wrote: > I think you are trying to make an issue out of nothing. > > First, the errata is a SHOULD, which means that any proprietary > protocol can do whatever it likes. > > Second, neither DYMO nor NHDP nor OLSRv2 nor DLEP (which was using > RFC5444 for some time) uses packet sequence numbers. > > In fact the only draft I remember which used RFC5444 packet sequence > numbers was the "funkfeuer ETX" draft, which explicitly specified > that the packet sequence numbers had to be interface specific to use > this ETX variant. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms010802030300000901030902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAyMjYxNDIyMjBaMCMGCSqGSIb3DQEJBDEWBBT8o44TE9UZ2Y33FrpU2xAveZ/fmDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAOiqLa2EHeoJ2erdTfd8k2ZHRv2XSZ35Ob9GWYa1PgOWz CV0kUDXBZGX4How3+PdYz3lym9MrdzcKN+WP0YQ1Vz8qkYKDwURd/aBMwSCIp7PsKGAq/HQx mViW7U+VWe98wPlLR5C7SYsSHEBeR+MmsXHdDf1Ml9J0b6aAXQsja8P8Kks9aPShIqqB9Y2e dFkMU1f76dWIUDP3K1dc+GU4sg6n6H7Us+0pZPRLUlGqTRyGUrniXEESBc5/9WS+CcYj5g31 t/3AQuhPo4YkQj3enQ2aiNxanUXGYvNPDx3m9Iu5E/0LS7x4uxVJxBlK+eNnhAwb9+Izoz99 irFD8TOxNQAAAAAAAA== --------------ms010802030300000901030902-- From joseph.macker@nrl.navy.mil Tue Feb 26 06:34:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC36321F8A56 for ; Tue, 26 Feb 2013 06:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[AWL=2.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3Yni5gkbw6F for ; Tue, 26 Feb 2013 06:34:45 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) by ietfa.amsl.com (Postfix) with ESMTP id 2F25221F8A4F for ; Tue, 26 Feb 2013 06:34:37 -0800 (PST) Received: from vpn217206.nrl.navy.mil (vpn217206.nrl.navy.mil [132.250.217.206]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id r1QEYPCI002003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Feb 2013 09:34:34 -0500 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Macker In-Reply-To: Date: Tue, 26 Feb 2013 09:28:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <91644B38-BBF7-465E-B355-56F9D3944967@nrl.navy.mil> References: <20130226132309.97678B1E006@rfc-editor.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Cc: elloyd@udel.edu, manet@ietf.org, RFC Errata System , sratliff@cisco.com, macker@itd.nrl.navy.mil Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:34:46 -0000 Because it corrects an error in the MPR pseudocode appendix B. We like and encourage errata. I have approved this and Justin Dean helped provide replacement text. I wish to thank Errol and his team for providing this.=20 Our prototype code tends to use Appendix A so this does not affect any = working prototype that I know of. -joe On Feb 26, 2013, at 9:15 AM, Abdussalam Baryun = wrote: > Hi Editors of RFC6621 or Errata reporter, > =20 > Could you inform us why is this errata now posted, I need to discuss = with you to understand, > =20 > AB >=20 > On Tue, Feb 26, 2013 at 1:23 PM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC6621, > "Simplified Multicast Forwarding". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6621&eid=3D3499 >=20 > -------------------------------------- > Type: Technical > Reported by: Errol Lloyd >=20 > Section: B.4. >=20 > Original Text > ------------- > 1. Initialize the set "MPR" to empty. >=20 > 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". >=20 > 3. Initialize the set "N2" to include all 2-hop neighbors, = excluding > "n0" and any routers in "N1". Nodes that are only reachable = via > "N1" routers with router priority values of NEVER are also > excluded. >=20 > 4. For each interface "y" in "N1", initialize a set "N2(y)" to > include any interfaces in "N2" that are 1-hop neighbors of "y". >=20 > 5. For each interface "x" in "N1" with a router priority value of > "ALWAYS" (or using the CF relay algorithm), select "x" as an = MPR: >=20 > A. Add "x" to the set "MPR" and remove "x" from "N1". >=20 > B. For each interface "z" in "N2(x)", remove "z" from "N2". >=20 > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". >=20 > 6. For each interface "z" in "N2", initialize the set "N1(z)" to > include any interfaces in "N1" that are 1-hop neighbors of "z". >=20 > 7. For each interface "x" in "N2" where "N1(x)" has only one = member, > select "x" as an MPR: >=20 > A. Add "x" to the set "MPR" and remove "x" from "N1". >=20 > B. For each interface "z" in "N2(x)", remove "z" from "N2" and > delete "N1(z)". >=20 > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". >=20 > 8. While "N2" is not empty, select the interface "x" in "N1" with > the largest router priority that has the number of members in > "N_2(x)" as an MPR: >=20 > A. Add "x" to the set "MPR" and remove "x" from "N1". >=20 > B. For each interface "z" in "N2(x)", remove "z" from "N2". >=20 > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". >=20 >=20 >=20 >=20 >=20 > Corrected Text > -------------- > 1. Initialize the set "MPR" to empty. >=20 > 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". >=20 > 3. Initialize the set "N2" to include all 2-hop neighbors, = excluding > "n0" and any routers in "N1". Nodes that are only reachable = via > "N1" routers with router priority values of NEVER are also > excluded. >=20 > 4. For each interface "y" in "N1", initialize a set "N2(y)" to > include any interfaces in "N2" that are 1-hop neighbors of "y". >=20 > 5. For each interface "x" in "N1" with a router priority value of > "ALWAYS" (or using the CF relay algorithm), select "x" as an = MPR: >=20 > A. Add "x" to the set "MPR" and remove "x" from "N1". >=20 > B. For each interface "z" in "N2(x)", remove "z" from "N2". >=20 > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". >=20 > 6. For each interface "z" in "N2", initialize the set "N1(z)" to > include any interfaces in "N1" that are 1-hop neighbors of "z". >=20 > 7. For each interface "w" in "N2" where "N1(w)" has only one = member, "x", > select "x" as an MPR: >=20 > A. Add "x" to the set "MPR" and remove "x" from "N1". >=20 > B. For each interface "z" in "N2(x)", remove "z" from "N2". >=20 > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". >=20 > 8. While "N2" is not empty, select the interface "x" in "N1" with > the highest router priority [break ties in favor of the node = with the > largest number of members in "N_2(x)"] as an MPR: >=20 > A. Add "x" to the set "MPR" and remove "x" from "N1". >=20 > B. For each interface "z" in "N2(x)", remove "z" from "N2". >=20 > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". >=20 >=20 >=20 >=20 >=20 > Notes > ----- > There are three changes: >=20 > On line 7, the first and second occurrences of x are replaced by w, = and then x is given as the name of the sole member of N1(w). >=20 > On line 7B, the phrase 'delete "N1(z)" is dropped to be consistent = with the rest of the algorithm. >=20 > On line 8 some rewording is done for clarification. >=20 > This errata prepared in consultation with Justin Dean and Gus Macker. >=20 > Instructions: > ------------- > This errata 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. >=20 > -------------------------------------- > RFC6621 (draft-ietf-manet-smf-14) > -------------------------------------- > Title : Simplified Multicast Forwarding > Publication Date : May 2012 > Author(s) : J. Macker, Ed. > Category : EXPERIMENTAL > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From abdussalambaryun@gmail.com Tue Feb 26 07:00:16 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5DD21F887F for ; Tue, 26 Feb 2013 07:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSGiy0tl1LQi for ; Tue, 26 Feb 2013 07:00:10 -0800 (PST) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3F721F887D for ; Tue, 26 Feb 2013 07:00:07 -0800 (PST) Received: by mail-da0-f46.google.com with SMTP id z8so831600dad.33 for ; Tue, 26 Feb 2013 07:00:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=itSSVnyqXIOUSeXaIAjJNzaPYFS7jXYx2YqHLnWPz4k=; b=DGUEpDzXUJolebY11VRhw1W+vBKXZ3Q8xXZbUp8lLQEvpZRCq+ekTI20i3KOcGnE0b 8WPuvkvw+O4X+sXxVIjIxQwv/aZyFWRrb+7KWWAePuZSAbc3heDkBM4c20rV+2cP6eMX ynCWUKlbOK3Du3L1nQ0ZNc1kzNIgDOj4VgFyhF1RbX278zbyhxRlk83eyksBhV3hNWzs NW24wndmQbjNaRlQMUqXgDCLYBXQ7/QRI0ArXVoiIlzPqZO6XipqD0dvLjEhquaL1JLT fpBcgHw2Mwd0WkYKn/O2kt315OxvJAlNmf0prT1EmaGGy1D9UKyATvLFoQyL+SYKg91L hjFg== MIME-Version: 1.0 X-Received: by 10.68.217.2 with SMTP id ou2mr24145673pbc.6.1361890807200; Tue, 26 Feb 2013 07:00:07 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 07:00:06 -0800 (PST) In-Reply-To: <512CC517.20404@fkie.fraunhofer.de> References: <20130225151705.EB129B1E008@rfc-editor.org> <512CC517.20404@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 15:00:06 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=e89a8ff2430bc9449804d6a1e91b Cc: manet@ietf.org Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:00:17 -0000 --e89a8ff2430bc9449804d6a1e91b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I like that protocols use the packet sequence number, if thoes protocols you refered to don't use the packet SQN, then I recommend they reconsider. I was always interested in the funkfeuer ETX" draft I even asked you to start it again but never seen your announcement of new draft, still waiting= , As you know, I may use WE or I when I discuss, you never know how many machines are with me while I am participating (on their behalf sometimes) from my room :-) AB On Tue, Feb 26, 2013 at 2:22 PM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > On 02/26/2013 03:09 PM, Abdussalam Baryun wrote: > >> Hi Chris, and All Does the changes in RFC5444 will affect other RFCs >> or protocols? we need to discuss this through, because many depend on >> RFC5444, >> > > and we did not understand the authors suggestions >> > > maybe you intended to write "I did not understand..." ? > > > > as they are the experts of the work, AB > > Allow me to quote myself from yesterday... > > On 02/25/2013 06:17 PM, Henning Rogge wrote: > >> I think you are trying to make an issue out of nothing. >> >> First, the errata is a SHOULD, which means that any proprietary >> protocol can do whatever it likes. >> >> Second, neither DYMO nor NHDP nor OLSRv2 nor DLEP (which was using >> RFC5444 for some time) uses packet sequence numbers. >> >> In fact the only draft I remember which used RFC5444 packet sequence >> numbers was the "funkfeuer ETX" draft, which explicitly specified >> that the packet sequence numbers had to be interface specific to use >> this ETX variant. >> > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --e89a8ff2430bc9449804d6a1e91b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I like that protocols use the packet sequence number, if thoes protoco= ls you refered to don't use the packet SQN, then I recommend they recon= sider. I was always interested in the funkfeuer ETX" draft I even aske= d you to start it again but never seen your announcement of new draft, stil= l waiting,
=A0
As you know, I may use WE or I when I discuss, you never= know how many machines are with me while I am participating (on their beha= lf sometimes)=A0from my room :-)
=A0
AB

On Tue, Feb 26, 2013 at 2:22 PM, Henning Rogge <henning.rog= ge@fkie.fraunhofer.de> wrote:
On 02/26/2013 03:09 PM, Abdussalam Baryun wrote:
Hi Chris, and All Does the changes in RFC5444 will affect other RFCs
or protocols? we need to discuss this through, because many depend on
RFC5444,

and we did not understand the authors suggestions

maybe you intended to write "I did not understand..." ?


> as they are the experts of the work, AB

Allow me to quote myself from yesterday...

On 02/25/2013 06:17 PM, Henning Rogge wrote:
I think you are trying to make an issue out of nothing.

First, the errata is a SHOULD, which means that any proprietary
protocol can do whatever it likes.

Second, neither DYMO nor NHDP nor OLSRv2 nor DLEP (which was using
RFC5444 for some time) uses packet sequence numbers.

In fact the only draft I remember which used RFC5444 packet sequence
numbers was the "funkfeuer ETX" draft, which explicitly specified=
that the packet sequence numbers had to be interface specific to use
this ETX variant.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


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


--e89a8ff2430bc9449804d6a1e91b-- From abdussalambaryun@gmail.com Tue Feb 26 07:05:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD6A21F89AE for ; Tue, 26 Feb 2013 07:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd72kQZv4cqG for ; Tue, 26 Feb 2013 07:05:06 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7500021F887D for ; Tue, 26 Feb 2013 07:05:06 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id bj3so2482220pad.34 for ; Tue, 26 Feb 2013 07:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hkuOqyfb0MchdM7ggi0OSs3En+i2keK0N9h1T8VFip0=; b=FcmcGzkPqtnrvPsumq9+jnrVGwaaODlowrFvR19bwHk+pIzb4N0Z/28bUFx2HWafg0 GnfIKxK8Z/wp/gH0AOZUoRpPjd4hufj53nC4+LJfh/BVXeOJSytyLtqCPEXrhiKqTNM1 yWIp4g/QRsJBTokXrm2luTk7hsvFRbk4kT/llFoxqB0ssJJeeS0hJDsTqJU6EjJ8ahzf jM5QXSH1ZDRfSlR6CJm4ZigjkPMFXJEfNVgXaRc9ZYqPN++Ut5PCT17tIASnpmRlV79j MHzGzn73kyWuBkkBgpHGapiHWIupHwhdO+wo5n+KIAgR+AXTKhg86hDVaxDzeTyqaVrx agRA== MIME-Version: 1.0 X-Received: by 10.66.234.132 with SMTP id ue4mr2114118pac.163.1361891106255; Tue, 26 Feb 2013 07:05:06 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 07:05:06 -0800 (PST) In-Reply-To: <91644B38-BBF7-465E-B355-56F9D3944967@nrl.navy.mil> References: <20130226132309.97678B1E006@rfc-editor.org> <91644B38-BBF7-465E-B355-56F9D3944967@nrl.navy.mil> Date: Tue, 26 Feb 2013 15:05:06 +0000 Message-ID: From: Abdussalam Baryun To: Joe Macker Content-Type: multipart/alternative; boundary=047d7b15a4a59c7fa004d6a1fbf6 Cc: elloyd@udel.edu, manet@ietf.org, RFC Errata System , sratliff@cisco.com, macker@itd.nrl.navy.mil Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:05:07 -0000 --047d7b15a4a59c7fa004d6a1fbf6 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, do you mean approaved as that there is no need to review and discuss this errata. Just wnat to be sure if chair approaved I will not go into checking further, Regards AB On Tue, Feb 26, 2013 at 2:28 PM, Joe Macker wrote: > Because it corrects an error in the MPR pseudocode appendix B. > We like and encourage errata. > > I have approved this and Justin Dean helped provide replacement text. > I wish to thank Errol and his team for providing this. > > Our prototype code tends to use Appendix A so this does not affect any > working prototype that I know of. > > -joe > > On Feb 26, 2013, at 9:15 AM, Abdussalam Baryun > wrote: > > > Hi Editors of RFC6621 or Errata reporter, > > > > Could you inform us why is this errata now posted, I need to discuss > with you to understand, > > > > AB > > > > On Tue, Feb 26, 2013 at 1:23 PM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > > > > The following errata report has been submitted for RFC6621, > > "Simplified Multicast Forwarding". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=6621&eid=3499 > > > > -------------------------------------- > > Type: Technical > > Reported by: Errol Lloyd > > > > Section: B.4. > > > > Original Text > > ------------- > > 1. Initialize the set "MPR" to empty. > > > > 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". > > > > 3. Initialize the set "N2" to include all 2-hop neighbors, excluding > > "n0" and any routers in "N1". Nodes that are only reachable via > > "N1" routers with router priority values of NEVER are also > > excluded. > > > > 4. For each interface "y" in "N1", initialize a set "N2(y)" to > > include any interfaces in "N2" that are 1-hop neighbors of "y". > > > > 5. For each interface "x" in "N1" with a router priority value of > > "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > > > 6. For each interface "z" in "N2", initialize the set "N1(z)" to > > include any interfaces in "N1" that are 1-hop neighbors of "z". > > > > 7. For each interface "x" in "N2" where "N1(x)" has only one member, > > select "x" as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2" and > > delete "N1(z)". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > > > 8. While "N2" is not empty, select the interface "x" in "N1" with > > the largest router priority that has the number of members in > > "N_2(x)" as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > > > > > > > > > > > Corrected Text > > -------------- > > 1. Initialize the set "MPR" to empty. > > > > 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". > > > > 3. Initialize the set "N2" to include all 2-hop neighbors, excluding > > "n0" and any routers in "N1". Nodes that are only reachable via > > "N1" routers with router priority values of NEVER are also > > excluded. > > > > 4. For each interface "y" in "N1", initialize a set "N2(y)" to > > include any interfaces in "N2" that are 1-hop neighbors of "y". > > > > 5. For each interface "x" in "N1" with a router priority value of > > "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > > > 6. For each interface "z" in "N2", initialize the set "N1(z)" to > > include any interfaces in "N1" that are 1-hop neighbors of "z". > > > > 7. For each interface "w" in "N2" where "N1(w)" has only one member, > "x", > > select "x" as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > > > 8. While "N2" is not empty, select the interface "x" in "N1" with > > the highest router priority [break ties in favor of the node with > the > > largest number of members in "N_2(x)"] as an MPR: > > > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > > > C. For each interface "y" in "N1", remove any interfaces in > > "N2(x)" from "N2(y)". > > > > > > > > > > > > Notes > > ----- > > There are three changes: > > > > On line 7, the first and second occurrences of x are replaced by w, and > then x is given as the name of the sole member of N1(w). > > > > On line 7B, the phrase 'delete "N1(z)" is dropped to be consistent with > the rest of the algorithm. > > > > On line 8 some rewording is done for clarification. > > > > This errata prepared in consultation with Justin Dean and Gus Macker. > > > > Instructions: > > ------------- > > This errata 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. > > > > -------------------------------------- > > RFC6621 (draft-ietf-manet-smf-14) > > -------------------------------------- > > Title : Simplified Multicast Forwarding > > Publication Date : May 2012 > > Author(s) : J. Macker, Ed. > > Category : EXPERIMENTAL > > Source : Mobile Ad-hoc Networks > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > --047d7b15a4a59c7fa004d6a1fbf6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joe,
=A0
do you mean approaved as that there is= no need to review and discuss this errata. Just wnat to be sure if chair a= pproaved I will not go into checking further,
=A0
Regar= ds
=A0
AB

On Tue, Feb 2= 6, 2013 at 2:28 PM, Joe Macker <joseph.macker@nrl.navy.mil>= ; wrote:
Because it corrects an error in the MPR pseudocode appendi= x B.
We like and encourage errata.

I have approved this and Justin Dean helped provide replacement text.
I wish to thank Errol and his team for providing this.

Our prototype code tends to use Appendix A so this does not affect any work= ing prototype that I know of.

-joe

On Feb 26, 2013, at 9:15 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

> Hi Editors of RFC6621 or Errata reporter,
>
> Could you inform us why is this errata now posted, I need to discuss w= ith you to understand,
>
> AB
>
> On Tue, Feb 26, 2013 at 1:23 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC6621,
> "Simplified Multicast Forwarding".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?r= fc=3D6621&eid=3D3499
>
> --------------------------------------
> Type: Technical
> Reported by: Errol Lloyd <elloyd= @udel.edu>
>
> Section: B.4.
>
> Original Text
> -------------
> =A0 1. =A0Initialize the set "MPR" to empty.
>
> =A0 =A02. =A0Initialize the set "N1" to include all 1-hop ne= ighbors of "n0".
>
> =A0 =A03. =A0Initialize the set "N2" to include all 2-hop ne= ighbors, excluding
> =A0 =A0 =A0 =A0"n0" and any routers in "N1". =A0No= des that are only reachable via
> =A0 =A0 =A0 =A0"N1" routers with router priority values of N= EVER are also
> =A0 =A0 =A0 =A0excluded.
>
> =A0 =A04. =A0For each interface "y" in "N1", initi= alize a set "N2(y)" to
> =A0 =A0 =A0 =A0include any interfaces in "N2" that are 1-hop= neighbors of "y".
>
> =A0 =A05. =A0For each interface "x" in "N1" with a= router priority value of
> =A0 =A0 =A0 =A0"ALWAYS" (or using the CF relay algorithm), s= elect "x" as an MPR:
>
> =A0 =A0 =A0 =A0A. =A0Add "x" to the set "MPR" and = remove "x" from "N1".
>
> =A0 =A0 =A0 =A0B. =A0For each interface "z" in "N2(x)&q= uot;, remove "z" from "N2".
>
> =A0 =A0 =A0 =A0C. =A0For each interface "y" in "N1"= ;, remove any interfaces in
> =A0 =A0 =A0 =A0 =A0 =A0"N2(x)" from "N2(y)".
>
> =A0 =A06. =A0For each interface "z" in "N2", initi= alize the set "N1(z)" to
> =A0 =A0 =A0 =A0include any interfaces in "N1" that are 1-hop= neighbors of "z".
>
> =A0 =A07. =A0For each interface "x" in "N2" where = "N1(x)" has only one member,
> =A0 =A0 =A0 =A0select "x" as an MPR:
>
> =A0 =A0 =A0 =A0A. =A0Add "x" to the set "MPR" and = remove "x" from "N1".
>
> =A0 =A0 =A0 =A0B. =A0For each interface "z" in "N2(x)&q= uot;, remove "z" from "N2" and
> =A0 =A0 =A0 =A0 =A0 =A0delete "N1(z)".
>
> =A0 =A0 =A0 =A0C. =A0For each interface "y" in "N1"= ;, remove any interfaces in
> =A0 =A0 =A0 =A0 =A0 =A0"N2(x)" from "N2(y)".
>
> =A0 =A08. =A0While "N2" is not empty, select the interface &= quot;x" in "N1" with
> =A0 =A0 =A0 =A0the largest router priority that has the number of memb= ers in
> =A0 =A0 =A0 =A0"N_2(x)" as an MPR:
>
> =A0 =A0 =A0 =A0A. =A0Add "x" to the set "MPR" and = remove "x" from "N1".
>
> =A0 =A0 =A0 =A0B. =A0For each interface "z" in "N2(x)&q= uot;, remove "z" from "N2".
>
> =A0 =A0 =A0 =A0C. =A0For each interface "y" in "N1"= ;, remove any interfaces in
> =A0 =A0 =A0 =A0 =A0 =A0"N2(x)" from "N2(y)".
>
>
>
>
>
> Corrected Text
> --------------
> =A0 1. =A0Initialize the set "MPR" to empty.
>
> =A0 =A02. =A0Initialize the set "N1" to include all 1-hop ne= ighbors of "n0".
>
> =A0 =A03. =A0Initialize the set "N2" to include all 2-hop ne= ighbors, excluding
> =A0 =A0 =A0 =A0"n0" and any routers in "N1". =A0No= des that are only reachable via
> =A0 =A0 =A0 =A0"N1" routers with router priority values of N= EVER are also
> =A0 =A0 =A0 =A0excluded.
>
> =A0 =A04. =A0For each interface "y" in "N1", initi= alize a set "N2(y)" to
> =A0 =A0 =A0 =A0include any interfaces in "N2" that are 1-hop= neighbors of "y".
>
> =A0 =A05. =A0For each interface "x" in "N1" with a= router priority value of
> =A0 =A0 =A0 =A0"ALWAYS" (or using the CF relay algorithm), s= elect "x" as an MPR:
>
> =A0 =A0 =A0 =A0A. =A0Add "x" to the set "MPR" and = remove "x" from "N1".
>
> =A0 =A0 =A0 =A0B. =A0For each interface "z" in "N2(x)&q= uot;, remove "z" from "N2".
>
> =A0 =A0 =A0 =A0C. =A0For each interface "y" in "N1"= ;, remove any interfaces in
> =A0 =A0 =A0 =A0 =A0 =A0"N2(x)" from "N2(y)".
>
> =A0 =A06. =A0For each interface "z" in "N2", initi= alize the set "N1(z)" to
> =A0 =A0 =A0 =A0include any interfaces in "N1" that are 1-hop= neighbors of "z".
>
> =A0 =A07. =A0For each interface "w" in "N2" where = "N1(w)" has only one member, "x",
> =A0 =A0 =A0 =A0select "x" as an MPR:
>
> =A0 =A0 =A0 =A0A. =A0Add "x" to the set "MPR" and = remove "x" from "N1".
>
> =A0 =A0 =A0 =A0B. =A0For each interface "z" in "N2(x)&q= uot;, remove "z" from "N2".
>
> =A0 =A0 =A0 =A0C. =A0For each interface "y" in "N1"= ;, remove any interfaces in
> =A0 =A0 =A0 =A0 =A0 =A0"N2(x)" from "N2(y)".
>
> =A0 =A08. =A0While "N2" is not empty, select the interface &= quot;x" in "N1" with
> =A0 =A0 =A0 =A0the highest router priority [break ties in favor of the= node with the
> =A0 =A0 =A0 =A0largest number of members in "N_2(x)"] as an = MPR:
>
> =A0 =A0 =A0 =A0A. =A0Add "x" to the set "MPR" and = remove "x" from "N1".
>
> =A0 =A0 =A0 =A0B. =A0For each interface "z" in "N2(x)&q= uot;, remove "z" from "N2".
>
> =A0 =A0 =A0 =A0C. =A0For each interface "y" in "N1"= ;, remove any interfaces in
> =A0 =A0 =A0 =A0 =A0 =A0"N2(x)" from "N2(y)".
>
>
>
>
>
> Notes
> -----
> There are three changes:
>
> On line 7, the first and second occurrences of x are replaced by w, an= d then x is given as the name of the sole member of N1(w).
>
> On line 7B, the phrase 'delete "N1(z)" is dropped to be = consistent with the rest of the algorithm.
>
> On line 8 some rewording is done for clarification.
>
> This errata prepared in consultation with Justin Dean and Gus Macker.<= br> >
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,= please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6621 (draft-ietf-manet-smf-14)
> --------------------------------------
> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Simplified Multicast Forwarding > Publication Date =A0 =A0: May 2012
> Author(s) =A0 =A0 =A0 =A0 =A0 : J. Macker, Ed.
> Category =A0 =A0 =A0 =A0 =A0 =A0: EXPERIMENTAL
> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Mobile Ad-hoc Networks
> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
> Verifying Party =A0 =A0 : IESG
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>


--047d7b15a4a59c7fa004d6a1fbf6-- From thomas@thomasclausen.org Tue Feb 26 07:13:16 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DAC21F86B8 for ; Tue, 26 Feb 2013 07:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUKF0DE1RHqh for ; Tue, 26 Feb 2013 07:13:15 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id C973321F86C3 for ; Tue, 26 Feb 2013 07:13:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id BD8031BD708F; Tue, 26 Feb 2013 07:13:15 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7E2731BD7083; Tue, 26 Feb 2013 07:13:14 -0800 (PST) References: <20130225151705.EB129B1E008@rfc-editor.org> <512CC517.20404@fkie.fraunhofer.de> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-5CBFE5A0-BE38-434C-A77F-26BE8E2888E6 Content-Transfer-Encoding: 7bit Message-Id: <413400E5-1352-4437-9E07-C47875875665@thomasclausen.org> X-Mailer: iPad Mail (10B141) From: Thomas Heide Clausen Date: Tue, 26 Feb 2013 16:13:12 +0100 To: Abdussalam Baryun Cc: "manet@ietf.org" Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:13:16 -0000 --Apple-Mail-5CBFE5A0-BE38-434C-A77F-26BE8E2888E6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 26 f=C3=A9vr. 2013, at 16:00, Abdussalam Baryun wrote: > I like that protocols use the packet sequence number, if thoes protocols y= ou refered to don't use the packet SQN, then I recommend they reconsider. Why? "Like" is not a technical argument. Thomas > I was always interested in the funkfeuer ETX" draft I even asked you to st= art it again but never seen your announcement of new draft, still waiting, > =20 > As you know, I may use WE or I when I discuss, you never know how many mac= hines are with me while I am participating (on their behalf sometimes) from m= y room :-) > =20 > AB >=20 > On Tue, Feb 26, 2013 at 2:22 PM, Henning Rogge wrote: >> On 02/26/2013 03:09 PM, Abdussalam Baryun wrote: >>> Hi Chris, and All Does the changes in RFC5444 will affect other RFCs >>> or protocols? we need to discuss this through, because many depend on >>> RFC5444, >>=20 >>> and we did not understand the authors suggestions >>=20 >> maybe you intended to write "I did not understand..." ? >>=20 >>=20 >> > as they are the experts of the work, AB >>=20 >> Allow me to quote myself from yesterday... >>=20 >> On 02/25/2013 06:17 PM, Henning Rogge wrote: >>> I think you are trying to make an issue out of nothing. >>>=20 >>> First, the errata is a SHOULD, which means that any proprietary >>> protocol can do whatever it likes. >>>=20 >>> Second, neither DYMO nor NHDP nor OLSRv2 nor DLEP (which was using >>> RFC5444 for some time) uses packet sequence numbers. >>>=20 >>> In fact the only draft I remember which used RFC5444 packet sequence >>> numbers was the "funkfeuer ETX" draft, which explicitly specified >>> that the packet sequence numbers had to be interface specific to use >>> this ETX variant. >>=20 >> Henning Rogge >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-5CBFE5A0-BE38-434C-A77F-26BE8E2888E6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 26 f=C3=A9vr. 2013, a= t 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I like that protocols use the packet sequence number, if tho= es protocols you refered to don't use the packet SQN, then I recommend they r= econsider.

Why?

"Like" is not a technical argument.

Thomas=

I was always inter= ested in the funkfeuer ETX" draft I even asked you to start it again but nev= er seen your announcement of new draft, still waiting,
 
As you know, I may use WE or I when I discuss, you nev= er know how many machines are with me while I am participating (on their beh= alf sometimes) from my room :-)
 
AB

On Tue, Feb 26, 2013 at 2:22 PM, Henning Rogge <henning.rogge= @fkie.fraunhofer.de> wrote:
On 02/26/2013 03:09 PM, Abdussalam Baryun wrote:
Hi Chris, and All Does the changes in RFC5444 will affect other RFCs
or protocols? we need to discuss this through, because many depend on
RFC5444,

and we did not understand the authors suggestions

maybe you intended to write "I did not understand..." ?

> as they are the experts of the work, AB

Allow me to quote myself from yesterday...

On 02/25/2013 06:17 PM, Henning Rogge wrote:
I think you are trying to make an issue out of nothing.

First, the errata is a SHOULD, which means that any proprietary
protocol can do whatever it likes.

Second, neither DYMO nor NHDP nor OLSRv2 nor DLEP (which was using
RFC5444 for some time) uses packet sequence numbers.

In fact the only draft I remember which used RFC5444 packet sequence
numbers was the "funkfeuer ETX" draft, which explicitly specified
that the packet sequence numbers had to be interface specific to use
this ETX variant.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


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


____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-5CBFE5A0-BE38-434C-A77F-26BE8E2888E6-- From Chris.Dearlove@baesystems.com Tue Feb 26 07:20:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA9B21F88A9 for ; Tue, 26 Feb 2013 07:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LS2S+HRalNYP for ; Tue, 26 Feb 2013 07:20:23 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 1762321F8759 for ; Tue, 26 Feb 2013 07:20:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; d="scan'208,217";a="314924620" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Feb 2013 15:20:10 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r1QFK9Yn029275 for ; Tue, 26 Feb 2013 15:20:09 GMT X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; d="scan'208,217";a="9070356" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 26 Feb 2013 15:20:09 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 15:20:09 +0000 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , manet Thread-Topic: [manet] [Technical Errata Reported] RFC5444 (3496) Thread-Index: AQHOE2tYWHRmgACwIkuCTgQkaOcmyZiMLwoAgAARJgA= Date: Tue, 26 Feb 2013 15:20:09 +0000 Message-ID: References: <20130225151705.EB129B1E008@rfc-editor.org> 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D2502674FGLKXM0002VGREEN_" MIME-Version: 1.0 Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:20:24 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D2502674FGLKXM0002VGREEN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If you can find someone who chose to implement something on a router with multiple interfaces, who used packet sequence numbers, relied on them being sequential in order to track missing packets, used the false indication missing packets in a significant way, implemented the packet sequence numbers as suggested (but not mandated) in RFC 5444 without either thinking through the consequences or noticing that this was different to the prior art of RFC 3626, had a problem as a result, but didn't even mention any of this here, then yes, that person had a problem. Otherwise, i.e. in reality, no. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: 26 February 2013 14:10 To: manet Cc: Dearlove, Christopher (UK) Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. Hi Chris, and All Does the changes in RFC5444 will affect other RFCs or protocols? we need to discuss this through, because many depend on RFC5444, and we did not understand the authors suggestions as they are the experts of the work, AB On Mon, Feb 25, 2013 at 3:17 PM, RFC Errata System > wrote: The following errata report has been submitted for RFC5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=3496 -------------------------------------- Type: Technical Reported by: Christopher Dearlove > Section: Appendix A Original Text ------------- o The field, if present, contains a sequence number that is incremented by 1 for each packet generated by a node. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way. Corrected Text -------------- o The field, if present, contains a sequence number that SHOULD be maintained for each participating interface and incremented by 1 for each packet generated by a node for that interface. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way. Notes ----- Packet sequence number should be per interface, not per node. Uses that recognise missing packet sequence numbers only work in the corrected (intended) case. Instructions: ------------- This errata 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. -------------------------------------- RFC5444 (draft-ietf-manet-packetbb-17) -------------------------------------- Title : Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format Publication Date : February 2009 Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG _______________________________________________ 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. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D2502674FGLKXM0002VGREEN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

If you can find someone who chose to implement something on a router with multiple interfaces, who used packet sequence numbers, relied on them being sequential in order to track missing packets,  used the false indication missing packets in a significant way, implemented the packet sequence numbers as suggested (but not mandated) in RFC 5444 without either thinking through the consequences or noticing that this was different to the prior art of RFC 3626, had a problem as a result, but didn't even mention any of this here, then yes, that person had a problem.

 

Otherwise, i.e. in reality, no.

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 14:10
To: manet
Cc: Dearlove, Christopher (UK)
Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Hi Chris, and All

 

Does the changes in RFC5444 will affect other RFCs or protocols? we need to discuss this through, because many depend on RFC5444, and we did not understand the authors suggestions as they are the experts of the work,

 

AB

On Mon, Feb 25, 2013 at 3:17 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:


The following errata report has been submitted for RFC5444,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=3496

--------------------------------------
Type: Technical
Reported by: Christopher Dearlove <chris.dearlove@baesystems.com>

Section: Appendix A

Original Text
-------------
   o  The <pkt-seq-num> field, if present, contains a sequence number
      that is incremented by 1 for each packet generated by a node.  The
      sequence number after 65535 is 0.  In other words, the sequence
      number "wraps" in the usual way.


Corrected Text
--------------
   o  The <pkt-seq-num> field, if present, contains a sequence number
      that SHOULD be maintained for each participating interface and
      incremented by 1 for each packet generated by a node for that
      interface.  The sequence number after 65535 is 0.  In other words,
      the sequence number "wraps" in the usual way.


Notes
-----
Packet sequence number should be per interface, not per node. Uses that recognise missing packet sequence numbers only work in the corrected (intended) case.

Instructions:
-------------
This errata 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.

--------------------------------------
RFC5444 (draft-ietf-manet-packetbb-17)
--------------------------------------
Title               : Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format
Publication Date    : February 2009
Author(s)           : T. Clausen, C. Dearlove, J. Dean, C. Adjih
Category            : PROPOSED STANDARD
Source              : Mobile Ad-hoc Networks
Area                : Routing
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
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.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D2502674FGLKXM0002VGREEN_-- From bebemaster@gmail.com Tue Feb 26 07:21:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29BF21F88AC for ; Tue, 26 Feb 2013 07:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWnMHVcxkcTa for ; Tue, 26 Feb 2013 07:21:11 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C447A21F8759 for ; Tue, 26 Feb 2013 07:21:10 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id ek20so3948544lab.2 for ; Tue, 26 Feb 2013 07:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yd87jKEyi6N+zfaLcGz4H6jNr3Ok21zJHdYh5ueV36M=; b=Ue+NXw6qIEPQaEsc53cHRBMb+sV60FZ0zTEqPuZTg2swEoC8sWVg9ls9BJY85fKyGj JnFFo3tneGveZcddMvP9NcNPZY0lrCIGGiB4iud1gqJ8rdLnoLYs3Znu7LKD1G2ev5DG JLzf3jP5EYYuUeDhobz3eAnhQvjHhK1fim/jSzIzlNVzClXm30ipqJCGyPbGy9tGbHxN ekAC5AP1OorqQq+Y9hAIaNHCEox+LN71TO9BtXoZeCDqB0qGljBNLMN2W+sB/685rLN6 7f6/QeUKwnLFcCB2OZqrli/ZTSFIbgPU8UYxfKqzAa/1GD1cxPhaJKEsRkYrvrrE2XvF VK8Q== MIME-Version: 1.0 X-Received: by 10.112.30.198 with SMTP id u6mr755767lbh.9.1361892069516; Tue, 26 Feb 2013 07:21:09 -0800 (PST) Received: by 10.152.132.162 with HTTP; Tue, 26 Feb 2013 07:21:09 -0800 (PST) In-Reply-To: <20130226132309.97678B1E006@rfc-editor.org> References: <20130226132309.97678B1E006@rfc-editor.org> Date: Tue, 26 Feb 2013 10:21:09 -0500 Message-ID: From: Justin Dean To: RFC Errata System Content-Type: multipart/alternative; boundary=f46d04016b2106b0b904d6a23541 Cc: elloyd@udel.edu, manet@ietf.org, sratliff@cisco.com, macker@itd.nrl.navy.mil Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:21:11 -0000 --f46d04016b2106b0b904d6a23541 Content-Type: text/plain; charset=ISO-8859-1 Thank you for finding and posting the errata. The errata fixes an error and I approve of the change. I would like to encourage others to look over the psuedo code and verify the correctness of the fix and correctness in general. Lets measure twice and cut once. Justin Notes > ----- > There are three changes: > > On line 7, the first and second occurrences of x are replaced by w, and > then x is given as the name of the sole member of N1(w). > > On line 7B, the phrase 'delete "N1(z)" is dropped to be consistent with > the rest of the algorithm. > > On line 8 some rewording is done for clarification. > > This errata prepared in consultation with Justin Dean and Gus Macker. > > Instructions: > ------------- > This errata 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. > > -------------------------------------- > RFC6621 (draft-ietf-manet-smf-14) > -------------------------------------- > Title : Simplified Multicast Forwarding > Publication Date : May 2012 > Author(s) : J. Macker, Ed. > Category : EXPERIMENTAL > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --f46d04016b2106b0b904d6a23541 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you for finding and posting the errata.=A0 The errata fixes an error = and I approve of the change.=A0 I would like to encourage others to look ov= er the psuedo code and verify the correctness of the fix and correctness in= general. Lets measure twice and cut once.

Justin

Notes
-----
There are three changes:

On line 7, the first and second occurrences of x are replaced by w, and the= n x is given as the name of the sole member of N1(w).

On line 7B, the phrase 'delete "N1(z)" is dropped to be consi= stent with the rest of the algorithm.

On line 8 some rewording is done for clarification.

This errata prepared in consultation with Justin Dean and Gus Macker.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
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.

--------------------------------------
RFC6621 (draft-ietf-manet-smf-14)
--------------------------------------
Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Simplified Multicast Forwarding
Publication Date =A0 =A0: May 2012
Author(s) =A0 =A0 =A0 =A0 =A0 : J. Macker, Ed.
Category =A0 =A0 =A0 =A0 =A0 =A0: EXPERIMENTAL
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Mobile Ad-hoc Networks
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--f46d04016b2106b0b904d6a23541-- From Chris.Dearlove@baesystems.com Tue Feb 26 07:35:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C3121F8840 for ; Tue, 26 Feb 2013 07:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghkx84dWipUX for ; Tue, 26 Feb 2013 07:35:56 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 752CC21F882D for ; Tue, 26 Feb 2013 07:35:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="314931215" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Feb 2013 15:35:51 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r1QFZpdp018758 for ; Tue, 26 Feb 2013 15:35:51 GMT X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="9073336" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 26 Feb 2013 15:35:50 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 15:35:50 +0000 From: "Dearlove, Christopher (UK)" To: Thomas Clausen , Henning Rogge Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt Thread-Index: AQHOFBnzQcK/1dKC6UukRyjp9E9HrJiMDrMAgAAzSfA= Date: Tue, 26 Feb 2013 15:35:50 +0000 Message-ID: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> <512CA5A D.4030800@fkie.fraunhofer.de> 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 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:35:57 -0000 An attacker can spoof packets appearing to be from a router that skips some= packet sequence numbers since the last packet sent by the router (and rece= ived and analysed by the attacker). This may have an effect on an implementation of NHDP that uses those packet= sequence numbers to recognise missing packets, and thus to change link qua= lity. (There's no required use of the packet sequence number, and I'm fairl= y sure no other even suggested possible use.) This is an implementation of link quality that frankly isn't very good. Tha= t's why in the translation from RFC 3626, where this is a formal option, to= NHDP, it got downgraded to a comment that it's something you can use in sp= ecifying link quality should you want to. Now against an unprotected NHDP, even one using that mechanism, there are a= lot of much more effective attacks that require less effort to mount, usin= g HELLO messages. So about the only case where this attack is worth mounting is when you know= that the NHDP implementation has gone to the trouble of protecting message= s, but is using a 5444 implementation that doesn't protect packets, and you= know that it uses this packet sequence number in the way described, despit= e having gone to the effort of protecting messages. Or in other words it's a smart but stupid NHDP implementer. (He made two mi= stakes, using a poor link quality mechanism, and using something unprotecte= d despite the work in protecting most things.) So it's rather specialised. And even in those circumstances I might (as the= attacker) spend my effort on something else. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= homas Clausen Sent: 26 February 2013 12:19 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Feb 26, 2013, at 1:08 PM, Henning Rogge wrote: > Hi, >=20 > so do we have an agreement that the old "sequence number attack" section = of nhdp-threats-00 is wrong and must be removed because it describes someth= ing that does not apply to NHDP? >=20 > If we (as a working group) decide we want a "sequence number attack" sect= ion in nhdp-threats, someone needs to write up a corresponding section and = we have to see if it gets consensus in the group. >=20 I believe that if there is a sequence number attack on NHDP, then it should= be written down. I also believe that I've not seen anything indicating that such an attack e= xists. That's what you're saying, isn't it? > Henning Rogge >=20 > On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: >> your right thanks :) >> AB >>=20 >> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge >> > > wrote: >>=20 >> On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: >>=20 >> I can only repeat it again: NHDP does *not* use sequence >> numbers, >> neither packet nor message sequence numbers. >>=20 >> That is your opinion which I disagree, and disagree that the edit= ors >> removed the section of sequence number without consensus of WG. >>=20 >>=20 >> You know that the old section was plain WRONG, yes? >>=20 >> (I suggest reading section 4.5 of nhdp-threats-00) >>=20 >> Because the attack it described cannot happen to NHDP. >>=20 >> If you want to get the "sequence number attack" paragraph back, >> maybe you should write a new one... one that applies to NHDP. >>=20 >>=20 >> Henning Rogge >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961 , Fax +49 228 >> 9435 685 >> mailto:henning.rogge@fkie.__fraunhofer.de >> http://www.fkie.fraunhofer.= de >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >=20 >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** 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 thomas@thomasclausen.org Tue Feb 26 07:40:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C8721F8795 for ; Tue, 26 Feb 2013 07:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I53YvLN4FVCl for ; Tue, 26 Feb 2013 07:40:24 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id BCFBA21F8788 for ; Tue, 26 Feb 2013 07:40:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 38F831C0B15; Tue, 26 Feb 2013 07:40:24 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 785681C03D9; Tue, 26 Feb 2013 07:40:19 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Clausen In-Reply-To: Date: Tue, 26 Feb 2013 16:40:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> <512CA5A D.4030800@fkie.fraunhofer.de> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:40:25 -0000 ....and that description of Chris' might be something worth folding into = the I-D? Thomas On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" = wrote: > An attacker can spoof packets appearing to be from a router that skips = some packet sequence numbers since the last packet sent by the router = (and received and analysed by the attacker). >=20 > This may have an effect on an implementation of NHDP that uses those = packet sequence numbers to recognise missing packets, and thus to change = link quality. (There's no required use of the packet sequence number, = and I'm fairly sure no other even suggested possible use.) >=20 > This is an implementation of link quality that frankly isn't very = good. That's why in the translation from RFC 3626, where this is a = formal option, to NHDP, it got downgraded to a comment that it's = something you can use in specifying link quality should you want to. >=20 > Now against an unprotected NHDP, even one using that mechanism, there = are a lot of much more effective attacks that require less effort to = mount, using HELLO messages. >=20 > So about the only case where this attack is worth mounting is when you = know that the NHDP implementation has gone to the trouble of protecting = messages, but is using a 5444 implementation that doesn't protect = packets, and you know that it uses this packet sequence number in the = way described, despite having gone to the effort of protecting messages. >=20 > Or in other words it's a smart but stupid NHDP implementer. (He made = two mistakes, using a poor link quality mechanism, and using something = unprotected despite the work in protecting most things.) >=20 > So it's rather specialised. And even in those circumstances I might = (as the attacker) spend my effort on something else. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Thomas Clausen > Sent: 26 February 2013 12:19 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] I-D Action: = draft-ietf-manet-nhdp-sec-threats-01.txt >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > On Feb 26, 2013, at 1:08 PM, Henning Rogge = wrote: >=20 >> Hi, >>=20 >> so do we have an agreement that the old "sequence number attack" = section of nhdp-threats-00 is wrong and must be removed because it = describes something that does not apply to NHDP? >>=20 >> If we (as a working group) decide we want a "sequence number attack" = section in nhdp-threats, someone needs to write up a corresponding = section and we have to see if it gets consensus in the group. >>=20 >=20 > I believe that if there is a sequence number attack on NHDP, then it = should be written down. > I also believe that I've not seen anything indicating that such an = attack exists. >=20 > That's what you're saying, isn't it? >=20 >> Henning Rogge >>=20 >> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: >>> your right thanks :) >>> AB >>>=20 >>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge >>> >> > wrote: >>>=20 >>> On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: >>>=20 >>> I can only repeat it again: NHDP does *not* use sequence >>> numbers, >>> neither packet nor message sequence numbers. >>>=20 >>> That is your opinion which I disagree, and disagree that the = editors >>> removed the section of sequence number without consensus of = WG. >>>=20 >>>=20 >>> You know that the old section was plain WRONG, yes? >>>=20 >>> (I suggest reading section 4.5 of nhdp-threats-00) >>>=20 >>> Because the attack it described cannot happen to NHDP. >>>=20 >>> If you want to get the "sequence number attack" paragraph back, >>> maybe you should write a new one... one that applies to NHDP. >>>=20 >>>=20 >>> Henning Rogge >>>=20 >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961 , Fax +49 = 228 >>> 9435 685 >>> mailto:henning.rogge@fkie.__fraunhofer.de >>> = http://www.fkie.fraunhofer.de >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>=20 >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 From Chris.Dearlove@baesystems.com Tue Feb 26 07:42:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38FB21F884C for ; Tue, 26 Feb 2013 07:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s+rOUvpVniU for ; Tue, 26 Feb 2013 07:42:03 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 56FE821F884B for ; Tue, 26 Feb 2013 07:42:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="267963068" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 26 Feb 2013 15:42:01 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r1QFg1Lm019575 for ; Tue, 26 Feb 2013 15:42:01 GMT X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="8841729" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 26 Feb 2013 15:42:00 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 15:42:00 +0000 From: "Dearlove, Christopher (UK)" To: "adrian@olddog.co.uk" , "'Thomas Heide Clausen'" Thread-Topic: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt Thread-Index: AQHOEPEBLVutv5XCKUOytW0Gg1fZg5iH2YcAgARynWA= Date: Tue, 26 Feb 2013 15:42:00 +0000 Message-ID: References: <20130222112847.22275.38109.idtracker@ietfa.amsl.com> <206AD221-FBA1-4554-B17B-4E191C39BE6E@thomasclausen.org> <021601ce11fd$b69e7880$23db6980$@olddog.co.uk> In-Reply-To: <021601ce11fd$b69e7880$23db6980$@olddog.co.uk> 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 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'manet List' , "draft-ietf-manet-olsrv2-metrics-rationale.all@tools.ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:42:03 -0000 We had intended to put in a comment that if you want a node metric, add it = to incoming link metrics. I think from the author team I dropped the ball o= n that one. I'm not sure if there's anything to say on security. It wasn't part of this= rationale. Any OLSRv2 threats document could consider link metrics. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= drian Farrel Sent: 23 February 2013 19:41 To: 'Thomas Heide Clausen' Cc: draft-ietf-manet-olsrv2-metrics-rationale.all@tools.ietf.org; 'manet Li= st' Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-= 02.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Thomas, Thanks for the update. I've been through the diff and (as noted by some others) the changes look reasonable. >From my original review there were a couple of points where you didn't make changes, and didn't make any comments to me or on the list. This is not a b= ig deal (as my comments were largely for discussion), but for cleanliness, I'l= l make some statements on the list here, and you can disagree or let them sta= nd: --- > I wonder whether you want to make any comments about node > metrics. Obviously, you don't have them (neighbor metrics being > a different thing), but you could comment on why you don't have=20 > them (if this was ever discussed). > > The question is slightly touched on in 5.2 in discussion of "delay". The issue was never discussed as an idea for inclusion in OLSRv2, and while= node metrics could be added in the future, there was no suggestion that there is= a requirement. Thus, there is no reason to add any notes on node metrics to = this document. --- > Section 8 > > Were there any security considerations that cropped up while > designing metric support in OSLRv2? If so, here would be the > place to mention them. Security issues arising from the inclusion of metrics in OLSRv2 did not get= any specific discussion. Since OLSRv2 has its own security considerations to co= ver the whole protocol, there is nothing further to say in this document. --- If you have any responses to these points that need to be addressed in the = text, we can handle it in IETF last call which I will start with no further (well= , you know, real time and all that) delay. Cheers, Adrian > -----Original Message----- > From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] > Sent: 22 February 2013 11:37 > To: manet List > Cc: Adrian Farrel > Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt >=20 > Just a heads up. This review folds in a couple of suggestions that our AD= made > from his review. In summary, it amounts to a sentence in the abstract and= a > paragraph in the introduction explaining the motivation for publishing th= is > document, plus a couple of nits that he caught (thanks!). >=20 > Thank you, Adrian, for your review and assistance on this matter >=20 > For the authors, >=20 > Thomas >=20 > On Feb 22, 2013, at 12:28 , internet-drafts@ietf.org wrote: >=20 > > > > 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 o= f the > IETF. > > > > =09Title : Link Metrics for the Mobile Ad Hoc Network (MANET) Routing > Protocol OLSRv2 - Rationale > > =09Author(s) : Christopher Dearlove > > Thomas Heide Clausen > > Philippe Jacquet > > =09Filename : draft-ietf-manet-olsrv2-metrics-rationale-02.txt > > =09Pages : 29 > > =09Date : 2013-02-22 > > > > Abstract: > > OLSRv2 includes the ability to assign metrics to links and to use > > those metrics to allow routing by other than minimum hop count > > routes. This document provides a historic record of the rationale > > for, and design considerations behind, how link metrics were included > > in OLSRv2. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-ration= ale > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-metrics-rational= e-02 > > > > > > 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 _______________________________________________ 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 Chris.Dearlove@baesystems.com Tue Feb 26 07:47:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFFC21F8848 for ; Tue, 26 Feb 2013 07:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euNaEfmR7t-1 for ; Tue, 26 Feb 2013 07:47:10 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 35A7F21F8786 for ; Tue, 26 Feb 2013 07:47:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="314935378" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Feb 2013 15:47:09 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r1QFl9lJ001609 for ; Tue, 26 Feb 2013 15:47:09 GMT X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="9075273" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 26 Feb 2013 15:47:08 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 15:47:09 +0000 From: "Dearlove, Christopher (UK)" To: "adrian@olddog.co.uk" , "'Thomas Heide Clausen'" Thread-Topic: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt Thread-Index: AQHOFDfY07Urwk7dQEKcbtf4epXkSZiMR5lA Date: Tue, 26 Feb 2013 15:47:08 +0000 Message-ID: References: <20130222112847.22275.38109.idtracker@ietfa.amsl.com> <206AD221-FBA1-4554-B17B-4E191C39BE6E@thomasclausen.org> <021601ce11fd$b69e7880$23db6980$@olddog.co.uk> 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-manet-olsrv2-metrics-rationale.all@tools.ietf.org" , 'manet List' Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:47:12 -0000 I omitted to say, that we will treat the node metrics as an IETF LC commen= t. Or at least that's the plan. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of D= earlove, Christopher (UK) Sent: 26 February 2013 15:42 To: adrian@olddog.co.uk; 'Thomas Heide Clausen' Cc: 'manet List'; draft-ietf-manet-olsrv2-metrics-rationale.all@tools.ietf.= org Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-= 02.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- We had intended to put in a comment that if you want a node metric, add it = to incoming link metrics. I think from the author team I dropped the ball o= n that one. I'm not sure if there's anything to say on security. It wasn't part of this= rationale. Any OLSRv2 threats document could consider link metrics. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= drian Farrel Sent: 23 February 2013 19:41 To: 'Thomas Heide Clausen' Cc: draft-ietf-manet-olsrv2-metrics-rationale.all@tools.ietf.org; 'manet Li= st' Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-= 02.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Thomas, Thanks for the update. I've been through the diff and (as noted by some others) the changes look reasonable. >From my original review there were a couple of points where you didn't make changes, and didn't make any comments to me or on the list. This is not a b= ig deal (as my comments were largely for discussion), but for cleanliness, I'l= l make some statements on the list here, and you can disagree or let them sta= nd: --- > I wonder whether you want to make any comments about node > metrics. Obviously, you don't have them (neighbor metrics being > a different thing), but you could comment on why you don't have=20 > them (if this was ever discussed). > > The question is slightly touched on in 5.2 in discussion of "delay". The issue was never discussed as an idea for inclusion in OLSRv2, and while= node metrics could be added in the future, there was no suggestion that there is= a requirement. Thus, there is no reason to add any notes on node metrics to = this document. --- > Section 8 > > Were there any security considerations that cropped up while > designing metric support in OSLRv2? If so, here would be the > place to mention them. Security issues arising from the inclusion of metrics in OLSRv2 did not get= any specific discussion. Since OLSRv2 has its own security considerations to co= ver the whole protocol, there is nothing further to say in this document. --- If you have any responses to these points that need to be addressed in the = text, we can handle it in IETF last call which I will start with no further (well= , you know, real time and all that) delay. Cheers, Adrian > -----Original Message----- > From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] > Sent: 22 February 2013 11:37 > To: manet List > Cc: Adrian Farrel > Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-02.txt >=20 > Just a heads up. This review folds in a couple of suggestions that our AD= made > from his review. In summary, it amounts to a sentence in the abstract and= a > paragraph in the introduction explaining the motivation for publishing th= is > document, plus a couple of nits that he caught (thanks!). >=20 > Thank you, Adrian, for your review and assistance on this matter >=20 > For the authors, >=20 > Thomas >=20 > On Feb 22, 2013, at 12:28 , internet-drafts@ietf.org wrote: >=20 > > > > 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 o= f the > IETF. > > > > Title : Link Metrics for the Mobile Ad Hoc Network (MANET) Routing > Protocol OLSRv2 - Rationale > > Author(s) : Christopher Dearlove > > Thomas Heide Clausen > > Philippe Jacquet > > Filename : draft-ietf-manet-olsrv2-metrics-rationale-02.txt > > Pages : 29 > > Date : 2013-02-22 > > > > Abstract: > > OLSRv2 includes the ability to assign metrics to links and to use > > those metrics to allow routing by other than minimum hop count > > routes. This document provides a historic record of the rationale > > for, and design considerations behind, how link metrics were included > > in OLSRv2. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-ration= ale > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-metrics-rational= e-02 > > > > > > 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 _______________________________________________ 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 From abdussalambaryun@gmail.com Tue Feb 26 07:49:58 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F24221F8889 for ; Tue, 26 Feb 2013 07:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7hbyZYV-13x for ; Tue, 26 Feb 2013 07:49:58 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA3A21F8887 for ; Tue, 26 Feb 2013 07:49:58 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md12so2439197pbc.2 for ; Tue, 26 Feb 2013 07:49:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wrAxpehodGzulPkzxFQO+fzn7wUtn7aRL+ilvBv1YOk=; b=GnjrGjAdd8nEn/ZQiJaB7nA+kHBrUZHtu3qsQJGqiW4Nk4NuRfpUZGQ01uF0U7D8Su FjmsnUY9SjU7wfouzlCJBKCxC5E7d+ZwkmCsaO9pp4PwiknDWmgeqmRHqnPsJ9rOlBmr XLaecdLXxmabgZYnBySNwEEtrnZ6sBnJAISHC9zb5ayO0D660DLWvwMhF1j8q/Mn5ptI we2IhBLUouOP0T/W4cGa3gwFVJ342LdapGRndPpeEIIxffTramYbe5aH4x6QsxDEDJ3G hwQj176VyYgrPwJ/FRvgWG+pbaG1SN6YlCzlBhD99HPyE1Zzw4dHo+o9Pes3UT68QYdb he8g== MIME-Version: 1.0 X-Received: by 10.67.5.193 with SMTP id co1mr2451619pad.6.1361893797810; Tue, 26 Feb 2013 07:49:57 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 07:49:57 -0800 (PST) In-Reply-To: <413400E5-1352-4437-9E07-C47875875665@thomasclausen.org> References: <20130225151705.EB129B1E008@rfc-editor.org> <512CC517.20404@fkie.fraunhofer.de> <413400E5-1352-4437-9E07-C47875875665@thomasclausen.org> Date: Tue, 26 Feb 2013 15:49:57 +0000 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=047d7b15a5a30b792004d6a29cd7 Cc: "manet@ietf.org" Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:49:58 -0000 --047d7b15a5a30b792004d6a29cd7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen < thomas@thomasclausen.org> wrote: > > On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun > wrote: > > I like that protocols use the packet sequence number, if thoes protocols > you refered to don't use the packet SQN, then I recommend they reconsider= . > > > Why? > > "Like" is not a technical argument. > > I agree that it not a technical word, but also agree that *like* can be used in technical volunteer discussions. For example; Why OLSRv2 protocol does not use the packet sequence number SQN? does it accept random packets and ignore to sense sequence packets? Why the designers like it to be that way? Why does AB like protocols to sense SQN? My technical answer is better if it got into a technical draft, however, if a protocol senses the SQN it will be more rebust and more organised in MANET communication. AB --047d7b15a5a30b792004d6a29cd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Cl= ausen <thomas@thomasclausen.org> wrote:

On 26 f=E9vr. 2013,= at 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I like that protocols use the packet sequence number, if thoes pr= otocols you refered to don't use the packet SQN, then I recommend they = reconsider.

Why?

"Like" is not a technical argument.

=A0
I agree that it not a technical word, bu= t also agree that *like*=A0can be used in technical volunteer discussions. = For example; Why OLSRv2 protocol does not use the packet sequence number SQ= N? does it accept random packets and ignore to sense=A0sequence packets? Wh= y the designers like it to be that way? Why does AB like protocols to sense= SQN?
=A0
My technical answer is better if it got into a technical= draft, however, if a protocol senses the SQN it will be more rebust and mo= re organised in=A0MANET communication.
=A0
AB
--047d7b15a5a30b792004d6a29cd7-- From abdussalambaryun@gmail.com Tue Feb 26 07:52:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466A921F8895 for ; Tue, 26 Feb 2013 07:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELqndOMwL9XQ for ; Tue, 26 Feb 2013 07:52:46 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 36B9921F8884 for ; Tue, 26 Feb 2013 07:52:45 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id xa12so2444969pbc.36 for ; Tue, 26 Feb 2013 07:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nyu/lJcq0GE7wXhma4nDcAWVJOg+XGOLPySYvmj46Gg=; b=wfNzbHc36jYjCv9KFQFs8keM2Mu8MTaODwW7/MSTPnpwKt73FI1ofoIEz6iywF8HR8 GqIVKag3fC+XWHQTT7wwAr7DI3Kd8AE36u1Q5HRVmlCrEPZ+uv3kunkzwvTMUD/P1jZI 4fjl0UfDq+YvcIdnEo/FnrNiANWdgCUb0FHpHRm8EhIkFVLZQXWrx9GELLeLsKksyRSl 1nLJLWeOgbhIMdcBBqUjV8NRo9jIGKWfNq/63Q30H0MYkRGLb2kUTMNY6rwVVvMP7RYS EzZHCHOibVxzRm22KTPDPY829aMU3CtssyFm8dYHA+hPhl7/txdjivdEdmdxgkwSxoDY gTOg== MIME-Version: 1.0 X-Received: by 10.68.28.194 with SMTP id d2mr23728681pbh.215.1361893965607; Tue, 26 Feb 2013 07:52:45 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 07:52:45 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 15:52:45 +0000 Message-ID: From: Abdussalam Baryun To: Thomas Clausen Content-Type: multipart/alternative; boundary=bcaec52162630abc2504d6a2a6de Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:52:50 -0000 --bcaec52162630abc2504d6a2a6de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, happy to know you agree to add that into the I-D, I will just hope/pray the editors agree, :-) AB On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen w= rote: > ....and that description of Chris' might be something worth folding into > the I-D? > > Thomas > > On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" < > Chris.Dearlove@baesystems.com> wrote: > > > An attacker can spoof packets appearing to be from a router that skips > some packet sequence numbers since the last packet sent by the router (an= d > received and analysed by the attacker). > > > > This may have an effect on an implementation of NHDP that uses those > packet sequence numbers to recognise missing packets, and thus to change > link quality. (There's no required use of the packet sequence number, and > I'm fairly sure no other even suggested possible use.) > > > > This is an implementation of link quality that frankly isn't very good. > That's why in the translation from RFC 3626, where this is a formal optio= n, > to NHDP, it got downgraded to a comment that it's something you can use i= n > specifying link quality should you want to. > > > > Now against an unprotected NHDP, even one using that mechanism, there > are a lot of much more effective attacks that require less effort to moun= t, > using HELLO messages. > > > > So about the only case where this attack is worth mounting is when you > know that the NHDP implementation has gone to the trouble of protecting > messages, but is using a 5444 implementation that doesn't protect packets= , > and you know that it uses this packet sequence number in the way describe= d, > despite having gone to the effort of protecting messages. > > > > Or in other words it's a smart but stupid NHDP implementer. (He made tw= o > mistakes, using a poor link quality mechanism, and using something > unprotected despite the work in protecting most things.) > > > > So it's rather specialised. And even in those circumstances I might (as > the attacker) spend my effort on something else. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Thomas Clausen > > Sent: 26 February 2013 12:19 > > To: Henning Rogge > > Cc: manet@ietf.org > > Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.t= xt > > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > > On Feb 26, 2013, at 1:08 PM, Henning Rogge < > henning.rogge@fkie.fraunhofer.de> wrote: > > > >> Hi, > >> > >> so do we have an agreement that the old "sequence number attack" > section of nhdp-threats-00 is wrong and must be removed because it > describes something that does not apply to NHDP? > >> > >> If we (as a working group) decide we want a "sequence number attack" > section in nhdp-threats, someone needs to write up a corresponding sectio= n > and we have to see if it gets consensus in the group. > >> > > > > I believe that if there is a sequence number attack on NHDP, then it > should be written down. > > I also believe that I've not seen anything indicating that such an > attack exists. > > > > That's what you're saying, isn't it? > > > >> Henning Rogge > >> > >> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: > >>> your right thanks :) > >>> AB > >>> > >>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge > >>> >>> > wrote: > >>> > >>> On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: > >>> > >>> I can only repeat it again: NHDP does *not* use sequence > >>> numbers, > >>> neither packet nor message sequence numbers. > >>> > >>> That is your opinion which I disagree, and disagree that the > editors > >>> removed the section of sequence number without consensus of WG. > >>> > >>> > >>> You know that the old section was plain WRONG, yes? > >>> > >>> (I suggest reading section 4.5 of nhdp-threats-00) > >>> > >>> Because the attack it described cannot happen to NHDP. > >>> > >>> If you want to get the "sequence number attack" paragraph back, > >>> maybe you should write a new one... one that applies to NHDP. > >>> > >>> > >>> Henning Rogge > >>> > >>> -- > >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >>> Kommunikationssysteme (KOM) > >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >>> Telefon +49 228 9435-961 , Fax +49 22= 8 > >>> 9435 685 > >>> mailto:henning.rogge@fkie.__fraunhofer.de > >>> > http://www.fkie.fraunhofer.de > >>> > >>> > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >>> > >>> > >> > >> > >> -- > >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >> Kommunikationssysteme (KOM) > >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >> Telefon +49 228 9435-961, Fax +49 228 9435 685 > >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > >> > >> _______________________________________________ > >> 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 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 > --bcaec52162630abc2504d6a2a6de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
=A0
happy to know you agree to add that= into the I-D, I will just hope/pray the editors agree, :-)
=A0
AB

On Tue, Feb 26, 2013 at= 3:40 PM, Thomas Clausen <thomas@thomasclausen.org> w= rote:
....and that description of Chris' might be something = worth folding into the I-D?

Thomas

On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com= > wrote:

> An attacker can spoof packets appearing to be from a router that skips= some packet sequence numbers since the last packet sent by the router (and= received and analysed by the attacker).
>
> This may have an effect on an implementation of NHDP that uses those p= acket sequence numbers to recognise missing packets, and thus to change lin= k quality. (There's no required use of the packet sequence number, and = I'm fairly sure no other even suggested possible use.)
>
> This is an implementation of link quality that frankly isn't very = good. That's why in the translation from RFC 3626, where this is a form= al option, to NHDP, it got downgraded to a comment that it's something = you can use in specifying link quality should you want to.
>
> Now against an unprotected NHDP, even one using that mechanism, there = are a lot of much more effective attacks that require less effort to mount,= using HELLO messages.
>
> So about the only case where this attack is worth mounting is when you= know that the NHDP implementation has gone to the trouble of protecting me= ssages, but is using a 5444 implementation that doesn't protect packets= , and you know that it uses this packet sequence number in the way describe= d, despite having gone to the effort of protecting messages.
>
> Or in other words it's a smart but stupid NHDP implementer. (He ma= de two mistakes, using a poor link quality mechanism, and using something u= nprotected despite the work in protecting most things.)
>
> So it's rather specialised. And even in those circumstances I migh= t (as the attacker) spend my effort on something else.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44= 1245 242194 | =A0Fax: +44 1245 242124
> chris.dearlove@baesys= tems.com | http= ://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> -----Original Message-----
> From: manet-bounces@ietf.org= [mailto:manet-bounces@ietf.o= rg] On Behalf Of Thomas Clausen
> Sent: 26 February 2013 12:19
> To: Henning Rogge
> Cc: manet@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.= txt
>
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> On Feb 26, 2013, at 1:08 PM, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote= :
>
>> Hi,
>>
>> so do we have an agreement that the old "sequence number atta= ck" section of nhdp-threats-00 is wrong and must be removed because it= describes something that does not apply to NHDP?
>>
>> If we (as a working group) decide we want a "sequence number = attack" section in nhdp-threats, someone needs to write up a correspon= ding section and we have to see if it gets consensus in the group.
>>
>
> I believe that if there is a sequence number attack on NHDP, then it s= hould be written down.
> I also believe that I've not seen anything indicating that such an= attack exists.
>
> That's what you're saying, isn't it?
>
>> Henning Rogge
>>
>> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote:
>>> your right thanks :)
>>> AB
>>>
>>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge
>>> <hennin= g.rogge@fkie.fraunhofer.de
>>> <mailto:henning.rogge@fkie.fraunhofer.de>> wrote:
>>>
>>> =A0 On 02/26/2013 12:21 PM, Abdussalam Baryun wrote:
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0I can only repeat it again: NHDP does *= not* use sequence
>>> =A0 =A0 =A0 numbers,
>>> =A0 =A0 =A0 =A0 =A0 =A0neither packet nor message sequence num= bers.
>>>
>>> =A0 =A0 =A0 That is your opinion which I disagree, and disagre= e that the editors
>>> =A0 =A0 =A0 removed the section of sequence number without con= sensus of WG.
>>>
>>>
>>> =A0 You know that the old section was plain WRONG, yes?
>>>
>>> =A0 (I suggest reading section 4.5 of nhdp-threats-00)
>>>
>>> =A0 Because the attack it described cannot happen to NHDP.
>>>
>>> =A0 If you want to get the "sequence number attack" = paragraph back,
>>> =A0 maybe you should write a new one... one that applies to NH= DP.
>>>
>>>
>>> =A0 Henning Rogge
>>>
>>> =A0 --
>>> =A0 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f= =FCr
>>> =A0 Kommunikation, Informationsverarbeitung und Ergonomie FKIE=
>>> =A0 Kommunikationssysteme (KOM)
>>> =A0 Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>>> =A0 Telefon +49 228 9435-961 <tel:%2B49%20228%209435-961>, =A0 F= ax +49 228
>>> =A0 9435 685 <tel:%2B49%20228%209435%20685>
>>> =A0 mailto:henning.rogg= e@fkie.__fraunhofer.= de
>>> =A0 <mailto:henning.rogge@fkie.fraunhofer.de> http://www.fkie.fraunhofer.de
>>>
>>>
>>> =A0 _______________________________________________
>>> =A0 manet mailing list
>>> =A0 manet@ietf.org <m= ailto:manet@ietf.org>
>>> =A0 https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>
>>
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM)
>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>> Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685
>> mailto:henning= .rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>>
>> _______________________________________________
>> 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 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
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec52162630abc2504d6a2a6de-- From thomas@thomasclausen.org Tue Feb 26 07:54:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F5B21F886E for ; Tue, 26 Feb 2013 07:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZRquNTh9DGR for ; Tue, 26 Feb 2013 07:54:33 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id ED19A21F8717 for ; Tue, 26 Feb 2013 07:54:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id B92ED1BD7944; Tue, 26 Feb 2013 07:54:32 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id D04791BD7924; Tue, 26 Feb 2013 07:54:31 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FC7DE96F-226F-4F49-9F31-1CB3715B565C" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Clausen In-Reply-To: Date: Tue, 26 Feb 2013 16:54:29 +0100 Message-Id: References: <20130225151705.EB129B1E008@rfc-editor.org> <512CC517.20404@fkie.fraunhofer.de> <413400E5-1352-4437-9E07-C47875875665@thomasclausen.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:54:33 -0000 --Apple-Mail=_FC7DE96F-226F-4F49-9F31-1CB3715B565C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 26, 2013, at 4:49 PM, Abdussalam Baryun = wrote: > On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen = wrote: >=20 > On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun = wrote: >=20 >> I like that protocols use the packet sequence number, if thoes = protocols you refered to don't use the packet SQN, then I recommend they = reconsider. >=20 > Why? >=20 > "Like" is not a technical argument. >=20 > =20 > I agree that it not a technical word, but also agree that *like* can = be used in technical volunteer discussions. For example; Why OLSRv2 = protocol does not use the packet sequence number SQN? does it accept = random packets and ignore to sense sequence packets? Why the designers = like it to be that way? Why does AB like protocols to sense SQN? It's not a "like"; it's because OLSRv2 has no technical use for it. > My technical answer is better if it got into a technical draft, = however, if a protocol senses the SQN it will be more rebust and more = organised in MANET communication. This is not true. Thomas > =20 > AB > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_FC7DE96F-226F-4F49-9F31-1CB3715B565C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 abdussalambaryun@gmail.com&= gt; wrote:

On Tue, Feb 26, 2013 at 3:13 = PM, Thomas Heide Clausen <thomas@thomasclausen.org> = wrote:

On 26 f=E9vr. = 2013, at 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> = wrote:

I like that protocols use the packet sequence number, if thoes = protocols you refered to don't use the packet SQN, then I recommend they = reconsider.

Why?

"Like" is not a technical argument.

 
I agree that it not a technical word, but also agree that = *like* can be used in technical volunteer discussions. For example; = Why OLSRv2 protocol does not use the packet sequence number SQN? does it = accept random packets and ignore to sense sequence packets? Why the = designers like it to be that way? Why does AB like protocols to sense = SQN?

It's not a "like"; it's because = OLSRv2 has no technical use for it.

 My technical answer = is better if it got into a technical draft, however, if a protocol = senses the SQN it will be more rebust and more organised in MANET = communication.

This is not = true.

Thomas

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

= --Apple-Mail=_FC7DE96F-226F-4F49-9F31-1CB3715B565C-- From thomas@thomasclausen.org Tue Feb 26 07:56:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B6121F8891 for ; Tue, 26 Feb 2013 07:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbF83Tf0It-g for ; Tue, 26 Feb 2013 07:55:58 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5BE21F887F for ; Tue, 26 Feb 2013 07:55:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 619661BD79A5; Tue, 26 Feb 2013 07:55:58 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 03D111BD799E; Tue, 26 Feb 2013 07:55:56 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1936678B-5715-45C1-A440-9D792464195B" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Clausen In-Reply-To: Date: Tue, 26 Feb 2013 16:55:54 +0100 Message-Id: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:56:01 -0000 --Apple-Mail=_1936678B-5715-45C1-A440-9D792464195B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun = wrote: > Hi Thomas, > =20 > happy to know you agree to add that into the I-D, I will just = hope/pray the editors agree, :-) The editors do what the WG consensus tells them to do. Chris made a proposal, for the WG to consider. Thomas > AB >=20 > On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen = wrote: > ....and that description of Chris' might be something worth folding = into the I-D? >=20 > Thomas >=20 > On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" = wrote: >=20 > > An attacker can spoof packets appearing to be from a router that = skips some packet sequence numbers since the last packet sent by the = router (and received and analysed by the attacker). > > > > This may have an effect on an implementation of NHDP that uses those = packet sequence numbers to recognise missing packets, and thus to change = link quality. (There's no required use of the packet sequence number, = and I'm fairly sure no other even suggested possible use.) > > > > This is an implementation of link quality that frankly isn't very = good. That's why in the translation from RFC 3626, where this is a = formal option, to NHDP, it got downgraded to a comment that it's = something you can use in specifying link quality should you want to. > > > > Now against an unprotected NHDP, even one using that mechanism, = there are a lot of much more effective attacks that require less effort = to mount, using HELLO messages. > > > > So about the only case where this attack is worth mounting is when = you know that the NHDP implementation has gone to the trouble of = protecting messages, but is using a 5444 implementation that doesn't = protect packets, and you know that it uses this packet sequence number = in the way described, despite having gone to the effort of protecting = messages. > > > > Or in other words it's a smart but stupid NHDP implementer. (He made = two mistakes, using a poor link quality mechanism, and using something = unprotected despite the work in protecting most things.) > > > > So it's rather specialised. And even in those circumstances I might = (as the attacker) spend my effort on something else. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Thomas Clausen > > Sent: 26 February 2013 12:19 > > To: Henning Rogge > > Cc: manet@ietf.org > > Subject: Re: [manet] I-D Action: = draft-ietf-manet-nhdp-sec-threats-01.txt > > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > > On Feb 26, 2013, at 1:08 PM, Henning Rogge = wrote: > > > >> Hi, > >> > >> so do we have an agreement that the old "sequence number attack" = section of nhdp-threats-00 is wrong and must be removed because it = describes something that does not apply to NHDP? > >> > >> If we (as a working group) decide we want a "sequence number = attack" section in nhdp-threats, someone needs to write up a = corresponding section and we have to see if it gets consensus in the = group. > >> > > > > I believe that if there is a sequence number attack on NHDP, then it = should be written down. > > I also believe that I've not seen anything indicating that such an = attack exists. > > > > That's what you're saying, isn't it? > > > >> Henning Rogge > >> > >> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: > >>> your right thanks :) > >>> AB > >>> > >>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge > >>> >>> > wrote: > >>> > >>> On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: > >>> > >>> I can only repeat it again: NHDP does *not* use = sequence > >>> numbers, > >>> neither packet nor message sequence numbers. > >>> > >>> That is your opinion which I disagree, and disagree that the = editors > >>> removed the section of sequence number without consensus of = WG. > >>> > >>> > >>> You know that the old section was plain WRONG, yes? > >>> > >>> (I suggest reading section 4.5 of nhdp-threats-00) > >>> > >>> Because the attack it described cannot happen to NHDP. > >>> > >>> If you want to get the "sequence number attack" paragraph back, > >>> maybe you should write a new one... one that applies to NHDP. > >>> > >>> > >>> Henning Rogge > >>> > >>> -- > >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >>> Kommunikationssysteme (KOM) > >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >>> Telefon +49 228 9435-961 , Fax +49 = 228 > >>> 9435 685 > >>> mailto:henning.rogge@fkie.__fraunhofer.de > >>> = http://www.fkie.fraunhofer.de > >>> > >>> > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >>> > >>> > >> > >> > >> -- > >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >> Kommunikationssysteme (KOM) > >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >> Telefon +49 228 9435-961, Fax +49 228 9435 685 > >> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de > >> > >> _______________________________________________ > >> 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 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. > > ******************************************************************** > > >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail=_1936678B-5715-45C1-A440-9D792464195B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 abdussalambaryun@gmail.com&= gt; wrote:

Hi Thomas,
 
happy to know = you agree to add that into the I-D, I will just hope/pray the editors = agree, :-)

The editors do what the = WG consensus tells them to do.

Chris made a = proposal, for the WG to = consider.

Thomas

AB

On = Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen <thomas@thomasclausen.org> wrote:
....and that = description of Chris' might be something worth folding into the I-D?

Thomas

On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.co= m> wrote:

> An attacker can spoof packets appearing to be from a router that = skips some packet sequence numbers since the last packet sent by the = router (and received and analysed by the attacker).
>
> This may have an effect on an implementation of NHDP that uses = those packet sequence numbers to recognise missing packets, and thus to = change link quality. (There's no required use of the packet sequence = number, and I'm fairly sure no other even suggested possible use.)
>
> This is an implementation of link quality that frankly isn't very = good. That's why in the translation from RFC 3626, where this is a = formal option, to NHDP, it got downgraded to a comment that it's = something you can use in specifying link quality should you want to.
>
> Now against an unprotected NHDP, even one using that mechanism, = there are a lot of much more effective attacks that require less effort = to mount, using HELLO messages.
>
> So about the only case where this attack is worth mounting is when = you know that the NHDP implementation has gone to the trouble of = protecting messages, but is using a 5444 implementation that doesn't = protect packets, and you know that it uses this packet sequence number = in the way described, despite having gone to the effort of protecting = messages.
>
> Or in other words it's a smart but stupid NHDP implementer. (He = made two mistakes, using a poor link quality mechanism, and using = something unprotected despite the work in protecting most things.)
>
> So it's rather specialised. And even in those circumstances I might = (as the attacker) spend my effort on something else.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 = 242124
> chris.dearlove@baesystems.co= m | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> -----Original Message-----
> From: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On = Behalf Of Thomas Clausen
> Sent: 26 February 2013 12:19
> To: Henning Rogge
> Cc: manet@ietf.org
> Subject: Re: [manet] I-D Action: = draft-ietf-manet-nhdp-sec-threats-01.txt
>
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> On Feb 26, 2013, at 1:08 PM, Henning Rogge <henning.rogge@fkie.fraunh= ofer.de> wrote:
>
>> Hi,
>>
>> so do we have an agreement that the old "sequence number = attack" section of nhdp-threats-00 is wrong and must be removed because = it describes something that does not apply to NHDP?
>>
>> If we (as a working group) decide we want a "sequence number = attack" section in nhdp-threats, someone needs to write up a = corresponding section and we have to see if it gets consensus in the = group.
>>
>
> I believe that if there is a sequence number attack on NHDP, then = it should be written down.
> I also believe that I've not seen anything indicating that such an = attack exists.
>
> That's what you're saying, isn't it?
>
>> Henning Rogge
>>
>> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote:
>>> your right thanks :)
>>> AB
>>>
>>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge
>>> <henning.rogge@fkie.fraunh= ofer.de
>>> <mailto:henning.rogge@fkie.fraunh= ofer.de>> wrote:
>>>
>>>   On 02/26/2013 12:21 PM, Abdussalam Baryun wrote:
>>>
>>>            I can only repeat = it again: NHDP does *not* use sequence
>>>       numbers,
>>>            neither packet nor = message sequence numbers.
>>>
>>>       That is your opinion which I disagree, = and disagree that the editors
>>>       removed the section of sequence number = without consensus of WG.
>>>
>>>
>>>   You know that the old section was plain WRONG, = yes?
>>>
>>>   (I suggest reading section 4.5 of = nhdp-threats-00)
>>>
>>>   Because the attack it described cannot happen to = NHDP.
>>>
>>>   If you want to get the "sequence number attack" = paragraph back,
>>>   maybe you should write a new one... one that applies = to NHDP.
>>>
>>>
>>>   Henning Rogge
>>>
>>>   --
>>>   Diplom-Informatiker Henning Rogge , = Fraunhofer-Institut f=FCr
>>>   Kommunikation, Informationsverarbeitung und = Ergonomie FKIE
>>>   Kommunikationssysteme (KOM)
>>>   Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>>>   Telefon +49 228 9435-961 = <tel:%2B49%20228%209435-961>,   Fax +49 228
>>>   9435 685 <tel:%2B49%20228%209435%20685>
>>>   mailto:henning.rogge@fkie.__fraunhofer.de
>>>   <mailto:henning.rogge@fkie.fraunh= ofer.de> http://www.fkie.fraunhofer.de
>>>
>>>
>>>   _______________________________________________
>>>   manet mailing list
>>>   manet@ietf.org = <mailto:manet@ietf.org>
>>>   https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>
>>
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
= >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM)
>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>> Telefon +49 228 9435-961,   Fax +49 228 = 9435 685
>> mailto:henning.rogge@fkie.fraunh= ofer.de http://www.fkie.fraunhofer.de
>>
>> _______________________________________________
>> 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 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


= --Apple-Mail=_1936678B-5715-45C1-A440-9D792464195B-- From hrogge@googlemail.com Tue Feb 26 07:56:52 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DF921F88A0 for ; Tue, 26 Feb 2013 07:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTmWFbUoxZd1 for ; Tue, 26 Feb 2013 07:56:51 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5F65A21F883A for ; Tue, 26 Feb 2013 07:56:51 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id fq12so4054703lab.19 for ; Tue, 26 Feb 2013 07:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=uuerGSh54WheVlrW0tnG9jdJcGzl16c+TeZ48Ruye5c=; b=Q8E/7SzbFxDCFWQw3jBSfxAE0sqw6k6AiL6HEaTqwbp5+tApgYnqdg4XIM9wPNDmNe uQRSIQ3MpZ/esECC5tTQGkBNxJi4jAWhbNpqXZfhKq6xn3DPNqomQ3j0NjnHdOXHiPr/ TwF886C4Lj/f8oJrHp1kuD3DXSjzumesmBnmqUt5EYe5UXVy2ZKjRqLX2El3oqJbFaLl vD9tUO/kixwfJRDNrFVNYmgB5Z6abjzQEAFbUoRQwVQHRrjByEKz/vl94e8d8W4/T40r 1jtuvu4pxXpDJ5qXoj0EwMrR928eoy2LvSrSp7IKOGZt1FZhbIz389ZJVGDvV1vwqNMh qwZA== X-Received: by 10.112.24.199 with SMTP id w7mr755801lbf.102.1361894209541; Tue, 26 Feb 2013 07:56:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Tue, 26 Feb 2013 07:56:29 -0800 (PST) In-Reply-To: References: <20130225151705.EB129B1E008@rfc-editor.org> <512CC517.20404@fkie.fraunhofer.de> <413400E5-1352-4437-9E07-C47875875665@thomasclausen.org> From: Henning Rogge Date: Tue, 26 Feb 2013 16:56:29 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , Thomas Heide Clausen Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:56:52 -0000 On Tue, Feb 26, 2013 at 4:49 PM, Abdussalam Baryun wrote: > I agree that it not a technical word, but also agree that *like* can be used > in technical volunteer discussions. For example; Why OLSRv2 protocol does > not use the packet sequence number SQN? does it accept random packets and > ignore to sense sequence packets? Why the designers like it to be that way? > Why does AB like protocols to sense SQN? Because OLSRv2 only deals with messages which are flooded through the network. Which is the reason it use MESSAGE sequence-numbers to detect valid incoming messages. Packet sequence-numbers are only "hop by hop"... OLSRv2 has no direct use for them. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From Chris.Dearlove@baesystems.com Tue Feb 26 07:57:53 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6DE21F88EF for ; Tue, 26 Feb 2013 07:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN7sa2-7LTsI for ; Tue, 26 Feb 2013 07:57:36 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 877BD21F88E6 for ; Tue, 26 Feb 2013 07:57:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208,217";a="314939187" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Feb 2013 15:57:20 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r1QFvKwM015281 for ; Tue, 26 Feb 2013 15:57:20 GMT X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208,217";a="9077014" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 26 Feb 2013 15:57:20 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 15:57:20 +0000 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , Thomas Heide Clausen Thread-Topic: [manet] [Technical Errata Reported] RFC5444 (3496) Thread-Index: AQHOE2tYWHRmgACwIkuCTgQkaOcmyZiMLwoAgAADeICAAAqUAIAAA6kAgAAKRICAAAEjwA== Date: Tue, 26 Feb 2013 15:57:19 +0000 Message-ID: References: <20130225151705.EB129B1E008@rfc-editor.org> <512CC517.20404@fkie.fraunhofer.de> <413400E5-1352-4437-9E07-C47875875665@thomasclausen.org> 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D25026841GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:57:53 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25026841GLKXM0002VGREEN_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable NHDP has made it to RFC, and OLSRv2 has made it to one AD short of RFC - an= d not for any related reason - without anyone thinking "we really should us= e that because it might be there - though it also might not". Which suggest= s your technical answer is wrong. And anyway, procedurally it's multiple st= eps too late. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: 26 February 2013 15:50 To: Thomas Heide Clausen Cc: manet@ietf.org Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen > wrote: On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun > wrote: I like that protocols use the packet sequence number, if thoes protocols yo= u refered to don't use the packet SQN, then I recommend they reconsider. Why? "Like" is not a technical argument. I agree that it not a technical word, but also agree that *like* can be use= d in technical volunteer discussions. For example; Why OLSRv2 protocol does= not use the packet sequence number SQN? does it accept random packets and = ignore to sense sequence packets? Why the designers like it to be that way?= Why does AB like protocols to sense SQN? My technical answer is better if it got into a technical draft, however, if= a protocol senses the SQN it will be more rebust and more organised in MAN= ET communication. AB ******************************************************************** 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. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25026841GLKXM0002VGREEN_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

NHDP has made it to RFC, = and OLSRv2 has made it to one AD short of RFC - and not for any related rea= son - without anyone thinking "we really should use that because it might be there - though it also might not". Which suggests= your technical answer is wrong. And anyway, procedurally it's multiple ste= ps too late.

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org= ] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:50
To: Thomas Heide Clausen
Cc: manet@ietf.org
Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)=

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clause= n <thomas@= thomasclausen.org> wrote:

 

On 26 f=E9vr. 2013, a= t 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I like that protocols use the packet sequence number= , if thoes protocols you refered to don't use the packet SQN, then I recomm= end they reconsider.

 

Why?

 

"Like" is not a technical argument.

 

 

I agree that it not a technical word, but also agree= that *like* can be used in technical volunteer discussions. For examp= le; Why OLSRv2 protocol does not use the packet sequence number SQN? does i= t accept random packets and ignore to sense sequence packets? Why the designers like it to be that way? Why does AB like protoc= ols to sense SQN?

 

My technical answer is better if it got into a techn= ical draft, however, if a protocol senses the SQN it will be more rebust an= d more organised in MANET communication.

 

AB


********************************************************************
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.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25026841GLKXM0002VGREEN_-- From abdussalambaryun@gmail.com Tue Feb 26 08:00:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAAF21F8853 for ; Tue, 26 Feb 2013 08:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZFM4UUv5LcJ for ; Tue, 26 Feb 2013 08:00:11 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63CE321F8783 for ; Tue, 26 Feb 2013 08:00:06 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so2090494dae.17 for ; Tue, 26 Feb 2013 08:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3+XOoN8AB8G71hEVnz0Ex4ibVFB0rzYDeH4mRgM/8kA=; b=yCXA7G49eJc/kdSULlfCWr5Qcp/q41kjwJogb1ugn93RGT+Q4G0mD6gs3GI8D0xKHY K/zAE+fr7CXar+mdGCY/xhE5ihyxJPEBYUah4PZxpVb2yp94Xdo+l1pofg1SQ2Gon5uI zHT9CbPTM7jCyyZhMN54AHV1PvERFCY85IlZUKOZtpxbrpvmwf5h8O7JbN8eL8VKYZRV BPoNuX6znwLYf/zPckFFRqbcKXWwSMGd5ENjD9CjKDYtgIsB2jgnLfW4j44SXJQbAXWl OScgiGIoVNjlnQ+Dn0lNl4a1zDgLibBsiomLA0a8jQOTveWTtr10G3HuXBuH3UvIA19t qpug== MIME-Version: 1.0 X-Received: by 10.66.234.132 with SMTP id ue4mr2354925pac.163.1361894402278; Tue, 26 Feb 2013 08:00:02 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 08:00:02 -0800 (PST) In-Reply-To: References: <20130225151705.EB129B1E008@rfc-editor.org> <512CC517.20404@fkie.fraunhofer.de> <413400E5-1352-4437-9E07-C47875875665@thomasclausen.org> Date: Tue, 26 Feb 2013 16:00:02 +0000 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=047d7b15a4a513a23f04d6a2c050 Cc: "manet@ietf.org" , Thomas Heide Clausen Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:00:41 -0000 --047d7b15a4a513a23f04d6a2c050 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is no harm in discussing, issues related to NHDP or RFC5444, or erratas, even after they were publish as we all know they are Request For Comments, AB On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > NHDP has made it to RFC, and OLSRv2 has made it to one AD short of RFC - > and not for any related reason - without anyone thinking "we really shoul= d > use that because it might be there - though it also might not". Which > suggests your technical answer is wrong. And anyway, procedurally it's > multiple steps too late.**** > > ** ** > > -- **** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > ** ** > > *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On Behalf > Of *Abdussalam Baryun > *Sent:* 26 February 2013 15:50 > *To:* Thomas Heide Clausen > *Cc:* manet@ietf.org > > *Subject:* Re: [manet] [Technical Errata Reported] RFC5444 (3496)**** > > ** ** > > ** ** > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this processon how t= o deal with suspicious emails. > ***** > > On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen < > thomas@thomasclausen.org> wrote:**** > > ** ** > > On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun > wrote:**** > > I like that protocols use the packet sequence number, if thoes protocols > you refered to don't use the packet SQN, then I recommend they reconsider= . > **** > > ** ** > > Why?**** > > ** ** > > "Like" is not a technical argument.**** > > ** ** > > **** > > I agree that it not a technical word, but also agree that *like* can be > used in technical volunteer discussions. For example; Why OLSRv2 protocol > does not use the packet sequence number SQN? does it accept random packet= s > and ignore to sense sequence packets? Why the designers like it to be tha= t > way? Why does AB like protocols to sense SQN?**** > > **** > > My technical answer is better if it got into a technical draft, however, > if a protocol senses the SQN it will be more rebust and more organised > in MANET communication.**** > > **** > > AB**** > > ******************************************************************** > 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. > ******************************************************************** > > --047d7b15a4a513a23f04d6a2c050 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There is no harm in discussing, issues related to NHDP or RFC5444, or = erratas,=A0even after they were publish as we all know they are Request For= Comments,
=A0
AB

On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) <C= hris.Dearlove@baesystems.com> wrote:

NHDP has made it to = RFC, and OLSRv2 has made it to one AD short of RFC - and not for any relate= d reason - without anyone thinking "we really should use that because it might be there - though it also might not". Which suggests= your technical answer is wrong. And anyway, procedurally it's multiple= steps too late.

=A0

--

Christopher Dearlove=

Senior Principal Eng= ineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:50
To: Thomas Heide Clausen
Cc: manet@ietf.o= rg


Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)

=A0

=A0

*** WARNING ***<= /span>

This message originates from outside ou= r organisation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clause= n <thomas@= thomasclausen.org> wrote:

=A0

On 26 f=E9vr. 2013, at = 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I like that protocols use the packet sequence number= , if thoes protocols you refered to don't use the packet SQN, then I re= commend they reconsider.

=A0

Why?

=A0

"Like" is not a technical argument.=

=A0=

=A0

I agree that it not a technical word, but also agree= that *like*=A0can be used in technical volunteer discussions. For example;= Why OLSRv2 protocol does not use the packet sequence number SQN? does it a= ccept random packets and ignore to sense=A0sequence packets? Why the designers like it to be that way? Why does AB like protoc= ols to sense SQN?

=A0

My technical answer is better if it got into a techn= ical draft, however, if a protocol senses the SQN it will be more rebust an= d more organised in=A0MANET communication.

=A0

AB


********************************************************************
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.
********************************************************************


--047d7b15a4a513a23f04d6a2c050-- From Chris.Dearlove@baesystems.com Tue Feb 26 08:01:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D6521F8853 for ; Tue, 26 Feb 2013 08:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FP1P+RWIf6iu for ; Tue, 26 Feb 2013 08:01:17 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id DD24521F88D6 for ; Tue, 26 Feb 2013 08:01:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208,217";a="267969804" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 26 Feb 2013 16:01:10 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r1QG1AK8000576 for ; Tue, 26 Feb 2013 16:01:10 GMT X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208,217";a="8844991" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 26 Feb 2013 16:01:09 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 16:01:10 +0000 From: "Dearlove, Christopher (UK)" To: Thomas Clausen , Abdussalam Baryun Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt Thread-Index: AQHOFBnzQcK/1dKC6UukRyjp9E9HrJiMDrMAgAAzSfCAAAT3gIAAA3uAgAAA4gCAAADBkA== Date: Tue, 26 Feb 2013 16:01:10 +0000 Message-ID: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D25026870GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:01:22 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25026870GLKXM0002VGREEN_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to be clear, I didn't make this as a proposal to be included - it's a = bit more colloquial than such text should be. I just made it as a statement of what (in my - fairly well informed - opini= on) the situation is. Of course as a contribution on the list the authors are free to make use of= it as a contribution should they wish. As I noted, if so I'd advise reword= ing it a bit. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Thomas Clausen [mailto:thomas@thomasclausen.org] Sent: 26 February 2013 15:56 To: Abdussalam Baryun Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun > wrote: Hi Thomas, happy to know you agree to add that into the I-D, I will just hope/pray the= editors agree, :-) The editors do what the WG consensus tells them to do. Chris made a proposal, for the WG to consider. Thomas AB On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen > wrote: ....and that description of Chris' might be something worth folding into th= e I-D? Thomas On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" > wrote: > An attacker can spoof packets appearing to be from a router that skips so= me packet sequence numbers since the last packet sent by the router (and re= ceived and analysed by the attacker). > > This may have an effect on an implementation of NHDP that uses those pack= et sequence numbers to recognise missing packets, and thus to change link q= uality. (There's no required use of the packet sequence number, and I'm fai= rly sure no other even suggested possible use.) > > This is an implementation of link quality that frankly isn't very good. T= hat's why in the translation from RFC 3626, where this is a formal option, = to NHDP, it got downgraded to a comment that it's something you can use in = specifying link quality should you want to. > > Now against an unprotected NHDP, even one using that mechanism, there are= a lot of much more effective attacks that require less effort to mount, us= ing HELLO messages. > > So about the only case where this attack is worth mounting is when you kn= ow that the NHDP implementation has gone to the trouble of protecting messa= ges, but is using a 5444 implementation that doesn't protect packets, and y= ou know that it uses this packet sequence number in the way described, desp= ite having gone to the effort of protecting messages. > > Or in other words it's a smart but stupid NHDP implementer. (He made two = mistakes, using a poor link quality mechanism, and using something unprotec= ted despite the work in protecting most things.) > > So it's rather specialised. And even in those circumstances I might (as t= he attacker) spend my effort on something else. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | htt= p://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet= -bounces@ietf.org] On Behalf Of Thomas Claus= en > Sent: 26 February 2013 12:19 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > On Feb 26, 2013, at 1:08 PM, Henning Rogge > wrote: > >> Hi, >> >> so do we have an agreement that the old "sequence number attack" section= of nhdp-threats-00 is wrong and must be removed because it describes somet= hing that does not apply to NHDP? >> >> If we (as a working group) decide we want a "sequence number attack" sec= tion in nhdp-threats, someone needs to write up a corresponding section and= we have to see if it gets consensus in the group. >> > > I believe that if there is a sequence number attack on NHDP, then it shou= ld be written down. > I also believe that I've not seen anything indicating that such an attack= exists. > > That's what you're saying, isn't it? > >> Henning Rogge >> >> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: >>> your right thanks :) >>> AB >>> >>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge >>> >>> >> wrote: >>> >>> On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: >>> >>> I can only repeat it again: NHDP does *not* use sequence >>> numbers, >>> neither packet nor message sequence numbers. >>> >>> That is your opinion which I disagree, and disagree that the edit= ors >>> removed the section of sequence number without consensus of WG. >>> >>> >>> You know that the old section was plain WRONG, yes? >>> >>> (I suggest reading section 4.5 of nhdp-threats-00) >>> >>> Because the attack it described cannot happen to NHDP. >>> >>> If you want to get the "sequence number attack" paragraph back, >>> maybe you should write a new one... one that applies to NHDP. >>> >>> >>> Henning Rogge >>> >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961 , Fax +49 228 >>> 9435 685 >>> mailto:henning.rogge@fkie.__fraunhofer.de= >>> > http://www.fkie.fraunhofer.de >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >> >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435= 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> _______________________________________________ >> 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 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 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25026870GLKXM0002VGREEN_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Just to be clear, I didn'= t make this as a proposal to be included - it's a bit more colloquial than = such text should be.

 <= /p>

I just made it as a state= ment of what (in my - fairly well informed - opinion) the situation is.

 <= /p>

Of course as a contributi= on on the list the authors are free to make use of it as a contribution sho= uld they wish. As I noted, if so I'd advise rewording it a bit.

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: Thomas Clausen [mailto:thomas@thomasclausen.org]
Sent: 26 February 2013 15:56
To: Abdussalam Baryun
Cc: Dearlove, Christopher (UK); manet@ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-0= 1.txt

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

 

On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun <<= a href=3D"mailto:abdussalambaryun@gmail.com">abdussalambaryun@gmail.com= > wrote:



Hi Thomas,

 

happy to know you agree to add that into the I-D, I = will just hope/pray the editors agree, :-)

 

The editors do what the WG consensus tells them to d= o.

 

Chris made a proposal, for the WG to consider.<= /o:p>

 

Thomas



AB

 

On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen <= thomas@thomas= clausen.org> wrote:

....and that description of Chris' might be somethin= g worth folding into the I-D?

Thomas


On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com= > wrote:

> An attacker can spoof packets appearing to be from a router that skips= some packet sequence numbers since the last packet sent by the router (and= received and analysed by the attacker).
>
> This may have an effect on an implementation of NHDP that uses those p= acket sequence numbers to recognise missing packets, and thus to change lin= k quality. (There's no required use of the packet sequence number, and I'm = fairly sure no other even suggested possible use.)
>
> This is an implementation of link quality that frankly isn't very good= . That's why in the translation from RFC 3626, where this is a formal optio= n, to NHDP, it got downgraded to a comment that it's something you can use = in specifying link quality should you want to.
>
> Now against an unprotected NHDP, even one using that mechanism, there = are a lot of much more effective attacks that require less effort to mount,= using HELLO messages.
>
> So about the only case where this attack is worth mounting is when you= know that the NHDP implementation has gone to the trouble of protecting me= ssages, but is using a 5444 implementation that doesn't protect packets, an= d you know that it uses this packet sequence number in the way described, despite having gone to the effort of= protecting messages.
>
> Or in other words it's a smart but stupid NHDP implementer. (He made t= wo mistakes, using a poor link quality mechanism, and using something unpro= tected despite the work in protecting most things.)
>
> So it's rather specialised. And even in those circumstances I might (a= s the attacker) spend my effort on something else.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 | &= nbsp;Fax: +44 1245 242124
> chris.dearlove@baesys= tems.com | http://www.baesyst= ems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> -----Original Message-----
> From: manet-bounces@ietf.org= [mailto:manet-bounces@ietf.o= rg] On Behalf Of Thomas Clausen
> Sent: 26 February 2013 12:19
> To: Henning Rogge
> Cc: manet@ietf.org
> Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.= txt
>
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> On Feb 26, 2013, at 1:08 PM, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote= :
>
>> Hi,
>>
>> so do we have an agreement that the old "sequence number atta= ck" section of nhdp-threats-00 is wrong and must be removed because it= describes something that does not apply to NHDP?
>>
>> If we (as a working group) decide we want a "sequence number = attack" section in nhdp-threats, someone needs to write up a correspon= ding section and we have to see if it gets consensus in the group.
>>
>
> I believe that if there is a sequence number attack on NHDP, then it s= hould be written down.
> I also believe that I've not seen anything indicating that such an att= ack exists.
>
> That's what you're saying, isn't it?
>
>> Henning Rogge
>>
>> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote:
>>> your right thanks :)
>>> AB
>>>
>>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge
>>> <hennin= g.rogge@fkie.fraunhofer.de
>>> <mailto:henning.rogge@fkie.fraunhofer.de>> wrote:
>>>
>>>   On 02/26/2013 12:21 PM, Abdussalam Baryun wrote:
>>>
>>>            I can only repeat it = again: NHDP does *not* use sequence
>>>       numbers,
>>>            neither packet nor me= ssage sequence numbers.
>>>
>>>       That is your opinion which I disagree, an= d disagree that the editors
>>>       removed the section of sequence number wi= thout consensus of WG.
>>>
>>>
>>>   You know that the old section was plain WRONG, yes?
>>>
>>>   (I suggest reading section 4.5 of nhdp-threats-00)
>>>
>>>   Because the attack it described cannot happen to NHDP.<= br> >>>
>>>   If you want to get the "sequence number attack&quo= t; paragraph back,
>>>   maybe you should write a new one... one that applies to= NHDP.
>>>
>>>
>>>   Henning Rogge
>>>
>>>   --
>>>   Diplom-Informatiker Henning Rogge , Fraunhofer-Institut= f=FCr
>>>   Kommunikation, Informationsverarbeitung und Ergonomie F= KIE
>>>   Kommunikationssysteme (KOM)
>>>   Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>>>   Telefon +49 = 228 9435-961 <tel:%2B49%20228%209435-961>,   Fax +49 228=
>>>   9435 685 <tel:%2B49%20228%209435%20685>
>>>   mailto:henning.r= ogge@fkie.__fraunho= fer.de
>>>   <mailto:henning.rogge@fkie.fraunhofer.de> http://www.fki= e.fraunhofer.de
>>>
>>>
>>>   _______________________________________________
>>>   manet mailing list
>>>   manet@ietf.org &l= t;mailto:manet@ietf.org>
>>>   https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>
>>
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM)
>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>> Telefon +49 228 9435-96= 1,   Fax +49 228 9435 685
>> mailto:henning= .rogge@fkie.fraunhofer.de http://www.fki= e.fraunhofer.de
>>
>> _______________________________________________
>> 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 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
h= ttps://www.ietf.org/mailman/listinfo/manet

 

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25026870GLKXM0002VGREEN_-- From abdussalambaryun@gmail.com Tue Feb 26 08:01:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D64F21F8783 for ; Tue, 26 Feb 2013 08:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+ltkqVm1Xmu for ; Tue, 26 Feb 2013 08:01:30 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 82C4921F88E8 for ; Tue, 26 Feb 2013 08:01:29 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id bg4so2509917pad.26 for ; Tue, 26 Feb 2013 08:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TH7WGfa93y+Qt18HdRi/cCNaDJtPeyhtEMC0VB2dGGg=; b=TMBnEX/FKwCdYLZ95/uu26pMIyySKCYjlt1d01bQtH2RVyVWB4nrwC1A9pwnQ+cueb r6DX3wBuxdb+uN6jujdXSfHE4/7lGv8sfudLpsUGD1Ae748okRlYUqmPhPZ9mu+G+jtq xo1CKoXPDOPtUew8Yb8jUU59RU3ae8/FqVXPvU1hf9XceGhUIkiYMvyFqesT2U05uBN/ DrKlpg95A7I9s8WVml+Zz6B4YBTb6YUmpIXNzoEDKrpnOO8iaJMUPu4PtZ+nwFIfycqM YJMGOEFjCDku1U4ntDiGk7wSgtD0AbA5T6OgfFwWVcMKSva89e12STt68AcujCtp2cye 0XFQ== MIME-Version: 1.0 X-Received: by 10.66.27.199 with SMTP id v7mr2284105pag.215.1361894489307; Tue, 26 Feb 2013 08:01:29 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 08:01:29 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 16:01:29 +0000 Message-ID: From: Abdussalam Baryun To: Thomas Clausen Content-Type: multipart/alternative; boundary=bcaec52becfd41bf4f04d6a2c515 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:01:38 -0000 --bcaec52becfd41bf4f04d6a2c515 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I made many proposals but not considered by editors, AB On Tue, Feb 26, 2013 at 3:55 PM, Thomas Clausen w= rote: > > On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun > wrote: > > Hi Thomas, > > happy to know you agree to add that into the I-D, I will just hope/pray > the editors agree, :-) > > > The editors do what the WG consensus tells them to do. > > Chris made a proposal, for the WG to consider. > > Thomas > > AB > > On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen wrote: > >> ....and that description of Chris' might be something worth folding into >> the I-D? >> >> Thomas >> >> On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" < >> Chris.Dearlove@baesystems.com> wrote: >> >> > An attacker can spoof packets appearing to be from a router that skips >> some packet sequence numbers since the last packet sent by the router (a= nd >> received and analysed by the attacker). >> > >> > This may have an effect on an implementation of NHDP that uses those >> packet sequence numbers to recognise missing packets, and thus to change >> link quality. (There's no required use of the packet sequence number, an= d >> I'm fairly sure no other even suggested possible use.) >> > >> > This is an implementation of link quality that frankly isn't very good= . >> That's why in the translation from RFC 3626, where this is a formal opti= on, >> to NHDP, it got downgraded to a comment that it's something you can use = in >> specifying link quality should you want to. >> > >> > Now against an unprotected NHDP, even one using that mechanism, there >> are a lot of much more effective attacks that require less effort to mou= nt, >> using HELLO messages. >> > >> > So about the only case where this attack is worth mounting is when you >> know that the NHDP implementation has gone to the trouble of protecting >> messages, but is using a 5444 implementation that doesn't protect packet= s, >> and you know that it uses this packet sequence number in the way describ= ed, >> despite having gone to the effort of protecting messages. >> > >> > Or in other words it's a smart but stupid NHDP implementer. (He made >> two mistakes, using a poor link quality mechanism, and using something >> unprotected despite the work in protecting most things.) >> > >> > So it's rather specialised. And even in those circumstances I might (a= s >> the attacker) spend my effort on something else. >> > >> > -- >> > Christopher Dearlove >> > Senior Principal Engineer, Communications Group >> > Communications, Networks and Image Analysis Capability >> > BAE Systems Advanced Technology Centre >> > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> > Tel: +44 1245 242194 | Fax: +44 1245 242124 >> > chris.dearlove@baesystems.com | http://www.baesystems.com >> > >> > BAE Systems (Operations) Limited >> > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> > Registered in England & Wales No: 1996687 >> > >> > >> > -----Original Message----- >> > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >> Of Thomas Clausen >> > Sent: 26 February 2013 12:19 >> > To: Henning Rogge >> > Cc: manet@ietf.org >> > Subject: Re: [manet] I-D Action: >> draft-ietf-manet-nhdp-sec-threats-01.txt >> > >> > ----------------------! WARNING ! ---------------------- >> > This message originates from outside our organisation, >> > either from an external partner or from the internet. >> > Keep this in mind if you answer this message. >> > Follow the 'Report Suspicious Emails' link on IT matters >> > for instructions on reporting suspicious email messages. >> > -------------------------------------------------------- >> > >> > On Feb 26, 2013, at 1:08 PM, Henning Rogge < >> henning.rogge@fkie.fraunhofer.de> wrote: >> > >> >> Hi, >> >> >> >> so do we have an agreement that the old "sequence number attack" >> section of nhdp-threats-00 is wrong and must be removed because it >> describes something that does not apply to NHDP? >> >> >> >> If we (as a working group) decide we want a "sequence number attack" >> section in nhdp-threats, someone needs to write up a corresponding secti= on >> and we have to see if it gets consensus in the group. >> >> >> > >> > I believe that if there is a sequence number attack on NHDP, then it >> should be written down. >> > I also believe that I've not seen anything indicating that such an >> attack exists. >> > >> > That's what you're saying, isn't it? >> > >> >> Henning Rogge >> >> >> >> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: >> >>> your right thanks :) >> >>> AB >> >>> >> >>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge >> >>> > >>> > wrote: >> >>> >> >>> On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: >> >>> >> >>> I can only repeat it again: NHDP does *not* use sequence >> >>> numbers, >> >>> neither packet nor message sequence numbers. >> >>> >> >>> That is your opinion which I disagree, and disagree that the >> editors >> >>> removed the section of sequence number without consensus of WG= . >> >>> >> >>> >> >>> You know that the old section was plain WRONG, yes? >> >>> >> >>> (I suggest reading section 4.5 of nhdp-threats-00) >> >>> >> >>> Because the attack it described cannot happen to NHDP. >> >>> >> >>> If you want to get the "sequence number attack" paragraph back, >> >>> maybe you should write a new one... one that applies to NHDP. >> >>> >> >>> >> >>> Henning Rogge >> >>> >> >>> -- >> >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> >>> Kommunikationssysteme (KOM) >> >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> >>> Telefon +49 228 9435-961 , Fax +49 >> 228 >> >>> 9435 685 >> >>> mailto:henning.rogge@fkie.__fraunhofer.de >> >>> >> http://www.fkie.fraunhofer.de >> >>> >> >>> >> >>> _______________________________________________ >> >>> manet mailing list >> >>> manet@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/manet >> >>> >> >>> >> >> >> >> >> >> -- >> >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> >> Kommunikationssysteme (KOM) >> >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> >> >> _______________________________________________ >> >> 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 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 >> > > > --bcaec52becfd41bf4f04d6a2c515 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I made many proposals but=A0 not considered by editors,
=A0<= /div>
AB

On Tue, Feb 26, 2013 a= t 3:55 PM, Thomas Clausen <thomas@thomasclausen.org> = wrote:

On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun <abdussalambaryun@gmail.com= > wrote:

Hi Thomas,
= =A0
happy to know you agree to add that into the I-D, I will just hope/pra= y the editors agree, :-)

The ed= itors do what the WG consensus tells them to do.

Chris made a proposal, for the WG to consider.
=

Thomas
=

AB

On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen <thomas@thomasclaus= en.org> wrote:
....and that description of Chris' might be something = worth folding into the I-D?

Thomas

On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" <Chris.Dearl= ove@baesystems.com> wrote:

> An attacker can spoof packets appearing to be from a router that skips= some packet sequence numbers since the last packet sent by the router (and= received and analysed by the attacker).
>
> This may have an effect on an implementation of NHDP that uses those p= acket sequence numbers to recognise missing packets, and thus to change lin= k quality. (There's no required use of the packet sequence number, and = I'm fairly sure no other even suggested possible use.)
>
> This is an implementation of link quality that frankly isn't very = good. That's why in the translation from RFC 3626, where this is a form= al option, to NHDP, it got downgraded to a comment that it's something = you can use in specifying link quality should you want to.
>
> Now against an unprotected NHDP, even one using that mechanism, there = are a lot of much more effective attacks that require less effort to mount,= using HELLO messages.
>
> So about the only case where this attack is worth mounting is when you= know that the NHDP implementation has gone to the trouble of protecting me= ssages, but is using a 5444 implementation that doesn't protect packets= , and you know that it uses this packet sequence number in the way describe= d, despite having gone to the effort of protecting messages.
>
> Or in other words it's a smart but stupid NHDP implementer. (He ma= de two mistakes, using a poor link quality mechanism, and using something u= nprotected despite the work in protecting most things.)
>
> So it's rather specialised. And even in those circumstances I migh= t (as the attacker) spend my effort on something else.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
> chr= is.dearlove@baesystems.com | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> -----Original Message-----
> From: mane= t-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Clausen
> Sent: 26 February 2013 12:19
> To: Henning Rogge
> Cc: manet@ietf.org=
> Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.= txt
>
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> On Feb 26, 2013, at 1:08 PM, Henning Rogge <henning.rogge@fkie.fraunhofe= r.de> wrote:
>
>> Hi,
>>
>> so do we have an agreement that the old "sequence number atta= ck" section of nhdp-threats-00 is wrong and must be removed because it= describes something that does not apply to NHDP?
>>
>> If we (as a working group) decide we want a "sequence number = attack" section in nhdp-threats, someone needs to write up a correspon= ding section and we have to see if it gets consensus in the group.
>>
>
> I believe that if there is a sequence number attack on NHDP, then it s= hould be written down.
> I also believe that I've not seen anything indicating that such an= attack exists.
>
> That's what you're saying, isn't it?
>
>> Henning Rogge
>>
>> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote:
>>> your right thanks :)
>>> AB
>>>
>>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge
>>> <henning.rogge@fkie.fraunhofer.de
>>> <mailto:henning.rogge@fkie.fraunhofer.de>> wrote:
>>>
>>> =A0 On 02/26/2013 12:21 PM, Abdussalam Baryun wrote:
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0I can only repeat it again: NHDP does *= not* use sequence
>>> =A0 =A0 =A0 numbers,
>>> =A0 =A0 =A0 =A0 =A0 =A0neither packet nor message sequence num= bers.
>>>
>>> =A0 =A0 =A0 That is your opinion which I disagree, and disagre= e that the editors
>>> =A0 =A0 =A0 removed the section of sequence number without con= sensus of WG.
>>>
>>>
>>> =A0 You know that the old section was plain WRONG, yes?
>>>
>>> =A0 (I suggest reading section 4.5 of nhdp-threats-00)
>>>
>>> =A0 Because the attack it described cannot happen to NHDP.
>>>
>>> =A0 If you want to get the "sequence number attack" = paragraph back,
>>> =A0 maybe you should write a new one... one that applies to NH= DP.
>>>
>>>
>>> =A0 Henning Rogge
>>>
>>> =A0 --
>>> =A0 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f= =FCr
>>> =A0 Kommunikation, Informationsverarbeitung und Ergonomie FKIE=
>>> =A0 Kommunikationssysteme (KOM)
>>> =A0 Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>>> =A0 Telefon +49 228 9435-961 <tel:%2B49%20228%209= 435-961>, =A0 Fax +49 228
>>> =A0 9435 685 <tel:%2B49%20228%209435%20685>
>>> =A0 mailto:henning.rogge@fkie.__fraunhofer.de
>>> =A0 <mailto:henning.rogge@fkie.fraunhofer.de> http://www.fkie.fraunhofe= r.de
>>>
>>>
>>> =A0 _______________________________________________
>>> =A0 manet mailing list
>>> =A0 manet@= ietf.org <mailto:manet@ietf.org>
>>> =A0 https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>
>>
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM)
>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>> Telefon +49 228 9435-961, =A0 Fax +49 228 9435 6= 85
>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
>>
>> _______________________________________________
>> 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 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
h= ttps://www.ietf.org/mailman/listinfo/manet



--bcaec52becfd41bf4f04d6a2c515-- From abdussalambaryun@gmail.com Tue Feb 26 08:02:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94CB21F8921 for ; Tue, 26 Feb 2013 08:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS98N5TIqaTq for ; Tue, 26 Feb 2013 08:02:35 -0800 (PST) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id C543C21F8782 for ; Tue, 26 Feb 2013 08:02:35 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id kl14so2537900pab.4 for ; Tue, 26 Feb 2013 08:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KJ/yZPxea40i9FHyPPsTxuTf8+M9+iAwAcv/7M/Hnug=; b=xEP6Si90B+LwJ9dMjw4fHpPbWpu2KP6McFw4QGEhVUEBrY3+FL/wpgWl9+1fxCHXwn 8vRK4fVnP9p1b4BdfZ73FvssDL1NyCwNZ0umIUKYm+2u4SkCu1FlrzgKz93s9J39fbxL oV7vDOQENdr1sCCxjfXT6j36K3c6LoQKKvvc5/Jq9zAj1qD2FHqf1M7UXJ2mym+PIYY1 GC7/AAw4czu+uDJ0JWqkjgzmIKUTFmzaeq6eD7R47Co5GXCGWSqoGFrpuzgGrVPmzsdd KLeiEL+e8r4u5rM2pVAefDBZMD64dEfohT3tC3Iy8vwt86dhDQ5pXI6igVpV1Cp4ciAE sXjw== MIME-Version: 1.0 X-Received: by 10.68.217.2 with SMTP id ou2mr24424881pbc.6.1361894555183; Tue, 26 Feb 2013 08:02:35 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 08:02:35 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 16:02:35 +0000 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=e89a8ff2430b30c5b204d6a2c9f0 Cc: "manet@ietf.org" , Thomas Clausen Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:02:38 -0000 --e89a8ff2430b30c5b204d6a2c9f0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Chris, I know that it was not your proposal, it was Thomas's proposal and I support :-), AB On Tue, Feb 26, 2013 at 4:01 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > Just to be clear, I didn't make this as a proposal to be included - it's > a bit more colloquial than such text should be.**** > > ** ** > > I just made it as a statement of what (in my - fairly well informed - > opinion) the situation is.**** > > ** ** > > Of course as a contribution on the list the authors are free to make use > of it as a contribution should they wish. As I noted, if so I'd advise > rewording it a bit.**** > > ** ** > > -- **** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > ** ** > > *From:* Thomas Clausen [mailto:thomas@thomasclausen.org] > *Sent:* 26 February 2013 15:56 > *To:* Abdussalam Baryun > *Cc:* Dearlove, Christopher (UK); manet@ietf.org > > *Subject:* Re: [manet] I-D Action: > draft-ietf-manet-nhdp-sec-threats-01.txt**** > > ** ** > > ** ** > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.*** > * > > Keep this in mind if you answer this message. > Please see this processon how t= o deal with suspicious emails. > ***** > > ** ** > > On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun > wrote:**** > > > > **** > > Hi Thomas,**** > > **** > > happy to know you agree to add that into the I-D, I will just hope/pray > the editors agree, :-)**** > > ** ** > > The editors do what the WG consensus tells them to do.**** > > ** ** > > Chris made a proposal, for the WG to consider.**** > > ** ** > > Thomas**** > > > > **** > > AB**** > > ** ** > > On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen > wrote:**** > > ....and that description of Chris' might be something worth folding into > the I-D? > > Thomas**** > > > On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" < > Chris.Dearlove@baesystems.com> wrote: > > > An attacker can spoof packets appearing to be from a router that skips > some packet sequence numbers since the last packet sent by the router (an= d > received and analysed by the attacker). > > > > This may have an effect on an implementation of NHDP that uses those > packet sequence numbers to recognise missing packets, and thus to change > link quality. (There's no required use of the packet sequence number, and > I'm fairly sure no other even suggested possible use.) > > > > This is an implementation of link quality that frankly isn't very good. > That's why in the translation from RFC 3626, where this is a formal optio= n, > to NHDP, it got downgraded to a comment that it's something you can use i= n > specifying link quality should you want to. > > > > Now against an unprotected NHDP, even one using that mechanism, there > are a lot of much more effective attacks that require less effort to moun= t, > using HELLO messages. > > > > So about the only case where this attack is worth mounting is when you > know that the NHDP implementation has gone to the trouble of protecting > messages, but is using a 5444 implementation that doesn't protect packets= , > and you know that it uses this packet sequence number in the way describe= d, > despite having gone to the effort of protecting messages. > > > > Or in other words it's a smart but stupid NHDP implementer. (He made tw= o > mistakes, using a poor link quality mechanism, and using something > unprotected despite the work in protecting most things.) > > > > So it's rather specialised. And even in those circumstances I might (as > the attacker) spend my effort on something else. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Thomas Clausen > > Sent: 26 February 2013 12:19 > > To: Henning Rogge > > Cc: manet@ietf.org > > Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.t= xt > > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > > On Feb 26, 2013, at 1:08 PM, Henning Rogge < > henning.rogge@fkie.fraunhofer.de> wrote: > > > >> Hi, > >> > >> so do we have an agreement that the old "sequence number attack" > section of nhdp-threats-00 is wrong and must be removed because it > describes something that does not apply to NHDP? > >> > >> If we (as a working group) decide we want a "sequence number attack" > section in nhdp-threats, someone needs to write up a corresponding sectio= n > and we have to see if it gets consensus in the group. > >> > > > > I believe that if there is a sequence number attack on NHDP, then it > should be written down. > > I also believe that I've not seen anything indicating that such an > attack exists. > > > > That's what you're saying, isn't it? > > > >> Henning Rogge > >> > >> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: > >>> your right thanks :) > >>> AB > >>> > >>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge > >>> >>> > wrote: > >>> > >>> On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: > >>> > >>> I can only repeat it again: NHDP does *not* use sequence > >>> numbers, > >>> neither packet nor message sequence numbers. > >>> > >>> That is your opinion which I disagree, and disagree that the > editors > >>> removed the section of sequence number without consensus of WG. > >>> > >>> > >>> You know that the old section was plain WRONG, yes? > >>> > >>> (I suggest reading section 4.5 of nhdp-threats-00) > >>> > >>> Because the attack it described cannot happen to NHDP. > >>> > >>> If you want to get the "sequence number attack" paragraph back, > >>> maybe you should write a new one... one that applies to NHDP. > >>> > >>> > >>> Henning Rogge > >>> > >>> -- > >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >>> Kommunikationssysteme (KOM) > >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >>> Telefon +49 228 9435-961 , Fax +49 22= 8 > >>> 9435 685 > >>> mailto:henning.rogge@fkie.__fraunhofer.de > >>> > http://www.fkie.fraunhofer.de > >>> > >>> > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >>> > >>> > >> > >> > >> -- > >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >> Kommunikationssysteme (KOM) > >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >> Telefon +49 228 9435-961, Fax +49 228 9435 685 > >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > >> > >> _______________________________________________ > >> 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 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**** > > ** ** > > ** ** > --e89a8ff2430b30c5b204d6a2c9f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chris,
=A0
I know that it was not your proposal= , it was Thomas's proposal and I support=A0:-),
=A0
AB


--e89a8ff2430b30c5b204d6a2c9f0-- From thomas@thomasclausen.org Tue Feb 26 08:05:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C41D21F853D for ; Tue, 26 Feb 2013 08:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07njFWoVL0Bq for ; Tue, 26 Feb 2013 08:05:36 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8F66F21F8858 for ; Tue, 26 Feb 2013 08:05:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 2C1AF1C03D9; Tue, 26 Feb 2013 08:05:31 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 064431C03B5; Tue, 26 Feb 2013 08:05:28 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_17043DA0-2BD6-4A2E-8588-7C45A24F1A4A" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Clausen In-Reply-To: Date: Tue, 26 Feb 2013 17:05:26 +0100 Message-Id: <7BB587F4-D0AC-44C3-A0BE-654DAD2FB5E5@thomasclausen.org> References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:05:38 -0000 --Apple-Mail=_17043DA0-2BD6-4A2E-8588-7C45A24F1A4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 26, 2013, at 5:01 PM, "Dearlove, Christopher (UK)" = wrote: > Just to be clear, I didn't make this as a proposal to be included - = it's a bit more colloquial than such text should be. > =20 > I just made it as a statement of what (in my - fairly well informed - = opinion) the situation is. > =20 > Of course as a contribution on the list the authors are free to make = use of it as a contribution should they wish. As I noted, if so I'd = advise rewording it a bit. Speaking as one of the authors of this document, the above is quite = understood. Having concrete text such as what you wrote, with a concrete = example given, makes the task easy. > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > =20 > From: Thomas Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 26 February 2013 15:56 > To: Abdussalam Baryun > Cc: Dearlove, Christopher (UK); manet@ietf.org > Subject: Re: [manet] I-D Action: = draft-ietf-manet-nhdp-sec-threats-01.txt > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Keep this in mind if you answer this message. > Please see this process on how to deal with suspicious emails. >=20 > =20 > On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun = wrote: >=20 >=20 > Hi Thomas, > =20 > happy to know you agree to add that into the I-D, I will just = hope/pray the editors agree, :-) > =20 > The editors do what the WG consensus tells them to do. > =20 > Chris made a proposal, for the WG to consider. > =20 > Thomas >=20 >=20 > AB > =20 > On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen = wrote: > ....and that description of Chris' might be something worth folding = into the I-D? >=20 > Thomas >=20 > On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" = wrote: >=20 > > An attacker can spoof packets appearing to be from a router that = skips some packet sequence numbers since the last packet sent by the = router (and received and analysed by the attacker). > > > > This may have an effect on an implementation of NHDP that uses those = packet sequence numbers to recognise missing packets, and thus to change = link quality. (There's no required use of the packet sequence number, = and I'm fairly sure no other even suggested possible use.) > > > > This is an implementation of link quality that frankly isn't very = good. That's why in the translation from RFC 3626, where this is a = formal option, to NHDP, it got downgraded to a comment that it's = something you can use in specifying link quality should you want to. > > > > Now against an unprotected NHDP, even one using that mechanism, = there are a lot of much more effective attacks that require less effort = to mount, using HELLO messages. > > > > So about the only case where this attack is worth mounting is when = you know that the NHDP implementation has gone to the trouble of = protecting messages, but is using a 5444 implementation that doesn't = protect packets, and you know that it uses this packet sequence number = in the way described, despite having gone to the effort of protecting = messages. > > > > Or in other words it's a smart but stupid NHDP implementer. (He made = two mistakes, using a poor link quality mechanism, and using something = unprotected despite the work in protecting most things.) > > > > So it's rather specialised. And even in those circumstances I might = (as the attacker) spend my effort on something else. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Thomas Clausen > > Sent: 26 February 2013 12:19 > > To: Henning Rogge > > Cc: manet@ietf.org > > Subject: Re: [manet] I-D Action: = draft-ietf-manet-nhdp-sec-threats-01.txt > > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > > On Feb 26, 2013, at 1:08 PM, Henning Rogge = wrote: > > > >> Hi, > >> > >> so do we have an agreement that the old "sequence number attack" = section of nhdp-threats-00 is wrong and must be removed because it = describes something that does not apply to NHDP? > >> > >> If we (as a working group) decide we want a "sequence number = attack" section in nhdp-threats, someone needs to write up a = corresponding section and we have to see if it gets consensus in the = group. > >> > > > > I believe that if there is a sequence number attack on NHDP, then it = should be written down. > > I also believe that I've not seen anything indicating that such an = attack exists. > > > > That's what you're saying, isn't it? > > > >> Henning Rogge > >> > >> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: > >>> your right thanks :) > >>> AB > >>> > >>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge > >>> >>> > wrote: > >>> > >>> On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: > >>> > >>> I can only repeat it again: NHDP does *not* use = sequence > >>> numbers, > >>> neither packet nor message sequence numbers. > >>> > >>> That is your opinion which I disagree, and disagree that the = editors > >>> removed the section of sequence number without consensus of = WG. > >>> > >>> > >>> You know that the old section was plain WRONG, yes? > >>> > >>> (I suggest reading section 4.5 of nhdp-threats-00) > >>> > >>> Because the attack it described cannot happen to NHDP. > >>> > >>> If you want to get the "sequence number attack" paragraph back, > >>> maybe you should write a new one... one that applies to NHDP. > >>> > >>> > >>> Henning Rogge > >>> > >>> -- > >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >>> Kommunikationssysteme (KOM) > >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >>> Telefon +49 228 9435-961 , Fax +49 = 228 > >>> 9435 685 > >>> mailto:henning.rogge@fkie.__fraunhofer.de > >>> = http://www.fkie.fraunhofer.de > >>> > >>> > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >>> > >>> > >> > >> > >> -- > >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >> Kommunikationssysteme (KOM) > >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > >> Telefon +49 228 9435-961, Fax +49 228 9435 685 > >> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de > >> > >> _______________________________________________ > >> 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 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. > > ******************************************************************** > > >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_17043DA0-2BD6-4A2E-8588-7C45A24F1A4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

= --Apple-Mail=_17043DA0-2BD6-4A2E-8588-7C45A24F1A4A-- From Chris.Dearlove@baesystems.com Tue Feb 26 08:06:46 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CD121F853D for ; Tue, 26 Feb 2013 08:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KszJ45SO-Zl1 for ; Tue, 26 Feb 2013 08:06:46 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id B869F21F8960 for ; Tue, 26 Feb 2013 08:06:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208,217";a="314943286" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Feb 2013 16:06:13 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r1QG6DdC027975 for ; Tue, 26 Feb 2013 16:06:13 GMT X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208,217";a="9078704" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 26 Feb 2013 16:06:13 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 16:06:13 +0000 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] [Technical Errata Reported] RFC5444 (3496) Thread-Index: AQHOE2tYWHRmgACwIkuCTgQkaOcmyZiMLwoAgAADeICAAAqUAIAAA6kAgAAKRICAAAEjwIAAAa4AgAABR3A= Date: Tue, 26 Feb 2013 16:06:12 +0000 Message-ID: References: <20130225151705.EB129B1E008@rfc-editor.org> <512CC517.20404@fkie.fraunhofer.de> <413400E5-1352-4437-9E07-C47875875665@thomasclausen.org> 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D250268A9GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "manet@ietf.org" , Thomas Heide Clausen Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:06:47 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D250268A9GLKXM0002VGREEN_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It's a waste of time beating a dead horse. Make a comment, if no one respon= ds, it doesn't have traction. This doesn't appear to have traction. And wil= l only even start to get it is someone other than you makes a comment. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 26 February 2013 16:00 To: Dearlove, Christopher (UK) Cc: Thomas Heide Clausen; manet@ietf.org Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. There is no harm in discussing, issues related to NHDP or RFC5444, or errat= as, even after they were publish as we all know they are Request For Commen= ts, AB On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) > wrote: NHDP has made it to RFC, and OLSRv2 has made it to one AD short of RFC - an= d not for any related reason - without anyone thinking "we really should us= e that because it might be there - though it also might not". Which suggest= s your technical answer is wrong. And anyway, procedurally it's multiple st= eps too late. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Abdussalam Bar= yun Sent: 26 February 2013 15:50 To: Thomas Heide Clausen Cc: manet@ietf.org Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen > wrote: On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun > wrote: I like that protocols use the packet sequence number, if thoes protocols yo= u refered to don't use the packet SQN, then I recommend they reconsider. Why? "Like" is not a technical argument. I agree that it not a technical word, but also agree that *like* can be use= d in technical volunteer discussions. For example; Why OLSRv2 protocol does= not use the packet sequence number SQN? does it accept random packets and = ignore to sense sequence packets? Why the designers like it to be that way?= Why does AB like protocols to sense SQN? My technical answer is better if it got into a technical draft, however, if= a protocol senses the SQN it will be more rebust and more organised in MAN= ET communication. AB ******************************************************************** 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. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D250268A9GLKXM0002VGREEN_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It's a waste of time beat= ing a dead horse. Make a comment, if no one responds, it doesn't have tract= ion. This doesn't appear to have traction. And will only even start to get it is someone other than you makes a comment.=

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 26 February 2013 16:00
To: Dearlove, Christopher (UK)
Cc: Thomas Heide Clausen; manet@ietf.org
Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)=

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

There is no harm in discussing, issues related to NH= DP or RFC5444, or erratas, even after they were publish as we all know= they are Request For Comments,

 

AB

On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christoph= er (UK) <Chris.Dearlove@baesystems.com> wrote:

NHDP has made it to RFC, and OLSRv2 has= made it to one AD short of RFC - and not for any related reason - without anyone thinking "we really should use that because i= t might be there - though it also might not". Which suggests your tech= nical answer is wrong. And anyway, procedurally it's multiple steps too lat= e.

 

--

Christopher Dearlove<= /p>

Senior Principal Engineer, Communicatio= ns Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 2= 42194 |  Fax: +44 1245 242124=

chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: manet-bounces@i= etf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:50
To: Thomas Heide Clausen
Cc: manet@ietf.o= rg


Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)=

 

 =

*** WARNING ***

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen <thomas@thomasclausen= .org> wrote:

 

On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com&= gt; wrote:

I like that protocols use the packet sequence number, if thoes pro= tocols you refered to don't use the packet SQN, then I recommend they recon= sider.

 

Why?

 

"Like" is not a technical argument.

 

 

I agree that it not a technical word, but also agree that *like*&n= bsp;can be used in technical volunteer discussions. For example; Why OLSRv2= protocol does not use the packet sequence number SQN? does it accept random packets and ignore to sense sequenc= e packets? Why the designers like it to be that way? Why does AB like proto= cols to sense SQN?

 

My technical answer is better if it got into a technical draft, ho= wever, if a protocol senses the SQN it will be more rebust and more organis= ed in MANET communication.

 

AB

 

*********************= ***********************************************
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.
********************************************************************

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D250268A9GLKXM0002VGREEN_-- From Chris.Dearlove@baesystems.com Tue Feb 26 08:10:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCDD21F87D5 for ; Tue, 26 Feb 2013 08:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycL7popIQapb for ; Tue, 26 Feb 2013 08:10:20 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE2721F8757 for ; Tue, 26 Feb 2013 08:10:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208,217";a="314945002" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Feb 2013 16:10:18 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r1QGAIoa001097 for ; Tue, 26 Feb 2013 16:10:18 GMT X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208,217";a="9079434" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 26 Feb 2013 16:10:18 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 16:10:18 +0000 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , Thomas Clausen Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt Thread-Index: AQHOFBnzQcK/1dKC6UukRyjp9E9HrJiMDrMAgAAzSfCAAAT3gIAAA3uAgAAA4gCAAAGPgIAAAWgw Date: Tue, 26 Feb 2013 16:10:18 +0000 Message-ID: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512C9EBB.3060902@fkie.fraunhofer.de> 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D250268C6GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:10:22 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D250268C6GLKXM0002VGREEN_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You mean not implemented by editors. Different thing. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 26 February 2013 16:01 To: Thomas Clausen Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. I made many proposals but not considered by editors, AB On Tue, Feb 26, 2013 at 3:55 PM, Thomas Clausen > wrote: On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun > wrote: Hi Thomas, happy to know you agree to add that into the I-D, I will just hope/pray the= editors agree, :-) The editors do what the WG consensus tells them to do. Chris made a proposal, for the WG to consider. Thomas AB On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen > wrote: ....and that description of Chris' might be something worth folding into th= e I-D? Thomas On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" > wrote: > An attacker can spoof packets appearing to be from a router that skips so= me packet sequence numbers since the last packet sent by the router (and re= ceived and analysed by the attacker). > > This may have an effect on an implementation of NHDP that uses those pack= et sequence numbers to recognise missing packets, and thus to change link q= uality. (There's no required use of the packet sequence number, and I'm fai= rly sure no other even suggested possible use.) > > This is an implementation of link quality that frankly isn't very good. T= hat's why in the translation from RFC 3626, where this is a formal option, = to NHDP, it got downgraded to a comment that it's something you can use in = specifying link quality should you want to. > > Now against an unprotected NHDP, even one using that mechanism, there are= a lot of much more effective attacks that require less effort to mount, us= ing HELLO messages. > > So about the only case where this attack is worth mounting is when you kn= ow that the NHDP implementation has gone to the trouble of protecting messa= ges, but is using a 5444 implementation that doesn't protect packets, and y= ou know that it uses this packet sequence number in the way described, desp= ite having gone to the effort of protecting messages. > > Or in other words it's a smart but stupid NHDP implementer. (He made two = mistakes, using a poor link quality mechanism, and using something unprotec= ted despite the work in protecting most things.) > > So it's rather specialised. And even in those circumstances I might (as t= he attacker) spend my effort on something else. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | htt= p://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet= -bounces@ietf.org] On Behalf Of Thomas Claus= en > Sent: 26 February 2013 12:19 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > On Feb 26, 2013, at 1:08 PM, Henning Rogge > wrote: > >> Hi, >> >> so do we have an agreement that the old "sequence number attack" section= of nhdp-threats-00 is wrong and must be removed because it describes somet= hing that does not apply to NHDP? >> >> If we (as a working group) decide we want a "sequence number attack" sec= tion in nhdp-threats, someone needs to write up a corresponding section and= we have to see if it gets consensus in the group. >> > > I believe that if there is a sequence number attack on NHDP, then it shou= ld be written down. > I also believe that I've not seen anything indicating that such an attack= exists. > > That's what you're saying, isn't it? > >> Henning Rogge >> >> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote: >>> your right thanks :) >>> AB >>> >>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge >>> >>> >> wrote: >>> >>> On 02/26/2013 12:21 PM, Abdussalam Baryun wrote: >>> >>> I can only repeat it again: NHDP does *not* use sequence >>> numbers, >>> neither packet nor message sequence numbers. >>> >>> That is your opinion which I disagree, and disagree that the edit= ors >>> removed the section of sequence number without consensus of WG. >>> >>> >>> You know that the old section was plain WRONG, yes? >>> >>> (I suggest reading section 4.5 of nhdp-threats-00) >>> >>> Because the attack it described cannot happen to NHDP. >>> >>> If you want to get the "sequence number attack" paragraph back, >>> maybe you should write a new one... one that applies to NHDP. >>> >>> >>> Henning Rogge >>> >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961 , Fax +49 228 >>> 9435 685 >>> mailto:henning.rogge@fkie.__fraunhofer.de= >>> > http://www.fkie.fraunhofer.de >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >> >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435= 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> >> _______________________________________________ >> 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 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 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D250268C6GLKXM0002VGREEN_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

You mean not implemented = by editors. Different thing.

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 26 February 2013 16:01
To: Thomas Clausen
Cc: Dearlove, Christopher (UK); manet@ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-0= 1.txt

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

I made many proposals but  not considered by ed= itors,

 

AB

On Tue, Feb 26, 2013 at 3:55 PM, Thomas Clausen <= thomas@thomas= clausen.org> wrote:

 

On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun <<= a href=3D"mailto:abdussalambaryun@gmail.com" target=3D"_blank">abdussalamba= ryun@gmail.com> wrote:



Hi Thomas,

 

happy to know you agree to add that into the I-D, I = will just hope/pray the editors agree, :-)

 

The editors do what the WG consensus tells them to d= o.

 

Chris made a proposal, for the WG to consider.<= /o:p>

 

Thomas



AB

 

On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen <= thomas@thomas= clausen.org> wrote:

....and that description of Chris' might be somethin= g worth folding into the I-D?

Thomas


On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" <Chris.Dearl= ove@baesystems.com> wrote:

> An attacker can spoof packets appearing to be from a router that skips= some packet sequence numbers since the last packet sent by the router (and= received and analysed by the attacker).
>
> This may have an effect on an implementation of NHDP that uses those p= acket sequence numbers to recognise missing packets, and thus to change lin= k quality. (There's no required use of the packet sequence number, and I'm = fairly sure no other even suggested possible use.)
>
> This is an implementation of link quality that frankly isn't very good= . That's why in the translation from RFC 3626, where this is a formal optio= n, to NHDP, it got downgraded to a comment that it's something you can use = in specifying link quality should you want to.
>
> Now against an unprotected NHDP, even one using that mechanism, there = are a lot of much more effective attacks that require less effort to mount,= using HELLO messages.
>
> So about the only case where this attack is worth mounting is when you= know that the NHDP implementation has gone to the trouble of protecting me= ssages, but is using a 5444 implementation that doesn't protect packets, an= d you know that it uses this packet sequence number in the way described, despite having gone to the effort of= protecting messages.
>
> Or in other words it's a smart but stupid NHDP implementer. (He made t= wo mistakes, using a poor link quality mechanism, and using something unpro= tected despite the work in protecting most things.)
>
> So it's rather specialised. And even in those circumstances I might (a= s the attacker) spend my effort on something else.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1= 245 242194 |  Fax: +44 1245 242124=
> chr= is.dearlove@baesystems.com | http://www.baesyst= ems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> -----Original Message-----
> From: mane= t-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Clausen
> Sent: 26 February 2013 12:19
> To: Henning Rogge
> Cc: manet@ietf.org=
> Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.= txt
>
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> On Feb 26, 2013, at 1:08 PM, Henning Rogge <henning.rogge@fkie.fraunhofe= r.de> wrote:
>
>> Hi,
>>
>> so do we have an agreement that the old "sequence number atta= ck" section of nhdp-threats-00 is wrong and must be removed because it= describes something that does not apply to NHDP?
>>
>> If we (as a working group) decide we want a "sequence number = attack" section in nhdp-threats, someone needs to write up a correspon= ding section and we have to see if it gets consensus in the group.
>>
>
> I believe that if there is a sequence number attack on NHDP, then it s= hould be written down.
> I also believe that I've not seen anything indicating that such an att= ack exists.
>
> That's what you're saying, isn't it?
>
>> Henning Rogge
>>
>> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote:
>>> your right thanks :)
>>> AB
>>>
>>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge
>>> <henning.rogge@fkie.fraunhofer.de
>>> <mailto:henning.rogge@fkie.fraunhofer.de>> wrote:
>>>
>>>   On 02/26/2013 12:21 PM, Abdussalam Baryun wrote:
>>>
>>>            I can only repeat it = again: NHDP does *not* use sequence
>>>       numbers,
>>>            neither packet nor me= ssage sequence numbers.
>>>
>>>       That is your opinion which I disagree, an= d disagree that the editors
>>>       removed the section of sequence number wi= thout consensus of WG.
>>>
>>>
>>>   You know that the old section was plain WRONG, yes?
>>>
>>>   (I suggest reading section 4.5 of nhdp-threats-00)
>>>
>>>   Because the attack it described cannot happen to NHDP.<= br> >>>
>>>   If you want to get the "sequence number attack&quo= t; paragraph back,
>>>   maybe you should write a new one... one that applies to= NHDP.
>>>
>>>
>>>   Henning Rogge
>>>
>>>   --
>>>   Diplom-Informatiker Henning Rogge , Fraunhofer-Institut= f=FCr
>>>   Kommunikation, Informationsverarbeitung und Ergonomie F= KIE
>>>   Kommunikationssysteme (KOM)
>>>   Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>>>   Telefon +49 228 9435-961 <tel:%2B49%20228%209435-961>, &n= bsp; Fax +49 228
>>>   9435 685 <tel:%2B49%20228%209435%20685>
>>>   mailto:henning.rogge@fkie.__fraunhofer.de
>>>   <mailto:henning.rogge@fkie.fraunhofer.de> http://www.fki= e.fraunhofer.de
>>>
>>>
>>>   _______________________________________________
>>>   manet mailing list
>>>   man= et@ietf.org <mailto:manet@ietf.org>
>>>   https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>
>>
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM)
>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>> Telefon &= #43;49 228 9435-961,   Fax +49 228 9435= 685
>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fki= e.fraunhofer.de
>>
>> _______________________________________________
>> 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 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
h= ttps://www.ietf.org/mailman/listinfo/manet

 

 

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D250268C6GLKXM0002VGREEN_-- From drdanhe@gmail.com Tue Feb 26 08:10:49 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD4D21F88AC for ; Tue, 26 Feb 2013 08:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLeFyD3XGyMA for ; Tue, 26 Feb 2013 08:10:48 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id F359221F8899 for ; Tue, 26 Feb 2013 08:10:47 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k11so4682607iea.10 for ; Tue, 26 Feb 2013 08:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/FGZ4w8JUI908QWbD8BbtCXI57CnPdisJw1b+Y4xApU=; b=g3G0+uP5MSp44OQ7H8Dd+zofr8kQuzuPKyHWwAeX9qJqnT/6IkGRgI0jbuf/FiPNIu Y/pI0qzsb25XQ1J5gYUPStM6YeWXD+rJV+EMiUmWEDDQ3v5jcs5oJmRbQmn63Keifzsk vDls2O3bqD0RrhmIkhSe3pUC1IeIiq9EjldVcp9LBHapZaKIINNT1XbsbyYsNa3gxP+7 vLf1vkMiFk52xKdMsXaxkGVDw+YmfWLQKNGZnY5NX6Bp5SFryZItr+pf34BVN94/S8Wh H+oTeMYECWc7UPthSl7UjqI3Qxpr/id+HW9BudL41+VtwvV80+gsn2l4aNm0OFTp8t/O 9mbw== MIME-Version: 1.0 X-Received: by 10.50.191.133 with SMTP id gy5mr5870663igc.50.1361895040586; Tue, 26 Feb 2013 08:10:40 -0800 (PST) Received: by 10.50.85.6 with HTTP; Tue, 26 Feb 2013 08:10:40 -0800 (PST) In-Reply-To: References: <20130225151705.EB129B1E008@rfc-editor.org> <512CC517.20404@fkie.fraunhofer.de> <413400E5-1352-4437-9E07-C47875875665@thomasclausen.org> Date: Tue, 26 Feb 2013 16:10:40 +0000 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=14dae93407191d998104d6a2e68d Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Thomas Heide Clausen Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:10:49 -0000 --14dae93407191d998104d6a2e68d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is no good to discuss on the mailing list if it is not technical relevant. Otherwise, we received too many useless emails without any technical information. It is not a BBS website. On 26 February 2013 16:00, Abdussalam Baryun wr= ote: > There is no harm in discussing, issues related to NHDP or RFC5444, or > erratas, even after they were publish as we all know they are Request For > Comments, > > AB > > On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> wrote: > >> NHDP has made it to RFC, and OLSRv2 has made it to one AD short of RFC >> - and not for any related reason - without anyone thinking "we really >> should use that because it might be there - though it also might not". >> Which suggests your technical answer is wrong. And anyway, procedurally >> it's multiple steps too late.**** >> >> ** ** >> >> -- **** >> >> Christopher Dearlove**** >> >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >> >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687**** >> >> ** ** >> >> *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On >> Behalf Of *Abdussalam Baryun >> *Sent:* 26 February 2013 15:50 >> *To:* Thomas Heide Clausen >> *Cc:* manet@ietf.org >> >> *Subject:* Re: [manet] [Technical Errata Reported] RFC5444 (3496)**** >> >> ** ** >> >> ** ** >> >> **** WARNING **** >> >> *This message originates from outside our organisation, either from an >> external partner or the internet.** >> Keep this in mind if you answer this message. >> Please see this processon how = to deal with suspicious emails. >> ***** >> >> On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen < >> thomas@thomasclausen.org> wrote:**** >> >> ** ** >> >> On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun >> wrote:**** >> >> I like that protocols use the packet sequence number, if thoes >> protocols you refered to don't use the packet SQN, then I recommend they >> reconsider.**** >> >> ** ** >> >> Why?**** >> >> ** ** >> >> "Like" is not a technical argument.**** >> >> ** ** >> >> **** >> >> I agree that it not a technical word, but also agree that *like* can be >> used in technical volunteer discussions. For example; Why OLSRv2 protoco= l >> does not use the packet sequence number SQN? does it accept random packe= ts >> and ignore to sense sequence packets? Why the designers like it to be th= at >> way? Why does AB like protocols to sense SQN?**** >> >> **** >> >> My technical answer is better if it got into a technical draft, however, >> if a protocol senses the SQN it will be more rebust and more organised >> in MANET communication.**** >> >> **** >> >> AB**** >> >> >> ******************************************************************** >> 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 > > --=20 Dan He --------------------- openstack contributor GPU stream programming http://wiki.openstack.org/Contributors Tel: +44-788-686-3428 --14dae93407191d998104d6a2e68d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is no good to discuss on the mailing list if it is not technical relevan= t. Otherwise, we received too many useless emails without any technical inf= ormation. It is not a BBS
website.



On 26 February 2013 16:00, Abdussalam Baryun <abdussalambaryun@g= mail.com> wrote:
There is no harm in discussing, issues related to NHDP or RFC5444, or = erratas,=A0even after they were publish as we all know they are Request For= Comments,
=A0
AB

On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) <C= hris.Dearlove@baesystems.com> wrote:

NHDP has made it to = RFC, and OLSRv2 has made it to one AD short of RFC - and not for any relate= d reason - without anyone thinking "we really should use that because it might be there - though it also might not". Which suggests= your technical answer is wrong. And anyway, procedurally it's multiple= steps too late.

=A0

--

Christopher Dearlove=

Senior Principal Eng= ineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124=

chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:50
To: Thomas Heide Clausen
Cc: manet@ietf.o= rg


Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)

=A0

=A0

*** WARNING ***<= /span>

This message originates from outside our= organisation, either from an external partner or the internet.<= i>
Kee= p this in mind if you answer this message.
Ple= ase see this process on how to deal with suspicious emails.

On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clause= n <thomas@= thomasclausen.org> wrote:

=A0

On 26 f=E9vr. 2013, at = 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I like that protocols use the packet sequence number= , if thoes protocols you refered to don't use the packet SQN, then I re= commend they reconsider.

=A0

Why?

=A0

"Like" is not a technical argument.=

=A0=

=A0

I agree that it not a technical word, but also agree= that *like*=A0can be used in technical volunteer discussions. For example;= Why OLSRv2 protocol does not use the packet sequence number SQN? does it a= ccept random packets and ignore to sense=A0sequence packets? Why the designers like it to be that way? Why does AB like protoc= ols to sense SQN?

=A0

My technical answer is better if it got into a techn= ical draft, however, if a protocol senses the SQN it will be more rebust an= d more organised in=A0MANET communication.

=A0

AB


********************************************************************
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
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Dan He
---------= ------------
openstack contributor
GPU stream programming

http://wik= i.openstack.org/Contributors

Tel: +44-788-686-3428
--14dae93407191d998104d6a2e68d-- From abdussalambaryun@gmail.com Tue Feb 26 08:16:34 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AEE21F88EE for ; Tue, 26 Feb 2013 08:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZupJ7XLE-lIc for ; Tue, 26 Feb 2013 08:16:33 -0800 (PST) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 237E221F88E6 for ; Tue, 26 Feb 2013 08:16:31 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id ma3so2455276pbc.39 for ; Tue, 26 Feb 2013 08:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=CMDzzbeuP8EHMfRn4IdXvEUSnMrDkpFZbV3dj67zh+g=; b=ufKX2rMMBO5BckgiTlbFEgJ4DdLXujRnDdve/6e3lY8IVb/W+34egFQqc9SCFD8nJx vyrbrm5DQAz7ymjsUM7yb8QS3ZTsngHDiBe+aYF/x3ZSXhvIXIKTkPINr6Rv05DqGY+0 2hYS0QCioNdftU+GTY3+/Ua2lLBr8rQQDpNGd3J36l2S74sl5pFSh7VNWHK+M6DmtDcf xarH3lOud1bgjOeXL6Eq1CRC7ZUyA4KR30JN0YJwHhSsDQ5uk/hRQo6e/st+cm1MssfH cVtkdVRFUqkBR9v4ki/N5fAZj7LcCz27D6pcGD6wrqal5OskQgQfjU48XC1GpjxLdtEB qC0g== MIME-Version: 1.0 X-Received: by 10.68.28.194 with SMTP id d2mr23838441pbh.215.1361895390895; Tue, 26 Feb 2013 08:16:30 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 08:16:30 -0800 (PST) Date: Tue, 26 Feb 2013 16:16:30 +0000 Message-ID: From: Abdussalam Baryun To: Daniel He Content-Type: multipart/alternative; boundary=bcaec5216263feeb1104d6a2fa48 Cc: "manet@ietf.org" Subject: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:16:34 -0000 --bcaec5216263feeb1104d6a2fa48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No one have right to try to discourage inputs, discussions are what this list is for. I know that editors don't like comments, but they have to live with it. For others that don't author work, please just do your job (not to comment on numbers of posts/input, or time spend) or keep quite, AB On Tue, Feb 26, 2013 at 4:10 PM, Daniel He wrote: > It is no good to discuss on the mailing list if it is not technical > relevant. Otherwise, we received too many useless emails without any > technical information. It is not a BBS > website. > > > > On 26 February 2013 16:00, Abdussalam Baryun = wrote: > >> There is no harm in discussing, issues related to NHDP or RFC5444, or >> erratas, even after they were publish as we all know they are Request Fo= r >> Comments, >> >> AB >> >> On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) < >> Chris.Dearlove@baesystems.com> wrote: >> >>> NHDP has made it to RFC, and OLSRv2 has made it to one AD short of RFC >>> - and not for any related reason - without anyone thinking "we really >>> should use that because it might be there - though it also might not". >>> Which suggests your technical answer is wrong. And anyway, procedurally >>> it's multiple steps too late.**** >>> >>> ** ** >>> >>> -- **** >>> >>> Christopher Dearlove**** >>> >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >>> >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>> Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687**** >>> >>> ** ** >>> >>> *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On >>> Behalf Of *Abdussalam Baryun >>> *Sent:* 26 February 2013 15:50 >>> *To:* Thomas Heide Clausen >>> *Cc:* manet@ietf.org >>> >>> *Subject:* Re: [manet] [Technical Errata Reported] RFC5444 (3496)**** >>> >>> ** ** >>> >>> ** ** >>> >>> **** WARNING **** >>> >>> *This message originates from outside our organisation, either from an >>> external partner or the internet.** >>> Keep this in mind if you answer this message. >>> Please see this processon how= to deal with suspicious emails. >>> ***** >>> >>> On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen < >>> thomas@thomasclausen.org> wrote:**** >>> >>> ** ** >>> >>> On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun < >>> abdussalambaryun@gmail.com> wrote:**** >>> >>> I like that protocols use the packet sequence number, if thoes >>> protocols you refered to don't use the packet SQN, then I recommend the= y >>> reconsider.**** >>> >>> ** ** >>> >>> Why?**** >>> >>> ** ** >>> >>> "Like" is not a technical argument.**** >>> >>> ** ** >>> >>> **** >>> >>> I agree that it not a technical word, but also agree that *like* can be >>> used in technical volunteer discussions. For example; Why OLSRv2 protoc= ol >>> does not use the packet sequence number SQN? does it accept random pack= ets >>> and ignore to sense sequence packets? Why the designers like it to be t= hat >>> way? Why does AB like protocols to sense SQN?**** >>> >>> **** >>> >>> My technical answer is better if it got into a technical draft, however= , >>> if a protocol senses the SQN it will be more rebust and more organised >>> in MANET communication.**** >>> >>> **** >>> >>> AB**** >>> >>> >>> ******************************************************************** >>> 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 >> >> > > > -- > Dan He > --------------------- > openstack contributor > GPU stream programming > > http://wiki.openstack.org/Contributors > > Tel: +44-788-686-3428 > --bcaec5216263feeb1104d6a2fa48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
No one have right to try to discourage inputs, discussions are what th= is list=A0is for. I know that editors don't like comments, but they hav= e to live with it. For others that don't author work, please just do yo= ur job (not to comment on numbers of posts/input, or time spend)=A0or keep = quite,
=A0
AB

On Tue, Feb 2= 6, 2013 at 4:10 PM, Daniel He <drdanhe@gmail.com> wrote:
=
It is no good to discuss on the mailing list if it is not technical relevan= t. Otherwise, we received too many useless emails without any technical inf= ormation. It is not a BBS
website.



On 26 February 2013 16:00, Abdussalam Baryun <abdussalambaryun@g= mail.com> wrote:
There is no harm in discussing, issues related to NHDP or RFC5444, or = erratas,=A0even after they were publish as we all know they are Request For= Comments,
=A0
AB

On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) <C= hris.Dearlove@baesystems.com> wrote:

NHDP has made it to = RFC, and OLSRv2 has made it to one AD short of RFC - and not for any relate= d reason - without anyone thinking "we really should use that because it might be there - though it also might not". Which suggests= your technical answer is wrong. And anyway, procedurally it's multiple= steps too late.

=A0

--

Christopher Dearlove=

Senior Principal Eng= ineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:50
To: Thomas Heide Clausen
Cc: manet@ietf.o= rg


Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)

=A0

=A0

*** WARNING ***<= /span>

This message originates from outside our= organisation, either from an external partner or the internet.<= i>
Kee= p this in mind if you answer this message.
Ple= ase see this process on how to deal with suspicious emails.

On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clause= n <thomas@= thomasclausen.org> wrote:

=A0

On 26 f=E9vr. 2013, at = 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I like that protocols use the packet sequence number= , if thoes protocols you refered to don't use the packet SQN, then I re= commend they reconsider.

=A0

Why?

=A0

"Like" is not a technical argument.=

=A0=

=A0

I agree that it not a technical word, but also agree= that *like*=A0can be used in technical volunteer discussions. For example;= Why OLSRv2 protocol does not use the packet sequence number SQN? does it a= ccept random packets and ignore to sense=A0sequence packets? Why the designers like it to be that way? Why does AB like protoc= ols to sense SQN?

=A0

My technical answer is better if it got into a techn= ical draft, however, if a protocol senses the SQN it will be more rebust an= d more organised in=A0MANET communication.

=A0

AB


********************************************************************
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
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Dan He
---------------------
openst= ack contributor
GPU stream programming

http://wiki.openstack.org/Contri= butors

Tel: +44-788-686-3428

--bcaec5216263feeb1104d6a2fa48-- From hrogge@googlemail.com Tue Feb 26 08:23:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A5921F8831 for ; Tue, 26 Feb 2013 08:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYhr71wAstzE for ; Tue, 26 Feb 2013 08:23:44 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id DD9E021F86BE for ; Tue, 26 Feb 2013 08:23:37 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id ek20so4095349lab.16 for ; Tue, 26 Feb 2013 08:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=xHd4Kmjkc5X5B2924skZgC5OCMTHub2YWii3BiTCCf4=; b=zURPU26g8GCkL4KUo56RDSkm4uZG98P1spOmaLYAGgEoubF48zGQQkhghQRR/GOJe7 aMJbalaFHwMo0gRr8h6vWX+qSCW6WxzhWjupoTWWx4bQP130F3ztGon2bU9/xtCI5QuF b4TmOa2Efi5mjePTRP9Ed3IcDmJHCbJ+lSz7iSRvFeE3vj8g7C94TKGjLUROHZQ3IUwN PIPXQuyRPBVTDHv5/AuwCe9vV4zLthILZoy7A7Pn0JqM97ctLH9kNizUhi/ohB+HoH0q 8o5ufsjS7JBEPb3FHlEtJkrWEJiSTQC4oh9v1AI8/EdaSZO5hyd3XUUJMQ6vyArVtsTp 4Y7A== X-Received: by 10.152.148.133 with SMTP id ts5mr14244886lab.2.1361895813566; Tue, 26 Feb 2013 08:23:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Tue, 26 Feb 2013 08:23:12 -0800 (PST) In-Reply-To: References: From: Henning Rogge Date: Tue, 26 Feb 2013 17:23:12 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:23:50 -0000 You are wrong... Ulrich (to name the person you are talking about) likes input and constructive feedback. Your posts of the last weeks were not. You fought for DAYS against the removal of the "packet sequence number attack" from the nhdp-threats document without even understanding that it doesn't apply to NHDP. On mailing lists like this there is an invisible thing called "reputation"... the more noise someone makes about things that turn out nothing at all, the less people will listen in the future. That is why I suggested you should read the documents more carefully. Henning Rogge On Tue, Feb 26, 2013 at 5:16 PM, Abdussalam Baryun wrote: > No one have right to try to discourage inputs, discussions are what this > list is for. I know that editors don't like comments, but they have to li= ve > with it. For others that don't author work, please just do your job (not = to > comment on numbers of posts/input, or time spend) or keep quite, > > AB > > On Tue, Feb 26, 2013 at 4:10 PM, Daniel He wrote: >> >> It is no good to discuss on the mailing list if it is not technical >> relevant. Otherwise, we received too many useless emails without any >> technical information. It is not a BBS >> website. >> >> >> >> On 26 February 2013 16:00, Abdussalam Baryun >> wrote: >>> >>> There is no harm in discussing, issues related to NHDP or RFC5444, or >>> erratas, even after they were publish as we all know they are Request F= or >>> Comments, >>> >>> AB >>> >>> On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) >>> wrote: >>>> >>>> NHDP has made it to RFC, and OLSRv2 has made it to one AD short of RFC= - >>>> and not for any related reason - without anyone thinking "we really sh= ould >>>> use that because it might be there - though it also might not". Which >>>> suggests your technical answer is wrong. And anyway, procedurally it's >>>> multiple steps too late. >>>> >>>> >>>> >>>> -- >>>> >>>> Christopher Dearlove >>>> >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>> >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>> Centre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>> >>>> >>>> >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >>>> Of Abdussalam Baryun >>>> Sent: 26 February 2013 15:50 >>>> To: Thomas Heide Clausen >>>> Cc: manet@ietf.org >>>> >>>> >>>> Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) >>>> >>>> >>>> >>>> >>>> >>>> *** WARNING *** >>>> >>>> This message originates from outside our organisation, either from an >>>> external partner or the internet. >>>> Keep this in mind if you answer this message. >>>> Please see this process on how to deal with suspicious emails. >>>> >>>> On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen >>>> wrote: >>>> >>>> >>>> >>>> On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun >>>> wrote: >>>> >>>> I like that protocols use the packet sequence number, if thoes protoco= ls >>>> you refered to don't use the packet SQN, then I recommend they reconsi= der. >>>> >>>> >>>> >>>> Why? >>>> >>>> >>>> >>>> "Like" is not a technical argument. >>>> >>>> >>>> >>>> >>>> >>>> I agree that it not a technical word, but also agree that *like* can b= e >>>> used in technical volunteer discussions. For example; Why OLSRv2 proto= col >>>> does not use the packet sequence number SQN? does it accept random pac= kets >>>> and ignore to sense sequence packets? Why the designers like it to be = that >>>> way? Why does AB like protocols to sense SQN? >>>> >>>> >>>> >>>> My technical answer is better if it got into a technical draft, howeve= r, >>>> if a protocol senses the SQN it will be more rebust and more organised= in >>>> MANET communication. >>>> >>>> >>>> >>>> AB >>>> >>>> >>>> ******************************************************************** >>>> 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 >>> >> >> >> >> -- >> Dan He >> --------------------- >> openstack contributor >> GPU stream programming >> >> http://wiki.openstack.org/Contributors >> >> Tel: +44-788-686-3428 > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From thomas@thomasclausen.org Tue Feb 26 08:25:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CC821F882D for ; Tue, 26 Feb 2013 08:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4UTEgFeL5Xb for ; Tue, 26 Feb 2013 08:25:24 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 91D0421F8873 for ; Tue, 26 Feb 2013 08:25:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 37C811C03B5; Tue, 26 Feb 2013 08:25:21 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B098F1C00CB; Tue, 26 Feb 2013 08:25:17 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E5C0E781-08BC-47EB-9ACF-DDF876DBF10D" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Clausen In-Reply-To: Date: Tue, 26 Feb 2013 17:25:15 +0100 Message-Id: References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:25:26 -0000 --Apple-Mail=_E5C0E781-08BC-47EB-9ACF-DDF876DBF10D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 26, 2013, at 5:16 PM, Abdussalam Baryun = wrote: > No one have right to try to discourage inputs, discussions are what = this list is for. I know that editors don't like comments, I do not believe that any editor/author of any WG document in this WG = has refused to consider serious and well reasoned comments. =20 Note that "consider" may imply "finding that they did not apply", and = that the operative words also are "serious and well reasoned". Thomas > but they have to live with it. For others that don't author work, = please just do your job (not to comment on numbers of posts/input, or = time spend) or keep quite, > =20 > AB >=20 > On Tue, Feb 26, 2013 at 4:10 PM, Daniel He wrote: > It is no good to discuss on the mailing list if it is not technical = relevant. Otherwise, we received too many useless emails without any = technical information. It is not a BBS > website.=20 >=20 >=20 >=20 > On 26 February 2013 16:00, Abdussalam Baryun = wrote: > There is no harm in discussing, issues related to NHDP or RFC5444, or = erratas, even after they were publish as we all know they are Request = For Comments, > =20 > AB >=20 > On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) = wrote: > NHDP has made it to RFC, and OLSRv2 has made it to one AD short of RFC = - and not for any related reason - without anyone thinking "we really = should use that because it might be there - though it also might not". = Which suggests your technical answer is wrong. And anyway, procedurally = it's multiple steps too late. >=20 > =20 >=20 > -- >=20 > Christopher Dearlove >=20 > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 >=20 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 > =20 >=20 > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Abdussalam Baryun > Sent: 26 February 2013 15:50 > To: Thomas Heide Clausen > Cc: manet@ietf.org >=20 >=20 > Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) >=20 > =20 >=20 > =20 >=20 > *** WARNING *** >=20 > This message originates from outside our organisation, either from an = external partner or the internet. > Keep this in mind if you answer this message. > Please see this process on how to deal with suspicious emails. >=20 > On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen = wrote: >=20 > =20 >=20 > On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun = wrote: >=20 > I like that protocols use the packet sequence number, if thoes = protocols you refered to don't use the packet SQN, then I recommend they = reconsider. >=20 > =20 >=20 > Why? >=20 > =20 >=20 > "Like" is not a technical argument. >=20 > =20 >=20 > =20 >=20 > I agree that it not a technical word, but also agree that *like* can = be used in technical volunteer discussions. For example; Why OLSRv2 = protocol does not use the packet sequence number SQN? does it accept = random packets and ignore to sense sequence packets? Why the designers = like it to be that way? Why does AB like protocols to sense SQN? >=20 > =20 >=20 > My technical answer is better if it got into a technical draft, = however, if a protocol senses the SQN it will be more rebust and more = organised in MANET communication. >=20 > =20 >=20 > AB >=20 >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 >=20 > --=20 > Dan He > --------------------- > openstack contributor > GPU stream programming >=20 > http://wiki.openstack.org/Contributors >=20 > Tel: +44-788-686-3428 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_E5C0E781-08BC-47EB-9ACF-DDF876DBF10D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 abdussalambaryun@gmail.com&= gt; wrote:
On Feb 26, 2013, = at 5:01 PM, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.co= m> wrote:

Just to be clear, I = didn't make this as a proposal to be included - it's a bit more = colloquial than such text should be.
 
I just made it as a = statement of what (in my - fairly well informed - opinion) the situation = is.
 
Of course as a contribution on the list the = authors are free to make use of it as a contribution should they wish. = As I noted, if so I'd advise rewording it a = bit.
 --
Christopher = Dearlove
Senior Principal Engineer, Communications = Group
Communications, Networks and Image Analysis Capability
BAE = Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  = Fax: +44 1245 242124
From: Thomas Clausen = [mailto:thomas@thomasclausen.org] 
Sent: 26 February 2013 = 15:56
To: Abdussalam = Baryun
Cc: Dearlove, Christopher = (UK); manet@ietf.org
Subject: Re: [manet] I-D Action: = draft-ietf-manet-nhdp-sec-threats-01.txt
 
 
*** WARNING ***

This = message originates from outside our organisation, either from an = external partner or the internet.Keep this in = mind if you answer this message.
Please see this process on how to deal with = suspicious emails.On = Feb 26, 2013, at 4:52 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> = wrote:

Hi = Thomas,
 
The editors do what the WG consensus tells them to = do.
On = Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen <thomas@thomasclausen.org> = wrote:
....and that = description of Chris' might be something worth folding into the = I-D?

Thomas

On Feb 26, 2013, at 4:35 PM, "Dearlove, = Christopher (UK)" < +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearlove@baesystems.com |  manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of = Thomas Clausen
> Sent: 26 February 2013 12:19
> To: Henning = Rogge
> Cc: manet@ietf.org
> Subject: Re: [manet] I-D Action: = draft-ietf-manet-nhdp-sec-threats-01.txt
>
> = ----------------------! WARNING ! ----------------------
> This = message originates from outside our organisation,
> either from an = external partner or from the internet.
> Keep this in mind if you = answer this message.
> Follow the 'Report Suspicious Emails' link = on IT matters
> for instructions on reporting suspicious email = messages.
> = --------------------------------------------------------
>
> = On Feb 26, 2013, at 1:08 PM, Henning Rogge <henning.rogge@fkie.fraunhofer.de> = wrote:
>
>> Hi,
>>
>> so do we have an = agreement that the old "sequence number attack" section of = nhdp-threats-00 is wrong and must be removed because it describes = something that does not apply to NHDP?
>>
>> If we (as = a working group) decide we want a "sequence number attack" section in = nhdp-threats, someone needs to write up a corresponding section and we = have to see if it gets consensus in the = group.
>>
>
> I believe that if there is a sequence = number attack on NHDP, then it should be written down.
> I also = believe that I've not seen anything indicating that such an attack = exists.
>
> That's what you're saying, isn't = it?
>
>> Henning Rogge
>>
>> On = 02/26/2013 12:41 PM, Abdussalam Baryun wrote:
>>> your right = thanks :)
>>> AB
>>>
>>> On Tue, Feb = 26, 2013 at 11:38 AM, Henning Rogge
>>> <>>>   maybe = you should write a new one... one that applies to = NHDP.
>>>
>>>
>>>   Henning = Rogge
>>>
>>>   --
>>>   = Diplom-Informatiker Henning Rogge , Fraunhofer-Institut = f=FCr
>>>   Kommunikation, Informationsverarbeitung und = Ergonomie FKIE
>>>   Kommunikationssysteme = (KOM)
>>>   Fraunhofer Stra=DFe 20, 53343 Wachtberg, = Germany
>>>   Telefon +49 228 9435-961 <tel:%2B49%20228%209435-96= 1>,   Fax +49 228
>>>   9435 685 = <tel:%2B49%20228%209435%20685>
>>>   mailto:henning.rogge@fkie.__fraunhofer.de
>>>   = <mailto:  manet@ietf.org <mailto:manet@ietf.org>
>>>    +49 228 9435-961,   Fax +49 228 9435 685
>> mailto:henning.rogge@fkie.fraunhofer.de  manet@ietf.org
>>  manet@ietf.org
> manet@ietf.org
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet
On Tue, Feb 26, 2013 at 4:01 P= M, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:

Just to be clear, I = didn't make this as a proposal to be included - it's a bit more col= loquial than such text should be.

=A0

I just made it as a = statement of what (in my - fairly well informed - opinion) the situation is= .

=A0

Of course as a contr= ibution on the list the authors are free to make use of it as a contributio= n should they wish. As I noted, if so I'd advise rewording it a bit.

=A0

=A0

From: Thomas Clausen [mailto:thomas@thomasclausen.org]
Sent: 26 February 2013 15:56
To: Abdussalam Baryun
Cc: Dearlove, Christopher (UK); manet@ietf.org


Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-0= 1.txt

=A0

=A0

*** WARNING ***<= /span>

This message originates from outside ou= r organisation, either from an external partner or the internet.


Ke= ep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

=A0

On Feb 26, 2013, at 4:52 PM, Abdussalam Baryun <<= a href=3D"mailto:abdussalambaryun@gmail.com" target=3D"_blank">abdussalamba= ryun@gmail.com> wrote:



Hi Thomas,

=A0

happy to know you agree to add that into the I-D, I = will just hope/pray the editors agree, :-)

=A0

The editors do what the WG consensus tells them to d= o.

=A0

Chris made a proposal, for the WG to consider.

=A0

Thomas



AB

=A0

On Tue, Feb 26, 2013 at 3:40 PM, Thomas Clausen <= thomas@thomas= clausen.org> wrote:

....and that description of Chris' might be some= thing worth folding into the I-D?

Thomas


On Feb 26, 2013, at 4:35 PM, "Dearlove, Christopher (UK)" <Chris.Dearl= ove@baesystems.com> wrote:

> An attacker can spoof packets appearing to be from a router that skips= some packet sequence numbers since the last packet sent by the router (and= received and analysed by the attacker).
>
> This may have an effect on an implementation of NHDP that uses those p= acket sequence numbers to recognise missing packets, and thus to change lin= k quality. (There's no required use of the packet sequence number, and = I'm fairly sure no other even suggested possible use.)
>
> This is an implementation of link quality that frankly isn't very = good. That's why in the translation from RFC 3626, where this is a form= al option, to NHDP, it got downgraded to a comment that it's something = you can use in specifying link quality should you want to.
>
> Now against an unprotected NHDP, even one using that mechanism, there = are a lot of much more effective attacks that require less effort to mount,= using HELLO messages.
>
> So about the only case where this attack is worth mounting is when you= know that the NHDP implementation has gone to the trouble of protecting me= ssages, but is using a 5444 implementation that doesn't protect packets= , and you know that it uses this packet sequence number in the way described, despite having gone to the effort of= protecting messages.
>
> Or in other words it's a smart but stupid NHDP implementer. (He ma= de two mistakes, using a poor link quality mechanism, and using something u= nprotected despite the work in protecting most things.)
>
> So it's rather specialised. And even in those circumstances I migh= t (as the attacker) spend my effort on something else.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 = 242194 | =A0Fax: +44 1245 242124
> chr= is.dearlove@baesystems.com | http://www.baesyst= ems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> -----Original Message-----
> From: mane= t-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Clausen
> Sent: 26 February 2013 12:19
> To: Henning Rogge
> Cc: manet@ietf.org=
> Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.= txt
>
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> On Feb 26, 2013, at 1:08 PM, Henning Rogge <henning.rogge@fkie.fraunhofe= r.de> wrote:
>
>> Hi,
>>
>> so do we have an agreement that the old "sequence number atta= ck" section of nhdp-threats-00 is wrong and must be removed because it= describes something that does not apply to NHDP?
>>
>> If we (as a working group) decide we want a "sequence number = attack" section in nhdp-threats, someone needs to write up a correspon= ding section and we have to see if it gets consensus in the group.
>>
>
> I believe that if there is a sequence number attack on NHDP, then it s= hould be written down.
> I also believe that I've not seen anything indicating that such an= attack exists.
>
> That's what you're saying, isn't it?
>
>> Henning Rogge
>>
>> On 02/26/2013 12:41 PM, Abdussalam Baryun wrote:
>>> your right thanks :)
>>> AB
>>>
>>> On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge
>>> <henning.rogge@fkie.fraunhofer.de
>>> <mailto:henning.rogge@fkie.fraunhofer.de>> wrote:
>>>
>>> =A0 On 02/26/2013 12:21 PM, Abdussalam Baryun wrote:
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0I can only repeat it again: NHDP does *= not* use sequence
>>> =A0 =A0 =A0 numbers,
>>> =A0 =A0 =A0 =A0 =A0 =A0neither packet nor message sequence num= bers.
>>>
>>> =A0 =A0 =A0 That is your opinion which I disagree, and disagre= e that the editors
>>> =A0 =A0 =A0 removed the section of sequence number without con= sensus of WG.
>>>
>>>
>>> =A0 You know that the old section was plain WRONG, yes?
>>>
>>> =A0 (I suggest reading section 4.5 of nhdp-threats-00)
>>>
>>> =A0 Because the attack it described cannot happen to NHDP.
>>>
>>> =A0 If you want to get the "sequence number attack" = paragraph back,
>>> =A0 maybe you should write a new one... one that applies to NH= DP.
>>>
>>>
>>> =A0 Henning Rogge
>>>
>>> =A0 --
>>> =A0 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f= =FCr
>>> =A0 Kommunikation, Informationsverarbeitung und Ergonomie FKIE=
>>> =A0 Kommunikationssysteme (KOM)
>>> =A0 Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>>> =A0 Telefon +49 228 9435-961 <tel:%2B49%20228%209435-961>, =A0 Fax +49= 228
>>> =A0 9435 685 <tel:%2B49%20228%209435%20685>
>>> =A0 mailto:henning.rogge@fkie.__fraunhofer.de
>>> =A0 <mailto:henning.rogge@fkie.fraunhofer.de> http://www.fki= e.fraunhofer.de
>>>
>>>
>>> =A0 _______________________________________________
>>> =A0 manet mailing list
>>> =A0 manet@= ietf.org <mailto:manet@ietf.org>
>>> =A0 https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>
>>
>> --
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM)
>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
>> Telefon += 49 228 9435-961, =A0 Fax +49 228 9435 685
>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fki= e.fraunhofer.de
>>
>> _______________________________________________
>> 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 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
h= ttps://www.ietf.org/mailman/listinfo/manet

=A0

=A0


No one have right to try to discourage inputs, = discussions are what this list is for. I know that editors don't = like comments, =


I do not = believe that any editor/author of any WG document in this WG has refused = to consider serious and well reasoned = comments.
 
Note that "consider" may imply = "finding that they did not apply", and that the operative words also are = "serious and well = reasoned".

Thomas

but they have to live with it. For others that don't = author work, please just do your job (not to comment on numbers of = posts/input, or time spend) or keep quite,
 
AB

On Tue, = Feb 26, 2013 at 4:10 PM, Daniel He <drdanhe@gmail.com> wrote:
It is no good to discuss on the mailing list if it is not technical = relevant. Otherwise, we received too many useless emails without any = technical information. It is not a BBS
website.



On 26 February 2013 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> = wrote:
There is no harm in discussing, issues related to NHDP or RFC5444, = or erratas, even after they were publish as we all know they are = Request For Comments,
 
AB

On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> = wrote:

NHDP has made it to RFC, and OLSRv2 has made = it to one AD short of RFC - and not for any related reason - without = anyone thinking "we really should use that because it might be there - though it also might not". Which suggests = your technical answer is wrong. And anyway, procedurally it's multiple = steps too late.

 

--

Christopher = Dearlove

Senior Principal Engineer, Communications = Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesyst= ems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:50
To: Thomas Heide Clausen
Cc: manet@ietf.org


Subject: Re: [manet] [Technical Errata Reported] RFC5444 = (3496)

 

&nbs= p;

*** WARNING ***

This message originates from outside our = organisation, either from an external partner or the = internet.
Keep this = in mind if you answer this message.
Please = see this process on how to deal with suspicious = emails.

On Tue, Feb 26, 2013 at 3:13 PM, = Thomas Heide Clausen <thomas@thomasclausen.org> = wrote:

 

On 26 f=E9vr. = 2013, at 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> = wrote:

I like that protocols use the packet = sequence number, if thoes protocols you refered to don't use the packet = SQN, then I recommend they reconsider.

 

Why?

 

"Like" is not a technical = argument.

 

 

I agree that it not a technical word, but = also agree that *like* can be used in technical volunteer = discussions. For example; Why OLSRv2 protocol does not use the packet = sequence number SQN? does it accept random packets and ignore to = sense sequence packets? Why the designers like it to be that way? Why does AB like = protocols to sense SQN?

 

My technical answer is better if it got into = a technical draft, however, if a protocol senses the SQN it will be more = rebust and more organised in MANET communication.

 

AB



********************************************************************
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




--
Dan = He
---------------------
openstack contributor
GPU stream = programming

http://wiki.openstack.org/Contributors

Tel: +44-788-686-3428

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

= --Apple-Mail=_E5C0E781-08BC-47EB-9ACF-DDF876DBF10D-- From drdanhe@gmail.com Tue Feb 26 08:27:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6155321F88C8 for ; Tue, 26 Feb 2013 08:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+DDWYHOHB2Y for ; Tue, 26 Feb 2013 08:27:10 -0800 (PST) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4BF21F85DB for ; Tue, 26 Feb 2013 08:27:10 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id u20so3551150iag.5 for ; Tue, 26 Feb 2013 08:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aQ7BC2WBvvCPhxB1JfWGjEQVoU12YIgjSXckORa3BAE=; b=iMDfoFbIhMMaGKEsEi+uriIarXPFAJKIH5xEM43Tga2/A/+CEbcwMWq3sv9E18bjmM FNicqBIX1fxcDl0ILKYG8lYp3mnBlC6qkVx17sTWmNzfb4jcC6T4npsUftvZpPQSKSsN 06oOyq3HSIfPufTu9SKeJi7G9cJ8++bC2y5yOVLfUHSVRPi20zrjbEFJstD1qt7ixnei GLfjP17Buxay26RoleTEP8zNNEbwu33wYJy1Frn3+joBkcg9hJUaGznuD2U8RGQEL4Y+ /p8G9Z3WUdC3Vz/zqK9gLNtrxJIAL/pfotZmwJBGso8QAfk9N3hzhIl/lrSz7BO9+Zbh c/eA== MIME-Version: 1.0 X-Received: by 10.50.190.231 with SMTP id gt7mr5615918igc.85.1361896029669; Tue, 26 Feb 2013 08:27:09 -0800 (PST) Received: by 10.50.85.6 with HTTP; Tue, 26 Feb 2013 08:27:09 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 16:27:09 +0000 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=14dae9340d1511cfb004d6a32194 Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:27:11 -0000 --14dae9340d1511cfb004d6a32194 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's not true. If you so called input is just as noise if they are not technical relevant. it wastes my time and my mailbox storage. I think most of other mailing list users will feel it as I felt. Comments are most welcome if the comments are relevant.if the comments are technical and critical. Comments should not be a "remind". you should not speak for the others. for example, " There was a input of John which I refered to in the ticket,". you speak for yourself!! On 26 February 2013 16:16, Abdussalam Baryun wr= ote: > No one have right to try to discourage inputs, discussions are what this > list is for. I know that editors don't like comments, but they have to li= ve > with it. For others that don't author work, please just do your job (not = to > comment on numbers of posts/input, or time spend) or keep quite, > > AB > > On Tue, Feb 26, 2013 at 4:10 PM, Daniel He wrote: > >> It is no good to discuss on the mailing list if it is not technical >> relevant. Otherwise, we received too many useless emails without any >> technical information. It is not a BBS >> website. >> >> >> >> On 26 February 2013 16:00, Abdussalam Baryun > > wrote: >> >>> There is no harm in discussing, issues related to NHDP or RFC5444, or >>> erratas, even after they were publish as we all know they are Request F= or >>> Comments, >>> >>> AB >>> >>> On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) < >>> Chris.Dearlove@baesystems.com> wrote: >>> >>>> NHDP has made it to RFC, and OLSRv2 has made it to one AD short of >>>> RFC - and not for any related reason - without anyone thinking "we rea= lly >>>> should use that because it might be there - though it also might not". >>>> Which suggests your technical answer is wrong. And anyway, procedurall= y >>>> it's multiple steps too late.**** >>>> >>>> ** ** >>>> >>>> -- **** >>>> >>>> Christopher Dearlove**** >>>> >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >>>> >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>> >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>> Centre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687**** >>>> >>>> ** ** >>>> >>>> *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On >>>> Behalf Of *Abdussalam Baryun >>>> *Sent:* 26 February 2013 15:50 >>>> *To:* Thomas Heide Clausen >>>> *Cc:* manet@ietf.org >>>> >>>> *Subject:* Re: [manet] [Technical Errata Reported] RFC5444 (3496)**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> **** WARNING **** >>>> >>>> *This message originates from outside our organisation, either from an >>>> external partner or the internet.** >>>> Keep this in mind if you answer this message. >>>> Please see this processon ho= w to deal with suspicious emails. >>>> ***** >>>> >>>> On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen < >>>> thomas@thomasclausen.org> wrote:**** >>>> >>>> ** ** >>>> >>>> On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun < >>>> abdussalambaryun@gmail.com> wrote:**** >>>> >>>> I like that protocols use the packet sequence number, if thoes >>>> protocols you refered to don't use the packet SQN, then I recommend th= ey >>>> reconsider.**** >>>> >>>> ** ** >>>> >>>> Why?**** >>>> >>>> ** ** >>>> >>>> "Like" is not a technical argument.**** >>>> >>>> ** ** >>>> >>>> **** >>>> >>>> I agree that it not a technical word, but also agree that *like* can b= e >>>> used in technical volunteer discussions. For example; Why OLSRv2 proto= col >>>> does not use the packet sequence number SQN? does it accept random pac= kets >>>> and ignore to sense sequence packets? Why the designers like it to be = that >>>> way? Why does AB like protocols to sense SQN?**** >>>> >>>> **** >>>> >>>> My technical answer is better if it got into a technical draft, >>>> however, if a protocol senses the SQN it will be more rebust and more >>>> organised in MANET communication.**** >>>> >>>> **** >>>> >>>> AB**** >>>> >>>> >>>> ******************************************************************** >>>> 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 >>> >>> >> >> >> -- >> Dan He >> --------------------- >> openstack contributor >> GPU stream programming >> >> http://wiki.openstack.org/Contributors >> >> Tel: +44-788-686-3428 >> > > --=20 Dan He --------------------- openstack contributor GPU stream programming http://wiki.openstack.org/Contributors Tel: +44-788-686-3428 --14dae9340d1511cfb004d6a32194 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's not true. If you so called input is just as noise if they are no= t technical relevant.
it wastes my time and my mailbox storage. I think = most of other mailing list users
will feel it as I felt.

Comments= are most welcome if the comments are relevant.if the comments are technica= l and critical. Comments should not be a "remind". you should not= speak
for the others. for example, " There was a input of John which I refer= ed to in the ticket,". you speak for yourself!!




On 26 February 2013 16:16, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
No one have right to try to discourage = inputs, discussions are what this list=A0is for. I know that editors don= 9;t like comments, but they have to live with it. For others that don't= author work, please just do your job (not to comment on numbers of posts/i= nput, or time spend)=A0or keep quite,
=A0
AB

On Tue, Feb 2= 6, 2013 at 4:10 PM, Daniel He <drdanhe@gmail.com> wrote:
=
It is no good to discuss on the mailing list if it is not technical relevan= t. Otherwise, we received too many useless emails without any technical inf= ormation. It is not a BBS
website.



On 26 February 2013 16:00, Abdussalam Baryun <abdussalambaryun@g= mail.com> wrote:
There is no harm in discussing, issues related to NHDP or RFC5444, or = erratas,=A0even after they were publish as we all know they are Request For= Comments,
=A0
AB

On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) <C= hris.Dearlove@baesystems.com> wrote:

NHDP has made it to = RFC, and OLSRv2 has made it to one AD short of RFC - and not for any relate= d reason - without anyone thinking "we really should use that because it might be there - though it also might not". Which suggests= your technical answer is wrong. And anyway, procedurally it's multiple= steps too late.

=A0

--

Christopher Dearlove=

Senior Principal Eng= ineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124=

chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:50
To: Thomas Heide Clausen
Cc: manet@ietf.o= rg


Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)

=A0

=A0

*** WARNING ***<= /span>

This message originates from outside our= organisation, either from an external partner or the internet.<= i>
Kee= p this in mind if you answer this message.
Ple= ase see this process on how to deal with suspicious emails.

On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clause= n <thomas@= thomasclausen.org> wrote:

=A0

On 26 f=E9vr. 2013, at = 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I like that protocols use the packet sequence number= , if thoes protocols you refered to don't use the packet SQN, then I re= commend they reconsider.

=A0

Why?

=A0

"Like" is not a technical argument.=

=A0=

=A0

I agree that it not a technical word, but also agree= that *like*=A0can be used in technical volunteer discussions. For example;= Why OLSRv2 protocol does not use the packet sequence number SQN? does it a= ccept random packets and ignore to sense=A0sequence packets? Why the designers like it to be that way? Why does AB like protoc= ols to sense SQN?

=A0

My technical answer is better if it got into a techn= ical draft, however, if a protocol senses the SQN it will be more rebust an= d more organised in=A0MANET communication.

=A0

AB


********************************************************************
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
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Dan He
------------------= ---
openstack contributor
GPU stream programming

http:/= /wiki.openstack.org/Contributors

Tel: +44-788-686-3428




--
Dan He
-------------= --------
openstack contributor
GPU stream programming

http://wiki.o= penstack.org/Contributors

Tel: +44-788-686-3428
--14dae9340d1511cfb004d6a32194-- From abdussalambaryun@gmail.com Tue Feb 26 08:31:29 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D9F21F88ED for ; Tue, 26 Feb 2013 08:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15s+6dH7O94b for ; Tue, 26 Feb 2013 08:31:28 -0800 (PST) Received: from mail-da0-f52.google.com (mail-da0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id E247821F88D6 for ; Tue, 26 Feb 2013 08:31:27 -0800 (PST) Received: by mail-da0-f52.google.com with SMTP id x33so1067204dad.11 for ; Tue, 26 Feb 2013 08:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n7HUFnBOW8pi6u1To8E0hYiuZUXke0NcZKcnIoRkMBw=; b=kgOb7xKSt2DL9z+ANzVXaGUKTR47nGKB99Lx5OdFdt9sLP+uwfytKMjSAAMxRZgNF0 pob2WOuBrbH6X295X/ry2g8e5bdsnCzgwpwjMTGCxBvL1hKrKhgtO3K+vpmqcgF3SCir 90jZyV88buucizcV8fyLmNzsN54wBW1qpNbEJr3MuR63CblBGMsOAnAsPCnT7mFT7kY6 xqjM+lvKBAcIcZHh5Q4xSTkltIjJwX3M7rFoL19yU2eonXwwafIDRkb26OqB5FqFMpu+ 5CwVfEM3Ab4kl1bm9/JG56fTaq+dq1GnM/PGq27UnI4J1AqI9Dn5aU6v+E6FhAlFkKZh TgyA== MIME-Version: 1.0 X-Received: by 10.68.245.229 with SMTP id xr5mr24319333pbc.163.1361896287754; Tue, 26 Feb 2013 08:31:27 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 08:31:27 -0800 (PST) In-Reply-To: <512C9EBB.3060902@fkie.fraunhofer.de> References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> <512C9EBB.3060902@fkie.fraunhofer.de> Date: Tue, 26 Feb 2013 16:31:27 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b2e155d73e1f604d6a330d7 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:31:29 -0000 --047d7b2e155d73e1f604d6a330d7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > If you want to get the "sequence number attack" paragraph back, maybe you > should write a new one... one that applies to NHDP. > > I don't think writing something will help for this threat draft, I should leave this item for others to discuss. This draft review was a bad experience for me and I may report that when the time comes. AB --047d7b2e155d73e1f604d6a330d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 26, 2013 at 11:38 AM, Henning Rogge = <henning.rogge@fkie.fraunhofer.de> wrote:
=
If you want to get the "sequence number attack" paragraph back, m= aybe you should write a new one... one that applies to NHDP.

I don't thin= k writing something will help for this threat draft, I should leave this it= em for others to discuss. This draft review=A0was a bad experience for me a= nd I may report that when the time comes.
=A0
AB

--047d7b2e155d73e1f604d6a330d7-- From abdussalambaryun@gmail.com Tue Feb 26 08:33:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8963D21F861C for ; Tue, 26 Feb 2013 08:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAVGgTGH0e10 for ; Tue, 26 Feb 2013 08:33:29 -0800 (PST) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1F37521F861B for ; Tue, 26 Feb 2013 08:33:29 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so981999dak.2 for ; Tue, 26 Feb 2013 08:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=olg6WRWKEb+91qY1j3Gwv1hOSAlNRWCmyuipxriwNFg=; b=nSZ1R4lGO0sVwhZ32MLBVmBxhIElQn+NIbcj/GFFGGXOpcghP5amIq/8h16XO2XMG4 r0zvWf7pgzJn5KOLooLHMQFsMLil2vBfSts8rSS2X2Fz4tVJtlXfh5CQr4oQYk0a/P94 Wg8a6jmBmlDMq21+1qDiwihULBCoEtl3/+6JEB1MPqOoCNJsXpDH3Q1F1S3mh8wVNAcK labLIv3rNkIVfDPeEN/u4VN7QLAjaRwsVTGfv/56Yty1z8nJ03MbO93rN310ETpyEANH 1y6VdwGF65IfemoREnRXOpMpUvg6CJOnXEAWAVh6uYf1cZ6eOAZqNJP/e6z7utTC2ZOj Sd0Q== MIME-Version: 1.0 X-Received: by 10.68.217.2 with SMTP id ou2mr24567019pbc.6.1361896408646; Tue, 26 Feb 2013 08:33:28 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 08:33:28 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 16:33:28 +0000 Message-ID: From: Abdussalam Baryun To: Daniel He Content-Type: multipart/alternative; boundary=e89a8ff2430ba88df704d6a337b7 Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:33:30 -0000 --e89a8ff2430ba88df704d6a337b7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I do speak for my self, and if I use any input or draft in my input there is no harm, but if editors say that I am the only input and if they are wrong, I may refer to other input. AB On Tue, Feb 26, 2013 at 4:27 PM, Daniel He wrote: > That's not true. If you so called input is just as noise if they are not > technical relevant. > it wastes my time and my mailbox storage. I think most of other mailing > list users > will feel it as I felt. > > Comments are most welcome if the comments are relevant.if the comments ar= e > technical and critical. Comments should not be a "remind". you should not > speak > for the others. for example, " There was a input of John which I refered > to in the ticket,". you speak for yourself!! > > > > > > On 26 February 2013 16:16, Abdussalam Baryun = wrote: > >> No one have right to try to discourage inputs, discussions are what this >> list is for. I know that editors don't like comments, but they have to l= ive >> with it. For others that don't author work, please just do your job (not= to >> comment on numbers of posts/input, or time spend) or keep quite, >> >> AB >> >> On Tue, Feb 26, 2013 at 4:10 PM, Daniel He wrote: >> >>> It is no good to discuss on the mailing list if it is not technical >>> relevant. Otherwise, we received too many useless emails without any >>> technical information. It is not a BBS >>> website. >>> >>> >>> >>> On 26 February 2013 16:00, Abdussalam Baryun < >>> abdussalambaryun@gmail.com> wrote: >>> >>>> There is no harm in discussing, issues related to NHDP or RFC5444, or >>>> erratas, even after they were publish as we all know they are Request = For >>>> Comments, >>>> >>>> AB >>>> >>>> On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) < >>>> Chris.Dearlove@baesystems.com> wrote: >>>> >>>>> NHDP has made it to RFC, and OLSRv2 has made it to one AD short of >>>>> RFC - and not for any related reason - without anyone thinking "we re= ally >>>>> should use that because it might be there - though it also might not"= . >>>>> Which suggests your technical answer is wrong. And anyway, procedural= ly >>>>> it's multiple steps too late.**** >>>>> >>>>> ** ** >>>>> >>>>> -- **** >>>>> >>>>> Christopher Dearlove**** >>>>> >>>>> Senior Principal Engineer, Communications Group >>>>> Communications, Networks and Image Analysis Capability >>>>> BAE Systems Advanced Technology Centre >>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >>>>> >>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>> >>>>> BAE Systems (Operations) Limited >>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>>> Centre, Farnborough, Hants, GU14 6YU, UK >>>>> Registered in England & Wales No: 1996687**** >>>>> >>>>> ** ** >>>>> >>>>> *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On >>>>> Behalf Of *Abdussalam Baryun >>>>> *Sent:* 26 February 2013 15:50 >>>>> *To:* Thomas Heide Clausen >>>>> *Cc:* manet@ietf.org >>>>> >>>>> *Subject:* Re: [manet] [Technical Errata Reported] RFC5444 (3496)**** >>>>> >>>>> ** ** >>>>> >>>>> ** ** >>>>> >>>>> **** WARNING **** >>>>> >>>>> *This message originates from outside our organisation, either from >>>>> an external partner or the internet.** >>>>> Keep this in mind if you answer this message. >>>>> Please see this processon h= ow to deal with suspicious emails. >>>>> ***** >>>>> >>>>> On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen < >>>>> thomas@thomasclausen.org> wrote:**** >>>>> >>>>> ** ** >>>>> >>>>> On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun < >>>>> abdussalambaryun@gmail.com> wrote:**** >>>>> >>>>> I like that protocols use the packet sequence number, if thoes >>>>> protocols you refered to don't use the packet SQN, then I recommend t= hey >>>>> reconsider.**** >>>>> >>>>> ** ** >>>>> >>>>> Why?**** >>>>> >>>>> ** ** >>>>> >>>>> "Like" is not a technical argument.**** >>>>> >>>>> ** ** >>>>> >>>>> **** >>>>> >>>>> I agree that it not a technical word, but also agree that *like* can >>>>> be used in technical volunteer discussions. For example; Why OLSRv2 >>>>> protocol does not use the packet sequence number SQN? does it accept = random >>>>> packets and ignore to sense sequence packets? Why the designers like = it to >>>>> be that way? Why does AB like protocols to sense SQN?**** >>>>> >>>>> **** >>>>> >>>>> My technical answer is better if it got into a technical draft, >>>>> however, if a protocol senses the SQN it will be more rebust and more >>>>> organised in MANET communication.**** >>>>> >>>>> **** >>>>> >>>>> AB**** >>>>> >>>>> >>>>> ******************************************************************** >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Dan He >>> --------------------- >>> openstack contributor >>> GPU stream programming >>> >>> http://wiki.openstack.org/Contributors >>> >>> Tel: +44-788-686-3428 >>> >> >> > > > -- > Dan He > --------------------- > openstack contributor > GPU stream programming > > http://wiki.openstack.org/Contributors > > Tel: +44-788-686-3428 > --e89a8ff2430ba88df704d6a337b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I do speak for my self, and if I use any input or draft in my input th= ere is no harm, but if editors say that I am the only input and if =A0they = are wrong, I may refer to other input.
=A0
AB

On Tue, Feb 26, 2013 at 4:27 PM, Daniel He <drd= anhe@gmail.com> wrote:
That's not true. If you so called input is just as noise if they are no= t technical relevant.
it wastes my time and my mailbox storage. I think = most of other mailing list users
will feel it as I felt.

Comments= are most welcome if the comments are relevant.if the comments are technica= l and critical. Comments should not be a "remind". you should not= speak
for the others. for example, " There was a input of John which I refer= ed to in the ticket,". you speak for yourself!!
<= div class=3D"h5">




On 26 Febru= ary 2013 16:16, Abdussalam Baryun <abdussalambaryun@gmail.com= > wrote:
No one have right to try to discourage inputs, discus= sions are what this list=A0is for. I know that editors don't like comme= nts, but they have to live with it. For others that don't author work, = please just do your job (not to comment on numbers of posts/input, or time = spend)=A0or keep quite,
=A0
AB

On Tue, Feb 2= 6, 2013 at 4:10 PM, Daniel He <drdanhe@gmail.com> wrote:
=
It is no good to discuss on the mailing list if it is not technical relevan= t. Otherwise, we received too many useless emails without any technical inf= ormation. It is not a BBS
website.



On 26 February 2013 16:00, Abdussalam Baryun <abdussalambaryun@g= mail.com> wrote:
There is no harm in discussing, issues related to NHDP or RFC5444, or = erratas,=A0even after they were publish as we all know they are Request For= Comments,
=A0
AB

On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) <C= hris.Dearlove@baesystems.com> wrote:

NHDP has made it to = RFC, and OLSRv2 has made it to one AD short of RFC - and not for any relate= d reason - without anyone thinking "we really should use that because it might be there - though it also might not". Which suggests= your technical answer is wrong. And anyway, procedurally it's multiple= steps too late.

=A0

--

Christopher Dearlove=

Senior Principal Eng= ineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:50
To: Thomas Heide Clausen
Cc: manet@ietf.o= rg


Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)

=A0

=A0

*** WARNING ***<= /span>

This message originates from outside our= organisation, either from an external partner or the internet.<= i>
Kee= p this in mind if you answer this message.
Ple= ase see this process on how to deal with suspicious emails.

On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clause= n <thomas@= thomasclausen.org> wrote:

=A0

On 26 f=E9vr. 2013, at = 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I like that protocols use the packet sequence number= , if thoes protocols you refered to don't use the packet SQN, then I re= commend they reconsider.

=A0

Why?

=A0

"Like" is not a technical argument.=

=A0=

=A0

I agree that it not a technical word, but also agree= that *like*=A0can be used in technical volunteer discussions. For example;= Why OLSRv2 protocol does not use the packet sequence number SQN? does it a= ccept random packets and ignore to sense=A0sequence packets? Why the designers like it to be that way? Why does AB like protoc= ols to sense SQN?

=A0

My technical answer is better if it got into a techn= ical draft, however, if a protocol senses the SQN it will be more rebust an= d more organised in=A0MANET communication.

=A0

AB


********************************************************************
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
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Dan He
------------------= ---
openstack contributor
GPU stream programming

http:/= /wiki.openstack.org/Contributors

Tel: +44-788-686-3428




--
Dan He
-------------= --------
openstack contributor
GPU stream programming

http://wiki.o= penstack.org/Contributors

Tel: +44-788-686-3428

--e89a8ff2430ba88df704d6a337b7-- From d.sturek@att.net Tue Feb 26 08:34:01 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E5221F88EF for ; Tue, 26 Feb 2013 08:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TanG3S4hMU1r for ; Tue, 26 Feb 2013 08:34:00 -0800 (PST) Received: from nm16-vm0.access.bullet.mail.mud.yahoo.com (nm16-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2CA21F88EE for ; Tue, 26 Feb 2013 08:34:00 -0800 (PST) Received: from [66.94.237.193] by nm16.access.bullet.mail.mud.yahoo.com with NNFMP; 26 Feb 2013 16:33:59 -0000 Received: from [98.139.221.53] by tm4.access.bullet.mail.mud.yahoo.com with NNFMP; 26 Feb 2013 16:33:59 -0000 Received: from [127.0.0.1] by smtp106.sbc.mail.bf1.yahoo.com with NNFMP; 26 Feb 2013 16:33:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1361896439; bh=fK+AuJseBnL9hYEysVXxUHs/wgwCQpSJ9Whvi7eagPo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=wVD3VxFq4sDzFgzwodOCAenw9aMupRnyhmqu4ilyxk5pUjwCLlXucmYdsMahHuksUdMya+Bu5WopKgORp/2iaVDMZ2o4T+g0HqvMrQevsG4Fc1RJLg6+elxKm0jaGBvTdbv8dvXoBwJOZx9TK2CoGG/wsGKprjZu6PSq6lnHcUM= X-Yahoo-Newman-Id: 518166.91801.bm@smtp106.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: eANjugsVM1lgMiN1T25dfU8nInbTzPUW52Wqwr59RWEISFB BCwUGkSg08S0lapQbvCG9CQXR2wUpLWK_xZEDGt6HGjCD2dN6iMqiD9RsI5U 6M28w_hRW4QK7vY.ZF7I1vAU6j3HTBnXNPCwgrBRY_yz8jDNs7xdfoL6jpHi hszSBkmtl9r6zJf.U92kVRIC1FQOzTpsUmH6IN0OlXBXMHSNH5uGG_XolbS1 MlUh7pTolUQ3KIg3uaNUVHCEBPyEFICR1GEspemuO2jLqoLhNmW4jBCe7cxH KPYyGJtLU_V9QC5tRHrkrllWqHrBC6lmfO4Rb8q45sWI.dGcK.s.KD7Kb5f6 ZYj2kg74KGmPOzI5mmZqHsZPUPSGncRd13PqIq5O1Nn_LxIBg_yn7bNBD.vb 8FSELLboiFQSzCxNDS5dM658uRI33evR0VJJFyqYR1in2c4MEI2zXxskfkfD IN45WMgZmF934v44EhiUAHG15q82ikama0DZzYxGmPXg6aCuAYtsCbXmjB0U RihPh2kwcNgxdwiP_qT.0XXzBdHIUd1UJqPPuMv1iLRtfyAd.KS45gyNMhIf IdEkrAMeeRZtABHwaoJp3sa1DbGQOxrc3paC0 X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.4.158.20] (d.sturek@216.236.254.7 with login) by smtp106.sbc.mail.bf1.yahoo.com with SMTP; 26 Feb 2013 08:33:59 -0800 PST User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Tue, 26 Feb 2013 08:33:56 -0800 From: Don Sturek To: Abdussalam Baryun , Daniel He Message-ID: Thread-Topic: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3444712439_539380" Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:34:01 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3444712439_539380 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi AB, Sorry to wade in here but the comment "For others that don't author work, please just do your job (not to comment on numbers of posts/input, or time spend) or keep quite," makes no sense. So far, as far as I can tell, there is no other support for your suggestion to add sequence numbers to NHDP. Whether other MANET members say that explicitly (as Daniel did) or simply provide no support should mean the sam= e thing to the authors. Don From: Abdussalam Baryun Date: Tuesday, February 26, 2013 8:16 AM To: Daniel He Cc: "manet@ietf.org" Subject: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) No one have right to try to discourage inputs, discussions are what this list is for. I know that editors don't like comments, but they have to live with it. For others that don't author work, please just do your job (not to comment on numbers of posts/input, or time spend) or keep quite, =20 AB On Tue, Feb 26, 2013 at 4:10 PM, Daniel He wrote: > It is no good to discuss on the mailing list if it is not technical relev= ant. > Otherwise, we received too many useless emails without any technical > information. It is not a BBS > website.=20 >=20 >=20 >=20 > On 26 February 2013 16:00, Abdussalam Baryun > wrote: >> There is no harm in discussing, issues related to NHDP or RFC5444, or >> erratas, even after they were publish as we all know they are Request Fo= r >> Comments, >> =20 >> AB >>=20 >> On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) >> wrote: >>> NHDP has made it to RFC, and OLSRv2 has made it to one AD short of RFC = - and >>> not for any related reason - without anyone thinking "we really should = use >>> that because it might be there - though it also might not". Which sugge= sts >>> your technical answer is wrong. And anyway, procedurally it's multiple = steps >>> too late. >>>=20 >>> =20 >>> --=20 >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 2421= 24 >>> >>> chris.dearlove@baesystems.com | >>> http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cent= re, >>> Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> =20 >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of >>> Abdussalam Baryun >>> Sent: 26 February 2013 15:50 >>> To: Thomas Heide Clausen >>> Cc: manet@ietf.org >>>=20 >>> Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) >>> =20 >>>=20 >>> =20 >>>=20 >>> *** WARNING *** >>>=20 >>> This message originates from outside our organisation, either from an >>> external partner or the internet. >>> Keep this in mind if you answer this message. >>> Please see this process >>> >> Dealing%20With%20Suspicious%20Emails.pdf> on how to deal with suspicio= us >>> emails. >>>=20 >>> On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen >>> wrote: >>>=20 >>> =20 >>>=20 >>> On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun >>> wrote: >>>>=20 >>>> I like that protocols use the packet sequence number, if thoes protoco= ls >>>> you refered to don't use the packet SQN, then I recommend they reconsi= der. >>>=20 >>> =20 >>>=20 >>> Why? >>>=20 >>> =20 >>>=20 >>> "Like" is not a technical argument. >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> I agree that it not a technical word, but also agree that *like* can be= used >>> in technical volunteer discussions. For example; Why OLSRv2 protocol do= es >>> not use the packet sequence number SQN? does it accept random packets a= nd >>> ignore to sense sequence packets? Why the designers like it to be that = way? >>> Why does AB like protocols to sense SQN? >>>=20 >>> =20 >>>=20 >>> My technical answer is better if it got into a technical draft, however= , if >>> a protocol senses the SQN it will be more rebust and more organised in = MANET >>> communication. >>>=20 >>> =20 >>>=20 >>> AB >>> =20 >>> ******************************************************************** >>> 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. >>> ******************************************************************** >>>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 >=20 >=20 > --=20 > Dan He > --------------------- > openstack contributor > GPU stream programming >=20 > http://wiki.openstack.org/Contributors >=20 > Tel: +44-788-686-3428 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --B_3444712439_539380 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi AB,

Sorry to wade in here but the comment "For others that don't author wo= rk, please just do your job (not to comment on numbers of posts/input, or ti= me spend) or keep quite," makes no sense.

So f= ar, as far as I can tell, there is no other support for your suggestion to a= dd sequence numbers to NHDP.   Whether other MANET members say that exp= licitly (as Daniel did) or simply provide no support should mean the same th= ing to the authors.

Don

From: Abdussalam Baryun <abdussalambaryun@gmail.com>Date: Tuesday, February 26, 2013 8:= 16 AM
To: Daniel He <drdanhe@gmail.com>
Cc: "manet@ietf.org" &l= t;manet@ietf.org>
Subject: [manet] An input (was Re: [Technical Errata = Reported] RFC5444 (3496))

No one have right to = try to discourage inputs, discussions are what this list is for. I know= that editors don't like comments, but they have to live with it. For others= that don't author work, please just do your job (not to comment on numbers = of posts/input, or time spend) or keep quite,
 
AB

On Tue, Feb 26, 2013 at 4:10 PM, = Daniel He <drdanhe@gmail.com> wrote:
It is no good to discuss on the mailing list if it is not technical relevan= t. Otherwise, we received too many useless emails without any technical info= rmation. It is not a BBS
website.



On 26 February 2013 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com= > wrote:
T= here is no harm in discussing, issues related to NHDP or RFC5444, or erratas= , even after they were publish as we all know they are Request For Comm= ents,
 
AB

On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) <Chris.De= arlove@baesystems.com> wrote:

NHDP has= made it to RFC, and OLSRv2 has made it to one AD short of RFC - and not for= any related reason - without anyone thinking "we really should use that because it might be there - though it also might not". Which suggests your= technical answer is wrong. And anyway, procedurally it's multiple steps too= late.

<= /u> 

--

Christopher De= arlove

Senior Pr= incipal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystem= s.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:5= 0
To: Thomas Heide Clausen
Cc: manet@ietf.org


Subject:= Re: [manet] [Technical Errata Reported] RFC5444 (3496)
<= p>

 

*** WARNING ***<= /u>

= This message originates from outside our organisation, either from an extern= al partner or the internet.
Keep this in mind if you answer this messa= ge.
Please s= ee this process on how to deal with suspicious emails.

On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:

I like that protocols use the packet = sequence number, if thoes protocols you refered to don't use the packet SQN,= then I recommend they reconsider.

 

Why?

&n= bsp;

"Like" is not a technical arg= ument.

 

 

I agree th= at it not a technical word, but also agree that *like* can be used in t= echnical volunteer discussions. For example; Why OLSRv2 protocol does not us= e the packet sequence number SQN? does it accept random packets and ignore t= o sense sequence packets? Why the designers like it to be that way? Why does AB like protoc= ols to sense SQN?

 =

My technical answer is better= if it got into a technical draft, however, if a protocol senses the SQN it = will be more rebust and more organised in MANET communication.

 

=

AB


********************************************************************
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




--
Dan He
---------------------
openstack contributor
GPU= stream programming

http://wiki.openstack.org/Contributors

Tel: +44-788-68= 6-3428

_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/= mailman/listinfo/manet --B_3444712439_539380-- From abdussalambaryun@gmail.com Tue Feb 26 08:35:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B853A21F861C for ; Tue, 26 Feb 2013 08:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.246 X-Spam-Level: X-Spam-Status: No, score=-3.246 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8yMIjlPyyvy for ; Tue, 26 Feb 2013 08:35:21 -0800 (PST) Received: from mail-da0-f51.google.com (mail-da0-f51.google.com [209.85.210.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8E52C21F8622 for ; Tue, 26 Feb 2013 08:35:21 -0800 (PST) Received: by mail-da0-f51.google.com with SMTP id n15so2096948dad.10 for ; Tue, 26 Feb 2013 08:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2LUNLmzFCsUH+zSzJSV2Th+nUAh8lo/2ES5TS7FGizc=; b=wcjeHmaJIcJ0Sx0yGMsVVKiOnqzpGjs2SZSWBqf60XBFK9LKZ2QXQySfiUo22kRcma t2JI0Pl2Ax/xOZYn2rA/u2v8xxEOc1r18QA61GGJKNbG5iYb2kLpW9HOzYkzgyY2toj2 FPF/c0KwLPYg8ArGMyuCAml4myeJWuWoFIfdJYhgBbt/6Lbe/1gGXfYFlkg7eFJ5m2Ah 9BrfwxjtKBTmnjx6Vauoe9yt7nxxJQMmfhBT+T3RZZxqIu280j0kuI2ulxvtbBQC7rFh HU9pLAo7T/qmtBfiRsbrjp2IA/8g6ecMekiOO87XctZhB4zNOapeMBMvmnckqYZKWDct x5hw== MIME-Version: 1.0 X-Received: by 10.68.217.2 with SMTP id ou2mr24575420pbc.6.1361896521333; Tue, 26 Feb 2013 08:35:21 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 08:35:21 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 16:35:21 +0000 Message-ID: From: Abdussalam Baryun To: Daniel He Content-Type: multipart/alternative; boundary=e89a8ff2430b60045c04d6a33e8e Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:35:22 -0000 --e89a8ff2430b60045c04d6a33e8e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't care about your mailbox, this is not my bussiness, you try to find to solve your problems. Don't wats my time by your noise to my work in IETF please, AB On Tue, Feb 26, 2013 at 4:27 PM, Daniel He wrote: > That's not true. If you so called input is just as noise if they are not > technical relevant. > it wastes my time and my mailbox storage. I think most of other mailing > list users > will feel it as I felt. > > Comments are most welcome if the comments are relevant.if the comments ar= e > technical and critical. Comments should not be a "remind". you should not > speak > for the others. for example, " There was a input of John which I refered > to in the ticket,". you speak for yourself!! > > > > > > On 26 February 2013 16:16, Abdussalam Baryun = wrote: > >> No one have right to try to discourage inputs, discussions are what this >> list is for. I know that editors don't like comments, but they have to l= ive >> with it. For others that don't author work, please just do your job (not= to >> comment on numbers of posts/input, or time spend) or keep quite, >> >> AB >> >> On Tue, Feb 26, 2013 at 4:10 PM, Daniel He wrote: >> >>> It is no good to discuss on the mailing list if it is not technical >>> relevant. Otherwise, we received too many useless emails without any >>> technical information. It is not a BBS >>> website. >>> >>> >>> >>> On 26 February 2013 16:00, Abdussalam Baryun < >>> abdussalambaryun@gmail.com> wrote: >>> >>>> There is no harm in discussing, issues related to NHDP or RFC5444, or >>>> erratas, even after they were publish as we all know they are Request = For >>>> Comments, >>>> >>>> AB >>>> >>>> On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) < >>>> Chris.Dearlove@baesystems.com> wrote: >>>> >>>>> NHDP has made it to RFC, and OLSRv2 has made it to one AD short of >>>>> RFC - and not for any related reason - without anyone thinking "we re= ally >>>>> should use that because it might be there - though it also might not"= . >>>>> Which suggests your technical answer is wrong. And anyway, procedural= ly >>>>> it's multiple steps too late.**** >>>>> >>>>> ** ** >>>>> >>>>> -- **** >>>>> >>>>> Christopher Dearlove**** >>>>> >>>>> Senior Principal Engineer, Communications Group >>>>> Communications, Networks and Image Analysis Capability >>>>> BAE Systems Advanced Technology Centre >>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >>>>> >>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>> >>>>> BAE Systems (Operations) Limited >>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>>> Centre, Farnborough, Hants, GU14 6YU, UK >>>>> Registered in England & Wales No: 1996687**** >>>>> >>>>> ** ** >>>>> >>>>> *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On >>>>> Behalf Of *Abdussalam Baryun >>>>> *Sent:* 26 February 2013 15:50 >>>>> *To:* Thomas Heide Clausen >>>>> *Cc:* manet@ietf.org >>>>> >>>>> *Subject:* Re: [manet] [Technical Errata Reported] RFC5444 (3496)**** >>>>> >>>>> ** ** >>>>> >>>>> ** ** >>>>> >>>>> **** WARNING **** >>>>> >>>>> *This message originates from outside our organisation, either from >>>>> an external partner or the internet.** >>>>> Keep this in mind if you answer this message. >>>>> Please see this processon h= ow to deal with suspicious emails. >>>>> ***** >>>>> >>>>> On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen < >>>>> thomas@thomasclausen.org> wrote:**** >>>>> >>>>> ** ** >>>>> >>>>> On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun < >>>>> abdussalambaryun@gmail.com> wrote:**** >>>>> >>>>> I like that protocols use the packet sequence number, if thoes >>>>> protocols you refered to don't use the packet SQN, then I recommend t= hey >>>>> reconsider.**** >>>>> >>>>> ** ** >>>>> >>>>> Why?**** >>>>> >>>>> ** ** >>>>> >>>>> "Like" is not a technical argument.**** >>>>> >>>>> ** ** >>>>> >>>>> **** >>>>> >>>>> I agree that it not a technical word, but also agree that *like* can >>>>> be used in technical volunteer discussions. For example; Why OLSRv2 >>>>> protocol does not use the packet sequence number SQN? does it accept = random >>>>> packets and ignore to sense sequence packets? Why the designers like = it to >>>>> be that way? Why does AB like protocols to sense SQN?**** >>>>> >>>>> **** >>>>> >>>>> My technical answer is better if it got into a technical draft, >>>>> however, if a protocol senses the SQN it will be more rebust and more >>>>> organised in MANET communication.**** >>>>> >>>>> **** >>>>> >>>>> AB**** >>>>> >>>>> >>>>> ******************************************************************** >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Dan He >>> --------------------- >>> openstack contributor >>> GPU stream programming >>> >>> http://wiki.openstack.org/Contributors >>> >>> Tel: +44-788-686-3428 >>> >> >> > > > -- > Dan He > --------------------- > openstack contributor > GPU stream programming > > http://wiki.openstack.org/Contributors > > Tel: +44-788-686-3428 > --e89a8ff2430b60045c04d6a33e8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't care about your mailbox, this is not my bussiness, you try= to find to solve your problems. Don't wats my time by your noise to my= work in IETF please,
=A0
AB


--e89a8ff2430b60045c04d6a33e8e-- From hrogge@googlemail.com Tue Feb 26 08:36:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C44C21F88F0 for ; Tue, 26 Feb 2013 08:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rx6o0Tle7q4M for ; Tue, 26 Feb 2013 08:36:35 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE8221F8622 for ; Tue, 26 Feb 2013 08:36:35 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id fo12so4130762lab.0 for ; Tue, 26 Feb 2013 08:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=YSvFcDuiZKs8Kt1d++IhZACIyxE+GGDtPZ60shx5QcQ=; b=EY5EHt331X6g0BtLLcf5NMQ5u4Wce7MYGeGMZoYfBlKW/r8r9RxfWRjAQFhHJcVt6L rCpSfCgTgSaQ1NWceciJ7z7LcP6CyBIm9TGGgF5e6hdvFVrXylr19w2FPkY5JxhU0HTd XTJP5/Igm3DZxGPy9lEb6fhv5VEqqT1iKhYL2lmSXR8mhzKD/El1cJ1m/t0xQY5RoCBX WlRtBVI9kRSmbbtozSDYvJzVvVYc/npzH8ySBFMG69911+eYwT/jaTOK/1VL3wBlrCQ0 OKWloLSeRzjEmdVkmmVNXqCOKj+QjLC/gzlYN8ppq1dOxcIdvumxCh46ecMJT3UIhp6q vFOg== X-Received: by 10.112.28.102 with SMTP id a6mr790455lbh.109.1361896594218; Tue, 26 Feb 2013 08:36:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Tue, 26 Feb 2013 08:36:14 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> <512C9EBB.3060902@fkie.fraunhofer.de> From: Henning Rogge Date: Tue, 26 Feb 2013 17:36:14 +0100 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:36:36 -0000 On Tue, Feb 26, 2013 at 5:31 PM, Abdussalam Baryun wrote: > I don't think writing something will help for this threat draft, I should > leave this item for others to discuss. This draft review was a bad > experience for me and I may report that when the time comes. Another good advise for you. "Reporting" is a two-edged sword. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From abdussalambaryun@gmail.com Tue Feb 26 08:37:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3A621F89CE for ; Tue, 26 Feb 2013 08:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YogHEynTAemH for ; Tue, 26 Feb 2013 08:37:12 -0800 (PST) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEBC21F8992 for ; Tue, 26 Feb 2013 08:37:12 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id uo15so2473611pbc.19 for ; Tue, 26 Feb 2013 08:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EzYBsl6n8QqldzVLA6F3RX+TZJTDT/LCJMuHBlvpqM8=; b=uPWTrfgNgQ/beyPgdmrkqz5xVUIPWDrJHTMPLVK+OGV9Poq4HD3hTf/2OVeM7GllE+ NWTGrV8TgJTIeRAKnibAG7ojjeUBeEheGGgw1jgtsF4lEgBLnULScm4RQbkEFTKaXVu7 YzEo100GkBbBdM8BLLRidEZzGL9C0sOZXoufPNS/6BuHMXZNAA6zXmmwRUmQIR5ICflD bvQWANE1NfrJjhBpRdOyO4rEGHkLQW8IQ5w3EdivtBYA5U1w7awSkrCyP7bBtYnXFQwx ySnjwEyEC69oMVNLl6fq1R3WPoUArxdMj/Zwk4mfoQn+uaG4S4oP2Vw8ewQP09ZhfomJ Qvhg== MIME-Version: 1.0 X-Received: by 10.68.138.170 with SMTP id qr10mr24170517pbb.190.1361896631983; Tue, 26 Feb 2013 08:37:11 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 08:37:11 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 16:37:11 +0000 Message-ID: From: Abdussalam Baryun To: Daniel He Content-Type: multipart/alternative; boundary=047d7b15aa2ff8669d04d6a344b5 Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:37:13 -0000 --047d7b15aa2ff8669d04d6a344b5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 26, 2013 at 4:27 PM, Daniel He wrote: > That's not true. If you so called input is just as noise if they are not > technical relevant. > it wastes my time and my mailbox storage. I think most of other mailing > list users > will feel it as I felt. > > Comments are most welcome if the comments are relevant. Who decides what is relavent. Please let the CHair do his job and never put your nose into other peoples work AB --047d7b15aa2ff8669d04d6a344b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 26, 2013 at 4:27 PM, Daniel He <drd= anhe@gmail.com> wrote:
That's not true. If you so called input is just as noise if they are no= t technical relevant.
it wastes my time and my mailbox storage. I think = most of other mailing list users
will feel it as I felt.

Comments= are most welcome if the comments are relevant.
=A0
Who decides what is relavent. Please let the CHair do hi= s job and=A0never put your nose into other peoples work
=A0
=
AB
--047d7b15aa2ff8669d04d6a344b5-- From abdussalambaryun@gmail.com Tue Feb 26 08:45:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC7221F8539 for ; Tue, 26 Feb 2013 08:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASpL7-POyaIU for ; Tue, 26 Feb 2013 08:45:50 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id C7FA921F8775 for ; Tue, 26 Feb 2013 08:45:38 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id xa12so2432877pbc.8 for ; Tue, 26 Feb 2013 08:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uNKGtvScE0Bqcb7xZdODa89OW+Ao4IVq3CMlQ4Qs/14=; b=BMVQ+dMOF6XDm5sQI0i2i0OrdXKF7FvmILPOWRpKKeK2+E/kaD9FfAu6QxHs911bDZ 8orrDZLpTc0J/wPn2GWb4W7tcrnUejqbshZC/3ErLu4shyIHqAAu3ukbH5CU2EJlCKm/ +Xn3HpKakkNF8+47ALWlACTPtwwr8kB4hpb8i7rDK04Bz/SAkcfAZ9RsuoYTh3P6mJix nm4lTvPtv1kDktGCOp8LM+W1vaFD49xMPkM4HKGhYdRBJ3OYS8cfoqIhJ9VvZx/UQwv3 9GnQ0d1B4fLjP1TZ8Jobx0l/Rmn6mcRUrYyaRIPhaLWCOzewQG+IeJPb/1nNLcPsF920 MyEA== MIME-Version: 1.0 X-Received: by 10.68.204.68 with SMTP id kw4mr24381571pbc.113.1361897138606; Tue, 26 Feb 2013 08:45:38 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 08:45:38 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 16:45:38 +0000 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b10cd952ad7de04d6a363ab Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:45:51 -0000 --047d7b10cd952ad7de04d6a363ab Content-Type: text/plain; charset=ISO-8859-1 Hi Henning, thanks for your respected advise and input, On Tue, Feb 26, 2013 at 4:23 PM, Henning Rogge wrote: > You are wrong... > > Ulrich (to name the person you are talking about) likes input and > constructive feedback. > His mistake is that he judge the consensus before it was clear, please read Teco respond to the editor (Ulrich). > > Your posts of the last weeks were not. You fought for DAYS against the > removal of the "packet sequence number attack" from the nhdp-threats > document without even understanding that it doesn't apply to NHDP. > Is there a rule in MANET WG that I don't know about, please point, otherwise every one can choose his/her strategy in confincing people/others > > On mailing lists like this there is an invisible thing called > "reputation"... the more noise someone makes about things that turn > out nothing at all, the less people will listen in the future. > I beleive what is important in IETF is not the participant reputation. the more important is the WG reputation or the work reputation or the draft reputation. Maybe I will add the editor reputation :) .........( pleae note that my voise is never shouting) > > That is why I suggested you should read the documents more carefully. > I accept your suggestion and advises, and will try my best, don't forget this will take some time for improving, as many drafts in IETF are improving but still they do submit even if they are noise for some other mailboxes. AB --047d7b10cd952ad7de04d6a363ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Henning,
=A0
thanks for your respected advise a= nd input,

On Tue, Feb 26, 2013 at 4= :23 PM, Henning Rogge <hrogge@googlemail.com> wrote:
You are wrong...

Ulrich (to name the person you are talking about) likes input and
constructive feedback.
His mistake is that he judge th= e consensus before it was clear, please read Teco respond to=A0the editor (= Ulrich).=A0

Your posts of the last weeks were not. You fought for DAYS against the
removal of the "packet sequence number attack" from the nhdp-thre= ats
document without even understanding that it doesn't apply to NHDP.
<= /blockquote>
=A0
Is there a rule in MANET WG that I don't= know about, please point, otherwise every one can choose his/her strategy = in confincing people/others=A0

On mailing lists like this there is an invisible thing called
"reputation"... the more noise someone makes about things that tu= rn
out nothing at all, the less people will listen in the future.
=A0
I beleive what is important in IETF is not the parti= cipant reputation. the more important is the WG reputation or the work repu= tation or the draft reputation. Maybe I will add the editor reputation :)= =A0.........( pleae note that my voise is never shouting)=A0

That is why I suggested you should read the documents more carefully.
=A0
I accept your suggestion and advises, and wil= l try my best, don't forget this will take some time for improving, as = many drafts in IETF are improving but still they do submit even if they are= noise for some other mailboxes.
=A0
AB
--047d7b10cd952ad7de04d6a363ab-- From abdussalambaryun@gmail.com Tue Feb 26 08:48:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE7C21F8934 for ; Tue, 26 Feb 2013 08:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbyraPpSdUzk for ; Tue, 26 Feb 2013 08:48:17 -0800 (PST) Received: from mail-da0-f52.google.com (mail-da0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3699F21F8942 for ; Tue, 26 Feb 2013 08:48:17 -0800 (PST) Received: by mail-da0-f52.google.com with SMTP id x33so1073756dad.25 for ; Tue, 26 Feb 2013 08:48:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VKKdLXVHyd5fZEUjFDLk6kzhUIJWruVX1CzlDfa2k3w=; b=nrKw3X2nn5yts5DthiqKevMY6KZ98AiG0OrpM8saATSiTvapxsYbQBTpVGFvp9Y3X0 AD7iI0ojYK6FSZDEESShB2swyeR5tNtU2h7le70FGe0qo0voyMuWUKb+sZ2gx/tGOta7 pFsXd0NEoPl9yenWjQKcdIQS/lSB5Lz7bGM/zCcHgxA6Se0R7XXZ88dqvCHxMCvsWemZ IkTE+NtcG0oc2latMd54z6ZlsPFeQwKL66qArab8ZJYLDUK0FQdkumlzV2lfrLLaZ1E1 XlJ8T+jRLzVO3jXw403WZBddH8Lt7aASWmNAsA5yAEz6BcTmhYYFeHkBNBr4vy852yh3 wopA== MIME-Version: 1.0 X-Received: by 10.66.158.2 with SMTP id wq2mr2615012pab.113.1361897296920; Tue, 26 Feb 2013 08:48:16 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 08:48:16 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 16:48:16 +0000 Message-ID: From: Abdussalam Baryun To: Don Sturek Content-Type: multipart/alternative; boundary=047d7b86c9f09a84fe04d6a36cdd Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:48:20 -0000 --047d7b86c9f09a84fe04d6a36cdd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is ok, your comment is your opinion, Thanks AB On Tue, Feb 26, 2013 at 4:33 PM, Don Sturek wrote: > Hi AB, > > Sorry to wade in here but the comment "For others that don't author work, > please just do your job (not to comment on numbers of posts/input, or tim= e > spend) or keep quite," makes no sense. > > So far, as far as I can tell, there is no other support for your > suggestion to add sequence numbers to NHDP. Whether other MANET members > say that explicitly (as Daniel did) or simply provide no support should > mean the same thing to the authors. > > Don > > > From: Abdussalam Baryun > Date: Tuesday, February 26, 2013 8:16 AM > To: Daniel He > Cc: "manet@ietf.org" > Subject: [manet] An input (was Re: [Technical Errata Reported] RFC5444 > (3496)) > > No one have right to try to discourage inputs, discussions are what this > list is for. I know that editors don't like comments, but they have to li= ve > with it. For others that don't author work, please just do your job (not = to > comment on numbers of posts/input, or time spend) or keep quite, > > AB > > On Tue, Feb 26, 2013 at 4:10 PM, Daniel He wrote: > >> It is no good to discuss on the mailing list if it is not technical >> relevant. Otherwise, we received too many useless emails without any >> technical information. It is not a BBS >> website. >> >> >> >> On 26 February 2013 16:00, Abdussalam Baryun wrote: >> >>> There is no harm in discussing, issues related to NHDP or RFC5444, or >>> erratas, even after they were publish as we all know they are Request F= or >>> Comments, >>> >>> AB >>> >>> On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) < >>> Chris.Dearlove@baesystems.com> wrote: >>> >>>> NHDP has made it to RFC, and OLSRv2 has made it to one AD short of RFC >>>> - and not for any related reason - without anyone thinking "we really >>>> should use that because it might be there - though it also might not". >>>> Which suggests your technical answer is wrong. And anyway, procedurall= y >>>> it's multiple steps too late.**** >>>> >>>> ** ** >>>> >>>> -- **** >>>> >>>> Christopher Dearlove**** >>>> >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >>>> >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>> >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>> Centre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687**** >>>> >>>> ** ** >>>> >>>> *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On >>>> Behalf Of *Abdussalam Baryun >>>> *Sent:* 26 February 2013 15:50 >>>> *To:* Thomas Heide Clausen >>>> *Cc:* manet@ietf.org >>>> >>>> *Subject:* Re: [manet] [Technical Errata Reported] RFC5444 (3496)**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> **** WARNING **** >>>> >>>> *This message originates from outside our organisation, either from an >>>> external partner or the internet.** >>>> Keep this in mind if you answer this message. >>>> Please see this processon ho= w to deal with suspicious emails. >>>> ***** >>>> >>>> On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen < >>>> thomas@thomasclausen.org> wrote:**** >>>> >>>> ** ** >>>> >>>> On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun < >>>> abdussalambaryun@gmail.com> wrote:**** >>>> >>>> I like that protocols use the packet sequence number, if thoes >>>> protocols you refered to don't use the packet SQN, then I recommend th= ey >>>> reconsider.**** >>>> >>>> ** ** >>>> >>>> Why?**** >>>> >>>> ** ** >>>> >>>> "Like" is not a technical argument.**** >>>> >>>> ** ** >>>> >>>> **** >>>> >>>> I agree that it not a technical word, but also agree that *like* can b= e >>>> used in technical volunteer discussions. For example; Why OLSRv2 proto= col >>>> does not use the packet sequence number SQN? does it accept random pac= kets >>>> and ignore to sense sequence packets? Why the designers like it to be = that >>>> way? Why does AB like protocols to sense SQN?**** >>>> >>>> **** >>>> >>>> My technical answer is better if it got into a technical draft, >>>> however, if a protocol senses the SQN it will be more rebust and more >>>> organised in MANET communication.**** >>>> >>>> **** >>>> >>>> AB**** >>>> >>>> >>>> ******************************************************************** >>>> 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 >>> >>> >> >> >> -- >> Dan He >> --------------------- >> openstack contributor >> GPU stream programming >> >> http://wiki.openstack.org/Contributors >> >> Tel: +44-788-686-3428 >> > > _______________________________________________ manet mailing list > manet@ietf.org https://www.ietf.org/mailman/listinfo/manet > --047d7b86c9f09a84fe04d6a36cdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It is ok, your comment is your opinion,
=A0
Thanks=
AB

On Tue, Feb 26, 2013 = at 4:33 PM, Don Sturek <d.sturek@att.net> wrote:
Hi AB,

Sorry to wade in here but the comment = "For others that don't author work, please just do your job (not t= o comment on numbers of posts/input, or time spend)=A0or keep quite," = makes no sense.

So far, as far as I can tell, there is no other support= for your suggestion to add sequence numbers to NHDP. =A0 Whether other MAN= ET members say that explicitly (as Daniel did) or simply provide no support= should mean the same thing to the authors.

Don


From: Abdussalam Baryun <abdussalambaryun@= gmail.com>
Date: Tuesday= , February 26, 2013 8:16 AM
To: Daniel He <drdanhe@gmail.com>
Cc: "manet@ietf.org" <manet@ietf.org>
Subject: [manet] An input (was Re:= [Technical Errata Reported] RFC5444 (3496))

No one have right to try to discourage inputs, discus= sions are what this list=A0is for. I know that editors don't like comme= nts, but they have to live with it. For others that don't author work, = please just do your job (not to comment on numbers of posts/input, or time = spend)=A0or keep quite,
=A0
AB

On Tue, Feb 2= 6, 2013 at 4:10 PM, Daniel He <drdanhe@gmail.com> wrote:
=
It is no good to discuss on the mailing list if it is not technical relevan= t. Otherwise, we received too many useless emails without any technical inf= ormation. It is not a BBS
website.



On 26 February 2013 16:00, Abdussalam Baryun <abdussalambaryun@g= mail.com> wrote:
There is no harm in discussing, issues related to NHDP or RF= C5444, or erratas,=A0even after they were publish as we all know they are R= equest For Comments,
=A0
AB

On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) <C= hris.Dearlove@baesystems.com> wrote:

NHDP has made it to RFC, and OLSRv2 has made it to one AD short= of RFC - and not for any related reason - without anyone thinking "we= really should use that because it might be there - though it also might not". Which suggests= your technical answer is wrong. And anyway, procedurally it's multiple= steps too late.

=A0

--

Christopher Dearlov= e

Senior Principal E= ngineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:5= 0
To: Thomas Heide Clausen
Cc: manet@ietf.org


Subjec= t: Re: [manet] [Technical Errata Reported] RFC5444 (3496)=

=A0

=A0

*** WARNING ***

<= div>

This message originates from outsid= e our organisation, either from an external partner or the internet.=
Keep this in mind if you an= swer this message.
Please see this process on how to deal with suspicious emails.

On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen <thomas@thomasclausen.org&g= t; wrote:

= =A0

On 26 f=E9vr= . 2013, at 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I like that protocols use the packet sequence number, if= thoes protocols you refered to don't use the packet SQN, then I recomm= end they reconsider.

=A0

<= /div>

Why?

=A0

= "Like" is not a technical argument.

=A0

=A0

I agree that it not a technic= al word, but also agree that *like*=A0can be used in technical volunteer di= scussions. For example; Why OLSRv2 protocol does not use the packet sequenc= e number SQN? does it accept random packets and ignore to sense=A0sequence packets? Why the designers like it to be that way? Why does AB like protoc= ols to sense SQN?

=A0=

My technical answer is bet= ter if it got into a technical draft, however, if a protocol senses the SQN= it will be more rebust and more organised in=A0MANET communication.=

=A0

AB


********************************************************************
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
m= anet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

=



= --
Dan He
---------------------
openstack contributor
GPU stre= am programming

http://wiki.openstack.org/Contributors

Tel: +44-788-686-3428

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

--047d7b86c9f09a84fe04d6a36cdd-- From drdanhe@gmail.com Tue Feb 26 08:48:46 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FC021F8A96 for ; Tue, 26 Feb 2013 08:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTRUu8rAMcO2 for ; Tue, 26 Feb 2013 08:48:46 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2916D21F8A93 for ; Tue, 26 Feb 2013 08:48:46 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id 17so4604283iea.40 for ; Tue, 26 Feb 2013 08:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aFein40Tl9gWkE87QDZVIQZpCvt4kJzJzuPYGrKjNQQ=; b=YOhvHQvjL4NyF/bjLSoKbiG21zfqVGuveozx7DDm9oBciHqy6wpwqV7XYYI7Epe1ay OYDCb2tdSFo50qBUlSTagzwvFMUIAKPNoFuYDQCRXV95mdQsu/3Zq8riP7/EJicqDM71 j38mTw97npGnJSbs733qBC7c7pMZNS1LXNQT1DDPNRkbz2rm7NJwRD+WhAbZDwCJaVuQ m9crrPmQRQVXoCbTjaFdHGVgMS0KGAE6oYZ7H3vD8lXVfKEu0rLCxtZkSmuQVLoyowXs E9CqcsMZiVv0DoT2smF+dPsw/mOI1pVQK7bBQHeTL1NtSNU8sSU671jypDDPM6hh9PNR JxXg== MIME-Version: 1.0 X-Received: by 10.50.195.170 with SMTP id if10mr5295635igc.72.1361897325797; Tue, 26 Feb 2013 08:48:45 -0800 (PST) Received: by 10.50.85.6 with HTTP; Tue, 26 Feb 2013 08:48:45 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 16:48:45 +0000 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=14dae9340af95327b404d6a36e52 Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:48:46 -0000 --14dae9340af95327b404d6a36e52 Content-Type: text/plain; charset=ISO-8859-1 It is yourself decides what is relevant. if you have no sense whether you are beating dead house, you are not a technical guy! "what is chair's job", please refer to RFC2418. On 26 February 2013 16:37, Abdussalam Baryun wrote: > On Tue, Feb 26, 2013 at 4:27 PM, Daniel He wrote: > >> That's not true. If you so called input is just as noise if they are not >> technical relevant. >> it wastes my time and my mailbox storage. I think most of other mailing >> list users >> will feel it as I felt. >> >> Comments are most welcome if the comments are relevant. > > > Who decides what is relavent. Please let the CHair do his job and never > put your nose into other peoples work > > AB > --14dae9340af95327b404d6a36e52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is yourself decides what is relevant. if you have no sense whether youare beating dead house, you are not a technical guy!
"what is cha= ir's job", please refer to RFC2418.


On 26 February 2013 16:37, Abdussalam Baryun <abdussalambaryun@g= mail.com> wrote:
On Tue, Feb 26, 2013 at 4:27 P= M, Daniel He <drdanhe@gmail.com> wrote:
That's not true. If you so called input is just as noise if they are no= t technical relevant.
it wastes my time and my mailbox storage. I think = most of other mailing list users
will feel it as I felt.

Comments= are most welcome if the comments are relevant.
=A0
Who decides what is relavent. Please let the CHair= do his job and=A0never put your nose into other peoples work
=A0
AB

--14dae9340af95327b404d6a36e52-- From teco@inf-net.nl Tue Feb 26 08:51:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D32121F8A05 for ; Tue, 26 Feb 2013 08:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIwj3rafuP3X for ; Tue, 26 Feb 2013 08:51:12 -0800 (PST) Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by ietfa.amsl.com (Postfix) with ESMTP id 81A3E21F88BE for ; Tue, 26 Feb 2013 08:51:12 -0800 (PST) Received: by mail-bk0-f43.google.com with SMTP id jm19so1960223bkc.2 for ; Tue, 26 Feb 2013 08:51:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=dRalYHXF/UD/wtVyiysqmHwZjasSgOlyFAok+ceV2mM=; b=Ne9c1JQOLCdvPxZKTDDSJRJujgEGQnvT8RaJC5674SvLbzOYz88fPXxZUZEO4YGk0F Sgh76PvQ42KKbZNUS/doB5z6tmaLRjFjkC7D7mpPKBSYxQy3D5K/klAWMxRBf+C+JN/k ARIOusL55OmG3HYJOWFsUAxnFm9GrblqYpOQ91dZCdaQkvTM8vgoBxC9DE9BPobdteMk WFd292jegGOztYW9u0Lke5y4qnkNricx3kvVeBeCYYy+lyT4DD7Prkn/TCkWKv5D2Bms dNpyC3Aw6pEy7WaTrBpnrjnYDcilTSO315t1ahasfEqUG0FKBfIixFFShrLgVO3fbyaw YA/g== X-Received: by 10.204.7.195 with SMTP id e3mr6885903bke.115.1361897471507; Tue, 26 Feb 2013 08:51:11 -0800 (PST) Received: from [10.87.22.64] ([88.128.80.4]) by mx.google.com with ESMTPS id gi19sm1843563bkc.2.2013.02.26.08.51.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 08:51:10 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Teco Boot In-Reply-To: Date: Tue, 26 Feb 2013 17:50:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQk2tXsnFyMdK31zgyrMHiuercqqFavGFNBxe6sd0jB44y8/7FdGkIzaaPJCX0Hm+Vl6ddpa Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:51:13 -0000 Op 26 feb. 2013, om 08:37 heeft Ulrich Herberg het = volgende geschreven: >=20 >=20 > On Mon, Feb 25, 2013 at 10:41 PM, Teco Boot wrote: >=20 > Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg = het volgende geschreven: >=20 > > AB, > > > > again, sequence numbers are not used by NHDP, therefore not a threat = to NHDP. If another protocols uses that information, it may be a threat = to that protocol, and may be documented in a security threats analysis = for that protocol. > > > > It seems you are the only one advocating for changing the draft on = this aspect. I will wait if someone else also asks for changes on this = matter before changing it. > =20 > Don't judge too early. I'm with AB that threats on optional parts of a = standard should be enlightened. >=20 > But it is *not* an optional part of NHDP (nor is it mandatory). It is = simply named as example what implementers may do, but it is outside of = the normative part. I cannot guess what people can implement in addition = to the normative part, since there may be infinite possibilities. Please = tell me how I should write security threats for these potentially = infinite, non-normative, things that people can implement.=20 >=20 > I can only repeat it again: NHDP does *not* use sequence numbers, = neither packet nor message sequence numbers. Than that is your valid response. If a protocol has same optional or non-normative elements, I cannot see = any reason not to fold in security considerations for it. No reason to write security considerations down for what is not present. = No infinity here. Teco > =20 >=20 > Ulrich From abdussalambaryun@gmail.com Tue Feb 26 08:51:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9859421F89A4 for ; Tue, 26 Feb 2013 08:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x9zV+Ez2E6G for ; Tue, 26 Feb 2013 08:51:54 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id B5B7D21F8AB7 for ; Tue, 26 Feb 2013 08:51:38 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id t11so1155018daj.8 for ; Tue, 26 Feb 2013 08:51:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mr0f+zCka0RfN7KOCEL8Nt5Oh4pF0GaM7iE1da/G9lk=; b=yG0v7CfQKJXY4f4KiRQZD2GCeR0p+TB0DEEvc4I2R5D28UmFmVhUK3zLlCSzHb5t2I rrEOANH+vDwi0r45J+cQY3jidei1+6B8H4wrTBX5WOASVegiutXJ5b5A25HIDtlnUqNx x4FKePmhCitkhY5VNAPvej0XLAnomNc9LECRvtRL6k8Twkx4PCR0MKVTvlkkUDmCmbls QVCk3o1AcFI3Vdr+hokQNR/CQ1f/zuKYR4+1MDLUwzBrr9yw1okXsMCf2GjheuqPQB5m vEa3ZHlUP3Afqyx1p/k+0cA5nI6HCqULumY4ThkUrbLN4LD7GYFGcHWAHSTo5kzxomJ0 mvdQ== MIME-Version: 1.0 X-Received: by 10.68.153.97 with SMTP id vf1mr24304429pbb.93.1361897498573; Tue, 26 Feb 2013 08:51:38 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 08:51:38 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 16:51:38 +0000 Message-ID: From: Abdussalam Baryun To: Daniel He Content-Type: multipart/alternative; boundary=f46d041701bd9f835904d6a37877 Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:51:54 -0000 --f46d041701bd9f835904d6a37877 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 26, 2013 at 4:48 PM, Daniel He wrote: > It is yourself decides what is relevant. if you have no sense whether you > are beating dead house, you are not a technical guy! > We all know that, the one who decides what is not relavent or noise is the Chair not you, AB > "what is chair's job", please refer to RFC2418. > > > I don't need to read any thing, just please stop taking my time, AB > > > On 26 February 2013 16:37, Abdussalam Baryun wrote: > >> On Tue, Feb 26, 2013 at 4:27 PM, Daniel He wrote: >> >>> That's not true. If you so called input is just as noise if they are not >>> technical relevant. >>> it wastes my time and my mailbox storage. I think most of other mailing >>> list users >>> will feel it as I felt. >>> >>> Comments are most welcome if the comments are relevant. >> >> >> Who decides what is relavent. Please let the CHair do his job and never >> put your nose into other peoples work >> >> AB >> > > --f46d041701bd9f835904d6a37877 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 26, 2013 at 4:48 PM, Daniel He <drd= anhe@gmail.com> wrote:
It is yourself decides what is relevant. if you have no sense whether youare beating dead house, you are not a technical guy!
=A0
We all=A0=A0know that, the one who decides what is not relav= ent or noise is the Chair not you,
=A0
AB
=A0

"what is = chair's job", please refer to RFC2418.

=A0

I don't need to read any thing, just please= stop taking my time,
=A0
AB=A0
=A0
=A0
--f46d041701bd9f835904d6a37877-- From Chris.Dearlove@baesystems.com Tue Feb 26 09:16:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3817221F8A8A for ; Tue, 26 Feb 2013 09:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QW56O7+yvMZ for ; Tue, 26 Feb 2013 09:16:56 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 74EE821F8A6F for ; Tue, 26 Feb 2013 09:16:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="267994375" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 26 Feb 2013 17:16:46 +0000 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r1QHGkGx017466 for ; Tue, 26 Feb 2013 17:16:46 GMT X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="8855944" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 26 Feb 2013 17:16:46 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 17:16:46 +0000 From: "Dearlove, Christopher (UK)" To: Teco Boot , Ulrich Herberg Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt Thread-Index: AQHOEeEdQcK/1dKC6UukRyjp9E9HrJiHzkyAgABbgACAAIUFAIAAHDMAgAAFiwCAADMyAIAAjWwAgAAFVgCAAIXSAIAADs8AgAGJ1ACAAA+DgIAAmqiAgAAGhgA= Date: Tue, 26 Feb 2013 17:16:45 +0000 Message-ID: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.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 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 17:16:57 -0000 Let's be crystal clear on what NHDP says - whichever way you want to read i= t. Section 14.4 is the relevant part, and in whole it reads (where the sec= ond bullet is the relevant one, but I've included it all for context). A router MAY update link quality based on any information available to it. Particular cases that MAY be used include: o Information from the link layer, such as signal-to-noise ratio or packet acknowledgment reception and loss information. o Receipt or loss of control packets. If control packets include a sequential packet sequence number, as defined in [RFC5444], then link quality can be updated when a control packet is received, whether or not it contains a HELLO message. The link quality may then, for example, be based on whether the last N out of M control packets on the link were received, or may use a "leaky integrator" tracking packet reception and loss. o Receipt or loss of HELLO messages. If the maximum interval between HELLO messages is known (such as by inclusion in HELLO messages of a Message TLV with Type :=3D INTERVAL_TIME, as defined in [RFC5497]), then the loss of HELLO messages can be determined without the need to receive a later HELLO message. Note that if this case is combined with the previous case, then care must be taken to avoid "double counting" a lost HELLO message in a lost packet. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= eco Boot Sent: 26 February 2013 16:51 To: Ulrich Herberg Cc: List Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Op 26 feb. 2013, om 08:37 heeft Ulrich Herberg het vo= lgende geschreven: >=20 >=20 > On Mon, Feb 25, 2013 at 10:41 PM, Teco Boot wrote: >=20 > Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg het = volgende geschreven: >=20 > > AB, > > > > again, sequence numbers are not used by NHDP, therefore not a threat to= NHDP. If another protocols uses that information, it may be a threat to th= at protocol, and may be documented in a security threats analysis for that = protocol. > > > > It seems you are the only one advocating for changing the draft on this= aspect. I will wait if someone else also asks for changes on this matter b= efore changing it. > =20 > Don't judge too early. I'm with AB that threats on optional parts of a st= andard should be enlightened. >=20 > But it is *not* an optional part of NHDP (nor is it mandatory). It is sim= ply named as example what implementers may do, but it is outside of the nor= mative part. I cannot guess what people can implement in addition to the no= rmative part, since there may be infinite possibilities. Please tell me how= I should write security threats for these potentially infinite, non-normat= ive, things that people can implement.=20 >=20 > I can only repeat it again: NHDP does *not* use sequence numbers, neither= packet nor message sequence numbers. Than that is your valid response. If a protocol has same optional or non-normative elements, I cannot see any= reason not to fold in security considerations for it. No reason to write security considerations down for what is not present. No= infinity here. Teco > =20 >=20 > Ulrich _______________________________________________ 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 reller@cococorp.com Tue Feb 26 09:48:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD5921F8887 for ; Tue, 26 Feb 2013 09:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC4GafZfGcop for ; Tue, 26 Feb 2013 09:48:02 -0800 (PST) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by ietfa.amsl.com (Postfix) with ESMTP id DC7F121F8880 for ; Tue, 26 Feb 2013 09:48:01 -0800 (PST) Received: by mail-bk0-f50.google.com with SMTP id jg9so1960171bkc.23 for ; Tue, 26 Feb 2013 09:48:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=IEJ40bo/1H47OGr9Nvzh+DJZRbXX+5dBSZuk1nYcykA=; b=OpAcmL026hm6Gz0QeWoq9MIZ/Xdn89pOtwZxhoyDgd6+sA4xHSWnQEJta9ZAaV0kGb oiCMXMRtw+ob/CI3zXJeOmV2TZnPYiiW9W9VlCQ716UUNJ6klHLjppk7oCklS+lbM63K +xuijvzGx5gzFcNYfA8imfINayeNNpdwIM2nCwsY8YEhtRhjvbcvQheXipVdCXhl6sET 7+CsBjSzRQuODf7E50ej04gzOU3I7jIoJYrQ0X1DjHpkCie2V6KE8U/iGVedyIRARqmI AWafkQNn8fhqWL/x7Xb4w437XW9DKFb8n2wNRyGWZc/Y1ivwyyw41eAkRzz0HwgveVpu XIzA== X-Received: by 10.204.147.18 with SMTP id j18mr6901769bkv.2.1361900880846; Tue, 26 Feb 2013 09:48:00 -0800 (PST) References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> From: "A .Riley Eller" Mime-Version: 1.0 (1.0) In-Reply-To: Date: Tue, 26 Feb 2013 09:46:03 -0800 Message-ID: <-790076332194296236@unknownmsgid> To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlDDEzPhqOQLm57s4juqXiyxIlcereLjbnjDYLb4mG2XSVJZ1IhfssNeSrGchh+I1XdbauH Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 17:48:03 -0000 Sorry to pick nits, but couldn't "sequential packet sequence number" be just "packet sequence number" or "sequential packet number"? On Feb 26, 2013, at 9:17 AM, "Dearlove, Christopher (UK)" wrote: > Let's be crystal clear on what NHDP says - whichever way you want to read= it. Section 14.4 is the relevant part, and in whole it reads (where the s= econd bullet is the relevant one, but I've included it all for context). > > A router MAY update link quality based on any information available > to it. Particular cases that MAY be used include: > > o Information from the link layer, such as signal-to-noise ratio or > packet acknowledgment reception and loss information. > > o Receipt or loss of control packets. If control packets include a > sequential packet sequence number, as defined in [RFC5444], then > link quality can be updated when a control packet is received, > whether or not it contains a HELLO message. The link quality may > then, for example, be based on whether the last N out of M control > packets on the link were received, or may use a "leaky integrator" > tracking packet reception and loss. > > o Receipt or loss of HELLO messages. If the maximum interval > between HELLO messages is known (such as by inclusion in HELLO > messages of a Message TLV with Type :=3D INTERVAL_TIME, as defined > in [RFC5497]), then the loss of HELLO messages can be determined > without the need to receive a later HELLO message. Note that if > this case is combined with the previous case, then care must be > taken to avoid "double counting" a lost HELLO message in a lost > packet. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Teco Boot > Sent: 26 February 2013 16:51 > To: Ulrich Herberg > Cc: List > Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Op 26 feb. 2013, om 08:37 heeft Ulrich Herberg het = volgende geschreven: > >> >> >> On Mon, Feb 25, 2013 at 10:41 PM, Teco Boot wrote: >> >> Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg het= volgende geschreven: >> >>> AB, >>> >>> again, sequence numbers are not used by NHDP, therefore not a threat to= NHDP. If another protocols uses that information, it may be a threat to th= at protocol, and may be documented in a security threats analysis for that = protocol. >>> >>> It seems you are the only one advocating for changing the draft on this= aspect. I will wait if someone else also asks for changes on this matter b= efore changing it. >> >> Don't judge too early. I'm with AB that threats on optional parts of a s= tandard should be enlightened. >> >> But it is *not* an optional part of NHDP (nor is it mandatory). It is si= mply named as example what implementers may do, but it is outside of the no= rmative part. I cannot guess what people can implement in addition to the n= ormative part, since there may be infinite possibilities. Please tell me ho= w I should write security threats for these potentially infinite, non-norma= tive, things that people can implement. >> >> I can only repeat it again: NHDP does *not* use sequence numbers, neithe= r packet nor message sequence numbers. > > Than that is your valid response. > > If a protocol has same optional or non-normative elements, I cannot see a= ny reason not to fold in security considerations for it. > No reason to write security considerations down for what is not present. = No infinity here. > > Teco > > > >> >> >> Ulrich > > _______________________________________________ > 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 From drdanhe@gmail.com Tue Feb 26 09:57:55 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB1921F887D for ; Tue, 26 Feb 2013 09:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKrucaLl7Xgn for ; Tue, 26 Feb 2013 09:57:55 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4032D21F8833 for ; Tue, 26 Feb 2013 09:57:55 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id k14so4816136iea.13 for ; Tue, 26 Feb 2013 09:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yIZxX1WiLm+4pTApJsdGOc5fHEEj8mXLGIoV+mHTJwU=; b=InZkc3BjBmYGF5kw9xvnJfGRFx1CE0V/7Je17jl9rGFz1Qgr6WqFhcYZo9vqeYD3X4 Hr2gw6T41L2l+CZ5knf+viqs1LrtmqJXqikCdlejJPd0sZyjcg1DtPCfLnTqud3GZ1E+ kSMZXe+enS0GNJbHIgGdNM6wcupUMC0SGevobuwTsgm6S4FZPDkYM9vqzuaTEvwJxT43 VoD/y8XLXIfh3UXzNMeZBvwSIg8lSrMZNwfNZ7D3smlSXFal530PDQ0AZLaxYRtklcvv 54J0SQ1bN6YtxhH1UrPf6/wQnMpDv0Lf78gbNLvpLg2CtymaBUhb47rPCCIfSzMqz0wj kRjw== MIME-Version: 1.0 X-Received: by 10.50.190.231 with SMTP id gt7mr5760173igc.85.1361901474860; Tue, 26 Feb 2013 09:57:54 -0800 (PST) Received: by 10.50.85.6 with HTTP; Tue, 26 Feb 2013 09:57:54 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 17:57:54 +0000 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=14dae9340d15a0d49e04d6a4656d Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 17:57:56 -0000 --14dae9340d15a0d49e04d6a4656d Content-Type: text/plain; charset=ISO-8859-1 you mean "pillar of salt"! On 26 February 2013 16:35, Abdussalam Baryun wrote: > I don't care about your mailbox, this is not my bussiness, you try to find > to solve your problems. Don't wats my time by your noise to my work in IETF > please, > > AB > > On Tue, Feb 26, 2013 at 4:27 PM, Daniel He wrote: > >> That's not true. If you so called input is just as noise if they are not >> technical relevant. >> it wastes my time and my mailbox storage. I think most of other mailing >> list users >> will feel it as I felt. >> >> Comments are most welcome if the comments are relevant.if the comments >> are technical and critical. Comments should not be a "remind". you should >> not speak >> for the others. for example, " There was a input of John which I refered >> to in the ticket,". you speak for yourself!! >> >> >> >> >> >> On 26 February 2013 16:16, Abdussalam Baryun wrote: >> >>> No one have right to try to discourage inputs, discussions are what this >>> list is for. I know that editors don't like comments, but they have to live >>> with it. For others that don't author work, please just do your job (not to >>> comment on numbers of posts/input, or time spend) or keep quite, >>> >>> AB >>> >>> On Tue, Feb 26, 2013 at 4:10 PM, Daniel He wrote: >>> >>>> It is no good to discuss on the mailing list if it is not technical >>>> relevant. Otherwise, we received too many useless emails without any >>>> technical information. It is not a BBS >>>> website. >>>> >>>> >>>> >>>> On 26 February 2013 16:00, Abdussalam Baryun < >>>> abdussalambaryun@gmail.com> wrote: >>>> >>>>> There is no harm in discussing, issues related to NHDP or RFC5444, >>>>> or erratas, even after they were publish as we all know they are Request >>>>> For Comments, >>>>> >>>>> AB >>>>> >>>>> >>>>> >>>>> >>>> --14dae9340d15a0d49e04d6a4656d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable you mean "pillar of salt"!

On 2= 6 February 2013 16:35, Abdussalam Baryun <abdussalambaryun@gmail.= com> wrote:
I don't care about your mailbox, th= is is not my bussiness, you try to find to solve your problems. Don't w= ats my time by your noise to my work in IETF please,
=A0
AB
On Tue, Feb 26, 2013 at 4:27 PM, Daniel He <drdanhe@gmail.com> wrote:
That's not true. If you so called input is just as noise if they are no= t technical relevant.
it wastes my time and my mailbox storage. I think = most of other mailing list users
will feel it as I felt.

Comments= are most welcome if the comments are relevant.if the comments are technica= l and critical. Comments should not be a "remind". you should not= speak
for the others. for example, " There was a input of John which I refer= ed to in the ticket,". you speak for yourself!!



<= br>
On 26 February 2013 16:16, Abdussalam Bar= yun <abdussalambaryun@gmail.com> wrote:
No one have right to try to discourage inputs, discus= sions are what this list=A0is for. I know that editors don't like comme= nts, but they have to live with it. For others that don't author work, = please just do your job (not to comment on numbers of posts/input, or time = spend)=A0or keep quite,
=A0
AB

On Tue, Feb 2= 6, 2013 at 4:10 PM, Daniel He <drdanhe@gmail.com> wrote:
=
It is no good to discuss on the mailing list if it is not technical relevan= t. Otherwise, we received too many useless emails without any technical inf= ormation. It is not a BBS
website.



On 26 February 2013 16:00, Abdussalam Baryun <abdussalambaryun@g= mail.com> wrote:
There is no harm in discussing, issues related to NHDP or RFC5444, or = erratas,=A0even after they were publish as we all know they are Request For= Comments,
=A0
AB




--14dae9340d15a0d49e04d6a4656d-- From sratliff@cisco.com Tue Feb 26 10:02:54 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D7021F895F for ; Tue, 26 Feb 2013 10:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avFFni9-j4th for ; Tue, 26 Feb 2013 10:02:53 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 204D021F8952 for ; Tue, 26 Feb 2013 10:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17118; q=dns/txt; s=iport; t=1361901773; x=1363111373; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yxLO/FETSna7flaNLP25hZbw1XI/U3rkW+si9hQihUQ=; b=bhd0F422nGaBEk6JU3hRUO8yDllyqxMTZQX+8bRm/e6tYKIboMB0rL5B owh4W+7W/21ywG5FxYzdQx1PDUSBgoZgY0bATLnxogR1A4iIGPxkodJCP pL+n+bSMAc4yalsPkd0tpQ4xFzyfM9WwpeOCKOnnhj3kPrpmkJXAOHK23 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAP33LFGtJXG8/2dsb2JhbABCA4JDtnoBiCp/FnOCHwEBAQICAQEBUhkDCBACAQgHCgQBAQsdByEGCxQJCAIEDgUIh3kDDwyvc4YmDYlSjDyBBwoOgQgGCRIFBgEEBgECBAMIgk5hA4g0jC+Ce4ozhReDCIFpCRce X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208,217";a="181404124" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 26 Feb 2013 18:02:52 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1QI2qbx002590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Feb 2013 18:02:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 12:02:52 -0600 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) Thread-Index: AQHOFDyoURDcZqartkOzKaUvCjTGN5iM0xYA Date: Tue, 26 Feb 2013 18:02:51 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10035AFA@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.34.217] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C10035AFAxmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:02:54 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C10035AFAxmbalnx03ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking as a co-chair - This discussion has now gotten out of line. AB, you DON'T get the option of= telling others to "keep quiet". This needs to stop. Now. Stan On Feb 26, 2013, at 11:16 AM, Abdussalam Baryun wrote: No one have right to try to discourage inputs, discussions are what this li= st is for. I know that editors don't like comments, but they have to live w= ith it. For others that don't author work, please just do your job (not to = comment on numbers of posts/input, or time spend) or keep quite, AB On Tue, Feb 26, 2013 at 4:10 PM, Daniel He > wrote: It is no good to discuss on the mailing list if it is not technical relevan= t. Otherwise, we received too many useless emails without any technical inf= ormation. It is not a BBS website. On 26 February 2013 16:00, Abdussalam Baryun > wrote: There is no harm in discussing, issues related to NHDP or RFC5444, or errat= as, even after they were publish as we all know they are Request For Commen= ts, AB On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) > wrote: NHDP has made it to RFC, and OLSRv2 has made it to one AD short of RFC - an= d not for any related reason - without anyone thinking "we really should us= e that because it might be there - though it also might not". Which suggest= s your technical answer is wrong. And anyway, procedurally it's multiple st= eps too late. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Abdussalam Bar= yun Sent: 26 February 2013 15:50 To: Thomas Heide Clausen Cc: manet@ietf.org Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen > wrote: On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun > wrote: I like that protocols use the packet sequence number, if thoes protocols yo= u refered to don't use the packet SQN, then I recommend they reconsider. Why? "Like" is not a technical argument. I agree that it not a technical word, but also agree that *like* can be use= d in technical volunteer discussions. For example; Why OLSRv2 protocol does= not use the packet sequence number SQN? does it accept random packets and = ignore to sense sequence packets? Why the designers like it to be that way?= Why does AB like protocols to sense SQN? My technical answer is better if it got into a technical draft, however, if= a protocol senses the SQN it will be more rebust and more organised in MAN= ET communication. AB ******************************************************************** 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 -- Dan He --------------------- openstack contributor GPU stream programming http://wiki.openstack.org/Contributors Tel: +44-788-686-3428 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C10035AFAxmbalnx03ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <45BDC0E7903703479406BC5E6011D6AE@cisco.com> Content-Transfer-Encoding: quoted-printable Speaking as a co-chair - 

This discussion has now gotten out of line. AB, you DON'T get the opti= on of telling others to "keep quiet". This needs to stop. Now.

Stan

On Feb 26, 2013, at 11:16 AM, Abdussalam Baryun wrote:

No one have right to try to discourage inputs, discussions are what th= is list is for. I know that editors don't like comments, but they have= to live with it. For others that don't author work, please just do your jo= b (not to comment on numbers of posts/input, or time spend) or keep quite,
 
AB

On Tue, Feb 26, 2013 at 4:10 PM, Daniel He <drdanhe@gmail.co= m> wrote:
It is no good to discuss on the mailing list if it is not technical relevan= t. Otherwise, we received too many useless emails without any technical inf= ormation. It is not a BBS
website.



On 26 February 2013 16:00, Abdussalam Baryun <a= bdussalambaryun@gmail.com> wrote:
There is no harm in discussing, issues related to NHDP or RFC5444, or = erratas, even after they were publish as we all know they are Request = For Comments,
 
AB
On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Chris= topher (UK) <Chris.Dearlove@baesystems.com> wrote:

NHDP has made it to = RFC, and OLSRv2 has made it to one AD short of RFC - and not for any relate= d reason - without anyone thinking "we really should use that because it might be there - though it also might not". Which sug= gests your technical answer is wrong. And anyway, procedurally it's multipl= e steps too late.

 =

--

Christopher Dearlove=

Senior Principal Eng= ineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baes= ystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 =

From: manet-bounces@i= etf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:50
To: Thomas Heide Clausen
Cc: manet@ietf.o= rg


Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)

 

 

*** WARNING ***<= /span>

This message originates from outside our= organisation, either from an external partner or the internet.<= i>
Kee= p this in mind if you answer this message.
Ple= ase see this process on how to deal with suspicious emails.

On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clause= n <thomas@= thomasclausen.org> wrote:

 

On 26 f=E9vr. 2013, at = 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I like that protocols use the packet sequence number= , if thoes protocols you refered to don't use the packet SQN, then I recomm= end they reconsider.

 

Why?

 

"Like" is not a technical argument.=

 =

 

I agree that it not a technical word, but also agree= that *like* can be used in technical volunteer discussions. For examp= le; Why OLSRv2 protocol does not use the packet sequence number SQN? does i= t accept random packets and ignore to sense sequence packets? Why the designers like it to be that way? Why does AB like protoc= ols to sense SQN?

 

My technical answer is better if it got into a techn= ical draft, however, if a protocol senses the SQN it will be more rebust an= d more organised in MANET communication.

 

AB



******************************************************************** 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
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Dan He
---------------------
openstack contributor
GPU stream programming

http:/= /wiki.openstack.org/Contributors

Tel: +44-788-686-3428

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

--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C10035AFAxmbalnx03ciscoc_-- From christopher.dearlove@googlemail.com Tue Feb 26 10:04:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698AA21F88B0 for ; Tue, 26 Feb 2013 10:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48c+H3kcK1Iy for ; Tue, 26 Feb 2013 10:04:06 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 03E2F21F8831 for ; Tue, 26 Feb 2013 10:03:57 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id hi18so5023697wib.15 for ; Tue, 26 Feb 2013 10:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=ehP2haAbRoR1WzmRtmS9WGw9YS5M98wyNYDEdJTu9Zg=; b=s1ShPaGAXNNMyiejvmC9XnRn8QqgAFJHv1bNJXlnbzfF8XYd8l/aZD+Ew8sp36teW2 zDAnvYfcHgfXP4gnKbS30j3cHmZsAE9xrL7ADc2v64mZxZkef8jT+JqWGq7VCH6hzRLi Ecaz4LwFY+OC/rvPJwXhxmvunoddFOyPh/v2E4iGR7JDFX4FDx4HTOotMTjRI8w43tOG hjPjRlvZE63qMki85RmBDstg5wPFxytyskS8hJrR1Dyn440HGMLd8Sfgvvl6LgxKc23t ojiLlFpvoyGOrGRXpWQXOkgZGgvulN5WHKOJWRZ+Ewxk2W4Y2CWaKG2SlmxzU1XQLTTP tcEw== X-Received: by 10.194.19.135 with SMTP id f7mr6026863wje.27.1361901837181; Tue, 26 Feb 2013 10:03:57 -0800 (PST) Received: from [10.216.151.102] (dab-crx1-h-54-1.dab.02.net. [82.132.224.186]) by mx.google.com with ESMTPS id fg6sm3502944wib.10.2013.02.26.10.03.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 10:03:56 -0800 (PST) References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> <-790076332194296236@unknownmsgid> In-Reply-To: <-790076332194296236@unknownmsgid> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8B117) From: Christopher Dearlove Date: Tue, 26 Feb 2013 18:03:43 +0000 To: "A .Riley Eller" Cc: "Dearlove, Christopher \(UK\)" , " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:04:07 -0000 Well, it's rather late to pick nits. But technically packet sequence number i= s the name of the field in RFC 5444. But you could use it non-sequentially (= e.g. pseudo-randomly) which would lead to that form of words to be precise. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 26 Feb 2013, at 17:46, "A .Riley Eller" wrote: > Sorry to pick nits, but couldn't "sequential packet sequence number" > be just "packet sequence number" or "sequential packet number"? >=20 >=20 >=20 > On Feb 26, 2013, at 9:17 AM, "Dearlove, Christopher (UK)" > wrote: >=20 >> Let's be crystal clear on what NHDP says - whichever way you want to read= it. Section 14.4 is the relevant part, and in whole it reads (where the se= cond bullet is the relevant one, but I've included it all for context). >>=20 >> A router MAY update link quality based on any information available >> to it. Particular cases that MAY be used include: >>=20 >> o Information from the link layer, such as signal-to-noise ratio or >> packet acknowledgment reception and loss information. >>=20 >> o Receipt or loss of control packets. If control packets include a >> sequential packet sequence number, as defined in [RFC5444], then >> link quality can be updated when a control packet is received, >> whether or not it contains a HELLO message. The link quality may >> then, for example, be based on whether the last N out of M control >> packets on the link were received, or may use a "leaky integrator" >> tracking packet reception and loss. >>=20 >> o Receipt or loss of HELLO messages. If the maximum interval >> between HELLO messages is known (such as by inclusion in HELLO >> messages of a Message TLV with Type :=3D INTERVAL_TIME, as defined >> in [RFC5497]), then the loss of HELLO messages can be determined >> without the need to receive a later HELLO message. Note that if >> this case is combined with the previous case, then care must be >> taken to avoid "double counting" a lost HELLO message in a lost >> packet. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Teco Boot >> Sent: 26 February 2013 16:51 >> To: Ulrich Herberg >> Cc: List >> Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt= >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> Op 26 feb. 2013, om 08:37 heeft Ulrich Herberg het v= olgende geschreven: >>=20 >>>=20 >>>=20 >>> On Mon, Feb 25, 2013 at 10:41 PM, Teco Boot wrote: >>>=20 >>> Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg het= volgende geschreven: >>>=20 >>>> AB, >>>>=20 >>>> again, sequence numbers are not used by NHDP, therefore not a threat to= NHDP. If another protocols uses that information, it may be a threat to tha= t protocol, and may be documented in a security threats analysis for that pr= otocol. >>>>=20 >>>> It seems you are the only one advocating for changing the draft on this= aspect. I will wait if someone else also asks for changes on this matter be= fore changing it. >>>=20 >>> Don't judge too early. I'm with AB that threats on optional parts of a s= tandard should be enlightened. >>>=20 >>> But it is *not* an optional part of NHDP (nor is it mandatory). It is si= mply named as example what implementers may do, but it is outside of the nor= mative part. I cannot guess what people can implement in addition to the nor= mative part, since there may be infinite possibilities. Please tell me how I= should write security threats for these potentially infinite, non-normative= , things that people can implement. >>>=20 >>> I can only repeat it again: NHDP does *not* use sequence numbers, neithe= r packet nor message sequence numbers. >>=20 >> Than that is your valid response. >>=20 >> If a protocol has same optional or non-normative elements, I cannot see a= ny reason not to fold in security considerations for it. >> No reason to write security considerations down for what is not present. N= o infinity here. >>=20 >> Teco >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> Ulrich >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Tue Feb 26 10:04:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C7821F8831 for ; Tue, 26 Feb 2013 10:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNBDYe1h1q1o for ; Tue, 26 Feb 2013 10:04:07 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF8521F889C for ; Tue, 26 Feb 2013 10:04:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5521; q=dns/txt; s=iport; t=1361901846; x=1363111446; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XtDWt7Wc1LNes0GH2SJDQYjfAUPLsu4ZGwXg33sHkxo=; b=OfRqsFWiIHIWLln2MldLQomjTJrZfhSGvTyTX/qGLQSZXTqGwEz5FIHH +/cu3ZsQOd51tH7A9Tbv/Y2iSJ2/2ukVHKizskC7MyD8TbgU1s++OQA3N fhReWvddpP6veEUHI26adnLJv5y2X78JTD9wiV9ABI9nShT3gsHF76tnp o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAP33LFGtJXHA/2dsb2JhbABFwWh/FnOCIAEBBAEBAWsLEAIBCCIdByEGCxQRAgQOBQiHeQMPDK9zhiYNiU4EjDyBBw8HgQoxB4JfYQOINIwvjS6FF4MIgWoIFx4 X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208,217";a="181381116" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 26 Feb 2013 18:04:05 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1QI45Lj017786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Feb 2013 18:04:05 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 12:04:05 -0600 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) Thread-Index: AQHOFDyoURDcZqartkOzKaUvCjTGN5iMuFqAgAACzoCAAAM7gIAAAM8AgAAUPAA= Date: Tue, 26 Feb 2013 18:04:04 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10035B0C@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.34.217] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C10035B0Cxmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:04:08 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C10035B0Cxmbalnx03ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, as a chair, I'll reply to this email as well. THIS. IS. NOISE. It is not relevant. Please halt, cease, and desist. Stan On Feb 26, 2013, at 11:51 AM, Abdussalam Baryun wrote: On Tue, Feb 26, 2013 at 4:48 PM, Daniel He > wrote: It is yourself decides what is relevant. if you have no sense whether you are beating dead house, you are not a technical guy! We all know that, the one who decides what is not relavent or noise is the= Chair not you, AB "what is chair's job", please refer to RFC2418. I don't need to read any thing, just please stop taking my time, AB On 26 February 2013 16:37, Abdussalam Baryun > wrote: On Tue, Feb 26, 2013 at 4:27 PM, Daniel He > wrote: That's not true. If you so called input is just as noise if they are not te= chnical relevant. it wastes my time and my mailbox storage. I think most of other mailing lis= t users will feel it as I felt. Comments are most welcome if the comments are relevant. Who decides what is relavent. Please let the CHair do his job and never put= your nose into other peoples work AB _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C10035B0Cxmbalnx03ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7983AF958516A343A22FC96498B3EA2C@cisco.com> Content-Transfer-Encoding: quoted-printable OK, as a chair, I'll reply to this email as well. 

THIS. IS. NOISE. It is not relevant. Please halt, cease, and desist.&n= bsp;

Stan


On Feb 26, 2013, at 11:51 AM, Abdussalam Baryun wrote:

On Tue, Feb 26, 2013 at 4:48 PM, Daniel He <drdanhe@gmail.co= m> wrote:
It is yourself decides what is relevant. if you have no sense whether you are beating dead house, you are not a technical guy!
 
We all  know that, the one who decides what is not relavent = or noise is the Chair not you,
 
AB
 

"what is chair's job", please refer to RFC2418.

 
I don't need to read any thing, just please stop taking my time,
 
AB 
 
 


On 26 February 2013 16:37, Abdussalam Baryun <abdussa= lambaryun@gmail.com> wrote:
On Tue, Feb 26, 2013 at 4:27 PM, Daniel He <drdanhe@gmail.com>= wrote:
That's not true. If you so called input is just as noise if they are not te= chnical relevant.
it wastes my time and my mailbox storage. I think most of other mailing lis= t users
will feel it as I felt.

Comments are most welcome if the comments are relevant.
 
Who decides what is relavent. Please let the CHair do his job and = ;never put your nose into other peoples work
 
AB


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

--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C10035B0Cxmbalnx03ciscoc_-- From abdussalambaryun@gmail.com Tue Feb 26 10:14:16 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A9A21F88BC for ; Tue, 26 Feb 2013 10:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awg00MElCm27 for ; Tue, 26 Feb 2013 10:14:15 -0800 (PST) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id EB16C21F8951 for ; Tue, 26 Feb 2013 10:14:14 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id un15so2504685pbc.38 for ; Tue, 26 Feb 2013 10:14:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5rz5sWSgU7a1e91LRB4GP5DdcyC46W8HN1/Osoyekl0=; b=eJIm3Mqgg24CEGrYgvCGLZxEO7DKx7OXtJAwKSu7MX2/gYCt78GuSLQgsqZDRTRazS KyvtJhMSd3dyQhhxToXNK6OcEmahOttTA8d7ZL55bGK2pB+TKTjwEMUrkYZmE4bGZ49H mo3RhsIJ578Fl+uubpTE+rqlEqvoBaa2xt9jlVSxBEq7plRniPUZYszef3fuhZpYi9uQ Jz+RpW8Mhm2JTP8thTT1RAOJmHVwznA8ba+TsBGHlBwUQE6GPYhjzEonZ+Bw6FGPgwJt DllnxQvPdgjKRNm+ppUv4lrPhfuM7AVGGmbm8/S/9xkBGdFyK101VXqcFsmRFboodR2T nmuw== MIME-Version: 1.0 X-Received: by 10.68.153.97 with SMTP id vf1mr24673769pbb.93.1361902454652; Tue, 26 Feb 2013 10:14:14 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 10:14:14 -0800 (PST) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10035AFA@xmb-aln-x03.cisco.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C10035AFA@xmb-aln-x03.cisco.com> Date: Tue, 26 Feb 2013 18:14:14 +0000 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=f46d041701bd07488404d6a4a055 Cc: "manet@ietf.org" Subject: Re: [manet] An input (was Re: [Technical Errata Reported] RFC5444 (3496)) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:14:16 -0000 --f46d041701bd07488404d6a4a055 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I did not tell others to keep quite, I said that not to claim that I am noise or spam, you misunderstood me, I like comments, but never discouragin= g Any way I will stop replying to such messages that don't respect others, AB On Tue, Feb 26, 2013 at 6:02 PM, Stan Ratliff (sratliff) wrote: > Speaking as a co-chair - > > This discussion has now gotten out of line. AB, you DON'T get the option > of telling others to "keep quiet". This needs to stop. Now. > > Stan > > On Feb 26, 2013, at 11:16 AM, Abdussalam Baryun wrote: > > No one have right to try to discourage inputs, discussions are what this > list is for. I know that editors don't like comments, but they have to li= ve > with it. For others that don't author work, please just do your job (not = to > comment on numbers of posts/input, or time spend) or keep quite, > > AB > > On Tue, Feb 26, 2013 at 4:10 PM, Daniel He wrote: > >> It is no good to discuss on the mailing list if it is not technical >> relevant. Otherwise, we received too many useless emails without any >> technical information. It is not a BBS >> website. >> >> >> >> On 26 February 2013 16:00, Abdussalam Baryun > > wrote: >> >>> There is no harm in discussing, issues related to NHDP or RFC5444, or >>> erratas, even after they were publish as we all know they are Request F= or >>> Comments, >>> >>> AB >>> >>> On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) < >>> Chris.Dearlove@baesystems.com> wrote: >>> >>>> NHDP has made it to RFC, and OLSRv2 has made it to one AD short of >>>> RFC - and not for any related reason - without anyone thinking "we rea= lly >>>> should use that because it might be there - though it also might not". >>>> Which suggests your technical answer is wrong. And anyway, procedurall= y >>>> it's multiple steps too late.**** >>>> >>>> ** ** >>>> >>>> -- **** >>>> >>>> Christopher Dearlove**** >>>> >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >>>> >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>> >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>> Centre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687**** >>>> >>>> ** ** >>>> >>>> *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On >>>> Behalf Of *Abdussalam Baryun >>>> *Sent:* 26 February 2013 15:50 >>>> *To:* Thomas Heide Clausen >>>> *Cc:* manet@ietf.org >>>> >>>> *Subject:* Re: [manet] [Technical Errata Reported] RFC5444 (3496)**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> **** WARNING **** >>>> >>>> *This message originates from outside our organisation, either from an >>>> external partner or the internet.** >>>> Keep this in mind if you answer this message. >>>> Please see this processon ho= w to deal with suspicious emails. >>>> ***** >>>> >>>> On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clausen < >>>> thomas@thomasclausen.org> wrote:**** >>>> >>>> ** ** >>>> >>>> On 26 f=E9vr. 2013, at 16:00, Abdussalam Baryun < >>>> abdussalambaryun@gmail.com> wrote:**** >>>> >>>> I like that protocols use the packet sequence number, if thoes >>>> protocols you refered to don't use the packet SQN, then I recommend th= ey >>>> reconsider.**** >>>> >>>> ** ** >>>> >>>> Why?**** >>>> >>>> ** ** >>>> >>>> "Like" is not a technical argument.**** >>>> >>>> ** ** >>>> >>>> **** >>>> >>>> I agree that it not a technical word, but also agree that *like* can b= e >>>> used in technical volunteer discussions. For example; Why OLSRv2 proto= col >>>> does not use the packet sequence number SQN? does it accept random pac= kets >>>> and ignore to sense sequence packets? Why the designers like it to be = that >>>> way? Why does AB like protocols to sense SQN?**** >>>> >>>> **** >>>> >>>> My technical answer is better if it got into a technical draft, >>>> however, if a protocol senses the SQN it will be more rebust and more >>>> organised in MANET communication.**** >>>> >>>> **** >>>> >>>> AB**** >>>> >>>> >>>> ******************************************************************** >>>> 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 >>> >>> >> >> >> -- >> Dan He >> --------------------- >> openstack contributor >> GPU stream programming >> >> http://wiki.openstack.org/Contributors >> >> Tel: +44-788-686-3428 >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --f46d041701bd07488404d6a4a055 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I did not tell others to keep quite, I said that not to claim that I a= m noise or spam, you misunderstood me, I like comments, but never discourag= ing
Any way I will stop replying to such messages that don= 9;t respect others,
=A0
AB
On Tue, Feb 26, 2= 013 at 6:02 PM, Stan Ratliff (sratliff) <sratliff@cisco.com> wrote:
Speaking as a co-chair -=A0

This discussion has now gotten out of line. AB, you DON'T get the = option of telling others to "keep quiet". This needs to stop. Now= .

Stan

On Feb 26, 2013, at 11:16 AM, Abdussalam Baryun wrote:

No one have right to try to discourage inputs, discussions are what th= is list=A0is for. I know that editors don't like comments, but they hav= e to live with it. For others that don't author work, please just do yo= ur job (not to comment on numbers of posts/input, or time spend)=A0or keep quite,
=A0
AB

On Tue, Feb 26, 2013 at 4:10 PM, Daniel He <drdanhe@gmail.co= m> wrote:
It is no good to discuss on the mailing list if it is not technical relevan= t. Otherwise, we received too many useless emails without any technical inf= ormation. It is not a BBS
website.



On 26 February 2013 16:00, Abdussalam Baryun <abdussalambary= un@gmail.com> wrote:
There is no harm in discussing, issues related to NHDP or RFC5444, or = erratas,=A0even after they were publish as we all know they are Request For= Comments,
=A0
AB
On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Chris= topher (UK) <Chris.Dearlove@baesystems.com> wrote:

NHDP has made it to = RFC, and OLSRv2 has made it to one AD short of RFC - and not for any relate= d reason - without anyone thinking "we really should use that because it might be there - though it also might not". Which sug= gests your technical answer is wrong. And anyway, procedurally it's mul= tiple steps too late.

=A0

--

Christopher Dearlove=

Senior Principal Eng= ineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baes= ystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0

From: manet-bounces@i= etf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:50
To: Thomas Heide Clausen
Cc: manet@ietf.o= rg


Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)

=A0

=A0

*** WARNING ***<= /span>

This message originates from outside our= organisation, either from an external partner or the internet.<= i>
Kee= p this in mind if you answer this message.
Ple= ase see this process on how to deal with suspicious emails.

On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clause= n <thomas@= thomasclausen.org> wrote:

=A0

On 26 f=E9vr. 2013, at = 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I like that protocols use the packet sequence number= , if thoes protocols you refered to don't use the packet SQN, then I re= commend they reconsider.

=A0

Why?

=A0

"Like" is not a technical argument.=

=A0=

=A0

I agree that it not a technical word, but also agree= that *like*=A0can be used in technical volunteer discussions. For example;= Why OLSRv2 protocol does not use the packet sequence number SQN? does it a= ccept random packets and ignore to sense=A0sequence packets? Why the designers like it to be that way? Why does AB like protoc= ols to sense SQN?

=A0

My technical answer is better if it got into a techn= ical draft, however, if a protocol senses the SQN it will be more rebust an= d more organised in=A0MANET communication.

=A0

AB



******************************************************************** 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
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Dan He
---------------------
openstack contributor
GPU stream programming

http:/= /wiki.openstack.org/Contributors

Tel: +44-788-686-3428

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


--f46d041701bd07488404d6a4a055-- From teco@inf-net.nl Tue Feb 26 11:00:38 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CFD21F8546 for ; Tue, 26 Feb 2013 11:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.413 X-Spam-Level: X-Spam-Status: No, score=-1.413 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDOf0JDZ4iWx for ; Tue, 26 Feb 2013 11:00:37 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 749FC21F8540 for ; Tue, 26 Feb 2013 11:00:36 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id d7so3755921wer.36 for ; Tue, 26 Feb 2013 11:00:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Dm+fqoDZo3oKvJR2e7A+dRBTr0Jsu/Yl4FGbRd1HU+M=; b=N8lFAgb+zbU1MNyJjAaa29YmwXaKJzGrfGem1ejz5racIlDlBS0GnplbMaqZIEhbaS MqQot22wyBZfsZyDQO6PEHrWB2JxqYp0hb7bPmTO1EMm475RlOAh5KRErIrRy5ahMU1w 3d1AXfjcNQ92EohUkqfND7CsIusj4a2UjeTd+D4QeF4XZmNI+9OBRWyi4qHKQZefmgrh 4hjTnMa6Esv5nCvjvbHWwyUkG+Y2eLaFuGREKte0ylPLXqSThMrWh74iWFcHo5Ga2kOT oNp51BFeY6V2K9MLiXNrBrTpdt43WpdOJRyVMI7ROFsKuGxcT+e6ppscXtIEhgWcXiEi swpA== X-Received: by 10.194.58.202 with SMTP id t10mr28918871wjq.4.1361905232867; Tue, 26 Feb 2013 11:00:32 -0800 (PST) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id bs6sm3866737wib.4.2013.02.26.11.00.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 11:00:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Tue, 26 Feb 2013 20:00:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQllaqtey8xEq6WBT1sII2+6QhGq1huYTroLUoZlTtfLGcPevzlXxuoBALhlNeIssHGGTbQo Cc: " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:00:38 -0000 Due to some mail bombs, I couldn't find time to check the documents. I'm = not the only one. Today, the mail server I'm using was overloaded. It is = not the smallest mail system on earth, so to say. Please send real = contributions only. I have nothing against a description of a NHDP security threat on packet = sequence number attack. Could be a single sentence, such as: "If a NHDP = link quality measurement is based on MANET control packet sequence = numbers, as described in RFC 6130 section 14.4, such a mechanism can be = influenced by spoofed packets or other attacks." BTW: why are NHDP message sequence numbers mentioned in Appendix C? If = unneeded, let's not send such. If it has some purpose, what are the = threats? Teco Op 26 feb. 2013, om 18:16 heeft Dearlove, Christopher (UK) het volgende = geschreven: > Let's be crystal clear on what NHDP says - whichever way you want to = read it. Section 14.4 is the relevant part, and in whole it reads = (where the second bullet is the relevant one, but I've included it all = for context). >=20 > A router MAY update link quality based on any information available > to it. Particular cases that MAY be used include: >=20 > o Information from the link layer, such as signal-to-noise ratio or > packet acknowledgment reception and loss information. >=20 > o Receipt or loss of control packets. If control packets include a > sequential packet sequence number, as defined in [RFC5444], then > link quality can be updated when a control packet is received, > whether or not it contains a HELLO message. The link quality may > then, for example, be based on whether the last N out of M = control > packets on the link were received, or may use a "leaky = integrator" > tracking packet reception and loss. >=20 > o Receipt or loss of HELLO messages. If the maximum interval > between HELLO messages is known (such as by inclusion in HELLO > messages of a Message TLV with Type :=3D INTERVAL_TIME, as = defined > in [RFC5497]), then the loss of HELLO messages can be determined > without the need to receive a later HELLO message. Note that if > this case is combined with the previous case, then care must be > taken to avoid "double counting" a lost HELLO message in a lost > packet. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Teco Boot > Sent: 26 February 2013 16:51 > To: Ulrich Herberg > Cc: List > Subject: Re: [manet] I-D Action: = draft-ietf-manet-nhdp-sec-threats-01.txt >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Op 26 feb. 2013, om 08:37 heeft Ulrich Herberg = het volgende geschreven: >=20 >>=20 >>=20 >> On Mon, Feb 25, 2013 at 10:41 PM, Teco Boot wrote: >>=20 >> Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg = het volgende geschreven: >>=20 >>> AB, >>>=20 >>> again, sequence numbers are not used by NHDP, therefore not a threat = to NHDP. If another protocols uses that information, it may be a threat = to that protocol, and may be documented in a security threats analysis = for that protocol. >>>=20 >>> It seems you are the only one advocating for changing the draft on = this aspect. I will wait if someone else also asks for changes on this = matter before changing it. >>=20 >> Don't judge too early. I'm with AB that threats on optional parts of = a standard should be enlightened. >>=20 >> But it is *not* an optional part of NHDP (nor is it mandatory). It is = simply named as example what implementers may do, but it is outside of = the normative part. I cannot guess what people can implement in addition = to the normative part, since there may be infinite possibilities. Please = tell me how I should write security threats for these potentially = infinite, non-normative, things that people can implement.=20 >>=20 >> I can only repeat it again: NHDP does *not* use sequence numbers, = neither packet nor message sequence numbers. >=20 > Than that is your valid response. >=20 > If a protocol has same optional or non-normative elements, I cannot = see any reason not to fold in security considerations for it. > No reason to write security considerations down for what is not = present. No infinity here. >=20 > Teco >=20 >=20 >=20 >>=20 >>=20 >> Ulrich >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 From abdussalambaryun@gmail.com Tue Feb 26 11:55:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6D621F8790 for ; Tue, 26 Feb 2013 11:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwNWMeBfro6R for ; Tue, 26 Feb 2013 11:54:59 -0800 (PST) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id 83F6021F8788 for ; Tue, 26 Feb 2013 11:54:59 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so1073996dak.16 for ; Tue, 26 Feb 2013 11:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fSe9oGlj5HFj8rcb94lQVbWZ9UK24ZULKHISZzhn/Js=; b=umAVf589AAW24qWUKQJTVIKlYH8n+86nDqrK5tkiW9LOxxIA+BP1YZRAlCuzNLzQp5 nnmdbjwA3QAmgtZtYasr47W0Wz9/UtVGiL4FM2ZRKKWFtVTDkiECASW3lKjOJRIE0O5n VbOeqxN8PRfZ5vG+Rl9y77aMW61mVlhLXf6qw2GZIV/CgPJtM1Kl4ex9pSVQ7jwwE9g/ RMKdSVdzN8gexRiAR3c3Z/d2O5siTJvaPlXdEHHbfaCuiRVWIvV7eNLaOICE8aQRsmmG HemHJmp4ijD02JJt88PJo40gwD8Qrry+rfV1iOscGLrQEignJbg8Mssz/svWy+FzRFM6 tirw== MIME-Version: 1.0 X-Received: by 10.68.245.229 with SMTP id xr5mr25213593pbc.163.1361908499288; Tue, 26 Feb 2013 11:54:59 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 11:54:59 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Tue, 26 Feb 2013 19:54:59 +0000 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: multipart/alternative; boundary=047d7b2e155d51196004d6a60823 Cc: "Dearlove, Christopher \(UK\)" , " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:55:00 -0000 --047d7b2e155d51196004d6a60823 Content-Type: text/plain; charset=ISO-8859-1 +1 AB On Tue, Feb 26, 2013 at 7:00 PM, Teco Boot wrote: > Due to some mail bombs, I couldn't find time to check the documents. I'm > not the only one. Today, the mail server I'm using was overloaded. It is > not the smallest mail system on earth, so to say. Please send real > contributions only. > > I have nothing against a description of a NHDP security threat on packet > sequence number attack. Could be a single sentence, such as: "If a NHDP > link quality measurement is based on MANET control packet sequence numbers, > as described in RFC 6130 section 14.4, such a mechanism can be influenced > by spoofed packets or other attacks." > > BTW: why are NHDP message sequence numbers mentioned in Appendix C? If > unneeded, let's not send such. If it has some purpose, what are the threats? > > Teco > > > Op 26 feb. 2013, om 18:16 heeft Dearlove, Christopher (UK) het volgende > geschreven: > > > Let's be crystal clear on what NHDP says - whichever way you want to > read it. Section 14.4 is the relevant part, and in whole it reads (where > the second bullet is the relevant one, but I've included it all for > context). > > > > A router MAY update link quality based on any information available > > to it. Particular cases that MAY be used include: > > > > o Information from the link layer, such as signal-to-noise ratio or > > packet acknowledgment reception and loss information. > > > > o Receipt or loss of control packets. If control packets include a > > sequential packet sequence number, as defined in [RFC5444], then > > link quality can be updated when a control packet is received, > > whether or not it contains a HELLO message. The link quality may > > then, for example, be based on whether the last N out of M control > > packets on the link were received, or may use a "leaky integrator" > > tracking packet reception and loss. > > > > o Receipt or loss of HELLO messages. If the maximum interval > > between HELLO messages is known (such as by inclusion in HELLO > > messages of a Message TLV with Type := INTERVAL_TIME, as defined > > in [RFC5497]), then the loss of HELLO messages can be determined > > without the need to receive a later HELLO message. Note that if > > this case is combined with the previous case, then care must be > > taken to avoid "double counting" a lost HELLO message in a lost > > packet. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Teco Boot > > Sent: 26 February 2013 16:51 > > To: Ulrich Herberg > > Cc: List > > Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt > > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > > Op 26 feb. 2013, om 08:37 heeft Ulrich Herberg > het volgende geschreven: > > > >> > >> > >> On Mon, Feb 25, 2013 at 10:41 PM, Teco Boot wrote: > >> > >> Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg > het volgende geschreven: > >> > >>> AB, > >>> > >>> again, sequence numbers are not used by NHDP, therefore not a threat > to NHDP. If another protocols uses that information, it may be a threat to > that protocol, and may be documented in a security threats analysis for > that protocol. > >>> > >>> It seems you are the only one advocating for changing the draft on > this aspect. I will wait if someone else also asks for changes on this > matter before changing it. > >> > >> Don't judge too early. I'm with AB that threats on optional parts of a > standard should be enlightened. > >> > >> But it is *not* an optional part of NHDP (nor is it mandatory). It is > simply named as example what implementers may do, but it is outside of the > normative part. I cannot guess what people can implement in addition to the > normative part, since there may be infinite possibilities. Please tell me > how I should write security threats for these potentially infinite, > non-normative, things that people can implement. > >> > >> I can only repeat it again: NHDP does *not* use sequence numbers, > neither packet nor message sequence numbers. > > > > Than that is your valid response. > > > > If a protocol has same optional or non-normative elements, I cannot see > any reason not to fold in security considerations for it. > > No reason to write security considerations down for what is not present. > No infinity here. > > > > Teco > > > > > > > >> > >> > >> Ulrich > > > > _______________________________________________ > > 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 > --047d7b2e155d51196004d6a60823 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1
=A0
AB

= On Tue, Feb 26, 2013 at 7:00 PM, Teco Boot <teco@inf-net.nl> w= rote:
Due to some mail bombs, I couldn't find time to check = the documents. I'm not the only one. Today, the mail server I'm usi= ng was overloaded. It is not the smallest mail system on earth, so to say. = Please send real contributions only.

I have nothing against a description of a NHDP security threat on packet se= quence number attack. Could be a single sentence, such as: "If a NHDP = link quality measurement is based on MANET control packet sequence numbers,= as described in RFC 6130 section 14.4, such a mechanism can be influenced = by spoofed packets or other attacks."

BTW: why are NHDP message sequence numbers mentioned in Appendix C? If unne= eded, let's not send such. If it has some purpose, what are the threats= ?

Teco


Op 26 feb. 2013, om 18:16 heeft Dearlove, Christopher (UK) het volgende ges= chreven:

> Let's be crystal clear on what NHDP says - whichever way you want = to read it. =A0Section 14.4 is the relevant part, and in whole it reads (wh= ere the second bullet is the relevant one, but I've included it all for= context).
>
> =A0 A router MAY update link quality based on any information availabl= e
> =A0 to it. =A0Particular cases that MAY be used include:
>
> =A0 o =A0Information from the link layer, such as signal-to-noise rati= o or
> =A0 =A0 =A0packet acknowledgment reception and loss information.
>
> =A0 o =A0Receipt or loss of control packets. =A0If control packets inc= lude a
> =A0 =A0 =A0sequential packet sequence number, as defined in [RFC5444],= then
> =A0 =A0 =A0link quality can be updated when a control packet is receiv= ed,
> =A0 =A0 =A0whether or not it contains a HELLO message. =A0The link qua= lity may
> =A0 =A0 =A0then, for example, be based on whether the last N out of M = control
> =A0 =A0 =A0packets on the link were received, or may use a "leaky= integrator"
> =A0 =A0 =A0tracking packet reception and loss.
>
> =A0 o =A0Receipt or loss of HELLO messages. =A0If the maximum interval=
> =A0 =A0 =A0between HELLO messages is known (such as by inclusion in HE= LLO
> =A0 =A0 =A0messages of a Message TLV with Type :=3D INTERVAL_TIME, as = defined
> =A0 =A0 =A0in [RFC5497]), then the loss of HELLO messages can be deter= mined
> =A0 =A0 =A0without the need to receive a later HELLO message. =A0Note = that if
> =A0 =A0 =A0this case is combined with the previous case, then care mus= t be
> =A0 =A0 =A0taken to avoid "double counting" a lost HELLO mes= sage in a lost
> =A0 =A0 =A0packet.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44= 1245 242194 | =A0Fax: +44 1245 242124
> chris.dearlove@baesys= tems.com | http= ://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> -----Original Message-----
> From: manet-bounces@ietf.org= [mailto:manet-bounces@ietf.o= rg] On Behalf Of Teco Boot
> Sent: 26 February 2013 16:51
> To: Ulrich Herberg
> Cc: <manet@ietf.org> List<= br> > Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.= txt
>
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> Op 26 feb. 2013, om 08:37 heeft Ulrich Herberg <ulrich@herberg.name> het volgende geschreven: >
>>
>>
>> On Mon, Feb 25, 2013 at 10:41 PM, Teco Boot <teco@inf-net.nl> wrote:
>>
>> Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg <ulrich@herberg.name> het volgende geschreven= :
>>
>>> AB,
>>>
>>> again, sequence numbers are not used by NHDP, therefore not a = threat to NHDP. If another protocols uses that information, it may be a thr= eat to that protocol, and may be documented in a security threats analysis = for that protocol.
>>>
>>> It seems you are the only one advocating for changing the draf= t on this aspect. I will wait if someone else also asks for changes on this= matter before changing it.
>>
>> Don't judge too early. I'm with AB that threats on optiona= l parts of a standard should be enlightened.
>>
>> But it is *not* an optional part of NHDP (nor is it mandatory). It= is simply named as example what implementers may do, but it is outside of = the normative part. I cannot guess what people can implement in addition to= the normative part, since there may be infinite possibilities. Please tell= me how I should write security threats for these potentially infinite, non= -normative, things that people can implement.
>>
>> I can only repeat it again: NHDP does *not* use sequence numbers, = neither packet nor message sequence numbers.
>
> Than that is your valid response.
>
> If a protocol has same optional or non-normative elements, I cannot se= e any reason not to fold in security considerations for it.
> No reason to write security considerations down for what is not presen= t. No infinity here.
>
> Teco
>
>
>
>>
>>
>> Ulrich
>
> _______________________________________________
> 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
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7b2e155d51196004d6a60823-- From yi.jiazi@gmail.com Tue Feb 26 12:04:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B48A21F8884 for ; Tue, 26 Feb 2013 12:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.075 X-Spam-Level: * X-Spam-Status: No, score=1.075 tagged_above=-999 required=5 tests=[AWL=-1.810, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcyvtuZ9p9H9 for ; Tue, 26 Feb 2013 12:04:32 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 876D721F8873 for ; Tue, 26 Feb 2013 12:04:27 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id ds1so4678321wgb.0 for ; Tue, 26 Feb 2013 12:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=EzEZKWSoxA2Z+NOivUrFR1cYx0aQlGfwhMrqRAN0S6g=; b=dHQZ8kmXPxsKJDQT92HVw8npDqroGWFU28Py2JTgVYhp48sUmNvZ4HRvqxwE9StZC5 6Hpym1/iV78T/+inl6xmZ3WLSTMDM3kRjY1AQer2Ch1WXanGUuk4UwQJdnKCHEtxs8zW 9ze+wkLOxXaI/JI/vMYD6P9xwJlaE7xmtRzW+e8dThIszZDCvU7NR37Lb9qRz5dQKL2L S4lpUol98M7qfPomEMk/zzG11/5gZ3YvO0U50I9c4Fs/nL8Zuk07UJzCa7CdBjbEx8JZ h2X2xvURmSvQpFpMXpCIHZbEGPDWEf6DYkgKBkBJuill4TLgjq3JwyqP321+ruNk1IMi 5uTA== X-Received: by 10.180.83.10 with SMTP id m10mr21810003wiy.5.1361909066616; Tue, 26 Feb 2013 12:04:26 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id n2sm23214072wiy.6.2013.02.26.12.04.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 12:04:25 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: Date: Tue, 26 Feb 2013 21:04:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> To: Teco Boot X-Mailer: Apple Mail (2.1499) Cc: "Dearlove, Christopher \(UK\)" , " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:04:33 -0000 Hi,=20 On the threat related to sequence number, my opinion is: 1. The "sequence number attack" in revision -00 is clearly wrong (for = duplicate detection), and not relevant to NHDP. So it has to be removed.=20= 2. The packet sequence number is not normative part of NHDP, however, it = may affects link quality updates. Therefore, I would agree with Teco, = that we can have a brief sentence to describe this threat, for example, = in identity spoofing section. On the appendix C, it is a little strange that a message sequence number = is included. For me, it's unnecessary.=20 best=20 Jiazi On Feb 26, 2013, at 8:00 PM, Teco Boot wrote: > Due to some mail bombs, I couldn't find time to check the documents. = I'm not the only one. Today, the mail server I'm using was overloaded. = It is not the smallest mail system on earth, so to say. Please send real = contributions only. >=20 > I have nothing against a description of a NHDP security threat on = packet sequence number attack. Could be a single sentence, such as: "If = a NHDP link quality measurement is based on MANET control packet = sequence numbers, as described in RFC 6130 section 14.4, such a = mechanism can be influenced by spoofed packets or other attacks." >=20 > BTW: why are NHDP message sequence numbers mentioned in Appendix C? If = unneeded, let's not send such. If it has some purpose, what are the = threats? >=20 > Teco >=20 >=20 > Op 26 feb. 2013, om 18:16 heeft Dearlove, Christopher (UK) het = volgende geschreven: >=20 >> Let's be crystal clear on what NHDP says - whichever way you want to = read it. Section 14.4 is the relevant part, and in whole it reads = (where the second bullet is the relevant one, but I've included it all = for context). >>=20 >> A router MAY update link quality based on any information available >> to it. Particular cases that MAY be used include: >>=20 >> o Information from the link layer, such as signal-to-noise ratio or >> packet acknowledgment reception and loss information. >>=20 >> o Receipt or loss of control packets. If control packets include a >> sequential packet sequence number, as defined in [RFC5444], then >> link quality can be updated when a control packet is received, >> whether or not it contains a HELLO message. The link quality may >> then, for example, be based on whether the last N out of M = control >> packets on the link were received, or may use a "leaky = integrator" >> tracking packet reception and loss. >>=20 >> o Receipt or loss of HELLO messages. If the maximum interval >> between HELLO messages is known (such as by inclusion in HELLO >> messages of a Message TLV with Type :=3D INTERVAL_TIME, as = defined >> in [RFC5497]), then the loss of HELLO messages can be determined >> without the need to receive a later HELLO message. Note that if >> this case is combined with the previous case, then care must be >> taken to avoid "double counting" a lost HELLO message in a lost >> packet. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Teco Boot >> Sent: 26 February 2013 16:51 >> To: Ulrich Herberg >> Cc: List >> Subject: Re: [manet] I-D Action: = draft-ietf-manet-nhdp-sec-threats-01.txt >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> Op 26 feb. 2013, om 08:37 heeft Ulrich Herberg = het volgende geschreven: >>=20 >>>=20 >>>=20 >>> On Mon, Feb 25, 2013 at 10:41 PM, Teco Boot wrote: >>>=20 >>> Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg = het volgende geschreven: >>>=20 >>>> AB, >>>>=20 >>>> again, sequence numbers are not used by NHDP, therefore not a = threat to NHDP. If another protocols uses that information, it may be a = threat to that protocol, and may be documented in a security threats = analysis for that protocol. >>>>=20 >>>> It seems you are the only one advocating for changing the draft on = this aspect. I will wait if someone else also asks for changes on this = matter before changing it. >>>=20 >>> Don't judge too early. I'm with AB that threats on optional parts of = a standard should be enlightened. >>>=20 >>> But it is *not* an optional part of NHDP (nor is it mandatory). It = is simply named as example what implementers may do, but it is outside = of the normative part. I cannot guess what people can implement in = addition to the normative part, since there may be infinite = possibilities. Please tell me how I should write security threats for = these potentially infinite, non-normative, things that people can = implement.=20 >>>=20 >>> I can only repeat it again: NHDP does *not* use sequence numbers, = neither packet nor message sequence numbers. >>=20 >> Than that is your valid response. >>=20 >> If a protocol has same optional or non-normative elements, I cannot = see any reason not to fold in security considerations for it. >> No reason to write security considerations down for what is not = present. No infinity here. >>=20 >> Teco >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> Ulrich >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Tue Feb 26 12:12:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5B521F8804 for ; Tue, 26 Feb 2013 12:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYKKLLdcDMDJ for ; Tue, 26 Feb 2013 12:12:46 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 62B0D21F85A1 for ; Tue, 26 Feb 2013 12:12:46 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id m4so3444974lbo.14 for ; Tue, 26 Feb 2013 12:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Ccr2ME1NWwzl2hvXPLQXRW40nnGi+Vbn4T89TNEXHvw=; b=vPgaZ41WlEIjBhmf97r4MldVmzGUXVjsbVm3RiO8wcaHUmMYFFLzkIjb9RvivspZ/8 393nTcaPr9X5x3i/hddqcvqqUhmVb25VYnuehD3PWVrsGDWyATIweSuFU34InPD/EWie IUAdJzj3x7KC0Q0QdRVRO4eeXNGOTgDii2FxjJsOqzT0j7U2AB/FMzEP+xHDXnBf49ct 0xdoVCn8WIC7HpctrulZFf0lVSzCAodqz7GktKpHc/o864/Xfuy3O3kCv4d/GW4cW9pu gIuuoOqw4I/zktiN8NX7YUTTzUVynx/xtsTRImB5uqANtlytrNDdmnkdOiezT+DqNjO1 nzdQ== X-Received: by 10.152.102.177 with SMTP id fp17mr14907441lab.0.1361909565237; Tue, 26 Feb 2013 12:12:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Tue, 26 Feb 2013 12:12:24 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> From: Henning Rogge Date: Tue, 26 Feb 2013 21:12:24 +0100 Message-ID: To: Jiazi Yi Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:12:47 -0000 On Tue, Feb 26, 2013 at 9:04 PM, Jiazi Yi wrote: > Hi, > > On the threat related to sequence number, my opinion is: > > 1. The "sequence number attack" in revision -00 is clearly wrong (for duplicate detection), and not relevant to NHDP. So it has to be removed. Yes. This one HAD to go. > 2. The packet sequence number is not normative part of NHDP, however, it may affects link quality updates. Therefore, I would agree with Teco, that we can have a brief sentence to describe this threat, for example, in identity spoofing section. What do you think about a compromise. Instead of focusing on the packet sequence for attacks on the link hysteresis, we could add a text that by implementing the hysteresis, the new input of the protocol will open more possible attack vectors... and add the packet sequence number as an example. We cannot even say for sure how/if an attack through this vector would work, because it would depend on the implementation of the link hysteresis. So we should not go into too much details. We might want to add a similar section for the coming olsrv2 threats document... by implementing a link metric, the implementation might open new attack vectors through the input of the metric. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From jvasseur@cisco.com Tue Feb 26 12:32:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B974D21F87A3 for ; Tue, 26 Feb 2013 12:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daZl8ZHeL6DF for ; Tue, 26 Feb 2013 12:32:26 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1E41D21F86B8 for ; Tue, 26 Feb 2013 12:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8772; q=dns/txt; s=iport; t=1361910738; x=1363120338; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Um8DWY/uVQQ1hMO7zdp4o7NFqkN6GtwBDQzincTieLA=; b=GPfQcRPkdvqLy/auqjYl87ayDvoq4kdTL30fyWBL23+9TGiGnXsfHgyE ZT1oClHMDfCRFZlsdRpYhKSQ8JyCwQGg8clehrfYuBdsmNDbVTfu+BxT7 W5BupLlQIL3VHpE7M5TSgppjGsYbaEPNRGctSw1oQBGNpXXdVxJJ4za9u 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK0aLVGtJXG+/2dsb2JhbABFwXV/FnOCHwEBAQMBAQEBNzQLEAIBCA4KChQQJwslAgQBDQUIDId5BgywAZAMBI1NBoEOAjEHgl9hA6cogwiBaQkXHg X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="181504938" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 26 Feb 2013 20:32:17 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1QKWHaJ002115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Feb 2013 20:32:17 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 14:32:17 -0600 From: "JP Vasseur (jvasseur)" To: Jiazi Yi , "Stan Ratliff (sratliff)" Thread-Topic: [manet] Why the WG Reactive Protocol to be Compatible with another? Thread-Index: AQHOFGBdVmWV3b6bFk6UuFRnR4ggiw== Date: Tue, 26 Feb 2013 20:32:16 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77232E414A@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100315E3@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10031A69@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10031A69@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.235] Content-Type: text/plain; charset="us-ascii" Content-ID: <15B94FA16973BE48A93F334756140CA2@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org List" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:32:27 -0000 I do agree with you Stan - I also miss the point of trying to get back at w= hat happened, why, ... as opposed to spending our energy making it right an= d more forward for the best of our community. Cheers. JP. On Feb 21, 2013, at 2:25 AM, Stan Ratliff (sratliff) wrote: >=20 > On Feb 20, 2013, at 5:03 PM, Jiazi Yi wrote: >=20 >> Hi,=20 >>=20 >> Please check inline (I'm just speaking on behalf of myself, not the LOAD= ng author team) : >>=20 >>=20 >> On Feb 20, 2013, at 9:52 PM, Stan Ratliff (sratliff) wrote: >>=20 >>> Jiazi,=20 >>>=20 >>> On Feb 20, 2013, at 12:22 PM, Jiazi Yi wrote: >>>=20 >>>> Hi AB, JP: >>>>=20 >>>> I also have doubts why the editor of DYMO declares that it will be com= patible with LOADng, and how it can be achieved.=20 >>>=20 >>> It probably won't be achieved - especially if you and the other LOADng = co-authors decide not to help us, taking the position of standing back and = lobbing emails like this one into the fray. If this is a desirable, then I = would say "suggest some alternatives, help us out". If not, then let us as = a working group declare it a dead issue, and move on.=20 >>=20 >> In the last 2~years, the LOADng co-authors have spent huge amount of eff= ort in reactive protocols. For me personally, it's the core of my research = project, and I invested most of my time in it. Hopefully it won't be regard= ed as "not willing to help".=20 >=20 > FWIW, here's how I look at it: The past history is what it is. The AD mad= e the decision he made. We are where we are. The operative question is whet= her or not any given working group participant is willing to help the WG mo= ve forward., *from where we are*, to the best reactive protocol we can spec= ify. Any and all assistance and ideas are welcome, and contributors will be= acknowledged.=20 >=20 >>=20 >>=20 >>>=20 >>>>=20 >>>> Although those two protocols share the general idea, the packet format= and message processing details are very different. As one who participated= in all LOADng interop tests and know dymo draft relatively well, I can say= that a lot of effort are needed to make DYMO and LOADng compatible, not to= mention the interop tests needed to verify the compatibility (at this poin= t, I have no idea if there is DYMO implementation, so I'm not even sure if = such test is possible).=20 >>>=20 >>> OK. Going on (yet another) "micro-cosmic trip through MANET reactive pr= otocol history", I'll note that AODV compatibility with LOADng was somethin= g that the co-chairs mandated from the combined author teams when we though= t that merging the two documents was something that could actually be accom= plished. The rationale there was to not exclude existing LOADng implementat= ions from being able to say they were compliant with the RFC - something th= at *no one* on the author teams (including yourself) complained about *at t= he time*.=20 >>=20 >> Since the Taipei IETF, the starting point agreed by the authors teams wa= s always LOADng, as indicated in Ulrich's mail to the chairs.=20 >> In that context, all the authors agree that companion documents can be d= eveloped, so that the dymo functions can be supported to be compatible.=20 >> Thanks for adding the note.=20 >> The issue of starting point didn't come out until several months before = Atlanta IETF. If I knew that the document would be based on DYMO, it would = be a totally different issue.=20 >=20 > We can quibble about the exact timing of when "the starting point" came o= ut - my memory is that the requirement was clearly stated to the parties in= volved in YVR. However, my point is that it did come out, has been out "for= a while", and no dissent was received. So any implication that this popped= up out of the blue is incorrect. >=20 > Stan >=20 >>=20 >>=20 >>>=20 >>> So to restate, the fundamentals of the issue have changed - the effort = to merge the documents was a total, miserable failure. At this juncture it = is fair to ask if LOADng compatibility is even something that is desirable.= The general trend of comments I'm reading on the list indicates that it is= not. Are there other opinions?=20 >>=20 >>=20 >> I agree that the fundamentals of the issue have changed, since the start= ing point and the design principle (slim core + companion document) were ch= anged.=20 >> As far as I can see, LOADng has no intention to be changed to "get close= r to DYMO". Having DYMO be compatible with LOADng would need great effort a= nd add extra complexity to the protocol - starting from scratch probably w= ould be easier to make a clear specification and be compatible with LOADng.= =20 >> I have spent days and nights in the interop tests of LOADng. Producing O= NE clear specification with limited options, and making it able to interope= rable among independent implementations are already hard enough. Having TWO= specifications, and one of them is a super set with all those additional o= ptions which are not specified clearly, would be a nightmare. Awful among o= f iterations and tests would be required.=20 >>=20 >> Therefore, personally, I would say LOADng compatibility is not desirable= .=20 >>=20 >> best >>=20 >> Jiazi >>=20 >>=20 >>>=20 >>> Stan=20 >>>=20 >>>=20 >>>>=20 >>>> btw,=20 >>>>=20 >>>>> the objective of the IETF is to produce qualitative protocols for the= best of the IETF community and industry, not to make X or Y happy >>>>=20 >>>>=20 >>>> I can't agree more.=20 >>>>=20 >>>> best >>>>=20 >>>> Jiazi >>>>=20 >>>> On Feb 20, 2013, at 4:26 PM, JP Vasseur (jvasseur) wrote: >>>>=20 >>>>> Hi AB, >>>>>=20 >>>>> This is critical topic and I cannot agree more with you; the objectiv= e is in my opinion to come up with the best protocol for the IETF. >>>>> Let's be clear: the objective of the IETF is to produce qualitative p= rotocols for the best of the IETF community and industry, not to make >>>>> X or Y happy. Every single good ideas borrowed from Load should in my= opinion be adopted by AODVv2, if there is a consensus. On the >>>>> other hand, trying to design AODVv2 with the constraint of making it = compatible with another protocol is a COMPLETE non sense. >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> JP. >>>>>=20 >>>>> On Feb 20, 2013, at 3:03 AM, Abdussalam Baryun wrote: >>>>>=20 >>>>>> Hi Folks, >>>>>>=20 >>>>>> I am not sure why we will make effort of AODVv2 compatible with >>>>>> LOADng, I am trying to find a good reason mentioned in the WG. I see= n >>>>>> the intention by some participants, but not sure was it intention to >>>>>> merge DYMO+LOADng without compatibility (with either DYMO or LOADng) >>>>>> or with percentage of compatibility. Do you think it is good way to >>>>>> make the reactive protocol and then try to make it compatible? Plea= se >>>>>> advise, >>>>>>=20 >>>>>> I will have to agree with the below proposal, that if the WG is >>>>>> agreeing to make compatible with LOADng, then why not go for 100% >>>>>> compatibility, just change the name title. >>>>>>=20 >>>>>> AB >>>>>>=20 >>>>>> Sub:Re: [manet] Reactive protocol decision process, for the record t= houghts >>>>>> On 2/16/13, Ulrich Herberg wrote: >>>>>>> Justin, >>>>>>>=20 >>>>>>> I very much agree with you, Justin. One point I would like to add i= s >>>>>>> that the WG will now spend a lot of time making the new AODVv2 >>>>>>> compatible with LOADng (which is claimed in the current DYMO draft)= ; >>>>>>> that is, in my opinion, a wasted effort since the LOADng draft is p= er >>>>>>> definition 100% compatible with LOADng (had that been the starting >>>>>>> point). >>>>>>> Ignoring a document that has multiple interoperable implementations= , >>>>>>> deployments, MIB document, as well a support from at least a dozen >>>>>>> MANET participants (not only LOADng authors) without giving rationa= l >>>>>>> was a disappointment for me. >>>>>>>=20 >>>>>>> Best regards >>>>>>> Ulrich >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Tue Feb 26 12:37:07 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA3221F8895 for ; Tue, 26 Feb 2013 12:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wsz1AU4R8Mej for ; Tue, 26 Feb 2013 12:37:06 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 48F0A21F87AF for ; Tue, 26 Feb 2013 12:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18321; q=dns/txt; s=iport; t=1361911022; x=1363120622; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iKf2iBVEPcI3LBpFPTbHOOd36v6gUlMDZqWgeX8FlBI=; b=K4kVj4ZU+y0LKFiOwTdYiaNKsrfCZm2OooKYjrO16ouQpvGgJIA/qoIe 86wBpDKX/RCb2m32uRxdBPvugHSTLx1ChdFe1ib8mtrE4uZ9JWo/IDmgZ s9vca1egR8hGpXzF4mXkYA18j/zcurD0qqk17yJOookCO88j2yHytf/xq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAO8bLVGtJXG9/2dsb2JhbABFgkOBNbVSAYgqfxZzgh8BAQEEAQEBUhkLEAIBCAcKBAEBCx0HJwsUCQgCBA4FCAGICgcFsACQD41DCgaBCgYLGwYBBAYBAgeCVmEDl16PSoMIgWkJFx4 X-IronPort-AV: E=Sophos;i="4.84,743,1355097600"; d="scan'208,217";a="178468892" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 26 Feb 2013 20:37:01 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1QKb1LG009499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Feb 2013 20:37:01 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 14:37:01 -0600 From: "Stan Ratliff (sratliff)" To: Thomas Clausen Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-26.txt Thread-Index: AQHOFBHUi+LASsPLf0qDcuOWqiGXKpiMDrKggABlhoCAAIpHAA== Date: Tue, 26 Feb 2013 20:37:00 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10035DD2@xmb-aln-x03.cisco.com> References: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> <512BEF17.70605@computer.org> <7117edef-b2ee-40d5-90fd-7002c639a6cb@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB06ACABBD@SUCNPTEXM02.com.ad.uk.ds.corp> <0CFB809D-6517-47A9-AF15-EECAF852204E@thomasclausen.org> In-Reply-To: <0CFB809D-6517-47A9-AF15-EECAF852204E@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.34.217] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C10035DD2xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:37:07 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C10035DD2xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thomas, According to the last email from Adrian, the Dymo draft would be renamed to= AODVv2 at the next opportunity. So no, I do not anticipate another WG poll= ing for adoption; rather, this is following the script. Regards, Stan On Feb 26, 2013, at 7:22 AM, Thomas Clausen wrote: Before a new document is adopted as a WG document, the WG will be polled fo= r adoption - yes? Thomas On Feb 26, 2013, at 1:20 PM, "Dowdell, John" > wrote: Abdussalam Yes that is the case. As Charlie mentioned it was forced on us by the IT ma= chinery. We will fix it as soon as we are able. Regards John From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: 26 February 2013 11:10 To: Charles E. Perkins Cc: manet@ietf.org; Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt Hi AODVv2 Editors, So do you mean if I review now the dymo-26 it is the same as aodvv2-00, please advise, AB On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins > wrote: Hello folks, draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts directories. The only problem is that it's got the wrong name, namely "draft-ietf-manet-dymo-26.txt" This is because it's now a week past the submission deadline for ...-00.txt initial drafts, and the submission tool would not allow me to upload it wit= h it's intended new name. This naming problem will be rectified at the earliest opportunity. Regards, Charlie P. On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of = the IETF. Title : Dynamic MANET On-demand (AODVv2) Routing Author(s) : Charles E. Perkins Stan Ratliff John Dowdell Filename : draft-ietf-manet-dymo-26.txt Pages : 60 Date : 2013-02-25 Abstract: The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dymo There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-dymo-26 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26 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 -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com= _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C10035DD2xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <463CD121BAAFA0478C491296B668FAE7@cisco.com> Content-Transfer-Encoding: quoted-printable Thomas, 

According to the last email from Adrian, the Dymo draft would be renam= ed to AODVv2 at the next opportunity. So no, I do not anticipate another WG= polling for adoption; rather, this is following the script. 

Regards,
Stan

On Feb 26, 2013, at 7:22 AM, Thomas Clausen wrote:

Before a new document is adopted as a WG document, the WG will be polled fo= r adoption - yes?

Thomas

On Feb 26, 2013, at 1:20 PM, "Dowdell, John" <John.Dowdell@Cassidian.com> wrote= :

Abdussalam

 =

Yes that is t= he case. As Charlie mentioned it was forced on us by the IT machinery. We w= ill fix it as soon as we are able.

 =

Regards

 =

John

 

 

 

 =

From:&nbs= p;manet-bounces@ietf.org [mailto:manet-bounces@ietf.o= rg] On Behalf Of Abdussalam= Baryun
Sent: 26 February = 2013 11:10
To: Charles E. Per= kins
Cc: m= anet@ietf.org; Stan Ratliff
Subject: Re: [mane= t] I-D Action: draft-ietf-manet-dymo-26.txt

 

Hi AODVv2 Editors,

 

So do you mean if I review now the dymo-26 it is the same as aodvv2-00,
please advise,

 

AB

On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins <charliep@computer.org> wrote:

Hello folks,

draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts directories.  The only problem is that it's got the wrong name, namely=
"draft-ietf-manet-dymo-26.txt"

This is because it's now a week past the submission deadline for ...-00.txt=
initial drafts, and the submission tool would not allow me to upload it wit= h
it's intended new name.

This naming problem will be rectified at the earliest opportunity.

Regards,
Charlie P.




On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote:

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

        Title           : Dyna= mic MANET On-demand (AODVv2) Routing
        Author(s)       : Charles E. Per= kins
                     = ;      Stan Ratliff
                     = ;      John Dowdell
        Filename        : draft-iet= f-manet-dymo-26.txt
        Pages           : 60         Date            := 2013-02-25

Abstract:
    The revised Ad Hoc On-demand Distance Vector (AODVv2) routing=
    protocol is intended for use by mobile routers in wireless, m= ultihop
    networks.  AODVv2 determines unicast routes among AODVv2= routers
    within the network in an on-demand fashion, offering on-deman= d
    convergence in dynamic topologies.


The IETF datatracker status page for this draft is:
https://d= atatracker.ietf.org/doc/draft-ietf-manet-dymo

There's also a htmlized version available at:
http://tools.i= etf.org/html/draft-ietf-manet-dymo-26

A diff from the previous version is available at:
http:/= /www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-dr= afts/

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

 
-- 
Regards,
Charlie P.


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

 

The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-mail or attached files, please con= tact the sender prior to any such disclosure. If you are not the intended r= ecipient, any disclosure, copying or distribution is prohibited. Please als= o contact the sender and inform them of the error and delete the e-mail, including any attached files from= your system. Cassidian Limited, Registered Office : Quadrant House, Celtic= Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.c= om __________________= _____________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/ma= net


--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C10035DD2xmbalnx03ciscoc_-- From thomas@thomasclausen.org Tue Feb 26 12:41:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6D321F8A5E for ; Tue, 26 Feb 2013 12:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM1P0+0kFfZ3 for ; Tue, 26 Feb 2013 12:41:11 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id A81F521F8A1D for ; Tue, 26 Feb 2013 12:41:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 994A71BD5903; Tue, 26 Feb 2013 12:41:11 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 38A511BD5ABE; Tue, 26 Feb 2013 12:41:10 -0800 (PST) References: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> <512BEF17.70605@computer.org> <7117edef-b2ee-40d5-90fd-7002c639a6cb@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB06ACABBD@SUCNPTEXM02.com.ad.uk.ds.corp> <0CFB809D-6517-47A9-AF15-EECAF852204E@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C10035DD2@xmb-aln-x03.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10035DD2@xmb-aln-x03.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-52F99BAA-9575-4098-9524-F70B7A956662 Content-Transfer-Encoding: 7bit Message-Id: <610DDB10-F5ED-4643-98D2-03C260A39C0E@thomasclausen.org> X-Mailer: iPad Mail (10B141) From: Thomas Heide Clausen Date: Tue, 26 Feb 2013 21:41:08 +0100 To: "Stan Ratliff (sratliff)" Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:41:12 -0000 --Apple-Mail-52F99BAA-9575-4098-9524-F70B7A956662 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In other words, WG consensus is disregarded concerning this document. Thank you for that clarification, this is duly noted. Thomas Sent from my iPad On 26 f=C3=A9vr. 2013, at 21:37, "Stan Ratliff (sratliff)" wrote: > Thomas,=20 >=20 > According to the last email from Adrian, the Dymo draft would be renamed t= o AODVv2 at the next opportunity. So no, I do not anticipate another WG poll= ing for adoption; rather, this is following the script.=20 >=20 > Regards, > Stan >=20 > On Feb 26, 2013, at 7:22 AM, Thomas Clausen wrote: >=20 >> Before a new document is adopted as a WG document, the WG will be polled f= or adoption - yes? >>=20 >> Thomas >>=20 >> On Feb 26, 2013, at 1:20 PM, "Dowdell, John" = wrote: >>=20 >>> Abdussalam >>> =20 >>> Yes that is the case. As Charlie mentioned it was forced on us by the IT= machinery. We will fix it as soon as we are able. >>> =20 >>> Regards >>> =20 >>> John >>> =20 >>> =20 >>> =20 >>> =20 >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Abdussalam Baryun >>> Sent: 26 February 2013 11:10 >>> To: Charles E. Perkins >>> Cc: manet@ietf.org; Stan Ratliff >>> Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt >>> =20 >>> Hi AODVv2 Editors, >>> =20 >>> So do you mean if I review now the dymo-26 it is the same as aodvv2-00, >>> please advise, >>> =20 >>> AB >>>=20 >>> On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins wrote: >>>=20 >>> Hello folks, >>>=20 >>> draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts= >>> directories. The only problem is that it's got the wrong name, namely >>> "draft-ietf-manet-dymo-26.txt" >>>=20 >>> This is because it's now a week past the submission deadline for ...-00.= txt >>> initial drafts, and the submission tool would not allow me to upload it w= ith >>> it's intended new name. >>>=20 >>> This naming problem will be rectified at the earliest opportunity. >>>=20 >>> Regards, >>> Charlie P. >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>> This draft is a work item of the Mobile Ad-hoc Networks Working Group o= f the IETF. >>>=20 >>> Title : Dynamic MANET On-demand (AODVv2) Routing >>> Author(s) : Charles E. Perkins >>> Stan Ratliff >>> John Dowdell >>> Filename : draft-ietf-manet-dymo-26.txt >>> Pages : 60 >>> Date : 2013-02-25 >>>=20 >>> Abstract: >>> The revised Ad Hoc On-demand Distance Vector (AODVv2) routing >>> protocol is intended for use by mobile routers in wireless, multihop= >>> networks. AODVv2 determines unicast routes among AODVv2 routers >>> within the network in an on-demand fashion, offering on-demand >>> convergence in dynamic topologies. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-manet-dymo >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-manet-dymo-26 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> =20 >>> --=20 >>> Regards, >>> Charlie P. >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> =20 >>> The information contained within this e-mail and any files attached to t= his e-mail is private and in addition may include commercially sensitive inf= ormation. The contents of this e-mail are for the intended recipient only an= d therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclosu= re. If you are not the intended recipient, any disclosure, copying or distri= bution is prohibited. Please also contact the sender and inform them of the e= rror and delete the e-mail, including any attached files from your system. C= assidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedke= rnew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com ______= _________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 --Apple-Mail-52F99BAA-9575-4098-9524-F70B7A956662 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In other words, WG consensus is disreg= arded concerning this document.

Thank you for that c= larification, this is duly noted.

Thomas
=
Sent from my iPad

On 26 f=C3=A9vr. 2013, at 21:37, "Stan R= atliff (sratliff)" <sratliff@cisco.= com> wrote:

= Thomas, 

According to the last email from Adrian, the Dymo draft would be rename= d to AODVv2 at the next opportunity. So no, I do not anticipate another WG p= olling for adoption; rather, this is following the script. 

Regards,
Stan

On Feb 26, 2013, at 7:22 AM, Thomas Clausen wrote:

Before a new document is adopted as a WG document, the WG will be polled for= adoption - yes?

Thomas

On Feb 26, 2013, at 1:20 PM, "Dowdell, John" <John.Dowdell@Cassidian.com> wrote:

Abdussalam

 <= /p>

Yes that is th= e case. As Charlie mentioned it was forced on us by the IT machinery. We wil= l fix it as soon as we are able.

 <= /p>

Regards=

 <= /p>

 

 

 <= /p>

From: <= /span>manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]=  On Behalf Of Abdussalam B= aryun
Sent: 26 February 2= 013 11:10
To: Charles E. Perk= ins
Cc: man= et@ietf.org; Stan Ratliff
Subject: Re: [manet= ] I-D Action: draft-ietf-manet-dymo-26.txt

 

Hi AODVv2 Editors,

 

So do you mean if I review now the dymo-26 it is the same as aodvv2-00,
please advise,

 

AB

On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins <charliep@computer.org> wrote:

Hello folks,

draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts
= directories.  The only problem is that it's got the wrong name, namely<= br> "draft-ietf-manet-dymo-26.txt"

This is because it's now a week past the submission deadline for ...-00.txt<= br> initial drafts, and the submission tool would not allow me to upload it with=
it's intended new name.

This naming problem will be rectified at the earliest opportunity.

Regards,
Charlie P.




On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directori= es.
  This draft is a work item of the Mobile Ad-hoc Networks Working Group= of the IETF.

        Title           : Dynam= ic MANET On-demand (AODVv2) Routing
        Author(s)       : Charles E. Perk= ins
                     =      Stan Ratliff
                     =      John Dowdell
        Filename        : draft-ietf= -manet-dymo-26.txt
        Pages           : 60         Date            : 2= 013-02-25

Abstract:
    The revised Ad Hoc On-demand Distance Vector (AODVv2) routing<= br>     protocol is intended for use by mobile routers in wireless, mu= ltihop
    networks.  AODVv2 determines unicast routes among AODVv2 r= outers
    within the network in an on-demand fashion, offering on-demand=
    convergence in dynamic topologies.


The IETF datatracker status page for this draft is:
https://datat= racker.ietf.org/doc/draft-ietf-manet-dymo

There's also a htmlized version available at:
http://tools.iet= f.org/html/draft-ietf-manet-dymo-26

A diff from the previous version is available at:
http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-draf= ts/

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

 
-- 
Regards,
Charlie P.


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

 

The information contained within this e-mail and any files attached to this e= -mail is private and in addition may include commercially sensitive informat= ion. The contents of this e-mail are for the intended recipient only and the= refore if you wish to disclose the information contained within this e-mail or attached files, please cont= act the sender prior to any such disclosure. If you are not the intended rec= ipient, any disclosure, copying or distribution is prohibited. Please also c= ontact the sender and inform them of the error and delete the e-mail, including any attached files from y= our system. Cassidian Limited, Registered Office : Quadrant House, Celtic Sp= rings, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com ___________________________= ____________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/mane= t


= --Apple-Mail-52F99BAA-9575-4098-9524-F70B7A956662-- From abdussalambaryun@gmail.com Tue Feb 26 12:48:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0303B21F8726 for ; Tue, 26 Feb 2013 12:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXITdU9TA9F3 for ; Tue, 26 Feb 2013 12:48:20 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF47E21F86FA for ; Tue, 26 Feb 2013 12:48:19 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id wz12so2596260pbc.31 for ; Tue, 26 Feb 2013 12:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=veACUuPa15+8TaLMrxzEmNKgjdm5pfuXHVJx8zfiyf8=; b=VGU3y+oFh6hRlwMoDO1BVNviD+vs5tIQiWQJe5MuPeiKbIDcwp0MjoFAvWu9RrA4y5 oUpHTm0S6bBw3C3m2cXq51S5CKA/YbpD2Rw0WyxriN2GrwpTBx8XiEpOOmyiGm58esQD nCHI2Xkh5PDbU4OXeUma88Aw6kuC6xU6rfg2e99QP2oyFxHrSX75VzIB/YVbAO2wZzFR dwD3mttEVFBPBkjE4Lzin89ilH0MyA3eoznQISH+mX14rAeKEMj4LWLyMR1sM5WAkdcA Y/fwXT2vy1Wg25v3wNUneUOzC9e/KY+U4v4WaMOY6OIri6sadei3Dq9Yv+Cdi+kjxIlm buFQ== MIME-Version: 1.0 X-Received: by 10.66.234.132 with SMTP id ue4mr3600014pac.163.1361911699736; Tue, 26 Feb 2013 12:48:19 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 12:48:19 -0800 (PST) In-Reply-To: <610DDB10-F5ED-4643-98D2-03C260A39C0E@thomasclausen.org> References: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> <512BEF17.70605@computer.org> <7117edef-b2ee-40d5-90fd-7002c639a6cb@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB06ACABBD@SUCNPTEXM02.com.ad.uk.ds.corp> <0CFB809D-6517-47A9-AF15-EECAF852204E@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C10035DD2@xmb-aln-x03.cisco.com> <610DDB10-F5ED-4643-98D2-03C260A39C0E@thomasclausen.org> Date: Tue, 26 Feb 2013 20:48:19 +0000 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=047d7b15a4a5140f8804d6a6c76d Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:48:23 -0000 --047d7b15a4a5140f8804d6a6c76d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, we can see it from another angle. I see that as a WG we need to get together and make a reactive protocol standard, but because there was *no consensus* on which to choose, we still need to become a WG (please don't forget that we tried to make consensus but there was no for any reactive protocol). However, there was a consensus on the choosing person to take it over, and also that we want to continue having such item on the charter. So, there was consensus of the WG for the work in progress charter item needed, and the person to choose that item, AB On Tue, Feb 26, 2013 at 8:41 PM, Thomas Heide Clausen < thomas@thomasclausen.org> wrote: > In other words, WG consensus is disregarded concerning this document. > > Thank you for that clarification, this is duly noted. > > Thomas > > Sent from my iPad > > On 26 f=E9vr. 2013, at 21:37, "Stan Ratliff (sratliff)" > wrote: > > Thomas, > > According to the last email from Adrian, the Dymo draft would be renamed > to AODVv2 at the next opportunity. So no, I do not anticipate another WG > polling for adoption; rather, this is following the script. > > Regards, > Stan > > On Feb 26, 2013, at 7:22 AM, Thomas Clausen wrote: > > Before a new document is adopted as a WG document, the WG will be polled > for adoption - yes? > > Thomas > > On Feb 26, 2013, at 1:20 PM, "Dowdell, John" > wrote: > > Abdussalam > > > Yes that is the case. As Charlie mentioned it was forced on us by the IT > machinery. We will fix it as soon as we are able. > > > Regards > > > John > > > > > > > > > *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On > Behalf Of *Abdussalam Baryun > *Sent:* 26 February 2013 11:10 > *To:* Charles E. Perkins > *Cc:* manet@ietf.org; Stan Ratliff > *Subject:* Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt > > > Hi AODVv2 Editors, > > > So do you mean if I review now the dymo-26 it is the same as aodvv2-00, > please advise, > > > > AB > On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins < > charliep@computer.org> wrote: > > Hello folks, > > draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts > directories. The only problem is that it's got the wrong name, namely > "draft-ietf-manet-dymo-26.txt" > > This is because it's now a week past the submission deadline for ...-00.t= xt > initial drafts, and the submission tool would not allow me to upload it > with > it's intended new name. > > This naming problem will be rectified at the earliest opportunity. > > Regards, > Charlie P. > > > > > On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group o= f > the IETF. > > Title : Dynamic MANET On-demand (AODVv2) Routing > Author(s) : Charles E. Perkins > Stan Ratliff > John Dowdell > Filename : draft-ietf-manet-dymo-26.txt > Pages : 60 > Date : 2013-02-25 > > Abstract: > The revised Ad Hoc On-demand Distance Vector (AODVv2) routing > protocol is intended for use by mobile routers in wireless, multihop > networks. AODVv2 determines unicast routes among AODVv2 routers > within the network in an on-demand fashion, offering on-demand > convergence in dynamic topologies. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dymo > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-dymo-26 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26 > > > 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 > > -- > Regards, > Charlie P. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > The information contained within this e-mail and any files attached to > this e-mail is private and in addition may include commercially sensitive > information. The contents of this e-mail are for the intended recipient > only and therefore if you wish to disclose the information contained with= in > this e-mail or attached files, please contact the sender prior to any suc= h > disclosure. If you are not the intended recipient, any disclosure, copyin= g > or distribution is prohibited. Please also contact the sender and inform > them of the error and delete the e-mail, including any attached files fro= m > your system. Cassidian Limited, Registered Office : Quadrant House, Celti= c > Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 > http://www.cassidian.com _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > --047d7b15a4a5140f8804d6a6c76d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
=A0
we can see it from another angle. I= see that as a WG we need to get together and make a reactive protocol stan= dard, but because there was *no consensus* on which to choose, we still nee= d to become a WG (please don't forget that we tried to make consensus b= ut there was no for any reactive protocol). However, there was a consensus = on the choosing person to take it over, and also that we want to continue h= aving such item on the charter.
=A0
So, there was consensus of the WG for the work in progre= ss charter item needed, and the person to choose that item,
=A0
AB

On Tue, Feb 26, 2013 at= 8:41 PM, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:
In other words, WG consensus is dis= regarded concerning this document.

Thank you for that clarification, this is duly noted.

Thomas

Sent from my iPad

On 26 f=E9vr. 2013, at 21:37, "Stan Ratliff (= sratliff)" <sratliff@cisco.com> wrote:

Thomas,=A0

According to the last email from Adrian, the Dymo draft would be renam= ed to AODVv2 at the next opportunity. So no, I do not anticipate another WG= polling for adoption; rather, this is following the script.=A0

Regards,
Stan

On Feb 26, 2013, at 7:22 AM, Thomas Clausen wrote:

Before a new document is adopted as a WG document, the WG will be polled fo= r adoption - yes?

Thomas

On Feb 26, 2013, at 1:20 PM, "Dowdell, John" <John.Dowdell@Cassidian= .com> wrote:

Abdussalam

=A0

Yes that is the cas= e. As Charlie mentioned it was forced on us by the IT machinery. We will fi= x it as soon as we are able.

=A0

Regards

=A0

John=

=A0<= /span>

=A0

=A0

=A0

From:=A0mane= t-bounces@ietf.org=A0[mailto:manet-bounces@ietf.org]<= span>=A0On Behalf Of=A0Abdussalam Baryun
Sent:=A026 February 2013 11:10
To:=A0Charles E. Perkins
Cc:=A0manet@ietf.org; Sta= n Ratliff
Subject:=A0Re: [manet] I-D Action: draft-ietf-manet-dym= o-26.txt

=A0

Hi AODVv2 Editors,

=A0

So do you mean if I review now the dymo-26 it is the same as aodvv2-00,
please advise,

=A0

AB

On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins <charliep@computer.org> wrote:

Hello folks,

draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts directories. =A0The only problem is that it's got the wrong name, namel= y
"draft-ietf-manet-dymo-26.txt"

This is because it's now a week past the submission deadline for ...-00= .txt
initial drafts, and the submission tool would not allow me to upload it wit= h
it's intended new name.

This naming problem will be rectified at the earliest opportunity.

Regards,
Charlie P.




On 2/25/2013 3:01 PM,=A0in= ternet-drafts@ietf.org=A0wrote:

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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Dynamic MANET On-demand (AODVv2= ) Routing
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Charles E. Perkins
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stan Ratliff
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0John Dowdell
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-manet-dymo-26.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 60
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-25

Abstract:
=A0 =A0 The revised Ad Hoc On-demand Distance Vector (AODVv2) routing
=A0 =A0 protocol is intended for use by mobile routers in wireless, multiho= p
=A0 =A0 networks. =A0AODVv2 determines unicast routes among AODVv2 routers<= br> =A0 =A0 within the network in an on-demand fashion, offering on-demand
=A0 =A0 convergence in dynamic topologies.


The IETF datatracker status page for this draft is:
https://datatrac= ker.ietf.org/doc/draft-ietf-manet-dymo

There's also a htmlized version available at:
http://tools.ietf.o= rg/html/draft-ietf-manet-dymo-26

A diff from the previous version is available at:
http://www.= ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26


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/mailma= n/listinfo/manet

=A0
--=A0
Regards,
Charlie P.


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

=A0

The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-mail or attached files, please con= tact the sender prior to any such disclosure. If you are not the intended r= ecipient, any disclosure, copying or distribution is prohibited. Please als= o contact the sender and inform them of the error and delete the e-mail, including any attached files from= your system. Cassidian Limited, Registered Office : Quadrant House, Celtic= Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036=A0http://www.cassidian.com=A0= _______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailma= n/listinfo/manet



--047d7b15a4a5140f8804d6a6c76d-- From thomas@thomasclausen.org Tue Feb 26 12:57:36 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836EA21F886E for ; Tue, 26 Feb 2013 12:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lusvGrn897UY for ; Tue, 26 Feb 2013 12:57:32 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id E84BE21F882A for ; Tue, 26 Feb 2013 12:57:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DD5AF26180F; Tue, 26 Feb 2013 12:57:31 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 64E85261810; Tue, 26 Feb 2013 12:57:30 -0800 (PST) References: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> <512BEF17.70605@computer.org> <7117edef-b2ee-40d5-90fd-7002c639a6cb@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB06ACABBD@SUCNPTEXM02.com.ad.uk.ds.corp> <0CFB809D-6517-47A9-AF15-EECAF852204E@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C10035DD2@xmb-aln-x03.cisco.com> <610DDB10-F5ED-4643-98D2-03C260A39C0E@thomasclausen.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-318C356A-A0EC-41E2-A95A-334F46D24FE0 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10B141) From: Thomas Heide Clausen Date: Tue, 26 Feb 2013 21:57:28 +0100 To: Abdussalam Baryun Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:57:36 -0000 --Apple-Mail-318C356A-A0EC-41E2-A95A-334F46D24FE0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable What you advance is not entirely accurate. There was an edict by an AD - but that edict was *not* supported by any (rat= ional or otherwise) arguments or justification or explanation. That makes pr= ogress very difficult, especially since that edict went against an objective= majority. Thus, if the WG is to assume responsibility for that document, the very leas= t that is required is, that the WG be given the opportunity to express conse= nsus for or against that document. If the WG is not given that opportunity, then I do not believe that the docu= ment can proceed as a WG document - nor do I believe that it should proceed a= s such.=20 If the AD wishes to proceed with a document outside of a WG consensus, then (= s)he can pursue it as an AD sponsored document, seeking IETF consensus inste= ad. Thomas Sent from my iPad On 26 f=C3=A9vr. 2013, at 21:48, Abdussalam Baryun wrote: > Hi Thomas, > =20 > we can see it from another angle. I see that as a WG we need to get togeth= er and make a reactive protocol standard, but because there was *no consensu= s* on which to choose, we still need to become a WG (please don't forget tha= t we tried to make consensus but there was no for any reactive protocol). Ho= wever, there was a consensus on the choosing person to take it over, and als= o that we want to continue having such item on the charter. > =20 > So, there was consensus of the WG for the work in progress charter item ne= eded, and the person to choose that item, > =20 > AB >=20 > On Tue, Feb 26, 2013 at 8:41 PM, Thomas Heide Clausen wrote: >> In other words, WG consensus is disregarded concerning this document. >>=20 >> Thank you for that clarification, this is duly noted. >>=20 >> Thomas >>=20 >> Sent from my iPad >>=20 >> On 26 f=C3=A9vr. 2013, at 21:37, "Stan Ratliff (sratliff)" wrote: >>=20 >>> Thomas,=20 >>>=20 >>> According to the last email from Adrian, the Dymo draft would be renamed= to AODVv2 at the next opportunity. So no, I do not anticipate another WG po= lling for adoption; rather, this is following the script.=20 >>>=20 >>> Regards, >>> Stan >>>=20 >>> On Feb 26, 2013, at 7:22 AM, Thomas Clausen wrote: >>>=20 >>>> Before a new document is adopted as a WG document, the WG will be polle= d for adoption - yes? >>>>=20 >>>> Thomas >>>>=20 >>>> On Feb 26, 2013, at 1:20 PM, "Dowdell, John" wrote: >>>>=20 >>>>> Abdussalam >>>>> =20 >>>>> Yes that is the case. As Charlie mentioned it was forced on us by the I= T machinery. We will fix it as soon as we are able. >>>>> =20 >>>>> Regards >>>>> =20 >>>>> John >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf= Of Abdussalam Baryun >>>>> Sent: 26 February 2013 11:10 >>>>> To: Charles E. Perkins >>>>> Cc: manet@ietf.org; Stan Ratliff >>>>> Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt >>>>> =20 >>>>> Hi AODVv2 Editors, >>>>> =20 >>>>> So do you mean if I review now the dymo-26 it is the same as aodvv2-00= , >>>>> please advise, >>>>> =20 >>>>> AB >>>>>=20 >>>>> On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins wrote: >>>>>=20 >>>>> Hello folks, >>>>>=20 >>>>> draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Draf= ts >>>>> directories. The only problem is that it's got the wrong name, namely= >>>>> "draft-ietf-manet-dymo-26.txt" >>>>>=20 >>>>> This is because it's now a week past the submission deadline for ...-0= 0.txt >>>>> initial drafts, and the submission tool would not allow me to upload i= t with >>>>> it's intended new name. >>>>>=20 >>>>> This naming problem will be rectified at the earliest opportunity. >>>>>=20 >>>>> Regards, >>>>> Charlie P. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote: >>>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>>> This draft is a work item of the Mobile Ad-hoc Networks Working Grou= p of the IETF. >>>>>=20 >>>>> Title : Dynamic MANET On-demand (AODVv2) Routing >>>>> Author(s) : Charles E. Perkins >>>>> Stan Ratliff >>>>> John Dowdell >>>>> Filename : draft-ietf-manet-dymo-26.txt >>>>> Pages : 60 >>>>> Date : 2013-02-25 >>>>>=20 >>>>> Abstract: >>>>> The revised Ad Hoc On-demand Distance Vector (AODVv2) routing >>>>> protocol is intended for use by mobile routers in wireless, multih= op >>>>> networks. AODVv2 determines unicast routes among AODVv2 routers >>>>> within the network in an on-demand fashion, offering on-demand >>>>> convergence in dynamic topologies. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-dymo >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-manet-dymo-26 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26 >>>>>=20 >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> =20 >>>>> --=20 >>>>> Regards, >>>>> Charlie P. >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> =20 >>>>> The information contained within this e-mail and any files attached to= this e-mail is private and in addition may include commercially sensitive i= nformation. The contents of this e-mail are for the intended recipient only a= nd therefore if you wish to disclose the information contained within this e= -mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or distr= ibution is prohibited. Please also contact the sender and inform them of the= error and delete the e-mail, including any attached files from your system.= Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coed= kernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com ____= ___________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-318C356A-A0EC-41E2-A95A-334F46D24FE0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
What you advance is not entirely accur= ate.

There was an edict by an AD - but that edict w= as *not* supported by any (rational or otherwise) arguments or justification= or explanation. That makes progress very difficult, especially since that e= dict went against an objective majority.

Thus, if t= he WG is to assume responsibility for that document, the very least that is r= equired is, that the WG be given the opportunity to express consensus for or= against that document.

If the WG is not given that= opportunity, then I do not believe that the document can proceed as a WG do= cument - nor do I believe that it should proceed as such. 
If the AD wishes to proceed with a document outside of a WG con= sensus, then (s)he can pursue it as an AD sponsored document, seeking IETF c= onsensus instead.

Thomas

S= ent from my iPad

On 26 f=C3=A9vr. 2013, at 21:48, Abdussalam B= aryun <abdussalambaryun@gma= il.com> wrote:

Hi Th= omas,
 
we can see it from another angle. I see tha= t as a WG we need to get together and make a reactive protocol standard, but= because there was *no consensus* on which to choose, we still need to becom= e a WG (please don't forget that we tried to make consensus but there was no= for any reactive protocol). However, there was a consensus on the choosing p= erson to take it over, and also that we want to continue having such item on= the charter.
 
So, there was consensus of the WG for the work in prog= ress charter item needed, and the person to choose that item,
&nbs= p;
AB

On Tue, Feb 26, 2013= at 8:41 PM, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:
In other words, WG consensus is disrega= rded concerning this document.

Thank you for that clarification, this is duly noted.

Thomas

Sent from my iPad

On 26 f=C3=A9vr. 2013, at 21:37, "Stan Ratliff (sratl= iff)" <sratliff@c= isco.com> wrote:

Thomas, 

According to the last email from Adrian, the Dymo draft would be rename= d to AODVv2 at the next opportunity. So no, I do not anticipate another WG p= olling for adoption; rather, this is following the script. 

Regards,
Stan

On Feb 26, 2013, at 7:22 AM, Thomas Clausen wrote:

Before a new document is adopted as a WG document, the WG will be polled for= adoption - yes?

Thomas

On Feb 26, 2013, at 1:20 PM, "Dowdell, John" <John.Dowdell@Cassidian.com>= wrote:

Abdussalam

 

Yes that is the case= . As Charlie mentioned it was forced on us by the IT machinery. We will fix i= t as soon as we are able.

 

Regards
=

 

John<= /span>

 = ;

 

 

 

From: manet= -bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 11:10
To: Charles E. Perkins
Cc: manet@ietf.org; St= an Ratliff
Subject: Re: [manet] I-D Action: draft-ietf-manet-d= ymo-26.txt

 

Hi AODVv2 Editors,

 

So do you mean if I review now the dymo-26 it is the same as aodvv2-00,
please advise,

 

AB

On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins <charliep@computer.org> wrote:

Hello folks,

draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts
= directories.  The only problem is that it's got the wrong name, namely<= br> "draft-ietf-manet-dymo-26.txt"

This is because it's now a week past the submission deadline for ...-00.txt<= br> initial drafts, and the submission tool would not allow me to upload it with=
it's intended new name.

This naming problem will be rectified at the earliest opportunity.

Regards,
Charlie P.




On 2/25/2013 3:01 PM, i= nternet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directori= es.
  This draft is a work item of the Mobile Ad-hoc Networks Working Group= of the IETF.

        Title           : Dynam= ic MANET On-demand (AODVv2) Routing
        Author(s)       : Charles E. Perk= ins
                     =      Stan Ratliff
                     =      John Dowdell
        Filename        : draft-ietf= -manet-dymo-26.txt
        Pages           : 60         Date            : 2= 013-02-25

Abstract:
    The revised Ad Hoc On-demand Distance Vector (AODVv2) routing<= br>     protocol is intended for use by mobile routers in wireless, mu= ltihop
    networks.  AODVv2 determines unicast routes among AODVv2 r= outers
    within the network in an on-demand fashion, offering on-demand=
    convergence in dynamic topologies.


The IETF datatracker status page for this draft is:
https://datatracke= r.ietf.org/doc/draft-ietf-manet-dymo

There's also a htmlized version available at:
http://tools.ietf.org= /html/draft-ietf-manet-dymo-26

A diff from the previous version is available at:
http://www.ie= tf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26


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

 
-- 
Regards,
Charlie P.


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

 

The information contained within this e-mail and any files attached to this e= -mail is private and in addition may include commercially sensitive informat= ion. The contents of this e-mail are for the intended recipient only and the= refore if you wish to disclose the information contained within this e-mail or attached files, please cont= act the sender prior to any such disclosure. If you are not the intended rec= ipient, any disclosure, copying or distribution is prohibited. Please also c= ontact the sender and inform them of the error and delete the e-mail, including any attached files from y= our system. Cassidian Limited, Registered Office : Quadrant House, Celtic Sp= rings, Coedkernew, Newport, NP10 8FZ Company No: 04191036 = http://www.cassidian.com = _______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/= listinfo/manet



____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-318C356A-A0EC-41E2-A95A-334F46D24FE0-- From fred@cisco.com Tue Feb 26 13:00:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C518D21F892F for ; Tue, 26 Feb 2013 13:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.421 X-Spam-Level: X-Spam-Status: No, score=-110.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llDxleNN1sWx for ; Tue, 26 Feb 2013 13:00:21 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1E44121F85C3 for ; Tue, 26 Feb 2013 13:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=775; q=dns/txt; s=iport; t=1361912421; x=1363122021; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8gCImht2PnYInM8HJk3hxSxdzgLJ8/ZpGZbrdDn8jrg=; b=VyxpMjQBDrgbS8/W5J+9Rcx0Ic7JMv6nfdakLSQ02Aquugkckhre1szY 6x0v0ITckinP3y4MMewkS0OP9eEWvKZArMbdtN1cnTg/BLoal4yjGv5GT tiqS4i+/kc/4268jD3OD8xMtnliwq+ehc783dQVbctBLfopSmbcCVvSRV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcFAGohLVGtJXHB/2dsb2JhbABFhgi7bYEAFnOCHwEBAQMBOj8FCwIBCA4UFBAyJQIEDgUIh3kDCQawBoYrDYlYjDyCJQIxB4JfYQOnKIMIgic X-IronPort-AV: E=Sophos;i="4.84,743,1355097600"; d="scan'208";a="178476205" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 26 Feb 2013 21:00:20 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1QL0KZc016860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Feb 2013 21:00:20 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 15:00:19 -0600 From: "Fred Baker (fred)" To: Henning Rogge Thread-Topic: [manet] Why the WG Reactive Protocol to be Compatible with another? Thread-Index: AQHOD4Jym9LGx4mve0CI9nrZumggqpiNDiAA Date: Tue, 26 Feb 2013 21:00:18 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7AE356@xmb-rcd-x09.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 21:00:23 -0000 On Feb 20, 2013, at 7:53 AM, Henning Rogge wrote: > This would also give people a way to describe which "optional" > features a software implementation supports. >=20 > "We implemented the core plus the RFC xyz and abc." As I recall, that was the wonder of the OSI protocols. They did it with opt= ions within the documents, but you could say that you did TP-4 with options= this and that, and you could describe SDLC NRM, LAP, LAPB, LAPF, LAPM, and= IEEE 802.2 as all implementing the same protocol with different options. The only real problem was that none of the implementations had the same opt= ion set as any of the others, which meant that none of them could actually = interoperate. Is interoperation a requirement?= From hrogge@googlemail.com Tue Feb 26 13:05:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E96E21F8746 for ; Tue, 26 Feb 2013 13:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUBafw1NwsSU for ; Tue, 26 Feb 2013 13:05:29 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE0321F873C for ; Tue, 26 Feb 2013 13:05:29 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id n1so3381868lba.23 for ; Tue, 26 Feb 2013 13:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=2tgy+gzguJ8tw6S6P8b/tkoDcFXbU1hE9nRUCg+gmSA=; b=PTMBns4bwFsD7vCgyOkRSw9NYLO9yT52JP4a15lAlpBKBE1BfcHYMViH/uLqKAvxZm haVvSNGWmeOfYfVB2QClteJl7ImXA0zqtzB5/8D6HT/+m7Lzssj256ycz2+D3/nZoCbD lBOkuteIQdPhvNb9sxgAaant31sOgOZcBwUQVJwxqAFXlKWWwOJWNb6fiRb9YgmnOd2s yA8wc3ZXB6+EdYEiv6JAgVYBAUq4fVwrucXtEYm6zEya53ReMRMQZMHWwuMHFn4qL2+V Nr+jmO45A4yBI1uxKjI4J/yYGZHIYrc8PxMOe3PjYM8gZ5TitlB+idUS6zS8xCzixfY6 fXBQ== X-Received: by 10.112.51.44 with SMTP id h12mr1110469lbo.111.1361912728209; Tue, 26 Feb 2013 13:05:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.165 with HTTP; Tue, 26 Feb 2013 13:05:08 -0800 (PST) In-Reply-To: <8C48B86A895913448548E6D15DA7553B7AE356@xmb-rcd-x09.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> <8C48B86A895913448548E6D15DA7553B7AE356@xmb-rcd-x09.cisco.com> From: Henning Rogge Date: Tue, 26 Feb 2013 22:05:08 +0100 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 21:05:30 -0000 On Tue, Feb 26, 2013 at 10:00 PM, Fred Baker (fred) wrote: > > On Feb 20, 2013, at 7:53 AM, Henning Rogge wrote: > >> This would also give people a way to describe which "optional" >> features a software implementation supports. >> >> "We implemented the core plus the RFC xyz and abc." > > As I recall, that was the wonder of the OSI protocols. They did it with o= ptions within the documents, but you could say that you did TP-4 with optio= ns this and that, and you could describe SDLC NRM, LAP, LAPB, LAPF, LAPM, a= nd IEEE 802.2 as all implementing the same protocol with different options. > > The only real problem was that none of the implementations had the same o= ption set as any of the others, which meant that none of them could actuall= y interoperate. > > Is interoperation a requirement? Yes, it is... but as long as we have a useful core that everyone has to implement according to specs it should be okay. What we must not allow is that the core becomes useless. Options and extensions are fine as long as everyone one has a common feature set that is still useful. Henning Rogge --=20 We began as wanderers, and we are wanderers still. We have lingured long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From thomas@thomasclausen.org Tue Feb 26 13:14:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75A521F889C for ; Tue, 26 Feb 2013 13:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CvyppFvRaiQ for ; Tue, 26 Feb 2013 13:14:56 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9D421F87CC for ; Tue, 26 Feb 2013 13:14:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D47B3362101; Tue, 26 Feb 2013 13:14:50 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 77729362119; Tue, 26 Feb 2013 13:14:50 -0800 (PST) References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> <8C48B86A895913448548E6D15DA7553B7AE356@xmb-rcd-x09.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8C48B86A895913448548E6D15DA7553B7AE356@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8A916D4E-740B-4132-8318-087680525A8A@thomasclausen.org> X-Mailer: iPad Mail (10B141) From: Thomas Heide Clausen Date: Tue, 26 Feb 2013 22:14:48 +0100 To: "Fred Baker (fred)" Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 21:14:56 -0000 Fred, [working my way through your recent batch of OSPF and IS-IS doc's...comments= to follow, I am intrigued but will bug Mark on that before bugging you] On 26 f=C3=A9vr. 2013, at 22:00, "Fred Baker (fred)" wrote:= > On Feb 20, 2013, at 7:53 AM, Henning Rogge wrote: >=20 >> This would also give people a way to describe which "optional" >> features a software implementation supports. >>=20 >> "We implemented the core plus the RFC xyz and abc." >=20 > As I recall, that was the wonder of the OSI protocols. They did it with op= tions within the documents, but you could say that you did TP-4 with options= this and that, and you could describe SDLC NRM, LAP, LAPB, LAPF, LAPM, and I= EEE 802.2 as all implementing the same protocol with different options. >=20 > The only real problem was that none of the implementations had the same op= tion set as any of the others, which meant that none of them could actually i= nteroperate. >=20 > Is interoperation a requirement? Not really sure what to answer here. Speaking as somebody who writes the odd line of code in a protocol implement= ation, I am no fan of options: each option tends to lead to code branches, a= nd each code branch to a doubling of the size of the test suite. In std. track documents, this, especially, if said option set is there witho= ut operational/experimental justification. There're several deployments of LOADng out there. That protocol was designed= to be exactly that which was operationally justified (and nothing beyond th= at), minimizing options. It's unfortunate if the IETF/IESG isn't considerin= g "running code" as part of its credo any more. Best, Thomas > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From yi.jiazi@gmail.com Tue Feb 26 13:51:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729AE21F8865 for ; Tue, 26 Feb 2013 13:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.302 X-Spam-Level: * X-Spam-Status: No, score=1.302 tagged_above=-999 required=5 tests=[AWL=-1.583, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSTYyfehjKx4 for ; Tue, 26 Feb 2013 13:51:46 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 833EC21F8848 for ; Tue, 26 Feb 2013 13:51:46 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id 12so4749797wgh.3 for ; Tue, 26 Feb 2013 13:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=B/x6SHdIWNHmFgzgvKZdI21fqrRN8RiY4KhmVw746Go=; b=FEkaIpf1lzydPw2tuJaPmsMa3hTGMSvCA922n5gb3D5J/p3GlAtxMB8MxfFbklEuS3 LXNSED7KF0cZfqtWEH/F/afZtr0SWGovXBXycUiiTajYXiGxcWgABfiL2b1pGDMHCwaN SlX2Qoe43aFsPrhlb7fznlwaXNNWF+Yv/mNbpL5Xqp8KOvozY+ei5Uymz1JpQa3muH4S xwFikmtF0R+MZvu/GCU2BCQKF1x//G4G3vCJYdzRCBz+2ygjrc1grMZ8HCBtubJLiOUG iMALPkURfZdq9Yu+OiQl70S/X+6LWmz+ztr7RLeINCFJhbVTO07wp/uv+CzyRbwQwE7n 2+HA== X-Received: by 10.194.9.166 with SMTP id a6mr14287309wjb.2.1361915505537; Tue, 26 Feb 2013 13:51:45 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id fv2sm4805816wib.6.2013.02.26.13.51.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 13:51:44 -0800 (PST) Sender: Jiazi YI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jiazi Yi In-Reply-To: <8C48B86A895913448548E6D15DA7553B7AE356@xmb-rcd-x09.cisco.com> Date: Tue, 26 Feb 2013 22:51:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3CC9F5A3-8F4F-4F9C-A36A-1ECF2761E94D@jiaziyi.com> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> <8C48B86A895913448548E6D15DA7553B7AE356@xmb-rcd-x09.cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1499) Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 21:51:47 -0000 Hi,=20 My understanding is that , the core just define the basic functions that = are required in all general scenarios.=20 The role of option Z is: If you want to improve performance X in = scenario Y, then do Z.=20 Therefore, for a document, it is important to define such "core" that = has been proven to be working, with operational experience. The options = that only for specified scenarios shouldn't be taken into the core, = which only increase the overall complexity.=20 By separating the core document and optional documents, the core = document is imperatively implemented. By doing so, the engineers would = know the interoperability can be guaranteed as long as the core is = there, even with other implementations with core + options.=20 If we made a large document with various options by using SHOULD, MAY, = the dangerous part is: o the document would be much more complex, hard to understand, = and with much more redundancy;=20 o different implementation wouldn't be in the same option set, = unless they specify another subset of the protocol by defining "let's do = section x.y, paragraph z, the second SHOULD" etc. This is exactly what = you described.=20 best Jiazi On Feb 26, 2013, at 10:00 PM, "Fred Baker (fred)" = wrote: >=20 > On Feb 20, 2013, at 7:53 AM, Henning Rogge = wrote: >=20 >> This would also give people a way to describe which "optional" >> features a software implementation supports. >>=20 >> "We implemented the core plus the RFC xyz and abc." >=20 > As I recall, that was the wonder of the OSI protocols. They did it = with options within the documents, but you could say that you did TP-4 = with options this and that, and you could describe SDLC NRM, LAP, LAPB, = LAPF, LAPM, and IEEE 802.2 as all implementing the same protocol with = different options. >=20 > The only real problem was that none of the implementations had the = same option set as any of the others, which meant that none of them = could actually interoperate. >=20 > Is interoperation a requirement? > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Tue Feb 26 15:53:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F2B21F853A for ; Tue, 26 Feb 2013 15:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcULGakoZVHH for ; Tue, 26 Feb 2013 15:53:27 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id ADB2D21F852A for ; Tue, 26 Feb 2013 15:53:24 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id m18so2528740vcm.36 for ; Tue, 26 Feb 2013 15:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cT6Cejd5cHXd0slgTrv7PIJ3C5tgzAzyXp3epuwdp+Q=; b=TbGgoOhmFioLi4nsjx2t2Ax/FSxiBEgtyGueE/uPfoLOtDoklspCELGOhrQTUlWHj+ d2GeFAl0TNDsWBx0tOWqDaxLdXFyBimfQOk5ZcE3PLRR6hpenFgJKaBaMobCrdqBLX0d 8DGCHT3xfkD2EEtJAbliUHpu0f1DAIY+0kKD4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=cT6Cejd5cHXd0slgTrv7PIJ3C5tgzAzyXp3epuwdp+Q=; b=REhX5u3+GLrNwL7IdASHLCaeCR9uEDj0ieoLkpbkydEscnEFIENVtH52G+fzB6AHqa XVP6nf7NN6FAMNnLZbPVzt3oIYDAbz6RBFY/017l5Hqwe162izzjkhX3w5t9YM9o5tSY kJSNqACuOOcAPUy5k/Ovsjntpwtf5B9DCrdxKedrc7EwS2Mf7ZcYW6XPbcp4pUluGoWY EwrkSulQz/cwXfCQU4pKcrxZyn7y5QW1onUPgvimgr0TTNWLbv4BVgeqOiYkMHAd6wrf 79VGE1JxNbj/EAleQsVgF3RUs9QQoLikIyj8E/6SJD9PlSdq0bUJA2OZ4QEB8d36UnQp ibYw== MIME-Version: 1.0 X-Received: by 10.59.4.101 with SMTP id cd5mr81399ved.14.1361922804096; Tue, 26 Feb 2013 15:53:24 -0800 (PST) Received: by 10.220.235.194 with HTTP; Tue, 26 Feb 2013 15:53:23 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <92A0E0AF-F962-4BC6-A1DA-27D7C26945C1@jiaziyi.com> Date: Tue, 26 Feb 2013 15:53:23 -0800 Message-ID: From: Ulrich Herberg To: Jiazi Yi Content-Type: multipart/alternative; boundary=089e01160c4ef3692a04d6a95c59 X-Gm-Message-State: ALoCoQmr5CA5W3rTKpgxLoCMv36XoBuwZL33Q5Lg8XsYETKVGI83UaKPaLo9T6s2R/7JRGI/xhZo Cc: "Dearlove, Christopher \(UK\)" , " List" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 23:53:30 -0000 --089e01160c4ef3692a04d6a95c59 Content-Type: text/plain; charset=ISO-8859-1 Jiazi, On Tue, Feb 26, 2013 at 12:04 PM, Jiazi Yi wrote: > Hi, > > On the threat related to sequence number, my opinion is: > > 1. The "sequence number attack" in revision -00 is clearly wrong (for > duplicate detection), and not relevant to NHDP. So it has to be removed. > Yes. > > 2. The packet sequence number is not normative part of NHDP, however, it > may affects link quality updates. Therefore, I would agree with Teco, that > we can have a brief sentence to describe this threat, for example, in > identity spoofing section. > Alright, even though I still think it's only in a non-normative part, and a rare case (as described by Chris), it may not hurt adding a few sentences to the draft. > > On the appendix C, it is a little strange that a message sequence number > is included. For me, it's unnecessary. > True, can be removed IMO. Ulrich > > best > > Jiazi > > On Feb 26, 2013, at 8:00 PM, Teco Boot wrote: > > > Due to some mail bombs, I couldn't find time to check the documents. I'm > not the only one. Today, the mail server I'm using was overloaded. It is > not the smallest mail system on earth, so to say. Please send real > contributions only. > > > > I have nothing against a description of a NHDP security threat on packet > sequence number attack. Could be a single sentence, such as: "If a NHDP > link quality measurement is based on MANET control packet sequence numbers, > as described in RFC 6130 section 14.4, such a mechanism can be influenced > by spoofed packets or other attacks." > > > > BTW: why are NHDP message sequence numbers mentioned in Appendix C? If > unneeded, let's not send such. If it has some purpose, what are the threats? > > > > Teco > > > > > > Op 26 feb. 2013, om 18:16 heeft Dearlove, Christopher (UK) het volgende > geschreven: > > > >> Let's be crystal clear on what NHDP says - whichever way you want to > read it. Section 14.4 is the relevant part, and in whole it reads (where > the second bullet is the relevant one, but I've included it all for > context). > >> > >> A router MAY update link quality based on any information available > >> to it. Particular cases that MAY be used include: > >> > >> o Information from the link layer, such as signal-to-noise ratio or > >> packet acknowledgment reception and loss information. > >> > >> o Receipt or loss of control packets. If control packets include a > >> sequential packet sequence number, as defined in [RFC5444], then > >> link quality can be updated when a control packet is received, > >> whether or not it contains a HELLO message. The link quality may > >> then, for example, be based on whether the last N out of M control > >> packets on the link were received, or may use a "leaky integrator" > >> tracking packet reception and loss. > >> > >> o Receipt or loss of HELLO messages. If the maximum interval > >> between HELLO messages is known (such as by inclusion in HELLO > >> messages of a Message TLV with Type := INTERVAL_TIME, as defined > >> in [RFC5497]), then the loss of HELLO messages can be determined > >> without the need to receive a later HELLO message. Note that if > >> this case is combined with the previous case, then care must be > >> taken to avoid "double counting" a lost HELLO message in a lost > >> packet. > >> > >> -- > >> Christopher Dearlove > >> Senior Principal Engineer, Communications Group > >> Communications, Networks and Image Analysis Capability > >> BAE Systems Advanced Technology Centre > >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > >> Tel: +44 1245 242194 | Fax: +44 1245 242124 > >> chris.dearlove@baesystems.com | http://www.baesystems.com > >> > >> BAE Systems (Operations) Limited > >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > >> Registered in England & Wales No: 1996687 > >> > >> > >> -----Original Message----- > >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Teco Boot > >> Sent: 26 February 2013 16:51 > >> To: Ulrich Herberg > >> Cc: List > >> Subject: Re: [manet] I-D Action: > draft-ietf-manet-nhdp-sec-threats-01.txt > >> > >> ----------------------! WARNING ! ---------------------- > >> This message originates from outside our organisation, > >> either from an external partner or from the internet. > >> Keep this in mind if you answer this message. > >> Follow the 'Report Suspicious Emails' link on IT matters > >> for instructions on reporting suspicious email messages. > >> -------------------------------------------------------- > >> > >> Op 26 feb. 2013, om 08:37 heeft Ulrich Herberg > het volgende geschreven: > >> > >>> > >>> > >>> On Mon, Feb 25, 2013 at 10:41 PM, Teco Boot wrote: > >>> > >>> Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg > het volgende geschreven: > >>> > >>>> AB, > >>>> > >>>> again, sequence numbers are not used by NHDP, therefore not a threat > to NHDP. If another protocols uses that information, it may be a threat to > that protocol, and may be documented in a security threats analysis for > that protocol. > >>>> > >>>> It seems you are the only one advocating for changing the draft on > this aspect. I will wait if someone else also asks for changes on this > matter before changing it. > >>> > >>> Don't judge too early. I'm with AB that threats on optional parts of a > standard should be enlightened. > >>> > >>> But it is *not* an optional part of NHDP (nor is it mandatory). It is > simply named as example what implementers may do, but it is outside of the > normative part. I cannot guess what people can implement in addition to the > normative part, since there may be infinite possibilities. Please tell me > how I should write security threats for these potentially infinite, > non-normative, things that people can implement. > >>> > >>> I can only repeat it again: NHDP does *not* use sequence numbers, > neither packet nor message sequence numbers. > >> > >> Than that is your valid response. > >> > >> If a protocol has same optional or non-normative elements, I cannot see > any reason not to fold in security considerations for it. > >> No reason to write security considerations down for what is not > present. No infinity here. > >> > >> Teco > >> > >> > >> > >>> > >>> > >>> Ulrich > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e01160c4ef3692a04d6a95c59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jiazi,


On Tue, Feb 26, 2013 at 12:04 = PM, Jiazi Yi <ietf@jiaziyi.com> wrote:
Hi,

On the threat related to sequence number, my opinion is:

1. The "sequence number attack" in revision -00 is clearly wrong = (for duplicate detection), and not relevant to NHDP. So it has to be remove= d.

Yes.

=A0

2. The packet sequence number is not normative part of NHDP, however, it ma= y affects link quality updates. Therefore, I would agree with Teco, that we= can have a brief sentence to describe this threat, for example, in identit= y spoofing section.


Alright, even though I still think it's only = in a non-normative part, and a rare case (as described by Chris), it may no= t hurt adding a few sentences to the draft.

=A0

On the appendix C, it is a little strange that a message sequence number is= included. For me, it's unnecessary.

True, can= be removed IMO.

Ulrich



=A0

best

Jiazi

On Feb 26, 2013, at 8:00 PM, Teco Boot <teco@inf-net.nl> wrote:

> Due to some mail bombs, I couldn't find time to check the document= s. I'm not the only one. Today, the mail server I'm using was overl= oaded. It is not the smallest mail system on earth, so to say. Please send = real contributions only.
>
> I have nothing against a description of a NHDP security threat on pack= et sequence number attack. Could be a single sentence, such as: "If a = NHDP link quality measurement is based on MANET control packet sequence num= bers, as described in RFC 6130 section 14.4, such a mechanism can be influe= nced by spoofed packets or other attacks."
>
> BTW: why are NHDP message sequence numbers mentioned in Appendix C? If= unneeded, let's not send such. If it has some purpose, what are the th= reats?
>
> Teco
>
>
> Op 26 feb. 2013, om 18:16 heeft Dearlove, Christopher (UK) het volgend= e geschreven:
>
>> Let's be crystal clear on what NHDP says - whichever way you w= ant to read it. =A0Section 14.4 is the relevant part, and in whole it reads= (where the second bullet is the relevant one, but I've included it all= for context).
>>
>> =A0A router MAY update link quality based on any information avail= able
>> =A0to it. =A0Particular cases that MAY be used include:
>>
>> =A0o =A0Information from the link layer, such as signal-to-noise r= atio or
>> =A0 =A0 packet acknowledgment reception and loss information.
>>
>> =A0o =A0Receipt or loss of control packets. =A0If control packets = include a
>> =A0 =A0 sequential packet sequence number, as defined in [RFC5444]= , then
>> =A0 =A0 link quality can be updated when a control packet is recei= ved,
>> =A0 =A0 whether or not it contains a HELLO message. =A0The link qu= ality may
>> =A0 =A0 then, for example, be based on whether the last N out of M= control
>> =A0 =A0 packets on the link were received, or may use a "leak= y integrator"
>> =A0 =A0 tracking packet reception and loss.
>>
>> =A0o =A0Receipt or loss of HELLO messages. =A0If the maximum inter= val
>> =A0 =A0 between HELLO messages is known (such as by inclusion in H= ELLO
>> =A0 =A0 messages of a Message TLV with Type :=3D INTERVAL_TIME, as= defined
>> =A0 =A0 in [RFC5497]), then the loss of HELLO messages can be dete= rmined
>> =A0 =A0 without the need to receive a later HELLO message. =A0Note= that if
>> =A0 =A0 this case is combined with the previous case, then care mu= st be
>> =A0 =A0 taken to avoid "double counting" a lost HELLO me= ssage in a lost
>> =A0 =A0 packet.
>>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
>> chris.dearlove@ba= esystems.com | = http://www.baesystems.com
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace= Centre, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> -----Original Message-----
>> From: manet-bounces@ietf= .org [mailto:manet-bounces@ie= tf.org] On Behalf Of Teco Boot
>> Sent: 26 February 2013 16:51
>> To: Ulrich Herberg
>> Cc: <manet@ietf.org> L= ist
>> Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats= -01.txt
>>
>> ----------------------! WARNING ! ----------------------
>> This message originates from outside our organisation,
>> either from an external partner or from the internet.
>> Keep this in mind if you answer this message.
>> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages.
>> --------------------------------------------------------
>>
>> Op 26 feb. 2013, om 08:37 heeft Ulrich Herberg <ulrich@herberg.name> het volgende geschreven= :
>>
>>>
>>>
>>> On Mon, Feb 25, 2013 at 10:41 PM, Teco Boot <teco@inf-net.nl> wrote:
>>>
>>> Op 25 feb. 2013, om 08:12 heeft Ulrich Herberg <ulrich@herberg.name> het volgende geschr= even:
>>>
>>>> AB,
>>>>
>>>> again, sequence numbers are not used by NHDP, therefore no= t a threat to NHDP. If another protocols uses that information, it may be a= threat to that protocol, and may be documented in a security threats analy= sis for that protocol.
>>>>
>>>> It seems you are the only one advocating for changing the = draft on this aspect. I will wait if someone else also asks for changes on = this matter before changing it.
>>>
>>> Don't judge too early. I'm with AB that threats on opt= ional parts of a standard should be enlightened.
>>>
>>> But it is *not* an optional part of NHDP (nor is it mandatory)= . It is simply named as example what implementers may do, but it is outside= of the normative part. I cannot guess what people can implement in additio= n to the normative part, since there may be infinite possibilities. Please = tell me how I should write security threats for these potentially infinite,= non-normative, things that people can implement.
>>>
>>> I can only repeat it again: NHDP does *not* use sequence numbe= rs, neither packet nor message sequence numbers.
>>
>> Than that is your valid response.
>>
>> If a protocol has same optional or non-normative elements, I canno= t see any reason not to fold in security considerations for it.
>> No reason to write security considerations down for what is not pr= esent. No infinity here.
>>
>> Teco
>>
>>
>>
>>>
>>>
>>> Ulrich
>>
>> _______________________________________________
>> 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<= br> >> 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

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

--089e01160c4ef3692a04d6a95c59-- From abdussalambaryun@gmail.com Tue Feb 26 16:34:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06CC21F869B for ; Tue, 26 Feb 2013 16:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xInL71VsncIX for ; Tue, 26 Feb 2013 16:34:15 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id EA29821F869A for ; Tue, 26 Feb 2013 16:34:14 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id bj3so58312pad.6 for ; Tue, 26 Feb 2013 16:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7V4FtayYZvbIhTungBQRSqB3LYPniuyISZxx+mRhmhc=; b=v17yVz/N/0dzYm272DUrXxfXgKsfqHo1kXHQy8PEpRVNesqBkvY3IH3vFHwskSazJe Klt9e9aEWAJOcbhuiz8w/AmDD9RqHXnIefDiiqZrTWLcCAoXygO6zxkjYDVBpJ43SzCa NYw0+KFfrCOPGTg64OZL7oHYeBI+ELbBMT2vXHwgkfKSMmbVMIbrpxpTqvOBIybLx8U8 K3oUgJZQ5KJbeuXBlfdIcsAm6zq7re1FyjlGOfOIeXB+Y0tGIMfLoTx3tIJppGIXyOBW EvEKIXxRXzhHETxAYni6NsIbhKu9oeMSZ/zY0iV3XkJ6edorRRdhjgkavUBy4snOn6Ma bv1w== MIME-Version: 1.0 X-Received: by 10.66.234.132 with SMTP id ue4mr4459411pac.163.1361925254744; Tue, 26 Feb 2013 16:34:14 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 16:34:14 -0800 (PST) In-Reply-To: <8C48B86A895913448548E6D15DA7553B7AE356@xmb-rcd-x09.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> <8C48B86A895913448548E6D15DA7553B7AE356@xmb-rcd-x09.cisco.com> Date: Wed, 27 Feb 2013 01:34:14 +0100 Message-ID: From: Abdussalam Baryun To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 00:34:15 -0000 Hi Fred, I may try to answer you question but would like to know your opinion as well. I think the answer depend on the protocol applicability. The answer can be Yes and can be No. The answer may depend on the designer approach or the user's application as well. However, mostly the user side or the use-cases. Options for the protocol is interesting as we have DYMO and LOADng both are AODV, but as you refer to options, both reactive have different options, and they don't need to be interoperable. Different designers and different users may use different options. IETF documents don't do that kind of one protocol with options to produce many protocol uses (my assumption or understanding). Usually in MANET interoperability of different implementation of each manet protocol SHOULD be required, because mostly this WG covers general purpose protocols or wider use-case. Even the approach of using one MANET packet format in this WG maybe hint to getting options closer to protocols to become working together sometime in future, Thanks AB On 2/26/13, Fred Baker (fred) wrote: > > On Feb 20, 2013, at 7:53 AM, Henning Rogge wrote: > >> This would also give people a way to describe which "optional" >> features a software implementation supports. >> >> "We implemented the core plus the RFC xyz and abc." > > As I recall, that was the wonder of the OSI protocols. They did it with > options within the documents, but you could say that you did TP-4 with > options this and that, and you could describe SDLC NRM, LAP, LAPB, LAPF, > LAPM, and IEEE 802.2 as all implementing the same protocol with different > options. > > The only real problem was that none of the implementations had the same > option set as any of the others, which meant that none of them could > actually interoperate. > > Is interoperation a requirement? > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Tue Feb 26 16:43:33 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EE721F84CC for ; Tue, 26 Feb 2013 16:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCLi87AzXVnD for ; Tue, 26 Feb 2013 16:43:32 -0800 (PST) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4891921F84F0 for ; Tue, 26 Feb 2013 16:43:32 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id fb11so58465pad.28 for ; Tue, 26 Feb 2013 16:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=K3WXvSAX1KgEUQMH4y0qut+xRDcKKd/TMKAngD4eg18=; b=CXgAnx+lhkJFo40vDa3dOu9Ex5ZYfqSv1UeqXTOnRqgL9jC9985K/wBuUU1B1xDnJT Aq9GbyUvOWK5saTF4dZtYmAC/Q19NBte/w1QVI4BRICvtkR3iEQQZfGrRrWYr1UqSLj9 RujT+Sl6NYDJGrudr9SprQmIGQGo2iiewS65oUouDuED+mmUwpBFFh72IOl4NkWL+GBP jFxRVcwkayx7yAcbWwasV9bwMdMG3rZ2YXY6F9h1+PcOEZllmtVuRvZdtDpWoHerTMxg jJAiycIiianZkSEISHZGUlX3zF6/8VnKq2P4oWQrpfKgo1J/B20R3Sw5SVQmZw56sewU nzwQ== MIME-Version: 1.0 X-Received: by 10.66.220.227 with SMTP id pz3mr4445553pac.190.1361925812061; Tue, 26 Feb 2013 16:43:32 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 26 Feb 2013 16:43:31 -0800 (PST) In-Reply-To: References: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> <512BEF17.70605@computer.org> <7117edef-b2ee-40d5-90fd-7002c639a6cb@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB06ACABBD@SUCNPTEXM02.com.ad.uk.ds.corp> <0CFB809D-6517-47A9-AF15-EECAF852204E@thomasclausen.org> <2ED1D3801ACAAB459FDB4EAC9EAD090C10035DD2@xmb-aln-x03.cisco.com> <610DDB10-F5ED-4643-98D2-03C260A39C0E@thomasclausen.org> Date: Wed, 27 Feb 2013 01:43:31 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 00:43:33 -0000 Hi Thomas, What I know now that I am going to review aodvv2-00, and then will submit my review relating the aodvv2-00, I hope we follow to make it better as the WG co-chair requested, AB On 2/26/13, Thomas Heide Clausen wrote: > What you advance is not entirely accurate. > > There was an edict by an AD - but that edict was *not* supported by any > (rational or otherwise) arguments or justification or explanation. That > makes progress very difficult, especially since that edict went against a= n > objective majority. > > Thus, if the WG is to assume responsibility for that document, the very > least that is required is, that the WG be given the opportunity to expres= s > consensus for or against that document. > > If the WG is not given that opportunity, then I do not believe that the > document can proceed as a WG document - nor do I believe that it should > proceed as such. > > If the AD wishes to proceed with a document outside of a WG consensus, th= en > (s)he can pursue it as an AD sponsored document, seeking IETF consensus > instead. > > Thomas > > Sent from my iPad > > On 26 f=E9vr. 2013, at 21:48, Abdussalam Baryun > wrote: > >> Hi Thomas, >> >> we can see it from another angle. I see that as a WG we need to get >> together and make a reactive protocol standard, but because there was *n= o >> consensus* on which to choose, we still need to become a WG (please don'= t >> forget that we tried to make consensus but there was no for any reactive >> protocol). However, there was a consensus on the choosing person to take >> it over, and also that we want to continue having such item on the >> charter. >> >> So, there was consensus of the WG for the work in progress charter item >> needed, and the person to choose that item, >> >> AB >> >> On Tue, Feb 26, 2013 at 8:41 PM, Thomas Heide Clausen >> wrote: >>> In other words, WG consensus is disregarded concerning this document. >>> >>> Thank you for that clarification, this is duly noted. >>> >>> Thomas >>> >>> Sent from my iPad >>> >>> On 26 f=E9vr. 2013, at 21:37, "Stan Ratliff (sratliff)" >>> wrote: >>> >>>> Thomas, >>>> >>>> According to the last email from Adrian, the Dymo draft would be renam= ed >>>> to AODVv2 at the next opportunity. So no, I do not anticipate another = WG >>>> polling for adoption; rather, this is following the script. >>>> >>>> Regards, >>>> Stan >>>> >>>> On Feb 26, 2013, at 7:22 AM, Thomas Clausen wrote: >>>> >>>>> Before a new document is adopted as a WG document, the WG will be >>>>> polled for adoption - yes? >>>>> >>>>> Thomas >>>>> >>>>> On Feb 26, 2013, at 1:20 PM, "Dowdell, John" >>>>> wrote: >>>>> >>>>>> Abdussalam >>>>>> >>>>>> Yes that is the case. As Charlie mentioned it was forced on us by th= e >>>>>> IT machinery. We will fix it as soon as we are able. >>>>>> >>>>>> Regards >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Beha= lf >>>>>> Of Abdussalam Baryun >>>>>> Sent: 26 February 2013 11:10 >>>>>> To: Charles E. Perkins >>>>>> Cc: manet@ietf.org; Stan Ratliff >>>>>> Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt >>>>>> >>>>>> Hi AODVv2 Editors, >>>>>> >>>>>> So do you mean if I review now the dymo-26 it is the same as >>>>>> aodvv2-00, >>>>>> please advise, >>>>>> >>>>>> AB >>>>>> >>>>>> On Mon, Feb 25, 2013 at 11:09 PM, Charles E. Perkins >>>>>> wrote: >>>>>> >>>>>> Hello folks, >>>>>> >>>>>> draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet >>>>>> Drafts >>>>>> directories. The only problem is that it's got the wrong name, >>>>>> namely >>>>>> "draft-ietf-manet-dymo-26.txt" >>>>>> >>>>>> This is because it's now a week past the submission deadline for >>>>>> ...-00.txt >>>>>> initial drafts, and the submission tool would not allow me to upload >>>>>> it with >>>>>> it's intended new name. >>>>>> >>>>>> This naming problem will be rectified at the earliest opportunity. >>>>>> >>>>>> Regards, >>>>>> Charlie P. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote: >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the Mobile Ad-hoc Networks Working >>>>>> Group of the IETF. >>>>>> >>>>>> Title : Dynamic MANET On-demand (AODVv2) Routing >>>>>> Author(s) : Charles E. Perkins >>>>>> Stan Ratliff >>>>>> John Dowdell >>>>>> Filename : draft-ietf-manet-dymo-26.txt >>>>>> Pages : 60 >>>>>> Date : 2013-02-25 >>>>>> >>>>>> Abstract: >>>>>> The revised Ad Hoc On-demand Distance Vector (AODVv2) routing >>>>>> protocol is intended for use by mobile routers in wireless, >>>>>> multihop >>>>>> networks. AODVv2 determines unicast routes among AODVv2 routers >>>>>> within the network in an on-demand fashion, offering on-demand >>>>>> convergence in dynamic topologies. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-dymo >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-manet-dymo-26 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26 >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Charlie P. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>> >>>>>> The information contained within this e-mail and any files attached = to >>>>>> this e-mail is private and in addition may include commercially >>>>>> sensitive information. The contents of this e-mail are for the >>>>>> intended recipient only and therefore if you wish to disclose the >>>>>> information contained within this e-mail or attached files, please >>>>>> contact the sender prior to any such disclosure. If you are not the >>>>>> intended recipient, any disclosure, copying or distribution is >>>>>> prohibited. Please also contact the sender and inform them of the >>>>>> error and delete the e-mail, including any attached files from your >>>>>> system. Cassidian Limited, Registered Office : Quadrant House, Celti= c >>>>>> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 >>>>>> http://www.cassidian.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 > From abdussalambaryun@gmail.com Wed Feb 27 02:06:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD1021F858A for ; Wed, 27 Feb 2013 02:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2Ek8ZbLH5-g for ; Wed, 27 Feb 2013 02:06:41 -0800 (PST) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id 582F421F8581 for ; Wed, 27 Feb 2013 02:06:41 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id un1so280386pbc.12 for ; Wed, 27 Feb 2013 02:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ndJOcFGkuyd4KYjquA03kmVwjLnlDKOYeFQ8csNzpLE=; b=UjoOYEWMKTtndYhfiV5K4uIEwN/7hBRo6uv/CkEpyIh74BObIw2ZaX+MiyuVlCowaM tJnJcp5zBKowYUrq5vtP32m6ugjUvSfKc3MFmiPUG6kJ7S+5TQ6Y59h38q4GLSjI13RS 07ZAid0f+56XUn020NOo4MIIQ8onRV4xXbW2NUycZCJ2KJpxhHn40rGPXhCR1Za8239p XmHsqkKxQZJaMRKvKF+oxkruLo7kRFqoOAJrebN+Zebo9DGrUXQsa1VcXA0afKJYoXRP 2+oBdFm4ZA2q8ESs7mandR2/S2SEPfs+tgnPtLFX4nf0ykQhXjQd5tk9hWDNUM7mTKKU HsRA== MIME-Version: 1.0 X-Received: by 10.66.13.74 with SMTP id f10mr6612380pac.202.1361959601061; Wed, 27 Feb 2013 02:06:41 -0800 (PST) Received: by 10.68.33.132 with HTTP; Wed, 27 Feb 2013 02:06:40 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fkie.fraunhofer.de> Date: Wed, 27 Feb 2013 10:06:40 +0000 Message-ID: From: Abdussalam Baryun To: Daniel He Content-Type: multipart/alternative; boundary=bcaec520e62f38465304d6b1ee40 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 10:06:41 -0000 --bcaec520e62f38465304d6b1ee40 Content-Type: text/plain; charset=ISO-8859-1 I will just quote the AD statement once on MANET WG list once; [.... I don't think it is a valuable use of time for anyone to debate the meaning of the responses or their number. ] Please don't respond to this, AB On Mon, Feb 25, 2013 at 6:55 PM, Daniel He wrote: > Hi Mr Baryun, > > So what? if you didn't know that issues, that is you not on the whole > internet > community. Don't speak for US! > > Even we didn' t know those issues, now it is corrected that it > is pretty fine to US. there is no wrong behavior as you accused of > commiting > on the time. I would like to remind you: DON'T SPAM in this mailing list. > Every day I received your email for nothing! > > Cheers, > > Dan > >> >> > --bcaec520e62f38465304d6b1ee40 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I will just quote the AD statement once on MANET WG list once;
=A0
[....
=A0I don't thi= nk it is a valuable use of time for anyone to debate the meaning of the responses or their number. ]
=A0
Please don't respond to this,
AB
On Mon, Feb 25, 2013 at 6:55 PM, Daniel He = <drdanhe@gmail.co= m> wrote:
Hi Mr Baryun,

So what? if you didn't know that = issues, that is you not on the whole internet
community. Don't speak for US!

Even we didn' t know=A0 those= issues, now it is corrected that it
is pretty fine to US. there is no = wrong behavior as you accused of commiting
on the time. I would like to remind you: DON'T SPAM in this mailing lis= t.
Every day I received your email for nothing!

Cheers,

Da= n
=A0
--bcaec520e62f38465304d6b1ee40-- From john.dowdell@cassidian.com Wed Feb 27 02:20:15 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E84921F850C for ; Wed, 27 Feb 2013 02:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCVJVP6M0SNu for ; Wed, 27 Feb 2013 02:20:14 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6B54721F84E6 for ; Wed, 27 Feb 2013 02:20:10 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 27 Feb 2013 11:20:08 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 27 Feb 2013 11:20:08 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 11:20:08 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 11:20:07 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 10:20:07 +0000 From: "Dowdell, John" To: Abdussalam Baryun , "Fred Baker (fred)" Thread-Topic: [manet] Why the WG Reactive Protocol to be Compatible with another? Thread-Index: AQHOFIIqnykg1LA9e0y1tSpJX7OE+ZiNeXog Date: Wed, 27 Feb 2013 10:20:06 +0000 Message-ID: <603F5FD847B5174CBDA37A9DC00532FB06ACD824@SUCNPTEXM02.com.ad.uk.ds.corp> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> <8C48B86A895913448548E6D15DA7553B7AE356@xmb-rcd-x09.cisco.com> <7332835e-651e-4f66-8c78-3013e92f52cc@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <7332835e-651e-4f66-8c78-3013e92f52cc@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.216.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2013 10:20:07.0692 (UTC) FILETIME=[043AFCC0:01CE14D4] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19660.000 X-TM-AS-Result: No--21.181200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "manet@ietf.org" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 10:20:15 -0000 Lets be clear what we mean by compatible here, since I am reading this in m= ore than one area just now in relation to routing protocols. Considering ITU specifications, PBX vendors that implemented the Q.931 inte= r-PBX protocol all had to conduct case-by-case bilateral interoperability t= ests because the message and action sequences in their implementations were= all hard-wired and different, even though they were written on the same st= andard. All were compatible and yet not. Is, say, OSPF compatible with iBGP? They can co-exist on the same network, = thanks to the IANA registries, but an OSPF parser will not understand iBGP,= nor should it. Can a single router understand both? That is up to the desi= gner of the router. Should MANET routing protocols use common building bloc= ks? Absolutely, where it makes sense to do so. AODVv2 is using RFC5444 for = message transport, but AODVv2 does a different job to OLSRv2, so the AODVv2= messages are likely to be different to those of OLSRv2. Personally I am in favour of a well-written core protocol and as few option= s as possible, but if the final WG consensus for AODVv2 is for a small core= and many options then that is what will be written. Vendors claim complian= ce with a single RFC document so we must seek to reduce the scope for incom= patible implementations of the same protocol. John -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: 27 February 2013 00:34 To: Fred Baker (fred) Cc: manet@ietf.org Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with ano= ther? Hi Fred, I may try to answer you question but would like to know your opinion as well. I think the answer depend on the protocol applicability. The answer can be Yes and can be No. The answer may depend on the designer approach or the user's application as well. However, mostly the user side or the use-cases. Options for the protocol is interesting as we have DYMO and LOADng both are AODV, but as you refer to options, both reactive have different options, and they don't need to be interoperable. Different designers and different users may use different options. IETF documents don't do that kind of one protocol with options to produce many protocol uses (my assumption or understanding). Usually in MANET interoperability of different implementation of each manet protocol SHOULD be required, because mostly this WG covers general purpose protocols or wider use-case. Even the approach of using one MANET packet format in this WG maybe hint to getting options closer to protocols to become working together sometime in future, Thanks AB On 2/26/13, Fred Baker (fred) wrote: > > On Feb 20, 2013, at 7:53 AM, Henning Rogge wrote: > >> This would also give people a way to describe which "optional" >> features a software implementation supports. >> >> "We implemented the core plus the RFC xyz and abc." > > As I recall, that was the wonder of the OSI protocols. They did it with > options within the documents, but you could say that you did TP-4 with > options this and that, and you could describe SDLC NRM, LAP, LAPB, LAPF, > LAPM, and IEEE 802.2 as all implementing the same protocol with different > options. > > The only real problem was that none of the implementations had the same > option set as any of the others, which meant that none of them could > actually interoperate. > > Is interoperation a requirement? > _______________________________________________ > 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 The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From abdussalambaryun@gmail.com Wed Feb 27 02:43:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC1E21F8436 for ; Wed, 27 Feb 2013 02:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWA0LZ8iFITC for ; Wed, 27 Feb 2013 02:43:28 -0800 (PST) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id BAC9F21F8433 for ; Wed, 27 Feb 2013 02:43:28 -0800 (PST) Received: by mail-da0-f54.google.com with SMTP id p1so241411dad.13 for ; Wed, 27 Feb 2013 02:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=C3gFgYMqUNue/ZhU8JB8EV4WWt7y/2P1e3JhHsuRcnU=; b=jCUbDCvw+HUIKwZL5ti7CUSJlHFHmbdG1Z2yS14w+e1+Cb1iKJkmIE+oJFUO6szjZ1 d76/YUGQYXtCOH4d1FSCIsrqhEoEgDhQs50qPk1CrQ/sR577ZBf5hchw8nz1kOmyBUi1 Ny/ol8o5/h7ZKEqdGZmWUjMMW/U70prnkZPbyD06Sc8CsacvvNWOAOyn6/88G0L+Sif3 XmjqHN5440sLlWoJn/CYouCNZnvB137c/MLavWzi0mnE/ROzBE5Ejw/OdnJ3QTn3EHKY DaXxpVeTHtv5+wazMF3R/i+kHRfpsvJ1coW0qK4tK49vM/5UsGNoY69JGE4V8HDnvXXM SE2g== MIME-Version: 1.0 X-Received: by 10.66.220.227 with SMTP id pz3mr6673929pac.190.1361961808480; Wed, 27 Feb 2013 02:43:28 -0800 (PST) Received: by 10.68.33.132 with HTTP; Wed, 27 Feb 2013 02:43:28 -0800 (PST) In-Reply-To: <603F5FD847B5174CBDA37A9DC00532FB06ACD824@SUCNPTEXM02.com.ad.uk.ds.corp> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> <8C48B86A895913448548E6D15DA7553B7AE356@xmb-rcd-x09.cisco.com> <7332835e-651e-4f66-8c78-3013e92f52cc@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB06ACD824@SUCNPTEXM02.com.ad.uk.ds.corp> Date: Wed, 27 Feb 2013 10:43:28 +0000 Message-ID: From: Abdussalam Baryun To: "Dowdell, John" Content-Type: multipart/alternative; boundary=047d7b5d49f4cad01e04d6b271b1 Cc: "manet@ietf.org" , "Fred Baker \(fred\)" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 10:43:30 -0000 --047d7b5d49f4cad01e04d6b271b1 Content-Type: text/plain; charset=ISO-8859-1 Hi John, I agree with you but not sure about one below; On Wed, Feb 27, 2013 at 10:20 AM, Dowdell, John wrote: > Lets be clear what we mean by compatible here, since I am reading this in > more than one area just now in relation to routing protocols. > > Considering ITU specifications, PBX vendors that implemented the Q.931 > inter-PBX protocol all had to conduct case-by-case bilateral > interoperability tests because the message and action sequences in their > implementations were all hard-wired and different, even though they were > written on the same standard. All were compatible and yet not. > > Is, say, OSPF compatible with iBGP? They can co-exist on the same network, > thanks to the IANA registries, but an OSPF parser will not understand iBGP, > nor should it. Can a single router understand both? That is up to the > designer of the router. Should MANET routing protocols use common building > blocks? Absolutely, where it makes sense to do so. AODVv2 is using RFC5444 > for message transport, but AODVv2 does a different job to OLSRv2, so the > AODVv2 messages are likely to be different to those of OLSRv2. > > Personally I am in favour of a well-written core protocol and as few > options as possible, agree > but if the final WG consensus for AODVv2 is for a small core and many > options then that is what will be written. What do you mean by *options*, are they protocol operation options, or information options? from Henning and Fred input I understood it meant operation options. > Vendors claim compliance with a single RFC document so we must seek to > reduce the scope for incompatible implementations of the same protocol. > > agree > John > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 27 February 2013 00:34 > To: Fred Baker (fred) > Cc: manet@ietf.org > Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with > another? > > Hi Fred, > > I may try to answer you question but would like to know your opinion > as well. I think the answer depend on the protocol applicability. The > answer can be Yes and can be No. The answer may depend on the designer > approach or the user's application as well. However, mostly the user > side or the use-cases. Options for the protocol is interesting as we > have DYMO and LOADng both are AODV, but as you refer to options, both > reactive have different options, and they don't need to be > interoperable. Different designers and different users may use > different options. IETF documents don't do that kind of one protocol > with options to produce many protocol uses (my assumption or > understanding). > > Usually in MANET interoperability of different implementation of each > manet protocol SHOULD be required, because mostly this WG covers > general purpose protocols or wider use-case. Even the approach of > using one MANET packet format in this WG maybe hint to getting options > closer to protocols to become working together sometime in future, > > Thanks > AB > > On 2/26/13, Fred Baker (fred) wrote: > > > > On Feb 20, 2013, at 7:53 AM, Henning Rogge > wrote: > > > >> This would also give people a way to describe which "optional" > >> features a software implementation supports. > >> > >> "We implemented the core plus the RFC xyz and abc." > > > > As I recall, that was the wonder of the OSI protocols. They did it with > > options within the documents, but you could say that you did TP-4 with > > options this and that, and you could describe SDLC NRM, LAP, LAPB, LAPF, > > LAPM, and IEEE 802.2 as all implementing the same protocol with different > > options. > > > > The only real problem was that none of the implementations had the same > > option set as any of the others, which meant that none of them could > > actually interoperate. > > > > Is interoperation a requirement? > > _______________________________________________ > > 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 > The information contained within this e-mail and any files attached to > this e-mail is private and in addition may include commercially sensitive > information. The contents of this e-mail are for the intended recipient > only and therefore if you wish to disclose the information contained within > this e-mail or attached files, please contact the sender prior to any such > disclosure. If you are not the intended recipient, any disclosure, copying > or distribution is prohibited. Please also contact the sender and inform > them of the error and delete the e-mail, including any attached files from > your system. Cassidian Limited, Registered Office : Quadrant House, Celtic > Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 > http://www.cassidian.com > --047d7b5d49f4cad01e04d6b271b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi John,
=A0
I agree with you but not sure about o= ne below;

On Wed, Feb 27, 2013 at 1= 0:20 AM, Dowdell, John <John.Dowdell@cassidian.com>= wrote:
Lets be clear what we mean by compatible here, since I am = reading this in more than one area just now in relation to routing protocol= s.

Considering ITU specifications, PBX vendors that implemented the Q.931 inte= r-PBX protocol all had to conduct case-by-case bilateral interoperability t= ests because the message and action sequences in their implementations were= all hard-wired and different, even though they were written on the same st= andard. All were compatible and yet not.

Is, say, OSPF compatible with iBGP? They can co-exist on the same network, = thanks to the IANA registries, but an OSPF parser will not understand iBGP,= nor should it. Can a single router understand both? That is up to the desi= gner of the router. Should MANET routing protocols use common building bloc= ks? Absolutely, where it makes sense to do so. AODVv2 is using RFC5444 for = message transport, but AODVv2 does a different job to OLSRv2, so the AODVv2= messages are likely to be different to those of OLSRv2.

Personally I am in favour of a well-written core protocol and as few option= s as possible,
=A0
agree
=A0
but if the final WG consensus for AODVv2 is for a small core and many opti= ons then that is what will be written.
=A0
What= do you mean by *options*, are they protocol operation options, or informat= ion options? from Henning and Fred=A0input I understood it meant operation = options.
=A0
Vendors claim compliance with a single RFC d= ocument so we must seek to reduce the scope for incompatible implementation= s of the same protocol.

agree=A0
John


-----Original Message-----
From: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 27 February 2013 00:34
To: Fred Baker (fred)
Cc: manet@ietf.org
Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with ano= ther?

Hi Fred,

I may try to answer you question but would like to know your opinion
as well. I think the answer depend on the protocol applicability. The
answer can be Yes and can be No. The answer may depend on the designer
approach or the user's application as well. However, mostly the user side or the use-cases. Options for the protocol is interesting as we
have DYMO and LOADng both are AODV, but as you refer to options, both
reactive have different options, and they don't need to be
interoperable. Different designers and different users may use
different options. IETF documents don't do that kind of one protocol with options to produce many protocol uses (my assumption or
understanding).

Usually in MANET interoperability of different implementation of each
manet protocol SHOULD be required, because mostly this WG covers
general purpose protocols or wider use-case. Even the approach of
using one MANET packet format in this WG maybe hint to getting options
closer to protocols to become working together sometime in future,

Thanks
AB

On 2/26/13, Fred Baker (fred) <fred@ci= sco.com> wrote:
>
> On Feb 20, 2013, at 7:53 AM, Hennin= g Rogge <hrogge@googlemail.com<= /a>> wrote:
>
>> This would also give people a way to describe which "optional= "
>> features a software implementation supports.
>>
>> "We implemented the core plus the RFC xyz and abc."
>
> As I recall, that was the wonder of the OSI protocols. They did it wit= h
> options within the documents, but you could say that you did TP-4 with=
> options this and that, and you could describe SDLC NRM, LAP, LAPB, LAP= F,
> LAPM, and IEEE 802.2 as all implementing the same protocol with differ= ent
> options.
>
> The only real problem was that none of the implementations had the sam= e
> option set as any of the others, which meant that none of them could > actually interoperate.
>
> Is interoperation a requirement?
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
The information contained within this e-mail and any files atta= ched to this e-mail is private and in addition may include commercially sen= sitive information. The contents of this e-mail are for the intended recipi= ent only and therefore if you wish to disclose the information contained wi= thin this e-mail or attached files, please contact the sender prior to any = such disclosure. If you are not the intended recipient, any disclosure, cop= ying or distribution is prohibited. Please also contact the sender and info= rm them of the error and delete the e-mail, including any attached files fr= om your system. Cassidian Limited, Registered Office : Quadrant House, Celt= ic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

--047d7b5d49f4cad01e04d6b271b1-- From drdanhe@gmail.com Wed Feb 27 02:54:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D1C21F850E for ; Wed, 27 Feb 2013 02:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da+IofCSbw5d for ; Wed, 27 Feb 2013 02:54:07 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id D1B7421F8506 for ; Wed, 27 Feb 2013 02:54:07 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id k13so424390iea.21 for ; Wed, 27 Feb 2013 02:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XVnEqXNtAQnyAeiMjRczb3q8T6hNJC/ywrRxttIFVb8=; b=sZbNF8jeUjDyAY+/vQo85DjKukdjt0Fw/xbc/rmDuNWxl0FAONs9BjYWKR3TTQ/BdE J6FSwvwFFUPuMP2kS4VNx407HDEEnIBAloLCmpMdxmE1qfMkNwruHXz05DFncAtG0GMc /raDevjx/PdSGmV/arDyYdy6Ctt7Xf31GyHoFG3T9ivFUCMTkXYVxrqRCbRFVxgJp+lz UCzVK6PheG6VVMDOtkPH7/0xolPriF2k26uUp56fLxripNiIqZRf0plwiEL7crHDIgyM n1guUS3FdZVbxjCjbGRSW/DFX2ZKx6/aMuzqH8c9uELnGXAFEBuJ2sRkt/YskvPAPEAL d0Rw== MIME-Version: 1.0 X-Received: by 10.43.134.202 with SMTP id id10mr736513icc.46.1361962447409; Wed, 27 Feb 2013 02:54:07 -0800 (PST) Received: by 10.50.85.6 with HTTP; Wed, 27 Feb 2013 02:54:07 -0800 (PST) In-Reply-To: References: <20121022205917.15922.83347.idtracker@ietfa.amsl.com> <512B15DC.1030002@fkie.fraunhofer.de> <512B1BD3.8080303@fkie.fraunhofer.de> <512B6443.9020807@fkie.fraunhofer.de> Date: Wed, 27 Feb 2013 10:54:07 +0000 Message-ID: From: Daniel He To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=20cf307f365ce01f2204d6b297a7 Cc: manet@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 10:54:08 -0000 --20cf307f365ce01f2204d6b297a7 Content-Type: text/plain; charset=ISO-8859-1 I don't think it is a valuable use of time for anyone to send me useless and unnecessary responses!! stop it please --20cf307f365ce01f2204d6b297a7 Content-Type: text/html; charset=ISO-8859-1 I don't think it is a valuable use of time for anyone to send me useless and unnecessary responses!!

stop it please
--20cf307f365ce01f2204d6b297a7-- From john.dowdell@cassidian.com Wed Feb 27 03:01:20 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA8021F8498 for ; Wed, 27 Feb 2013 03:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjvxehmI-eKF for ; Wed, 27 Feb 2013 03:01:14 -0800 (PST) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id D80B621F8519 for ; Wed, 27 Feb 2013 03:01:12 -0800 (PST) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 27 Feb 2013 12:01:11 +0100 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 27 Feb 2013 12:01:10 +0100 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 12:01:10 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 12:01:10 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 11:01:09 +0000 From: "Dowdell, John" To: Abdussalam Baryun Thread-Topic: [manet] Why the WG Reactive Protocol to be Compatible with another? Thread-Index: AQHOFNftTxZYpzuFOEKSnZKzmYfyK5iNhq9Q Date: Wed, 27 Feb 2013 11:01:09 +0000 Message-ID: <603F5FD847B5174CBDA37A9DC00532FB06ACD88B@SUCNPTEXM02.com.ad.uk.ds.corp> References: <03B78081B371D44390ED6E7BADBB4A77232CA63D@xmb-rcd-x02.cisco.com> <8C48B86A895913448548E6D15DA7553B7AE356@xmb-rcd-x09.cisco.com> <7332835e-651e-4f66-8c78-3013e92f52cc@SUCNPTEXC01.COM.AD.UK.DS.CORP> <603F5FD847B5174CBDA37A9DC00532FB06ACD824@SUCNPTEXM02.com.ad.uk.ds.corp> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.216.34] Content-Type: multipart/alternative; boundary="_000_603F5FD847B5174CBDA37A9DC00532FB06ACD88BSUCNPTEXM02coma_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2013 11:01:10.0407 (UTC) FILETIME=[C01F7970:01CE14D9] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19658.003 X-TM-AS-Result: No--22.549600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "manet@ietf.org" , "Fred Baker \(fred\)" Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with another? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 11:01:20 -0000 --_000_603F5FD847B5174CBDA37A9DC00532FB06ACD88BSUCNPTEXM02coma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well let's consider something in AODVv2 which is present in the current dra= ft. It is mandatory for routers to multicast RREQ messages to a nominated m= ulticast address. However there is an option for routers to send by unicast= to the next hop. I will not debate this topic here, you'll have to read th= e draft, but: Core - receiving routers MUST listen on a specified multicast address for i= ncoming RREQ messages Option - receiving router MAY listen for same message on its unicast addres= s. Thus the option is a different behaviour (or operation if you wish) from th= e core specification. The implementation requires core functionality, plus = whichever options the implementer feels necessary to achieve their objectiv= e. An implementation that does not listen on the Unicast address for RREQs = would not receive them, but could still claim compliance with the specifica= tion. John From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 27 February 2013 10:43 To: Dowdell, John Cc: Fred Baker (fred); manet@ietf.org Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with ano= ther? Hi John, I agree with you but not sure about one below; On Wed, Feb 27, 2013 at 10:20 AM, Dowdell, John > wrote: Lets be clear what we mean by compatible here, since I am reading this in m= ore than one area just now in relation to routing protocols. Considering ITU specifications, PBX vendors that implemented the Q.931 inte= r-PBX protocol all had to conduct case-by-case bilateral interoperability t= ests because the message and action sequences in their implementations were= all hard-wired and different, even though they were written on the same st= andard. All were compatible and yet not. Is, say, OSPF compatible with iBGP? They can co-exist on the same network, = thanks to the IANA registries, but an OSPF parser will not understand iBGP,= nor should it. Can a single router understand both? That is up to the desi= gner of the router. Should MANET routing protocols use common building bloc= ks? Absolutely, where it makes sense to do so. AODVv2 is using RFC5444 for = message transport, but AODVv2 does a different job to OLSRv2, so the AODVv2= messages are likely to be different to those of OLSRv2. Personally I am in favour of a well-written core protocol and as few option= s as possible, agree but if the final WG consensus for AODVv2 is for a small core and many optio= ns then that is what will be written. What do you mean by *options*, are they protocol operation options, or info= rmation options? from Henning and Fred input I understood it meant operatio= n options. Vendors claim compliance with a single RFC document so we must seek to redu= ce the scope for incompatible implementations of the same protocol. agree John -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Abdussalam Bar= yun Sent: 27 February 2013 00:34 To: Fred Baker (fred) Cc: manet@ietf.org Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with ano= ther? Hi Fred, I may try to answer you question but would like to know your opinion as well. I think the answer depend on the protocol applicability. The answer can be Yes and can be No. The answer may depend on the designer approach or the user's application as well. However, mostly the user side or the use-cases. Options for the protocol is interesting as we have DYMO and LOADng both are AODV, but as you refer to options, both reactive have different options, and they don't need to be interoperable. Different designers and different users may use different options. IETF documents don't do that kind of one protocol with options to produce many protocol uses (my assumption or understanding). Usually in MANET interoperability of different implementation of each manet protocol SHOULD be required, because mostly this WG covers general purpose protocols or wider use-case. Even the approach of using one MANET packet format in this WG maybe hint to getting options closer to protocols to become working together sometime in future, Thanks AB On 2/26/13, Fred Baker (fred) > wrote= : > > On Feb 20, 2013, at 7:53 AM, Henning Rogge > wrote: > >> This would also give people a way to describe which "optional" >> features a software implementation supports. >> >> "We implemented the core plus the RFC xyz and abc." > > As I recall, that was the wonder of the OSI protocols. They did it with > options within the documents, but you could say that you did TP-4 with > options this and that, and you could describe SDLC NRM, LAP, LAPB, LAPF, > LAPM, and IEEE 802.2 as all implementing the same protocol with different > options. > > The only real problem was that none of the implementations had the same > option set as any of the others, which meant that none of them could > actually interoperate. > > Is interoperation a requirement? > _______________________________________________ > 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 The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com --_000_603F5FD847B5174CBDA37A9DC00532FB06ACD88BSUCNPTEXM02coma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well let’s consider something in AODVv2 = which is present in the current draft. It is mandatory for routers to multi= cast RREQ messages to a nominated multicast address. However there is an option for routers to send by unicast to the next hop. I will not de= bate this topic here, you’ll have to read the draft, but:

 

Core – receiving routers MUST listen on = a specified multicast address for incoming RREQ messages

Option – receiving router MAY listen for= same message on its unicast address.

 

Thus the option is a different behaviour (or o= peration if you wish) from the core specification. The implementation requi= res core functionality, plus whichever options the implementer feels necessary to achieve their objective. An implementation that does no= t listen on the Unicast address for RREQs would not receive them, but could= still claim compliance with the specification.

 

John

 

 

 

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.co= m]
Sent: 27 February 2013 10:43
To: Dowdell, John
Cc: Fred Baker (fred); manet@ietf.org
Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible w= ith another?

 

Hi John,

 

I agree with you but = not sure about one below;

On Wed, Feb 27, 2013 at 10:20 AM, Dowdell, John <= John.Dowdel= l@cassidian.com> wrote:

Lets be clear what we mean by compatible here, since= I am reading this in more than one area just now in relation to routing pr= otocols.

Considering ITU specifications, PBX vendors that implemented the Q.931 inte= r-PBX protocol all had to conduct case-by-case bilateral interoperability t= ests because the message and action sequences in their implementations were= all hard-wired and different, even though they were written on the same standard. All were compatible and yet= not.

Is, say, OSPF compatible with iBGP? They can co-exist on the same network, = thanks to the IANA registries, but an OSPF parser will not understand iBGP,= nor should it. Can a single router understand both? That is up to the desi= gner of the router. Should MANET routing protocols use common building blocks? Absolutely, where it makes s= ense to do so. AODVv2 is using RFC5444 for message transport, but AODVv2 do= es a different job to OLSRv2, so the AODVv2 messages are likely to be diffe= rent to those of OLSRv2.

Personally I am in favour of a well-written core protocol and as few option= s as possible,

 

agree

 

but if the final WG consensus for AODVv2 is for a sm= all core and many options then that is what will be written.

 

What do you mean by *options*, are they protocol ope= ration options, or information options? from Henning and Fred input I = understood it meant operation options.

 

Vendors claim complia= nce with a single RFC document so we must seek to reduce the scope for inco= mpatible implementations of the same protocol.

agree 

John



-----Original Message-----
From: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 27 February 2013 00:34
To: Fred Baker (fred)
Cc: manet@ietf.org
Subject: Re: [manet] Why the WG Reactive Protocol to be Compatible with ano= ther?

Hi Fred,

I may try to answer you question but would like to know your opinion
as well. I think the answer depend on the protocol applicability. The
answer can be Yes and can be No. The answer may depend on the designer
approach or the user's application as well. However, mostly the user
side or the use-cases. Options for the protocol is interesting as we
have DYMO and LOADng both are AODV, but as you refer to options, both
reactive have different options, and they don't need to be
interoperable. Different designers and different users may use
different options. IETF documents don't do that kind of one protocol
with options to produce many protocol uses (my assumption or
understanding).

Usually in MANET interoperability of different implementation of each
manet protocol SHOULD be required, because mostly this WG covers
general purpose protocols or wider use-case. Even the approach of
using one MANET packet format in this WG maybe hint to getting options
closer to protocols to become working together sometime in future,

Thanks
AB

On 2/26/13, Fred Baker (fred) <fred@ci= sco.com> wrote:
>

> On Feb 20, 2013, at 7:53 AM, Henning Rogge <= hrogge@googlemail.com> wrot= e:
>
>> This would also give people a way to describe which "optional= "
>> features a software implementation supports.
>>
>> "We implemented the core plus the RFC xyz and abc."
>
> As I recall, that was the wonder of the OSI protocols. They did it wit= h
> options within the documents, but you could say that you did TP-4 with=
> options this and that, and you could describe SDLC NRM, LAP, LAPB, LAP= F,
> LAPM, and IEEE 802.2 as all implementing the same protocol with differ= ent
> options.
>
> The only real problem was that none of the implementations had the sam= e
> option set as any of the others, which meant that none of them could > actually interoperate.
>
> Is interoperation a requirement?
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

The information contained within this e-mail and any= files attached to this e-mail is private and in addition may include comme= rcially sensitive information. The contents of this e-mail are for the inte= nded recipient only and therefore if you wish to disclose the information contained within this e-mail or at= tached files, please contact the sender prior to any such disclosure. If yo= u are not the intended recipient, any disclosure, copying or distribution i= s prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including a= ny attached files from your system. Cassidian Limited, Registered Office : = Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 0= 4191036 http://www.cassidian= .com

 

The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-mail or attached files, please con= tact the sender prior to any such disclosure. If you are not the intended r= ecipient, any disclosure, copying or distribution is prohibited. Please als= o contact the sender and inform them of the error and delete the e-mail, including any attached files from= your system. Cassidian Limited, Registered Office : Quadrant House, Celtic= Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cas= sidian.com --_000_603F5FD847B5174CBDA37A9DC00532FB06ACD88BSUCNPTEXM02coma_-- From abdussalambaryun@gmail.com Wed Feb 27 05:31:46 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE8821F8623 for ; Wed, 27 Feb 2013 05:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTykJGfKeIKt for ; Wed, 27 Feb 2013 05:31:45 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7C40C21F8602 for ; Wed, 27 Feb 2013 05:31:45 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id kp6so428234pab.22 for ; Wed, 27 Feb 2013 05:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=pziDKtPuazQVLgU9raKi1CO79xXGVidvxvpe9y1N0cQ=; b=DdT+WAT+NNjKmZsLThmqMZnfwlkMSNpfo5fyKk+xtBPAwO4VF5R7Lo8XOyghcnFwgv nLe8n07kQ7f1FgdOMmhUjg4G2aKxDnqohBT1oDSGLXWYBC97Mi9koWVKb/yfd07I04JK AR8MRiDreUGqu2sRV2XjdN/W94MSEmBu/XYkOVGGFuv9sruvWKndinEedvxF3LA6jICk GrHFg5mP1LPrRtaM5lifraQe1YJc8aa9BIr7YWPKJ7jwzlYYxHGPuTCBLJSUvLmcYec0 48YO+Vuh0XtIl0Yo+hZjxcvPYpE5mRhaV41FSMOHmJUYX5VW9CP0mOyylYI4Lt7vqfwP MrJA== MIME-Version: 1.0 X-Received: by 10.66.220.227 with SMTP id pz3mr7402732pac.190.1361971903579; Wed, 27 Feb 2013 05:31:43 -0800 (PST) Received: by 10.68.33.132 with HTTP; Wed, 27 Feb 2013 05:31:43 -0800 (PST) Date: Wed, 27 Feb 2013 13:31:43 +0000 Message-ID: From: Abdussalam Baryun To: "Dowdell, John" Content-Type: multipart/alternative; boundary=047d7b5d49f481d1c104d6b4cb0d Cc: "manet@ietf.org" Subject: [manet] AODVv2 Optionals X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 13:31:46 -0000 --047d7b5d49f481d1c104d6b4cb0d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi John, I agree with that type of implement option, but I don't think it is different behavior but think different implementation. However, I agree if there is different behavior (not able to work together) to be out of the document in another refering to it. When I read optional (as Core+Option) in any MANET doc I understand that it does not affect the core if used together, am I right? I think both mandate and option are listen behavior and not different much, because don't affact if one of two aodvv2 routers in network having the optional, AB ++++++ Sub: Re: [manet] Why the WG Reactive Protocol to be Compatible with another= ? On Wed, Feb 27, 2013 at 11:01 AM, Dowdell, John wrote: > Well let=92s consider something in AODVv2 which is present in the curren= t > draft. It is mandatory for routers to multicast RREQ messages to a > nominated multicast address. However there is an option for routers to se= nd > by unicast to the next hop. I will not debate this topic here, you=92ll h= ave > to read the draft, but: > > > > Core =96 receiving routers MUST listen on a specified multicast address f= or > incoming RREQ messages > > Option =96 receiving router MAY listen for same message on its unicast > address. > > > > Thus the option is a different behaviour (or operation if you wish) from > the core specification. The implementation requires core functionality, > plus whichever options the implementer feels necessary to achieve their > objective. An implementation that does not listen on the Unicast address > for RREQs would not receive them, but could still claim compliance with t= he > specification. > > > > John > > > > > --047d7b5d49f481d1c104d6b4cb0d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi John,
=A0
I agree with that type of implement o= ption, but I don't think it is different behavior but think different i= mplementation. However, I agree if there is different behavior (not able to= work together)=A0to be out of the document in another refering to it. When= I read optional (as Core+Option)=A0in any MANET doc I understand that it d= oes not affect the core if used together, am I right?
=A0
I think both mandate and option are listen behavior and = not different much, because don't affact if one of two aodvv2 routers i= n network having the optional,
=A0
AB
++++++
Sub:= Re: [manet] Why the WG Reactive Protocol to be Compatible with another?
On Wed, Feb 27, 2013 at 11:01 AM, Dowdell, John = <John.Dowdell@cassidian.com> wrote:

Well let=92s consider something in AODVv2 which= is present in the current draft. It is mandatory for routers to multicast = RREQ messages to a nominated multicast address. However there is an option for routers to send by unicast to the next hop. I will not de= bate this topic here, you=92ll have to read the draft, but:

=A0

Core =96 receiving routers MUST listen on a spe= cified multicast address for incoming RREQ messages

Option =96 receiving router MAY listen for same= message on its unicast address.

=A0

Thus the option is a different behaviour (or op= eration if you wish) from the core specification. The implementation requir= es core functionality, plus whichever options the implementer feels necessary to achieve their objective. An implementation that does no= t listen on the Unicast address for RREQs would not receive them, but could= still claim compliance with the specification.

=A0

John

=A0

=A0

--047d7b5d49f481d1c104d6b4cb0d-- From Chris.Dearlove@baesystems.com Wed Feb 27 05:49:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B60F21F85B2 for ; Wed, 27 Feb 2013 05:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgGmXIIDT-1n for ; Wed, 27 Feb 2013 05:49:10 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4C61A21F85AF for ; Wed, 27 Feb 2013 05:49:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; d="scan'208";a="315243323" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Feb 2013 13:49:09 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r1RDn7MG010483 for ; Wed, 27 Feb 2013 13:49:08 GMT X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; d="scan'208";a="9189036" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 27 Feb 2013 13:49:07 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Wed, 27 Feb 2013 13:49:07 +0000 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-26.txt Thread-Index: AQHOE6x3GDD6ewCtmUCtsD24oBOkOZiLMuSAgAKHwmA= Date: Wed, 27 Feb 2013 13:49:07 +0000 Message-ID: References: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> <512BEF17.70605@computer.org> In-Reply-To: <512BEF17.70605@computer.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 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 13:49:11 -0000 I note that this version has removed Ian Chakeres from the author list, but= has not even put him into the acknowledgements section. I think that's a c= lear oversight. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C= harles E. Perkins Sent: 25 February 2013 23:09 To: manet@ietf.org Cc: Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello folks, draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts directories. The only problem is that it's got the wrong name, namely "draft-ietf-manet-dymo-26.txt" This is because it's now a week past the submission deadline for ...-00.txt initial drafts, and the submission tool would not allow me to upload it wit= h it's intended new name. This naming problem will be rectified at the earliest opportunity. Regards, Charlie P. On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group o= f the IETF. > > =09Title : Dynamic MANET On-demand (AODVv2) Routing > =09Author(s) : Charles E. Perkins > Stan Ratliff > John Dowdell > =09Filename : draft-ietf-manet-dymo-26.txt > =09Pages : 60 > =09Date : 2013-02-25 > > Abstract: > The revised Ad Hoc On-demand Distance Vector (AODVv2) routing > protocol is intended for use by mobile routers in wireless, multihop > networks. AODVv2 determines unicast routes among AODVv2 routers > within the network in an on-demand fashion, offering on-demand > convergence in dynamic topologies. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dymo > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-dymo-26 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26 > > > 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 > --=20 Regards, Charlie P. _______________________________________________ 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 sratliff@cisco.com Wed Feb 27 07:43:46 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6E921F85F3 for ; Wed, 27 Feb 2013 07:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYGFbrmjV038 for ; Wed, 27 Feb 2013 07:43:45 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDF121F85E7 for ; Wed, 27 Feb 2013 07:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4333; q=dns/txt; s=iport; t=1361979825; x=1363189425; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=V6KV1dWa1p8M4r4jIOMx7BnumFLtbhzYWjiEKnz2Pe4=; b=KpeKrugVDK8P8KB/ztG58Yo0T1Mf35jvoT6Xd/zrnLgH7isaHWrqDJ0A Dm1DAJaEGJ/KE5B/G1RZ0ZLndLuSp2nq0Wzwmn1me8RnhPjIQW3y+WC7w ye7ayxPAXhtT9eIMqlgL5MtFIb+qSVkQotjxyGtpcEMTFIvqSXrx9dX5h 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAKgoLlGtJV2c/2dsb2JhbABFg3i+H3kWc4IfAQEBAwEBAQFSGQMIBQcEAgEIEQQBAQEKHQcnCxQJCAIEDgUIAYgEBgcFvmuNQwoOgQYCJgsHBoJZYQOINI8rj0yDCIFpCRce X-IronPort-AV: E=Sophos;i="4.84,747,1355097600"; d="scan'208";a="178804264" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 27 Feb 2013 15:43:44 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1RFhhEW005108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Feb 2013 15:43:43 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 09:43:43 -0600 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dymo-26.txt Thread-Index: AQHOE6w7i+LASsPLf0qDcuOWqiGXKpiLl3qAgAKIL4CAACADAA== Date: Wed, 27 Feb 2013 15:43:43 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10038039@xmb-aln-x03.cisco.com> References: <20130225230139.27967.46575.idtracker@ietfa.amsl.com> <512BEF17.70605@computer.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.34.217] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4FD47A577AA09349AE2A1F00CD78BFFA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:43:46 -0000 Chris,=20 Good catch. Thanks. It will be corrected in the next spin. Regards, Stan On Feb 27, 2013, at 8:49 AM, Dearlove, Christopher (UK) wrote: > I note that this version has removed Ian Chakeres from the author list, b= ut has not even put him into the acknowledgements section. I think that's a= clear oversight. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Charles E. Perkins > Sent: 25 February 2013 23:09 > To: manet@ietf.org > Cc: Stan Ratliff > Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-26.txt >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Hello folks, >=20 > draft-ietf-manet-aodvv2-00.txt has been submitted to the Internet Drafts > directories. The only problem is that it's got the wrong name, namely > "draft-ietf-manet-dymo-26.txt" >=20 > This is because it's now a week past the submission deadline for ...-00.t= xt > initial drafts, and the submission tool would not allow me to upload it w= ith > it's intended new name. >=20 > This naming problem will be rectified at the earliest opportunity. >=20 > Regards, > Charlie P. >=20 >=20 >=20 > On 2/25/2013 3:01 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Mobile Ad-hoc Networks Working Group o= f the IETF. >>=20 >> Title : Dynamic MANET On-demand (AODVv2) Routing >> Author(s) : Charles E. Perkins >> Stan Ratliff >> John Dowdell >> Filename : draft-ietf-manet-dymo-26.txt >> Pages : 60 >> Date : 2013-02-25 >>=20 >> Abstract: >> The revised Ad Hoc On-demand Distance Vector (AODVv2) routing >> protocol is intended for use by mobile routers in wireless, multihop >> networks. AODVv2 determines unicast routes among AODVv2 routers >> within the network in an on-demand fashion, offering on-demand >> convergence in dynamic topologies. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-dymo >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-manet-dymo-26 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dymo-26 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 From adrian@olddog.co.uk Thu Feb 28 09:44:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E07D21F8C0C for ; Thu, 28 Feb 2013 09:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXY3GOMntoJr for ; Thu, 28 Feb 2013 09:44:29 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 72C0021F8C08 for ; Thu, 28 Feb 2013 09:44:17 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1SHiAi3000726; Thu, 28 Feb 2013 17:44:10 GMT Received: from 950129200 (089144192249.atnat0001.highway.a1.net [89.144.192.249]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1SHi7st000703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Feb 2013 17:44:08 GMT From: "Adrian Farrel" To: References: <20130226132309.97678B1E006@rfc-editor.org> In-Reply-To: Date: Thu, 28 Feb 2013 17:44:09 -0000 Message-ID: <007101ce15db$37fd2080$a7f76180$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01CE15DB.3800F110" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHEkYAddi4PNnYjAc25anqyC5AbmgJlb4rMmI9eKjA= Content-Language: en-gb Cc: elloyd@udel.edu, macker@itd.nrl.navy.mil, sratliff@cisco.com Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 17:44:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0072_01CE15DB.3800F110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi working group, I am trying to understand the status of Appendix B in 6621. I interpret it as a normative definition of an algorithm that is a suggested algorithm that could be used. I agree that all of these changes are of the nature of errata fixes of a technical nature. That is, they are editorial errors that make the technical content debatable or unclear. It sounds to me that there is general agreement that the changes are good. Thanks, Adrian From: Justin Dean [mailto:bebemaster@gmail.com] Sent: 26 February 2013 15:21 To: RFC Errata System Cc: macker@itd.nrl.navy.mil; stbryant@cisco.com; adrian@olddog.co.uk; sratliff@cisco.com; elloyd@udel.edu; manet@ietf.org Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) Thank you for finding and posting the errata. The errata fixes an error and I approve of the change. I would like to encourage others to look over the psuedo code and verify the correctness of the fix and correctness in general. Lets measure twice and cut once. Justin Notes ----- There are three changes: On line 7, the first and second occurrences of x are replaced by w, and then x is given as the name of the sole member of N1(w). On line 7B, the phrase 'delete "N1(z)" is dropped to be consistent with the rest of the algorithm. On line 8 some rewording is done for clarification. This errata prepared in consultation with Justin Dean and Gus Macker. Instructions: ------------- This errata 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. -------------------------------------- RFC6621 (draft-ietf-manet-smf-14) -------------------------------------- Title : Simplified Multicast Forwarding Publication Date : May 2012 Author(s) : J. Macker, Ed. Category : EXPERIMENTAL Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ------=_NextPart_000_0072_01CE15DB.3800F110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi working = group,

 

I am trying to understand the = status of Appendix B in 6621.

I interpret it as a normative = definition of an algorithm that is a suggested algorithm that could be = used.

 

I agree that all of these = changes are of the nature of errata fixes of a technical nature. That = is, they are editorial errors that make the technical content debatable = or unclear.

 

It sounds to me that there is = general agreement that the changes are good.

 

Thanks,

Adrian

 

 

From: Justin Dean = [mailto:bebemaster@gmail.com]
Sent: 26 February 2013 = 15:21
To: RFC Errata System
Cc: = macker@itd.nrl.navy.mil; stbryant@cisco.com; adrian@olddog.co.uk; = sratliff@cisco.com; elloyd@udel.edu; manet@ietf.org
Subject: = Re: [manet] [Technical Errata Reported] RFC6621 = (3499)

 

Thank you for finding and posting the = errata.  The errata fixes an error and I approve of the = change.  I would like to encourage others to look over the psuedo = code and verify the correctness of the fix and correctness in general. = Lets measure twice and cut = once.

Justin

Notes
-----
There are three changes:

On = line 7, the first and second occurrences of x are replaced by w, and = then x is given as the name of the sole member of N1(w).

On line = 7B, the phrase 'delete "N1(z)" is dropped to be consistent = with the rest of the algorithm.

On line 8 some rewording is done = for clarification.

This errata prepared in consultation with = Justin Dean and Gus = Macker.

Instructions:
-------------
This errata 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.

--------------------------------------
RFC6621 = (draft-ietf-manet-smf-14)
--------------------------------------
Ti= tle               : Simplified = Multicast Forwarding
Publication Date    : May = 2012
Author(s)           : J. Macker, = Ed.
Category            : = EXPERIMENTAL
Source              : = Mobile Ad-hoc Networks
Area             =    : Routing
Stream           =    : IETF
Verifying Party     : = IESG
_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

 

------=_NextPart_000_0072_01CE15DB.3800F110-- From thomas@thomasclausen.org Thu Feb 28 10:12:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC7C21F8C0C for ; Thu, 28 Feb 2013 10:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubsy9vZoCh1K for ; Thu, 28 Feb 2013 10:12:44 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD9421F8B9C for ; Thu, 28 Feb 2013 10:12:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 1A5B51603BB; Thu, 28 Feb 2013 10:12:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.115] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 503AB1603BA; Thu, 28 Feb 2013 10:12:42 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_88B94917-AD46-44DE-AF81-53CE7A3767DA" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Thomas Heide Clausen In-Reply-To: <007101ce15db$37fd2080$a7f76180$@olddog.co.uk> Date: Thu, 28 Feb 2013 19:12:41 +0100 Message-Id: References: <20130226132309.97678B1E006@rfc-editor.org> <007101ce15db$37fd2080$a7f76180$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1499) Cc: elloyd@udel.edu, manet@ietf.org, macker@itd.nrl.navy.mil, sratliff@cisco.com Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 18:12:45 -0000 --Apple-Mail=_88B94917-AD46-44DE-AF81-53CE7A3767DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Having looked at the errata in some detail, and on my implementation of = that bit of 6621, I note (with smug self-satisfaction?) that I'd = implemented what the errata recommends, even though my code was based on = the original specification. I therefore agree with Justin that it's an error that should be fixed - = and with Adrian that it's more of an editorial error, and certainly not = a change of an algorithm. Thomas On Feb 28, 2013, at 18:44 , "Adrian Farrel" wrote: > Hi working group, > =20 > I am trying to understand the status of Appendix B in 6621. > I interpret it as a normative definition of an algorithm that is a = suggested algorithm that could be used. > =20 > I agree that all of these changes are of the nature of errata fixes of = a technical nature. That is, they are editorial errors that make the = technical content debatable or unclear. > =20 > It sounds to me that there is general agreement that the changes are = good. > =20 > Thanks, > Adrian > =20 > =20 > From: Justin Dean [mailto:bebemaster@gmail.com]=20 > Sent: 26 February 2013 15:21 > To: RFC Errata System > Cc: macker@itd.nrl.navy.mil; stbryant@cisco.com; adrian@olddog.co.uk; = sratliff@cisco.com; elloyd@udel.edu;manet@ietf.org > Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) > =20 > Thank you for finding and posting the errata. The errata fixes an = error and I approve of the change. I would like to encourage others to = look over the psuedo code and verify the correctness of the fix and = correctness in general. Lets measure twice and cut once. >=20 > Justin >=20 > Notes > ----- > There are three changes: >=20 > On line 7, the first and second occurrences of x are replaced by w, = and then x is given as the name of the sole member of N1(w). >=20 > On line 7B, the phrase 'delete "N1(z)" is dropped to be consistent = with the rest of the algorithm. >=20 > On line 8 some rewording is done for clarification. >=20 > This errata prepared in consultation with Justin Dean and Gus Macker. >=20 > Instructions: > ------------- > This errata 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. >=20 > -------------------------------------- > RFC6621 (draft-ietf-manet-smf-14) > -------------------------------------- > Title : Simplified Multicast Forwarding > Publication Date : May 2012 > Author(s) : J. Macker, Ed. > Category : EXPERIMENTAL > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > 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=_88B94917-AD46-44DE-AF81-53CE7A3767DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Having looked at the errata in = some detail, and on my implementation of that bit of 6621, I note (with = smug self-satisfaction?) that I'd implemented what the errata = recommends, even though my code was based on the original = specification.

I therefore agree with Justin that = it's an error that should be fixed - and with Adrian that it's more of = an editorial error, and certainly not a change of an = algorithm.

Thomas

On = Feb 28, 2013, at 18:44 , "Adrian Farrel" <adrian@olddog.co.uk> = wrote:

Hi working = group,
 
I am trying to understand the status of = Appendix B in 6621.
I interpret it as a normative definition of = an algorithm that is a suggested algorithm that could be = used.
 
I agree that all of these changes are of the = nature of errata fixes of a technical nature. That is, they are = editorial errors that make the technical content debatable or = unclear.
 
It sounds to me that there is general = agreement that the changes are good.
 
Adrian
 
From: Justin Dean = [mailto:bebemaster@gmail.com] 
Sent: 26 February 2013 = 15:21
To: RFC = Errata System
Cc: macker@itd.nrl.navy.mil; stbryant@cisco.com; adrian@olddog.co.uk; sratliff@cisco.com; elloyd@udel.edu; Re: [manet] [Technical = Errata Reported] RFC6621 (3499)

Thank you for finding and posting the errata.  The = errata fixes an error and I approve of the change.  I would like to = encourage others to look over the psuedo code and verify the correctness = of the fix and correctness in general. Lets measure twice and cut = once.

Justin

Notes
-----
There = are three changes:

On line 7, the first and second occurrences of = x are replaced by w, and then x is given as the name of the sole member = of N1(w).

On line 7B, the phrase 'delete "N1(z)" is dropped to be = consistent with the rest of the algorithm.

On line 8 some = rewording is done for clarification.

This errata prepared in = consultation with Justin Dean and Gus = Macker.

Instructions:
-------------
This errata 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.

--------------------------------------
RFC6621 = (draft-ietf-manet-smf-14)
--------------------------------------
Tit= le               : Simplified = Multicast Forwarding
Publication Date    : May = 2012
Author(s)           : J. Macker, = Ed.
Category            : = EXPERIMENTAL
Source              : = Mobile Ad-hoc Networks
Area             =    : Routing
Stream           =    : IETF
Verifying Party     : = IESG
_______________________________________________
manet mailing = list
manet@ietf.org
rest > of the algorithm. > > On line 8 some rewording is done for clarification. > > This errata prepared in consultation with Justin Dean and Gus Macker. > > Instructions: > ------------- > This errata 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. > > -------------------------------------- > RFC6621 (draft-ietf-manet-smf-14) > -------------------------------------- > Title : Simplified Multicast Forwarding > Publication Date : May 2012 > Author(s) : J. Macker, Ed. > Category : EXPERIMENTAL > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > From abdussalambaryun@gmail.com Thu Feb 28 13:49:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0702121F8AD8 for ; Thu, 28 Feb 2013 13:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v72EfkbAzi+A for ; Thu, 28 Feb 2013 13:49:11 -0800 (PST) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id 42BF421F892C for ; Thu, 28 Feb 2013 13:49:11 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id up1so1297740pbc.23 for ; Thu, 28 Feb 2013 13:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bQ9ZugBvQ3Owqidb5T1awi80jm9nYHILy1GeKDvhrt8=; b=rvohEf/LQk0C+0W9J9cqviBpVTIvT365bQkgNLY6yZdDb6Qb6Yia6ai/idUZuWwvDG lTAFLLQdzmi9YFrFDS3SHKjFMHqXkDekWstuHXwo6NATfg+dw0oSywT4eiznrLacFJu0 A5xA6v95bJ6x8R4o4Tz87Q+xvDfbbnJkKPIkt61JjV9nxj5NlDZk6MH5ZGDEHBAcs+TJ Twg6jI75t74OiyyRi99vq9b4PPdjvvCvuvvK1uLuQ0Pyuo5gkr66dB5NqPOp7VX0wLc3 bgT9cyh+giM16vY6HOdFrZFvdh2A5s2lPiRoCTbCIdiOgFI25SpkgU0gxqkO+NRNeERV umNg== MIME-Version: 1.0 X-Received: by 10.66.158.2 with SMTP id wq2mr15376940pab.113.1362088151006; Thu, 28 Feb 2013 13:49:11 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 28 Feb 2013 13:49:10 -0800 (PST) In-Reply-To: References: <20130226132309.97678B1E006@rfc-editor.org> <007101ce15db$37fd2080$a7f76180$@olddog.co.uk> Date: Thu, 28 Feb 2013 22:49:10 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: elloyd@udel.edu, manet@ietf.org, macker@itd.nrl.navy.mil, sratliff@cisco.com Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 21:49:12 -0000 On 2/28/13, Thomas Heide Clausen wrote: > Having looked at the errata in some detail, and on my implementation of that > bit of 6621, I note (with smug self-satisfaction?) that I'd implemented what > the errata recommends, even though my code was based on the original > specification. > > I therefore agree with Justin that it's an error that should be fixed - and > with Adrian that it's more of an editorial error, and certainly not a change > of an algorithm. There are many ways to fix errors is errata the only way of fixing errors in IETF, AB > > Thomas > > On Feb 28, 2013, at 18:44 , "Adrian Farrel" wrote: > >> Hi working group, >> >> I am trying to understand the status of Appendix B in 6621. >> I interpret it as a normative definition of an algorithm that is a >> suggested algorithm that could be used. >> >> I agree that all of these changes are of the nature of errata fixes of a >> technical nature. That is, they are editorial errors that make the >> technical content debatable or unclear. >> >> It sounds to me that there is general agreement that the changes are >> good. >> >> Thanks, >> Adrian >> >> >> From: Justin Dean [mailto:bebemaster@gmail.com] >> Sent: 26 February 2013 15:21 >> To: RFC Errata System >> Cc: macker@itd.nrl.navy.mil; stbryant@cisco.com; adrian@olddog.co.uk; >> sratliff@cisco.com; elloyd@udel.edu;manet@ietf.org >> Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) >> >> Thank you for finding and posting the errata. The errata fixes an error >> and I approve of the change. I would like to encourage others to look >> over the psuedo code and verify the correctness of the fix and correctness >> in general. Lets measure twice and cut once. >> >> Justin >> >> Notes >> ----- >> There are three changes: >> >> On line 7, the first and second occurrences of x are replaced by w, and >> then x is given as the name of the sole member of N1(w). >> >> On line 7B, the phrase 'delete "N1(z)" is dropped to be consistent with >> the rest of the algorithm. >> >> On line 8 some rewording is done for clarification. >> >> This errata prepared in consultation with Justin Dean and Gus Macker. >> >> Instructions: >> ------------- >> This errata 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. >> >> -------------------------------------- >> RFC6621 (draft-ietf-manet-smf-14) >> -------------------------------------- >> Title : Simplified Multicast Forwarding >> Publication Date : May 2012 >> Author(s) : J. Macker, Ed. >> Category : EXPERIMENTAL >> Source : Mobile Ad-hoc Networks >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> 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 joseph.macker@nrl.navy.mil Thu Feb 28 16:41:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E3E21F8B8F for ; Thu, 28 Feb 2013 16:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=1.367, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zd90FtrfYN4 for ; Thu, 28 Feb 2013 16:41:12 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) by ietfa.amsl.com (Postfix) with ESMTP id 9255521F84F0 for ; Thu, 28 Feb 2013 16:41:11 -0800 (PST) Received: from vpn217206.nrl.navy.mil (vpn217206.nrl.navy.mil [132.250.217.206]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id r210f8QW023529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2013 19:41:09 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Macker In-Reply-To: Date: Thu, 28 Feb 2013 19:41:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130226132309.97678B1E006@rfc-editor.org> <007101ce15db$37fd2080$a7f76180$@olddog.co.uk> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1499) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Cc: elloyd@udel.edu, manet@ietf.org, macker@itd.nrl.navy.mil, sratliff@cisco.com Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 00:41:13 -0000 Thomas: Thanks its good to have an OLSR-MPR community double-check of Appendix B = as our running prototype uses App A more typically. The intention to = have the suggested algorithm pseudocode in the Appendices and in this = case it was an editorial error .=20 -Joe On Feb 28, 2013, at 1:12 PM, Thomas Heide Clausen = wrote: > Having looked at the errata in some detail, and on my implementation = of that bit of 6621, I note (with smug self-satisfaction?) that I'd = implemented what the errata recommends, even though my code was based on = the original specification. >=20 > I therefore agree with Justin that it's an error that should be fixed = - and with Adrian that it's more of an editorial error, and certainly = not a change of an algorithm. >=20 > Thomas >=20 > On Feb 28, 2013, at 18:44 , "Adrian Farrel" = wrote: >=20 >> Hi working group, >> =20 >> I am trying to understand the status of Appendix B in 6621. >> I interpret it as a normative definition of an algorithm that is a = suggested algorithm that could be used. >> =20 >> I agree that all of these changes are of the nature of errata fixes = of a technical nature. That is, they are editorial errors that make the = technical content debatable or unclear. >> =20 >> It sounds to me that there is general agreement that the changes are = good. >> =20 >> Thanks, >> Adrian >> =20 >> =20 >> From: Justin Dean [mailto:bebemaster@gmail.com]=20 >> Sent: 26 February 2013 15:21 >> To: RFC Errata System >> Cc: macker@itd.nrl.navy.mil; stbryant@cisco.com; adrian@olddog.co.uk; = sratliff@cisco.com; elloyd@udel.edu;manet@ietf.org >> Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) >> =20 >> Thank you for finding and posting the errata. The errata fixes an = error and I approve of the change. I would like to encourage others to = look over the psuedo code and verify the correctness of the fix and = correctness in general. Lets measure twice and cut once. >>=20 >> Justin >>=20 >> Notes >> ----- >> There are three changes: >>=20 >> On line 7, the first and second occurrences of x are replaced by w, = and then x is given as the name of the sole member of N1(w). >>=20 >> On line 7B, the phrase 'delete "N1(z)" is dropped to be consistent = with the rest of the algorithm. >>=20 >> On line 8 some rewording is done for clarification. >>=20 >> This errata prepared in consultation with Justin Dean and Gus Macker. >>=20 >> Instructions: >> ------------- >> This errata 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. >>=20 >> -------------------------------------- >> RFC6621 (draft-ietf-manet-smf-14) >> -------------------------------------- >> Title : Simplified Multicast Forwarding >> Publication Date : May 2012 >> Author(s) : J. Macker, Ed. >> Category : EXPERIMENTAL >> Source : Mobile Ad-hoc Networks >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> =20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From abdussalambaryun@gmail.com Thu Feb 28 19:18:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2D121F886A for ; Thu, 28 Feb 2013 19:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRCRS2OjnlWB for ; Thu, 28 Feb 2013 19:18:34 -0800 (PST) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 857BB21F8585 for ; Thu, 28 Feb 2013 19:18:34 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id ro8so1469121pbb.4 for ; Thu, 28 Feb 2013 19:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=H0GX3QpJcWNdfsf/GEs1q6ObUthceL2eQiBCQ4X0Oww=; b=ggq/zbXdVnJj9uI4N+87BpIb2B+v9BQrR1n84DOESN7ITt3DS1BK7QLCe7SEha5+XJ ItlONm66p6WsVoUakTpqYVn//3uLEnUZ1mFaq0PXEth40A1NljbfZOg5vMjjylubvZbW uvLv9o8+WGMmNDX8sARJBNH9OhrnNyQSrdYM2ob/0u1dbFlWo6EvvHQoTmQaWxkNGkuB jHeNbbeFHo9Gq/Kg3u0DxSR9NvzhjGBVLgoU0IPmCLT3G11j1FLo1myn2IOENSmDkORa uZEqEKUGI/oG9JXQTsebNvuchXwvoS6IPN7nscY54GGVXXo0F80uuqfRa/0nxTYfeLAh aYpw== MIME-Version: 1.0 X-Received: by 10.66.13.74 with SMTP id f10mr16654116pac.202.1362107914277; Thu, 28 Feb 2013 19:18:34 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 28 Feb 2013 19:18:33 -0800 (PST) In-Reply-To: <20130226132309.97678B1E006@rfc-editor.org> References: <20130226132309.97678B1E006@rfc-editor.org> Date: Fri, 1 Mar 2013 04:18:33 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: elloyd@udel.edu, macker@itd.nrl.navy.mil, sratliff@cisco.com Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 03:18:37 -0000 The *x* in the line 7 is different to others, it was interface, then became memebr of an interface, AB>edit> replace *x* in 7 to *n* (still not complete the review check of RFC6621, this thread does not include a last date for review) AB On 2/26/13, RFC Errata System wrote: > > The following errata report has been submitted for RFC6621, > "Simplified Multicast Forwarding". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6621&eid=3499 > > -------------------------------------- > Type: Technical > Reported by: Errol Lloyd > > Section: B.4. > > Original Text > ------------- > 1. Initialize the set "MPR" to empty. > > 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". > > 3. Initialize the set "N2" to include all 2-hop neighbors, excluding > "n0" and any routers in "N1". Nodes that are only reachable via > "N1" routers with router priority values of NEVER are also > excluded. > > 4. For each interface "y" in "N1", initialize a set "N2(y)" to > include any interfaces in "N2" that are 1-hop neighbors of "y". > > 5. For each interface "x" in "N1" with a router priority value of > "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". > > 6. For each interface "z" in "N2", initialize the set "N1(z)" to > include any interfaces in "N1" that are 1-hop neighbors of "z". > > 7. For each interface "x" in "N2" where "N1(x)" has only one member, > select "x" as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2" and > delete "N1(z)". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". > > 8. While "N2" is not empty, select the interface "x" in "N1" with > the largest router priority that has the number of members in > "N_2(x)" as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". > > > > > > Corrected Text > -------------- > 1. Initialize the set "MPR" to empty. > > 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". > > 3. Initialize the set "N2" to include all 2-hop neighbors, excluding > "n0" and any routers in "N1". Nodes that are only reachable via > "N1" routers with router priority values of NEVER are also > excluded. > > 4. For each interface "y" in "N1", initialize a set "N2(y)" to > include any interfaces in "N2" that are 1-hop neighbors of "y". > > 5. For each interface "x" in "N1" with a router priority value of > "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". > > 6. For each interface "z" in "N2", initialize the set "N1(z)" to > include any interfaces in "N1" that are 1-hop neighbors of "z". > > 7. For each interface "w" in "N2" where "N1(w)" has only one member, > "x", > select "x" as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". > > 8. While "N2" is not empty, select the interface "x" in "N1" with > the highest router priority [break ties in favor of the node with the > > largest number of members in "N_2(x)"] as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". > > > > > > Notes > ----- > There are three changes: > > On line 7, the first and second occurrences of x are replaced by w, and then > x is given as the name of the sole member of N1(w). > > On line 7B, the phrase 'delete "N1(z)" is dropped to be consistent with the > rest of the algorithm. > > On line 8 some rewording is done for clarification. > > This errata prepared in consultation with Justin Dean and Gus Macker. > > Instructions: > ------------- > This errata 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. > > -------------------------------------- > RFC6621 (draft-ietf-manet-smf-14) > -------------------------------------- > Title : Simplified Multicast Forwarding > Publication Date : May 2012 > Author(s) : J. Macker, Ed. > Category : EXPERIMENTAL > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Thu Feb 28 20:42:42 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D871721F89CB for ; Thu, 28 Feb 2013 20:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMuVzGIWeToJ for ; Thu, 28 Feb 2013 20:42:42 -0800 (PST) Received: from mail-da0-f52.google.com (mail-da0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5E85221F8992 for ; Thu, 28 Feb 2013 20:42:42 -0800 (PST) Received: by mail-da0-f52.google.com with SMTP id x33so1199064dad.25 for ; Thu, 28 Feb 2013 20:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5qbNEtcVOM0WaDTZDdVJEpx9c5pjqJQp1pcOM1h1+hk=; b=hRvXtBbfXsIBykNbV6La7iOAurJcmD3ww/J8QB1rpoGx4XWaW/k0Br0CkoYANRoxzl ohZaS0DLflfw7OEMjNFZmPA6RQ3CnIrYI5mqxesF3oxaSoYABn3KTNqkKYC+4lRkwUaP y5YxSmUBdU5W7BieQNaWagIcs6fQ/GtS0bMgQABWxNsJD/rKlULZ5gFnH2vFUM+vKIPo R6Y3DVjewBSJxAyK8QcN43TgNIlvC2M4f6quX2LEbFkeHBB9AUC+PdRTYJ/ln+FNsjJP umF2IRbr9FTyBx45ioolGXt86Cn5Vey8qdnvN/9IFACHy4aiAkfNM96h7Bu7Ux7ubd3B YjRA== MIME-Version: 1.0 X-Received: by 10.67.5.193 with SMTP id co1mr16932524pad.6.1362112962087; Thu, 28 Feb 2013 20:42:42 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 28 Feb 2013 20:42:41 -0800 (PST) In-Reply-To: <20130226132309.97678B1E006@rfc-editor.org> References: <20130226132309.97678B1E006@rfc-editor.org> Date: Fri, 1 Mar 2013 05:42:41 +0100 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: elloyd@udel.edu, sratliff@cisco.com, macker@itd.nrl.navy.mil, RFC Errata System Subject: Re: [manet] [Technical Errata Reported] RFC6621 (3499) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 04:42:43 -0000 > 7. For each interface "w" in "N2" where "N1(w)" has only one member, > "x", > select "x" as an MPR: > > A. Add "x" to the set "MPR" and remove "x" from "N1". > > B. For each interface "z" in "N2(x)", remove "z" from "N2". > > C. For each interface "y" in "N1", remove any interfaces in > "N2(x)" from "N2(y)". AB>edit> 7. For each interface "w" in "N2" where "N1(w)" has only one member, "n", select "n" as an MPR: A. Add "n" to the set "MPR" and remove "n" from "N1". B. For each interface "z" in "N2(w)", remove "z" from "N2". C. For each interface "y" in "N1", remove all interfaces in "N2(w)" from "N2(y)". In your errata proposal for the point 7-C please advise do you mean *any* or *ALL*, because any may mean one only but all is a must for all that are in N2(w) to be removed. I think you mean all, Please discuss, or advise, AB From abdussalambaryun@gmail.com Thu Feb 28 22:51:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B4821F8A3F for ; Thu, 28 Feb 2013 22:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wE0q+uy5xn7V for ; Thu, 28 Feb 2013 22:51:32 -0800 (PST) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9F021F886B for ; Thu, 28 Feb 2013 22:51:32 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id wy12so1550458pbc.21 for ; Thu, 28 Feb 2013 22:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=HRB6OKFCNj0yJdmYTd/egpF/CZAV9d8pvFzQayDGU+0=; b=IJCb37CCss5KlNw6O+HgR8JHEr2s23Dc5cX9KGTQZpfYuAYKLhAde9iQDEKvW9fIss EBjLLVdN8eaF9aji83HYxlkeWmr7TdKPhWGZ/QPeISQ7/TXlM+LjFPv8OX9IwLMx31Vg R+phb/n/u7unFoTLyRYQdjn+ZK1bVnRDVoJ4/VnmVbJXp6eyZnVis6CuSX8FrIegohxu USOMpdyo5Kb/gi0E1SspmMafotRafkuT0Y7L+NL9mLYtDlIwsx1aebJAtPo3tT2KNI7L voAqavtI0+vKnF+8hrrIKBrHk6CnDamr6WWfXrOCzOgeatMzXl9bvgrJtzCAsENwVQJh EkAA== MIME-Version: 1.0 X-Received: by 10.68.138.170 with SMTP id qr10mr12945603pbb.190.1362120691981; Thu, 28 Feb 2013 22:51:31 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 28 Feb 2013 22:51:31 -0800 (PST) In-Reply-To: <066.1f1dc1e7a958c726a83d410656ac5449@trac.tools.ietf.org> References: <066.1f1dc1e7a958c726a83d410656ac5449@trac.tools.ietf.org> Date: Fri, 1 Mar 2013 07:51:31 +0100 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] #18: NHDP Sequence Number Threat X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:51:33 -0000 I think as related to this ticket about NHDP-interface sequence number, three errata (two technical and one editorials) were posted later [1] [2] [3]. If we change RFC5444 related to interfaces info, then we will need to change RFC6130. Why it was it not mentioned the packet sequence number maintained in RFC6130-NHDP and how, or why not as NHDP sequence number? I may need to prapare an update about NHDP information which is different from threats of NHDP. [1] http://www.ietf.org/mail-archive/web/manet/current/msg15025.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg15026.html [3] http://www.ietf.org/mail-archive/web/manet/current/msg15058.html AB On Mon, Feb 25, 2013 at 7:40 AM, manet issue tracker < trac+manet@trac.tools.ietf.org> wrote: > #18: NHDP Sequence Number Threat > > I don't know how the sequence number section was ignored/deleted in the > updated draft but would like to advise to include as per the below input > discussions. > > http://www.ietf.org/mail-archive/web/manet/current/msg13286.html > > http://www.ietf.org/mail-archive/web/manet/current/msg15004.html > > http://www.ietf.org/mail-archive/web/manet/current/msg15006.html > > The attack to sequence number of packets/messages may make changes into > NHDP and routing. If you disagree please discuss, > > Regards > AB > > -- > ----------------------------------------+------------------------------- > Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun > Type: enhancement | Status: new > Priority: major | Milestone: milestone1 > Component: nhdp-sec-threats | Version: 1.0 > Severity: In WG Last Call | Keywords: NHDP > ----------------------------------------+------------------------------- > > Ticket URL: > manet > > From abdussalambaryun@gmail.com Thu Feb 28 23:07:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA23C21F859D for ; Thu, 28 Feb 2013 23:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh7rlyyvVB7k for ; Thu, 28 Feb 2013 23:07:57 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1F59921F8566 for ; Thu, 28 Feb 2013 23:07:57 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md12so1574689pbc.2 for ; Thu, 28 Feb 2013 23:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tp+YvO/LqdSwGIGxq3LS0so4tF0lIJuX188pAVQvfSQ=; b=SpoDPcjjNtPTtfna/PPDE0Li5KkJHDRqevNvc2rTEEgg4plqM/B0UKgmIzj4p4TToY 0jvS+HOep6BOH8rF5L+eSGFvauwppjfRejGBa1rIt62WarALF0BBgDLNAn9jfSuw1Q7H 7GP5sQU4TSQHmvOk93m4tp4v1DvY8TXqAtRdyaTDwPwaYBpcFkenq1FbJHr1HtnDxSk5 Ma4di752/GFX8RewYtwjNIxu5SCjEMb8AYhA/cWgxy81aKIWbctYUrfZ6iZL8eK52dOw M+9nENfmPzKKhQsArf891km9oU1+/AUkXMyCzhfIKREfAqQnSjF7i1QVIRg40M6KRdpg rR/Q== MIME-Version: 1.0 X-Received: by 10.67.5.193 with SMTP id co1mr17398848pad.6.1362121672819; Thu, 28 Feb 2013 23:07:52 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 28 Feb 2013 23:07:52 -0800 (PST) In-Reply-To: <20130225151705.EB129B1E008@rfc-editor.org> References: <20130225151705.EB129B1E008@rfc-editor.org> Date: Fri, 1 Mar 2013 08:07:52 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: chris.dearlove@baesystems.com Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 07:07:58 -0000 I think errata suitable for editorials not serious technical change, I think I will need to review the RFC5444 and RFC6130 to make sure all consistent, comments below, Questions for discussion below, AB > Corrected Text > -------------- > o The field, if present, contains a sequence number > that SHOULD be maintained for each participating interface and > incremented by 1 for each packet generated by a node for that > interface. The sequence number after 65535 is 0. In other words, > the sequence number "wraps" in the usual way. > what you mean by *participating interface* do you mean NHDP-RFC6130, how does the interface maintain such number? is there an answer in any MANET doc? > > Notes > ----- > Packet sequence number should be per interface, not per node. Uses that > recognise missing packet sequence numbers only work in the corrected > (intended) case. Why you say SHOULD not MUST, or RECOMMENDED, please advise, AB
On Tue, Feb 26, 2013 at 4:27 PM, Daniel He <drdanhe@gmail.com> wrote:
That's not true. If you so called input is just as noise if they are no= t technical relevant.
it wastes my time and my mailbox storage. I think = most of other mailing list users
will feel it as I felt.

Comments= are most welcome if the comments are relevant.if the comments are technica= l and critical. Comments should not be a "remind". you should not= speak
for the others. for example, " There was a input of John which I refer= ed to in the ticket,". you speak for yourself!!
<= div class=3D"h5">




On 26 Febru= ary 2013 16:16, Abdussalam Baryun <abdussalambaryun@gmail.com= > wrote:
No one have right to try to discourage inputs, discus= sions are what this list=A0is for. I know that editors don't like comme= nts, but they have to live with it. For others that don't author work, = please just do your job (not to comment on numbers of posts/input, or time = spend)=A0or keep quite,
=A0
AB

On Tue, Feb 2= 6, 2013 at 4:10 PM, Daniel He <drdanhe@gmail.com> wrote:
=
It is no good to discuss on the mailing list if it is not technical relevan= t. Otherwise, we received too many useless emails without any technical inf= ormation. It is not a BBS
website.



On 26 February 2013 16:00, Abdussalam Baryun <abdussalambaryun@g= mail.com> wrote:
There is no harm in discussing, issues related to NHDP or RFC5444, or = erratas,=A0even after they were publish as we all know they are Request For= Comments,
=A0
AB

On Tue, Feb 26, 2013 at 3:57 PM, Dearlove, Christopher (UK) <C= hris.Dearlove@baesystems.com> wrote:

NHDP has made it to = RFC, and OLSRv2 has made it to one AD short of RFC - and not for any relate= d reason - without anyone thinking "we really should use that because it might be there - though it also might not". Which suggests= your technical answer is wrong. And anyway, procedurally it's multiple= steps too late.

=A0

--

Christopher Dearlove=

Senior Principal Eng= ineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesy= stems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=A0

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 26 February 2013 15:50
To: Thomas Heide Clausen
Cc: manet@ietf.o= rg


Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)

=A0

=A0

*** WARNING ***<= /span>

This message originates from outside our= organisation, either from an external partner or the internet.<= i>
Kee= p this in mind if you answer this message.
Ple= ase see this process on how to deal with suspicious emails.

On Tue, Feb 26, 2013 at 3:13 PM, Thomas Heide Clause= n <thomas@= thomasclausen.org> wrote:

=A0

On 26 f=E9vr. 2013, at = 16:00, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I like that protocols use the packet sequence number= , if thoes protocols you refered to don't use the packet SQN, then I re= commend they reconsider.

=A0

Why?

=A0

"Like" is not a technical argument.=

=A0=

=A0

I agree that it not a technical word, but also agree= that *like*=A0can be used in technical volunteer discussions. For example;= Why OLSRv2 protocol does not use the packet sequence number SQN? does it a= ccept random packets and ignore to sense=A0sequence packets? Why the designers like it to be that way? Why does AB like protoc= ols to sense SQN?

=A0

My technical answer is better if it got into a techn= ical draft, however, if a protocol senses the SQN it will be more rebust an= d more organised in=A0MANET communication.

=A0

AB


********************************************************************
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
h= ttps://www.ietf.org/mailman/listinfo/manet




--
Dan He
------------------= ---
openstack contributor
GPU stream programming

http:/= /wiki.openstack.org/Contributors

Tel: +44-788-686-3428




--
Dan He
-------------= --------
openstack contributor
GPU stream programming

http://wiki.o= penstack.org/Contributors

Tel: +44-788-686-3428


On 26 February 2013 16:37, Abdussalam Baryun <abdussalambaryun@g= mail.com> wrote:
On Tue, Feb 26, 2013 at 4:27 PM, Daniel He = <drdanhe@gmail.com> wrote:
That's not true. If you so called input is just as noise if they are no= t technical relevant.
it wastes my time and my mailbox storage. I think = most of other mailing list users
will feel it as I felt.

Comments= are most welcome if the comments are relevant.
=A0
Who decides what is relavent. Please let the CHair= do his job and=A0never put your nose into other peoples work
=A0
AB