Subject: [Dots] draft-ietf-dots-data-channel: Lifetime handling

From: <[email-masked]>
Date: Wed, 14 Feb 2018 08:23:16 +0000

Hi all,

As agreed during the interim, there are some issues that need fixes in the data-channel spec. We would like to hear from the WG to know what to record in the document.

Issue description: It was agreed to associate a lifetime with entries instantiated by a DOTS client (-12). The current behavior in the spec is as follows:

-    A lifetime hint is included in the resource creation request by the client.

-    The server may honor the suggested lifetime or assign a distinct value as per its local policies.

When a distinct value is used by the server, the issue is how to notify the client given that RFC8040 says:

"If the POST method succeeds, a "201 Created" status-line is returned and there is no response message-body."

* Option 1:

A work around would be to relax the above constraint at the server side to include a message-body even for "201 Created", but this is not a clean design as it requires changes to the base RESTCONF spec.

* Option 2:

Change completely the data module so that we can make use of operations (action/rpc). For example, these operations can be defined:

          +---x activate-filtering

          |  +---w input

          |  |  +---w name             string

          |  |  +---w lifetime-hint    int32

          |  +--ro output

          |     +--ro name        string

          |     +--ro lifetime    int32

          +---x deactivate-filtering

             +---w input

                +---w name    string

This approach will require major changes to the document. This may not be justified given that in some cases no lifetime is included at all.

* Option 3:

This one assumes that servers must maintain an entry for a minimum period (e.g., 1 week, 1 month). No Lifetime is included in a request. If no refresh request is seen from the client, the server removes expired entries.

This one requires minor changes to the document.

* Option 4:

This approach does not associate a lifetime with filtering/alias entries but maintains an inactivity timer of a given DOTS client. This option does not allow to clean stale mappings that may be induced by clients that do not remove their state appropriately.

Recommended position:

-    Proceed with option 3.

Any objection?

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 03:47:29 +0000

Option 3 looks good to me.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 14, 2018 1:53 PM
To: [email-masked]
Subject: [Dots] draft-ietf-dots-data-channel: Lifetime handling

Hi all,

* Option 1:

* Option 2:

          +---x activate-filtering

          |  +---w input

          |  |  +---w name             string

          |  +--ro output

          |     +--ro name        string

          |     +--ro lifetime    int32

             +---w input

                +---w name    string

* Option 3:

* Option 4:

Recommended position:

-    Proceed with option 3.

Any objection?

Cheers,

Med

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 16 Feb 2018 12:38:51 -0000

However do we need to add in a "when it will expire" parameter in  a GET
response so that a restarting DOTS client knows it has to do a refresh
within a certain time?

Separately, I think Option 4 should still be in place as a recommendation to
manage stale DOTS clients (as determined by cuid) that have not been active
on the signal and data channel for a period of time.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 16 February 2018 03:47
To: [email-masked]; [email-masked]
Subject: Re: [Dots] draft-ietf-dots-data-channel: Lifetime handling

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, February 14, 2018 1:53 PM
To: [email-masked]
Subject: [Dots] draft-ietf-dots-data-channel: Lifetime handling

Hi all, 

As agreed during the interim, there are some issues that need fixes in the
data-channel spec. We would like to hear from the WG to know what to record
in the document. 

Issue description: It was agreed to associate a lifetime with entries
instantiated by a DOTS client (-12). The current behavior in the spec is as
follows: 

-    A lifetime hint is included in the resource creation request by the
client.

-    The server may honor the suggested lifetime or assign a distinct value
as per its local policies.   

When a distinct value is used by the server, the issue is how to notify the
client given that RFC8040 says:

"If the POST method succeeds, a "201 Created" status-line is returned and
there is no response message-body."

* Option 1: 

A work around would be to relax the above constraint at the server side to
include a message-body even for "201 Created", but this is not a clean
design as it requires changes to the base RESTCONF spec. 

* Option 2: 

Change completely the data module so that we can make use of operations
(action/rpc). For example, these operations can be defined: 

          +---x activate-filtering

          |  +---w input

          |  |  +---w name             string

          |  +--ro output

          |     +--ro name        string

          |     +--ro lifetime    int32

             +---w input

                +---w name    string

This approach will require major changes to the document. This may not be
justified given that in some cases no lifetime is included at all. 

* Option 3: 

This one assumes that servers must maintain an entry for a minimum period
(e.g., 1 week, 1 month). No Lifetime is included in a request. If no refresh
request is seen from the client, the server removes expired entries.

* Option 4:

This approach does not associate a lifetime with filtering/alias entries but
maintains an inactivity timer of a given DOTS client. This option does not
allow to clean stale mappings that may be induced by clients that do not
remove their state appropriately. 

Recommended position:

-    Proceed with option 3. 

Any objection? 

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 13:18:14 +0000

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, February 16, 2018 6:09 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] draft-ietf-dots-data-channel: Lifetime handling

However do we need to add in a "when it will expire" parameter in  a GET response so that a restarting DOTS client knows it has to do a refresh within a certain time?

[TR] Yes.

Separately, I think Option 4 should still be in place as a recommendation to manage stale DOTS clients (as determined by cuid) that have not been active on the signal and data channel for a period of time.

[TR] If Option 3 is used, don't see the use of Option 4.

-Tiru

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 03:47
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] draft-ietf-dots-data-channel: Lifetime handling

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, February 14, 2018 1:53 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] draft-ietf-dots-data-channel: Lifetime handling

Hi all,

* Option 1:

* Option 2:

          +---x activate-filtering

          |  +---w input

          |  |  +---w name             string

          |  +--ro output

          |     +--ro name        string

          |     +--ro lifetime    int32

             +---w input

                +---w name    string

* Option 3:

* Option 4:

Recommended position:

-    Proceed with option 3.

Any objection?

Cheers,

Med

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 16 Feb 2018 13:26:04 -0000

Hi Tiru,

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 16 February 2018 13:18
To: Jon Shallow; [email-masked]; [email-masked]
Subject: Re: [Dots] draft-ietf-dots-data-channel: Lifetime handling

From: Jon Shallow [mailto:[email-masked]] 
Sent: Friday, February 16, 2018 6:09 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>;
[email-masked]; [email-masked]
Subject: RE: [Dots] draft-ietf-dots-data-channel: Lifetime handling

[TR] Yes.

[Jon] Option 4 is also about the lifetime handling of cuids that go stale -
perhaps a separate discussion, but it is also lifetimes.

-Jon

-Tiru

Regards

Jon

-Tiru

Hi all, 

* Option 1: 

* Option 2: 

          +---x activate-filtering

          |  +---w input

          |  |  +---w name             string

          |  +--ro output

          |     +--ro name        string

          |     +--ro lifetime    int32

             +---w input

                +---w name    string

* Option 3: 

* Option 4:

Recommended position:

-    Proceed with option 3. 

Any objection? 

Cheers,

Med