Constrained Application Protocol (CoAP) Hop-Limit Option
draft-ietf-core-hop-limit-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-03-20
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-03-19
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-02-27
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-12-02
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-11-28
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-11-28
|
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-11-27
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-11-26
|
07 | (System) | IANA Action state changed to In Progress |
2019-11-26
|
07 | (System) | RFC Editor state changed to EDIT |
2019-11-26
|
07 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-11-26
|
07 | (System) | Announcement was received by RFC Editor |
2019-11-26
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-11-26
|
07 | Amy Vezza | IESG has approved the document |
2019-11-26
|
07 | Amy Vezza | Closed "Approve" ballot |
2019-11-26
|
07 | Amy Vezza | Ballot approval text was generated |
2019-11-26
|
07 | Alexey Melnikov | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2019-11-26
|
07 | Alexey Melnikov | I am satisfied that a generic way of gatewaying COAP options in HTTP is in works and will be done in a separate document. |
2019-11-09
|
07 | Éric Vyncke | Closed request for Telechat review by IOTDIR with state 'Withdrawn': The document has been approved by the IESG. |
2019-10-17
|
07 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2019-10-17
|
07 | Michelle Cotton | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-10-17
|
07 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-10-17
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-10-17
|
07 | Mohamed Boucadair | New version available: draft-ietf-core-hop-limit-07.txt |
2019-10-17
|
07 | (System) | New version approved |
2019-10-17
|
07 | (System) | Request for posting confirmation emailed to previous authors: Jon Shallow , Reddy K , Mohamed Boucadair |
2019-10-17
|
07 | Mohamed Boucadair | Uploaded new revision |
2019-10-16
|
06 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-10-15
|
06 | Adam Roach | [Ballot comment] Thanks to everyone who worked on this document. I'm a little surprised that the treatment of loops that go between HTTP and CoAP … [Ballot comment] Thanks to everyone who worked on this document. I'm a little surprised that the treatment of loops that go between HTTP and CoAP networks involves a simple observation that detection of such cases simply won't work, without any attempt at mitigation. I'm sympathetic to the observation during WGLC that directly interworking with RFC 8586 isn't feasible, but surprised that more primitive approaches to at least preserving the CoAP Hop-Count as it crossed the HTTP network weren't considered. There are aesthetic discussions to be had around, e.g., defining an HTTP "Hop-Count" header field (which isn't acted on by the HTTP network, but serves the purpose of preserving the value during transit) or overloading the semantics (but not really the meaning) of the HTTP "Max-Forwards" header field, or (in extremis) squirreling the Hop-Count away in the `pseudonym` portion of the inserted HTTP Via header field. But I think the high order bit here is that preserving the Hop-Count value through the HTTP network would be trivial, and would prevent the identified shortcoming of the current mechanism. |
2019-10-15
|
06 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-10-15
|
06 | Barry Leiba | [Ballot comment] Thanks for a simple, yet useful document. Just some really small nits here: I wish you had used “that” in most places in … [Ballot comment] Thanks for a simple, yet useful document. Just some really small nits here: I wish you had used “that” in most places in the document where “which” is. Perhaps the RFC Editor will change those. If you care to make me happier (an optional thing, surely), you might change every instance of “which” to “that” *except* the one in the Abstract (which is correct). — Section 3 — Nevertheless, the presence of such proxies will not prevent infinite loop detection if at least one CoAP proxy which support the Hop-Limit option is involved in the loop. “support” -> “supports” A CoAP proxy which understands the Hop-Limit option MAY be instructed, using a configuration parameter, to insert a Hop-Limit option when relaying a request which do not include the Hop-Limit option. “do not” -> “does not” |
2019-10-15
|
06 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2019-10-15
|
06 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-10-15
|
06 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-10-15
|
06 | Benjamin Kaduk | [Ballot comment] Section 1.1 It's not entirely clear to me that the original ("specific") use case needs to be mentioned given that the document now … [Ballot comment] Section 1.1 It's not entirely clear to me that the original ("specific") use case needs to be mentioned given that the document now has a generic intended usage. Note that this means that a server that receives requests both via proxies and directly from clients may see otherwise identical requests with and without the Hop-Limit option included; servers with internal caching will therefore also want to implement this option. We might want to have one more sentence here to expound on why (if they implement the option, then it's okay for them to ignore it when doing a cache lookup which would not otherwise be safe?) Section 3 I'd suggest mentioning that C/U/N/R and the formatting of Table 1 also match up with Table 4 (Section 5.10) of RFC 7252, since without that reference for comparison it's a bit hard to know how to interpret the C/U/N/R columns in the table. Nevertheless, the presence of such proxies will not prevent infinite loop detection if at least one CoAP proxy which support the Hop-Limit option is involved in the loop. nit: s/support/supports/ A CoAP proxy which understands the Hop-Limit option MAY be instructed, using a configuration parameter, to insert a Hop-Limit option when relaying a request which do not include the Hop-Limit option. In light of the other discussion about how strongly to recommend Hop-Limit's usage, do we want to revisit MAY vs. SHOULD here? (My apologies if we already did and I missed it.) The initial Hop-Limit value should be configurable. If no initial value is explicitly provided, the default initial Hop-Limit value of 16 MUST be used. This value is chosen to be sufficiently large to guarantee that a CoAP request would not be dropped in networks when there were no loops, but not so large as to consume CoAP proxy resources when a loop does occur. [...] It would have been nice to have an updated rev that includes feedback from, e.g., the secdir reviewer. That is to say, I also think that "guarantee" is too strong here. Note: If a request with a given value of Hop-Limit failed to reach a server because the hop limit is exhausted, then the same failure will be observed if a less value of the Hop-Limit option is used instead. nit: s/less/smaller/ Section 4 To ease debugging and troubleshooting, the CoAP proxy which detects a loop includes its information in the diagnostic payload under the nit: given the subsequent discussion, maybe s/its information/an identifier for itself/? conditions detailed in Section 5.5.2 of [RFC7252]. That information MUST NOT include any space character. The information inserted by a Does "space character" just mean ASCII 0x20, or any character with the WSpace property? Each intermediate proxy involved in relaying a TBA1 (Hop Limit Reached) error message prepends its own information in the diagnostic payload with a space character used as separator. Only one information per proxy should appear in the diagnostic payload. Doing Does this mean that a proxy is expected to inspect the diagnostic payload for its own identifier before prepending? Section 5 By default, the HTTP-to-CoAP Proxy inserts a Hop-Limit option following the guidelines in Section 3. The HTTP-to-CoAP Proxy MAY be instructed by policy to insert a Hop-Limit option only if a Via (Section 5.7.1 of [RFC7230]) or CDN-Loop header field [RFC8586] is present in the HTTP request. It seems like a descriptive "may" would work okay here, if desired. By default, the CoAP-to-HTTP Proxy inserts a Via header field in the HTTP request if the CoAP request includes a Hop-Limit option. The CoAP-to-HTTP Proxy MAY be instructed by policy to insert a CDN-Loop header field instead of the Via header field. (same here) When both HTTP-to-CoAP and CoAP-to-HTTP proxies are involved, the loop detection may get broken if the proxy-forwarded traffic repeatedly crosses the HTTP-to-CoAP and CoAP-to-HTTP proxies. It feels like we could say more here -- if the hc and ch proxies use mapping rules such that proxy identifiers are preserved across a protocol-translation round-trip, wouldn't loop detection still work? Section 7 It seems that any attacker in a position to add or modify a hop-limit option would be able to drop the request or forge a response anyway, so there's not much of a new DoS risk. However, in addition to the topology leakage in the diagnostic payload, I think that an attacker could use small hop-limit values to probe the topology of a network into which it is making requests, finding the smallest hop-limit value that allows the request to succeed. |
2019-10-15
|
06 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2019-10-15
|
06 | Magnus Westerlund | [Ballot comment] Table 1: This table is missing a legend for what the meaning of a blank cell is for the CUNR flags. I assume … [Ballot comment] Table 1: This table is missing a legend for what the meaning of a blank cell is for the CUNR flags. I assume they are boolean True or false, and that empty implies false, but this could be clarified. |
2019-10-15
|
06 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2019-10-15
|
06 | Warren Kumari | [Ballot comment] Firstly, thank you for writing this - also, thank you for the discussions and addressing the comments from the OpsDir review (and much … [Ballot comment] Firstly, thank you for writing this - also, thank you for the discussions and addressing the comments from the OpsDir review (and much thanks to Scott for providing the review). I agree that this should have an Updates: tab, but I understand the arguments against it. There are some very good notes in the other ballots, which I really think need to be addressed, including such clear things as Suresh's: "CoAP messages received with a Hop-Limit option ... ***greater than '255'*** MUST be rejected" -- Since the field is only 8 bits long this will never happen, right? If so, this text about >255 needs to be removed. |
2019-10-15
|
06 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-10-15
|
06 | Roman Danyliw | [Ballot comment] ** Section 1.0, What is an “involved application agent”? ** Section 1.1 Per “CoAP proxies that do not have specific knowledge that proxy … [Ballot comment] ** Section 1.0, What is an “involved application agent”? ** Section 1.1 Per “CoAP proxies that do not have specific knowledge that proxy loops are avoided in some way …”, how would a proxy know that? ** Section 7. Perhaps also add that a malicious proxy can induce more subtle failures than just straight packet drops by manipulating the Hop Limit value. ** Editorial Nits: -- Section 1.1. Editorial. s/ The Hop-Limit option has originally been designed for a/The Hop-Limit option was originally designed for a/ -- Section 3. Recommend being clearer on what it means for “Hop-Limit detection gets broken” when proxies on boundaries re-write the hop limit value. Perhaps something on the order of: s/ This modification should be done with caution in case proxy-forwarded traffic repeatedly crosses the administrative domain boundary in a loop and so Hop-Limit detection gets broken ./ This modification should be done with caution in case proxy-forwarded traffic repeatedly crosses the administrative domain boundary in a loop rendering negating the efficacy of loop detection through the Hop-Limit field. -- Section 4. Per “Only one information per proxy should appear in the diagnostic payload”, what is “one information” (it seems like a few words are missing here)? -- Section 4. Per “Doing so allows to limit the size of the TBA1 …”, this sentence doesn’t parse for me. |
2019-10-15
|
06 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-10-14
|
06 | Suresh Krishnan | [Ballot comment] * Section 3 "CoAP messages received with a Hop-Limit option ... ***greater than '255'*** MUST be rejected" Since the field is only 8 … [Ballot comment] * Section 3 "CoAP messages received with a Hop-Limit option ... ***greater than '255'*** MUST be rejected" Since the field is only 8 bits long this will never happen, right? If so, this text about >255 needs to be removed. * I would have expected that a CoAP option with NoCacheKey bits all zero would need to match in order to be served from the cache. Checking also for smaller values of Hop Limit for sending stored responses seems to (IMHO) complicate things for little benefit. |
2019-10-14
|
06 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-10-14
|
06 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-10-11
|
06 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-10-10
|
06 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. I have a couple of COMMENTs (that I would appreciate to see a reply … [Ballot comment] Thank you for the work put into this document. I have a couple of COMMENTs (that I would appreciate to see a reply of yours) and one NIT. Regards, -éric == DISCUSS == == COMMENTS == -- Section 3 -- C.1) "Because forwarding errors may occur if inadequate Hop-Limit values are used, proxies at the boundaries of an administrative domain MAY be instructed to remove or rewrite the value of Hop-Limit carried in received messages" Isn't this remove all usefulness of the Hop-Limit option ? C.2) table 1, suggest to state the value of the C, U, N, R properties -- Section 4 -- C.3) while I understand why a proxy should not add its own diagnostic information when packet should become larger than the MTU of the next link, I wonder what will happen downstream when the MTU will be exceeded... C.4) suggest to use normative language (uppercase MAY, MUST, ...) == NITS == -- Section 3 -- N.1) s/if a less value/if a smaller value/ ? |
2019-10-10
|
06 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-10-08
|
06 | Amy Vezza | Placed on agenda for telechat - 2019-10-17 |
2019-10-08
|
06 | Alexey Melnikov | Ballot has been issued |
2019-10-08
|
06 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2019-10-08
|
06 | Alexey Melnikov | Created "Approve" ballot |
2019-10-08
|
06 | Alexey Melnikov | Ballot writeup was changed |
2019-10-08
|
06 | Alexey Melnikov | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-10-03
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Radia Perlman. Submission of review completed at an earlier date. |
2019-09-28
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Radia Perlman. |
2019-09-27
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2019-09-27
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-core-hop-limit-06. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-core-hop-limit-06. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the CoAP Response Codes sub-registry of the CoAP Codes registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at: https://www.iana.org/assignments/core-parameters/ a new value is to be registered as follows: Code: [ TBD-at-Registration ] Description: Hop Limit Reached Reference: [ RFC-to-be ] IANA understands that the value 5.08 has been suggested by the authors as the code to be assigned. Second, in the CoAP Option Numbers registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at: https://www.iana.org/assignments/core-parameters/ a new value is to be registered as follows: Number: TBA2 Name: Hop-Limit Reference: [ RFC-to-be ] The IANA Functions Operator understands that these are the only actions 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 meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-09-27
|
06 | Mohamed Boucadair | New version available: draft-ietf-core-hop-limit-06.txt |
2019-09-27
|
06 | (System) | New version approved |
2019-09-27
|
06 | (System) | Request for posting confirmation emailed to previous authors: Jon Shallow , Reddy K , Mohamed Boucadair |
2019-09-27
|
06 | Mohamed Boucadair | Uploaded new revision |
2019-09-27
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-09-26
|
05 | Scott Bradner | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Scott Bradner. Sent review to list. |
2019-09-26
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2019-09-26
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2019-09-24
|
05 | Russ Mundy | Assignment of request for Last Call review by SECDIR to Russ Mundy was rejected |
2019-09-22
|
05 | Éric Vyncke | Requested Telechat review by IOTDIR |
2019-09-22
|
05 | Roni Even | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Roni Even. Sent review to list. |
2019-09-19
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2019-09-19
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2019-09-19
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Mundy |
2019-09-19
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Mundy |
2019-09-19
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2019-09-19
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2019-09-13
|
05 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-09-13
|
05 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-09-27): From: The IESG To: IETF-Announce CC: draft-ietf-core-hop-limit@ietf.org, Jaime Jimenez , jaime@iki.fi, core@ietf.org, … The following Last Call announcement was sent out (ends 2019-09-27): From: The IESG To: IETF-Announce CC: draft-ietf-core-hop-limit@ietf.org, Jaime Jimenez , jaime@iki.fi, core@ietf.org, alexey.melnikov@isode.com, core-chairs@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Constrained Application Protocol (CoAP) Hop-Limit Option) to Proposed Standard The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Constrained Application Protocol (CoAP) Hop-Limit Option' 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 2019-09-27. 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 presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-hop-limit/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-hop-limit/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-09-13
|
05 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-09-13
|
05 | Alexey Melnikov | Last call was requested |
2019-09-13
|
05 | Alexey Melnikov | Last call announcement was generated |
2019-09-13
|
05 | Alexey Melnikov | Ballot approval text was generated |
2019-09-13
|
05 | Alexey Melnikov | Ballot writeup was generated |
2019-09-13
|
05 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation |
2019-09-12
|
05 | Alexey Melnikov | IESG state changed to AD Evaluation from Publication Requested |
2019-09-10
|
05 | Jaime Jimenez | ## Shepherd Writeup The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such … ## Shepherd Writeup The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. The new hop-limit option is elective, safe to forward, not part of a cache and not-repeatable and gets decremented after every hop. This draft is the solution to a problem raised by the DOTs WG (https://tools.ietf.org/html/draft-ietf-dots-signal-channel-37). It is referred as a normative reference there. The option has already been implemented in the proprietary NCC Group DOTS. ### Summary Document Shepherd: Jaime Jiménez Area Director: Alexey Melnikov The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. The document is intended for Standards Track. ### Review and Consensus The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. ### 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 The document creates a new CoAP response code (5.08 which is unassigned) and a new Option Number, we have had reviewers verify both. ### 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? - [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? - [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? - [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? - [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? |
2019-09-10
|
05 | Jaime Jimenez | Responsible AD changed to Alexey Melnikov |
2019-09-10
|
05 | Jaime Jimenez | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2019-09-10
|
05 | Jaime Jimenez | IESG state changed to Publication Requested from I-D Exists |
2019-09-10
|
05 | Jaime Jimenez | IESG process started in state Publication Requested |
2019-09-10
|
05 | Jaime Jimenez | Changed consensus to Yes from Unknown |
2019-09-10
|
05 | Jaime Jimenez | Intended Status changed to Proposed Standard from None |
2019-09-10
|
05 | Mohamed Boucadair | New version available: draft-ietf-core-hop-limit-05.txt |
2019-09-10
|
05 | (System) | New version approved |
2019-09-10
|
05 | (System) | Request for posting confirmation emailed to previous authors: Jon Shallow , Reddy K , Mohamed Boucadair |
2019-09-10
|
05 | Mohamed Boucadair | Uploaded new revision |
2019-09-10
|
04 | Jaime Jimenez | ## Shepherd Writeup The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such … ## Shepherd Writeup The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. The new hop-limit option is elective, safe to forward, not part of a cache and not-repeatable and gets decremented after every hop. This draft is the solution to a problem raised by the DOTs WG (https://tools.ietf.org/html/draft-ietf-dots-signal-channel-37). It is referred as a normative reference there. The option has already been implemented in the proprietary NCC Group DOTS. ### Summary Document Shepherd: Jaime Jiménez Area Director: Alexey Melnikov The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. The document is intended for Standards Track. ### Review and Consensus The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. ### 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 The document creates a new CoAP response code (5.08 which is unassigned) and a new Option Number, we have had reviewers verify both. ### 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? - [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? - [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? - [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? - [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? |
2019-09-10
|
04 | Jaime Jimenez | Notification list changed to Jaime Jimenez <jaime@iki.fi> |
2019-09-10
|
04 | Jaime Jimenez | Document shepherd changed to Jaime Jimenez |
2019-07-03
|
04 | Mohamed Boucadair | New version available: draft-ietf-core-hop-limit-04.txt |
2019-07-03
|
04 | (System) | New version approved |
2019-07-03
|
04 | (System) | Request for posting confirmation emailed to previous authors: Jon Shallow , Mohamed Boucadair , core-chairs@ietf.org, Reddy K |
2019-07-03
|
04 | Mohamed Boucadair | Uploaded new revision |
2019-07-02
|
03 | Carsten Bormann | Till 2019-06-25. |
2019-06-12
|
03 | Carsten Bormann | WGLC until 2019-06-25 1820Z |
2019-06-12
|
03 | Carsten Bormann | IETF WG state changed to In WG Last Call from WG Document |
2019-02-26
|
03 | Mohamed Boucadair | New version available: draft-ietf-core-hop-limit-03.txt |
2019-02-26
|
03 | (System) | New version approved |
2019-02-26
|
03 | (System) | Request for posting confirmation emailed to previous authors: Reddy K , Mohamed Boucadair , Jon Shallow |
2019-02-26
|
03 | Mohamed Boucadair | Uploaded new revision |
2018-12-12
|
02 | Mohamed Boucadair | New version available: draft-ietf-core-hop-limit-02.txt |
2018-12-12
|
02 | (System) | New version approved |
2018-12-12
|
02 | (System) | Request for posting confirmation emailed to previous authors: Reddy K , Mohamed Boucadair , Jon Shallow |
2018-12-12
|
02 | Mohamed Boucadair | Uploaded new revision |
2018-11-06
|
01 | Mohamed Boucadair | New version available: draft-ietf-core-hop-limit-01.txt |
2018-11-06
|
01 | (System) | New version approved |
2018-11-06
|
01 | (System) | Request for posting confirmation emailed to previous authors: Reddy K , Mohamed Boucadair , Jon Shallow |
2018-11-06
|
01 | Mohamed Boucadair | Uploaded new revision |
2018-09-17
|
00 | Carsten Bormann | This document now replaces draft-boucadair-core-hop-limit instead of None |
2018-09-17
|
00 | Mohamed Boucadair | New version available: draft-ietf-core-hop-limit-00.txt |
2018-09-17
|
00 | (System) | WG -00 approved |
2018-09-17
|
00 | Mohamed Boucadair | Set submitter to "Mohamed Boucadair ", replaces to draft-boucadair-core-hop-limit and sent approval email to group chairs: core-chairs@ietf.org |
2018-09-17
|
00 | Mohamed Boucadair | Uploaded new revision |