PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)
draft-ietf-core-etch-04
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-03-31
|
04 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-03-20
|
04 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-03-08
|
04 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2017-02-13
|
04 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-02-13
|
04 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-02-10
|
04 | (System) | IANA Action state changed to Waiting on Authors |
2017-02-06
|
04 | (System) | RFC Editor state changed to EDIT |
2017-02-06
|
04 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-02-06
|
04 | (System) | Announcement was received by RFC Editor |
2017-02-06
|
04 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2017-02-06
|
04 | Amy Vezza | IESG has approved the document |
2017-02-06
|
04 | Amy Vezza | Closed "Approve" ballot |
2017-02-06
|
04 | Amy Vezza | Ballot approval text was generated |
2017-02-06
|
04 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2016-11-30
|
04 | Alexey Melnikov | [Ballot comment] Check if further changes in response to Kathleen's comment is needed. |
2016-11-30
|
04 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-11-30
|
04 | Alissa Cooper | [Ballot comment] Thank you for addressing my DISCUSS. OLD COMMENT: = Section 2 = "(However, while processing a search request, a server can be expected … [Ballot comment] Thank you for addressing my DISCUSS. OLD COMMENT: = Section 2 = "(However, while processing a search request, a server can be expected to allocate computing and memory resources or even create additional server resources through which the response to the search can be retrieved.)" s/search/fetch/ would be clearer I think = Section 3 = "If the Request-URI does not point to an existing resource, the server MAY create a new resource with that URI, depending on the patch document type (whether it can logically modify a null resource) and permissions, etc." I know this is the same text as in RFC 5789, but it's vague. What else might create the basis for the server's decision besides the document type and permissions? = Section 5 = It seems that FETCH does introduce a new security consideration, in that any observer of FETCH requests can potentially glean information about the specific portions of a resource of interest to the requester. This might factor into decisions about whether to use DTLS to secure a particular request so may be worth mentioning. |
2016-11-30
|
04 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2016-11-14
|
04 | Spencer Dawkins | [Ballot comment] Thanks for working with me (and Alexey) to resolve my Discuss, which was: I'm following most of your reasoning behind having the twin … [Ballot comment] Thanks for working with me (and Alexey) to resolve my Discuss, which was: I'm following most of your reasoning behind having the twin methods PATCH and iPATCH, but I'm struggling a bit that there's nothing that I saw that prevents a problem when the client implements only PATCH and the server implements only iPATCH. The only text I saw that provides guidance about which method to implement is A client can mark a request as idempotent by using the iPATCH method instead of the PATCH method. This is the only difference between the two. The indication of idempotence may enable the server to keep less state about the interaction; some constrained servers may only implement the iPATCH variant for this reason. Maybe I missed something? If not, I saw There is no guarantee that a resource can be modified with PATCH or iPATCH. so, maybe that mismatch isn't going to be a problem in practice, but it seems sad that you might have a patchable resource, that can't be patched because of that mismatch. I'm not asking for "clients MUST implement iPATCH if you implement PATCH" (which would accommodate servers that only implement iPATCH), but I wonder if the working group talked about a way to avoid this mismatch? (My previous comment was) I was a bit uneasy with the "nearly" in The security considerations for PATCH or iPATCH are nearly identical to the security considerations for PUT ([RFC7252]). with no explanation of any differences, but I'll leave that for the SEC ADs to pick up on if it matters. |
2016-11-14
|
04 | Spencer Dawkins | [Ballot Position Update] Position for Spencer Dawkins has been changed to No Objection from Discuss |
2016-11-13
|
04 | Kathleen Moriarty | [Ballot comment] Thanks for the added text. It doesn't exactly cover my discuss and the attack mentioned, but I'll clear as the text is improved … [Ballot comment] Thanks for the added text. It doesn't exactly cover my discuss and the attack mentioned, but I'll clear as the text is improved and gets closer to what I think is needed. If a patch is corrupted or maliciously altered, there is no way to detect this and it can happen when stored (no hash or signature validation is performed). This is not explicitly stated in the revised draft, although similar considerations are now included. |
2016-11-13
|
04 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss |
2016-11-13
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-11-13
|
04 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2016-11-13
|
04 | Carsten Bormann | New version available: draft-ietf-core-etch-04.txt |
2016-11-13
|
04 | (System) | New version approved |
2016-11-13
|
04 | (System) | Request for posting confirmation emailed to previous authors: "Peter Van der Stok" , "Carsten Bormann" , "Anuj Sehgal" , core-chairs@ietf.org |
2016-11-13
|
04 | Carsten Bormann | Uploaded new revision |
2016-10-13
|
03 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2016-10-13
|
03 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2016-10-13
|
03 | Benoît Claise | [Ballot comment] [reflections on core, as opposed to actionable items for the document] Coming back to Alissa's DISCUSS and Sheng Jiang's OPS DIR review: … [Ballot comment] [reflections on core, as opposed to actionable items for the document] Coming back to Alissa's DISCUSS and Sheng Jiang's OPS DIR review: This Standards Track document defines a new CoAP methods, FETCH, to perform the equivalent of a GET with a request body; and the twin methods PATCH and iPATCH, to modify parts of a CoAP resource. This document is well written. I don't see any major issues from the operations and management perspective. It is almost ready to be published. There are one of potential major (the word potential means I don’t really sure how serious it may be) comments from me: In section 2.5, it raises an issue that “a FETCH request cannot be generated from a link alone, but also needs a way to generate the request payload.” From the discussion text, I am not sure whether there are existing way to generate the request payload or not. And I am not sure whether the FECTCH method needs a standard such way to be able to work or not. If the answer for my first question is no, or the question for my second question is yes. Then we probably have an major issue here. I wish my suspecting is wrong. I would like to make sure I understand (with my OPS background,): - COAP (RFC7252) is about HTTP GET, POST, PUT, DELETE for constrained nodes and constrained environments - draft-ietf-core-etch specification specifies the new CoAP methods, FETCH, PATCH and iPATCH, which are used to access and update parts of a resource. - CBOR (RFC7049) is the binary encoding of JSON for COAP. And for draft-ietf-core-etch, I guess? - There are two data modeling language in CORE YANG: draft-ietf-core-yang-cbor-02 provides the mapping for YANG data models encoding: CBOR SenML: draft-ietf-core-senml-02 provides Media Types for Sensor Markup Language encodings: JSON, CBOR, XML, EXI Good so far? Coming to Alissa's DISCUSS: It seems that FETCH is not a useful operation unless the server is capable of understanding what it is supposed to fetch. So it's not true that "any" media type can be used, but rather only those media types for which a definition exists for what the fetch parameters indicate and which part of the resource they are intended to delineate. Shouldn't the use of FETCH be constrained to such media types? So what we're missing for this to work is the equivalent of RESTCONF for constrained nodes/networks - Either "CoAP Management Interface", draft-vanderstok-core-comi-09 (btw this draft expired...) - Or Constrained Objects Language, draft-veillette-core-cool-02 Note: COMI is mentioned in the draft, but not COOL Is this what is meant behind? it is outside the scope of this document how information about admissible media types is obtained by the client There is a clear parallel with RESTCONF (REST-like) and the CORE work: NETMOD/NETCONF CORE Data Modeling Language YANG YANG or SenML (*) Data Models YANG Module YANG Module or SenML (*) Encoding XML, JSON CBOR for YANG, JSON/CBOR/XML/EXI for SENML Protocol HTTP for RESTCONF COAP Mgmt Protocol RESTCONF/NETCONF COMI or COOL for YANG, for SenML?? (**) (*) not sure if SenML is a data modeling language or data models (**) not sure if a specific mgmt protocol for SenML Please let me know. Regards, Benoit |
2016-10-13
|
03 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2016-10-13
|
03 | Mirja Kühlewind | [Ballot comment] Does this doc update RFC7252? Maybe not; just asking... |
2016-10-13
|
03 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2016-10-12
|
03 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2016-10-12
|
03 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2016-10-12
|
03 | Ben Campbell | [Ballot comment] I share the concerns from Alissa's DISCUSS point and comment about section 5. |
2016-10-12
|
03 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2016-10-12
|
03 | Alexey Melnikov | [Ballot comment] I agree with Alissa and Spencer. |
2016-10-12
|
03 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-10-12
|
03 | Kathleen Moriarty | [Ballot discuss] I'd like to see more of the actual requirements for this draft in the security considerations as the pointers include all of the … [Ballot discuss] I'd like to see more of the actual requirements for this draft in the security considerations as the pointers include all of the configuration options for DTLS, including the "nosec" option. I would think this operation would require authentication to prevent unauthorized access by devices that are clones. This is a real problem in the non-IoT space for firmware updates and will be a problem in this space if it isn't already - knock off hardware that installs the firmware of a popular product. In In section 5 of RFC5789, I see this: These include authorizing requests (possibly through access control and/or authentication) and ensuring that data is not corrupted through transport errors or through accidental overwrites. And would like to see something similar in this section to at least list some of the requirements and reasoning. For patch and fetch, I think the reason outlined above needs to be included as well so it is top of mind for implementers and they are aware of this very real threat. It is important they understand why they need authentication and encryption to prevent attacks against their brand. If someone buys knock-off hardware that is faulty and uses their firmware, they have multiple problems to deal with, not just the loss of sales. |
2016-10-12
|
03 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
2016-10-12
|
03 | Spencer Dawkins | [Ballot discuss] I'm following most of your reasoning behind having the twin methods PATCH and iPATCH, but I'm struggling a bit that there's nothing that … [Ballot discuss] I'm following most of your reasoning behind having the twin methods PATCH and iPATCH, but I'm struggling a bit that there's nothing that I saw that prevents a problem when the client implements only PATCH and the server implements only iPATCH. The only text I saw that provides guidance about which method to implement is A client can mark a request as idempotent by using the iPATCH method instead of the PATCH method. This is the only difference between the two. The indication of idempotence may enable the server to keep less state about the interaction; some constrained servers may only implement the iPATCH variant for this reason. Maybe I missed something? If not, I saw There is no guarantee that a resource can be modified with PATCH or iPATCH. so, maybe that mismatch isn't going to be a problem in practice, but it seems sad that you might have a patchable resource, that can't be patched because of that mismatch. I'm not asking for "clients MUST implement iPATCH if you implement PATCH" (which would accommodate servers that only implement iPATCH), but I wonder if the working group talked about a way to avoid this mismatch? |
2016-10-12
|
03 | Spencer Dawkins | [Ballot comment] I was a bit uneasy with the "nearly" in The security considerations for PATCH or iPATCH are nearly identical to the … [Ballot comment] I was a bit uneasy with the "nearly" in The security considerations for PATCH or iPATCH are nearly identical to the security considerations for PUT ([RFC7252]). with no explanation of any differences, but I'll leave that for the SEC ADs to pick up on if it matters. |
2016-10-12
|
03 | Spencer Dawkins | [Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins |
2016-10-11
|
03 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2016-10-11
|
03 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2016-10-11
|
03 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2016-10-11
|
03 | Joel Jaeggli | [Ballot comment] Sheng Jiang "BRPC path computation chain unavailable" set. Bit number Name Flag 28 … [Ballot comment] Sheng Jiang "BRPC path computation chain unavailable" set. Bit number Name Flag 28 BRPC path computation chain unavailable 13. Metric Normalization In the case of inter-area TE, the same IGP/TE metric scheme is usually adopted for all the IGP areas (e.g., based on the link-speed, propagation delay, or some other combination of link attributes). Hence, the proposed set of mechanisms always computes the shortest path across multiple areas that obey the required set of constraints with respect to a specified objective function. Conversely, in the case of inter-AS TE, in order for this path computation to be meaningful, metric normalization between ASes may be required. One solution to avoid IGP metric modification would be for the service providers to agree on a TE metric normalization scheme and use the TE Vasseur, et al. Standards Track [Page 12] RFC 5441 BRPC April 2009 metric for TE LSP path computation (in that case, the use of the TE metric must be requested in the PCEP path computation request) using the METRIC object (defined in [RFC5440]). 14. Manageability Considerations This section follows the guidance of [PCE-MANAGE]. 14.1. Control of Function and Policy The only configurable item is the support of the BRPC procedure on a PCE. The support of the BRPC procedure by the PCE MAY be controlled by a policy module governing the conditions under which a PCE should participate in the BRPC procedure (origin of the requests, number of requests per second, etc.). If the BRPC is not supported/allowed on a PCE, it MUST send a PCErr message as specified in Section 9. 14.2. Information and Data Models A BRPC MIB module will be specified in a separate document. 14.3. Liveness Detection and Monitoring The BRPC procedure is a multiple-PCE path computation technique and, as such, a set of PCEs are involved in the path computation chain. If the path computation chain is not operational either because at least one PCE does not support the BRPC procedure or because one of the PCEs that must be involved in the path computation chain is not available, procedures are defined to report such failures in Sections 9 and 12, respectively. Furthermore, a built-in diagnostic tool to check the availability and performances of a PCE chain is defined in [PCE-MONITOR]. 14.4. Verifying Correct Operation Verifying the correct operation of BRPC can be performed by monitoring a set of parameters. A BRPC implementation SHOULD provide the following parameters: o Number of successful BRPC procedure completions on a per-PCE-peer basis o Number of BRPC procedure completion failures because the VSPT flag was not recognized (on a per-PCE-peer basis) o Number of BRPC procedure completion failures because the BRPC procedure was not supported (on a per-PCE-peer basis) Vasseur, et al. Standards Track [Page 13] RFC 5441 BRPC April 2009 14.5. Requirements on Other Protocols and Functional Components The BRPC procedure does not put any new requirements on other protocols. That said, since the BRPC procedure relies on the PCEP protocol, there is a dependency between BRPC and PCEP; consequently, the BRPC procedure inherently makes use of the management functions developed for PCEP. 14.6. Impact on Network Operation The BRPC procedure does not have any significant impact on network operation: indeed, BRPC is a multiple-PCE path computation scheme as defined in [RFC4655] and does not differ from any other path computation request. 14.7. Path Computation Chain Monitoring [PCE-MONITOR] specifies a set of mechanisms that can be used to gather PCE state metrics. Because BRPC is a multiple-PCE path computation technique, such mechanisms could be advantageously used in the context of the BRPC procedure to check the liveness of the path computation chain, locate a faulty component, monitor the overall performance, and so on. 15. IANA Considerations 15.1. New Flag of the RP Object A new flag of the RP object (specified in [RFC5440]) is defined in this document. IANA maintains a registry of RP object flags in the "RP Object Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has allocated the following value: Bit Description Reference 25 VSPT This document 15.2. New Error-Type and Error-Value IANA maintains a registry of Error-Types and Error-values for use in PCEP messages. This is maintained as the "PCEP-ERROR Object Error Types and Values" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. Vasseur, et al. Standards Track [Page 14] RFC 5441 BRPC April 2009 A new Error-value is defined for the Error-Type "Not supported object" (type 4). Error-Type Meaning and error values Reference 4 Not supported object Error-value=4: Unsupported parameter This document A new Error-Type is defined in this document as follows: Error-Type Meaning Reference 13 BRPC procedure completion failure This document Error-value=1: BRPC procedure not This document supported by one or more PCEs along the domain path 15.3. New Flag of the NO-PATH-VECTOR TLV A new flag of the NO-PATH-VECTOR TLV defined in [RFC5440]) is specified in this document. IANA maintains a registry of flags for the NO-PATH-VECTOR TLV in the "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has allocated the following allocation value: Bit number Meaning Reference 4 BRPC path computation This document chain unavailable 16. Security Considerations The BRPC procedure relies on the use of the PCEP protocol and as such is subjected to the potential attacks listed in Section 10 of [RFC5440]. In addition to the security mechanisms described in [RFC5440] with regards to spoofing, snooping, falsification, and denial of service, an implementation MAY support a policy module governing the conditions under which a PCE should participate in the BRPC procedure. The BRPC procedure does not increase the information exchanged between ASes and preserves topology confidentiality, in compliance with [RFC4105] and [RFC4216]. Vasseur, et al. Standards Track [Page 15] RFC 5441 BRPC April 2009 17. Acknowledgments The authors would like to thank Arthi Ayyangar, Dimitri Papadimitriou, Siva Sivabalan, Meral Shirazipour, and Mach Chen for their useful comments. A special thanks to Adrian Farrel for his useful comments and suggestions. 18. References 18.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5440] Vasseur, J., Ed. and J. Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, April 2009. 18.2. Informative References [PATH-KEY] Bradford, R., Vasseur, J., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", Work in Progress, November 2008. [PCE-MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", Work in Progress, January 2009. [PCE-MONITOR] Vasseur, J., Roux, J., and Y. Ikejiri, "A set of monitoring tools for Path Computation Element based Architecture", Work in Progress, November 2008. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. Vasseur, et al. Standards Track [Page 16] RFC 5441 BRPC April 2009 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006. [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per- Domain Path Computation Method for Establishing Inter- Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008. [RFC5316] Chen, M., Zhang, R., and X. Duan, performed the opsdir review notable discussion Hi, Carsten, Thanks for clarification. I took it as that the answer for my second question is no. Then, I have no further concern. Good work. Regards, Sheng ________________________________________ From: Carsten Bormann [cabo@tzi.org] Sent: 09 October 2016 4:29 To: Sheng Jiang Cc: ops-dir@ietf.org; draft-ietf-core-etch.all@tools.ietf.org Subject: Re: OPS-DIR review of draft-ietf-core-etch Hi Sheng, thank you for your review. We don't believe there needs to be a single "standard" for the FETCH request payload media type. As the media type is somewhat specific to the kind of selection or search to be performed, as well as to the structure of the resource, more specific standards will define these media types. Please see application/cool-instance-id-list+cbor defined in https://tools.ietf.org/html/draft-veillette-core-cool-02 for just one example of such a specific definition. We have added a short note to 2.1.1 in the editors' draft to make the fact more prominent that FETCH media types are typically specifically defined. Please see https://core-wg.github.io/etch/ for the current editor's draft, to become -03 soon. Grüße, Carsten |
2016-10-11
|
03 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2016-10-11
|
03 | Joel Jaeggli | [Ballot comment] Sheng Jiang performed the opsdir review |
2016-10-11
|
03 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2016-10-10
|
03 | Alissa Cooper | [Ballot discuss] I agree with the comment made by the ops-dir reviewer, and I don't think the parenthetical in 2.2.1 addresses the problem. It seems … [Ballot discuss] I agree with the comment made by the ops-dir reviewer, and I don't think the parenthetical in 2.2.1 addresses the problem. It seems that FETCH is not a useful operation unless the server is capable of understanding what it is supposed to fetch. So it's not true that "any" media type can be used, but rather only those media types for which a definition exists for what the fetch parameters indicate and which part of the resource they are intended to delineate. Shouldn't the use of FETCH be constrained to such media types? |
2016-10-10
|
03 | Alissa Cooper | [Ballot comment] = Section 2 = "(However, while processing a search request, a server can be expected to allocate computing and memory resources or … [Ballot comment] = Section 2 = "(However, while processing a search request, a server can be expected to allocate computing and memory resources or even create additional server resources through which the response to the search can be retrieved.)" s/search/fetch/ would be clearer I think = Section 3 = "If the Request-URI does not point to an existing resource, the server MAY create a new resource with that URI, depending on the patch document type (whether it can logically modify a null resource) and permissions, etc." I know this is the same text as in RFC 5789, but it's vague. What else might create the basis for the server's decision besides the document type and permissions? = Section 5 = It seems that FETCH does introduce a new security consideration, in that any observer of FETCH requests can potentially glean information about the specific portions of a resource of interest to the requester. This might factor into decisions about whether to use DTLS to secure a particular request so may be worth mentioning. |
2016-10-10
|
03 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2016-10-10
|
03 | Alexey Melnikov | AD review comments were responded to. |
2016-10-10
|
03 | Alexey Melnikov | IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup |
2016-10-10
|
03 | Alexey Melnikov | Ballot has been issued |
2016-10-10
|
03 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2016-10-10
|
03 | Alexey Melnikov | Created "Approve" ballot |
2016-10-10
|
03 | Alexey Melnikov | Ballot writeup was changed |
2016-10-09
|
03 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-10-09
|
03 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2016-10-09
|
03 | Carsten Bormann | New version available: draft-ietf-core-etch-03.txt |
2016-10-09
|
03 | (System) | New version approved |
2016-10-09
|
02 | (System) | Request for posting confirmation emailed to previous authors: "Peter Van der Stok" , "Carsten Bormann" , "Anuj Sehgal" , core-chairs@ietf.org |
2016-10-09
|
02 | Carsten Bormann | Uploaded new revision |
2016-09-20
|
02 | Christer Holmberg | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Christer Holmberg. |
2016-09-18
|
02 | Alexey Melnikov | Ballot writeup was changed |
2016-09-12
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Sheng Jiang. |
2016-09-08
|
02 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Phillip Hallam-Baker. |
2016-09-08
|
02 | Alexey Melnikov | Placed on agenda for telechat - 2016-10-13 |
2016-09-08
|
02 | Alexey Melnikov | A revision to address my agreed points in my AD review is needed. Also a reply to SecDir review. |
2016-09-08
|
02 | Alexey Melnikov | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2016-09-07
|
02 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2016-09-07
|
02 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2016-09-06
|
02 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2016-09-06
|
02 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-core-etch-02.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-etch-02.txt. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there are three actions which IANA must complete. First, in the CoAP Method Codes subregistry of the Constrained RESTful Environments (CoRE) Parameters registry located at: http://www.iana.org/assignments/core-parameters/ three new method codes are to be added to the registry as follows: Code: 0.05 Name: FETCH Reference: [ RFC-to-be ] Code: 0.06 Name: PATCH Reference: [ RFC-to-be ] Code: 0.07 Name: iPATCH Reference: [ RFC-to-be ] Second, in the CoAP Response Codes subregistry also in the Constrained RESTful Environments (CoRE) Parameters registry located at: http://www.iana.org/assignments/core-parameters/ two new response codes are to be registered as follows: Code: 4.09 Name: Conflict Reference: [ RFC-to-be ] Code: 4.22 Name: Unprocessable Entity Reference: [ RFC-to-be ] Third, in the CoAP Content-Formats subregistry also in the Constrained RESTful Environments (CoRE) Parameters registry located at: http://www.iana.org/assignments/core-parameters/ two new content formats are to be registered as follows: Media Type: application/json-patch+json Encoding: ID: 51 Reference: [ RFC-to-be ] Media Type: application/merge-patch+json Encoding: ID: 52 Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. IANA understands that the three 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-09-01
|
02 | Alexey Melnikov | Double check: https://www.ietf.org/mail-archive/web/core/current/msg07801.html |
2016-08-25
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2016-08-25
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2016-08-25
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2016-08-25
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2016-08-24
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sheng Jiang |
2016-08-24
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sheng Jiang |
2016-08-24
|
02 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2016-08-24
|
02 | 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-etch@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-etch@ietf.org, core@ietf.org, alexey.melnikov@isode.com, "Jaime Jimenez" Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Patch and Fetch Methods for Constrained Application Protocol (CoAP)) to Proposed Standard The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Patch and Fetch Methods for Constrained Application Protocol (CoAP)' 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-09-07. 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 The existing Constrained Application Protocol (CoAP) methods only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP will need to perform partial resource accesses. Similar to HTTP, the existing Constrained Application Protocol (CoAP) GET method only allows the specification of a URI and request parameters in CoAP options, not the transfer of a request payload detailing the request. This leads to some applications to using POST where actually a cacheable, idempotent, safe request is desired. Again similar to HTTP, the existing Constrained Application Protocol (CoAP) PUT method only allows to replace a complete resource. This also leads applications to use POST where actually a cacheable, possibly idempotent request is desired. This specification adds new CoAP methods, FETCH, to perform the equivalent of a GET with a request body; and the twin methods PATCH and iPATCH, to modify parts of a CoAP resource. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-etch/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-etch/ballot/ No IPR declarations have been submitted directly on this I-D. The document has a reference to obsolete RFC 2616, this is intentional. |
2016-08-24
|
02 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2016-08-24
|
02 | Alexey Melnikov | Last call announcement was changed |
2016-08-24
|
02 | Alexey Melnikov | Last call was requested |
2016-08-24
|
02 | Alexey Melnikov | Last call announcement was generated |
2016-08-24
|
02 | Alexey Melnikov | Ballot approval text was generated |
2016-08-24
|
02 | Alexey Melnikov | Ballot writeup was generated |
2016-08-24
|
02 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation |
2016-08-24
|
02 | Alexey Melnikov | My AD review: I think response code 4.15 should be mentioned in Section 2 and not just in the IANA Considerations section. I am generally … My AD review: I think response code 4.15 should be mentioned in Section 2 and not just in the IANA Considerations section. I am generally missing Error handling section for the FETCH method, similarly to what you have for PATCH/iPATCH. draft-hartke-core-apps-03 is mentioned several times in the document. It is currently expired. What is the plan with getting it finished? Nit: It looks like RFC 6902 and RFC 7396 should be Normative (IANA Registrations). Obsolete reference: RFC 2616. You also need to update section references you use when referencing RFC 2616 to point to the correct section and RFC from the latest HTTP/1.1 set of RFCs. |
2016-08-24
|
02 | Alexey Melnikov | IESG state changed to AD Evaluation from Publication Requested |
2016-08-24
|
02 | Jaime Jimenez | ## Shepherd Writeup Full HTML version can be found at: http://jaimejim.github.io/temp/draft-ietf-core-etch#shepherd-writeup ###Summary Document Shepherd: [Jaime Jiménez](jaime.jimenez@ericsson.com) Area Director: [Alexey Melnikov](aamelnikov@fastmail.fm) The … ## Shepherd Writeup Full HTML version can be found at: http://jaimejim.github.io/temp/draft-ietf-core-etch#shepherd-writeup ###Summary Document Shepherd: [Jaime Jiménez](jaime.jimenez@ericsson.com) Area Director: [Alexey Melnikov](aamelnikov@fastmail.fm) The existing Constrained Application Protocol (CoAP) methods only allow access to a complete resource. This does not permit applications to access parts of a resource. In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP will need to perform partial resource accesses. Similar to HTTP, the existing Constrained Application Protocol (CoAP) GET method only allows the specification of a URI and request parameters in CoAP options, not the transfer of a request payload detailing the request. This leads to some applications to using POST where actually a cacheable, idempotent, safe request is desired. Again similar to HTTP, the existing Constrained Application Protocol (CoAP) PUT method only allows to replace a complete resource. This also leads applications to use POST where actually a cacheable, possibly idempotent request is desired. This specification adds new CoAP methods, FETCH, to perform the equivalent of a GET with a request body; and the twin methods PATCH and iPATCH, to modify parts of an existing CoAP resource. The document is intended as an Standards Track RFC. ###Review and Consensus The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed. There are no known implementations available. ###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 > There is a downref to RFC 2616: This is in there because the security considerations of RFC 7252 reference (the now obsoleted) RFC 2616. The authors are not aware of someone having done the work to collect the relevant security considerations from the splinters of RFC 2616 (RFC 7230 and following). ###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? * [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? ` There is no ABNF in this draft` * [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? `There is a normative reference to [I-D.ietf-core-block] but that shouldn't be a problem as it is in late stages` * [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state? * [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. `I wonder if adding a link to the CoRE Parameters registry could help, but it looks OK to me. ` `http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#method-codes` * [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)? `The two new entries to the content format registry (51 and 52) require expert review and a request has been SENT to that list.` * [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 new registries` * [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? |
2016-08-24
|
02 | Jaime Jimenez | Responsible AD changed to Alexey Melnikov |
2016-08-24
|
02 | Jaime Jimenez | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2016-08-24
|
02 | Jaime Jimenez | IESG state changed to Publication Requested |
2016-08-24
|
02 | Jaime Jimenez | IESG process started in state Publication Requested |
2016-08-24
|
02 | Jaime Jimenez | Changed consensus to Yes from Unknown |
2016-08-24
|
02 | Jaime Jimenez | Intended Status changed to Proposed Standard from None |
2016-08-24
|
02 | Jaime Jimenez | Changed document writeup |
2016-08-23
|
02 | Jaime Jimenez | Changed document writeup |
2016-08-23
|
02 | Jaime Jimenez | Changed document writeup |
2016-08-10
|
02 | Carsten Bormann | New version available: draft-ietf-core-etch-02.txt |
2016-07-11
|
01 | Jaime Jimenez | IETF WG state changed to In WG Last Call from WG Document |
2016-06-23
|
01 | Carsten Bormann | New version available: draft-ietf-core-etch-01.txt |
2016-06-11
|
00 | Alexey Melnikov | Notification list changed to "Jaime Jimenez" <jaime.jimenez@ericsson.com> |
2016-06-11
|
00 | Alexey Melnikov | Document shepherd changed to Jaime Jimenez |
2016-05-08
|
00 | Jaime Jimenez | This document now replaces draft-vanderstok-core-etch instead of None |
2016-05-08
|
00 | Carsten Bormann | New version available: draft-ietf-core-etch-00.txt |