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,

You were right. It should be ok now.

Thanks,

Carlos

On Mon, 17 Apr 2023 at 16:29, John Scudder <[e-mail]> wrote:

> Hi Carlos,
>
> Thanks. It looks like revision 11 still needs to be published. I see you
> uploaded it but Datatracker says the state is “Request for posting
> confirmation emailed to previous authors: Carlos Bernardos , Fabrice
> Theoleyre , Georgios Papadopoulos , Pascal Thubert”. Probably you have an
> approval email sitting in your inbox somewhere, that you need to click
> through on?
>
> I guess you were not logged in to Datatracker when you did this upload,
> unlike earlier ones, which is why the behavior is different.
>
> —John
>
> > On Apr 17, 2023, at 6:45 AM, CARLOS JESUS BERNARDOS CANO <
> [e-mail]> wrote:
> >
> >
> > 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?
> > >
>
> --
Sent from a mobile device, please excuse any brevity or typing errors.