Re: [core] Spencer Dawkins' No Objection on draft-ietf-core-block-19: (with COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Spencer,

I think I have addressed your comments in draft-ietf-core-block-20

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

Specifically:

> My problem was that I didn't understand from the text that the same
> method of pacing packets that contained complete requests was being used
> to pace packets that contained blocks. I think that I can derive what
> you're saying from the draft, but it wasn't clear to me.
> 
> I saw that in the thread of Mirja's Discuss, you suggested adding this
> point more explicitly. That would solve my issue here.

See the new text in the introduction.

>  
> 
>     > 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 first request may be using a block size that is larger than what the
>     server prefers.  That is one case where the block size changes during a
>     whole transfer.  See also Figure 4 for an example where the client
>     prefers a smaller block size than the server sent initially.
> 
>     So, yes, an implementation needs to be prepared for cases where at least
>     the initial block is of a different size than the following (full)
>     blocks.  I believe this is evident to the implementers at least from the
>     examples.
> 
> 
> That's very helpful. 
> 
> Would it be correct to say (in the first paragraph I included above)
> something like
> 
>     In most cases, all blocks being transferred for a body (except for
>     the last one) will be of the same size. If the first request uses a
> bigger
>     block size than the receiver prefers, subsequent requests will use
>     the preferred block size.
> 
> just so you're not relying on implementers to figure out what to
> implement solely from the examples?

Thanks for the text suggestion.  That text is now in the last paragraph
of the introduction to section 2.

Grüße, Carsten