Subject: Rationale for Proposed TLP Revisions

From: IETF Administrative Director <[email-masked]>
Date: Sun, 19 Jul 2009 14:11:35 -0700 (PDT)

The IETF Trustees invited community comments on the proposed revisions to
the "Legal Provisions Relating to IETF Documents" (TLP) policy on 23 June
2009.  The proposed revisions are in rtf, pdf and doc formats and located
at: http://trustee.ietf.org/policyandprocedures.html under Draft Policies
and Procedures for IETF Documents.

On 18 July, in a reply to Subject:  Proposed Revisions to the IETF Trust
Legal Provisions (TLP), the IETF Trust Chair said: The rationale for the
remaining summary of proposed changes will be sent in a separate email.

This is a summary of the proposed revisions to the TLP by section with
explanations, 
where needed:

2.f -- this new language describes the conditions under which the IETF  
Trust will assume licensing and copyright responsibility for IAB, IRTF  
and Independent Stream submissions, should the managers of those  
streams request that it do so.

Explanation:  The IETF Trust was approached by representatives of the
IAB, IRTF and RFC Editor, who asked the Trust to assume the role of
"license administrator" for their respective document streams.  The
Trust is happy to do so as part of its role supporting the IETF.  The
language included in new Section 2.f of the TLP describes the procedure
by which the Trust proposes to handle documents from these non-IETF
streams.

4.c -- clarifies that the BSD License may not be applied to Code  
Components that come from IETF Documents as to which the Contributor  
has prohibited the making of derivative works.

Explanation:  An IETF participant noticed that, under the existing TLP,
the broad BSD
adoption language might "trump" a contributor's prohibition on the right
to make derivative works of his/her contribution.  The new language
clarifies that the BSD license will not apply if the contributor has
specified that no derivative works may be made of his/her contribution.

4.e -- this new section clarifies the legend requirements for Code  
Components that are used in software under the BSD License. 
In short, the user must include the full BSD License text or a shorter
pointer  to it (which is set forth in Section 6.d)

Explanation:  The issue of the appropriate BSD License language to
include in Code
Components extracted from IETF documents has been discussed extensively
within the IESG.  The proposed TLP language is intended to be consistent
with the IESG's latest guidance language, and allows the user of IETF
Code to include either the full BSD license language (about 15 lines of
text), or a short "pointer" to the BSD language (about 4 lines). 

6 -- the language regarding placement of legends on IETF Documents has  
been clarified.  Placement on the "first page" is no longer required,  
and authority for placement of the legends is  with the RFC Editor and  
IESG.

Explanation:  Self-explanatory

6.a - the words "to IETF" have been removed, to enable submission to  
IAB, IRFT and other streams.

Explanation:  Self-explanatory

6.b -- a new sentence has been added to the legend that must be placed  
on all IETF Documents, pointing out the BSD License requirements  
described in 4.e above and emphasizing that code in IETF Documents  
comes without any warranty, as described in the BSD License.

Explanation:  See 4.e above

6.d -- the BSD legend/pointer described in 4.e above

Explanation:  See 4.e above

Comments on the proposed revisions to the TLP are welcomed.

Ray
Trustee

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Jul 2009 10:02:38 +0200

Apologies for this being a month late.

> Explanation:  See 4.e above
The text added, which is intended to be placed on all IETF documents 
(internet-drafts and RFCs), is:

> Code Components
> extracted from this document must include BSD License text as 
> described in Section 4.e of
> the TLP and are provided without warranty as described in the BSD License.

I object to this change.

The reason is this:

- The RFCs are intended to be permanent (as in "forever").
- The purpose of the "incoming/outgoing split" was to make sure the 
Trust had the tools it needed to fix any errors made, or to respond to 
changed circumstances, by changing the rights granted under "outgoing".
- The BSD license is a specific license text, and there is no guarantee 
that there won't be new circumstances that warrant generic licensing 
under a different license in the future.

Thus, this change limits the ability of the Trust to respond to future 
changes; if it ever decides (as an example) to use the Apache License 
instead of the BSD license because some court has found the BSD text to 
be objectionable in some manner, this will lead to all documents 
published with this text to be misleading.

(As an example of changed circumstances - the Wikimedia Foundation just 
changed its licensing terms from GPL to a Creative Commons license - 
this required some fancy footwork to make it seem legal, even though a 
large majority of contributors agreed that it was the right thing to do. 
I don't want to see that kind of trouble in the IETF.)

If the text added instead read:

  Code Components extracted from this document must include license text
  as described in the TLP and are provided without warranty as described in
  the TLP license provisions

I would have no objection. This preserves the Trust's ability to change 
provisions.

                          Harald Alvestrand

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Jul 2009 08:41:04 -0400

I think that the alternate text proposed by Harald meets the current 
need without constraining the future.

Russ

>>Components that are used in software under the BSD License. In 
>>short, the user must include the full BSD License text or a shorter
>Trust had the tools it needed to fix any errors made, or to respond 
>to changed circumstances, by changing the rights granted under "outgoing".
>- The BSD license is a specific license text, and there is no 
>guarantee that there won't be new circumstances that warrant generic 
>licensing under a different license in the future.
>
>Thus, this change limits the ability of the Trust to respond to 
>future changes; if it ever decides (as an example) to use the Apache 
>License instead of the BSD license because some court has found the 
>BSD text to be objectionable in some manner, this will lead to all 
>documents published with this text to be misleading.
>
>(As an example of changed circumstances - the Wikimedia Foundation 
>just changed its licensing terms from GPL to a Creative Commons 
>license - this required some fancy footwork to make it seem legal, 
>even though a large majority of contributors agreed that it was the 
>right thing to do. I don't want to see that kind of trouble in the IETF.)
>
>I would have no objection. This preserves the Trust's ability to 
>change provisions.
>
>                          Harald Alvestrand
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Jul 2009 19:26:07 +0200

Julian Reschke wrote:
> Harald Alvestrand wrote:
>> ...
>
> Hi,
>
> I'm trying to understand whether this change affects me.
>
> So...
>
> 1) Many specs I'm editor of contain ABNF. Does it need to be labeled 
> as code component (I believe not).
In my understanding, all ABNF is code by definition (included in the 
Trust's list of "things considered code"), so no.
>
> 2) These specs also collect all ABNF fragments into an appendix, 
> containing the collected ABNF. Does that appendix need to contain the 
> BSD license text (I believe not, but heard from colleagues that their 
> docs are blocked because they do not).
I believe it would be silly to make it contain the BSD license.
Some people on the IESG seem to think that the IESG has made such a 
statement; one of my WGs has a couple of documents that are blocked 
until this is resolved.
>
> 3) If I *extract* ABNF from these documents (such as for the purpose 
> of generating an input file for an ABNF parser), do I need to include 
> the BSD license text? If so, can somebody explain how to do that given 
> the constraints of the ABNF syntax?
; is a fine character. A block of comment should be fine.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Jul 2009 14:32:04 -0400

On Mon, Jul 20, 2009 at 02:19:24PM -0400, Contreras, Jorge wrote:
> 
> I also think that Harald's alternate language would work.  

Is it a problem that this means that shipping code's license could
change at some time in the future?  Are there practical issues to that
if (for instance) the Trust decided to change from BSD to some
copyleft-like license?  Note that I'm thinking of shipping, and not
already deployed, code.  So one develops based on the BSD-licensed
code, and then the license changes and you ship another instance.  Is
this a problem?  I'm assuming not, because the original licensee still
has the code under the original terms.  But I thought it wouldn't hurt
to ask.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Jul 2009 15:25:24 -0400

On Mon, Jul 20, 2009 at 02:56:01PM -0400, Joel M. Halpern wrote:
> Rather, what it does is the RfC says "the code must include whatever  
> license the trust document says.
> When the code is produced, that link is dereferenced, the license is  
> determined, and the license is inserted in the code.

Ok.  So is the point then just not to have to issue a new RFC if the
Trust decides they want a different license?  I.e. is that the
"future-proofing" that the proposed change is supposed to provide?

If so, in light of the other comments people are making about how the
Trust appears to be rather more activist than some people find
congenial (I am reserving my opinion on that topic), I'm not sure the
proposed change is a good one.  If the Trust needed to change the
license, there would be two reasons to do it, I think:

    1.  The community wants the change.

    2.  External forces (say, legal precedents) cause the
    currently-selected license to be the wrong one.

But both of those cases seem to me to be the sort of thing that
requires some community input and some rough consensus, no?  If so,
then what would be hard about writing a new RFC that captured this
update, and publishing it the way of the usual RFC process?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Jul 2009 17:20:18 -0400

On Mon, Jul 20, 2009 at 4:53 PM, Joel M. Halpern<[email-masked]> wrote:
> I think Harald's suggestion makes sense and should be implemented.

I agree.

Barry

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Jul 2009 17:51:35 -0400

On 2009-07-20, at 16:44, "Contreras, Jorge" <[email-masked] 
 > wrote:

>
> I apologize if my unfortunate use of the term "future-proofing" has
> caused angst.  But I was referring to the proposal made by Harald
> Alvestrand, as a member of the community, not a proposal made by the
> Trust.  Harald's proposal should not be taken as an indication of the
> Trust's intentions.  I believe that Russ and I were merely saying that
> Harald's proposal seemed reasonable.  If other members of the  
> community
> disagree, then that's fine too.
>>

No, no angst over the term. I find the idea fetching, in principle,  
too, but I can't see how the proposed change does what is needed. If  
the goal is to be able to allow the trust to relicence the code as it  
sees fit, parallel with its ability to cope with the license of rfc  
text, then I get the purpose of the change. If this is just to avoid  
the bureaucracy of publishing a new rfc then no, sorry, I don't think  
that's a good idea. The bureaucratic hurdles are there to find  
consensus, and I see no reason to make this a special case. If we  
think rfc production is too bureaucratic, let's fix that.

Andrew Sullivan
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Jul 2009 08:57:01 +0200

> update, and publishing it the way of the usual RFC process?
I agree completely that any licensing change needs solid community input 
and rough consensus (as well as being legal). That's entirely orthogonal 
to the binding time issue (I think). My worry is the logistics of 
executing the change.

We have two possibilities:

1 - the update consists of revisions of *every single RFC* that 
references the BSD license
2 - some RFCs continue to carry the BSD license, even while the "real" 
current license is different.

1 seems like a logistical nightmare. 2 seems confusing to me.

             Harald

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Jul 2009 10:27:40 -0400

> 1 seems like a logistical nightmare. 2 seems confusing to me.

Ok, this is what I was trying to understand.  What you are proposing
is that the licence on the code in the RFC can change
restrospectively, by virtue of the Trust changing the licence they
select.

This scenario is exactly what inspired my first question, then.
Imagine I have a product, and it is shipping.  It has code taken from
an RFC.  The original RFC was published when the Trust used the BSD
licence.  Therefore, as far as I know, the code I used is under BSD
licence.  

Suppose now that the Trust now changes the licence they use to the
GPL.  (I know, I know, this won't happen, &c.  But there's nothing to
prevent it, as far as I can tell, except community consensus.  I don't
know what that might be in the future.)  If I understand what you
want, I think there are four possibilities:

    a.  The product I have already shipped is now suddenly covered by
    the GPL.  It may be in violation of the licence therefore.

    b.  The prodict I have already shipped does not change, but
    products I ship after the Trust changes policy are covered under
    the new rules.  So my shipped product is BSD, and my unshipped
    stuff is suddenly GPL (possibly forcing me to change my product,
    or its licence).

    c.  The code I used remains under the BSD because of the date I
    used it, but new uses of that code are under GPL (so my
    competitors would have to have a different licence, or version 2
    of my product might have to have a different licence).

    d.  The date the RFC was published binds the licence, so that the
    terms on the code embedded in the RFC change.  This is equivalent
    to your option (2), I think, and you say its undesirable.

I argue that compared to (a-c), (d) is a big win.  If (d) is right,
however, your option (1) isn't a problem: the RFCs that are already
published don't need a new licence in them, because they stick to the
old one.  Therefore, the new text only gives the Trust a way around
getting a new RFC published with the new licence explicitly selected
by community consensus.  I don't see the reason to provide that short
cut.  If, however, you think (a-c) are preferable, then your proposed
change makes sense.  

If I were building a product, however, I would be very wary of using
any code whose licence might change after I've shipped my code.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 21 Jul 2009 10:59:06 -0400

>    to your option (2), I think, and you say its undesirable.

I am not a lawyer, but I don't see how legally we could do anything  
but (d).

Regards
Marshall

> _______________________________________________
> Trustees mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trustees
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Jul 2009 11:49:14 -0400

On Tue, Jul 21, 2009 at 10:52:30AM -0400, Joel M. Halpern wrote:

> Clearly, any change in IETF policy can not change the text in an RFC.  

Only if by "the text" you exclude all the implicitly included text
that is the resolution of a pointer in "the text" strictly construed.
If the actual text says, "This code is covered by the licence
currently published by the Trust," then the real meaning of that text
changes depending on $current_licence.  This sort of referential issue
is what Russell is talking about when discussing the present King of
France and whether His Imaginary Majesty is bald.  I'd prefer not to
relive that portion of my undergrad education every time someone
decides a licence change would be good.

> Nor can it change what someone has done historically complying with that  
> text.

Sure.

> The issue is that we may discover that we would prefer that folks use a  
> different license going forward.  

That is the scenario (c) that I described.  I have shipping derivative
code under BSD, but new derivative code is forced to be under GPL, for
instance.  (I find that to be a pretty absurd situation to be trying
to cause, but it appears to be what is wanted by some.)  This means
that my competitor can't use the derived code under the same terms I
can, and presumably that new interoperating products of my own, using
the same code, can't be released under the same licence as I used the
first time.  Is that really what we want?

The position I outline in (d) is what we might call the early-binding
option: the Trust can't change the licence terms of code in an RFC
after the RFC is published, period.  If there is a desire to change
the licence, a new RFC is needed (and, of course, the obsoleted RFC's
code is still under its original licence).  From my point of view,
this is the clearest alternative.  Everything else sounds to me like a
good way to generate work for corporate counsel in figuring out
exactly what licence is in effect on any given day, but not a good way
to ensure that geeks can get their jobs done with a minimum of fuss
(which is, I assume, a major part of the ultimate goal).

> But given the pain that gratuitous boilerplate changes introduce, I  
> would prefer not to need such for an easily foreseeable situation.

Surely the right answer, then, is to minimise gratuitous boilerplate
changes, which can be partly achieved by saying, "You need a new RFC
to change the licence terms."

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Jul 2009 18:28:27 +0200

>     of my product might have to have a different licence).
I think this is the version that applies, with one difference that matters.

Under the BSD license, you can ALSO give copies of the copy you took 
from the RFC to anyone at any time, and they will have the right of 
modification, but not the right to publish the code without the BSD 
license text - that is, the BSD license is a sublicenseable license.

Effectively, the code will be available under all licenses that the 
Trust has ever licensed stuff under between the time of publication and 
the present time; if a more restrictive license is used (perish the 
thought!), you have the right to fork the code, and distribute the 
forked code under the BSD license in perpetuity.
> any code whose licence might change after I've shipped my code.
See above. But as usual, IANAL, I just have opinions.

                       Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Jul 2009 18:40:52 +0200

Robert Elz wrote:
>     Date:        Tue, 21 Jul 2009 08:57:01 +0200
>     From:        Harald Alvestrand <[email-masked]>
>     Message-ID:  <[email-masked]>
>
>   | We have two possibilities:
>   | 
>   | 1 - the update consists of revisions of *every single RFC* that 
>   | references the BSD license
>   | 2 - some RFCs continue to carry the BSD license, even while the "real" 
>   | current license is different.
>
> Harald,
>
> what you're anticipating there is absurd, if an RFC gets issued containing
> code with the BSD licence, then that is the licence that code, in that RFC
> will have forevermore, nothing can change that - and nothing should change
> that, nothng the trustees or community can do can ever change that - only
> the rights holder (author) of the code can cause it to be offered with
> some different licence.    Any system where it even looked as if it were
> possible for anyone to simply alter the licence under which code that
> had previously been published became available would be a disaster.
>   
Robert,

I'm afraid that your perception disagrees with the structure that RFC 
5378 set up. The Trust has enough rights to license code under a license 
of its choice, and has currently chosen to use the BSD license.

The authors may *in addition* license the code under the BSD license, 
the GPL license, or any other license they feel like using, and there's 
no way the Trust can stop them from doing that. But neither can the 
authors restrict the Trust's ability to license the code.

It may be a disaster, but it's been in that state since November 2008.

                  Harald

---

From: Tom Taylor <[email-masked]>
Date: Tue, 21 Jul 2009 12:27:04 -0400

I think Andrew makes a lot of sense. I really can't envision a situation where 
the IETF would want to change licence terms en masse, given the impact Andrew 
demonstrates on deployed or ready-to-deploy product.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 22 Jul 2009 08:32:38 +0200

Robert Elz wrote:
>     Date:        Tue, 21 Jul 2009 18:40:52 +0200
>     Message-ID:  <[email-masked]>
>
>   | I'm afraid that your perception disagrees with the structure that RFC 
>   | 5378 set up.
>
> I was misunderstanding what's going on, Joel has been educating me off list...
>
> But while my reasoning changes slightly, my conclusion does not.
>
>   | The Trust has enough rights to license code under a license 
>   | of its choice, and has currently chosen to use the BSD license.
>
> I think we can agree that the trust (the IETF) cannot give away more
> rights than it has obtained from the contributor (however much they are,
> and if that's "everything related to copyright" that's fine).
>
> I can think of no reason why the trust (IETF) should ever offer less
> than what the contributor has allowed - that would be entirely contrary
> to the purposes for which we need licences from the contributor in the
> first place - the aim is to make sure that the code is available with
> as few restrictions as possible, having the trust add restrictive licence
> terms would be counter productive (regardless of what those terms are).
>   
The working group's non-consensus on this point is documented in section 
4.4 of RFC 5377:

4.4.  Rights Granted for Use of Text from IETF Contributions

   There is no consensus at this time to permit the use of text from
   RFCs in contexts where the right to modify the text is required.  The
   authors of IETF Contributions may be able and willing to grant such
   rights independently of the rights they have granted to the IETF by
   making the Contribution.

> If all that's reasonable, then it follows that licence in == licence out,
> and while it is possible that might be change from time to time, the
> change must be to the licence in first, and that then means that the
> licence out change affects only those RFCs published after the change,
> one earlier must still be on the old terms (if the change was broadening
> the licence to the IETF, then no earlier submission by anyone would be
> broader in the new way, and so the outgoing licence could not be the new
> broader form, if the change is to narrow the rights given to the IETF,
> that will necessarily narrow what the IETF can grant users of the code,
> but there's no reason it should restrict the rights granted under older
> submissions, that were published with a broader grant to the IETF.
>   
The "RFC 5378" license to the trust allows, for instance, the Trust to 
grant the right of copying small snippets of code without attaching the 
full BSD license to them. The current TLP does not give that right.

Incoming and outgoing rights for code are currently different.
> So, I remain fairly convinced that there's no need at all to ever
> make (or pretend to make) any change which would ever require updating all
> past RFCs, a change should only ever affect future publications.
>   
I'm fairly convinced that there will come a time when we need to 
relicense text that was previously licensed by the Trust in a way that 
is more liberal than the current text of the TLP allows for (while 
remaining within the scope of rights granted to the trust).

That's why I yell so much on this matter.

                   Harald

---

From: Robert Elz <[email-masked]>
Date: Wed, 22 Jul 2009 08:25:54 +0700

kre

ps; there is no assumption in anything above that every RFC must necessarily
have the exact same licence terms, negotiation with contributors might
sometimes be reasonable, nothing above is altered by this, what matters is
that the licence granted to the IETF for any particular code segment should
be exactly the licence the IETF grants to users of that code.

---

From: Robert Elz <[email-masked]>
Date: Wed, 22 Jul 2009 18:22:47 +0700

Date:        Wed, 22 Jul 2009 08:32:38 +0200
    From:        Harald Alvestrand <[email-masked]>
    Message-ID:  <[email-masked]>

I don't want to say much more on this issue, I suspect enough has
been said now, but just one final (from me) point ...

  | The working group's non-consensus on this point is documented in section 
  | 4.4 of RFC 5377:
  | 
  | 4.4.  Rights Granted for Use of Text from IETF Contributions
  | 
  |    There is no consensus at this time to permit the use of text from
  |    RFCs in contexts where the right to modify the text is required.  The
  |    authors of IETF Contributions may be able and willing to grant such
  |    rights independently of the rights they have granted to the IETF by
  |    making the Contribution.

I have no idea how to interpret that - one meaning might be that
contributors of code to the IETF can assume that the IETF will not
grant rights that allow modification of the text.   If that's how it
works out, then once again, whatever you think other parts of the
RFC say, contributors can rely upon that, and then the IETF cannot
later change its mind, and allow modification - the contributor gave
the code based upon the assumption that would not be permitted.

On the other hand, if we're all convinced that the contributor must be
giving the IETF the rights to do whatever it likes with the contribution,
including permitting modifications - then the IETF should be (and by
referring to a BSD like licence, in fact, is) allowing people do do
whatever they want with code in an RFC - which includes modifying it.

After all "there is no consensus to permit" also can be written with
the exact same meaning as "there is no consensus not to permit", that's
what "no consensus" means (though authors sometimes try to describe a
point where there's no agreement at all to make it look as if the result
of that should be what they think the outcome should be - which is what
the paragraph you quoted looks like to me.   That is, we couldn't get
people to agree to prohibit modifications, so we'll write a paragraph
that makes it look like the base position is to prohibit that, and then
make it clear that we didn't agree that distribution with modification
rights should be allowed - everyone will just conclude that it isn't
allowed...

That's bogus, and it looks to me (by use of the BSD licence, which if
the advertising clause were removed, which it should be (and is in the
current version of the BSD licence) about as liberal as it is possible to be.
That is, I cannot see it is possible to be more liberal (advertising
excepted, and that's a minor point) than the BSD licence which is being
specified.

Making it truly difficult to change makes it harder for the distribution
to be made more restricted, which looks to me to be just about the only
way it is possible to move (and if the advertising clause has been, or can
be quicky, removed from the IETF's version of the BSD licence, then we're
about as unrestricted as it is possible to get).

On the other hand, if the IETF's "BSD licence" is currently prohibiting
modifications, then it clearly is not a BSD licence at all (so you'd be
right, that name ought to be removed as being misleading) - and that ought
to be fixed, as quoted above (being read carefully) we have no consensus
to prohibit distribution with modifications permitted (unless the
contributors are not granting that right, of course) so we may as well
just allow modifications.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jul 2009 11:40:24 +1200

This may seem like a small comment but I believe it is important.
We know that we have an issue to resolve collectively, namely the
IPR regimes for non-IETF stream documents. We probably agree that
(as the revised TLP says or implies) it is for each stream individually
to decide whether it accepts none, some or all of the IETF rules
and the IETF Trust's legal provisions.

However, Clause 2.f.i of the draft revised TLP includes the
statement "The IETF Trust does not determine the legal rules that
apply to documents in Alternate Streams."

I would like to see that changed to "The IETF Trust does not
*currently* determine the legal rules that apply to documents in
Alternate Streams."

Rationale: some of the other streams might choose to request the
Trust to do so. (Or they might not; I don't know.)

I have re-read the "Purpose" clause of the Trust Agreement, and
it has the flexibility to allow the Trust to do this, if so
requested and agreed. We shouldn't remove that flexibility.

There are other issues in this area, but John Klensin's appeal
already addresses them.

Regards
   Brian Carpenter