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

[Abdussalam Baryun <[e-mail]>]

Hi Chris,

IMO the use of 5444 is for implementation purpose or information. So, I
agree with Stan's comment, that this draft is important to progress, but
would nice to add in the draft some examples of use cases of OLSRv2 and
AODVv2 both routing-protocols, or examples of implementation. This will
help the use of 5444 because I think these protocols use 5444 differently
because they have different purposes/advantages. Thanks,

AB


On Mon, Apr 18, 2016 at 10: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).
>
>
>
> *-- *
>
>
>
>
> *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
>
>
>
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>