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.
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...
* 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.
* 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.
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.”)...
* 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? 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.
* 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).
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?! 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? 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?
* 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 […]”.
* 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...
* 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.
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?
* 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]…
?
* 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.
* 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?
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.
* 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?
Best regards,
Lotte
[1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html ;
<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@xxxxxxxxx>:
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@xxxxxxxxxxxxxx <mailto:chris.dearlove@xxxxxxxxxxxxxx>> 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 <tel:%2B44%20%280%291245%20242194> | E:
chris.dearlove@xxxxxxxxxxxxxx <mailto:chris.dearlove@xxxxxxxxxxxxxx>
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
-----Original Message-----
From: manet [mailto:manet-bounces@xxxxxxxx ;<mailto:manet-bounces@xxxxxxxx>]
On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@xxxxxxxx <mailto:manet@xxxxxxxx>
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@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet ;
<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@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet ;
<https://www.ietf.org/mailman/listinfo/manet>
_______________________________________________
manet mailing list
manet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/manet
