Subject: [Dots] DOTS signal and resource path discovery

From: "Jon Shallow" <[email-masked]>
Date: Thu, 26 Oct 2017 14:54:54 +0100

Hi there

Following on from the recent virtual conference with discussions about what
should be the signal request path (should .wellknown be included in it
etc.).

RFC7252 7.1 Service Discovery

"The CoAP default port number 5683 MUST be supported by a server that

   offers resources for resource discovery (see Section 7.2 below) and

   SHOULD be supported for providing access to other resources.  The

   default port number 5684 for DTLS-secured CoAP MAY be supported by a

   server for resource discovery and for providing access to other

   resources.  In addition, other endpoints may be hosted at other

   ports, e.g., in the dynamic port space."

DOTS is not hosting non (D)TLS COAP, and so we will be breaking the MUST for
port 5683.  I propose that we do the following for the signal channel spec
and support resource discovery.

1)      Update the 2 paths (signal and configuration) in the specification,
when can then be the default values.

     Uri-Path: "version"

     Uri-Path: "dots-signal"

     Uri-Path: "signal"

To

     Uri-Path: "v1"                              << We are v1 as described
in the text

     Uri-Path: "dots-signal"

     Uri-Path: "mitigation"                 << overloaded use of signal,
this is the mitigate part of dots-signal

               And

     Uri-Path: "version"

     Uri-Path: "dots-signal"

     Uri-Path: "config"

To

     Uri-Path: "v1"

     Uri-Path: "dots-signal"

     Uri-Path: "configuration"

2)      Add in the following

===============================================

5.7 Resource Discovery

As per [RFC7252 7.2 Resource Discovery] the DOTS server SHOULD support the
CoRe Link Format of discoverable resource as described in [RFC6690], except
where fully manual configuration is desired.

The two discoverable resources that SHOULD be available to a DOTS client are
"mitigation" and "configuration".  If the appropriate URI paths are
returned, the DOTS client MUST use them, overriding any default
configuration.  A DOTS client SHOULD do a resource discovery, which is done
by a GET request to "/.wellknown/core"

Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".wellknown"

     Uri-Path: "core"

Figure xxx: GET to retrieve dots-signal resources

Content-Format:application/link-format

<v1/dots-signal/mitigation>;rt="mitigation";title="DOTS Signal
Mitigation";ct=60,

</v1/dots-signal/configuration>;rt="configuration";title="DOTS Signal
Configuration";ct=60

Figure yyy: Example response to GET to retrieve dots-signal resources

As to CoAP being on different ports on the server hosting DOTS server (or
DOTS gateway), this may have to be configurable in the DOTS clients, or
configurable on the Data Channel as an extension to

"The DOTS client will perform the root resource discovery procedure

   discussed in Section 3.1 of [RFC8040] to determine the root of the

   RESTCONF API.  After discovering the RESTCONF API root, the DOTS

   client uses this value as the initial part of the path in the request

   URI, in any subsequent request to the DOTS server.  The DOTS server

   may support retrieval of the YANG modules it supports (Section 3.7 in

   [RFC8040]), for example, a DOTS client may use RESTCONF to retrieve

   the company proprietary YANG modules supported by the DOTS server."

Regards

Jon

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Thu, 26 Oct 2017 17:01:43 +0300

Hi,

It's not ".wellknown", it's ".well-known", note "-".

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: [email-masked]
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

26 окт. 2017 г. 4:55 ПП пользователь "Jon Shallow" <
[email-masked]> написал:

Hi there

“The CoAP default port number 5683 MUST be supported by a server that

   ports, e.g., in the dynamic port space.”

DOTS is not hosting non (D)TLS COAP, and so we will be breaking the MUST
for port 5683.  I propose that we do the following for the signal channel
spec and support resource discovery.

     Uri-Path: "version"

     Uri-Path: "dots-signal"

     Uri-Path: "signal"

To

     Uri-Path: "dots-signal"

               And

     Uri-Path: "version"

     Uri-Path: "dots-signal"

     Uri-Path: "config"

To

     Uri-Path: "v1"

     Uri-Path: "dots-signal"

2)      Add in the following

5.7 Resource Discovery

The two discoverable resources that SHOULD be available to a DOTS client
are “mitigation” and “configuration”.  If the appropriate URI paths are
returned, the DOTS client MUST use them, overriding any default
configuration.  A DOTS client SHOULD do a resource discovery, which is done
by a GET request to “/.wellknown/core”

Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".wellknown"

     Uri-Path: "core"

“The DOTS client will perform the root resource discovery procedure

   the company proprietary YANG modules supported by the DOTS server.”

Regards

Jon

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

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 26 Oct 2017 15:26:32 +0100

Oops – well spotted – thanks!

Text below corrected.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of Artyom Gavrichenkov
Sent: 26 October 2017 15:02
To: Jon Shallow
Cc: [email-masked]
Subject: Re: [Dots] DOTS signal and resource path discovery

Hi,

| Artyom Gavrichenkov

26 окт. 2017 г. 4:55 ПП пользователь "Jon Shallow" <[email-masked]> написал:

Hi there

Following on from the recent virtual conference with discussions about what should be the signal request path (should .wellknown be included in it etc.).

DOTS is not hosting non (D)TLS COAP, and so we will be breaking the MUST for port 5683.  I propose that we do the following for the signal channel spec and support resource discovery.

1)      Update the 2 paths (signal and configuration) in the specification, when can then be the default values.

     Uri-Path: "version"

     Uri-Path: "dots-signal"

     Uri-Path: "signal"

To

     Uri-Path: "v1"                              << We are v1 as described in the text

     Uri-Path: "dots-signal"

     Uri-Path: "mitigation"                 << overloaded use of signal, this is the mitigate part of dots-signal

               And

     Uri-Path: "version"

     Uri-Path: "dots-signal"

     Uri-Path: "config"

To

     Uri-Path: "v1"

     Uri-Path: "dots-signal"

2)      Add in the following

5.7 Resource Discovery

As per [RFC7252 7.2 Resource Discovery] the DOTS server SHOULD support the CoRe Link Format of discoverable resource as described in [RFC6690], except where fully manual configuration is desired.

The two discoverable resources that SHOULD be available to a DOTS client are “mitigation” and “configuration”.  If the appropriate URI paths are returned, the DOTS client MUST use them, overriding any default configuration.  A DOTS client SHOULD do a resource discovery, which is done by a GET request to “/.well-known/core”

Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "core"

<v1/dots-signal/mitigation>;rt="mitigation";title="DOTS Signal Mitigation";ct=60,

</v1/dots-signal/configuration>;rt="configuration";title="DOTS Signal Configuration";ct=60

 

As to CoAP being on different ports on the server hosting DOTS server (or DOTS gateway), this may have to be configurable in the DOTS clients, or configurable on the Data Channel as an extension to

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 26 Oct 2017 14:29:52 +0000

I don't see the need to complicate the DOTS signal channel by introducing resource discovery (see https://tools.ietf.org/html/rfc5785),

Many protocols like EST use well-known locations (e.g. https://www.example.com/.well-known/est/) where uri-suffix 'est' is allocated by the IANA to avoid collisions.

We can consider a similar approach and request IANA to allocate uri-suffix 'dots'.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Thursday, October 26, 2017 7:25 PM
To: [email-masked]
Subject: [Dots] DOTS signal and resource path discovery

Hi there

     Uri-Path: "version"

     Uri-Path: "dots-signal"

     Uri-Path: "signal"

To

     Uri-Path: "dots-signal"

     Uri-Path: "dots-signal"

     Uri-Path: "config"

To

     Uri-Path: "v1"

     Uri-Path: "dots-signal"

2)      Add in the following

The two discoverable resources that SHOULD be available to a DOTS client are "mitigation" and "configuration".  If the appropriate URI paths are returned, the DOTS client MUST use them, overriding any default configuration.  A DOTS client SHOULD do a resource discovery, which is done by a GET request to "/.wellknown/core"

Header: GET (Code=0.01)
     Uri-Host: "host"
     Uri-Path: ".wellknown"
     Uri-Path: "core"

Regards

Jon

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Thu, 26 Oct 2017 14:49:30 +0000

On Oct 26, 2017, at 10:29 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

I don’t see the need to complicate the DOTS signal channel by introducing resource discovery (see https://tools.ietf.org/html/rfc5785),

We can consider a similar approach and request IANA to allocate uri-suffix 'dots’.

I like this approach.

andrew

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Thursday, October 26, 2017 7:25 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] DOTS signal and resource path discovery

Hi there

The two discoverable resources that SHOULD be available to a DOTS client are “mitigation” and “configuration”.  If the appropriate URI paths are returned, the DOTS client MUST use them, overriding any default configuration.  A DOTS client SHOULD do a resource discovery, which is done by a GET request to “/.wellknown/core”

Header: GET (Code=0.01)
     Uri-Host: "host"
     Uri-Path: ".wellknown"
     Uri-Path: "core"

Regards

Jon

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

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 26 Oct 2017 21:44:35 +0100

This works for me.  It means that we no longer need “dots-signal” in the path (saves packet space).  I still would like to see “signal” in the path renamed to, say, “mitigate” as DOTS signal covers both mitigation and configuration.

However, what happens if DOTS has a version change from v1 to v2 ?

- How do we handle this (unlikely) event?

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Mortensen, Andrew
Sent: 26 October 2017 15:50
To: Konda, Tirumaleswar Reddy
Cc: Jon Shallow; [email-masked]
Subject: Re: [Dots] DOTS signal and resource path discovery

On Oct 26, 2017, at 10:29 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:

I don’t see the need to complicate the DOTS signal channel by introducing resource discovery (see  <https://tools.ietf.org/html/rfc5785> https://tools.ietf.org/html/rfc5785), 
Many protocols like EST use well-known locations (e.g.  <https://www.example.com/.well-known/est/> https://www.example.com/.well-known/est/) where uri-suffix 'est' is allocated by the IANA to avoid collisions. 
We can consider a similar approach and request IANA to allocate uri-suffix 'dots’.

I like this approach.

andrew

 

Hi there

     Uri-Path: "version"

     Uri-Path: "dots-signal"

     Uri-Path: "signal"

To

     Uri-Path: "dots-signal"

               And

     Uri-Path: "version"

     Uri-Path: "dots-signal"

     Uri-Path: "config"

To

     Uri-Path: "v1"

     Uri-Path: "dots-signal"

2)      Add in the following

5.7 Resource Discovery

Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".wellknown"

     Uri-Path: "core"

 

Regards

Jon

---

From: <[email-masked]>
Date: Fri, 27 Oct 2017 06:23:29 +0000

Hi all,

Fully agree with Tiru.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : jeudi 26 octobre 2017 16:30
À : Jon Shallow; [email-masked]
Objet : Re: [Dots] DOTS signal and resource path discovery

-Tiru

Hi there

     Uri-Path: "version"

     Uri-Path: "dots-signal"

     Uri-Path: "signal"

To

     Uri-Path: "dots-signal"

     Uri-Path: "dots-signal"

     Uri-Path: "config"

To

     Uri-Path: "v1"

     Uri-Path: "dots-signal"

2)      Add in the following

Header: GET (Code=0.01)
     Uri-Host: "host"
     Uri-Path: ".wellknown"
     Uri-Path: "core"

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 27 Oct 2017 06:44:07 +0000

Hi Jon,

Thanks, The URI path can look as follows:

     Uri-Host: "host"
     Uri-Path: "URI suffix"
     Uri-Path: "version"
     Uri-Path: "mitigate" or "config"

IANA will be requested to allocate the uri-suffix “dots” or “dots-signal” (depending on if the WG decides to take the same approach for DOTS data channel).

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, October 27, 2017 2:15 AM
To: 'Mortensen, Andrew' <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] DOTS signal and resource path discovery

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Mortensen, Andrew
Sent: 26 October 2017 15:50
To: Konda, Tirumaleswar Reddy
Cc: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS signal and resource path discovery

I like this approach.

andrew

Hi there

Header: GET (Code=0.01)
     Uri-Host: "host"
     Uri-Path: ".wellknown"
     Uri-Path: "core"

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 27 Oct 2017 08:11:09 +0000

Thanks for all the responses, we will address this comment in the next revision.

-Tiru

From: Mortensen, Andrew [mailto:[email-masked]]
Sent: Thursday, October 26, 2017 8:20 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Jon Shallow <[email-masked]>; [email-masked]
Subject: Re: [Dots] DOTS signal and resource path discovery

I like this approach.

andrew

Hi there

Header: GET (Code=0.01)
     Uri-Host: "host"
     Uri-Path: ".wellknown"
     Uri-Path: "core"

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 27 Oct 2017 09:30:19 +0100

Hi Tiru,

My suggest would be to go with uri-suffix “dots” and have the final Uri-Path: as “alias” or “filter” for the DOTS data channel.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 October 2017 07:44
To: Jon Shallow; 'Mortensen, Andrew'; [email-masked]
Subject: Re: [Dots] DOTS signal and resource path discovery

Hi Jon,

     Uri-Host: "host"

     Uri-Path: "URI suffix"

     Uri-Path: "version"

-Tiru

Regards

Jon

 

I like this approach.

andrew

 

Hi there

     Uri-Path: "version"

     Uri-Path: "dots-signal"

     Uri-Path: "signal"

To

     Uri-Path: "dots-signal"

               And

     Uri-Path: "version"

     Uri-Path: "dots-signal"

     Uri-Path: "config"

To

     Uri-Path: "v1"

     Uri-Path: "dots-signal"

2)      Add in the following

5.7 Resource Discovery

Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".wellknown"

     Uri-Path: "core"

 

Regards

Jon