RFC 3356

Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines

πŸ“… published August 2002, from ietf

RFC 3356 πŸ’Œ Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines

Okay bestie, let's get into it πŸ¦‹ This is RFC 3356, written by G. Fishman (Bell Laboratories) and S. Bradner (Harvard University). It's Category Informational, dated August 2002, and it obsoletes RFC 2436 πŸ“œ The header doesn't list any Updates, so that's all the paperwork. It's the official vibe check for how the IETF and ITU-T should work together πŸ’œ

Status of this Memo ✨

This memo provides information for the Internet community. It doesn't specify an Internet standard of any kind, so this is more of a "here's how we vibe together" doc than a rulebook. Distribution is unlimited, so share it with everyone πŸ’…

Copyright (C) The Internet Society (2002). All Rights Reserved. The Internet Society owns the rights here, so respect the copyright, babe πŸŽ€

Abstract πŸ“

So this doc gives guidance to help us understand how standards development collaboration works between the International Telecommunication Union -- Telecommunication Standardization Sector (ITU-T) and the Internet Society (ISOC) / Internet Engineering Task Force (IETF). It's an update of and obsoletes RFC 2436, because a lot changed in the IETF and ITU-T since that one was written πŸ”₯ Most of this doc is shared text with ITU-T Supplement 3 to the ITU-T A-Series Recommendations, so it's giving "two orgs, one plan" energy ✨

Note: This was approved by ITU-T TSAG on 30 November 2001 as a Supplement to the ITU-T A-Series of Recommendations (will be numbered as A-Series Supplement 3). Iconic approval date, iykyk 🫢

Table of Contents πŸ“‘

1.  Scope...........................................................2
2.  Introduction ...................................................2
3.  Guidance on collaboration.......................................3
3.1 How to interact on ITU-T or IETF work items.....................3
3.2 Representation..................................................4
3.3 Document sharing................................................7
3.4 Simple cross referencing........................................8
3.5 Additional items................................................8
4.  Security Considerations........................................10
5.  Non-normative references.......................................10
6.  Acknowledgements...............................................10
7.  Changes since RFC 2436.........................................10
8.  Author's addresses.............................................11
9.  Full Copyright Statement.......................................12

1. Scope πŸ—ΊοΈ

This doc is all about helping us understand how the ITU-T and the Internet Society (ISOC) / Internet Engineering Task Force (IETF) collaborate on standards development 🌸

Okay so, in the IETF, the work happens in Working Groups (WG). It's mostly done on open, public mailing lists instead of face-to-face meetings, which is so chill. WGs get organized into Areas, and each Area is managed by two co-Area Directors. All the Area Directors together make up the Internet Engineering Steering Group (IESG) πŸ‘‘

Now the ITU-T is a different vibe πŸ’… Its work gets defined by study Questions, and those are worked on mostly through meetings led by Rapporteurs. Questions are usually grouped into Working Parties (WPs), which are led by a WP Chairman. Then the Working Parties report up to a parent Study Group, led by an SG Chairman. Very hierarchical, very organized 🧚

2. Introduction πŸ¦‹

The telecom industry is basically going through a glow-up because the Internet and other IP (Internet Protocol) based networks are growing like crazy πŸ“ˆ Operators, manufacturers, and software and application providers are all rethinking their business directions πŸ’€ And Standards Development Organizations, Forums, and Consortia are facing a massive challenge trying to keep up 😭

These challenges got on the ITU-T's radar in September 1998 (TSAG), and the IETF picked up on them shortly after. It was realized that the ITU-T and ISOC/IETF were already working together in a bunch of areas, and that this collaboration had to get stronger, because the ITU-T was shifting its work emphasis and direction toward studies about IP based networks πŸ”₯

Lots of ITU-T Study Groups already look at aspects of IP based networks. There are so many topics they should be looking into in the IP area, like signaling, routing, security, numbering & addressing, integrated management, performance, IP - telecom interworking, and access 🌈 A lot of these topics are also being looked into by the IETF, so there's a real need for close teamwork 🫢

The current level of cooperation between the ITU-T and the IETF should be built upon πŸŽ€ The goal is making sure each organization's competence and experience gets used in the most effective way, and in collaboration with the other one. This document is basically the guidelines for that collaboration ✨

3. Guidance on Collaboration πŸ’œ

This section builds on the collaborative processes that already exist, and it covers some of the more important guidance points that each organization should be aware of so the collaboration actually works 🧚

3.1 How to Interact on ITU-T or IETF Work Items πŸ“

Study Groups that have identified IP-related work topics should check out how those topics relate to topics already defined in the IETF πŸ‘€ The current IETF Working Groups and their charters (the IETF's definition of the scope of work) are listed in the IETF archives (see section 3.5) πŸ“š

A Study Group might decide that developing a Recommendation on a particular topic could benefit from working with the IETF. If so, the Study Group should note this collaboration in its work plan (specifically in the plan for each Question involved), and describe the goal of the collaboration and its expected outcome πŸ’…

An IETF Working Group should also look at where it overlaps with the ITU-T, and document that collaboration with the ITU-T Study Group in its charter 🌸 The next sections outline a process that helps each group learn about the other's new work items πŸ¦‹

3.1.1 How the ITU-T Learns About Existing IETF Work Items πŸ”

It's on each individual Study Group to review the current IETF Working Groups and figure out if there are any topics of mutual interest. If a Study Group thinks there's an opportunity to collaborate on a topic of mutual interest, it should contact both the IETF Working Group Chair and the responsible Area Director(s) πŸ’Œ

3.1.2 How the ITU-T Learns About Proposed New IETF Work Items πŸ“¬

The IETF keeps a mailing list for distributing proposed new work items among standards development organizations πŸ’œ The IETF forwards draft charters for all new and revised Working Groups, plus Birds Of a Feather session announcements, to the IETF NewWork mailing list. An ITU-T mail exploder is subscribed to this list 🌈

It's recommended that each Study Group subscribe to this ITU-T exploder, which is maintained by the TSB. Members of the SG-specific listname can include the SG Chairman, SG Vice Chairmen, Working Party Chairmen, concerned Rapporteurs, other experts designated by the SG, and the SG Counselor. This lets the SGs keep an eye on new work items for any overlap or interest with their Study Group πŸ‘€ It's expected that this mailing list will see a few messages per month 🫢

Each SG Chairman, or a designated representative, can provide comments on these charters by responding to the IESG mailing list at iesg@ietf.org, clearly indicating their ITU-T position and the nature of their concern. Plain-text email is preferred on the IESG mailing list πŸ“

Also, the IETF turnaround time for new Working Group charters is two weeks 😭 Because of that, the mailing list should be consistently monitored. No skipping it, bestie ⏰

3.1.3 How the IETF Learns About ITU-T Work Items πŸ”­

The ITU-T work programme is documented in the Questions of each Study Group, and you can find those on the ITU-T web site 🌐

Study Groups should send updates to the IETF NewWork mailing list as they happen. And Area Directors or WG Chairs should give comments to the relevant SG Chairman when there's possible overlap or interest πŸ’–

3.2 Representation πŸŽ€

ISOC, including its standards body IETF, is a Sector Member of the ITU-T. Because of that, ISOC delegates get the same rights as other ITU-T Sector Members (see 3.2.1) πŸ‘‘ The flip side is that ITU-T delegates may take part in IETF work as representatives of the ITU-T (see 3.2.2) πŸ¦‹ To help the collaboration along, it's useful to make communication between the organizations easier, as described below ✨

3.2.1 IETF Recognition at ITU-T 🧚

Participants from the IETF may join ITU-T meetings as ISOC delegates if the appropriate IETF Working Group (or Area) has approved their attendance. That approval gets communicated to the TSB as a registration for a particular ITU-T meeting, done by the IAB Chair πŸ’Œ

3.2.2 ITU-T Recognition at ISOC/IETF 🌸

ITU-T Study Group Chairmen can authorize one or more members to attend an IETF meeting as an official ITU-T delegate, speaking authoritatively on behalf of the Study Group's activities (or a particular Rapporteur Group) πŸ’… The Study Group Chairman emails the ITU-T list of delegates to the Working Group chair, with a copy to the Area Directors and to the Study Group too πŸ“§

Now, the tea: according to IETF process, opinions expressed by any such delegate are given equal weight with opinions from other working group participants. Everyone's voice counts the same 🫢πŸ”₯

3.2.3 Communication Contacts πŸ“ž

To keep the communication between the ITU-T and IETF going, it's important to identify and set up contact points within each organization πŸ’œ Contact points can include:

  1. ITU-T Study Group Chairman and IETF Area Director

An IETF Area Director is the individual responsible for overseeing a major focus of activity, with a scope similar to that of an ITU-T Study Group Chairman. Both of these positions are relatively long-term (several years), so they give the two organizations stable contact points for a given topic 🌈

  1. ITU-T Rapporteur and IETF Working Group Chair

An IETF Working Group Chair is someone assigned to lead the work on a specific task within one particular Area, with a scope similar to that of an ITU-T Rapporteur. These are working positions (a year or more) that typically end when the work on that specific topic ends. Collaboration here is super beneficial to make sure the actual work gets done πŸ› οΈβœ¨

  1. Other Contact Points

It can be beneficial to set up additional contact points for specific topics of mutual interest πŸ¦‹ These should be established early in the work effort. And in some cases, the contact point each organization picks might be the same individual πŸ‘€

Note that the current IETF Area Directors and Working Group Chairs can be found in the IETF Working Group charters πŸ“š The current ITU-T Study Group Chairmen and Rapporteurs are listed on the ITU-T web page 🌐

3.2.4 Communication

okay bestie, informal chatting between contact points and experts from both orgs is totally encouraged 🫢 but heads up: formal communication from an ITU-T Study Group, Working Party or Rapporteur to an associated IETF contact point must be explicitly approved and identified as coming from the Study Group, Working Party or Rapporteur Group, respectively πŸ’…. formal comms from the ITU-T to the IETF should be addressed to the appropriate Working Group Chairs and Area Directors, with a copy to statements@ietf.org ✨. the IETF posts these on a liaison statements web page at http://www.ietf.org/IESG/liaison.html πŸ¦‹. an individual at the IETF is assigned to handle each communication that comes in, and their name and contact info is listed next to the links on that page 🌸.

the vibe goes the other way too. formal communication from an IETF Working Group or Area Director must also be explicitly approved and identified before it gets forwarded to any ITU-T contact πŸ‘‘. the IETF shows that approval by copying the appropriate Working Group Chairs and Area Directors on the message πŸ’œ. formal communication is there so the IETF and ITU-T can share positions outside of actual documents (as described in 3.3) 🧚. think comments on documents, or requests for input, stuff like that πŸ’–. the approved message just gets emailed from one body's contact to the other's, and the appropriate mailing lists (as described in 3.2.5) may be copied πŸŽ€.

3.2.5 Mailing Lists

every IETF Working Group and every ITU-T Study Group Question has an associated mailing list 🌈.

in the IETF, the mailing list is the main place for discussion and decision-making πŸ’…. it is recommended that ITU-T experts who are into particular IETF Working Group topics subscribe to and take part in these lists 🫢. IETF WG mailing lists are open to all subscribers ✨. the subscription and archive info for each Working Group's list is noted in its charter πŸ“œ.

over in the ITU-T, the TSB has set up formal mailing lists for Questions, Working Parties and other topics within Study Groups (you can find more detail on the ITU website) πŸ“. these are typically used for discussing ITU-T contributions πŸ’…. note that individual subscribers to these lists must be affiliated with an ITU-T member 😀 (right now there's no blanket inclusion of all IETF participants as members, BUT as a member, ISOC may designate representatives to subscribe πŸ‘‘). also, ITU-T members run personal mailing lists on various topics with no restrictions on membership, so IETF participants are welcome there too (e.g., IETF participants are welcome) πŸ¦‹.

3.3 Document Sharing

during ITU-T and IETF collaboration it's super important to share working drafts and documents among the technical working groups πŸ“š. early concepts and specs can usually get passed around by email on both the IETF and ITU-T mailing lists (often just repeating the concept and not including the full details of the spec) πŸ’Œ. working texts (or URLs) of draft Recommendations, Internet Drafts or RFCs can also be sent between the orgs, as described below 🌸.

Internet Drafts are available on the IETF web site 🌐. the ITU-T can make selected ITU-T documents available in a common FTP area on the ITU-T web site 🧚. a communication can point to a URL where a non-ASCII document (e.g., Word) can be downloaded, BUT Word attachments to an IETF mailing list are discouraged πŸ™ˆ. also, the official version of all IETF documents is in ASCII, so keep that in mind πŸ’œ.

3.3.1 IETF to ITU-T

IETF documents (e.g., Internet Drafts) can be submitted to a Study Group as a Contribution from ISOC πŸŽ€. to make sure the IETF has properly authorized this, the IETF Working Group must agree that the specific drafts are of mutual interest, that forwarding them to the ITU-T for review, comment and potential use is beneficial, and that the document status is accurately represented in the cover letter 🫢. once that's agreed, the appropriate Area Directors review the Working Group request and give approval πŸ‘‘. then the contributions get forwarded (with the noted approval) to the TSB for circulation as a Study Group Contribution (see 3.2.4) ✨.

3.3.2 ITU-T to IETF

a Study Group or Working Party may send texts of draft new or revised Recommendations to the IETF as contributions in the form of Internet Drafts, clearly indicating their status πŸ“‹. Internet Drafts are IETF temporary documents that expire six months after being published ⏳. the Study Group or Working Party must decide that there is a benefit in forwarding them to the IETF for review, comment and potential use πŸ’–. terms of reference for Rapporteur Group meetings may authorize Rapporteur Groups to send working documents to the IETF in the form of Internet Drafts 🧚.

in these cases, the document editor gets instructed to prepare the contribution in Internet Draft format (in ASCII and optionally postscript format, as per [RFC2223]) and submit it to the Internet Draft editor (email internet-drafts@ietf.org) πŸ’…. or! the Study Group, Working Party or Rapporteur Group could agree to post the doc on a web site and just document its existence with a short Internet Draft that has a summary and the document URL πŸ¦‹. the URL can point to a Word document as long as it's publicly available, with the understanding that it won't be eligible for publication as an RFC in that format πŸ™ˆ.

both the Rapporteur and the Document Editor should be listed as contacts in the contribution 🌸. the contribution must also clearly indicate that the Internet Draft is a working document of a particular ITU-T Study Group πŸ”₯.

3.3.3 ITU-T & IETF

it's envisaged that the processes in 3.3.1 & 3.3.2 will often be used at the same time by both an IETF Working Group and an ITU-T Study Group collaborating on a topic of mutual interest 🀝.

the outcome of the collaboration is also envisaged to be the full documentation by one body, with the other body referencing it (see section 3.4 for details) πŸ“–. common or joint text is discouraged, because of the current differences in procedures for document approval and revision πŸ™…. where complementary work is happening in both organizations and will result in Recommendations or RFCs, due allowance should be given to the differing perspectives, working methods, and procedures of the two orgs 🌈. basically, each organization should understand the other's procedures and strive to respect them in the collaboration πŸ«ΆπŸ’œ.

3.4 Simple Cross Referencing

ITU-T Recommendation A.5 describes the process for including references to documents of other organizations in ITU-T Recommendations πŸ“š. info specific to referencing IETF RFCs is found at http://www.itu.int/itudoc/itu-t/sdo/ref-a.5/isocietf.html πŸ”—.

IETF RFC2026, specifically section 7.1.1, describes the process for referencing other open standards (like ITU-T Recommendations) in IETF RFCs πŸ’….

3.5 Additional Items

3.5.1 Several URLs to IETF procedures

these URLs to IETF procedures are provided here for information 🌸:

RFC2223  - Instructions to RFC Authors, October 1997
   http://www.ietf.org/rfc/rfc2223.txt

RFC2026  - The Internet Standards Process Revision 3, October 1996
   http://www.ietf.org/rfc/rfc2026.txt

RFC2418 - IETF Working Group Guidelines and Procedures, September
   1998 http://www.ietf.org/rfc/rfc2418.txt

Current list and status of all IETF RFCs:
   ftp://ftp.ietf.org/rfc/rfc-index.txt

Current list and description of all IETF Internet Drafts:
   ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt

Current list of IETF Working Groups and their Charters: (includes
   Area Directors and Chair contacts, Mailing list information, etc.)
   http://www.ietf.org/html.charters/wg-dir.html

RFC Editor pages about publishing RFCs:
   http://www.rfc-editor.org/howtopub.html

Current list of liaison statements:
   http://www.ietf.org/IESG/liaison.html

IETF Intellectual Property Rights Notices:
   http://www.ietf.org/ipr.html

3.5.2 Current ITU-T information

current ITU-T info lives on the ITU website 🧚 (it includes contacts, organization, Recommendations for purchase, mailing list info, etc.):

ITU-T Main page: http://www.itu.int/ITU-T

List of all ITU-T Recommendations:
   http://www.itu.int/publibase/itu-t/

ITU-T Study Group main page for Study Group NN (where NN is the
   2-digit SG number):
   http://www.itu.int/ITU-T/studygroups/comNN/index.html

ITU-T Special Study Group on IMT-2000 and beyond:
   http://www.itu.int/ITU-T/studygroups/ssg/index.html

Intellectual Property policies, forms and databases:
   http://www.itu.int/ITU-T/dbase/patent/index.html

ITU-T operational matters including:
   Recommendation A.1 - Study Group work methods
   Recommendation A.2 - Preparation of written contributions
   Recommendation A.4 - Communication process between ITU-T and
   forums and consortia
   Recommendation A.5 - Include reference to documents of other
   organizations in ITU-T Recs
   Recommendation A.8 - Alternative Approval Process for
   Recommendations: http://www.itu.int/itudoc/itu-t/rec/A

ITU T Procedures including:
   Resolution 1 - Rules of Procedure for ITU-T
   Resolution 2 - Study Group responsibility and mandates
   http://www.itu.int/itudoc/itu-t/wtsa-res/index.html

Authors Guide for drafting ITU-T Recommendations:
   http://www.itu.int/itudoc/itu-t/guide/64657.html

Templates for contributions:
   http://www.itu.int/itudoc/itu-t/com2/template/w2000tem/index.html

4. Security Considerations

okay this part is serious πŸ”’ but the good news: documents that describe cooperation procedures, like this one does, have no direct Internet security implications πŸ’œ.

5. Non-normative references

these are the references, all as written πŸ“š:

[RFC2026] Bradner. S, " The Internet Standards Process -- Revision
          3", BCP 9, RFC 2026, October 1996.

[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
          RFC 2223, October 1997.

[RFC2436] Brett, R., Bradner, S. and G. Parsons, "Collaboration
          between ISOC/IETF and ITU-T", RFC 2436, October 1998.

6. Acknowledgements

this doc is based on the text from RFC 2436, and it benefited hugely from discussions during the November 2001 ITU-T TSAG meeting πŸ«ΆπŸŽ€βœ¨

7. Changes since RFC 2436 πŸŽ€

okay so the wording got a glow-up in a bunch of places, a few new references joined the chat, and the details of the cooperation process got tweaked a little bit πŸ’…βœ¨

  • Sec 3.2.1: Registration for IETF representatives to ITU-T meetings is now done by the IAB Chair instead of the ISOC VP for Standards. πŸ‘‘
  • Sec 3.2.2: Notice of ITU-T delegates to IETF Working Group meetings now goes to the Working Group chairs and appropriate Area Directors instead of the ISOC VP for Standards. πŸ¦‹
  • Sec 3.2.4: Official communications from the ITU-T to the IETF now go to the appropriate Working Group Chairs and Area Directors, with a copy to the email address statements@ietf.org, instead of the ISOC VP for Standards. A description of the new IETF liaison statements web page was added too 🌸 Official approval of messages from the IETF to the ITU-T is now shown by having the appropriate Working Group Chairs and Area Directors copied on the message. 🫢
  • Sec 3.3: A description of the new ITU-T common FTP area was added. 🧚
  • Sec 3.3.1: The appropriate Area Directors now review documents to be sent to the ITU-T instead of the ISOC VP for Standards. πŸ’–
  • Annex A was removed as unneeded. πŸ™ˆ

8. Author's addresses πŸ¦‹

Two people who helped make this happen, bestie! Here's where to find them:

Gary Fishman
Bell Laboratories
101 Crawfords Corner Road
Room 4D-605B
Holmdel, NJ 07733-3030
USA
+1 732 949 3401
EMail: garyfishman@lucent.com


Scott Bradner
Harvard University
29 Oxford St.
Cambridge MA 02138
USA
+1 617 495 3864
EMail: sob@Harvard.edu

This part is legal stuff, so I've kept the whole thing word for word. No cap, don't mess with it πŸ”’

Copyright (C) The Internet Society (2002).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫢

The RFC Editor function is funded for now by the Internet Society, which is so sweet of them ✨

πŸ“¦ where this page comes from