Re: [Raw] Roman Danyliw's Discuss on draft-ietf-raw-use-cases-08: (with DISCUSS and COMMENT)

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

Hi John,

Revision -11 should address remaining points from Roman, plus one on LEO
that was made by another reviewer and was also pending.

Please let me know if something else is missing from our side.

Thanks!

Carlos

On Mon, Apr 10, 2023 at 8:51 AM CARLOS JESUS BERNARDOS CANO <[e-mail]>
wrote:

> Dear John,
>
> Sorry for the late reply. These two points are still pending. I have
> not received any reply yet from the aeronautical experts on the WG.
> Maybe Corinna can help? Corinna, you were in the CC of the e-mails I
> sent to Nils asking for help.
>
> Thanks!
>
> Carlos
>
>
> On Mon, Apr 3, 2023 at 3:41 PM John Scudder <[e-mail]> wrote:
> >
> > Hi Carlos and all,
> >
> > You replied to two of Roman’s COMMENT points with “this is pending”. Can
> you let me know if these points are still pending, or if they’ve been
> resolved, what the resolution was?
> >
> > Thanks,
> >
> > —John
> >
> > > On Mar 13, 2023, at 2:43 PM, CARLOS JESUS BERNARDOS CANO <
> [e-mail]> wrote:
> > >
> > >
> > > Hi Roman,
> > >
> > > Apologies for the belated follow up on this. Please see inline how we
> have addressed the comments (in rev -09).
> > >
> > > On Tue, Nov 29, 2022 at 11:46 PM CARLOS JESUS BERNARDOS CANO <
> [e-mail]> wrote:
> > > Hi Roman,
> > >
> > > Thanks a lot for your review. Please see inline some responses on how
> we propose to address your comments.
> > >
> > > On Thu, Nov 17, 2022 at 6:22 PM Roman Danyliw via Datatracker <
> [e-mail]> wrote:
> > > Roman Danyliw has entered the following ballot position for
> > > draft-ietf-raw-use-cases-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-raw-use-cases/
> > >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > >
> > > Section 12 states the situation accurately – “Each of the potential RAW
> > > use-cases will have security considerations from both the use-specific
> > > perspective.”  Where are these security and privacy considerations for
> these
> > > uses cases discussed?  Are these in scope to solve for RAW?  A select
> list to
> > > review would be:
> > >
> > > ** Section 3.*. Per the amusement park use case, what are the physical
> location
> > > tracking and surveillance considerations?
> > >
> > > ** Section 7.*.  Per the vehicle platooning use case, what are the
> physical
> > > location tracking privacy considerations?
> > >
> > > ** Section 8.*. Per the edge robotics use case, what are the privacy
> > > considerations of the video surveillance?
> > >
> > > ** Section 9.*.  Per the ambulance use case, what are the security
> > > considerations around exchanging health care information over a
> wireless WAN?
> > >
> > > A clearer distinction of what is to be addressed at the protocol
> level, and
> > > what seems like an application consideration is needed.
> > >
> > > [Carlos] This is a good point to clarify. We have followed the same
> approach as in the DETNET use cases document (RFC 8578). The RAW use cases
> document aims at documenting different use cases of interest for RAW, and
> documenting their demands in terms of rea liability and availability. The
> document does not go into the per-use case privacy and security
> considerations of potential future RAW solutions. As of today, the RAW WG
> is not chartered to work on solutions (it might be done in RAW or DETNET).
> We believe that the specific privacy and security considerations for the
> solutions would belong to a different document. Do you think we should be
> specific about this in the document? We borrowed some text from RFC 8578 to
> be consistent with the approach that DETNET followed.
> > >
> > > [Carlos] We have added 1-2 sentences per-use case to clarify, in
> addition to some other edits.
> > >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > >
> > > ** Section 1.
> > >    Reliable and
> > >    Available Wireless (RAW) is an effort to provide Deterministic
> > >    Networking Mechanisms on a multi-hop path that includes a wireless
> > >    physical layer.
> > >
> > > Is this RAW the “RAW WG”?  If so, the WG doesn’t appear to be
> chartered to
> > > provide the described solution.
> > >
> > > [Carlos] It's true that the RAW WG is not chartered as of today to
> provide solutions, but it is to provide an architecture/framework. We took
> the text from the charter with small adaptations, but I agree that we can
> probably rewrite the text to be more precise. Would the following text be
> more appropriate?
> > >
> > > "The term RAW stands for Reliable and Available Wireless, and refers
> to the mechanisms aimed for providing high reliability and availability for
> IP connectivity over a wireless medium."
> > >
> > > [Carlos] We have performed this change.
> > >
> > >
> > >
> > > ** Section 2.5.
> > >
> > >    Different safety levels need to be supported, from extremely safety
> > >    critical ones requiring low latency, such as a WAKE warning - a
> > >    warning that two aircraft come dangerously close to each other - and
> > >    high resiliency, to less safety critical ones requiring low-medium
> > >    latency for services such as WXGRAPH - graphical weather data.
> > >
> > > I can appreciate the abstract idea of using certain information for
> safety
> > > critical decision making.  However, can more detail be provided to
> translate
> > > the “safety levels” to requirements of the data link or the “RAW
> protocol”?
> > > Mentioned already seems to be “low” vs. “low-medium” latency; and “high
> > > resiliency” which should be read as guaranteed delivery or ability to
> use
> > > multiple paths/radio technologies?  Or is “low latency” translated
> into a
> > > design as the subsequent text suggests of “small packets” and
> resiliency
> > > primarily about “choosing links”
> > >
> > > [Carlos] This is a good point to clarify. I will work with the
> aeronautical experts in the WG to clarify these points and make the text
> more clear.
> > >
> > > [Carlos] This is pending, waiting for input from the aeronautical
> experts in the WG.
> > >
> > >
> > > ** Section 2.5.*.  Low latency is stated as a requirement a few
> times.  Can
> > > this be expressed quantitatively?  Use case owners (and readers) might
> have
> > > their own subjective idea of what constitutes “low”.
> > >
> > > [Carlos] Same as above, we will express this quantitatively in the
> next revision of the document.
> > >
> > > [Carlos] This is also pending, waiting for input from the aeronautical
> experts in the WG.
> > >
> > >
> > >
> > > ** Section 3.1.
> > >    Such
> > >    deployment is a mix between industrial automation (i.e., Smart
> > >    Factories) and multimedia entertainment applications.
> > >
> > > In what way is “industrial automation” and “Smart Factories” the same
> in this
> > > example?  One seems to connote automation of operational technology
> (as opposed
> > > to IT).  The other seems to be a marketing term for OT building things
> – I’m
> > > not sure.
> > >
> > > [Carlos] We used the terms not to be synonyms. We refer to industrial
> automation as automating processes in an industrial environment. And we use
> "Smart factories" to refer to factories that are actually making use of
> automated processes. Note that for example a warehouse making use of some
> automated processes could fall under "industrial automation", but it would
> not be a "smart factory". Maybe this is too convoluted and it just easier
> to remove the "(i.e., Smart Factories)" from the original text. Would you
> agree?
> > >
> > > [Carlos] We have removed the term Smart Factories there and performed
> some edits to clarify the mix of multimedia and non-multimedia applications.
> > >
> > >
> > > ** Section 3.2.
> > >       Some non-time-critical tasks may
> > >       rather use the cloud (predictive maintenance, marketing).
> > >
> > > -- Marketing is mentioned as an example of a computational workload
> appropriate
> > > for the cloud but it isn’t noted as an application in Section 3.1.
> Perhaps it
> > > should be made more explicit.
> > >
> > > [Carlos] Good catch. We would add a small description in Section 3.1.
> > >
> > > [Carlos] We have added some text regarding Marketing in section 3.1
> and do some edits as well in the predictive maintenance part.
> > >
> > >
> > > -- If these tasks are “non-time-critical”, why can’t traditional
> wireless
> > > technologies address them (i.e., why can’t they be solved without RAW)?
> > >
> > > [Carlos]  This is specifically addressed in section 3.4.1. Basically,
> the reasons are that these applications that mostly demand reliability.
> > >
> > > [Carlos] This is addressed in section 3.4.1. Additionally, we have
> elaborated a bit more on the point that the network infrastructure should
> limit the resource consumption for these delay-tolerant applications.
> Typically, scheduling low-priority flows that use the unused high-priority
> resources may save energy and bandwidth without impacting the other flows.
> Wireless networks force us to consider frugality. We have added some text
> in 3.4 about this.
> > >
> > >
> > > ** Section 4.2.1
> > >    A rare packet loss is usually admissible, but
> > >    typically 4 losses in a row will cause an emergency halt of the
> > >    production and incur a high cost for the manufacturer.
> > >
> > > What is the basis for the “4 losses” (as opposed to say 3 or 5)?  Can
> this be
> > > cited with a reference?
> > >
> > > [Carlos] Honestly, I don't remember, but I will check with the
> contributors and we will definitely amend the text and/or provide a
> reference. Thanks for pointing it out.
> > >
> > > [Carlos] We have rewritten the text a bit to avoid giving an exact
> number and just explain that multiple losses in a row would be problematic.
> > >
> > >
> > > ** Section 6.1.
> > >       But Wi-Fi has an
> > >       especially bad reputation among the gaming community.  The main
> > >       reasons are high latency, lag spikes, and jitter.
> > >
> > > This statement is suggestion a subjective assessment of the user
> experience.
> > > Is it technically accurate?
> > >
> > > [Carlos] I believe it is accurate in the sense that this is indeed the
> reputation it has. I understand the term "reputation" implies subjectivity,
> but it is probably a mistake from me as non-native English speaker. I know
> from experiments with 5G and gaming to basically improve the gaming
> experience over 4G and WiFi, but I think there are no public documents I
> can reference. I'll try to find some good reference for this.
> > >
> > > [Carlos] We have kept it for the reasons above, but we are happy to
> remove that specific sentence if you don't agree with our interpretation of
> the term "reputation".
> > >
> > >
> > >
> > > ** Section 6.1.  The use cases seem to overlap:
> > >
> > > -- Can one do “real-time mobile gaming” on a “wireless console”?
> > >
> > > -- Are “cloud gaming” and “wireless console” mutually exclusive
> categories?
> > > Can’t an Xbox use Wi-Fi 5 to use the “Xbox Cloud Gaming” service?
> > >
> > > [Carlos] You are right, they overlap and they are not meant to be
> mutually exclusive. Should we make this explicit in the text?
> > >
> > > [Carlos] We have made explicit that they are not meant to be mutually
> exclusive.
> > >
> > >
> > > ** Section 7.1
> > >
> > > the Spanish traffic control has recently introduced
> > >    a fleet of drones for quicker reactions upon traffic congestion
> > >    related events
> > >
> > > Could a reference please be provided.
> > >
> > > [Carlos] Yes, we will add one.
> > >
> > > [Carlos] We have added a ref (in Spanish).
> > >
> > >
> > >
> > > ** Section 8.2.  What is “very low latency” in this context?
> > >
> > > [Carlos] We will quantify that in the next revision.
> > >
> > > [Carlos] We have quantified and added a reference.
> > >
> > >
> > >
> > > ** Section 9.1.  I don’t have any insight into how a network
> infrastructure is
> > > built on an ambulance.  Are these systems all really on the same LAN in
> > > practice now?  Is the navigation systems connected to the vital signs
> sensor?
> > > Don’t these discrete functions all function as their own WWAN?
> > >
> > > [Carlos] I will discuss these points with the people that contributed
> that use case to address your comments.
> > >
> > > [Carlos] We have addressed this with the help of the people that
> contributed to this use case. Basically this is not fully defined, but what
> is important is that these systems all have a report-back function.
> > >
> > >
> > >
> > > ** Section 9.1.  What is a “radio-WAN”?  Is this the same as a
> wireless WAN?
> > >
> > > [Carlos] I'd say so, but I will check with the contributors of that
> specific section.
> > >
> > > [Carlos] We have addressed this with the help of the people that
> contributed to this use case. We use this term to refer to a radio network
> in the interior of a network (as opposed to in the fringe). The
> characteristics of a radio-WAN is that the surrounding networks are likely
> to be higher capacity than the radio-WAN itself (by orders of magnitude) so
> the radio-WAN can be expected to be saturated.
> > >
> > >
> > >
> > > ** Section 9.4.  What is “high availability” in this context?
> > >
> > > [Carlos] We will clarify in the next revision.
> > >
> > > [Carlos] We have addressed this with the help of the people that
> contributed to this use case.
> > >
> > >
> > >
> > > Editorial
> > >
> > > [Carlos] Thanks a lot for all the good catches and clarifying
> comments. We will address them all in the next revision.
> > >
> > > [Carlos] We have addressed the comments in version -09.
> > >
> > > Thanks a lot for the very good review comments!
> > >
> > > Carlos
> > >
> > >
> > > Thanks a lot!
> > >
> > > Carlos
> > >
> > > ** Section 1.  Editorial.  “Deterministic Networking in the IP world
> …” uses
> > > colloquial, consider rephrasing.
> > >
> > > ** Section 1.  Editorial
> > > So far, Open Standards for Deterministic Networking ...
> > >
> > > Why is “Open Standards for Deterministic Networking …” capitalized?
> Which of
> > > these are proper nouns?
> > >
> > > ** Section 2.3.  Typo. s/accomodate/accommodate/
> > >
> > > ** Section 2.4.  Editorial.
> > > Thus, making use of wireless
> > >    technologies is a must
> > >
> > > Consider alternative language to this colloquial syntax.
> > >
> > > ** Section 3.1.  Editorial
> > >    *  Emergency: safety has to be preserved, and must stop the
> > >       attraction when a failure is detected.
> > >
> > > Consider being clearer on safety for whom – is it the attraction
> operator and
> > > visitor/rider/bystander?
> > >
> > > ** Section 3.3.  Editorial.
> > >    Wireless also increases the
> > >    reconfigurability, enabling to update an attraction at a lower cost.
> > >    The frequent renewal helps to increase the customer loyalty.
> > >
> > > This first sentence doesn’t parse for me.  As such, I don’t follow the
> link to
> > > customer loyalty in the second sentence.  Is the idea here that
> wireless allows
> > > the attractions to be swapped or adapted more frequently than if a
> wired
> > > network was used? In turn, this variability of offerings in the
> amusement park,
> > > attracts repeat visits by customers.
> > >
> > > ** Section 4.2.1.  Editorial.
> > >    Finally, some industries exhibit
> > >    hybrid behaviors, like canned soup that will start as a process
> > >    industry while mixing the food and then operate as a discrete
> > >    manufacturing when putting the final product in cans and shipping
> > >    them.
> > >
> > > The discrete steps of “process industry”, “discrete manufacturing”
> aren’t
> > > explained; and don’t link to the previous narrative of “process
> control”,
> > > “factory automation” or “motion control”.
> > >
> > > ** Section 4.2.2.  Editorial.  Consider replacing the colloquial
> phrases:
> > > --  “Holy Grail of the Industrial Internet of Things”.
> > >
> > > -- “carpeted floor over IP”
> > >
> > > ** Section 4.3.  Editorial. s/a few thousands of flexions/a few
> thousand
> > > flexions/
> > >
> > > ** Section 4.4.  Editorial.
> > >   RAW mechanisms should be
> > >    able to setup a Track
> > >  Should “Track” be capitalized?
> > >
> > > ** Section 5.3.
> > >
> > >    Deployed announcement speakers, for instance along the platforms of
> > >    the train stations, need the wireless communication to forward the
> > >    audio traffic in real time.
> > >
> > > Why do train stations needed wireless communication (as opposed to
> wired being
> > > acceptable)?
> > >
> > > ** Section 6.1.  Is “Real-Time Mobile Gaming” assuming that the
> connected
> > > players and game servers are using the Internet to connect them?  How
> can RAW
> > > help then?
> > >
> > > ** Section 6.1.  Editorial.
> > > *  Wireless Console Gaming: Playing online on a console has 2 types
> > >       of internet connectivity, which is either wired or Wi-Fi.
> > >
> > > Isn’t the definition of “wireless console gaming” that a wireless
> connection is
> > > used?  The distinction to wired doesn’t make sense to me.
> > >
> > > ** Section 6.4.  Typo. s/importan/important.
> > >
> > > ** Section 9.  Editorial. Is an “Instrumented emergency vehicle” only
> scoped to
> > > “emergency medical vehicles”?  If so, I recommend renaming the section.
> > >
> > > ** Section 9.4.  Editorial. Can “radio footprint” be more precisely
> defined.
> > > Does this mean a seamless hand-off approach is needed between multiple
> > > base-stations of some kind to keep the radio connected?
> >
>