Subject: [Anima] 200 vs 201 responses from MASA to Registrar (BRSKI-MASA protocol)

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Jun 2017 21:42:58 -0400

Max, in section 3.3 we document the contents that the Registrar will POST to
the MASA's /requestvoucher.

In section 3.4 we say:
   3.4.  Voucher Response

   ...
   If the the join operation is successful, the server response MUST
   contain an HTTP 200 response code.  The server MUST answer with a
   suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs.

It seems that since we are using POST, that we ought to answer with an HTTP
201 response code, and include a Location: header at which the voucher could
be accessed later on.    I am not sure if I'm arguing for returning just the
201, and expect the Registrar to do a GET, although that would be more
correct.

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

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 5 Jun 2017 23:13:49 +0000

>From https://tools.ietf.org/html/rfc2616#section-9.5

   The action performed by the POST method might not result in a
   resource that can be identified by a URI. In this case, either 200
   (OK) or 204 (No Content) is the appropriate response status,
   depending on whether or not the response includes an entity that
   describes the result.

In this case I think the 200 OK code is most appropriate since the server generates a signed voucher as a result of the POST and returns it. The voucher is not identified by a URI. 

- max 

> On Jun 4, 2017, at 7:42 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Jun 2017 22:02:28 -0400

> In this case I think the 200 OK code is most appropriate since the
    > server generates a signed voucher as a result of the POST and returns
    > it. The voucher is not identified by a URI.

Agreed... let me ask the question again:
   SHOULD the voucher be identified by a URI?

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 6 Jun 2017 03:54:52 +0000

That is an interesting idea. Obtaining a “renewed” voucher would be as simple as a query to the known URL (unless the nonce needed to be updated in which case use the POST method). Hmm.

Feels a little bit like a premature optimization; but I see the point. 

- max

> On Jun 5, 2017, at 8:02 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Jun 2017 12:36:32 -0400

Max Pritikin (pritikin) <[email-masked]> wrote:
    > That is an interesting idea. Obtaining a “renewed” voucher would be as
    > simple as a query to the known URL (unless the nonce needed to be
    > updated in which case use the POST method). Hmm.

    > Feels a little bit like a premature optimization; but I see the point.

I'd like to suggest that we permit a 200 *or* 201 response, but document
that 201 SHOULD be treated like a 200 for this version of the BRSKI-MASA
protocol.   Maybe it's implied somewhere that all 2xx responses are success,
yet 204 (No content) is not a useful response.

This lets' us update to 201 in a future version if we find it useful.

I need to re-read to determine what failure responses are expected.

Are we allowed to return 503 if one should try later?
What about 420 or 429:
     Returned by the Twitter Search and Trends API when the client is being
     rate limited. The text is a quote from 'Demolition Man' and the '420'
     code is likely a reference to this number's association with
     marijuana. Other services may wish to implement the 429 Too Many
     Requests response code instead.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 6 Jun 2017 22:21:44 +0200

a) I don't think we want to expand the set of permitted replies later on because
that introduces compatibility issues with older (pledge) implementations.

Instead, if we figure out later that we might want to get a different reply, for
example a URL for the voucher, then IMHO this should be done through a new
voucher request URL. So, ideally we would be able to define today
a format for the request voucher URL or POST that would allow us to add
further features to it in the future in such a way that an old (BRSKI v1 ;-) registrar/MASA
could ignore such an option - and return the 200 - and that a new Registrar/MASA
would return new/enhanced information.

Do we have such a format ?

b) Any reply to let the pledge hang around would be nice in case we have a workflow
where MASA/registar or some othre backend take longer or maybe even want to insert
a human intervention. BUT: We should have such feedback consistently across all
signaling steps, including the EST ones. If EST does define a specific delay feedback
option, we should use the same for the new BRSKI messages. If not, then we should
define the required feedback but also make it required to be accepted by pledges
for the EST pat of the signalig.

Cheers
    Toerless

On Tue, Jun 06, 2017 at 12:36:32PM -0400, Michael Richardson wrote:
>     > That is an interesting idea. Obtaining a ???renewed??? voucher would be as

-- 
---
[email-masked]