This document describes the guidelines for the formation and operation of a special kind of Working Group (WG): Special Interest Group (SIG). SIGs differ from RFC 2418 WG because their main charter is not to publish protocol or process; they are rather a place where discussions related to the IETF can take place.
The creation and chartering process of a SIG is slightly different when compared to usual WG while being compatible with RFC 2418. This document explains the main difference with respect to usual WG.
The first SIG created was MOPS in 2019 and the IoTOPS WG in formation is also a SIG.
Unofficial side meetings have existed since at least IETF 99 and are quite useful and successful with a wide variety of topics. But, they are non-official, often a one shot without continuity, and they do not appear on the IETF meeting agenda, only on a side wiki page.
There is a desire for some IETF members sharing the same interest to discuss regularly specified and deployed protocols or best common practices. The SIG variant of a RFC 2418 WG brings significant differences when compared to side meetings:
The SIG agenda could also include sharing experience in training, in glossaries, in how different technologies could interact, ...
When determining whether it is appropriate to create a special interest group, the Area Director(s) and the IESG will consider the same issues as in section 2.1 of RFC2418 but may ignore the point "Are the goals specific and reasonably achievable, and achievable within a reasonable time frame?". The reasoning is that a SIG does not have any specific technical objective, i.e., no protocols or processes will be designed.
The formation of SIG is similar to the normal RFC2418 WG:
Section 3 of [RFC2418] applies for SIGs: SIGs will operate with mailing list discussions but it is expected that the value of SIGs will be in the interim and plenary meetings.
SIGs will have a data tracker page to maintain the list of adopted and individual documents. It is expected that several of those documents will never be published as RFC but will either die after a couple of revisions or will be kept alive by having a revised version at every SIG meeting. Nevertheless, a SIG may adopt documents if deemed useful for the wider community and these documents may be published in the IETF stream following the normal publication process.
A SIG may identify new requirements and may help to identify candidate venues to address these requirements; possibly by identifying a more appropriate WG for the matter and/or document, and dispatch it. The dispatch is implicit in all WG so there is no need to specify it in the SIG charter.
While a SIG may hold interim meetings as any other WG, it is expected that the greatest benefit of a SIG is by the discussions before, during, and after the SIG meeting when the meeting happens face to face. It is also to be expected that face to face SIG meetings will attract non-regular SIG participants who are interested in adjacent topics. Those non-regular SIG participants will probably not participate in interim meetings.
The meetings interim and plenary will have an agenda made public on the IETF agenda page and materials (including minutes) will be posted as any other WG meeting.
A SIG will have the lowest priority during the agenda building / conflict resolution process by the IESG and the IETF secretaria. SIG chairs should aim for one 1-hour session.
As there are usually no milestones for a SIG, section 4 of RFC 2418 cannot be applied for a SIG. Therefore, it is up to the IESG and the SIG chairs to close the SIG.
Criteria to be used by the responsible AD and the SIG chairs to decide whether a SIG should be terminated include:
A SIG may also be rechartered to a different scope or even into a normal WG as described in section 5 of RFC2418.