Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)
draft-ietf-core-http-mapping-17
Yes
No Objection
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
Note: This ballot was opened for revision 14 and is now closed.
Alexey Melnikov Former IESG member
Yes
Yes
(2016-12-02)
Unknown
This document is returning as Proposed Standard (it was Informational earlier).
Spencer Dawkins Former IESG member
(was Discuss)
Yes
Yes
(2016-10-03 for -15)
Unknown
Thanks for addressing my Discuss and comments. For what it's worth, I also like the changes you made to address other feedback, too.
Suresh Krishnan Former IESG member
(was Discuss)
Yes
Yes
(2016-10-05 for -15)
Unknown
Thanks for addressing my DISCUSS and COMMENTs.
Alia Atlas Former IESG member
No Objection
No Objection
(for -14)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -15)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
()
Unknown
Ben Campbell Former IESG member
(was Discuss)
No Objection
No Objection
(2016-12-12)
Unknown
Thanks for addressing my discuss!
Benoît Claise Former IESG member
(was Discuss)
No Objection
No Objection
(2016-10-13 for -15)
Unknown
Previous DISCUSS point: One point I would like to DISCUSS: I wonder if this document is not already obsolete, now that we have the new FETCH/iPATCH/PATCH methods (draft-ietf-core-etch)? Should we expect an update document for the new mappings? Don't we need at least a reference to draft-ietf-core-etch, expressing it's not covered? The point has been discussed, so moving to a COMMENT. I trust the responsible AD to take the right action. Regards, Benoit
Deborah Brungard Former IESG member
No Objection
No Objection
(for -15)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -14)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2016-10-12 for -15)
Unknown
מנחם דודג' <menachemdodge1@gmail.com> performed the opsdir review
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2016-09-27 for -14)
Unknown
Thank you for addressing my discuss points with the proposed text. I'll follow along with Stephen's discuss as he picked up on some other important points.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2016-09-19 for -14)
Unknown
Well written doc! Thanks!
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2016-12-02)
Unknown
Thanks for handling my DISCUSS points. OLD Comments below. I didn't check 'em vs. the latest draft. --- Generally, I'd have been happier if this document went more towards reducing the attack surface and seemed less keen on being more flexible. I assume though that the WG considered that. (Some specific places that occurred to me are noted below.) I also agree with Kathleen's discuss. - 6.1: "free to attempt mapping a single Accept header in a GET request to multiple CoAP GET requests" - does that provide a potential way to DoS (e.g. battery depletion) devices in the constrained network? If so, would a warning be useful? E.g. to limit the number of times a given media type is attempted. - 6.1: What "other forms of access control" do you mean? - 6.2: This looks like it allows too large an attack surface and maybe you ought default to denying - 6.5: Transcoding bugs galore! Given the history of bugs in transcoding libraries shouldn't you recommend some caution here? And are there forms of zipbomb that might cause problems? - 8.2: The presentation of the formula is not clear to me. You say "reduces M_R iff..." but that's not a clear "method to decide" as promised. - 10.3: In practice, what does "other means" mean in "This recommendation may be relaxed in case the destination network is believed to be secured by other means." ?