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

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 20 Apr 2016 04:05:10 -0700

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.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 20 Apr 2016 16:36:41 -0500

I'm not updating my ballot, but

> https://datatracker.ietf.org/doc/draft-ietf-core-block/

I was equally confused about something similar - looking at the description
(and not the examples), I wasn't sure whether you could send all the blocks
of an object, and wait for a response. So, I'd agree with Mirja on her
point here.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Apr 2016 09:01:15 +0200

Hi Mirja,

I'm wondering how we managed to create that expectation.

As I said in the response to Spencer's comment, block-wise transfers are
strictly layered on top of RFC 7252 CoAP.  Maybe there is some
introductory text needed that emphasizes this early on.

Implementations that I know run completely lock-step.  Theoretically, an
implementation could pipeline requests for further blocks after the
initial exchange (which needs to be lock-step so a common block-size can
be determined; also, a Size2 option would be needed to determine the
number of requests to be sent).  NSTART (Section 4.7 of RFC 7252) puts a
hard limit on the parallelism here, and the default value of NSTART
(without advanced congestion control) is 1, so we are back to lock-step.

> guidance on congestion control would be needed.

Block-wise transfers can be sent in NON messages.  That would not be a
particularly wise choice in general, as the delivery probability for the
whole body decreases exponentially (section 2.8 outlines one specific
use case for using NON in the first block only, though).

NON messages can not simply be sent back-to-back in CoAP, see section
4.7 of RFC 7252.

The usage guidance (section 2.5?) is more normative than just an
example.  Moving all interoperability requirements into one section
might create even more duplication of text.

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

I have added a reference to Section 5.10.6 of RFC 7252 in the editor's
draft.

Grüße, Carsten

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 22 Apr 2016 14:07:34 +0200

Hi Carsten,

see below.

Mirja

> Am 21.04.2016 um 09:01 schrieb Carsten Bormann <[email-masked]>:
> 
> Hi Mirja,
> 

I guess by not talking about it at all (and Spencer and me being overly sensitive to this topic) :-)

> introductory text needed that emphasizes this early on.

Yes, please add something similar as what you’ve written in your response to Spencer, (early) in the doc. Thanks!

> (without advanced congestion control) is 1, so we are back to lock-step.

Okay, the problem with not talking about this at all is that all these value in rfc7252 are only recommendation. There are no restricting max values which are defined like 'MUST NOT be larger than X'. Therefore my fear would be that people could assume that this extension, as it supports sending or larger data, could provide a reason to increase the default values.

Would it make sense to say something like: Using this extension MUST NOT lead to changes in the transmission behavior (e.g. other default value than specified in RFC7252).  ?

> use case for using NON in the first block only, though).

Again, I don’t think this is spelled to anywhere and really should.

> NON messages can not simply be sent back-to-back in CoAP, see section

Please correct me if I’m wrong but looking at section 4.7 this might not be well enough defined to be fully applicable and save for a case where you send a large message with several blocks as NON (even though this is in general not recommended). Note, 4.7 is explicitly saying "Further congestion control optimizations and considerations are expected in the future“. Please double-check and consider giving further recommendations in this doc!

> might create even more duplication of text.

Might still be worth trying to remove redundancy where possible and double-check all MUST and SHOULD. Thanks!

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Apr 2016 20:35:57 +0200

Hi Mirja,

I believe I have addressed your DISCUSS and COMMENTs in
draft-ietf-core-block-20.

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-20

> Please correct me if I’m wrong but looking at section 4.7 this might not be well enough defined to be fully applicable and save for a case where you send a large message with several blocks as NON…

All this should be addressed by the new paragraph right in the introduction.

> Might still be worth trying to remove redundancy where possible and double-check all MUST and SHOULD. Thanks!

Ben identified a particularly atrocious use of SHOULD in Section 2.4, I
have fixed that.  Apart from that, I tried to refrain from major surgery
-- this document has been around for a while, been tested in four
plugtests, etc.  Risks vs. benefit.

>> I have added a reference to Section 5.10.6 of RFC 7252 in the editor's

Done.

Grüße, Carsten