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:
>
> Max Pritikin (pritikin) <[email protected]> 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.
>
>
>
> >> On Jun 5, 2017, at 8:02 PM, Michael Richardson <[email protected]>
> wrote:
> >>
> >>
> >> Max Pritikin (pritikin) <[email protected]> wrote:
> >>> 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.
> >>
> >> Agreed... let me ask the question again:
> >> SHOULD the voucher be identified by a URI?
> >>
> >> --
> >> Michael Richardson <[email protected]>, Sandelman Software Works
> >> -= IPv6 IoT consulting =-
> >>
> >>
> >>
>
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
