Reliable and Available Wireless (RAW) Use Cases
draft-ietf-raw-use-cases-11

[Ballot comment]
Thank you for addressing my DISCUSS and substantive COMMENTs.

===

** 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”

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

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

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


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

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-raw-use-cases-08
CC @evyncke

Thank you for the work put into this document. I really like the common format used for all the use cases.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Corinna Schmitt for the shepherd's detailed write-up including the WG consensus *but* with a very weird justification of the intended status.

Please note that Suresh Krishnan is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well:
https://datatracker.ietf.org/doc/review-ietf-raw-use-cases-08-intdir-telechat-krishnan-2022-11-28/ (I saw that Carlos has already replied)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Shepherd's write-up

The justification for the intended status is really weird and outdated (such write-ups can be updated):
```
Standard Track is mentioned, but reading it I assume “Informational” is meant.
Request is send out.
```

### Quantitative approach ?

While this I-D is easy and interesting to read, it would have been more useful if actual numbers were given per use case, e.g., bounded latency, max packet loss, ...

### Section 1

Is the use of capitalized "Deterministic Networking" a reference to the work of the DETNET WG ? Then, let's state it else suggest not to use capitalized words. Later in the text "DetNet" is used, it would be nice to use a common naming.

### Section 4.3

Are "Ethernet cables" still used ? As opposed to optical fiber (notably for noise reduction)

### Section 5

Suggest to add a reference to RFC 9317 "Operational Considerations for Streaming Media"

### Section 7

Like Murray, I wonder whether DRIP & IPWAVE WGs were made aware of this section.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-raw-use-cases-08
CC @evyncke

Thank you for the work put into this document. I really like the common format used for all the use cases.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Corinna Schmitt for the shepherd's detailed write-up including the WG consensus *but* with a very weird justification of the intended status.

Please note that Suresh Krishnan is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well:
https://datatracker.ietf.org/doc/review-ietf-raw-use-cases-08-intdir-telechat-krishnan-2022-11-28/ (I saw that Carlos has already replied)

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

###

## COMMENTS

### Shepherd's write-up

The justification for the intended status is really weird and outdated (such write-ups can be updated):
```
Standard Track is mentioned, but reading it I assume “Informational” is meant.
Request is send out.
```

### Quantitative approach ?

While this I-D is easy and interesting to read, it would have been more useful if actual numbers were given per use case, e.g., bounded latency, max packet loss, ...

### Section 1

Is the use of capitalized "Deterministic Networking" a reference to the work of the DETNET WG ? Then, let's state it else suggest not to use capitalized words. Later in the text "DetNet" is used, it would be nice to use a common naming.

### Section 4.3

Are "Ethernet cables" still used ? As opposed to optical fiber (notably for noise reduction)

### Section 5

Suggest to add a reference to RFC 9317 "Operational Considerations for Streaming Media"

### Section 7

Like Murray, I wonder whether DRIP & IPWAVE WGs were made aware of this section.

## NITS

### Section 2

s/Aircraft are /Aircrafts are /

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
I support Roman's DISCUSS, and I find Martin's ABSTAIN discussion to be compelling.

Just out of curiosity, was the DRIP WG consulted for any input or feedback regarding Section 7?

[Ballot comment]
Thank you for the document, I found it to be an informative read that was clear and well-written.

I do, however, find myself supporting Roman's discuss.

[Ballot comment]
I see no flaws in this Informational document that rise to the level of a DISCUSS, but its current form I don't think it is a particularly useful contribution to the RFC series. It would need a major revision to reach that level, in my opinion.

Broadly speaking, the document describes a number of wireless use cases, but doesn't create a unified framework of requirements associated with them, certainly doesn't make the case that a detnet-style solution is appropriate. Here is a non-exhaustive list of examples:

(2.3) "It is necessary to keep latency, time and data overhead of new aeronautical datalinks at a minimum."

'At a minimum' is not a real requirement: these things are always traded off against other design considerations. A completely integrated, bespoke protocol stack with custom hardware all along the path is always the way to get "minimum" latency, but this is impossible in practice. Instead, there should be a number attached to the metric, or at least "similar latency to interactive voice", or whatever.

(3.4) "The network infrastructure must support heterogeneous traffic, with very different critical requirements. Thus, flow isolation must be provided."

Individual identification of flows doesn't follow at all. The whole concept of Diffserv is to provide differentiated services without identifying individual flows.

(6.4.1) "But note that in most of these scenarios, part of the communication path is not wireless and DetNet mechanisms cannot be applied easily (e.g., when the public Internet is involved), and therefore in these cases, reliability is the critical requirement."

If I read this correctly, it's saying "low latency would be nice but we can't actually guarantee it". Reliability without hard latency bounds already has a solution: TCP.

(8.4) "When a given service is decomposed into functions -- hosted at different robots -- chained, each link connecting two given functions would have a well-defined set of requirements (latency, bandwidth and jitter) that must be met."

For this use case, you throw up your hands and say "requirements depend on the application," which is the most banal statement possible. This is indicative of the problem that this use case document is identifying market segments rather than technical requirements that will drive the work. As it stands, this use case provides zero motivation for RAW rather than existing protocol solutions.

(9.4) "The inter-network needs to operate in damaged state (e.g. during an earthquake aftermath, heavy weather, wildfire, etc.). In addition to continuity of operations, rapid restore is a needed characteristic."

Robustness to infrastructure damage is one of the original design requirements of the Internet, and does not motivate new work.

... and so on.

A much better approach to this document would articulate specific requirements levied on the network that are not well served by existing standards, and then tie those shortfalls into specific use cases.

[Ballot comment]
Thanks to Roman for his discuss and comments!

I can only add that I found the wireless gaming a little contrived, as what really matters for gaming is the home internet connection. Die hard gamers will only use modern switches and cabling to hook up their consoles and stay away from wifi completely to ensure it is only their home network that is the limiting factor. I interpreted the text to mean it is trying to solve this in a way that wifi can be used in this scenario (although the real latency/loss issue is still the home internet connection quality)

[Ballot comment]
# Internet AD comments for draft-ietf-raw-use-cases-08
CC @ekline

## Nits

### S2.2

* In Figure 1 description:
    - "Termina" -> "Terminal"
    - "domain domain" -> "domain"?

[Ballot comment]
Hi,

Thanks for an informative read.  I just had one minor question/comment on this doc:

  *  Wireless Console Gaming: Playing online on a console has 2 types
      of internet connectivity, which is either wired or Wi-Fi.  Most of
      the gaming consoles today support Wi-Fi 5.  But Wi-Fi has an
      especially bad reputation among the gaming community.  The main
      reasons are high latency, lag spikes, and jitter.

Is the concern here just about how the console is connected to the Internet (which could be wired or wireless), and/or how the handheld controllers are connected to the console (which could also be wired or wireless)?  Presumably both of these could be in scope for RAW?  E.g., I thought that one of the alleged benefits of Google's project Stadia was that it was meant to reduce latency for cloud gaming via going directly from the handheld controller to the router without going via a console or PC.

Thanks,
Rob

[Ballot comment]
Hi,

Thanks for an informative read.  I just had one minor question/comment on this doc:

  *  Wireless Console Gaming: Playing online on a console has 2 types
      of internet connectivity, which is either wired or Wi-Fi.  Most of
      the gaming consoles today support Wi-Fi 5.  But Wi-Fi has an
      especially bad reputation among the gaming community.  The main
      reasons are high latency, lag spikes, and jitter.

Is the concern here just about how the console is connected to the Internet (which could be wired or wireless), and/or how the handheld controllers are connected to the console (which could also be wired or wireless)?  Presumably both of these could be in scope for RAW?  E.g., I thought that one of the alleged benefits of Google's project Stadia was that it was meant to reduce latency for cloud gaming via going directly from the handheld controller to the router without going via a console or PC.

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

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

** 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”

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

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

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

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

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

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

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

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

** Section 8.2.  What is “very low latency” in this context?

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

** Section 9.1.  What is a “radio-WAN”?  Is this the same as a wireless WAN?

** Section 9.4.  What is “high availability” in this context?

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

The IESG last call has concluded. While none of the reviews raised any showstoppers, I would prefer if the reviews were responded to at minimum, and probably at least some of the review feedback taken on board a new revision, before I schedule this for IESG review.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-raw-use-cases-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-10-06):

From: The IESG
To: IETF-Announce
CC: corinna.schmitt@unibw.de, draft-ietf-raw-use-cases@ietf.org, jgs@juniper.net, raw-chairs@ietf.org, raw@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RAW Use-Cases) to Informational RFC


The IESG has received a request from the Reliable and Available Wireless WG
(raw) to consider the following document: - 'RAW Use-Cases'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-10-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The wireless medium presents significant specific challenges to
  achieve properties similar to those of wired deterministic networks.
  At the same time, a number of use-cases cannot be solved with wires
  and justify the extra effort of going wireless.  This document
  presents wireless use-cases (such as aeronautical communications,
  amusement parks, industrial applications, pro audio and video,
  gaming, UAV and V2V control, edge robotics and emergency vehicles)
  demanding reliable and available behavior.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-raw-use-cases/



No IPR declarations have been submitted directly on this I-D.

Thanks for addressing the RTGDIR review. I'm just bumping the document state to indicate we also need to close on the AD review (https://mailarchive.ietf.org/arch/msg/raw/iEYhEgbiju99UfCLJJi1ugJgXwQ/) prior to going to IETF LC.

Based on: https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-cases-04


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standard Track is mentioned, but reading it I assume “Informational” is meant. Request is send out.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  The wireless medium presents significant specific challenges to
  achieve properties similar to those of wired deterministic networks.
  At the same time, a number of use-cases cannot be solved with wires
  and justify the extra effort of going wireless.  This document
  presents wireless use-cases (such as aeronautical communications,
  amusement parks, industrial applications, pro audio and video,
  gaming, UAV and V2V control, edge robotics and emergency vehicles)
  demanding reliable and available behavior.

Working Group Summary:

The process was as smooth as possible, with no contradiction over the ML or during meetings. The document mentions the main identified use-cases demanding reliability and availability for the wireless communication used and points our challenges in request in parallel.


Document Quality:

The document underwent several iterations by involved experts of the different use-cases and results in a well written version with manifold references to further details beyond the document’s scope. Overall it is very readable and quite thorough.

Personnel:

Document Shepherd: Corinna Schmitt
Responsible Area Director: John Scudder: https://datatracker.ietf.org/person/jgs@juniper.net

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd performed a full review of the document, and the comments were addressed. No major issue reported. The document appears ready for publication request.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Not at all!

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Not needed. Only recommendation would be to include references to other IETF documents related to it. E.g. LDACS would benefit of a link to the current document(https://datatracker.ietf.org/doc/html/draft-ietf-raw-ldacs) that is under review for RFC handling. This should be done for the other use-cases as well if appropriate.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No such thing

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, they all confirmed; there is no IPR to report on that document itself; there might be IPR on the presented technology.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosure

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG as a whole understand and agree with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No such thing

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nothing worth mentioning

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No such need

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Only RFCs

(15) Are there downward normative references(see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No IANA requests

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No such need

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No such need

Based on: https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-cases-04


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standard Track is mentioned, but reading it I assume “Informational” is meant. Request is send out.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  The wireless medium presents significant specific challenges to
  achieve properties similar to those of wired deterministic networks.
  At the same time, a number of use-cases cannot be solved with wires
  and justify the extra effort of going wireless.  This document
  presents wireless use-cases (such as aeronautical communications,
  amusement parks, industrial applications, pro audio and video,
  gaming, UAV and V2V control, edge robotics and emergency vehicles)
  demanding reliable and available behavior.

Working Group Summary:

The process was as smooth as possible, with no contradiction over the ML or during meetings. The document mentions the main identified use-cases demanding reliability and availability for the wireless communication used and points our challenges in request in parallel.


Document Quality:

The document underwent several iterations by involved experts of the different use-cases and results in a well written version with manifold references to further details beyond the document’s scope. Overall it is very readable and quite thorough.

Personnel:

Document Shepherd: Corinna Schmitt
Responsible Area Director: John Scudder: https://datatracker.ietf.org/person/jgs@juniper.net

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd performed a full review of the document, and the comments were addressed. No major issue reported. The document appears ready for publication request.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Not at all!

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Not needed. Only recommendation would be to include references to other IETF documents related to it. E.g. LDACS would benefit of a link to the current document(https://datatracker.ietf.org/doc/html/draft-ietf-raw-ldacs) that is under review for RFC handling. This should be done for the other use-cases as well if appropriate.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No such thing

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, they all confirmed; there is no IPR to report on that document itself; there might be IPR on the presented technology.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosure

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG as a whole understand and agree with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No such thing

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nothing worth mentioning

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No such need

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Only RFCs

(15) Are there downward normative references(see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No IANA requests

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No such need

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No such need