Subject: [6tisch] pending with 6tisch-minimal-security

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Nov 2017 03:30:23 -0500

Malisa, CORE has a document "tomorrow" (Tuesday) on their schedule:
        https://tools.ietf.org/html/draft-hartke-core-pending-01

This would let the JRC return a message Pending, if it felt that the network
was too congested, and lets it say when the pledge should come back.
Since we are now using POST, we can now consider if we can return this.
I'd like to make it in-scope.

It clearly can not be trusted, but it can help.

If a pledge had other options then it could continue on to those options
immediately and return to this network at the time indicated.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Nov 2017 16:33:10 +0800

> was too congested, and lets it say when the pledge should come back.

5.03 is the response code for that.

7252 says:
5.9.3.4.  5.03 Service Unavailable

   This Response Code is like HTTP 503 "Service Unavailable" but uses
   the Max-Age Option in place of the "Retry-After" header field to
   indicate the number of seconds after which to retry.

Pending is for a different situation: The request was accepted, but needs more work before it can return its result.

Grüße, Carsten

---

From: peter van der Stok <[email-masked]>
Date: Mon, 13 Nov 2017 09:38:33 +0100

Right,

and in particular, core-pending provides for many simultaneous waiting 
requests from one client.

Peter

Carsten Bormann schreef op 2017-11-13 09:33:
> Pending is for a different situation: The request was accepted, but
> needs more work before it can return its result.
> 
> Grüße, Carsten
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 13 Nov 2017 10:51:12 +0100

Michael,

I am missing the benefit of a 5.03 or Pending response for network congestion case when join completes in a single round trip. Why not return a join response that fits into a single frame rather than a signal to attempt later? If there is an error at JRC, we stay silent anyways. 

I understand the benefit when multi round-trip key establishment phase precedes join request/response exchange, but this response code should come as a response to the message triggering the key establishment. Join request/response only comes later, and so I don’t see why would we specify it in minimal-security. It should probably be in the document (zero touch I assume) where key establishment method is actually specified.

Do you see my point?

Mališa

> On 13 Nov 2017, at 09:30, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Nov 2017 14:01:07 -0500

> 5.9.3.4.  5.03 Service Unavailable

Thank you for educating me...

    > indicate the number of seconds after which to retry.

Ah, I think that we actually can use both in different situations!

In the situation where we have congestion, and we want them to retry, I guess
5.03 is correct.

In the situation where we are missing the PSK to complete the minimal-security,
or in the zerotouch situation where we have to contact the MASA (and/or there
might be human intervention to accept), then 2.__ pending might be more
instructive.

    > needs more work before it can return its result.

"more work", I interpret to include, "more crypto"?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Nov 2017 22:17:37 -0500

Mališa Vučinić <[email-masked]> wrote:
    > I am missing the benefit of a 5.03 or Pending response for network
    > congestion case when join completes in a single round trip. Why not
    > return a join response that fits into a single frame rather than a
    > signal to attempt later? If there is an error at JRC, we stay silent
    > anyways.

Yes, you make a good point.  If the response fits into a single 802.15.4
frame, then any Pending takes the same amount of bandwidth.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [