Re: [Lwip] Magnus Westerlund's Discuss on draft-ietf-lwig-curve-representations-19: (with DISCUSS)
Hi Rene, On Wed, Feb 17, 2021 at 08:27:41PM -0500, Rene Struik wrote: > Dear colleagues: > > I uploaded v20 of this document. It is my sincere hope that this will > help in making swift progress. > > Changes (compared to previous version v19): > - removed the cose iana requests subsections, so as to avoid further > pollution of discussion of this document (which is long overdue to get out). Is there WG consensus for this action? Note that once the draft was adopted by the WG, change control passed to the WG/the IETF, and your role becomes that of an editor, tasked with realizing the consensus positions (even when they disagree with your own). While you retain significant editorial latitude in editorial matters, I would have expected that matters such as whether or not to request allocation of IANA codepoints would be a consensus decision. > [Excerpt email RS of Feb 16, 2021, 11.50am EST; see > https://mailarchive.ietf.org/arch/msg/lwip/9SH1J3OZoiwMZ8jx49OhOlZOtAg/ ] > > The iana cose "bickering" is about the value of 6 one-word character strings, > in an otherwise quite voluminous, since 137 pages, document, where the value > could be "new" or "reuse existing" (i.e., at most six bits of entropy). The > current iana cose request may not be perfect. If it requires improvement, I > can write some text to accommodate this *in parallel* to the IESG review. For the record, I dispute this characterization on several counts. You say "bickering" where I see legitimate technical concerns that remain unanswered. (Yes, there was a statement made by one individual about previous IANA review of the COSE registrations and that statement turned out to be inaccurate. I note that the statement in question was prefaced with "to my undersanding" and the author of the statement was quick to acknowledge the correction.) I believe that the technical issues raised involve more than just the character strings (that also correspond to integer values for the CBOR encoding). In addition to the topic of what class of semantics those values are to convey, there was also a question raised relating to ECDSA on Wei25519 and the need to truncate the hash function output to a number of bits not divisible by 8. In what review of the document I have done so far I do note a fastidious (possibly excessively so) attention to bit-order of encoding, but it is not clear to me that proper prominence has been given to the need to pay attention to this concern as it relates to ECDSA over a curve that requires truncation to a non-multiple of 8 bits, and whether the behavior of the existing COSE ECDSA codepoints (which indicate specific hash functions) has been fully specified in terms of the bits to select for signature input. I do not recall seeing technical discussion to indicate that this issue has been closed (but I am only human, and would welcome a pointer to where such discussion has occurred). You say that you could write some text in parallel to the IESG review, but this document is intended to be published on the IETF stream, and per RFC 8789 all documents on the IETF stream require IETF consensus. I think it is clear from the ongoing discussions on the COSE WG list that further effort is needed to determine the consensus position on these proposed IANA registrations, and thus that it is premature for the IESG to evaluate text that is in flux and has undetermined consensus status. Thank you, Ben ___ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
Re: [Lwip] [COSE] draft-ietf-lwig-curve-representations-13
On Sun, Feb 14, 2021 at 08:13:36AM +, John Mattsson wrote: > >I uploaded a new version of the lwig curve draft [1], changing the intended > >status to "standards track". I hope > >this helps. > > You cannot just change the status from “informational” to “standards track”. > They are very different things. Informational is just general information, > while standards track means IETF consensus and recommendation. Changing the > status would (I assume) require wg consensus and then redoing the last calls. Note that since RFC 8789, IETF Consensus is required even for Informational documents (on the IETF stream). (ISE- and IRTF-stream Informational documents, of course, have no requirement for IETF Consensus.) -Ben ___ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
Re: [Lwip] Benjamin Kaduk's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)
Hi Carles, Thank you for the updates; they look good and I have no further comments. -Ben On Fri, Oct 30, 2020 at 09:38:38AM +0100, Carles Gomez Montenegro wrote: > Hi Benjamin, > > Thank you very much for your review! > > We just submitted revision -12, which aims at addressing the comments > received from the IESG and related reviewers: > https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12 > > Please find below our inline responses: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-lwig-tcp-constrained-node-networks-11: 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-lwig-tcp-constrained-node-networks/ > > > > > > > > -- > > COMMENT: > > -- > > > > Mostly just editorial nits, but please see the comment on Section 5.3. > > > > Section 2 > > > > (I believe the existence of the RFC 8174 version of the BCP 14 > > boilerplate has already been noted.) > > Thanks. In fact, since the document does not use normative language, we > removed Section 2 in the last document revision. > > > Section 3.2 > > > >or devices with a pool of multiple send/receive buffers. In the > >latter case, it is possible that buffers also be shared for other > >protocols. > > > > nit: s/be/are/ (or any number of other minor tweaks) > > Done. > > >One key use case for the use of TCP in CNNs is a model where > > > > nit: "use case for the use" is probably redundant: "use case for TCP in > > CNNs" seems like it would work okay. > > Done, thanks. > > >middlebox (e.g. a firewall, NAT, etc.). Figure 1 illustrates such > >scenario. Note that the scenario is asymmetric, as the unconstrained > > > > nit: "such a scenario". > > Done. > > > Section 3.3 > > > >o Unidirectional transfers: An IoT device (e.g. a sensor) can send > > (repeatedly) updates to the other endpoint. Not in every case > > there is a need for an application response back to the IoT > > device. > > > > (editorial) I suggest "There is not always a need for an application > > response back to the IoT device". > > Done. > > > Section 4.1.1 > > > >smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note that > >it is advised for TCP implementations to consume payload space > >instead of increasing datagram size when including IP or TCP options > >in an IP packet to be sent [RFC6691]. Therefore, the suggestion of > > > > [my reading of RFC 6691 is that it was required to consume payload > > space, but only recommended to account for this behavior when > > advertising MSS. I guess Erik covered this in his Discuss point already, > > though.] > > As per a subsequent discussion on the tcpm mailing list, we updated the > second paragraph of current Section 3.1.1 is as follows: > > NEW: >An IPv6 datagram size exceeding 1280 bytes can be avoided by setting >the TCP MSS not larger than 1220 bytes. Note that it is already a >requirement that TCP implementations consume payload space instead of >increasing datagram size when including IP or TCP options in an IP >packet to be sent [RFC6691]. Therefore, it is not required to >advertise an MSS smaller than 1220 bytes in order to accommodate TCP >options. > > > Section 5.3 > > > >The message and latency overhead that stems from using a sequence of > >short-lived connections could be reduced by TCP Fast Open (TFO) > >[RFC7413], which is an experimental TCP extension, at the expense of > >increased implementation complexity and increased TCP Control Block > >(TCB) size. TFO allows data to be carried in SYN (and SYN-ACK) > > > > We should probably make at least a passing mention of the TFO security > > considerations here, possibly with some discussion of why they are less > > consequential for
[Lwip] Benjamin Kaduk's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-lwig-tcp-constrained-node-networks-11: 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-lwig-tcp-constrained-node-networks/ -- COMMENT: -- Mostly just editorial nits, but please see the comment on Section 5.3. Section 2 (I believe the existence of the RFC 8174 version of the BCP 14 boilerplate has already been noted.) Section 3.2 or devices with a pool of multiple send/receive buffers. In the latter case, it is possible that buffers also be shared for other protocols. nit: s/be/are/ (or any number of other minor tweaks) One key use case for the use of TCP in CNNs is a model where nit: "use case for the use" is probably redundant: "use case for TCP in CNNs" seems like it would work okay. middlebox (e.g. a firewall, NAT, etc.). Figure 1 illustrates such scenario. Note that the scenario is asymmetric, as the unconstrained nit: "such a scenario". Section 3.3 o Unidirectional transfers: An IoT device (e.g. a sensor) can send (repeatedly) updates to the other endpoint. Not in every case there is a need for an application response back to the IoT device. (editorial) I suggest "There is not always a need for an application response back to the IoT device". Section 4.1.1 smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note that it is advised for TCP implementations to consume payload space instead of increasing datagram size when including IP or TCP options in an IP packet to be sent [RFC6691]. Therefore, the suggestion of [my reading of RFC 6691 is that it was required to consume payload space, but only recommended to account for this behavior when advertising MSS. I guess Erik covered this in his Discuss point already, though.] Section 5.3 The message and latency overhead that stems from using a sequence of short-lived connections could be reduced by TCP Fast Open (TFO) [RFC7413], which is an experimental TCP extension, at the expense of increased implementation complexity and increased TCP Control Block (TCB) size. TFO allows data to be carried in SYN (and SYN-ACK) We should probably make at least a passing mention of the TFO security considerations here, possibly with some discussion of why they are less consequential for certain CNNs than in general. (Note that the security considerations for TFO are not limited to just the risk of replay, and that there are privacy considerations for the TFO cookie being used to link together multiple TCP connections between the same endpoints.) Section 10.1 RFC 3819 may not need to be listed as normative, given the nature of the one place in which it is referenced. Similarly, we don't say much about TCP-AP other than it exists, so RFC 5925 may not need to be normative either. Section 10.2 RFC 6092 appears to not be referenced from anywhere? idnits notes a couple other reference-related issues. ___ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
