Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"
"Dearlove, Christopher (UK)" <email@example.com> Wed, 04 January 2017 10:10 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5BB128DF6 for <firstname.lastname@example.org>; Wed, 4 Jan 2017 02:10:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-10.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([220.127.116.11]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyxNyMUuo0Rn for <email@example.com>; Wed, 4 Jan 2017 02:10:17 -0800 (PST)
Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [18.104.22.168]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931F712711D for <firstname.lastname@example.org>; Wed, 4 Jan 2017 02:10:16 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.33,458,1477958400"; d="scan'208,217"; a="48389624"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 04 Jan 2017 10:10:13 +0000
X-IronPort-AV: E=Sophos;i="5.33,458,1477958400"; d="scan'208,217";a="149926662"
Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 04 Jan 2017 10:10:13 +0000
Received: from GLKXM0003V.GREENLNK.net ([169.254.4.144]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Wed, 4 Jan 2017 10:10:13 +0000
From: "Dearlove, Christopher (UK)" <email@example.com>
To: Jiazi Yi <firstname.lastname@example.org>, "Peter S Lau (peterlau)" <email@example.com>
Thread-Topic: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"
Date: Wed, 4 Jan 2017 10:10:13 +0000
References: <BLUPR0401MB1731F4A2461F01E0550CBE70C96E0@BLUPR0401MB1731.namprd04.prod.outlook.com> <97591271-9997-4245-BDED-056BE872AF8B@jiaziyi.com>
Accept-Language: en-GB, en-US
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DA51A9158GLKXM0003vGREEN_"
Cc: "firstname.lastname@example.org" <email@example.com>
Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2017 10:10:19 -0000
There some immediate retrograde steps compared to existing protocols: fixed message format (making adding new information to be used by the protocol hard), forwarding by blind flooding (hence scalability issues), and no security (an example of something that to add would require a changed format). The rather peculiar link metric (in effect) that mixes hop count, time and battery power leads to many questions (and while not simply hop count is likely to be a backward step in flexibility). There’s a rather unusual message body that is not used by this protocol but said to be for the application, which is a bit of a layering issue. GPS is included with no indication how to use and hence no indication why it is there. They are also underspecified in terms of format information (and for GPS at least even size of field). There’s quite a lot underspecified, such as route determination, and there’s no consideration of how the acknowledgements are used - and even what the meaning of acknowledgements in what must be (but is not so described) as a local broadcast/multicast message (with potentially unknown recipients). I don’t see any handling of the problems that link asymmetry produces. I’d have issues over timing parameters and their management (these being not reflected in the message). And in a proposed IETF protocol, I don’t see any IP addresses. That it hasn’t even caught up with the existence of RFC 7181 (only quoting RFC 3626) is not a good sign. It is suggested that RFC 3626 (and hence, no doubt, RFC 7181) is too complex. That may or may not be so (there are reasons for the added complexity in RFC 7181, which need to be understood before deciding whether you need them) and there thus may or may not be a space for a lightweight proactive protocol, but this is not that protocol in current or foreseeable evolutionary form. -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: +44 (0)1245 242194 | E: firstname.lastname@example.org<mailto:email@example.com> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN. www.baesystems.com/ai<http://www.baesystems.com/ai> BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP From: manet [mailto:firstname.lastname@example.org] On Behalf Of Jiazi Yi Sent: 04 January 2017 09:08 To: Peter S Lau (peterlau) Cc: email@example.com Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh" *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Consider carefully whether you should click on any links, open any attachments or reply. For information regarding Red Flags that you can look out for in emails you receive, click here<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Red%20Flags.pdf>df>. If you feel the email is suspicious, please follow this process<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Dealing%20With%20Suspicious%20Emails.pdf>df>. *** WARNING *** EXTERNAL EMAIL -- This message originates from outside our organization. Dear Peter, Thanks very much for your draft. Looking at the overview section: TRP is a table-driven proactive data forwarding protocol and at the same time allows users to announce their presence to the network. A node, wishing to be contacted, periodically broadcasts control messages about itself to the network. A node, receiving control messages, caches an optimal path to each of the originators of the control messages. Could you please briefly introduce what’s the difference between TRP and other proactive protocols like OLSR(v2)? Especially, it would be very helpful for the readers to understand by providing a bit more text about the mechanism of the protocol in the overview. best Jiazi On 3 Jan 2017, at 18:09, Peter S Lau (peterlau) <firstname.lastname@example.org<mailto:email@example.com>> wrote: Dear manet Working Group: I have uploaded a proposed draft entitled "draft-peterlau-manet-topology-refresh-00". for the WG to consider. Regards, Peter Lau Peter Lau The University of Memphis Electrical and Computer Engineering _______________________________________________ manet mailing list firstname.lastname@example.org<mailto:email@example.com> 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] A proposed draft "draft-peterlau-manet-to… Peter S Lau (peterlau)
- Re: [manet] A proposed draft "draft-peterlau-mane… Jiazi Yi
- Re: [manet] A proposed draft "draft-peterlau-mane… Dearlove, Christopher (UK)
- Re: [manet] A proposed draft "draft-peterlau-mane… Justin Dean
- Re: [manet] A proposed draft "draft-peterlau-mane… Peter S Lau (peterlau)
- Re: [manet] A proposed draft "draft-peterlau-mane… Christopher Dearlove