Subject: [core] core-coap RFC status

From: "Peter A. Bigot" <[email-masked]>
Date: Fri, 20 Dec 2013 08:53:18 -0600

draft-ietf-core-coap has been hanging in limbo for about a year now,
currently waiting for some missing references. In this state it's not
possible to record technical issues where they can easily be found by
future implementers (viz. as errata recorded on the IETF RFC page).

There are gaps in -coap that impact the evaluation of documents that are
in or have passed WGLC. The interaction of message cancellation with
retransmission requirements affects an assessment of the supersedure
approach in -observe. I expect -groupcomm also has some impact on how
-coap must be interpreted since -coap only barely mentions multicast
support.

Is there an estimate of when this will be resolved?

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 20 Dec 2013 16:14:48 +0100

> Is there an estimate of when this will be resolved?

The status of the RFC as it progresses through publication can be watched at:

	http://www.rfc-editor.org/cluster_info.php?cid=C203

This shows that publication is held up by waiting for two security area documents.

Following the links on this page, and using the “history” tab on the linked pages, we see:

draft-mcgrew-tls-aes-ccm-ecc-07
2013-10-24	07	State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation

draft-ietf-tls-oob-pubkey-10
2013-11-21	10	State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation

So both documents have already been approved a while ago, but are waiting for some processing by their responsible AD.
(Unfortunately, this also means the IANA assignments needed to use CoAP’s RPK mode also haven’t been made.
We went into the last CoAP interop with made-up numbers for these.)

Once the write-ups for the two drafts are available, the RFC editor will process them, and then the entire cluster will be published; this typically takes another two months.

This does not have to keep us from creating implementer notes.
Two documents of interest are:
— http://tools.ietf.org/html/draft-bormann-core-roadmap
  This is a place where we can collect information about how pieces fit together, 
  as well as non-obvious spec interpretation issues.
— http://tools.ietf.org/html/draft-kovatsch-lwig-coap
  This can be used to collect implementation notes, including implementation techniques 
  that may not be obvious.

Both documents are meant to be open to contributions.
If you are aware of something that needs to be documented, please tell us (or, even better, write text).

Grüße, Carsten

---

From: Barry Leiba <[email-masked]>
Date: Mon, 23 Dec 2013 13:56:56 -0500

In addition to what Carsten said, let me add one thing:

> In this state it's not

The CoAP document will go through a final edit phase (called "AUTH48")
once the missing references are cleared (and I'm working with Sean,
the responsible AD for the two TLS documents in question, to get that
to happen as soon as possible).  Significant changes to the document
are not allowed in AUTH48 state, but:

1. Anything that would otherwise be filed as errata can and should be
fixed in AUTH48.  If there are things of that nature that we know now
that need to be corrected, be sure the authors and chairs know about
them so we can get them fixed at the time the RFC is published, so we
don't need to file errata later.

2. It's possible to have the working group review other changes and to
make them during AUTH48.  This does not include significant rethinking
of things, nor resolution of new controversies (or revisiting of old
ones), but it can include technical faults that were not anticipated
and have since been discovered.  Again, if there are things of this
nature, please make sure we sort them out *before* the RFC is
published.

Barry, Applications AD

---

From: "Peter A. Bigot" <[email-masked]>
Date: Mon, 23 Dec 2013 13:34:39 -0600

> nature, please make sure we sort them out *before* the RFC is

The two topics I recall planning to raise as technical errata are:

1) the ability to express option numbers that exceed 65535, as raised in
http://www.ietf.org/mail-archive/web/core/current/msg04972.html.

2) The interaction of message cancellation (a REST-layer concept) with
CoAP message-layer retransmission which is subject to congestion
limitations.  The fundamental issue is whether base CoAP permits a
right-to-transmit that is left unused due to cancellation to be
transferred to a new message, and if so any constraints on how such a
transmission may be used.  One entry point to the massive but unresolved
(AFAIK) discussion is at
http://www.ietf.org/mail-archive/web/core/current/msg05038.html.  (I
think -observe was updated in some way resulting from this discussion,
but that the underlying issue with respect to -core remains unaddressed.)

My views and proposals on these issues are in the referenced messages
and their follow-ups.  I don't recall a consensus on either.

Peter