Skip to main content

Shepherd writeup
draft-ietf-core-coap

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in
the title page header?

This is intended to be Proposed Standard.  CoAP has broad
industry support, and is intended to form the basis for a wide
variety of machine to machine applications.  The title page
header reflects this.


(2) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
The Constrained Application Protocol (CoAP) is a specialized web
transfer protocol for use with constrained nodes and constrained
(e.g., low-power, lossy) networks. The nodes often have 8-bit
microcontrollers with small amounts of ROM and RAM, while
constrained networks such as 6LoWPAN often have high packet error
rates and a typical throughput of 10s of kbit/s. The protocol is
designed for machine-to-machine (M2M) applications such as smart
energy and building automation.

CoAP provides a request/response interaction model between
application endpoints, supports built-in discovery of resources,
and includes key concepts of the Web such as URIs and Internet
media types. CoAP easily interfaces with HTTP for integration
with the Web while meeting specialized requirements such as
multicast support, very low overhead and simplicity for
constrained environments.

Working Group Summary
WG review has been intense, with input from many participants
beyond the document authors, and particularly input from
implementers.  There are no particular controversies to note.

Document Quality
There have been multiple expert reviews, from security,
applications (once a general review, and once specifically on the
URI schema), and transport areas. All the reviews produced useful
input, that resulted in significant changes to the specification.
All review feedback is now incorporated in the final document.

There are at least 15 publically disclosed implementations, both
commercial and open-source. There have been several
interoperability events, and a high level of interoperability has
been reported from those events.

Personnel
Document Shepherd is Andrew McGregor <andrewmcgr@google.com>
Responsible Area Director is Barry Leiba <barryleiba@computer.org>
Zach Shelby <zach@sensinode.com> is suggested as the designated
expert for the IANA registries defined in Sections 12.2 and 12.3.


(3) Briefly describe the review of this document that was
performed by the Document Shepherd.

As shepherd, I have read through the document for editorial
matters and clarity of language. Since it has had intense review
already, both for logical clarity and technical correctness, I
judge it ready for publication.


(4) Does the document Shepherd have any concerns about the depth
or breadth of the reviews that have been performed?

No concerns about review, this specification has had really
in-depth discussion of every aspect.


(5) Do portions of the document need review from a particular or
from broader perspective, e.g., security, operational complexity,
AAA, DNS, DHCP, XML, or internationalization? If so, describe the
review that took place.

There were two security reviews, once early in the process and a
do-over recently. The initial concerns were addressed partly by
reworking security basics, and partly by splitting some of the
more advanced and problematic features into a separate document
where they can be developed further without holding up the base
specification.


There was a URI schema review, which was adequately resolved
after some clarification of the intent of the specification.

Congestion control was identified as an issue, and there was
considerable discussion both at IETF 84 and on-list.  The
relevant transport experts are now satisfied that CoAP has no
lurking congestion control disasters, the CoAP Block
specification will need further work and was separated from the
base document.


(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area
Director and/or the IESG should be aware of?

No particular concerns. CoAP is technically solid, widely
implemented, and has broad support.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of
BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.  B. Frank was removed as author in the final draft because
he is uncontactable, and we do not have confirmation from him.


(8) Has an IPR disclosure been filed that references this
document?

There are no filed IPR disclosures that the authors or shepherd
are aware of.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

This document represents solid WG consensus, broadly understood.


(10) Has anyone threatened an appeal or otherwise indicated
extreme discontent?

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough;
this check needs to be thorough.

The idnits tool reports only false positives due to some notation
in the document being mistaken for references.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type
reviews.

The URI schema defined has been reviewed, and the reviewers were
happy with the eventual result.


(13) Have all references within this document been identified as
either normative or informative?

Yes


(14) Are there normative references to documents that are not
ready for advancement or are otherwise in an unclear state? If
such normative references exist, what is the plan for their
completion?

There are two such references.  One is in the RFC Editor queue,
draft-farrell-decade-ni.  The other is draft-ietf-tls-oob-pubkey,
which is making progress.


(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

No downward references exist.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header,
listed in the abstract, and discussed in the introduction? If the
RFCs are not listed in the Abstract and Introduction, explain
why, and point to the part of the document where the relationship
of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers
it unnecessary.

CoAP does not change the status of existing RFCs.


(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency
with the body of the document. Confirm that all protocol
extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any
referenced IANA registries have been clearly identified. Confirm
that newly created IANA registries include a detailed
specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see
RFC 5226).

CoAP requests an IPv4 multicast address, two IPv6 multicast
addresses, two UDP port numbers, and two URI schemes.  All these
reservation requests have had expert review, and are correctly
scoped and syntactically reasonable.

CoAP also creates 3 new IANA registries, for CoAP Codes (with
subregistries CoAP Method Codes and CoAP Response Codes), CoAP
Option Numbers and CoAP Content Formats.  All of these have
complete specifications for initial content, allocation
procedures, and names.


(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG
would find useful in selecting the IANA Experts for these new
registries.

CoAP Option Numbers and Content Formats both have codepoint
ranges that require Expert Review. Experts will need to
understand the encoding formats for these options and the
consequences of the encoding for packet size. Suitable candidates
amongst the authors and implementers should be reasonably
plentiful given the number of implementations.


(19) Describe reviews and automated checks performed by the
Document Shepherd to validate sections of the document written in
a formal language, such as XML code, BNF rules, MIB definitions,
etc.

I have not personally verified this, but I am told the examples
were all generated from packet dumps from interoperable running
code.
Back