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

(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

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

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.

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.

[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

[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?

[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.

[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.

[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.

[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.

[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?

[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://?

[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?

[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.

[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.

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

[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.

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?

(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

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.

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.```

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.```

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

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