Subject: [core] WGLC for draft-ietf-core-block-15

From: Andrew Mcgregor <[email-masked]>
Date: Sat, 5 Jul 2014 09:56:45 +1000

The chairs believe that draft-ietf-core-block is now ready for last call.
 We intend a short last call on this document, since we would like to be
able to discuss the results in Toronto in two weeks time.  Please make any
comments as soon as possible.

The draft is located at:
http://www.ietf.org/internet-drafts/draft-ietf-core-block-15.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-block/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-15

Andrew

-- 
Andrew McGregor | SRE | [email-masked] | +61 4 1071 2221

---

From: "weigengyu" <[email-masked]>
Date: Mon, 7 Jul 2014 14:25:45 +0800

Hi,

I have a question about using TOKEN in block tranfer.

In page 14 Figure 2: Simple blockwise GET,
there is one GET and three ACK, each ACK with BLOCK1 should have the same 
TOKEN as the GET.
should these ACKs with BLOCK1 have the same TOKEN?

In Page 15 Figure 3: Blockwise GET with early negotiation,
there are serveal GETs and their ACKs.
Should these GETs With BLOCK2 have the same TOKEN?

So, for receiving two GETs as an example,
when the last GET has the same TOKEN as the first GET, they belong to one 
request according to BLOCK2 option.
Without BLOCK2 the last GET may be a retransmited request, or it is 
irregular.

Correct?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

From: Andrew Mcgregor
Sent: Saturday, July 05, 2014 7:56 AM
To: core ; [email-masked] ; Barry Leiba ; Zach Shelby
Subject: [core] WGLC for draft-ietf-core-block-15

The chairs believe that draft-ietf-core-block is now ready for last call. 
We intend a short last call on this document, since we would like to be able 
to discuss the results in Toronto in two weeks time.  Please make any 
comments as soon as possible.

The draft is located at:

Andrew

-- 

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 7 Jul 2014 09:54:57 +0200

> there is one GET and three ACK, each ACK with BLOCK1 should have the same TOKEN as the GET.

You lost me, Figure 2 is about Block2.

> Should these GETs With BLOCK2 have the same TOKEN?

Each response (piggybacked in an ACK here) should have the same token that the request has.
The client gets to choose the request token for each request independently; it might be reusing a token or it might be using a new one; that is up to the client’s token usage.

In any case, you never need to worry about tokens with Block.

You handle the tokens just like you would handle them for any other sequence of CoAP requests.
Tokens do not play any special role with Block.

(That’s why the draft doesn’t even mention tokens, except in the Observe example, where it is given to remind people that the Observation relationship blocks its token so you have to use different ones for the block-wise transfer.
Now that example might give the impression the block-wise transfer *has* to be done with the same token (here; 0xfc) for all requests.
Actually, it just happens that it *can* be done with the same token in this case, but maybe that fact should be spelled out.  Thanks for making me aware of this possible misunderstanding.)

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Mon, 7 Jul 2014 16:49:37 +0800

Hi Castern,

Thank you for your reply.

> You lost me, Figure 2 is about Block2.

Thank you for your correction.

> Now that example might give the impression the block-wise transfer *has* 
> to be done with the same token (here; 0xfc) for all requests.
Yes.
While one token identifies one request, retransmission of one request should 
affect messages with the same tokens.
It will be different if each request has a different token.
Current draft considered retransmission of message(s), it may also consider 
the retransmission of Request.

Regard,

Gengyu WEI
-----原始邮件----- 
From: Carsten Bormann
Sent: Monday, July 07, 2014 3:54 PM
To: weigengyu
Cc: core
Subject: Re: [core] WGLC for draft-ietf-core-block-15

> Should these GETs With BLOCK2 have the same TOKEN?

Each response (piggybacked in an ACK here) should have the same token that 
the request has.
The client gets to choose the request token for each request independently; 
it might be reusing a token or it might be using a new one; that is up to 
the client’s token usage.

You handle the tokens just like you would handle them for any other sequence 
of CoAP requests.
Tokens do not play any special role with Block.

(That’s why the draft doesn’t even mention tokens, except in the Observe 
example, where it is given to remind people that the Observation 
relationship blocks its token so you have to use different ones for the 
block-wise transfer.
Now that example might give the impression the block-wise transfer *has* to 
be done with the same token (here; 0xfc) for all requests.
Actually, it just happens that it *can* be done with the same token in this 
case, but maybe that fact should be spelled out.  Thanks for making me aware 
of this possible misunderstanding.)

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Mon, 7 Jul 2014 17:04:13 +0800

Hi Carsten,

Yes.

Regard,

Gengyu WEI
-----原始邮件----- 
From: Carsten Bormann
Sent: Monday, July 07, 2014 3:54 PM
To: weigengyu
Cc: core
Subject: Re: [core] WGLC for draft-ietf-core-block-15

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Mon, 7 Jul 2014 22:17:55 +0800

Hi all,

The concept of one CoAP request in block transfer needs clarifying.
And the the relation between token and one request has been described in 
RFC7252.
So, If the request is sent in a block, then it may be (A) the whole bLock is 
a request, or (B) each piece of the block is a request.

If (A), each piece of the block should have the same token.
If (B), each piece of the block should use different token.

By my understanding it is (A).
The problem that I concern is when the request needs restransmiting,
the client will re-send the whole block.

Regards,

Gengyu WEI
-----原始邮件----- 
From: weigengyu
Sent: Monday, July 07, 2014 5:04 PM
To: Carsten Bormann
Cc: core
Subject: Re: [core] WGLC for draft-ietf-core-block-15

Hi Carsten,

Yes.

Regard,

Gengyu WEI
-----原始邮件----- 
From: Carsten Bormann
Sent: Monday, July 07, 2014 3:54 PM
To: weigengyu
Cc: core
Subject: Re: [core] WGLC for draft-ietf-core-block-15

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 7 Jul 2014 16:25:59 +0200

Point of terminology: we call the pieces “blocks”, not the entire block-wise transfer.

The -block protocol is strictly layered above the CoAP core protocol.
So there is no way the block transfer can influence or take advantage of specific token values.
Each of the blocks (pieces) is its own CoAP transfer, with its own request, response, and a token linking the two.  For all the blocks in a block-wise transfer, the token may be the same if the client chooses so (and the conditions for re-using a token are fulfilled), they may be all different, or a mixture of these.

Grüße, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 7 Jul 2014 11:41:17 -0400

Hi Carsten,

Do you think it is worth adding an updated version of the Figure 1 (Abstract Layering of CoAP) from RFC 7252 into core-block-15 to show this layering?

Akbar

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Monday, July 07, 2014 10:26 AM
To: weigengyu
Cc: [email-masked]
Subject: Re: [core] WGLC for draft-ietf-core-block-15

Point of terminology: we call the pieces "blocks", not the entire block-wise transfer.

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Tue, 8 Jul 2014 05:10:11 +0800

Hi Carsten,

Using Block Transfer, the token of each CoAP request can be the same or not.
Actually, token functions nothing for the client.

Considering CoRE, zero length token is best for all requests as it is the 
shortest.

Within the Block transfer option, another means is defined to relate each 
request carried one block and the response
instead of using  token.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Carsten Bormann
Sent: Monday, July 07, 2014 10:25 PM
To: weigengyu
Cc: [email-masked]
Subject: Re: [core] WGLC for draft-ietf-core-block-15

Point of terminology: we call the pieces “blocks”, not the entire 
block-wise transfer.

The -block protocol is strictly layered above the CoAP core protocol.
So there is no way the block transfer can influence or take advantage of 
specific token values.
Each of the blocks (pieces) is its own CoAP transfer, with its own request, 
response, and a token linking the two.  For all the blocks in a block-wise 
transfer, the token may be the same if the client chooses so (and the 
conditions for re-using a token are fulfilled), they may be all different, 
or a mixture of these.

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Tue, 8 Jul 2014 05:21:47 +0800

Hi Akbar,

Refering to layered protocol concept,
the upper layer is tried to use the lower layer capabilities instead of 
making useless.

Regard,

Gengyu WEI
-----原始邮件----- 
From: Rahman, Akbar
Sent: Monday, July 07, 2014 11:41 PM
To: Carsten Bormann ; weigengyu
Cc: [email-masked]
Subject: RE: [core] WGLC for draft-ietf-core-block-15

Hi Carsten,

Do you think it is worth adding an updated version of the Figure 1 (Abstract 
Layering of CoAP) from RFC 7252 into core-block-15 to show this layering?

Akbar

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Monday, July 07, 2014 10:26 AM
To: weigengyu
Cc: [email-masked]
Subject: Re: [core] WGLC for draft-ietf-core-block-15

Point of terminology: we call the pieces "blocks", not the entire block-wise 
transfer.

Grüße, Carsten