Hi, Hannes, I see your point about preprocessor directives to derive different versions of binaries based on the same code. The point I was trying to make was different though. When I said " the same stack could be used for scenarios outside of IoT", I meant at the same time. This can happen either because a device participates simultaneously in both the IoT and the general domain (using mainstream IETF protocols), or because the lines between both become blurry. I believe in the future we will see more and more of the lines becoming blurrier as mainstream protocols become better profiled and/or adapted for certain IoT scenarios (as we've seen with other industries in the past). Thanks for your response, and I'm glad the proposed wording is ok with you. Gabriel > -----Original Message----- > From: dtls-iot [mailto:dtls-iot-bounces@xxxxxxxx] On Behalf Of Hannes > Tschofenig > Sent: Tuesday, September 8, 2015 12:24 > To: g_e_montenegro@xxxxxxxxx; ietf@xxxxxxxx > Cc: dtls-iot@xxxxxxxx > Subject: Re: [Dtls-iot] Last Call: <draft-ietf-dice-profile-14.txt> (TLS/DTLS > Profiles for the Internet of Things) to Proposed Standard > > Hi Gabriel, > > thanks for your review comments. > > I am OK with the proposed text changes. > > A minor remark regarding the stacks used in IoT devices: In the stacks I have > seen the developer has the possibility to include or exclude certain features > using preprocessor directives. Even if you have the ability to re-use a > TLS/DTLS stack on devices that have nothing to do with IoT and have no code > size restriction you will typically have to remove features for an IoT device to > keep the code size at a reasonable level. > > I am, of course, aware of devices that have very few limitations in terms of > processing speed, RAM, and flash size. The boundaries between IoT devices > and non-IoT devices is certainly fuzzy. > > Ciao > Hannes > > On 09/04/2015 01:21 AM, g_e_montenegro@xxxxxxxxx wrote: > > Overall, looks good, thanks for this work. I do have some comments. > > > > Not sure if these are "substantive comments" as requested, but after > > some discussion with some collegues we'd like to point out issues with > > some of the normative language. > > > > In particular, we suggest modifying the language here: > > > > Hence, RFC 7366 and RFC 6066 are not applicable to this specification > > and MUST NOT be implemented. > > > > Whereas CCM and AEAD ciphers in general render RFC7366 moot, a MUST > > NOT on implementation is too strong (i.e., from the intro, "This > > document does not alter TLS/DTLS specifications") and potentially > > damaging: the same stack could be used for scenarios outside of IoT, > > where RFC7366 could still provide some benefit. As for RFC6066, a > > blanket statement saying it "MUST NOT implement" is not only wrong, it > > is also contradictory with other statements within this draft which > > recommend other parts of RFC6066. Instead, the language should limit > > itself to the specific extension of RFC6066. > > > > Also, with other extensions the doc does not prohibit > > *implementation*, but recommends against it or against its use (by > > using "NOT RECOMMENDED"). So I'd change the above text to something > like: > > > > In https://tools.ietf.org/html/draft-ietf-dice-profile-14#section-15: > > OLD: > > Hence, RFC 7366 and RFC 6066 are not applicable to this > > specification and MUST NOT be implemented. > > NEW: > > Hence, RFC 7366 and the Truncated MAC extension of RFC 6066 > > are not applicable to this > > specification and are NOT RECOMMENDED. > > > > Similarly, in > > https://tools.ietf.org/html/draft-ietf-dice-profile-14#section-10 my > > suggestion would be: > > OLD: > > This TLS/DTLS profile MUST NOT implement TLS/DTLS layer > compression. > > NEW: > > TLS/DTLS layer compression is NOT RECOMMENDED by this TLS/DTLS > > profile. > > > > thanks, > > > > Gabriel > > > > > > > > On Friday, August 21, 2015 6:53 AM, The IESG <iesg-secretary@xxxxxxxx> > > wrote: > > > > > > > > > > The IESG has received a request from the DTLS In Constrained > > Environments > > WG (dice) to consider the following document: > > - 'TLS/DTLS Profiles for the Internet of Things' > > <draft-ietf-dice-profile-14.txt> 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@xxxxxxxx <mailto:ietf@xxxxxxxx> mailing lists by 2015-09-04. > > Exceptionally, comments may be > > sent to iesg@xxxxxxxx <mailto:iesg@xxxxxxxx> instead. In either > > case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > A common design pattern in Internet of Things (IoT) deployments is > > the use of a constrained device that collects data via sensor or > > controls actuators for use in home automation, industrial control > > systems, smart cities and other IoT deployments. > > > > This document defines a Transport Layer Security (TLS) and Datagram > > TLS (DTLS) 1.2 profile that offers communications security for this > > data exchange thereby preventing eavesdropping, tampering, and > > message forgery. The lack of communication security is a common > > vulnerability in Internet of Things products that can easily be > > solved by using these well-researched and widely deployed Internet > > security protocols. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > > > _______________________________________________ > > dtls-iot mailing list > > dtls-iot@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/dtls-iot > >