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 protected]> wrote: > > > 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 protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
