Subject: [core] Ben Campbell's No Objection on draft-ietf-core-coap-tcp-tls-09: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Mon, 22 May 2017 13:09:26 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-core-coap-tcp-tls-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Update2: I've cleared my DISCUSS position, since version 09 removed the
use of the scheme to select the transport. I would have liked to see a
bit more precision from Adam's suggested design in the section on
transport selection, but I don't consider that discuss-worthy.

Update: I removed point 1 from my discuss. But I do still think it would
be useful to add a paragraph about how COAP reliability features are only
hop-by-hop.

Subtantive:

3.2: I agree with Adam that this length scheme seems very complex for
the
return

3.3: Since the initiator can start sending messages before receiving a
CSM
from the responder, how long should the initiator wait for a CSM before
bailing?

3.4: Can you offer any guidance about how often to send keep-alives? I
note
that these keepalives are not necessarily bi-directional. Aren't there
some
NAT/FW cases where bi-directional traffic is needed to keep bindings
from
timing out?

This and other places explicitly mention that in-flight messages may be
lost
when the transport is closed or reset. This creates uncertainty about
whether
such messages have been processed or not. Is that really okay?

4: After the discussion resulting from Mark's Art-Art review, I expected
to
see more emphasis about WebSocket being intended for browser-based
clients.
There's a couple of in-passing mentions of browser-clients buried in
the
text; I would have expected something more up front.

4.2: Is it really worth making the framing code behave differently for
WebSocket than for TCP?

5.3: Do I understand correctly that once an option is established, it
cannot
be removed unless replaced? (Short of tearing down the connection and
starting over, anyway.)

7.2: The text mentions 443 as a default port, but really seems to make
5684
the default. If 443 is really a default, then this needs  discussion
about
why and why it's okay to squat on HTTPS.

The text about whether ALPN is required is confusing. Why not just
require
ALPN and move one, rather than special casing it by port choice? (There
seems
to be some circular logic about requiring 5685 to support clients that
don't
do ALPN, then saying clients MUST do ALPN unless they are using port
5685.)

7.3: I agree with Adam's DISCUSS comment. And even if people decide that
the
well-known bit can be specified in CORE, I think it does future users of
a
well-known URIs for ws a disservice to make them dig through this spec
to
find the update to 6455.  It would be better to pull that into a
separate
draft. That's also a material addition post IETF last call, so we should
consider
repeating the LC.

10.2: Is the registration policy "analogous to" that of [RFC7252] S12.2,
or
"identical to" it. If the answer is not "identical", then the policy
should be detailed here.

Editorial:

Figures 7 and 8: "Payload (if any)" - Can we assume that if one uses
either
extended length format, one has a payload?

3.3: Is the guidance about what errors to return if you don't implement
a
server any different here than for UDP?

4.3 and 4.4 seem to primarily repeat details that are the same for WS as
for
TCP, even though the introduction to the WS part says that it won't do
that
:-)

5.3: "One CSM MUST be sent by both endpoints...": s/both/each

7.6: The "updates" in this section are confusing. I understand this to
mean
that the procedures for TCP and WS are identical to those for UDP except
for
the mentioned steps. But the language of the form of "This step from
[RFC7252] is updated to:" makes it sound like this intends to actually
change
the language in 7252 to this new language. If the latter, then that
effectively removes UDP support from 7252 as updated.

This could easily be fixed by changing that to something to the effect
of
"When using TCP, this step changes to ..."

Appendix A: Why is this an appendix? Updates to a standards track RFC
seem to
warrant a more prominent position in the draft.