Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)
draft-ietf-core-http-mapping-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-02-28
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-02-27
|
17 | (System) | RFC Editor state changed to AUTH48 from AUTH48-DONE |
2017-02-24
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-02-07
|
17 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-01-30
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-12-24
|
17 | Gunter Van de Velde | Request for Telechat review by OPSDIR Completed: Has Issues. Reviewer: Susan Hares. |
2016-12-22
|
17 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Dacheng Zhang. |
2016-12-20
|
17 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2016-12-20
|
17 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2016-12-20
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2016-12-19
|
17 | (System) | IANA Action state changed to In Progress |
2016-12-19
|
17 | (System) | RFC Editor state changed to EDIT |
2016-12-19
|
17 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2016-12-19
|
17 | (System) | Announcement was received by RFC Editor |
2016-12-19
|
17 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2016-12-19
|
17 | Cindy Morgan | IESG has approved the document |
2016-12-19
|
17 | Cindy Morgan | Closed "Approve" ballot |
2016-12-19
|
17 | Cindy Morgan | Ballot approval text was generated |
2016-12-19
|
17 | Cindy Morgan | Ballot writeup was changed |
2016-12-15
|
17 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Team Will not Review Version' |
2016-12-15
|
17 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from Waiting for AD Go-Ahead |
2016-12-15
|
17 | Alexey Melnikov | RFC Editor Note was changed |
2016-12-15
|
17 | Alexey Melnikov | RFC Editor Note for ballot was generated |
2016-12-15
|
17 | Alexey Melnikov | RFC Editor Note for ballot was generated |
2016-12-13
|
17 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2016-12-12
|
17 | Ben Campbell | [Ballot comment] Thanks for addressing my discuss! |
2016-12-12
|
17 | Ben Campbell | [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss |
2016-12-12
|
17 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2016-12-12
|
17 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2016-12-12
|
17 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-core-http-mapping-17.txt. If any part of this review is inaccurate, please let … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-core-http-mapping-17.txt. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" registry located at: https://www.iana.org/assignments/core-parameters/ a single new value is to be registered as follows: Attribute Value: core.hc Description: HTTP to CoAP mapping base resource. Reference: [ RFC-to-be ] Second, in the application namespace of the Media Types registry located at: https://www.iana.org/assignments/media-types/ a single, new application media type is to be registered as follows: Name: coap-payload Template: [ TBD-at-registration ] Reference: [ RFC-to-be ] The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
2016-12-02
|
17 | Martin Stiemerling | Closed request for Telechat review by TSVART with state 'Overtaken by Events' |
2016-12-02
|
17 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Susan Hares |
2016-12-02
|
17 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Susan Hares |
2016-12-02
|
17 | Alexey Melnikov | Telechat date has been changed to 2016-12-15 from 2016-10-13 |
2016-12-02
|
17 | Alexey Melnikov | [Ballot comment] This document is returning as Proposed Standard (it was Informational earlier). |
2016-12-02
|
17 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-12-02
|
17 | Stephen Farrell | [Ballot 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 … [Ballot 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." ? |
2016-12-02
|
17 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2016-12-02
|
17 | Martin Stiemerling | Request for Telechat review by TSVART is assigned to Fernando Gont |
2016-12-02
|
17 | Martin Stiemerling | Request for Telechat review by TSVART is assigned to Fernando Gont |
2016-12-02
|
17 | Martin Stiemerling | Requested Telechat review by TSVART |
2016-12-01
|
17 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2016-12-01
|
17 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2016-12-01
|
17 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dacheng Zhang |
2016-12-01
|
17 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dacheng Zhang |
2016-11-29
|
17 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-http-mapping@ietf.org, core@ietf.org, alexey.melnikov@isode.com, "Jaime … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-http-mapping@ietf.org, core@ietf.org, alexey.melnikov@isode.com, "Jaime Jimenez" Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Guidelines for HTTP-to-CoAP Mapping Implementations) to Proposed Standard The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Guidelines for HTTP-to-CoAP Mapping Implementations' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-12-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is a Second IETF LC for the document. The document was initially targeted at Informational, but is now targeting to become Proposed Standard. Abstract This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to CoAP (Constrained Application Protocol). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ballot/ No IPR declarations have been submitted directly on this I-D. |
2016-11-29
|
17 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2016-11-29
|
17 | Alexey Melnikov | Last call announcement was changed |
2016-11-29
|
17 | Alexey Melnikov | Last call announcement was generated |
2016-11-29
|
17 | Alexey Melnikov | I forgot to update the document status in Datatracker, so the Last Call announcement needs to be redone. |
2016-11-29
|
17 | Alexey Melnikov | Last call was requested |
2016-11-29
|
17 | Alexey Melnikov | IESG state changed to Last Call Requested from In Last Call |
2016-11-29
|
17 | Alexey Melnikov | Intended Status changed to Proposed Standard from Informational |
2016-11-28
|
17 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-http-mapping@ietf.org, core@ietf.org, alexey.melnikov@isode.com, "Jaime … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-http-mapping@ietf.org, core@ietf.org, alexey.melnikov@isode.com, "Jaime Jimenez" Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Guidelines for HTTP-to-CoAP Mapping Implementations) to Informational RFC The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Guidelines for HTTP-to-CoAP Mapping Implementations' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-12-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is a Second IETF LC for the document. The document was initially targeted at Informational, but is now targeting to become Proposed Standard. Abstract This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to CoAP (Constrained Application Protocol). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ballot/ No IPR declarations have been submitted directly on this I-D. |
2016-11-28
|
17 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2016-11-28
|
17 | Alexey Melnikov | Last call was requested |
2016-11-28
|
17 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation |
2016-11-28
|
17 | Alexey Melnikov | Last call announcement was changed |
2016-11-28
|
17 | Alexey Melnikov | Last call announcement was generated |
2016-11-28
|
17 | Alexey Melnikov | IESG state changed to AD Evaluation from IESG Evaluation::AD Followup |
2016-11-28
|
17 | Thomas Fossati | New version available: draft-ietf-core-http-mapping-17.txt |
2016-11-28
|
17 | (System) | New version approved |
2016-11-28
|
17 | (System) | Request for posting confirmation emailed to previous authors: core-chairs@ietf.org, "Thomas Fossati" , "Salvatore Loreto" , "Esko Dijk" , "Akbar Rahman" , "Angelo Castellani" |
2016-11-28
|
17 | Thomas Fossati | Uploaded new revision |
2016-10-25
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-10-25
|
16 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2016-10-25
|
16 | Thomas Fossati | New version available: draft-ietf-core-http-mapping-16.txt |
2016-10-25
|
16 | (System) | New version approved |
2016-10-25
|
16 | (System) | Request for posting confirmation emailed to previous authors: core-chairs@ietf.org, "Thomas Fossati" , "Salvatore Loreto" , "Esko Dijk" , "Akbar Rahman" , "Angelo Castellani" |
2016-10-25
|
16 | Thomas Fossati | Uploaded new revision |
2016-10-14
|
15 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Dacheng Zhang. |
2016-10-13
|
15 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2016-10-13
|
15 | Benoît Claise | [Ballot comment] Previous DISCUSS point: One point I would like to DISCUSS: I wonder if this document is not already obsolete, now that we have … [Ballot comment] 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 |
2016-10-13
|
15 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss |
2016-10-13
|
15 | Benoît Claise | [Ballot discuss] [sorry for coming late to the party] One point I would like to DISCUSS: I wonder if this document is not already obsolete, … [Ballot discuss] [sorry for coming late to the party] 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? |
2016-10-13
|
15 | Benoît Claise | Ballot discuss text updated for Benoit Claise |
2016-10-13
|
15 | Benoît Claise | [Ballot discuss] [sorry for coming late to the party] One point I would like to DISCUSS: I wonder if this document is not already obsolete, … [Ballot discuss] [sorry for coming late to the party] 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 want a reference to draft-ietf-core-etch, expressing it's not covered. |
2016-10-13
|
15 | Benoît Claise | Ballot discuss text updated for Benoit Claise |
2016-10-13
|
15 | Benoît Claise | [Ballot discuss] [sorry for coming late to the party] One point I would like to DISCUSS: I wonder if this document is not already obsolete, … [Ballot discuss] [sorry for coming late to the party] 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 at least want a reference to draft-ietf-core-etch, expressing it's not covered. |
2016-10-13
|
15 | Benoît Claise | [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise |
2016-10-12
|
15 | Joel Jaeggli | [Ballot comment] מנחם דודג' performed the opsdir review |
2016-10-12
|
15 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2016-10-12
|
15 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2016-10-12
|
15 | Ben Campbell | [Ballot discuss] This is a generally well written document, but it seems to be defining protocol, or at least required practices for interoperability. Why is … [Ballot discuss] This is a generally well written document, but it seems to be defining protocol, or at least required practices for interoperability. Why is it informational? If it really does make sense for it to be informational, I think a paragraph explaining why would be helpful. The 2nd paragraph in section 1 seems to attempt that, but the explanation leads me again to think that informational is not the right status. "Guidelines that...should adhere to" to increase interoperability doesn't sound informational. |
2016-10-12
|
15 | Ben Campbell | [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell |
2016-10-12
|
15 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2016-10-11
|
15 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2016-10-10
|
15 | Francis Dupont | Request for Telechat review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2016-10-06
|
15 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2016-10-06
|
15 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2016-10-05
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Menachem Dodge. |
2016-10-05
|
15 | Suresh Krishnan | [Ballot comment] Thanks for addressing my DISCUSS and COMMENTs. |
2016-10-05
|
15 | Suresh Krishnan | [Ballot Position Update] Position for Suresh Krishnan has been changed to Yes from Discuss |
2016-10-03
|
15 | Spencer Dawkins | [Ballot comment] Thanks for addressing my Discuss and comments. For what it's worth, I also like the changes you made to address other feedback, too. |
2016-10-03
|
15 | Spencer Dawkins | [Ballot Position Update] Position for Spencer Dawkins has been changed to Yes from Discuss |
2016-10-03
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-10-03
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2016-10-03
|
15 | Thomas Fossati | New version available: draft-ietf-core-http-mapping-15.txt |
2016-10-03
|
15 | (System) | New version approved |
2016-10-03
|
15 | (System) | Request for posting confirmation emailed to previous authors: core-chairs@ietf.org, "Thomas Fossati" , "Salvatore Loreto" , "Esko Dijk" , "Akbar Rahman" , "Angelo Castellani" |
2016-10-03
|
15 | Thomas Fossati | Uploaded new revision |
2016-09-28
|
14 | Alexey Melnikov | Telechat date has been changed to 2016-10-13 from 2016-09-29 |
2016-09-28
|
14 | Alexey Melnikov | IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for Writeup::AD Followup |
2016-09-27
|
14 | Suresh Krishnan | [Ballot discuss] Thanks for this well written draft. I do have a concern about some missing behavior. When an IPv6 literal is used the percent … [Ballot discuss] Thanks for this well written draft. I do have a concern about some missing behavior. When an IPv6 literal is used the percent encoded square brackets need to be reverted to their non-percent-encoded form on the HTTP server in order to be compliant with RFC7252 that uses IP-literal from RFC3986 for the host component. This is not specified anywhere in the document. |
2016-09-27
|
14 | Suresh Krishnan | [Ballot comment] Just thinking out loud here (Maybe I am being paranoid). There does not seem to be any kind of limitations on the IPv6 … [Ballot comment] Just thinking out loud here (Maybe I am being paranoid). There does not seem to be any kind of limitations on the IPv6 address part of the coap URI. What stops someone from sticking in a multicast address into the coap URI (such as the FF0X::FD All CoAP Nodes address) to use the proxy as DoS attack amplifier? |
2016-09-27
|
14 | Suresh Krishnan | [Ballot Position Update] New position, Discuss, has been recorded for Suresh Krishnan |
2016-09-27
|
14 | Spencer Dawkins | [Ballot discuss] This is going to be a Yes position after we talk, of course ... Someone can tell me to relax, but I found … [Ballot discuss] This is going to be a Yes position after we talk, of course ... Someone can tell me to relax, but I found this text When found in a Hosting HTTP URI, the scheme (i.e., "coap" or "coaps"), the scheme component delimiter (":"), and the double slash ("//") preceding the authority MAY be omitted. In such case, a local default - not defined by this document - applies. So, http://p.example.com/hc/s.coap.example.com/foo could either represent the target coap://s.coap.example.com/foo or coaps://s.coap.example.com/foo depending on application specific presets. worrisome - is it saying that if you leave off the scheme, you don't know whether the resulting mapped URI is coap:// or coaps://? If so, how critical is it that this isn't deterministic? Can the HTTP client tell whether the result used coaps://? |
2016-09-27
|
14 | Spencer Dawkins | [Ballot comment] In this text from the Abstract, This document covers the Reverse, Forward and Interception cross-protocol proxy cases. are Reverse, … [Ballot comment] In this text from the Abstract, This document covers the Reverse, Forward and Interception cross-protocol proxy cases. are Reverse, Forward, and Interception proxys so well understood that the average reader would know what you're talking about? Do I understand that they're defined directly in this document, not referencing some other draft? Further in the document, I see this text, Note that the guidelines apply to all forms of an HC proxy (i.e., Reverse, Forward, Intercepting) unless explicitly otherwise noted. which makes me wonder if you need to mention the various forms of HC proxy in the Abstract at all ... This text, Note that a Reverse Proxy appears to an HTTP client as an origin server while a Forward Proxy does not. So, when communicating with a Reverse Proxy a client may be unaware it is communicating with a proxy at all. would be clearer if it followed the definition of Reverse Proxy. In the current document, Reverse Proxy is defined, then Interception Proxy is defined, and then this note refers back to the Reverse Proxy definition. Confusingly, aren't clients unaware they're communicating with an Interception Proxy, as well? It's easy for me to read this text, See Figure 1 for an example deployment scenario. Here a HC proxy is located at the boundary of the Constrained Network domain, to avoid sending any HTTP traffic into the Constrained Network and to avoid any (unsecured) CoAP multicast traffic outside the Constrained Network. as saying that secured CoAP multicast traffic might be sent outside the Constrained Network. Is that what you meant? In this text, The HC proxy is furthermore configured to only pass through GET requests in order to protect the constrained network. did you mean "GET requests and their corresponding responses"? In this text, The default URI mapping function SHOULD be implemented and activated by default in a HC proxy, unless there are valid reasons, e.g., application specific, to use a different mapping function. I found myself wondering if you could point to a valid use of a different mapping function. That would have been helpful to me. In this text, However, it should be noted that in certain cases, transcoding can lose information in a non-obvious manner. For example, encoding an XML document using schema-informed EXI encoding leads to a loss of information when the destination does not know the exact schema version used by the encoder, which means that whenever the HC proxy transcodes an application/XML to application/EXI in-band metadata could be lost. Therefore, the implementer should always carefully verify such lossy payload transformations before triggering the transcoding. I didn't understand how you "verify" payload transformations. Is that a well-understood term of art for the community? |
2016-09-27
|
14 | Spencer Dawkins | [Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins |
2016-09-27
|
14 | Kathleen Moriarty | [Ballot comment] 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 … [Ballot comment] 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. |
2016-09-27
|
14 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss |
2016-09-27
|
14 | Stephen Farrell | [Ballot discuss] I don't get why you don't at least RECOMMEND that HTTP requests need to be authenticated? And I don't get why you don't … [Ballot discuss] I don't get why you don't at least RECOMMEND that HTTP requests need to be authenticated? And I don't get why you don't REQUIRE HC implementations support some form(s) of strong-ish user authentication. We are seeing fairly major botnets being built from the kinds of device that might use CoAP and (with careless implementations all around) this could provide a nice way to expose those to the Internet. Isn't a good bit more caution needed in what we describe here? Note: I'm not saying HTTP authentication, nor specifically TLS client auth. |
2016-09-27
|
14 | Stephen Farrell | [Ballot comment] Generally, I'd have been happier if this document went more towards reducing the attack surface and seemed less keen on being more flexible. … [Ballot comment] 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." ? |
2016-09-27
|
14 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2016-09-27
|
14 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2016-09-26
|
14 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2016-09-26
|
14 | Francis Dupont | Request for Telechat review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2016-09-26
|
14 | Kathleen Moriarty | [Ballot discuss] This is one discuss point with 2 questions. The second part is what's discussable and the first should be easy to fix either … [Ballot discuss] This is one discuss point with 2 questions. The second part is what's discussable and the first should be easy to fix either with the text provided or something similar. 1. In Section 10.1, this is more of a security than a privacy consideration as this is "network reconnaissance". This is a typical pre-cursor to an attack one the the attacker has gathered more information on the network. From a privacy perspective, they can be used to gather detailed information about the resources hosted in the constrained network. How about: This can be used to gather detailed information about the resources hosted in the constrained network, as siting with network reconnaissance. then for the last sentence: If privacy is a concern, for example whenever the HTTP request transits through the public Internet, the request SHOULD be transported over a mutually authenticated and encrypted TLS connection. How about: If confidentiality of the network is a concern, for example whenever the HTTP request transits through the public Internet, the request SHOULD be transported over a mutually authenticated and encrypted TLS connection. The word privacy here is confusing, so it's better to state exactly the issue. More importantly, if you can do network reconnaissance, what's to stop the attacker from using this new method of connecting? Some mention of this threat should be explicitly stated, maybe section 10.1 is the best place to do that, expanding on the existing text with another sentence. 2. (Really part of #1, but a separate point) Could transforms of URIs result in successful attacks? I would think that would be the highest security consideration. Although RFC7230 includes similar considerations, the mapping aspect of this draft could open up new attack possibilities, especially if a media type mapping is used. If there is an attack possible in the IoT space that is not in the HTTP world (device specific, or related to size constraints and coding), an intrusion prevention system monitoring the HTTP traffic before it is transformed would not pick it up and the attack traffic would evade detection. I think this merits mention and some text in the draft. Please let me know if it is elsewhere and another pointer is all that is needed. Thank you. |
2016-09-26
|
14 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
2016-09-24
|
14 | Alexey Melnikov | [Ballot comment] Larry Masinter promised Apps-Dir review, but he hasn't done it yet. |
2016-09-24
|
14 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-09-22
|
14 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2016-09-22
|
14 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2016-09-19
|
14 | Mirja Kühlewind | [Ballot comment] Well written doc! Thanks! |
2016-09-19
|
14 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2016-09-18
|
14 | Alexey Melnikov | AD review comments were addressed (or at least replied to). |
2016-09-12
|
14 | Alexey Melnikov | Ballot writeup was changed |
2016-09-09
|
14 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2016-09-08
|
14 | Alexey Melnikov | Ballot has been issued |
2016-09-08
|
14 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2016-09-08
|
14 | Alexey Melnikov | Created "Approve" ballot |
2016-09-08
|
14 | Alexey Melnikov | Ballot writeup was changed |
2016-09-08
|
14 | Alexey Melnikov | Placed on agenda for telechat - 2016-09-29 |
2016-09-08
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-09-08
|
14 | Thomas Fossati | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2016-09-08
|
14 | Thomas Fossati | New version available: draft-ietf-core-http-mapping-14.txt |
2016-09-01
|
13 | Alexey Melnikov | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2016-09-01
|
13 | Alexey Melnikov | In Section 4: I think you should add an informative reference to HTML5. In 5.4.1.1, example 3: Would it be better to define a separate … In Section 4: I think you should add an informative reference to HTML5. In 5.4.1.1, example 3: Would it be better to define a separate variable (in addition to "tu") which doesn't include the scheme? I don't see how your current example 3 is valid as written, because your ABNF in 5.4.1 says that the scheme URI part is always included. In 6.3: is the table fixed or can implementations do variations of it? Excuse my ignorance, but does does "htc" attribute need registering with IANA? In 9.2: "encoding consideration" should say "binary", because if the specific content format is not known, we can't say anything more specific than "binary". "Provisional Registration" - should be "no". In 10.3, last para: is this actually a good idea? What about opportunistic security and desire to prevent pervasive monitoring? You are using Obsolete RFC 2616 reference. Please point to one or more latest HTTP/1.1 RFC. Reported by ID-nits: RFC 2119 keyword use template doesn't match expected text. Should the document cover HTTP PATCH? |
2016-08-31
|
13 | Francis Dupont | Request for Last Call review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2016-08-22
|
13 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2016-08-16
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Menachem Dodge |
2016-08-16
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Menachem Dodge |
2016-08-16
|
13 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2016-08-16
|
13 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-core-http-mapping-13.txt. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-core-http-mapping-13.txt. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there are two actions which IANA must complete. First, in the Resource Type (rt=) Link Target Attribute Values subregistry of the Constrained RESTful Environments (CoRE) Parameters registry located at: https://www.iana.org/assignments/core-parameters/ a single attribute value is to be registered as follows: Value: core.hc Description: HTTP to CoAP mapping base resource Reference: [ RFC-to-be, Section 5.5 ] Notes: [ none ] Second, in the application media types subregistry of the Media Types registry located at: https://www.iana.org/assignments/media-types/ a new application media type is to be registered as follows: Name: coap-payload Template: [ TBD-at-registration ] Reference: [ RFC-to-be ] IANA understands that the two actions above are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Specialist ICANN |
2016-08-11
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2016-08-11
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2016-08-11
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dacheng Zhang |
2016-08-11
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dacheng Zhang |
2016-08-08
|
13 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2016-08-08
|
13 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-http-mapping@ietf.org, core@ietf.org, alexey.melnikov@isode.com, "Jaime … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-http-mapping@ietf.org, core@ietf.org, alexey.melnikov@isode.com, "Jaime Jimenez" Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Guidelines for HTTP-to-CoAP Mapping Implementations) to Informational RFC The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Guidelines for HTTP-to-CoAP Mapping Implementations' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ballot/ No IPR declarations have been submitted directly on this I-D. |
2016-08-08
|
13 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2016-08-08
|
13 | Amy Vezza | Last call announcement was changed |
2016-08-07
|
13 | Alexey Melnikov | Last call was requested |
2016-08-07
|
13 | Alexey Melnikov | Last call announcement was generated |
2016-08-07
|
13 | Alexey Melnikov | Ballot approval text was generated |
2016-08-07
|
13 | Alexey Melnikov | Ballot writeup was generated |
2016-08-07
|
13 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation |
2016-08-07
|
13 | Alexey Melnikov | IESG state changed to AD Evaluation from Publication Requested |
2016-07-22
|
13 | Alexey Melnikov | Changed consensus to Yes from Unknown |
2016-07-22
|
13 | Jaime Jimenez | Proper formatting and latest version: http://jaimejim.github.io/temp/draft-ietf-core-http-mapping#shepherd-writeup ###Summary Document Shepherd: [Jaime Jiménez](jaime.jimenez@ericsson.com) Area Director: [Alexey Melnikov](aamelnikov@fastmail.fm) This document provides reference information for … Proper formatting and latest version: http://jaimejim.github.io/temp/draft-ietf-core-http-mapping#shepherd-writeup ###Summary Document Shepherd: [Jaime Jiménez](jaime.jimenez@ericsson.com) Area Director: [Alexey Melnikov](aamelnikov@fastmail.fm) This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. The document is intended as an Informational RFC. ###Review and Consensus The document has gone through multiple expert reviews over the years and was last presented on IETF95. There are several implementations available: 1. Squid HTTP-CoAP mapping module, Angelo Castellani. 2. HTTP-CoAP proxy based on EvCoAP, Thomas Fossati, and Salvatore Loreto. 3. FIWARE (Ericsson) implementation. 4. Oliver Kleine implementation, available here: 5. Californium uses the default URI Mapping (section 5.3): ###Intellectual Property Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG. ###Other Points Appendix-A should be removed before publication. On the IANA section, the part that describes `Interoperability considerations: Published specification: (this I-D - TBD)` should be updated with the `RFCXXXX` reference. Few changes since the shepherds review, see: The working group has very good consensus on this document as it is. HTTP mapping aspects raised by future CoAP extensions will then be addressed by these extensions or in separate documents. ###Checklist * [x] Does the shepherd stand behind the document and think the document is ready for publication? * [x] Is the correct RFC type indicated in the title page header? * [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary? * [x] Is the intent of the document accurately and adequately explained in the introduction? * [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed? ``` Yes, some edits have been done, see https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-core-http-mapping-10.txt&url2=https://tools.ietf.org/id/draft-ietf-core-http-mapping-13.txt ``` * [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? ``` No errors, but some warnings are shown about existing ABNF. I aggregated all CoAP ABNF refs here: http://jaimejim.github.io/temp/coap-abnf ``` * [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79? * [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified? * [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state? ``` Clear state, but non-Standard reference [I-D.ietf-core-block] ``` * [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? ```Does not apply``` * [x] If this is a "bis" document, have all of the errata been considered? ```Does not apply``` * IANA Considerations: * [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions. * [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries? * [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)? * [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries? * [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call? * [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives? ```No registries are created. ``` * [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified? ```No registries are created.``` |
2016-07-22
|
13 | Jaime Jimenez | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2016-07-22
|
13 | Jaime Jimenez | IESG state changed to Publication Requested from AD is watching |
2016-07-22
|
13 | Jaime Jimenez | Proper formatting and latest version: http://jaimejim.github.io/temp/draft-ietf-core-http-mapping#shepherd-writeup ###Summary Document Shepherd: [Jaime Jiménez](jaime.jimenez@ericsson.com) Area Director: [Alexey Melnikov](aamelnikov@fastmail.fm) This document provides reference information for … Proper formatting and latest version: http://jaimejim.github.io/temp/draft-ietf-core-http-mapping#shepherd-writeup ###Summary Document Shepherd: [Jaime Jiménez](jaime.jimenez@ericsson.com) Area Director: [Alexey Melnikov](aamelnikov@fastmail.fm) This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. The document is intended as an Informational RFC. ###Review and Consensus The document has gone through multiple expert reviews over the years and was last presented on IETF95. There are several implementations available: 1. Squid HTTP-CoAP mapping module, Angelo Castellani. 2. HTTP-CoAP proxy based on EvCoAP, Thomas Fossati, and Salvatore Loreto. 3. FIWARE (Ericsson) implementation. 4. Oliver Kleine implementation, available here: 5. Californium uses the default URI Mapping (section 5.3): ###Intellectual Property Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG. ###Other Points Appendix-A should be removed before publication. On the IANA section, the part that describes `Interoperability considerations: Published specification: (this I-D - TBD)` should be updated with the `RFCXXXX` reference. Few changes since the shepherds review, see: The working group has very good consensus on this document as it is. HTTP mapping aspects raised by future CoAP extensions will then be addressed by these extensions or in separate documents. ###Checklist * [x] Does the shepherd stand behind the document and think the document is ready for publication? * [x] Is the correct RFC type indicated in the title page header? * [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary? * [x] Is the intent of the document accurately and adequately explained in the introduction? * [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed? ``` Yes, some edits have been done, see https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-core-http-mapping-10.txt&url2=https://tools.ietf.org/id/draft-ietf-core-http-mapping-13.txt ``` * [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? ``` No errors, but some warnings are shown about existing ABNF. I aggregated all CoAP ABNF refs here: http://jaimejim.github.io/temp/coap-abnf ``` * [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79? * [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified? * [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state? ``` Clear state, but non-Standard reference [I-D.ietf-core-block] ``` * [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? ```Does not apply``` * [x] If this is a "bis" document, have all of the errata been considered? ```Does not apply``` * IANA Considerations: * [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions. * [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries? * [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)? * [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries? * [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call? * [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives? ```No registries are created. ``` * [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified? ```No registries are created.``` |
2016-07-20
|
13 | Thomas Fossati | New version available: draft-ietf-core-http-mapping-13.txt |
2016-07-11
|
12 | Jaime Jimenez | Proper formatting and latest version: http://jaimejim.github.io/temp/draft-ietf-core-http-mapping#shepherd-writeup Shepherd Writeup Summary Document Shepherd: Jaime Jiménez Area Director: Alexey Melnikov This document provides reference information for implementing a … Proper formatting and latest version: http://jaimejim.github.io/temp/draft-ietf-core-http-mapping#shepherd-writeup Shepherd Writeup Summary Document Shepherd: Jaime Jiménez Area Director: Alexey Melnikov This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. The document is intended as an Informational RFC. Review and Consensus The document has gone through multiple expert reviews over the years and was last presented on IETF95. It is noteworthy that the document focuses on the reverse HTTP-CoAP proxy case, the forward proxy case was well specified in RFC7252. There are several implementations available: Squid HTTP-CoAP mapping module, Angelo Castellani. http://telecom.dei.unipd.it/iot HTTP-CoAP proxy based on EvCoAP, Thomas Fossati, and Salvatore Loreto. https://github.com/koanlogic/webthings/tree/master/bridge/sw/lib/evcoap FIWARE (Ericsson) implementation. https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Gateway_Device_Management_-_Ericsson_Gateway_-_User_and_Programmers_Guide#HTTP-CoAP_mapping Oliver Kleine implementation, https://media.itm.uni-luebeck.de/people/kleine/poster_kleine_ssp.pdf available here: http://core.ietf.narkive.com/d4MCPLLl/http-coap-proxy-setup Intellectual Property Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG. Other Points Appendix-A should be removed before publication. https://tools.ietf.org/html/draft-ietf-core-http-mapping-12#appendix-A On the IANA section, the part that describes Interoperability considerations: Published specification: (this I-D - TBD) should be updated with the RFCXXXX reference. The working group has very good consensus on this document as it is. HTTP mapping aspects raised by future CoAP extensions will then be addressed by these extensions or in separate documents. Checklist Does the shepherd stand behind the document and think the document is ready for publication? Is the correct RFC type indicated in the title page header? Is the abstract both brief and sufficient, and does it stand alone as a brief summary? Is the intent of the document accurately and adequately explained in the introduction? Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed? in progress, asked authors. Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? No errors, but some warnings are shown about existing ABNF. I aggregated all CoAP ABNF refs here: http://jaimejim.github.io/temp/coap-abnf Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79? Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified? Are all normative references made to documents that are ready for advancement and are otherwise in a clear state? Clear state, but non-Standard reference [I-D.ietf-core-block] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? Does not apply If this is a bis document, have all of the errata been considered? Does not apply IANA Considerations: Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions. Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries? Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)? Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries? in progress For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call? Not that I know of. For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives? Not that I know of. Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified? Does not apply |
2016-07-11
|
12 | Jaime Jimenez | http://jaimejim.github.io/temp/draft-ietf-core-http-mapping#shepherd-writeup Shepherd Writeup Summary Document Shepherd: Jaime Jiménez Area Director: Alexey Melnikov This document provides reference information for implementing a cross-protocol network proxy that performs … http://jaimejim.github.io/temp/draft-ietf-core-http-mapping#shepherd-writeup Shepherd Writeup Summary Document Shepherd: Jaime Jiménez Area Director: Alexey Melnikov This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the CoAP protocol. This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. This document covers the Reverse, Forward and Interception cross-protocol proxy cases. The document is intended as an Informational RFC. Review and Consensus The document has gone through multiple expert reviews over the years and was last presented on IETF95. It is noteworthy that the document focuses on the reverse HTTP-CoAP proxy case, the forward proxy case was well specified in RFC7252. There are several implementations available: Squid HTTP-CoAP mapping module, Angelo Castellani. http://telecom.dei.unipd.it/iot HTTP-CoAP proxy based on EvCoAP, Thomas Fossati, and Salvatore Loreto. https://github.com/koanlogic/webthings/tree/master/bridge/sw/lib/evcoap FIWARE (Ericsson) implementation. https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Gateway_Device_Management_-_Ericsson_Gateway_-_User_and_Programmers_Guide#HTTP-CoAP_mapping Oliver Kleine implementation, https://media.itm.uni-luebeck.de/people/kleine/poster_kleine_ssp.pdf available here: http://core.ietf.narkive.com/d4MCPLLl/http-coap-proxy-setup Intellectual Property Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG. Other Points Appendix-A should be removed before publication. https://tools.ietf.org/html/draft-ietf-core-http-mapping-12#appendix-A On the IANA section, the part that describes Interoperability considerations: Published specification: (this I-D - TBD) should be updated with the RFCXXXX reference. The working group has very good consensus on this document as it is. HTTP mapping aspects raised by future CoAP extensions will then be addressed by these extensions or in separate documents. Checklist Does the shepherd stand behind the document and think the document is ready for publication? Is the correct RFC type indicated in the title page header? Is the abstract both brief and sufficient, and does it stand alone as a brief summary? Is the intent of the document accurately and adequately explained in the introduction? Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed? in progress, asked authors. Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? No errors, but some warnings are shown about existing ABNF. I aggregated all CoAP ABNF refs here: http://jaimejim.github.io/temp/coap-abnf Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79? Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified? Are all normative references made to documents that are ready for advancement and are otherwise in a clear state? Clear state, but non-Standard reference [I-D.ietf-core-block] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? Does not apply If this is a bis document, have all of the errata been considered? Does not apply IANA Considerations: Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions. Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries? Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)? Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries? in progress For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call? Not that I know of. For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives? Not that I know of. Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified? Does not apply |
2016-07-11
|
12 | Jaime Jimenez | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2016-07-07
|
12 | Jaime Jimenez | Notification list changed to "Jaime Jimenez" <jaime.jimenez@ericsson.com> |
2016-07-07
|
12 | Jaime Jimenez | Document shepherd changed to Jaime Jimenez |
2016-07-01
|
12 | Thomas Fossati | New version available: draft-ietf-core-http-mapping-12.txt |
2016-06-22
|
11 | Thomas Fossati | New version available: draft-ietf-core-http-mapping-11.txt |
2016-05-13
|
10 | Akbar Rahman | New version available: draft-ietf-core-http-mapping-10.txt |
2016-04-23
|
09 | Alexey Melnikov | Intended Status changed to Informational |
2016-04-23
|
09 | Alexey Melnikov | IESG process started in state AD is watching |
2016-04-23
|
09 | (System) | Earlier history may be found in the Comment Log for /doc/draft-castellani-core-http-mapping/ |
2016-04-06
|
09 | Akbar Rahman | New version available: draft-ietf-core-http-mapping-09.txt |
2016-04-04
|
08 | Carsten Bormann | Added to session: IETF-95: core Fri-1000 |
2016-03-18
|
08 | Akbar Rahman | New version available: draft-ietf-core-http-mapping-08.txt |
2015-09-15
|
07 | Carsten Bormann | IETF WG state changed to In WG Last Call from WG Document |
2015-07-03
|
07 | Esko Dijk | New version available: draft-ietf-core-http-mapping-07.txt |
2015-03-09
|
06 | Esko Dijk | New version available: draft-ietf-core-http-mapping-06.txt |
2014-10-23
|
05 | Akbar Rahman | New version available: draft-ietf-core-http-mapping-05.txt |
2014-07-04
|
04 | Thomas Fossati | New version available: draft-ietf-core-http-mapping-04.txt |
2014-02-12
|
03 | Thomas Fossati | New version available: draft-ietf-core-http-mapping-03.txt |
2013-11-06
|
02 | Carsten Bormann | Set of documents this document replaces changed to draft-castellani-core-http-mapping from None |
2013-10-12
|
02 | Esko Dijk | New version available: draft-ietf-core-http-mapping-02.txt |
2013-07-03
|
01 | Akbar Rahman | New version available: draft-ietf-core-http-mapping-01.txt |
2013-06-03
|
00 | Akbar Rahman | New version available: draft-ietf-core-http-mapping-00.txt |