Re: [core] Genart last call review of draft-ietf-core-new-block-10

[Pete Resnick <[e-mail]>]

Thanks for the followup. Just to close the loop on some of these:

On 26 Apr 2021, at 5:31, [e-mail] wrote:

>> In section 4.4:
>>
>> I find this paragraph confusing:
>>
>>    The requested missing block numbers MUST have an increasing block
>>    number in each additional Q-Block2 Option with no duplicates.  The
>>    server SHOULD respond with a 4.00 (Bad Request) to requests not
>>    adhering to this behavior.
>>
>> So, given the SHOULD in the second sentence, it appears that the MUST
>> in the first sentence doesn't apply to the server (i.e., to enforce
>> this), but rather to the client doing the request. You should
>> probably say it that way.
>
> [Med] Yes. This text should be linked to the previous paragraph when 
> the client issues the request for missing blocks. Anyway, I agree it 
> is better to be explicit here. Fixed.

Excellent. Here's a purely editorial suggestion; entirely up to you 
whether to use it:

     The missing block numbers requested by the client MUST have an
     increasing block number in each additional Q-Block2 Option with no
     duplicates.

>> Also, the SHOULD in the second sentence is
>> not entirely clear to me: Are you saying that the server can choose
>> to use some other response code, or are you saying that the server
>> can accept the request and do something interesting with it?
>
> [Med] The latter. Normally the server must discard such request but 
> given that one of the target use cases for this spec is DDoS 
> mitigation, servers may be tolerant.

Ah, OK, then what you have is correct as-is.

>> In section 4.3:
>>
>> In several response code definitions:
>>
>>    The token used MUST be any token that was received in a request
>> using
>>    the same Request-Tag.
>>
>> That doesn't really parse well. I think you either mean "The token
>> used MUST be a token" or you mean "The token used can be any token".
>>
>
> [Med] The second para of this section specifies that all block 
> requests must use the same Request-Tag. The 4th para indicates that 
> each of these block requests will use a new token. The server must use 
> one of these tokens when replying.
>
> Updated the text as follows:
>
> NEW:
>    The token used MUST be one of the tokens that were received in a 
> request for this block-wise exchange.

I like it.

>> In section 7.2:
>>
>>    For the server receiving NON Q-Block1 requests, it SHOULD send
>> back a
>>    2.31 (Continue) Response Code on receipt of all of the
>> MAX_PAYLOADS
>>    payloads to prevent the client unnecessarily delaying.
>> Otherwise...
>>
>> When you say "Otherwise", Do you mean, "For other payloads"? Either
>> way, you should probably change that to make it clear.
>>
>>
> [Med] Changed to: "If not all of the MAX_PAYLOADS payloads were 
> received, ..."

Perfect.

All of the others look fine. Thanks again for the quick reply.

Cheers,

pr

-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best