Subject: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

From: "Jon Shallow" <[email-masked]>
Date: Wed, 1 Aug 2018 17:22:44 +0100

Hi there

RFC 7641: 4.5 Transmission
.
   A server that transmits notifications mostly in non-confirmable
   messages MUST send a notification in a confirmable message instead of
   a non-confirmable message at least every 24 hours.  This prevents a
   client that went away or is no longer interested from remaining in
   the list of observers indefinitely.

RFC 7641: 4.5.1. Congestion Control 
..
In order not to cause congestion, servers MUST strictly limit the number of
simultaneous outstanding notifications/responses that they transmit to a
given
client to NSTART (1 by default; see Section 4.7 of RFC 7252 [RFC7252]).
An outstanding notification/response is either a confirmable message for
which
an acknowledgement has not yet been received and whose last retransmission
attempt has not yet timed out or a non-confirmable message for which the
waiting time that results from the following rate-limiting rules has not yet
elapsed.

RFC 7641: 3.5.  Transmission
.
   An acknowledgement message signals to the server that the client is
   alive and interested in receiving further notifications; if the
   server does not receive an acknowledgement in reply to a confirmable
   notification, it will assume that the client is no longer interested
   and will eventually remove the associated entry from the list of
   observers (Section 4.5).

There are 2 things that immediately come out of this.

1)      If a Ping 0.00 messages is currently active (no response yet
received), and an observe is triggered and it happens to be the one every 24
hrs, it will get dropped / delayed

2)      What happens when the observe response for a mitigation status
(change) is chosen by the underlying CoAP library to be a CON instead of a
NON during a mitigation - which fails because of the attack and the observer
gets deleted. 

Are we happy with this happening?

FYI - the libcoap I am using does this CON every 5 NON observe response
transmissions.  Statistically less chance with once every 24 hrs, but..

Regards

Jon

---

From: <[email-masked]>
Date: Thu, 2 Aug 2018 07:06:58 +0000

Hi Jon,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : mercredi 1 août 2018 18:23
À : [email-masked]
Objet : [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi there

...

RFC 7641: 4.5.1. Congestion Control
....
In order not to cause congestion, servers MUST strictly limit the number of
simultaneous outstanding notifications/responses that they transmit to a given
client to NSTART (1 by default; see Section 4.7 of RFC 7252 [RFC7252]).
An outstanding notification/response is either a confirmable message for which
an acknowledgement has not yet been received and whose last retransmission
attempt has not yet timed out or a non-confirmable message for which the
waiting time that results from the following rate-limiting rules has not yet
elapsed.

...

1)      If a Ping 0.00 messages is currently active (no response yet received), and an observe is triggered and it happens to be the one every 24 hrs, it will get dropped / delayed

[Med] That is IMHO a very corner case which may not be problematic if the state was already sent in a previous message. As a reminder, 7641:

"It also MAY choose to send
   more than one notification for the same resource state."

2)      What happens when the observe response for a mitigation status (change) is chosen by the underlying CoAP library to be a CON instead of a NON during a mitigation - which fails because of the attack and the observer gets deleted.

[Med] Given that notification and message types are application-dependent, it is up to the DOTS application (via interaction with coap library) to control this and especially to implement the following behaviour (from the signal channel draft):

   "the DOTS agents MUST behave differently to

   handle message transmission and DOTS session liveliness during link

   saturation"

FYI - the libcoap I am using does this CON every 5 NON observe response transmissions.  Statistically less chance with once every 24 hrs, but..

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 2 Aug 2018 09:14:41 +0100

Hi Med,

See inline.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 02 August 2018 08:07
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses
that occasionally have to be confirmable (mitigation)

Hi Jon, 

Please see inline. 

Cheers,

Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : mercredi 1 août 2018 18:23
À : [email-masked]
Objet : [Dots] Signal Channel WGLC: Non Confirmable observe responses that
occasionally have to be confirmable (mitigation)

Hi there

…

….

…

[Med] That is IMHO a very corner case which may not be problematic if the
state was already sent in a previous message. As a reminder, 7641: 

“It also MAY choose to send

   more than one notification for the same resource state.”

Jon> Unfortunately, the corner case is when there is a change of state and
the underlying libcoap elects that the current observe response has to be a
CON type.  I guess that the DOTS implementation could trigger multiple
observe responses (with a time gap in between) per resource state change.  I
think my preference would be to trigger a observe response every 30 seconds
or so, and an immediate observe response on a state change.

2)      What happens when the observe response for a mitigation status
(change) is chosen by the underlying CoAP library to be a CON instead of a
NON during a mitigation – which fails because of the attack and the observer
gets deleted. 

[Med] Given that notification and message types are application-dependent,
it is up to the DOTS application (via interaction with coap library) to
control this and especially to implement the following behaviour (from the
signal channel draft):  

   “the DOTS agents MUST behave differently to
   handle message transmission and DOTS session liveliness during link
   saturation"

Jon> Agreed that agents are to behave differently.  It is the underlying
coap library layer that, if following the RFC7641 rules, that deletes the
current observer (not the apps responsibility) and the DOTS client has no
knowledge that the observer subscription has gone away.  The DOTS server
potentially can find that the observe has gone away and possibly recreate
it, but libcoap I am using is not really set up for that.

Jon> I need to code in some sort of recovery logic to re-instate observe
etc. when under traffic loss scenarios to make things more robust.

FYI – the libcoap I am using does this CON every 5 NON observe response
transmissions.  Statistically less chance with once every 24 hrs, but..

Regards

Jon

---

From: <[email-masked]>
Date: Thu, 2 Aug 2018 09:09:17 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : jeudi 2 août 2018 10:15
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi Med,

See inline.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 02 August 2018 08:07
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi Jon,

Please see inline.

Cheers,
Med

Hi there

"It also MAY choose to send
   more than one notification for the same resource state."
Jon> Unfortunately, the corner case is when there is a change of state and the underlying libcoap elects that the current observe response has to be a CON type.  I guess that the DOTS implementation could trigger multiple observe responses (with a time gap in between) per resource state change.  I think my preference would be to trigger a observe response every 30 seconds or so, and an immediate observe response on a state change.

[Med] Seems reasonable if the state last more than 2mn. I tend to leave this implementation-specific. Are you fine with that?

   saturation"

Jon> Agreed that agents are to behave differently.  It is the underlying coap library layer that, if following the RFC7641 rules, that deletes the current observer (not the apps responsibility) and the DOTS client has no knowledge that the observer subscription has gone away.  The DOTS server potentially can find that the observe has gone away and possibly recreate it, but libcoap I am using is not really set up for that.
Jon> I need to code in some sort of recovery logic to re-instate observe etc. when under traffic loss scenarios to make things more robust.

[Med] Looks good to me. Further, it adheres to the text excerpt provided above.

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 2 Aug 2018 10:19:27 +0000

RFC7641 seems to be mandating the use of confirmable message for notifications to handle amplification attack because CoAP does not mandate DTLS, client authentication and liveliness checks.  The amplification attack is not possible in our scenario (DTLS handles amplification attack), and the security considerations section in RFC7641 discusses confirmable messages interspersed with non-confirmable messages only when the client is not authenticated.

It looks like a bug in the coap library ?

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 2 Aug 2018 14:57:47 +0100

Hi Tiru,

The Security section explains their thinking behind why CON has to get sent periodically for an insecure connection.

However, 4.5 does use MUST for the periodic CON every 24hrs or less, so am not convinced there is a bug in the CoAP library as it is dealing with the MUST in the general text body.  Likewise, I am not convinced that the library is doing the wrong thing in deleting the observe subscription.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 August 2018 11:19
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 2 Aug 2018 14:09:19 +0000

Hi Jon,

If DTLS, client authentication and liveliness checks are used b/w the peers, I don’t see any benefit (or attack blocked) by sending confirmable notifications.

-Tiru

From: Dots <[email-masked]> On Behalf Of Jon Shallow
Sent: Thursday, August 2, 2018 7:28 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi Tiru,

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 August 2018 11:19
To: [email-masked]<mailto:[email-masked]>; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 2 Aug 2018 15:10:05 +0100

Hi Med,

See inline Jon1.

Regards

Jon

Hi there

[Med] Seems reasonable if the state last more than 2mn. I tend to leave this
implementation-specific. Are you fine with that?

Jon> The advantage for me it that if the DOTS server periodically sends down
status updates, status can be tracked on the DOTS client (and possibly
reported in slow real-time) and helps towards any decisions about efficacy
updates.  If the (other implementation) DOTS server does not do this, then
the DOTS client will have to periodically request status updates to help
here.

Jon> It is a bit late in the day to have a refresh period variable that the
DOTS client can request.

[Med] Looks good to me. Further, it adheres to the text excerpt provided
above.

Jon> This comes back to the question Andrew M raised at IETF101 about how
robust is the logic when handling traffic loss – has it really been stress
tested?

Jon> This will require extra coding in the app to recover from these corner
cases.  Not sure how to add this to the signal draft other than to remind
the reader / implementer to be careful about implementing recovery under
packet loss scenarios.

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 2 Aug 2018 15:17:23 +0100

Hi Tiru,

I agree totally with you – the CON is not required and gets in the way.  However, do we need to add text to override the RFC7641 MUST CON requirement for mitigation status updates?

I have found that in libcoap, the PDU is built (with type CON or NON) before calling the DOTS server’s GET handler to cause the observe response to get sent back.  The GET handler can change the PDU type to NON and so the PDU is always sent as NON.  So I can override the CON if needed.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 August 2018 15:09
To: Jon Shallow; [email-masked]; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi Jon,

-Tiru

  _____  

Hi Tiru,

Regards

Jon

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 2 Aug 2018 14:32:34 +0000

Hi Jon,

Nice way to fix the problem in libcoap ☺
Adding a implementation note should suffice (otherwise this specification will have to update RFC7641).

-Tiru

From: Jon Shallow <[email-masked]>
Sent: Thursday, August 2, 2018 7:47 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 August 2018 15:09
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi Jon,

-Tiru

From: Dots <[email-masked]<mailto:[email-masked]>> On Behalf Of Jon Shallow
Sent: Thursday, August 2, 2018 7:28 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Regards

Jon

-Tiru

---

From: <[email-masked]>
Date: Thu, 2 Aug 2018 14:43:18 +0000

Re-,

Even if RFC7641 is supported as it is, the text we do have in the draft nullifies its effect when an attack is ongoing.

Unless this is strongly justified, I would like to avoid having notes that would be seen as an update to 7641.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : jeudi 2 août 2018 16:33
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi Jon,

-Tiru

Regards

Jon

Hi Jon,

-Tiru

Regards

Jon

-Tiru

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 06:02:17 +0000

Re-,

After thinking about this more and discussing with Tiru, I suggest to make this modification which basically reminds that the type of the message is application-dependent and asks DOTS applications to always have control over it:

OLD:
   Unidirectional notifications within the bidirectional signal channel
   allows unsolicited message delivery, enabling asynchronous
   notifications between the agents.  Due to the higher likelihood of
   packet loss during a DDoS attack, the DOTS server periodically sends
   attack mitigation status to the DOTS client and also notifies the
   DOTS client whenever the status of the attack mitigation changes.  If
   the DOTS server cannot maintain an RTT estimate, it SHOULD NOT send
   more than one unsolicited notification every 3 seconds, and SHOULD
   use an even less aggressive rate whenever possible (case 2 in
   Section 3.1.3 of [RFC8085]<https://tools.ietf.org/html/rfc8085#section-3.1.3>).

NEW:
   Unidirectional notifications within the bidirectional signal channel
   allows unsolicited message delivery, enabling asynchronous
   notifications between the agents.  [RFC7641] indicates that (1) a
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   notification can be sent in a confirmable or a non-confirmable
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   message, and (2) the message type used is typically application
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   dependent and may be determined by the server for each notification
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   individually.  For DOTS application, the message type is always set
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   to non-confirmable even if the underlying COAP library elects a
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   notification to be sent in a confirmable message.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   Due to the higher likelihood of packet loss during a DDoS attack, the
   DOTS server periodically sends attack mitigation status to the DOTS
   client and also notifies the DOTS client whenever the status of the
   attack mitigation changes.  If the DOTS server cannot maintain an RTT
   estimate, it SHOULD NOT send more than one unsolicited notification
   every 3 seconds, and SHOULD use an even less aggressive rate whenever
   possible (case 2 in Section 3.1.3 of [RFC8085]).

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 2 août 2018 16:43
À : Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]
Objet : Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Re-,

Cheers,
Med

Hi Jon,

-Tiru

Regards

Jon

Hi Jon,

-Tiru

Regards

Jon

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Aug 2018 08:17:28 +0100

Hi Med,

Do we want to be more emphatic as in

Old

For DOTS application, the message type is always set

New

For DOTS application, the message type MUST always be set

Another comment is that this is in the mitigation notifications section – configuration notifications are currently CON  (4.3 DOTS Signal Channel Session Configuration – Requests and responses are deemed reliable by marking then as Confirmable (CON) messages).

4.5.3 Configuration Freshness and Notifications

   If an Observe Option set to 0 is included in the configuration

   request, the DOTS server sends notifications of any configuration

   change (Section 4.2 of [RFC7641]).

Do the same (always NON) rules apply to configuration notifications?

If not, then for clarity it is only for mitigations

Old

Unidirectional notifications

New

Unidirectional mitigation notifications

Otherwise the configuration text needs to be updated to state notifications are NON.

Finally, “DOTS application” is not defined anywhere I can find.  As it is always the server,

Old

For DOTS application, the message type 

New

For DOTS server, the message type

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 03 August 2018 07:02
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Re-,

 

OLD:

    <https://tools.ietf.org/html/rfc8085#section-3.1.3> Section 3.1.3 of [RFC8085]).

NEW:

 

Cheers,

Med

Re-,

Cheers,

Med

Hi Jon,

Nice way to fix the problem in libcoap J

-Tiru

  _____  

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

  _____  

Hi Tiru,

Regards

Jon

-Tiru

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 07:43:53 +0000

Hi Jon,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 09:17
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi Med,

[Med] OK.

[Med] OK. The initial text is within the scope of the section: mitigation notifications.

[Med] OK. “application” is used in reference to 7641.

Regards

Jon

Re-,

OLD:

NEW:

Cheers,
Med

Re-,

Cheers,
Med

Hi Jon,

-Tiru

Regards

Jon

Hi Jon,

-Tiru

Regards

Jon

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Aug 2018 08:58:22 +0100

Hi Med,

See inline.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 03 August 2018 08:44
To: Jon Shallow; Konda, Tirumaleswar Reddy; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi Jon, 

Please see inline. 

Cheers,

Med

Hi Med,

Old

New

[Med] OK.

Old

New

Jon> Agreed – it is within ‘mitigation notifications’.  I was looking for clarity in the text so that there was no ambiguity for how ‘configuration notifications’ are to be done when someone reads that there is a NON override in the text:-

Jon> For DOTS server application, the message type MUST always be set

 

Old

New

Jon> “DOTS server application” works for me.

~Jon

Regards

Jon

Re-,

 

OLD:

NEW:

 

Cheers,

Med

Re-,

Cheers,

Med

Hi Jon,

-Tiru

  _____  

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

  _____  

Hi Tiru,

Regards

Jon

-Tiru

---

From: <[email-masked]>
Date: Fri, 3 Aug 2018 08:30:02 +0000

Jon,

I think we are done for this one.

The diff is available at: https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-21.txt%20draft-ietf-dots-signal-channel-22.pdf

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 09:58
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi Med,

See inline.

Regards

Jon

Hi Jon,

Please see inline.

Cheers,
Med

Hi Med,

[Med] OK.

Regards

Jon

Re-,

OLD:

NEW:

Cheers,
Med

Re-,

Cheers,
Med

Hi Jon,

-Tiru

Regards

Jon

Hi Jon,

-Tiru

Regards

Jon

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Aug 2018 09:37:20 +0100

Hi Med,

Yes, the updated paragraph is good for me and handles the enforcement of the NON requirement.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 03 August 2018 09:30
To: Jon Shallow; Konda, Tirumaleswar Reddy; [email-masked]
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Jon, 

Cheers,

Med

Hi Med,

See inline.

Regards

Jon

Hi Jon, 

Please see inline. 

Cheers,

Med

Hi Med,

Old

New

[Med] OK.

Old

New

 

Old

New

~Jon

Regards

Jon

Re-,

 

OLD:

NEW:

 

Cheers,

Med

Re-,

Cheers,

Med

Hi Jon,

-Tiru

  _____  

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

  _____  

Hi Tiru,

Regards

Jon

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 3 Aug 2018 09:36:29 +0000

+1

-Tiru

From: Jon Shallow <[email-masked]>
Sent: Friday, August 3, 2018 2:07 PM
To: [email-masked]; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 03 August 2018 09:30
To: Jon Shallow; Konda, Tirumaleswar Reddy; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Jon,

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 09:58
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi Med,

See inline.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 03 August 2018 08:44
To: Jon Shallow; Konda, Tirumaleswar Reddy; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi Jon,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 09:17
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi Med,

[Med] OK.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 03 August 2018 07:02
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Re-,

OLD:

NEW:

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : jeudi 2 août 2018 16:43
À : Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Re-,

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : jeudi 2 août 2018 16:33
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Hi Jon,

-Tiru

From: Jon Shallow <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, August 2, 2018 7:47 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Signal Channel WGLC: Non Confirmable observe responses that occasionally have to be confirmable (mitigation)

Regards

Jon

Hi Jon,

-Tiru

Regards

Jon

-Tiru