Subject: [core] Stephen Farrell's No Objection on draft-ietf-core-http-mapping-17: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Fri, 02 Dec 2016 06:11:15 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-core-http-mapping-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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." ?

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 2 Dec 2016 14:42:01 +0000

Hi Stephen,

All your comments had been addressed in –15 [1] and the relevant text has not changed since then.

Cheers, thanks,
t

[1] https://www.ietf.org/rfcdiff?url1=draft-ietf-core-http-mapping-14&url2=draft-ietf-core-http-mapping-15

On 02/12/2016 14:11, "core on behalf of Stephen Farrell" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
Stephen Farrell has entered the following ballot position for
draft-ietf-core-http-mapping-17: No Objection

_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core