Simon Josefsson wrote:
Marshall Eubanks <tme@xxxxxxxxxxxxxx> writes:
Comments sought for: Standard Procedure for Modifying the TLP
Is this a solution looking for a problem? RFC 5377 is an example of
where the IETF asks the Trust do something. What is wrong with using
the same approach in the future? The approach would be that someone
writes an I-D, there is IETF-wide last call on it, and it is either
approved or not. If it is approved, the Trust needs to act.
Correct and this document specifies how the trust will react: it takes
the guidance (for example, RFC 5377), modifies the text, gets legal
advice and proposes an implementation to the community. The community
reviews the changes and checks that what is implemented, is what is
requested.
2. Whoever brings up the problem, writes a problem statement.
a. In case 1a: this can be an individual submission ID or a ID from
a WG
chartered to discuss these items.
b. In case 1b: A note from the trust to the community.
c. In case 1c: A note from whoever brings up the issue.
For 2c, whom is the note to? To only the trust or to the community? If
the former, will be trust communicate the request to the community?
2c are cases where the Trust manages something for another stream, so in
first order, I'd say that the note is for the trust and that other stream.
I don't see a problem sending it else where though.
4. Trust (with legal counsel) reviews the issue and comes up with a
response:
a. No, we don't think changing this is a good idea, because ...
b. Yes, we suggest to modify the text as follows ... (perhaps with
some background material why this is the answer).
I'm strongly concerned that this puts the decision making of what is and
what is not a problem into the Trust's hands.
No, there is always step 5: review of the new text or decision not to change
the text. If a suggestion isn't considered a good idea by the Trust, the
reasons for not changing it can be discussed in this step.
The trust is there to protect the IPR held by the IETF, if the community
comes up with a suggestion that has a negative impact on that, I want the
Trust to be able to warn the community about this, rather than blindly
implement the change.
Henk
--
------------------------------------------------------------------------------
Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre http://www.xs4all.nl/~henku
P.O.Box 10096 Singel 258 Phone: +31.20.5354414
1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445
The Netherlands The Netherlands Mobile: +31.6.55861746
------------------------------------------------------------------------------
Belgium: an unsolvable problem, discussed in endless meetings, with no
hope for a solution, where everybody still lives happily.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf