Send Ietf mailing list submissions to
ietf(_at_)ietf(_dot_)org
To subscribe or unsubscribe via the World Wide Web, visit
https://www1.ietf.org/mailman/listinfo/ietf
or, via email, send a message with subject or body 'help' to
ietf-request(_at_)ietf(_dot_)org
You can reach the person managing the list at
ietf-owner(_at_)ietf(_dot_)org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ietf digest..."
Today's Topics:
1. The Trust Agreement Proposal (John C Klensin)
2. Re: [IAOC] Re: The IETF Trust License is too restricted
(Simon Josefsson)
3. Re: The IETF Trust License is too restricted (Sam Hartman)
4. Any Final Comments on the IETF Trust (Lucy E. Lynch)
5. Re: [IAOC] I know I am dumb stupid but I am also dumb
stubborn [was IETF Trust license is too restricted] (Lucy E. Lynch)
6. The Trust Agreement Proposal (Bob Hinden)
7. Re: Appeal: Publication of draft-lyon-senderid-core-01 in
conflict with referenced draft-schlitt-spf-classic-02
(Frank Ellermann)
8. Re: Last Call: 'NETCONF Configuration Protocol' to Proposed
Standard (Sam Hartman)
9. Re: [IAOC] I know I am dumb stupid but I am also dumb
stubborn [was IETF Trust license is too restricted]
(JFC (Jefsey) Morfin)
----------------------------------------------------------------------
Message: 1
Date: Thu, 08 Dec 2005 14:00:49 -0500
From: John C Klensin <john-ietf(_at_)jck(_dot_)com>
Subject: The Trust Agreement Proposal
To: "Lucy E. Lynch" <llynch(_at_)darkwing(_dot_)uoregon(_dot_)edu>
Cc: ietf(_at_)ietf(_dot_)org
Message-ID: <21B2C7D31E873A43417F4C0A(_at_)scan(_dot_)jck(_dot_)com>
Content-Type: text/plain; charset=us-ascii
Lucy and IAOC,
I've reviewed the notes on the list, the FAQs, the Settlor
agreements, and what I assume is the new 9.5 text. First of
all, I'd like to express thanks to the IAOC for being willing to
open the agreement up to community review, comment, and approval
and for making changes that process seemed to call for. I think
that, as the result of this process, critical provisions of the
document are vastly better than they were and hope that the IAOC
and the rest of the community agree.
Some of the provisions of the current version are not what I
would have preferred in a more perfect world. On the other
hand, in such a world, I don't know whether we would have the
Trust model at all and certainly would have preferred that the
IAOC not spend a large fraction of the last year negotiating it.
But this is not, as we all know, a perfect world. Given the
actual world in which we live, it is as important to know where
to stop, approve a document, and move on, rather than letting
the quest for perfection drag things out and block other
important tasks.
It appears to me that we have reached that point. I would urge
others to consider whether more discussion and tuning is really
worth the possible benefits.
The more recent discussion about the rights the IETF might have
and want to grant seems largely irrelevant to the Trust
agreement given the new wording (it did not appear irrelevant
under the old agreement). It seems to me that the IETF (or the
IASA, or either or both Settlors) might lay full or partial
claim to two fundamentally different types of IPR:
(i) Materials associated with the development, approval,
or publication of standards. These are materials
contributed to the IETF by its participants or prepared
for the IETF, under contract or other arrangement, in
support of those materials. Those materials now appear
to be excluded from the scope of 9.5. I say "appear"
under the IANAL disclaimer, but, if counsel has advised
the IAOC that the wording is adequate, then I think that
case is taken care of.
(ii) Materials associated with, or developed as a
consequence of, the operation of the IETF or
administration of the standards process. Those
materials might be developed under contract, or might
include documents or tools contributed to the IETF to
make its processes more efficient. These are the
materials that appear to be covered under 9.5 now and,
as far as I can tell, they are not covered at all by RFC
3979. Even in my most vivid imaginings, I cannot
imagine a legitimate purpose for which another body
would want most of that stuff, much less one under which
a "share alike" provision would be clearly
inappropriate. Exceptions might occur with tools or
similar material contributed to the IETF, but the
solution there is for the author to reserve some rights,
giving the IETF/IASA only the right to use the tools and
perhaps to modify them for specialized purposes. So
while, in principle, I would prefer to see no
restrictions on the choices the IETF might make, I don't
see these restrictions as having any significant impact.
So, from my point of view, while the IPR Licensing debate should
continue in its own right, we have gotten past the point at
which it has enough interaction with the Trust to justify
holding the latter up.
In conclusion, I think we have reached the point at which it is
appropriate to approve this thing and get one with the
standards-creation and definition business of the IETF.
john
------------------------------
Message: 2
Date: Thu, 08 Dec 2005 20:05:49 +0100
From: Simon Josefsson <jas(_at_)extundo(_dot_)com>
Subject: Re: [IAOC] Re: The IETF Trust License is too restricted
To: Brian E Carpenter <brc(_at_)zurich(_dot_)ibm(_dot_)com>
Cc: IAOC <iaoc(_at_)ietf(_dot_)org>, Sam Hartman
<hartmans-ietf(_at_)mit(_dot_)edu>,
ietf(_at_)ietf(_dot_)org, Harald Tveit Alvestrand
<harald(_at_)alvestrand(_dot_)no>
Message-ID: <iluacfbpfxu(_dot_)fsf(_at_)latte(_dot_)josefsson(_dot_)org>
Content-Type: text/plain; charset=us-ascii
Brian E Carpenter <brc(_at_)zurich(_dot_)ibm(_dot_)com> writes:
Lucy E. Lynch wrote:
On Thu, 8 Dec 2005, Simon Josefsson wrote:
Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu> writes:
I think it is sufficient the trust be able to operate under any set of
outbound rights we come up with.
That won't be possible, given the current (and even the updated) IETF
Trust agreement.
The IETF may decide that third parties should be given rights to all
contributions, not only to RFCs/I-Ds.
Currently, the IETF Trust would be unable to comply to such a wish
from the IETF, because the Trust agreement prevent them from doing so.
explain please, I don't understand this.
Straw man?
To me, the new phrase "IETF
standards-related documents (such as RFCs, Internet Drafts and the
like)" clearly covers contributions to the standards process, i.e.
the same scope as RFC 3978. I don't see a problem here.
RFC 3978 define Contributions as:
c. "IETF Contribution": any submission to the IETF intended by the
Contributor for publication as all or part of an Internet-Draft or
RFC (except for RFC Editor Contributions described below) and any
statement made within the context of an IETF activity. Such
statements include oral statements in IETF sessions, as well as
written and electronic communications made at any time or place,
which are addressed to:
o the IETF plenary session,
o any IETF working group or portion thereof,
o the IESG, or any member thereof on behalf of the IESG,
o the IAB or any member thereof on behalf of the IAB,
o any IETF mailing list, including the IETF list itself, any
working group or design team list, or any other list
functioning under IETF auspices,
o the RFC Editor or the Internet-Drafts function (except for RFC
Editor Contributions described below).
That is considerably more than what even a lax interpretation of "IETF
standards-related documents" would mean.
So I do see a (minor) problem.
Thanks,
Simon
------------------------------
Message: 3
Date: Thu, 08 Dec 2005 14:19:54 -0500
From: Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu>
Subject: Re: The IETF Trust License is too restricted
To: Simon Josefsson <jas(_at_)extundo(_dot_)com>
Cc: Harald Tveit Alvestrand <harald(_at_)alvestrand(_dot_)no>,
ietf(_at_)ietf(_dot_)org,
IAOC <iaoc(_at_)ietf(_dot_)org>
Message-ID: <tslbqzro0px(_dot_)fsf(_at_)cz(_dot_)mit(_dot_)edu>
Content-Type: text/plain; charset=us-ascii
I don't see the problem here. For example, I believe the IETF could
license a tool under the GPL if it wanted to. I believe it would need
to require that work it paid for was assigned to the trust but that's
a fairly common practice.
------------------------------
Message: 4
Date: Thu, 8 Dec 2005 12:50:28 -0800 (PST)
From: "Lucy E. Lynch" <llynch(_at_)darkwing(_dot_)uoregon(_dot_)edu>
Subject: Any Final Comments on the IETF Trust
To: ietf(_at_)ietf(_dot_)org
Message-ID:
<Pine(_dot_)GSO(_dot_)4(_dot_)58(_dot_)0512081239350(_dot_)1595(_at_)darkwing(_dot_)uoregon(_dot_)edu>
Content-Type: TEXT/PLAIN; charset=US-ASCII
All -
I'll be closing the Consensus Call on the the IETF Trust at 5:00PM
PST today. The current version of the document, incorporating the new
language for Section 9.5 can be found here:
http://koi.uoregon.edu/~iaoc/docs/IETF-Trust-12-08-05.pdf
Please send any final comments to: ietf(_at_)ietf(_dot_)org or
iaoc(_at_)ietf(_dot_)org
Thanks
Lucy E. Lynch Academic User Services
Computing Center University of Oregon
llynch @darkwing.uoregon.edu (541) 346-1774
------------------------------
Message: 5
Date: Thu, 8 Dec 2005 12:55:47 -0800 (PST)
From: "Lucy E. Lynch" <llynch(_at_)darkwing(_dot_)uoregon(_dot_)edu>
Subject: Re: [IAOC] I know I am dumb stupid but I am also dumb
stubborn [was IETF Trust license is too restricted]
To: "JFC (Jefsey) Morfin" <jefsey(_at_)jefsey(_dot_)com>
Cc: IAOC <iaoc(_at_)ietf(_dot_)org>, ietf(_at_)ietf(_dot_)org
Message-ID:
<Pine(_dot_)GSO(_dot_)4(_dot_)58(_dot_)0512081252590(_dot_)1595(_at_)darkwing(_dot_)uoregon(_dot_)edu>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 5 Dec 2005, JFC (Jefsey) Morfin wrote:
At 15:50 05/12/2005, Brian E Carpenter wrote:
Simon,
You are bit behind real time. We already updated this text.
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01837.html
Dear Brian,
Great! the three stupid points I am stubbornly interested in are
gathered here! Please read what follows with humour, however the
three issues are serious.
<snip>
If I copy all the RFCs, sort their content, add a legal blabla paying
my respects to all those who contributed through the IETF, make an
open use e-book from them all, class their proposition in some
orders, updating it when they change, mixing them with other SSDOs
propositions, etc. translating parts in various languages, adding
comments on their usage cons and pros and testing, linking the
various comments people may have made on them, etc. quoting available
open source/commercial libraries and their variations, etc. and the
various registry repositories where they can find the values of the
related parameters, i.e. what the users long for a while, will the
IAOC sue me and send me to jail as the US DMCA and the French DADVSI would
do?
Tounge firmly in cheek:
Of course we won't send you to jail. We'll make you come live in a
country with no real cheese and a lot of overly oak-y white wine.
far worse. ;-)
- lel
thank you
jfc
_______________________________________________
IAOC mailing list
IAOC(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/iaoc
------------------------------
Message: 6
Date: Thu, 8 Dec 2005 13:48:27 -0800
From: Bob Hinden <bob(_dot_)hinden(_at_)nokia(_dot_)com>
Subject: The Trust Agreement Proposal
To: "Lucy E. Lynch" <llynch(_at_)darkwing(_dot_)uoregon(_dot_)edu>
Cc: IETF discussion list <ietf(_at_)ietf(_dot_)org>
Message-ID: <2B73E8B7-83EA-42EE-8D09-D6497C260783(_at_)nokia(_dot_)com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Lucy and IAOC,
As John Klenson, said we don't live in a perfect world. I think the
trust agreement as written solves some very important problems we
have now (e.g., getting rights to things like the IETF's domain name,
past meeting proceedings, email archives, etc.). It is probably not
perfect, but more than good enough to go forward with. I think that
we can work around any issues that come up and have the ability to
revise it in the future.
I support it and urge others to do so.
I also want to thank Lucy and the other members of IAOC for the all
the time and hard work they have put into this. It's an important
step for the IETF.
Bob
------------------------------
Message: 7
Date: Thu, 08 Dec 2005 23:05:49 +0100
From: Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in
conflict with referenced draft-schlitt-spf-classic-02
To: ietf(_at_)ietf(_dot_)org
Cc: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Message-ID: <4398AE3D(_dot_)512D(_at_)xyzzy(_dot_)claranet(_dot_)de>
Content-Type: text/plain; charset=us-ascii
The IESG decided:
while we have found merit in Julian Mehnle's technical
concerns, we will not change our decision to publish the
draft as an Experimental RFC without change to its technical
content.
The IESG did consider this conflict in its original
discussions, and that is one of the reasons why we crafted
the original IESG note to be included in these documents,
which highlights that there are concerns about using these
mechanisms in tandem.
That's beside the point. Of course "consenting adults" can use
"spf2.0/mfrom,pra", and that's semantically almost the same as
"v=spf1" plus an identical "spf2.0/pra" policy. There are no
technical issues with using these mechanisms in tandem for all
senders explicitly wishing to participate in both experiments.
The issue are senders _not_ wishing to participate in the later
PRA experiment: "v=spf1" is semantically almost the same as
"spf2.0/mfrom" _without_ "spf2.0/pra".
That's what the v=spf1 spec. says with its "NOT RECOMMENDED" in
chapter 2.4. It simply reflects what all v=spf1 specifications
and implementations did since 2003.
It is quite clear that this conflict would not be acceptable
for a standards track specification.
It's also unacceptale for a standards organization with a bare
minimum of ethical and engineering principles.
document the different approaches as they were considered in
the MARID working group.
The MARID WG came to the conclusion that PRA (spf2.0/pra) is in
fact so different from SPF (v=spf1 or spf2.0/mfrom) that they
should be clearly separated. That was the last MARID decision
before this WG was dissolved unilaterally by Mr. Hardie.
[he = Julian]
he requested that we modify draft-lyon-senderid-core to
address the conflict.
Yes, backed by the SPF community and more than 200 signatures
<http://old.openspf.org/cgi-bin/openspf_pledge.cgi>. This does
not include several competent voices who don't like v=spf1, but
still agree that (ab)using v=spf1 for PRA without the explicit
consent of the v=spf1 participants is an ethical and technical
nightmare.
his proposed modification amounted to a substantive technical
change.
That's not the case. His proposal affects _four characters_ in
a chapter about the alleged spf2.0 "backwards" compatibility:
Instead of 'treat v=spf1 like spf2.0/mfrom,pra' this should be
'treat v=spf1 like spf2.0/mfrom'.
The IESG did not consider this an appropriate action to take
in this case.
Well, you are wrong, and everybody can see it. If one draft
says "SHOULD do x", and another draft says "SHOULD NOT do x",
then something has to give.
Depending on the content of the record, this may mean that
Sender-ID heuristics would be applied incorrectly to a
message.
This does _not_ depend on the content of the v=spf1 record. It
depends on a PRA being identical to the MAIL FROM. Which isn't
the case for a significant portion of all mails.
Participants publishing SPF experiment DNS records should
consider the advice given in section 3.4 of RFC XXXX
(draft-lyon-senderid-core) and may wish to publish both
v=spf1 and v=spf2.0 records to avoid the conflict.
There's no such thing as "v=spf2.0 records". This "advice" is
completely bogus, there are more than a million v=spf1 records,
and it will take years to migrate this installed base to use
the new SPF RR.
For this migration period the best they can do is to publish
both SPF and TXT records, "v=spf1" or "spf2.0". Asking the
participants of the older "experiment" to publish four records
instead of two won't fly, let alone anytime soon.
Besides, since when favours the IESG "opt-out" for experiments
with non-consenting participants ?
we hope that this augmented IESG note will address his
concerns.
I seriously doubt it. Bye, Frank
------------------------------
Message: 8
Date: Thu, 08 Dec 2005 17:34:34 -0500
From: Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu>
Subject: Re: Last Call: 'NETCONF Configuration Protocol' to Proposed
Standard
To: iesg(_at_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org
Message-ID: <tsl8xuvmd51(_dot_)fsf(_at_)cz(_dot_)mit(_dot_)edu>
Content-Type: text/plain; charset=us-ascii
Hi. This is not a blocking comment nor am I even asking for a change;
I'm just asking people consider this for netconf and future work.
Netconf currently recommends that netconf over ssh be run over a
different port than the normal ssh port.
That seems like a fine idea. I think there are cases where you might
want to allow access to netconf but not allow access to the CLI
through the normal ssh port.
However I think in many cases it would not be a security problem if
the netconf subsystem were available over the normal ssh port. In
many applications the same privileges will be granted to users over
the CLI as to the same users over netconf. In many cases the
functionality available through netconf will also be available through
the CLI.
--Sam
------------------------------
Message: 9
Date: Fri, 09 Dec 2005 01:44:49 +0100
From: "JFC (Jefsey) Morfin" <jefsey(_at_)jefsey(_dot_)com>
Subject: Re: [IAOC] I know I am dumb stupid but I am also dumb
stubborn [was IETF Trust license is too restricted]
To: "Lucy E. Lynch" <llynch(_at_)darkwing(_dot_)uoregon(_dot_)edu>
Cc: IAOC <iaoc(_at_)ietf(_dot_)org>, ietf(_at_)ietf(_dot_)org
Message-ID:
<6(_dot_)2(_dot_)3(_dot_)4(_dot_)2(_dot_)20051209013831(_dot_)04d982e0(_at_)mail(_dot_)jefsey(_dot_)com>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 21:55 08/12/2005, Lucy E. Lynch wrote:
On Mon, 5 Dec 2005, JFC (Jefsey) Morfin wrote:
At 15:50 05/12/2005, Brian E Carpenter wrote:
Simon,
You are bit behind real time. We already updated this text.
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01837.html
Dear Brian,
Great! the three stupid points I am stubbornly interested in are
gathered here! Please read what follows with humour, however the
three issues are serious.
<snip>
If I copy all the RFCs, sort their content, add a legal blabla paying
my respects to all those who contributed through the IETF, make an
open use e-book from them all, class their proposition in some
orders, updating it when they change, mixing them with other SSDOs
propositions, etc. translating parts in various languages, adding
comments on their usage cons and pros and testing, linking the
various comments people may have made on them, etc. quoting available
open source/commercial libraries and their variations, etc. and the
various registry repositories where they can find the values of the
related parameters, i.e. what the users long for a while, will the
IAOC sue me and send me to jail as the US DMCA and the French
DADVSI would do?
Tounge firmly in cheek:
Of course we won't send you to jail. We'll make you come live in a
country with no real cheese and a lot of overly oak-y white wine.
far worse. ;-)
This response is recorded. And taken as an unusual but formal
permission, due to circumstances and repeated denial of response. It
will be acted upon as described. Any possible opposition will be
objected this response and Brian's one, and unanswered request of
authoritative comments.
NB1: I fully understand that people from the darkwing are jealous
from those living on the brightside. :-)
NB2: I still wait for my response concerning the legal responsibility
of the Trust.
Thank you.
jfc
------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
End of Ietf Digest, Vol 20, Issue 24
************************************