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 <[email protected]> > 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:[email protected]] On Behalf Of Templin (US), Fred L > Sent: Monday, August 2, 2021 9:50 PM > To: [email protected] > Cc: [email protected]; int-area <[email protected]>; rtgwg-chairs > <[email protected]>; Bob Hinden <[email protected]>; Robert Moskowitz > <[email protected]>; Linda Dunbar <[email protected]>; 6man > Chairs <[email protected]>; [email protected]; routing WG > <[email protected]> > Subject: AERO/OMNI transition to the IETF (2nd try) > > (Re-sending to correct [email protected] 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 [email protected] 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 [email protected] 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 > [email protected] > [email protected] > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
