draft-ietf-core-block-20.txt   draft-ietf-core-block-21.txt 
CoRE Working Group C. Bormann CoRE Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track Z. Shelby, Ed. Updates: 7252 (if approved) Z. Shelby, Ed.
Expires: October 31, 2016 ARM Intended status: Standards Track ARM
April 29, 2016 Expires: January 9, 2017 July 08, 2016
Block-wise transfers in CoAP Block-wise transfers in CoAP
draft-ietf-core-block-20 draft-ietf-core-block-21
Abstract Abstract
CoAP is a RESTful transfer protocol for constrained nodes and CoAP is a RESTful transfer protocol for constrained nodes and
networks. Basic CoAP messages work well for the small payloads we networks. Basic CoAP messages work well for the small payloads we
expect from temperature sensors, light switches, and similar expect from temperature sensors, light switches, and similar
building-automation devices. Occasionally, however, applications building-automation devices. Occasionally, however, applications
will need to transfer larger payloads -- for instance, for firmware will need to transfer larger payloads -- for instance, for firmware
updates. With HTTP, TCP does the grunt work of slicing large updates. With HTTP, TCP does the grunt work of slicing large
payloads up into multiple packets and ensuring that they all arrive payloads up into multiple packets and ensuring that they all arrive
skipping to change at page 1, line 41 skipping to change at page 1, line 41
basic CoAP with a pair of "Block" options, for transferring multiple basic CoAP with a pair of "Block" options, for transferring multiple
blocks of information from a resource representation in multiple blocks of information from a resource representation in multiple
request-response pairs. In many important cases, the Block options request-response pairs. In many important cases, the Block options
enable a server to be truly stateless: the server can handle each enable a server to be truly stateless: the server can handle each
block transfer separately, with no need for a connection setup or block transfer separately, with no need for a connection setup or
other server-side memory of previous block transfers. other server-side memory of previous block transfers.
In summary, the Block options provide a minimal way to transfer In summary, the Block options provide a minimal way to transfer
larger representations in a block-wise fashion. larger representations in a block-wise fashion.
A CoAP implementation that does not support these options generally
is limited in the size of the representations that can be exchanged.
There is therefore an expectation that the Block options are very
widely implemented in CoAP implementations, which is why this
specification is listed as "updating" RFC 7252.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 31, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Block-wise transfers . . . . . . . . . . . . . . . . . . . . 5 2. Block-wise transfers . . . . . . . . . . . . . . . . . . . . 6
2.1. The Block2 and Block1 Options . . . . . . . . . . . . . . 6 2.1. The Block2 and Block1 Options . . . . . . . . . . . . . . 7
2.2. Structure of a Block Option . . . . . . . . . . . . . . . 7 2.2. Structure of a Block Option . . . . . . . . . . . . . . . 7
2.3. Block Options in Requests and Responses . . . . . . . . . 9 2.3. Block Options in Requests and Responses . . . . . . . . . 9
2.4. Using the Block2 Option . . . . . . . . . . . . . . . . . 11 2.4. Using the Block2 Option . . . . . . . . . . . . . . . . . 11
2.5. Using the Block1 Option . . . . . . . . . . . . . . . . . 12 2.5. Using the Block1 Option . . . . . . . . . . . . . . . . . 13
2.6. Combining Block-wise Transfers with the Observe Option . 13 2.6. Combining Block-wise Transfers with the Observe Option . 14
2.7. Combining Block1 and Block2 . . . . . . . . . . . . . . . 14 2.7. Combining Block1 and Block2 . . . . . . . . . . . . . . . 15
2.8. Combining Block2 with Multicast . . . . . . . . . . . . . 15 2.8. Combining Block2 with Multicast . . . . . . . . . . . . . 15
2.9. Response Codes . . . . . . . . . . . . . . . . . . . . . 15 2.9. Response Codes . . . . . . . . . . . . . . . . . . . . . 16
2.9.1. 2.31 Continue . . . . . . . . . . . . . . . . . . . . 15 2.9.1. 2.31 Continue . . . . . . . . . . . . . . . . . . . . 16
2.9.2. 4.08 Request Entity Incomplete . . . . . . . . . . . 15 2.9.2. 4.08 Request Entity Incomplete . . . . . . . . . . . 16
2.9.3. 4.13 Request Entity Too Large . . . . . . . . . . . . 15 2.9.3. 4.13 Request Entity Too Large . . . . . . . . . . . . 16
2.10. Caching Considerations . . . . . . . . . . . . . . . . . 16
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.10. Caching Considerations . . . . . . . . . . . . . . . . . 17
3.1. Block2 Examples . . . . . . . . . . . . . . . . . . . . . 17 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Block1 Examples . . . . . . . . . . . . . . . . . . . . . 21 3.1. Block2 Examples . . . . . . . . . . . . . . . . . . . . . 18
3.3. Combining Block1 and Block2 . . . . . . . . . . . . . . . 22 3.2. Block1 Examples . . . . . . . . . . . . . . . . . . . . . 22
3.4. Combining Observe and Block2 . . . . . . . . . . . . . . 24 3.3. Combining Block1 and Block2 . . . . . . . . . . . . . . . 23
4. The Size2 and Size1 Options . . . . . . . . . . . . . . . . . 27 3.4. Combining Observe and Block2 . . . . . . . . . . . . . . 25
5. HTTP Mapping Considerations . . . . . . . . . . . . . . . . . 29 4. The Size2 and Size1 Options . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5. HTTP Mapping Considerations . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
7.1. Mitigating Resource Exhaustion Attacks . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7.2. Mitigating Amplification Attacks . . . . . . . . . . . . 32 7.1. Mitigating Resource Exhaustion Attacks . . . . . . . . . 32
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 7.2. Mitigating Amplification Attacks . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . 33 8.1. Normative References . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The work on Constrained RESTful Environments (CoRE) aims at realizing The work on Constrained RESTful Environments (CoRE) aims at realizing
the REST architecture in a suitable form for the most constrained the REST architecture in a suitable form for the most constrained
nodes (such as microcontrollers with limited RAM and ROM [RFC7228]) nodes (such as microcontrollers with limited RAM and ROM [RFC7228])
and networks (such as 6LoWPAN, [RFC4944]) [RFC7252]. The CoAP and networks (such as 6LoWPAN, [RFC4944]) [RFC7252]. The CoAP
protocol is intended to provide RESTful [REST] services not unlike protocol is intended to provide RESTful [REST] services not unlike
HTTP [RFC7230], while reducing the complexity of implementation as HTTP [RFC7230], while reducing the complexity of implementation as
well as the size of packets exchanged in order to make these services well as the size of packets exchanged in order to make these services
skipping to change at page 4, line 35 skipping to change at page 4, line 43
within block-wise transfers outside the use case of Section 2.8 would within block-wise transfers outside the use case of Section 2.8 would
escalate the overall non-delivery probability). To be perfectly escalate the overall non-delivery probability). To be perfectly
clear, the present specification also does not remove any of the clear, the present specification also does not remove any of the
constraints posed by the base specification it is strictly layered on constraints posed by the base specification it is strictly layered on
top of; e.g., back-to-back packets are limited by Section 4.7 of top of; e.g., back-to-back packets are limited by Section 4.7 of
[RFC7252] (NSTART as a limit for initiating exchanges, PROBING_RATE [RFC7252] (NSTART as a limit for initiating exchanges, PROBING_RATE
as a limit for sending with no response): block-wise transfers cannot as a limit for sending with no response): block-wise transfers cannot
send/solicit more traffic than a client could be sending to the same send/solicit more traffic than a client could be sending to the same
server without the block-wise mode. server without the block-wise mode.
In some cases, the present specification will RECOMMEND that a client
perform a sequence of block-wise transfers "without undue delay".
This cannot be phrased as an interoperability requirement, but is an
expectation on implementation quality. Conversely, the expectation
is that servers will not have go out of their way to accommodate
clients that take forever to finish a block-wise transfer. E.g., for
a block-wise GET, if the resource changes while this proceeds, the
ETag for a further block obtained may be different. To avoid this
happening all the time for a fast-changing resource, a server MAY try
to keep a cache around for a specific client for a short amount of
time. The expectation here is that the lifetime for such a cache can
be kept short, on the order of a few expected round-trip times,
counting from the previous block transferred.
In summary, this specification adds a pair of Block options to CoAP In summary, this specification adds a pair of Block options to CoAP
that can be used for block-wise transfers. Benefits of using these that can be used for block-wise transfers. Benefits of using these
options include: options include:
o Transfers larger than what can be accommodated in constrained- o Transfers larger than what can be accommodated in constrained-
network link-layer packets can be performed in smaller blocks. network link-layer packets can be performed in smaller blocks.
o No hard-to-manage conversation state is created at the adaptation o No hard-to-manage conversation state is created at the adaptation
layer or IP layer for fragmentation. layer or IP layer for fragmentation.
skipping to change at page 5, line 9 skipping to change at page 5, line 32
o Both sides have a say in the block size that actually will be o Both sides have a say in the block size that actually will be
used. used.
o The resulting exchanges are easy to understand using packet o The resulting exchanges are easy to understand using packet
analyzer tools and thus quite accessible to debugging. analyzer tools and thus quite accessible to debugging.
o If needed, the Block options can also be used (without changes) to o If needed, the Block options can also be used (without changes) to
provide random access to power-of-two sized blocks within a provide random access to power-of-two sized blocks within a
resource representation. resource representation.
A CoAP implementation that does not support these options generally
is limited in the size of the representations that can be exchanged,
see Section 4.6 of [RFC7252]. Even though the options are Critical,
a server may decide to start using them in an unsolicited way in a
response. No effort was expended to provide a capability indication
mechanism supporting that decision: since the block-wise transfer
mechanisms are so fundamental to the use of CoAP for representations
larger than about a kilobyte, there is an expectation that they are
very widely implemented.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119, BCP 14 [RFC2119] and indicate requirement levels for compliant 2119, BCP 14 [RFC2119] and indicate requirement levels for compliant
CoAP implementations. CoAP implementations.
In this document, the term "byte" is used in its now customary sense In this document, the term "byte" is used in its now customary sense
as a synonym for "octet". as a synonym for "octet".
Where bit arithmetic is explained, this document uses the notation Where bit arithmetic is explained, this document uses the notation
skipping to change at page 13, line 33 skipping to change at page 14, line 18
always keep the partial request body for as long. always keep the partial request body for as long.
The error code 4.13 (Request Entity Too Large) can be returned at any The error code 4.13 (Request Entity Too Large) can be returned at any
time by a server that does not currently have the resources to store time by a server that does not currently have the resources to store
blocks for a block-wise request payload transfer that it would intend blocks for a block-wise request payload transfer that it would intend
to implement in an atomic fashion. (Note that a 4.13 response to a to implement in an atomic fashion. (Note that a 4.13 response to a
request that does not employ Block1 is a hint for the client to try request that does not employ Block1 is a hint for the client to try
sending Block1, and a 4.13 response with a smaller SZX in its Block1 sending Block1, and a 4.13 response with a smaller SZX in its Block1
option than requested is a hint to try a smaller SZX.) option than requested is a hint to try a smaller SZX.)
A block-wise transfer of a request payload that is implemented in a
stateless fashion at the server is likely to leave the resource being
operated on in an inconsistent state during the time the transfer is
still ongoing or when the client does not complete the transfer.
This characteristic is closer to that of remote file systems than to
that of HTTP, where state is always kept on the server during a
transfer. Techniques well known from shared file access (e.g.,
client-specific temporary resources) can be used to mitigate this
difference from HTTP.
The Block1 option provides no way for a single endpoint to perform The Block1 option provides no way for a single endpoint to perform
multiple concurrently proceeding block-wise request payload transfer multiple concurrently proceeding block-wise request payload transfer
(e.g., PUT or POST) operations to the same resource. Starting a new (e.g., PUT or POST) operations to the same resource. Starting a new
block-wise sequence of requests to the same resource (before an old block-wise sequence of requests to the same resource (before an old
sequence from the same endpoint was finished) simply overwrites the sequence from the same endpoint was finished) simply overwrites the
context the server may still be keeping. (This is probably exactly context the server may still be keeping. (This is probably exactly
what one wants in this case -- the client may simply have restarted what one wants in this case -- the client may simply have restarted
and lost its knowledge of the previous sequence.) and lost its knowledge of the previous sequence.)
2.6. Combining Block-wise Transfers with the Observe Option 2.6. Combining Block-wise Transfers with the Observe Option
skipping to change at page 15, line 45 skipping to change at page 16, line 36
2.9.2. 4.08 Request Entity Incomplete 2.9.2. 4.08 Request Entity Incomplete
This new client error status code indicates that the server has not This new client error status code indicates that the server has not
received the blocks of the request body that it needs to proceed. received the blocks of the request body that it needs to proceed.
The client has not sent all blocks, not sent them in the order The client has not sent all blocks, not sent them in the order
required by the server, or has sent them long enough ago that the required by the server, or has sent them long enough ago that the
server has already discarded them. server has already discarded them.
(Note that one reason for not having the necessary blocks at hand may (Note that one reason for not having the necessary blocks at hand may
be a Content-Format mismatch, see Section 2.3.) be a Content-Format mismatch, see Section 2.3. Implementation note:
A server can reject a Block1 transfer with this code when NUM != 0
and a different Content-Format is indicated than expected from the
current state of the resource. If it implements the transfer in a
stateless fashion, it can match up the Content-Format of the block
against that of the existing resource. If it implements the transfer
in an atomic fashion, it can match up the block against the partially
reassembled piece of representation that is going to replace the
state of the resource.)
2.9.3. 4.13 Request Entity Too Large 2.9.3. 4.13 Request Entity Too Large
In [RFC7252], Section 5.9.2.9, the response code 4.13 (Request Entity In [RFC7252], Section 5.9.2.9, the response code 4.13 (Request Entity
Too Large) is defined to be like HTTP 413 "Request Entity Too Large". Too Large) is defined to be like HTTP 413 "Request Entity Too Large".
[RFC7252] also recommends that this response SHOULD include a Size1 [RFC7252] also recommends that this response SHOULD include a Size1
Option (Section 4) to indicate the maximum size of request entity the Option (Section 4) to indicate the maximum size of request entity the
server is able and willing to handle, unless the server is not in a server is able and willing to handle, unless the server is not in a
position to make this information available. position to make this information available.
skipping to change at page 32, line 29 skipping to change at page 33, line 29
[RFC7252] discusses the susceptibility of CoAP end-points for use in [RFC7252] discusses the susceptibility of CoAP end-points for use in
amplification attacks. amplification attacks.
A CoAP server can reduce the amount of amplification it provides to A CoAP server can reduce the amount of amplification it provides to
an attacker by offering large resource representations only in an attacker by offering large resource representations only in
relatively small blocks. With this, e.g., for a 1000 byte resource, relatively small blocks. With this, e.g., for a 1000 byte resource,
a 10-byte request might result in an 80-byte response (with a 64-byte a 10-byte request might result in an 80-byte response (with a 64-byte
block) instead of a 1016-byte response, considerably reducing the block) instead of a 1016-byte response, considerably reducing the
amplification provided. amplification provided.
8. Acknowledgements 8. References
Much of the content of this draft is the result of discussions with
the [RFC7252] authors, and via many CoRE WG discussions.
Charles Palmer provided extensive editorial comments to a previous
version of this draft, some of which the authors hope to have covered
in this version. Esko Dijk reviewed a more recent version, leading
to a number of further editorial improvements, a solution to the 4.13
ambiguity problem, and the section about combining Block and
multicast. Markus Becker proposed getting rid of an ill-conceived
default value for the Block2 and Block1 options. Peter Bigot
insisted on a more systematic coverage of the options and response
code. Qin Wu provided a review for the IETF Operational directorate,
and Goeran Selander commented on the security considerations.
Kepeng Li, Linyi Tian, and Barry Leiba wrote up an early version of
the Size Option, which has informed this draft. Klaus Hartke wrote
some of the text describing the interaction of Block2 with Observe.
Matthias Kovatsch provided a number of significant simplifications of
the protocol.
The IESG reviewers provided very useful comments. Spencer Dawkins
even suggested new text. Mirja Kuehlewind and he insisted on being
more explicit about the layering of block-wise transfers on top of
the base protocol. Ben Campbell helped untangling some MUST/SHOULD
soup. Comments by Alexey Melnikov, as well as the gen-art review by
Jouni Korhonen and the ops-dir review by Qin Wu, caused further
improvements to the text.
9. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <http://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<http://www.rfc-editor.org/info/rfc7641>. <http://www.rfc-editor.org/info/rfc7641>.
9.2. Informative References 8.2. Informative References
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Ph.D. Dissertation, Network-based Software Architectures", Ph.D. Dissertation,
University of California, Irvine, 2000, University of California, Irvine, 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/ <http://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>. fielding_dissertation.pdf>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", Overview, Assumptions, Problem Statement, and Goals",
skipping to change at page 34, line 20 skipping to change at page 34, line 41
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
RFC 7233, DOI 10.17487/RFC7233, June 2014, RFC 7233, DOI 10.17487/RFC7233, June 2014,
<http://www.rfc-editor.org/info/rfc7233>. <http://www.rfc-editor.org/info/rfc7233>.
Acknowledgements
Much of the content of this draft is the result of discussions with
the [RFC7252] authors, and via many CoRE WG discussions.
Charles Palmer provided extensive editorial comments to a previous
version of this draft, some of which the authors hope to have covered
in this version. Esko Dijk reviewed a more recent version, leading
to a number of further editorial improvements, a solution to the 4.13
ambiguity problem, and the section about combining Block and
multicast. Markus Becker proposed getting rid of an ill-conceived
default value for the Block2 and Block1 options. Peter Bigot
insisted on a more systematic coverage of the options and response
code. Qin Wu provided a review for the IETF Operational directorate,
and Goeran Selander commented on the security considerations.
Kepeng Li, Linyi Tian, and Barry Leiba wrote up an early version of
the Size Option, which has informed this draft. Klaus Hartke wrote
some of the text describing the interaction of Block2 with Observe.
Matthias Kovatsch provided a number of significant simplifications of
the protocol.
The IESG reviewers provided very useful comments. Spencer Dawkins
even suggested new text. Mirja Kuehlewind and he insisted on being
more explicit about the layering of block-wise transfers on top of
the base protocol. Ben Campbell helped untangling some MUST/SHOULD
soup. Comments by Alexey Melnikov, as well as the gen-art review by
Jouni Korhonen and the ops-dir review by Qin Wu, caused further
improvements to the text.
Authors' Addresses Authors' Addresses
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
 End of changes. 15 change blocks. 
65 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/