Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03
Stan Ratliff <ratliffstan@gmail.com> Mon, 18 April 2016 13:17 UTC
Return-Path: <ratliffstan@gmail.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 8F27312D8F8 for <manet@ietfa.amsl.com>; Mon, 18 Apr 2016 06:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 HhJUT8KwCUdd for <manet@ietfa.amsl.com>; Mon, 18 Apr 2016 06:17:42 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80FA12B04F for <manet@ietf.org>; Mon, 18 Apr 2016 06:17:41 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id 2so194219129ioy.1 for <manet@ietf.org>; Mon, 18 Apr 2016 06:17:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=+OSs0ZzaTfJm3j4hzm2kYbfOSzKmP3jWCRIfCgsk+w0=; b=quIyrmO8eBvydlNw2fx5acd6lrYILcC61ce3/6Yc55uD4m7CNDJ9Ksx44u9PZQPiJ9 AUaC7z2+/uQdk5nrdxJX1M+3LNUMS6OlcTuS+vhNHTYitgqRJXOHjsKZ6Ic83nyTIKI1 cwvQ7252wAIE4iKUcA8uHW0/dNhytUTUPCzvmgZqUxUzMjI7cG7AH4AmPtNRtVF0Qb9P 2weZOpzMDf/oFKSq1Iu2cX2aGGFxRSWK8fO6s7bgCtcuZvhHJM57GgGXz42XlKOHsvTn TkqwDTjhNALxwSPziFoQGrTEGzlLNRGnMh5OefMma+oyxbo0if/AnvHrFJPwqnDQxP6t kSTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+OSs0ZzaTfJm3j4hzm2kYbfOSzKmP3jWCRIfCgsk+w0=; b=IDtfSanR/TVW18exJmkBkaWXRgJ1M/xdOq4gDlMXfWm1E+CuKYKOFUnhVZwsl8ThY/ PitqR6InJDdyvfHvimulOI9f7GlQot/r43UGlozH5HLo/UROidaZGD/PVOzq1x44ASrM e8M5WlV6JqIB00a+FFaBlcHfPgKVRp7UmwYqagNy7RLMqTtQk/jcVo5hMOlbHD85CXnp hk1jb6Pu4KxuumYBV/B5HCfEbcvbaDygI+/JXlJT6Swkuj8aR9/voDBT0D9/LkAnnr6J U0xEjllAoYQxflg8jvFC3VOfyz5qC1Xzs/LQ47ePl5ZCVM3MEqkrSoROK7dwDh7GcoR4 fGFw==
X-Gm-Message-State: AOPr4FW9EaN/Rie8i2ignuyj9kOwFy8g7pRemGpD5MZGzuJ/xZcpHiUD8cFLzwrM0zTwLYMy5Lp/JMyB7FAsUg==
MIME-Version: 1.0
X-Received: by 10.107.129.32 with SMTP id c32mr37882184iod.102.1460985460965; Mon, 18 Apr 2016 06:17:40 -0700 (PDT)
Received: by 10.79.72.68 with HTTP; Mon, 18 Apr 2016 06:17:40 -0700 (PDT)
In-Reply-To: <B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADA83@GLKXM0002V.GREENLNK.net>
References: <CAK=bVC-vpFR1LxqwBt-nKgNNjkbahLjXo-UVZG_2qUWgZgSVBQ@mail.gmail.com> <B31EEDDDB8ED7E4A93FDF12A4EECD30D923A8FD9@GLKXM0002V.GREENLNK.net> <CA+-pDCcpZjJ2JfCKUo2pJ6ZeaTJhWe=szSwJvf5DHDQZqRxaug@mail.gmail.com> <D8EFB5A0-82C0-4AC3-ABEC-C20DD38FE025@fu-berlin.de> <A284DF24-798C-48EA-88EE-E33135646C01@gmail.com> <CALtoyokjLySvBFHAaFcYJui32pXDnbmj6Te3NMHKW9c1j7cfew@mail.gmail.com> <45DFA343-1FDD-4EB9-9291-AB3A830A3CD9@mnemosyne.demon.co.uk> <CALtoyongRbun87nMM0dHjVbVE0ZjF+00aZybHfdyBRYEmxdSMA@mail.gmail.com> <B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD7B9@GLKXM0002V.GREENLNK.net> <CALtoyokjvzEHgS8i88eKLZoSi6c4EwV5eX5pX1LUGRcOX_N1GQ@mail.gmail.com> <B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADA83@GLKXM0002V.GREENLNK.net>
Date: Mon, 18 Apr 2016 09:17:40 -0400
Message-ID: <CALtoyokq1G5jntTy22SU6yjMa1Xd-RWwF6XAGcT2iPCp=+0X8g@mail.gmail.com>
From: Stan Ratliff <ratliffstan@gmail.com>
To: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
Content-Type: multipart/alternative; boundary="001a113ec9286c4b450530c22f33"
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/U6fdcEHYptng8xbLJvY_M4ZLxEg>
Cc: Christopher Dearlove <chris@mnemosyne.demon.co.uk>, "manet@ietf.org" <manet@ietf.org>, Christopher Dearlove <christopher.dearlove@gmail.com>
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03
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: Mon, 18 Apr 2016 13:17:47 -0000
On Mon, Apr 18, 2016 at 9:13 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > As has been pointed out to me, some implementations don’t do this. If you > are building an implementation in a constrained environment, you can build > a constrained implementation. And some people have. > > > > So no, it’s not appropriate to specify an independent parser, or require > one. Rather you need to design so that when people do, it can be efficient. > Which is what we have been doing. > > > > Or in other words, I don’t think this sort of change is appropriate. Quite > the contrary. > Well, we disagree. This has been a fundamental point of contention for some of the follow-on protocols attempting to use 5444. and IMO, this has to be addressed. > > > The key point is that what’s mandated is a multiplexer and a format. But > not an independent parser. > How can you mandate a multiplexer, but not an independent parser? This makes no sense. Stan > > > *-- * > > > > > *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 > > > > *From:* Stan Ratliff [mailto:ratliffstan@gmail.com] > *Sent:* 18 April 2016 14:09 > *To:* Dearlove, Christopher (UK) > *Cc:* Christopher Dearlove; manet@ietf.org; Christopher Dearlove > *Subject:* Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > > > > > **** 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://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.* > * If you feel the email is suspicious, please follow this process > <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.* > > > > > > On Mon, Apr 18, 2016 at 4:52 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > I don’t believe we can or should suggest an implementation. That’s not > what the IETF does, and it would be a hard, probably impossible, sell, to > the IESG. That the obvious implementation employs an independent parser is > already said - it may be appropriate to strengthen the words, but this > second I’m not sure if that’s needed (not got time to check current > wording). > > > > (Again, with my Working Group Participant hat on) - > > > > I don't mean to suggest an implementation. At least to me, this is an > architecture (that of an independent parser, with a reliable communications > mechanism to said parser, that deals with logical messages instead of > packets. Is sequencing guaranteed? I'm not sure, to be honest. But once the > independent parser is assumed, engineers also MUST assume that the > transport (and it's the transport for control plane traffic, but not for > data plane traffic), is "owned" by the independent parser. > > > > Which leads me to the other point I'm trying to make (perhaps badly): > Abstracting the transport away from the control plane *can* effect > protocol design. > > > > I believe both of these points should be addressed in the usage document. > > > > Regards, > > Stan > > > > > > > > *-- * > > > > > *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 > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Stan Ratliff > *Sent:* 16 April 2016 19:09 > *To:* Christopher Dearlove > *Cc:* manet@ietf.org; Christopher Dearlove > *Subject:* Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > > > > > **** 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://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.* > * If you feel the email is suspicious, please follow this process > <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.* > > **** **WARNING ****** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > > > > > On Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlove < > chris@mnemosyne.demon.co.uk> wrote: > > I don't understand what you mean by the concept of "fields the protocol > can and can't touch". > > > > CAVEAT: I am speaking here as a Working Group participant. With that > understood: > > > > > TTL is a great example, since that discussion blew the mailing list up a > few months ago. I'm *not* saying manipulating TTL is a good thing for a > protocol to try - in truth, I think it's pretty "hacky". But the notion was > floated, and in the context of that discussion, it may will have worked. > The opposition on-list was fast, and pretty forceful. > > I've said before - 5444, especially with the multiplexer, changes the > relationship between a routing protocol and an interface. I think the > document should have some type of "overview" section which discusses these > differences, in order to frame the issue for someone coming along who > hasn't been a part of the 5444 mail discussion. > > I'm talking about the type of overview that goes something like this: > > "Use of RFC 5444 with the multiplexer feature imposes design requirements > on the protocol. The actual transport mechanism is abstracted from the > protocol. For example, routing protocols are not aware of precisely when a > message is sent. A good example of operation in this model is [BGP], > utilizing the [TCP] transport. This is opposed to a protocol such as > [OSPF], which is capable of sending traffic with its own IP type. Since the > transport is abstracted, protocols are not presented with "packets", and > are not capable of manipulating data items in packet headers (e.g. data > items at the IP and/or MAC layers)." > > As Lou Berger put it to me in the context of DLEP - "You want an engineer > to be able to pick up this document, with no prior exposure to the topic, > and code an interoperable implementation." I think this type of an > overview, setting basic ground rules, would help. > > I've also contended for a while now that 5444, with the mux, effectively > forces an architecture on implementers - in the Linux world, that > architecture is a 5444 parser as an independent process, with IPC > mechanisms to the routing protocol(s) it is servicing. The 5444 parser > itself "owns" the transport (the socket). The usage document *strongly > infers* that. I believe we should concretely state it, so we don't have to > answer the question over and over again. > > Regards, > > Stan > > > > > > > When a protocol creates a message from scratch it's not constrained in any > way I'd describe in such terms. So I assume you mean when it receives a > message and then sends a similar message. > > > > There are two cases there. Unchanged (with the special exceptions for hop > count and limit) and not unchanged. The former is better, and there's > really nothing more to say. > > > > So let's consider the latter. Really it's not the same message, it's a > brand new message. That's a useful way to look at it from a security > perspective, because it tells you that end to end authentication isn't > going to work. And what are the restrictions on brand new messages? The > same as on any new message. > > > > OK, you might say, true but does that mean I can add this, remove that, > change the hop data? Yes. But is that a good idea? No. But maybe you are > forced into it. But that it's inherently not good suggests the corollary > that if you must, do the minimum and make it trackable. But that's not a > 5444 requirement, just good practice. It does break 7182 message ICVs, so > don't use them. > > > > We could, hypothetically, have someone create an extension or alternative > to 7182 that defined aggregated signatures. Then we'd have rules on what > you could change. But that would belong there. If you think those would be > good, then again you would want make minimal changes, and mainly only of > certain types. What types? There I can't help you as I don't have a > candidate. > > > > The summary? Don't change if you don't have to. That's recommended. If you > must change you're on your own (with the same restrictions as new > messages). Advice like "as little as possible" is good, but that's not > actually 5444 advice. And don't use 7182 message ICVs. > > -- > > Christopher Dearlove > > christopher.dearlove@gmail.com (iPhone) > > chris@mnemosyne.demon.co.uk (home) > > > On 15 Apr 2016, at 19:37, Stan Ratliff <ratliffstan@gmail.com> wrote: > > My main concern addressed inline... > > > > > > On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove < > christopher.dearlove@gmail.com> wrote: > > A few immediate comments inline below. > > -- > > Christopher Dearlove > > christopher.dearlove@gmail.com (iPhone) > > chris@mnemosyne.demon.co.uk (home) > > > On 15 Apr 2016, at 15:18, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> > wrote: > > Hi all, > > > > sparked by the recently started WGLC, I’ve reviewed the current revision > of the draft. I’d like to offer the working group my perspective as someone > who doesn’t have decades of protocol and/or packet format design under > their belt (i.e. some things might not be obvious to me that are obvious to > others), but also as someone who has worked with RFC 5444 when implementing > a routing protocol (AODVv2), updating the packet format of a routing > protocol (AODVv2 again) and (partially) implementing my own RFC5444 > builder/parser. > > > > Overall, I think the document is easy to read and follow. To me, it > contains valuable information and guidance and in some cases prevents > people from shooting themselves in the foot. > > I’m really happy this document exists and I’d like it to move forward > soon, but I do feel that it is still lacking in some areas, which is why I > was a bit surprised to see it go to Last Call all of a sudden. > > > > Not really. The authors had said what they intended to say, no one was > commenting, time for WGLC. > > > > First, some nitpicks and comments: > > > > * from *1.2.1* > <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-1.2.1>*. > Packet/Message Format*: > > > > […] a packet > > transmission following a successful packet reception is by design > > of a new packet that may include all, some, or none of the > > received messages [...] > > > > I’m not a native speaker, but that „of“ seems out of place... > > > > I am a native speaker, and no, it's not. Some would repeat it after each > of all, some and none, and I might sometimes. But it really doesn't matter > which of the two styles we pick, the RFC Editor may well change to the > other. > > > > * Regarding *4.2* > <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.2>*. > Packets and Messages:* > > this section talks a lot about how the multiplexer operates, so I think > it’d be helpful if its title reflected that. > > > > I'm of two opinions on that. On the one hand it is, as its title suggests, > about the packet and message level, as opposed to lower levels, and its > title contrasts with that if 4.3 for that reason. On the other hand you are > right, it does have much about the multiplexer. A title covering all three > woukd start getting cumbersome. Will take this one away to think about. > > > > * from *4.4* > <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.4>*. > Addresses Require Attributes:* > > > > An unmodified extension to NHDP would ignore such addresses, > > as required, as it does not support that specialized purpose. > > > > At first glance, (to me) this reads as „All addresses that are associated > with an unknown TLV are ignored“, which is obviously nonsense (but quite > panic-inducing :D). I’d propose to reword it to something along the lines > of > > An unmodified extension to NHDP would not consider this > > address to be of a neighbor, as it is lacking a LINK_STATUS > > or OTHER_NEIGHB TLV. > > > > I take your point, but I think that if the address ends up with no > relevant associated TLVs then it is ignored is also a point. I dare say we > can wordsmith something. > > > > Also, I don’t quite get where you’re going with the last paragraph of that > section (“These restrictions do not, however, mean that added information > is > > completely ignored for purposes of the base protocol.”)... > > > > Read on, the rest of the paragraph describes the case where not. But we > might telegraph that better in the opening sentence. > > > > * regarding the maps in *4.5* > <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.5>*. > Information Representation:* > > I’m afraid I just don’t really understand the purpose of this section and > the mapping notation. I’m assuming that the maps are supposed to offer a > way of describing how a TLV relates to a message or an address? > > If so, why does it only mention extension types, but not the basis types? > > > > It says extended types, meaning the combination of the two. But full type > would be better, as almost defined in 5444. In fact I think we should add a > comment to the notation section. (5444 uses a symbolic name rather than the > phrase.) > > > > Or is it supposed to be used something like this: > > > > *BASE_TLV* > > > > Message: > > (base_tlv_extension_type_1) -> (2 octets, "value a when condition x is > met") > > (base_tlv_extension_type_2) -> (2 octets, "value b when condition y is > met") > > > > ? Also, I don’t quite get how this would be used in future protocol > specifications? Or aid in implementing RFC5444 parsers? > > An example or a clarification would be very helpful. > > > > It's a way of looking at things. But not the only one, it goes on to > discuss variants. I think it mostly comes under heading of if useful use > it, if not skip it. We'll take another look, but I don't think this will > ever be elementary. > > > > * regarding *4.6* > <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.6>*. > TLVs:* > > In general, it’s not clear everywhere in the section whether you’re > talking to RFC5444 parser/builder implementors or protocol designers. > > > > A protocol SHOULD use an efficient > > representation, but this is a quality of implementation issue. > > > > I’m not sure where you’re going with the last part of that sentence? I’d > reword it to something like „A protocol SHOULD use an efficient > representation, avoiding unnecessarily verbose use of TLVs and extension > types. However, the final arrangement in a message- or addressTLV block is > a quality of implementation issue“ (in case that’s what you meant). > > > > No, you're considering the protocol design. This is considering the > protocol object that implements the protocol. There isn't a one to one > mapping from information to representation, it's up to the implementation > to do it efficiently. Different implementations of the same protocol > specification may do better or worse here. (Trivial case, an implementation > could choose to never compress addresses. Bad idea, but legal.) > > > > And then: > > > > A > > protocol MUST recognize any permitted representation of the > > information; even if it chooses to (for example) only use multivalue > > TLVs, it MUST recognize single value TLVs (and vice versa). > > > > … I thought protocols weren’t supposed to specify whether a TLV is > arranged (for example) as a multivalue TLV?! > > > > Implementation again, not design. > > > > And so, since a protocol shouldn't be concerned with multivalue TLVs and > the like, wouldn’t it be the *RFC5444 implementation* that MUST recognize > any permitted representation? > > > > You're assuming that there is an RFC 5444 implementation. That's the same > way to work if you plan to implement more than one protocol. But nothing > says you have to do it that way. The architecture defined by 5498 admits of > the multiplexer and protocols, and thus these are rules on the protocol. If > protocols delegate all their common work to something (parser/creator) then > it inherits those restrictions, but that's not defined, and we can't assume > it. > > > > Or is this paragraph really just a complicated way of saying „as a > protocol designer, make sure to not specify/rely on things like (for > example) multivalue TLVs, since your messages have to work with *any* > representation“? If so, I think that should be done in a less complicated > fashion (see below). > > > > * regarding *5* > <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-5>*. > Structure:* > > Since this section talks a lot about flags, it’d be nice if its title > represented that. Maybe consider renaming it to „Structure and Flags“ or so? > > > > I mostly don't agree. Structure is the subject, flags are a detail. > > > > * from *6.1* > <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.1>*. > Address Block Compression:* > > > > Compression of addresses in an Address Block considers addresses to > > consist of a Head, a Mid, and a Tail, where all addresses in an > > Address Block have the same Head and Tail, but different Mids. > > > > > > I’d find this sentence easier to read if it started with “Compression of > addresses in an Address Block is possible when addresses consist of a Head, > a Mid […]”. > > > > No. That's missing the point and misleading. Addresses are always > considered to have the head/mid/tail format. Compression is possible if > either the head or tail (or both) is non-empty. > > > > * from *6.1* > <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.1>*. > Address Block Compression:* > > > > Putting addresses into a message efficiently also has to include: > > > > Why „has to“? I’d think that would be a „may“. Multiple Adress Blocks > and/or reordering don’t increase efficiency in all possible cases... > > > > I think that's the wrong change. Rather "include" should be "consider". > > > > * from *6.2* > <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.2>*. > TLVs:* > > [...] This is even possible if the MPR TLV specified in > > OLSRv2 [RFC7181 <https://tools.ietf.org/html/rfc7181>] is added; but it is not possible, in general, if > > the LINK_METRIC TLV is also added. > > > > Why is it not possible for the latter? If that could be explained/hinted > at in a half sentence, I think it’d be helpful information to have in the > draft. > > > > That's very hard, and not just because it's a negative. It's really an > observation that motivates the duscussion. A half sentence would I think > confuse more than it enlightens (it's because you have too many constraints > to satisfy at once - I doubt that helped). > > > > In a typical case where a > > LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with > > enough addresses, sorted appropriately, two single value TLVs can > > be more efficient than one multivalue TLV. > > > > Same thing: why? > > > > Here I think this should be obvious to anyone who has looked at 5444. > > > > * regarding the second paragraph from *6.3* > <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.3>*. > TLV Values*, i.e. > > > > This approach was specified in [RFC7188 <https://tools.ietf.org/html/rfc7188>], and required for protocols > > that extend [RFC6130 <https://tools.ietf.org/html/rfc6130>] and [RFC7181 <https://tools.ietf.org/html/rfc7181>]. It is here RECOMMENDED that > > this approach is followed when defining any Address Block TLV that > > may be used by a protocol using [RFC5444 <https://tools.ietf.org/html/rfc5444>]. > > > > The term „this approach“ confused me, since I initially thought it meant > „the approach is to use UNSPECIFIED in a way that makes sense“ rather than > „the approach is to use UNSPECIFIED“. Maybe that could be reworded to > something along the lines of > > The UNSPECIFIED TLV and its usage was specified in [RFC7188]… > > ? > > > > No. There is no UNSPECIFIED TLV. There is a recommendation to include an > UNSPECIFIED value in a TLV. But really, we've described this once in 7188, > it's there to read. > > > > * regarding *6.3* > <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.3>*. > TLV Values:* > > The second paragraph is a bit confusing and seems to explaing roghly the > same things as the fourth paragraphs. I’d propose to merge the second into > the fourth. > > > > I'm not sure I exactly agree, but the ordering in that section could be > improved. > > > > * from *6.4* > <https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.4>*. > Automation:* > > > > The possible gain depends on the efficiency > > of the original message creation, > > > > the term „the original message creation“ seems a bit ambiguous– does this > refer to the message as created by an RFC5444 message builder > implementation? > > > > Yes. > > > > Additionally, I'm concerned about two things that *aren’t* in the draft: > > > > * Some of the AODVv2 co-authors and me have asked for a list of „as a > protocol, you can set all of these fields of a message, but please leave > the rest alone“, which would’ve saved us many hours of discussions (and > Henning a lot of time spent explaining these things…). These requests have > been met with a refusal to specify a concrete API, as such an effort is > dependent on outside factors such as programming language or software > architecture. I agree with this notion, but a programming-language > dependent API is not what we’ve asked for. I’ve tried to supply a sketch of > what I did ask for in [1], but unfortunately I didn’t get an answer (and as > far as I can see it, the draft wasn’t changed either). I still think that > such a list, in whatever form, would be very helpful for future > Internet-Draft authors and I also think this request is in accordance with > the intentions stated in 1.1 History and Purpose, and I think it should > be included in the document. > > > > No. There are many reasons why we're just not touching this one. > > > > One is that language independence is a mirage. How you go about things is > completely different in, for example an object oriented language than one > that isn't. Section 4.5 shows that there are quite different ways of doing > things even given a decision to use a map approach, and there are other > approaches than that. It would be wrong and beyond our competence to > suggest one of these as "best". There's reasons the IETF doesn't do this, > and that's one. > > > > Plus, frankly, the work it would take is beyond what we choose to spend. > > > > > > <Speaking as a WG Participant> > > > > I'm confused (which is an altogether too common occurrence these days). I > get that we don't want to specify an API. But I think the discussion about > fields a protocol can and can't touch in a messages is a good thing - and > it's one spot where I, too, find the document wanting. > > > > To paraphrase something I've said before, I believe that RFC 5444 changes > the relationship that a routing protocol has with an "interface". I'm not > commenting on whether or not that's a good thing, or a bad thing - just > that it does change the relationship. This change has been at the root of > some of the long-running discussions as to whether protocols under > development were RFC 5444 compliant or not. The goal of this document being > to eliminate (it's a goal, probably not reachable) those discussions, I'd > like to see that information in the document in some form. > > > > I'm interested in seeing this document progress, and eventually be > published. I think it will help future protocol designers to better use RFC > 5444. But I would like to see *something* along the lines of what Lotte is > requesting, as I think it will improve the doc. > > > > Regards, > > Stan > > > > > > > > * As the exact rules for using/setting the hop count & hop-limit fields > are currently being discussed w/ regard to AODVv2 in another thread [2]– > should a definitive answer to that question be part of 5444-usage? > > > > You don't want that. Because if we did specify that you'd find yourself > more constrained than you want to be. There is a design intent described in > 5444, but it assumes immutable messages. Which you don't want. Really, > we're doing you a favour by not imposing on you. > > > > Best regards, > > Lotte > > > > [1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html > > [2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html > > > > > > Am 06.04.2016 um 19:14 schrieb Justin Dean <bebemaster@gmail.com>: > > > > The chairs agree that a 3 week WGLC is appropriate. Everyone please read > the draft early and get comments in early so that they can be addressed > within the last call period. > > > > Justin > > > > On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > Obviously +1 to the request for WGLC. > > With regard to what's changed, technically the only significant thing is > to make it clear that if a protocol delivers a message to the multiplexer, > the multiplexer must pass it on unchanged to the protocol (another instance > of, at another router) unchanged. Without that nothing that the protocol > itself chooses to do with regard to security makes sense. Though the > protocol can alternatively let the multiplexer do the security, 7182 can be > implemented in either way. This isn't really new, but it wasn't formally > spelled out. It's presented as part of spelling out multiplexer rules more > carefully. > > But what about message optimisation? That's a function of constructing a > 5444 message, not the multiplexer, and is down to that 5444 includes two > things - packet/message structure (and implicitly, and in pretty much any > implementation I would expect to see, a parser and builder for that > structure) and the multiplexer. So we took the opportunity to separate out > more clearly a discussion of the two, which we think will be helpful. > > -- > 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 > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg > Sent: 05 April 2016 20:08 > To: manet@ietf.org > Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > ----------------------! WARNING ! ---------------------- This message > originates from outside our organisation, either from an external partner > or from the internet. > Consider carefully whether you should click on any links, open any > attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions > on reporting suspicious email messages. > -------------------------------------------------------- > > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > Hi, > > As you have seen, we have submitted a new revision of 5444-usage. The > authors feel comfortable that we have addressed all issues by this version, > and would like to ask the WG chairs to issue a WGLC on this document. While > it is a fairly short document, given that it is IETF week for some, we'd > suggest that a 3-4 week WGLC would be appropriate. > > Best regards > 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 > > > > _______________________________________________ > 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] WGLC request for draft-ietf-manet-rfc5444… Ulrich Herberg
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Dearlove, Christopher (UK)
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Thomas Clausen
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Justin Dean
- Re: [manet] WGLC request for draft-ietf-manet-rfc… John Dowdell
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Justin Dean
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Dearlove, Christopher (UK)
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Jiazi YI
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Lotte Steenbrink
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Christopher Dearlove
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Stan Ratliff
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Christopher Dearlove
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Stan Ratliff
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Dearlove, Christopher (UK)
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Abdussalam Baryun
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Dearlove, Christopher (UK)
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Stan Ratliff
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Dearlove, Christopher (UK)
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Stan Ratliff
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Dearlove, Christopher (UK)
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Stan Ratliff
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Dearlove, Christopher (UK)
- Re: [manet] WGLC request for draft-ietf-manet-rfc… Lotte Steenbrink