[Last-Call] Re: [art] draft-ietf-iotops-7228bis-06 ietf last call Artart review

[Valery Smyslov <[e-mail]>]

Hi Carsten,

thank you for addressing my concerns. The proposed changes look good to me.

Regards,
Valery.

> Hi Valery,
> 
> thank you for this review!
> 
> We created a common PR clarifying our use of MSL, motivated by the comments we got on MSL:
> 
> https://github.com/lwig-wg/terminology/pull/19/changes
> 
> We also created a PR trying to cover the improvements you specifically suggested:
> 
> https://github.com/lwig-wg/terminology/pull/24/changes
> 
> On 2026-04-23, at 14:10, Valery Smyslov via Datatracker <[e-mail]> wrote:
> > […]
> > Nits:
> > 1. The purpose of the note below Table 10 (the text in parentheses: "'Sx'
> > stands for 'Size x'") is not clear to me. […]
> 
> Indeed, it is better to explain the name in the text referencing the table, which we now do.
> 
> > 2. Section 5.3
> > I do not think that reference to MSL in the context of B0 networks is relevant.
> > MSL is only defined for TCP and I doubt if nodes connected to B0 network will
> > use TCP. In any case, MSL in TCP is only concerned with the chance for SN
> > repeat after host reboots. Referring to COAP's MAX_LATENCY value (discussed in
> > I-D.gomez-tiptop-coap) is more appropriate in this context, but its default
> > value is 100 (and not 120 as MSL).
> 
> We added a reference to CoAP’s MAX_LATENCY, but decided to continue TCP’s MSL as the main yardstick when
> defining our classes, clarifying that this usage is just an example for protocol or application behavior that makes
> some assumption on a maximum latency in this general vicinity.
> 
> > 3. Section 5.3
> > I also think that 62.5 bytes calculated here must be rounded to the full number
> > of bytes (I assume that all protocols operate on byte boundary and cannot send
> > say 62.3 bytes to remain "responsive" in B1 networks).
> 
> Indeed.  We use ≥ 63 now (which is still a bit too exact for this metric, but that’s what the arithmetic gives us).
> 
> You can see the changes in the context of all the IETF last-call related changes at
> 
> https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-iotops-7228bis&url_2=https://lwig-
> wg.github.io/terminology/draft-ietf-iotops-7228bis.txt
> 
> Of course, IESG processing continues, so any further comments are welcome.
> 
> Grüße, Carsten