Subject: [Dots] Signal Observe implementation issue

From: "Jon Shallow" <[email-masked]>
Date: Thu, 8 Mar 2018 09:03:16 -0000

Hi there,

We currently cannot support multiple Observe requests per client.  A simple
change fixes the issue.

In the signal-17 draft, we have 

     Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "v1"

     Uri-Path: "mitigate"

     Uri-Query: "cuid=dz6pHjaADkaFTbjr0JGBpw"

     Uri-Query: "mid=12332"

     Observe: 0

       Figure 12: GET to Retrieve a Specific DOTS Mitigation Request

Where the resource to Observe is a combination of the Uri-Path: and
Uri-Query.  RFC7252 supports have the 'request URI' as a combination of
both, so this is legal.  

However, in the libcoap I am using, it only supports one Query per Token per
Resource (the resource in this case being ".wellknown/dots/v1/mitigate") for
Observe.  The Token should remain constant as per 

RFC7252 5.3.1.  Token

..

   The client SHOULD generate tokens in such a way that tokens currently

   in use for a given source/destination endpoint pair are unique

and then

RFC7641 4.1.  Request

..

   The entry in the list of observers is keyed by the client endpoint

   and the token specified by the client in the request.  If an entry

   with a matching endpoint/token pair is already present in the list

   (which, for example, happens when the client wishes to reinforce its

   interest in a resource), the server MUST NOT add a new entry but MUST

   replace or update the existing one.

So, a subsequent different Query using the same Token is overwritten - the
previous Observe is deleted and the new one invoked.  The libcoap is correct
in what it is doing.

Can we therefore have this as (to support the monitoring of multiple
mitigation requests per client)

4.4.2

.

  'cuid' is a mandatory Uri-Path parameter for GET requests.

   Uri-Path parameters with empty values MUST NOT be present in a

   request.

   The same considerations for manipulating 'cdid' parameter by server-

   domain DOTS gateways specified in Section 4.4.1 MUST be followed for

   GET requests.

   If the DOTS server does not find the 'mid' Uri-Path value conveyed

   in the GET request in its configuration data for the requesting DOTS

   client, it MUST respond with a 4.04 (Not Found) error response code.

   Likewise, the same error MUST be returned as a response to a request

   to retrieve all mitigation records (i.e., 'mid' Uri-Path is not

   defined) of a given DOTS client if the DOTS server does not find any

   mitigation record for that DOTS client.  As a reminder, a DOTS client

   is identified by its identity (e.g., client certificate, 'cuid') and

   optionally the 'cdid'

.

     Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "v1"

     Uri-Path: "mitigate"

     Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: "mid=12332"

     Observe: 0

       Figure 12: GET to Retrieve a Specific DOTS Mitigation Request

And for consistency

4.4.4

.

   'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE

   requests.

     Header: DELETE (Code=0.04)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "v1"

     Uri-Path: "mitigate"

     Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: "mid=123"

                   Figure 16: Withdraw a DOTS Mitigation

4.5.3

.

     Header: DELETE (Code=0.04)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "v1"

     Uri-Path: "config"

     Uri-Path: "sid=123"

                      Figure 22: DELETE Configuration

Regards

Jon

---

From: kaname nishizuka <[email-masked]>
Date: Fri, 9 Mar 2018 11:56:12 +0900

Hi WG,

This is a significant issue and I strongly support this proposal.

thanks,
Kaname

On 2018/03/08 18:03, Jon Shallow wrote:
>
> Hi there,
>
> We currently cannot support multiple Observe requests per client.  A simple change fixes the issue.
>
> Where the resource to Observe is a combination of the Uri-Path: and Uri-Query.  RFC7252 supports have the ‘request URI’ as a combination of both, so this is legal.
>
> However, in the libcoap I am using, it only supports one Query per Token per Resource (the resource in this case being “.wellknown/dots/v1/mitigate”) for Observe. The Token should remain constant as per
>
> RFC7252 5.3.1.  Token
>
> ..
>
> ….
> So, a subsequent different Query using the same Token is overwritten – the previous Observe is deleted and the new one invoked.  The libcoap is correct in what it is doing.
>
> Can we therefore have this as (to support the monitoring of multiple mitigation requests per client)
>
> 4.4.2
>
> …
>
>   'cuid' is a mandatory Uri-*Path*parameter for GET requests.
>
>    Uri-*Path*parameters with empty values MUST NOT be present in a
>
>    request.
>
>    If the DOTS server does not find the 'mid' Uri-*Path*value conveyed
>
>    to retrieve all mitigation records (i.e., 'mid' Uri-*Path*is not
>
> …
>      Uri-*Path*: "cuid=dz6pHjaADkaFTbjr0JGBpw"
>
>      Uri-*Path*: "mid=12332"
>
>      Observe: 0
>
> …
>    'cuid' and 'mid' are mandatory Uri-*Path* parameters for DELETE
>
>    requests.
>
>      Uri-*Path*: "cuid=dz6pHjaADkaFTbjr0JGBpw"
>
>      Uri-*Path*: "mid=123"
>
> …
>      Uri-*Path*: "sid=123"
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Fri, 9 Mar 2018 04:18:02 +0000

On Mar 8, 2018, at 9:56 PM, kaname nishizuka <[email-masked]<mailto:[email-masked]>> wrote:

Hi WG,

+1

andrew

     Header: GET (Code=0.01)
     Uri-Host: "host"
     Uri-Path: ".well-known"
     Uri-Path: "dots"
     Uri-Path: "v1"
     Uri-Path: "mitigate"

RFC7252 5.3.1.  Token
..

and then

RFC7641 4.1.  Request
….

4.4.2
…

And for consistency

4.4.4
…

4.5.3
…

Regards

Jon

_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots

_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Fri, 9 Mar 2018 06:51:23 +0000

Hi Jon,

Seems pragmatic. Please check at: https://github.com/boucadair/draft-ietf-dots-signal-channel

In the meantime RFC 7252 says the following:

   A token is intended for use as a client-local identifier for
   differentiating between concurrent requests (see Section 5.3<https://tools.ietf.org/html/rfc7252#section-5.3>); it
   could have been called a "request ID".

An implementation that follows this "spirit" would assign distinct tokens for concurrent requests involving the same endpoints pair.

IMO, the SHOULD text is broken because it assumes that only one request is likely to be active between two endpoints.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : jeudi 8 mars 2018 10:03
À : [email-masked]
Objet : [Dots] Signal Observe implementation issue

Hi there,

     Header: GET (Code=0.01)
     Uri-Host: "host"
     Uri-Path: ".well-known"
     Uri-Path: "dots"
     Uri-Path: "v1"
     Uri-Path: "mitigate"

Where the resource to Observe is a combination of the Uri-Path: and Uri-Query.  RFC7252 supports have the 'request URI' as a combination of both, so this is legal.

However, in the libcoap I am using, it only supports one Query per Token per Resource (the resource in this case being ".wellknown/dots/v1/mitigate") for Observe.  The Token should remain constant as per

RFC7252 5.3.1.  Token
..

and then

RFC7641 4.1.  Request
....

So, a subsequent different Query using the same Token is overwritten - the previous Observe is deleted and the new one invoked.  The libcoap is correct in what it is doing.

4.4.2
...

...

And for consistency

4.4.4
...

4.5.3
...

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 9 Mar 2018 09:14:32 -0000

Hi Med,

I agree with you that the SHOULD is causing confusion, and a better text for
RFC7252 could read

   in use for a given source/destination endpoint are unique per request

However, I do think that the changes to the draft are the right way to go as
it gets rid of any possible issues here.

[My client code now uses a different tokens for each request]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 09 March 2018 06:51
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Observe implementation issue

Hi Jon, 

Seems pragmatic. Please check at:
https://github.com/boucadair/draft-ietf-dots-signal-channel 

   differentiating between concurrent requests (see
<https://tools.ietf.org/html/rfc7252#section-5.3> Section 5.3); it

An implementation that follows this “spirit” would assign distinct tokens
for concurrent requests involving the same endpoints pair. 

IMO, the SHOULD text is broken because it assumes that only one request is
likely to be active between two endpoints. 

Cheers,

Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : jeudi 8 mars 2018 10:03
À : d <mailto:[email-masked]> [email-masked]
Objet : [Dots] Signal Observe implementation issue

Hi there,

     Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "v1"

     Uri-Path: "mitigate"

     Uri-Query: "mid=12332"

     Observe: 0

Where the resource to Observe is a combination of the Uri-Path: and
Uri-Query.  RFC7252 supports have the ‘request URI’ as a combination of
both, so this is legal.  

However, in the libcoap I am using, it only supports one Query per Token per
Resource (the resource in this case being “.wellknown/dots/v1/mitigate”) for
Observe.  The Token should remain constant as per 

RFC7252 5.3.1.  Token

..

and then

RFC7641 4.1.  Request

….

So, a subsequent different Query using the same Token is overwritten – the
previous Observe is deleted and the new one invoked.  The libcoap is correct
in what it is doing.

4.4.2

…

   request.

   GET requests.

   optionally the 'cdid'

…

     Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "v1"

     Uri-Path: "mitigate"

     Uri-Path: "mid=12332"

     Observe: 0

And for consistency

4.4.4

…

   requests.

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "v1"

     Uri-Path: "mitigate"

     Uri-Path: "mid=123"

4.5.3

…

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "v1"

     Uri-Path: "config"

     Uri-Path: "sid=123"

Regards

Jon

---

From: <[email-masked]>
Date: Fri, 9 Mar 2018 09:37:41 +0000

Re-,

Agree. This is why I went with the change in the draft.

FWIW, I submitted an errata available at https://www.rfc-editor.org/errata_search.php?rfc=7252 (Errata ID: 5284).

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 9 mars 2018 10:15
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] Signal Observe implementation issue

Hi Med,

I agree with you that the SHOULD is causing confusion, and a better text for RFC7252 could read

However, I do think that the changes to the draft are the right way to go as it gets rid of any possible issues here.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 09 March 2018 06:51
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Observe implementation issue

Hi Jon,

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : jeudi 8 mars 2018 10:03
À : [email-masked]<mailto:[email-masked]>
Objet : [Dots] Signal Observe implementation issue

Hi there,

     Header: GET (Code=0.01)
     Uri-Host: "host"
     Uri-Path: ".well-known"
     Uri-Path: "dots"
     Uri-Path: "v1"
     Uri-Path: "mitigate"

RFC7252 5.3.1.  Token
..

and then

RFC7641 4.1.  Request
....

4.4.2
...

And for consistency

4.4.4
...

4.5.3
...

Regards

Jon