[Iotops] Gorry Fairhurst's Discuss on draft-ietf-iotops-7228bis-08: (with DISCUSS and COMMENT)

[Gorry Fairhurst via Datatracker <[e-mail]>]

Gorry Fairhurst has entered the following ballot position for
draft-ietf-iotops-7228bis-08: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-iotops-7228bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work that has been put into this document. Please find below
one blocking DISCUSS point (easy to address or help me understand), and some
non-blocking COMMENT points/nits.

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise. I hope that this review helps to improve the document.

## I'd like to understand the basis and safety of class S19 defined in Section
5.1:

Can you expand the descriptions to provide counter examples of this support in
Constrained-Node Networks, because I doubt that class S19, defining a frame
size ≥ 65536 is actually realistic and safe. If these links support the IP
service with this size of frames what are the requirements would be needed? I'd
like to understand the types of physical-layer error detection methods and
synchronisation that can be used to safely deploy such an approach for an IP
service. For example, I am also curious about how such large frames would be
multiplexed with any other packets at transmission rates expected of
Constrained-Node Networks, to avoid long periods of head-of-line blocking.

As a possibly simpler alternative (if this could be acceptable), is it possible
this document would still be useful without the class S19 entry in the table?


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

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.

Best wishes,
Gorry