Procedure for Modifying the TLP

This document describes the procedure the Trust intends to follow when responding to policy requests from the community. The Trust is there to react to policy requests, it is not the intention of the Trust to start making policy by itself.

  1. An issue with the current TLP is identified:
    1. (Some subset of) the IETF community wants something different from what the TLP currently says.
    2. The trust (or its legal counsel) finds a problem itself.
    3. There is a request from one of the other bodies (IRTF, IAB, IESG, independent stream, etc) for which the trust manages rights.

  2. Whoever brings up the problem, writes a problem statement. The problem statement will be published on the Trust's website.
    1. In case 1a: this can be an individual submission ID or a ID from a WG chartered to discuss these items.
    2. In case 1b: A note from the trust to the IETF community.
    3. In case 1c: A note from whoever brings up the issue.

  3. Is it really a problem?
    1. If the problem statement was developed in a group effort, then it is by default.
    2. All other cases, including issues brought up by the Trust themselves, a short comment period (2 weeks).

  4. Trust (with legal counsel) reviews the issue and comes up with a response:
    1. No, we don't think changing this is a good idea, because ...
    2. Yes, we suggest to modify the text as follows ... (perhaps with some background material why this is the answer).
    3. 30 day community review period of the proposed changes (or decision not to change).

The trust will engage in discussion with the community.

If the comments show a clear trend indicating that the proposal needs a revision, the Trust may withdraw or modify the proposal, publish it and reset the counter before the comment period is over.

  1. Trust evaluates responses. Possible outcomes are:
    1. There is positive consensus about the change => Go to 7.
    2. There is positive consensus but textual changes are needed => Trust modifies the text, go back step 5, but with a 14 day review period.
    3. There is no consensus or negative consensus => drop proposal (and explain why). Consensus will be called by the Trust Chair.

  2. Publish new TLP. The following documents will be published on the Trust website.
    1. The new TLP (with an effective date)
    2. The previous TLP
    3. A list of changes between (A) and (B).
    4. Any background documents.

Announcements: All announcements to go to the TLP mailing list and the ietf-announce list plus the equivalent for the other streams. Discussion will take place on the TLP mailing list. The TLP mailing list will be archived.

Emergencies. An emergency is defined as "there is a problem with the TLP that is likely to be abused, or a legal problem has arisen with the TLP that has stopped publication of documents". In these cases, the trust can publish a modified text for a 2 week review period, then modify the TLP. The Trust must explain the reason for the change.

Appeals: use the process from RFC 4071 for the IAOC, with IAOC replaced by Trust.

If a member of the IETF community is not satisfied with the Trusts's response to his or her review request, he or she may escalate the issue by appealing the decision or action to the IAB, using the appeals procedures outlined in RFC 2026 [RFC 2026]. If he or she is not satisfied with the IAB response, he or she can escalate the issue to the ISOC Board of Trustees, as described in RFC 2026.

Adopted by the IETF Trust 11 November 2009

Internet SocietyAMSIETF - IESG - IAB - IASA & IETF LLC - IETF Trust - RFC Editor - IANA - IRTF - IETF Tools - Privacy Statement
Secretariat services provided by Association Management Solutions, LLC (AMS).
Please send problem reports to: