Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-new-block-13: (with COMMENT)

[[e-mail]]

Hi Ben

See inline.

Regards

Jon

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker [mailto: [e-mail]]
> Sent: 21 May 2021 19:16
> To: The IESG
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Benjamin Kaduk's No Objection on draft-ietf-core-new-block-13:
> (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-core-new-block-13: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-core-new-block/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for addressing my discuss and comment points!
> 
> In reviewing the latest updates, I briefly tried to cross-reference
> the formula in section 7.2:
> 
>       NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT)
> - 1) *
>       ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT
> 
> My initial attempt found that the corresponding formulae in RFC 7252 used
> PROCESSING_DELAY instead of NON_TIMEOUT for the last term, but I did not
> go back to double-check.  It's possible I'm just misreading something.

[Jon] RFC7253 4.8.2

   o  PROCESSING_DELAY is the time a node takes to turn around a
      Confirmable message into an acknowledgement.  We assume the node
      will attempt to send an ACK before having the sender time out, so
      as a conservative assumption we set it equal to ACK_TIMEOUT.

And hence NON_TIMEOUT.
> 
>