[core] Ben Campbell's No Objection on draft-ietf-core-coap-tcp-tls-09: (with COMMENT)
Ben Campbell <ben@nostrum.com> Mon, 22 May 2017 20:09 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 396F2120454; Mon, 22 May 2017 13:09:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez <jaime.jimenez@ericsson.com>, core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149548376623.16443.17405907888159334729.idtracker@ietfa.amsl.com>
Date: Mon, 22 May 2017 13:09:26 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/FQ6d5JvyGGVdSWcXL1Du-rVisGk>
Subject: [core] Ben Campbell's No Objection on draft-ietf-core-coap-tcp-tls-09: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 May 2017 20:09:26 -0000
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.
- [core] Ben Campbell's No Objection on draft-ietf-… Ben Campbell