[core] Mirja Kühlewind's Discuss on draft-ietf-core-block-19: (with DISCUSS and COMMENT)

"Mirja Kuehlewind" <ietf@kuehlewind.net> Wed, 20 April 2016 11:05 UTC

Return-Path: <ietf@kuehlewind.net>
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 70F1412E3F0; Wed, 20 Apr 2016 04:05:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kuehlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160420110510.32319.55772.idtracker@ietfa.amsl.com>
Date: Wed, 20 Apr 2016 04:05:10 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/vjDICVwFDcu2usQ4P8qpyglmD3Y>
Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, core@ietf.org
Subject: [core] Mirja Kühlewind's Discuss on draft-ietf-core-block-19: (with DISCUSS and 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: Wed, 20 Apr 2016 11:05:10 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-core-block-19: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is only a minor point, requesting to spell out implicit assumptions
explicitly. However, I think it's important to address this before
publication.

It is not clear in the main part of the doc that this extension to does
not change the message transmission method as specified in RFC7252
(Stop-and-wait retransmission). With my initial ready I assumed that this
extension would allow the sending of back-to-back messages. Only by
looking at the examples, it got clear to me that this is not the case. 

Further, this document does not say anything about reliability. Do block
message need to be transmitted reliable (as Confirmable)? If not, this
extension could still lead to back-to-back sending and then further
guidance on congestion control would be needed.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with others that reduncy makes the doc harder to read, especially
regarding SHOULDs and MUSTs. Would it be helpful to have all SHOULDs and
MUST in one section and combine the Usage guidance with the examples?

Further, please also add a reference for ETag in section 2.4.