Subject: Re: [core] Pete Resnick's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT)

From: Pete Resnick <[email-masked]>
Date: Wed, 15 May 2013 20:27:52 -0700

Sorry for not replying to this sooner. I saw -16; thanks for your work 
on the doc. I'll update the ballot and clear what needs clearing in a 
bit (I'll try to get that done tonight), but wanted to respond to some 
of the points in here:

On 4/25/13 6:23 AM, Carsten Bormann wrote:

>          ----------------------------------------------------------------------
>          DISCUSS:
>          ----------------------------------------------------------------------
>
>          4.1:
>          If you insist on the MUSTs, make the second one "bytes of data MUST NOT
>          be present". The current construction is ambiguous.
>
> (Done the obvious editorial fix as [1304].)
>    

I actually liked Barry's suggested text, but this is fine. (And I'm also 
OK with the "MUST NOT send/MUST treat as a format error"; I understand 
what it's saying.)

>          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.
>
> I think we are trying to use "reject" as a technical term here (as
> used in the draft "rejecting" often does not imply actively sending a
> message).  I'm open to inventing another term that is assigned the
> semantics that "reject" has in CoAP right now.
>    

"Reject" in this sense 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, "ignore" is one possible form of rejection. 
That's just weird.

If you're going to do this, I'd define terms 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.

I can suggest text if you want.

That said, though I feel strongly that this should be fixed for clarity 
sake, I just got done defending the idea that there's no need to DISCUSS 
such a thing, so I will move this to a comment.

>          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?)
>
> We had this discussion a couple of times between the authors and in the WG.
>  From a protocol point of view, you are of course right -- if the
> options is elective, it can always be ignored.
>  From a quality of implementation point of view, this is a "if you
> implement this option, this is the way we expect you to".
> Sending the wrong response typically is an efficiency violation, so
> this can stay at a less-than-MUST level.
> We can turn this into an implementation note if this RFC 2119 usage is
> too offensive.
>    

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

>          ----------------------------------------------------------------------
>          COMMENT:
>          ----------------------------------------------------------------------
>
>          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.
>
> Because Observe benefits from this capability (here the sender is a
> server):  The client might have asked to observe a resource, the
> sender might be sending occasional updates, and then the client loses
> its mind (reboots).  RST is a quick way to stop the incoming messages.
>    

I suppose clients aren't required to do anything with the RST, and they 
do need to deal with random responses anyway, so no harm in having this. 
And clients who are capable of responding to this will improve things. OK.

>          3:
>
>          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?
>
> The value of the field can be 0-8, so three bits is not enough.
> (The values of 9-15 are reserved and might be used for something
> completely different in the future.)
>    

Crap. I can't count. OK.

>            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.
>
> This requires some surgery but is probably a good idea.
> ->  Ticket
>    

What you've got in -16 is fine, though I'll suggest some text in the 
updated ballot; take it if you like it.

>          4.2:
>
> "be empty" is a technical term here for code=0.
>    

Oh. That's a bummer. "Empty" is definitely confusing. "Null" or "Noop" 
probably would have been better. But again, if (like Reject) this is 
already well understood, probably just to define it clearly and move on.

>          4.5: All of the MUSTs and MAYs in the section are used rather terribly.
>          I'm glad to suggest text if you need.
>
> This is a difficult section, because it has to express all the
> lenience that is needed to make very constrained implementations work.
> Text gladly accepted.
>    

I'll have a read through the new text and send suggestions if needed.

>          4.6:
>          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.
>
> It is a bit more than an implementation note, because we are setting
> expectations for message sizes here.  This is a subject that has
> received quite a bit of discussion, and it seemed the current text has
> just the right level of firmness.  (We really need a 6919bis for this
> kind of language.)
>    

Hah! Exactly right!

I'm not going to jump up and down about this. But it still seems icky to me.

>          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.
>
> I'm picking up the "8-bit" and the reordering as an editorial comment [1306].
> (It is not meant to add anything, it's meant as explanatory.)
>    

That's fine. I understood it was explanatory; I just didn't think the 
explanation was all that helpful.

> [I'd rather write those in RFC4648 base32hex.]
>    

:-)

>          5.2.3: Potential confusion: s/the client may send a Resent message/the
>          client will send a Resent message
>
> [this is 5.3.2, and about "Reset" messages]
>    

Aside from my inability to get the number straight, I also have my 
fingers so trained to talk about email "Resent-*" fields that I can no 
longer type the word "reset" with a capital R and not sneak the "n" in 
there.

> Editorial change in [1307] (added a "likely").
>    

I think the "likely" gets you back into the problem. In what 
circumstance would the client *not* send the Reset?

>          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.
>
> Option numbers have more than 8 bits...
>    

Right. I meant put it in the high four bits of the most significant byte.

>          5.5.1: The implementation note notwithstanding, I don't understand why
>          Content-Format is not a SHOULD.
>
> This is another one of these hard-to-calibrate-the-lenience things.
> The "why" is right there, though:
>        This is
>        not a "SHOULD"-level requirement solely because it is not a
>        protocol requirement, and it also would be difficult to outline
>        exactly in what cases this expectation can be violated.
>    

Well, the second half of the "why" is not a problem; it can be a SHOULD 
even if you don't know precisely what the exceptions are. But I don't 
understand why it is not a protocol requirement. Seems like it could 
cause interoperability problems if it's missing.

>          5.10.5 s/MUST/is. The MUST is not meaningful.
>
> You MAY consider it unfresh at any time, but MUST consider it unfresh
> after Max-Age expires.  It sure means something to me.
>    

It already says that it is "the maximum time". I stand by my comment: 
You're defining the option semantics, not requiring anything.

>          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 really means "A server SHOULD spend the effort needed to be
> aware"...
>    

What SHOULD I implement to accomplish this awareness? And what do I do 
with this awareness once I accomplish it? Again, I don't get what this 
means.

As I said, I'll try to get the ballot updated ASAP. Thanks for your 
answers and your updates to the document.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478