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

supjps-ietf@jpshallow.com Fri, 21 May 2021 18:40 UTC

Return-Path: <jon.shallow@jpshallow.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B4B3A1AE1 for <core@ietfa.amsl.com>; Fri, 21 May 2021 11:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3J-QVlhdlKC for <core@ietfa.amsl.com>; Fri, 21 May 2021 11:40:43 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAC83A1ADC for <core@ietf.org>; Fri, 21 May 2021 11:40:43 -0700 (PDT)
Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1lkA4d-00075A-IJ; Fri, 21 May 2021 19:40:39 +0100
From: <supjps-ietf@jpshallow.com>
To: "'Benjamin Kaduk'" <kaduk@mit.edu>, "'The IESG'" <iesg@ietf.org>
Cc: <draft-ietf-core-new-block@ietf.org>, <core-chairs@ietf.org>, <core@ietf.org>, <marco.tiloca@ri.se>
References: <162162096651.11745.11475318344342658600@ietfa.amsl.com>
In-Reply-To: <162162096651.11745.11475318344342658600@ietfa.amsl.com>
Date: Fri, 21 May 2021 19:40:41 +0100
Message-ID: <093401d74e70$ccfd1240$66f736c0$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIlO8cBtQaQUeahZBG4mS/wV7bzG6pSaJVA
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ep6S-aXE6HLIi2kPpIR98TRQMSc>
Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-new-block-13: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2021 18:40:48 -0000

Hi Ben

See inline.

Regards

Jon

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker [mailto: noreply@ietf.org]
> Sent: 21 May 2021 19:16
> To: The IESG
> Cc: draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; core@ietf.org;
> marco.tiloca@ri.se; marco.tiloca@ri.se
> 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.
> 
>