Re: [manet-dlep-rg] notes DLEP meeting @ IETF88

["Stan Ratliff (sratliff)" <[e-mail]>]

+1

On Nov 14, 2013, at 11:23 AM, Rick Taylor <[e-mail]> wrote:

> I'm afraid I still prefer the router being in the listen state for the TCP and the modem sending the SYN.
> 
> It just seems more logical to have the router that will be communicating with multiple modems being the TCP server.
> 
> Rick
> ________________________________________
> From: [e-mail] [[e-mail]] on behalf of Teco Boot [[e-mail]]
> Sent: 14 November 2013 16:12
> To: Henning Rogge
> Cc: Duke, Martin; DLEP Research Group ([e-mail]); Martin Duke; Taylor,    Rick
> Subject: Re: [manet-dlep-rg] notes DLEP meeting @ IETF88
> 
> Op 14 nov. 2013, om 16:20 heeft Henning Rogge <[e-mail]> het volgende geschreven:
> 
>> I still prefer the UDP peer discovery sent by the radio.
> 
> +1
> Followed by a TCP SYN response sent by router.
> This enables set up of DLEP sessions without the UDP ignition packet. Routers can send the TCP SYN to the modem if they have knowledge on the modem IP address.
> 
> Teco
> 
> 
>> 
>> Henning Rogge
>> 
>> On Thu, Nov 14, 2013 at 4:19 PM, Martin Duke <[e-mail]> wrote:
>>> I'm comfortable with router-initiated processes, though it doesn't seem to
>>> match up with things that Stan and Teco have said recently.
>>> 
>>> On Nov 14, 2013 2:17 AM, "Taylor, Rick" <[e-mail]> wrote:
>>>> 
>>>> Martin,
>>>> 
>>>> I think the discussions passed like two ships in the night, but I believe
>>>> we have now moved to peer discovery being a router-initiated process for
>>>> exactly the reason you describe.
>>>> 
>>>> The router can keep strobing for interested modems, and modems can decide
>>>> to connect to the advertising router if they wish.
>>>> 
>>>> If you check back through the archive, the recent thread called "DLEP
>>>> session establishment" has the discussion.
>>>> 
>>>> Sorry, this list has gone quite mad since Vancouver, but I suppose that
>>>> shows interest by the DT!
>>>> 
>>>> And thanks for taking a personal interest even if you are moving off your
>>>> current project.
>>>> 
>>>> Cheers,
>>>> 
>>>> Rick
>>>> 
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:manet-dlep-rg-
>>>>> [e-mail]] On Behalf Of Duke, Martin
>>>>> Sent: 12 November 2013 16:57
>>>>> To: [e-mail]
>>>>> Cc: [e-mail]
>>>>> Subject: Re: [manet-dlep-rg] notes DLEP meeting @ IETF88
>>>>> 
>>>>> Teco,
>>>>> 
>>>>> It seems like there are two competing proposals for session
>>>>> initialization. Yours:
>>>>> 
>>>>>>> Router                    Modem   Message Description
>>>>>>> ====================================================================
>>>>>>> 
>>>>>>> <-------Peer Discovery---------   Modem initiates discovery
>>>>>>>                                with server TCP port ...
>>>>>>> <-------Peer Discovery---------   Repeats discovery forever
>>>>>>> ...
>>>>>>> 
>>>>>>> ------------TCP SYN----------->   Router initiates TCP connection to
>>>>> TCP server
>>>>>>>                                port from Peer Discovery
>>>>>>> <---------TCP SYN ACK----------   Modem part of TCP connection set up
>>>>>>> ------------TCP ACK----------->   Router finishes TCP connection set
>>>>>>> up
>>>>>>> 
>>>>>>> -----------Peer Offer--------->   Router starts DLEP session with
>>>>>>> Offer
>>>>>>> <--------Peer Offer ACK--------   Modem joins in DLEP session with
>>>>> Offer Ack
>>>>>>> ---------Peer Offer ACK------->   Router completes DLEP session with
>>>>> Offer Ack
>>>>> 
>>>>> And Stan's:
>>>>> 
>>>>> Router                  Modem               Message Description
>>>>> ======================================================
>>>>> <------------------------ Peer Discovery     Modem initiates discovery
>>>>> via
>>>>> MCAST UDP.
>>>>> Peer Offer    -------------------------->     Response to discovery,
>>>>> basically an "I'm here"
>>>>>                                             response. Contains TCP
>>>>> address/port for
>>>>>                                                     subsequent
>>>>> connection.
>>>>> <------------------------- TCP SYN
>>>>> TCP SYN ACK ----------------------->
>>>>> <------------------------- ACK         (Standard TCP 3-way handshake)
>>>>> <-------------------------- Peer Initialization (New message). The Peer
>>>>> Init message contains, for example, all of the MANDATORY metric TLVs
>>>>> that
>>>>> the modem supports. It's a way to get the DLEP control session
>>>>> initialized.
>>>>> 
>>>>> ... and I suppose Stan, if he was finishing the example, would need two
>>>>> additional messages to complete session negotiation.
>>>>> 
>>>>> A bunch of comments:
>>>>> 1) Stan's stated purpose to flip the SYN is to put the server
>>>>> implementation at the router. Frankly that's good enough for me unless
>>>>> Teco has counter-arguments.
>>>>> 2) Given #1, I agree with Stan the Peer Offer has to come outside the
>>>>> TCP
>>>>> connection to provide the port number.
>>>>> 3) I'm not particularly convinced that we have to strip all the TLVs and
>>>>> whatnot out of the Peer Discovery/Peer Offer messages and put them in a
>>>>> new Peer Initialization exchange. It's a small thing either way, but I'm
>>>>> in favor of having fewer messages if we can afford it, and refusing
>>>>> sessions prior to a TCP handshake if we can do it.
>>>>> 
>>>>> Martin
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Teco Boot [mailto:[e-mail]]
>>>>> Sent: Tuesday, November 12, 2013 8:33 AM
>>>>> To: Duke, Martin
>>>>> Cc: [e-mail]
>>>>> Subject: Re: notes DLEP meeting @ IETF88
>>>>> 
>>>>> 
>>>>> Op 12 nov. 2013, om 17:04 heeft Duke, Martin <[e-mail]>
>>>>> het
>>>>> volgende geschreven:
>>>>> 
>>>>>> It feels like the terminology is a bit jumbled here. The "Peer
>>>>> Discovery" contains all the session parameters for the modem. The "Peer
>>>>> Offer" in effect acknowledges these and contains relevant parameters for
>>>>> the Router. The "Peer Offer ACK" confirms the modem's acceptance of
>>>>> these?
>>>>> Why do we have to confirm the confirmation?
>>>>> 
>>>>> We have to come back to this. Recent posts rename couple of messages.
>>>>> Discovery is just the advertisement, where DLEP session setup takes care
>>>>> of transfer of all supported TLVs.
>>>>> 
>>>>> The Peer Offer would be renamed to Peer Initialization, with three-way
>>>>> handshake.
>>>>> 
>>>>> Maybe better rename Peer Discovery to DLEP Modem Advertisement.
>>>>> 
>>>>> All of this has to do with rework because we transfer to TCP were we
>>>>> have
>>>>> the connection setup.
>>>>> 
>>>>> Teco
>>>>> 
>>>>> 
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Teco Boot [mailto:[e-mail]]
>>>>>> Sent: Monday, November 11, 2013 9:57 PM
>>>>>> To: Duke, Martin
>>>>>> Cc: [e-mail]
>>>>>> Subject: Re: notes DLEP meeting @ IETF88
>>>>>> 
>>>>>> 
>>>>>> Op 11 nov. 2013, om 22:45 heeft Duke, Martin <[e-mail]>
>>>>> het volgende geschreven:
>>>>>> 
>>>>>>> What is the purpose of the second Peer Offer ACK?
>>>>>> 
>>>>>> It informs the modem that router accepts the Modem Peer Offer. Then
>>>>>> both
>>>>> peers of the session knows session setup was successful. If the Router
>>>>> does not accept the Peer Offer Ack (e.g. version mismatch), it sends an
>>>>> error and / or closes the connection.
>>>>> 
>>>>>> 
>>>>>> Teco
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Teco Boot [mailto:[e-mail]]
>>>>>>> Sent: Monday, November 11, 2013 1:39 PM
>>>>>>> To: Duke, Martin
>>>>>>> Cc: [e-mail]
>>>>>>> Subject: Re: notes DLEP meeting @ IETF88
>>>>>>> 
>>>>>>> Let's come back to this topic after we completed TCP connection and
>>>>> DLEP session management. Probably the issue is solved by then.
>>>>>>> 
>>>>>>> Please comment on the TCP connection setup and maintenance. Below the
>>>>> proposal, adjusted after comments from Stan and Henning.
>>>>>>> 
>>>>>>> Router                    Modem   Message Description
>>>>>>> ====================================================================
>>>>>>> 
>>>>>>> <-------Peer Discovery---------   Modem initiates discovery
>>>>>>>                                with server TCP port ...
>>>>>>> <-------Peer Discovery---------   Repeats discovery forever
>>>>>>> ...
>>>>>>> 
>>>>>>> ------------TCP SYN----------->   Router initiates TCP connection to
>>>>> TCP server
>>>>>>>                                port from Peer Discovery
>>>>>>> <---------TCP SYN ACK----------   Modem part of TCP connection set up
>>>>>>> ------------TCP ACK----------->   Router finishes TCP connection set
>>>>>>> up
>>>>>>> 
>>>>>>> -----------Peer Offer--------->   Router starts DLEP session with
>>>>>>> Offer
>>>>>>> <--------Peer Offer ACK--------   Modem joins in DLEP session with
>>>>> Offer Ack
>>>>>>> ---------Peer Offer ACK------->   Router completes DLEP session with
>>>>> Offer Ack
>>>>>>> 
>>>>>>> <=============================>   DLEP session is established
>>>>>>> 
>>>>>>> <--------Peer Heartbeat--------   Heartbeats when no other messages
>>>>>>> ---------Peer Heartbeat------->     between Router and Modem
>>>>>>> 
>>>>>>> <---------Neighbor Up ---------   Modem sends Neighbor Up with
>>>>>>> metrics
>>>>>>>                                No DLEP Ack required
>>>>>>> 
>>>>>>> <-------Neighbor Update--------   Modem Neighbor metrics update
>>>>>>> ...
>>>>>>> <-------Neighbor Update--------
>>>>>>> ...
>>>>>>> <--------Neighbor Down---------   Modem sends Neighbor Down
>>>>>>> 
>>>>>>> When somethings goes wrong or down state is scheduled, DLEP session
>>>>>>> terminates with TCP connection mechanism. Before, a Peer Error MAY be
>>>>>>> send.
>>>>>>> 
>>>>>>> <----------Peer Error----------   Optional Modem error report
>>>>>>> <-------TCP RESET or FIN-------   Modem terminates session
>>>>>>>    completed following
>>>>>>>       TCP procedure
>>>>>>> or
>>>>>>> -----------Peer Error--------->   Optional Router error report
>>>>>>> --------TCP RESET or FIN------>   Router terminates session
>>>>>>>    completed following
>>>>>>>       TCP procedure
>>>>>>> 
>>>>>>> Teco
>>>>>>> 
>>>>>>> Op 11 nov. 2013, om 19:48 heeft Duke, Martin <[e-mail]>
>>>>> het volgende geschreven:
>>>>>>> 
>>>>>>>> We must be talking past each other. In Section 11 of DLEP-04:
>>>>>>>> 
>>>>>>>> A Peer Discovery Message received from a modem that is already in
>>>>>>>> session MUST be processed as if a Peer Termination Message had been
>>>>>>>> received. A router implementation MAY then process the received Peer
>>>>>>>> Discovery Message.
>>>>>>>> 
>>>>>>>> The plain language interpretation of this is that a modem that
>>>>> continues to send out Peer Discovery messages to find new peers will
>>>>> trigger resets of existing sessions.
>>>>>>>> 
>>>>>>>> Perhaps the root problem is that we haven't really done a scrub for
>>>>> the implications of using TCP on all of the reliability mechanisms from
>>>>> previous drafts. I get confused on whether or not we're precluding UDP
>>>>> implementations, but maybe the right answer is to simply delete this
>>>>> provision.
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Teco Boot [mailto:[e-mail]]
>>>>>>>> Sent: Monday, November 11, 2013 10:31 AM
>>>>>>>> To: Duke, Martin
>>>>>>>> Cc: [e-mail]
>>>>>>>> Subject: Re: notes DLEP meeting @ IETF88
>>>>>>>> 
>>>>>>>> I might have missed some context here, discussed during post-meeting
>>>>> meeting.
>>>>>>>> 
>>>>>>>> Do you think there is a need for terminating the TCP connection,
>>>>>>>> other
>>>>> than what TCP can provide? Maybe you had something in mind with
>>>>> heartbeat
>>>>> turned off and blocked TCP port. I prefer a non-blocking implementation.
>>>>> For a crashed DLEP agent, I can think of a Peer Order with Reset TLV,
>>>>> where router resets the modem. Would be similar to AT!RESET.
>>>>>>>> 
>>>>>>>> Teco
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Op 11 nov. 2013, om 17:33 heeft Duke, Martin
>>>>>>>> <[e-mail]>
>>>>> het volgende geschreven:
>>>>>>>> 
>>>>>>>>> Teco,
>>>>>>>>> 
>>>>>>>>> Although I follow that you want multiple peer sessions per modem,
>>>>>>>>> I'm
>>>>> having trouble parsing what your prescription is to address the peer
>>>>> session teardown problem I pointed out.
>>>>>>>>> 
>>>>>>>>> Martin
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Teco Boot [mailto:[e-mail]]
>>>>>>>>> Sent: Monday, November 11, 2013 7:48 AM
>>>>>>>>> To: Duke, Martin
>>>>>>>>> Cc: [e-mail]
>>>>>>>>> Subject: Re: notes DLEP meeting @ IETF88
>>>>>>>>> 
>>>>>>>>> I think we keep Peer Discovery message generation and DLEP session
>>>>> maintenance separate. This keeps state machines less complex, less code,
>>>>> less bugs, increased functionality.
>>>>>>>>> 
>>>>>>>>> Having multiple DLEP session to same modem is related. If we
>>>>>>>>> support
>>>>> it, sending Peer Discovery messages shall not be stopped after first
>>>>> session.
>>>>>>>>> 
>>>>>>>>> Reason why I need multiple sessions: about half of modems I have to
>>>>> support have multiple ethernet ports. They serve multiple unrelated
>>>>> networks, there is no single connected router. Some modems are 6 digit
>>>>> $,
>>>>> we have to share these expensive assets. And they fully support it;).
>>>>>>>>> 
>>>>>>>>> Teco
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Op 11 nov. 2013, om 16:30 heeft Duke, Martin
>>>>>>>>> <[e-mail]>
>>>>> het volgende geschreven:
>>>>>>>>> 
>>>>>>>>>> Teco,
>>>>>>>>>> 
>>>>>>>>>> Yes, this point was at the very end. The current spec says that if
>>>>> the router receives a Peer Discovery message it must terminate any
>>>>> existing session with that modem. Clearly this is not acceptable
>>>>> behavior
>>>>> if the modem is continuing to multicast Peer Discovery messages when a
>>>>> peer session exists.
>>>>>>>>>> 
>>>>>>>>>> There are other ways to solve this problem, but the reply I got
>>>>>>>>>> back
>>>>> was that there was no reason to keep seeking routers once a peer session
>>>>> exists. If there's disagreement on this point I'm happy  to back off the
>>>>> assertion that it's settled.
>>>>>>>>>> 
>>>>>>>>>> Martin
>>>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Teco Boot [mailto:[e-mail]]
>>>>>>>>>> Sent: Friday, November 08, 2013 10:59 PM
>>>>>>>>>> To: Duke, Martin
>>>>>>>>>> Cc: DLEP Research Group ([e-mail])
>>>>>>>>>> Subject: Re: notes DLEP meeting @ IETF88
>>>>>>>>>> 
>>>>>>>>>> Good summary, thanks. Let's only post the summary to the MANET ML.
>>>>>>>>>> Having minutes archived on DLEP-RG ML would be fine, I think.
>>>>>>>>>> 
>>>>>>>>>> On 7: It was not discussed during our meeting, at least not were I
>>>>> was present. And I don't think this is a good idea. It is not needed and
>>>>> blocks more advanced usage of DLEP. Let's not have a restriction in that
>>>>> a
>>>>> router or modem has only a single DLEP peer.
>>>>>>>>>> 
>>>>>>>>>> Teco
>>>>>>>>>> 
>>>>>>>>>> Op 8 nov. 2013, om 21:40 heeft Duke, Martin
>>>>>>>>>> <[e-mail]>
>>>>> het volgende geschreven:
>>>>>>>>>> 
>>>>>>>>>>> Thanks Ron. That matches the notes I have. I might also add this
>>>>> summary of what I think we agreed on in terms of changing/clarifying the
>>>>> spec, which perhaps is more interesting than the play-by-play:
>>>>>>>>>>> 
>>>>>>>>>>> 1. There are no metric TLVs it is MANDATORY for the Router to
>>>>> process.
>>>>>>>>>>> 2. The modem MUST report MDRT, MDRR, CDRT, and CDRR in the Peer
>>>>> Discovery message, and make a best effort to accurately report these
>>>>> metrics subsequently.
>>>>>>>>>>> 3. The modem and router MUST include DLEP version in Peer
>>>>>>>>>>> Discovery
>>>>> and Peer Offer messages.
>>>>>>>>>>> 4. The modem MUST include a Heartbeat Interval/Threshold TLV in
>>>>>>>>>>> its
>>>>> Peer Discovery messages. It is STRONGLY RECOMMENDED that the Interval be
>>>>> a
>>>>> nonzero value.
>>>>>>>>>>> 5. The modem MUST include all metric TLVs it reports in the Peer
>>>>> Discovery Message to allow the router to initialize its session control
>>>>> block.
>>>>>>>>>>> 6. The Router MUST NOT include metric TLVs in a Link
>>>>> Characteristics Request message that were not in the session's Peer
>>>>> Discovery message.
>>>>>>>>>>> 7. The modem MUST NOT send Peer Discovery messages if it has an
>>>>> existing Peer Session.
>>>>>>>>>>> 8. Both router and modem MUST send a Heartbeat Message to the
>>>>>>>>>>> peer
>>>>> if it has sent no DLEP message in an interval equivalent to the
>>>>> Heartbeat
>>>>> Interval value in the Peer Discovery Message. It MAY send a Heartbeat
>>>>> Message in every instance of the interval regardless of any other DLEP
>>>>> traffic.
>>>>>>>>>>> 9. Both router and modem MUST reset their Heartbeat timer when
>>>>>>>>>>> any
>>>>> DLEP message arrives from the peer.
>>>>>>>>>>> 10. The Heartbeat Interval/Threshold TLV becomes a "Heartbeat
>>>>> Interval TLV." Any DLEP peer is free to set any threshold for
>>>>> terminating
>>>>> the peer session as long as it equals or exceeds two Heartbeat
>>>>> Intervals,
>>>>> unless the Heartbeat Interval is zero.
>>>>> 
>>>>>>>>>>> 11. We will combine Expected Forwarding Time and Latency TLVs
>>>>>>>>>>> into
>>>>> a single, well-defined TLV.
>>>>>>>>>>> 12. Delete the Resources TLVs.
>>>>>>>>>>> 13. Keep the RLQ TLV, but Rick and Stan will formulate a stricter
>>>>> definition. There will be no other link quality TLVs (e.g. BER, packet
>>>>> delivery rate, SINR, etc) in the next draft.
>>>>>>>>>>> 14. Stan to add clarifying language on how multicast neighbors
>>>>> work, in line with what he said at the meeting.
>>>>>>>>>>> 
>>>>>>>>>>> As Ron said, the form of the Credits TLVs are unresolved at this
>>>>> moment.
>>>>>>>>>>> 
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Velt, R. (Ronald) in 't [mailto:[e-mail]]
>>>>>>>>>>> Sent: Thursday, November 07, 2013 5:58 PM
>>>>>>>>>>> To: Ulrich Herberg
>>>>>>>>>>> Cc: [e-mail]; [e-mail];
>>>>>>>>>>> [e-mail]; Duke, Martin; Teco Boot
>>>>>>>>>>> ([e-mail]); [e-mail]; Henning Rogge
>>>>>>>>>>> ([e-mail]); [e-mail]; [e-mail]
>>>>>>>>>>> Subject: RE: notes DLEP meeting @ IETF88
>>>>>>>>>>> 
>>>>>>>>>>> I leave that up to the DLEP veterans to decide. They may want to
>>>>>>>>>>> "redact" these notes a bit ;-)
>>>>>>>>>>> 
>>>>>>>>>>> Ronald
>>>>>>>>>>> 
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Ulrich Herberg [mailto:[e-mail]]
>>>>>>>>>>>> Sent: vrijdag 8 november 2013 2:44
>>>>>>>>>>>> To: Velt, R. (Ronald) in 't
>>>>>>>>>>>> Cc: [e-mail]; [e-mail];
>>>>>>>>>>>> [e-mail]; [e-mail]; Teco Boot
>>>>>>>>>>>> (teco@inf- net.nl); [e-mail]; Henning Rogge
>>>>>>>>>>>> ([e-mail]); [e-mail]; [e-mail]
>>>>>>>>>>>> Subject: Re: notes DLEP meeting @ IETF88
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks. Do you want to send them out to the MANET mailing list?
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, Nov 7, 2013 at 5:40 PM, Velt, R. (Ronald) in 't
>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Please find attached my *raw* notes of our meeting on Tuesday.
>>>>>>>>>>>> Disclaimer: Neither completeness nor correctness are guaranteed.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Ronald in 't Velt
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ----
>>>>>>>>>>>>> TNO Technical Sciences
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Network Technology dept.
>>>>>>>>>>>>> ----
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Dit bericht kan informatie bevatten die niet voor u is bestemd.
>>>>>>>>>>>>> Indien u niet
>>>>>>>>>>>> de geadresseerde bent of dit bericht abusievelijk aan u is
>>>>>>>>>>>> toegezonden, wordt u verzocht dat aan de afzender te melden en
>>>>>>>>>>>> het bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid
>>>>>>>>>>>> voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt
>>>>>>>>>>>> en voor schade, van welke aard ook, die verband houdt met
>>>>>>>>>>>> risico's
>>>>> verbonden aan het elektronisch verzenden van berichten.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> This message may contain information that is not intended for
>>>>> you.
>>>>>>>>>>>>> If you
>>>>>>>>>>>> are not the addressee or if this message was sent to you by
>>>>>>>>>>>> mistake, you are requested to inform the sender and delete the
>>>>>>>>>>>> message. TNO accepts no liability for the content of this
>>>>>>>>>>>> e-mail, for the manner in which you use it and for damage of any
>>>>>>>>>>>> kind resulting from the risks inherent to the electronic
>>>>> transmission of messages.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Dit bericht kan informatie bevatten die niet voor u is bestemd.
>>>>> Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is
>>>>> toegezonden, wordt u verzocht dat aan de afzender te melden en het
>>>>> bericht
>>>>> te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van
>>>>> deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke
>>>>> aard ook, die verband houdt met risico's verbonden aan het elektronisch
>>>>> verzenden van berichten.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> This message may contain information that is not intended for
>>>>>>>>>>> you.
>>>>> If you are not the addressee or if this message was sent to you by
>>>>> mistake, you are requested to inform the sender and delete the message.
>>>>> TNO accepts no liability for the content of this e-mail, for the manner
>>>>> in
>>>>> which you use it and for damage of any kind resulting from the risks
>>>>> inherent to the electronic transmission of messages.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> manet-dlep-rg mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>>>> The information contained within this e-mail and any files attached to
>>>> this e-mail is private and in addition may include commercially sensitive
>>>> information. The contents of this e-mail are for the intended recipient only
>>>> and therefore if you wish to disclose the information contained within this
>>>> e-mail or attached files, please contact the sender prior to any such
>>>> disclosure. If you are not the intended recipient, any disclosure, copying
>>>> or distribution is prohibited. Please also contact the sender and inform
>>>> them of the error and delete the e-mail, including any attached files from
>>>> your system. Cassidian Limited, Registered Office : Quadrant House, Celtic
>>>> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036
>>>> http://www.cassidian.com
>>>> _______________________________________________
>>>> manet-dlep-rg mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>>> 
>>> 
>>> _______________________________________________
>>> manet-dlep-rg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>>> 
>> 
>> 
>> 
>> --
>> We began as wanderers, and we are wanderers still. We have lingered
>> long enough on the shores of the cosmic ocean. We are ready at last to
>> set sail for the stars - Carl Sagan
> 
> _______________________________________________
> manet-dlep-rg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
> _______________________________________________
> manet-dlep-rg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg