Subject: [Gen-art] Gen-Art review of draft-ietf-core-block-19

From: Jouni Korhonen <[email-masked]>
Date: Mon, 18 Apr 2016 15:16:23 -0700

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-core-block-19
Reviewer: Jouni Korhonen
Review Date: 4/18/2016
IETF LC End Date: 4/12/2016
IESG Telechat date: 4/21/2016

Summary: Ready with nits

Major issues: none.

Minor issues:

* The intoduction mentions that the block transfwer can be used for 
random access. This is not separately described anywhere in the 
documents. Although the operation is more or less trivial I would 
appreciate an example or some text there because the Block2 overloads 
the NUM value 0 with special meaning (for the cases where the first ever 
accessed block is not the block number 0).

Nits/editorial comments:

* There are few issues with capitalization (e.g., section vs Section), 
which I believe the RFC Editor will handle without me pointing at them.

* The document has a tendency of using long portions of text inside 
braces, sometimes even in a middle of a paragraph. I would strongly 
suggest either making those part of the normal text flow or a separate 
(intended) editor's note if they for some reason cannot be part of the 
normal text flow.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Apr 2016 08:26:42 +0200

> accessed block is not the block number 0).

The random access operation is not described in this draft, but it is
indeed quite obvious how one would make use of such a capability.
Its use would require some previous understanding between client and
server (possibly gained by the client simply trying out random access).
I'm not sure how NUM=0 is special in this case.
In any case, I would expect specifications that want to make use of
random access to flesh out any details that would be relevant in their
use case.

> which I believe the RFC Editor will handle without me pointing at them.

They certainly will.  (Also addressed in editor's draft now.)

> (intended) editor's note if they for some reason cannot be part of the

Again, I expect the RFC editor to help with the cleanup here.

Grüße, Carsten

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Apr 2016 12:27:25 +0200

Thanks for your review, Jouni.

Jari

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 25 Apr 2016 10:51:27 -0700

Carsten,

See inline.

> I'm not sure how NUM=0 is special in this case.

NUM=0 is used in some cases to indicate the desired block size in the 
initial request (as I read and understand from the draft.. if that is 
not the case then it needs to stated more clearly that it is not the 
case). I mean the text in 2.4 and 2.8 for example.

- Jouni

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Apr 2016 23:33:42 +0200

Hi Jouni,

> case). I mean the text in 2.4 and 2.8 for example.

There is definitely a special case for NUM=0 in 2.8 (multicast), but
that is because, for discovery, the client will switch to unicast for
all other blocks.  It doesn't sound reasonable to "discover" a resource
while performing random access to it.

The text in 2.4 is more about the outcome of using Block2 options
properly; here we prefer the wording "first request"/"first response"
because indeed that might be for a block with NUM≠0.

(The special case for NUM≠0 in the last paragraph of 2.10 is about not
creating "holes".)

Grüße, Carsten

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 29 Apr 2016 09:24:44 -0700

Hi Jouni,

Just saying.. the use of NUM was not crystal clear just by reading the 
draft and not having the followed the core block development & 
discussion past few years.

Thanks,	
	Jouni

---

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

> discussion past few years.

Right.  I'm not sure I have fully addressed this one; all your other
comments should be addressed in draft-ietf-core-block-20.

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

Grüße, Carsten