[core] Spencer Dawkins' No Objection on draft-ietf-core-block-19: (with COMMENT)
"Spencer Dawkins" <spencer.dawkins@huawei.com> Mon, 18 April 2016 04:48 UTC
Return-Path: <spencer.dawkins@huawei.com>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74ECC12DE55; Sun, 17 Apr 2016 21:48:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencer.dawkins@huawei.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160418044805.28780.94432.idtracker@ietfa.amsl.com>
Date: Sun, 17 Apr 2016 21:48:05 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/zvc5Eueg_KaWGLIuglHNtW0Pg6Y>
Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, core@ietf.org
Subject: [core] Spencer Dawkins' No Objection on draft-ietf-core-block-19: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 18 Apr 2016 04:48:05 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-core-block-19: 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please consider whether you need to say more about UDP usage for this extension than what the base CORE specification says - RFC 7252 has only one mention of RFC 5405, and that only points to guidance about reducing ACK_TIMEOUT below one second. I understand that the CoAP story includes "most of these nodes aren't capable of generating a lot of packets in a short timeframe", but does this extension make it easier to send multiple UDP packets back-to-back? I'm reading this text, In most cases, all blocks being transferred for a body (except for the last one) will be of the same size. and then this text * The block size implied by SZX MUST match the size of the payload in bytes, if the M bit is set. (SZX does not govern the payload size if M is unset). For Block2, if the request suggested a larger value of SZX, the next request MUST move SZX down to the size given in the response. (The effect is that, if the server uses the smaller of (1) its preferred block size and (2) the block size requested, all blocks for a body use the same block size.) and realizing that I'm confused about why all the blocks for a body might NOT use the same block size. Maybe this doesn't matter (because an implementation would need to be prepared for the case when all the blocks don't use the same block size)? The examples were helpful to me. Thank you for doing that work.
- [core] Spencer Dawkins' No Objection on draft-iet… Spencer Dawkins
- Re: [core] Spencer Dawkins' No Objection on draft… Carsten Bormann
- Re: [core] Spencer Dawkins' No Objection on draft… Spencer Dawkins at IETF
- Re: [core] Spencer Dawkins' No Objection on draft… Carsten Bormann