Re: [Raw] Magnus Westerlund's Block on charter-ietf-raw-00-00: (with BLOCK)

"BRUNGARD, DEBORAH A" <> Thu, 23 January 2020 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2749712023E; Thu, 23 Jan 2020 04:58:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tXg4b5-UdRVZ; Thu, 23 Jan 2020 04:58:19 -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 6F5A1120255; Thu, 23 Jan 2020 04:58:19 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id 00NCtrtm012852; Thu, 23 Jan 2020 07:58:15 -0500
Received: from ( []) by with ESMTP id 2xq0rdj67c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jan 2020 07:58:15 -0500
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id 00NCwEJc008162; Thu, 23 Jan 2020 07:58:14 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id 00NCw8nD008061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Jan 2020 07:58:09 -0500
Received: from ( []) by (Service) with ESMTP id CE8164009E7B; Thu, 23 Jan 2020 12:58:03 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id B754040002C7; Thu, 23 Jan 2020 12:58:03 +0000 (GMT)
Received: from ([]) by ([]) with mapi id 14.03.0468.000; Thu, 23 Jan 2020 07:58:03 -0500
To: Magnus Westerlund <>
CC: The IESG <>, "" <>
Thread-Topic: [Raw] Magnus Westerlund's Block on charter-ietf-raw-00-00: (with BLOCK)
Thread-Index: AQHV0ddOrGXR00cnPUaYD0i0m0wBV6f4NdD8
Date: Thu, 23 Jan 2020 12:58:02 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-23_08:2020-01-23, 2020-01-23 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 bulkscore=0 impostorscore=0 mlxscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001230110
Archived-At: <>
Subject: Re: [Raw] Magnus Westerlund's Block on charter-ietf-raw-00-00: (with BLOCK)
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: Thu, 23 Jan 2020 12:58:21 -0000

Hi Magnus!

I’m not sure I understand your interpretation of significant rewording? At this time, I have Alvaro’s tweaking of a few sentences. Other comments were similar to Alvaro’s. If you have interpreted something more substantial is needed, can you send?

I responded over the weekend to Barry on the history of how this group ended up in routing. I would hope we do not block this very early work based on indecision on which area.

The LDACS work is the wording from the document submitted by folks employed in the industry - and from the BoF notes, the BoF co-chair (in the industry) confirmed the interest. The LDACS work itself is the lower physical work, and as noted in the discussions, there are proprietary IP connectivity solutions. We now have (operator) folks attending IETF requesting a standard solution. I sympathize, and happy they came to the IETF. If you have suggestions on the wording, I’m interested.

And I agree with Alvaro, to quickly scope the work, it may be good to say focused on the aeronautical industry but I’m a bit concerned to do that as from the use cases there is interest from others (Use cases document).

So I prefer to let the working group try to find a wireless commonality in the uses vs. one niche at this time. If it is determined there is no commonality, we can recharter for a specific group on the aeronautical industry. In the routing area, e.g. ccamp, teas, detnet, etc., we first try to find a commonality.

Interested in your proposals to help resolve your block on this progressing -


Sent from my iPhone

> On Jan 23, 2020, at 5:24 AM, Magnus Westerlund via Datatracker <> wrote:
> Magnus Westerlund has entered the following ballot position for
> charter-ietf-raw-00-00: Block
> 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.)
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> This is not a particular hard Block. However, I think the sum of the comments
> from the IESG recommends substantial rewording on the charter before it going
> out for external review. I at least would like to see the reworked charter
> before giving it a go-ahead to sending it out for external review. I personally
> are especially interested if it can be clarified what the WG actually is
> expected to produce.
> I also have to ask the question, is Routing the right area? A lot of the text
> appears to talk about issues that would be more at home in INT? This appears to
> take a more architectural gap analysis. I understand that there is overlap into
> both areas. However, if the target is to produce a gap analysis to figure out
> where there are short comings in the IETF suit of protocols, are there going to
> be any effort into identifying issues using this network for transport
> protocols?
> The LDACS text appears to implicitly indicate that the WG should consider how
> to provide an IP solution for them. If such work is to be done I think that
> needs its own home. Can the below part be changed to not imply such work:
> " 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."
> -- 
> Raw mailing list