Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : Inspect the deploy log : Browse the preview : 
 As a bit random comment ... I always wondered if it 's allowed for the AS to provide a " delayed " response , or in other words , leverage the HTTP long polling mechanism just like for this response with the field . Of course , there will be definitely upsides and downsides to it . See for more info . 
 Since it 's over HTTP , long polling is allowed regardless of whether we mention it or not . I personally do n't see a reason to mention it explicitly here . 
 It 's a continuation of the discussion started in which I would like to track as a separate issue . If we want to have that then client should be able to wait and handle a delayed response say after 60 - 120 seconds , and client should be able to gracefully handle various timeous ( client and from the network infrastructure ) and make a subsequent call , and client should know what to do with the " wait " field when a timeout occurs in the previous step . I think it could be a great addition to this specification . Furthermore , take a look at and how they leverage the HTTP long polling mechanism . 
 The specification allows using the HTTP long polling mechanism against the  token endpoint in somewhat similar circumstances . I had some spare time to research this topic a bit deeper and do n't have a good answer on how it was possible for me to have the abovementioned specification out of sight . Again , it would be such a great thing to have a bit more instant notification mechanism in the specification core , I mean , not in its extensions or in one or another out of band / vendor - specific solution . 
 Continuing a Grant Request :  's note : What 's a reasonable amount of time to wait by default so as not to DOS the server if the field is missing ? 
 Might have to broaden the perspective and provide more general guidance on how to avoid / limit DDoS 
 I think we need general considerations as well , but this is a specific case where a naive implementation could accidentally DoS the system by polling too quickly . 
 yes . Then it 's simple , anything around the minute should work . 
 Discussed in security considerations However , still no normative requirement in the polling section so this issue is staying open until that 's in . 
 Need to add this to the interaction response section . I suggest " SHOULD NOT be less than five seconds " and " omission MUST NOT be treated as zero " .
Paragraph (version A):
If a "wait" parameter was included in the response-continue, the
client instance MUST NOT call the continuation URI prior to waiting
the number of seconds indicated.  If no "wait" period is indicated,
the client instance SHOULD wait at least 5 seconds.  If the client
instance does not respect the given wait period, the AS MUST return
an error.
Paragraph (version B):
If a "wait" parameter was included in the response-continue, the
client instance MUST NOT call the continuation URI prior to waiting
the number of seconds indicated.  If no "wait" period is indicated,
the client instance MUST NOT poll immediately and SHOULD wait at
least 5 seconds.  If the client instance does not respect the given
wait period, the AS MUST return the error "too_fast" defined in
response-error.