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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

On 26 Apr 2021, at 5:31, mohamed.boucadair@xxxxxxxxxx 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

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux