Subject: [manet] draft-ietf-manet-rfc5444-usage

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 29 Apr 2016 16:04:47 +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: [email-masked]

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