Hi Pete, Thanks for the thoughtful review! Good catches, and happy to see the document improved.
Authors – please go ahead and submit the update including these changes, so I can push the button and move it forward. Thanks, Francesca From: "mohamed.boucad...@orange.com" <mohamed.boucad...@orange.com> Date: Wednesday, 28 April 2021 at 06:52 To: Pete Resnick <resn...@episteme.net> Cc: "last-c...@ietf.org" <last-c...@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-core-new-block....@ietf.org" <draft-ietf-core-new-block....@ietf.org>, "c...@ietf.org" <c...@ietf.org> Subject: RE: [Last-Call] Genart last call review of draft-ietf-core-new-block-10 Resent from: <alias-boun...@ietf.org> Resent to: <mohamed.boucad...@orange.com>, <supjps-i...@jpshallow.com>, Bormann <c...@tzi.org>, <ja...@iki.fi>, <marco.til...@ri.se>, <superu...@gmail.com>, Francesca Palombini <francesca.palomb...@ericsson.com> Resent date: Wednesday, 28 April 2021 at 06:52 Hi Pete, OK with the proposed editorial change. Fixed in the local copy. Thank you. Cheers, Med De : last-call [mailto:last-call-boun...@ietf.org] De la part de Pete Resnick Envoyé : mercredi 28 avril 2021 01:11 À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucad...@orange.com> Cc : last-c...@ietf.org; gen-art@ietf.org; draft-ietf-core-new-block....@ietf.org; c...@ietf.org 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.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 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/<https://protect2.fireeye.com/v1/url?k=4f76cc35-10edf576-4f768cae-861fcb972bfc-1147fe9a31398186&q=1&e=ede0ae9f-ec03-476d-a29a-c0628cdb9626&u=https%3A%2F%2Fwww.episteme.net%2F> 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.
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
