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

[<mohamed.boucadair@xxxxxxxxxx>]

Hi Pete,

 

OK with the proposed editorial change. Fixed in the local copy.

 

Thank you.

 

Cheers,

Med

 

De : last-call [mailto:last-call-bounces@xxxxxxxx] De la part de Pete Resnick
Envoyé : mercredi 28 avril 2021 01:11
À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@xxxxxxxxxx>
Cc : last-call@xxxxxxxx; gen-art@xxxxxxxx; draft-ietf-core-new-block.all@xxxxxxxx; core@xxxxxxxx
Objet : Re: [Last-Call] Genart last call review of draft-ietf-core-new-block-10

 

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

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