Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

[Stan Ratliff <[e-mail]>]

On Mon, Apr 18, 2016 at 4:52 AM, Dearlove, Christopher (UK) <
[e-mail]> 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*:  [phone]  |  *E: *[e-mail]
>
> 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:[e-mail]] *On Behalf Of *Stan Ratliff
> *Sent:* 16 April 2016 19:09
> *To:* Christopher Dearlove
> *Cc:* [e-mail]; 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 <
> [e-mail]> 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
>
> [e-mail] (iPhone)
>
> [e-mail] (home)
>
>
> On 15 Apr 2016, at 19:37, Stan Ratliff <[e-mail]> wrote:
>
> My main concern addressed inline...
>
>
>
>
>
> On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove <
> [e-mail]> wrote:
>
> A few immediate comments inline below.
>
> --
>
> Christopher Dearlove
>
> [e-mail] (iPhone)
>
> [e-mail] (home)
>
>
> On 15 Apr 2016, at 15:18, Lotte Steenbrink <[e-mail]>
> 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 <[e-mail]>:
>
>
>
> 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) <
> [e-mail]> 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:  [phone]  |  E: [e-mail]
>
> 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:[e-mail]] On Behalf Of Ulrich Herberg
> Sent: 05 April 2016 20:08
> To: [e-mail]
> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>
>
>
>