Subject: Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Mar 2007 10:06:44 -0400

Folks, we didn't get a lot of support expressed in the second last
call.  If I were making a consensus call today I'd say we do not have
consensus to publish draft-housley-tls-authz-extns as a proposed
standard given the IPR claims against it.

However Russ pointed out to me that it may be that people thought this
was a typical last call where silence meant agreement.  I think even
under that interpretation things look grim: silence means agreement
with the prevailing expressed opinion.

But to make absolutely sure I propose to conduct a last call to
confirm that we don't have consensus to publish as a proposed
standard.  Does this seem like the right approach to folks?  I plan to
take some next step within the next couple of days based on input.

I'm sorry this issue is taking up so much of the community's time.

Sam Hartman
Security Area Director

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 29 Mar 2007 16:33:47 +0200

I don't care strongly about the standards track status.  However,
speaking as implementer of the protocol: If the document ends up as
informational or experimental, I request that we make an exception and
allow the protocol to use the already allocated IANA protocol
constants.  That will avoid interoperability problems.  I know the
numbers are allocated from the pool of numbers reserved for standards
track documents.  There is no indication that we are running out of
numbers in that registry.  Thus, given the recall, I think the IETF
should be flexible and not re-assign the IANA allocated numbers at
this point just because of procedural reasons.

/Simon

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 29 Mar 2007 16:39:07 +0200

Sam Hartman wrote:
 
> I propose to conduct a last call to confirm that we don't
> have consensus to publish as a proposed standard.  Does
> this seem like the right approach to folks?

Did that ever happen before ?  A Last Call trying to get 
consensus that there's no consensus.

If "silence means agreement" my silence about the Last Call
for say the "channels bindings" only indicates my agreement
that I have not understood its implications for SASL.

Now I wonder what my silence wrt to your proposed Last Call
could mean.  Agree to IANAL would be fine with me.

Frank

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Mar 2007 10:44:20 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> I don't care strongly about the standards track status.
    Simon> However, speaking as implementer of the protocol: If the
    Simon> document ends up as informational or experimental, I
    Simon> request that we make an exception and allow the protocol to
    Simon> use the already allocated IANA protocol constants.  That
    Simon> will avoid interoperability problems.  I know the numbers
    Simon> are allocated from the pool of numbers reserved for
    Simon> standards track documents.  There is no indication that we
    Simon> are running out of numbers in that registry.  Thus, given
    Simon> the recall, I think the IETF should be flexible and not
    Simon> re-assign the IANA allocated numbers at this point just
    Simon> because of procedural reasons.

Would you support publication on the standards track given the IPR
situation as someone who has implemented?

---

From: Dave Cridland <[email-masked]>
Date: Thu, 29 Mar 2007 15:45:26 +0100

On Thu Mar 29 15:39:07 2007, Frank Ellermann wrote:
> Did that ever happen before ?  A Last Call trying to get consensus 
> that there's no consensus.

Well, it's a call to establish that there is consensus not to publish 
as a proposed standard, if you prefer a slightly less confusing 
phrasing.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Mar 2007 10:44:20 -0400

---

From: Dave Cridland <[email-masked]>
Date: Thu, 29 Mar 2007 15:45:26 +0100

Dave.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 29 Mar 2007 17:18:21 +0200

I think that the current texts would merit some additional work.
In particular to permit authorisation statements and to clarify
that how which client acts as a proxy for someone else.

I mentioned the first part to the authors some time ago, but
they didn't buy the idea.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 29 Mar 2007 17:12:18 +0200

> situation as someone who has implemented?

If the patent concern is valid and covers TLS libraries or other
applications, no.

However, as far as I am aware of the public information that is
available, the situation appears to be that we don't know whether
these patents apply and to what extent.  I don't know whether the
patents were filed in good or bad faith.  More information from the
patent holders may help here.

If it is possible to implement the protocol without violating the
patents, I would support publication.  I've seen some claims that this
may be possible.  I have no interest in reading these patents myself,
but my position would be influenced if someone knowledgeable reads the
patents.

Given the amount of patents out there, it would be unreasonable for us
to move everything to informational just because someone finds
something that may be relevant to a piece of work.

The community needs to evaluate patent claims, and preferably reach
conservative agreement (rough consensus is not good enough) on whether
we should care about a particular patent or not.  Input to that
community evaluation process may be documentation of legal actions
taken by a patent owner.  Sometimes that may happen only after a
document has been published.

I would support down-grading standards track documents that later turn
out to be patent-infected to informational.  Doing so would avoid
sending a message that the IETF supports patented technology, when the
IETF community didn't know about the patents at publication time.  For
credibility of the process, I believe it is important that these
decisions are only made based on publicly available information.

/Simon

---

From: Ted Hardie <[email-masked]>
Date: Thu, 29 Mar 2007 09:51:54 -0700

>I'm sorry this issue is taking up so much of the community's time.

I thought Eric Rescorla and Pasi Eronen had suggested that this document
be evaluated by the TLS working group and the IPR terms evaluated there.
I have that suggestion in an email thread on the main IETF list, started by
Eric and with the thread title "Last Call Comments on draft-housley-tls-authz-07".
I personally believe that would be a sensible way forward, as it seems
likely that the working group would be better able to evaluate
the impact of the IPR claims (both RedPhone's and IBM's) than the
main IETF list.

Was there a problem that came up with that way forward in Prauge?

				regards,
					Ted

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Mar 2007 13:05:36 -0400

>>>>> "Ted" == Ted Hardie <[email-masked]> writes:

    Ted> I thought Eric Rescorla and Pasi Eronen had suggested that
    Ted> this document be evaluated by the TLS working group and the
    Ted> IPR terms evaluated there.  I have that suggestion in an
    Ted> email thread on the main IETF list, started by Eric and with
    Ted> the thread title "Last Call Comments on
    Ted> draft-housley-tls-authz-07".  I personally believe that would
    Ted> be a sensible way forward, as it seems likely that the
    Ted> working group would be better able to evaluate the impact of
    Ted> the IPR claims (both RedPhone's and IBM's) than the main IETF
    Ted> list.

The problem is that this work is outside the charter of the TLS
working group.  So, I don't think asking them to take on the document
would be appropriate.
I also don't think rechartering TLS for this purpose would be appropriate.

If there is a question we can ask that does not involve them taking on
responsibility for the technical details of the work then I'd be happy
to take that path forward.  It's important in writing such a question
not to ask them to make a consensus determination about the IPR claims
as the IETf doesn't do that, but rather to focus on the document given
the IPR claims.

I don't know how to do that without asking them to take on the
document as a whole.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 29 Mar 2007 11:11:03 -0700

>I also don't think rechartering TLS for this purpose would be appropriate.

It is actually fairly common for working groups to provide advice to the
community on work that is related to their charter and not on it.  If you
do not wish to amend the TLS charter, you can make a positive evaluation
by TLS a necessary step before you agree to sponsor this document; since
that would not make the draft a work product of the working group, I don't
think that would require a full re-charter.  A re-charter would allow you,
obviously, to move change control into the WG and allow competing
proposals to be put forward.  That might be useful at this point, but it
also doesn't seem required.

Basically, I think this has moved to the stage where evaluation by a community
of developers and potential licensees is the best way forward.  The review
by the IETF community as a whole does not seem to be providing this.  You
can, of course, just drop it as a result.  But if you are concerned to get a more
realistic up/down evaluation, then having TLS do the evaluation or chartering
some WG to do the work seem to be the obvious choices.

				Ted

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 29 Mar 2007 15:07:21 -0400

On Thu, 29 Mar 2007 17:12:18 +0200

> decisions are only made based on publicly available information.

To be consistent with IETF process and IPR policy, I think that the only
way to do that is via a "standards action" -- an IETF consensus call
(often preceeded by a WG discussion and last call) to downgrade the
document.  Reclassifying documents as Historic is done by separate RFCs
-- I suspect that that's the mechanism that would have to be followed
here.

Look at it this way -- we give WGs the right to standardize encumbered
technologies.  If we're to later reject technologies because they've
become encumbered, it's really a case of going through the same sort of
decision process.  

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Mar 2007 16:25:40 -0400

Ted> At 1:05 PM -0400 3/29/07, Sam Hartman wrote:
    >> working group.  So, I don't think asking them to take on the
    >> document would be appropriate.  I also don't think rechartering
    >> TLS for this purpose would be appropriate.

    Ted> It is actually fairly common for working groups to provide
    Ted> advice to the community on work that is related to their
    Ted> charter and not on it.  If you do not wish to amend the TLS
    Ted> charter, you can make a positive evaluation by TLS a
    Ted> necessary step before you agree to sponsor this document;
    Ted> since that would not make the draft a work product of the
    Ted> working group, I don't think that would require a full
    Ted> re-charter.  A re-charter would allow you, obviously, to move
    Ted> change control into the WG and allow competing proposals to
    Ted> be put forward.  That might be useful at this point, but it
    Ted> also doesn't seem required.

Ted, I'd like to do this.  However I could use some help figuring out
exactly what question I'm asking the TLS working group to provide
advice on.  I guess it could be as simple as "Do you think
draft-housley-tls-authz-extns is worth publishing on the standards
track?"

Would that be the right direction?

---

From: Ted Hardie <[email-masked]>
Date: Thu, 29 Mar 2007 13:56:37 -0700

>draft-housley-tls-authz-extns is worth publishing on the standards

That sounds fine to me.  You could load it up with other questions
(about the IANA considerations, the IPR issues, or competing
proposals), but the upshot really does come down to:  "You're
the folks who will live with this: is it a good idea?"  Your
formulation captures that well enough, in my opinion.
		regards,
				Ted

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Mar 2007 17:13:45 -0400

Ted> At 4:25 PM -0400 3/29/07, Sam Hartman wrote:
    >>  Ted, I'd like to do this.  However I could use some help
    >> figuring out exactly what question I'm asking the TLS working
    >> group to provide advice on.  I guess it could be as simple as
    >> "Do you think draft-housley-tls-authz-extns is worth publishing
    >> on the standards track?"

    Ted> That sounds fine to me.  You could load it up with other
    Ted> questions (about the IANA considerations, the IPR issues, or
    Ted> competing proposals), but the upshot really does come down
    Ted> to: "You're the folks who will live with this: is it a good
    Ted> idea?"  Your formulation captures that well enough, in my
    Ted> opinion.  regards, Ted

OK.  Then my current best thing to do is to send the question above to
the TLS working group.  The authors have indicated they may ask me for
a delay and if they do I'll honor that.  This seems far better than a
third last call to confirm lack of consensus.

Thanks for your help.

--Sam

---

From: "Mark Brown" <[email-masked]>
Date: Thu, 29 Mar 2007 11:50:17 -0500

Simon,

I filed for patent (Jan and Sep 2005) and later promoted TLS authz (Feb
2006) in good faith.  It is possible that the patent claims can be read more
broadly than I expected, but that's a fairly detailed and unresolved legal
question.  I am working diligently to -- let me speak carefully -- explore
if and how I can make a royalty free license grant to ensure that promoting
TLS authz continues to be an act in good faith, while still protecting a way
for my company to make money on its IPR.

I have experienced some surprises when mixing law and Internet standards.
To try to avoid surprises, I have hired IPR attorneys at two different firms
to review my draft which proposes a royalty-free license grant.  I expect
any resulting license will be conditioned upon IETF acceptance of TLS authz
as a standard.  I hope to have concluded these services next week.

I think IPR questions are complicated in part because for some questions
only a lawsuit can answer the question -- but we should all want to stay
clear of these kinds of lawsuits!  So answers seem to me to be in short
supply.  I want to craft the proposed license to make this situation a
little clearer than that, but doing so often involves taking risks of giving
away a huge loophole.  So I'm working to get good legal advice.

In short, I am working to create a royalty-free license grant -- hopefully I
can disclose it next week.  With some luck, it will clarify the situation.

Best regards,

mark

> -----Original Message-----
> From: Simon Josefsson [mailto:[email-masked]]
> Sent: Thursday, March 29, 2007 10:12 AM
> To: Sam Hartman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Withdrawal of Approval and Second Last Call: draft-housley-
> tls-authz-extns
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Mar 2007 10:12:14 -0700

>as a standard.  I hope to have concluded these services next week.

You may feel that this is an offer, but it is in fact a form of 
bargaining. "If you put this on standards track, then we will (or 
might) give a royalty-free license". That is a poor bargain for the 
IETF, and the IETF should not consider the offer when it decides 
whether or not to make the protocol a standard.

This protocol extension does not seem significant enough for the IETF 
to be making bargains, particularly when the IPR holder has not shown 
good faith in the past about being up-front about what they know. A 
reasonable way forward would be to simply publish it as an 
Informational RFC as if it had been brought to the RFC Editor as an 
individual submission.

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Fri, 30 Mar 2007 13:56:58 -0400

--On Friday, 30 March, 2007 10:12 -0700 Paul Hoffman
<[email-masked]> wrote:

>> I have experienced some surprises when mixing law and
>> Internet standards. To try to avoid surprises, I have hired
>> IPR attorneys at two different firms to review my draft which
>> proposes a royalty-free license grant.  I expect any
>> resulting license will be conditioned upon IETF acceptance of
>> TLS authz as a standard.  I hope to have concluded these
>> services next week.
> 
> You may feel that this is an offer, but it is in fact a form
> of bargaining. "If you put this on standards track, then we
> will (or might) give a royalty-free license". That is a poor
> bargain for the IETF, and the IETF should not consider the
> offer when it decides whether or not to make the protocol a
> standard.
> 
> This protocol extension does not seem significant enough for
> the IETF to be making bargains, particularly when the IPR
> holder has not shown good faith in the past about being
> up-front about what they know. A reasonable way forward would
> be to simply publish it as an Informational RFC as if it had
> been brought to the RFC Editor as an individual submission.

For whatever it is worth, I think we need to step carefully
around the distinction Paul makes above: there are almost
certainly circumstances in which we should accept a broader
grant of rights conditional on standardization and a narrower
one if the technology is not standardized.  I wish the IPR WG
were paying a bit more attention to this sort of issue.

However, in this particular case, I tend to agree with Paul.
While I'd be happy to hear the opinion of the TLS WG on the
subject, I don't think the case has yet been made that these
extensions are sufficiently important that the IETF should
standardize an encumbered technology --or engage in a
negotiation about those encumbrances, especially with parties
who appear to have been less forthcoming in the past than our
rules require.

I also do not believe that it is appropriate to view
Informational publication as some sort of consolation prize.
If the community, and the IESG, conclude that the document and
its technology should be standardized, then Informational
publication should not be automatic: the document should be
reviewed for sponsorship appropriateness according the IESG's
recently-published procedures or actually handed off to the RFC
Editor as an independent submission.

    john

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 30 Mar 2007 13:42:51 -0500

Just following onto John's note.

> were paying a bit more attention to this sort of issue.

Again, for whatever it is worth, these two-level statements have been fairly 
common in IPR disclosures in the past. I didn't scan the 600 or so 
disclosures this afternoon, but in the most recent ID-specific disclosures, 
this seems to be more common than not (see 
https://datatracker.ietf.org/public/ipr_list.cgi to check my math).

I wonder from time to time how these conditional grants are supposed to 
interact with prototype implementations before a standard is approved ("... 
and running code"), but if I sit very still, that thought usually goes away.

Thanks,

Spencer

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 30 Mar 2007 14:36:45 -0400

On Friday, March 30, 2007 10:12:14 AM -0700 Paul Hoffman 
<[email-masked]> wrote:

>> To try to avoid surprises, I have hired IPR attorneys at two different
>> firms to review my draft which proposes a royalty-free license grant.  I
>> expect any resulting license will be conditioned upon IETF acceptance of
>> TLS authz as a standard.  I hope to have concluded these services next
>> week.
>
> bargaining. "If you put this on standards track, then we will (or might)
> give a royalty-free license". That is a poor bargain for the IETF, and
> the IETF should not consider the offer when it decides whether or not to
> make the protocol a standard.

I think there is a significant exception which may apply in this case.  If 
the IPR issues are the sole remaining factor in the IETF's decision as to 
whether to make a protocol a standard, then I think it is entirely 
reasonable for the IETF to consider an offer which would eliminate or at 
least mitigate those issues if the protocol were to become a standard.  I 
see nothing wrong with saying "I'm willing to grant a reasonable license if 
my technology becomes a standard, but reserve the right to make money 
otherwise", as long as the IETF does not allow such an offer to result in 
adoption as a standard of something it would not have standardized 
otherwise.

As for informational vs an independent submission, I think there is a 
factor to be considered.  It seems to me that an informational IETF 
document is a fine way to say "this is a good idea, and we think this is 
the right way to do FOO, but we can't actually recommend it (for whatever 
reason)".  For example, we have at least one document that defines the use 
of elliptic curve cryptography with one of our protocols, which is 
informational because the working group that produced it didn't feel they 
could recommend it as a standard due to the hairy IPR issues surrounding 
that technology.

-- Jeff

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 30 Mar 2007 13:42:51 -0500

Thanks,

Spencer

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 30 Mar 2007 14:36:45 -0400

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Fri, 30 Mar 2007 15:51:17 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> I also do not believe that it is appropriate to view
    John> Informational publication as some sort of consolation prize.
    John> If the community, and the IESG, conclude that the document
    John> and its technology should be standardized, then
    John> Informational publication should not be automatic: the
    John> document should be reviewed for sponsorship appropriateness
    John> according the IESG's recently-published procedures or
    John> actually handed off to the RFC Editor as an independent
    John> submission.

I agree with John here.  I've basically concluded that I'm not
interested in sponsoring this document as an informational or
experimental document.  I feel that it would come across way too much
as a consolation prise and I'm not sure that  it would be justified.

If the IETF decides it is appropriate I'm happy to continue my
sponsorship on the standards track.

Note that the decision of whether I sponsor a document is one I get to
make; it is not subject to community consensus.

I would not object to an independent submission and while I think I
would advise other ADs against sponsoring info/experimental, I would
not hold a discuss if they chose to do so.

--Sam

---

From: Scott W Brim <[email-masked]>
Date: Sat, 31 Mar 2007 08:49:06 -0400

> were paying a bit more attention to this sort of issue.

This is a WG decision.  IPR WG could produce guidance on the subject,
but that's all.  What are you looking for?

On 03/30/2007 14:36 PM, Jeffrey Hutzelman wrote:
> If the IPR issues are the sole remaining factor in the IETF's decision
> as to whether to make a protocol a standard, then I think it is entirely
> least mitigate those issues if the protocol were to become a standard. 

As Spencer pointed out, text like "If included in a standard" is
common.  We already do this implicitly.

swb

---

From: John C Klensin <[email-masked]>
Date: Sat, 31 Mar 2007 10:28:48 -0400

--On Saturday, 31 March, 2007 08:49 -0400 Scott W Brim
<[email-masked]> wrote:

> This is a WG decision.  IPR WG could produce guidance on the
> subject, but that's all.  What are you looking for?

While I have an opinion on this particular case, I am more
concerned about our precedents and decision-making processes
than I am about it.   Paul's note seemed to be saying "the IETF
should never accept material if IPR conditions are contingent on
standardization".  I don't know if that is what he intended, but
I consider such a principle to be dangerous to us if
generalized".

I believe that any time the IETF considers adoption of an
encumbered technology we need to weight importance of
standardizing any technology in the area and the availability of
alternatives against the particular encumbrances.  I believe
that is the case whether the issue is particular IPR terms (such
as RAND iff standardization) or  the specifics of the
encumbrances.  I believe that decision ultimately has to be an
IETF one, not merely that of an individual WG.

But I believe that advice from the appropriate WG is useful to
the community in determining whether something should be
standardized in spite of the IPR entanglements.  To some extent,
if a WG is given the opportunity to examine a particular
proposal and chooses to not take it up and comment, that
provides part of the answer: absent strong evidence from other
sources, the proposal isn't valuable enough to standardize
especially given IPR restrictions.

>> If the IPR issues are the sole remaining factor in the IETF's
>> decision as to whether to make a protocol a standard, then I
>> think it is entirely reasonable for the IETF to consider an
>> offer which would eliminate or at least mitigate those issues
>> if the protocol were to become a standard. 
> 
> As Spencer pointed out, text like "If included in a standard"
> is common.  We already do this implicitly.

Indeed.

    john

---

From: Eliot Lear <[email-masked]>
Date: Sat, 31 Mar 2007 17:15:33 +0200

Jeff,
> document is a fine way to say "this is a good idea, and we think this 
> is the right way to do FOO, but we can't actually recommend it (for 
> whatever reason)".  For example, we have at least one document that 
> defines the use of elliptic curve cryptography with one of our 
> protocols, which is informational because the working group that 
> produced it didn't feel they could recommend it as a standard due to 
> the hairy IPR issues surrounding that technology.
Most people outside of this organization can't tell the difference 
between a standard and an informational document.  They simply look at 
the label "RFC" and are done.  And now you are trying to cut the line 
even thinner?

Eliot