Re: [Raw] Proposed RAW charter

"BRUNGARD, DEBORAH A" <> Tue, 14 January 2020 20:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C0B81209F1 for <>; Tue, 14 Jan 2020 12:20:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8vyxwhMcxSU6 for <>; Tue, 14 Jan 2020 12:20:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E1CC51208DE for <>; Tue, 14 Jan 2020 12:20:01 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id 00EKFWFi018869; Tue, 14 Jan 2020 15:19:57 -0500
Received: from ( []) by with ESMTP id 2xhfkjhbdx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Jan 2020 15:19:57 -0500
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id 00EKJudQ017893; Tue, 14 Jan 2020 15:19:57 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id 00EKJsAI017866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Jan 2020 15:19:54 -0500
Received: from ( []) by (Service) with ESMTP id 5847216A3EB; Tue, 14 Jan 2020 20:19:54 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id E0E5316A599; Tue, 14 Jan 2020 20:19:53 +0000 (GMT)
Received: from ([]) by ([]) with mapi id 14.03.0468.000; Tue, 14 Jan 2020 15:19:53 -0500
To: "" <>, "" <>, "" <>
Thread-Topic: [Raw] Proposed RAW charter
Thread-Index: AdXKVnmbULuYyq59Tr2J+ZIiJo18pwAzbR+AAADStIAABWUuEA==
Date: Tue, 14 Jan 2020 20:19:51 +0000
Message-ID: <>
References: <> <> <015f01d5cafd$9043d980$b0cb8c80$>
In-Reply-To: <015f01d5cafd$9043d980$b0cb8c80$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8AF883040MISOUT7MSGUSRDE_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-14_06:2020-01-14, 2020-01-14 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 clxscore=1011 bulkscore=0 adultscore=0 mlxlogscore=999 spamscore=0 mlxscore=0 suspectscore=0 phishscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001140154
Archived-At: <>
Subject: Re: [Raw] Proposed RAW charter
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: reliable and available wireless <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Jan 2020 20:20:06 -0000

On several of the comments, the question seems to be “how can we define a reliable and available Layer 3 if the Layer 1-2 is not reliable”. That’s the work of this working group to determine. Maybe the answer will be “impossible”.

The other concern is the sensitivity on solution work. Until the working group does a gap analysis on the current solutions, we don’t know the answer. Maybe current solutions (or a combination) will be sufficient to provide a solution. First, though, we need to understand the use scenarios and what has not been addressed in on-going IETF work. RAW is not to boil the ocean – for the next 10 years. The BoF indicated there were several concrete use cases which have not been addressed by DetNET and are of immediate industrial need. RAW’s scope is to quickly identify the gaps in the current work so we can determine what work is needed.

Here’s some responses – below –

Thanks for the comments!

From: <>
Sent: Tuesday, January 14, 2020 12:11 PM
Subject: RE: [Raw] Proposed RAW charter

<DL> In-line </DL>

From: Raw <<>> On Behalf Of Justin Dean
Sent: 14 January 2020 16:47
Subject: Re: [Raw] Proposed RAW charter

Comments inline below.
Justin Dean

On Mon, Jan 13, 2020 at 2:14 PM BRUNGARD, DEBORAH A <<>> wrote:

Happy New Year!

As promised, here’s a proposed charter. Please send comments. I’ll be submitting it to the IESG for the first step (internal review) by the end of the week.

Note, while the BoF had the most support for doing only use cases and requirements, I’ve included here also a gap analysis and an architecture/framework document. I think the gap analysis will be the most critical. The architecture/framework is intended not to be the typical comprehensive protocol architecture, but only architectural aspects of what is needed to enable deployment and usage in a wireless network.

Looking forward to your comments-
(your supporting AD)


Reliable and Available Wireless (RAW) provides for high reliability and availability for IP connectivity over a wireless medium..

This very first sentence seems off to me as later in the charter it's mentioned that no solutions are going to be directly in scope so will the work actually provide this or just outline the challenges and point towards solutions in DetNet/Manet/other WGs?  If no solutions will be in scope then I suggest leading with the next 1-2 sentences mixed with the first as way of introduction to RAW.
[deborah] I don’t read it the same way -this first sentence is simply defining the acronym for the group. Details of what the group will do are in later paragraphs.
The wireless medium presents significant challenges to achieve deterministic properties such as low packet error rate, bounded consecutive losses, and bounded latency. RAW extends the DetNet Working Group concepts to provide for high reliability and availability for an IP network utilizing scheduled wireless segments and other media, e.g., frequency/time-sharing physical media resources with stochastic traffic: IEEE Std. 802.15.4 timeslotted channel hopping (TSCH), 3GPP 5G ultra-reliable low latency communications (URLLC), IEEE 802.11ax/be, and L-band Digital Aeronautical Communications System (LDACS).
and etc. is needed here unless this his is exhaustive.
[deborah] Ok

<DL> LDACS does not use IP.   A number of other systems where we need to create Reliable and Available Wireless paths do not use IP.   This limits the applicability of the technology.  Is it the PATH we wish to make Reliable and Available or the Protocol? </DL>
[deborah] This is on the Layer 3 aspect – input was that there was interest in having IP connectivity (draft-maeurer-raw-ldacs).
Similar to DetNet, RAW will stay abstract to the radio layers underneath, addressing the Layer 3 aspects in support of applications requiring high reliability and availability.

While DetNet solutions apply to both wireless and wired, there has been recent industry interest for wireless applications which were not initially included in the DetNet use cases. One critical application is Aeronautical Data Communications. The Aeronautical standards work on a physical layer and data link layer for data communications is reaching maturity and there is significant interest in developing an IP connectivity solution.
(using wireless links?)
[deborah] Refer to the draft mentioned above.

<DL> “significant interest” reads purely of conjecture to me.  If what we are trying to do is to make the link Reliable and Available, does the higher-level protocol actually matter? </DL>
[deborah] Refer above – IETF doesn’t do Layer 1 and Layer 2 for these technologies, the scope is Layer 3.

In the interests of providing timely solutions for these newly identified industry applications, RAW’s focus will be on identifying use cases and requirements for these new applications. RAW will solicit input on deployment plans, requirements, and operational practices (including security and privacy aspects) for these newer industrial applications. RAW’s primary focus is on identifying areas where the DetNet adaptation to wireless networks requires additional supporting mechanisms. The RAW Working Group will also examine the applicability of other existing IETF work, e.g..., DLEP.  The RAW Working Group will provide input to the DetNet Working Group, MANET Working Group, and other IETF Working Groups, and cooperate in reviewing solutions to RAW’s identified deployment problems. RAW is not chartered to work on a solution, if solution work is needed in addition to the DetNet solution work or other existing solution work in the IETF, it will be coordinated on where the work will be done.
In terms of presentation of information the critical bit of info that RAW will NOT work on solutions seems a bit buried here and this should be moved towards the top.
[deborah] The flow is consistent with other charters – first define the acronym “RAW”, explain interest for a working group, and then define scope of work.

The RAW Working Group is planned to be a short timeframe (12-18 months) Working Group to quickly address these newer industry applications. The initial milestones will be comprised of Informational documents. The documents may exist individually or on a git repository.
Unnecessary suggest cutting previous sentence.
[deborah] This is to clarify the documents may not be necessarily published. The same sentence is in DetNet and other recent charters.

The use case document may consist of one or more documents to allow users/operators the opportunity to provide comprehensive deployment plans for these new (to IETF) technologies. The group will closely coordinate with the DetNet and MANET Working Groups. The work produced by this group may be of interest to other SDOs, 3GPP, IEEE, and the Aeronautical industry. No formal co-ordination is anticipated with these groups at this time.
"these groups" meaning "these non-IETF groups"?
[deborah] Yes, non-IETF groups. This same sentence is in many charters, no confusion.

<DL> The general concern I have is in terms of abstracting the Layer 1 aspects from the delivery SLA.   The analogy I will draw where it works VERY well is VoLTE where the contract in terms of an IP QoS is explicitly tied to the air interface QCI and “reliability” is built by moving the voice call from a packet-switched to a circuit-switched connection if the air-interface breaks-down.   This means that the solution is anything BUT abstracted in terms of layers!

We do need to be aware that significant, non-predictable behaviour can occur on RF connections – for example, the massive tropospheric “lift” that occurred across much of Western Europe at the end of December which caused OTA TV and Radio to be severely impacted for a number of days<>

[deborah] Refer to above – IETF is scoped to Layer 3 for these technologies. The same sentence is in DetNet. Any solution work on Layer 1-2 needs to be done in the appropriate SDO.
Draft for “Use Cases” adopted by WG
Draft for “Problem Statement and Requirements” adopted by WG
Draft for “Architectural/Framework aspects to enable deployment and usage in a wireless network” adopted by WG
Draft for “Evaluation of Existing IETF Tools and Gap Analysis” adopted by WG
Draft for “Use Cases” submit for publication
Draft for “Problem Statement and Requirements” submit for publication
Draft for “Architectural/Framework aspects to enable deployment and usage in a wireless network” submit for publication
Draft for “Evaluation of Existing IETF Tools and Gap Analysis” submit for publication

Raw mailing list<><>