Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[joel jaeggli]

On 9/18/12 11:46 PM, Joe Touch wrote:



On 9/16/2012 6:56 AM, Lawrence Conroy wrote:
...

It is VERY useful to be able to search through drafts to see how we
got here, AND to see things that were explored and abandoned.


Thieves find it very useful to have what they steal. That doesn't 
legitimize their theft.


Utility can determine whether it's worth the effort/expense to run a 
public archive, but your utility never undermines my rights as an author.

Non-lawyer here...

An authors rights are not entirely exclusive. e.g. 17 U.S.C 107 applies.

Joe

Re: copyright notices in RFC 6716

[Simon Josefsson]

Russ,

I had missed that section (which seems like a wonderful section btw).
However the license isn't what my initial question was about, so this is
a red herring.  This also explains why I wasn't able to follow Cullen's
initial reply.  My question was about the copyright header.  Let's see
if I can be clearer...  The TLP says the copyright header must be:

Copyright (c)  IETF Trust and the persons identified as
authors of the code.  All rights reserved.

but the code in the document uses:

Copyright 1994-2011 IETF Trust, Xiph.Org, Skype Limited, Octasic,
   Jean-Marc Valin, Timothy B. Terriberry,
   CSIRO, Gregory Maxwell, Mark Borgerding,
   Erik de Castro Lopo. All rights reserved.

The difference between these two forms is what I'm wondering about.
Essentially what I'm asking is which one applies of:

 1) Was the copyright header variation permitted intentionally for this
 document as an exception to the TLP?

 2) Nobody noticed that the copyright header was different from what the
 TLP demands.

 3) Something else.

/Simon

Russ Housley  writes:

> Simon:
>
> The RFC contains the usual boilerplate and one additional paragraph.
> The rights granted in the additional paragraph align with the rights
> that the authors wanted to provide.  Here is the additional paragraph:
>
>The licenses granted by the IETF Trust to this RFC under Section 3.c
>of the Trust Legal Provisions shall also include the right to extract
>text from Sections 1 through 8 and Appendix A and Appendix B of this
>RFC and create derivative works from these extracts, and to copy,
>publish, display and distribute such derivative works in any medium
>and for any purpose, provided that no such derivative work shall be
>presented, displayed or published in a manner that states or implies
>that it is part of this RFC or any other IETF Document.
>
> Russ
>
>
> On Sep 18, 2012, at 5:33 PM, Simon Josefsson wrote:
>
>> Russ,
>> 
>> I can't seem to align what you say with the document content.  The
>> rights granted by the license text in the document (quoted below)
>> appears to me be identical to the TLP except that the copyright header
>> also includes non-authors.  Is this what you refer to with granting
>> additional rights?
>> 
>> My concern is not about rights granted (they appear to follow the TLD),
>> but with the form of the copyright header that deviates from the TLD
>> boilerplate.
>> 
>> What puzzles me is that the explanation that I have received earlier is
>> that variations beyond what the TLP demand is not permitted even if
>> there is community support for the content of a particular document.
>> I'm happy if this is now the policy, as it would allow including more
>> source code into RFCs.
>> 
>> /Simon
>> 
>> Russ Housley  writes:
>> 
>>> Simon:
>>> 
>>> The authors wanted to grant additional rights beyond those that are
>>> granted by the TLP.  They indicated those rights in Section 10 of the
>>> internet-Draft.  This was challenged during WG Last Call, and it was
>>> challenged during IETF Last Call.  In each case, the authors make
>>> their desire clear and the community supported them.  For this reason
>>> the IETF Trust granted the usual TLP rights and the additional rights
>>> as well.
>>> 
>>> Russ
>>> 
>>> 
>>> On Sep 13, 2012, at 10:18 AM, Simon Josefsson wrote:
>>> 
 All,
 
 I noticed that the recent RFC 6716 contains some reference code that
 contain the copyright and licenses notice reproduced below.  The IETF
 TLP [1] mandates a certain form of copyright notices and the TLP does
 not, as far as I can see, permit varying the boiler plate in any way.
 Note that both companies and organisations are mentioned in the
 copyright notice in RFC 6716, besides individuals.
 
 Does this indicate a policy change, a mistake with that document, or
 something else?
 
 Btw, kudos to the RFC 6716 authors for shipping reference code!  I hope
 this will establish a best practice for standards in the future.
 
 /Simon
 
 [1]
 http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.htm
 
 Copyright 1994-2011 IETF Trust, Xiph.Org, Skype Limited, Octasic,
   Jean-Marc Valin, Timothy B. Terriberry,
   CSIRO, Gregory Maxwell, Mark Borgerding,
   Erik de Castro Lopo. All rights reserved.
 
 This file is extracted from RFC6716. Please see that RFC for additional
 information.
 
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
 
 - Redistributions of source code must retain the above copyright
 notice, this list of conditions and the following disclaimer.
 
 - Redistributions in binary form must reproduce the above copyright
 notice, this list of conditions and

Re: Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

[John C Klensin]

--On Tuesday, September 18, 2012 21:24 -0500 Ben Campbell
 wrote:

> I am the assigned Gen-ART reviewer for this draft. For
> background on Gen-ART, please see the FAQ at
> 
>  .
> 
> Please resolve these comments along with any other Last Call
> comments you may receive.
> 
> Document:  draft-ietf-eai-simpledowngrade-07
> Reviewer: Ben Campbell
> Review Date: 2012-09-18
> IETF LC End Date: 2012-09-20
> 
> Summary: This draft is mostly on the right track, but has open
> issues
> 
> Major issues:
> 
> -- I'm concerned about the security considerations related to
> having a mail drop modify a potentially signed message. The
> draft mentions that this is an issue. I think more discussion
> is warranted. In particular. What client behavior is expected
> when a signature is invalidated due to downgrading? I suspect
> the answer is "warn the user, who will most likely just click
> through without understanding the issue." I'm concerned about
> adding yet another reason to train end users to ignore
> security warnings. OTOH, should the mail drop strip out
> signatures? That has it's own issues. I'm not saying that I
> know the answer--merely that it's not clear to me that it has
> been sufficiently explored.

Ben,

I want to respond as WG Co-chair to this one issue.  Comments on
your minor issues will follow, but please be assured that the
non-editorial ones (and even some of those) have been discussed
extensively in the WG.

There is a fundamental issue that runs across the four
documents, that the WG discussed extensively, and that the WG
believes is adequately described.  The WG made an explicit
decision to not repeat that explanation at every possible point
and in each document.  It explicitly chose overall brevity over
repetition partially in the belief that repeating the material
might cause important comments or requirements to get lost in
the noise.  At the same time, it is easy to lose sight of the
issue and its implications when reviewing the documents.  It
actually becomes very clear when one starts considering
implementation details.

That issue is that a upgraded IMAP or POP server may find itself
in possession of an message that requires SMTPUTF8 ("EAI")
capability, that it may be one message of that type among many
messages with ACSCII-only headers that do not require that
capability, and that it may find itself connected to by a legacy
client.  There are two important things about that case:

* There is absolutely no way to deliver the problem
message to the client.  The IMAP and POP specifications,
and the basic email transport and header specifications
from which their provisions are derived, are absolutely
clear that addresses and header fields are in ASCII
(IMAP allows for the use of some alternate character
sets and encodings, but that turns out to be a bad
choice in this case and, fwiw, conversion to use any of
them would also invalidate signatures.

* There are no provisions in POP or IMAP for the server
to say to the client "this particular message fails
within the range you have specified, but cannot be
delivered to you" (much less why that is the case).  In
principle, EAI could have added such capabilities but
they would not haved helped legacy clients (that, by
definition, didn't implement them), would have added
clutter to the protocols, and would not have benefited
upgraded clients either (because it is easier to just
support UTF-8 headers and other requirements.

Given that situation, the POP or IMAP server can choose to do
any of a range of things, all of them bad news.  Two of the
choices are to _replace_ the original message with a substitute
(or "synthetic" or "surrogate") message that provides the user
of the client some more or less good hints  about what is going
on and what the original message was about.  What is being
delivered is not the original message.  If the original
contained non-ASCII addresses, the surrogate will not be able to
represent them directly and will, in general, not be reply-able.
Expecting an integrity check on the original message to be valid
with the surrogate one is unreasonable; indeed, one would be
very concerned if such a check (signature-based or otherwise)
did validate.  

When there is an integrity check present, perhaps the Right
Thing would be to disable it and include a note in the surrogate
message that indicates that the original contained such a check.
The wording was intended to allow for that option when it is
deemed appropriate and feasible by the server's designers and
operators.  But remember that there are undetectable cases (not
covered specifically by IETF standards) such as when the
signature or equivalent information is transmitted out of band.

The net result of this is that saying much more in the Security
Consi

Re: Gen-ART LC Review of draft-ietf-eai-5738bis-09

[John C Klensin]

Following up on my earlier note about a comment from you that
really applies to the strategy on which all four documents are
really based...

--On Tuesday, September 18, 2012 20:44 -0500 Ben Campbell
 wrote:

>...
> Along the same lines, section 7 seems to go to lengths to
> illustrate why downgrading is somewhere between hard and
> problematic. Do we really believe that downgrading will ever
> be the "least bad"?

As compared to what, Ben?  

One alternative is to not support delivery of SMTPUTF8 messages
at all except in environments in which it can be guaranteed that
all IMAP and POP clients that might contact the servers are
already upgraded.  It is operationally possible to make that
guarantee in a few scenarios, but they are rare.   In those
scenarios, many people in the WG would say "do that" (easily
managed by not having the delivery servers accept SMTPUTF8
messages until the POP/IMAP client upgrades are complete).
But, for all of the more usual cases in which the IMAP/POP
server operator cannot control exactly what clients might be
used, the only alternate is to not allow such messages, ever.
We don't think that is a desirable choice (or we wouldn't have
done the work in the WG) but nothing in these protocols require
that anyone deploy i18n mail.

For the other alternatives, yes, downgrading --by one of these
scenarios or some other one-- is, indeed, likely to be "less
bad" than others in some operational scenarios.   In particular,
one alternate is for the server to silently delete all messages
requiring SMTPUTF8 (EAI) capability if a client connects that
doesn't support the needed capability.  If only because the user
might later come back with a more capable client (or a message
access mechanism that doesn't use a POP or IMAP client at all),
that messaging-deleting alternative is almost certainly the
worst option of all, making almost anything else "less bad".

And, again, yes the WG discussed these issues at length, perhaps
even ad nauseam.

john

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[Martin Rex]

Joe Touch wrote:
> 
> Lawrence Conroy wrote:
>> 
>> It is VERY useful to be able to search through drafts to see how we
>> got here, AND to see things that were explored and abandoned.
> 
> Thieves find it very useful to have what they steal. That doesn't 
> legitimize their theft.
> 
> Utility can determine whether it's worth the effort/expense to run a 
> public archive, but your utility never undermines my rights as an author.

You're still seriously confusing things.

An I-D contribution transfers perpetual (i.e. irrevocable) redistribution
rights to the IETF -- at a minimum since rfc2026 (Oct 1996) and
1id-guidelines.txt pointing to rfc2026 section 10.  For copyrighted
contents, the perpetual, irrevocable transfer of specific rights is
actually the norm, and an extraordinary, time-limited lease of rights
would have to be negotiated and mutually agreed to in order to apply.
(in German legalese the term is "Erschöpfungsgrundsatz").


The management of the online I-D repository and the expiration of
documents in there has NOTHING whatsoever to do with that transfer
of rights.

Surely an author can decide to re-publish the I-D contents under
different licenses somewhere else or later.  But that does not
impair the rights previously granted to the IETF in any way.


What is necessary, however, for the transfer of rights according to
rfc2026 section 10 to have happened, is that the I-D submitter was
in posession of (or entitled to) grant/transfer these rights.  
Only when the I-D submitter did not have that rights when he submitted
the document, would require the IETF to stop re-distribution the I-D
when it became aware of this (and found itself unable to retroactively
obtain the necessary rights from the rightful owner).


-Martin

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[John Levine]

>Utility can determine whether it's worth the effort/expense to run a 
>public archive, but your utility never undermines my rights as an author.

We're very deep into Junior Lawyer territory here.

You might want to review RFC 3978, section 3.3a, in which contributors
make a:

  perpetual, irrevocable, non-exclusive, royalty-free, world-wide
  right and license to the ISOC and the IETF under all intellectual
  property rights in the Contribution:

This is unrelated to how long I-D's stay in the public archive.  If
you're not willing to accept those terms including the perpetual and
irrevocable part, you really shouldn't be submitting I-Ds or sending
mail to IETF mailing lists.

R's,
John

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[Joe Touch]

On 9/19/2012 11:24 AM, John Levine wrote:

Utility can determine whether it's worth the effort/expense to run a
public archive, but your utility never undermines my rights as an author.


We're very deep into Junior Lawyer territory here.


I'm not. I'm simply refuting *any* argument that starts with "because 
it's useful to the community".


There are other arguments - that lawyers will make - that depend on the 
particular boilerplate used, when the ID was published, whether 
click-based copyright transfer holds up, and so forth.


But utility doesn't drive the law. There are rights -rights of the 
author, and rights of the copyright holder - which are protected here, 
and they trump any perceived benefit to the community.


Joe

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[Carsten Bormann]

On Sep 19, 2012, at 22:28, Joe Touch  wrote:

> I'm simply refuting *any* argument that starts with "because it's useful to 
> the community".

Interestingly, these kinds of arguments are the only ones I'm interested in.

Until there is a court decision impacting this usefulness (or one can be 
reasonably expected), the legal angle is simply irrelevant.

(Just keeping the thread alive so it doesn't seem that everybody agrees with 
the strangely luddite position taken here.)

Grüße, Carsten

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[John Levine]

In article <505a2b08.70...@isi.edu> you write:
>
>
>On 9/19/2012 11:24 AM, John Levine wrote:
>>> Utility can determine whether it's worth the effort/expense to run a
>>> public archive, but your utility never undermines my rights as an author.
>>
>> We're very deep into Junior Lawyer territory here.
>
>I'm not. I'm simply refuting *any* argument that starts with "because 
>it's useful to the community".

Could you answer the question, please?  Are you saying that you are
unaware, or do not believe that you have already given the IETF a
permanent license for all of your I-Ds and all your other IETF
contributions, which means it can publish them any way it wants
whether you like it or not?

This horse left the barn so long ago that the barn has long since
been torn down and replaced by a parking lot.

R's,
John