I have no objection for publication of this document as Informational. Many thanks to Valery Smyslov for the ARTART review.

Thanks for the work done in this document. Some comments though:

1) the document use "*small* device" while the constraints are not always linked to the physical size (e.g., deepspace sensors), so suggest to simply use "device" (albeit it does not cover virtual devices)

2) about the 'limited bandwidth', should IoT also cover 'intermittent connectivity' ? (mainly in sections 1 and 2.1)

3) suggest expanded LLN also in the section title

4) I find section 3.3 *VERY UNSPECIFIED* for a BCP. I am trusting the Security AD whether this is 'enough'.

Thanks for providing this informational document to define these reference terms.

I have some COMMENTS (non-blocking). These I think are easy to fix by choosing appropriate words:

## In the following: "with elaborate network stacks" I do not have a clear picture of what constitutues an "elaborate" stack, rather than one that is sophisticated, or something else. Is there a better choice of words?

## In the following: "elaborate sleep modes" - similarly I wonder if another word would be clearer?

## The term: "extreme measures" - I hope an IETF RFC could find a better word that "extreme" to describe sophisticated power saving..

## I stumbled at: "and above often create islands of higher MTU in an otherwise Ethernet-inspired Layer 2 network." - Is it possible to rephrase this, because Ethernet is not universally constrained and the clause does not really explain that typical frames are limited by common Ethernet MTU sizes?

## The words: "he relative increase in energy expenditure during reattachment may be acceptable" lead me to ask acceptable for whom? - I presume this might fall within the power budget, but some refinement in teh words would be helpful.

Thanks to Marcus Ihlar for his helpsful IETF Last Call Review submitted for his Transport Area Review Team, and for the resolutions proposed in -08.

Best wishes,
Gorry

Notes:
## I discussed how to understand the basis and safety of class S19 defined in Section 5.1, now resolved.

** Section 3.3	 

3.3.  Shielded Secrets	
   Some platforms can keep secrets shielded (usually in conjunction with	
   secure enclave functionality).  Refer to Table 4 for more details.	
   Note that Sh9 is aspirational language; no real hardware can achieve	
   this.	
 		
                 +======+================================+	
                 | Name | Secret shielding functionality |	
                 +======+================================+	
                 | Sh0  | no secret shielding            |	
                 +------+--------------------------------+	
                 | Sh1  | some secret shielding          |	
                 +------+--------------------------------+	
                 | Sh9  | perfect secret shielding       |	
                 +------+--------------------------------+
Is there any narrative text that can be added to describe what these qualitative categories mean.  A few examples:

-- what is “secret shielding”?  For example: Is this a hardware or software function/only hardware?  Would putting a sticker over screws of a chassis qualify as “some secret shielding” or “no secret shielding”?

-- Is the scale here “no shielding” (Sh0) vs. something more than nothing but less that the unachievable perfection (Sh1) vs. “something that doesn’t exist” (Sh9)?  If Sh9 us not attainable, isn’t this really a two-scale list of “nothing” vs. “more than nothing”?

-- Against what class of threat is “perfect secret shielding” protecting against?

-- Given the qualitative definitions, one risks different reviewers assessing a given hardware item in different ways.  It is unclear if this is a problem for the intended use of this terminology.