[manet] draft-ietf-manet-rfc5444-usage
"Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> Fri, 29 April 2016 16:04 UTC
Return-Path: <chris.dearlove@baesystems.com>
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 EB0B912B02C for <manet@ietfa.amsl.com>; Fri, 29 Apr 2016 09:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.127
X-Spam-Level:
X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEK1fzRcmFY5 for <manet@ietfa.amsl.com>; Fri, 29 Apr 2016 09:04:50 -0700 (PDT)
Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D320712B012 for <manet@ietf.org>; Fri, 29 Apr 2016 09:04:49 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="scan'208";a="34497285"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 29 Apr 2016 17:04:48 +0100
X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="scan'208";a="116117505"
Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 29 Apr 2016 17:04:48 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Fri, 29 Apr 2016 17:04:48 +0100
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: "manet@ietf.org" <manet@ietf.org>
Thread-Topic: draft-ietf-manet-rfc5444-usage
Thread-Index: AdGiMGOHnWZV2LzgSKGOdp7rWDj9Zg==
Date: Fri, 29 Apr 2016 16:04:47 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D923B26BB@GLKXM0002V.GREENLNK.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/lrtg5hxKcdtOOZK4fYKLuaHu8RE>
Subject: [manet] draft-ietf-manet-rfc5444-usage
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2016 16:04:52 -0000
WGLC having finished, I've been through everyone's comments. And by my reckoning this is what we (the authors) should do (agreed changes, and in at least one case I had an "aha" that's what I think is being asked for, in which case we can do that). - Section 4.2 is titled Packets and Messages, but is about Multiplexer. Take under advisement, can see both sides of that. Hope when we've done everything else what's best will be clear. - Section 4.4 "An unmodified extension to NHDP would ignore such addresses" Be clear that ignoring if just present. Don't ignore if address has TLVs router is using. Also be clearer up front in this paragraph that discussing case in final sentence. - Section 4.5. Some words up front as to why this material is here. - Read through document to check if clear where advice is for protocol designer, and where is for protocol implementer. The former is our main emphasis, though comments about parsing are the latter. - Words up front to be clear that, as well as multiplexer (and how RFC 5498 mandates that),RFC 5444 only specifies formats; parsing (and its opposite - forming?) is done by protocol. An implementer may simply do this in a protocol, but a natural design is a separate parser used by multiple protocols (e.g. NHDP and OLSRv2). Some comments are about if you choose to do latter, especially Section 6.4 but don't leave first mention to there. But a separate parser is not a requirement. - Section 6.1 to be clear, addresses always have a head a mid and a tail. Gain compression advantage when head and/or tail are not empty. - Section 6.1 " Putting addresses into a message efficiently also has to include" s/include/consider/ - Section 6.2 Be clear that analysis of NHDP and OLSRv2 shows ordering possible, but the details are beyond the scope of this document. - Section 6.3 Be clear that UNSPECIFIED is for TLVs with discrete values (usually specified in a registry). There is an equivalent in at least one other case (OLSRv2 metrics). - Section 4.2 first bullet, or elsewhere cross-referenced. Be clear (reference to 5444 appendix) that the recommended approach is messages unchanged except for hop count/limit, because it enables E2E authentication, in particular using RFC 7182 message TLVs. - Section 4.2 bullet 3, add comment that protocol should not produce message that (with additional headers) would exceed MTU if sent on its own in a packet. (If it does, as the multiplexer can't fragment, IP will have to, and that's undesirable.) - Multiplexer adding packet sequence number, MUST be consistent (add to all packets or none - for each interface and destination as it already says). - Probably (if there's a suitable place to say it) note that the multiplexer has a relationship (message transfer) with protocols that own messages. The interaction between a protocol and any extensions is up to them, not the multiplexer. - Change uses of extended type to full type. Add full type to Terminology, matching to symbolic name in RFC 5444. Check if extended type is used in other RFCs, if it is, add comment that sometimes so referred to. Somewhere be clear that routers in a MANET need to have a common understanding of RFC 7182 usage, including whether by multiplexer (always for packets) or protocol. -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP ******************************************************************** 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] draft-ietf-manet-rfc5444-usage Dearlove, Christopher (UK)
- Re: [manet] draft-ietf-manet-rfc5444-usage Abdussalam Baryun
- Re: [manet] draft-ietf-manet-rfc5444-usage Christopher Dearlove
- Re: [manet] draft-ietf-manet-rfc5444-usage John Dowdell