Re: [Last-Call] Tsvart last call review of draft-ietf-raw-use-cases-07

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Dear Joerg,

Thanks a lot for your review. Please see inline below how we are addressing
your comments in rev -08.

On Thu, Oct 6, 2022 at 5:40 PM Joerg Ott via Datatracker <[e-mail]>
wrote:

> Reviewer: Joerg Ott
> Review result: Almost Ready
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> [e-mail] if you reply to or forward this review.
>
> The draft discusses use cases for the Reliable and Available Wireless WG;
> in fact, it "extends" on existing documents.
>
> Being a use case document, the draft doesn't really have specific transport
> related issues per se, but a few points below -- some of more general
> nature -- are worth considering.
>
> Maybe section 1 can avoid using the term transport in the context of the
> underlying carrier network and use a different term more compatible with
> IETF terminology instead. Link? Network? L2?
>

[Carlos] Thanks, done.


>
> The document discussed quite a diverse set of use cases but does so at
> very different depth and level of detail.  In one case, concrete
> requirements
> are hinted at in terms of milliseconds of latency but no others mention
> these.
> I understand that this is not a requirements document but if something is a
> specific use case for RAW, maybe we can be more specific than saying data
> needs to be carried within some time bound across a wireless link?  I
> believe
> being more concrete may help the group decide which types of mechanisms are
> to be applied for which use cases.
>

[Carlos] This is a good point but not that simple to tackle. We have
incorporated the input that has been made available by the WG participants.
It's true that it is not at the same level across all the use cases. This
sometimes has to do with the fact that some use cases actually group
several possible applications with different quantitative requirements.
Since the document is not a pure requirements document, we believe the
level of detail is sufficient to help future developments in the RAW/DETNET
WGs regarding what the solutions have to provide.


> Section 5.2.2: With audiovisual communication having a long history in the
> IETF, there is clearly an awareness of what it takes to do smooth playback
> and synchronized playback: playout buffers. These, of course, would add
> latency, so the point made here is well taken but it should be put into the
> context of A/V over packet networks.
>

[Carlos] Not sure if you suggest adding here some text to clarify that this
is in the context of packet networks. I've added something but I'm not sure
if this addresses your point completely.


> When discussing especially the non-latency critical considerations
> (e.g., in section 5.4.1), keep in mind that the IETF offers many protocols
> that could quite easily cope with packet losses, add redundancy, also
> across
> multiple paths.  These protocols operate above the link and IP layer,
> typically at the transport layer or, e.g., with Application Layer Framing,
> even at the application layer.  I would thus urge the authors to not have
> the
> document suggest that certain mechanisms need to be addressed with the
> scope
> of RAW or the layers below.  This would appear beyond scope of a use case
> draft and also too limiting.
>

[Carlos] I agree on the comments about the mechanisms above the link and IP
layer. This document does not neglect nor prevent those to be in place. But
in the context of the heterogeneous and/or multi-hop wireless networks that
RAW considers, there might be additional actions that can also be taken to
improve non-latency critical aspects, in the same way that DETNET does for
multi-hop wired environments. I think it is useful to highlight that in the
document. This was added in the document after some discussion in the WG
requesting it.


> Finally, the document suddenly mentions security properties in section 9.4.
> This appears inconsistent as such considerations likely apply to all other
> use case as well and there may be little the RAW WG can do here (especially
> when security is suggested to be end-to-end).
>

[Carlos] I agree. I've removed that part.


>
> Nits:
> -- articles missing in numerous places -> RFC Editor?
> -- "communications system" -> "communication systems"
> -- communication's requirements -> communication requirements
> -- network's edge device -> network edge device
> -- inter-network
>

[Carlos] Fixed, thanks.

Thanks a lot,

Carlos