A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)
draft-jimenez-p2psip-coap-reload-10

[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

[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:-)

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

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

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

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

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/