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

[Carsten Bormann <[e-mail]>]

Hi Gorry,

Thank you for this detailed review.

Since I'm just about to go on vacation and will be back only on June 5th, let me address the DISCUSS first.

On May 25, 2026, at 17:51, Gorry Fairhurst via Datatracker <[e-mail]> wrote:
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ———————————————————————————————————
> […]
> 
> ## 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.

Like Table 1, Table 10 does not stop at a specific level where constrained nodes are becoming less and less likely; we didn’t want to bind the definition of the term constrained node to any specific limiting metric.
MS/TP is an example of a large-MTU network that is used in constrained applications, but still 1.5 orders of magnitude below S19.

> If these links support the IP
> service with this size of frames what are the requirements would be needed?

I don’t think any the authors have worked on networks with MTU class S19.
(Well, RFC 2675 hasn’t been deprecated yet, so IP appears to support this class at least theoretically.)

> 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.

I don’t know the answer.
I now do know about the existence of draft-jones-6man-historic-rfc2675-00, but not what happened to it.
65536 is less than one order of magnitude off from widely deployed practical L2 networks’ MTUs.

> 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.

(I can offer RFC 2687 as an example for a subnet layer design that might be able to pull this off...)
But we are not really addressing questions like this for any of the classes.

> 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?

The class S19 is mainly there to be able to refer to something that is beyond what is in wide use today (note the gap to S15).
I would not be entirely happy about completely removing it, but I would see no problem with replacing the “unusual” in that row with “theoretical” or “not practically deployed”.

Grüße, Carsten