A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)
draft-jimenez-p2psip-coap-reload-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-09-22
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-09-17
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-08-28
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-08-11
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-08-11
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2015-08-10
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-07-30
|
10 | (System) | RFC Editor state changed to EDIT |
2015-07-30
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-07-30
|
10 | (System) | Announcement was received by RFC Editor |
2015-07-30
|
10 | (System) | IANA Action state changed to In Progress |
2015-07-30
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2015-07-30
|
10 | Amy Vezza | IESG has approved the document |
2015-07-30
|
10 | Amy Vezza | Closed "Approve" ballot |
2015-07-29
|
10 | Ben Campbell | Ballot approval text was generated |
2015-07-23
|
10 | Jaime Jimenez | New version available: draft-jimenez-p2psip-coap-reload-10.txt |
2015-07-02
|
09 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2015-06-09
|
09 | Barry Leiba | [Ballot comment] Thanks for changing the registration policy to Specification Required; I think that's a better choice than Standards Action. And thanks for addressing my … [Ballot comment] Thanks for changing the registration policy to Specification Required; I think that's a better choice than Standards Action. And thanks for addressing my other comments. The only small issue I still have is with this change: OLD For example in cases multiple Wireless Sensor Networks (WSN) that need to be federated over some wider-area network. NEW For example in cases where multiple Wireless Sensor Networks (WSN) need to be federated over some wider-area network. The changed sentence is still not a complete sentence. But at least now I know what you're trying to say, so let me suggest merging it with the previous sentence, like this: NEWER This usage is intended for interconnected devices over a wide-area geographical coverage, such as in cases where multiple Wireless Sensor Networks (WSN) need to be federated over some wider-area network. END |
2015-06-09
|
09 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2015-06-09
|
09 | Jaime Jimenez | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-06-09
|
09 | Jaime Jimenez | New version available: draft-jimenez-p2psip-coap-reload-09.txt |
2015-05-15
|
08 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2015-05-15
|
08 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2015-05-14
|
08 | Cindy Morgan | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2015-05-14
|
08 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-05-14
|
08 | Stephen Farrell | [Ballot comment] - This is an AD sponsored document with an IPR declaration that says RAND+possible-fee. The write-up says that the core and p2psip WGs … [Ballot comment] - This is an AD sponsored document with an IPR declaration that says RAND+possible-fee. The write-up says that the core and p2psip WGs discussed the document and are ok with it being AD sponsored. Was the IPR declaration a part of that discussion? (The shepherd write up only says that nobody had a problem, it's not clear if the WGs were told about the IPR directly.) The IETF LC does however properly note the IPR, so this isn't a formal process-whine, I'm just asking:-) If the WGs were not in fact told about the IPR (via a mail or at the presentations mentioned) then it might be a good belt/braces type thing to do to just check that before proceeding since we know there are a bunch of people who aren't subscribed to IETF announce. - intro, "Regisgtration" para: I forget - do all CoAP nodes have a "CoAP URI" that they need to know? If so, a ref to that bit of the CoAP spec would be good. If not, I'm not sure how this works. - PEA on 1st use: "RN" is a what? - section 9: "which canonicalized form hashes (using the hash function for the overlay) to the Resource-ID" is not clear enough IMO and likely to create interop issues. I think you need some more detail and a combination of references and examples before this will be implemented well. Similarly "certificate has an associated URI" isn't precise enough is it? (It could be in a SAN or some otherName or even outside the cert with that wording.) - section 10: I think you're missing a security consideration: if a CoAP node (probably esp. a sleepy node) uses this to publish information about itself, then it is more likely to get attacked, e.g. a sleepy node may be more likely to get a barrage of messages as soon as it awakens as part of a battery depletion or other DoS attack. I'd note that and say that it's more important to be DoS resistent and get e.g. s/w updates when you tell the world about yourself, since not all bits of the world you're telling are nice. (PEA == Please Expand Acronyms:-) |
2015-05-14
|
08 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-05-13
|
08 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-05-13
|
08 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-05-13
|
08 | Cindy Morgan | Changed consensus to Yes from Unknown |
2015-05-13
|
08 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-05-13
|
08 | Barry Leiba | [Ballot discuss] For the new registry in Section 11.3, why is Standards Action necessary? That's the strictest policy we have. What harm is done if … [Ballot discuss] For the new registry in Section 11.3, why is Standards Action necessary? That's the strictest policy we have. What harm is done if other policies are registered, such that a Standards Track RFC is necessary? Would "Standards Action or Specification Required" be good enough, allowing a designated expert to review requests that don't come from Standards Track? (I ask this because we have painted ourselves into corners many times, forcing things to be Standards Track unnecessarily, just because we made a too-strict registry policy earlier.) |
2015-05-13
|
08 | Barry Leiba | [Ballot comment] The Introduction starts rather abruptly. I presume the intent is that the Abstract is really the first paragraph of the Introduction. I know … [Ballot comment] The Introduction starts rather abruptly. I presume the intent is that the Abstract is really the first paragraph of the Introduction. I know you're trying to avoid duplicating the Abstract in the Introduction, but maybe that really is the best thing to do here. For example in cases multiple Wireless Sensor Networks (WSN) that need to be federated over some wider-area network. There's something missing here, and the result doesn't make sense. Please fix. -- Section 3 -- In our architecture we extend the different nodes present in RELOAD (Peer, Client) and add support for sensor devices or other constrained devices. Figure 2 illustrates our architecture. And yet it's Figure 1 that's labelled "Architecture". Figure 2 says it's about "Overlay Topology". -- Section 7 subsections -- I find the use of "[length]" to describe arrays to be confusing, especially as they're preceded by something also called "length" that actually is a length value. For example: struct { Node-ID Node_ID; uint32 length; SensorEntry sensors[length]; } ProxyCache; If the "sensors" item is an array, wouldn't it be better to sau "sensors[count]", or some such? -- Section 7.2 -- SensorInfo contains relevant sensor information that is dependent on the use case. As an example we use the sensor manufacturer as relevant information. struct { opaque manufacturer; /* extensions */ } SensorInfo; sensor_type contains the type of a resource as defined in [RFC6690], for example temperature, luminosity, etc.; duration_of_inactivity contains the sleep pattern (if any) that the sensor device follows, specified in seconds; last_awake indicates the last time that the sensor was awake represented as the number of milliseconds elapsed since midnight Jan 1, 1970 UTC not counting leap seconds. This will have the same values for seconds as standard UNIX time or POSIX time; That doesn't make sense to me: the items sensor_type, duration_of_inactivity, and last_awake don't appear in the structure. What's supposed to be described here? -- Section 9 -- In URI-NODE-MATCH policy, a given value MUST be written and overwritten if and only if the signer's certificate has an associated URI which canonicalized form hashes (using the hash function for the overlay) to the Resource-ID for the resource. In addition, the dictionary key MUST be equal to the Node-ID in the certificate and that Node-ID MUST be the one indicated in the SignerIdentity value cert_hash. I have two problems with this. One is that it repeats the description of URI-MATCH exactly, but doesn't say so, so the reader wonders if there's a difference (I compared them carefully; why make the reader work that hard?). The other is that you have that very clear "if and only if", which you then appear to modify in the next sentence, so it isn't really if and only if, is it? I suggest this, which I think is clearer: NEW In URI-NODE-MATCH policy, a given value MUST be written and overwritten if and only if the condition for URI-MATCH is met and, in addition, the dictionary key is equal to the Node-ID in the certificate and that Node-ID is the one indicated in the SignerIdentity value cert_hash. END You also refer to Section 9 twice, like this: The "coap:" prefix needs to be removed from the COAP URI before matching. See Section 9. ...but there is nothing in Section 9 about that at all. Oversight? -- Section 11.3 -- Both SHALLs in this section are not appropriate use of 2119 key words -- especially the first one. Please replace the first with something like "IANA is asked to...". For the second, more of a fix is needed, because you have a dangling reference to 5226, followed by a sentence fragment. So: "New entries in this registry are registered using the Standards Action policy [RFC5226]." |
2015-05-13
|
08 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2015-05-13
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-05-13
|
08 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-05-13
|
08 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-05-13
|
08 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-05-12
|
08 | Spencer Dawkins | [Ballot comment] I don't think this is a problem, but would you expect a COAP RELOAD usage to use self-signed certificates pretty much all the … [Ballot comment] I don't think this is a problem, but would you expect a COAP RELOAD usage to use self-signed certificates pretty much all the time? Otherwise, wouldn't you have to configure certificates on each node? The base RELOAD specification allows that, but if that's what's expected, it might be helpful to explain what's expected and why. |
2015-05-12
|
08 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2015-05-07
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2015-05-07
|
08 | Ben Campbell | Placed on agenda for telechat - 2015-05-14 |
2015-05-07
|
08 | Ben Campbell | Ballot has been issued |
2015-05-07
|
08 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2015-05-07
|
08 | Ben Campbell | Created "Approve" ballot |
2015-05-07
|
08 | Ben Campbell | Ballot approval text was generated |
2015-05-01
|
08 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2015-05-01
|
08 | Pearl Liang | (Via drafts-lastcall@iana.org): IESG/Authors: IANA has reviewed draft-jimenez-p2psip-coap-reload-08. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions … (Via drafts-lastcall@iana.org): IESG/Authors: IANA has reviewed draft-jimenez-p2psip-coap-reload-08. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA has a question about one of the actions requested in the IANA Considerations section of this document. IANA understands that, upon approval of this document there are two actions which need to be completed. First, in the RELOAD Data Kind-ID subregistry of the REsource LOcation And Discovery (RELOAD) registry located at: http://www.iana.org/assignments/reload/ two new Kind_IDs are to be registered as follows: Kind-ID: { TBD-AT-REGISTRATION ] Kind: CoAP-REGISTRATION Reference: [ RFC-to-be ] IANA notes that the authors request Kind-ID 105 for this registration. Kind-ID: { TBD-AT-REGISTRATION ] Kind: CoAP-CACHING Reference: [ RFC-to-be ] IANA notes that the authors request Kind-ID 106 for this registration. Second, IANA will created a new registry called the CoAP Usage for RELOAD Access Control Policy registry. IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained? Is it the existing RELOAD registry? This new registry will be managed via Standards Action as defined in RFC 5226. The initial contents of the registry are: Access-Policy Reference -----------------------+----------------- URI-NODE-MATCH [ RFC-TO-BE ] URI-MATCH [ RFC-TO-BE ] IANA understands that these two actions are the only ones that need 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. Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. |
2015-04-19
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Suzanne Woolf |
2015-04-19
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Suzanne Woolf |
2015-04-16
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2015-04-16
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2015-04-16
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to John Bradley |
2015-04-16
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to John Bradley |
2015-04-15
|
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-04-15
|
08 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (A Constrained Application Protocol (CoAP) Usage … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)' 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 2015-05-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). The CoAP Usage provides the functionality to federate Wireless Sensor Networks (WSN) in a peer-to-peer fashion. The CoAP Usage for RELOAD allows CoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a lookup service, and enables the use of RELOAD overlay as a cache for sensor data. This functionality is implemented in the RELOAD overlay itself, without the use of centralized servers. The RELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged. The file can be obtained via http://datatracker.ietf.org/doc/draft-jimenez-p2psip-coap-reload/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-jimenez-p2psip-coap-reload/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1783/ |
2015-04-15
|
08 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-04-15
|
08 | Ben Campbell | Last call was requested |
2015-04-15
|
08 | Ben Campbell | Last call announcement was generated |
2015-04-15
|
08 | Ben Campbell | IESG state changed to Last Call Requested from AD is watching |
2015-04-15
|
08 | Ben Campbell | IESG state changed to AD is watching from AD Evaluation |
2015-04-15
|
08 | Ben Campbell | Ballot approval text was generated |
2015-04-15
|
08 | Ben Campbell | Ballot writeup was changed |
2015-04-15
|
08 | Jaime Jimenez | New version available: draft-jimenez-p2psip-coap-reload-08.txt |
2015-04-10
|
07 | Ben Campbell | IESG state changed to AD Evaluation from Publication Requested |
2015-03-30
|
07 | Ben Campbell | Shepherding AD changed to Ben Campbell |
2015-02-17
|
07 | Richard Barnes | Ballot writeup was generated |
2015-02-05
|
07 | Richard Barnes | Assigned to Real-time Applications and Infrastructure Area |
2015-02-05
|
07 | Richard Barnes | Intended Status changed to Proposed Standard |
2015-02-05
|
07 | Richard Barnes | IESG process started in state Publication Requested |
2015-02-05
|
07 | Richard Barnes | Stream changed to IETF from None |
2015-02-04
|
07 | Richard Barnes | Shepherding AD changed to Richard Barnes |
2015-02-04
|
07 | Carlos Jesús Bernardos | Changed document writeup |
2015-02-03
|
07 | Richard Barnes | Notification list changed to "Carlos J. Bernardos" <cjbc@it.uc3m.es> |
2015-02-03
|
07 | Richard Barnes | Document shepherd changed to Carlos Jésus Bernardos |
2015-02-03
|
07 | Jaime Jimenez | New version available: draft-jimenez-p2psip-coap-reload-07.txt |
2015-01-29
|
06 | Jaime Jimenez | New version available: draft-jimenez-p2psip-coap-reload-06.txt |
2015-01-02
|
05 | Jaime Jimenez | New version available: draft-jimenez-p2psip-coap-reload-05.txt |
2014-07-02
|
04 | Gonzalo Camarillo | New version available: draft-jimenez-p2psip-coap-reload-04.txt |
2013-02-17
|
03 | Jaime Jimenez | New version available: draft-jimenez-p2psip-coap-reload-03.txt |
2012-08-20
|
02 | Jaime Jimenez | New version available: draft-jimenez-p2psip-coap-reload-02.txt |
2012-05-16
|
(System) | Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-jimenez-p2psip-coap-reload-01 | |
2012-02-29
|
01 | Jaime Jimenez | New version available: draft-jimenez-p2psip-coap-reload-01.txt |
2012-02-24
|
00 | (System) | New version available: draft-jimenez-p2psip-coap-reload-00.txt |