Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)
draft-ietf-core-http-mapping-17

Note: This ballot was opened for revision 14 and is now closed.

(Spencer Dawkins) (was Discuss) Yes

Comment (2016-10-03 for -15)
No email
send info
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) (was Discuss) Yes

Comment (2016-10-05 for -15)
No email
send info
Thanks for addressing my DISCUSS and COMMENTs.

(Alexey Melnikov) Yes

Comment (2016-12-02)
No email
send info
This document is returning as Proposed Standard (it was Informational earlier).

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2016-12-12)
No email
send info
Thanks for addressing my discuss!

(Benoît Claise) (was Discuss) No Objection

Comment (2016-10-13 for -15)
No email
send info
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

Alissa Cooper No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2016-12-02)
No email
send info
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." ?

(Joel Jaeggli) No Objection

Comment (2016-10-12 for -15)
No email
send info
מנחם דודג' <menachemdodge1@gmail.com> performed the opsdir review

(Mirja Kühlewind) No Objection

Comment (2016-09-19 for -14)
No email
send info
Well written doc! Thanks!

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2016-09-27 for -14)
No email
send info
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.

Alvaro Retana No Objection