Re: AERO/OMNI transition to the IETF (2nd try)

Fred Baker <fredbaker.ietf@gmail.com> Wed, 04 August 2021 20:25 UTC

Return-Path: <fredbaker.ietf@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2EB3A08C7; Wed, 4 Aug 2021 13:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ic-Aa76uJ9uE; Wed, 4 Aug 2021 13:25:45 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25E93A08C5; Wed, 4 Aug 2021 13:25:44 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id t68so4030436qkf.8; Wed, 04 Aug 2021 13:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=bCPyuqSTcYqN0rRgV4gQogAF60fPczruDZ5oufGf1CQ=; b=C2QcxxFLkKFhtfrrBog6o4cg6cf6q79Uwg+keQk/VOt4Rgj4s1GGtjzlucpxbwzjtG JkmTxEhkgXJexSqLOgXmFuHpjqD3RHrlzdVRqaldXUaUn6UtZ9ZIvY8SavZaHiPq+rZm 0+rzJkzLuyn07XDsFwrDbzhRMgGHO296Fkd2Ye5e97K+yur1RRJIqf6MNtRaHeMwc0Km zj0mkYTrv7GPz5Hzl0r5Rboc3wPLmWZCmvjiMOBbuGyGAf9YjN/7IOCkIi4eBWNqIfYD YvVSbghv4ZgHLHLxivGCk2xv5JB6NZw+53FEeCQyD3VhSb2VyBPTO6YCkvID7RXCAVZN dcWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=bCPyuqSTcYqN0rRgV4gQogAF60fPczruDZ5oufGf1CQ=; b=Z35Yt0i2YuC4DdRytj2gxHHdRy6sXt4G3q/t0asR1odhd/BTNii1NnV6gJ4xgomN70 x29u2YeucrV/Wta1SXFkfA/Ai6cSs7zwDF78U2r1Ydmb0Futb8QnuNCAfLT3eYTx2HpY Q7O3jOQWoWC4v1SKZ3D8Stf4rlI7VTGE7aUqTOGWSZtaLU97R9puWUp0546jyuxL77T2 U7sO3W/DR8Wk+RAXd8szVObSj4qGWlMiW97ZJXqU0F7BdPyPBsY1eBWU93+uwITCzn25 3mq0BgI1K5AdaMD2ZdA25FTfqHC6C/8j9604tF77mGq1ufttTFfeanw2rsRknLToIx6W bfRA==
X-Gm-Message-State: AOAM532cjM704U5Jd+lHvXoFZMW/HWYyQreAjpPKLDMQHLeVPNEXw3j0 INnRwL87PAgfEs+lm6gBwh8=
X-Google-Smtp-Source: ABdhPJxuvyh+NotgXGGSKIMs3GD/GKwyO93f5uI3w2Tc6SRChmPUgld5IJW5lKpzPtlgIRGZD48GsQ==
X-Received: by 2002:a05:620a:1913:: with SMTP id bj19mr1212582qkb.341.1628108742100; Wed, 04 Aug 2021 13:25:42 -0700 (PDT)
Received: from smtpclient.apple ([2600:1702:290:6530:38a4:62c2:b711:f0ab]) by smtp.gmail.com with ESMTPSA id b25sm1804407qka.123.2021.08.04.13.25.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Aug 2021 13:25:39 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_7BCCEEBA-FF34-4AC4-A9A2-CF4DA09DBE38"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: AERO/OMNI transition to the IETF (2nd try)
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <dbea63ea9c0e4800a933fd0ed303ccb8@huawei.com>
Date: Wed, 04 Aug 2021 13:25:34 -0700
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, atn@ietf.org, 6man@ietf.org, int-area <int-area@ietf.org>, rtgwg-chairs <rtgwg-chairs@ietf.org>, routing WG <rtgwg@ietf.org>
Message-Id: <54BB79F6-B4DC-4E8A-89AA-E81AC3022996@gmail.com>
References: <dbea63ea9c0e4800a933fd0ed303ccb8@huawei.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mxu_833Co1RCjofqGxnfAcE2Pmk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Aug 2021 20:25:52 -0000

Sending again as this was rejected by int-area...

I don’t think *I* put it in a working group. I’ll tell you the same thing I have told Fred many times.

It’s not in our charter. https://datatracker.ietf.org/wg/v6ops/charter/ <https://datatracker.ietf.org/wg/v6ops/charter/>.

If you disagree, argue from the charter, or a charter such as 6man or int-area to go to that WG.

Part of the problem is that Fred doesn’t want to discuss IPv6 networks (like “all of China”), he wants to discuss a network connecting aircraft in flight to stations on the ground, that might use IPv6 but could use MPLS (as Lufthansa does) or some other technology. When I have tried to apply his drafts to IPv6 networks, he has pointedly corrected me.

ATN is pretty close, and just needs to have a bof to become a working group. I would suggest talking with Warren Kumari about the prospects there. Or maybe int-area, which is copied here.

Sent using a machine that autocorrects in interesting ways...

> On Aug 3, 2021, at 8:32 AM, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
> 
> Hi all,
> It is the only scheme that has at the same time:
> - mobility support (3GPP roaming has such feature)
> - works cross-everything on the global scale: IPv4/Pv6/L2 and/or many carriers on the path in the underlay (SD WAN has such feature too)
> And many other features that are evident for such type of an overlay: fragmentation, QoS, multicast, security, etc.
> 
> The use case of airplane, vessel, or vehicle jumping over different carriers is real. Nothing else addresses it.
> 
> I promise to work on it if it would be adopted whatever WG you would put it in.
> Ed/
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin (US), Fred L
> Sent: Monday, August 2, 2021 9:50 PM
> To: atn@ietf.org
> Cc: 6man@ietf.org; int-area <int-area@ietf.org>; rtgwg-chairs <rtgwg-chairs@ietf.org>; Bob Hinden <bob.hinden@gmail.com>; Robert Moskowitz <rgm@labs.htt-consult.com>; Linda Dunbar <linda.dunbar@futurewei.com>; 6man Chairs <6man-chairs@ietf.org>; intarea-chairs@ietf.org; routing WG <rtgwg@ietf.org>
> Subject: AERO/OMNI transition to the IETF (2nd try)
> 
> (Re-sending to correct int-area@ietf.org email address)
> 
> Members of the International Civil Aviation Organization (ICAO) Aeronautical Telecommunications Network (ATN) Community and the Internet Engineering Task Force (IETF),
> 
> As you know, the AERO and OMNI technologies have been under development for many years within the ATN Working Group I (WG-I) and Mobility Subgroup (MSG) communities, but their technical specifications are now complete and ready for adoption by the IETF.
> The final products are in the following IETF "Internet Drafts" dated 7/2/2021:
> 
> https://www.ietf.org/archive/id/draft-templin-6man-aero-22.txt
> https://www.ietf.org/archive/id/draft-templin-6man-omni-33.txt
> 
> These documents will remain in their current form unless and until they are ADOPTED by the IETF for progression to some form of Requests for Comments (RFC) publication. In the interim, an "Issue Tracker" will be maintained for each document to track any technical and/or editorial errata reported between now and IETF adoption.
> 
> As you may be aware, there has been an impasse as to how to encourage the IETF to adopt the work with the goal of producing RFCs. The possible avenues for RFC publication include:
> 
> 1) IETF working group documents
> In this approach, the document is adopted by a new or existing IETF working group, with the ultimate goal of progressing to a Working Group Last Call (WGLC), an IESG ballot, a resolution of all outstanding issues and finally publication as either Standards Track, Informational or Experimental-category RFC.
> 
> 2) IESG Area Director (AD) sponsorship
> The AD Sponsored approach is sometimes taken in which an IETF AD (e.g., Routing Area, Internet Area, etc.) serves as "Document Shepherd" and brings the work forward outside the context of any IETF working group but within scope of their area of responsibility. The document would undergo IESG review the same as for a working group document, again with Standards Track, Informational or Experimental-category as possible outcomes.
> 
> 3) Independent Submissions through the RFC-ISE Editor The ISE stream allows anyone with work that is relevant to the IETF and of sufficient quality to submit an Internet Draft directly to the RFC-ISE Editor. The work is then progressed toward RFC publication with a note that it is related to the IETF but is not an IETF standard of any kind. In this alternative, only Informational or Experimental documents are possible and Standards Track is not an option. While there have been examples of non-Standards Track works that have been implemented by vendors of widely distributed implementations, this seems to be the exception rather than the normal course of events for ISE stream documents.
> 
>> From the above alternatives, it should be clear that AERO and OMNI
>> should be published
> as Standards-Track if at all possible as either an IETF working group or AD-sponsored product (i.e., options 1 or 2). While publication through option 3) would also attain the desirable end -state of an IETF RFC publication, failure to attain Standards Track could fail to encourage a wide range of network equipment vendors to implement the technologies in their products which could lead to either few or no equipment vendor products to choose from.
> 
> To date, several overtures have been made to the IETF including publication of a liaison statement requesting IETF action:
> 
> https://datatracker.ietf.org/liaison/1676/
> 
> The AERO/OMNI works were then brought to the attention of the IETF 6man working group where they were largely ignored, including a presentation at IETF110 that drew no comments or discussion. This led the author to conclude that the scope of the work is too broad for the 6man charter; therefore, following finalization of the drafts the works were then offered to the IETF rtgwg and intarea working groups for presentation at IETF111 held last week.
> 
> At IETF111, a presentation to rtgwg generated substantial discussion on the chat session for which a summary note was posted on the rtgwg mailing list:
> 
> https://mailarchive.ietf.org/arch/msg/rtgwg/oNPr8BA_4esFDXTmY-CbBRhkJ2I/
> 
> The IETF111 presentation to intarea generated no discussion, presumably due to the author's attempt  to cram 60 mins worth of detailed presentation materials into a 20 min timeslot which may have been better served by a shorter presentation with higher-level bullet points.
> 
> With all of the above under consideration, the following are now seen as possible ways forward toward RFC publication:
> 
> 1) Publish AERO as a WG item of the rtgwg working group, while publishing OMNI as a WG item of the intarea working group.
> 
> 2) Publish one of AERO/OMNI as a WG item, while publishing the other as AD Sponsored.
> 
> 3) Publish both AERO/OMNI as AD sponsored (i.e., with AERO in the routing area and OMNI in the Internet area)
> 
> 4) Form a new ATN IETF working group using the atn@ietf.org mailing list for coordination and publish both AERO/OMNI as working documents of this new working group.
> 
> 5) Publish both AERO and OMNI as RFC ISE stream Informational Category documents.
> 
> 6) Other
> 
> Of these alternatives, operating within the context of an existing working group or through AD-sponsorship (options 1-3) would provide the fastest paths toward a Standards-Track publication, while publishing through the RFC ISE stream (option 5) could potentially provide an even faster path but for a lesser publication category. Option 4) (form a new working group) could also be considered, but would likely take multiple years with cooperation needed from a significant number of contributors since first a "Birds of a Feather (BoF)" would first need to be held at an upcoming IETF meeting, followed by selection of working group chairs followed by development and ratification of a working group charter, etc. And, it is not clear that ICAO's deadlines would be met by an approach that could take 3-5 years or even longer to produce a final product.
> 
> So, the purpose of this message is to both inform the ICAO and IETF communities of possible ways forward toward AERO/OMNI IETF RFC publication and to request interested parties to respond to this message to confirm that some form of IETF action is desired. This is especially true for members of the atn@ietf.org list who are not regular IETF participants.
> This appeal is being posted also to the IETF working groups as well as wg chairs/ADs where the work might potentially be taken up.
> 
> In closing, the technical work on AERO and OMNI is now complete. So, if they are indeed wanted by ICAO (and/or any other interest groups) the time for discussion on publication ways forward has come. Please send responses to this list (keeping the To:/Cc:) to express your interest.
> 
> Sincerely, Fred Templin
> fred.l.templin@boeing.com
> fltemplin@acm.org
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------