The Constrained Application Protocol (CoAP)
draft-ietf-core-coap-18

[Ballot comment]
Thanks for addressing my more serious concerns. Nothing blocking, but for your consideration:

By section number:

4.2/4.3: "Reject" in the sense it is talked about in these sections is an internal state change. That's confusing to me, as the normal sense of the English word implies a party that "hears about" the rejection. (It's hard to me to think of a circumstance where someone or something was "rejected" and only the rejector ever knew about it.) In your use, "silently ignore" is one possible form of rejection. That's just weird.

If you're going to do this, I'd define the term up front. Maybe even capitalize "Reject" wherever you use it.

Either way, in both 4.2 and 4.3, "MUST reject" is probably wrong (since that's an internal state and nothing a protocol requirement is useful for) and "MAY involve sending" is a strange construction.

4.5: I think the MAYs confuse things and might encourage implementers to take that path. Instead of:

  This rule MAY be relaxed in case
  the Confirmable message transports a request that is idempotent (see
  Section 5.1) or can be handled in an idempotent fashion.  Examples
  for relaxed message deduplication:
 
I suggest: "Exceptions to this are when the Confirmable message transports a request that is idempotent (see Section 5.1) or can be handled in an idempotent fashion.  Examples of these exceptions:". Also:

  As a general rule that MAY be
  relaxed based on the specific semantics of a message, the recipient
  SHOULD silently ignore any duplicated Non-confirmable message, and
  SHOULD process any request or response in the message only once.
 
I suggest: "The recipient SHOULD silently ignore any duplicated Non-confirmable message, and SHOULD process any request or response in the message only once, though the specific semantics of the message might dictate an exception."

4.6: I feel like this section is really one big implementation note: Because it is a layer violation, it's not clear to me that any implementer has the ability to figure out much of this. (For example, the idea that an implementer would be willing to -- or even know how to -- set the Do Not Fragment bit or figure out the Path MTU is a bit hopeful.) I have no objection to this section, but it might be better as an implementation note rather than a set of protocol instructions.

5.3.2: Change "the client will likely send a Reset message so it does not receive any more retransmissions" to "the client will send". A client that has lost state that receives what it will see as a random CON message will always send back a Reset.

5.4.6: If it were me, I would have put the NoCacheKey bits in the high four bits of the most significant byte so that you could simply do a <224 test for cache-matching options. I suppose this ship has sailed.

5.5.1: The implementation note notwithstanding, I don't understand why Content-Format is not a SHOULD.

8.1:

  A server SHOULD be aware that a request arrived via multicast, e.g.
  by making use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if
  available.

That SHOULD is not meaningful. It is useful, not required with exceptions (as SHOULD indicates), for the server to know that it is using multicast.

This also gives a reason not to allow RST on *any* NON messages.

12.1: I think it would be much easier to figure these out if you separated out the bit fields of code type and code, and then had sub-registries for request codes, success codes, client error codes, and server error codes.

[Ballot discuss]
Updated based on - 17.

A well-written document and I have a few points to discuss.

Here are the issues (based on my own review and input from Joe Touch and Michael Scharf):

1)  done.

2) done.

3) done.

4) done.

5) done.

6)  done.

7) done.

8) Flow Control/Receiver Buffer
The protocol does not have any real means for the receiver to control the amount of data that is being sent to it. I can understand the attempt to provide a simple protocol, but adding a very basic flow control mechanism will not prohibitively increase the complexity of the protocol, while improving robustness.
The 4.13 "Request Entity Too Large" with a protocol field that indicates the maximum data size would be fixing this.

9) done.

[Ballot discuss]
A well-written document and I have a few points to discuss.

The congestion avoidance mechanisms look ok, but I assume we will get feedback from implementers and deployments on the parameters and mechanisms. It would be good to get this feedback documented at some point.

Here are the issues (based on my own review and input from Joe Touch and Michael Scharf):

1)  done.

2) done.

3) done.

4) done.

5) done.

6) Idempotency  -- done.

7) done.

8) Flow Control/Receiver Buffer
The protocol does not have any real means for the receiver to control the amount of data that is being sent to it. I can understand the attempt to provide a simple protocol, but adding a very basic flow control mechanism will not prohibitively increase the complexity of the protocol, while improving robustness.
The 4.13 "Request Entity Too Large" with a protocol field that indicates the maximum data size would be fixing this.

9) done.

[Ballot discuss]
A well-written document and I have a few points to discuss.

The congestion avoidance mechanisms look ok, but I assume we will get feedback from implementers and deployments on the parameters and mechanisms. It would be good to get this feedback documented at some point.

Here are the issues (based on my own review and input from Joe Touch and Michael Scharf):

1) IPv6 UDP checksum calculation -- fixed.

2) Handling of UDP-lite  -- fixed.



3) Fragmentation of messages -- done.

4) Ensuring no fragmentation with IPv4  -- done.


5) Reaction to network errors that are signalled
I wonder why the draft is not discussing any reaction to network failures signalled through ICMP messages. This relates also to my DISCUSS issue no 4.

6) Idempotency  -- done.


7) Protocol reactions to reserved or prohibited values
Regarding reserved or prohibited values in the IANA section, it would be useful to be clear about what happens when those values are seen. I.e., should they be ignored, generate an error, etc.

8) Flow Control/Receiver Buffer
The protocol does not have any real means for the receiver to control the amount of data that is being sent to it. I can understand the attempt to provide a simple protocol, but adding a very basic flow control mechanism will not prohibitively increase the complexity of the protocol, while improving robustness.
The 4.13 "Request Entity Too Large" with a protocol field that indicates the maximum data size would be fixing this.

9) Handling a wrapping message IDs
According to Section 4.4.:
"The same Message ID MUST NOT be re-used (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2)" with EXCHANGE_LIFETIME of 247s.
By now it is unrealistic that the message ID of 16 bits will wrap around in that time frame, but protocols live long and at some later time it can be possible.
However, the protocol doesn't have any means to detect wrapped message IDs.

[Ballot discuss]
A well-written document and I have a few points to discuss.

The congestion avoidance mechanisms look ok, but I assume we will get feedback from implementers and deployments on the parameters and mechanisms. It would be good to get this feedback documented at some point.

Here are the issues (based on my own review and input from Joe Touch and Michael Scharf):

1) IPv6 UDP checksum calculation -- fixed.

2) Handling of UDP-lite  -- fixed.



3) Fragmentation of messages
The recommendation in Section 4.6 about the path MTU is generally valid only for IPv6. For IPv4, 567 bytes is the safe area to work without fragmentation, though in today WANs 1280 work perfectly, but I am not so sure about the networks envisioned for CoAP. This 576 bytes for IPv4 are mentioned in the implementation note, but deserves text on the same level as for IPv6.

4) Ensuring no fragmentation with IPv4  -- fixed.



5) Reaction to network errors that are signalled
I wonder why the draft is not discussing any reaction to network failures signalled through ICMP messages. This relates also to my DISCUSS issue no 4.

6) Idempotency  -- fixed.


7) Protocol reactions to reserved or prohibited values
Regarding reserved or prohibited values in the IANA section, it would be useful to be clear about what happens when those values are seen. I.e., should they be ignored, generate an error, etc.

8) Flow Control/Receiver Buffer
The protocol does not have any real means for the receiver to control the amount of data that is being sent to it. I can understand the attempt to provide a simple protocol, but adding a very basic flow control mechanism will not prohibitively increase the complexity of the protocol, while improving robustness.
According to Section 2.1, a node can always return a RST if the message cannot be process for whatever reason.
I propose to add an option to the RST message that allows the message receiver to state how much data it is willing to accept from a particular sender or in general (up to the implementation). 

9) Handling a wrapping message IDs
According to Section 4.4.:
"The same Message ID MUST NOT be re-used (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2)" with EXCHANGE_LIFETIME of 247s.
By now it is unrealistic that the message ID of 16 bits will wrap around in that time frame, but protocols live long and at some later time it can be possible.
However, the protocol doesn't have any means to detect wrapped message IDs.

[Ballot discuss]
I'm still worried about 5.10.4:

                                                      The server SHOULD
  return the preferred Content-Format if available.  If the preferred
  Content-Format cannot be returned, then a 4.06 "Not Acceptable"
  SHOULD be sent as a response.

The possibility that a server could potentially not send back a 4.06 seems really problematic from a client perspective. I have no way as a client to say, "I really can only accept format X, and if you can't make format X, I don't want something else", and I have no way to distinguish that from "I would prefer format X, but am willing to take whatever you can give me." For the former, I have to be prepared to throw things away. For the latter, I have to be willing to send two requests, the first with Accept (potentially getting back 4.06), and then a re-request without Accept. Which one of the above are current clients doing? If it's the former, then I suggest making this into an implementation note, and I would even consider getting rid of the 4.06 response code  for this use case, since it is nearly useless, and probably harmful. If it's the latter, then these SHOULDs ought to be MUSTs and the option should be critical so that clients can stop doing that.

[Ballot comment]
By section number:

3.

  Code:  8-bit unsigned integer, split into a 3-bit class (most
      significant bits) and a 5-bit detail (least significant bits),
      documented as c.dd where c is a digit from 0 to 7 for the 3-bit
      subfield and dd are two digits from 00 to 31 for the 5-bit
      subfield.  Indicates if the message carries a request (0.01-0.31)
      or a response (2.00-5.31), or is empty (0.00).  (All other code
      values are reserved.)

I suggest changing the last two sentences above to: "The class can indicate a request (0), a success response (2), a client error response (4), or a server error response (5). (All other class values are reserved.)"

4.1: Personally, I find the word "empty" confusing here. "Null" or "Noop" probably would have been better. If this use is already well understood, it's probably best to define it clearly. Capitalizing "Empty" might help.


4.2/4.3: "Reject" in the sense it is talked about in these sections is an internal state change. That's confusing to me, as the normal sense of the English word implies a party that "hears about" the rejection. (It's hard to me to think of a circumstance where someone or something was "rejected" and only the rejector ever knew about it.) In your use, "silently ignore" is one possible form of rejection. That's just weird.

If you're going to do this, I'd define the term up front. Maybe even capitalize "Reject" wherever you use it.

Either way, in both 4.2 and 4.3, "MUST reject" is probably wrong (since that's an internal state and nothing a protocol requirement is useful for) and "MAY involve sending" is a strange construction.

4.5: I think the MAYs confuse things and might encourage implementers to take that path. Instead of:

  This rule MAY be relaxed in case
  the Confirmable message transports a request that is idempotent (see
  Section 5.1) or can be handled in an idempotent fashion.  Examples
  for relaxed message deduplication:
 
I suggest: "Exceptions to this are when the Confirmable message transports a request that is idempotent (see Section 5.1) or can be handled in an idempotent fashion.  Examples of these exceptions:". Also:

  As a general rule that MAY be
  relaxed based on the specific semantics of a message, the recipient
  SHOULD silently ignore any duplicated Non-confirmable message, and
  SHOULD process any request or response in the message only once.
 
I suggest: "The recipient SHOULD silently ignore any duplicated Non-confirmable message, and SHOULD process any request or response in the message only once, though the specific semantics of the message might dictate an exception."

4.6: I feel like this section is really one big implementation note: Because it is a layer violation, it's not clear to me that any implementer has the ability to figure out much of this. (For example, the idea that an implementer would be willing to -- or even know how to -- set the Do Not Fragment bit or figure out the Path MTU is a bit hopeful.) I have no objection to this section, but it might be better as an implementation note rather than a set of protocol instructions.

5.3.2: Change "the client will likely send a Reset message so it does not receive any more retransmissions" to "the client will send". A client that has lost state that receives what it will see as a random CON message will always send back a Reset.

5.4.6: If it were me, I would have put the NoCacheKey bits in the high four bits of the most significant byte so that you could simply do a <224 test for cache-matching options. I suppose this ship has sailed.

5.5.1: The implementation note notwithstanding, I don't understand why Content-Format is not a SHOULD.

5.7.1:

  a proxy SHOULD be conservative

s/SHOULD/should. There's nothing to implement here.

5.10.5 s/MUST/is. The MUST is not meaningful.

8.1:

  A server SHOULD be aware that a request arrived via multicast, e.g.
  by making use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if
  available.

That SHOULD is not meaningful. It is useful, not required with exceptions (as SHOULD indicates), for the server to know that it is using multicast.

This also gives a reason not to allow RST on *any* NON messages.

12.1: As mentioned regarding section 3 and 5.2 above, I think it would be much easier to figure these out if you separated out the bit fields of code type and code, and then had sub-registries for request codes, success codes, client error codes, and server error codes.

[Ballot comment]

Thanks for addressing my discuss points. I've left the comments
in below from last time, but didn't check 'em against -17.

--- former discuss points

(1) I think you made a change to 5.6 for this but I still
think (now at COMMENT level) that it'd be really good to say
that CoAP is currently well defined only for URI schemes like
coap(s) and http(s) but maybe not others. Basically, you need
a scheme://host:port syntax or else you have to do some more
specification work to get CoAP interop.

(3) You now say "SHOULD use 32 bits of randomness" which
is ok. I think it might be worth adding that CoAP nodes
that might be targetted with many guesses SHOULD also 
detect and react to that.

Text of discuss (3) was:
4.2, last para: this creates an attack that can work
from off-path - just send loads of faked ACKs with guessed
Tokens and some of 'em will be accepted with probability
depending on Token-length and perhaps the quality of the RNG
used by the sender of the CON. That could cause all sorts of
"interesting" application layer behaviour. Why is that ok?
(Or put another way - was this considered and with what
conclusion?) I suspect you need to have text trading off the
Token length versus use of DTLS or else CoAP may end up too
insecure for too many uses. (Note: the attack here is made
worse because the message ID comparison can be skipped.
Removing that "feature" would help a lot here.) 5.3.1's
client "may want to use a non-trivial, randomized token"
doesn't seem to cut it to me. How does this kind of
interaction map to DTLS sessions/epoch? Basically, I'd like
to see some RECOMMENDED handling of token length that would
result in it not being unsafe to connect a CoAP node to the
Internet. (And please note recent instances where 10's of
thousands of insecure devices have been found via probing
the IPv4 address space. These are real attacks.)

(4) 4.4, implementation note - this seems unwise since it
means that once Alice has interacted with Bob, then Bob can
easily guess the message IDs that Alice will use to talk to
Charlie. This is no longer a DISCUSS because you said that
the WG figure its ok and given you say to randomise at
the start (of what?) then its marginal.

--- old comments below, sorta checked against -16

intro, 2nd para: better to not talk about the WG name and
its work really, but about the resulting protocol

intro, last para: more sales pitch language

3: Message ID - with 16 bits that imposes a rate limit on
how often you can send. I don't think that's described and
I'm curious as to whether it'd set to max goodput for CoAP
that'd be way less than otherwise possible with e.g. HTTP.
- I think in a mail Carsten said its 250/second max or
something, I still think this'd be great information to
say explicitly early on in the spec since it might prevent
someone spending a lot of effort before they find out that
CoAP doesn't work for their use-case.

7.1 - what if I want to only do discovery via DTLS? What
does "support" mean for port 5683 then? Carsten said that
you do need to still listen on 5683 even if you only
want to do work on . I'm not so happy about that but
its not DISCUSS level.

12.7 - as it turns out I also don't see why this needs
two ports - the cost is two more bytes for security which
is significantly-enough less than the current cost (in
terms of message size) for security. Am I wrong? Carsten
responded: "yep, that's what we want" and I'm ok with that,
if not convinced.

[Ballot comment]
On 5/20/2013 3:35 PM, Carsten Bormann wrote:
> Spencer,
>
> thank you for this attentive review.
> I have done some of the changes as simple editorial fixes, these are
> marked like [1373] below and can be reviewed in
> http://trac.tools.ietf.org/wg/core/trac/changeset/1373
> (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline).

Hi, Carsten,

Thank you for the quick and careful response.

We've discussed my DISCUSS, so I'm changing my ballot position to YES (but please make Martin happy on his transport-ish DISCUSS :-).

I have a couple of places where I've suggested text that seems clearer to me, but I moved these to COMMENTs on my ballot.

> Grüße, Carsten
>
>          ----------------------------------------------------------------------
>          DISCUSS:
>          ----------------------------------------------------------------------
>
>          Note that I plan to ballot Yes, after we resolve these questions.
>
>          I have three points - the first one is the one I'm most curious about.
>
>          In 4.8.1.  Changing The Parameters
>
>            It is recommended that an
>            application environment use consistent values for these parameters.
>
>          I'm thinking about this in an IOT/M2M context where it's somewhere
>          between inconvenient and impossible to change parameters on all the
>          deployed devices at once. I understand that configuring these parameters
>          is out of scope for the doc, so assume changing the parameters is out of
>          scope as well.
>
> Yes.  The assumption is that implementations better don't start
> changing the parameters until there is a good way to do so.
>
>          If you start deploying new devices into that environment with
>          significantly different parameters, is it more likely that performance
>          would suffer, or that something would break? (I don't care what the
>          answer is, I'd just like for the reader to have one - do you HAVE to get
>          the parameters right the first time, or do you WANT to get them right,
>          but you can deploy new devices with different parameters and let the old
>          devices be removed/replaced over time?)
>
> The answer is different for each parameter and for the direction in
> which you change it.  I don't think we can provide all the definitive
> answers in this document.

For "changing the parameters" above ... I think what you're saying in your response to me is more helpful than the way I read the text in -16. If I'm understanding correctly, the situation is

- the specification doesn't include a way to change parameters without a "flag day", and

- if an application environment uses consistent parameters, everything will work, but

- if an application environment doesn't use consistent parameters, what happens next is out of scope for this specification (and, for extra credit, is unpredictable)

As a COMMENT, I'd be more comfortable if

    It is recommended that an
    application environment use consistent values for these parameters.

continued to say "Operation with inconsistent values in an application environment is outside the scope of this specification", or something like that.

As an aside, also as a COMMENT ... I am now noticing that the specification has "recommended" in lower case. If you were telling me it's "RECOMMENDED = SHOULD = do it this way unless you're sure what you're doing, and if you think you know what you're doing, but you break it, you own it", I'd be more comfortable. That's consistent with the way I read this text in 2119:

3. SHOULD  This word, or the adjective "RECOMMENDED", mean that there
  may exist valid reasons in particular circumstances to ignore a
  particular item, but the full implications must be understood and
  carefully weighed before choosing a different course.

>          This one is on the edge of being a Comment:
>
>          In 5.10.5.  Max-Age
>
>            The value is intended to be current at the time of transmission.
>            Servers that provide resources with strict tolerances on the value of
>            Max-Age SHOULD update the value before each retransmission.
>
>          Will servers know that resources they serve have strict
>          tolerances?
>
> Yes.  It is typically in the nature of a resource to be replaced
> periodically (e.g., the ECB exchange rate -- this has a very specific
> Max-Age) or be on a more unpredictable basis.  In the CoRE model,
> servers generally should be aware about the nature of the resources
> they are serving.
>
>          The
>          answer may be "yes", I'm just asking. If not, I'm wondering if this
>          should be a MUST.
>
> Because both the condition on the SHOULD and the desired behavior are
> very much local matter, a MUST won't have a much different outcome
> here.  Maybe the SHOULD should be turned into a non-RFC 2119
> implementation guidance recommendation.

Your explanation was very helpful to me. I'm fine with SHOULD as 2119 language here - that matches what I'm hearing you say.

>          This one is on the edge of being a comment:
>
>          In 7.2.  Resource Discovery
>
>            The discovery of resources offered by a CoAP endpoint is extremely
>            important in machine-to-machine applications where there are no
>            humans in the loop and static interfaces result in fragility.  A CoAP
>            endpoint SHOULD support the CoRE Link Format of discoverable
>            resources as described in [RFC6690].
>
>          Is it obvious that this is a SHOULD? Is CoRE Link Format necessary for
>          resource discovery, or can you also accomplish this with humans if
>          they're in the loop? I'm just trying to wrap my head around "it's
>          extremely important but implementations might not do it".
>
> This is more of a policy statement, a statement of expectation: If you
> want to be part of the CoRE ecosystem, do CoAP and do RFC 6690,
> because that will maximize interoperability.  So this may be another
> SHOULD abuse.  (But it does impact interoperability!)

This is very helpful. What I wasn't getting was whether there was any way other than CoRE Link Format to discover resources when there are no humans in the loop.

Again, as a COMMENT, I'm reading this response as "SHOULD support the CoRE Link Format of discoverable resources as described in [RFC6690] if there are no humans in the loop, to maximize interoperability". Am I getting that right?

And if this is a statement of expectation, I'm OK with SHOULD, if the working group thinks that's appropriate.

>          ----------------------------------------------------------------------
>          COMMENT:
>          ----------------------------------------------------------------------
>
>          I think this specification is well-written, it's important, and a lot of
>          people will need to read it - that's why I'm being picky on comments.
>
>          Martin already has a DISCUSS about some of the more transport-ish topics
>          (support for UDP-lite, etc.). I'm sympathetic, but didn't restate them.
>          If Martin is happy, I'll be happy.
>
>          In this text:
>            Constrained networks like
>            6LoWPAN support the expensive fragmentation of IPv6 packets into
>            small link-layer frames.
>
>          Is "support" the right word here? I'm not understanding "support the
>          expensive fragmentation".
>
> 6LoWPAN has a mechanism for ("supports") sending IPv6 packets that are
> larger than the link layer packet size.  This mechanism is expensive
> in the sense that it reduces performance similar to the way
> fragmentation often does.

So I should be reading this as something like "Constrained networks like 6LoWPAN support the fragmentation of IPv6 packets into small link-layer frames, but this mechanism is expensive in that it reduces performance"?

>
>          In this text:
>            Although CoAP could be used for
>            compressing simple HTTP interfaces
>
>          Is "compressing ... interfaces" the right way to say this?
>
> No.  [1385]

Ack.

>          I've seen other reviewers mention "short messages" in "CoAP is based on
>          the exchange of short messages", but it may also be worth clearly
>          distinguishing "short message" from "SMS" ("short message service") - as
>          I understand it, the two phrases have nothing in common, but they are
>          both used in the document (at the beginning of Section 3, and even in the
>          same paragraph) without qualification.
>
> Oh.  Good catch.  [1373]

Ack.

>            Response codes
>            correspond to a small subset of HTTP response codes with a few CoAP
>            specific codes added, as defined in Section 5.9.
>
>          I get this, but I'm wondering if it's worth thinking about whether these
>          similar but unrelated namespaces can semi-collide (if HTTP is extended to
>          include a 328 response code, is it OK for CoAP to define a 3.28 response
>          code that means nothing like what HTTP 328 means?) Given that 404 and
>          4.04 are similar, for example, I'd expect some implementers to guess what
>          less common CoAP response codes are, based on HTTP response codes, rather
>          than check carefully. That's an obscure comment, but I thought I should
>          ask.
>
> We already deviate from a strict one-to-one correspondence with HTTP
> (e.g., we have a 2.05 where HTTP uses 200).  So "correspond" may
> indeed be too strong.  [1386]

Ack.

>          In 6.4.  Decomposing URIs into Options, is "fail this algorithm" clear?
>          It might be a term of art for HTTP folk, but I'm not familiar with it.
>
>            4.  If |url| has a  component, then fail this algorithm.
>
> Indeed, this is hixiefied speak (right out of text in the versions of
> the websockets spec that were current when we wrote this, and still in
> HTML5).  It might be shorter to just say "fail", but the intent is not
> for the node to blow up in smoke, but to specifically fail the
> algorithm defined in this section (as explained in the introduction to
> 6.4).

No, I think you're doing this right (thanks for the clue!).

>          In 8.1.  Messaging Layer
>
>            When a server is aware that a request arrived via multicast, it MUST
>            NOT return a RST in reply to NON.  If it is not aware, it MAY return
>            a RST in reply to NON as usual.
>
>          Doesn't this tell me that the MUST NOT is not required for
>          interoperability? I'm only quibbling about the use of 2119
>          language.
>
> This hand-waving is a reaction on a specific restriction of the POSIX API
> that I don't wish on anyone.  "Please avoid using RFC3542-challenged
> environments.  But if you have to (.NET?)..."
>
>          On a
>          related point, if there was a sentence that started out "to keep Bad
>          Thing X from happening, ..." that would be helpful.
>
> Good point.  [1387]

Ack.

>          There's similar language in 8.2.  Request/Response Layer
>
>            When a server is aware that a request arrived via multicast, the
>            server MAY always ignore the request, in particular if it doesn't
>            have anything useful to respond (e.g., if it only has an empty
>            payload or an error response).
>
>          but MAY is pretty weak anyway (maybe "can always ignore the request", to
>          avoid the 2119 question?).
>
> This is trying to say that the peer has to be able to cope with the
> "MAY"-type behaviour described, so it does affect interoperability and
> I think 2119 language is appropriate here.

I understand why you're using 2119 language now. I'm not sure I understand how the requirement for the peer is different from either the request or response getting lost.

I'm reading the spec as saying that multicast requests are sent as non-confirmable at the messaging layer, so if there's no confirmation at the messaging layer and no response from the server at the request/response layer, does the peer see any difference between hearing nothing back because something was lost, and hearing nothing back because the server had nothing to say?

>          In 11.3.  Risk of amplification
>
>            This is particularly a problem in nodes that enable NoSec access,
>            that are accessible from an attacker and can access potential victims
>            (e.g. on the general Internet), as the UDP protocol provides no way
>            to verify the source address given in the request packet.  An
>            attacker need only place the IP address of the victim in the source
>            address of a suitable request packet to generate a larger packet
>            directed at the victim.  Such large amplification factors SHOULD NOT
>            be done in the response if the request is not authenticated.
>
>          I don't understand what the SHOULD NOT means in practice. Is this saying
>          the server shouldn't return large resources for NoSec requests (whatever
>          "large" means), or ? If this is saying the same thing as the text on
>          using "slicing/blocking mode" two paragraphs, down, it would be clearer
>          to combine these points in a single paragraph.
>
> Well, it is leading into it, and you just have to read one more
> paragraph before it comes...  (I'm still optimistic that at least some
> implementers read a whole section before writing code.)
> [ceterum censeo deploy BCP38...]

My apologies for not being clearer in my comment.

I'm looking at this text:

  This is particularly a problem in nodes that enable NoSec access,
  that are accessible from an attacker and can access potential victims
  (e.g. on the general Internet), as the UDP protocol provides no way
  to verify the source address given in the request packet.  An
  attacker need only place the IP address of the victim in the source
  address of a suitable request packet to generate a larger packet
  directed at the victim.  Such large amplification factors SHOULD NOT
  be done in the response if the request is not authenticated.

[annoyingly distracting paragraph deleted here]

  A CoAP server can reduce the amount of amplification it provides to
  an attacker by using slicing/blocking modes of CoAP
  [I-D.ietf-core-block] and offering large resource representations
  only in relatively small slices.  E.g., for a 1000 byte resource, a
  10-byte request might result in an 80-byte response (with a 64-byte
  block) instead of a 1016-byte response, considerably reducing the
  amplification provided.

and I'm not seeing

- the SHOULD NOT, which is conditional on whether the request is authenticated, and

- the subsequent suggestion to use slicing/blocking, which is not conditional on authentication, seamlessly hooked together.

Is the intention that the recommendation to use slicing/blocking be conditional on authentication, or should the server always use slicing/blocking whether the request is authenticated or not?

Is that clearer? ("writing text is hard" :-)

Spencer

[Ballot comment]
I lacked some time to review the draft details. However, after a discussion with Joel Jaeggli, and with the OPS DIR review from Mehmet, I trust that the OPS aspects have been taken care of.

[Ballot comment]
Thank you for this important work and well written specification. While there are aspects that I would personally have done differently and some fine-tuning of the spec could continue, I believe the document is ready to move to an RFC. I also believe it that is a much-awaited spec and very useful to the Internet community in its current state.

I do agree with some of the points raised in other reviews, and those need to be addressed.

I did have one specific additional suggestion worth bringing up here. Dan Romascanu did a Gen-ART review and raised the issue that the parameter changes discussed in S4.8.1 are security sensitive, i.e., changes in the parameters may cause security/denial-of-service issues. This should be noted somewhere in the S11. I'd make a brief observation that it is security sensitive and should be addressed in any system that allows configuration of these parameters.

Here's what Dan wrote:

3. Section 4.8 defines a number of CoAP protocol parameters and derived parameters that according to 4.8.1 may be changed. Some of these parameters have limitations and their changes may affect the basic functionality of the nodes, the interaction between nodes or between nodes and servers, as well as the functioning in constrained environments. However there is no risk analysis in Section 11 (Security Considerations) about the threats related to mis-configuration of the modes and un-appropriate or malevolent changes in these parameters, and recommendations of security counter-measures on this respect.

[Ballot comment]
Thank you for this important work and well written specification. While there are aspects that I would personally have done differently, I believe the document is ready to move to an RFC. I also believe it that is a much-awaited spec and very useful to the Internet community.

I do agree with some of the points raised in other reviews, and those need to be addressed.

I did have one specific additional suggestion worth bringing up here. Dan Romascanu did a Gen-ART review and raised the issue that the parameter changes discussed in S4.8.1 are security sensitive, i.e., changes in the parameters may cause security/denial-of-service issues. This should be noted somewhere in the S11. I'd make a brief observation that it is security sensitive and should be addressed in any system that allows configuration of these parameters.

Here's what Dan wrote:

3. Section 4.8 defines a number of CoAP protocol parameters and derived parameters that according to 4.8.1 may be changed. Some of these parameters have limitations and their changes may affect the basic functionality of the nodes, the interaction between nodes or between nodes and servers, as well as the functioning in constrained environments. However there is no risk analysis in Section 11 (Security Considerations) about the threats related to mis-configuration of the modes and un-appropriate or malevolent changes in these parameters, and recommendations of security counter-measures on this respect.

[Ballot discuss]
Thanks for a clear draft.  Makes things so much easier to review.  Just want to discuss a couple of things before moving to yes (hopefully).

0) s9.1.3.2: Before I get in to the nitty-gritty of the specific concerns I have with DTLS use of Raw Public Keys, I have to ask whether use of the DTLS client_certificate_url extension was considered?  If raw public keys is just about size then that'd work wouldn't it.  If you're about dumping processing of paths, then that's another thing.

1) s9.1.3.2.1: What's really hung me up on this draft is the raw public key option.  Primarily, the TLS draft is not quite done yet; I'm still in discussions with the authors.  Two issues that affect your draft:

a)  By draft-ietf-tls-oob-pubkey taking a pass on specifying all of the ways an identity can be bound to a public key, it leaves it up to the application to specify that mechanism.  This binding is important because you can't get peer authentication without it; I'm really worried that if this mode gets widely deployed people will say they have "DTLS security" but few (if any) are actually do the work necessary to bind the identity to the key.    So, you specify that binding in the provisioning section (good ;) but I want to make sure that it's clear who's doing what to whom:

i) s9.1.3.2.1: For machines it's perfect appropriate to generate the key and install it because we doubt it'll be able to do that well enough right (i.e., crummy entropy sources)?  I want to make it clear that that's been done by the manufacturer.

In this mode the device has an asymmetric key pair but without an
X.509 certificate (called a raw public key).

to:

In this mode the device has an asymmetric key pair but without an
X.509 certificate (called a raw public key); the asymmetric key
paid is generated by the manufacturer and installed on the device.

ii) s9.1.3.2.1: This draft does that binding using Stephen's naming thing with hashes, but I want to make sure that it's clear who is identifier, it now says:

  An identifier is calculated
  from the public key as described in Section 2 of [RFC6920].

Is it the

  An identifier is calculated by the endpoint from
  from the public key as described in Section 2 of [RFC6920].

b) draft-ietf-tls-oob-pubkey is likely to take a pass on specifying a mechanism for revoking the public key and identity binding.  Note that ocsp-/multi-ocsp staplingwon't work because there's no way to request information about a certificate that you don't have information about.  I'm not trying to gold plate the security mechanism here but I think we need some words on how revocation for this mode will be handled.  However, I suspect you'll want to use the ACLs....there's a mechanism for including ACLs during provisioning but is there a way to update them later?  What happens if a new node gets installed or removed?  Is there a requirement for ACLs to be supported; the text has a SHOULD but that seems to be about ACL provisioning support not ACL support.

2) s9.1.3.2: Another TLS-related issue:

When referring to TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 please include the MTI curve(s).  Ever so glad that conservative curves are being used.  In the following, I assumed you'd want the one must and the two mays but I can understand if you don't.  I'd argue you do have algorithm agility with DTLS so you could get away with just the MUST ad not the MAYs.

Unrelated to you, but I thought I'd let you know about: the curve requirements will almost certainly be removed from the mcgrew draft at my direction because no other D/TLS EC cipher suite specifies an MTI curve.  There's support for conservative curves, but not enough interest in starting to add MTI curves instead of the application picking them.  Note the Zigbee folks also point to the mcgrew draft but it seems their drafts already include the curves so we ought to be good to go on both fronts.

I think we need to be clear that choosing this particular cipher suite that it means an implementation needs to support the extensions defined in RFC 4492 - or if it doesn't.  I'm assuming you want it to so I'm going to propose some tweaking:

OLD:

  Implementations in
  RawPublicKey mode MUST support the mandatory to implement cipher
  suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in
  [I-D.mcgrew-tls-aes-ccm-ecc], [RFC5246], [RFC4492].

NEW:

  Implementations in
  RawPublicKey mode MUST support the mandatory to implement
  cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified
  in [I-D.mcgrew-tls-aes-ccm-ecc].  The key used MUST be
  ECDSA-capable; the curve secp256r1 MUST
  be supported, and the curves secp384r1 and secp521r1 MAY be
  supported [RFC4492]; these curves are equivalent to the
  NIST P-256, P-384, and P-521 curves. Implementations MUST
  use/support (?) the Supported Elliptic Curves Extension and
  Supported Point Format extensions [RFC4492]; the uncompressed
  point format MUST be supported; [RFC6090] can be used as an
  implementation method.

The mcgrew draft had the following instead of the last sentence so I'm open to whichever but I think something about the folllowing needs to be added:

o The uncompressed point format MUST be supported.  Other point
  formats MAY be used.
o The client SHOULD offer the elliptic_curves extension and the
  server SHOULD expect to receive it.
o The client MAY offer the ec_point_formats extension, but the
  server need not expect to receive it.
o [RFC6090] MAY be used as an implementation method.

And then, I think we need to specify how the MTI would look: namely by adding the following on to the end of the paragraph.

  When the mandatory to implement DTLS cipher suite and curve and
  used the SubjectPublicKeyInfo indicates an algorithm of
  id-ecPublicKey with the namedCurves object identifier set to
  secp256r1 [RFC5480].  If secp384r1 or secp521r1 are used the
  those object identifiers [RFC5480] are included instead.
 
That way everybody knows what values go in the SPKI of the oob-pubkey draft.  Note they tried to change that field recently and I had to remind them not to.

3) s9:  I know we're all about be liberal in what you accept, but in this context that might be challengeing; this bit:

... all modes of DTLS may not be
applicable.  Some DTLS cipher suites can add significant
implementation complexity as well as some initial
handshake overhead
needed when setting up the security association.

Made me wonder whether you considered which other DTLS extensions might be useful in addition to the EC ones and SNI as well as what extensions should be profiled out?  For example, max_fragment_length looks pretty useful in this context as well as certificate_url.  But does heartbeat make any sense?

4) s8: I think you need to make it pretty darn clear in s8 that multi-cast is an unsecured "mode" as specified in this document.  It's kind of buried in s9.

5) s9.1.2: (worried about a DoS attack) Do you mean that responses to secured-CoAP messages returned unsecured are silently discarded/ignored or rejected and then that kicks off an error code response?

6) s9.1.3.1: Did you consider whether there should be an application profile for the psk_identity_hint (see Section 5 [RFC4279]) - i.e., is there a standard format for CoAP that should be defined?

7) s9.1.3.3: When you say "the Certificate must be validated" I'm just checking that you're think there's going to be a certificate chain?  If there's no chain the validation rules in 5280 don't apply.

8) s9: If you're going to allow more than two entities to share the preshared keys I think it's worth pointing out you really can't get peer authentication with either CoAP or DTLS.  The description in s9 and elsewhere seems to imply that more than one peer might share the same key.

9) Either in s9 or s11 we need to say something about devices with bad entropy sources not bothering to make keys because they won't be of any use.  If they've got bad entropy sources the manufacturer or whoever should be making the keys.

[Ballot comment]
0) s1.2: Is the "CoAP-to-CoAP proxy" definition missing?  s5.7 refers to s1.2 for the definition but that term is not in s1.2.

1) s7.1: I think this is munged:

  A server is discovered by a client by the client knowing or

2) s9: In the NoSec option is worth also pointing to the link layer security (IEEE 802.15.4)?

3) s9.1: Because there's no s9.2 (I assume that might have been an IPsec-secured CoAP section at one point) you can drop the header.

4) s9.1.3.3: The 1st paragraph is about certificates but it only indicates the TLS cipher suite needed to be supported.  It should say what values go in the certificate to support the cipher suite.  Basically, need to point to RFC 5480 and say include values X.  I'd suggest:

OLD:

Implementations in Certificate Mode MUST support the mandatory to
implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as
specified in [RFC5246].

NEW (adding some more stuff + references):

Implementations in Certificate Mode MUST support the mandatory to
implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as
specified in [RFC5246].  Namely, the certificate includes a
SubjectPublicKeyInfo that indicates an algorithm of id-ecPublicKey
with namedCurves secp256r1, secp384r1, or secp521r1 [RFC5480];
the public key format is uncompressed [RFC5480]; if included
the key usage extension indicates digitalSignature.

5) s9.1.3.3: Going with the thought that there's a chain, we also need to say what algorithms can be used to sign the certificate.  I assume we want the use same algorithm for both the TLS_ECDHE_PSK and TLS_ECDHE_ECDSA certificate so text is needed at the end of the paragraph to indicate that:

Certificates MUST be signed with ECDSA [RFC6090], and it MUST
use SHA-256, SHA-384, or SHA-512 [SHS].  It is RECOMMENDED that
the curve match the hash function's output matches the length of
the elliptic curve order.

On the fist bit: You could lock it down to just one curve if that's what you decide to do based on comment #5. 

On the second bit: if the curve and the hash size line up then you can use RFC 6090 and we - really - want that.  Not sure if the above is too cryptic ;)

6) s9.1.3.3: Maybe a typo MUST instead of must:

If there is no
SubjectAltName in the certificate, then the Authoritative Name must
match the CN found in the certificate using the matching rules
defined in [RFC2818] with the exception that certificates with
wildcards are not allowed.

7) s9.1.3.3: r/further work./further study.

[Ballot discuss]
A well-written document and I have a few points to discuss.

The congestion avoidance mechanisms look ok, but I assume we will get feedback from implementers and deployments on the parameters and mechanisms. It would be good to get this feedback documented at some point.

Here are the issues (based on my own review and input from Joe Touch and Michael Scharf):

1) IPv6 UDP checksum calculation
It is not clear if zero UDP checksums are permitted or not permitted with COAP.?
(UDP zero checksums:
https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/)
That should be specified.

2) Handling of UDP-lite
Can UDP-lite (RFC 3828) be used or cannot be used in conjunction with CoAP?


3) Fragmentation of messages
The recommendation in Section 4.6 about the path MTU is generally valid only for IPv6. For IPv4, 567 bytes is the safe area to work without fragmentation, though in today WANs 1280 work perfectly, but I am not so sure about the networks envisioned for CoAP. This 576 bytes for IPv4 are mentioned in the implementation note, but deserves text on the same level as for IPv6.

4) Ensuring no fragmentation with IPv4
The implementation note in Section 4.6 states that for IPv4 it is 'harder to ensure that there is no IP fragmentation'. This neglects the possibility of using the Don't Fragment (DF) flag in the IPv4 header and also that there is possibly feedback from a node enroute that the MTU is too big if the DF flag is set, i.e., by means of an ICMP error message.
Should there be any recommendation or protocol machinery to deal with path probing? E.g., referencing RFC 4821 (PMTUD).


5) Reaction to network errors that are signalled
I wonder why the draft is not discussing any reaction to network failures signalled through ICMP messages. This relates also to my DISCUSS issue no 4.

6) Idempotency
done.

7) Protocol reactions to reserved or prohibited values
Regarding reserved or prohibited values in the IANA section, it would be useful to be clear about what happens when those values are seen. I.e., should they be ignored, generate an error, etc.

8) Flow Control/Receiver Buffer
The protocol does not have any real means for the receiver to control the amount of data that is being sent to it. I can understand the attempt to provide a simple protocol, but adding a very basic flow control mechanism will not prohibitively increase the complexity of the protocol, while improving robustness.
According to Section 2.1, a node can always return a RST if the message cannot be process for whatever reason.
I propose to add an option to the RST message that allows the message receiver to state how much data it is willing to accept from a particular sender or in general (up to the implementation). 

9) Handling a wrapping message IDs
According to Section 4.4.:
"The same Message ID MUST NOT be re-used (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2)" with EXCHANGE_LIFETIME of 247s.
By now it is unrealistic that the message ID of 16 bits will wrap around in that time frame, but protocols live long and at some later time it can be possible.
However, the protocol doesn't have any means to detect wrapped message IDs.

[Ballot comment]
I think this specification is well-written, it's important, and a lot of people will need to read it - that's why I'm being picky on comments.

Martin already has a DISCUSS about some of the more transport-ish topics (support for UDP-lite, etc.). I'm sympathetic, but didn't restate them. If Martin is happy, I'll be happy.

In this text:
  Constrained networks like
  6LoWPAN support the expensive fragmentation of IPv6 packets into
  small link-layer frames.

Is "support" the right word here? I'm not understanding "support the expensive fragmentation".

In this text:
  Although CoAP could be used for
  compressing simple HTTP interfaces

Is "compressing ... interfaces" the right way to say this?

I've seen other reviewers mention "short messages" in "CoAP is based on the exchange of short messages", but it may also be worth clearly distinguishing "short message" from "SMS" ("short message service") - as I understand it, the two phrases have nothing in common, but they are both used in the document (at the beginning of Section 3, and even in the same paragraph) without qualification.

  Response codes
  correspond to a small subset of HTTP response codes with a few CoAP
  specific codes added, as defined in Section 5.9.

I get this, but I'm wondering if it's worth thinking about whether these similar but unrelated namespaces can semi-collide (if HTTP is extended to include a 328 response code, is it OK for CoAP to define a 3.28 response code that means nothing like what HTTP 328 means?) Given that 404 and 4.04 are similar, for example, I'd expect some implementers to guess what less common CoAP response codes are, based on HTTP response codes, rather than check carefully. That's an obscure comment, but I thought I should ask.

In 6.4.  Decomposing URIs into Options, is "fail this algorithm" clear? It might be a term of art for HTTP folk, but I'm not familiar with it.

  4.  If |url| has a  component, then fail this algorithm.

In 8.1.  Messaging Layer

  When a server is aware that a request arrived via multicast, it MUST
  NOT return a RST in reply to NON.  If it is not aware, it MAY return
  a RST in reply to NON as usual.

Doesn't this tell me that the MUST NOT is not required for interoperability? I'm only quibbling about the use of 2119 language. On a related point, if there was a sentence that started out "to keep Bad Thing X from happening, ..." that would be helpful.

There's similar language in 8.2.  Request/Response Layer

  When a server is aware that a request arrived via multicast, the
  server MAY always ignore the request, in particular if it doesn't
  have anything useful to respond (e.g., if it only has an empty
  payload or an error response).

but MAY is pretty weak anyway (maybe "can always ignore the request", to avoid the 2119 question?).

In 11.3.  Risk of amplification

  This is particularly a problem in nodes that enable NoSec access,
  that are accessible from an attacker and can access potential victims
  (e.g. on the general Internet), as the UDP protocol provides no way
  to verify the source address given in the request packet.  An
  attacker need only place the IP address of the victim in the source
  address of a suitable request packet to generate a larger packet
  directed at the victim.  Such large amplification factors SHOULD NOT
  be done in the response if the request is not authenticated.

I don't understand what the SHOULD NOT means in practice. Is this saying the server shouldn't return large resources for NoSec requests (whatever "large" means), or ? If this is saying the same thing as the text on using "slicing/blocking mode" two paragraphs, down, it would be clearer to combine these points in a single paragraph.

[Ballot discuss]
Note that I plan to ballot Yes, after we resolve these questions.

I have three points - the first one is the one I'm most curious about.

In 4.8.1.  Changing The Parameters

  It is recommended that an
  application environment use consistent values for these parameters.

I'm thinking about this in an IOT/M2M context where it's somewhere between inconvenient and impossible to change parameters on all the deployed devices at once. I understand that configuring these parameters is out of scope for the doc, so assume changing the parameters is out of scope as well.

If you start deploying new devices into that environment with significantly different parameters, is it more likely that performance would suffer, or that something would break? (I don't care what the answer is, I'd just like for the reader to have one - do you HAVE to get the parameters right the first time, or do you WANT to get them right, but you can deploy new devices with different parameters and let the old devices be removed/replaced over time?)

This one is on the edge of being a Comment:

In 5.10.5.  Max-Age

  The value is intended to be current at the time of transmission.
  Servers that provide resources with strict tolerances on the value of
  Max-Age SHOULD update the value before each retransmission.

Will servers know that resources they serve have strict tolerances? The answer may be "yes", I'm just asking. If not, I'm wondering if this should be a MUST.

This one is on the edge of being a comment:

In 7.2.  Resource Discovery

  The discovery of resources offered by a CoAP endpoint is extremely
  important in machine-to-machine applications where there are no
  humans in the loop and static interfaces result in fragility.  A CoAP
  endpoint SHOULD support the CoRE Link Format of discoverable
  resources as described in [RFC6690].

Is it obvious that this is a SHOULD? Is CoRE Link Format necessary for resource discovery, or can you also accomplish this with humans if they're in the loop? I'm just trying to wrap my head around "it's extremely important but implementations might not do it".

[Ballot comment]
I think this specification is well-written, it's important, and a lot of people will need to read it - that's why I'm being picky on comments.

Martin already has a DISCUSS about some of the more transport-ish topics (support for UDP-lite, etc.). I'm sympathetic, but didn't restate them. If Martin is happy, I'll be happy.

In this text:
  Constrained networks like
  6LoWPAN support the expensive fragmentation of IPv6 packets into
  small link-layer frames.

Is "support" the right word here? I'm not understanding "support the expensive fragmentation".

In this text:
  Although CoAP could be used for
  compressing simple HTTP interfaces

Is "compressing ... interfaces" the right way to say this?

I've seen other reviewers mention "short messages" in "CoAP is based on the exchange of short messages", but it may also be worth clearly distinguishing "short message" from "SMS" ("short message service") - as I understand it, the two phrases have nothing in common, but they are both used in the document (at the beginning of Section 3, and even in the same paragraph) without qualification.

  Response codes
  correspond to a small subset of HTTP response codes with a few CoAP
  specific codes added, as defined in Section 5.9.

I get this, but I'm wondering if it's worth thinking about whether these similar but unrelated namespaces can semi-collide (if HTTP is extended to include a 328 response code, is it OK for CoAP to define a 3.28 response code that means nothing like what HTTP 328 means?) Given that 404 and 4.04 are similar, for example, I'd expect some implementers to guess what less common CoAP response codes are, based on HTTP response codes, rather than check carefully. That's an obscure comment, but I thought I should ask.

In 6.4.  Decomposing URIs into Options, is "fail this algorithm" clear? It might be a term of art for HTTP folk, but I'm not familiar with it.

  4.  If |url| has a  component, then fail this algorithm.

In 8.1.  Messaging Layer

  When a server is aware that a request arrived via multicast, it MUST
  NOT return a RST in reply to NON.  If it is not aware, it MAY return
  a RST in reply to NON as usual.

Doesn't this tell me that the MUST NOT is not required for interoperability? I'm only quibbling about the use of 2119 language. On a related point, if there was a sentence that started out "to keep Bad Thing X from happening, ..." that would be helpful.

There's similar language in 8.2.  Request/Response Layer

  When a server is aware that a request arrived via multicast, the
  server MAY always ignore the request, in particular if it doesn't
  have anything useful to respond (e.g., if it only has an empty
  payload or an error response).

but MAY is pretty weak anyway (maybe "can always ignore the request", to avoid the 2119 question?).

In 11.3.  Risk of amplification

  This is particularly a problem in nodes that enable NoSec access,
  that are accessible from an attacker and can access potential victims
  (e.g. on the general Internet), as the UDP protocol provides no way
  to verify the source address given in the request packet.  An
  attacker need only place the IP address of the victim in the source
  address of a suitable request packet to generate a larger packet
  directed at the victim.  Such large amplification factors SHOULD NOT
  be done in the response if the request is not authenticated.

I don't understand what the SHOULD NOT means in practice. Is this saying the server shouldn't return large resources for NoSec requests (whatever "large" means), or ? If this is saying the same thing as the text on using "slicing/blocking mode" two paragraphs, down, it would be clearer to combine these points in a single paragraph, or otherwise describe "large amplification factors SHOULD NOT be done".

[Ballot comment]
Overall, this is a very nicely written specification.  Thanks! 

In Section 2.2., are requests and responses in 1-1 correspondence?  Or can a single request receive more than one response?

In Section 3, why is version number 1 and not 0?  What's the plan here, do we get 3 or 4 versions out of this?

In Section 4.3, would it make sense to have something stronger than MAY for cases where future messages are likely to be screwed up, e.g., where CoAP syntax is malformed?  (A "STFU RST"?)

From Section 4.2 and 4.3, I generated a table mapping message types to request/response/empty:
            CON NON ACK RST
Request    X  X  ?  !
Response    X  X  X  !
Empty      !  !  X  X   
Might be helpful to include something like that as a summary.  This might be a bad idea, but: Did the WG consider allowing an ACK to contain a request?  In the case where a CON contains a response and the client wants to send another request, it would save a message to put the request in the ACK to the response.

[Ballot discuss]

I will (still:-) end up balloting yes for his.
Just one DISCUSS point remaining.

(1) Cleared, but see comment below

(2) Cleared.

(3) Cleader, but see comment below.

(4) Cleared, but see comment below.

(5) Cleared.

(6) Cleared.

(7) Cleared.

(8) Cleared.

(9) Cleared.

(10) 10.1 - what does https mean here? If it means that
the request/response are in clear between the source and
proxy and then encrypted then a) you really really need to
say that clearly and b) why is that even acceptable and c)
what if the destination resource requires client auth? It
just seems broken to pretend to use https this way. Going
via a cross-proxy breaks security.  Similarly, what does
coaps mean in 10.2? We had some mail exchanges about that,
but I'm not sure I'm ok with the outcome so I'd like to
DISCUSS this some more. (And did any of that get into
-16? Not sure.)

[Ballot comment]

--- former discuss points

(1) I think you made a change to 5.6 for this but I still
think (now at COMMENT level) that it'd be really good to say
that CoAP is currently well defined only for URI schemes like
coap(s) and http(s) but maybe not others. Basically, you need
a scheme://host:port syntax or else you have to do some more
specification work to get CoAP interop.

(3) You now say "SHOULD use 32 bits of randomness" which
is ok. I think it might be worth adding that CoAP nodes
that might be targetted with many guesses SHOULD also 
detect and react to that.

Text of discuss (3) was:
4.2, last para: this creates an attack that can work
from off-path - just send loads of faked ACKs with guessed
Tokens and some of 'em will be accepted with probability
depending on Token-length and perhaps the quality of the RNG
used by the sender of the CON. That could cause all sorts of
"interesting" application layer behaviour. Why is that ok?
(Or put another way - was this considered and with what
conclusion?) I suspect you need to have text trading off the
Token length versus use of DTLS or else CoAP may end up too
insecure for too many uses. (Note: the attack here is made
worse because the message ID comparison can be skipped.
Removing that "feature" would help a lot here.) 5.3.1's
client "may want to use a non-trivial, randomized token"
doesn't seem to cut it to me. How does this kind of
interaction map to DTLS sessions/epoch? Basically, I'd like
to see some RECOMMENDED handling of token length that would
result in it not being unsafe to connect a CoAP node to the
Internet. (And please note recent instances where 10's of
thousands of insecure devices have been found via probing
the IPv4 address space. These are real attacks.)

(4) 4.4, implementation note - this seems unwise since it
means that once Alice has interacted with Bob, then Bob can
easily guess the message IDs that Alice will use to talk to
Charlie. This is no longer a DISCUSS because you said that
the WG figure its ok and given you say to randomise at
the start (of what?) then its marginal.

--- old comments below, sorta checked against -16

intro, 2nd para: better to not talk about the WG name and
its work really, but about the resulting protocol

intro, last para: more sales pitch language

3: Message ID - with 16 bits that imposes a rate limit on
how often you can send. I don't think that's described and
I'm curious as to whether it'd set to max goodput for CoAP
that'd be way less than otherwise possible with e.g. HTTP.
- I think in a mail Carsten said its 250/second max or
something, I still think this'd be great information to
say explicitly early on in the spec since it might prevent
someone spending a lot of effort before they find out that
CoAP doesn't work for their use-case.

7.1 - what if I want to only do discovery via DTLS? What
does "support" mean for port 5683 then? Carsten said that
you do need to still listen on 5683 even if you only
want to do work on . I'm not so happy about that but
its not DISCUSS level.

12.7 - as it turns out I also don't see why this needs
two ports - the cost is two more bytes for security which
is significantly-enough less than the current cost (in
terms of message size) for security. Am I wrong? Carsten
responded: "yep, that's what we want" and I'm ok with that,
if not convinced.

in tracker
IANA Actions - YES

NOTE: This revised review is based on a new version (-16) of the draft
document.

We have a question about the IANA Considerations section of this document.

We understand that, upon approval of this document, there are several actions which we must complete.

First, a new high-level registry will be created in the IANA Matrix, located at:

http://www.iana.org/numbers.html

This will be called the "CoAP Codes" registry and will contain a number of subregistries.

QUESTION -> Does the proposed URL "http://www.iana.org/assignments/core-parameters" look okay?  Please confirm the URL for this new registry
"CoAP Codes".

Values in the registry and its subregistries are eight-bit values notated as three decimal digits c.dd separated by a period between the first and the second digit; the first digit c is between 0 and 7 and denotes the code class; the second and third digit dd denote a decimal number between 00 and 31 for the detail.

All values are assigned by sub-registries according to the following ranges:

0.00 Indicates an empty message (see Section 4.1 of [ RFC-to-be ]).

0.01-0.31 Indicates a request. Values in this range are assigned by the "CoAP Method Codes" sub-registry (see Section 12.1.1 of [ RFC-to-be ]).

1.00-1.31 Reserved

2.00-5.31 Indicates a response. Values in this range are assigned by the "CoAP Response Codes" sub-registry (see Section 12.1.2 of [ RFC-to-be ]).

6.00-7.31 Reserved

Second, a new subregistry of the CoAP Codes registry will be created called the CoAP Method Codes subregistry. Maintenance of the new subreigstry is through IETF Review or IESG Approval as defined by RFC5226. There are initial registrations in the new subregistry as follows:

Code: 0.01
Name: GET
Reference: [ RFC-to-be ]

Code: 0.02
Name: POST
Reference: [ RFC-to-be ]

Code: 0.03
Name: PUT
Reference: [ RFC-to-be ]

Code: 0.04
Name: DELETE
Reference: [ RFC-to-be ]

All other Method Codes are to be marked "Unassigned."

Third, a new subregistry of the CoAP Codes registry will be created called the CoAP Response Codes subregistry. Maintenance of the new subreigstry is through IETF Review or IESG Approval as defined by RFC5226. There are initial registrations in the new subregistry as follows:


Code Description Reference
----+-------------------------------------------+-----------------
2.01 Created [ RFC-to-be ]
2.02 Deleted [ RFC-to-be ]
2.03 Valid [ RFC-to-be ]
2.04 Changed [ RFC-to-be ]
2.05 Content [ RFC-to-be ]
4.00 Bad Request [ RFC-to-be ]
4.01 Unauthorized [ RFC-to-be ]
4.02 Bad Option [ RFC-to-be ]
4.03 Forbidden [ RFC-to-be ]
4.04 Not Found [ RFC-to-be ]
4.05 Method Not Allowed [ RFC-to-be ]
4.06 Not Acceptable [ RFC-to-be ]
4.12 Precondition Failed [ RFC-to-be ]
4.13 Request Entity Too Large [ RFC-to-be ]
4.15 Unsupported Content-Format [ RFC-to-be ]
5.00 Internal Server Error [ RFC-to-be ]
5.01 Not Implemented [ RFC-to-be ]
5.02 Bad Gateway [ RFC-to-be ]
5.03 Service Unavailable [ RFC-to-be ]
5.04 Gateway Timeout [ RFC-to-be ]
5.05 Proxying Not Supported [ RFC-to-be ]

The Response Codes 3.00-3.31 are Reserved for future use. All other Response Codes are Unassigned.

Fifth, a new subregistry of the new high-level "CoAP Codes" registry will be created called the "CoAP Option Numbers" registry. Maintenance of the new registry depends on the value being registered:

The range of 0 - 255 is reserved for options maintained by IETF Review or IESG approval as defined in RFC 5226. The range of 256 - 2047 is maintained via Specification Required as defined by RFC 5226. The range of 2048 - 64999 is maintained via Expert Review as defined in RFC 5226. The option numbers between 65000 and 65535 inclusive are reserved for experimental use.

There are initial registrations in this registry as follows:

                  +--------+----------------+-----------+
                  | Number | Name          | Reference |
                  +--------+----------------+-----------+
                  |      0 | (Reserved)    | [RFCXXXX] |
                  |      1 | If-Match      | [RFCXXXX] |
                  |      3 | Uri-Host      | [RFCXXXX] |
                  |      4 | ETag          | [RFCXXXX] |
                  |      5 | If-None-Match  | [RFCXXXX] |
                  |      7 | Uri-Port      | [RFCXXXX] |
                  |      8 | Location-Path  | [RFCXXXX] |
                  |    11 | Uri-Path      | [RFCXXXX] |
                  |    12 | Content-Format | [RFCXXXX] |
                  |    14 | Max-Age        | [RFCXXXX] |
                  |    15 | Uri-Query      | [RFCXXXX] |
                  |    16 | Accept        | [RFCXXXX] |
                  |    20 | Location-Query | [RFCXXXX] |
                  |    35 | Proxy-Uri      | [RFCXXXX] |
                  |    39 | Proxy-Scheme  | [RFCXXXX] |
                  |    128 | (Reserved)    | [RFCXXXX] |
                  |    132 | (Reserved)    | [RFCXXXX] |
                  |    136 | (Reserved)    | [RFCXXXX] |
                  |    140 | (Reserved)    | [RFCXXXX] |
                  +--------+----------------+-----------+

Sixth, a new subregistry of the new high-level "CoAP Codes" registry will be created called the "CoAP Content-Formats" registry. Regsitrations in the new "CoAP Content-Formats" subregistry are governed by the following rules:

For values in the range 0 - 255 maintenance of the registry will be done through Expert Review as defined in RFC 5226. Values in the range 256 - 9999 are maintained through IETF Review or IESG approval as defined in RFC 5226. Values in the range 10000 - 64999 are registered through "First Come, FIrst Served" as defined in RFC 5226. Values between 65000 and 65535 are reserved for experimental use.

There are initial registrations in the new sub registry as follows:

  +--------------------+----------+-----+-----------------------------+
  | Media type        | Encoding | Id. | Reference                  |
  +--------------------+----------+-----+-----------------------------+
  | text/plain;        | -        |  0 | [RFC2046][RFC3676][RFC5147] |
  | charset=utf-8      |          |    |                            |
  | application/      | -        |  40 | [RFC6690]                  |
  | link-format        |          |    |                            |
  | application/xml    | -        |  41 | [RFC3023]                  |
  | application/      | -        |  42 | [RFC2045][RFC2046]          |
  | octet-stream      |          |    |                            |
  | application/exi    | -        |  47 | [EXIMIME]                  |
  | application/json  | -        |  50 | [RFC4627]                  |
  +--------------------+----------+-----+-----------------------------+

NOTE:    [EXIMIME]  "Efficient XML Interchange (EXI) Format 1.0",
              December 2009, .

Seventh, this document requests adding two URI schemes to the URI scheme registry located at:

http://www.iana.org/assignments/uri-schemes.html

The two URI schemes to be added are:

coap
coaps

Currently the URI scheme registry is maintained through expert review as defined in RFC 5226.

Eighth, IANA has done an early allocation of port number 5683. Approval of this document will make that assignment permanent and the reference for port 5683 will be changed to [ RFC-to-be ].

Ninth, a new port assignment is requested as follows:

CoAP resource discovery may also be provided using the DTLS-secured CoAP "coaps" scheme. Thus the CoAP port for secure resource discovery needs to be standardized.

This document requests the assignment of the port number
[IANA_TBD_PORT] and the service name "coaps", in accordance with
[RFC6335].

Besides unicast, DTLS-secured CoAP can be used with anycast.

Service Name.
coaps

Transport Protocol.
UDP

Assignee.
IESG

Contact.
IETF Chair

Description.
DTLS-secured CoAP

Reference.
[RFCXXXX]

Port Number.
[IANA_TBD_PORT]

NOTE: This request has been resolved as per a message from IESG
secretary [Ticket #677633].

Tenth, a multicast address from the IPv4 Multicast Address Space registry is to be assigned. Called the "All CoAP Nodes" address, the authors request it should come from the Internetwork Control Block (224.0.1.x, RFC 5771).

Eleventh, a multicast address from the IPv6 Multicast Address Space registry, in the Variable Scope Multicast Addresses space (RFC3307) is requested.. The authors request that the address should be of the form FF0x::nn, where nn is a single byte, to ensure good compression of the local-scope address with [RFC6282].

We understand that these eleven actions are the only ones required upon approval of this document.

Thank you,

Pearl Liang
ICANN/IANA


On Wed Apr 17 08:57:22 2013, noreply@ietf.org wrote:
> Evaluation for  can be found at
> http://datatracker.ietf.org/doc/draft-ietf-core-coap/
>
> Last call to expire on: 2013-03-27 00:00
>
>
>        Please return the full line with your position.
>
>                      Yes  No-Objection  Discuss  Abstain
> Barry Leiba          [ X ]    [  ]      [  ]    [  ]
>
>
> "Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
> with no "Discuss" positions, are needed for approval.
>
> DISCUSSES AND COMMENTS
> ===========
> ?
> ---- following is a DRAFT of message to be sent AFTER approval ---
> From: The IESG
> To: IETF-Announce
> Cc: RFC Editor ,
>    core mailing list ,
>    core chair
> Subject: Protocol Action: 'Constrained Application Protocol (CoAP)' to
> Proposed Standard (draft-ietf-core-coap-14.txt)
>
> The IESG has approved the following document:
> - 'Constrained Application Protocol (CoAP)'
>  (draft-ietf-core-coap-14.txt) as Proposed Standard
>
> This document is the product of the Constrained RESTful Environments
> Working Group.
>
> The IESG contact persons are Barry Leiba and Pete Resnick.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-core-coap/
>
>
>
>
> Technical Summary
>
> The Constrained Application Protocol (CoAP) is a specialized web
> transfer protocol for use with constrained nodes and constrained
> (e.g., low-power, lossy) networks. The nodes often have 8-bit
> microcontrollers with small amounts of ROM and RAM, while
> constrained networks such as 6LoWPAN often have high packet error
> rates and a typical throughput of 10s of kbit/s. The protocol is
> designed for machine-to-machine (M2M) applications such as smart
> energy and building automation.
>
> CoAP provides a request/response interaction model between
> application endpoints, supports built-in discovery of resources,
> and includes key concepts of the Web such as URIs and Internet
> media types. CoAP easily interfaces with HTTP for integration
> with the Web while meeting specialized requirements such as
> multicast support, very low overhead and simplicity for
> constrained environments.
>
>
> Working Group Summary
>
> WG review has been intense, with input from many participants
> beyond the document authors, and particularly input from
> implementers.  There are no particular controversies to note.
>
>
> Document Quality
>
> There have been multiple expert reviews, from security,
> applications (once a general review, and once specifically on the
> URI schema), and transport areas. All the reviews produced useful
> input, that resulted in significant changes to the specification.
> All review feedback is now incorporated in the final document.
>
> There are at least 15 publically disclosed implementations, both
> commercial and open-source. There have been several
> interoperability events, and a high level of interoperability has
> been reported from those events.
>
>
> Personnel
> Document Shepherd is Andrew McGregor
> Responsible Area Director is Barry Leiba
> Zach Shelby  is suggested as the designated
> expert for the IANA registries defined in Sections 12.2 and 12.3.
>
>

[Ballot comment]
I want to thank the authors and WG for producing this specification. I
think it may be one of the more important pieces of work in recent
years. As might be expected with a document of over 100 pages reviewed
by a pedant, I have a list of nits and worries. These are all enetered
as Comments: I hope you will find time to address them and make the
resulting RFC more polished, but none of them comes even close to a
requirement that you change the text, and I am ballotting Yes.

---

How quickly we forget!

I looked up the spec of a typical home computer around the time of HTTP
v1.0 and discovered that it was not so very different from what you are
scoping your environment to today.

That is not to say that your work is not valid. Far from it! But I do
believe it might be helpful to explore in more detail why you don't
simply run an early, low-function version of HTTP.

FWIW, I believe the answer is that you want some of the advanced
functions that have been added to HTTP over the years, but do not want
the full family of rich features that may chew memory and bandwidth.

---

What about the use of CoAP on the wider Internet?

---

A very minor terminology point from Section 1.2

  Confirmable Message
      Some messages require an acknowledgement.  These messages are
      called "Confirmable".  When no packets are lost, each Confirmable
      message elicits exactly one return message of type Acknowledgement
      or type Reset.

  Non-confirmable Message
      Some other messages do not require an acknowledgement.  This is
      particularly true for messages that are repeated regularly for
      application requirements, such as repeated readings from a sensor.

You have picked a form "confirmable" and "non-confirmable" tha expresses
the ability to do something: this message can be confirmed.

But you have mapped the form to a description that requires action: an
acknowledgement must be sent.

"Can be confirmed" != "A confirmation must be sent"
"Cannot be confirmed" != "A conformation does not need to be sent"

I don't believe this is too important because you are defining the tems,
but I do think that the casual reader will not embed your redefinitions
of normal English words, and so will be confused by these terms in the
text.

---

Section 1.2. Also a very minor point.

  Acknowledgement Message
      An Acknowledgement message acknowledges that a specific
      Confirmable Message arrived.  It does not indicate success or
      failure of any encapsulated request.

The fact that and Acknowledgement Message can carry a response is lost
in this definition. Maybe you need (including fixes to your typos)...

  Acknowledgement Message
      An Acknowledgement Message acknowledges that a specific
      Confirmable Message arrived.  Of itself, an Acknoweledgement
      Message does not indicate success or failure of any request
      encapsulated in the Confirmable Message, but the Acknoweledgement
      Message may also carry a Piggy-backed response (q.v.).

---

My feeling was that the Message IDs shown in figures 2 through 6 were
confusing in their randomness. For example, you could spend a lot of
time staring at figures 2 and 3 trying to work out how CON is encodeded
as 0x7d34 while NON is encoded as 0x01a0.

Since you want to show Message IDs to show how they correspond on
different parts of the flow, you could have written, e.g.,

                        Client              Server
                            |                  |
                            |  CON [MsgID1]  |
                            +----------------->|
                            |                  |
                            |  ACK [MsgID1]  |
                            |<-----------------+
                            |                  |

---

Section 2.1

  As CoAP is based on UDP, it also supports the use of multicast IP

I don't think it is based on UDP. I think it runs over UDP.

---

Section 2.3

  As CoAP was designed according to the REST architecture and thus

Maybe insert another pointer to [REST].

---

Section 4.2

  A Confirmable message
  always carries either a request or response and MUST NOT be empty,
  unless it is used only to elicit a Reset message.

That is a bit of an over-use of "MUST NOT". I think

  A Confirmable message
  always carries either a request or response, unless it is used only
  to elicit a Reset message in which case it is empty.

---

Section 4.2

  A CoAP endpoint that sent a Confirmable message MAY give up in
  attempting to obtain an ACK even before the MAX_RETRANSMIT counter
  value is reached: E.g., the application has canceled the request as
  it no longer needs a response, or there is some other indication that
  the CON message did arrive.  In particular, a CoAP request message
  may have elicited a separate response, in which case it is clear to
  the requester that only the ACK was lost and a retransmission of the
  request would serve no purpose.  However, a responder MUST NOT in
  turn rely on this cross-layer behavior from a requester, i.e. it
  SHOULD retain the state to create the ACK for the request, if needed,
  even if a Confirmable response was already acknowledged by the
  requester.

This paragraph is giving me some worries.

I think the initial MAY confuses the CoAP implementation with the
endpoint containing the CoAP implementation.  The endpoint may give up,
and may instruct the CoAP implementation to stop retransmitting.  But I
think a CoAP implementaiton must not give up unless it is told to.


The drop from MUST NOT to SHOULD in the final sentence seems odd. My
understanding was that a CoAP implementation MUST always retain the
state to create the ACK for the request.  Is this use of SHOULD a
relaxation, and how does it square with the MUST NOT?

---

Section 4.6

  Messages
  larger than an IP fragment result in undesired packet fragmentation.

s/undesired/undesirable/  ?

---

Section 4.6

  A CoAP message, appropriately encapsulated, SHOULD fit within a
  single IP packet (i.e., avoid IP fragmentation) and (by fitting into
  one UDP payload) obviously MUST fit within a single IP datagram.

s/MUST/will/

---

Section 12

I am surprised that IANA was relaxed about the use of "reserved" in
Section 12.

For example, in 12.1 you have two ranges marked "Reserved" without any
clue to what this means. For example, does it mean that allocations can
be made, that an RFC can dedicate them to a new use, or that they must
never be allocated?

In 12.1.2 you have
  The Response Codes 96-127 are Reserved for future use.  All other
  Response Codes are Unassigned.
I take "Unassigned" to mean available for assignment according to the
policy for the registry. But "Reserved or future use" means what?

In 12.2 you have
                  |      0 | (Reserved)    |          |
This is the meaning of "reserved" I think we are used to, and means will
not be made available for allocation. (Although I am puzzled that you
don't include the pointer to this RFC.)

[Ballot comment]
I support some of the points raised by mehmet against draft 13 (addressed by carsten) which ultimately are not likely to be resolved by the this draft alone.

> ** Concerning the migration path, and future versions of CoAP in the same network:
>
> - It would be useful to state clearly, in which cases it is dangerous to change any of the recommended default values or parameters in future versions of CoAP and would potentially impact the co-existence of two CoAP versions. Thus such a statement would support an incremental deployment to be successful.

Again, I believe this is future work, which also applies for the configuration and management data model.

Protocol debugging is aided by the self-describing nature of the protocol messages.
This has worked pretty well in the (informal and formal) interops so far.

Future work will have to address management interfaces for CoAP nodes, including management of security related events.
I think some of this will have to integrate with resource discovery, an active subject in the working group.

Grüße, Carsten

---

this is not a dicuss because frankly I think at some point you have to draw a line under work that has been done so far and progress work from there.

[Ballot comment]
P. 14: informative reference to HHGTG almost, but not entirely,
helpful.  :)

P. 15: why start at version 1 when you can only have a total of 4 versions?  Wouldn't version 0 be a better choice?

P. 19: I'm a little uncomfortable with this text:

    There is no
            expectation and no need to perform normalization within a
            CoAP implementation (except where Unicode strings that are
            not known to be normalized are imported from sources
            outside the CoAP protocol).

I think what's intended here is right, but you've mentioned what
amounts to a strong suggestion, if not a requirement, as a
parenthetical note.  It seems like what you intended was something
like this:

    There is no expectation and no need to perform
            normalization within a CoAP implementation, since senders
            are expected to be implemented with pre-normalized
            strings.  However, strings received from non-CoAP sources
            SHOULD be normalized where possible.

Of course, there's actually no value to normalization in this case if
it can't be depended on, and I suspect that you don't want to make
that a MUST.  So this might be a better way to do it:

    There is no expectation and no need to perform
            normalization within a CoAP implementation, since senders
            are expected to be implemented with pre-normalized
            strings.  Strings received from non-CoAP sources and then
            forwarded by CoAP senders cannot be assumed to have been
            normalized, and may not compare correctly with normalized
            strings representing the same text.

I don't have a strong opinion about how this should be done, but it
seems like the text as written doesn't give clear guidance.  It seems
that cross-proxies ought to be able to do normalization, and maybe
other proxies could as well, but that's a much bigger change.

Section 4.1: Even though I think it doesn't make any sense to do this,
it might be worth stating how a receiver should behave if it receives
an ACK with a request.

Section 4.2: Wouldn't this:

  More
  generally, Acknowledgement and Reset messages MUST NOT elicit any
  Acknowledgement or Reset message from their recipient.

be better stated this way?

  More generally, recipients of Acknowledgement and Reset messages
  MUST NOT respond with either Acknowledgement or Reset messages.

Might be worth grouping for operator precedence here:

OLD:
        ACK_TIMEOUT * (2 ** MAX_RETRANSMIT - 1) * ACK_RANDOM_FACTOR
NEW:
        ACK_TIMEOUT * (2 ** (MAX_RETRANSMIT - 1)) * ACK_RANDOM_FACTOR

OLD:
        2 * MAX_LATENCY + PROCESSING_DELAY
NEW:
        (2 * MAX_LATENCY) + PROCESSING_DELAY

Section 5.8: The use of the word "safe" to describe methods is really
confusing because of save/unsafe options.  It would help ease of
comprehension if you used a different word--e.g., read-only.  I
realize that this goes somewhat against the idea of sharing
nomenclature with HTTP, but I think the clash between safe/unsafe
options and safe/unsafe methods is confusing enough that you aren't
really benefiting from that anyway.

In 5.9: as a user and implementor of RESTful systems who has learned
by doing more than by reading, the term "action result" is somewhat
opaque to me.  I think I know what it means, but it might be nice to
explain what it means before using it like this:

  Like HTTP 201 "Created", but only used in response to POST and PUT
  requests.  The payload returned with the response, if any, is a
  representation of the action result.

5.9.2.2: I think you mean "first" rather than "previously":

  The client is not authorized to perform the requested action.  The
  client SHOULD NOT repeat the request without previously improving its
  authentication status to the server.  Which specific mechanism can be
  used for this is outside this document's scope; see also Section 9.

5.10.1: how does the client know that an endpoint hosts multiple
virtual servers in time to leave out the Uri-Host option?  Is this
literally just in the case where the hostname appears in the URI to be
decomposed as an IP address literal?

  are sufficient for requests to most servers.  Explicit Uri-Host and
  Uri-Port Options are typically used when an endpoint hosts multiple
  virtual servers.


In 5.10.8.2: I can't quite understand what is meant here.  I could see
it meaning either or both of the following:

  1. If If-None-Match appears in a query with one or more If-Match
  options, and none of the If-Match options match, the condition is
  fulfilled.
  2. If If-None-Match appears in a query, no If-Match options may
  appear in that query; the condition is met if the target doesn't
  exist.

I think that the text means just (2), but because of the name of the
option, I want it to mean (1), even though the text doesn't say that,
and since the text doesn't say that If-None-Match and If-Match are
mutually exclusive, I can easily imagine someone reading the text and
carelessly assuming that it means (1) or (1 or 2).

In 6.4, why /url/?  This is really confusing--I was halfway through
this section, and kind of confused, before I realized that the slashes
were for emphasis, and weren't path separators.

Also in 6.4, the text does not account for the case where there's a
user part to the authority section of the URI.

[Ballot discuss]
Overall, this is a very nicely written specification.  Thanks!  There's just one point I think needs action on before I switch to a "YES" position.

In Section 5.3.1, "A client sending a request...".  This needs to be stronger.  The requirement for a randomized token needs to be a MUST, and the stack SHOULD limit the number of rejected responses (before closing the request) based on the length of the token (e.g., 2**(TKL/2)).

[Ballot comment]
In Section 2.2., are requests and responses in 1-1 correspondence?  Or can a single request receive more than one response?

In Section 3, why is version number 1 and not 0?  What's the plan here, do we get 3 or 4 versions out of this?

In Section 4.3, would it make sense to have something stronger than MAY for cases where future messages are likely to be screwed up, e.g., where CoAP syntax is malformed?  (A "STFU RST"?)

From Section 4.2 and 4.3, I generated a table mapping message types to request/response/empty:
            CON NON ACK RST
Request    X  X  ?  !
Response    X  X  X  !
Empty      !  !  X  X   
Might be helpful to include something like that as a summary.  This might be a bad idea, but: Did the WG consider allowing an ACK to contain a request?  In the case where a CON contains a response and the client wants to send another request, it would save a message to put the request in the ACK to the response.

RFC
5280 section 6? If so, say so. If not, say what you do mean.
(But we might need to talk about it in that case,
depending;-)

(9) 9.1.3.3 - you don't mention certificate status checking.
I can see why that's hard to impossible in some n/w's but
entirely ignoring it seems wrong. Perhaps call out the
vulnerability and point at OCSP stapling as a potential
solution, but one that requires further work and/or further
specification?

(10) 10.1 - what does https mean here? If it means that
the request/response are in clear between the source and
proxy and then encrypted then a) you really really need to
say that clearly and b) why is that even acceptable and c)
what if the destination resource requires client auth? It
just seems broken to pretend to use https this way. Going
via a cross-proxy breaks security.  Similarly, what does
coaps mean in 10.2?

NETMOD                                                    D. Bogdanovic
Internet-Draft                                      Volta Networks, Inc.
Intended status: Informational                                B. Claise
Expires: April 29, 2017                                        C. Moberg
                                                    Cisco Systems, Inc.
                                                        October 26, 2016

                      YANG Module Classification
            draft-ietf-netmod-yang-model-classification-04

Abstract

  The YANG [RFC6020] data modeling language is currently being
  considered for a wide variety of applications throughout the
  networking industry at large.  Many standards-defining organizations
  (SDOs), open source software projects, vendors and users are using
  YANG to develop and publish YANG modules for a wide variety of
  applications.  At the same time, there is currently no well-known
  terminology to categorize various types of YANG modules.

  A consistent terminology would help with the categorization of YANG
  modules, assist in the analysis of the YANG data modeling efforts in
  the IETF and other organizations, and bring clarity to the YANG-
  related discussions between the different groups.

  This document describes a set of concepts and associated terms to
  support consistent classification of YANG modules.

Status of This Memo

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF).  Note that other groups may also distribute
  working documents as Internet-Drafts.  The list of current Internet-
  Drafts is at http://datatracker.ietf.org/drafts/current/.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  This Internet-Draft will expire on April 29, 2017.

Bogdanovic, et al.      Expires April 29, 2017                [Page 1]
Internet-Draft        YANG Module Classification          October 2016

Copyright Notice

  Copyright (c) 2016 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect
  to this document.  Code Components extracted from this document must
  include Simplified BSD License text as described in Section 4.e of
  the Trust Legal Provisions and are provided without warranty as
  described in the Simplified BSD License.

Table of Contents[Ballot comment]

general: 112 pages, sheesh;-) Seriously though, there is
repetition here that'd be better not there and fewer words
is better. Too late now though.

abstract: "CoAP easily..." is a bit of sales-talk, better to
say "CoAP is designed to easily..."

intro, 2nd para: better to not talk about the WG name and
its work really, but about the resulting protocol

intro, 2nd para: suggest s/limiting the use of/limiting the
need for/

intro, last para: more sales pitch language

1.2, critical option - I wondered here if proxies have to
know these or just client & server.  "Endpoint receiving the
message" doesn't make that (ctystal) clear. "Unsafe Option"
made me wonder more. (It is clear later.)

2.2: This is the first time Token is used. Might be no harm
to distinguish that explicitly from Message ID.

2.3: For what "security reason" are proxies useful?

3: Ver field "MUST set this field to 1" - I guess someone
might set both bits to 1, so saying '01'B might be better.

Section 3: I didn't see where Message ID wrap-around was
described. I see Martin has a discuss on that which I
support.

3: Message ID - with 16 bits that imposes a rate limit on
how often you can send. I don't think that's described and
I'm curious as to whether it'd set to max goodput for CoAP
that'd be way less than otherwise possible with e.g. HTTP.

3.2: So I can't have an option with a uint value where
missing != 0? Might be worth saying.

4.1: middle two paragraphs seem like repetition - maybe they
could be deleted?

4.2, 1st para, "acknowledge such a message" - do you mean
all CONs or just an empty CON? splitting up this para into a
few or using a bullet list or pseudo-code would be better I
think.

4.2, "a random number between 2 and 3" (replacing names with
defaults) - ought you recommend some minimun granularity
just in case some careless developer did something like:

      initialTimeout=ACK_TIMEOUT+
          rand()%(ACK_TIMEOUT*ACKRANDOM_FACTOR-ACK_TIMEOUT)

4.3, last sentence in parenthesis - I have no idea what that
means

4.4, last para: I just wonder if any NAT or v6 transition
schemes might invalidate this MUST?

4.6, 1st sentence: don't get that, maybe better deleted.

4.8.1, DEFAULT_LEISURE is in table 1 but not discussed until
section 8, a fwd ref at least would be good

5.2.2, "The server maybe initiates..." seems too casual.

5.3.1, 3rd para - the note about using the same token for
different source ports seems broken to me. I don't think you
say anything to the effect that the response has to go to
that source port.

5.4.6, option numbers can be 16 bits long, in that case bit
7 is not the lsb - does that need fixing? Similarly with
Figure 11.

5.5.2, I buy your argument here about language tagging, but
what happens at a CoAP->HTTP g/w? Doesn't language tagging
become an issue there? How's that handled?

5.10.1 - can any of the valid options for Host from 3986 be
used? e.g. IPv6 addresses as text in square brackets,
decimal form IPv4 addresses? You do have some guidance later
but I think that'd be bettern being more obvious.

5.10.5 - I'm probably just confused by reading so much;-) If
there are two Max-Age options, which wins? Where's that
stated in general?

5.10.8.1 - I don't get why its ok to not say which If-Match
to pick if more than one matches. Why's that?

6.1 - I don't get what you mean by saying that the coap URI
scheme "supports" /.well-known, maybe that'll be clear in
section 7. (I don't think it was.)

6.2 - s/for privacy// - DTLS does authentication, integrity
and confidentiality, not privacy

7.1 - what if I want to only do discovery via DTLS? What
does "support" mean for port 5683 then?

7.2 - I didn't really get how this works, but I assume that
if I re-read RFC6690, then I'd get it. Is that a good
assumption?

8.2.1, 1st para - this talks about "the cache" but I don't
think you've (so far) told me that clients that send
multicast requests have to have a cache for responses. Don't
you need to?

8.2.2 - Please make it clear(er) that bormann-coap-misc is
properly an informative ref. (Assuming it is.)

section 9, last para: what's that mean? I got the feeling
the text was trying to hide something from me fwiw.

6.5 - I thin you need a security consideration somwhere
about comparing coap(s) URIs and the potential for access
control screw-ups.

9.1 - have people implemented the ECDH ciphersuites in CoAP
testing? Knowing if this is just text or also running code
might help discuss resolution.

9.1.3.3 - throwing in RSA as a SHOULD (albeit within a
section that's a MAY) is odd - if devices can do RSA then
why not have 'em all do it for the raw public keys and get
the interop gains that will accrue from that.

11.5 - this is a bit detailed, wouldn't a reference do
most of it?

12.7 - as it turns out I also don't see why this needs
two ports - the cost is two more bytes for security which
is significantly-enough less than the current cost (in
terms of message size) for security. Am I wrong?

Please also consider the secdir review [1] (if you've
not done so already, I do see a shepherd response).

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03873.html

[Ballot comment]
I am entering no-objection on the basis that this has no impact on the routing layer and I am confident that the applications layer ADs will ensure the quality of the design.

[Ballot discuss]
A well-written document and I have a few points to discuss.

The congestion avoidance mechanisms look ok, but I assume we will get feedback from implementers and deployments on the parameters and mechanisms. It would be good to get this feedback documented at some point.

Here are the issues (based on my own review and input from Joe Touch and Michael Scharf):

1) IPv6 UDP checksum calculation
It is not clear if zero UDP checksums are permitted or not permitted with COAP.?
(UDP zero checksums:
https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/)
That should be specified.

2) Handling of UDP-lite
Can UDP-lite (RFC 3828) be used or cannot be used in conjunction with CoAP?


3) Fragmentation of messages
The recommendation in Section 4.6 about the path MTU is generally valid only for IPv6. For IPv4, 567 bytes is the safe area to work without fragmentation, though in today WANs 1280 work perfectly, but I am not so sure about the networks envisioned for CoAP. This 576 bytes for IPv4 are mentioned in the implementation note, but deserves text on the same level as for IPv6.

4) Ensuring no fragmentation with IPv4
The implementation note in Section 4.6 states that for IPv4 it is 'harder to ensure that there is no IP fragmentation'. This neglects the possibility of using the Don't Fragment (DF) flag in the IPv4 header and also that there is possibly feedback from a node enroute that the MTU is too big if the DF flag is set, i.e., by means of an ICMP error message.
Should there be any recommendation or protocol machinery to deal with path probing? E.g., referencing RFC 4821 (PMTUD).


5) Reaction to network errors that are signalled
I wonder why the draft is not discussing any reaction to network failures signalled through ICMP messages. This relates also to my DISCUSS issue no 4.

6) Idempotency
The discussion of idempotency is useful, but overlooks message order. I.e., the discussion appears to assume that a sequence of the same actions has the same effect as a single action, but this is true only if different sets of actions (from different sources, or copies of different actions from a single source) aren't interleaved. This should be addressed.

7) Protocol reactions to reserved or prohibited values
Regarding reserved or prohibited values in the IANA section, it would be useful to be clear about what happens when those values are seen. I.e., should they be ignored, generate an error, etc.

8) Flow Control/Receiver Buffer
The protocol does not have any real means for the receiver to control the amount of data that is being sent to it. I can understand the attempt to provide a simple protocol, but adding a very basic flow control mechanism will not prohibitively increase the complexity of the protocol, while improving robustness.
According to Section 2.1, a node can always return a RST if the message cannot be process for whatever reason.
I propose to add an option to the RST message that allows the message receiver to state how much data it is willing to accept from a particular sender or in general (up to the implementation). 

9) Handling a wrapping message IDs
According to Section 4.4.:
"The same Message ID MUST NOT be re-used (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2)" with EXCHANGE_LIFETIME of 247s.
By now it is unrealistic that the message ID of 16 bits will wrap around in that time frame, but protocols live long and at some later time it can be possible.
However, the protocol doesn't have any means to detect wrapped message IDs.

[Ballot comment]
1) Endpoint vs. host
This document uses the term "endpoint" to refer to the combination of address and port, and possibly also security association, that is local to one end of an association. I would have expected the more common term "socket", as originated in TCP parlance, to be used instead (even though here the term is used in a connectionless context).

2) Reaction to network errors due to local link errors
Link layers can give some hints if the link is up, down, etc. Traditionally, this has not been taken into account too much when design transport protocols, but wouldn't it make sense to take it into account for CoAP, as it is much more working in constrained environments?

3) Short messages
Section 3., paragraph 1:

>    CoAP is based on the exchange of short messages which, by default,
>    are transported over UDP (i.e. each CoAP message occupies the data
>    section of one UDP datagram).  CoAP may also be used over Datagram

What are short messages in terms of bytes? Is this a hidden protocol requirement?


4) randomization of message IDs

Section 4.4., paragraph 3:

>    Implementation Note:  Several implementation strategies can be
>      employed for generating Message IDs.  In the simplest case a CoAP
>      endpoint generates Message IDs by keeping a single Message ID
>      variable, which is changed each time a new Confirmable or Non-
>      confirmable message is sent regardless of the destination address
>      or port.  Endpoints dealing with large numbers of transactions
>      could keep multiple Message ID variables, for example per prefix
>      or destination address (note that some receiving endpoints may not
>      be able to distinguish unicast and multicast packets adressed to
>      it, so endpoints generating Message IDs need to make sure these do
>      not overlap).  The initial variable value should be randomized.

  the initial variable SHOULD be randomized, just to avoid blind off
  path attacks, right?

5)
In Section 4.6.:

>  larger than an IP fragment result in undesired packet fragmentation.
should read larger than an 'IP packet' instead of 'IP fragment'.

6)
Section 5.4.1., paragraph 7:

>    Critical/Elective rules apply to non-proxying endpoints.  A proxy
>    processes options based on Unsafe/Safe classes as defined in
>    Section 5.7.

  I suggest moving this statement to the beginning of this subsection,
  as it provides important information that shouldn’t be missed.

7) Dependency between application layer and CoAP
Section 5.2.2., paragraph 2:

>    The server maybe initiates the attempt to obtain the resource
>    representation and times out an acknowledgement timer, or it
>    immediately sends an acknowledgement knowing in advance that there
>    will be no piggy-backed response.  The acknowledgement effectively is
>    a promise that the request will be acted upon.

This may or may not be an issue:
Assuming that the server did sent an ACK for a request but is never ever fulfilling its promise to send any real 'response'. The request/response initiated from the client is done on the CoAP level, but not for the application on top.
Is there any recommendation for the application on top of CoAP how to handle such cases?

[Ballot discuss]
A well-written document and I have a few points to discuss, but I still need to write them in a comprehensive way.

A tentative short list:

1) IPv6 UDP checksum calculation
It is not clear if zero UDP checksums are permitted or not permitted with COAP.?
(UDP zero checksums:
https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/)
That should be specified.

2) Handling of UDP-lite
Can UDP-lite (RFC 3828) be used or cannot be used in conjunction with CoAP?

[Ballot discuss]
The items here are very borderline in my book for DISCUSS items; I'm happy to be talked out of them. But I would like to hear from the authors and/or chairs before I give my "YES" (which is my plan once these are resolved).

4.1:

  An empty message has the Code field set to 0.  The Token Length field
  MUST be set to 0 and no bytes MUST be present after the Message ID
  field.  If there are any bytes, they MUST be processed as a message
  format error.
 
If you insist on the MUSTs, make the second one "bytes of data MUST NOT be present". The current construction is ambiguous. That said, I find the combination of MUSTs to be a bit problematic. MUST NOT send data, but MUST receive as a format error will lead to some sender saying, "A conformant receiver MUST reject with an error, so no need for me to validate on the way out" and for a receiver to say, "A conformant sender MUST NOT send data, so no need for me to validate on the way in." That's a recipe for non-interoperability. If it were me, I'd drop the last sentence.

4.3:

  rejecting a Non-confirmable message MAY involve sending a matching
  Reset message, and apart from the Reset message the rejected message
  MUST be silently ignored.

See comment on 2.1. But if you're going to allow this, I don't understand the MAY: Doesn't rejecting the message require sending a Reset? Otherwise, the message has not been rejected; it's simply been ignored. The second part is either redundant or confusing: What else might I do with a rejected message other than send the Reset and ignore it? I think this needs rewriting.

5.2.2: It is probably worth saying somewhere in here: "Once the server sends back an empty Acknowledgement, it MUST NOT send back the response in another Acknowledgement, even if the client retransmits another identical request. If a retransmitted request is received (perhaps because the original Acknowledgement was delayed), another empty Acknowledgement is sent and any response MUST be sent as a separate response."

5.4.2: Cache-Key is undefined, here or in any other document I can find. It probably needs an explanation somewhere in this document.

5.5: Again, I don't like the combination of MUST NOT include/MUST ignore. I would drop the MUST ignore part.

5.10.4:

                                                      The server SHOULD
  return the preferred Content-Format if available.  If the preferred
  Content-Format cannot be returned, then a 4.06 "Not Acceptable"
  SHOULD be sent as a response.

What are the exceptions to the above two SHOULDs? If the preferred format is available, when would a server not return it. If it's not available, when would the server return other than "Not Acceptable"? Also, since Accept is not marked as "Critical", why isn't it *always* treated as elective and therefore ignored if the server can't satisfy the request? (In other words, shouldn't you also have a "Critical Accept" option defined?)

[Ballot comment]
By section number:

1. The reference to [I-D.ietf-lwig-terminology] worries me, given that it is not even in LC yet.

2.1:

  When
  a recipient is not able to process a Non-confirmable message, it may
  reply with a Reset message (RST).

Why is this? If a NON message can't be ACKed, why can it be RST? This seems like additional machinery for the client.

2.2:

                                          the response to a request
  carried in a Confirmable message is carried in the resulting
  Acknowledgement (ACK) message.  This is called a piggy-backed
  response, detailed in Section 5.2.1.
  [...]
  If the server is not able to respond immediately to a request carried
  in a Confirmable message, it simply responds with an empty
  Acknowledgement message so that the client can stop retransmitting
  the request.  When the response is ready, the server sends it in a
  new Confirmable message (which then in turn needs to be acknowledged
  by the client).

It took me a bit to figure out why things worked this way, and I think a sentence or two of explanation would be useful. A piggy-backed response to a Confirmable request doesn't itself need to be confirmable because if the ACK gets lost, the client will  re-transmit the request until it gets the answer. When the response to a Confirmable request is not piggy-backed, the response should itself be Confirmable, since a Confirmable request will normally want a guaranteed response.

  Likewise, if a request is sent in a Non-confirmable message, then the
  response is usually sent using a new Non-confirmable message,
  although the server may send a Confirmable message.

"Likewise" seems wrong here. A Non-confirmable request can *not* get an Acknowledgement message, and therefore can *not* get a piggy-backed response. Additionally, the response MAY be Confirmable or MAY be Non-confirmable, though certainly Non-Confirmable is the more likely case. This should probably be reworded.


3:

  Token Length (TKL):  4-bit unsigned integer.  Indicates the length of
      the variable-length Token field (0-8 bytes).  Lengths 9-15 are
      reserved, MUST NOT be sent, and MUST be processed as a message
      format error.

Why not make TKL a 3-bit unsigned integer and have a reserved padding bit before it? Is this protocol likely to be extended to 9-15 byte Tokens?

  Code:  8-bit unsigned integer.  Indicates if the message carries a
      request (1-31) or a response (64-191), or is empty (0).
     
As above, why not make a 3-bit field for Code Type (000=request, 001=reserved, 010=success response, 100=client error response, 101 =server error response, 110/111=reserved), and then a 6-bit Code? It would also make the registry much easier to read.

4.2:

                                              A Confirmable message
  always carries either a request or response and MUST NOT be empty,
  unless it is used only to elicit a Reset message.
 
I don't understand the requirement not to be empty, especially when there is an exception at the end of the sentence. Shouldn't this be "and contains data bytes unless it is used only to elicit a Reset message."?

                                                      The
  Acknowledgement message MUST echo the Message ID of the Confirmable
  message, and MUST carry a response or be empty (see Section 5.2.1 and
  Section 5.2.2).
 
I don't understand the second MUST: What other choice is there besides carrying a response or being empty? Aren't those the only two options?
 
                    The Reset message MUST echo the Message ID of the
  Confirmable message, and MUST be empty.

Why MUST a Reset be empty? What harm is there if there is data in there?
 
  Rejecting an Acknowledgement
  or Reset message is effected by silently ignoring it.

I don't understand the above. As far as I can tell, an Acknowledgement nor a Reset can be rejected; the side that sent them will never know it is rejected.
 
4.5: All of the MUSTs and MAYs in the section are used rather terribly. I'm glad to suggest text if you need.

4.6: The phrase "and (by fitting into one UDP payload) obviously MUST fit within a single IP datagram" is unnecessary, but even if you do use it, s/MUST/needs to. The MUST is not a requirement on an implementation of CoAP. That said, I fear this section is really nothing more than an implementation note: Because it is a layer violation, it's not clear to me that any implementer has the ability to figure out much of this. (For example, the idea that an implementer would be willing to -- or even know how to -- set the Do Not Fragment bit or figure out the Path MTU is a bit hopeful.) I have no objection to this section, but it might be better as an implementation note rather than a set of requirements.

5.2: I found "indicating a value of 4*32+3, hexadecimal 0x83 or decimal 131" just adds confusion rather than clarify. Perhaps instead: "even though if taken as an 8-bit unsigned, the entire Response Code field would have a value of hexadecimal 0x83 or decimal 131 (4*32+3)". But personally, I would simply drop it; it doesn't add anything. See also comments above on section 3 and below on 12.1.

Also:

  The response codes are designed to be extensible: Response Codes in
  the Client Error and Server Error class that are unrecognized by an
  endpoint MUST be treated as being equivalent to the generic Response
  Code of that class (4.00 and 5.00, respectively).  However, there is
  no generic Response Code indicating success, so a Response Code in
  the Success class that is unrecognized by an endpoint can only be
  used to determine that the request was successful without any further
  details.
 
First, I suggest changing the first sentence after the colon: "Response Code details that are unrecognized by an endpoint when the class is Client Error or Server Error  are treated as equivalent to the...". Much clearer, and the MUST is wrong. Second, I don't see why you don't simply define a 2.00 so that this can be a bunch simpler.

5.2.3: Potential confusion: s/the client may send a Resent message/the client will send a Resent message

5.4.1: I don't understand the need for the third bullet. Isn't this already said in the second bullet? The fourth bullet has the same issue as 2.1 and 4.3.

5.4.4

  If the option is not present, the default
  value MUST be assumed.

Don't you really mean, "If an option is present with no value, the value is the default."? The way you have it written sounds like a completely missing option should be assumed to be present and have a default value. I don't think that's what you mean. (The MUST is just superfluous anyway.)

5.4.5:

  If a message includes an option with more occurrences than the option
  is defined for, the additional option occurrences MUST be treated
  like an unrecognized option (see Section 5.4.1).
 
I think you want to be specific about the order:

  If a message includes an option with more occurrences than the option
  is defined for, any additional option occurrences that appear
  subsequently in the message MUST be treated like an unrecognized
  option (see Section 5.4.1).

That is to say, you can't choose to keep later ones and discard earlier ones.

5.4.6: If it were me, I would have put the NoCacheKey bits in the high four bits so that you could simply do a <224 test for cache-matching options. I suppose this ship has sailed.

5.5.1: The implementation note notwithstanding, I don't understand why Content-Format is not a SHOULD.

5.7.1:

  If a response is generated out of a cache, it MUST be generated with
  a Max-Age Option that does not extend the max-age originally set by
  the server

The reverse would be clearer:

  If a response is generated out of a cache, the generated Max-Age
  Option MUST NOT extend the max-age originally set by the server
 
Also: "a proxy SHOULD be conservative" s/SHOULD/should. There's nothing to implement here.

5.10.5 s/MUST/is. The MUST is not meaningful.

8.1:

  A server SHOULD be aware that a request arrived via multicast, e.g.
  by making use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if
  available.

That SHOULD is not meaningful. It is useful, not required with exceptions (as SHOULD indicates), for the server to know that it is using multicast.

This also gives a reason not to allow RST on *any* NON messages.

8.2: "the server MAY always pretend"? We are getting sillier with our 2119 usage later in the document. Did you really mean, "the server MAY ignore the request"? Isn't that true of any NON request, not just multicast ones?

(I did not do an significant review of sections 9 or 11.)

12.1: As mentioned regarding section 3 and 5.2 above, I think it would be much easier to figure these out if you separated out the bit fields of code type and code, and then had sub-registries for request codes, success codes, client error codes, and server error codes.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-core-coap-14.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We have questions about the IANA Considerations section of this document.

We understand that, upon approval of this document, there are several actions which IANA must complete.

First, a new high-level registry will be created in the IANA Matrix, located at:

http://www.iana.org/numbers.html

This will be called the "CoAP Parameters and Codes" registry and will contain a number of subregistries.

QUESTION -> What is the URL address for this new top-level registry?
Does http://www.iana.org/assignments/core-coap look okay?

Second, a new subregistry of the "CoAP Parameters and Codes" registry will be created called the CoAP Code Registry. Values in the new registy range from 0-255 with the following subranges:

  0        Indicates an empty message (see Section 4.1).

  1-31      Indicates a request.  Values in this range are assigned by
            the "CoAP Method Codes" sub-registry (see below).

  32-63    Reserved

  64-191    Indicates a response.  Values in this range are assigned by
            the "CoAP Response Codes" sub-registry (see
            Section below).

  192-255  Reserved

Third, a new subregistry of the CoAP Codes registry will be created called the CoAP Method Codes subregistry.  Maintenance of the new subreigstry is through IETF Review or IESG Approval as defined by RFC5226.  There are initial registrations in the new subregistry as follows:

Code:  1
Name: GET
Reference: [ RFC-to-be ]

Code:  2
Name: POST
Reference: [ RFC-to-be ]

Code:  3
Name: PUT
Reference: [ RFC-to-be ]

Code:  4
Name: DELETE
Reference: [ RFC-to-be ]

The remainder of the entries in this registry, 5-31, are unassigned.

Fourth, a new subregistry of the CoAP Codes registry will be created called the CoAP Response Codes subregistry.  Maintenance of the new subreigstry is through IETF Review or IESG Approval as defined by RFC5226.  There are initial registrations in the new subregistry as follows:


Code  Description                      Reference
==  ================  =======  65  2.01 Created                    [ RFC-to-be ]
  66  2.02 Deleted                    [ RFC-to-be ]
  67  2.03 Valid                      [ RFC-to-be ]
  68  2.04 Changed                    [ RFC-to-be ]
  69  2.05 Content                    [ RFC-to-be ]
  128  4.00 Bad Request                [ RFC-to-be ]
  129  4.01 Unauthorized                [ RFC-to-be ]
  130  4.02 Bad Option                  [ RFC-to-be ]
  131  4.03 Forbidden                  [ RFC-to-be ]
  132  4.04 Not Found                  [ RFC-to-be ]
  133  4.05 Method Not Allowed          [ RFC-to-be ]
  134  4.06 Not Acceptable              [ RFC-to-be ]
  140  4.12 Precondition Failed        [ RFC-to-be ]
  141  4.13 Request Entity Too Large    [ RFC-to-be ]
  143  4.15 Unsupported Content-Format  [ RFC-to-be ]
  160  5.00 Internal Server Error      [ RFC-to-be ]
  161  5.01 Not Implemented            [ RFC-to-be ]
  162  5.02 Bad Gateway                [ RFC-to-be ]
  163  5.03 Service Unavailable        [ RFC-to-be ]
  164  5.04 Gateway Timeout            [ RFC-to-be ]
  165  5.05 Proxying Not Supported      [ RFC-to-be ]

The Response Codes 96-127 are Reserved for future use.  All other Response Codes are Unassigned.

Fifth, a new subregistry of the new high-level "CoAP Parameters and Codes" registry will be created called the "CoAP Option Numbers" registry. Maintenance of the new registry depends on the value being registered:

The range of 0 - 255 is reserved for options maintained by IETF Review or IESG approval as defined in RFC 5226.  The range of 256 - 2047 is maintained via Specification Required as defined by RFC 5226.  The range of 2048 - 64999 is maintained via Expert Review as defined in RFC 5226.  The option numbers between 65000 and 65535 inclusive are reserved for experimental use.

There are initial registrations in this registry as follows:

Number  Name            Reference
===  ======== =======
    0  (Reserved)               
    1  IfMatch        [ RFC-to-be ]
    3  UriHost        [ RFC-to-be ]
    4  ETag            [ RFC-to-be ]
    5  IfNoneMatch    [ RFC-to-be ]
    7  UriPort        [ RFC-to-be ]
    8  LocationPath    [ RFC-to-be ]
    11  UriPath        [ RFC-to-be ]
    12  ContentFormat  [ RFC-to-be ]
    14  MaxAge          [ RFC-to-be ]
    15  UriQuery        [ RFC-to-be ]
    16  Accept          [ RFC-to-be ]
    20  LocationQuery  [ RFC-to-be ]
    35  ProxyUri        [ RFC-to-be ]
    39  ProxyScheme    [ RFC-to-be ]
  128  (Reserved)      [ RFC-to-be ]
  132  (Reserved)      [ RFC-to-be ]
  136  (Reserved)      [ RFC-to-be ]
  140  (Reserved)      [ RFC-to-be ]

Sixth, a new subregistry of the new high-level "CoAP Parameters and Codes" registry will be created called the "CoAP Content-Formats" registry. Regsitrations in the new "CoAP Content-Formats" subregistry are governed by the following rules:

For values in the range 0 - 255 maintenance of the registry will be done through Expert Review as defined in RFC 5226.  Values in the range 256 - 9999 are maintained through IETF Review or IESG approval as defined in RFC 5226.  Values in the range 10000 - 64999 are registered through "First COme, FIrst Served" as defined in RFC 5226.  Values between 65000 and 65535 are reserved for experimental use.

There are initial registrations in the new sub registry as follows:


Media type          Encoding  Id.  Reference 
=============== == ===============text/plain;                    0  [RFC2046][RFC3676][RFC5147]
charset=utf8   

application/                  40  [RFC6690]                 
linkformat 

application/xml              41  [RFC3023] 

application/                  42  [RFC2045][RFC2046]         
octetstream   

application/exi              47  [EXIMIME]

application/json              50  [RFC4627]                 

IANA Question -> What reference should be substituted for the reference in these initial registrations marked "EXIMIME?"

Seventh, this document requests adding two URI schemes to the URI scheme registry located at:

http://www.iana.org/assignments/uri-schemes.html

The two URI schemes to be added are:

coap
coaps

Currently the URI scheme registry is maintained through expert review as defined in RFC 5226.

NOTE: IANA will initiate a request and send this to the designated expert
of the URI Scheme registry for review and approval.

Eighth, IANA has done an early allocation of port number 5683.  Approval of this document will make that assignment permanent and the reference for port 5683 will be changed to [ RFC-to-be ].

Ninth, a new port assignment is requested as follows:

  CoAP resource discovery may also be provided using the DTLS-secured
  CoAP "coaps" scheme.  Thus the CoAP port for secure resource
  discovery needs to be standardized.

  This document requests the assignment of the port number
  [IANA_TBD_PORT] and the service name "coaps", in accordance with
  [RFC6335].

  Besides unicast, DTLS-secured CoAP can be used with anycast.

  Service Name.
      coaps

  Transport Protocol.
      UDP

  Assignee.
      IESG

  Contact.
      IETF Chair

  Description.
      DTLS-secured CoAP

  Reference.
      [RFCXXXX]

  Port Number.
      [IANA_TBD_PORT]

NOTE: the authors need to submit a template for early allocation and put
the Internet Draft as a reference according to RFC 6335 as stated in
section 8.1.1:

"IANA MAY accept early assignment [RFC4020 ] requests (known as "early allocation" therein) from IETF working groups that reference a sufficiently stable Internet-Draft instead of a published Standards-Track RFC. "

Tenth, a multicast address from the IPv4 Multicast Address Space registry is to be assigned.  Called the "All CoAP Nodes" address, the authors request it should come from the Internetwork Control Block (224.0.1.x, RFC 5771).

Eleventh, a multicast address from the IPv6 Multicast Address Space registry, in the Variable Scope Multicast Addresses space (RFC3307) is requested..  The authors request that the address should be of the form FF0x::nn, where nn is a single byte, to ensure good compression of the local-scope address with [RFC6282].

IANA understands that these eleven actions are the only ones required 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (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:
- '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 2013-03-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 Constrained Application Protocol (CoAP) is a specialized web
  transfer protocol for use with constrained nodes and constrained
  (e.g., low-power, lossy) networks.  The nodes often have 8-bit
  microcontrollers with small amounts of ROM and RAM, while constrained
  networks such as 6LoWPAN often have high packet error rates and a
  typical throughput of 10s of kbit/s.  The protocol is designed for
  machine-to-machine (M2M) applications such as smart energy and
  building automation.

  CoAP provides a request/response interaction model between
  application endpoints, supports built-in discovery of services and
  resources, and includes key concepts of the Web such as URIs and
  Internet media types.  CoAP easily interfaces with HTTP for
  integration with the Web while meeting specialized requirements such
  as multicast support, very low overhead and simplicity for
  constrained environments.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-core-coap/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-core-coap/ballot/


No IPR declarations have been submitted directly on this I-D.