Hello,
At 19:10 17-08-2009, Joel M. Halpern wrote:
The Trust Legal Provisions document specifies exactly how the trust,
and people acting based on the trust, are doing things.
From Section 2e of the IETF Trust License Policy:
"These Legal Provisions may be amended from time to time by the IETF Trust
in a manner consistent with the guidance provided by the IETF community
and its own operating procedures."
From Item 10 of the Administrative Procedures of the IETF Trust:
"The Trust shall be guided by IETF process documents, decisions of the
IETF leadership, and IETF consensus when licensing use of its
intellectual property in accordance with the Trust Agreement."
I'll mention a sentence from Item 11:
"All the Trustees' decisions shall be subject to the community review
process defined in Section 3.5 of BCP 101 for IAOC decisions."
One of the advantages of restricting how the IETF Trust operates is
that it can also protect the IETF Trust.
There are (at least) two kinds of changes that can occur.
1) There can be changes in policy, particularly policy as it affects
IETF documents. Policy changes that affect the IETF have to come
from the IETF, with sufficient clear community support (at least to
the level of rough consensus) for the trust to act on.
I gather that by the above, Joel means that clear community support
is given through a BCP. If I misunderstood, please clarify how the
clear community support is determined and by whom.
2) There can be changes of mechanism. The trust could learn that
the mechanism that it adopted has a flaw. For example, RFC 5377
specifically leaves the marking determination and legal writing to
the trust. Within a defined policy. If the trust determines it
needs to change its mechanism, the whole point of that structure was
to not need a new RFC. But it does require checking with the
community to make sure that there are no surprise (in particular,
this space is full of unanticipated side-effects. More eyes can
help with that.)
I'll quote a message [1] from an IETF participant:
"When the Trust was formed a number of us were quite worried that it
would begin to see itself as self directed and not as a function whose
purpose was to act at the direction of and in support of the IETF."
As far as I am aware that is not mentioned in any RFCs or the IETF
Trust Agreement. I am not going to argue with the IETF participant
who made that statement as I believe that I can learn from the
experience of others, whether they are young and less young, even if
what they say is not a "standard of any kind".
If you want to accuse me of selective quoting, I'll mention that I
would have quoted other sections of that message and other messages
if I were to follow the advice of old Fairford (note that the latter
is not an IETF participant).
I hereby elect not to invoke any rights under the Internet Standard
Process in relation to this message. Please feel free to say
whatever crosses your mind.
So the trust does need some procedure by which it checks with the
community that mechanism changes are acceptable.
The published steps look reasonable to me.
The subject line of the message posted by the IETF Trust Chair says
"Proposed Policy for Modifications". If the IETF Trust is to deal
with legal aspects, I assume that it will have weighed whether its
proposal is about procedures (how things work in practice) or
policies. As the messages states that it is "proposed policy", I
will consider it as such.
Note that it is perfectly reasonable (but I hope and expect very
rare) for someone in the public review cycle to say "hey, you are
changing the policy (not just mechanism) we all told you about." In
which case, assuming other folks agree, the ballgame changes.
As few days ago, Joel mentioned that there are two arguments being
made and I preferred not to argue about them. However, the recent
events have prompted me to rethink that. I believe that the IETF
Trust is changing the policy and not just the mechanism. Saying that
the IETF Trust has gone rogue might capture the attention of IETF participants.
I'm going to rehash the "obnoxious license" thread.
Andrew Sullivan asked 'Why not have these "stable" licences published
in RFCs'. [2]
The answer is because it is not convenient, depending on where you
stand, to update RFCs as they have to go through the Process. The
Process intentionally has safeguards so that changes are carefully
reviewed and are seen as the consensus of the IETF Community. I
believe that it would be better to have these licenses in RFCs as
they are a stable reference. RFCs are also widely disseminated and
can be accessing using various protocols. There are disadvantages,
depending on your viewpoint, to putting these documents on one web
site as it is one point of access and it is not possible to determine
whether the document has been modified (I do not believe that the
IETF Trust would resort to that but that's not the point). The
persons controlling the web site also have full control over the changes.
As a side note for the Open Source folks, I'll comment on license by
reference. The Apple's Common Documentation License v1.0 refers to
http://www.opensource.apple.com/cdl You won't find that page there.
John Levine mentioned that the ABNF is only two lines of
code [3]. I'll leave it to you to determine the absurdity of having
a 32 line license for two lines of code. It is good to acknowledge
the source. However, if we had to use the same rule as for code,
most of the content of a RFC would be acknowledgements.
Sean Turner mentioned [4] that the IESG added RFC editor notes to the
ASN.1 modules in a document. The message from the IESG was on May
15. Joel mentioned that the trust procedures no longer require those
license statements in RFCs. The "Code Components List" has been
effective as from April 23. I have some doubts about whether we can
invoke "overcome by events" (OBE) for such a case. If you are going
to tell me that the IESG is not aware of what the IETF Trust is
doing, please do not expect the IETF Community to be better informed.
John Klensin filed an appeal on July 18 which is exactly one month
ago. I am waiting to see whether the appeal will be OBE.
We generally refer to RFCs in our arguments as they are a way to
document the thoughts of the IETF Community. In the case of the IETF
Trust, I don't know whether the BCPs take precedence over the IETF
Trust Agreement. I am not comfortable with claims made based on
documents which are not BCPs as it falls foul of the spirit of how
the IETF has been doing business up to now. An overtly legal
approach might made sense if we want to avoid litigations but it
requires a cultural change within the IETF. Once we cross that
bridge, there is no going back. Some people may argue that the IETF
is operating in a hostile environment and that it is in the best
interest of the IETF to take that path. I'd say that we can always
look for an environment which is better aligned to IETF
culture. That culture is changing but that's another story.
Regards,
-sm
1. http://www.ietf.org/mail-archive/web/ietf/current/msg57650.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg57969.html
3. http://www.ietf.org/mail-archive/web/ietf/current/msg57986.html
4. http://www.ietf.org/mail-archive/web/ietf/current/msg57984.html
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf