Subject: Re: Document Action: 'US Secure Hash Algorithms (SHA and HMAC-SHA)' to Informational RFC

From: Simon Josefsson <[email-masked]>
Date: Tue, 07 Feb 2006 00:11:33 +0100

The IESG <[email-masked]> writes:

> Note to the RFC Editor
>
>   To resolve the concerns with the term "open source", please make the
>   following changes:
>
>   In the Abstract:
>
>     OLD:
>
>       The purpose of this document is to make open source code
>       performing these hash functions conveniently available to
>       the Internet community.
>
>     NEW:
>
>       The purpose of this document is to make source code
>       performing these hash functions conveniently available to
>       the Internet community.
>
>   In Section 10:
>
>     OLD:
>
>       This document is intended to provide convenient open source
>       access by the Internet community to the United States of
>       America Federal Information Processing Standard Secure Hash
>       Algorithms (SHAs) [FIPS 180-2] and HMACs based thereon.
>
>     NEW:
>
>       This document provides the Internet community convenient
>       access to source code that implements the United States of
>       America Federal Information Processing Standard Secure Hash
>       Algorithms (SHAs) [FIPS 180-2] and HMACs based upon these
>       one-way hash functions.  See license in Section 1.1.

The license in section 1.1 reads:

   Royalty free license to copy and use this software is granted
   provided that this document is identified in all material
   mentioning or referencing this software.

I believe this part of the license is incompatible with some licenses
used to implement IETF protocols.  It has the same problem as the
advertisement clause in the old BSD license.  It is thus questionable
whether the document achieve its stated goal.

Btw:

> The IESG has approved the following document:
>
> - 'US Secure Hash Algorithms (SHA and HMAC-SHA) '
>    <draft-eastlake-sha2-02.txt> as an Informational RFC
>
> This document has been reviewed in the IETF but is not the product of an
> IETF Working Group.

Was there a last call for this document?  I do not recall seeing it.

Thanks,
Simon

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 06 Feb 2006 20:04:51 -0500

In message <[email-masked]>, Simon Josefsson writes:

.....

>Was there a last call for this document?  I do not recall seeing it.
Informational RFCs do not require Last Calls.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Sam Hartman <[email-masked]>
Date: Mon, 06 Feb 2006 20:45:21 -0500

It seems fairly clear to me that four-clause BSD is free software and
open source, just not GPL compatible.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 06 Feb 2006 23:16:28 -0500

> open source, just not GPL compatible.

True, but it can also be somewhat impractical.

---

From: Russ Housley <[email-masked]>
Date: Tue, 07 Feb 2006 09:32:43 -0500

>Was there a last call for this document?  I do not recall seeing it.

Informational documents do not require an IETF Last Call.  The 
sponsoring AD can issue one if they think that community input id 
needed, but most Informational RFCs do not have an IETF Last Call.  I 
choose to progress this document without an IETF Last Call.

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Feb 2006 07:45:03 -0800

At 9:32 AM -0500 2/7/06, Russ Housley wrote:
>needed, but most Informational RFCs do not have an IETF Last Call. 
>I choose to progress this document without an IETF Last Call.

For some stand-alone informational RFCs, not having an IETF-wide last 
call is probably reasonable. However, a document like this is going 
to be referenced many times in other RFCs, sometimes as a normative 
reference. It would be useful to have IETF-wide last calls on all 
documents that are going to be widely referenced, if for no other 
reason than to alert the authors of the documents that will reference 
them that they have an opportunity for open discussion.

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Tue, 07 Feb 2006 11:03:50 -0500

Paul:

>For some stand-alone informational RFCs, not having an IETF-wide 
>last call is probably reasonable. However, a document like this is 
>going to be referenced many times in other RFCs, sometimes as a 
>normative reference. It would be useful to have IETF-wide last calls 
>on all documents that are going to be widely referenced, if for no 
>other reason than to alert the authors of the documents that will 
>reference them that they have an opportunity for open discussion.

It is not clear to me that this will become a normative 
reference.  The FIPS could remain the normative reference, with this 
as a supporting informational one.

Russ

---

From: Pekka Savola <[email-masked]>
Date: Tue, 7 Feb 2006 18:37:07 +0200 (EET)

>   mentioning or referencing this software.

The bigger problem with this is IMHO that I don't think RFCs are 
supposed to contain IPR disclosures, licenses, or whatever.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Feb 2006 12:03:16 -0500

>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:

    Pekka> The bigger problem with this is IMHO that I don't think
    Pekka> RFCs are supposed to contain IPR disclosures, licenses, or
    Pekka> whatever.

I'll agree with you on the IPR disclosures.

RFCs should also not contain copyright statements besides the ISOC copyright.

Licenses (non-exclusive grants of copyright) seem to be OK provided
they clearly grant additional permissions and cannot restrict
permissions.

---

From: Russ Housley <[email-masked]>
Date: Tue, 07 Feb 2006 12:15:18 -0500

Most RFCs do not contain source code.  The IESG discussed this 
situation, and felt that the explicit licenses was the right thing to 
do in this situation.  Including source code without any indication 
of the authors intent seemed much worse.

Russ

---

From: Joe Touch <[email-masked]>
Date: Tue, 07 Feb 2006 11:24:26 -0800

Russ Housley wrote:
> Most RFCs do not contain source code.

Algorithm specs are the exception, and typically do contain reference
code, though.

They tend to include licenses in that code, however. That code is
typically given as an example, in which case it is more like including a
large quoted text than a focus of the body of the text.

Joe

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 07 Feb 2006 15:46:22 -0500

On Tuesday, February 07, 2006 12:15:18 PM -0500 Russ Housley 
<[email-masked]> wrote:

> Most RFCs do not contain source code.  The IESG discussed this situation,
> and felt that the explicit licenses was the right thing to do in this
> situation.  Including source code without any indication of the authors
> intent seemed much worse.

I fail to see the difference between this case and that of RFC1321.
That was also an informational document describing a hash algorithm 
originally specified outside the IETF.  It also included a reference 
implementation, under remarkably similar license terms.  It was right to 
publish that document in 1992, and it is just as right to publish this one 
today.

-- Jeff

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 07 Feb 2006 16:29:14 -0500

In message <[email-masked]>, Jeffrey Hutzelman 
>publish that document in 1992, and it is just as right to publish this one 

In the abstract, you're completely correct.  But IETF procedures have 
tightened up a lot since 1992; we're much more aware of certain things. 
I'm not saying it's wrong to include that license today -- fortunately, 
I no longer have to have an opinion on such things! -- but I don't 
think that 1321 is a binding precedent.

---

From: Tony Hansen <[email-masked]>
Date: Tue, 07 Feb 2006 22:16:58 -0500

If this sentence were changed to read:

   Royalty free license to copy and use this software is granted,
   provided that redistributed derivative works do not contain
   misleading author or version information.

would that satisfy your concerns? The new wording is similar to the
phrasing found in the comparable statement in punycode's RFC 3492.

	Tony Hansen
	[email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 08 Feb 2006 09:53:48 +0100

Tony, yes, I believe that would be fine.  The best would be to ask
debian-legal (or a similar community) to review it.  They have
experience in evaluating software licenses.  I'll forward the updated
language to them, and will relay any responses that indicate a
problem.

Generally, it is unfortunate and problematic to create new licenses.
Incompatibilities and problems have a history of turning up later on.
I believe the IETF should adopt a specific permissive license for its
publications to avoid this problem.  The license should be reviewed by
the community.  If people are interested in this topic, please
participate in the IPR working group.

Regards,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Feb 2006 11:50:11 +0100

Tony,

That would have amounted to the author and IESG deciding
to change the IETF's policy on derivative works, which would
have been way out of line, especially in view of the ongoing
debate about this point in the ipr WG.

Although I agree with Steve Bellovin that RFC 1321 isn't
automatically a precedent, I have no indication that it's
caused any problems. I wasn't involved the decision about
RFC 3492, so I can't comment.

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 11 Feb 2006 17:03:01 +0100

> debate about this point in the ipr WG.

I disagree.

Similar license terms are already part of several RFCs, and they don't
amount to change the official IETF policy.  Such license statements
merely make those particular document more useful.

Compare RFC 3492, and the license terms in it.  I believe
Internationalized Domain Names would not have been deployed as fast if
that document did not contain source under a license that permitted
free use of it (_including_ modifications).  I was able to use that
code in my LibIDN.

Further, the license in this approved document was not in line with
either BCP 78 nor RFC 1321.  The IESG apparently did not object to the
licensing terms (rightly, I believe).

> caused any problems.

Awkward licensing creates problems continuously.  The IETF have been
told about this repeatedly.  Witness the FreeBSD 6.0 release
announcement and the discussion with the IAB/IESG that preceded it.
Witness Debian's continued work on removing all traces of RFCs inside
the packages they distribute.

I don't understand why you keep repeating that there are no
indications of troubles caused by the current licensing terms.  It is
simply false.

Thanks,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Sat, 11 Feb 2006 13:42:17 -0500

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:

    Brian> Tony, That would have amounted to the author and IESG
    Brian> deciding to change the IETF's policy on derivative works,
    Brian> which would have been way out of line, especially in view
    Brian> of the ongoing debate about this point in the ipr WG.

Had this sentence been added by the author it would not have changed
anything about IETF policy.

---

From: Tony Hansen <[email-masked]>
Date: Sat, 11 Feb 2006 22:56:41 -0500

And *as* one of the authors of the proposed-RFC in question, I find the
statement even more curious. Given the objections, I was proposing
different text that would have aligned the statement with text already
found in other RFCs already published.

	Tony Hansen
	[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Feb 2006 14:43:30 +0100

My point is only that while we have an active WG looking at the question
of license terms for the use of text from RFCs, it wouldn't be
right for the IESG to unilaterally approve a new policy, even for a
single draft. I don't believe the approved text does set a new
policy.

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Feb 2006 15:24:33 +0100

How about updating the document with the new license, and ask for a
IETF-wide last call on it?

If anyone has a problem with a license that make it possible for
everyone to use the code in the document, they can tell the IESG the
reasons.

I really don't understand why making this change to the license would
be such a big deal.  It seems as if you are saying that authors
contributing to IETF documents are not entitled to make their work
available under a more permissive license than the IETF has decided
on.  Since the IETF policy is too restrictive to permit use of the
source code in free software, some authors may want to address that
issue in their documents.  The IETF should not object to that, in my
opinion.  Again, compare the license in RFC 3492 or RFC 4027, they
were approved by the IESG fairly recently.  (Or even RFC 4398 for an
even fresher example, it has been approved, and is in AUTH48.)

Thanks.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 14 Feb 2006 14:50:09 -0500

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:

    Brian> My point is only that while we have an active WG looking at
    Brian> the question of license terms for the use of text from
    Brian> RFCs, it wouldn't be right for the IESG to unilaterally
    Brian> approve a new policy, even for a single draft. I don't
    Brian> believe the approved text does set a new policy.

    Brian>     Brian

I don't think the proposed change from one of the authors does either.
I think it is well within what we have recently approved.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Feb 2006 10:22:13 +0100

> I think it is well within what we have recently approved.

I think it's linked to the question we're discussing in IPR about
relaxing our change control, which is why I'm hesitant. Simon is
correct of course; if such a change was successfully Last Called the
IESG would (IMHO) be entitled to approve it.

    Brian

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Feb 2006 09:49:55 -0500

>>>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    Brian> My point is only that while we have an active WG looking
    >> at
    Brian> the question of license terms for the use of text from
    Brian> RFCs, it wouldn't be right for the IESG to unilaterally
    Brian> approve a new policy, even for a single draft. I don't
    Brian> believe the approved text does set a new policy.  Brian
    >> I don't think the proposed change from one of the authors does
    >> either.  I think it is well within what we have recently
    >> approved.

    Brian> I think it's linked to the question we're discussing in IPR
    Brian> about relaxing our change control, which is why I'm
    Brian> hesitant. Simon is correct of course; if such a change was
    Brian> successfully Last Called the IESG would (IMHO) be entitled
    Brian> to approve it.

No.  The question in IPR is what the IETF working group does with all
of its documents.

Authors already have the permission under our current process to relax
the change control.  I have the ability to try and convince any author
they should do so.

By preventing an author from including an additional statement we've
agreed to in the license you don't prevent the author from relaxing
the change control.  You simply prevent the community from knowing
about it and being able to take advantage of it.
Failing to document reality is not generally considered a virtue in these parts:-)

Also note that the IESG has already approved a document of Simon's
with change control provisions at least as liberal as what is being
discussed here.

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Feb 2006 10:17:03 -0500

It is not clear to me what I ought to do at  this point.  I will 
conduct the Last Call if requested by the document authors, but I 
need exact text for it.

Russ

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 15 Feb 2006 09:22:59 -0600

Dear Sam,

> Failing to document reality is not generally considered a virtue in these 

I can't decide whether this appropriate sentiment would work better as a 
t-shirt or as a tattoo...

Thanks for sharing!

Spencer