Re: [Raw] Barry Leiba's No Record on charter-ietf-raw-00-00: (with COMMENT)

"BRUNGARD, DEBORAH A" <> Sat, 18 January 2020 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DC3E12002F; Sat, 18 Jan 2020 08:45:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V2dlSa-Lrsof; Sat, 18 Jan 2020 08:45:12 -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 88C2512003E; Sat, 18 Jan 2020 08:45:12 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id 00IGjBlT036738; Sat, 18 Jan 2020 11:45:11 -0500
Received: from ( []) by with ESMTP id 2xkxv55vyd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Jan 2020 11:45:11 -0500
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id 00IGivTH000897; Sat, 18 Jan 2020 11:44:57 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id 00IGipYQ000771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Jan 2020 11:44:51 -0500
Received: from ( []) by (Service) with ESMTP id 6B19F4014CA2; Sat, 18 Jan 2020 16:44:51 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id 535244009E7F; Sat, 18 Jan 2020 16:44:51 +0000 (GMT)
Received: from ([]) by ([]) with mapi id 14.03.0468.000; Sat, 18 Jan 2020 11:44:50 -0500
To: Barry Leiba <>, The IESG <>
CC: "" <>, "" <>
Thread-Topic: Barry Leiba's No Record on charter-ietf-raw-00-00: (with COMMENT)
Thread-Index: AQHVzfSfmFehpknGoES54/Ow+kfqsqfwkuag
Date: Sat, 18 Jan 2020 16:44:50 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
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-18_05:2020-01-16, 2020-01-18 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxscore=0 mlxlogscore=999 bulkscore=0 priorityscore=1501 clxscore=1011 adultscore=0 suspectscore=0 malwarescore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001180136
Archived-At: <>
Subject: Re: [Raw] Barry Leiba's No Record on charter-ietf-raw-00-00: (with COMMENT)
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: Sat, 18 Jan 2020 16:45:18 -0000

Hi Barry,

Thanks for the questions!
Answers below-

-----Original Message-----
From: iesg <> On Behalf Of Barry Leiba via Datatracker
Sent: Saturday, January 18, 2020 6:44 AM
To: The IESG <>
Subject: Barry Leiba's No Record on charter-ietf-raw-00-00: (with COMMENT)

Barry Leiba has entered the following ballot position for
charter-ietf-raw-00-00: No Record

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: 


Before I record a specific position, I’d like to understand more here:

1.  As it’s written, except for the stated connections to DETNET and MANET this sounds more like an INT area working group than one in RTG. Can it be clearer as to why it’s about routing?

[deborah] Some history, originally the group had a non-working group forming BoF, PAW, at IETF104 in the INT area (Suresh). There was a lot of concern raised by Routing Area folks saying it really overlapped with DetNet, TEAS, CCAMP. As the use cases were about multiple links/multi-hop, selection of path, and dependency on L1, Suresh and Routing ADs decided to move it to the Routing Area.

As you can see in the BoF proposed charter slides (page 7) there is no "solution" answer at this time:

And several of the other sentences were also considered too "solution specific" and maybe no longer even accurate, and so we didn't include. Solution work was also the main concern at IETF106 BoF, no one knows yet what gaps will be identified:

So I was very careful - I didn't want to hint at the solution in the charter at this time - it may end up being in INT or Routing or both. Considering the charter is about identifying what needs to be done - do you feel it is necessary to identify/scope to one area vs. another at this time in the charter life? If you have any suggestions, we are interested.

2. Given how tightly connected it is to DETNET, why does it make sense to separate it out in its own working group?  Won’t it simply be the same people, just dividing their time between the two?  How does the separation help get the collective work between the two groups done?

[deborah] Most of the discussion at IETF106 BoF was on the concern where would the solution work be done. Folks (including the DetNet chairs) were not concerned so much on a working group focused on use cases, they recognized a working group scoped to new requirements would attract a different industry niche than has been attracted to DetNet. 

The following comments at the BoF, I think are very relevant:

"Jari Arkko: Is there a market for this? 

Rick: I work for Airbus, our industry needs this. 

Thomas Graeupl: Hard to find people at IETF to talk to about standards for aeronautics communications. Having a focused WG would help."
(Thomas is with German Aerospace)

While there will be overlap of people (no different than any of our routing groups), the work will attract new people to IETF. With LDACS completing their L1-L2 work, and their interest in IP connectivity, it is critical to initiate work at IETF if we are to have timely standard solutions: