Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07

["Rahman, Akbar" <[e-mail]>]

Hi Klaus,


Thank you for your thorough review and apologies for the long delay in answering your comments.   None of the authors were able to make it to last November's IETF meeting where we had wanted to speak to you directly to resolve some of the issues.  This resulted in an overall delay to the entire process.  However, we were recently able to coordinate a point by point response to comments.  Please review and tell if us you agree with the responses.  Once we have closed all the comments with you we will do an update of the draft before the IETF-95 cut-off date.


Best Regards,

Akbar (on behalf of all the authors)

-----------------------------------------------------------------
KH Comment #1:
=============
Here's my review of draft-ietf-core-http-mapping-07:
Overall -- the document is 'Informational', but it makes a lot of use of requirement keywords (SHOULD, MUST, etc.). Do these keywords indicate conformance requirements? What happens if a proxy implementation ignores any of the requirements? Where do interoperability problems occur in this case? Please review all occurrences of a requirement keywords in the document and verify that is really necessary for interoperability. Explain what happens when a proxy implementation fails to implement a requirement keyword. IMHO the only requirement is really that the proxy MUST keep up the illusion that it is an HTTP origin server; everything else seems to be OPTIONAL to me.

Authors? Response #1:
==================
- Okay.  We will change any requirements language taken from other RFCs to lower case (and this will remove quite a few requirements).
- We will go through and see if remaining requirements language should be optional or mandatory.
- We propose to leave the document as Informational as there is good precedence for this.  For example, a random search of Informational RFCs in the IETF stream shows that many Informational RFCs use RFC2119 language.


-----------------------------------------------------------------
KH Comment #2:
=============
1. "is to reduce variation between proxy implementations, thereby increasing interoperability" -- where do these interoperability problems occur? A HTTP-CoAP cross-protocol reverse proxy appears as an origin server to the HTTP client, so for the HTTP client any such proxy looks the same.

Authors? Response #2:
==================
Not if proxy ?A? does something with a given HTTP request and proxy ?B? does something else.  What we are talking here is interoperability between a CoAP endpoint and an HTTP endpoint independently of the HC proxy that implements the protocol mappings.  For example, the mapping of CoAP Response codes to HTTP Status codes to be done by the HC proxy can be subject to different interpretations unless some guidelines are given as in Table 2.  We will clarify this in the draft.


-----------------------------------------------------------------
KH Comment #3:
=============
5. "base URI" -- the term "base URI" has a well-defined meaning in the context of URI reference resolution (RFC 3986, Section 5). You're using it here for something else, which is confusing. Please use a different term.

Authors? Response #3:
==================
The term ?base (or context) URI? for the subject of the ?hosts? link relationship of with resource type ?core.hc? is correct.  However, we will review all the uses of ?base URI? in the draft because there might be inconsistencies.  We will clarify this in the draft.


-----------------------------------------------------------------
KH Comment #4:
=============
5.2 "The default URI mapping function is RECOMMENDED to be implemented" -- why? What happens when this requirement is ignored?

Authors? Response #4:
=================
Okay.  This is a key point that requires clarification in the current draft.  We will clarify that the whole section 5 is only for the special (optional) case where a CoAP URI is embedded within the HTTP URI by the HTTP client.  The other case is when only a ?pure? HTTP URI is sent by the HTTP client to the HC proxy, and the HC proxy itself generates the CoAP URI.  In this second case the whole section 5 is not required.

Specifically, the case where the HTTP client embeds the CoAP URI info into the HTTP URI as we describe in Section 5 will map implicitly to our 1st use case in section 4.  On the other hand, our 2nd use case in section 4 implies that the legacy application probably does not embed the CoAP URI info into the HTTP URI as it is legacy and was written without CoAP support.  So in this case, section 5 does not imply but sections 6 and 7 do apply.  We definitely need to clarify these different possible scenarios of "pure reverse proxy" vs the other case of embedded CoAP URI info in the HTTP request.


Please remember that the request for this type of feature was brought up in the WG a long time ago ...

       "Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies?"

       http://trac.tools.ietf.org/wg/core/trac/ticket/259


-----------------------------------------------------------------
KH Comment #5:
=============
5.3 -- I don't understand this section. What is this? Why do we need this? How is this different from the default mapping in Section 5.2?
Who uses these templates, the client or the proxy?

Authors? Response #5:
==================
Okay, we will explicitly state in the section that it applies to the client.

Please see London f2f discussion for the background on this at http://tools.ietf.org/wg/core/minutes?item=minutes-89-core.html (?Zach: on 'hct' link parameter - could be more widely usable concept. URI templates are more general, so perhaps not define just for this I-D context? Could be in a separate draft, or in a separate section that can be easily referenced from other docs.?)   We did the latter, adding a separate section for it.


-----------------------------------------------------------------
KH Comment #6:
==============
5.3 -- Section 5.2 defines a default mapping, 5.3.1 seems to define three additional mappings, 5.3.2 seems to define yet another mapping.
Section 1 says that one goal of the spec "is to reduce variation between proxy implementations, thereby increasing interoperability".
How does this multitude of mappings reduce variability?

Authors? Response #6:
==================
Same as Response #5 (and in particular please go back to Zach's comment from the London f2f meeting).


-----------------------------------------------------------------
KH Comment #7:
==============
5.4 -- "to discover the proxy function, the HC proxy SHOULD publish information related to the location and syntax of the HC proxy function" -- the proxy is a reverse proxy. It appears as an origin server to any client. Why does the proxy function need to be discovered? Who are the "third parties"?

Authors? Response #7:
==================
As per our Response #4, we will clarify that the whole section 5 is only for the special (optional) case where the HTTP client wishes to embed CoAP URI information into the overall HTTP URI.  If this is not the case, then no discovery needs to happen and the whole section 5 is not necessary.



-----------------------------------------------------------------
KH Comment #8:
=============
5.4.1 -- Section 5.4 is about discovering the proxy function, 5.4.1 is about discovering resources, 5.4.2 is about discovering the proxy function again. This is confusing.

Authors? Response #8:
==================
Okay, you are right.  We put 5.4.2 in the document quite recently to hint that a co-located RD could provide resource discovery.  Probably, it doesn't really add much value.  If it also potentially generates confusion, so we will remove section 5.4.2


-----------------------------------------------------------------
KH Comment #9:
=============
5.4.2 "The first example exercises the CoAP interface" -- why does a CoAP client need to discover a HTTP-CoAP proxy?

Authors? Response #9:
=================
The idea here is to support use case 1, i.e. ?Smartphone and home sensor?: the smartphone discovers the public HC proxy before leaving the homenet and then uses it from outside to query the homenet-attached sensors.  We will clarify this in the draft.


-----------------------------------------------------------------
KH Comment #10:
==============
6.5.2. -- to keep the illusion up that the proxy is an origin server, the proxy MUST rewrite _all_ URIs in _all_ representation formats, not just Link Formats. This includes _all_ URIs generated on-the-fly by JavaScript code! Unless the proxy has a very deep understanding of the application, this is generally not possible. But a reverse proxy with a very deep understanding of the application is unlikely to use any of the URI mapping schemes defined in the document. So basically the whole Section 5 is useless.

Authors? Response #10:
===================
The recommendation in this section is to not fiddle with the payloads which is a very sensible thing to do unless this is an application specific HC proxy.  Also the ?MUST rewrite? argument is not correct: reverse proxies typically do nothing with the response bodies, it?s just not their territory.


-----------------------------------------------------------------
KH Comment #11:
==============
6.5.3. "the CoAP diagnostic payload must be used as the HTTP reason-phrase of the HTTP status line" -- a diagnostic payload is similar to the HTTP reason phrase, but it can be much more verbose and, e.g., can include CR-LF line breaks. It's probably best to stick the diagnostic payload into the payload and use the default reason phrase for the status code.

Authors? Response #11:
===================
Okay.  This is a good observation: reason-phrase?s must not include CR-LF. If diagnostic payloads do, the 1:1 mapping is not possible.  We will clarify this in the draft.


-----------------------------------------------------------------
KH Comment #12:
===============
7. "4.02 Bad Option | 400 Bad Request" -- can the HTTP client make a change to its request so that the proxy does not include the bad option in its CoAP request? If not, the bad option is the proxy's fault (5xx status code) and not the HTTP client's fault (4xx status code).

Authors? Response #12:
===================
Okay.  This is a good observation as well.  If the proxy has a way to determine that the bad option is due to the straightforward mapping of a client request header into a CoAP option, then the 400 is appropriate.  Otherwise we should probably return a 500, because the error is proxy?s ?fault? not being able to translate the request appropriately.  We will clarify this in the draft.


-----------------------------------------------------------------
KH Comment #13:
===============
7. "The proxy receiving 2.03 updates the freshness of its cached representation and returns the entire representation to the HTTP client." -- If the proxy receives a response indicating that the etag supplied by the HTTP client is valid, why does the proxy need to send the representation to the client?

Authors? Response #13:
===================
To clarify, the situation we are describing here is:
-        HTTP client makes an unconditional request for resource R;
-        HC proxy finds R in its cache but R is out of its ?freshness lifetime? as dictated by its max-age;
-        HC proxy thus makes a conditional request to check the validity of the stored R;
-        CoAP server replies 2.03 confirming it?s still OK;
-        HC proxy sends the cached R to HTTP client.
It?d be completely different (and similar to what you say) if the HTTP client had made a conditional request.  We will clarify this in the draft.


-----------------------------------------------------------------
KH Comment #14:
==============
7. "If the HC proxy does not implement a proper authentication method that can be used to gain access to the target CoAP resource, it can include a 'dummy' challenge for example "WWW-Authenticate: None"." -- if the proxy cannot gain access to the CoAP resource, it should probably return a 403 (Forbidden) status code to the HTTP client.

Authors? Response #14:
===================
Ok.  Good point.  We will clarify this in the draft.


-----------------------------------------------------------------
KH Comment #15:
===============
7. "In this case the HC Proxy SHOULD also return a HTTP reason-phrase in the HTTP status line that starts with the string "405" in order to facilitate troubleshooting." -- this leads to a status line like
"HTTP/1.1 400 405 Method Not Allowed" which looks wrong and may confuse implementers.

Authors? Response #15:
===================
Ok.  Good point.  There is a typo in Note 7 of Section 7: ?HTTP 400 (Method Not Allowed)? should be ?HTTP 400 (Bad Request)?.  You are right, the status line is quite confusing.  We will change it to something like ?CoAP server returned 4.05? instead.  We will clarify this in the draft.


-----------------------------------------------------------------
KH Comment #16:
===============
7. "The value of the HTTP "Retry-After" response-header field is taken from the value of the CoAP Max-Age Option, if present." -- if the Max-Age Option is not present, it means that the Max-Age is 60 seconds, not that the representation doesn't have a Max-Age.

Authors? Response #16:
===================
This is just a straightforward mapping of Section 5.9.3.4. of RFC7252, which decided to overload Max-Age to convey Retry-After semantics.  Can you reword what you are concerned about?


-----------------------------------------------------------------
KH Comment #17:
===============
8.1 "An HC proxy SHOULD limit the number of requests to CoAP servers by responding, where applicable, with a cached representation of the resource." -- The proxy actually MUST perform congestion control as specified in RFC 7252. Caching is not about congestion control, it is about efficiency. So, as a matter of quality of implementation, it is a good idea for a proxy to implement caching. But responding with a cached representation of the resource is not a tool to enforce congestion control.

Authors? Response #17:
===================
Okay.  Good point.  We will clarify this in the draft.


-----------------------------------------------------------------
KH Comment #18:
==============
8.1 "Duplicate idempotent pending requests by an HC proxy to the same CoAP resource SHOULD in general be avoided, by using the same response for multiple requesting HTTP clients without duplicating the CoAP request." -- this is not how caching in CoAP works. Please read RFC 7252.

Authors? Response #18:
===================
RFC 7252, Section 5.6. says ?endpoints MAY cache responses?.  Here we are tightening up the requirement to a SHOULD for a specific class of CoAP endpoints (HC proxies).


-----------------------------------------------------------------
KH Comment #19:
===============
8.1 "According to [RFC7252], a proxy MUST limit the number of outstanding interactions to a given CoAP server to NSTART." -- this has already been specified in RFC 7252. There is no need to repeat that here.

Authors? Response #19:
===================
Okay.  We will change the ?MUST? to ?must? as per our Response #1.  We will clarify this in the draft.


-----------------------------------------------------------------
KH Comment #20:
===============
9.2 -- have you submitted the registration to the [e-mail] mailing list for review? It's probably a good idea to do this before sending the document to the IESG.

Authors? Response #20:
====================
Good point.  We will do so shortly.


-----------------------------------------------------------------
KH Comment #21:
===============
Are there any implementations of this document?

Authors? Response #21:
===================
Yes, there are various open source implementations that we are aware of (to various versions of this draft).


******************************************

That's all.  Thanks again for all your good comments.


/Akbar





-----Original Message-----
From: core [mailto:[e-mail]] On Behalf Of Klaus Hartke
Sent: Monday, September 28, 2015 10:09 AM
To: [e-mail] WG <[e-mail]>
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07

Here's my review of draft-ietf-core-http-mapping-07:

Overall -- the document is 'Informational', but it makes a lot of use of requirement keywords (SHOULD, MUST, etc.). Do these keywords indicate conformance requirements? What happens if a proxy implementation ignores any of the requirements? Where do interoperability problems occur in this case? Please review all occurrences of a requirement keywords in the document and verify that is really necessary for interoperability. Explain what happens when a proxy implementation fails to implement a requirement keyword. IMHO the only requirement is really that the proxy MUST keep up the illusion that it is an HTTP origin server; everything else seems to be OPTIONAL to me.

1. "is to reduce variation between proxy implementations, thereby increasing interoperability" -- where do these interoperability problems occur? A HTTP-CoAP cross-protocol reverse proxy appears as an origin server to the HTTP client, so for the HTTP client any such proxy looks the same.

5. "base URI" -- the term "base URI" has a well-defined meaning in the context of URI reference resolution (RFC 3986, Section 5). You're using it here for something else, which is confusing. Please use a different term.

5.2 "The default URI mapping function is RECOMMENDED to be implemented" -- why? What happens when this requirement is ignored?

5.3 -- I don't understand this section. What is this? Why do we need this? How is this different from the default mapping in Section 5.2?
Who uses these templates, the client or the proxy?

5.3 -- Section 5.2 defines a default mapping, 5.3.1 seems to define three additional mappings, 5.3.2 seems to define yet another mapping.
Section 1 says that one goal of the spec "is to reduce variation between proxy implementations, thereby increasing interoperability".
How does this multitude of mappings reduce variability?

5.4 -- "to discover the proxy function, the HC proxy SHOULD publish information related to the location and syntax of the HC proxy function" -- the proxy is a reverse proxy. It appears as an origin server to any client. Why does the proxy function need to be discovered? Who are the "third parties"?

5.4.1 -- Section 5.4 is about discovering the proxy function, 5.4.1 is about discovering resources, 5.4.2 is about discovering the proxy function again. This is confusing.

5.4.2 "The first example exercises the CoAP interface" -- why does a CoAP client need to discover a HTTP-CoAP proxy?

6.5.2. -- to keep the illusion up that the proxy is an origin server, the proxy MUST rewrite _all_ URIs in _all_ representation formats, not just Link Formats. This includes _all_ URIs generated on-the-fly by JavaScript code! Unless the proxy has a very deep understanding of the application, this is generally not possible. But a reverse proxy with a very deep understanding of the application is unlikely to use any of the URI mapping schemes defined in the document. So basically the whole Section 5 is useless.

6.5.3. "the CoAP diagnostic payload must be used as the HTTP reason-phrase of the HTTP status line" -- a diagnostic payload is similar to the HTTP reason phrase, but it can be much more verbose and, e.g., can include CR-LF line breaks. It's probably best to stick the diagnostic payload into the payload and use the default reason phrase for the status code.

7. "4.02 Bad Option | 400 Bad Request" -- can the HTTP client make a change to its request so that the proxy does not include the bad option in its CoAP request? If not, the bad option is the proxy's fault (5xx status code) and not the HTTP client's fault (4xx status code).

7. "The proxy receiving 2.03 updates the freshness of its cached representation and returns the entire representation to the HTTP client." -- If the proxy receives a response indicating that the etag supplied by the HTTP client is valid, why does the proxy need to send the representation to the client?

7. "If the HC proxy does not implement a proper authentication method that can be used to gain access to the target CoAP resource, it can include a 'dummy' challenge for example "WWW-Authenticate: None"." -- if the proxy cannot gain access to the CoAP resource, it should probably return a 403 (Forbidden) status code to the HTTP client.

7. "In this case the HC Proxy SHOULD also return a HTTP reason-phrase in the HTTP status line that starts with the string "405" in order to facilitate troubleshooting." -- this leads to a status line like
"HTTP/1.1 400 405 Method Not Allowed" which looks wrong and may confuse implementers.

7. "The value of the HTTP "Retry-After" response-header field is taken from the value of the CoAP Max-Age Option, if present." -- if the Max-Age Option is not present, it means that the Max-Age is 60 seconds, not that the representation doesn't have a Max-Age.

8.1 "An HC proxy SHOULD limit the number of requests to CoAP servers by responding, where applicable, with a cached representation of the resource." -- The proxy actually MUST perform congestion control as specified in RFC 7252. Caching is not about congestion control, it is about efficiency. So, as a matter of quality of implementation, it is a good idea for a proxy to implement caching. But responding with a cached representation of the resource is not a tool to enforce congestion control.

8.1 "Duplicate idempotent pending requests by an HC proxy to the same CoAP resource SHOULD in general be avoided, by using the same response for multiple requesting HTTP clients without duplicating the CoAP request." -- this is not how caching in CoAP works. Please read RFC 7252.

8.1 "According to [RFC7252], a proxy MUST limit the number of outstanding interactions to a given CoAP server to NSTART." -- this has already been specified in RFC 7252. There is no need to repeat that here.

9.2 -- have you submitted the registration to [e-mail] mailing list for review? It's probably a good idea to do this before sending the document to the IESG.

Are there any implementations of this document?

Klaus

_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core